CICD Pipeline with Cloud Build
This post is dedicated primarily on making a cicd pipeline, a pretty generic boilerplate pipeline that uses Cloud Build, which is google's CICD serverless platform. We are modularly building upwards so that my next biggish project can use this. We're using Cloud Source Repos to host repos, but the pattern is all the same. All these CI pipelines follow the same structure:
- There's a steps file to define steps (e.g. steps to test a pipeline)
- There's a trigger to invoke some steps (e.g. pushing to a branch)
For jenkins, there's Jenkinsfile and SCM. For GCP, there's cloudbuild and a trigger UI. For gitlab there's gitlab-ci and a trigger UI. For circleci, there's a config file, etc. They all have some way of conditionally triggering pipelines.
I've decided to use cloud build (GCP) as my CI tool since I have everything in gcp anyway. My trigger is defined as any changes to my master branch, and my cloudbuild.yml file has pretty self-explanatory steps: run a test, build docker image, push docker image (and optionally deploy docker image).
This tutorial, which is what I'm generally following, has a separate branch that has a separate cloudbuild.yaml file to manage deployment. This way, the CI step which is generally managed by the developer is decoupled from the CD step, which is generally managed by automated systems. The CD step uses the kubectl builder to automatically link a cluster to deploy, which is a nice abstraction. I made some custom modifications to conform to the way I want feature-branch tested and the final result deployed.
Feature branch runs test and builds docker image (I made it fail on purpose to see how it would stop)
Master branch runs test, builds, pushes image, and deploys
Beautiful! Everything works like a charm. You can also do more fancy things. I think if you have more complex docker images, you can simply layer images on top of the GCP builder images. These A-records are mapped to LoadBalancer IPs:
Other random stuff:
- This post isn't really well-served for "follow-along" reading purposes. I recommend this.
- Though I think it's much cheaper to try out k8s in GCP over AWS, GCP costs have been racking up; for the time being, my rust endpoint is down.
- It's pretty easy in general for GCP to context switch.
The end goal is to create a notetaking app where users don't have to login. A page that they visit gets created dynamically and that address is theirs to keep. They can use that page to take notes. If they want to password protect a page (e.g. /benson), they can make a one-time payment to add a lock to that page. We will dedicated the next few posts to that.