神刀安全网

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 whyXL 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. Beyond Docker Compose

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+)</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.

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>
Beyond Docker Compose

Docker deployment validated by a smoke test

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.

Beyond Docker Compose

Docker compose file imported as is

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.

Beyond Docker Compose

Docker compose file imported as Docker.Images

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.

Beyond Docker Compose

转载本站任何文章请注明:转载至神刀安全网,谢谢神刀安全网 » Beyond Docker Compose

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址
分享按钮