{"id":4931,"date":"2018-12-18T15:24:58","date_gmt":"2018-12-18T15:24:58","guid":{"rendered":"https:\/\/discoverpassenger.com.temp.link\/?p=4931"},"modified":"2026-08-07T07:26:00","modified_gmt":"2026-08-07T06:26:00","slug":"doing-our-bit-for-the-development-environment-docker-at-base","status":"publish","type":"post","link":"https:\/\/www.masabi.com\/it\/news\/doing-our-bit-for-the-development-environment-docker-at-base\/","title":{"rendered":"In depth: Doing our bit for the (development) environment with Docker"},"content":{"rendered":"
\n

Originally posted on our ‘Base’ Medium account.
In September 2019, Base became Passenger<\/a>.<\/p><\/blockquote>\n<\/div>\n\n

\n

As the team behind Passenger grows, so have our approaches and processes in software engineering. One such evolution has been our recent move to Docker, when we decided that our Vagrant\/Ansible solution was no longer fit for purpose.<\/p>\n<\/div>\n\n

\n
\"\"<\/figure><\/div>\n<\/div>\n\n
\n

On the surface, Passenger \u2014 Base\u2019s core product offering \u2014 is an easy to use, customer-facing digital product. Look more deeply and you\u2019ll find that the system comprises a number of different technologies and databases<\/a>. It is the combination of these, working as one beneath Passenger\u2019s app and web surface, that attracts such heartwarming feedback from users on a daily basis.<\/p>\n<\/div>\n\n

\n

We recently invested in Docker to help us build, manage and secure each Passenger application in a more efficient way. Read on to better understand the work we\u2019re doing to make Passenger a stronger, more reliable solution for all that use it.<\/p>\n<\/div>\n\n

\n
\"\"<\/figure><\/div>\n<\/div>\n\n
\n

Why we moved to Docker!<\/strong><\/p>\n<\/div>\n\n

\n

Passenger\u2019s numerous development environments were previously built using Vagrant<\/a> and our production Ansible<\/a> playbooks \u2014 scripts\/configuration files which turn blank machines into a fully configured boxes that can serve requests.<\/p>\n<\/div>\n\n

\n

As Vagrant uses virtual machines as its backend, Passenger benefited from some great separation between its development environments. However, that was also a very resource intensive approach. Vagrant creates a new VM for each application used at Passenger, which requires fixed CPU, disk and memory to be allocated. We previously used an Ubuntu LTS base image for this \u2014 one of the most popular distributions. The Ansible playbook would then run on this VM, which creates a fully configured environment ready to serve requests.<\/p>\n<\/div>\n\n

\n

These \u201cfull-fat\u201d VMs with fixed resource allocation can be a time sink. Rebuilding the whole Passenger stack takes around an hour \u2014 not to mention requiring expensive hardware in order to run the stack performantly. When developing, full requests \u2014 depending on the complexity \u2014 could take 5\u201320 seconds to compute. An eternity in development time.<\/p>\n<\/div>\n\n

\n

When we increased the amount of engineers<\/a> working on the Passenger stack this summer (2018), it quickly became apparent that this development environment was no longer the fit-for-purpose solution it had been before. Technology and common practice have shifted towards containerised environments.<\/p>\n<\/div>\n\n

\n
\"\"<\/figure><\/div>\n<\/div>\n\n
\n

Containing the problem<\/strong><\/p>\n<\/div>\n\n

\n

As containers use dynamic resource allocation, they do not require an up-front allocation of disk, CPU or memory (although you can reserve these for each container if required). Importantly, containers are also a much more native approach, as no virtualization is required. The application runs natively on the host machine, but using a different base image than the host. (Developers even use different operating systems \u2014 the most popular is Debian-based Linux distributions, we also have OpenSuse Tumbleweed, Fedora and MacOS.)<\/p>\n<\/div>\n\n

\n

The most popular, easiest, and most portable way of implementing containerized environments today is Docker<\/a>. This approach defines the environment in a special Dockerfile. Docker then creates a container using a base image. We chose an Alpine base image; an extremely small linux distribution. This is built using musl<\/a> rather than the bigger glibc<\/a>, which is more standard. The Dockerfile contains a list of commands that can bring this container into a fully functioning environment.<\/p>\n<\/div>\n\n

\n

This approach results in far fewer lines of configuration than the Vagrant\/Ansible solution \u2014 with the added benefit of keeping everything in a single file, which makes the whole application environment visible at a glance.<\/p>\n<\/div>\n\n

\n

As our services often require other programs which would not be suited to run in the same container as the application, e.g. MariaDB, Elasticsearch & Redis, we\u2019ve also adopted Docker Compose, a tool that enables us to further define how Passenger\u2019s multiple application containers can come together to build an overall service.<\/p>\n<\/div>\n\n

\n

Docker Compose enables us to create a specification in a docker-compose.yml for each service that defines how multiple containers come together to build a service. We also have environment specific compose files, which overlay with the base file to apply adjustments, such as enable debugging and disable master\/slave replication in development.<\/p>\n<\/div>\n\n

\n
\"\"<\/figure><\/div>\n<\/div>\n\n
\n

What does all this mean for Passenger?<\/strong><\/p>\n<\/div>\n\n

\n

The process of dockerizing our development environments was not an easy one.<\/p>\n<\/div>\n\n

\n

First off, the diversity of the Base engineers and the variety of preferred development systems they use was the cause of several headaches.<\/p>\n<\/div>\n\n

\n

Furthermore, MacOS does not support host bridged networking. A container cannot be assigned a unique ip address for communication; instead, different ports must be bound to the host for each container.<\/p>\n<\/div>\n\n

\n

We also had issues around the osxfs filesystem with MariaDB. This required us to use docker volumes instead of mounting directly into the host filesystem.<\/p>\n<\/div>\n\n

\n

But, despite these early issues\u2026<\/p>\n<\/div>\n\n

\n