In this session we introduce administrators to the concepts of Docker and discuss architectural decisions that will come into play when deploying containers. Although this session was originally presented as part of IBM's New Way To Learn initiative it does not discuss any specific aspects of IBM technology

1. NWTL: Docker
Why, What, How?
Gabriella Davis
IBM Lifetime Champion for Social Business
The Turtle Partnership

2. Why?
• We are talking about Docker and containerisation because it’s a
rapidly emerging technology that has broken out from a
developer toolset into production architecture
• Connections Pink is entirely based on container architecture
which should mean we don’t have to actually install anything, just
deploy given containers
• Understanding container concepts and how to manage them is
going to be critical to managing our new environment

3. Audience
• This presentation is aimed at people who have heard of Docker but not
worked with it
• It is intended to give an overview of Docker and containerisation concepts
as well as enough of an understanding to get you started thinking about
deploying docker
• It is not a intended as a comprehensive guide on how to develop in Docker
• be wary reading the internet for out of data references to Docker
behaviour and commands

4. What? Concepts Behind Docker

5. Virtualisation
• Isolating applications running on a single physical server
• Virtualisation allows us to use software to mimic physical hardware
• Using virtual machines we can more easily create new server
instances and scale them
• This saves both time and cost
• The use of virtual machines and virtual environments has grown
exponentially in the past decade

6. Virtualisation works well but each instance represents a single piece of
physical hardware and so depends on all the software layers including
operating system being installed within for it to work

7. DevOps
• DevOps or Developer Operations refers to the collaboration of
software development and developers with IT operations
• it refers to practices, processes and communication not specific
technologies
• good DevOps practices are designed around rapid, consistent and
reliable systems
• The goal of DevOps is to ensure the seamless delivery and
maintenance of applications

8. Microservices
• Applications were traditionally developed in entirety with every function of the
application grouped together and operating in concert
• for that reason applications can often be large, over developed and hard to
update
• a change to a single function has to be incorporated into the entire application
without any impact
• Microservices architecture refers to applications that are developed as separate
functional or core services each operating in their own isolated container but able
to talk to each other
• updates are simpler and minimising the overall application size is easier by
deploying just those micro services that are needed

9. Containers
• Self-contained sandbox environments that host applications including micro
services
• Containers do not have an entire OS installed inside them the way virtual servers
do but instead share the OS of the host machine
• Multiple containers can share the OS of a host machine with their own isolated
application and file system
• Container architecture is designed to be portable and simple to update / maintain
• A container would usually contain a single service so that maximum benefit can be
leveraged from the portability

10. Virtual Machine vs Container
• With no OS of their own, containers are more lightweight and
allow the host OS and hardware to be utilised more efficiently
Virtual
Machines
Containers

11. Virtual Machine or Container?
It’s not an either / or - both architectures have their benefits and drawbacks
Virtual Machine Container
More isolated and more secure
Portable, simple to move between hosts or deploy
from development directly to production
Can run different operating systems in each virtual
machine and not be tied to the host OS
Fast to start up with no OS overhead
Able to granularly scale use of resources Able to make more efficient use of host resources
More work to set up and manage
Collectively dependent upon and all using the same
host OS
Each VM must have enough resources assigned to
also run the VMs OS
Potential for security vulnerability via a “bleed” from
the container to the OS and the process that started it

12. How? Working With Docker

13. Docker
• Docker is an open source container based virtualisation solution
• There is both a “Docker” client and a “Docker” server
• Docker is not the only container environment, there are others such as rkt
(Rocket) but IBM are using Docker for Connections Pink and it’s supported
in Bluemix
• While we’re here wouldn’t a Docker implementation for Domino be nice?
• There are many tools out there to help cluster Docker containers and manage
the infrastructure including Kubernetes from Google which is Linux only and
also supported within Bluemix

14. Docker the Program
• Docker has both a client and a server program
• The Docker server program handles all the containerisation commands
• The Docker client program talks to the server program giving it instructions such as “create
a new container” “open a bash shell in a running container” etc
• There are several Docker install models
• CE (Community Edition) available for Mac and Windows and aimed at small
development teams or personal use
• CE updates are issued quarterly (Stable) or monthly (Edge) and support is mostly
community based
• EE (Enterprise Edition) for production builds. This has an associated per node license
cost

16. Command Line
• Docker is very much a command line system
• You issue commands from the client on a terminal screen to work with Docker
elements
• Once you have installed a docker environment on your host machine you will have
the “docker” command line to work with
• CE version to create an entire Docker environment to work with
• Windows https://docs.docker.com/docker-for-windows/install/
• https://docs.docker.com/docker-for-mac/install/
• Note: Docker Toolbox which is referenced on a lot of sites is now a legacy system
and should be avoided

