{"id":13859,"date":"2016-07-08T12:15:39","date_gmt":"2016-07-08T09:15:39","guid":{"rendered":"https:\/\/www.webcodegeeks.com\/?p=13859"},"modified":"2016-07-06T22:51:18","modified_gmt":"2016-07-06T19:51:18","slug":"using-honcho-create-multi-process-docker-container","status":"publish","type":"post","link":"https:\/\/www.webcodegeeks.com\/devops\/using-honcho-create-multi-process-docker-container\/","title":{"rendered":"Using Honcho to Create a Multi-Process Docker Container"},"content":{"rendered":"

A common misconception is that Docker is only for creating single-process or single-service containers. While it\u2019s true that the Dockerfile<\/code> and docker run<\/code> command options are designed for running a single process, that doesn\u2019t mean that Docker itself doesn\u2019t allow for a multi-process Docker container.<\/p>\n

In fact, Docker\u2019s documentation has a very useful tutorial<\/a> on how to run multi-process containers using Supervisor to manage the processes within the container.<\/p>\n

Why I Don\u2019t Use Supervisor for Docker Containers<\/h2>\n

While Supervisor is a great tool (I\u2019m a big fan), I don\u2019t personally like using it for multi-process Docker containers. This is due to how Supervisor handles process failures.<\/p>\n

Supervisor is an application designed to start processes and keep those processes running if they fail. This feature can be very useful in some cases if configured appropriately. If left to its default configuration however, you can easily find yourself with a container that is not providing the service it is supposed to provide, and you may not even know that service is down.<\/p>\n

By default, Supervisor will auto-restart processes that fail. If the managed process fails three times in a row or exits in a way Supervisor is not configured to handle, the supervisord<\/code> process will stop restarting the process. The problem is that the supervisord<\/code> process itself does not exit; it simply logs the event.<\/p>\n

This means that the container will still be running, but the important service within the container is dead.<\/p>\n

Using Honcho to Create a Multi-Process Container<\/h2>\n

Honcho<\/a> is a tool for managing Procfile-based applications<\/a>. A Procfile<\/code> is a file that specifies which commands should be executed to start an application via tools like Honcho.<\/p>\n

We can use Honcho to start and manage all of the processes defined within a Procfile<\/code>. The nice thing about Honcho is if any one of these processes exit abnormally, by default the whole Honcho process and sub-processes are stopped. This causes the Docker container to exit, which is the desired effect for this type of scenario.<\/p>\n

In this article, we will use Honcho to create a custom multi-process Docker container. This container will be used to host a Redis service that supports TLS connections.<\/p>\n

Redis-tls Docker container<\/h2>\n

Redis is a highly popular in-memory datastore. It does not, however, currently support SSL or TLS. To add TLS support to Redis, we will need to run another application called stunnel<\/strong>. The stunnel service is an SSL\/TLS proxy that can be used as a reverse proxy to perform TLS offloading for services that do not natively support TLS.<\/p>\n

While it is possible to deploy stunnel as a stand-alone container and have it linked to a Redis container, for this article we will be combining these two processes into a single container.<\/p>\n

The redis-tls<\/code> Docker container we will be launching today will run two processes: the first being stunnel<\/code> and the second being redis-server<\/code>. As Redis traffic arrives to the containe, it will first pass through stunnel<\/code>, which will perform all of the TLS communication. From there, stunnel<\/code> will then forward the unencrypted traffic to the redis-server<\/code> instance.<\/p>\n

This allows for communications outside of the container to be encrypted, with non-encrypted traffic being contained within the container.<\/p>\n

Since a redis-tls<\/code> container image does not exist today, we will also be creating our own custom Docker image as part of this article. To start this process, we will first need to define a Dockerfile<\/code>.<\/p>\n

Creating a custom Docker image from a Redis base<\/h4>\n

The first instruction in any Dockerfile<\/code> is usually FROM<\/code>. This instruction is used to define what base image the Docker container should be created from.<\/p>\n

Since we will be creating a Redis container with TLS support, we can base our container from the standard redis<\/code> Docker image by specifying redis<\/code> in the FROM<\/code> instruction: FROM redis<\/code><\/p>\n

A benefit of basing our image on the official redis<\/code> image is that our image will inherit all of the latest features of the official redis<\/code> image when updates occur. This keeps the redis-server<\/code> installation up to date with the latest security and bug fixes.<\/p>\n

Installing stunnel and pip<\/h4>\n

With the redis<\/code> image as our base image, we don\u2019t have to go through the effort of installing Redis. We will however need to install the stunnel<\/code> package. We\u2019ll also need to install the python-pip<\/code> package to install pip<\/code>. The pip<\/code> command will be used to install Honcho within the Dockerfile<\/code>.<\/p>\n

To install these packages, we will add a RUN<\/code> instruction calling the Apt package manager.<\/p>\n

FROM redis\r\n\r\nRUN apt-get update --fix-missing && \\\r\n    apt-get install -y stunnel python-pip && \\\r\n    rm -rf \/var\/lib\/apt\/lists\/*<\/pre>\n
The above will run three instructions during the Docker build process:<\/p>\n