🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

🚚 धडा 10 — CI मधून Kubernetes वर deploy: delivery व्हॅन

📍 तुम्ही इथे आहात: 12 पैकी धडा 10 · मागील: lesson-09-deploy-strategies · पुढील: lesson-11-four-dialects

📦 या ब्रँचमध्ये काय आहे

धडे 01–09, आणि त्याशिवाय व्हॅनचा पूर्ण मार्ग: day pass घ्या, शाळा शोधा, placeholder बदला, सूचना लावा, ती वाचनीय होईपर्यंत थांबा, घरी परत जा. खऱ्या files:

.github/workflows/deploy.yml — व्हॅन: staging job, मग gate असलेला production job
.github/workflows/ship.yml — workflow_call मधून व्हॅनला image reference देतो
k8s/deployment.yaml · k8s/service.yaml — जे apply होते ते, बदलण्याची वाट पाहणाऱ्या IMAGE_PLACEHOLDER सह
iam/ci-role-policy.json — update-kubeconfig ला लागणारी एकमेव permission म्हणजे eks:DescribeCluster

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

फोटोकॉपी लॉकरमध्ये 🏦 आहेत (धडा 07) आणि प्राचार्यांच्या सहीचा नियम ठरला आहे (धडा 08). तरीही कोणाला तरी गाडी चालवत शाळेत जावे लागते. 🚚

प्रत्येक फेरीत व्हॅन त्याच चार गोष्टी करते:

फाटकावर आपला badge दाखवते 🪪 — glove box मध्ये master key नाही. OIDC badge च्या बदल्यात day pass मिळतो (धडा 06), आणि शाळेच्या front desk च्या यादीत व्हॅनचे नाव असते.
शाळा कुठे आहे ते विचारते 🗺️ — aws eks update-kubeconfig पत्ता आणि फाटकाचा pass एका kubeconfig file मध्ये लिहितो.
सूचना लावते 📌 — आजचा copy क्रमांक सूचनेवर लिहिते (sed IMAGE_PLACEHOLDER बदलतो), मग kubectl apply.
वाचनीय होईपर्यंत थांबते ⏳ — धडा 09 चा rolling update पूर्ण होईपर्यंत kubectl rollout status अडवून ठेवतो, किंवा हार मानून अयशस्वी delivery नोंदवतो. सराव फलकावर ती जाणाऱ्या एखाद्या विद्यार्थिनीला सूचना मोठ्याने वाचायलाही सांगते (cluster मधली smoke test).

मग ती घरी परत जाते. आणि इथेच मेख आहे: व्हॅन गेली की mailroom मधले कोणीही फलकावर लक्ष ठेवत नाही. एखाद्या शिक्षिकेने हाताने pin हलवला, तर mailroom ला ते पुढच्या delivery ला कळते, कळलेच तर. हा विचार ArgoCD शाळेसाठी लक्षात ठेवा.

🗺️ आकृती

flowchart LR
    ship["📦 ship.yml<br/>image = …/hello-courier:sha"]
    badge["🪪 configure-aws-credentials<br/>OIDC → day pass"]
    kc["🗺️ aws eks update-kubeconfig"]
    pin["📌 sed IMAGE_PLACEHOLDER<br/>kubectl apply -n staging"]
    wait["⏳ kubectl rollout status<br/>--timeout=180s"]
    smoke["🧪 kubectl run smoke<br/>curl hello-courier/healthz"]
    gate["🛑 environment: production<br/>required reviewers"]
    prod["📌 same four moves<br/>-n production"]
    drift["🤷 nobody watches the board<br/>→ ArgoCD school"]
    ship -->|"1 workflow_call"| badge
    badge -->|"2"| kc
    kc -->|"3"| pin
    pin -->|"4"| wait
    wait -->|"5 exit 0"| smoke
    smoke -->|"6"| gate
    gate -->|"7 approved"| prod
    prod -.->|"8 the van drives away"| drift

❓ काय

