○ le conteneurs du noyau LXC

○ les groupes de contrôle cgroups

○ les namespaces,

○ UnionFS : union file system

Namespaces

● Docker uses a technology called namespaces to provide the

isolated workspace called the container.

● When you run a container, Docker creates a set of

namespaces for that container.

● These namespaces provide a layer of isolation.

● Each aspect of a container runs in a separate namespace and

its access is limited to that namespace.

19

20

Namespaces

○ The pid namespace: Process isolation (PID: Process ID).

○ The net namespace: Managing network interfaces (NET: Networking).

○ The ipc namespace: Managing access to IPC resources (IPC:

InterProcess Communication).

○ The mnt namespace: Managing filesystem mount points (MNT:

Mount).

○ The uts namespace: Isolating kernel and version identifiers. (UTS:

Unix Timesharing System).

Control Groups (CGroups)

○ A cgroup limits an application to a specific set of resources. Control

groups allow Docker Engine to share available hardware resources

to containers and optionally enforce limits and constraints.

○ For example, you can limit the memory available to a specific

container.

21

22

Union file systems

○ Union file systems, or UnionFS, are file systems that operate by

creating layers, making them very lightweight and fast.

○ Docker Engine uses UnionFS to provide the building blocks for

containers.

○ Docker Engine can use multiple UnionFS variants, including AUFS,

btrfs, vfs, and DeviceMapper.

23

Container format

Docker Engine combines the namespaces, control groups, and

UnionFS into a wrapper called a container format. The default

container format is libcontainer. In the future, Docker may

support other container formats by integrating with technologies

such as BSD Jails or Solaris Zones.

24

Version 1.0

TABLE DES MATIÈRES

01

02

03

04

Présentation

Composantes technologiques

Architecture

Commandes principales

Approche Docker

Objectif

Exécuter plusieurs processus et applications séparément les uns des

autres afin d'optimiser l'utilisation de l’infrastructure tout en

bénéficiant du même niveau de sécurité que celui des systèmes

distincts.

25

26

Approche Docker

Réponds au besoin

Deploy highly scalable secure apps

27

Approche Docker

● Modèle de déploiement basé sur une image

○ Plus simple de partager une application ou un ensemble de services,

avec toutes leurs dépendances, entre plusieurs environnements.

● Docker permet d'automatiser le déploiement des applications

(ou d'ensembles de processus combinés qui forment une

application) au sein d'un environnement de conteneurs.

28

Architecture Docker

● Architecture Client/Serveur

○ Un serveur appelé processus

démon (commande dockerd).

○ Une API REST pour communiquer

avec le démon

○ Un client d'interface de ligne de

commande (CLI) (la commande

docker).

Architecture Docker

29

30

Creation d’image et de contenaire

TABLE DES MATIÈRES

01

02

03

04

Présentation

Composantes technologiques

Architecture

Commandes principales

Version 1.0

31

32

DEMO TIME

https://training.play-with-docker.com/ops-s1-hello/

33

34

Dr. Wassim Youssef

Version 1.0

CLOUD COMPUTING

CH03.02

Docker 02 :

• Dockerfile *

TABLE DES MATIÈRES

01

02

Rappel & Principes

Dockerfile

Version 1.0

36

Docker

37

38

Basé sur un tutoriel par MÁRK TAKÁCS

https://takacsmark.com/dockerfile-tutorial-by-example-dockerfile-best-practices-2018/

https://www.docker.com/blog/intro-guide-to-dockerfile-best-practices/

https://snyk.io/blog/10-docker-image-security-best-practices/

https://docs.docker.com/develop/develop-images/dockerfile_best-practices/

39

Docker containers

● Docker containers: containers are runtime environments.

○ Run one main process in one Docker container

○ One Docker container provides one service in your project.

■ For example : one container is your MySQL database and another container is

your Wordpress server and connect these containers together to get a Wordpress

project setup.

● We can start containers to run all the tech we can think of : it can run

databases, web servers, web frameworks, test servers, execute big data

scripts, work on shell scripts, etc.

40

Docker image

● Docker containers are started by running a Docker image.

○ A Docker image is a pre-built environment for a certain technology or service.

○ A Docker image is not a runtime, it’s rather a collection of files, libraries and

configuration files that build up an environment.

Architecture Docker

docker pull : pull the image from the docker hub (store)

docker run : runs the image and creates a running container

41

42

TABLE DES MATIÈRES

01

02

Rappel & Principes

Dockerfile

What is a Dockerfile and why you’d want to

