DevOps avec des conteneurs

Principe de fonctionnement

Partage de l'OS et isolation des processus

Par rapport aux VM, les conteneurs docker sont basés sur des fonctionnalités d'isolation du noyau Linux :

(source : www.docker.com - Comparing Containers and Virtual Machines)

Principe de fonctionnement

Utilisation d'un système de fichiers par couche

Avec docker, nous trouverons un concept d'image fonctionnellement identique à celui auquel nous sommes habitué avec les VM (ex : les .box téléchargées par vagrant dans la partie précédente).

La deuxième optimisation notable de docker par rapport aux VM tiendra à l'utilisation de système de fichiers par couche ("overlay") pour matérialiser ces images.

Cette approche permettra à docker d'optimiser le téléchargement et la construction des images avec des mécanismes de cache.

Principe de fonctionnement

La surcouche docker

Les mécanismes d'isolation ne sont pas nouveaux dans le noyau Linux (voir LXC - LinuX Containers et cgroups). Les systèmes de fichiers par couches non plus.

Docker apporte par contre un ensemble cohérent de concepts et d'outils donnant un cadre pour construire et déployer efficacement des applications en s'appuyant sur ces mécanismes.

Les principaux concepts

Vue d'ensemble des concepts

Les principaux clients

Nous utiliserons principalement les clients en ligne de commande suivants pour communiquer avec l'API docker :

• L'exécutable docker qui permettra de manipuler individuellement les images, les conteneurs, les volumes, les réseaux,...
• Son plugin docker compose qui permettra de gérer des stacks au format YAML (des services exécutant des conteneurs, des réseaux et des volumes,...)

Nous mentionnerons l'existance d'interfaces graphiques (ex : Portainer) qui sont clientes de l'API docker. Elles ne seront pas utilisées dans ce cours pour une meilleure compréhension du fonctionnement.

Les dépôts d'images

DockerHub

Les dépôts d'images

Les autres dépôts d'images publiques

Les dépôts d'images

Les dépôts d'images privés

Il est possible de stocker des images avec des outils tels Harbor, Nexus ou registry déployés en propre.

Les dépôts d'images

Le dépôt d'images du gestionnaire de code source

La plupart des gestionnaires de code source (GitHub, GitLab, Gitea,...) intègrent désormais un système de stockage d'image docker (ghcr.io, registry.gitlab.com,...) ce qui :

• Évite de gérer en parallèle des authentifications et des droits au niveau du dépôt d'images.
• Simplifie la publication des images au niveau des orchestrateurs d'intégration continue (qui sont eux aussi intégrés aux gestionnaires de code source)

Les dépôts d'images

Les dépôts d'images des hébergeurs

Enfin, nous mentionnerons l'existence de dépôts d'images au niveau des solutions d'hébergement (ex : Google Container Registry, Azure Container Registry, Amazon Elastic Container Registry (ECR)...).

L'utilisation de ces derniers sera parfois imposée pour utiliser certaines fonctionnalités.

NB : Un hébergeur ne pourra pas garantir qu'il est capable de redéployer votre application en cas de problème s'il dépend une infrastructure tierce.

L'observabilité

Les journaux applicatifs

L'observabilité

Les métriques systèmes

En outre, nous soulignerons que docker collectera des métriques systèmes sur les conteneurs (CPU, mémoire, entrées/sorties disque et réseau).

Ces métriques seront disponibles au niveau de l'API docker et via la commande docker stats.

Découvrir docker par la pratique

Principe

A l'instar de Ansible, il faudrait de nombreuses séances pour vous former réellement à l'utilisation de docker. Nous allons nous contenter d'une découverte des principaux concepts à l'aide d'exemples.

Pour approfondir sur cette technologie, vous pourrez suivre un cours dédié ou vous appuyer sur les ressources suivantes :

• docs.docker.com - Docker overview
• container.training - Introduction to Containers

Découvrir docker par la pratique

Installation de docker

Nous allons nous assurer d'avoir une installation fonctionnelle de docker permettant d'exécuter docker run hello-world.

