Lesson 06 — Push-to-Deploy

From a signed image in GHCR to a running container in the cloud — with environment-scoped secrets and a blue/green pattern.

Cloud & DevOps Module 2

What we have so far

• L04 — GitHub Actions: green CI on every PR; lint, build, and test run automatically
• L05 — Security & Signing: Trivy scan + SBOM attestation + cosign signature on every merge to main
• The image is pushed to GHCR and signed — it is available and verified
• The gap: nothing actually pulls that image and runs it. The deploy step is missing.

The deploy spectrum

Today: one step right of manual — a CI job invokes the deploy on push to main.

GHCR vs ECR vs other registries

We use GHCR for all course labs. The lab guide includes a side note on the ECR variant.

Environment-scoped secrets

GitHub Environments (Settings → Environments) let you scope secrets to specific environments such as production or staging. The production environment can require manual approval before its secrets are released to a job.

• Secrets — only injected when a job opts into that environment; invisible to every other job
• Required reviewers — the job pauses and waits for a named reviewer to approve in the GitHub UI
• Wait timer — an optional soak period between approval and secret release
• Deployment branch policy — only branches matching the pattern can deploy to that environment (e.g., only main → production)

Defining an environment in a workflow

deploy:
  environment:
    name: production
    url: https://shortener.example.com

When this job runs, GitHub checks the production environment policy. If a required reviewer is configured, the job blocks until that reviewer approves in the GitHub Actions UI. Only then are the production secrets injected and the steps begin executing.

• The url: field powers the “deployed to” link in the GitHub deployment history
• Without it, the deployment link in the UI is blank — a common oversight

The deploy step: simplest version (SSH to a VM)

- uses: appleboy/ssh-action@v1
  with:
    host: ${{ secrets.DEPLOY_HOST }}
    username: ${{ secrets.DEPLOY_USER }}
    key: ${{ secrets.DEPLOY_KEY }}
    script: |
      docker pull ghcr.io/$ORG/$REPO/api:${{ github.sha }}
      docker compose -f /opt/shortener/docker-compose.yml up -d

• DEPLOY_HOST, DEPLOY_USER, DEPLOY_KEY are production environment secrets
• appleboy/ssh-action is a placeholder — L07 replaces it with a Terraform-provisioned target
• docker compose up -d recreates only changed services; volumes and networks persist
• L09 replaces SSH entirely with kubectl apply against a Kubernetes cluster

Blue/green basics

  ┌──────────────────────────────────────────────────┐
  │                  Load Balancer / Router           │
  └─────────────────┬────────────────────────────────┘
                    │  ◀── traffic flows here
          ┌─────────▼──────────┐   ┌────────────────────┐
          │    BLUE (live)      │   │   GREEN (idle)      │
          │  api:sha-a1b2c3d    │   │  api:sha-e4f5g6h    │
          └────────────────────┘   └────────────────────┘
  

• One environment serves production traffic; the other is idle
• Deploy the new version to the idle environment; smoke-test it
• Flip the router to point traffic at the new environment
• Rollback = flip the router back — instant, no re-deploy needed
• Cost: 2× infrastructure; the tradeoff is zero-downtime cutovers

Blue/green in a workflow (sketch)

- name: Deploy to blue
  run: ./deploy.sh blue ${{ github.sha }}

- name: Smoke test blue
  run: curl -fsS https://blue.shortener.example.com/healthz

- name: Flip traffic
  run: ./flip.sh blue

• The ./deploy.sh and ./flip.sh scripts are stand-ins for the actual routing primitive
• A real blue/green flip needs a load balancer rule, an ingress annotation, or a service weight
• L11 (Ingress) and L13 (HPA-aware services) build the routing primitive this sketch assumes
• This slide is the shape of the pattern — the wiring is environment-specific

Tag your deploys with the digest

Deploying by digest (@sha256:…) instead of a mutable tag (:latest) prevents the surprise of a silently mutated tag.

# Risky: tag can be overwritten
docker pull ghcr.io/org/repo/api:latest

# Safe: digest is content-addressable, immutable
docker pull ghcr.io/org/repo/api@sha256:abc123...

• Pair this with L05’s signature: verify the signature on the digest, then deploy the digest
• The commit SHA → digest mapping is your source of truth
• Store the digest in the workflow output or a deployment artifact so rollback can reference it

Rollback strategy

Three options, from simplest to most GitOps-consistent:

All three need the previous digest written down somewhere. Design your pipeline to emit it.

What we’ll build in lab

• A deploy.yml workflow that triggers via workflow_run after security.yml succeeds on main
• Cosign verification steps that confirm both the api and worker images are signed before deploying
• A GitHub Environment production with a manual approval gate
• An SSH step using appleboy/ssh-action that pulls the new image and runs docker compose up -d on the target VM
• Concurrency control: cancel-in-progress: false so two quick pushes queue rather than race

Common gotchas

• Deploying without verifying the signature — defeats all the work done in L05; the verify steps must run before the SSH step, not after
• Deploying :latest — you can’t deterministically roll back to “the previous :latest” because the tag is mutable; always deploy by commit SHA or digest
• Missing environment.url — the GitHub UI deployment history shows a blank “deployed to” link; the deployment event still fires but is harder to trace
• Concurrency unset — two pushes in quick succession start two deploy jobs that can partially deploy each and leave the target in an inconsistent state; add the concurrency: block

Recap & what’s next

• Registry → environment-scoped secrets → deploy step: the three-part structure of a push-to-deploy pipeline
• Deploy by digest, not by tag — content-addressable references pair with L05’s cosign signatures
• Blue/green is the rollback pattern: deploy to idle, smoke-test, flip the router; the routing primitive comes in later modules