Implement continuous integration and continuous deployment (CI/CD) for your AKS application, ensuring automatic updates with each pipeline run. In previous labs, the application build tag was manually set up.
- Previously, the image build version was hardcoded. This meant that to update the pods on the cluster, you had to delete the Kubernetes deployment and rerun the pipeline with the new build version. This approach is not ideal as it does not support zero-downtime deployments.
image: devopsjourneymay2024acr.azurecr.io/devopsjourney:123
- Confirm the hardcoded image version in the app.yaml file
- Why is a hardcoded image version problematic for CI/CD?
- What are the drawbacks of manually deleting and redeploying for updates?
- Change the image tag to latest and add an imagePullPolicy to ensure the latest image is always pulled when the pods are updated.
image: devopsjourneymay2024acr.azurecr.io/devopsjourney:latest
imagePullPolicy: Always
The imagePullPolicy
determines when the kubelet attempts to pull (download) the specified image. Here are the possible values:
- IfNotPresent: The image is pulled only if it is not already present locally.
- Always: Every time the kubelet launches a container, it queries the container image registry to resolve the image name to a digest. If the image is not cached locally, the kubelet pulls it and uses it to launch the container.
- Never: The kubelet does not try to fetch the image. If the image is present locally, the kubelet attempts to start the container; otherwise, the startup fails.
- Ensure both the image tag and imagePullPolicy are correctly set in the YAML file
- What are the different imagePullPolicy options and their use cases?
- Why is 'Always' particularly useful in a CI/CD context?
💡 Pro Tip: While 'latest' is convenient for CI/CD, consider using specific version tags in production for better traceability and rollback capabilities.
- Make the necessary changes to the app.yaml file as shown here
- Update the Pipeline Tag
Previously, the pipeline tag was set to the latest Build ID:
tags: $(Build.BuildId)
Which will tag with the latest BuildId each time of the pipeline.
- Update this to latest to ensure the latest build is always used:
tags: 'latest'
- Modify this in your pipeline file here
- Double-check that the changes are correctly applied to the app.yaml file
- Confirm the tag change in your pipeline file
- How does this change affect the deployment process?
- What potential issues could arise from using 'latest' in production?
- How does using 'latest' instead of $(Build.BuildId) impact your deployment strategy?
- What are the pros and cons of using 'latest' versus unique build IDs?
💡 Pro Tip: Use version control to track changes to your Kubernetes manifests, enabling easy rollbacks if needed.
Once you merge these changes, the pipeline will run automatically. In the Azure Container Registry (ACR), you will see a new tag latest
. This tag will be used to update the pods on the AKS cluster.
As we changed the imagePullPolicy
to Always
, reviewing the K8s cluster, you will see a new pod also with the latest
image tag
kubectl describe pod thomasthornton-85cccb565d-qdltc | grep Image
Image: devopsjourneyoct2024acr.azurecr.io/repository:latest
Congratulations! You've successfully implemented CI/CD and automated deployments for your AKS application.
- Confirm the 'latest' tag in ACR
- Check for new pods in the AKS cluster using the 'latest' image
- How does the imagePullPolicy affect the pod update process?
- What would happen if you reverted to an older commit with this setup?