Introducing DAB and Stacks for Docker MeetUp - Bangalore, 20th Aug 2016, ps: Includes playbook to rollout a swarm cluster to test these features

1. Docker Distributed
Application Bundle &
Stack
20th Aug 2016, Docker Bangalore Meetup,
RedHat India Pvt. Ltd.
Thomas Chacko
thomasch (at ) iconnexions.com

2. Distributed Application Bundle & Stack
Advisory: The functionality described here is marked as experimental, and as such, may
change before it becomes GA.
• Real-world applications are complex - codebases, stacks, databases, queues,
networks..
• Deploy and managing using docker compose and service to start/stop and link
individual containers / service not efficient within production environment
• Introducing DAB :: Experimental open file format to bundle and distribute all
artefacts for a real-world multi-container, multi-host, multi-tiered networked
applications
• High level abstraction - leverages all new features of Docker 1.12 ( swarm - orchestration &
load balancing, services, nodes etc ).
• DAB describes ( JSON ) :
• all services required
• images
• ports to expose
• networks used to link services
• etc…

3. Distributed Application Bundle & Stack
• Requires docker-compose 1.8 and docker 1.12. Developers use docker-compose to
create DABs and Ops deploys these stacks using docker.
• Image is a portable format for a single container file
• Distributed Application Bundle or DAB is a light-weight portable format for multiple
containers. Each bundle can be deployed as a Stack at run-time in production.

4. DAB in action - demo
Front End Back End
• Python webapp which lets you vote
between several options
• Node.js /AngularJS webapp showing
the results of the poll in real time
• Redis Queue to collect new votes
• Java Worker which consumes
votes and stores them in the
database
• Postgres database backed by a
Docker Volume

