A deployment pipeline removes the need for someone to apply every configuration change by hand. When a change is pushed to a configuration repository, a repository trigger runs deployment steps against a Kubernetes cluster. The rollout comes from committed configuration rather than an operator’s local files. section 11.3.1
A practical GitOps workflow is:
- Change the Kubernetes configuration in the repository, then commit and push it. section 11.3.1
- Let the pipeline apply the pushed configuration. If a correction is needed, change the repository and trigger another rollout instead of editing the cluster directly. section 11.3.1
- Check the deployment environment before applying files. A script that checks the current namespace can prevent a wrong-environment rollout, but a namespace written into a configuration file overrides that safeguard. section 11.3
Deploy on a repository push with Cloud Build
For a Google Kubernetes Engine cluster, give the Cloud Build service account permission to act on the cluster, create a trigger for pushes to the configuration repository, and point it at a build configuration that runs kubectl apply -f on the configuration folder. section 11.3.2
Listing 11.3 Chapter11/11.3.2_CloudBuild/cloudbuild-deploy.yaml
steps: - name: 'gcr.io/cloud-builders/kubectl' id: Deploy args: - 'apply' - '-f' - '$FOLDER' env: - 'CLOUDSDK_COMPUTE_REGION=us-west1' - 'CLOUDSDK_CONTAINER_CLUSTER=my-cluster'
The Cloud Build configuration shows the deploy step, its kubectl arguments, and the region and cluster environment variables. section 11.3.2
A push-triggered pipeline runs when the repository changes. A GitOps operator such as Flux takes a different approach: it continually reconciles the cluster with the repository and can act when they diverge between pushes. Kubernetes leaves teams free to assemble either a simple push-to-deploy workflow or a pipeline with additional controls such as security scanning. section 11.3.2 section 1.2.2
