Welcome!

Containers Expo Blog Authors: Liz McMillan, Pat Romanski, Yeshim Deniz, Elizabeth White, Zakia Bouachraoui

Related Topics: @DevOpsSummit, Linux Containers, Containers Expo Blog

@DevOpsSummit: Blog Feed Post

Beyond Docker Compose By @XebiaLabs | @DevOpsSummit #DevOps #Containers

Docker Compose is the solution provided by Docker to help users package and deploy a set of containers that are running together

Beyond Docker Compose
By Benoit Moussaud

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

Docker deployment validated by a smoke test

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.

Docker compose file imported as is

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.

Docker compose file imported as Docker.Images

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.

docker-whales-transparent - xldeploy

The post Beyond Docker Compose appeared first on XebiaLabs.

Read the original blog entry...

More Stories By XebiaLabs Blog

XebiaLabs is the technology leader for automation software for DevOps and Continuous Delivery. It focuses on helping companies accelerate the delivery of new software in the most efficient manner. Its products are simple to use, quick to implement, and provide robust enterprise technology.

IoT & Smart Cities Stories
The deluge of IoT sensor data collected from connected devices and the powerful AI required to make that data actionable are giving rise to a hybrid ecosystem in which cloud, on-prem and edge processes become interweaved. Attendees will learn how emerging composable infrastructure solutions deliver the adaptive architecture needed to manage this new data reality. Machine learning algorithms can better anticipate data storms and automate resources to support surges, including fully scalable GPU-c...
Machine learning has taken residence at our cities' cores and now we can finally have "smart cities." Cities are a collection of buildings made to provide the structure and safety necessary for people to function, create and survive. Buildings are a pool of ever-changing performance data from large automated systems such as heating and cooling to the people that live and work within them. Through machine learning, buildings can optimize performance, reduce costs, and improve occupant comfort by ...
The explosion of new web/cloud/IoT-based applications and the data they generate are transforming our world right before our eyes. In this rush to adopt these new technologies, organizations are often ignoring fundamental questions concerning who owns the data and failing to ask for permission to conduct invasive surveillance of their customers. Organizations that are not transparent about how their systems gather data telemetry without offering shared data ownership risk product rejection, regu...
René Bostic is the Technical VP of the IBM Cloud Unit in North America. Enjoying her career with IBM during the modern millennial technological era, she is an expert in cloud computing, DevOps and emerging cloud technologies such as Blockchain. Her strengths and core competencies include a proven record of accomplishments in consensus building at all levels to assess, plan, and implement enterprise and cloud computing solutions. René is a member of the Society of Women Engineers (SWE) and a m...
Poor data quality and analytics drive down business value. In fact, Gartner estimated that the average financial impact of poor data quality on organizations is $9.7 million per year. But bad data is much more than a cost center. By eroding trust in information, analytics and the business decisions based on these, it is a serious impediment to digital transformation.
Digital Transformation: Preparing Cloud & IoT Security for the Age of Artificial Intelligence. As automation and artificial intelligence (AI) power solution development and delivery, many businesses need to build backend cloud capabilities. Well-poised organizations, marketing smart devices with AI and BlockChain capabilities prepare to refine compliance and regulatory capabilities in 2018. Volumes of health, financial, technical and privacy data, along with tightening compliance requirements by...
Predicting the future has never been more challenging - not because of the lack of data but because of the flood of ungoverned and risk laden information. Microsoft states that 2.5 exabytes of data are created every day. Expectations and reliance on data are being pushed to the limits, as demands around hybrid options continue to grow.
Digital Transformation and Disruption, Amazon Style - What You Can Learn. Chris Kocher is a co-founder of Grey Heron, a management and strategic marketing consulting firm. He has 25+ years in both strategic and hands-on operating experience helping executives and investors build revenues and shareholder value. He has consulted with over 130 companies on innovating with new business models, product strategies and monetization. Chris has held management positions at HP and Symantec in addition to ...
Enterprises have taken advantage of IoT to achieve important revenue and cost advantages. What is less apparent is how incumbent enterprises operating at scale have, following success with IoT, built analytic, operations management and software development capabilities - ranging from autonomous vehicles to manageable robotics installations. They have embraced these capabilities as if they were Silicon Valley startups.
As IoT continues to increase momentum, so does the associated risk. Secure Device Lifecycle Management (DLM) is ranked as one of the most important technology areas of IoT. Driving this trend is the realization that secure support for IoT devices provides companies the ability to deliver high-quality, reliable, secure offerings faster, create new revenue streams, and reduce support costs, all while building a competitive advantage in their markets. In this session, we will use customer use cases...