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
<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
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:8080To:
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}}:8080At 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"]
<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"]- 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.