Introduction to Containers

.debug[
```
 M slides/Docker-1hour.yml
 M slides/containers/links.md
 M slides/intro-fullday.yml.html
 M slides/intro-selfpaced.yml.html
 M slides/intro-twodays.yml.html
 M slides/kadm-fullday.yml.html
 M slides/kadm-twodays.yml.html
 M slides/kube-adv.yml.html
 M slides/kube-fullday.yml.html
 M slides/kube-halfday.yml.html
 M slides/kube-selfpaced.yml.html
 M slides/kube-twodays.yml.html
 M slides/slides.zip
 M slides/swarm-fullday.yml.html
 M slides/swarm-halfday.yml.html
 M slides/swarm-selfpaced.yml.html
 M slides/swarm-video.yml.html
?? slides/Docker-1hour.yml.html
?? slides/shared/about-slides-old.md

```

These slides have been built from commit: 55180b0

[shared/title.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/shared/title.md)]
---

Introduction to Containers

.footnote[
**Slides[:](https://www.youtube.com/watch?v=h16zyxiwDLY) https://ryaxtech.github.io/kube.training/**
]

<!--
WiFi: **Something** 
Password: **Something**

**Be kind to the WiFi!** 
*Use the 5G network.*
*Don't use your hotspot.* 
*Don't stream videos or download big files during the workshop* 
*Thank you!*
-->

.debug[[shared/title.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/shared/title.md)]
---
## A brief introduction

- These slides are adapted and based upon the materials maintained by [Jérôme Petazzoni](https://twitter.com/jpetazzo) and [multiple contributors](https://github.com/jpetazzo/container.training/graphs/contributors) which reside on this link https://github.com/jpetazzo/container.training

- You can also follow along on your own, at your own pace

- We included as much information as possible in these slides

- We recommend having a mentor to help you ...

- ... Or be comfortable spending some time reading the Docker
 [documentation](https://docs.docker.com/) ...

- ... And looking for answers in the [Docker forums](forums.docker.com),
  [StackOverflow](http://stackoverflow.com/questions/tagged/docker),
  and other outlets

.debug[[containers/intro.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/intro.md)]
---

.debug[[containers/intro.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/intro.md)]
---

## Part 1

- [Docker 30,000ft overview](#toc-docker-ft-overview)

- [History of containers ... and Docker](#toc-history-of-containers--and-docker)

- [Installing Docker](#toc-installing-docker)

- [Our first containers](#toc-our-first-containers)

- [Background containers](#toc-background-containers)

- [Getting inside a container](#toc-getting-inside-a-container)

- [Understanding Docker images](#toc-understanding-docker-images)

## Part 2

- [Building Docker images with a Dockerfile](#toc-building-docker-images-with-a-dockerfile)
- [`CMD` and `ENTRYPOINT`](#toc-cmd-and-entrypoint)
- [Copying files during the build](#toc-copying-files-during-the-build)
- [Reducing image size](#toc-reducing-image-size)
- [Multi-stage builds](#toc-multi-stage-builds)
- [Publishing images to the Docker Hub](#toc-publishing-images-to-the-docker-hub)
- [Tips for efficient Dockerfiles](#toc-tips-for-efficient-dockerfiles)
- [Dockerfile examples](#toc-dockerfile-examples)
- [Compose for development stacks](#toc-compose-for-development-stacks)
- [Links and resources](#toc-links-and-resources)

.debug[[shared/toc.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/shared/toc.md)]
---

.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/Container-Ship-Freighter-Navigation-Elbe-Romance-1782991.jpg)]

---

Docker 30,000ft overview

.nav[
[Previous part](#toc-)
|
[Back to table of contents](#toc-part-1)
|
[Next part](#toc-history-of-containers--and-docker)
]

---
# Docker 30,000ft overview

In this lesson, we will learn about:

* Why containers (non-technical elevator pitch)

* Why containers (technical elevator pitch)

* How Docker helps us to build, ship, and run

* The history of containers

We won't actually run Docker or containers in this chapter (yet!).

Don't worry, we will get to that fast enough!

.debug[[containers/Docker_Overview.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Docker_Overview.md)]
---

## Elevator pitch

### (for your manager, your boss...)

.debug[[containers/Docker_Overview.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Docker_Overview.md)]
---

## OK... Why the buzz around containers?

* The software industry has changed

* Before:
  * monolithic applications
  * long development cycles
  * single environment
  * slowly scaling up

* Now:
  * decoupled services
  * fast, iterative improvements
  * multiple environments
  * quickly scaling out

.debug[[containers/Docker_Overview.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Docker_Overview.md)]
---

## Deployment becomes very complex

* Many different stacks:
  * languages
  * frameworks
  * databases

* Many different targets:
  * individual development environments
  * pre-production, QA, staging...
  * production: on prem, cloud, hybrid

.debug[[containers/Docker_Overview.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Docker_Overview.md)]
---

## The deployment problem

![problem](images/shipping-software-problem.png)

.debug[[containers/Docker_Overview.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Docker_Overview.md)]
---

## The matrix from hell

![matrix](images/shipping-matrix-from-hell.png)

.debug[[containers/Docker_Overview.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Docker_Overview.md)]
---

## The parallel with the shipping industry

![history](images/shipping-industry-problem.png)

.debug[[containers/Docker_Overview.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Docker_Overview.md)]
---

## Intermodal shipping containers

![shipping](images/shipping-industry-solution.png)

.debug[[containers/Docker_Overview.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Docker_Overview.md)]
---

## A new shipping ecosystem

![shipeco](images/shipping-indsutry-results.png)

.debug[[containers/Docker_Overview.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Docker_Overview.md)]
---

## A shipping container system for applications

![shipapp](images/shipping-software-solution.png)

.debug[[containers/Docker_Overview.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Docker_Overview.md)]
---

## Eliminate the matrix from hell

![elimatrix](images/shipping-matrix-solved.png)

.debug[[containers/Docker_Overview.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Docker_Overview.md)]
---

## Results

* [Dev-to-prod reduced from 9 months to 15 minutes (ING)](
  https://www.docker.com/sites/default/files/CS_ING_01.25.2015_1.pdf)

* [Continuous integration job time reduced by more than 60% (BBC)](
  https://www.docker.com/sites/default/files/CS_BBCNews_01.25.2015_1.pdf)

* [Deploy 100 times a day instead of once a week (GILT)](
  https://www.docker.com/sites/default/files/CS_Gilt%20Groupe_03.18.2015_0.pdf)

* [70% infrastructure consolidation (MetLife)](
  https://www.docker.com/customers/metlife-transforms-customer-experience-legacy-and-microservices-mashup)

* [60% infrastructure consolidation (Intesa Sanpaolo)](
  https://blog.docker.com/2017/11/intesa-sanpaolo-builds-resilient-foundation-banking-docker-enterprise-edition/)

* [14x application density; 60% of legacy datacenter migrated in 4 months (GE Appliances)](
  https://www.docker.com/customers/ge-uses-docker-enable-self-service-their-developers)

* etc.

.debug[[containers/Docker_Overview.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Docker_Overview.md)]
---

## Elevator pitch

### (for your fellow devs and ops)

.debug[[containers/Docker_Overview.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Docker_Overview.md)]
---

## Escape dependency hell

1. Write installation instructions into an `INSTALL.txt` file

2. Using this file, write an `install.sh` script that works *for you*

3. Turn this file into a `Dockerfile`, test it on your machine

4. If the Dockerfile builds on your machine, it will build *anywhere*

5. Rejoice as you escape dependency hell and "works on my machine"

Never again "worked in dev - ops problem now!"

.debug[[containers/Docker_Overview.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Docker_Overview.md)]
---

## On-board developers and contributors rapidly

1. Write Dockerfiles for your application components

2. Use pre-made images from the Docker Hub (mysql, redis...)

3. Describe your stack with a Compose file

4. On-board somebody with two commands:

```bash
git clone ...
docker-compose up
```

With this, you can create development, integration, QA environments in minutes!

.debug[[containers/Docker_Overview.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Docker_Overview.md)]
---

## Implement reliable CI easily

1. Build test environment with a Dockerfile or Compose file

2. For each test run, stage up a new container or stack

3. Each run is now in a clean environment

4. No pollution from previous tests

Way faster and cheaper than creating VMs each time!

.debug[[containers/Docker_Overview.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Docker_Overview.md)]
---

## Use container images as build artefacts

1. Build your app from Dockerfiles

2. Store the resulting images in a registry

3. Keep them forever (or as long as necessary)

4. Test those images in QA, CI, integration...

5. Run the same images in production

6. Something goes wrong? Rollback to previous image

7. Investigating old regression? Old image has your back!

Images contain all the libraries, dependencies, etc. needed to run the app.

.debug[[containers/Docker_Overview.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Docker_Overview.md)]
---

## Decouple "plumbing" from application logic

1. Write your code to connect to named services ("db", "api"...)

2. Use Compose to start your stack

3. Docker will setup per-container DNS resolver for those names

4. You can now scale, add load balancers, replication ... without changing your code

Note: this is not covered in this intro level workshop!

.debug[[containers/Docker_Overview.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Docker_Overview.md)]
---

## What did Docker bring to the table?

### Docker before/after

.debug[[containers/Docker_Overview.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Docker_Overview.md)]
---

## Formats and APIs, before Docker

* No standardized exchange format.
 (No, a rootfs tarball is *not* a format!)

* Containers are hard to use for developers.
 (Where's the equivalent of `docker run debian`?)

* As a result, they are *hidden* from the end users.

* No re-usable components, APIs, tools.
 (At best: VM abstractions, e.g. libvirt.)

Analogy:

* Shipping containers are not just steel boxes.
* They are steel boxes that are a standard size, with the same hooks and holes.

.debug[[containers/Docker_Overview.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Docker_Overview.md)]
---

## Formats and APIs, after Docker

* Standardize the container format, because containers were not portable.

* Make containers easy to use for developers.

* Emphasis on re-usable components, APIs, ecosystem of standard tools.

* Improvement over ad-hoc, in-house, specific tools.

.debug[[containers/Docker_Overview.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Docker_Overview.md)]
---

## Shipping, before Docker

* Ship packages: deb, rpm, gem, jar, homebrew...

* Dependency hell.

* "Works on my machine."

* Base deployment often done from scratch (debootstrap...) and unreliable.

.debug[[containers/Docker_Overview.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Docker_Overview.md)]
---

## Shipping, after Docker

* Ship container images with all their dependencies.

* Images are bigger, but they are broken down into layers.

* Only ship layers that have changed.

* Save disk, network, memory usage.

.debug[[containers/Docker_Overview.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Docker_Overview.md)]
---

## Example

Layers:

* CentOS
* JRE
* Tomcat
* Dependencies
* Application JAR
* Configuration

.debug[[containers/Docker_Overview.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Docker_Overview.md)]
---

## Devs vs Ops, before Docker

* Drop a tarball (or a commit hash) with instructions.

* Dev environment very different from production.

* Ops don't always have a dev environment themselves ...

* ... and when they do, it can differ from the devs'.

* Ops have to sort out differences and make it work ...

* ... or bounce it back to devs.

* Shipping code causes frictions and delays.

.debug[[containers/Docker_Overview.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Docker_Overview.md)]
---

## Devs vs Ops, after Docker

* Drop a container image or a Compose file.

* Ops can always run that container image.

* Ops can always run that Compose file.

* Ops still have to adapt to prod environment,
  but at least they have a reference point.

* Ops have tools allowing to use the same image
  in dev and prod.

* Devs can be empowered to make releases themselves
  more easily.

.debug[[containers/Docker_Overview.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Docker_Overview.md)]
---

.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/ShippingContainerSFBay.jpg)]

---

History of containers ... and Docker

.nav[
[Previous part](#toc-docker-ft-overview)
|
[Back to table of contents](#toc-part-1)
|
[Next part](#toc-installing-docker)
]

---
# History of containers ... and Docker

.debug[[containers/Docker_History.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Docker_History.md)]
---

## First experimentations

* [IBM VM/370 (1972)](https://en.wikipedia.org/wiki/VM_%28operating_system%29)

* [Linux VServers (2001)](http://www.solucorp.qc.ca/changes.hc?projet=vserver)

* [Solaris Containers (2004)](https://en.wikipedia.org/wiki/Solaris_Containers)

* [FreeBSD jails (1999-2000)](https://www.freebsd.org/cgi/man.cgi?query=jail&sektion=8&manpath=FreeBSD+4.0-RELEASE)

Containers have been around for a *very long time* indeed.

(See [this excellent blog post by Serge Hallyn](https://s3hh.wordpress.com/2018/03/22/history-of-containers/) for more historic details.)

.debug[[containers/Docker_History.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Docker_History.md)]
---

## The VPS age (until 2007-2008)

![lightcont](images/containers-as-lightweight-vms.png)

.debug[[containers/Docker_History.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Docker_History.md)]
---

## Containers = cheaper than VMs

* Users: hosting providers.

* Highly specialized audience with strong ops culture.

.debug[[containers/Docker_History.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Docker_History.md)]
---

.debug[[containers/Docker_History.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Docker_History.md)]
---

.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/aerial-view-of-containers.jpg)]

---

Installing Docker

.nav[
[Previous part](#toc-history-of-containers--and-docker)
|
[Back to table of contents](#toc-part-1)
|
[Next part](#toc-our-first-containers)
]

---

# Installing Docker

![install](images/title-installing-docker.jpg)

.debug[[containers/Installing_Docker.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Installing_Docker.md)]
---

## Installing Docker on Linux

* The recommended method is to install the packages supplied by Docker Inc :

- add Docker Inc.'s package repositories to your system configuration

- install the Docker Engine

* Detailed installation instructions (distro by distro) are available on:

https://docs.docker.com/engine/installation/

* You can also install from binaries (if your distro is not supported):

https://docs.docker.com/engine/installation/linux/docker-ce/binaries/

* To quickly setup a dev environment, Docker provides a convenience install script:

```bash
  curl -fsSL get.docker.com | sh
  ```

.debug[[containers/Installing_Docker.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Installing_Docker.md)]
---

## Docker Inc. packages vs distribution packages

* Docker Inc. releases new versions monthly (edge) and quarterly (stable)

* Releases are immediately available on Docker Inc.'s package repositories

* Linux distros don't always update to the latest Docker version

(Sometimes, updating would break their guidelines for major/minor upgrades)

* Sometimes, some distros have carried packages with custom patches

* Sometimes, these patches added critical security bugs ☹

* Installing through Docker Inc.'s repositories is a bit of extra work …

… but it is generally worth it!

.debug[[containers/Installing_Docker.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Installing_Docker.md)]
---

## Docker Desktop internals

* Leverages the host OS virtualization subsystem

(e.g. the [Hypervisor API](https://developer.apple.com/documentation/hypervisor) on macOS)

* Under the hood, runs a tiny VM

(transparent to our daily use)

* Accesses network resources like normal applications

(and therefore, plays better with enterprise VPNs and firewalls)

* Supports filesystem sharing through volumes

(we'll talk about this later)

.debug[[containers/Installing_Docker.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Installing_Docker.md)]
---

## Important PSA about security

* If you have access to the Docker control socket, you can take over the machine

(Because you can run containers that will access the machine's resources)

* Therefore, on Linux machines, the `docker` user is equivalent to `root`

* You should restrict access to it like you would protect `root`

* By default, the Docker control socket belongs to the `docker` group

* You can add trusted users to the `docker` group

* Otherwise, you will have to prefix every `docker` command with `sudo`, e.g.:

```bash
  sudo docker version
  ```

.debug[[containers/Installing_Docker.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Installing_Docker.md)]
---

.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/blue-containers.jpg)]

---

Our first containers

.nav[
[Previous part](#toc-installing-docker)
|
[Back to table of contents](#toc-part-1)
|
[Next part](#toc-background-containers)
]

---

# Our first containers

![Colorful plastic tubs](images/title-our-first-containers.jpg)

.debug[[containers/First_Containers.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/First_Containers.md)]
---

## Objectives

At the end of this lesson, you will have:

* Seen Docker in action.

* Started your first containers.

.debug[[containers/First_Containers.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/First_Containers.md)]
---

## Hello World

In your Docker environment, just run the following command:

```bash
$ docker run busybox echo hello world
hello world
```

(If your Docker install is brand new, you will also see a few extra lines,
corresponding to the download of the `busybox` image.)

.debug[[containers/First_Containers.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/First_Containers.md)]
---

## That was our first container!

* We used one of the smallest, simplest images available: `busybox`.

* `busybox` is typically used in embedded systems (phones, routers...)

* We ran a single process and echo'ed `hello world`.

.debug[[containers/First_Containers.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/First_Containers.md)]
---

## A more useful container

Let's run a more exciting container:

```bash
$ docker run -it ubuntu
root@04c0bb0a6c07:/#
```

* This is a brand new container.

* It runs a bare-bones, no-frills `ubuntu` system.

* `-it` is shorthand for `-i -t`.

* `-i` tells Docker to connect us to the container's stdin.

* `-t` tells Docker that we want a pseudo-terminal.

.debug[[containers/First_Containers.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/First_Containers.md)]
---

## Do something in our container

Try to run `figlet` in our container.

```bash
root@04c0bb0a6c07:/# figlet hello
bash: figlet: command not found
```

Alright, we need to install it.

.debug[[containers/First_Containers.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/First_Containers.md)]
---

## Install a package in our container

We want `figlet`, so let's install it:

```bash
root@04c0bb0a6c07:/# apt-get update
...
Fetched 1514 kB in 14s (103 kB/s)
Reading package lists... Done
root@04c0bb0a6c07:/# apt-get install figlet
Reading package lists... Done
...
```

One minute later, `figlet` is installed!

.debug[[containers/First_Containers.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/First_Containers.md)]
---

## Try to run our freshly installed program

The `figlet` program takes a message as parameter.

```bash
root@04c0bb0a6c07:/# figlet hello
 _          _ _       
| |__   ___| | | ___  
| '_ \ / _ \ | |/ _ \ 
| | | |  __/ | | (_) |
|_| |_|\___|_|_|\___/ 
```

Beautiful! 😍

.debug[[containers/First_Containers.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/First_Containers.md)]
---

## Counting packages in the container

Let's check how many packages are installed there.

```bash
root@04c0bb0a6c07:/# dpkg -l | wc -l
97
```

* `dpkg -l` lists the packages installed in our container

* `wc -l` counts them

How many packages do we have on our host?

.debug[[containers/First_Containers.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/First_Containers.md)]
---

## Counting packages on the host

Exit the container by logging out of the shell, like you would usually do.

(E.g. with `^D` or `exit`)

```bash
root@04c0bb0a6c07:/# exit
```

Now, try to:

* run `dpkg -l | wc -l`. How many packages are installed?

* run `figlet`. Does that work?

.debug[[containers/First_Containers.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/First_Containers.md)]
---

## Comparing the container and the host

Exit the container by logging out of the shell, with `^D` or `exit`.

Now try to run `figlet`. Does that work?

(It shouldn't; except if, by coincidence, you are running on a machine where figlet was installed before.)

.debug[[containers/First_Containers.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/First_Containers.md)]
---

## Host and containers are independent things

* We ran an `ubuntu` container on an Linux/Windows/macOS host.

* They have different, independent packages.

* Installing something on the host doesn't expose it to the container.

* And vice-versa.

* Even if both the host and the container have the same Linux distro!

* We can run *any container* on *any host*.

(One exception: Windows containers can only run on Windows hosts; at least for now.)

.debug[[containers/First_Containers.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/First_Containers.md)]
---

## Where's our container?

* Our container is now in a *stopped* state.

* It still exists on disk, but all compute resources have been freed up.

* We will see later how to get back to that container.

.debug[[containers/First_Containers.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/First_Containers.md)]
---

## Starting another container

What if we start a new container, and try to run `figlet` again?
 
```bash
$ docker run -it ubuntu
root@b13c164401fb:/# figlet
bash: figlet: command not found
```

* We started a *brand new container*.

* The basic Ubuntu image was used, and `figlet` is not here.

.debug[[containers/First_Containers.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/First_Containers.md)]
---

## Where's my container?

* Can we reuse that container that we took time to customize?

*We can, but that's not the default workflow with Docker.*

* What's the default workflow, then?

*Always start with a fresh container.*
 
 *If we need something installed in our container, build a custom image.*

* That seems complicated!

*We'll see that it's actually pretty easy!*

* And what's the point?

*This puts a strong emphasis on automation and repeatability. Let's see why ...*

.debug[[containers/First_Containers.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/First_Containers.md)]
---

## Pets vs. Cattle

* In the "pets vs. cattle" metaphor, there are two kinds of servers.

* Pets:

* have distinctive names and unique configurations

* when they have an outage, we do everything we can to fix them

* Cattle:

* have generic names (e.g. with numbers) and generic configuration

* configuration is enforced by configuration management, golden images ...

* when they have an outage, we can replace them immediately with a new server

* What's the connection with Docker and containers?

.debug[[containers/First_Containers.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/First_Containers.md)]
---

## Local development environments

* When we use local VMs (with e.g. VirtualBox or VMware), our workflow looks like this:

* create VM from base template (Ubuntu, CentOS...)

* install packages, set up environment

* work on project

* when done, shut down VM

* next time we need to work on project, restart VM as we left it

* if we need to tweak the environment, we do it live

* Over time, the VM configuration evolves, diverges.

* We don't have a clean, reliable, deterministic way to provision that environment.

.debug[[containers/First_Containers.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/First_Containers.md)]
---

## Local development with Docker

* With Docker, the workflow looks like this:

* create container image with our dev environment

* run container with that image

* work on project

* when done, shut down container

* next time we need to work on project, start a new container

* if we need to tweak the environment, we create a new image

* We have a clear definition of our environment, and can share it reliably with others.

* Let's see in the next chapters how to bake a custom image with `figlet`!

???

:EN:- Running our first container
:FR:- Lancer nos premiers conteneurs

.debug[[containers/First_Containers.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/First_Containers.md)]
---

.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/chinook-helicopter-container.jpg)]

---

Background containers

.nav[
[Previous part](#toc-our-first-containers)
|
[Back to table of contents](#toc-part-1)
|
[Next part](#toc-getting-inside-a-container)
]

---

# Background containers

![Background containers](images/title-background-containers.jpg)

.debug[[containers/Background_Containers.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Background_Containers.md)]
---

## Objectives

Our first containers were *interactive*.

We will now see how to:

* Run a non-interactive container.
* Run a container in the background.
* List running containers.
* Check the logs of a container.
* Stop a container.
* List stopped containers.

.debug[[containers/Background_Containers.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Background_Containers.md)]
---

## A non-interactive container

We will run a small custom container.

This container just displays the time every second.

```bash
$ docker run jpetazzo/clock
Fri Feb 20 00:28:53 UTC 2015
Fri Feb 20 00:28:54 UTC 2015
Fri Feb 20 00:28:55 UTC 2015
...
```

* This container will run forever.
* To stop it, press `^C`.
* Docker has automatically downloaded the image `jpetazzo/clock`.
* This image is a user image, created by `jpetazzo`.
* We will hear more about user images (and other types of images) later.

.debug[[containers/Background_Containers.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Background_Containers.md)]
---

## When `^C` doesn't work...

Sometimes, `^C` won't be enough.

Why? And how can we stop the container in that case?

.debug[[containers/Background_Containers.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Background_Containers.md)]
---

## What happens when we hit `^C`

`SIGINT` gets sent to the container, which means:

- `SIGINT` gets sent to PID 1 (default case)

- `SIGINT` gets sent to *foreground processes* when running with `-ti`

But there is a special case for PID 1: it ignores all signals!

- except `SIGKILL` and `SIGSTOP`

- except signals handled explicitly

TL,DR: there are many circumstances when `^C` won't stop the container.

.debug[[containers/Background_Containers.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Background_Containers.md)]
---

## Why is PID 1 special?

- PID 1 has some extra responsibilities:

- it starts (directly or indirectly) every other process

- when a process exits, its processes are "reparented" under PID 1

- When PID 1 exits, everything stops:

- on a "regular" machine, it causes a kernel panic

- in a container, it kills all the processes

- We don't want PID 1 to stop accidentally

- That's why it has these extra protections

.debug[[containers/Background_Containers.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Background_Containers.md)]
---

## How to stop these containers, then?

- Start another terminal and forget about them

(for now!)

- We'll shortly learn about `docker kill`

.debug[[containers/Background_Containers.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Background_Containers.md)]
---

## Run a container in the background

Containers can be started in the background, with the `-d` flag (daemon mode):

```bash
$ docker run -d jpetazzo/clock
47d677dcfba4277c6cc68fcaa51f932b544cab1a187c853b7d0caf4e8debe5ad
```

* We don't see the output of the container.
* But don't worry: Docker collects that output and logs it!
* Docker gives us the ID of the container.

.debug[[containers/Background_Containers.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Background_Containers.md)]
---

## List running containers

How can we check that our container is still running?

With `docker ps`, just like the UNIX `ps` command, lists running processes.

```bash
$ docker ps
CONTAINER ID  IMAGE           ...  CREATED        STATUS        ...
47d677dcfba4  jpetazzo/clock  ...  2 minutes ago  Up 2 minutes  ...
```

Docker tells us:

* The (truncated) ID of our container.
* The image used to start the container.
* That our container has been running (`Up`) for a couple of minutes.
* Other information (COMMAND, PORTS, NAMES) that we will explain later.

.debug[[containers/Background_Containers.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Background_Containers.md)]
---

## Starting more containers

Let's start two more containers.

```bash
$ docker run -d jpetazzo/clock
57ad9bdfc06bb4407c47220cf59ce21585dce9a1298d7a67488359aeaea8ae2a
```

```bash
$ docker run -d jpetazzo/clock
068cc994ffd0190bbe025ba74e4c0771a5d8f14734af772ddee8dc1aaf20567d
```

Check that `docker ps` correctly reports all 3 containers.

.debug[[containers/Background_Containers.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Background_Containers.md)]
---

## Viewing only the last container started

When many containers are already running, it can be useful to
see only the last container that was started.

This can be achieved with the `-l` ("Last") flag:

```bash
$ docker ps -l
CONTAINER ID  IMAGE           ...  CREATED        STATUS        ...
068cc994ffd0  jpetazzo/clock  ...  2 minutes ago  Up 2 minutes  ...
```

.debug[[containers/Background_Containers.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Background_Containers.md)]
---

## View only the IDs of the containers

Many Docker commands will work on container IDs: `docker stop`, `docker rm`...

If we want to list only the IDs of our containers (without the other columns
or the header line),
we can use the `-q` ("Quiet", "Quick") flag:

```bash
$ docker ps -q
068cc994ffd0
57ad9bdfc06b
47d677dcfba4
```

.debug[[containers/Background_Containers.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Background_Containers.md)]
---

## Combining flags

We can combine `-l` and `-q` to see only the ID of the last container started:

```bash
$ docker ps -lq
068cc994ffd0
```

At a first glance, it looks like this would be particularly useful in scripts.

However, if we want to start a container and get its ID in a reliable way,
it is better to use `docker run -d`, which we will cover in a bit.

(Using `docker ps -lq` is prone to race conditions: what happens if someone
else, or another program or script, starts another container just before
we run `docker ps -lq`?)

.debug[[containers/Background_Containers.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Background_Containers.md)]
---

## View the logs of a container

We told you that Docker was logging the container output.

Let's see that now.

```bash
$ docker logs 068
Fri Feb 20 00:39:52 UTC 2015
Fri Feb 20 00:39:53 UTC 2015
...
```

* We specified a *prefix* of the full container ID.
* You can, of course, specify the full ID.
* The `logs` command will output the *entire* logs of the container.
 (Sometimes, that will be too much. Let's see how to address that.)

.debug[[containers/Background_Containers.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Background_Containers.md)]
---

## View only the tail of the logs

To avoid being spammed with eleventy pages of output,
we can use the `--tail` option:

```bash
$ docker logs --tail 3 068
Fri Feb 20 00:55:35 UTC 2015
Fri Feb 20 00:55:36 UTC 2015
Fri Feb 20 00:55:37 UTC 2015
```

* The parameter is the number of lines that we want to see.

.debug[[containers/Background_Containers.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Background_Containers.md)]
---

## Follow the logs in real time

Just like with the standard UNIX command `tail -f`, we can
follow the logs of our container:

```bash
$ docker logs --tail 1 --follow 068
Fri Feb 20 00:57:12 UTC 2015
Fri Feb 20 00:57:13 UTC 2015
^C
```

* This will display the last line in the log file.
* Then, it will continue to display the logs in real time.
* Use `^C` to exit.

.debug[[containers/Background_Containers.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Background_Containers.md)]
---

## Stop our container

There are two ways we can terminate our detached container.

* Killing it using the `docker kill` command.
* Stopping it using the `docker stop` command.

The first one stops the container immediately, by using the
`KILL` signal.

The second one is more graceful. It sends a `TERM` signal,
and after 10 seconds, if the container has not stopped, it
sends `KILL.`

Reminder: the `KILL` signal cannot be intercepted, and will
forcibly terminate the container.

.debug[[containers/Background_Containers.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Background_Containers.md)]
---

## Stopping our containers

Let's stop one of those containers:

```bash
$ docker stop 47d6
47d6
```

This will take 10 seconds:

* Docker sends the TERM signal;
* the container doesn't react to this signal
  (it's a simple Shell script with no special
  signal handling);
* 10 seconds later, since the container is still
  running, Docker sends the KILL signal;
* this terminates the container.

.debug[[containers/Background_Containers.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Background_Containers.md)]
---

## Killing the remaining containers

Let's be less patient with the two other containers:

```bash
$ docker kill 068 57ad
068
57ad
```

The `stop` and `kill` commands can take multiple container IDs.

Those containers will be terminated immediately (without
the 10-second delay).

Let's check that our containers don't show up anymore:

```bash
$ docker ps
```

.debug[[containers/Background_Containers.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Background_Containers.md)]
---

## List stopped containers

We can also see stopped containers, with the `-a` (`--all`) option.

```bash
$ docker ps -a
CONTAINER ID  IMAGE           ...  CREATED      STATUS
068cc994ffd0  jpetazzo/clock  ...  21 min. ago  Exited (137) 3 min. ago
57ad9bdfc06b  jpetazzo/clock  ...  21 min. ago  Exited (137) 3 min. ago
47d677dcfba4  jpetazzo/clock  ...  23 min. ago  Exited (137) 3 min. ago
5c1dfd4d81f1  jpetazzo/clock  ...  40 min. ago  Exited (0) 40 min. ago
b13c164401fb  ubuntu          ...  55 min. ago  Exited (130) 53 min. ago
```

???

:EN:- Foreground and background containers
:FR:- Exécution interactive ou en arrière-plan

.debug[[containers/Background_Containers.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Background_Containers.md)]
---

.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/container-cranes.jpg)]

---

Getting inside a container

.nav[
[Previous part](#toc-background-containers)
|
[Back to table of contents](#toc-part-1)
|
[Next part](#toc-understanding-docker-images)
]

---

# Getting inside a container

![Person standing inside a container](images/getting-inside.png)

.debug[[containers/Getting_Inside.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Getting_Inside.md)]
---

## Objectives

On a traditional server or VM, we sometimes need to:

* log into the machine (with SSH or on the console),

* analyze the disks (by removing them or rebooting with a rescue system).

In this chapter, we will see how to do that with containers.

.debug[[containers/Getting_Inside.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Getting_Inside.md)]
---

## Getting a shell

Every once in a while, we want to log into a machine.

In an perfect world, this shouldn't be necessary.

* You need to install or update packages (and their configuration)?

Use configuration management. (e.g. Ansible, Chef, Puppet, Salt...)

* You need to view logs and metrics?

Collect and access them through a centralized platform.

In the real world, though ... we often need shell access!

.debug[[containers/Getting_Inside.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Getting_Inside.md)]
---

## Not getting a shell

Even without a perfect deployment system, we can do many operations without getting a shell.

* Installing packages can (and should) be done in the container image.

* Configuration can be done at the image level, or when the container starts.

* Dynamic configuration can be stored in a volume (shared with another container).

* Logs written to stdout are automatically collected by the Docker Engine.

* Other logs can be written to a shared volume.

* Process information and metrics are visible from the host.

_Let's save logging, volumes ... for later, but let's have a look at process information!_

.debug[[containers/Getting_Inside.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Getting_Inside.md)]
---

## Viewing container processes from the host

If you run Docker on Linux, container processes are visible on the host.

```bash
$ ps faux | less
```

* Scroll around the output of this command.

* You should see the `jpetazzo/clock` container.

* A containerized process is just like any other process on the host.

* We can use tools like `lsof`, `strace`, `gdb` ... To analyze them.

.debug[[containers/Getting_Inside.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Getting_Inside.md)]
---

## What's the difference between a container process and a host process?

* Each process (containerized or not) belongs to *namespaces* and *cgroups*.

* The namespaces and cgroups determine what a process can "see" and "do".

* Analogy: each process (containerized or not) runs with a specific UID (user ID).

* UID=0 is root, and has elevated privileges. Other UIDs are normal users.

_We will give more details about namespaces and cgroups later._

.debug[[containers/Getting_Inside.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Getting_Inside.md)]
---

## Getting a shell in a running container

* Sometimes, we need to get a shell anyway.

* We _could_ run some SSH server in the container ...

* But it is easier to use `docker exec`.

```bash
$ docker exec -ti ticktock sh
```

* This creates a new process (running `sh`) _inside_ the container.

* This can also be done "manually" with the tool `nsenter`.

.debug[[containers/Getting_Inside.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Getting_Inside.md)]
---

## Caveats

* The tool that you want to run needs to exist in the container.

* Some tools (like `ip netns exec`) let you attach to _one_ namespace at a time.

(This lets you e.g. setup network interfaces, even if you don't have `ifconfig` or `ip` in the container.)

* Most importantly: the container needs to be running.

* What if the container is stopped or crashed?

.debug[[containers/Getting_Inside.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Getting_Inside.md)]
---

## Getting a shell in a stopped container

* A stopped container is only _storage_ (like a disk drive).

* We cannot SSH into a disk drive or USB stick!

* We need to connect the disk to a running machine.

* How does that translate into the container world?

.debug[[containers/Getting_Inside.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Getting_Inside.md)]
---

## Analyzing a stopped container

As an exercise, we are going to try to find out what's wrong with `jpetazzo/crashtest`.

```bash
docker run jpetazzo/crashtest
```

The container starts, but then stops immediately, without any output.

What would MacGyver™ do?

First, let's check the status of that container.

```bash
docker ps -l
```

.debug[[containers/Getting_Inside.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Getting_Inside.md)]
---

## Viewing filesystem changes

* We can use `docker diff` to see files that were added / changed / removed.

```bash
docker diff <container_id>
```

* The container ID was shown by `docker ps -l`.

* We can also see it with `docker ps -lq`.

* The output of `docker diff` shows some interesting log files!

.debug[[containers/Getting_Inside.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Getting_Inside.md)]
---

## Accessing files

* We can extract files with `docker cp`.

```bash
docker cp <container_id>:/var/log/nginx/error.log .
```

* Then we can look at that log file.

```bash
cat error.log
```

(The directory `/run/nginx` doesn't exist.)

.debug[[containers/Getting_Inside.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Getting_Inside.md)]
---

## Exploring a crashed container

* We can restart a container with `docker start` ...

* ... But it will probably crash again immediately!

* We cannot specify a different program to run with `docker start`

* But we can create a new image from the crashed container

```bash
docker commit <container_id> debugimage
```

* Then we can run a new container from that image, with a custom entrypoint

```bash
docker run -ti --entrypoint sh debugimage
```

.debug[[containers/Getting_Inside.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Getting_Inside.md)]
---

## Obtaining a complete dump

* We can also dump the entire filesystem of a container.

* This is done with `docker export`.

* It generates a tar archive.

```bash
docker export <container_id> | tar tv
```

This will give a detailed listing of the content of the container.

???

:EN:- Troubleshooting and getting inside a container
:FR:- Inspecter un conteneur en détail, en *live* ou *post-mortem*

.debug[[containers/Getting_Inside.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Getting_Inside.md)]
---

.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/container-housing.jpg)]

---

Understanding Docker images

.nav[
[Previous part](#toc-getting-inside-a-container)
|
[Back to table of contents](#toc-part-1)
|
[Next part](#toc-building-docker-images-with-a-dockerfile)
]

---

# Understanding Docker images

![image](images/title-understanding-docker-images.png)

.debug[[containers/Initial_Images.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Initial_Images.md)]
---

## Objectives

In this section, we will explain:

* What is an image.

* What is a layer.

* The various image namespaces.

* How to search and download images.

* Image tags and when to use them.

.debug[[containers/Initial_Images.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Initial_Images.md)]
---

## What is an image?

* Image = files + metadata

* These files form the root filesystem of our container.

* The metadata can indicate a number of things, e.g.:

* the author of the image
  * the command to execute in the container when starting it
  * environment variables to be set
  * etc.

* Images are made of *layers*, conceptually stacked on top of each other.

* Each layer can add, change, and remove files and/or metadata.

* Images can share layers to optimize disk usage, transfer times, and memory use.

.debug[[containers/Initial_Images.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Initial_Images.md)]
---

## Example for a Java webapp

Each of the following items will correspond to one layer:

* CentOS base layer
* Packages and configuration files added by our local IT
* JRE
* Tomcat
* Our application's dependencies
* Our application code and assets
* Our application configuration

(Note: app config is generally added by orchestration facilities.)

.debug[[containers/Initial_Images.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Initial_Images.md)]
---

## The read-write layer

![layers](images/container-layers.jpg)

.debug[[containers/Initial_Images.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Initial_Images.md)]
---

## Differences between containers and images

* An image is a read-only filesystem.

* A container is an encapsulated set of processes,

running in a read-write copy of that filesystem.

* To optimize container boot time, *copy-on-write* is used
  instead of regular copy.

* `docker run` starts a container from a given image.

.debug[[containers/Initial_Images.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Initial_Images.md)]
---

## Multiple containers sharing the same image

![layers](images/sharing-layers.jpg)

.debug[[containers/Initial_Images.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Initial_Images.md)]
---

## Comparison with object-oriented programming

* Images are conceptually similar to *classes*.

* Layers are conceptually similar to *inheritance*.

* Containers are conceptually similar to *instances*.

.debug[[containers/Initial_Images.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Initial_Images.md)]
---

## Wait a minute...

If an image is read-only, how do we change it?

* We don't.

* We create a new container from that image.

* Then we make changes to that container.

* When we are satisfied with those changes, we transform them into a new layer.

* A new image is created by stacking the new layer on top of the old image.

.debug[[containers/Initial_Images.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Initial_Images.md)]
---

## A chicken-and-egg problem

* The only way to create an image is by "freezing" a container.

* The only way to create a container is by instantiating an image.

* Help!

.debug[[containers/Initial_Images.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Initial_Images.md)]
---

## Creating the first images

There is a special empty image called `scratch`.

* It allows to *build from scratch*.

The `docker import` command loads a tarball into Docker.

* The imported tarball becomes a standalone image.
* That new image has a single layer.

Note: you will probably never have to do this yourself.

.debug[[containers/Initial_Images.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Initial_Images.md)]
---

## Creating other images

`docker commit`

* Saves all the changes made to a container into a new layer.
* Creates a new image (effectively a copy of the container).

`docker build` **(used 99% of the time)**

* Performs a repeatable build sequence.
* This is the preferred method!

We will explain both methods in a moment.

.debug[[containers/Initial_Images.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Initial_Images.md)]
---

## Images namespaces

There are three namespaces:

* Official images

e.g. `ubuntu`, `busybox` ...

* User (and organizations) images

e.g. `jpetazzo/clock`

* Self-hosted images

e.g. `registry.example.com:5000/my-private/image`

Let's explain each of them.

.debug[[containers/Initial_Images.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Initial_Images.md)]
---

## Root namespace

The root namespace is for official images.

They are gated by Docker Inc.

They are generally authored and maintained by third parties.

Those images include:

* Small, "swiss-army-knife" images like busybox.

* Distro images to be used as bases for your builds, like ubuntu, fedora...

* Ready-to-use components and services, like redis, postgresql...

* Over 150 at this point!

.debug[[containers/Initial_Images.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Initial_Images.md)]
---

## User namespace

The user namespace holds images for Docker Hub users and organizations.

For example:

```bash
jpetazzo/clock
```

The Docker Hub user is:

```bash
jpetazzo
```

The image name is:

```bash
clock
```

.debug[[containers/Initial_Images.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Initial_Images.md)]
---

## Self-hosted namespace

This namespace holds images which are not hosted on Docker Hub, but on third
party registries.

They contain the hostname (or IP address), and optionally the port, of the
registry server.

For example:

```bash
localhost:5000/wordpress
```

* `localhost:5000` is the host and port of the registry
* `wordpress` is the name of the image

Other examples:

```bash
quay.io/coreos/etcd
gcr.io/google-containers/hugo
```

.debug[[containers/Initial_Images.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Initial_Images.md)]
---

## How do you store and manage images?

Images can be stored:

* On your Docker host.
* In a Docker registry.

You can use the Docker client to download (pull) or upload (push) images.

To be more accurate: you can use the Docker client to tell a Docker Engine
to push and pull images to and from a registry.

.debug[[containers/Initial_Images.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Initial_Images.md)]
---

## Showing current images

Let's look at what images are on our host now.

```bash
$ docker images
REPOSITORY       TAG       IMAGE ID       CREATED         SIZE
fedora           latest    ddd5c9c1d0f2   3 days ago      204.7 MB
centos           latest    d0e7f81ca65c   3 days ago      196.6 MB
ubuntu           latest    07c86167cdc4   4 days ago      188 MB
redis            latest    4f5f397d4b7c   5 days ago      177.6 MB
postgres         latest    afe2b5e1859b   5 days ago      264.5 MB
alpine           latest    70c557e50ed6   5 days ago      4.798 MB
debian           latest    f50f9524513f   6 days ago      125.1 MB
busybox          latest    3240943c9ea3   2 weeks ago     1.114 MB
training/namer   latest    902673acc741   9 months ago    289.3 MB
jpetazzo/clock   latest    12068b93616f   12 months ago   2.433 MB
```

.debug[[containers/Initial_Images.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Initial_Images.md)]
---

## Searching for images

We cannot list *all* images on a remote registry, but
we can search for a specific keyword:

```bash
$ docker search marathon
NAME                     DESCRIPTION                     STARS  OFFICIAL  AUTOMATED
mesosphere/marathon      A cluster-wide init and co...   105              [OK]
mesoscloud/marathon      Marathon                        31               [OK]
mesosphere/marathon-lb   Script to update haproxy b...   22               [OK]
tobilg/mongodb-marathon  A Docker image to start a ...   4                [OK]
```

* "Stars" indicate the popularity of the image.

* "Official" images are those in the root namespace.

* "Automated" images are built automatically by the Docker Hub.
 (This means that their build recipe is always available.)

.debug[[containers/Initial_Images.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Initial_Images.md)]
---

## Downloading images

There are two ways to download images.

* Explicitly, with `docker pull`.

* Implicitly, when executing `docker run` and the image is not found locally.

.debug[[containers/Initial_Images.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Initial_Images.md)]
---

## Pulling an image

```bash
$ docker pull debian:jessie
Pulling repository debian
b164861940b8: Download complete
b164861940b8: Pulling image (jessie) from debian
d1881793a057: Download complete
```

* As seen previously, images are made up of layers.

* Docker has downloaded all the necessary layers.

* In this example, `:jessie` indicates which exact version of Debian
  we would like.

It is a *version tag*.

.debug[[containers/Initial_Images.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Initial_Images.md)]
---

## Image and tags

* Images can have tags.

* Tags define image versions or variants.

* `docker pull ubuntu` will refer to `ubuntu:latest`.

* The `:latest` tag is generally updated often.

.debug[[containers/Initial_Images.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Initial_Images.md)]
---

## When to (not) use tags

Don't specify tags:

* When doing rapid testing and prototyping.
* When experimenting.
* When you want the latest version.

Do specify tags:

* When recording a procedure into a script.
* When going to production.
* To ensure that the same version will be used everywhere.
* To ensure repeatability later.

This is similar to what we would do with `pip install`, `npm install`, etc.

.debug[[containers/Initial_Images.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Initial_Images.md)]
---

## Multi-arch images

- An image can support multiple architectures

- More precisely, a specific *tag* in a given *repository* can have either:

- a single *manifest* referencing an image for a single architecture

- a *manifest list* (or *fat manifest*) referencing multiple images

- In a *manifest list*, each image is identified by a combination of:

- `os` (linux, windows)

- `architecture` (amd64, arm, arm64...)

- optional fields like `variant` (for arm and arm64), `os.version` (for windows)

.debug[[containers/Initial_Images.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Initial_Images.md)]
---

## Working with multi-arch images

- The Docker Engine will pull "native" images when available

(images matching its own os/architecture/variant)

- We can ask for a specific image platform with `--platform`

- The Docker Engine can run non-native images thanks to QEMU+binfmt

(automatically on Docker Desktop; with a bit of setup on Linux)

.debug[[containers/Initial_Images.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Initial_Images.md)]
---

## Section summary

We've learned how to:

* Understand images and layers.
* Understand Docker image namespacing.
* Search and download images.

???

:EN:Building images
:EN:- Containers, images, and layers
:EN:- Image addresses and tags
:EN:- Finding and transferring images

:FR:Construire des images
:FR:- La différence entre un conteneur et une image
:FR:- La notion de *layer* partagé entre images

.debug[[containers/Initial_Images.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Initial_Images.md)]
---

.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/containers-by-the-water.jpg)]

---

Building Docker images with a Dockerfile

.nav[
[Previous part](#toc-understanding-docker-images)
|
[Back to table of contents](#toc-part-2)
|
[Next part](#toc-cmd-and-entrypoint)
]

---

# Building Docker images with a Dockerfile

![Construction site with containers](images/title-building-docker-images-with-a-dockerfile.jpg)

.debug[[containers/Building_Images_With_Dockerfiles.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
---

## Objectives

We will build a container image automatically, with a `Dockerfile`.

At the end of this lesson, you will be able to:

* Write a `Dockerfile`.

* Build an image from a `Dockerfile`.

.debug[[containers/Building_Images_With_Dockerfiles.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
---

## `Dockerfile` overview

* A `Dockerfile` is a build recipe for a Docker image.

* It contains a series of instructions telling Docker how an image is constructed.

* The `docker build` command builds an image from a `Dockerfile`.

.debug[[containers/Building_Images_With_Dockerfiles.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
---

## Writing our first `Dockerfile`

Our Dockerfile must be in a **new, empty directory**.

1. Create a directory to hold our `Dockerfile`.

```bash
$ mkdir myimage
```

2. Create a `Dockerfile` inside this directory.

```bash
$ cd myimage
$ vim Dockerfile
```

Of course, you can use any other editor of your choice.

.debug[[containers/Building_Images_With_Dockerfiles.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
---

## Type this into our Dockerfile...

```dockerfile
FROM ubuntu
RUN apt-get update
RUN apt-get install figlet
```

* `FROM` indicates the base image for our build.

* Each `RUN` line will be executed by Docker during the build.

* Our `RUN` commands **must be non-interactive.**
 (No input can be provided to Docker during the build.)

* In many cases, we will add the `-y` flag to `apt-get`.

.debug[[containers/Building_Images_With_Dockerfiles.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
---

## Build it!

Save our file, then execute:

```bash
$ docker build -t figlet .
```

* `-t` indicates the tag to apply to the image.

* `.` indicates the location of the *build context*.

We will talk more about the build context later.

To keep things simple for now: this is the directory where our Dockerfile is located.

.debug[[containers/Building_Images_With_Dockerfiles.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
---

## What happens when we build the image?

It depends if we're using BuildKit or not!

If there are lots of blue lines and the first line looks like this:
```
[+] Building 1.8s (4/6)
```
... then we're using BuildKit.

If the output is mostly black-and-white and the first line looks like this:
```
Sending build context to Docker daemon  2.048kB
```
... then we're using the "classic" or "old-style" builder.

.debug[[containers/Building_Images_With_Dockerfiles.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
---

## To BuildKit or Not To BuildKit

Classic builder:

- copies the whole "build context" to the Docker Engine

- linear (processes lines one after the other)

- requires a full Docker Engine

BuildKit:

- only transfers parts of the "build context" when needed

- will parallelize operations (when possible)

- can run in non-privileged containers (e.g. on Kubernetes)

.debug[[containers/Building_Images_With_Dockerfiles.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
---

## With the classic builder

The output of `docker build` looks like this:

.small[
```bash
docker build -t figlet .
Sending build context to Docker daemon  2.048kB
Step 1/3 : FROM ubuntu
 ---> f975c5035748
Step 2/3 : RUN apt-get update
 ---> Running in e01b294dbffd
(...output of the RUN command...)
Removing intermediate container e01b294dbffd
 ---> eb8d9b561b37
Step 3/3 : RUN apt-get install figlet
 ---> Running in c29230d70f9b
(...output of the RUN command...)
Removing intermediate container c29230d70f9b
 ---> 0dfd7a253f21
Successfully built 0dfd7a253f21
Successfully tagged figlet:latest
```
]

* The output of the `RUN` commands has been omitted.
* Let's explain what this output means.

.debug[[containers/Building_Images_With_Dockerfiles.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
---

## Sending the build context to Docker

```bash
Sending build context to Docker daemon 2.048 kB
```

* The build context is the `.` directory given to `docker build`.

* It is sent (as an archive) by the Docker client to the Docker daemon.

* This allows to use a remote machine to build using local files.

* Be careful (or patient) if that directory is big and your link is slow.

* You can speed up the process with a [`.dockerignore`](https://docs.docker.com/engine/reference/builder/#dockerignore-file) file

* It tells docker to ignore specific files in the directory

* Only ignore files that you won't need in the build context!

.debug[[containers/Building_Images_With_Dockerfiles.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
---

## Executing each step

```bash
Step 2/3 : RUN apt-get update
 ---> Running in e01b294dbffd
(...output of the RUN command...)
Removing intermediate container e01b294dbffd
 ---> eb8d9b561b37
```

* A container (`e01b294dbffd`) is created from the base image.

* The `RUN` command is executed in this container.

* The container is committed into an image (`eb8d9b561b37`).

* The build container (`e01b294dbffd`) is removed.

* The output of this step will be the base image for the next one.

.debug[[containers/Building_Images_With_Dockerfiles.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
---

## With BuildKit

.small[
```bash
[+] Building 7.9s (7/7) FINISHED
 => [internal] load build definition from Dockerfile                                                 0.0s
 => => transferring dockerfile: 98B                                                                  0.0s
 => [internal] load .dockerignore                                                                    0.0s
 => => transferring context: 2B                                                                      0.0s
 => [internal] load metadata for docker.io/library/ubuntu:latest                                     1.2s
 => [1/3] FROM docker.io/library/ubuntu@sha256:cf31af331f38d1d7158470e095b132acd126a7180a54f263d386  3.2s
 => => resolve docker.io/library/ubuntu@sha256:cf31af331f38d1d7158470e095b132acd126a7180a54f263d386  0.0s
 => => sha256:cf31af331f38d1d7158470e095b132acd126a7180a54f263d386da88eb681d93 1.20kB / 1.20kB       0.0s
 => => sha256:1de4c5e2d8954bf5fa9855f8b4c9d3c3b97d1d380efe19f60f3e4107a66f5cae 943B / 943B           0.0s
 => => sha256:6a98cbe39225dadebcaa04e21dbe5900ad604739b07a9fa351dd10a6ebad4c1b 3.31kB / 3.31kB       0.0s
 => => sha256:80bc30679ac1fd798f3241208c14accd6a364cb8a6224d1127dfb1577d10554f 27.14MB / 27.14MB     2.3s
 => => sha256:9bf18fab4cfbf479fa9f8409ad47e2702c63241304c2cdd4c33f2a1633c5f85e 850B / 850B           0.5s
 => => sha256:5979309c983a2adeff352538937475cf961d49c34194fa2aab142effe19ed9c1 189B / 189B           0.4s
 => => extracting sha256:80bc30679ac1fd798f3241208c14accd6a364cb8a6224d1127dfb1577d10554f            0.7s
 => => extracting sha256:9bf18fab4cfbf479fa9f8409ad47e2702c63241304c2cdd4c33f2a1633c5f85e            0.0s
 => => extracting sha256:5979309c983a2adeff352538937475cf961d49c34194fa2aab142effe19ed9c1            0.0s
 => [2/3] RUN apt-get update                                                                         2.5s
 => [3/3] RUN apt-get install figlet                                                                 0.9s
 => exporting to image                                                                               0.1s
 => => exporting layers                                                                              0.1s
 => => writing image sha256:3b8aee7b444ab775975dfba691a72d8ac24af2756e0a024e056e3858d5a23f7c         0.0s
 => => naming to docker.io/library/figlet                                                            0.0s
 ```
 ]

.debug[[containers/Building_Images_With_Dockerfiles.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
---

## Understanding BuildKit output

- BuildKit transfers the Dockerfile and the *build context*

(these are the first two `[internal]` stages)

- Then it executes the steps defined in the Dockerfile

(`[1/3]`, `[2/3]`, `[3/3]`)

- Finally, it exports the result of the build

(image definition + collection of layers)

.debug[[containers/Building_Images_With_Dockerfiles.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
---

## BuildKit plain output

- When running BuildKit in e.g. a CI pipeline, its output will be different

- We can see the same output format by using `--progress=plain`

.debug[[containers/Building_Images_With_Dockerfiles.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
---

## The caching system

If you run the same build again, it will be instantaneous. Why?

* After each build step, Docker takes a snapshot of the resulting image.

* Before executing a step, Docker checks if it has already built the same sequence.

* Docker uses the exact strings defined in your Dockerfile, so:

* `RUN apt-get install figlet cowsay`
 is different from
 `RUN apt-get install cowsay figlet`

* `RUN apt-get update` is not re-executed when the mirrors are updated

You can force a rebuild with `docker build --no-cache ...`.

.debug[[containers/Building_Images_With_Dockerfiles.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
---

## Running the image

The resulting image is not different from the one produced manually.

```bash
$ docker run -ti figlet
root@91f3c974c9a1:/# figlet hello
 _          _ _       
| |__   ___| | | ___  
| '_ \ / _ \ | |/ _ \ 
| | | |  __/ | | (_) |
|_| |_|\___|_|_|\___/ 
```

Yay! 🎉

.debug[[containers/Building_Images_With_Dockerfiles.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
---

## Using image and viewing history

The `history` command lists all the layers composing an image.

For each layer, it shows its creation time, size, and creation command.

When an image was built with a Dockerfile, each layer corresponds to
a line of the Dockerfile.

```bash
$ docker history figlet
IMAGE CREATED CREATED BY SIZE
f9e8f1642759 About an hour ago /bin/sh -c apt-get install fi 1.627 MB
7257c37726a1 About an hour ago /bin/sh -c apt-get update 21.58 MB
07c86167cdc4 4 days ago /bin/sh -c #(nop) CMD ["/bin 0 B
<missing> 4 days ago /bin/sh -c sed -i 's/^#\s*\( 1.895 kB
<missing> 4 days ago /bin/sh -c echo '#!/bin/sh' 194.5 kB
<missing> 4 days ago /bin/sh -c #(nop) ADD file:b 187.8 MB
```

.debug[[containers/Building_Images_With_Dockerfiles.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
---

## Why `sh -c`?

* On UNIX, to start a new program, we need two system calls:

- `fork()`, to create a new child process;

- `execve()`, to replace the new child process with the program to run.

* Conceptually, `execve()` works like this:

`execve(program, [list, of, arguments])`

* When we run a command, e.g. `ls -l /tmp`, something needs to parse the command.

(i.e. split the program and its arguments into a list.)

* The shell is usually doing that.

(It also takes care of expanding environment variables and special things like `~`.)

.debug[[containers/Building_Images_With_Dockerfiles.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
---

## Why `sh -c`?

* When we do `RUN ls -l /tmp`, the Docker builder needs to parse the command.

* Instead of implementing its own parser, it outsources the job to the shell.

* That's why we see `sh -c ls -l /tmp` in that case.

* But we can also do the parsing jobs ourselves.

* This means passing `RUN` a list of arguments.

* This is called the *exec syntax*.

.debug[[containers/Building_Images_With_Dockerfiles.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
---

## Shell syntax vs exec syntax

Dockerfile commands that execute something can have two forms:

* plain string, or *shell syntax*:
 `RUN apt-get install figlet`

* JSON list, or *exec syntax*:
 `RUN ["apt-get", "install", "figlet"]`

We are going to change our Dockerfile to see how it affects the resulting image.

.debug[[containers/Building_Images_With_Dockerfiles.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
---

## Using exec syntax in our Dockerfile

Let's change our Dockerfile as follows!

```dockerfile
FROM ubuntu
RUN apt-get update
RUN ["apt-get", "install", "figlet"]
```

Then build the new Dockerfile.

```bash
$ docker build -t figlet .
```

.debug[[containers/Building_Images_With_Dockerfiles.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
---

## History with exec syntax

Compare the new history:

```bash
$ docker history figlet
IMAGE CREATED CREATED BY SIZE
27954bb5faaf 10 seconds ago apt-get install figlet 1.627 MB
7257c37726a1 About an hour ago /bin/sh -c apt-get update 21.58 MB
07c86167cdc4 4 days ago /bin/sh -c #(nop) CMD ["/bin 0 B
<missing> 4 days ago /bin/sh -c sed -i 's/^#\s*\( 1.895 kB
<missing> 4 days ago /bin/sh -c echo '#!/bin/sh' 194.5 kB
<missing> 4 days ago /bin/sh -c #(nop) ADD file:b 187.8 MB
```

* Exec syntax specifies an *exact* command to execute.

* Shell syntax specifies a command to be wrapped within `/bin/sh -c "..."`.

.debug[[containers/Building_Images_With_Dockerfiles.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
---

## When to use exec syntax and shell syntax

* shell syntax:

* is easier to write
  * interpolates environment variables and other shell expressions
  * creates an extra process (`/bin/sh -c ...`) to parse the string
  * requires `/bin/sh` to exist in the container

* exec syntax:

* is harder to write (and read!)
  * passes all arguments without extra processing
  * doesn't create an extra process
  * doesn't require `/bin/sh` to exist in the container

.debug[[containers/Building_Images_With_Dockerfiles.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
---

## Pro-tip: the `exec` shell built-in

POSIX shells have a built-in command named `exec`.

`exec` should be followed by a program and its arguments.

From a user perspective:

- it looks like the shell exits right away after the command execution,

- in fact, the shell exits just *before* command execution;

- or rather, the shell gets *replaced* by the command.

.debug[[containers/Building_Images_With_Dockerfiles.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
---

## Example using `exec`

```dockerfile
CMD exec figlet -f script hello
```

In this example, `sh -c` will still be used, but
`figlet` will be PID 1 in the container.

The shell gets replaced by `figlet` when `figlet` starts execution.

This allows to run processes as PID 1 without using JSON.

???

:EN:- Towards automated, reproducible builds
:EN:- Writing our first Dockerfile
:FR:- Rendre le processus automatique et reproductible
:FR:- Écrire son premier Dockerfile

.debug[[containers/Building_Images_With_Dockerfiles.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Building_Images_With_Dockerfiles.md)]
---

.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/distillery-containers.jpg)]

---

`CMD` and `ENTRYPOINT`

.nav[
[Previous part](#toc-building-docker-images-with-a-dockerfile)
|
[Back to table of contents](#toc-part-2)
|
[Next part](#toc-copying-files-during-the-build)
]

---

# `CMD` and `ENTRYPOINT`

![Container entry doors](images/entrypoint.jpg)

.debug[[containers/Cmd_And_Entrypoint.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Cmd_And_Entrypoint.md)]
---

## Objectives

In this lesson, we will learn about two important
Dockerfile commands:

`CMD` and `ENTRYPOINT`.

These commands allow us to set the default command
to run in a container.

.debug[[containers/Cmd_And_Entrypoint.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Cmd_And_Entrypoint.md)]
---

## Defining a default command

When people run our container, we want to greet them with a nice hello message, and using a custom font.

For that, we will execute:

```bash
figlet -f script hello
```

* `-f script` tells figlet to use a fancy font.

* `hello` is the message that we want it to display.

.debug[[containers/Cmd_And_Entrypoint.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Cmd_And_Entrypoint.md)]
---

## Adding `CMD` to our Dockerfile

Our new Dockerfile will look like this:

```dockerfile
FROM ubuntu
RUN apt-get update
RUN ["apt-get", "install", "figlet"]
CMD figlet -f script hello
```

* `CMD` defines a default command to run when none is given.

* It can appear at any point in the file.

* Each `CMD` will replace and override the previous one.

* As a result, while you can have multiple `CMD` lines, it is useless.

.debug[[containers/Cmd_And_Entrypoint.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Cmd_And_Entrypoint.md)]
---

## Build and test our image

Let's build it:

```bash
$ docker build -t figlet .
...
Successfully built 042dff3b4a8d
Successfully tagged figlet:latest
```

And run it:

```bash
$ docker run figlet
 _          _   _       
| |        | | | |      
| |     _  | | | |  __  
|/ \   |/  |/  |/  /  \_
|   |_/|__/|__/|__/\__/ 
```

.debug[[containers/Cmd_And_Entrypoint.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Cmd_And_Entrypoint.md)]
---

## Overriding `CMD`

If we want to get a shell into our container (instead of running
`figlet`), we just have to specify a different program to run:

```bash
$ docker run -it figlet bash
root@7ac86a641116:/# 
```

* We specified `bash`.

* It replaced the value of `CMD`.

.debug[[containers/Cmd_And_Entrypoint.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Cmd_And_Entrypoint.md)]
---

## Using `ENTRYPOINT`

We want to be able to specify a different message on the command line,
while retaining `figlet` and some default parameters.

In other words, we would like to be able to do this:

```bash
$ docker run figlet salut
           _            
          | |           
 ,   __,  | |       _|_ 
/ \_/  |  |/  |   |  |  
 \/ \_/|_/|__/ \_/|_/|_/
```

We will use the `ENTRYPOINT` verb in Dockerfile.

.debug[[containers/Cmd_And_Entrypoint.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Cmd_And_Entrypoint.md)]
---

## Adding `ENTRYPOINT` to our Dockerfile

Our new Dockerfile will look like this:

```dockerfile
FROM ubuntu
RUN apt-get update
RUN ["apt-get", "install", "figlet"]
ENTRYPOINT ["figlet", "-f", "script"]
```

* `ENTRYPOINT` defines a base command (and its parameters) for the container.

* The command line arguments are appended to those parameters.

* Like `CMD`, `ENTRYPOINT` can appear anywhere, and replaces the previous value.

Why did we use JSON syntax for our `ENTRYPOINT`?

.debug[[containers/Cmd_And_Entrypoint.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Cmd_And_Entrypoint.md)]
---

## Implications of JSON vs string syntax

* When CMD or ENTRYPOINT use string syntax, they get wrapped in `sh -c`.

* To avoid this wrapping, we can use JSON syntax.

What if we used `ENTRYPOINT` with string syntax?

```bash
$ docker run figlet salut
```

This would run the following command in the `figlet` image:

```bash
sh -c "figlet -f script" salut
```

.debug[[containers/Cmd_And_Entrypoint.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Cmd_And_Entrypoint.md)]
---

## Build and test our image

Let's build it:

```bash
$ docker build -t figlet .
...
Successfully built 36f588918d73
Successfully tagged figlet:latest
```

And run it:

```bash
$ docker run figlet salut
           _            
          | |           
 ,   __,  | |       _|_ 
/ \_/  |  |/  |   |  |  
 \/ \_/|_/|__/ \_/|_/|_/
```

.debug[[containers/Cmd_And_Entrypoint.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Cmd_And_Entrypoint.md)]
---

## Using `CMD` and `ENTRYPOINT` together

What if we want to define a default message for our container?

Then we will use `ENTRYPOINT` and `CMD` together.

* `ENTRYPOINT` will define the base command for our container.

* `CMD` will define the default parameter(s) for this command.

* They *both* have to use JSON syntax.

.debug[[containers/Cmd_And_Entrypoint.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Cmd_And_Entrypoint.md)]
---

## `CMD` and `ENTRYPOINT` together

Our new Dockerfile will look like this:

```dockerfile
FROM ubuntu
RUN apt-get update
RUN ["apt-get", "install", "figlet"]
ENTRYPOINT ["figlet", "-f", "script"]
CMD ["hello world"]
```

* `ENTRYPOINT` defines a base command (and its parameters) for the container.

* If we don't specify extra command-line arguments when starting the container,
  the value of `CMD` is appended.

* Otherwise, our extra command-line arguments are used instead of `CMD`.

.debug[[containers/Cmd_And_Entrypoint.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Cmd_And_Entrypoint.md)]
---

## Build and test our image

Let's build it:

```bash
$ docker build -t myfiglet .
...
Successfully built 6e0b6a048a07
Successfully tagged myfiglet:latest
```

Run it without parameters:

```bash
$ docker run myfiglet
 _          _   _                             _        
| |        | | | |                           | |    |  
| |     _  | | | |  __             __   ,_   | |  __|  
|/ \   |/  |/  |/  /  \_  |  |  |_/  \_/  |  |/  /  |  
|   |_/|__/|__/|__/\__/    \/ \/  \__/    |_/|__/\_/|_/
```

.debug[[containers/Cmd_And_Entrypoint.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Cmd_And_Entrypoint.md)]
---

## Overriding the image default parameters

Now let's pass extra arguments to the image.

```bash
$ docker run myfiglet hola mundo
 _           _                                               
| |         | |                                      |       
| |     __  | |  __,     _  _  _           _  _    __|   __  
|/ \   /  \_|/  /  |    / |/ |/ |  |   |  / |/ |  /  |  /  \_
|   |_/\__/ |__/\_/|_/    |  |  |_/ \_/|_/  |  |_/\_/|_/\__/ 
```

We overrode `CMD` but still used `ENTRYPOINT`.

.debug[[containers/Cmd_And_Entrypoint.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Cmd_And_Entrypoint.md)]
---

## Overriding `ENTRYPOINT`

What if we want to run a shell in our container?

We cannot just do `docker run myfiglet bash` because
that would just tell figlet to display the word "bash."

We use the `--entrypoint` parameter:

```bash
$ docker run -it --entrypoint bash myfiglet
root@6027e44e2955:/# 
```

.debug[[containers/Cmd_And_Entrypoint.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Cmd_And_Entrypoint.md)]
---

## `CMD` and `ENTRYPOINT` recap

- `docker run myimage` executes `ENTRYPOINT` + `CMD`

- `docker run myimage args` executes `ENTRYPOINT` + `args` (overriding `CMD`)

- `docker run --entrypoint prog myimage` executes `prog` (overriding both)

.small[
| Command                         | `ENTRYPOINT`       | `CMD`   | Result
|---------------------------------|--------------------|---------|-------
| `docker run figlet`             | none               | none    | Use values from base image (`bash`)
| `docker run figlet hola`        | none               | none    | Error (executable `hola` not found)
| `docker run figlet`             | `figlet -f script` | none    | `figlet -f script`
| `docker run figlet hola`        | `figlet -f script` | none    | `figlet -f script hola`
| `docker run figlet`             | none    | `figlet -f script` | `figlet -f script`
| `docker run figlet hola`        | none    | `figlet -f script` | Error (executable `hola` not found)
| `docker run figlet`             | `figlet -f script` | `hello` | `figlet -f script hello`
| `docker run figlet hola`        | `figlet -f script` | `hello` | `figlet -f script hola`
]

.debug[[containers/Cmd_And_Entrypoint.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Cmd_And_Entrypoint.md)]
---

## When to use `ENTRYPOINT` vs `CMD`

`ENTRYPOINT` is great for "containerized binaries".

Example: `docker run consul --help`

(Pretend that the `docker run` part isn't there!)

`CMD` is great for images with multiple binaries.

Example: `docker run busybox ifconfig`

(It makes sense to indicate *which* program we want to run!)

???

:EN:- CMD and ENTRYPOINT
:FR:- CMD et ENTRYPOINT

.debug[[containers/Cmd_And_Entrypoint.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Cmd_And_Entrypoint.md)]
---

.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/lots-of-containers.jpg)]

---

Copying files during the build

.nav[
[Previous part](#toc-cmd-and-entrypoint)
|
[Back to table of contents](#toc-part-2)
|
[Next part](#toc-reducing-image-size)
]

---

# Copying files during the build

![Monks copying books](images/title-copying-files-during-build.jpg)

.debug[[containers/Copying_Files_During_Build.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Copying_Files_During_Build.md)]
---

## Objectives

So far, we have installed things in our container images
by downloading packages.

We can also copy files from the *build context* to the
container that we are building.

Remember: the *build context* is the directory containing
the Dockerfile.

In this chapter, we will learn a new Dockerfile keyword: `COPY`.

.debug[[containers/Copying_Files_During_Build.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Copying_Files_During_Build.md)]
---

## Build some C code

We want to build a container that compiles a basic "Hello world" program in C.

Here is the program, `hello.c`:

```bash
int main () {
  puts("Hello, world!");
  return 0;
}
```

Let's create a new directory, and put this file in there.

Then we will write the Dockerfile.

.debug[[containers/Copying_Files_During_Build.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Copying_Files_During_Build.md)]
---

## The Dockerfile

On Debian and Ubuntu, the package `build-essential` will get us a compiler.

When installing it, don't forget to specify the `-y` flag, otherwise the build will fail (since the build cannot be interactive).

Then we will use `COPY` to place the source file into the container.

```bash
FROM ubuntu
RUN apt-get update
RUN apt-get install -y build-essential
COPY hello.c /
RUN make hello
CMD /hello
```

Create this Dockerfile.

.debug[[containers/Copying_Files_During_Build.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Copying_Files_During_Build.md)]
---

## Testing our C program

* Create `hello.c` and `Dockerfile` in the same directory.

* Run `docker build -t hello .` in this directory.

* Run `docker run hello`, you should see `Hello, world!`.

Success!

.debug[[containers/Copying_Files_During_Build.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Copying_Files_During_Build.md)]
---

## `COPY` and the build cache

* Run the build again.

* Now, modify `hello.c` and run the build again.

* Docker can cache steps involving `COPY`.

* Those steps will not be executed again if the files haven't been changed.

.debug[[containers/Copying_Files_During_Build.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Copying_Files_During_Build.md)]
---

## Details

* We can `COPY` whole directories recursively

* It is possible to do e.g. `COPY . .`

(but it might require some extra precautions to avoid copying too much)
 
* In older Dockerfiles, you might see the `ADD` command; consider it deprecated

(it is similar to `COPY` but can automatically extract archives)

* If we really wanted to compile C code in a container, we would:

* place it in a different directory, with the `WORKDIR` instruction

* even better, use the `gcc` official image

.debug[[containers/Copying_Files_During_Build.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Copying_Files_During_Build.md)]
---

## `.dockerignore`

- We can create a file named `.dockerignore`

(at the top-level of the build context)

- It can contain file names and globs to ignore

- They won't be sent to the builder

(and won't end up in the resulting image)

- See the [documentation] for the little details

(exceptions can be made with `!`, multiple directory levels with `**`...)

[documentation]: https://docs.docker.com/engine/reference/builder/#dockerignore-file

???

:EN:- Leveraging the build cache for faster builds
:FR:- Tirer parti du cache afin d'optimiser la vitesse de *build*

.debug[[containers/Copying_Files_During_Build.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Copying_Files_During_Build.md)]
---

.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/plastic-containers.JPG)]

---

Reducing image size

.nav[
[Previous part](#toc-copying-files-during-the-build)
|
[Back to table of contents](#toc-part-2)
|
[Next part](#toc-multi-stage-builds)
]

---
# Reducing image size

* In the previous example, our final image contained:

* our `hello` program

* its source code

* the compiler

* Only the first one is strictly necessary.

* We are going to see how to obtain an image without the superfluous components.

.debug[[containers/Multi_Stage_Builds.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Multi_Stage_Builds.md)]
---

## Can't we remove superfluous files with `RUN`?

What happens if we do one of the following commands?

- `RUN rm -rf ...`

- `RUN apt-get remove ...`

- `RUN make clean ...`

This adds a layer which removes a bunch of files.

But the previous layers (which added the files) still exist.

.debug[[containers/Multi_Stage_Builds.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Multi_Stage_Builds.md)]
---

## Removing files with an extra layer

When downloading an image, all the layers must be downloaded.

| Dockerfile instruction | Layer size | Image size |
| ---------------------- | ---------- | ---------- |
| `FROM ubuntu` | Size of base image | Size of base image |
| `...` | ... | Sum of this layer + all previous ones |
| `RUN apt-get install somepackage` | Size of files added (e.g. a few MB) | Sum of this layer + all previous ones |
| `...` | ... | Sum of this layer + all previous ones |
| `RUN apt-get remove somepackage` | Almost zero (just metadata) | Same as previous one |

Therefore, `RUN rm` does not reduce the size of the image or free up disk space.

.debug[[containers/Multi_Stage_Builds.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Multi_Stage_Builds.md)]
---

## Removing unnecessary files

Various techniques are available to obtain smaller images:

- collapsing layers,

- adding binaries that are built outside of the Dockerfile,

- squashing the final image,

- multi-stage builds.

Let's review them quickly.

.debug[[containers/Multi_Stage_Builds.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Multi_Stage_Builds.md)]
---

## Collapsing layers

You will frequently see Dockerfiles like this:

```dockerfile
FROM ubuntu
RUN apt-get update && apt-get install xxx && ... && apt-get remove xxx && ...
```

Or the (more readable) variant:

```dockerfile
FROM ubuntu
RUN apt-get update \
 && apt-get install xxx \
 && ... \
 && apt-get remove xxx \
 && ...
```

This `RUN` command gives us a single layer.

The files that are added, then removed in the same layer, do not grow the layer size.

.debug[[containers/Multi_Stage_Builds.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Multi_Stage_Builds.md)]
---

## Collapsing layers: pros and cons

Pros:

- works on all versions of Docker

- doesn't require extra tools

Cons:

- not very readable

- some unnecessary files might still remain if the cleanup is not thorough

- that layer is expensive (slow to build)

.debug[[containers/Multi_Stage_Builds.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Multi_Stage_Builds.md)]
---

## Building binaries outside of the Dockerfile

This results in a Dockerfile looking like this:

```dockerfile
FROM ubuntu
COPY xxx /usr/local/bin
```

Of course, this implies that the file `xxx` exists in the build context.

That file has to exist before you can run `docker build`.

For instance, it can:

- exist in the code repository,
- be created by another tool (script, Makefile...),
- be created by another container image and extracted from the image.

See for instance the [busybox official image](https://github.com/docker-library/busybox/blob/fe634680e32659aaf0ee0594805f74f332619a90/musl/Dockerfile) or this [older busybox image](https://github.com/jpetazzo/docker-busybox).

.debug[[containers/Multi_Stage_Builds.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Multi_Stage_Builds.md)]
---

## Building binaries outside: pros and cons

Pros:

- final image can be very small

Cons:

- requires an extra build tool

- we're back in dependency hell and "works on my machine"

Cons, if binary is added to code repository:

- breaks portability across different platforms

- grows repository size a lot if the binary is updated frequently

.debug[[containers/Multi_Stage_Builds.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Multi_Stage_Builds.md)]
---

## Squashing the final image

The idea is to transform the final image into a single-layer image.

This can be done in (at least) two ways.

- Activate experimental features and squash the final image:
  ```bash
  docker image build --squash ...
  ```

- Export/import the final image.
  ```bash
  docker build -t temp-image .
  docker run --entrypoint true --name temp-container temp-image
  docker export temp-container | docker import - final-image
  docker rm temp-container
  docker rmi temp-image
  ```

.debug[[containers/Multi_Stage_Builds.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Multi_Stage_Builds.md)]
---

## Squashing the image: pros and cons

Pros:

- single-layer images are smaller and faster to download

- removed files no longer take up storage and network resources

Cons:

- we still need to actively remove unnecessary files

- squash operation can take a lot of time (on big images)

- squash operation does not benefit from cache
 
 (even if we change just a tiny file, the whole image needs to be re-squashed)

.debug[[containers/Multi_Stage_Builds.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Multi_Stage_Builds.md)]
---

## Multi-stage builds

Multi-stage builds allow us to have multiple *stages*.

Each stage is a separate image, and can copy files from previous stages.

We're going to see how they work in more detail.

.debug[[containers/Multi_Stage_Builds.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Multi_Stage_Builds.md)]
---

.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/train-of-containers-1.jpg)]

---

Multi-stage builds

.nav[
[Previous part](#toc-reducing-image-size)
|
[Back to table of contents](#toc-part-2)
|
[Next part](#toc-publishing-images-to-the-docker-hub)
]

---

# Multi-stage builds

* At any point in our `Dockerfile`, we can add a new `FROM` line.

* This line starts a new stage of our build.

* Each stage can access the files of the previous stages with `COPY --from=...`.

* When a build is tagged (with `docker build -t ...`), the last stage is tagged.

* Previous stages are not discarded: they will be used for caching, and can be referenced.

.debug[[containers/Multi_Stage_Builds.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Multi_Stage_Builds.md)]
---

## Multi-stage builds in practice

* Each stage is numbered, starting at `0`

* We can copy a file from a previous stage by indicating its number, e.g.:

```dockerfile
  COPY --from=0 /file/from/first/stage /location/in/current/stage
  ```

* We can also name stages, and reference these names:

```dockerfile
  FROM golang AS builder
  RUN ...
  FROM alpine
  COPY --from=builder /go/bin/mylittlebinary /usr/local/bin/
  ```

.debug[[containers/Multi_Stage_Builds.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Multi_Stage_Builds.md)]
---

## Multi-stage builds for our C program

We will change our Dockerfile to:

* give a nickname to the first stage: `compiler`

* add a second stage using the same `ubuntu` base image

* add the `hello` binary to the second stage

* make sure that `CMD` is in the second stage

The resulting Dockerfile is on the next slide.

.debug[[containers/Multi_Stage_Builds.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Multi_Stage_Builds.md)]
---

## Multi-stage build `Dockerfile`

Here is the final Dockerfile:

```dockerfile
FROM ubuntu AS compiler
RUN apt-get update
RUN apt-get install -y build-essential
COPY hello.c /
RUN make hello
FROM ubuntu
COPY --from=compiler /hello /hello
CMD /hello
```

Let's build it, and check that it works correctly:

```bash
docker build -t hellomultistage .
docker run hellomultistage
```

.debug[[containers/Multi_Stage_Builds.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Multi_Stage_Builds.md)]
---

## Comparing single/multi-stage build image sizes

List our images with `docker images`, and check the size of:

- the `ubuntu` base image,

- the single-stage `hello` image,

- the multi-stage `hellomultistage` image.

We can achieve even smaller images if we use smaller base images.

However, if we use common base images (e.g. if we standardize on `ubuntu`),
these common images will be pulled only once per node, so they are
virtually "free."

.debug[[containers/Multi_Stage_Builds.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Multi_Stage_Builds.md)]
---

## Build targets

* We can also tag an intermediary stage with the following command:
  ```bash
  docker build --target STAGE --tag NAME
  ```

* This will create an image (named `NAME`) corresponding to stage `STAGE`

* This can be used to easily access an intermediary stage for inspection

(instead of parsing the output of `docker build` to find out the image ID)

* This can also be used to describe multiple images from a single Dockerfile

(instead of using multiple Dockerfiles, which could go out of sync)

???

:EN:Optimizing our images and their build process
:EN:- Leveraging multi-stage builds

:FR:Optimiser les images et leur construction
:FR:- Utilisation d'un *multi-stage build*

.debug[[containers/Multi_Stage_Builds.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Multi_Stage_Builds.md)]
---

.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/train-of-containers-2.jpg)]

---

Publishing images to the Docker Hub

.nav[
[Previous part](#toc-multi-stage-builds)
|
[Back to table of contents](#toc-part-2)
|
[Next part](#toc-tips-for-efficient-dockerfiles)
]

---
# Publishing images to the Docker Hub

We have built our first images.

We can now publish it to the Docker Hub!

*You don't have to do the exercises in this section,
because they require an account on the Docker Hub, and we
don't want to force anyone to create one.*

*Note, however, that creating an account on the Docker Hub
is free (and doesn't require a credit card), and hosting
public images is free as well.*

.debug[[containers/Publishing_To_Docker_Hub.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Publishing_To_Docker_Hub.md)]
---

## Logging into our Docker Hub account

* This can be done from the Docker CLI:
  ```bash
  docker login
  ```

.warning[When running Docker for Mac/Windows, or
Docker on a Linux workstation, it can (and will when
possible) integrate with your system's keyring to
store your credentials securely. However, on most Linux
servers, it will store your credentials in `~/.docker/config`.]

.debug[[containers/Publishing_To_Docker_Hub.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Publishing_To_Docker_Hub.md)]
---

## Image tags and registry addresses

* Docker images tags are like Git tags and branches.

* They are like *bookmarks* pointing at a specific image ID.

* Tagging an image doesn't *rename* an image: it adds another tag.

* When pushing an image to a registry, the registry address is in the tag.

Example: `registry.example.net:5000/image`

* What about Docker Hub images?

* `jpetazzo/clock` is, in fact, `index.docker.io/jpetazzo/clock`

* `ubuntu` is, in fact, `library/ubuntu`, i.e. `index.docker.io/library/ubuntu`

.debug[[containers/Publishing_To_Docker_Hub.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Publishing_To_Docker_Hub.md)]
---

## Tagging an image to push it on the Hub

* Let's tag our `figlet` image (or any other to our liking):
  ```bash
  docker tag figlet jpetazzo/figlet
  ```

* And push it to the Hub:
  ```bash
  docker push jpetazzo/figlet
  ```

* That's it!

* Anybody can now `docker run jpetazzo/figlet` anywhere.

.debug[[containers/Publishing_To_Docker_Hub.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Publishing_To_Docker_Hub.md)]
---

## The goodness of automated builds

* You can link a Docker Hub repository with a GitHub or BitBucket repository

* Each push to GitHub or BitBucket will trigger a build on Docker Hub

* If the build succeeds, the new image is available on Docker Hub

* You can map tags and branches between source and container images

* If you work with public repositories, this is free

.debug[[containers/Publishing_To_Docker_Hub.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Publishing_To_Docker_Hub.md)]
---

## Setting up an automated build

* We need a Dockerized repository!
* Let's go to https://github.com/jpetazzo/trainingwheels and fork it.
* Go to the Docker Hub (https://hub.docker.com/) and sign-in. Select "Repositories" in the blue navigation menu.
* Select "Create" in the top-right bar, and select "Create Repository+".
* Connect your Docker Hub account to your GitHub account.
* Click "Create" button.
* Then go to "Builds" folder.
* Click on Github icon and select your user and the repository that we just forked.
* In "Build rules" block near page bottom, put `/www` in "Build Context" column (or whichever directory the Dockerfile is in).
* Click "Save and Build" to build the repository immediately (without waiting for a git push).
* Subsequent builds will happen automatically, thanks to GitHub hooks.

.debug[[containers/Publishing_To_Docker_Hub.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Publishing_To_Docker_Hub.md)]
---

## Building on the fly

- Some services can build images on the fly from a repository

- Example: [ctr.run](https://ctr.run/)

- Use ctr.run to automatically build a container image and run it:
  ```bash
  docker run ctr.run/github.com/undefinedlabs/hello-world
  ```

]

There might be a long pause before the first layer is pulled,
because the API behind `docker pull` doesn't allow to stream build logs, and there is no feedback during the build.

It is possible to view the build logs by setting up an account on [ctr.run](https://ctr.run/).

???

:EN:- Publishing images to the Docker Hub
:FR:- Publier des images sur le Docker Hub

.debug[[containers/Publishing_To_Docker_Hub.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Publishing_To_Docker_Hub.md)]
---

.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/two-containers-on-a-truck.jpg)]

---

Tips for efficient Dockerfiles

.nav[
[Previous part](#toc-publishing-images-to-the-docker-hub)
|
[Back to table of contents](#toc-part-2)
|
[Next part](#toc-dockerfile-examples)
]

---
# Tips for efficient Dockerfiles

We will see how to:

* Reduce the number of layers.

* Leverage the build cache so that builds can be faster.

* Embed unit testing in the build process.

.debug[[containers/Dockerfile_Tips.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Dockerfile_Tips.md)]
---

## Reducing the number of layers

* Each line in a `Dockerfile` creates a new layer.

* Build your `Dockerfile` to take advantage of Docker's caching system.

* Combine commands by using `&&` to continue commands and `\` to wrap lines.

Note: it is frequent to build a Dockerfile line by line:

```dockerfile
RUN apt-get install thisthing
RUN apt-get install andthatthing andthatotherone
RUN apt-get install somemorestuff
```

And then refactor it trivially before shipping:

```dockerfile
RUN apt-get install thisthing andthatthing andthatotherone somemorestuff
```

.debug[[containers/Dockerfile_Tips.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Dockerfile_Tips.md)]
---

## Avoid re-installing dependencies at each build

* Classic Dockerfile problem:

"each time I change a line of code, all my dependencies are re-installed!"

* Solution: `COPY` dependency lists (`package.json`, `requirements.txt`, etc.)
  by themselves to avoid reinstalling unchanged dependencies every time.

.debug[[containers/Dockerfile_Tips.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Dockerfile_Tips.md)]
---

## Example "bad" `Dockerfile`

The dependencies are reinstalled every time, because the build system does not know if `requirements.txt` has been updated.

```bash
FROM python
WORKDIR /src
COPY . .
RUN pip install -qr requirements.txt
EXPOSE 5000
CMD ["python", "app.py"]
```

.debug[[containers/Dockerfile_Tips.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Dockerfile_Tips.md)]
---

## Fixed `Dockerfile`

Adding the dependencies as a separate step means that Docker can cache more efficiently and only install them when `requirements.txt` changes.

```bash
FROM python
WORKDIR /src
COPY requirements.txt .
RUN pip install -qr requirements.txt
COPY . .
EXPOSE 5000
CMD ["python", "app.py"]
```

.debug[[containers/Dockerfile_Tips.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Dockerfile_Tips.md)]
---

## Be careful with `chown`, `chmod`, `mv`

* Layers cannot store efficiently changes in permissions or ownership.

* Layers cannot represent efficiently when a file is moved either.

* As a result, operations like `chown`, `chown`, `mv` can be expensive.

* For instance, in the Dockerfile snippet below, each `RUN` line
  creates a layer with an entire copy of `some-file`.

```dockerfile
  COPY some-file .
  RUN chown www-data:www-data some-file
  RUN chmod 644 some-file
  RUN mv some-file /var/www
  ```

* How can we avoid that?

.debug[[containers/Dockerfile_Tips.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Dockerfile_Tips.md)]
---

## Put files on the right place

* Instead of using `mv`, directly put files at the right place.

* When extracting archives (tar, zip...), merge operations in a single layer.

Example:

```dockerfile
    ...
    RUN wget http://.../foo.tar.gz \
     && tar -zxf foo.tar.gz \
     && mv foo/fooctl /usr/local/bin \
     && rm -rf foo
  ...
  ```

.debug[[containers/Dockerfile_Tips.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Dockerfile_Tips.md)]
---

## Use `COPY --chown`

* The Dockerfile instruction `COPY` can take a `--chown` parameter.

Examples:

```dockerfile
  ...
  COPY --chown=1000 some-file .
  COPY --chown=1000:1000 some-file .
  COPY --chown=www-data:www-data some-file .
  ```

* The `--chown` flag can specify a user, or a user:group pair.

* The user and group can be specified as names or numbers.

* When using names, the names must exist in `/etc/passwd` or `/etc/group`.

*(In the container, not on the host!)*

.debug[[containers/Dockerfile_Tips.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Dockerfile_Tips.md)]
---

## Set correct permissions locally

* Instead of using `chmod`, set the right file permissions locally.

* When files are copied with `COPY`, permissions are preserved.

.debug[[containers/Dockerfile_Tips.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Dockerfile_Tips.md)]
---

## Embedding unit tests in the build process

```dockerfile
FROM <baseimage>
RUN <install dependencies>
COPY <code>
RUN <build code>
RUN <install test dependencies>
COPY <test data sets and fixtures>
RUN <unit tests>
FROM <baseimage>
RUN <install dependencies>
COPY <code>
RUN <build code>
CMD, EXPOSE ...
```

* The build fails as soon as an instruction fails
* If `RUN <unit tests>` fails, the build doesn't produce an image
* If it succeeds, it produces a clean image (without test libraries and data)

.debug[[containers/Dockerfile_Tips.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Dockerfile_Tips.md)]
---

.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/wall-of-containers.jpeg)]

---

Dockerfile examples

.nav[
[Previous part](#toc-tips-for-efficient-dockerfiles)
|
[Back to table of contents](#toc-part-2)
|
[Next part](#toc-compose-for-development-stacks)
]

---

# Dockerfile examples

There are a number of tips, tricks, and techniques that we can use in Dockerfiles.

But sometimes, we have to use different (and even opposed) practices depending on:

- the complexity of our project,

- the programming language or framework that we are using,

- the stage of our project (early MVP vs. super-stable production),

- whether we're building a final image or a base for further images,

- etc.

We are going to show a few examples using very different techniques.

.debug[[containers/Dockerfile_Tips.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Dockerfile_Tips.md)]
---

## When to optimize an image

When authoring official images, it is a good idea to reduce as much as possible:

- the number of layers,

- the size of the final image.

This is often done at the expense of build time and convenience for the image maintainer;
but when an image is downloaded millions of time, saving even a few seconds of pull time
can be worth it.

.small[
```dockerfile
RUN apt-get update && apt-get install -y libpng12-dev libjpeg-dev && rm -rf /var/lib/apt/lists/* \
	&& docker-php-ext-configure gd --with-png-dir=/usr --with-jpeg-dir=/usr \
	&& docker-php-ext-install gd
...
RUN curl -o wordpress.tar.gz -SL https://wordpress.org/wordpress-${WORDPRESS_UPSTREAM_VERSION}.tar.gz \
	&& echo "$WORDPRESS_SHA1 *wordpress.tar.gz" | sha1sum -c - \
	&& tar -xzf wordpress.tar.gz -C /usr/src/ \
	&& rm wordpress.tar.gz \
	&& chown -R www-data:www-data /usr/src/wordpress
```
]

(Source: [Wordpress official image](https://github.com/docker-library/wordpress/blob/618490d4bdff6c5774b84b717979bfe3d6ba8ad1/apache/Dockerfile))

.debug[[containers/Dockerfile_Tips.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Dockerfile_Tips.md)]
---

## When to *not* optimize an image

Sometimes, it is better to prioritize *maintainer convenience*.

In particular, if:

- the image changes a lot,

- the image has very few users (e.g. only 1, the maintainer!),

- the image is built and run on the same machine,

- the image is built and run on machines with a very fast link ...

In these cases, just keep things simple!

(Next slide: a Dockerfile that can be used to preview a Jekyll / github pages site.)

.debug[[containers/Dockerfile_Tips.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Dockerfile_Tips.md)]
---

```dockerfile
FROM debian:sid

RUN apt-get update -q
RUN apt-get install -yq build-essential make
RUN apt-get install -yq zlib1g-dev
RUN apt-get install -yq ruby ruby-dev
RUN apt-get install -yq python-pygments
RUN apt-get install -yq nodejs
RUN apt-get install -yq cmake
RUN gem install --no-rdoc --no-ri github-pages

COPY . /blog
WORKDIR /blog

VOLUME /blog/_site

EXPOSE 4000
CMD ["jekyll", "serve", "--host", "0.0.0.0", "--incremental"]
```

.debug[[containers/Dockerfile_Tips.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Dockerfile_Tips.md)]
---

## Multi-dimensional versioning systems

Images can have a tag, indicating the version of the image.

But sometimes, there are multiple important components, and we need to indicate the versions
for all of them.

This can be done with environment variables:

```dockerfile
ENV PIP=9.0.3 \
    ZC_BUILDOUT=2.11.2 \
    SETUPTOOLS=38.7.0 \
    PLONE_MAJOR=5.1 \
    PLONE_VERSION=5.1.0 \
    PLONE_MD5=76dc6cfc1c749d763c32fff3a9870d8d
```

(Source: [Plone official image](https://github.com/plone/plone.docker/blob/master/5.1/5.1.0/alpine/Dockerfile))

.debug[[containers/Dockerfile_Tips.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Dockerfile_Tips.md)]
---

## Entrypoints and wrappers

It is very common to define a custom entrypoint.

That entrypoint will generally be a script, performing any combination of:

- pre-flights checks (if a required dependency is not available, display
  a nice error message early instead of an obscure one in a deep log file),

- generation or validation of configuration files,

- dropping privileges (with e.g. `su` or `gosu`, sometimes combined with `chown`),

- and more.

.debug[[containers/Dockerfile_Tips.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Dockerfile_Tips.md)]
---

## A typical entrypoint script

```dockerfile
 #!/bin/sh
 set -e
 
 # first arg is '-f' or '--some-option'
 # or first arg is 'something.conf'
 if [ "${1#-}" != "$1" ] || [ "${1%.conf}" != "$1" ]; then
 	set -- redis-server "$@"
 fi
 
 # allow the container to be started with '--user'
 if [ "$1" = 'redis-server' -a "$(id -u)" = '0' ]; then
 	chown -R redis .
 	exec su-exec redis "$0" "$@"
 fi
 
 exec "$@"
```

(Source: [Redis official image](https://github.com/docker-library/redis/blob/d24f2be82673ccef6957210cc985e392ebdc65e4/4.0/alpine/docker-entrypoint.sh))

.debug[[containers/Dockerfile_Tips.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Dockerfile_Tips.md)]
---

## Factoring information

To facilitate maintenance (and avoid human errors), avoid to repeat information like:

- version numbers,

- remote asset URLs (e.g. source tarballs) ...

Instead, use environment variables.

.small[
```dockerfile
ENV NODE_VERSION 10.2.1
...
RUN ...
    && curl -fsSLO --compressed "https://nodejs.org/dist/v$NODE_VERSION/node-v$NODE_VERSION.tar.xz" \
    && curl -fsSLO --compressed "https://nodejs.org/dist/v$NODE_VERSION/SHASUMS256.txt.asc" \
    && gpg --batch --decrypt --output SHASUMS256.txt SHASUMS256.txt.asc \
    && grep " node-v$NODE_VERSION.tar.xz\$" SHASUMS256.txt | sha256sum -c - \
    && tar -xf "node-v$NODE_VERSION.tar.xz" \
    && cd "node-v$NODE_VERSION" \
...
```
]

(Source: [Nodejs official image](https://github.com/nodejs/docker-node/blob/master/10/alpine/Dockerfile))

.debug[[containers/Dockerfile_Tips.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Dockerfile_Tips.md)]
---

## Overrides

In theory, development and production images should be the same.

In practice, we often need to enable specific behaviors in development (e.g. debug statements).

One way to reconcile both needs is to use Compose to enable these behaviors.

Let's look at the [trainingwheels](https://github.com/jpetazzo/trainingwheels) demo app for an example.

.debug[[containers/Dockerfile_Tips.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Dockerfile_Tips.md)]
---

## Production image

This Dockerfile builds an image leveraging gunicorn:

```dockerfile
FROM python
RUN pip install flask
RUN pip install gunicorn
RUN pip install redis
COPY . /src
WORKDIR /src
CMD gunicorn --bind 0.0.0.0:5000 --workers 10 counter:app
EXPOSE 5000
```

(Source: [trainingwheels Dockerfile](https://github.com/jpetazzo/trainingwheels/blob/master/www/Dockerfile))

.debug[[containers/Dockerfile_Tips.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Dockerfile_Tips.md)]
---

## Development Compose file

This Compose file uses the same image, but with a few overrides for development:

- the Flask development server is used (overriding `CMD`),

- the `DEBUG` environment variable is set,

- a volume is used to provide a faster local development workflow.

.small[
```yaml
services:
  www:
    build: www
    ports:
      - 8000:5000
    user: nobody
    environment:
      DEBUG: 1
    command: python counter.py
    volumes:
      - ./www:/src
```
]

(Source: [trainingwheels Compose file](https://github.com/jpetazzo/trainingwheels/blob/master/docker-compose.yml))

.debug[[containers/Dockerfile_Tips.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Dockerfile_Tips.md)]
---

## How to know which best practices are better?

- The main goal of containers is to make our lives easier.

- In this chapter, we showed many ways to write Dockerfiles.

- These Dockerfiles use sometimes diametrically opposed techniques.

- Yet, they were the "right" ones *for a specific situation.*

- It's OK (and even encouraged) to start simple and evolve as needed.

- Feel free to review this chapter later (after writing a few Dockerfiles) for inspiration!

???

:EN:Optimizing images
:EN:- Dockerfile tips, tricks, and best practices
:EN:- Reducing build time
:EN:- Reducing image size

:FR:Optimiser ses images
:FR:- Bonnes pratiques, trucs et astuces
:FR:- Réduire le temps de build
:FR:- Réduire la taille des images

.debug[[containers/Dockerfile_Tips.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Dockerfile_Tips.md)]
---

.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/Container-Ship-Freighter-Navigation-Elbe-Romance-1782991.jpg)]

---

Compose for development stacks

.nav[
[Previous part](#toc-dockerfile-examples)
|
[Back to table of contents](#toc-part-2)
|
[Next part](#toc-links-and-resources)
]

---
# Compose for development stacks

Dockerfile = great to build *one* container image.

What if we have multiple containers?

What if some of them require particular `docker run` parameters?

How do we connect them all together?

... Compose solves these use-cases (and a few more).

.debug[[containers/Compose_For_Dev_Stacks.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
---

## Life before Compose

Before we had Compose, we would typically write custom scripts to:

- build container images,

- run containers using these images,

- connect the containers together,

- rebuild, restart, update these images and containers.

.debug[[containers/Compose_For_Dev_Stacks.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
---

## Life with Compose

Compose enables a simple, powerful onboarding workflow:

1. Checkout our code.

2. Run `docker-compose up`.

3. Our app is up and running!

.debug[[containers/Compose_For_Dev_Stacks.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
---

![composeup](images/composeup.gif)

.debug[[containers/Compose_For_Dev_Stacks.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
---

## Life after Compose

(Or: when do we need something else?)

- Compose is *not* an orchestrator

- It isn't designed to need to run containers on multiple nodes

(it can, however, work with Docker Swarm Mode)

- Compose isn't ideal if we want to run containers on Kubernetes

- it uses different concepts (Compose services ≠ Kubernetes services)

- it needs a Docker Engine (althought containerd support might be coming)

.debug[[containers/Compose_For_Dev_Stacks.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
---

## First rodeo with Compose

1. Write Dockerfiles

2. Describe our stack of containers in a YAML file called `docker-compose.yml`

3. `docker-compose up` (or `docker-compose up -d` to run in the background)

4. Compose pulls and builds the required images, and starts the containers

5. Compose shows the combined logs of all the containers

(if running in the background, use `docker-compose logs`)

6. Hit Ctrl-C to stop the whole stack

(if running in the background, use `docker-compose stop`)

.debug[[containers/Compose_For_Dev_Stacks.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
---

## Iterating

After making changes to our source code, we can:

1. `docker-compose build` to rebuild container images

2. `docker-compose up` to restart the stack with the new images

We can also combine both with `docker-compose up --build`

Compose will be smart, and only recreate the containers that have changed.

When working with interpreted languages:

- dont' rebuild each time

- leverage a `volumes` section instead

.debug[[containers/Compose_For_Dev_Stacks.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
---

## Launching Our First Stack with Compose

First step: clone the source code for the app we will be working on.

```bash
git clone https://github.com/jpetazzo/trainingwheels
cd trainingwheels
```

Second step: start the app.

```bash
docker-compose up
```

Watch Compose build and run the app.

That Compose stack exposes a web server on port 8000; try connecting to it.

.debug[[containers/Compose_For_Dev_Stacks.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
---

## Launching Our First Stack with Compose

We should see a web page like this:

![composeapp](images/composeapp.png)

Each time we reload, the counter should increase.

.debug[[containers/Compose_For_Dev_Stacks.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
---

## Stopping the app

When we hit Ctrl-C, Compose tries to gracefully terminate all of the containers.

After ten seconds (or if we press `^C` again) it will forcibly kill them.

.debug[[containers/Compose_For_Dev_Stacks.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
---

## The `docker-compose.yml` file

Here is the file used in the demo:

services:
  www:
    build: www
    ports:
      - ${PORT-8000}:5000
    user: nobody
    environment:
      DEBUG: 1
    command: python counter.py
    volumes:
      - ./www:/src

redis:
    image: redis
```
]

.debug[[containers/Compose_For_Dev_Stacks.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
---

## Compose file structure

A Compose file has multiple sections:

* `version` is mandatory. (Typically use "3".)

* `services` is mandatory. Each service corresponds to a container.

* `networks` is optional and indicates to which networks containers should be connected.
 (By default, containers will be connected on a private, per-compose-file network.)

* `volumes` is optional and can define volumes to be used and/or shared by the containers.

.debug[[containers/Compose_For_Dev_Stacks.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
---

## Compose file versions

* Version 1 is legacy and shouldn't be used.

(If you see a Compose file without `version` and `services`, it's a legacy v1 file.)

* Version 2 added support for networks and volumes.

* Version 3 added support for deployment options (scaling, rolling updates, etc).

* Typically use `version: "3"`.

The [Docker documentation](https://docs.docker.com/compose/compose-file/)
has excellent information about the Compose file format if you need to know more about versions.

.debug[[containers/Compose_For_Dev_Stacks.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
---

## Containers in `docker-compose.yml`

Each service in the YAML file must contain either `build`, or `image`.

* `build` indicates a path containing a Dockerfile.

* `image` indicates an image name (local, or on a registry).

* If both are specified, an image will be built from the `build` directory and named `image`.

The other parameters are optional.

They encode the parameters that you would typically add to `docker run`.

Sometimes they have several minor improvements.

.debug[[containers/Compose_For_Dev_Stacks.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
---

## Container parameters

* `command` indicates what to run (like `CMD` in a Dockerfile).

* `ports` translates to one (or multiple) `-p` options to map ports.
 You can specify local ports (i.e. `x:y` to expose public port `x`).

* `volumes` translates to one (or multiple) `-v` options.
 You can use relative paths here.

For the full list, check: https://docs.docker.com/compose/compose-file/

.debug[[containers/Compose_For_Dev_Stacks.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
---

## Environment variables

- We can use environment variables in Compose files

(like `$THIS` or `${THAT}`)

- We can provide default values, e.g. `${PORT-8000}`

- Compose will also automatically load the environment file `.env`

(it should contain `VAR=value`, one per line)

- This is a great way to customize build and run parameters

(base image versions to use, build and run secrets, port numbers...)

.debug[[containers/Compose_For_Dev_Stacks.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
---

## Running multiple copies of a stack

- Copy the stack in two different directories, e.g. `front` and `frontcopy`

- Compose prefixes images and containers with the directory name:

`front_www`, `front_www_1`, `front_db_1`

`frontcopy_www`, `frontcopy_www_1`, `frontcopy_db_1`

- Alternatively, use `docker-compose -p frontcopy`

(to set the `--project-name` of a stack, which default to the dir name)

- Each copy is isolated from the others (runs on a different network)

.debug[[containers/Compose_For_Dev_Stacks.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
---

## Checking stack status

We have `ps`, `docker ps`, and similarly, `docker-compose ps`:

```bash
$ docker-compose ps
Name                      Command             State           Ports          
----------------------------------------------------------------------------
trainingwheels_redis_1   /entrypoint.sh red   Up      6379/tcp               
trainingwheels_www_1     python counter.py    Up      0.0.0.0:8000->5000/tcp 
```

Shows the status of all the containers of our stack.

Doesn't show the other containers.

.debug[[containers/Compose_For_Dev_Stacks.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
---

## Cleaning up (1)

If you have started your application in the background with Compose and
want to stop it easily, you can use the `kill` command:

```bash
$ docker-compose kill
```

Likewise, `docker-compose rm` will let you remove containers (after confirmation):

```bash
$ docker-compose rm
Going to remove trainingwheels_redis_1, trainingwheels_www_1
Are you sure? [yN] y
Removing trainingwheels_redis_1...
Removing trainingwheels_www_1...
```

.debug[[containers/Compose_For_Dev_Stacks.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
---

## Cleaning up (2)

Alternatively, `docker-compose down` will stop and remove containers.

It will also remove other resources, like networks that were created for the application.

```bash
$ docker-compose down
Stopping trainingwheels_www_1 ... done
Stopping trainingwheels_redis_1 ... done
Removing trainingwheels_www_1 ... done
Removing trainingwheels_redis_1 ... done
```

Use `docker-compose down -v` to remove everything including volumes.

.debug[[containers/Compose_For_Dev_Stacks.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
---

## Special handling of volumes

- When an image gets updated, Compose automatically creates a new container

- The data in the old container is lost...

- ... Except if the container is using a *volume*

- Compose will then re-attach that volume to the new container

(and data is then retained across database upgrades)

- All good database images use volumes

(e.g. all official images)

.debug[[containers/Compose_For_Dev_Stacks.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
---

## A bit of history and trivia

- Compose was initially named "Fig"

- Compose is one of the only components of Docker written in Python

(almost everything else is in Go)

- In 2020, Docker introduced "Compose CLI":

- `docker compose` command to deploy Compose stacks to some clouds

- progressively getting feature parity with `docker-compose`

- also provides numerous improvements (e.g. leverages BuildKit by default)

???

:EN:- Using compose to describe an environment
:EN:- Connecting services together with a *Compose file*

:FR:- Utiliser Compose pour décrire son environnement
:FR:- Écrire un *Compose file* pour connecter les services entre eux

.debug[[containers/Compose_For_Dev_Stacks.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/Compose_For_Dev_Stacks.md)]
---
class: title, self-paced

Thank you!

.debug[[shared/thankyou.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/shared/thankyou.md)]
---

That's all, folks! Questions?

![end](images/end.jpg)

.debug[[shared/thankyou.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/shared/thankyou.md)]
---

.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/ShippingContainerSFBay.jpg)]

---

Links and resources

.nav[
[Previous part](#toc-compose-for-development-stacks)
|
[Back to table of contents](#toc-part-2)
|
[Next part](#toc-)
]

---
# Links and resources

- [Docker Community Slack](https://community.docker.com/registrations/groups/4316)
- [Docker Community Forums](https://forums.docker.com/)
- [Docker Hub](https://hub.docker.com)
- [Docker Blog](https://blog.docker.com/)
- [Docker documentation](https://docs.docker.com/)
- [Docker on StackOverflow](https://stackoverflow.com/questions/tagged/docker)
- [Docker on Twitter](https://twitter.com/docker)
- [Play With Docker Hands-On Labs](https://training.play-with-docker.com/)

.debug[[containers/links.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/containers/links.md)]