use one?

● A Dockerfile is a text file that defines a Docker image.

● We use a Dockerfile to create our custom Docker image

○ To define our custom environment to be used in a Docker container.

● The Dockerfile contains a list of instructions that Docker will execute

when you issue the docker build command.

Version 1.0

43

44

Typical Docker workflow

1. Create the Dockerfile and define the steps that build up your images

a. The new image is generally based on an already existing image

b. The new image could also be built from scratch

2.

Issue the docker build command which will build a Docker image from

your Dockerfile

3. Use this image to start containers with the docker run command

45

Dockerfile

● The Dockerfile is a text file that (mostly) contains the instructions that you

would execute on the command line to create an image.

● A Dockerfile is a step by step set of instructions.

● Docker provides a set of standard instructions to be used in the

Dockerfile, like FROM, COPY, RUN, ENV, EXPOSE, CMD just to name a

few basic ones.

● Docker will build a Docker image automatically by reading these

instructions from the Dockerfile.

46

Dockerfile

● Understanding Dockerfile instructions is not enough to create your

Dockerfile, because you need to also understand the context of the

technology you are building for.

○ For example, building a Dockerfile to be used in a PHP project, requires to

dive into PHP specific knowledge, like configuration methods, PHP

extensions, environment settings and such.

Dockerfile

Use the command docker images in your terminal to list the images you

currently have on your computer.

47

48

DEMO TIME

https://training.play-with-docker.com/ops-s1-images/

49

50

Dr. Wassim Youssef

Version 1.0

CLOUD COMPUTING

CH03.03

Docker 03 :

• Volume/Network *

TABLE DES MATIÈRES

01

Review

02

03

Volume

Network

Version 1.0

52

Docker Engine

Docker Architecture

53

54

Dockerfile - Image - Running Container

Docker development best practices : hint1

● Keep your images small

○ Small images are faster to pull over the network and faster to load into

memory when starting containers or services

○ Start with an appropriate base image

○ Use multistage builds

○ To keep your production image lean but allow for debugging, consider using

the production image as the base image for the debug image. Additional

testing or debugging tooling can be added on top of the production image.

○ When building images, always tag them with useful tags which codify version

information, intended destination (prod or test), stability...

55

56

Docker development best practices : hint2

● Where and how to persist application data

○ Avoid storing application data in your container’s writable layer using storage

drivers. This increases the size of your container and is less efficient from an

I/O perspective than using volumes or bind mounts. Instead, store data using

volumes.

■ Bind mounts could be used during development, when you may want to mount

your source directory or a binary you just built into your container.

■ Volume should be used in production

■ For production, use secrets to store sensitive application data used by services,

and use configs for non-sensitive data such as configuration files.

57

TABLE DES MATIÈRES

01

Review

02

03

Volume

Network

Version 1.0

58

Docker storage Overview

● By default all files created inside a container are stored on a writable

container layer. This means that:

○ The data doesn’t persist when that container no longer exists, and it can be

difficult to get the data out of the container if another process needs it.

○ A container’s writable layer is tightly coupled to the host machine where the

container is running. You can’t easily move the data somewhere else.

○ Writing into a container’s writable layer requires a storage driver to manage

the filesystem. The storage driver provides a union filesystem, using the Linux

kernel. This extra abstraction reduces performance as compared to using

data volumes, which write directly to the host filesystem.

59

Choosing the right type of mount 1/4

● Docker has two options for containers to store files in the host machine, so

that the files are persisted even after the container stops:

○ volumes

○ bind mounts.

● If you’re running Docker on Linux you can also use a tmpfs mount.

● If you’re running Docker on Windows you can also use a named pipe.

● No matter which type of mount you choose to use (volume, bind, tmpfs),

the data looks the same from within the container. It is exposed as either a

directory or an individual file in the container’s filesystem.

60

Choosing the right type of mount 2/4

● Volumes are stored in a part of the host filesystem which is managed by

Docker (/var/lib/docker/volumes/ on Linux).

○ Non-Docker processes should not modify this part of the filesystem.

○ Volumes are the best way to persist data in Docker.

Choosing the right type of mount 3/4

● Bind mounts may be stored anywhere on the host system.

○ They may even be important system files or directories.

○ Non-Docker processes on the Docker host or a Docker container can modify

them at any time.

61

62

Choosing the right type of mount 4/4

● tmpfs mounts are stored in the host system’s memory only, and are never

written to the host system’s filesystem.

● When the container stops, the tmpfs mount is removed, and files written

