Training Containerization

Gepardec who?

That’s us

office: vienna / linz
size: ~ 40 people
we do what we love..
- custom software solution
- cloud transformation
- devOps automation

openshift

rh premium partner

jboss

How we teach

Gepardec believes in learning by doing
The training is lab driven
Work together!
Ask questions at any time

Session Logistics

1 days duration
Mostly exercises
Regular breaks

Assumed knowledge and requirements

Fmailiarity with Bash or Powershell
Bash Cheat sheet http://bit.ly/2mTQr8l

Your lab environment

You have been given an instance for use in the exercises
Ask the instructor for the credentials if you don’t have them already

Training learning objectives

By the end of this training, trainess will be able to

Asses the advantages of a containerized software development & deployment
Use container engine features necessary for running containerized applications

Virtualization vs Containerization

What we want

Ideal software should

be modular and flexible (DEVs)
be easy to migrate (DEVOPS)
be easy to scale, monitor and lifecycle (OPS)
mitigate vulnerabilities (Security)
and run cheap (business)

Every stakeholder in the software supply chain has a set of priorities they’d like software to satisfy.
Developers want flexibility and choice in the components they build application out of; problems like vendor lock-in, technical debt, and tight coupling between components slows the development cycle down and can prevent developers from building the software they want.
Devops engineers in charge of building and maintaining CI/CD pipelines are primarily responsible for getting applications running across many environments; they’d like to be able to move software easily, and rely that tests passing in one environment won’t break in another.
Operations teams responsible for scaling, maintaining and monitoring software would like to be able to deploy applications easily across a datacenter, and know what to expect from those applications to make monitoring and maintenance simple.
Security teams want assurances that software not only minimizes attack surfaces, but has built-in failsafes to mitigate compromises when they occur.
Finally, business interests want to be able to do all of the above as cheaply as possible, by making most efficient use of the compute resources purchased to run it.
These are many and varied priorities - but containerization is such a success because it speaks to all of them.

Virtualization

Without containerization, we can imagine a host that looks as such. The key feature of this diagram is that all the dependencies, configurations, and system resources for applications on this host are shared.
From the developer’s standpoint, an uncontainerized environment requires strict discipline to avoid tight coupling between components; it’s easy to develop your way into a state where changes to one component break another, and all components are affected by the environmental requirements of the others, complicating and hindering testing and development.
For a devops engineer, the shared host environment of these components also adds friction. Every environment in the CI pipeline has to reflect this stack of dependencies and configurations, which can be difficult to maintain and difficult to reproduce.
For operations personnel, the more tightly coupled different components become, the more difficult they can be to scale and monitor; tight couplings can make it complicated to understand what’s needed to relax a performance bottleneck or trace root causes of application failures.

Containerization

Rapid development

Containers can be removed and replaced with a minimum of impact on their neighbors, increasing developer choice and speed.

Smooth migration

Containers carry their environment and dependencies with them, simplifying and minimizing requirements on the hosts that run them.

Simple sclae & mainenance

Containers have private system resources, so a compromise in one does not affect the rest.

Secure by default

Containers have private system resources, so a compromise in one does not affect the rest.

Application density

Containers save datacenter costs by running many more application instances than virtual machines can on the same physical hosts.

Containerization basics

Learning objectives

By the end of this module, trainees will be able to

Describe what a container is in terms of processes and isolation tools
Use the key commands for interacting with Docker containers

Containers are processes

Containers are processes sandboxed by

Kernel namespaces
Control Groups
Root priviledge management & syscall restrictions (Linux)
VM isolation (Windows)

Linux kernel namespaces

DEFAULT
- Process IDs
- Network stacks
- Inter-process communications
- Mount points
- Hostnames
OPTIONAL
- User IDs

The baseline tool for creating containers is the kernel namespace. Kernel namespaces create distinct representations of things like PID trees, user spectra, network stacks and mount points; processes live in exactly one namespace, and are only able to interact with the broader system via the representation encapsulated therein.
By analogy: an un-namespaced system is like when airplanes used to have just one TV in the cabin everyone would look up at to watch the in-flight movie. Everyone shared the device, and everyone saw the same thing.
Introducing namespaces is like putting seatback TVs in front of every passenger. Now everyone has their own private devices and sees their own thing, which is hidden from their neighbors.
In the same way, a namespaced process has all their own resources - their own iptables rules and eth0 device, their own mount points, their own PID tree - and processes in other namespaces aren’t allowed to touch or even see these resources.

