From Monorepos to Google Kubernetes Engine

A full walkthrough of how I built a pipeline that deploys an app from a monorepo to GKE


Monorepos are great when working with lots of repos that rely on each other in some way or another. They solve a lot of problems that microservices bring along with them, such as

  1. allowing sharing of code through libraries across all services, and making it a lot easier to upgrade or change libraries across the whole repo — try upgrading your logging library across all your services with polyrepos and see how laborious it can be;
  2. making it easier to refactor code across multiple services;
  3. making it easier to search through the whole code base.

I highly recommend doing some research into why and when monorepos are suitable for your needs —

For personal projects it’s probably not so simple to argue why a monorepo is the way forward, but nonetheless that’s what I did. Apart from the above reasons I also wanted:

  1. a way to quickly and easily deploy my small projects into the wild;
  2. to get a better idea of monorepos (their pros and cons) first hand.

Possibly the most difficult part of working with a monorepos is the build process. In polyrepos you can wire up pipelines that work well with that repo, but with monorepos we need a single method of deploying all our services and libraries. The one build tool that I’ve heard about the most is Bazel, which is Google’s open sourced version of their internal build tool. I think Bazel is for another day when I want to experiment with it after getting a better feel for monorepos. Bazel is just a build tool, and it’s not only for monorepos, but it does work very well with them.

I’ve forked off to build my monorepo. It works with CircleCI and it does exactly what I need it to do for now — build go services from a monorepo.


So here are all the steps I took to get a service from a monorepo into GKE. It’s going to be a bit dry and to the point, and if you want to follow along it will require some reading in the linked posts/articles:

  1. Fork
  2. Change the name of the repo to Godzilla — to help signify the awesome size and power 🙃
  3. Log into CircleCI with your github account
  4. Setup a CircleCI job for the new monorepo
  5. Add a personal token to the repo
  6. Add a CIRCLE_TOKEN to the new project
  7. Change to using circleci/golang:1.14.3 to build the service
  8. Add a linter step
    - and
  9. Build static binary and disable cgo so that we can run the service in a barebones Docker container
  10. Create a Dockerfile which has a distroless base image, copies the binary, and defines the entry point for the app
  11. Create a version file in the service that will be cat’d when creating a tag for the docker image
  12. Initially I wanted to work with Docker Hub
    - (use machine and don’t need a executor —
  13. Once published to Docker hub, you should be able to pull and run it locally with:
    - docker pull <path to docker hub repo>
    - docker images | grep <name of image>
    - docker run <hash of image>
  14. Create a hello world server, that can shut down and responds to GET requests
  15. Once created and deployed run the following in the terminal:
    - docker pull ankura22/messenger-server:0.3.0–196
    - Find the image hash
    - docker run -p — env PORT=8080 0e72fae04e3c
    - curl localhost:8080
  16. Deploy and run in Google Cloud
    Use v1 instead of v1beta1 in the deployment yaml
    - Update to the latest orbs
    - To find the container name — kubectl get --output=wide deploy
    - Reduce the node count (defaults to 3)
  17. I changed script to deploy the “latest” tagged docker image and deploy to k8s engine when merged into master
  18. Using code coverage and codecov (this doesn’t work well with monorepos, but at least there’s another badge for the README):
  19. To get TLS to work I needed to work with helm charts
  20. To create the service file
  21. DNS:
  22. TLS:
    (Ensure Issuer is letsencrypt-prod not letsencrypt-production)
  23. For wildcard you need to also follow:
    - — helped with kubectl commands
    - describe orders — all-namespaces helped me find an issue with wildcard certs
    secrets -> certs -> certrequest -> posts -> challenge -> ingress
  24. Order of commands to verify wildcard cert issuance
    - kubectl describe issuer; kubectl describe secrets
    - kubectl describe certificates
    - kubectl describe certificaterequest
    - kubectl describe orders --all-namespaces
    - kubectl describe challenges --all-namespaces

The Monorepo

Here’s a link to the github page for my monorepo:

On an adventure

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store