Découvrir docker par la pratique

Les problèmes classiques

Une annexe docker référence la procédure d'installation officielle et s'efforce de guider sur la résolution des problèmes classiques.

En particulier, il vous faudra potentiellement traiter ceux liés à l'utilisation d'un proxy sortant avec docker.

Découvrir docker par la pratique

Mise en garde

Éviter d'installer le démon docker directement sur un poste de travail branché sur le réseau de votre école/entreprise.

La configuration par défaut du démon (/etc/docker/daemon.json) devra être adaptée pour :

• Éviter les conflits d'IP entre les réseaux virtuels créés par docker et le réseau local (bip et default-address-pools)
• Définir les bonnes options de sécurité (voir docker-bench-for-security)

Découvrir docker par la pratique

Quelques exemples pour débuter...

Pour la prise en main du client docker et la découverte des concepts, nous allons voir ensemble les exemples stockés dans un dépôt dédié annexé à ce cours :

• mborne/docker-exemples

Pour la prise en main de docker compose, nous utiliserons mborne/docker-devbox qui est mon terrain de jeu pour docker et Kubernetes en démarrant (1) :

• mborne/docker-devbox - redis
• mborne/docker-devbox - postgis

(1) Il faudra en pré-requis exécuter docker network create devbox (l'intérêt de la chose sera expliqué par la suite)

Le déploiement de GeoStack

Principe

Après cette brève introduction, nous allons pouvoir reprendre le déploiement de GeoStack réalisé précédemment avec Ansible.

Le déploiement de GeoStack

La construction d'une image

Pour illustrer la construction d'une image docker à partir d'un Dockerfile, nous allons faire l'exercice de :

• Créer nous même l'image pour GeoServer
• Stocker cette image à l'aide de GitHub Container Registry (ghcr.io)

Nous inspecterons ensemble le dépôt mborne/docker-geoserver correspondant et soulignerons que nous pourrons récupérer l'image comme suit pour la suite :

Le déploiement de GeoStack

Le déploiement avec docker compose

Nous trouverons la démonstration correspondante dans le dépôt ci-après :

mborne/geostack-deploy - Déploiement de GeoStack avec docker compose

Nous mémoriserons que :

• L'utilisation d'un fichier docker-compose.yml permet de démarrer une pile applicative complète à l'aide de la commande docker compose up -d.
• Sans docker compose, nous serions amené à exécuter de nombreuses commandes docker.

Le déploiement de GeoStack

La mise en oeuvre d'un reverse proxy (1/2)

Avec Ansible, la mise en oeuvre d'un reverse proxy aurait induit par exemple l'installation et la configuration de nginx.

Avec docker, la présence d'une API au niveau de docker permet des mécanismes de découverte de configuration exploités par exemple par Traefik.

Nous traiterons le déploiement geostack-deploy - docker - Mise en oeuvre d'un reverse proxy pour en comprendre le fonctionnement.

En alternative à Traefik, il est possible d'utiliser nginx-proxy. La principale problématique à traiter serait la même : Le LoadBalancer devra avoir accès aux conteneurs exposés (d'où le réseau "devbox" au niveau de mborne/docker-devbox).

Le déploiement de GeoStack

La mise en oeuvre d'un reverse proxy (2/2)

En complément, nous constaterons que traefik faciliterait au passage la mise en oeuvre de TLS et de bien d'autres points tels la mise en oeuvre de limites de nombres d'appel par IP

L'intérêt des conteneurs

Que manque-t'il à ce stade?

En l'état, si cherchions à héberger GeoStack sur plusieurs machines, nous remarquerions que :

• Les conteneurs sur la machine A ne peuvent communiquer avec ceux de la machine B
• Les démons docker sur les machines ne se connaissent pas (un outil tel Traefik devrait moissonner deux API distinctes)

Les conteneurs étant une technologie d'isolation, nous avons actuellement uniquement l'option de scalabilité verticale.

Nous allons voir comment y remédier dans la partie DevOps avec Kubernetes.