Summer is over and school is back in session. These events mark a change of seasons, a change in lifestyle, and a return to the meetups of Docker Brno. Tomáš Tomeček guided 45 of us through presentations by three speakers as well as a news and updates presentation.

Tomas started us off with a news and updates presentation about recent changes in Docker (Slides). He briefly covered a lot of the features in the latest releases of docker, versions 1.12.0 and 1.12.1.

These versions include the new orchestration components bundled into the daemon. The addition of the components is particularly controversial and has caused some people to wonder why they are part of docker-engine.

Along with the orchestration components, a new abstraction called the service API was added along with load balancing using IPVS in Linux Kernel. Additional features include a plugin API, a new HEALTHCHECK instruction, and the --live-restore daemon flag that allows for auto-restarting of your containers.

Josef Karásek presented “Rolling Down the Upgrade River doesn’t need to be a White Water Experience.” This demonstration of rolling updates used a Java application running in docker containers on OpenShift Origin.

The demo was a “canary-style” rolling upgrade, allowing an application to be upgraded in-place, on a live service, with no interruption for client sessions. While the demo used a monolithic application, many of the Twelve-Factor App principles were satisfied.

In both a show of demo-bravery and zero-to-hero magic, he started his demo with a clean install of OpenShift Origin. This was done using the new oc cluster up command which started a local single node OpenShift environment on his laptop. His secondary goal was to show how he could go from nothing to a fully launched Java application in less that 15 minutes, including build time and downloads.

To build the demo application he performed the following actions in the web console and with the CLI. He alternated between them to show off OpenShift during the build process.

1. Created a project to hold a git forge. OpenShift lives behind a NAT by default, so he needed a git forge that could send a webhook to the rest of OpenShift. This project contains one container that provides a Gogs - Go Git Service.

2. Created a second project to hold the actual application. Into this project he loaded:

   1. A Java application based on a JBoss EAP Quickstart example. The application is built using maven and is able to create and greet users and store session IDs in a replicated cache. The greeting page displays the cached session key information and reports what node is serving it. The session key was stored in a cache replicated over all EAP nodes. The application ran on a tiny cluster of two EAP servers (on a laptop!).
   2. A Postgres database to store user information.

3. Configured Image Streams and other administrative components of OpenShift so that new builds can be automatically triggered and deployed. This would normally be done by the operations team and not the developer.

4. Added the URL for the webhook to Gogs.

5. Started the application and let it build.

While the build was finishing, he talked about how there are models for using OpenShift that include full CI/CD systems, like Jenkins. These models allow code changes to be built, tested, merged and deployed automatically. Today, he changed the code and merged it by hand because he was on his laptop and had memory constraints.

Then it was demo breaking time! Karásek scaled the application to two replicas and showed how a specific pod was assigned to serve it. A “pod” is a Kubernetes abstraction that represents one or more related containers. The containers are managed as a single group for administrative purposes, including replication. In this example, each pod consists of one Java application container. Once we were convinced that the HAProxy router used by OpenShift would not allow us to be served by any other pod, he deleted the pod. The other pod was able to pick up the session without a user visible failure because of the auto-spawn capabilities of OpenShift and the session ID cache.

Next, it was time for a code change. A quick git clone later and the code was modified and pushed to the Gogs service. Less than a second later OpenShift reacted to the git webhook notification and kicked of a new build of the code. Using the web console and oc get pod, we watched the builds progress. When complete, they seamlessly and invisibly replaced the original pods with zero downtime.

This demonstration provided insight into how an existing application can be migrated to containers to gain scale-out and management features from an orchestrator like OpenShift Origin in a way that preserves all of the hard-won existing functionality. Take a look at the demo script and code and try it yourself.

We took breaks between every talk and enjoyed the fine facilities provided by kiwi.com. They arranged for the use of their wine cellar for the meetup and a large supply of beverages and food for the attendees.

Vadim Rutkovsky was next with his presentation, Ansible Container: Look mom, no Dockerfile! (Slides) His need for a new way to build containers was driven by his use of grafana. He started with a container from DockerHub, but quickly hit some limitations that would mean he needed a custom built version.

This should be easy to do as the Dockerfiles are online next to the containers. Unfortunately, the Dockerfile in question, while successfully able to build a container, was crazy-pants and not easy to maintain or modify. In particular its handling of plugins was not elegant.

This got him thinking about traditional application installment concepts and he decided to use Ansible Container. Ansible Container has ability to build docker images and orchestrate containers using only Ansible playbooks + shell + docker-compose. It allows the container builder to leverage the power of Ansible features like vars, templates and roles.

Getting started is easy thanks to the ansible-container init command. This generates the basic files of:

• main.yml: that describes the images
• container.yml: that describes orchestration
• requirements.txt: which can load additional Ansible modules, if required

A huge win came with the main.yml file structure because the container could be built using traditional application and system installation idioms.

A build using Ansible Container creates a “builder image” which allows building and deploying one or more images.
Ansible Container can then launch the container using docker-compose, or it can create a playbook and ship it to Kubernetes and OpenShift.

The project is fairly new and the next round of features will include build caching, detached execution, custom volumes and build variables, and rkt and OCI support. Full documentation is online as well as an active community in #ansible-container on Freenode.

Tomáš Král presented the final talk of the evening, Kompose: from your local machine to the cloud with one command. (Slides) Kompose can convert a Docker Compose file into a full Kubernetes or OpenShift configuration. It is a golang open source project supported by Skippbox, Google and Red Hat.

Kral’s demo used the golang guestbook application which he had decomposed into two containerized services. First he started the application just using a pair of docker run commands that started each service. Next he showed and used a Docker Compose file that was equivalent to the same pair of commands. Kompose showed up at this point and with one command allowed us to deploy our application to a local Minikube cluster.

As a final demo step, he made a live deployment to OpenShift 3 Online (dev-preview) to show how to go from a Docker Compose file on your local machine to a live production deployment in the cloud.

Kompose allows you to easily move from a development environment using Docker Compose or an application delivered with a distributed application bundle (DAB) file to a production quality environment based on Kubernetes and OpenShift. The output of Kompose allows you to quickly bootstrap to the rich Kubernetes and OpenShift environments with a standard configuration that can then be tuned and configured. Download the demo code and script and try it out.

This meetup was a fantastic event showing of some really cool technology. I want to thank our speakers, attendees and sponsors for an making this such an awesome event. I personally walked away motivated to play with both Ansible Container and Kompose to solve some challenges in my tech-life.

The meetup was made possible through the generosity of our sponsors: kiwi.com, who provided space and refreshments, and Red Hat, who provided administrative support and funding.

Our next meetup will be on 1 December 2016. We are looking for speakers and hope you’ll contact us at @DockerBrno or on our meetup page. If you’re not local to Brno and are interested in talking, contact us too. We may able to invite and sponsor you.