Linux PID kernel namespace

For example, PID namespaces make the first process in the namespace appear as the root of a process tree to all other processes in that namespace, which will be its children.
Meanwhile, processes in the parent namespace see these processes with PID numbers like any other process in the parent PID namespace.
In this way, processes in the child namespace aren’t able to find information about processes in the parent namespace, but the child namespace remains transparent from the perspective of the parent namespace.
Stopping the PID 1 of a child namespace and stopping the container are the exact same thing.
Isolating host system resources, rather than creating a whole new virtual machine, is where the high performace of containers comes from. Think of it like building a little wall around a patch of sand in a sandbox; the area marked off can itself be thought of as a new sandbox, but no new sand has been acquired.

Optional Linux isolation features

Control groups: limit memory & CPU
Root priviledge management: acceptlist root powers
System call management: acceptlist available system calls
Linux Security Modules: mandatory filesystem access control

Instructor demo: Process isolation

See the demo

Process isolation

in the exercise book

Exercise: Container Basics

Work through

Running and inspecting a container
Interactive containers
Detached containers and Logging
Starting, stopping, inspecting and deleting cotnainers

In the exercise book.

Container lifecycle

The rectangles display the state of the container and the arrow labels show the Docker command used to change the container state.
The container lifecycle always begins in the CREATED state. A container in this state has a private filesystem set up on disk (more on this in the next chapter) and metadata defined regarding what process it is to encapsulate and how, but it not yet running. When the process in question begins running, the container transitions to the UP state.
If a containerized process exits, the container transitions to the EXITED state. It can normally be restarted with a start command.
Finally, Docker containers can enter a PAUSED state of suspension imposed by control group freezing. This suspension technique (unlike using SIGSTOP and SIGCONT) can’t be caught by the process, ensuring that pausing a container doesn’t disrupt the process it containerizes.

Container logs

STOUD and STERR for a container process
docker container logs <container_name>

Container basics takeaways

Single process constrained by kernel namespaces, control groups and other Linux technologies
Private & ephemeral filesystem and data

Container images

Learning objectives

By the end of this module, trainess will be able to

Create container images via several methods
Describe the filesystem structure underlying a container image
Understand the performance implications of different container image design decisions
Correctly tag and namespace container images for distribution via a registry

What are container images?

A filesystem for container processes
Made of a stack of immutable layers
Start with a base image
New layer for each change

Sharing layers

The writable container layer

Images: Copy on write

Linux Containers: Union FS

Creating images

Three methods:

Commit the R/W container layer as a new R/O container image layer.
Define layers to add to a existing container image in a Containerfile.
Import a traball into as a standalone base image.

Commiting container changes

docker container commit saves the container layer as a new R/O container image layer
Pro: build container images interactively
Con: hard to reproduce or audit; avoid this in pratice

Containerfiles

Content manifest
Provides container image layer documentation
Enable automation (CI/CD)
FROM command defines the base image
Each subsequent command adds a layer of metadata
docker image build … builds container image Containerfile

# Comments begin with the pound sign
FROM ubuntu:16.04
RUN apt-get update && apt-get install -y wget
ADD /data /myapp/data

Instructor demo: Creating images

See the demo

Creating images

in the exercise book.

Exercise: Creating images

Work through

Interactive Image Creation
Creating Images with Dockerfiles (1/2)

in the exercise book.

Build cache

After completion, the resulting container images layer is labeled with a hash of the content of all current image layer in the stack.

CMD and ENTRYPOINT

Recall all container run a process as their PID 1
CMD and ENTRYPOINT allow us to specify default processes
CMD alone: default command ans list of parameters.
CMD & ENTRYPOINT provides command, CMD provides default parameters.
CMD overridden by command argument to docker container run
ENTRYPOINT overriden via --entrypoint flag to docker container run.

Shell vs Exec format

# Shell form
CMD sudo -u ${USER} java ...

# Exec form
CMD ["sudo", "-u", "jdoe", "java", ...]

