SmileLab a développé un nouvel outil pour synchroniser un registre Docker privé et les déploiements Kubernetes.

Kubernetes est un orchestrateur référence. Sa capacité à s’installer aisément sur presque toutes les plateformes (cluster privé, AWS, Azure, Scaleway, . . . ) lui confère un statut de maitre en la matière. Ce n’est pas pour rien que Redhat développe OpenShift sur la base de Kubernetes.

Kubernetes propose quelques “addons” tels que la gestion automatique de DNS “intra cluster” basé sur SkyDNS, ou “Heapster” qui permet de monitorer le cluster, sans compter le “dashboard”.

Mais un addons manquait. 
Le module dont nous avons besoin doit permettre de synchroniser un registre Docker privé et les déploiement impactés.

Autrement dit, si un déploiement d’image est effectué, nous avons besoin (selon certaines règles) d’initier automatiquement un nouveau déploiement avec cette version.

C’est de ce constat que nous avons démarré le développement de "Argoos".

Le nom vient du dieu grec Argos qui guidait les marins avec la centaine d’yeux répartis sur tout le corps. Dans la lignée du mot “Kubernetes” qui est le mot grec pour “homme de barre”, ou “maitre de navigation”, ou encore “fleet” proposé par CoreOS pour le mot “flotte (de navires)”, Argos est un nom qui porte tout son sens. Et pour se différentier des balises homonymes qui se trouvent sur les navires des skeepers, le nom Argoos a vu le jour.

Argoos nécessite un peu de paramétrage du registre docker. Il est en fait un "receveur de webhook".

Pour paramétrer le registre Docker, vous pouvez vous référer à la page https://docs.docker.com/registry/notifications/.

En d’autres termes, il suffit d’effectuer ces commandes:

docker run --entrypoint=cat registry:2 /etc/docker/registry/config.yml > config.yaml

Le contenu du ficher est donc la configuration standard - elle peut être enregistré dans un ConfigMap Kubernetes si vous délivrez le registre en tant qu’objet Kubernetes. A ce stade, il faut ajouter un bloc pour les notifications:

notifications:
   endpoints:
      -  name: argoos
         disabled: false
         url: http://adresse/ver/argoos:3000
         timeout: 500
         threshold: 5
         backoff: 1000

Et enfin, monter cette configuration dans le registre, par exemple si vous démarrez le registre via Docker:

docker run -p 5000:5000 -v /chemin/du/config.yml:/etc/docker/registry/config.yml registry:2

Désormais, tout ajout d’image dans le registre contactera Argoos.

Le paramétrage de Argoos est simple, il suffit de lui fournir l’adresse de l’API Kubernetes pour qu’il puisse interagir avec. Si vous démarrez Argoos en tant qu’objet dans Kubernetes, vous pouvez lui fournir l’url non sécurisée “http://kubernetes:8080”, cette dernière n’étant accessible qu’au sein du cluster.

Enfin, dans un objet de déploiement Kubernetes, vous pouvez ajouter un label précisant la règle de gestion de mise à jour.
Prenons l’exemple de l’image “youregistry:5000/our/nginx:1.8.1”:

apiVersion: extensions/v1beta1
metadata:
   namespace: example
   name: nginx-test
   labels:
      argoos.net/policy: all
spec:
   # ...
   template:
      spec:
         containers:
         - image: youregistry:5000/our/nginx:1.8.1
           name: webserver
         # ...

Si vous poussez une image nginx:1.8.2 dans le registre, alors Argoos va scanner les déploiements existants, trouver ceux dont le label “argoos.net/policy” existe, et vérifier la politique de mise à jour. La politique peut prendre, à ce jour, les options suivantes en prenant en compte un numéro de version x.y.z semver (http://semver.org/), où x est le numéro de version “majeure”, y le numéro de version “mineur” et z le numéro de patch:

• “all” pour mettre à jour l’image quelque soit la version, y compris si le tag (version) ne correspond pas à un modèle semver
• “patch” pour mettre à jour le déploiement si l’image a changé le numéro de patch (et seulement celle-ci)
• “minor” pour mettre à jour le déploiement si l’image a changé de numéro de version mineure ou de patch
• “major” pour mettre à jour le déploiement si l’image a changé de version majeur, mineur ou patch

Si un déploiement utilise plusieurs conteneurs de différentes images, il est possible que ces deux images soient poussées dans le registre avec un écart de temps assez court, voir en simultanée. Pour éviter de relancer le déploiement trop rapidement, un délai entre chaque relecture de déploiement a été mis en place dans Argoos (par défaut 5 secondes). Il est paramétrable dans les options de démarrage (option -rollout-delay)

Argoos est déjà disponible en open source, sur le dépôt de Smile sur GitHub, et l’image est sur le hub de Docker.

A vous de l'utiliser !

Par ailleurs, les travaux continuent sur Argoos:

• paramétrer le délai d’attente de déploiement dans les labels
• permettre l’utilisation d’une expression régulière pour choisir les versions qui provoquent un déploiement
• scalabilité du service
• journaux plus précis, reporting