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.
- 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.
Created a second project to hold the actual application. Into this
project he loaded:
- 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!).
- A Postgres database to store user information.
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.
Added the URL for the webhook to Gogs.
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 imagescontainer.yml: that describes orchestrationrequirements.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.
View article »