CMD, ENTRYPOINT and RUN commands can use either exec or shell syntax
If we have a command like this on Windows powershell New-Item c:\test then if it is in declared in shell form what is executed is in reality cmd /S /C powershell New-Item c:\test whilst in exec form the command is executed as is without the use of the shell (cmd in this case). The analogous is true for Linux containers.
exec is generally preferred for ENTRYPOINT, since it preserves the ability to override options.
subtle differences:
- Shell form allows for the parsing of variables like `CMD sudo -u ${USER} java … `
- Exec form can run in a container with no shell; shell form always runs via /bin/sh -c
- Shell form for ENTRYPOINT prevents options from being overridden by CMD or docker container run.
Note that exec form is formal JSON - double quotes mandatory.
When using the shell form, the specified binary is executed with an invocation of the shell using /bin/sh -c, which means the process running as PID 1 is the /bin/sh executable.

Exercise: Containerfiles (2/2)

Work through

Creating Images with Dockerfiles (2/2)

in the exercise book.

COPY and ADD commands

COPY copies files from build context to container image

COPY <src> <dest>

ADD can also untar* or fetch URLs.

* Linux containers only!

create checksum for files added
log checksum in build cache
cache invalidated if checksum changed

Containerfile command roundup

FROM: base image to start fron (usually OS)
RUN: run a command in the environment defined so far
CMD & ENTRYPOINT: define default behaviour
COPY & ADD: copy files into container

Many more Containerfile commands are available; see the docs at https://docs.docker.com/engine/reference/builder/

Advanced Containerfile construction

How can we build container images that are

Lighweight
Secure
Minimal build times

The scratch container image

An "empty" image
Can’t be pulled
Doesn’t create a layer
Used for building container image not based on any pre-existing container image
Linux only

FROM scratch

ADD centos-7-docker.tar.xz /

LABEL org.label-schema.schema-version="1.0" \
org.label-schema.name="CentOS Base Image" \
org.label-schema.vendor="CentOS" \
org.label-schema.license="GPLv2" \
org.label-schema.build-date="20181205"

CMD ["/bin/bash"]

Multi-Stage builds (1/2)

Hello worls, in C:

FROM alpine:3.5
RUN apk update && \
    apk add --update alpine-sdk
RUN mkdir /app
WORKDIR /app
ADD hello.c /app
RUN mkdir bin
RUN gcc -Wall hello.c -o bin/hello
CMD /app/bin/hello

Builds to:

$ docker image ls hwc
REPOSITORY      TAG             IMAGE ID        CREATED         SIZE
hwc             latest          142c29686b6a    15 hours ago    184 MB

Multi-Stage builds (2/2)

Hello worls, in C:

# Full SDK version (built and discarded)
FROM alpine:3.5 AS build
RUN apk update && \
    apk add --update alpine-sdk
RUN mkdir /app
WORKDIR /app
ADD hello.c /app
RUN mkdir bin
RUN gcc -Wall hello.c -o bin/hello

# Lightweight image returned as final product
FROM alpine:3.5
COPY --from=build /app/bin/hello /app/hello
CMD /app/hello

Builds to:

$ docker image ls hwc
REPOSITORY      TAG             IMAGE ID        CREATED         SIZE
hwc             latest          5d925cfc9c96    39 seconds ago  4MB

Build target

Containerfile

FROM <base image> as base
...

FROM <foo image> as foo
...

FROM <bar image> as bar
...

FROM alpine:3.4
...
COPY --from foo ...
COPY --from bar ...
...

building the container image

docker image build --tag <name> …

Exercise: Multi-Stage Builds

Work through

Multi-Stage Builds

in the exercise book.

Container image construction best practices

Start with an official container image
Use multi-stage builds to drop compilers, SDKs, …
More layers leverage the cache
…but fewer layers perform better

Now that we have the mechanics of making Dockerfiles, there’s also a number of optional best practices to consider.
Base your images off of official images whenever possible; you can recognize these on Docker Hub as they don’t have an explicit namespace like vendor/product; they’re just single-word names, possibly with a tag. These are all battle-tested images produced in collaboration between the product vendors and Docker, and are scanned regularly for security vulnerabilities.
Take advantage of multi-stage builds; these allow you to drop unnecessary layers, which will result in faster container start times, and less components that potentially inject vulnerabilities into your containers.
Deciding how many layers to build an image out of depends on your priorities. The fundamental tension is that more layers leverage the cache better (since hopefully you don’t invalidate the cache until you’re most of the way through your Dockerfile), but this creates more overhead at container runtime, which you may wish to avoid for production images.