there won't be persisted.

● Useful to temporarily

store sensitive files that

you don't want to

persist in the host or the

container writable layer.

DEMO TIME

Manipulation de volume

Notion de docker-machine

63

64

Docker volume cli

$ docker volume

Usage:

docker volume COMMAND

Manage volumes

Commands:

create Create a volume

inspect Display detailed information on one or more volumes

ls List volumes

prune Remove all unused local volumes

rm Remove one or more volumes

Run 'docker volume COMMAND --help' for more information on a command.

Docker volume cli

create a new container and update it’s content

⇒ create a new container in attached mode based on alpine image

$ docker run -it --name=container00 alpine

Unable to find image 'alpine:latest' locally [...]

⇒ inside the container, create a new file

/ # echo "hello World" > myImportantData.txt

/ # more myImportantData.txt

hello World

/ # exit

⇒ we exited from the container, list running containers

$ docker ps

⇒ nothing

65

66

Docker volume cli

restart our and check it’s content

$ docker ps

⇒ nothing, let’s list all containers

$ docker ps -a

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

a22fe9f060f1 alpine "/bin/sh" 27 seconds ago Exited (0) 7 seconds ago container00

⇒ restart the container and check data

$ docker start container00

container00

$ docker attach container00

/ # more myImportantData.txt

hello World

/ # exit

Docker volume cli

remove the container, re-create it, check for data …

$ docker rm -f container00

container00

$ docker run -it --name=container00 alpine

/ # more myImportantData.txt

more: myImportantData.txt: No such file or directory

/ # exit

67

68

Docker volume cli

remove the container, re-create it, check for data …

$ docker rm -f container00

container00

$ docker run -it --name=container00 alpine

/ # more myImportantData.txt

more: myImportantData.txt: No such file or directory

/ # exit

container content is lost

when we delete it

we should use ephemeral

containers (stateless)

Stateless containers

stateless containers

⇒ create a stateless container that will be deleted once stopped

$ docker run -it --rm alpine

/ # touch myfile.txt

/ # exit

⇒ list running containers, nothing

$ docker ps

⇒ recreate the conainer and check for the file

$ docker run -it --rm alpine

/ # more myfile.txt

more: myfile.txt: No such file or directory

69

70

docker volume cli

create a docker volume and attach it to a docker stateless container

⇒ create a volume

$ docker volume create my-vol

my-vol

⇒ list volumes

$ docker volume ls

DRIVER VOLUME NAME

local my-vol

docker volume cli

create a docker volume and attach it to a docker stateless container

⇒ create a volume

$ docker volume create my-vol

my-vol

⇒ list volumes

$ docker volume ls

DRIVER VOLUME NAME

local my-vol

71

72

docker volume cli

create a docker volume and attach it to a docker stateless container

⇒ run à container attched to this volume

$ docker run -it --rm -v my-vol:/data alpine

/ # ls /data

/ # cd /data

/data # touch myfile.txt

/data # ls

myfile.txt

/data # exit

⇒ list running containers, nothing

$ docker ps

docker volume cli

create a docker volume and attach it to a docker stateless container

⇒ create another container attached to the same volume

$ docker run -it --rm -v my-vol:/data alpine

/ # ls /data

myfile.txt

/data # exit

73

74

docker volume cli

create a docker volume and attach it to a docker stateless container

⇒ inspect volume

$ docker volume inspect my-vol

[

{

"CreatedAt": "2019-10-18T10:04:45Z",

"Driver": "local",

"Labels": {},

"Mountpoint": "/mnt/sda1/var/lib/docker/volumes/my-vol/_data",

"Name": "my-vol",

"Options": {},

"Scope": "local"

}

]

docker volume cli

create a docker volume and attach it to a docker stateless container

⇒ inspect volume

$ docker volume inspect my-vol

[

{

"CreatedAt": "2019-10-18T10:04:45Z",

"Driver": "local",

"Labels": {},

"Mountpoint": "/mnt/sda1/var/lib/docker/volumes/my-vol/_data",

"Name": "my-vol",

"Options": {},

"Scope": "local"

}

]

data is available

even with

stateless

containers

75

76

Create à container using a bind mount

$ docker run -dit --name my-apache-app -p 8080:80 \

-v "$PWD":/usr/local/apache2/htdocs/ httpd:2.4

$ echo "<b>hello</b>" > index.html

⇒ go check http://docker-machine-ip:8080

Docker-machine

● In order to run the following commands, a working docker environment is