17. Images and Containers
• The Docker server runs on a host machine and maintains a registry of both
images and containers
• Once the Docker server is installed you can use the command “docker” to
manage your images and containers
• An image contains all the information needed to run a service or
application
• There are thousands of publicly available docker images already pre-
installed with specific services such as web servers, firewalls, databases etc
• These can be accessed from the online docker registry

18. Images and Containers
• You don’t run the image itself but use the
Docker server to spawn a container based
upon that image
• You can spawn as many containers as you
want using the same image on the same
host
• Each time a new container starts it is given
a name, an ID and a tag
• Changes made inside the container are
not saved when you quit it unless you
commit those changes back to a new
image

19. DockerFiles
• A dockerfile defines how to create an image
• Dockerfile ——> Image ——> Container
• you don’t need to have a dockerfile to create an image but
think of it as an image template

20. Where’s the OS?
• It’s not in the container
• It’s not in the image
• the OS kernel is on the host machine
• both the image and therefore the container access the host
kernel for their core functionality
• this means you can’t run a Windows container on a Linux host
machine or vice versa

21. Resources
• When creating a docker container from an image you do have
some control over the resources on the host that it can consume.
This includes
• Maximum allowed memory
• Allocated CPU % as a total of the host and/or relative to other
containers running
• This will prevent a container from consuming too much resource

22. Docker Networking
• Docker can create a private network for each container it starts
• Containers can be linked together to share the same private network and
isolate themselves from other containers started by the same docker
machine
• by linking containers you can ensure if they are killed then recreated with
the same name, the network link is maintained
• We can also tell the docker server to expose specific ports inside the
containers to external ports that can be reached outside the containers. For
instance a port 25 SMTP listener or 443 web server

23. Port Forwarding
• When running the containers we
specify both a port to open and
how it is reached from the host
machine
• This port forwarding can then be
used by other containers to talk to
each other via the host

24. Linked Private Networks
• Each container is created as part of a
private network
• Containers can be grouped in multiple
isolated private networks or none at all
• Containers can be told to “link” to
each other so that they can be seen an
addressed within their own private
network without routing traffic through
the host

25. Docker Data Volumes
• Shared storage areas that can be used by the containers to
access data on the host or within another container
• You can’t create volumes within a container so you create
volumes that link to either data stored in another container or on
the host
• Volumes defined within a container can be accessed by other
containers using the volumes-from option

26. Data Volumes in Containers
• You are essentially creating containers to be NFS
stores
• Since they are containers they can be moved to
new locations and the references to them will still
work
• However if the data container isn’t running the
data can’t be reached
• Backing up the data means backing up the
container
• All containers that mount that volume are reading
and writing to the same space
• Be careful not to destroy the data Container

27. Docker Data Volumes
• A location on the host machine that is “mapped” to a
mount point essentially in one or multiple containers
• It is accessible and exists regardless of whether any
containers are running or using it
• It can be backed up as standard data storage
• Access is controlled by host file permissions
• It can’t be as easily moved to a new location
• Be careful of tying yourself in knots with relative
references to data volumes
• Be VERY careful of launching a container if you don’t
know the mount points that are defined inside it

28. So Let’s Back Up A Bit
• Virtual Machines and Containers
• Microservices
• DevOps
• Docker
• Install and licensing
• Dockerfiles, images and containers
• Docker networking
• Docker storage

29. Some Common Docker Commands
• docker images - shows all existing images in the registry
• docker ps - shows all existing containers
• docker run - lets you start a new container from an image
• docker attach - lets you connect to a running container
• CTRL P, CTRL Q exists a running container without closing it
• CTRL D - exits and closes a container, this isn’t the same as removing it but does lose all
your changes
• docker-machine <command> <machinename> e.g. docker-machine inspect turtle test
• docker exec <container name>- run a new process in the named container e.g. bash
• docker logs <containername>

30. Down The Rabbit Hole
• This was just a very surface outline of what Docker is and how it
works
• If you’re a developer you can now dive into the rabbit hole that is
docker containers, building your own images and deploying your
own services
• If you’re an administrator who is going to be deploying images that
are supplied to you this should have helped you understand the key
components

31. When Deploying Docker In Production
• You will need to give thought to things like
• where the storage is and who shares it
• building private networks
• port forwarding
• backups
• plans for deploying updated images or moving containers
• You don’t need to learn all that programming stuff about building
Docker services that developers need to know

32. Questions?