Development: More layers

Bad caching:

FROM python:3.5-alpine
RUN mkdir /app
COPY /mypy /app/
RUN pip install -r app/reqs.txt
...

Good caching:

FROM python:3.5-alpine
RUN mkdir /app
COPY /mypy/reqs.txt /app/
RUN pip install -r app/reqs.txt
COPY /mypy /app/
...

Production: Less layers

To collapse ALL image layer:

$ docker container run -d --name demo mytallimage:1.0
$ docker container export demo > image.tar
$ cat image.tar | docker image import - myflatimage:1.0

Or build with --squash flag (experimental): compress all non-base-layers
Use container export --squash for one shareable base layer & one application layer

Once it’s time to go to production (or even to start CI/CD), we don’t care so much about build times and caching. The image is nominally built - what matters is performance.
One way to compress everything into a single layer is to export a container as a tarball, and reimport it as a new, single layer image. This completely destroys the ability of containers to share layers, though
Another method is the experimental squash flag, which combines all non-base layers into a single layer. Now the base layer remains sharable, and our production image is only two layers.
One technique for getting the best of both worlds when layer sharing is important is to use the first method to collapse all widely shared layers into a common base image, and then use the --squash flag on subsequent builds to squash the application-unique layers into a single application layer.

Best practices: Patching & Updates

Container Image tags

Optional string after image name, separated by :
:latest by default
Same image with two tags share same ID, image layer:

$ docker image ls centos*
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
centos              7                   8140d0c64310        7 days ago          193 MB
$ docker image tag centos:7 centos:mytag
$ docker image ls centos*
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
centos              7                   8140d0c64310        7 days ago          193 MB
centos              mytag               8140d0c64310        7 days ago          193 MB

Container Image namespaces

Container images exist in one of three namespaces:

Root (ubuntu, nginx, mongo, mysql,…)
User / Org (jdoe/myapp:1.1, microsoft/nanoserver:latest,…)
Registry (FQDN/jdoe/myapp:1.1)

Image tagging & namespacing

Tag on build: docker image build -t myapp:1.0 .
Retag an exisitng image: docker image tag myapp:1.0 me/myapp:2.0
Note docker image tag can set both tag and namespace
Names and tags are just pointers to container image ID
Container Image ID corresponds to immutable content addressable storage

Sharing container images

Docker HUB
- Provides certified commercial and free software distributed as Docker Images
- Shares community-generated container images and content

Exercise: Managing container images

Work through

Managing Images

in the exercise book.

Container Image Creation takeaways

Container images are built out of R/O layers.
Containerfiles specify container image layer contents
Key Containerfile commands: FROM, RUN, COPY and ENTRYPOINT
Container images must be namepsaced accoriding to where you intend on sharing them

Container Volumes

Learning objectives

By the end of this module, trainees will be able to

Define a volume and identify its primary use cases
Describe advantages and potential secuity risks of mounting volumes and host directories

Volume usecases

Volumes provide a R/W path separate from the layered filesystem.

Mount data at container startup
Persist data when a container is deleted
Share data between containers
Speed up I/O by circumventing the union filesystem

Volumes primarily provide a way to handle data that has a longer lifecycle than an individual container, by providing a writable location separate from the container’s union filesystem.
For example, if a container needs access to a large body of files, those files can be mounted into a running container as a volume, avoiding the need to create a (potentially huge) image with that data baked in.
If a container is creating or collecting data as it runs, it should be stored in a volume, since that volume will survive the deletion of the container.
Furthermore, volumes can be a more performant choice for write heavy workloads for the same reason. Rather than searching the layers of the union filesystem and performing a copy on write operation when writing a file, I/O in a volume simply reads and writes the relevant file, without the added overhead.

Basic volumes

Named: managed by Docker; filesystem independent; user-specified identifier
Anonymous: managed by Docker; filesystem independent; randomly-generated identifier
Host mounted: mount a specific path on the host; DIY management

Instructor demo: Volumes

See the demo

Basic Volume Usage

in the exercise book.

Volumes in Containerfile

VOLUME instructions creates a mount point
Can specify arguments in a JSON array or string
Cannot map volumes to host directories
Volumes are initialized when the container is executed

FROM nginx:latest
...
# string example
VOLUME /myvolume

# string example with multiple volumes
VOLUME /www/website1 /www/website2

