The need for a S.M.A.R.T private registry

After our Managed Kubernetes Service release, we received many requests  for a fully managed private container registry.

Though a container registry for hosting images may sound quite trivial to deploy, our users mentioned a production-grade registry solution was a critical part of the software delivery supply chain and was actually quite difficult to maintain.

Our customers were asking for an enterprise-grade solution, offering advanced role-based-access-control and security by design, as concerns around vulnerabilities within the publicly available images increased and requirements for content-trust became a necessity.

Users were regularly praising the user interface of services such as the Docker Hub, but at the same time requested a service with high availability and backed by SLA.

The perfect mix of open source and enterprise-grade feature set

After surveying prospects to fine tune our feature set and pricing model, we searched for the best existing technologies to back it and landed on the CNCF incubating project Harbor (donated to the CNCF by VMWare). In addition to Harbor being one of the few projects to reach CNCF incubation state, thus confirming the strong commitment from the community, it has as well become a key part of several commercial enterprise containerization solutions. We also appreciated the approach taken by Harbor of not re-inventing the wheel but gluing best-of-breed technologies for components such as vulnerability scanning, content trust and many others. It leverages CNCF’s strong network of open source projects and ensures great UX quality levels.

It was now the time to take this 10k-GitHub-stars technology and adapt it to our specific case : managing tens of thousands of registries for our users, each of them having specific volume of container images and usage patterns.

Of course high-availability (customers’s software integration and deployment rely on this service) but also data durability were non-negotiable for us.

In addition, Kubernetes to ensure stateless services HA and object storage (based on Openstack Swift and compatible with the S3 API) were evident choices to check those requirements.

Addressing  operational challenges at the cloud-provider scale

Within a few weeks, we opened the service in public beta, quickly attracting hundreds of active users. But with this surge in traffic, we naturally hit our first bottlenecks and performance challenges.

We approached the Harbor user group and team who kindly pointed us to potential solutions, and after some small but key changes to how Harbor handles database connections our issues were resolved. This reinforced our beliefs that the Harbor community is strong and committed to the health of the project and the requirements of its users.

As our service flourished there was no real tooling available to easily accommodate the life-cycle of Harbor instances. Our commitment to the Kubernetes ecosystem made the concept of a Harbor operator for Kubernetes an interesting approach.

We discussed with the Harbor maintainers and they warmly welcomed our idea to develop it, and open source it as the official Harbor Kubernetes Operator. OVHcloud is very proud to have the project now available in the goharbor GitHub project under Apache 2 licensing. This project is another example of our strong commitment towards open source and our willingness to contribute our efforts back to the projects that we love.

A versatile operator designed to accommodate any Harbor deployment

Readers familiar with the Harbor project may wonder what value this operator brings to the current catalogue of deployments including the Helm Chart version maintained by the project.

The operator design pattern is quickly catching on and mimics an application-centric controller that extends Kubernetes to manage more complex, stateful apps.  Simply put, It addresses different use-cases than those of Helm. Whereas the Helm chart offers an all-in-one installer that would also deploy the different dependencies of Harbor (database, cache, etc) from open source Docker images,other enterprises, service operators and cloud providers like us will want to pick-and-choose the service or technology behind those components.

We also aim at extending the current v0.5  operator to manage the full life-cycle of Harbor, from deployment to deletion, including scaling, updates, upgrades, and backup management.

This will help production users reach their target SLO, benefit from managed solutions or from existing databases clusters they already maintain for example.

We designed the operator (leveraging the OperatorSDK framework) so that both Harbor optional modules (Helm Chart store, vulnerability scanner etc) and dependencies (registry storage backend, relation and non relational databases, etc) can easily match your specific use case.

Contributing to Harbor and the operator project

We already have a roadmap planned with the Harbor maintainers to further enrich the operator to accommodate more than the deployment and destruction phases (for example making Harbor version upgrades more elegant). We look forward to being an integral part of the project and will continue investing in Harbor.

To that end, Jérémie Monsinjon and Pierre Peronnet have also been invited to be  maintainers of the Harbor project focusing on goharbor/operator .

In addition to regular contributions to multiple projects we use within OVHcloud, the container-platform team is also working on other major open sources releases, like an official OVHcloud cloud controller for self-managed Kubernetes we plan to deliver in late 2020.