required

● we could easily create one using docker-machine command (in linux, or

macos)

○ docker-machine creates a new virtual machine containing a clean docker

environment

○ the new docker machine could be used from host using docker cli

77

78

Docker-machine

We will use Docker Machine to create our test Docker Host. Driver's option is

set to virtualbox so the host is created on the local machine as a virtualbox VM

⇒ create a new docker machine

$ docker-machine create --driver virtualbox node1

Running pre-create checks [....]

⇒ echo env varible required to connect to node1 docker-machine

$ docker-machine env node1

export DOCKER_TLS_VERIFY="1"

export DOCKER_HOST="tcp://192.168.99.103:2376"

export DOCKER_CERT_PATH="/Users/wy/.docker/machine/machines/node1"

export DOCKER_MACHINE_NAME="node1"

Run this command to configure your shell:

eval $(docker-machine env node1)

Docker-machine

inside the docker-machine node1

⇒ configure current shell to connect to node1 docker-machine

$ eval $(docker-machine env node1)

⇒ all following commands in this shell will be executed on docker-machine node1

⇒ list running containers on docker-machine node1

$ docker ps

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

⇒ as expected, no running containers on docker-machine node1

79

80

Docker storage & volume Overview

● EXTRA LINKS

○ Official Docker documentation

■ https://docs.docker.com/storage/volumes/

■ https://docs.docker.com/storage/bind-mounts/

■ https://docs.docker.com/storage/tmpfs/

TABLE DES MATIÈRES

01

Review

02

03

Volume

Network

Version 1.0

81

82

Docker Network drivers

● Docker’s networking subsystem is pluggable, using drivers. Several drivers

exist by default, and provide core networking functionality:

○ bridge

○ host

○ overlay

○ macvlan

○ none

○ Network plugins

Docker Network drivers : bridge

● The default network driver.

● If you don’t specify a driver, this is the type of network you are creating.

● Bridge networks are usually used when your applications run in

standalone containers that need to communicate.

83

84

Docker Network drivers : host

● host: for usage with standalone containers, remove network isolation

between the container and the Docker host, and use the host’s

networking directly.

● host is only available for swarm services on Docker 17.06 and higher.

Docker Network drivers : overlay

● overlay: Overlay networks connect multiple Docker daemons together

and enable swarm services to communicate with each other.

● Overlay networks could be used to facilitate communication between a

swarm service and a standalone container, or between two standalone

containers on different Docker daemons.

○ This strategy removes the need to do OS-level routing between these

containers.

85

86

Docker Network drivers : macvlan

● macvlan: Macvlan networks allow you to assign a MAC address to a

container, making it appear as a physical device on your network.

● The Docker daemon routes traffic to containers by their MAC addresses.

● Using the macvlan driver is sometimes the best choice when dealing with

legacy applications that expect to be directly connected to the physical

network, rather than routed through the Docker host’s network stack.

Docker Network drivers : none / plugins

● none: For this container, disable all networking. Usually used in

conjunction with a custom network driver. none is not available for

swarm services.

● Network plugins: You can install and use third-party network plugins with

Docker. These plugins are available from Docker Hub or from third-party

vendors.

87

88

Network driver summary

● User-defined bridge networks : Multiple containers to communicate on the same

Docker host.

● Host networks : the network stack should not be isolated from the Docker host,

but you want other aspects of the container to be isolated.

● Overlay networks : Communication between containers running on different

Docker hosts, or when multiple applications work together using swarm services.

● Macvlan networks : migrating from a VM setup or need your containers to look

like physical hosts on your network, each with a unique MAC address.

● Third-party network plugins allow you to integrate Docker with specialized

network stacks.

89

Bridge networks

● In terms of Docker, a bridge network uses a software bridge which allows

containers connected to the same bridge network to communicate,

while providing isolation from containers which are not connected to

that bridge network.

● The Docker bridge driver automatically installs rules in the host machine

so that containers on different bridge networks cannot communicate

directly with each other.

● Bridge networks apply to containers running on the same Docker

daemon host.

90

User-defined bridges VS default bridge

User defined bridge

Default bridge

User-defined bridges VS default bridge

● Containers connected to the same user-defined bridge network :

○ Effectively expose all ports to each other

○ Better isolation and interoperability between containerized

applications

■ Automatic DNS resolution between containers

○ Containers can be attached and detached from user-defined

networks on the fly

● For a port to be accessible to containers or non-Docker hosts on different

networks, that port must be published using the -p or --publish flag.