# JSON example
VOLUME ["myvol1", "myvol2"]
...

Volumes and security

Point of ingress to the host and other containers
Don’t mount things unnecessarily
Use the :ro flag whenever possible
Linu: in-memory tmpfs mounts available

Volumes are the first thing we’ve seen so far that pierce the isolation we carefully crafted between containers, the host, and other containers. A malicious actor can inject files from one container to another, and to the host, if care is not taken.
Mount volumes and directories only as needed, and use the :ro flag when a container is only a passive consumer of data. Better yet, ask if there’s a way to separate out reader and writer containers, to keep write access to volumes as tightly restricted as possible.
Also for those running linux hosts, it’s also possible to mount purely in-memory volumes to a container; anything written here will never be written to disk, and will be released when the container is deleted. This is a good option for persisting sensitive data while a container is running.

Exercise: Volumes usecases

Work through

Database Volumes

in the exercise book.

Container volumes takeaways

Volumes persist data beyond the container lifecycle
Volumes bypass the copy-ob-write system (better for write-heavy containers)

Docker system commands

Learning objectives

By the end of this module, trainees will be able to

Execut cleanup commands
Locate Docker system information

Cleanup commands

$ docker system df
TYPE           TOTAL    ACTIVE   SIZE        RECLAIMABLE
Images         39       2        9.01 GB     7.269 GB (80%)
Containers     2        2        69.36 MB    0 B

docker system prune

more limited…

docker image prune [--filter "foo=bar"]
docker container prune [--filter "foo=bar"]
docker volume prune [--filter "foo=bar"]
docker network prune [--filter "foo=bar"]

Inspect the system

$ docker system info
Containers: 2
 Running: 2
 Paused: 0
 Stopped: 0
Images: 105
Server Version: 17.03.0-ee
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host ipvlan macvlan null overlay
Swarm: active
 NodeID: ybmqksh6fm627armruq0e8id1
 Is Manager: true
 ClusterID: 2rbf1dv6t5ntro2fxbry6ikr3
 Managers: 1
 Nodes: 1
 Orchestration:
  Task History Retention Limit: 5
 Raft:
  Snapshot Interval: 10000
  Number of Old Snapshots to Retain: 0
  Heartbeat Tick: 1

System events

$ docker system events
2017-01-25T16:57:48.553596179-06:00 container create 30eb630790d44052f26c1081...
2017-01-25T16:57:48.556718161-06:00 container attach 30eb630790d44052f26c1081...
2017-01-25T16:57:48.698190608-06:00 network connect de1b2b40f522e69318847ada3...
2017-01-25T16:57:49.062631155-06:00 container start 30eb630790d44052f26c1081d...
2017-01-25T16:57:49.164526268-06:00 container die 30eb630790d44052f26c1081dbf...
2017-01-25T16:57:49.613422740-06:00 network disconnect de1b2b40f522e69318847a...
2017-01-25T16:57:49.815845051-06:00 container destroy 30eb630790d44052f26c108...

Generates events with docker container run --rm apline echo 'Hello world'

Exercise: System commands

Work through

Cleaning up Docker resources
Inspecting Commands

in the exercise book.

Discussion

What is the origin of dangling container image layers?
What are potential pitfalls automating system cleanup, and how can we avoid them?
Questions?

Containerization fundementals conclusion: Any app, anywhere

Containers are isolated processes
Container images provide filesystem for containers
Volumes persist data

the key takehome from basic containerization is an understanding of how it lets docker deliver on its promise to enable you to run any app, anywhere.
the layered filesystems defined by Dockerfiles which in turn define images contain all the execution context a process needs to run; features of the linux kernel like kernel namespacing and control groups allow that environment to be created as a container on any host linux system, securely and without regard to whatever else is running on that machine. These tools provide the standardization and encapsulation we predicted would be of benefit in the introduction at the start of the day.
One slightly subtler point is that in none of this did we ever impose any restrictions on how many containers could be running on a given machine, or any necessary connections between the images that underlie them. This ability to mix and match frees us from correlations between processes; run your postgres database from ubuntu, your node.js web app from debian and your FORTRAN data wrangling from centos if you want - all on the same machine. Containerization’s implicit win is the ability to always use the right tool for the job.

Wrap up - Quarkus Hello-world

Exercise instructions