Push model = pipeline कडे cluster चे credentials असतात आणि ती बाहेरून बदल आत ढकलते. पर्याय, pull model, मध्ये cluster च्या आतला agent git मधून हवी असलेली स्थिती आणतो — तीच ArgoCD शाळा.
aws eks update-kubeconfig = असे kubeconfig लिहितो ज्याची user entry aws eks get-token चालवते; त्यासाठी role वर eks:DescribeCluster लागते, आणि cluster ने तो IAM role एका Kubernetes identity शी जोडलेला असला पाहिजे (EKS access entries, किंवा जुना aws-auth ConfigMap) — ही एक setup पायरी आहे, इथे शिकवलेली नाही.
Placeholder बदल = git मधला manifest IMAGE_PLACEHOLDER म्हणतो; job apply करण्याआधी खरा reference त्यात लिहितो. हे करणारे सर्वात छोटे tool म्हणजे sed; kustomize edit set image आणि helm upgrade --set image.tag= हे अधिक नीटनेटके आहेत.
kubectl rollout status --timeout = पास/fail गेट: Deployment पूर्ण झाला की exit 0, rollout अडकला किंवा timeout आला तर non-zero.
Cluster मधली smoke test = kubectl run … --image=curlimages/curl namespace च्या आतून Service ला त्याच्या DNS नावाने curl करते, म्हणजे pods आणि Service ची जोडणी चालते हे सिद्ध होते — फक्त container सुरू झाला एवढेच नव्हे.
प्रत्येक environment साठी एक namespace: staging आणि production म्हणजे तेच YAML वेगवेगळ्या -n सह दोनदा apply केलेले. तेच manifests, वेगळा फलक.

🧠 व्हॅनच्या चार चाली — आणि प्रत्येक कशामुळे fail होते

चाल	काय चालते	job fail होतो जेव्हा
🪪 badge	OIDC → तात्पुरते credentials	trust policy चा `sub` या repo आणि branch शी जुळत नाही
🗺️ पत्ता	`aws eks update-kubeconfig`	role कडे `eks:DescribeCluster` नाही, किंवा cluster ने तो जोडलेला नाही
📌 लावणे	`sed` + `kubectl apply -n <ns> -f k8s/`	अवैध YAML, किंवा जोडलेल्या identity ला namespace मध्ये लिहिण्याची परवानगी नाही
⏳ थांबणे	`kubectl rollout status --timeout=180s`	नवा pod वेळेत `/healthz` ला कधीच उत्तर देत नाही

🤔 का

या धड्याआधी "deploy" म्हणजे laptop वर kubeconfig असलेली एक व्यक्ती — कुठेही न लिहिलेले, पुन्हा करायला अवघड, आणि ती file ज्याच्याकडे असेल त्याला बांधलेले. व्हॅनमुळे ते दरवेळी त्याच चार commands होते, commit शेजारी log होते, धडा 08 च्या approval मागे. AWS शाळेचा L05 साठवलेल्या key पेक्षा badge का सरस आहे ते समजावतो; ArgoCD शाळेचा L03 नेमकी हीच pipeline काढतो, आणि त्याचे L04 आणि L05 job संपल्यावर व्हॅनला काय दिसू शकत नाही आणि त्याबद्दल काय करायचे ते मोजतात.

🔧 कसे (या repo मध्ये)

deploy.yml चा पूर्ण staging job:

jobs:
  staging:
    runs-on: ubuntu-latest
    environment: staging                          # the practice notice board
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with: { role-to-assume: "${{ vars.AWS_ROLE_ARN }}", aws-region: "${{ vars.AWS_REGION }}" }
      - name: 🔧 point kubectl at the cluster
        run: aws eks update-kubeconfig --region "${{ vars.AWS_REGION }}" --name "${{ vars.EKS_CLUSTER }}"
      - name: 📌 pin the new notice (rolling update, lesson 09)
        run: |
          sed -i "s|IMAGE_PLACEHOLDER|${{ inputs.image }}|" k8s/deployment.yaml
          kubectl apply -n staging -f k8s/
          kubectl rollout status -n staging deployment/hello-courier --timeout=180s
      - name: 🧪 smoke-test staging from inside the cluster
        run: kubectl run -n staging smoke --rm -i --restart=Never --image=curlimages/curl -- -fsS http://hello-courier/healthz

production job त्याच steps -n production सह, environment: production मागे पुन्हा करतो. अधिक नीटनेटके placeholder बदल असे दिसतात:

# illustrative — this repo ships neither a kustomization.yaml nor a Helm chart
kustomize edit set image hello-courier=123456789012.dkr.ecr.ap-south-1.amazonaws.com/hello-courier:$GITHUB_SHA
helm upgrade --install hello-courier ./chart --set image.tag=$GITHUB_SHA

