Continuous Integration, Delivery, and Deployment of Microservices: A Hands-on Guide
Continuous Deployment with Argo CD
Create the Argo CD Application resource, which will instruct Argo CD to deploy our application using the Helm chart we created earlier.
Reminder: Argo CD will search for the Helm chart on the GitHub Pages site we previously created, using an "index.yaml" file. This file contains a list of packages available in the repository and was generated by the GitHub workflow using the Helm Chart Releaser action.
Note that we will be using the following URL when specifying the Helm repository URL.
echo \
https://${GITHUB_USERNAME}.github.io/${GITHUB_REPOSITORY_NAME}/
Before handing control to Argo CD, make sure there are no leftover resources from earlier manual deployments. Otherwise, Argo CD will attempt to patch the existing Service and Deployment, keeping the extra http port and triggering the validation error you saw earlier.
# Remove any previous Helm release (ignore errors if it was never installed)
helm uninstall cicd-flask || true
# Make sure the Service and Deployment are gone before Argo CD recreates them
kubectl delete deployment cicd-flask --ignore-not-found
kubectl delete service cicd-flask --ignore-not-found
When we use GitHub Pages to host our Helm charts, the repository URL follows a specific format based on our GitHub username and repository name:
If your repository URL is https://github.com/you/app, then the Helm repository URL will be https://you.github.io/app/. The default page will return a 404 error because it has no index.html file, but Argo CD will be able to access the index.yaml file at this URL.
If you are using a private GitHub repository, you can configure Argo CD to use it by providing a GitHub personal access token. You can find more information in the Argo CD documentation.
We are using the values-staging.yaml file as the values file for our staging environment, but you can also create new values files for other environments. This is the Application resource definition (Argo CD manifest):
kubectl apply -f - <
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: cicd-flask
namespace: argocd
spec:
destination:
namespace: default
server: https://kubernetes.default.svc
project: default
source:
chart: cicd-flask
repoURL: https://${GITHUB_USERNAME}.github.io/${GITHUB_REPOSITORY_NAME}/
targetRevision: 0.1.1
helm:
valueFiles:
- values-staging.yaml
syncPolicy:
automated:
prune: true
selfHeal: true
allowEmpty: true
EOF
The targetRevision: 0.1.0 specifies the version of the Helm chart to deploy. This value should correspond to the version defined in the Chart.yaml file of the Helm chart. If you update the chart, you need to update its version in the Chart.yaml file and also update the targetRevision field in the Argo CD Application resource.
If you are using DigitalOcean Kubernetes (DoK8s) as your cloud provider, there is a known issue with the CiliumIdentity CRD (as described in a GitHub issue) that prevents the application from being deployed. To solve this issue, we need to add an exclusion to the Argo CD ConfigMap. This applies only to DoK8s clusters using Cilium as the CNI plugin. Skip this part if you are using a different cloud provider.
kubectl apply -f - <
apiVersion: v1
kind: ConfigMap
metadata:
labels:
app.kubernetes.io/name: argocd-cm
app.kubernetes.io/part-of: argocd
name: argocd-cm
namespace: argocd
data:
resource.exclusions: |
- apiGroups:
- cilium.io
kinds:
- CiliumIdentity
clusters:
- "*"
EOF
If you are using a different cloud provider, or if this issue has been resolved by the time you are reading this guide, you may not need to do any additional configuration.
Automating Upgrades
Argo CD can be used to deploy a new version of the application by upgrading the Helm release. To test this, we can change anything from the image tag to the number of replicas in the values file and push the changes to the repository.
In this example, we will change the number of replicas from 1 to 3 in the "values-staging.yaml" file.
cat << EOF > charts/cicd-flask/values-staging.yaml
# change the replica count to 3 here
replicaCount: 3
image:
repository: ${DOCKER_USERNAME}/${DOCKER_REPOSITORY_NAME}
pullPolicy: IfNotPresent
tag: "latest"
imagePullSecrets: []
nameOverride: ""
fullnameOverride: ""Cloud-Native Microservices With Kubernetes - 2nd Edition
A Comprehensive Guide to Building, Scaling, Deploying, Observing, and Managing Highly-Available Microservices in KubernetesEnroll now to unlock all content and receive all future updates for free.