Goal: Build a docker image that runs a Java application
Find the fat jar hello-world-<version>-runner.jar in the zip you downloaded
Run the application with java –jar hello-world-<version>-runner.jar.
Try it out via http://localhost:8080/

Considerations:

What container image is suitable?
Do you need CMD, or ENTRYPOINT, or maybe both?
If you run two containers, what do need to take care of?

Solution

Sample Containerfile

FROM anapsix/alpine-java
LABEL MAINTAINER=thomas.herzo@gepardec.com
WORKDIR /data
EXPOSE 8080
COPY build/libs/hello-world-<version>-runner.jar hello-world-<version>-runner.jar
CMD ["-jar", "hello-world-<version>-runner.jar"]
ENTRYPOINT ["java"]

Solution commands

docker build -t hello_world .
docker run -d -p 8080:8080 hello_world

Container networking basics

Disciussion: Portable networks

Network traffic must by efinition traverse a network outside its origination container.
How can we make inter-container communication as portable and secure as containers themselves?

Lead the class to think about the need for networking abstractions, both software defined networks and DNS-resolvable container names.
Hint questions if the class is stuck:
Can we rely on a container having the same IP or mac address every time it is created, no matter what host it is created on? (obviously not, a given private IP could already be taken on a destination host, and any global public identifier like a public IP or mac address couldn’t be practically registered at container run time). Therefore, we must need some sort of networking layer that abstracts away the host network. That also might give us the opportunity to impose some security on our networks, since we control this extra networking layer.
How will service discovery work in our containerized application logic? We’d like to avoid having a lot of boilerplate that exposes the networking underlay to our application logic; Docker should provide some portable addressing mechanism. (leads to thinking about DNS).

Learning objectives

By the end of this module, trainees will be able to

Describe Docker’s container network model and its security implications
Describe the basic technologies that underwrite single host networks
Understand how Docker manipulates a host’s firewall rules to control container traffic

The container network model

Linux: Default single-host network

Linux: Default container networking

linux default container networking

Quiz: identify the sandbox, endpoint and network corresponding to the container networking model objects in this diagram.

Linux: User-defined bridges & firewalls

linux custom container networking

Exposing container ports

Containers have no public IP address by default.
Can forward host port → container port
Mapping created manually or automatically.
Port mappings visible via docker container ls or docker container port

Instructor demo: Single host networks

See the demo

Single host netowrks

in the exercise book.

Exercise: Single host networks

Work through

Introduction to Container Networking
Container Port Mapping

in the exercise book.

Container networking takeaways

Single host networks follow the container networking model:
- Sandbox: Network namespaces
- Endpoint: veth (linux)
- Network: bridge (linux)
Containers resolve each other by DNS lookup when named and attached to custom networks
Docker software defined networks are firewalled from each other by default

Introduction to container compose

Discussion: Processes vs. applications

Containers and images describe individual processes.
What will we need to describe entire applications?

Lead class to the simple answer (some sort of manifest file that describes the application, in the spirit of deploy scripts or infrastructure-as-code), as well as the more substantial answer of some way to manage a living application, where 'manage' in this context means scale, route traffic, deploy and upgrade.
Hint questions if the class is stuck:
It’s not enough just to 'describe' an application - we need to make the deployment of those applications reproducible and portable. How? (someone should think of some sort of script).
Are applications static after they’re launched? What if load changes? (leads to thinking about scaling).
After scaling an application, how do we make sure traffic gets to the new instances of our app? Re-do service discovery? Reconfigure load balancers? We’d rather have something a little more transparent.

Learning objectives

By the end of this module, trainees will be able to

Design scalable Docker services
Leverage Docker’s built in service discovery mechanism
Write a compose file describing an application

Distributed application architecture

Applications consisting of one or more containers across one or more nodes
Docker Compose facilitates multi-container design on a single node

Container services

Goal: declare and (re)configure many similar containers all at once
Goal: scale apps by adding containers seamlessly
A service defines the desired state of a group of identically configured containers
Docker provides transparent service discovery for Services

So far, we’ve declared containers one at a time with docker container run…, and we’ve seen how to network individual containers together. This all works, but doesn’t scale conveniently.
Since we’re going to start designing apps to consist of potentially many containers, we’d like to be able to create and reconfigure containers en masse.
Furthermore, we need to put some thought into how discovery will work in this paradigm; if we scale up an app by declaring more containers, how will they all find out about each other and network themselves together
To address this problem, Docker orchestration introduces the idea of services. A service defines the desired state of a collection of identically configured containers, allowing us to declare a batch of containers all at once, and reconfigure them later by updating the service definition.
Furthermore, Docker provides out-of-the-box service discovery for services, automatically providing and configuring the networking necessary for these groups of containers to interact.