🔁 हेच CircleCI मध्ये

  deploy-to-eks:
    parameters:
      namespace:
        type: string
    docker:
      - image: cimg/aws:2024.03
    steps:
      - checkout
      - aws-cli/setup:
          role_arn: ${AWS_ROLE_ARN}
          region: ${AWS_DEFAULT_REGION}
      - run:
          name: 📌 apply and wait for the rollout
          command: |
            IMAGE="${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_DEFAULT_REGION}.amazonaws.com/${ECR_REPOSITORY}:${CIRCLE_SHA1}"
            sed -i "s|IMAGE_PLACEHOLDER|${IMAGE}|" k8s/deployment.yaml
            kubectl apply -n << parameters.namespace >> -f k8s/
            kubectl rollout status -n << parameters.namespace >> deployment/hello-courier --timeout=180s

एकच parameterized job, workflows: मधून दोनदा बोलावलेला — namespace: staging सह deploy-staging, आणि hold-for-approval नंतर namespace: production सह deploy-production.

🦊 हेच GitLab CI मध्ये

.deploy: &deploy
  stage: deploy
  image: amazon/aws-cli:2.17.0
  <<: *aws-badge
  script:
    - aws eks update-kubeconfig --region "$AWS_REGION" --name "$EKS_CLUSTER"
    - IMAGE="${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com/${ECR_REPOSITORY}:${CI_COMMIT_SHA}"
    - sed -i "s|IMAGE_PLACEHOLDER|${IMAGE}|" k8s/deployment.yaml
    - kubectl apply -n "$NAMESPACE" -f k8s/
    - kubectl rollout status -n "$NAMESPACE" deployment/hello-courier --timeout=180s

deploy-staging:
  <<: *deploy
  variables: { NAMESPACE: staging }
  environment: { name: staging }

.deploy anchor म्हणजे व्हॅन; प्रत्येक environment म्हणजे तो anchor अधिक एक NAMESPACE आणि एक environment: नाव.

🎩 हेच Jenkins मध्ये

def deployTo(String namespace) {
  withAWS(credentials: 'aws-school-cicd', region: env.AWS_REGION) {
    sh """
      ACCOUNT=\$(aws sts get-caller-identity --query Account --output text)
      IMAGE="\${ACCOUNT}.dkr.ecr.${env.AWS_REGION}.amazonaws.com/${env.ECR_REPOSITORY}:${env.GIT_COMMIT}"
      aws eks update-kubeconfig --region ${env.AWS_REGION} --name ${env.EKS_CLUSTER}
      sed -i "s|IMAGE_PLACEHOLDER|\${IMAGE}|" k8s/deployment.yaml
      kubectl apply -n ${namespace} -f k8s/
      kubectl rollout status -n ${namespace} deployment/hello-courier --timeout=180s
    """
  }
}

deployTo('staging') म्हणून बोलावला जातो, आणि input stage नंतर deployTo('production') म्हणून.

🧪 करून पाहा

व्हॅनचा मार्ग, स्थानिक cluster वर हाताने चालवलेला. फक्त AWS अशी खूण असलेल्या ओळींना account लागते; बाकी kind किंवा Docker Desktop वर चालते.

# 0) local cluster + both boards (skip the first line if lesson 09's cluster is still up)
kind create cluster --name school
kubectl create namespace staging; kubectl create namespace production

# 1) the photocopy — ship.yml's build job, locally (CI tags with the full SHA)
docker build --build-arg APP_VERSION=$(git rev-parse --short HEAD) -t hello-courier:local app
kind load docker-image hello-courier:local --name school   # kind only; Docker Desktop shares its daemon

# 2) the van as a loop: staging, a signature, production
IMAGE=hello-courier:local
for NS in staging production; do
  echo "🚚 delivering $IMAGE to $NS"
  # AWS only: aws-actions/configure-aws-credentials        → locally, your kubeconfig already exists
  # AWS only: aws eks update-kubeconfig --region ap-south-1 --name school-eks
  sed "s|IMAGE_PLACEHOLDER|$IMAGE|" k8s/deployment.yaml | kubectl apply -n "$NS" -f -   # CI: sed -i on its throwaway checkout
  kubectl apply -n "$NS" -f k8s/service.yaml
  kubectl rollout status -n "$NS" deployment/hello-courier --timeout=180s || { echo "❌ failed delivery"; break; }
  kubectl run -n "$NS" smoke --rm -i --restart=Never --image=curlimages/curl -- -fsS http://hello-courier/healthz
  [ "$NS" = staging ] && { echo "🛑 principal: press Enter to approve production"; read -r _; }