91

92

User-defined bridges VS default bridge

● User-defined bridges provide better isolation and interoperability

between containerized applications.

○ Containers connected to the same user-defined bridge network automatically

expose all ports to each other, and no ports to the outside world. This allows

containerized applications to communicate with each other easily, without

accidentally opening access to the outside world.

○

Imagine an application with a web front-end and a database back-end. The outside world needs

access to the web front-end (perhaps on port 80), but only the back-end itself needs access to the

database host and port. Using a user-defined bridge, only the web port needs to be opened, and the

database application doesn’t need any ports open, since the web front-end can reach it over the

user-defined bridge.

User-defined bridges VS default bridge

● User-defined bridges provide automatic DNS resolution between

containers.

○ Containers on the default bridge network can only access each other by IP

addresses, unless you use the --link option, which is considered legacy. On a

user-defined bridge network, containers can resolve each other by name or

alias.

○

Imagine the same application as in the previous point, with a web front-end and a database

back-end. If you call your containers web and db, the web container can connect to the db container

at db, no matter which Docker host the application stack is running on.

93

94

User-defined bridges VS default bridge

● Containers can be attached and detached from user-defined networks

on the fly.

○ During a container’s lifetime, you can connect or disconnect it from

user-defined networks on the fly.

○ To remove a container from the default bridge network, you need to stop the

container and recreate it with different network options.

User-defined bridges VS default bridge

● Each user-defined network creates a configurable bridge.

○ If your containers use the default bridge network, you can configure it, but all

the containers use the same settings, such as MTU and iptables rules. In

addition, configuring the default bridge network happens outside of Docker

itself, and requires a restart of Docker.

○ User-defined bridge networks are created and configured using docker

network create. If different groups of applications have different network

requirements, you can configure each user-defined bridge separately, as you

create it.

95

96

User-defined bridges VS default bridge

● Linked containers on the default bridge network share environment

variables.

○ Originally, the only way to share environment variables between two

containers was to link them using the --link flag.

○ This type of variable sharing is not possible with user-defined networks.

User-defined bridges VS default bridge

● Linked containers on the default bridge network share environment

variables.

● Sharing environment variable between containers using user defined

network could be achieved through :

○ Multiple containers can mount a file or directory containing the shared

information, using a Docker volume.

○ Multiple containers can be started together using docker-compose and the

compose file can define the shared variables.

○ You can use swarm services instead of standalone containers, and take

advantage of shared secrets and configs.

97

98

DEMO TIME

Docker network cli

$ docker network

Usage: docker network COMMAND

Manage Docker networks

Options:

--help Print usage

Commands:

connect Connect a container to a network

create Create a network

disconnect Disconnect a container from a network

inspect Display detailed information on one or more networks

ls List networks

rm Remove one or more networks

99

100

Docker network cli

List networks

$ docker network ls

NETWORK ID NAME DRIVER

18a2866682b8 none null

c288470c46f6 host host

7b369448dccb bridge bridge

// list supported network drivers

$ docker info | grep Network

Network: bridge host ipvlan macvlan null overlay

Docker network cli

create a new container named container01 attached to default bridge

network based on alpine image

$ docker run -itd --name=container01 alpine

74695c9cea6d9810718fddadc01a727a5dd3ce6a69d09752239736c030599741

$ docker network inspect bridge

// will print details on default bridge that helps identify container ip

101

102

Docker network cli

identify internal ip associated with the created container

$ docker network inspect bridge --format='{{json .Containers}}' | python -m

json.tool

{

"cbd2cd744cdf86d0551b3ec10009df9d3336ddff6ce110ce084fa2103be2222e": {

"EndpointID":

"f441082fb6f8a396b5c02caf0cb5b554453b7ae6fd8742a1ce604eb1ce5bbce2",

"IPv4Address": "172.17.0.2/16",

"IPv6Address": "",

"MacAddress": "02:42:ac:11:00:02",

"Name": "container01"

}

}

Docker network cli

create a second container container02 attached to default bridge network

based on on busybox image and try to ping the container01

$ docker run -it --name=container02 busybox /bin/sh

⇒ here we are in interactive mode, inside the busybox container

/ # ping container01

ping: bad address 'container01'

⇒ no response, unable to resolve container by name, let’s test connexion by IP

/ # ping 172.17.0.2

PING 172.17.0.2 (172.17.0.2): 56 data bytes

64 bytes from 172.17.0.2: seq=0 ttl=64 time=0.203 ms