Download Harbor or the Harbor Operator : Official Harbor Github repo

Learn more about Harbor : Official Harbor website

Docker, un ami que l’on aime détester

Soyons clairs, lorsque nous avons proposé d’héberger des bases de données sous Docker, c’était la panique en interne ! Nous avons retrouvé des sysadmins en pleurs dans les couloirs, tandis que d’autres se réfugiaient sous leur bureau. Mais pourquoi Docker génère-t-il tant de craintes ?

« Docker c’est stateless, tu vas perdre toutes tes données »

Effectivement, Docker a été largement utilisé ces dernières années pour des applications dites stateless. On déploie une API et une fois que celle-ci n’est plus utilisée, on la supprime ou la relance ailleurs car elle ne dépend pas de données présentes sur le host en particulier.

Heureusement pour nous, Docker offre la possibilité d’utiliser des volumes. Un volume est un répertoire défini pour y stocker les données issues d’un conteneur et ce stockage persiste même lorsque le conteneur est supprimé.

Voici un exemple pour un conteneur MySQL. Le volume correspond au dossier /var/lib/mysql du conteneur.

/var/lib/docker/volumes/8a9f45f44164c62b6ab226ac8db6c723aaf2276749f2ec5f8e601e179e298d0e/_data/data# ls -la
-rw-r--r-- 1 - -        0 May  3 11:32 debian-10.1.flag
-rw-rw---- 1 - - 79691776 Jun 20 08:26 ibdata1
-rw-rw---- 1 - -  5242880 Jun 20 08:26 ib_logfile0
-rw-rw---- 1 - -  5242880 Jun 15 21:23 ib_logfile1
drwx------ 2 - -     4096 May 15 16:56 mysql
drwx------ 2 - -     4096 May 15 16:56 performance_schema

« Avec Docker, tu vas avoir des problèmes de performance »

Nous pourrions nous lancer dans un grand discours, assorti de jolis graphiques, pour vous convaincre. Mais, à vrai dire, ce travail a déjà été fait. Voici un très bon article (en anglais), relatant différents tests effectués avec Docker et MySQL : MySQL with Docker – Performance characteristics

Ce qu’il faut en retenir : il n’existe aucune différence de performance entre une instance MySQL hébergée dans un conteneur ou hors de celui-ci. Docker n’est qu’un orchestrateur de conteneur, lequel s’appuie sur des fonctionnalités existantes du noyau Linux qui n’impliquent pas ou très peu d’overhead (consommation de ressources supplémentaires engendrée par le processus de conteneurisation).

Lors de nos propres tests, nous avons obtenu des résultats sensiblement équivalents. Alors, circulez il n’y a rien à voir ?

« Docker, ce n’est pas stable ! »

Malheureusement, c’est plutôt vrai.

Docker a fortement évolué ces dernières années, aussi bien en termes de fonctionnalités que d’architecture. Nous avions, par exemple, dans la version 1.10 un seul et unique exécutable docker qui jouait le rôle de daemon et de client. En version 1.12, vous n’avez pas moins de 7 exécutables différents.

La rapidité avec laquelle les versions de Docker s’enchaînent a du bon, puisque chaque release corrige des bugs plus ou moins critiques et perfectionne le fonctionnement global de la technologie. Le souci, c’est que chaque version est susceptible de contenir de nouveaux bugs, spécifiques à certains usages et donc longs à apparaître.

Il en va ainsi du cas du daemon Docker qui ne répond plus lorsqu’il doit gérer un trop grand nombre de commandes Docker inspect (qui permet d’être renseigné sur les caractéristiques du conteneur) ou de Docker exec (qui permet d’exécuter une commande à l’intérieur du conteneur). Vous pouvez trouver plus de détails sur cette problématique sur le GitHub Docker.

La solution pour résoudre ce problème ? Un simple strace sur le processus père de Docker. Car le strace envoie un appel système ptrace, ce qui a pour effet secondaire de libérer l’appel système qui bloque.

Mais il nous fallait une solution plus sérieuse, et exploitable à grande échelle. C’est pourquoi nous avons « fixé » une version précise de Docker, celle présentant la plus grande stabilité dans le cadre de notre usage particulier. Nous avons également dû contourner certaines difficultés. En effectuant moins de Docker inspect par exemple. Et, lorsque nous développons une fonctionnalité, il nous faut garder à l’esprit ces différentes contraintes.

