ENSG

DevOps avec des conteneurs

ENSG

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 :

Conteneur vs VM

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

Le démarrage d'un conteneur sera plus rapide que le démarrage d'une VM car :

  • Démarrer un conteneur = démarrer un processus isolé
  • Démarrer une VM = démarrer un OS complet
ENSG

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.

ENSG

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.

ENSG

Les principaux concepts

Vue d'ensemble des concepts

L'utilisation de docker amènera en effet à manipuler plusieurs concepts :

  • Les images qui sont fonctionnellement équivalentes aux images de VM
  • Les fichiers Dockerfile qui décrivent la construction d'une image.
  • Les dépôts d'images (registry) qui permettent de télécharger et stocker des images.
  • Les conteneurs qui sont des instances des images se comportant comme des VM grace à des mécanismes d'isolation.
  • Les volumes qui permettent d'externaliser les données des conteneurs ("montage de disque")
  • Les réseaux qui permettent la communication entre les conteneurs.
  • Le démon docker qui met à disposition une API pour gérer les conteneurs, images, volumes, réseaux,....
ENSG

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.

ENSG

Les dépôts d'images

DockerHub

Nous trouverons plusieurs dépôts d'images mettant à disposition des images docker prêtes à l'emploi. Le plus connu étant DockerHub qui met à disposition :

Pour déployer GeoStack, nous y trouverons par exemple :

Nous remarquerons que l'utilisation de DockerHub pour stocker des images ne sera pas forcément gratuite (c.f. docker.com - Pricing & Subscriptions) et qu'il existe une limite de nombre de téléchargement par IP ou par utilisateur.

ENSG

Les dépôts d'images

Les autres dépôts d'images publiques

Il existe d'autres dépôts d'images publiquement accessibles dont :

Ainsi :

  • En l'absence de précision, nous utiliserons DockerHub (utiliser l'image keycloak/keycloak sera équivalent à utiliser l'image docker.io/keycloak/keycloak).
  • Nous préciserons le domaine en cas d'utilisation d'un autre dépôt (ex : quay.io/keycloak/keycloak)
ENSG

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.

ENSG

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)
ENSG

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.

ENSG

L'observabilité

Les journaux applicatifs

Nous soulignerons que la gestion des journaux applicatifs est unifiée par :

(1) Il sera bien sûr toujours possible d'écrire des journaux dans des fichiers mais se conformer à la 11ième recommandation sur Logs des 12 facteurs et écrire les messages dans les flux standards simplifiera la collecte de ces derniers.

(2) journald semble particulièrement intéressant pour unifier les journaux des conteneurs avec ceux des services systemd classiques afin d'en faciliter la centralisation.

ENSG

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.

ENSG

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 :

ENSG

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.

Si docker n'est pas installé sur votre poste, vous pourrez :

Play with Docker

ENSG

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.

ENSG

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)
ENSG

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 :

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) :

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

ENSG

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.

ENSG

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 :

docker pull ghcr.io/mborne/geoserver:v2.21.1
ENSG

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.
ENSG

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).

ENSG

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

ENSG

L'intérêt des conteneurs

En synthèse, nous soulignerons le succès de docker doit beaucoup aux points suivants :

  • L'image est un livrable universel (plus besoin de choisir entre un .deb, .rpm, .war, .zip,...)
  • L'image est définie as code via le Dockerfile (donc reconstructible)
  • L'image testée en DEV est celle qui s'exécute en PROD
  • Le démarrage des conteneurs est rapide.
  • Les téléchargements et constructions d'images sont optimisés.
  • Un cadre est posé pour l'observabilité avec journaux applicatifs et les métriques systèmes
  • L'API permet la construction d'un écosystème avec par exemple :
    • Le reverse proxy traefik qui se configure automatiquement en inspectant les conteneurs (introspection)
    • L'IHM portainer qui permet de démarrer des conteneurs (réflexion)
ENSG

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.