done

# 3) AWS only — the real van: set the four repo variables from ship.yml's header, then
gh workflow run deploy.yml -f image=123456789012.dkr.ecr.ap-south-1.amazonaws.com/hello-courier:<full-sha>
gh run watch

⚠️ नेहमीच्या चुका

kubeconfig किंवा दीर्घकाळ चालणाऱ्या AWS keys CI secret म्हणून साठवणे — हीच glove box मधली master key; OIDC role आणि cluster मधले role mapping तिची जागा घेतात
वाट न पाहता apply करणे: API server ने YAML स्वीकारताच kubectl apply परत येतो, म्हणून rollout status पास होईपर्यंत हिरवा job फारसे काही सिद्ध करत नाही
sed -i चा निकाल बाहेर जाऊ देणे: बदललेली deployment.yaml runner वरच फेकून द्यायची राहिली पाहिजे — ती commit केली तर पुढच्या run साठी IMAGE_PLACEHOLDER नाहीसा होतो

⏭️ पुढे

व्हॅनने आता GitHub Actions मध्ये पूर्ण मार्ग पार केला. धडा 11 CircleCI, GitLab आणि Jenkins च्या व्हॅन तिच्या शेजारी उभ्या करतो आणि तुम्हाला शब्दकोश देतो.

git checkout lesson-11-four-dialects

🚚 Lesson 10 — Deploy to Kubernetes from CI: the delivery van

📍 You are here: Lesson 10 of 12 · Previous: lesson-09-deploy-strategies · Next: lesson-11-four-dialects

📦 What's in this branch

Lessons 01–09, plus the van's whole route: get a day pass, find the school, swap the placeholder, pin the notice, wait until it is readable, drive home. Real files:

.github/workflows/deploy.yml — the van: the staging job, then the gated production job
.github/workflows/ship.yml — hands the van the image reference through workflow_call
k8s/deployment.yaml · k8s/service.yaml — what gets applied, IMAGE_PLACEHOLDER waiting to be swapped
iam/ci-role-policy.json — eks:DescribeCluster is the one permission update-kubeconfig needs

🧒 Explain like I'm 5

The photocopies are in the locker 🏦 (lesson 07) and the principal's signature rule is set (lesson 08). Someone still has to drive to school. 🚚

The van does the same four things on every trip:

Shows its badge at the gate 🪪 — no master key in the glove box. The OIDC badge buys a day pass (lesson 06), and the school's front desk has the van's name on its list.
Asks where the school is 🗺️ — aws eks update-kubeconfig writes the address and the gate pass into a kubeconfig file.
Pins the notice 📌 — writes today's copy number onto the notice (sed swaps IMAGE_PLACEHOLDER), then kubectl apply.
Waits until it is readable ⏳ — kubectl rollout status blocks until lesson 09's rolling update finishes, or gives up and reports a failed delivery. On the practice board it also asks a passing student to read the notice back (the in-cluster smoke test).

Then it drives home. And here is the catch: once the van is gone, nobody in the mailroom is watching the board. If a teacher moves a pin by hand, the mailroom finds out at the next delivery, if at all. Hold that thought for the ArgoCD school.

🗺️ Diagram

flowchart LR
    ship["📦 ship.yml<br/>image = …/hello-courier:sha"]
    badge["🪪 configure-aws-credentials<br/>OIDC → day pass"]
    kc["🗺️ aws eks update-kubeconfig"]
    pin["📌 sed IMAGE_PLACEHOLDER<br/>kubectl apply -n staging"]
    wait["⏳ kubectl rollout status<br/>--timeout=180s"]
    smoke["🧪 kubectl run smoke<br/>curl hello-courier/healthz"]
    gate["🛑 environment: production<br/>required reviewers"]
    prod["📌 same four moves<br/>-n production"]
    drift["🤷 nobody watches the board<br/>→ ArgoCD school"]
    ship -->|"1 workflow_call"| badge
    badge -->|"2"| kc
    kc -->|"3"| pin
    pin -->|"4"| wait
    wait -->|"5 exit 0"| smoke
    smoke -->|"6"| gate
    gate -->|"7 approved"| prod
    prod -.->|"8 the van drives away"| drift

❓ What

