The Dev World – Sergio Lema

In a previous article, I’ve built a microservices architecture using a managed service of GCP, I’ve used the Instance Groups. But I didn’t use Docker to deploy new versions of my application.

But let’s face it, not using Docker nowadays is like a bike with square wheels, it doesn’t let me move forward very quickly.

So today, let’s create a GCP Instance Group using Docker and let’s see how to integrate this into a CI/CD pipeline.

Artifact Registry

Before we dive into creating the Instance Groups, let’s talk about the artifact registry. Think of it as a fancy hotel for your Docker images: secure, reliable, and expensive if you forget to clean up after yourself.

We’ll use GCP’s Artifact Registry to store Docker images of my application. To maintain sanity during debugging, I use the commit hash as the tag for each image. This allows me to easily link a specific Docker image to the corresponding Git commit. Here’s how you can do it:

#!/bin/bash

GIT_HASH=$(git rev-parse --short HEAD)
docker build . -t my-awesome-app:${GIT_HASH}
docker push my-awesome-app:${GIT_HASH}

Instance Templates

Once the Docker image is in the Artifact Registry, I’ll create an Instance Template. GCP will take the definition of the Instance Templates to create all the microservices instances of my service.

In the Instance Template, I indicate the machine type, the memory allocated, the Docker image to use and some environment variables.

It’s the best place to have all the environment variables, but for sensitive data (like API keys), use the Secret Manager. Trust me, you don’t want to see your secrets pasted all over GitHub.

#!/bin/bash


GIT_HASH=$(git rev-parse --short HEAD)
gcloud compute instance-templates create-with-container \
		--project ${PROJECT_NAME} my-awesome-app-${GIT_HASH} \
        --machine-type=e2-small \
        --network-interface=network=my-vpc,subnet=my-subnet,network-tier=PREMIUM,stack-type=IPV4_ONLY \
        --region=europe-west9 \
        --maintenance-policy=MIGRATE --service-account=my-service-account@iam.gserviceaccount.com \
        --container-image=europe-west9-docker.pkg.dev/${PROJECT_NAME}/my-registry/my-awesome-app:${GIT_HASH} \
        --container-restart-policy=always --container-env=PLATFORM=prod,DATABASE_HOST=10.162.51.3
            

Instance Group

Now that I have the Instance Template, let’s create an Instance Group. Choose an instance size larger than 1, unless you enjoy downtime during rollouts or debugging outages in production (spoiler: you won’t).

#!/bin/bash

GIT_HASH=$(git rev-parse --short HEAD)
gcloud compute instance-groups managed create my-instance-group \
    --zone=europe-west9-a \
    --template=my-awesome-app-${GIT_HASH} \
    --size=3

CI/CD

A robust CI/CD pipeline ensures your application is deployed without manual intervention. When I need to update the Instance Group with a new Instance Template, it should be done with a simple command:

#!/bin/bash

GIT_HASH=$(git rev-parse --short HEAD)
gcloud compute instance-groups managed rolling-action start-update \
    my-instance-group \
    --zone=europe-west9-a \
    --version=template=my-awesome-app-${GIT_HASH} \
    --max-surge=1 --max-unavailable=0

Conclusion

As always, the goal is to automate everything. With Docker, GCP instance groups, and a bit of bash script magic, you can ensure that every git push seamlessly triggers a build, deploys a Docker image, updates an instance group, and rolls out the changes. It’s like having a self-cleaning kitchen—if only such a thing existed for actual cooking.

Now go forth and deploy with confidence. Just don’t forget to clean up unused resources, or you’ll have a heart attack when the bill arrives.