Deploying a Rails application to Google Container Engine with Kubernetes

Recently, I had the opportunity to deploy a Rails application to Google Cloud Platform (GCP). This application required https support and leveraged GCP services such as Cloud SQL, Google PubSub, Google Storage buckets and Stackdriver logging.

Since the application comprised of a web app and several ActiveJobs that would consume messages off the Pub/sub topics, Google Container Engine (GKE) seemed like a good fit as it would enable better control over deployments.

As this was my first foray into GCP, I was hoping that the tutorials online would help me get there fast. I came across some great articles that got me started quickly (See Resources section below). Over time, I realized that I had many questions (Should I use a Replication Controller or a Deployment? How do I incorporate tls support in GKE? What is an Ingress? How do I use environment variables within my Kubernetes cluster? How do I roll back to a previous version?).

This article is an effort to simplify some of these concepts without diluting their value, while bringing all of the above in one place. I have embedded links to helpful material below so you can read from the official sources. The Terminology section at the end contains a simplified explanation of each of the topics that were covered here. This article assumes that the reader has a project created in GCP and is at least familiar with kubectl, the command line interface for running commands against Kubernetes clusters.

Please see the Dockerfile and yml files in the Github repository for a sample deployment.

The list below shows the end-end process of creating and deploying a Rails app to GKE:

• Create a very simple Rails App that shows a welcome page
• Add a health check endpoint (/_health). This is required as each instance is polled periodically to check its health and any instance deemed “unhealthy” does not receive any more traffic.
• Create a Docker container for this app (see Dockerfile)
• Tag and upload the container to the Google Container Registry (see gcloud_deployment.sh)
• Create a Kubernetes Deployment that controls the number of containers that will be deployed (see web-deployment.yml)
• Create a Kubernetes Service that allows access to these containers (see web-service-static-lb.yml)
• Create a Kubernetes Secret using an SSL certificate (see gcloud_deployment.sh)
• Create a GCE TLS Ingress that uses this secret to allow https access to the Service. (see gce-tls-ingress.yml)
• Allow for incorporating changes to the application with “rolling updates” via newer container versions without bringing the whole application down. (see gcloud_deployment.sh)

The following diagram shows the process behind the deployment.

Deploying a Rails Application to GKE

Steps 1–5 in the diagram above show the orchestration process in gcloud_deployment.sh

In subsequent articles, I’ll cover leveraging Kubernetes secrets for environment variables and integrating with CircleCI to do the above orchestration on every code checkin.

Important note: Once the application is deployed, you would need to ensure that you have firewall rules in place to restrict external access to the IP address exposed by your Service . If you already have a static IP in mind, you could use that in web-service-static-lb.yml

Terminology:

1. Kubernetes: an open-source system for automating deployment, scaling, and management of containerized applications. In this article, we use it to create a Deployment, a Service, a Secret and an Ingress
2. Docker: a software technology providing containers, promoted by the company Docker, Inc.[6] Docker provides an additional layer of abstraction and automation of operating-system-level virtualization on Windows and Linux. Docker is used in step 1 in the diagram above to build the application, create a container and tag it with a version number.
3. Kubernetes Pod: a group of Docker containers
4. Kubernetes Deployment: similar to a Kubernetes Replication Controller, it ensures that a certain number of containers are running. It is recommended over the ReplicationController as it creates Replica sets which manage the pods and help with rollbacks.
5. Kubernetes Service: a microservice that defines a logical set of pods and allows for a single point of contact to work with a set of pods. The pods themselves are fungible and could be replaced by others.
6. Kubernetes Secrets: used to hold sensitive information that the containers can access. In the example above, a secret is created from a SSL certificate. This secret will be used by the Ingress in the next step.
7. Kubernetes Ingress: a collection of rules that allows inbound traffic to reach the cluster services. It can be used to give an externally accessible url to Services, terminate SSL and to act as a load balancer. The figure below is from the Kubernetes documentation

    internet
        |
   [ Ingress ]
   --|-----|--
   [ Services ]

Resources:

1. One of the best articles I’ve read on this topic, written by Aja Hammerly: http://www.thagomizer.com/blog/2015/07/01/kubernetes-and-deploying-to-google-container-engine.html
2. Another excellent article on deploying Rails on GKE: https://engineering.adwerx.com/rails-on-kubernetes-8cd4940eacbe
3. Rolling updates: a gem on the topic of using Deployments: https://tachingchen.com/blog/Kubernetes-Rolling-Update-with-Deployment/
4. Connecting to a CloudSQL instance from a Rails app in GKE: https://medium.com/@nithinmallya4/using-the-cloudsql-proxy-to-talk-to-mysql-from-your-gke-rails-application-aa53f2611b78
5. Blue Green Deployments: https://medium.com/@nithinmallya4/blue-green-deployments-for-a-rails-app-in-google-container-engine-gke-49ddcc1b002