blog.bressure.net

C’est un sujet connu depuis que les applications sont modulaires c’est-à-dire depuis presque toujours. En effet depuis fort longtemps les applications partagent ou utilisent des composants externes non développés par le projet lui-même. C’est le cas des libraires externes .so ou .dll ou .jar etc. Dans le monde docker ces dépendances externes sont les images que l’on assemble entre elles via un docker-compose.yml ou que l’on étend via un FROM dans un DockerFile.

Mibew

J’avais une instance de Mibew dockerisée qui j’avais trouvée sur dockerhub, le registry public des images docker, sous le nom manyos/mibew. J’avais laissé cette images tourner sur ma VM depuis plusieurs mois sans y toucher mais avec mon chantier de suppression de ma VM staging, puisque je modifie la définition des mes conteneurs, je devais donc repasser tous les pipelines de construction. C’est là que pour Mibew le drame survint. Dans mon IC la phase de test est faite bien heureusement dans DIND qui part d’un environnement docker vierge. C’est alors que le processus échoua car l’image Mibew avait été supprimée du registry dockerhub par son propriétaire !

Avoir un bakcup

Comme le conteneur est encore en exécution sur ma VM de production cela veut dire que l’image manyos/mibew est encore dans cette environnement docker. Il me suffit de prendre cette image, de la retaguer et de la pousser dans un registry de backup.

Supposons que je dispose d’un registry (lui-même une image docker) de sauvegarde à l’adresse registry-backup-bressure.net:5000 alors pour taguer l’image manyos/mibew existante il faut faire:

docker tag manyos/mibew registry-backup.bressure.net:5000/manyos/mibew

Puis de l’envoyer sur le registry de sauvegarde:

docker push registry-backup.bressure.net:5000/manyos/mibew

Il faudra enfin modifier la référence de l’image dans le fichier docker-compose.yml pour pointer vers l’image dans le registry backup.

Mise en cache

Cette copie dans le registry de backup est une manipulation de dépannage une fois que l’IC constate la disparition de l’image de sont registry original. Afin de ne pas casser l’IC tout de suite et de bénéficier d’une accélération des constructions en réduisant le temps de téléchargement, la mise en place d’un registry proxy est une solution. Je choisi donc d’avoir 2 instance de l’image registry

version: "3.7"
services:
  backup:
    restart: always
    image: registry:2
  proxy:
    restart: always
    image: registry:2

Leur configuration diffère par l’ajout d’une instruction dans le registry proxy pour lui indiquer d’agir comme …. un proxy. Voici la configuration du proxy

version: 0.1
 log:
   accesslog:
     disabled: true
   fields:
     service: registry
 storage:
   cache:
     blobdescriptor: inmemory
   filesystem:
     rootdirectory: /var/lib/registry
 http:
   addr: :5000
   headers:
     X-Content-Type-Options: [nosniff]
 health:
   storagedriver:
     enabled: true
     interval: 10s
     threshold: 3
 delete:
   enabled: true
 proxy:
   remoteurl: https://registry-1.docker.io

Mise en en place derrière Traefik

Bien entendu je mets en place mon registry privé de backup derrière Traefik car je veux bénéficier du routage par nom de domaine tout en exposant que le port 5000 sur mon hôte.

Réglages importants

Pour garder mes registry privés, je ne les inclus pas dans la chaine de flux accessible depuis internet c’est-à-dire que je ne les mets pas derrière les ports 80 et 443 du frontal TLS de mon architecture. Le port 5000 est ouvert uniquement sur l’hôte et est configuré comme un EntryPoints dédié aux registry dans Traefik. Dans la commande de lancement de Traefik ajouter:

--entryPoints.registry.address=:5000 

La configuration du conteneur registry doit indiquer à Traefik qu’il utilise TLS par une instruction:

labels:
 - "traefik.http.routers.registry_backup.tls"
 - "traefik.http.routers.registry_backup.entryPoints=registry"

C’est obligatoire car lé démon docker essaye de joindre le registry en HTTPS en premier. Si le HTTPS échoue alors il joint le registry en HTTP. Or Traefik répond en HTTPS avec un certificat par défaut qui ne correspond pas à mon nom de domaine. Or en mode insecure (je ne veux pas mettre en oeuvre de TLS) le démon docker ignore l’erreur de certificat et continue à faire des requêtes en HTTPS, il faut donc que Traefik continue à router les requêtes vers le conteneur.

Enfin afin de bénéficier de mon registry de backup et de mon registry proxy à l’intérieur de ma phase de test dans l’IC, il faut configurer DIND:

• pour utiliser le proxy
• indiquer que le proxy et le backup sont insecure (je n’ai pas mis en place de certificat valide pour ces briques purement internes)
• ajouter les noms de domaine (je n’ai pas de DNS interne)

 services:
      - name: docker:dind
        entrypoint: ["/bin/sh","-c" ,'echo "192.168.122.1 registry-backup.bressure.net registry-proxy.bressure.net">>/etc/hosts && dockerd-entrypoint.sh --insecure-registry registry-backup.bressure.net:5000 --insecure-registry registry-proxy.bressure.net:5000 --registry-mirror https://registry-proxy.bressure.net:5000' ]