Push model = the pipeline holds credentials for the cluster and pushes changes in from outside. The alternative, the pull model, has an agent inside the cluster fetch desired state from git — that is the ArgoCD school.
aws eks update-kubeconfig = writes a kubeconfig whose user entry runs aws eks get-token; it needs eks:DescribeCluster on the role, and the cluster must map that IAM role to a Kubernetes identity (EKS access entries, or the older aws-auth ConfigMap) — one setup step, not taught here.
The placeholder swap = the manifest in git says IMAGE_PLACEHOLDER; the job writes the real reference in before applying. sed is the smallest tool that does it; kustomize edit set image and helm upgrade --set image.tag= are the tidier ones.
kubectl rollout status --timeout = the pass/fail gate: exit 0 once the Deployment is complete, non-zero on a stalled rollout or when the timeout hits.
In-cluster smoke test = kubectl run … --image=curlimages/curl curls the Service by its DNS name from inside the namespace, proving pods and Service wiring work — not just that a container started.
One namespace per environment: staging and production are the same YAML applied twice with a different -n. Same manifests, different board.

🧠 The van's four moves — and what fails each one

move	what runs	the job fails when
🪪 badge	OIDC → temporary credentials	the trust policy's `sub` does not match this repo and branch
🗺️ address	`aws eks update-kubeconfig`	the role lacks `eks:DescribeCluster`, or the cluster does not map it
📌 pin	`sed` + `kubectl apply -n <ns> -f k8s/`	invalid YAML, or the mapped identity may not write to the namespace
⏳ wait	`kubectl rollout status --timeout=180s`	the new pod never answers `/healthz` in time

🤔 Why

Before this lesson, "deploy" meant a person with a kubeconfig on a laptop — undocumented, hard to repeat, and tied to whoever holds the file. The van makes it the same four commands each time, logged next to the commit, behind the approval from lesson 08. The AWS school's L05 explains why the badge beats a stored key; the ArgoCD school's L03 draws this exact pipeline, and its L04 and L05 count what the van cannot see once the job ends and what to do about it.

🔧 How (in this repo)

The whole staging job of deploy.yml:

jobs:
  staging:
    runs-on: ubuntu-latest
    environment: staging                          # the practice notice board
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with: { role-to-assume: "${{ vars.AWS_ROLE_ARN }}", aws-region: "${{ vars.AWS_REGION }}" }
      - name: 🔧 point kubectl at the cluster
        run: aws eks update-kubeconfig --region "${{ vars.AWS_REGION }}" --name "${{ vars.EKS_CLUSTER }}"
      - name: 📌 pin the new notice (rolling update, lesson 09)
        run: |
          sed -i "s|IMAGE_PLACEHOLDER|${{ inputs.image }}|" k8s/deployment.yaml
          kubectl apply -n staging -f k8s/
          kubectl rollout status -n staging deployment/hello-courier --timeout=180s
      - name: 🧪 smoke-test staging from inside the cluster
        run: kubectl run -n staging smoke --rm -i --restart=Never --image=curlimages/curl -- -fsS http://hello-courier/healthz

The production job repeats the same steps with -n production behind environment: production. The tidier placeholder swaps look like this:

# illustrative — this repo ships neither a kustomization.yaml nor a Helm chart
kustomize edit set image hello-courier=123456789012.dkr.ecr.ap-south-1.amazonaws.com/hello-courier:$GITHUB_SHA
helm upgrade --install hello-courier ./chart --set image.tag=$GITHUB_SHA

🔁 The same thing in CircleCI

  deploy-to-eks:
    parameters:
      namespace:
        type: string
    docker:
      - image: cimg/aws:2024.03
    steps:
      - checkout
      - aws-cli/setup:
          role_arn: ${AWS_ROLE_ARN}
          region: ${AWS_DEFAULT_REGION}
      - run:
          name: 📌 apply and wait for the rollout
          command: |
            IMAGE="${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_DEFAULT_REGION}.amazonaws.com/${ECR_REPOSITORY}:${CIRCLE_SHA1}"
            sed -i "s|IMAGE_PLACEHOLDER|${IMAGE}|" k8s/deployment.yaml
            kubectl apply -n << parameters.namespace >> -f k8s/
            kubectl rollout status -n << parameters.namespace >> deployment/hello-courier --timeout=180s

One parameterized job, called twice from workflows: — deploy-staging with namespace: staging, and deploy-production with namespace: production after hold-for-approval.