5. related command synopsis
$ docker-compose bundle --help
Generate a Distributed Application Bundle (DAB) from the Compose file . Images must have digests stored, which requires
interaction with a Docker registry. If digests aren't stored for all images, you can fetch them with `docker-compose pull` or `docker-
compose push`. To push images automatically when bundling, pass `--push-images`. Only services with a `build` option specified will
have their images pushed.
Usage: bundle [options]
Options:
--push-images Automatically push images for any services
which have a `build` option specified.
-o, --output PATH Path to write the bundle file to.
Defaults to "<project name>.dab”.
$ docker deploy --help
Usage: docker deploy [OPTIONS] STACK
Create and update a stack from a Distributed Application Bundle (DAB)
Options:
--file string Path to a Distributed Application Bundle file (Default: STACK.dab)
--help Print usage
--with-registry-auth Send registry authentication details to Swarm agents

6. related command synopsis..cont
$ docker stack --help
Usage: docker stack COMMAND
Manage Docker stacks
Options:
--help Print usage
Commands:
config Print the stack configuration
deploy Create and update a stack from a Distributed Application Bundle (DAB)
rm Remove the stack
ps List the tasks in the stack

7. Docker Compose vs DAB
• Docker Compose is a client side tool presently used in development / test workflow
• Docker DAB is ( specifically intended ) to be used at scale and server side orchestration
within production environment. Bundle deployment is an integral function of docker 1.12
engine. Stack can be deployed on a docker 1.12 swarm cluster only.
• DAB can deploy non-containerised app also.
• more (?)

8. Playbook : swarm/dab local test setup 1/4
• Pre-requisite : one Host PC or laptop : Windows 7+, MacOS X 10.11+, any modern Linux
with 3.10+ kernel ( recommended, Redhat/Centos/Ubuntu) with min 4GB ( 8GB
recomended) RAM and 20GB free hard disk.
• For Windows and OSX, one can install docker toolbox from https://docs.docker.com/
toolbox/overview/. Additionally can install docker for windows or OSX client also. For
Linux, install latest docker ver 1.12+ client /server , compose 1.8 from https://
docs.docker.com/engine/getstarted/step_one/ . Docker toolbox on OSX and Windows also
installs Oracle Virtualbox ; for Linux install it from https://www.virtualbox.org/wiki/
Downloads
• Create a docker hub/cloud login account ( https://cloud.docker.com/ - req only if one wish
to build custom images and push/pull from docker hub repository)
• Now we are ready to setup nodes and a swarm cluster on it
• Note : This playbook is for local VM setup. One can alternatively spin up machines on any
public cloud and follow this guide accordingly.

9. We will setup a simple 3 node swarm with 1 leader (master ) using docker-machine
Create the nodes :
$ docker-machine create -d virtualbox master
$ docker-machine create -d virtualbox node-1
$ docker-machine create -d virtualbox node-2
Inspect/configure the VM nodes created :
$ docker-machine ls
Note : VirtualBox will generally provision 2 networks : one NAT for internet and one Host-only networking whose IP will be
dynamically allotted with each reboots. This changing DHCP IP allocation will break our docker PKI and swarm config on
node reboots and hence the workaround presently is a tweak script here which can make this IP static ( Ref : https://
github.com/fivestars/docker-machine-ipconfig). Immediately after the VMs are created and docker provisioned - use the
above docker-machine-ipconfig cmd and make these ips static. The other option is to bypass docker-machine and instead
directly use vagrant/puppet/chef scripts with fixed ip declaration.
Recommended ( not mandatory ) - Add the ip address for all 3 nodes from ‘docker-machine ls’ cmd above to /etc/hosts on
the host OS machine. This playbook assumes such and refers nodes with their host name here viz. ( master , node-1 ,
node-2 ). Recommended to edit VM settings and set all the 3 node VMs memory to 1GB (min, recomended 2GB) each.
Roll out the swarm cluster network :
(Optional ) If docker for Windows or OSX client was also installed, then we need to point this local docker client to the
Docker engine on master node by setting DOCKER_* environment variables using :
$ eval $( docker-machine env master )
Lets initialise the swarm network on master node.
$ docker-machine ssh master
master $ docker swarm init — listen-addr=192.168.99.103:2733 —advertise-addr=192.168.99.103:2733
The - - advertise-addr above is required because of 2 network interface on these VMs. Substitute 192.168.99.103 above
with your master node ip from ‘docker-machine ls’. The above command will return an URL with a swarm token string to be
run on each worker nodes. SSH to each worker nodes and copy/paste this command on it
$ docker-machine ssh node-1
node-1 $ ( copy/paste the above join command here )
repeat above for node-2. The docker swarm cluster is setup .
Checkout the Docker swarm cluster members . PS: all commands further down are assumed to be run against master node.
$ docker node ls
This will show the three nodes with the elected leader node(s) tagged.
Playbook : swarm/dab test-setup 2/4

10. Test setup the classic voting app ( thanks to Docker )
Option -1 Download/ build the images required for this Docker playbook
$ git clone https://github.com/docker/example-voting-app.git
$ cd example-voting-app
There are 5 services , one can modify the script to change the poll options etc. refer git read me.
$ cd vote
$ docker build --no-cache -t thomasch/votingapp_voting-app .
{ replace thomasch here in all the image name(s) with your docker-hub id or name }
$ cd worker
$ docker build --no-cache -t thomasch/votingapp_worker .
$ cd result
$ docker build --no-cache -t thomasch/votingapp_result-app .
We will push these images to docker repository ( also create image digest )
$ docker login
{ provide docker hub/cloud username and password when prompted }
$ docker push thomasch/votingapp_voting-app
$ docker push thomasch/votingapp_worker
$ docker push thomasch/votingapp_result-app
{ use corrected docker image names above }
Option-2 OR ALTERNATIVELY instead of Option-1 , [ only if you trust them :) ] - you can pull these images directly
from my docker public repository
$ docker pull thomasch/votingapp_voting-app
$ docker pull thomasch/votingapp_worker
$ docker pull thomasch/votingapp_result-app
Inspect the docker-compose.yml file in the example-voting-app folder. This file has to be slightly modified to be dab
conversion compatible . Check/download the final edited version here :
https://gist.github.com/thomgit/c0ddfcded35f986055e391442c83bda9
Copy this yml file to a new directory. Review and update the images names if you have changed them during custom
build above in Option-1.
Playbook : swarm/dab test-build 3/4

11. Convert the compose YAML to DAB format and test stack and swarm workflow
cd to the directory with modified docker-compose.yml file and covert this to .DAB format
first pull the remaining images required for this voting app from public repository - redis, postgres
$ docker-compose pull vote, redis, worker , db, result
convert the docker-compose yaml file to JSON dab format using docker-compose client tool ( >ver 1.8 )
$ docker-compose bundle -o votingapp.dab.
deploy this dab file on the swarm cluster we setup
$ docker deploy votingapp
This will deploy 5 services - it might take time for all the 5 services to start. Check the stack services status using
$ docker stack ps votingapp
Inspect the ‘PublishedPort’ for votingapp_vote and votingapp_result. These port(s) should be in 30000+ range.
$ docker service inspect votingapp_vote --pretty
$ docker service inspect votingapp_result --pretty
The voting and results front-end will be available in the host machine browser on any ( swarm mesh network feature ) node
cluster ip address ( e.g. http://192.168.99.xx: <PublshedPort> ). Test the vote page and see the real-time poll results
displayed by the node.js/AngularJS result app page.
We have stood-up an entire application stack now . The new ‘docker stack’ CLI can be used to manage all the services
together in this stack:
check the stack configuration
$ docker stack config votingapp
delete the entire stack
$ docker stack rm votingapp
Additional suggested activity
Use this docker swarm cluster to :
• test scale-up/down the votingapp_vote service
• drain any one node and see how swarm reschedules the services to other node(s) to maintain the desired state of stack
• create a new version of votingapp_vote_v2 and check out rolling upgrades.
Hope this help get a reasonable grip on these exciting new docker 1.12 features...
Playbook : swarm/dab test-run 3/4