Le terme « DOCKER » désigne plusieurs choses : le projet d'une communauté Open Source, les outils issus de ce projet Open Source, l'entreprise Docker Inc. qui constitue le principal soutien de ce projet, ainsi que les outils que l'entreprise prend officiellement en charge. Des technologies et une entreprise qui partagent le même nom, cela peut prêter à confusion.

Voici donc une rapide explication de cet état de fait.

• Le logiciel « Docker » est une technologie de conteneurisation qui permet la création et l'utilisation de conteneurs Linux®.
• La communauté Open Source Docker travaille à l'amélioration de cette technologie disponible gratuitement pour tout le monde.
• L'entreprise Docker Inc. s'appuie sur le travail de la communauté Docker, sécurise sa technologie et partage ses avancées avec tous les utilisateurs. Elle prend ensuite en charge les technologies améliorées et sécurisées pour ses clients professionnels.

Docker est une plate-forme logicielle qui vous permet de concevoir, tester et déployer des applications rapidement. Docker intègre les logiciels dans des unités normalisées appelées conteneurs, qui rassemblent tous les éléments nécessaires à leur fonctionnement, dont les bibliothèques, les outils système, le code et l'environnement d'exécution. Avec Docker, vous pouvez facilement déployer et dimensionner des applications dans n'importe quel environnement, avec l'assurance que votre code s'exécutera correctement.

Un conteneur Linux est un ensemble de processus qui sont isolés du reste du système. Un conteneur s'exécute à partir d'une image distincte qui fournit tous les fichiers nécessaires à la prise en charge des processus qu'il contient. En fournissant une image qui contient toutes les dépendances d'une application, le conteneur assure la portabilité et la cohérence de l'application entre les divers environnements (développement, test puis production).

Pour mieux comprendre ce qu'est un conteneur, imaginons que vous êtes en train de développer une application. Vous travaillez sur un ordinateur portable dont l'environnement présente une configuration spécifique. D'autres développeurs peuvent travailler sur des machines qui présentent des configurations légèrement différentes. L'application que vous développez repose sur cette configuration et dépend de fichiers spécifiques. En parallèle, votre entreprise exploite des environnements de test et de production qui sont standardisés sur la base de configurations qui leur sont propres et de l'ensemble des fichiers associés.

Vous souhaitez émuler ces environnements autant que possible localement, mais sans avoir à payer les coûts liés à la recréation des environnements de serveur. Comment faire pour que votre application en développement puisse fonctionner dans ces environnements, passer l'assurance qualité et être déployée sans prise de tête, sans réécriture et sans correctifs ? La réponse est simple : il vous suffit d'utiliser des conteneurs. Le conteneur qui accueille votre application contient toutes les configurations (et les fichiers) nécessaires. Vous pouvez ainsi le déplacer entre les environnements de développement, de test et de production, sans aucun effet secondaire. La crise est évitée, le travail peut continuer.

Oui et non. Voyons pourquoi avec ces deux définitions simples :

• La virtualisation permet à de nombreux systèmes d'exploitation de s'exécuter simultanément sur un seul système.
• Les conteneurs partagent le même noyau de système d'exploitation et isolent les processus de l'application du reste du système.

Qu'est-ce que cela signifie ? Tout d'abord, l'exécution de plusieurs systèmes d'exploitation sur un hyperviseur (le logiciel qui permet la virtualisation) n'est pas une solution aussi légère que les conteneurs. Lorsque vous disposez de ressources limitées, aux fonctionnalités limitées, il est nécessaire que vos applications soient légères et puissent être déployées de manière dense.

Les conteneurs Linux s'exécutent sur cet unique système d'exploitation, qu'ils partagent entre eux. Vos applications et services restent ainsi légers et s'exécutent rapidement en parallèle.

La technologie Docker utilise le noyau Linux et des fonctions de ce noyau, telles que les groupes de contrôle cgroups et les espaces de noms, pour séparer les processus afin qu'ils puissent s'exécuter de façon indépendante. Cette indépendance reflète l'objectif des conteneurs : exécuter plusieurs processus et applications séparément les uns des autres afin d'optimiser l'utilisation de votre infrastructure tout en bénéficiant du même niveau de sécurité que celui des systèmes distincts.

