Containers for Rails Developers: Use containers while staying true to your RoR roots

Our stack

Our infrastructure before moving to Kubernetes

Why the move?

  1. Have only one type of server (no snowflakes)
  2. Be able to add preconfigured components to our infrastructure quickly and easily

Getting ready for the move

Building the configuration

  • 01_setup.yml
  • 02_security.yml
  • 03_configs.yml
  • 04_secrets.yml
  • 05_certs.yml
  • 06_backend.yml
  • 07_service.yml
  • 08_frontend.yml
  • 09_ingress.yml
  • 10_nginx.yml
  • 11_worker.yml

Dealing with Rails specific issues

  • Database migration
  • Asset pipeline migration
  • Sidekiq restarts
  • Unicorn memory and thread usage

Database migration

Asset Pipeline Compilation

  • You need to configure k8s to delay killing the process if it’s not down by quite a lot to avoid the k8s scheduler shutting down a Sidekiq process before it’s done.
  • The issue becomes worse if you are using k8s sidecar containers in Sidekiq pods. For example if you are running your cluster on Google’s GKE with CloudSQL (Google’s managed database service), you need to have a CloudSQL Proxy container next to each Sidekiq container so it can access your database. This means while you might be able to keep Sidekiq from dying when k8s wants to kill it until it’s finished, the kill signal will be caught by the CloudSQL Proxy sidecar and it will dutifully exit, leaving your Sidekiq in the middle of a job and with no DB access. To solve this we had to write a shim that controls the behaviour of CloudSQL Proxy until Sidekiq is done.

Unicorn memory and thread model

Non-Rails issues


Build Chain




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
Cloud 66

Cloud 66

DevOps-as-a-Service to help developers build, deploy and maintain apps on any Cloud. Sign-up for a free trial by visting: