Beyond Docker Compose

Docker Compose is the solution provided by Docker to help users package and deploy a set of containers that are running together. The containers are identified either by its image name or by the ‘build’ configuration keyword that asks Compose to build it before to deploy it. The typical use case is that a developer is working on a new image, but he/she needs all of its dependencies to make it run. So he/she enters in the following cycle: make modifications, commit, and restart the containers using the ‘docker-compose up’ command... until the feature is done. Fine! But how do you move from development to production? If you’re following the same pattern, you'll fail. I’ll show how and why XL Deploy can help you to tackle the obstacles. Note: The docker-compose file used in this article comes from a blog post written by Arun Gupta.  

Stop building the images, compose only.

The scenario described above works well on the development side. Docker Compose provides a fast way to build the new image and deploy the images on an existing Docker machine, allowing the developer to quickly validate the modifications. But once the feature is done, the release process should aggregate only images and their configurations in a ready-to-deploy package.

Missing meta-information

One drawback of the docker-compose file is that there is no information about the application name and its version. Of course, you can commit your file in an SCM and tag a version. For example, if your repository name is ‘my-app’, you can publish it in the 'my-app-delivery’ repository and tag the commit with ‘v1.0.4’. XL Deploy provides out of the box features to describe and to store the versions of your application: so it can help you by acting as an application repository. To build the deployment package, you can use the XL Deploy Jenkins plugin, the XL Deploy Maven plugin, or a simple build file that zips your docker-compose.yml file with an XL Deploy manifest file (deployit-manifest.xml) like this one.  

<udm.DeploymentPackage version="1.0.4" application="wildflymysqljavaee7">
 <deployables>
   <docker.ComposeFile name="docker-compose-app" file="wildflymysqljavaee7.yaml"/>
 </deployables>
</udm.DeploymentPackage>

Using the XL Deploy deployment package also allows you to add more than one docker-compose file. For example:  

<udm.DeploymentPackage version="1.0.4" application="wildflymysqljavaee7">
  <deployables>
    <docker.ComposeFile name="docker-compose-app-front" file="wildflymysqljavaee7-front.yaml"/>
    <docker.ComposeFile name="docker-compose-app-back" file="wildflymysqljavaee7-back.yaml"/>
  </deployables>
</udm.DeploymentPackage>

Behaviour: the wildflymysqljavaee7 version 1.0.4 is composed of 2 docker-composed applications described in 2 yaml file:

• wildflymysqljavaee7-front.yaml, the compose file for the front part of the application
• wildflymysqljavaee7-back.yaml, the compose file for the backend part of the application

Use Case: Describing all the components of an application in a single docker-compose file can be difficult to manage, especially for a very large application whose containers cannot be deployed independently. In this case, the docker-compose file becomes a critical resource. Moreover the ‘modify-commit-up’ cycle may become slower and slower using a large compose file. An XL Deploy deployment package also allows you to define dependencies between different parts of your applications. For example:  

<udm.DeploymentPackage version="1.0.4" application="wildflymysqljavaee7">
  <deployables>
    <docker.ComposeFile name="docker-compose-app-front" file="wildflymysqljavaee7.yaml"/>
  </deployables>
  <applicationDependencies>
    <entry key="wildflymysqljavaee7-back">1.0.0</entry>
  </applicationDependencies>
</udm.DeploymentPackage>

Behaviour: The application wildflymysqljavaee7 version 1.0.4 depends on application wildflymysqljavaee7-back version 1.0 or above.Use Case: different teams provide the different parts of the application; the dependencies allow the test and ops teams to deploy a full platform with right components.

Live Webinar: Enterprise Software Delivery in the Age of Containers

Many companies are challenged with how to run containers at scale and standardize and manage release processes across hundreds of applications. Learn from Rob Stroud, XebiaLabs CPO and former Forrester Analyst, how to bridge the gap between the promise of containers and the realities of complex enterprise application delivery.

Manage the configuration

Like all applications (legacy or Dockerized), a Docker-composed application needs to be configured across all environments: Development, Test, QA and, Production etc. The configuration is always managed at two levels:

• The technical configuration defines values for items such as user names, passwords, endpoint URL, machines, IP addresses, and so on
• The functional configuration defines values for items such as feature toggles, timeout (for example, 10 minutes in Test, 12 hours in Production), labels, and so on

During the build process, the values set in the docker-compose file should be replaced by placeholders then XL Deploy will automatically detect them and manage them at deployment time. From:  

mysqldb:
  image: mysql:5.7
  environment:
    MYSQL_DATABASE: sample
    MYSQL_USER: mysql
    MYSQL_PASSWORD: mysql
    MYSQL_ROOT_PASSWORD: supersecret
