Docker in Many Ways

Orchestrating Docker Containers Solutions

I create several tutorials on orchestrating WordPress and MySQL docker containers through a variety solutions. WordPress is gestalt solution for demonstrating change automation as it is a classic multi-tier monolithic web application that is quite popular.

With this, I can demonstrate how to implement a simple solution with a few advance docker features, like volumes, networks, and using environment variables to control options like the host web port. This way, we can demonstrate some of the nuances between different solutions to acheive the same desired results, which can be verified some test automation written in InSpec.

In this article, I will present the problem that is universal to all the problems, provide links to solutions I have completed so far, and references to other solutions I have yet to explore.

The Problem

I divided the problem into into two basic features and advance features.

The Basic Features

Getting started, we want to simply launch two containers and verify the solution works by pointing your web browser to localhost:8080.

The features are below:

The Advance Features

For this, we want to create a private network resource and have the containers use this, create a volume that is mounted for the database with the MySQL container, and support WORDPRESS_PORT, so that we can change the host port.

Requirements Documentation

Docker Orchestration Challenge.pdf

Validation

Validation will be to try the solution once with the default port, and again using an alternative port. Point your web browser to the appropriate port, and try out the WordPress application.

If you do not remove and recreate the db_data volume, the data should be preserved between starting and stopping the containers.

Verification

Manual Verification of Basic Features

With the commands docker, jq, and grep, we can test to see if the containers are configured correctly.

Manual Verification of Advance Features

Using the same commands, we can verify advanced features:

Automated Verification

For verifying the solution in an automated way, we can download this script below:

To run this script container_test.rb, download and install InSpec, and then run on the system with Docker containers running the following:

inspec exec container_test.rb

If we are using a port specified by the WORDPRESS_PORT, we can run these tests using that as well:

echo "port: $WORDPRESS_PORT" > attributes.yml
inspec exec container_test.rb --attrs=attributes.yml

Final Solutions

Docker CLI in Shell

Docker the Hard Way: Part 2

Docker CLI in Perl, Ruby, or Python

Docker the Hard Way: Part 3

Docker-Compose

Docker the Easy Way — Part 2

Ansible

Docker the Ansible Way — Part 2

Python (Docker Python SDK)

Docker the Pythonic Way — Part 2

Vagrant

Docker the Vagrant Way - part 2

Terraform

Docker the Terraform Way - Part 2

Other Alternatives

I have not yet tried out these scenarios.

Curl (or Pure REST)

• Docker SDKs: https://docs.docker.com/develop/sdk/
• Docker SDKs Examples: https://docs.docker.com/develop/sdk/examples/

Ruby Language

• Docker API Gem: https://github.com/swipely/docker-api

Go Language

• Docker Go SDK Docs: https://godoc.org/github.com/docker/docker/client
• Docker SDKs: https://docs.docker.com/develop/sdk/
• Docker SDKs Examples: https://docs.docker.com/develop/sdk/examples/

Chef Cookbooks

• https://supermarket.chef.io/cookbooks/docker

Puppet Modules

• https://forge.puppet.com/puppetlabs/docker
• https://github.com/puppetlabs/puppetlabs-docker

Salt Stack Formulas

• https://github.com/saltstack-formulas/docker-formula
• https://github.com/salt-formulas/salt-formula-docker

Systemd

• https://container-solutions.com/running-docker-containers-with-systemd/
• https://coreos.com/os/docs/latest/getting-started-with-systemd.html

Which should I use?

The main purpose of these articles were to teach Docker and the related technology, but I am sure the question will arise, which solution should I use?

The Answer: It depends

There are so many ways to slice this problem, as Docker solves any number of problems. In my professional experience, I used different solutions depending on:

• Local Development
• Continuous Integration
• Deployed to Infrastructure: test, stage, uat, prod

Local Development

I almost always use Docker Compose as it is a great no fuss container orchestration.

Continuous Integration

For most cases, Docker Compose is also a great fit, and you can reuse the tooling from local development, making use of environment variables, such as BUILD_ENV=CI vs. BUILD_ENV=dev, to toggle options.

For cases where Docker is a build container, or a platform that loads a Java artifact (JAR, WAR, EAR, etc) such as Mulesoft, Tomcat, WildFly (JBOSS WilfFly Site), Apache Storm, etc., then I use regular Docker CLI with a makefile and custom support scripts.

Infrastructure Deployments (Test, Stage, UAT, Prod)

In this scenario, the database or other persistent storage are managed as an external source. For strictly the container portion, where I am running a web application, I would use either a deployment tool for simple needs, or robust scheduler.

For the deployment tool, I would use something like Ansible or Salt Stack combined with using a systemd unit to manage the container as I would with any other service.

For a more robust scheduler, I would use Kubernetes, such as EKS or Fargate, AKS, or GKE implementations. Alternatives to Kubernetes that I have not yet explored: Nomad, Swarm, or Mesos with Marathon or Aurora.

Conclusion

This article was to provide essentially and index into articles that I have published, and also to provide a clear set of requirements. The articles that state the problem (often the part 1) may prove useful, as they provide some hints or are further tailored to that unique tool.