Google Cloud's Duplicate Service Problem
In my previous blog post I described a quick and easy way to set up a build and deploy automated pipeline. It was surprisingly easy to do so, and I was quite impressed with the ease of use. How does it all work though? What are the configuration options that were set and exactly how much can I customize the process? I was curious and learning about Google Cloud is a part of my current goals, so I decided to take a closer look.
Table of Content
- What I was Expecting to Find
- Closer Look: Connecting to GitHub
- Closer Look: Container Image Storage
- Closer Look: Deployment
- Final Thoughts
What I was Expecting to Find
I've used a variety of deployment setups in the past. Every company seems to have one or more of its own set of services they rely on for automating this part of the workflow. In general, I would summarize the average CI/CD pipeline in the diagram below.
- Application code is stored in a version control system (VCS)
- A webhook is configured that notifies a build service whenever there is an update to the repo
- The build service pulls the latest code and compiles into an artifact
- The compiled "artifact" is then stored into an artifact repository
- If it's a library, this will be a package of the relevant kind
- If it's an application, it could be a container image, tar file or an executable
- The artifact is then deployed to production via a "deploy service"
- The deploy service essentially knows how to take an artifact and install it into the relevant cloud or on prem system
- It usually has a relevant config file of some variety that specifies network, storage and cpu resources to be used
If you are familiar with these kinds of systems, you will notice the above is a simplification that doesn't really cover a lot of details such as code analysis, reviews, approvals, reverts, rollbacks, databases, canary deployments, blue/green deployments, etc... Depending on your needs and setup, you will probably need more than the basics illustrated above.
The Google Cloud CI/CD Services
Google cloud offers a nice set of these services. Here is a comparison table showing some popular options from each category, as well as matching Google Cloud services.
| Type | Popular Option | Google Cloud Option |
|---|---|---|
| VCS | GitHub, GitLab, BitBucket | Cloud Source Repositories |
| Build Service | CircleCI, BuildKite, GitHub Actions | Cloud Build |
| Artifact Repository | JFrog Artifactory, Sonatype Nexus | Artifact Registry |
| Deploy Service | Puppet, Ansible, Heroku, Helm + Kubernetes | Cloud Deployment Manager |
It seems that Google Cloud provides a solution in every category... In fact, they seem to provide multiple competing solutions in just about all the categories.
Closer Look: Connecting to GitHub
In the tutorial I was able to connect GitHub to Google Cloud and avoid having to fiddle with Cloud Source Repositories. Thankfully the Cloud Run developers made the setup easy.
What I didn't mention in the tutorial is that when I was first getting things setup (early January 2022), the GitHub integration was broken. When I tried it, the post back auth link to Google Cloud was 404ing. I almost gave up on the entire idea of using Google CLoud at this point, but then I noticed that if you select the "other" option for VCS integration, you get a second, legacy way for connecting to GitHub.
The legacy way worked great, by the way. I didn't notice any functional differences between the two GitHub Integrations. At least in this case, it seems that there were advantages to Google building duplicate solutions. It is a small thing, but I couldn't call it out.
Interestingly, GitHub (legacy) is in beta at the moment 🤔. I am not sure what that means. Is it that they didn't finish building the first GitHub integration before starting on the second? Or is it the legacy integration is being build as we speak...
In either case, when I was repeating the setup for the how-to article screenshots, the GitHub App integration worked fine so I left it in.
Closer Look: Container Image Storage
After looking at the repository integration, I next wanted to take a look at the Container Image Storage configuration. I went over to Artifact Registry and was greeted with the following screen.
It seems that Artifact Registry is not used for storing container images? So where are my container images going? After the initial head scratch moment, I noticed there is a notice on top that explains things (kind of).
It turns out that there is a legacy service called "Container Registry" that was replaced by "Artifact Registry" at some point in the past. If we go to the Container Registry service in cloud console we get:
It looks like Container Registry is essentially a deprecated service. At least it seems to still be received security fixes ¯\(ツ)/¯ . Why did the brand new Cloud Run configuration wizard configure my deployment to use a deprecated service? Why am I accruing technical debt minutes into launching my service?
This was so surprising to me that I went back several times to check. Perhaps I missed something in the configuration wizard? Perhaps, I miss clicked? I've checked several times and have become convinced that by default the Cloud Run setup wizard indeed leverages a duplicate and deprecated service. I get the honor to do a migration and pay back tech debt on my very first day of the project.
Thank's Google! Thanks Google product managers for thinking about me the solo dev with a blog! I did say I wanted to learn about the details, didn't I?
Closer Look: Deployment
After deciding to not bother with a day one migration from Container Registry to Artifact Registry, I decided to take a look at how those containers make into production. Cloud Deployment Manager seemed like a worthwhile thing to check out, since in the future I will sure have more complicated deployment scenarios.
Naturally, there are no configured deployments...
The website is up and running, so where did the deployment configuration go? To be honest at this point, I was expecting a duplicate service somewhere. If it's not Cloud Deployment Manager, could it be Cloud Deployment Manager V2 API? Doesn't look like it. Is it Cloud Deploy. Nope, that is for deploying to Google Kubernetes Engine. Is it "Delivery Pipelines"? Nope, that seems to redirect back to Cloud Deployments.
After poking around for a while I was able to find the deployment configuration. It turns out, the Cloud Run wizard isn't using any deployment configuration service per se. What it does is to configure the relevant components inside a Cloud Build trigger.
If we click into the trigger configuration, we see that Cloud Run set up a .yaml configuration file thoughtfully hidden behind that Open Editor button.
How could I have missed it all this time?
Final Thoughts
It was the best of times, it was the worst of times, it was the age of wisdom, it was the age of foolishness, it was the epoch of belief, it was the epoch of incredulity... in short, the period was so far like the present period, that some of its noisiest authorities insisted on its being received, for good or for evil, in the superlative degree of comparison only..
~Tale of Two Cities
To be honest, I am coming away from this Google Cloud experiment with very mixed feeling. On the one hand, Cloud Run does seem to deliver easy setup and a compelling container run time. Sure beats spinning up a kubernetes cluster cloud or no cloud. I think it hits a sweet spot of providing enough flexibility for a variety of web workloads, while at the same time abstracting away a ton of the details that normally go into a system like this.
On the other hand, the integration with the other services in the ecosystem makes me feel like I accrued tech debt on launch. Moreover, there are so many services that overlap, that I can never be sure that the selection I made to narrow down the field is the correct one. Google is famous for cancelling products they offer, in favor of new ones. I can't help, but wonder how long this setup will run without needing any changes...
← Back to home