« Et la securité ? »

Docker utilise les mêmes mécanismes de sécurité que de la conteneurisation standard (comme LXC) : des « namespaces » et des « control groups ».

Les namespaces permettent, entre autres, d’isoler vos processus à l’intérieur de votre conteneur. Ils ne voient pas ou ne peuvent interagir avec les autres processus de votre host ou des autres conteneurs présents sur ce même host.

Les control groups permettent quant à eux de contrôler vos ressources : limitation en RAM, en écriture sur le disque, en utilisation CPU, etc.

Il reste tout de même un point de vigilance : le daemon de Docker ne doit pas être accessible, que ce soit de l’extérieur par un utilisateur lambda, ou de l’intérieur par un utilisateur système.

Rendre accessible ce daemon, c’est rendre accessible l’ensemble de vos conteneurs et leurs données. Également, cela aurait pour fâcheuse conséquence de créer un point d’entrée dans votre host et votre infrastructure. Et introduire une faille de sécurité dans une image Docker revient inévitablement à voir cette faille multipliée par le nombre de conteneurs sur lesquels l’image est déployée. Raison pour laquelle nous utilisons nos propres images, rigoureusement contrôlées.

Vous pouvez retrouver l’ensemble des points abordés, ainsi que d’autres moyens de sécuriser vos infrastructures dans la documentation de Docker.

Pourquoi Docker est notre ami

Facilité d’administration

Docker garantit que notre image MySQL fonctionnera de la même manière, quel que soit le type de host et d’environnement. Ainsi, les bases de données mutualisées sont hébergées exclusivement sur des serveurs dédiés, tandis que  les « SQL Privé » et « CloudDB » tournent respectivement sur des serveurs dédiés et des VM. Mais la même image Docker est utilisée.

Cette image Docker va nous permettre de configurer l’instance MySQL de manière standard. Elle écoutera sur le port 3306, et la configuration se trouvera dans le répertoire par défaut /etc/mysql/my.cnf du conteneur. Si nous voulions installer plusieurs instances MySQL sur un seul host sans conteneurisation, il nous faudrait une configuration par instance MySQL avec un port différent pour chaque instance MySQL.

Simplicité de maintenance

Dans le cas d’une mise à jour MySQL, nous sommes sûrs que si la mise à jour s’effectue correctement sur un conteneur, elle s’effectuera correctement sur l’ensemble de nos conteneurs exploitant la même image.

Les mises à jour constituent justement un point crucial, car nous savons que sans votre base de données, votre site a très peu de chance de fonctionner correctement. La procédure doit être rapide et sûre !

Voici schématisée notre procédure de mise à jour de MySQL :

En moyenne, nous constatons un « downtime » d’une minute par conteneur. Cela correspond au temps nécessaire pour que le conteneur ferme correctement l’application qu’il héberge. Il est déconseillé de fermer trop brutalement une instance MySQL. Le risque de corruption des données existe dans ce cas, nous y reviendrons.

A noter que nous utilisons la même méthode pour déplacer un conteneur d’un host vers un autre. La seule différence étant que nous effectuons un rsync des datas avant de stopper le conteneur A, puis après avoir stoppé le conteneur A, afin de garantir la cohérence des données.

Rapidité de déploiement

Comme vous le constatez sur le schéma ci-dessus, chaque host va chercher l’image sur un registry Docker.

Pour une plus grande rapidité de déploiement, nous récupérons (docker pull) chaque image sur les hosts avant de mettre effectivement en production une nouvelle image. Il nous suffit alors de faire une simple requête HTTPS vers le daemon Docker pour lui indiquer de mettre à jour les images souhaitées, ou de déployer un nouveau conteneur basé sur la nouvelle image.
Pour résumer, il nous suffit simplement de placer notre nouvelle image sur le registry pour effectuer la mise en production. On a vu plus compliqué !

OOMKiller, la bête noire des bases de données

Nous avons été confrontés à un souci particulier avec les conteneurs : l’OOMKiller. Cette fonctionnalité kernel permet au noyau Linux de stopper (brutalement) un processus qui dépasse la capacité maximale de mémoire disponible.

