Ce mardi 26 Juin se tenait à Paris, au pied de la Tour Eiffel, la troisième édition du Paris Container Day (https://paris-container-day.fr). Cette conférence avait pour but de partager une vision de l’écosystème des conteneurs d’aujourd’hui et de demain. Cette année, le thème de la conférence était « Vivre avec l’orchestration ». La question aujourd’hui n’est plus d’utiliser des conteneurs et un orchestrateur, le défi est maintenant de les déployer à grande échelle et d’adapter nos pratiques pour vivre avec l’orchestration.
Cette année, le PCD (Paris Container Day) a permis aux 450 participants de suivre des conférences passionnantes réparties selon 3 niveaux de connaissances/expertises : Débutant, intermédiaire et avancé. Autant dire que faire son choix était assez compliqué.
La première demi-heure de cette journée qui s’annonçait chargée a été surprenante dans le bon sens du terme. Un orchestre à corde est monté sur scène. Vivre avec l’orchestration. Quelle meilleure façon d’expliquer un concept qu’avec un exemple concret en images et en musique ?
Les comparatifs ont été nombreux entre les 2 situations. On a parlé du rôle du compositeur et de l’orchestrateur dans l’organisation, de la façon dont on travaille en groupe ou individuellement, de son empathie et de savoir reconnaître quand le groupe n’a pas besoin d’un maître d’orchestre… La matinée commençait bien sur les airs de musique classique…
C’est Liz Rice (@lizrice) qui a ouvert le bal des « conférences techniques ». Cette ingénieure de chez AquaSecurity nous fait le constat que les acteurs de l’univers des conteneurs sont préoccupés par la sécurité. Le monde a changé, la durée de vie moyenne d’un conteneur est de 2,5 jours, on est loin de nos applications « legacy » livrées quelques fois par an… En tant qu’acteur emblématique de la sécurité dans les écosystèmes Docker, Liz Rice nous a rassurés (pour ceux qui auraient encore des doutes). Si on veut appliquer un patch une image pour quelques raisons que ce soit, la seule façon de faire est de relancer le pipeline de CI/CD ! Evidemment, il a été abordé les thématiques comme les images policies intégrés dans les pipelines, les contrôles des configurations de la sécurité des serveurs et la protection au « runtine » des conteneurs….
Clairement, aujourd’hui, (peut-être) pour rassurer l’audience, Liz Rice a conclu par les avantages en terme de sécurité de l’utilisation des clouds natives :
David Aronchick (@aronchick) est venu parler de Machine Learning (ML). Ce product manager a travaillé pour quelques projets sympas Chez Google (Google container engine, kubernetes, …). Aujourd’hui, il est le co-fondateur de KubeFlow. Ce projet a pour vocation de faciliter le déploiement des écosystèmes de ML, qui sont à ce jour assez complexes. Vous expérimentez TensorFlow ? Vous avez un cluster kubernetes ?
Ce projet est pour vous…
Joe Beda disait en 2014 que « tout chez Google tourne dans des conteneurs ». Il est (entre autres) à l’origine du premier « commit » sur le projet open-source d’orchestration de conteneur nommé Kubernetes. C’est une version « hybride » du célèbre Google Borg, le système de conteneur de Google. On sait aujourd’hui que Google démarre deux milliards de conteneurs par semaine.
Kubernetes (k8s) avance très vite, pour être up-to-date, c’est assez compliqué (publication de nombreux patchs de sécurité, de feature). Au moment où j’écris cet article, je me demande si je dois installer la v1.10 ou la v1.11-rc (release candidate). On peut dire que le projet est super vivant. Mais ne faut-il pas regarder la concurrence ? avec DC/OS ou Nomad ?
Alexandre Beslic (@abronan), un ancien de la Docker Core Engine Team est venu nous présenté une vision high-level de sa vision des orchestrateurs. Il a posé une question intéressante : « Utilise-t-on le produit adapté à nos besoins ? ». Kubernetes par exemple permet de gérer jusqu’à 10K nœuds, mais qui a besoin de gérer un parc aussi grand ? (hormis les grandes entreprises). Il y a-t-il aujourd’hui des solutions pour de petits clusters entre 1 et 50 nœuds ? Swarm et Nomad peut-être ? Alexandre Beslic a fait une comparaison de l’architecture technique de ces orchestrateurs pour mettre en évidence les algorithmes de gestion de la persistance de l’état des systèmes. Nous aurions pu nous croire sur une introduction autour de la BlockChain, mais non… On a parlé de « systèmes centralisés » vs « systèmes décentralisés », de consensus et de fortes consistances. Sa présentation intéressante nous a emmené vers son projet (mantissa) ou comment refondre le système actuel et le remplacer par un système basé sur le concept de « consistance éventuel » (Causal Consistency), pour ne plus assurer l’ordre exact mais seulement la présence de l’information… etcd (la base de données distribuées utilisée avec k8s) n’a plus qu’à bien se tenir…
Quelques projets utilisent déjà le CRDT (Conflit-free Replicated Data Type _aka _Strong Eventual Consitency) comme CosmoDB (Microsoft), AntidoteDB, Bolt-on (Cassandra), …
Nous aurions pu débattre sur la pyramide des tests, sur le fait d’avoir plus de tests unitaires, que de tests de comportement et que de tests end-to-end (E2E), mais ce n’était pas le sujet… Sébastien Le Gall et Sébastien Lavallée nous ont présenté comment ils ont automatisé l’exécution de leurs tests end-to-end (E2E) avec k8s dans un monde distribué avec des caches, des microservices, des brokers… Evidemment, les stacks sont à reconstruire intégralement à la volée avec leur orchestrateur mais le plus intéressant a été la gestion multiple des namespaces (un par utilisateur pour la scalabilité et le parallélisme). Intéressant, dans un système distribué, il y a forcément des composants interdépendant (un process peut attendre une base de données…) et pour gagner du temps, quand on lance des batteries de tests, k8s offre des options de synchronisation au démarrage :
David Gageot de Google Cloud a commencé sa session par « Qui aime reconstruire son image docker, la tagger et la pousser dans k8s ? puis recommencer indéfiniment ? personne… ». Il n’avait pas faux. Il nous a présenté quelques outils pour développer efficacement dans un monde de conteneurs grâce aux projets Google Container Tools (https://github.com/GoogleContainerTools)
Ce fut une journée bien chargée. Mais ce qui m’aura le plus fait plaisir, c’est les retours d’expériences sur Nomad, l’orchestrateur de déploiement made by HashiCorp (aussi connu pour sa galaxie de produit : Terraform, Vault, …). Il est compatible avec tous les grands cloud providers : AWS, GCP, Azure, Digital Ocean. Original, il ne se limite pas seulement aux conteneurs, il gère aussi des applications standalones. Nomad est également capable d’optimiser l’utilisation serveur afin d’exploiter toute la capacité disponible plutôt que de créer plus d’instances. La question est : « aura-t-il une chance de résister face au mastodonte de Google ? »