Les outils de conteneurs, y compris Docker, sont associés à un modèle de déploiement basé sur une image. Il est ainsi plus simple de partager une application ou un ensemble de services, avec toutes leurs dépendances, entre plusieurs environnements. Docker permet aussi 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.

Ces outils conçus sur des conteneurs Linux offrent aux utilisateurs un accès sans précédent aux applications, la capacité d'accélérer le déploiement, ainsi qu'un contrôle des versions et de l'attribution des versions.

Les conteneurs Linux traditionnels utilisent un système init capable de gérer plusieurs processus. Ainsi, des applications entières peuvent s'exécuter comme un bloc. La technologie Docker encourage la décomposition des applications en processus distincts et fournit les outils nécessaires. Cette approche granulaire présente bien des avantages.

L'architecture Docker utilise un modèle client-serveur et comprend les composants Client Docker, Hôte Docker, Réseau et Stockage, ainsi que le Registre / Hub Docker.

Examinons chacune d'elles en détail.

Le client Docker permet aux utilisateurs d'interagir avec Docker. Le client Docker peut résider sur le même hôte que le démon ou se connecter à un démon sur un hôte distant. Un client peut communiquer avec plusieurs démons.

Le client Docker fournit une interface de ligne de commande qui vous permet d'envoyer des commandes de génération, d'exécution et d'arrêt à un démon Docker.

L'objectif principal du client Docker est de fournir un moyen de diriger l'extraction des images d'un registre et de le faire fonctionner sur un hôte Docker.

Les commandes courantes émises par un client sont:

# docker build
# docker pull
# docker run

L'hôte Docker fournit un environnement complet pour exécuter et lancer des applications. Il comprend le démon Docker, les images, les conteneurs, les réseaux et le stockage.

Comme mentionné précédemment, le démon est responsable de toutes les actions liées au conteneur et reçoit des commandes via la CLI ou l'API REST. Il peut également communiquer avec d'autres démons pour gérer ses services. Le démon Docker extrait et construit les images de conteneur à la demande du client.

Une fois l'image demandée extraite, il crée un modèle de travail pour le conteneur en utilisant un ensemble d'instructions appelé fichier de construction. Le fichier de construction peut également inclure des instructions permettant au démon de pré-charger d'autres composants avant d'exécuter le conteneur, ou des instructions à envoyer à la ligne de commande locale une fois le conteneur créé.

Divers objets sont utilisés dans l'assemblage de votre application. Les principaux objets Docker requis sont:

Les images sont un modèle binaire en lecture seule utilisé pour créer des conteneurs. Les images contiennent également des métadonnées décrivant les capacités et les besoins du conteneur. Celles-ci sont utilisées pour stocker et livrer des applications.

Une image peut être utilisée seule pour construire un conteneur ou personnalisée pour ajouter des éléments supplémentaires afin d'étendre la configuration actuelle. Elles peuvent être partagées entre les équipes d'une entreprise à l'aide d'un registre de conteneurs privé ou partagées avec le monde entier à l'aide d'un registre public tel que Docker Hub.

Les images font partie intégrante de l'expérience Docker car elles permettent une collaboration entre développeurs d'une manière qui était impossible auparavant.

Les conteneurs sont des environnements encapsulés dans lesquels vous exécutez des applications. Celui-ci est défini par l'image et par toute option de configuration supplémentaire fournie au démarrage du conteneur, notamment les connexions réseau et les options de stockage.

Les conteneurs ont uniquement accès aux ressources définies dans l'image, sauf si un accès supplémentaire est défini lors de la création de l'image dans un conteneur. Vous pouvez également créer une nouvelle image en fonction de l'état actuel d'un conteneur.

Étant donné que les conteneurs sont beaucoup plus petits que les ordinateurs virtuels, ils peuvent être activés en quelques secondes et améliorer considérablement la densité du serveur.

Docker implémente la mise en réseau de manière orientée application et fournit diverses options tout en conservant suffisamment d'abstraction pour les développeurs.

Il existe essentiellement deux types de réseaux disponibles: le réseau Docker par défaut et les réseaux définis par l'utilisateur.

Par défaut, vous obtenez trois réseaux différents lors de l'installation de Docker: None, Default Bridge et Host.