mywildfly:
  image: arungupta/wildfly-mysql-javaee7
  links:
    - mysqldb:db
  ports:
    - 8080:8080

  To:  

mysqldb:
  image: mysql:5.7
  environment:
    MYSQL_DATABASE: {{MYSQL_DB_NAME}}
    MYSQL_USER: {{MYSQL_DB_USER}}
    MYSQL_PASSWORD: {{MYSQL_DB_PASSWORD}}
    MYSQL_ROOT_PASSWORD: {{MYSQL_DB_ROOT_PASSWORD}}
mywildfly:
  image: arungupta/wildfly-mysql-javaee7
  links:
    - mysqldb:db
  ports:
    - {{HOST_PORT}}:8080

  At deployment time, XL Deploy will either request values for the placeholders for the current deployment or will query the dictionaries that are associated with the target environment. With this feature, it is easier to set different credentials or to manage the host port value for each environment. Docker Compose provides a similar mechanism but with few drawbacks:

• No automated detection: you need to open and analyse the yaml file to find out the properties using $XXX or ${XXX} format
• No error or warning if a property’s value is not provided: a blank value is set instead.
• The values are provided using shell environment variables and because there is not only a single parameter to manage, the result is a very long command line and or the need to manage a set of shell script per environment (source envXXX.sh && docker-compose up)

Not only Docker images

By definition, Docker Compose only manages Docker images. The XL Deploy manifest file allows you to not only package the docker-compose files, but also to add extra items. For example, in the manifest file you can define a smoke test that should run after the application has been deployed to check that everything is up and running. In the blog post on which this article is based, Arun Gupta ran the smoke test to check the service was up after the application was turned up. The following manifest file includes the compose yaml file and the associated smoke test.  

<udm.DeploymentPackage version="1.0.6" application="wildflymysqljavaee7">
  <deployables>
    <smoketest.HttpRequestTest name="check customer web service">
      <url>http://{{HOST_ADDRESS}}:8080/employees/resources/employees/</url>
      <expectedResponseText>collection</expectedResponseText>
    </smoketest.HttpRequestTest>
    <docker.ComposeFile name="docker-compose-app" file="wildflymysqljavaee7.yaml"/>
  </deployables>
</udm.DeploymentPackage>

[caption id="attachment_11889" align="aligncenter" width="300"] Docker deployment validated by a smoke test[/caption]   Another use case is to support a hybrid-mode. If your new applications will be fully based on containers, the oldest will begin by replacing small and non-critical parts by containers. In this case, the XL Deploy manifest file will help you to package legacy part with a container part in a single definition. The following manifest file includes the compose yaml file and the legacy ear file.  

<udm.DeploymentPackage version="2.0.6" application="MyLegacyApp">
  <deployables>
    <jee.Ear name="myApp.ear" file="myApp-2.0.6.ear"/>
    <docker.ComposeFile name="docker-compose-app" file="migrated-part-compose.yaml"/>
  </deployables>
</udm.DeploymentPackage>

Open the black box!

In one hand, using the docker-compose command is easy; but on the other hand, it’s all black box magic. If you run `docker-compose up`, there is very little information on the commands that are actually being executed under the covers. Moreover the command displays the logs of all the started containers in a single and multiplexed output that is very difficult to analyse in case of error. XL Deploy allows you to import your docker-compose YAML file and, instead of identifying it as a ‘docker.ComposeFile’ type, it can create all of the referenced images for you and put them in a deployment package as ‘docker.Images’ with its associated configuration (links, ports, volumes, environments variables…) Below, the version 1.0.4 is imported as a docker-compose file and deployed on the Development environment; in this case, XL Deploy generates a single step.   [caption id="attachment_11890" align="aligncenter" width="300"] Docker compose file imported as is[/caption]   Below, version V1448026576129 is imported using the same docker-compose file, but translated into ‘docker.Images’ and deployed on the Development environment; in this case, XL Deploy generates six steps.   [caption id="attachment_11891" align="aligncenter" width="300"] Docker compose file imported as Docker.Images[/caption]   The 6 steps are easier to control and to orchestrate.

• The ops teams like to control, so with a 6 generated steps sequence they can easily insert pauses before or after the steps.
• Deploying a container-based application to a complex environment implies to target different containers on multiple machines so with a more detailed view it is now possible to orchestrate the deployment plan using sequential and parallels blocks.

The docker plugin for XLDeploy is available as a community plugin here: https://github.com/xebialabs-community/xld-docker-plugin/ so feel free to test it and to improve it to match your need. Thanks to Arun Gupta for his blog post.