64 bytes from 172.17.0.2: seq=1 ttl=64 time=0.152 ms

⇒ connexion possible via IP

$ docker network inspect bridge

// will print details on default bridge that helps identify container ip

103

104

Docker network cli

create a second container container02 attached to default bridge network

based on on busybox image and try to ping the container01

$ docker run -it --name=container02 busybox /bin/sh

⇒ here we are in interactive mode, inside the busybox container

Container are connected via default

/ # ping container01

bridge that doesn't offer DNS resolution

ping: bad address 'container01'

⇒ no response, unable to resolve container by name, let’s test connexion by IP

/ # ping 172.17.0.2

PING 172.17.0.2 (172.17.0.2): 56 data bytes

64 bytes from 172.17.0.2: seq=0 ttl=64 time=0.203 ms

64 bytes from 172.17.0.2: seq=1 ttl=64 time=0.152 ms

⇒ connexion possible via IP

Let’s create à user defined bridge and

start over

$ docker network inspect bridge

// will print details on default bridge that helps identify container ip

Docker network cli

stop and restart the container attached to myBridgeNetwork

$ docker network create myBridgeNetwork

9ee7e9d379c834960ad18476d21ecba1ba965da5aa4fb42e9c5d0e14dce22adb

$ docker network ls

NETWORK ID NAME DRIVER SCOPE

ac3b7ddf68e5 bridge bridge local

50aefffe4b06 host host local

9ee7e9d379c8 myBridgeNetwork bridge local

9cd3368ad349 none null local

105

106

Docker network cli

re-run the containers attached to myBridgeNetwork

⇒ delete the containers

$ docker rm -f container01

$ docker rm -f container02

⇒ start them attached to myBridgeNetwork (first detached, second attached)

$ docker run -itd --name=container01 --net myBridgeNetwork alpine

ded231d65b4db99e3bc8339258b672a6520f79354b0d2976b711118ffd1ab620

$ docker run -it --name=container02 --net myBridgeNetwork busybox /bin/sh

/ # ping container01

PING container01 (192.168.16.2): 56 data bytes

64 bytes from 192.168.16.2: seq=0 ttl=64 time=0.168 ms

..

Docker network cli

re-run the containers attached to myBridgeNetwork

⇒ delete the containers

$ docker rm -f container01

$ docker rm -f container02

⇒ start them attached to myBridgeNetwork (first detached, second attached)

Containers are

connected via

user defined

bridge and are

able to perform

DNS resolution

Containers are

deleted then re

$ docker run -itd --name=container01 --net myBridgeNetwork alpine

created

ded231d65b4db99e3bc8339258b672a6520f79354b0d2976b711118ffd1ab620

$ docker run -it --name=container02 --net myBridgeNetwork busybox /bin/sh

/ # ping container01

PING container01 (192.168.16.2): 56 data bytes

64 bytes from 192.168.16.2: seq=0 ttl=64 time=0.168 ms

..

107

108

Docker network cli

attach to user defined bridge without re-creating the containers

⇒ create a new container in detached mode

$ docker run -itd --name=container03 busybox /bin/sh

⇒ attach to container03

$ docker attach container03

⇒ test connexion to container02 using DNS resolution

/ # ping container02

ping: bad address 'container02'

109

Docker network cli

attach to user defined bridge without re-creating the containers

using another shell session out container03

⇒ list containers

$ docker ps

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

f671100419aa busybox "/bin/sh" 9 minutes ago Up About a minute container03

6e048c4b25c7 busybox "/bin/sh" 19 minutes ago Up 19 minutes container02

ded231d65b4d alpine "/bin/sh" 19 minutes ago Up 19 minutes container01

⇒ connect running container03 to myBridgeNetwork

$ docker network connect myBridgeNetwork container03

⇒ in the running container03 shell

/ # ping container02

PING container02 (192.168.16.3): 56 data bytes

64 bytes from 192.168.16.3: seq=0 ttl=64 time=0.152 ms

110

Docker network cli

attach to user defined bridge without re-creating the containers

using another shell session out container03

⇒ list containers

$ docker ps

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

f671100419aa busybox "/bin/sh" 9 minutes ago Up About a minute container03

6e048c4b25c7 busybox "/bin/sh" 19 minutes ago Up 19 minutes container02

ded231d65b4d alpine "/bin/sh" 19 minutes ago Up 19 minutes container01

⇒ connect running container03 to myBridgeNetwork

Containers could be connected via user

defined bridge and are able to perform DNS

resolution, without restart

$...