• none : pas de réseau (sauf l'interface loopback)
• host : on partage la pile IP de l’hôte (donc les ports …)
• default bridge : crée automatiquement une passerelle et un sous-réseau IP et tous les conteneurs appartenant à ce réseau. Ceux-ci peuvent communiquer entre eux via un adressage IP. Ce réseau n'est pas couramment utilisé car il ne s'adapte pas bien et a des contraintes en termes de facilité d'utilisation et de découverte de services.

Les autres type de réseau sont ceux défini par l'utilisateur. Il y a trois types de réseaux :

• Bridge network : Semblable au réseau Default Brigde, un réseau Bridge défini par l'utilisateur diffère en ce qu'il n'est pas nécessaire de transférer les ports pour que les conteneurs du réseau puissent communiquer entre eux. L'autre différence est qu'il prend totalement en charge la découverte automatique du réseau.
• Overlay network : Un réseau Overlay est utilisé lorsque vous avez besoin de conteneurs sur des hôtes distincts pour pouvoir communiquer entre eux, comme dans le cas d'un réseau distribué.
• Macvlan network : Lorsque vous utilisez des réseaux Bridge et Overlay, un bridge réside entre le conteneur et l'hôte. Un réseau Macvlan supprime ce pont, offrant l'avantage d'exposer les ressources de conteneur à des réseaux externes sans traiter le transfert de port. Ceci est réalisé en utilisant des adresses MAC au lieu d'adresses IP.

L'approche de Docker en matière de conteneurisation repose sur la décomposition des applications : c'est-à-dire la capacité de réparer ou de mettre à jour une partie d'une application sans devoir désactiver l'ensemble de cette dernière. En plus de cette approche basée sur les microservices, Docker vous permet de partager des processus entre différentes applications quasiment comme vous le feriez avec une architecture orientée services (SOA).

Chaque fichier image Docker est composé d'une série de couches. Ces couches sont assemblées dans une image unique. Chaque modification de l'image engendre la création d'une couche. Chaque fois qu'un utilisateur exécute une commande, comme run ou copy, une nouvelle couche se crée.

Docker réutilise ces couches pour la construction de nouveaux conteneurs, accélérant ainsi le processus de construction. Les modifications intermédiaires sont partagées entre les images, ce qui optimise la vitesse, la taille et l'efficacité. Qui dit superposition de couches, dit contrôle des versions. À chaque changement, un journal des modifications est mis à jour afin de vous offrir un contrôle total des images de votre conteneur.

La fonction la plus intéressante de la superposition de couches est sans doute la restauration. Chaque image est composée de couches. Aussi, si l'itération actuelle d'une image ne vous convient pas, vous pouvez restaurer la version précédente. Cette fonction favorise le développement agile et vous aide à mettre en œuvre les pratiques d'intégration et de distribution continues (CI/CD) au niveau des outils.

Avant, il fallait plusieurs jours pour mettre en place du nouveau matériel, l'exécuter, l'approvisionner et le rendre disponible. C'était un processus complexe et fastidieux. Aujourd'hui, avec les conteneurs Docker, vous pouvez effectuer tout cela en quelques secondes seulement. En créant un conteneur pour chaque processus, vous pouvez rapidement partager les processus similaires avec les nouvelles applications. De plus, comme vous n'avez pas besoin de redémarrer le système d'exploitation pour ajouter ou déplacer un conteneur, le délai de déploiement s'en trouve encore réduit. Et ce n'est pas tout. La vitesse du déploiement est telle que vous pouvez vous permettre de créer et de détruire facilement et à moindre coût les données de vos conteneurs, sans aucun problème.

Pour résumer, la technologie Docker propose une approche plus granulaire, contrôlable et basée sur des microservices, qui place l'efficacité au cœur de ses objectifs.

Docker est une technologie très efficace pour la gestion de conteneurs uniques. Cependant, à mesure qu'augmente le nombre de conteneurs et d'applications conteneurisées (tous décomposés en centaines de composants), la gestion et l'orchestration se complexifient. Au final, vous devez prendre du recul et regrouper plusieurs conteneurs pour assurer la distribution des services (réseau, sécurité, télémétrie, etc.) vers tous vos conteneurs.

C'est précisément à ce niveau qu'intervient la technologie Kubernetes.

Avec Docker, vous ne profitez pas des mêmes fonctionnalités de type UNIX qu'offrent les conteneurs Linux traditionnels, c'est-à-dire que vous ne pouvez notamment pas utiliser de processus tels que cron ou syslog au sein du conteneur, en parallèle de votre application. Il existe aussi des limites au niveau du nettoyage des processus petits-enfants après l'arrêt des processus enfants, alors que ce nettoyage était effectué par les conteneurs Linux traditionnels. Vous pouvez contourner ces problèmes en modifiant le fichier de configuration et en configurant ces fonctions dès le début, même si ce n'est pas immédiatement évident.

De plus, il existe d'autres sous-systèmes et périphériques Linux qui n'appartiennent pas à un espace de noms, notamment les périphériques SELinux, cgroups et /dev/sd*. Cela signifie que si un pirate prenait le contrôle de ces sous-systèmes, l'hôte serait compromis. Afin de préserver sa légèreté, le noyau de l'hôte est partagé avec les conteneurs, ce qui ouvre une brèche de sécurité. Ce n'est pas le cas avec les machines virtuelles, car elles sont bien mieux isolées du système hôte.

Le démon Docker peut également poser des problèmes de sécurité. Pour utiliser et exécuter des conteneurs Docker, il est conseillé d'utiliser le démon Docker, qui s'exécute en permanence pour la gestion des conteneurs. Le démon Docker nécessite des privilèges root, il est donc important de surveiller l'accès à ces processus, ainsi qu'à leur emplacement. Par exemple, un démon en local est plus difficile à attaquer qu'un démon qui réside dans un emplacement public, comme un serveur Web.

Les conteneurs sont moins isolés les uns des autres que les machines virtuelles. Le travail d’un conteneur consiste à empaqueter et à distribuer des applications, mais tous ceux disponibles sur le Web, ainsi que toutes les librairies et les composants qu’ils contiennent, ne sont pas forcément dignes de confiance. Une étude récente montre que 67 % des entreprises prévoient de commencer à utiliser des conteneurs d’ici 2 ans mais 60 % disent qu’ils sont préoccupés par les problèmes de sécurité.

Selon Adrian Mouat (Container Solutions), il y a cinq choses à retenir lors d’un examen de sécurité d’un conteneur Docker :

• Faille dans le noyau : Contrairement à une machine virtuelle, le noyau est partagé entre tous les conteneurs et le système hôte. Si un conteneur provoque une panique du noyau, il emportera tout le système hôte,
• Attaques par déni de service : Les conteneurs partagent des ressources du noyau, donc si un conteneur peut monopoliser l’accès à certaines ressources, il peut affamer d’autres conteneurs sur l’hôte. Il en résulte un déni de service (DoS). Les utilisateurs ne peuvent accéder à une partie ou à la totalité du système,
• Évasion de conteneurs : Soyez conscient d’éventuelles attaques par élévation de privilèges, où un utilisateur accède à des privilèges élevés grâce à un bug dans le code de l’application qui doit être exécuté avec des privilèges supplémentaires. Bien que peu probable, des évasions sont possibles et devraient être prises en compte lors de l’élaboration d’un plan de continuité,
• Images empoisonnées : Si un attaquant réussit à vous tromper lors de l’exécution d’une image, le système hôte et les données sont en danger. En outre, assurez-vous que les images en cours d’exécution sont à jour,
• Secrets compromettants : Lorsqu’un conteneur a accès à une base de données ou à un service, cela devrait nécessiter l’utilisation d’un « secret », comme une clé API ou un nom d’utilisateur / mot de passe. Un attaquant qui accède au secret aura également accès au service.

Alors que les conteneurs Docker peuvent être efficaces et offrir une certaine souplesse, il est essentiel de prendre en compte ces différents points avant de passer à la mise en œuvre.

Vous pouvez utiliser des conteneurs Docker en tant que composantes de base pour la création d'applications et de plates-formes modernes. Grâce à Docker, il est facile de concevoir et d'exécuter des architectures de microservices distribués, de déployer votre code avec des pipelines standardisés d'intégration et de diffusion continues, de développer des systèmes de traitement des données hautement scalables et de créer des plates-formes entièrement gérées pour vos développeurs.

Concevez et mettez à l'échelle des architectures d'applications distribuées en tirant parti de déploiements de code standardisés à l'aide de conteneurs Docker.

Diffusez vos applications plus rapidement en standardisant vos environnements quels qu'ils soient et en supprimant les conflits entre les piles de langues et les versions.

Fournit un service de traitement de Big Data. Rassemble des données et des paquets d'analyses sous la forme de conteneurs portables qui peuvent être exécutés par des utilisateurs qui ne disposent pas de formation technique.

Développez et envoyez des applications distribuées avec du contenu et une infrastructure sécurisée gérée par informatique. —

Vous pouvez installer Docker CE de différentes manières, en fonction de vos besoins:

• La plupart des utilisateurs configurent les repository Docker et l’installent à partir de ceux-ci pour faciliter les tâches d’installation et de mise à niveau. C'est l'approche recommandée.
• Certains utilisateurs téléchargent le package RPM, l’installent manuellement et gèrent les mises à niveau complètement manuellement. Ceci est utile dans des situations telles que l’installation de Docker sur des systèmes isolés sans accès à Internet.
• Dans les environnements de test et de développement, certains utilisateurs choisissent d’utiliser des scripts de confort automatisés pour installer Docker.

Avant d'installer Docker CE pour la première fois sur un nouvel ordinateur hôte, vous devez configurer le repository Docker. Vous pouvez ensuite installer et mettre à jour Docker à partir du référentiel.

Installez les paquets requis. “yum-utils” fournit l'utilitaire “yum-config-manager”, “device-mapper-persistent-data” et “lvm2” sont requis par le pilote de stockage “devicemapper”.

$ sudo yum install -y yum-utils \
  device-mapper-persistent-data \
  lvm2

Utilisez la commande suivante pour configurer le repository stable. Vous avez toujours besoin du repository stable, même si vous souhaitez également installer des versions à partir du repository Edge ou des repository de test.

$ sudo yum-config-manager \
    --add-repo \
    https://download.docker.com/linux/centos/docker-ce.repo

Installez la dernière version de Docker CE:

$ sudo yum install docker-ce

Si vous êtes invité à accepter la clé GPG, vérifiez que l'empreinte correspond à 060A 61C5 1B55 8A7F 742B 77AA C52F EB6B 621E 9F35 et si tel est le cas, acceptez-la.

Docker est installé mais pas démarré. Le groupe Docker est créé, mais aucun utilisateur n'est ajouté au groupe.

Démarrer Docker avec la commande suivante :

$ sudo systemctl start docker

Démarrer automatiquement Docker en cas de redémarrage du serveur avec la commande suivante :

$ sudo systemctl enable docker

Vérifiez que Docker est correctement installé en exécutant l'image “hello-world”.

$ sudo docker run hello-world

Cette commande télécharge une image de test et l'exécute dans un conteneur. Lorsque le conteneur s'exécute, il imprime un message d'information et se ferme.

Docker CE est installé et fonctionne. Vous devez utiliser sudo pour exécuter les commandes Docker. Passez à la post-installation de Linux pour permettre aux utilisateurs non privilégiés d’exécuter des commandes Docker et à d’autres étapes de configuration facultatives.

Le démon Docker se lie à un socket Unix au lieu d’un port TCP. Par défaut, ce socket Unix appartient à l'utilisateur root et les autres utilisateurs ne peuvent y accéder qu'en utilisant sudo. Le démon Docker s'exécute toujours en tant qu'utilisateur root.

Si vous ne souhaitez pas préfacer la commande docker avec sudo, créez un groupe Unix appelé “docker” si celui-ci n'est pas créer à l'installation et ajoutez-lui des utilisateurs. Lorsque le démon Docker démarre, il crée un socket Unix accessible aux membres du groupe docker.

[root@docker ~]# useradd userdock
[root@docker ~]# passwd userdock
[root@docker ~]# usermod -a -G docker userdock

Déconnectez-vous et reconnectez-vous pour que votre appartenance à un groupe soit réévaluée.

Si vous effectuez des tests sur une machine virtuelle, il peut être nécessaire de redémarrer la machine virtuelle pour que les modifications prennent effet.

Sur un environnement de bureau Linux tel que X Windows, déconnectez-vous complètement de votre session, puis reconnectez-vous.

Vérifiez que vous pouvez exécuter les commandes Docker sans sudo.

[userdock@docker ~]$ docker run hello-world

A cette étapes, notre serveur est opérationnel pour faire fonctionner des conteneurs.

Nous allons maintenant tester notre plateforme en récupérant une image de type “nginx” et la tester. Pour rappel, “nginx” est un serveur web, une alternative à l'historique apache. Toute les images sont récupérés par défaut sur le registry Docker.

Utiliser la commande : “docker search”

[userdock@docker ~]$ docker search nginx
NAME                                     DESCRIPTION                                     STARS  OFFICIAL  AUTOMATED
nginx                                    Official build of Nginx.                        9907   [OK]                
jwilder/nginx-proxy                      Automated Nginx reverse proxy for docker con…   1430             [OK]
richarvey/nginx-php-fpm                  Container running Nginx + PHP-FPM capable of…   626              [OK]
jrcs/letsencrypt-nginx-proxy-companion   LetsEncrypt container to use with nginx as p…   425              [OK]
kong                                     Open-source Microservice & API Management la…   233    [OK]                
webdevops/php-nginx                      Nginx with PHP-FPM                              114              [OK]
kitematic/hello-world-nginx              A light-weight nginx container that demonstr…   111                                     
zabbix/zabbix-web-nginx-mysql            Zabbix frontend based on Nginx web-server wi…   72               [OK]
bitnami/nginx                            Bitnami nginx Docker Image                      58               [OK]
linuxserver/nginx                        An Nginx container, brought to you by LinuxS…   42                                      
tobi312/rpi-nginx                        NGINX on Raspberry Pi / armhf                   23               [OK]
blacklabelops/nginx                      Dockerized Nginx Reverse Proxy Server.          12               [OK]
wodby/drupal-nginx                       Nginx for Drupal container image                11               [OK]
schmunk42/nginx-redirect                 A very simple container to redirect HTTP tra…   11               [OK]
nginxdemos/hello                         NGINX webserver that serves a simple page co…   8                [OK]
centos/nginx-18-centos7                  Platform for running nginx 1.8 or building n…   8                                       
webdevops/nginx                          Nginx container                                 8                [OK]
centos/nginx-112-centos7                 Platform for running nginx 1.12 or building …   5                                       
1science/nginx                           Nginx Docker images that include Consul Temp…   4                [OK]
pebbletech/nginx-proxy                   nginx-proxy sets up a container running ngin…   2                [OK]
mailu/nginx                              Mailu nginx frontend                            1                [OK]
toccoag/openshift-nginx                  Nginx reverse proxy for Nice running on same…   1                [OK]
travix/nginx                             NGinx reverse proxy                             1                [OK]
ansibleplaybookbundle/nginx-apb          An APB to deploy NGINX                          0                [OK]

Nous allons récupérer la première image, celle-ci correspond à la version officiel de nginx.

Pour récupérer celle-ci, nous allons utiliser la commande : “docker pull …”

[userdock@docker ~]$ docker pull nginx
Using default tag: latest
latest: Pulling from library/nginx
f17d81b4b692: Pull complete 
d5c237920c39: Pull complete 
a381f92f36de: Pull complete 
Digest: sha256:b73f527d86e3461fd652f62cf47e7b375196063bbbd503e853af5be16597cb2e
Status: Downloaded newer image for nginx:latest

On vérifier la liste des images disponibles sur notre serveur avec la commande “docker images”. On remarque que notre images “nginx” a bien été récupérer.

[userdock@docker ~]$ docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
nginx               latest              dbfc48660aeb        18 hours ago        109MB

Maintenant il nous suffira de lancer notre container avec un simple “docker run”. Dans l'exemple suivant, on définie un Name pour notre container.

[userdock@docker ~]$ docker run -d --name SrvNginx nginx:latest
7d6220c8ec2618cb01dc25be7bef3d75de035a55186bce336f3d8d3df812d979

On vérifie que le container est bien installé avec la commande “docker ps”

[userdock@docker ~]$ docker ps -a
CONTAINER ID      IMAGE            COMMAND                  CREATED           STATUS            PORTS          NAMES
7d6220c8ec26      nginx:latest     "nginx -g 'daemon of…"   5 seconds ago     Up 4 seconds      80/tcp         SrvNginx

Pour afficher toutes les informations de notre container, on passera par la commande “docker inspect <NAMES>/<CONTAINER ID>”:

[userdock@docker ~]$ docker inspect 7d6220c8ec26
[
    {
        "Id": "5e304545f2a7bb05c795f2fac5c1b6be97f1fb8fe673d971933ec9b5453b83aa",
        "Created": "2018-10-17T08:06:04.173506918Z",
        "Path": "nginx",
        "Args": [
            "-g",
            "daemon off;"
        ],
        "State": {
            "Status": "running",
            "Running": true,
            "Paused": false,
            ...

Pour visualiser la page par défaut de notre serveur web “nginx”, il nous suffira de récupérer l'adresse IP de notre container avec la commande précédente, “docker inspect <NAMES>/<CONTAINER ID>” puis de lancer le binaire “elinks” :

[userdock@docker ~]$ docker inspect 5f440a183eea | grep "IPAddress"
            "SecondaryIPAddresses": null,
            "IPAddress": "172.17.0.2",
                    "IPAddress": "172.17.0.2",

Visualisation de la page par défaut

[userdock@docker ~]$ elinks 172.17.0.2

Il nous faut maintenant à cette étapes rendre notre container accessible de l'extérieur. Pour cela, nous allons créer un deuxième container depuis l'image “nginx” avec quelques arguments en plus :

[userdock@docker ~]$ docker run -d -p 80:80 --name SrvNginx2 nginx:latest

En nous rendant à l'adresse de l'hôte.

Pour se connecter à un container qui tourne, nous utiliserons la commande “docker exec -i -t <NAMES>/<CONTAINER ID> /bin/bash” :

[userdock@docker ~]$ docker exec -i -t 7d6220c8ec26 /bin/bash

Pour supprimer le container, nous listerons les containers avec commande “docker container ls -all” puis utiliser la commande “docker rm <NAMES>/<CONTAINER ID>”

[userdock@docker ~]$ docker rm 7d6220c8ec26
7d6220c8ec26

Pour supprimer l'image “nginx” que nous avons téléchargés, nous allons utiliser la commande “docker rmi <REPOSITORY>” :

[userdock@docker ~]$ docker rmi nginx
Untagged: nginx:latest
Untagged: nginx@sha256:b73f527d86e3461fd652f62cf47e7b375196063bbbd503e853af5be16597cb2e
Deleted: sha256:dbfc48660aeb7ef0ebd74b4a7e0822520aba5416556ee43acb9a6350372e516f
Deleted: sha256:1a34717cf175feab802f74f0edd1c41a811165f6e6af5cddf9b33f9211acde10
Deleted: sha256:df31c4d2dc314417ca1507e7e6ac4e732683a67b5aec725ede170ea7c2ecc99e
Deleted: sha256:237472299760d6726d376385edd9e79c310fe91d794bc9870d038417d448c2d5

Docker peut créer des images automatiquement en lisant les instructions d'un fichier Docker. Un fichier Docker est un document texte contenant toutes les commandes qu'un utilisateur peut appeler en ligne de commande pour assembler une image.

En utilisant docker build, les utilisateurs peuvent créer une construction automatisée qui exécute plusieurs instructions de ligne de commande les unes à la suite des autres.

Dans cette exemple nous allons créer une images depuis Centos 7 et faire en sorte de mettre a disposition le cms “GravCMS”.

Pour commencer, créez un nouveau dossier pour votre projet “CentOS-GravCMS” avec à l’intérieur un fichier Dockerfile à la racine de celui-ci.

Le format / structure de Dockerfile est très simple. Les instructions ne sont pas sensibles à la casse, mais comme le veut la convention, les développeurs sont habitués à écrire des instructions au format majuscule. L'ordre des instructions dans Dockerfile est important. Le même ordre a été suivi lors de la création de l'image.

Réduire le nombre d'étapes dans votre image peut améliorer les performances de génération et d'extraction. Par conséquent, il est préférable de combiner plusieurs étapes en une seule ligne, de sorte qu’elles ne créent qu’une seule image intermédiaire.

Nous pouvons reformuler notre fichier Docker comme ceci:

FROM alpine:latest 
 
RUN apk update && \
  apk add curl && \
  apk add vim && \
  apk add git

Une Docker Registry est une application qui permet de distribuer des images Docker au sein de votre organisation.

C’est un composant majeur dans l’écosystème Docker, car il va permettre :

• À vos développeurs de distribuer des images prêtes à l’emploi de vos applications et de les versionner avec un système de tags.
• À de nouveaux arrivants dans votre société de mettre en place rapidement leur environnement de développement à partir de ces images.
• À des outils d’intégration en continu de jouer une suite de tests sans avoir besoin d’autre chose que de Docker.
• Et à des systèmes automatisés de déployer ces applications sur vos environnement de développement, de tests, de recette et de production.

Pour rappel : Une image Docker est en quelque sorte une image disque qui contient l’arborescence d’une distribution linux, le code source d’une application et des binaires capables de la faire tourner.

Une image se construit à partir d’un fichier Dockerfile que l’on retrouve généralement à la racine des sources d’une application.

Docker met à disposition un registre d’images publiques : DockerHub. Dans ce registre, vous allez retrouver des images, telles que :

• des distributions linux,
• des images pré-configurées avec un serveur web et un environnement, exécution pour votre langage préféré,
• des bases de données,
• et des applications open-source prêtes à l’emploi

Docker propose également le dépôt d’images privées.

Liste des Url's :

• https://www.redhat.com/fr/
• https://docs.docker.com/
• https://docs.docker.com/develop/develop-images/dockerfile_best-practices/

Commande :

## List Docker CLI commands
docker
docker container --help
 
## Display Docker version and info
docker --version
docker version
docker info
 
## Execute Docker image
docker run hello-world
 
## List Docker images
docker image ls
 
## List Docker containers (running, all, all in quiet mode)
docker container ls
docker container ls --all
docker container ls -aq
 
## Search Docker image
docker search

Usage:	docker [OPTIONS] COMMAND
 
A self-sufficient runtime for containers
 
Options:
      --config string      Location of client config files (default "/home/userdock/.docker")
  -D, --debug              Enable debug mode
  -H, --host list          Daemon socket(s) to connect to
  -l, --log-level string   Set the logging level ("debug"|"info"|"warn"|"error"|"fatal") (default "info")
      --tls                Use TLS; implied by --tlsverify
      --tlscacert string   Trust certs signed only by this CA (default "/home/userdock/.docker/ca.pem")
      --tlscert string     Path to TLS certificate file (default "/home/userdock/.docker/cert.pem")
      --tlskey string      Path to TLS key file (default "/home/userdock/.docker/key.pem")
      --tlsverify          Use TLS and verify the remote
  -v, --version            Print version information and quit
 
Management Commands:
  config      Manage Docker configs
  container   Manage containers
  image       Manage images
  network     Manage networks
  node        Manage Swarm nodes
  plugin      Manage plugins
  secret      Manage Docker secrets
  service     Manage services
  stack       Manage Docker stacks
  swarm       Manage Swarm
  system      Manage Docker
  trust       Manage trust on Docker images
  volume      Manage volumes
 
Commands:
  attach      Attach local standard input, output, and error streams to a running container
  build       Build an image from a Dockerfile
  commit      Create a new image from a container changes
  cp          Copy files/folders between a container and the local filesystem
  create      Create a new container
  diff        Inspect changes to files or directories on a container filesystem
  events      Get real time events from the server
  exec        Run a command in a running container
  export      Export a container filesystem as a tar archive
  history     Show the history of an image
  images      List images
  import      Import the contents from a tarball to create a filesystem image
  info        Display system-wide information
  inspect     Return low-level information on Docker objects
  kill        Kill one or more running containers
  load        Load an image from a tar archive or STDIN
  login       Log in to a Docker registry
  logout      Log out from a Docker registry
  logs        Fetch the logs of a container
  pause       Pause all processes within one or more containers
  port        List port mappings or a specific mapping for the container
  ps          List containers
  pull        Pull an image or a repository from a registry
  push        Push an image or a repository to a registry
  rename      Rename a container
  restart     Restart one or more containers
  rm          Remove one or more containers
  rmi         Remove one or more images
  run         Run a command in a new container
  save        Save one or more images to a tar archive (streamed to STDOUT by default)
  search      Search the Docker Hub for images
  start       Start one or more stopped containers
  stats       Display a live stream of container(s) resource usage statistics
  stop        Stop one or more running containers
  tag         Create a tag TARGET_IMAGE that refers to SOURCE_IMAGE
  top         Display the running processes of a container
  unpause     Unpause all processes within one or more containers
  update      Update configuration of one or more containers
  version     Show the Docker version information
  wait        Block until one or more containers stop, then print their exit codes