Par défaut en cas de dépassement de mémoire, la fonctionnalité cgroups envoie un signal de type SIGKILL au processus du conteneur. Lorsque le processus reçoit ce type de signal, il s’arrête immédiatement sans terminer la moindre action, ce qui peut provoquer une corruption de la base de données et donc des pertes d’informations.

Nous avons expérimenté différentes solutions.

1/ Changer les capacités Linux représentées par l’option « --cap-add » lors de l’instanciation du conteneur.

docker run --detach --memory 268435456 --cap-add=SYS_RAWIO

Avec cette « capacité » l’OOMKiller envoie maintenant un signal de type SIGTERM, indiquant au processus de se terminer proprement. Mais cela ne peut marcher, car le processus sature déjà 100 % de la mémoire disponible. Il ne peut donc plus allouer la mémoire nécessaire pour se terminer correctement. On se retrouve alors avec un conteneur bloqué.

2/ Désactiver l’OOMKiller grace à l’option –oom-kill-disable.

docker run --detach --memory 268435456 --oom-kill-disable

Dans ce cas-là, notre conteneur ne sera jamais « killed ».  Cependant, il ne peut obtenir plus de mémoire. De ce fait, il devra attendre que des plages mémoire soient disponibles pour se fermer, plages qui ne seront pas libérées car utilisées par le processus. On se retrouve dans la même situation que précédemment : un conteneur bloqué.

3/ La solution choisie : un deuxième deamon dans le conteneur.

Bien que cela soit contraire aux bonnes pratiques liées à l’utilisation de conteneurs, nous avons introduit un daemon qui se charge de surveiller la mémoire utilisée et d’envoyer lui-même un signal de type SIGTERM pour que le processus se termine correctement. Pour ce faire, le daemon doit envoyer le signal avant que le processus n’utilise toute la mémoire.

Simple ? Pas vraiment ! Car le concept de la mémoire Linux est d’allouer le maximum de mémoire possible, puis de réutiliser cette mémoire : une page libre est une page perdue (« A free page is a wasted page »). On obtient vite des conteneurs qui atteignent leur limite sans toutefois la dépasser. Le daemon passe donc son temps à redémarrer les conteneurs…

C’est pour cette raison que nous avons introduit la « soft-limit. »

docker run --detach --memory 268435456  --memory-reservation 255013684

Sur ce graphique, nous pouvons constater la différence d’utilisation de la mémoire par le conteneur avec et sans soft limit. Avec la soft limit, le conteneur vide régulièrement la mémoire non utilisée.

En parallèle nous avons augmenté la mémoire des conteneurs de 5 % et fixé la soft limit 5 % en-dessous de la mémoire définie dans l’offre. Le daemon ne relancera le conteneur qu’ une fois arrivé à la limite fixée dans l’offre, 256 Mo dans notre exemple.
De ce fait, il restera 12,8 Mo disponibles au processus pour se terminer correctement. Si au bout de 60 secondes celui-ci n’a pas réussi à se terminer, le daemon envoie un SIGKILL.

Halte à la corruption

Lorsque nous avons migré l’ensemble de nos clients sur notre nouvelle infrastructure Docker, nous avions énormément d’instances MySQL avec des erreurs InnoDB, de corruption, etc.

Nous avons développé un petit outil qui se sert de toute la mécanique de Docker : « ressurect-container ».

La première étape consiste à obtenir un dump MySQL. Sans cela, nous ne pouvons aller plus loin, mais c’est également la garantie que nous récupérerons l’ensemble des données contenues dans l’instance MySQL.
Pour ce faire, nous créons un nouveau conteneur avec les mêmes volumes que le conteneur d’origine.

Nous réparons ensuite l’ensemble des tables et effectuons un « mysql_check » de l’ensemble de l’instance.
Une fois ce dump obtenu, nous coupons l’accès réseau du conteneur et effectuons un nouveau dump afin d’obtenir des données cohérentes.

Lorsque le nouveau dump est obtenu, nous recréons un nouveau conteneur « xxxx-new » et nous insérons le dump dans la nouvelle instance MySQL vide.
L’ancien conteneur « xxxx-<date> » reste éteint quelques jours afin de pouvoir rollback sur l’opération. Il est ensuite supprimé automatiquement.

Cette procédure nous permet de réparer l’ensemble de vos tables et de corriger l’ensemble des erreurs InnoDB de votre instance (corruptions, logs dans le futurs, etc.).