ATOMIT
ATOMIT
Site de Partage de Connaissance
Aller au contenu principal
Accueil
WINDOWS
LINUX
Mon CV
Contact
Les Bases Sur DOCKER
Dans ce tutoriel nous allons voir comment fonctionne docker et nous allons présenter quelques
fonctionnalités incontournables de docker. Si vous lisez cet article, nous supposons que vous avez
déjà lu notre article précédent sur la découverte de docker ou alors vous avez lu d’autres articles sur
internet, donc vous savez au moins ce qu’est docker. Mais ne vous inquiétez pas, la présentation est
très explicite donc pas besoin d’être un pro sur docker pour lire cet article il faut juste savoir de quoi
il est question. Bon assez bavardé…. Action.
1. Dockerfile et Cycle de vie d’un conteneur
1.1. Cycle de vie des images et des conteneurs
Avant toute chose il est important de savoir que sur docker nous manipulons des Dockerfile qui sont
compilés en images et ensuite instanciés en Conteneur. Donc en gros l’on part d’un fichier Dockerfile
qui nous permet de construire une image qui une fois instanciée va devenir un conteneur. Le
conteneur ainsi instancié reste toutefois lié à son image de départ.
Voici un schéma illustrant le cycle de vie d’un conteneur avec les commandes du client Docker :
2
Quelque commandes qui vous seront surement très utiles :
docker images : Lister les images présentes en local
docker ps : Liste les conteneurs démarrés
docker ps –a : Liste tous les conteurs (ceux qui sont démarrés, arrêtés normalement ou après une
erreur)
docker log : attache la sortis console à celle du conteneur.
docker stop $(docker ps -q) : arrêter tous les conteneurs lancés d’un coup de baguette magique.
docker start $(docker ps -q) : relancer en même temps tous les conteneurs qui ont été arrêtés et qui
sont en mémoire.
docker exec -it Nom_Du_Conteneur /bin/bash : Se connecter au Shell d’un conteneur.
docker rm $(docker ps -a -q --filter "status=exited") : Effacer tous les conteneurs arrêtés d’un coup
de baguette magique.
1.2 Dockerfile
Le fichier qui nous permet de créer des images s’appelle un Dockerfile. C’est un fichier qui permet de
décrire comment une image sera construite avec la commande docker build. Il contient le nom de
l’ensemble des paquets qui seront installés dans l’image, les répertoires qui seront partagés par
l’image, les ports qui seront exposés, l’ensemble des variables d’environnements qui seront
instanciés de base, etc.
Syntaxe
Voici la syntaxe de base d’un Dockerfile qui vous permettra de décrire une image et la manière dont
elle sera créée:
MAINTAINER <name>
FROM <image>
ENV <key> <value>
ADD <src> <dest>
VOLUME ["/<dir>"]
USER <user>
EXPOSE <port>
RUN <command> ou RUN ["exécutable", "param1", "param2"]
CMD <command> ou CMD ["exécutable", "param1", "param2"]
Légende :
MAINTAINER <name> : Auteur de l’image vous pouvez mettre votre nom par exemple
FROM <image> : Nom de l’image de base. Cela permet de ne pas partir de rien et d’utiliser une image
existante. Par exemple se base sur une image Debian pour créer un conteneur APACHE.
ENV <key> <value> : Permets de définir des variables d’environnement qui seront créées lors de
l’instanciation du conteneur. Ex : MYSQL_PASSWORD qui permettra à celui qui lance l’instance du
conteneur de passer le mot de passe de SQL via l’option -e.
ADD <src> <dest> : Il permet de récupérer des fichiers en local et de les uploader dans l’image lors de
sa compilation. Ces fichiers feront désormais partie de l’image.
VOLUME [« /<dir> »] : Répertoire monté au démarrage du conteneur et qui est externe à celui-ci.
Cela permet de rendre des fichiers du conteneur directement accessible sur l’hôte.
USER <user> : Permets d’indiquer l’utilisateur Linux qui sera utilisé lors du démarrage du conteneur.
EXPOSE <port> : Permet d’indiquer les ports réseaux exposés par le conteneur. Il définir sur quels
ports réseau les conteneurs communiquent avec l’extérieur.
RUN <command> ou RUN [« exécutable », « param1 », « param2 »] : Il permet d’exécuter une
commande sur l’image lors de sa création. Ex : run apt-get install apache
CMD <command> ou CMD [« exécutable », « param1 », « param2 »] :
il faut noter qu’il ne doit y avoir qu’un seul CMD dans un Dockerfile. c’est une commande qui est
lancée dans les conteneurs qui utilisent cette image à chacun de leurs démarrages.
Si l’image contient le serveur NGINX, il peut s’agir de lancer l’exécution du serveur NGINX au
démarrage du conteneur.
La commande n’est lancée qu’à l’exécution du conteneur et non durant la construction de l’image
Cette commande peut être redéfinie dans la commande de lancement du conteneur (Docker run)
2. Réseau et partage de fichier sous docker
Sachez-le. Quoi que vous fassiez sur docker, quel que soit l’architecture que vous déciderez de
mettre en place vous utiliserez forcement de manière consciente ou non le réseau et/ou le partage
de fichier.
1.1 Partage de fichier
Le partage de fichier se fait dans un conteneur en réalisant le montage de volumes disques ce qui
permettra à un conteneur d’utiliser le contenu d’un répertoire de la machine hôte. Le conteneur peut
ainsi avoir des fichiers que nous aurons définis (fichier de conf par exemple) lors de son premier
démarrage et ces fichiers sont stockés sur la machine hôte donc ils ne seront pas effacés lors de
l’arrêt et de la suppression du conteneur.
Le partage de fichiers nécessite de :
Créer le répertoire de partage sur la machine hôte (machine utilisée pour le lancement du
conteneur)
Spécifier le répertoire de partage au sein du conteneur (dans le Dockerfile)
Ajouter la ligne suivante dans le fichier Dockerfile pour indiquer quel répertoire du conteneur sera
partagé :
VOLUME [« [répertoire du conteneur] »]
Au lancement du conteneur, indiquer le mapping entre le répertoire de partage du conteneur et la
machine hôte.
Dans la commande docker run, ajouter l’option -v [répertoire de la machine hôte]:[répertoire du
conteneur] pour mapper le répertoire de la machine hôte avec celui du conteneur:
docker run -v [host directory]:[container directory]
ajouter :ro à la fin pour activer la lecture seule :
docker run -v [host directory]:[container directory]:ro
1.2 Communications réseau.
L’interfaçage réseau permet à un conteneur de communiquer avec l’extérieur et/ou avec les autres
conteneurs. Pour définir l’interfaçage réseau, il est nécessaire de :
Exposer le port réseau du conteneur :
soit dans le fichier Dockerfile de l’image : EXPOSE [port conteneur]
soit via l’option –expose de la commande docker run : –expose [port conteneur]
Pour que le port réseau du conteneur soit accessible à l’extérieur de la machine hôte nous devons
mapper le port réseau du conteneur avec celui de la machine hôte via l’option -p de la commande
docker run. Le mappage peut être manuel ou automatique :
Pour Mapper manuellement les ports. Dans ce cas nous fixons manuellement qu’elles port de
l’hôte et du conteneur seront mappez ensemble.
Utilisation :
docker run -p ip :port/protocole
docker run -p [port hôte]:[port conteneur]
docker run -p [IP]:[port hôte]:[port conteneur]
docker run -p [IP]:[port hôte]:[port conteneur]/[protocol]
NB :
[IP] : Adresse IP (non obligatoire),
[port hôte] : Port de la machine hôte,
[port conteneur] : Port du conteneur,
[protocol] : Protocol réseau (non obligatoire) (exemple : tcp ou udp).
Il est possible de définir plusieurs mapping de ports à l’aide de plusieurs options -p dans la même
commande docker run: docker run … -p 80:80 -p 8080:8080
Mapper automatiquement tous les ports exposés d’un conteneur avec des ports livre de la
machine hôte.
L’option -P de docker run utilisée toute seule sans spécification de numéro de port permet de
mapper chacun des ports exposés d’un conteneur sur un des ports de la machine hôte sur une plage
comprise entre 49000 et 49900.
docker run ... -p
Il faudrait alors lancer la commande docker ps pour voir sur quels ports de la machine hôte sont
mappés les ports du conteneur.
Pour qu’un conteneur puisse communiquer directement avec un autre conteneur sans forcément
avoir besoin de leur affecter des ports sur la machine hôte, il est nécessaire de lié les 2 conteneurs.
Pour cela on lance un 1er conteneur et ensuite au lancement du 2ème conteneur on le lie au 1er.
Cela permet ainsi au 2ème conteneur d’avoir des informations sur le 1er Conteneur. On devra donc
lancer le 2ème conteneur avec en plus le paramètre.
Docker run … --link=[nom conteneur lié]:[alias du conteneur]
[nom conteneur lié] : Nom du conteneur lié qui doit être en cours d’exécution (le nom de conteneur
doit avoir été défini lors du lancement de ce conteneur via l’option –name de la commande docker
run)
[alias lien] : alias du lien dans le conteneur
Docker vas fournir au deuxième conteneur les variables d’environnement qui ont été déclarées pour
le 1er conteneur dans le fichier Dockerfile ou via la commande docker run (via l’aide des options -e).
Ces variables d’environnements sont préfixés par le nom de l’alias qui a été formaté en majuscules.
Ex: Pour un alias apache, les variables d’environnement commencent par APACHE_.
Le conteneur lié doit être en cours d’exécution et doit donc être dans la liste des conteneurs en cours
d’exécution via la commande docker ps. Le nom d’alias sert au nommage des variables
d’environnement dans le conteneur qui va appeler le 1er. Donc en gros pour le 2ème conteneur
c’est-à-dire celui qui appel. Le conteneur 1 nommé [nom conteneur lié] sur la machine hôte aura
pour nom [alias lien] dans le conteneur.
Voilà en gros à quoi cela peut ressembler schématiquement.
Le conteneur 1 expose le port 111. Nous démarrons le premier conteneur :
docker run -d --name conteneur1 --expose 111 demo/image1
Nous démarrons un second conteneur en le liant avec le premier conteneur :
docker run -d --name conteneur2 -P --link conteneur1:in_conteneur1 demo/image2
Docker ajoute dans le conteneur 2 des variables d’environnement concernant le conteneur 1 pour
chaque port exposé par le conteneur 1 :
Pour le port 111 du conteneur 1 :
IN_CONTENEUR1_PORT_111_TCP_ADDR=172.17.0.2
IN_CONTENEUR1_PORT_111_TCP_PORT=111
IN_CONTENEUR1_PORT_111_TCP_PROTO=tcp
Nous pouvons ainsi récupérer l’adresse IP du conteneur lié pour que le conteneur 2 puisse
communiquer avec le conteneur 1.
Si le conteneur 1 exposait le port 22 avec un serveur SSH, le conteneur 2 pourra se connecter en SSH
sur ce premier conteneur via le port 22 et en utilisant la variable d’environnement contenant
l’adresse IP « IN_CONTENEUR1_PORT_22_TCP_ADDR« .
Exemple : MySql + Drupal
Démarrer conteneur SQL
docker run -d -v /home/joel/data/webstack/bdd/:/var/lib/mysql -e
MYSQL_ROOT_PASSWORD=docker2016 --name webstack_mysql mysql
Démarrer Conteneur Drupal lié à SQL
docker run --name drupal_01 --link webstack_mysql:mysql -p 3001:80 -d drupal
Démarrage de WordPress lié à SQL
docker run --name wordpress_01 --link webstack_mysql:mysql -v
/data/webstack/wordpress/1/:/var/www/html/ -p 3002:80 -d wordpress
Attention: il n’est possible de communiquer qu’avec les ports exposés d’un conteneur. Même entre 2
conteneur lié.
1.3 Changer les paramètres spécifiés lors de l’exécution du conteneur
Il n’y a pas de commande docker pour modifier les informations spécifiées via la commande docker
run du conteneur lors de l’exécution de celui-ci, que ce soit le mapping des ports réseau ou des
fichiers.
Il faut alors enregistrer l’état ‘Commiter’ et redémarrer le conteneur en spécifiant le nouveau
mapping de ports ou de fichiers. Lors du commit, il faut indiquer le nouveau nom d’image d’export
qui sera utilisé pour redémarrer le conteneur à partir de cette image (en gros c’est le nom de l’image
de sauvegarde). Il ne faut pas utiliser le nom de l’image initial qui avait servi lors du premier
démarrage du conteneur.
docker commit [identifiant] [nom image temporaire]
docker run (…) [nom image temporaire] (…)
3. Webographie
Blog2dev « Réseau et Fichiers »
Partager :
Cliquez pour partager sur Twitter(ouvre dans une nouvelle fenêtre)Cliquez pour partager sur
Facebook(ouvre dans une nouvelle fenêtre)Cliquez pour partager sur Google+(ouvre dans une
nouvelle fenêtre)
Articles similaires
Sauvegarde / Restauration de Conteneurs DOCKER23 novembre 2016Dans "LINUX"
Les Bonnes Pratiques Docker23 novembre 2016Dans "LINUX"
DÉCOUVERTE DE DOCKER10 octobre 2016Dans "LINUX"
www.pdf24.org Envoyer l'article en PDF
Taggé CONTENEUR, DEBIAN, DOCKER, LINUX, SERVEUR.Mettre en favori le Permaliens.
« DÉCOUVERTE DE DOCKER
SharePoint APP Store »
Laisser un commentaire
Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *
Commentaire
Nom *
Adresse de messagerie *
Site web
Prévenez-moi de tous les nouveaux commentaires par e-mail.
Prévenez-moi de tous les nouveaux articles par e-mail.
Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos
commentaires sont utilisées.
Rechercher Un Article
Rechercher :
Articles récents
Migration d’une VM d’HYPER-V vers PROXMOX
Installation de docker sur Debian 9
Mise en place du service NFS
Service SSH sous Debian
Configuration Serveur FTP + SSL sous DEBIAN
Traduire
Powered by Google TranslateTranslate
Accueil
WINDOWS
LINUX
Mon CV
Contact
Pour faire ses preuves il faut devenir le meilleur !!!
ATOMIT | Fièrement propulsé par Mantra & WordPress.