Service discovery

Services are assigned a Virtual IP which spreads traffic out across the underlying container automatically.

Our application: Dockercoins

dockercoins
(DockerCoins 2016 logo courtesy of @XtlCnslt and @ndeloof. Thanks!)

It is a Dockercoin miner!
💰🐳📦🚢
with 5 services: dockercoins flow

Instructor demo: Docker-Compose

See the demo

Docker Compose

in the exercise book.

Exercise: Compose apps

Work through

Starting a Compose App
Scaling s Compose App

in the exercise book.

Container Compose takeaways

Docker Compose makes single node orchestration easy
Compose services makes scaling applications easy
Bottleneck identification important
Syntactically: docker-compose.yml + API

Wrapup Dontainer Compose - Sonarqube

Sonarqube

Exercise: Instructions

Setup a Sonarqube server that listens on port 9000
Connect it to a persistent database
Use postgresql and persist it‘s data on the host filesystem using volumes
Verify that the data is persistent (create user and delete the container)
Check that Sonarqube is really using your postgresql database
Hint: use docker-compose

Solution

version: "2"
services:
  sonarqube:
    image: sonarqube
    ports:
      - "9000:9000"
    networks:
      - sonarnet
    environment:
      - SONARQUBE_JDBC_URL=jdbc:postgresql://db:5432/sonar
    volumes:
      - sonarqube_conf:/opt/sonarqube/conf
      - sonarqube_data:/opt/sonarqube/data
      - sonarqube_extensions:/opt/sonarqube/extensions
      - sonarqube_bundled-plugins:/opt/sonarqube/lib/bundled-plugins
  db:
    image: postgres
    networks:
      - sonarnet
    environment:
      - POSTGRES_USER=sonar
      - POSTGRES_PASSWORD=sonar
    volumes:
      - postgresql:/var/lib/postgresql
      - postgresql_data:/var/lib/postgresql/datanetworks
    sonarnet:
      driver: bridge
volumes:
  sonarqube_conf:
  sonarqube_data:
  sonarqube_extensions:
  sonarqube_bundled-plugins:
  postgresql:
  postgresql_data:

Containerization Training

Please take our feedback survey

Get in touch: office@gepardec.com

https://www.gepardec.com/trainings

#WECKDENGEPARDENINDIR

Training Containerization

Gepardec who?

That’s us

How we teach

Session Logistics

Assumed knowledge and requirements

Your lab environment

Training learning objectives

Virtualization vs Containerization

What we want

Virtualization

Containerization

Rapid development

Smooth migration

Simple sclae & mainenance

Secure by default

Application density

Containerization basics

Learning objectives

Containers are processes

Linux kernel namespaces

Linux PID kernel namespace

Optional Linux isolation features

Instructor demo: Process isolation

Exercise: Container Basics

Container lifecycle

Container logs

Container basics takeaways

Further reading

Container images

Learning objectives

What are container images?

Sharing layers

The writable container layer

Images: Copy on write

Linux Containers: Union FS

Creating images

Commiting container changes

Containerfiles

Instructor demo: Creating images

Exercise: Creating images

Build cache

CMD and ENTRYPOINT

Shell vs Exec format

Exercise: Containerfiles (2/2)

COPY and ADD commands

Containerfile command roundup

Advanced Containerfile construction

The scratch container image

Multi-Stage builds (1/2)

Multi-Stage builds (2/2)

Build target

Exercise: Multi-Stage Builds

Container image construction best practices

Development: More layers

Production: Less layers

Best practices: Patching & Updates

Container Image tags

Container Image namespaces

Image tagging & namespacing

Sharing container images

Exercise: Managing container images

Container Image Creation takeaways

Further reading

Container Volumes

Learning objectives

Volume usecases

Basic volumes

Instructor demo: Volumes

Volumes in Containerfile

Volumes and security

Exercise: Volumes usecases

Container volumes takeaways

Further reading

Docker system commands

Learning objectives

Cleanup commands

Inspect the system

System events

Exercise: System commands