🦊 The same thing in GitLab CI

.deploy: &deploy
  stage: deploy
  image: amazon/aws-cli:2.17.0
  <<: *aws-badge
  script:
    - aws eks update-kubeconfig --region "$AWS_REGION" --name "$EKS_CLUSTER"
    - IMAGE="${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com/${ECR_REPOSITORY}:${CI_COMMIT_SHA}"
    - sed -i "s|IMAGE_PLACEHOLDER|${IMAGE}|" k8s/deployment.yaml
    - kubectl apply -n "$NAMESPACE" -f k8s/
    - kubectl rollout status -n "$NAMESPACE" deployment/hello-courier --timeout=180s

deploy-staging:
  <<: *deploy
  variables: { NAMESPACE: staging }
  environment: { name: staging }

The .deploy anchor is the van; each environment is the anchor plus a NAMESPACE and an environment: name.

🎩 The same thing in Jenkins

def deployTo(String namespace) {
  withAWS(credentials: 'aws-school-cicd', region: env.AWS_REGION) {
    sh """
      ACCOUNT=\$(aws sts get-caller-identity --query Account --output text)
      IMAGE="\${ACCOUNT}.dkr.ecr.${env.AWS_REGION}.amazonaws.com/${env.ECR_REPOSITORY}:${env.GIT_COMMIT}"
      aws eks update-kubeconfig --region ${env.AWS_REGION} --name ${env.EKS_CLUSTER}
      sed -i "s|IMAGE_PLACEHOLDER|\${IMAGE}|" k8s/deployment.yaml
      kubectl apply -n ${namespace} -f k8s/
      kubectl rollout status -n ${namespace} deployment/hello-courier --timeout=180s
    """
  }
}

Called as deployTo('staging'), and after the input stage as deployTo('production').

🧪 Try it

The van's route, driven by hand against a local cluster. Only the lines marked AWS need an account; the rest runs on kind or Docker Desktop.

# 0) local cluster + both boards (skip the first line if lesson 09's cluster is still up)
kind create cluster --name school
kubectl create namespace staging; kubectl create namespace production

# 1) the photocopy — ship.yml's build job, locally (CI tags with the full SHA)
docker build --build-arg APP_VERSION=$(git rev-parse --short HEAD) -t hello-courier:local app
kind load docker-image hello-courier:local --name school   # kind only; Docker Desktop shares its daemon

# 2) the van as a loop: staging, a signature, production
IMAGE=hello-courier:local
for NS in staging production; do
  echo "🚚 delivering $IMAGE to $NS"
  # AWS only: aws-actions/configure-aws-credentials        → locally, your kubeconfig already exists
  # AWS only: aws eks update-kubeconfig --region ap-south-1 --name school-eks
  sed "s|IMAGE_PLACEHOLDER|$IMAGE|" k8s/deployment.yaml | kubectl apply -n "$NS" -f -   # CI: sed -i on its throwaway checkout
  kubectl apply -n "$NS" -f k8s/service.yaml
  kubectl rollout status -n "$NS" deployment/hello-courier --timeout=180s || { echo "❌ failed delivery"; break; }
  kubectl run -n "$NS" smoke --rm -i --restart=Never --image=curlimages/curl -- -fsS http://hello-courier/healthz
  [ "$NS" = staging ] && { echo "🛑 principal: press Enter to approve production"; read -r _; }
done

# 3) AWS only — the real van: set the four repo variables from ship.yml's header, then
gh workflow run deploy.yml -f image=123456789012.dkr.ecr.ap-south-1.amazonaws.com/hello-courier:<full-sha>
gh run watch

⚠️ Common mistakes

storing a kubeconfig or long-lived AWS keys as a CI secret — that is the master key in the glove box; the OIDC role plus a role mapping inside the cluster replaces it
applying without waiting: kubectl apply returns as soon as the API server accepts the YAML, so a green job proves little until rollout status has passed
letting the sed -i result leak: the swapped deployment.yaml must stay a throwaway on the runner — commit it and IMAGE_PLACEHOLDER is gone for the next run

⏭️ Next

The van has now driven the full route in GitHub Actions. Lesson 11 parks the CircleCI, GitLab and Jenkins vans next to it and hands you the phrasebook.

git checkout lesson-11-four-dialects

← Previousdeploy strategies Next →four dialects

This page is the lesson's README from the lesson-10-deploy-to-kubernetes branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.