Infrastructure – Actualités

L’adoption des conteneurs chez Camptocamp

24 octobre 2017

Préambule

Les besoins d’abstraction et de portabilité auxquels répondent les conteneurs ne sont pas vraiment nouveaux dans le monde informatique. Cette notion est cependant devenue indispensable pour faire face à la complexité croissante des solutions informatiques déployées et accessible au travers d’Internet. Chez Camptocamp, nous avons déjà un long historique d’utilisation de conteneurs, tout d’abord avec la notion de chroot (intégrée depuis 1979 dans Unix et depuis toujours dans Linux) puis avec Linux-VServer qui offrait déjà certaines notions de quotas de ressources pour finalement évoluer vers OpenVZ qui paraissait déjà en 2005 comme une révolution.

Depuis 2006, de très nombreux efforts (initiés par Google) ont été réalisés dans le noyau Linux pour permettre de limiter, compter et isoler l’utilisation des ressources (processeur, mémoire et espace disque). Cet effort considérable, connu sous le nom de cgroups (control groups) a permis l’émergence de Linux Containers (LXC) puis de Docker, qui a été distribué en tant que projet open source à partir de 2013. Il existe aujourd’hui de très sérieuses alternatives à Docker, comme rkt (développé par CoreOS) ou plus récemment cri-o (issu du projet Kubernetes).

Aujourd’hui, des entreprises IT comme Camptocamp ne peuvent plus se contenter de développer et livrer une ou plusieurs solutions logicielles qui fonctionnent à un instant précis. Il s’agit désormais de mettre en place de véritables plateformes qui permettent d’orchestrer et surveiller, tout au long de leur cycle de vie, les différents composants de la solution déployée. Ces plateformes peuvent ainsi évoluer, aussi bien du point de vue fonctionnel (gestion des changements) que dimensionnel (scalabilité), afin de faire face à l’augmentation du nombre d’utilisateurs. La redondance des services qui permet d’assurer un très haut niveau de disponibilité doit aussi être prise en compte.

Début 2016 : adoption de Rancher Cattle

Durant l’année 2015, nous avons beaucoup utilisé Docker pour cloisonner des processus de build ou effectuer des déploiements mono-hosts dans lesquels nous avons isolé les différents services en autant de containers Docker. C’est mi-2015 que nous avons vraiment réalisé l’importance et la nécessité pour nous de monter en compétence sur l’orchestration de conteneurs. Les orchestrateurs résolvent de nombreuses questions liées à la distribution de services informatiques sur plusieurs serveurs, qu’ils soient physiques ou virtuels. Les principaux aspects gérés par les orchestrateurs sont :

  • multi-host network orchestration (overlay networks, software-defined networking)
  • gestion des placements et affinités
  • interfaçage avec des services de stockage
  • scalabilité (montée en charge)
  • répartition de charge
  • rolling ou blue-green upgrades

Fin 2015, nous avons procédé à différentes évaluations selon des critères préalablement définis et en adéquation avec nos besoins. Notre objectif était de déterminer l’orchestrateur open source le plus apte à être utilisé rapidement dans le cadre de nos projets et selon les besoins identifiés. Les orchestrateurs que nous avions passé à la loupe à cette époque étaient :

Nos différents tests nous avaient assez rapidement permis d’exclure certains orchestrateurs et notre attention s’était finalement concentrée sur Kubernetes, OpenShift et Rancher. Ces raisons sont rapidement explicitées ci-dessous.

Kubernetes

Début 2016, Kubernetes (communément appelé k8s) était déjà considéré comme une solution extrêment aboutie (dérivé de la solution Borg de Google) mais relativement difficile à mettre en œuvre. De notre côté, nous étions assez rebutés par l’idée de ne pas pouvoir (ré)utiliser les APIs standards fournies par Docker (principalement Docker Compose). De plus, les possibilités proposées par Kubernetes et son architecture nous semblaient disproportionnées par rapport à nos besoins de l’époque. Nous pensions également que la courbe d’apprentissage pour nos équipes techniques qui devraient interagir avec cette orchestrateur serait très (sans doute trop) importante.

OpenShift

En tant que partenaire Red Hat, Camptocamp était naturellement très intéressé par cette solution. Ceci d’autant plus qu’à partir de la version 3, OpenShift a totalement été ré-architecturé autour de Kubernetes. Sur le papier, cette solution ajoutait à Kubernetes l’ensemble des éléments nécessaires à l’orchestration de conteneurs dans un contexte d’entreprise (authentification, gestion des droits, registry privée, etc.), avec en plus de très nombreuses fonctionnalités liées au déploiement continu. Néanmoins, et après avoir testé la version 3.1, nous étions étions arrivés à la conclusion que les promesses n’étaient malheureusement pas “encore” au rendez-vous et qu’il nous serait impossible, en l’état, d’utiliser cette solution pour des projets en production. Au final nous étions séduits par l’idée d’une solution allant dans le sens d’une plateforme applicative “PaaS” (très orientée DevOps), mais nous avons dû constater que cette solution n’était malheureusement pas encore mature pour nos besoins.

Rancher

C’est un peu par hasard que nous avions, fin 2015, découvert cette solution. La philosophie initiale de Rancher était de s’appuyer au maximum sur les APIs standard fournies par Docker. Cela facilitait ainsi la prise en main de la solution pour des personnes disposant déjà d’une expérience avec Docker. Cette simplicité couplée à une interface de gestion extrêment intuitive nous a très rapidement séduit. De plus, et contrairement à d’autres solutions, les aspects de déploiement de Rancher lui-même étaient pleinement intégrés à la solution.

Début 2016, nous étions en mesure de tirer quelques conclusions par rapport à la maturité de ces différents orchestrateurs en gardant bien évidemment à l’esprit que ce domaine était très vaste et en pleine évolution. Les évolutions technologiques sont ainsi faites : elles apportent des réponses concrètes à des problèmes complexes mais en même temps remettent en question de nombreuses pratiques, adoptées et stabilisées au cours du temps. C’est continuellement une pesée d’intérêt entre innovation et stabilité.

Nous pourrions résumer notre sentiment début 2016 de la manière suivante:

Kubernetes était très impressionnant d’un point de vue des fonctionnalités mais il se présentait davantage comme une boîte à outils d’orchestration que comme une solution intégrable dans un contexte concret de projet.

OpenShift, quant à lui, se présentait comme une vraie solution intégrable dans un contexte d’entreprise et tirant pleinement parti des fonctionnalités éprouvées de Kubernetes, mais la version 3.1 n’était pas du tout mature, trop orientée “PaaS” et pas assez “CaaS”. Un aspect qui a depuis beaucoup évolué et qui était vraisemblablement lié, à cette époque, à la transition de la version 2 à la version 3.

Rancher, et son orchestrateur Cattle, était simple à mettre en œuvre et répondait pleinement à nos attentes du moment. Il nous semblait être la solution la plus raisonnable pour la mise en place de plateformes stables et l’adoption de nos équipes.

Juin 2016 : Rancher/Cattle en production

Début 2016, nous avons commencé à adopter massivement Rancher/Cattle pour des besoins internes, puis pour architecturer et déployer de nouveaux projets. Nous avons beaucoup appris durant toute l’année 2016 et au passage découvert à quel point l’utilisation de Docker et Rancher nous ont permis d’évoluer techniquement mais également culturellement. Au delà de la gestion des ressources et des services distribués, c’est réellement les aspects liés à l’intégration continue et au déploiement qui ont le plus bénéficié de ce changement.

La collaboration interne entre des personnes plutôt en charge des aspects opérationnels et des personnes chargées du développement a pris une tout autre dimension durant cette période : de nombreuses cloisons ont sauté et le fait de travailler avec des technologies communes nous a vraiment rapproché. A l’évidence, insuffler une culture DevOps dans une entreprise ne peut se faire simplement par la volonté, il faut impérativement partager des outils et repenser le cadre des responsabilités.

En mars 2016, Rancher propose coup sur coup Kubernetes et Docker Swarm comme alternatives à son orchestrateur historique Cattle. De notre côté, plusieurs projets partent en production avec l’orchestrateur Cattle et, hormis quelques petits problèmes de jeunesse, les retours sont très positifs. Adopter Docker et Rancher nous a également permis d’évoluer très rapidement sur de nombreux fronts. Du point de vue du provisioning, le développement d’une intégration avec Terraform a permis de totalement automatiser les déploiements d’environnements Rancher ; le couple Prometheus/Grafana a révolutionné notre approche du monitoring. Enfin, l’intégration du déploiement continu avec Jenkins a donné une nouvelle dynamique aux projets de développement. Tout ceci a pu être effectué sans devoir faire de concession en terme de maintenabilité et de sécurisation des différents services déployés, bien au contraire.

Début 2017 : Kubernetes est partout

L’utilisation de conteneurs se généralise un peu partout et en ce début d’année 2017, la plupart des nouveaux projets sur lesquels nous travaillons sont basés d’une manière ou d’une autre sur Docker. Nous sommes globalement satisfait de l’utilisation de Rancher/Cattle comme orchestrateur. Nous identifions cependant quelques aspects qui deviennent relativement limitants, en particulier l’absence d’une registry privée, un contrôle d’accès trop limité et quelques problèmes de stabilité réseau. Ces limitations en terme de contrôle d’accès ne permettent pas réellement la mise en place d’architectures multi-tenant, pré-requis au partage et au cloisonnement d’une plateforme et des ressources entre plusieurs organisations clientes distinctes.

Le début de l’année 2017 marque également un tournant dans la lutte féroce que se livrent les différentes solutions d’orchestration de conteneurs. À l’évidence, Kubernetes est en train de surclasser les solutions concurrentes, tant d’un point de vue technique qu’au niveau de la communication. Des développeurs charismatiques comme l’omniprésent Kelsey Hightower, contribuent à dynamiser la communauté Kubernetes, dont le nombre de contributeurs et d’utilisateurs ne cesse de grandir.

Cette adoption massive de Kubernetes comme une sorte de standard en terme d’orchestration de conteneurs se reflète concrètement du côté des éditeurs de solutions. CoreOS abandonne progressivement fleet au profit de Kubernetes, IBM intègre également Kubernetes dans sa solution Bluemix, Red Hat accélère le développement d’OpenShift en participant très activement au développement de Kubernetes, sans oublier VMWare qui s’active avec Pivotal autour du projet Kubo. Du côté de Rancher Labs, la communication et les efforts s’intensifient également autour du support de Kubernetes sans pour autant délaisser les évolutions de leur orchestrateur historique Cattle.

Avril 2017 : sortie d’OpenShift 3.5

Après plus d’une année de travaux intensifs autour de Docker/Rancher, nous décidons d’intensifier en parallèle notre veille par rapport à Kubernetes et OpenShift. En tant que Red Hat Partner, nous avons alors la chance de pouvoir participer à différentes formations et workshops en lien avec ce domaine, une opportunité que nous saisissons.

Après plusieurs semaines d’immersion dans Kubernetes et OpenShift, force est de constater que ces solutions ont considérablement évolué, tant du point de vue de leur déploiement qu’en terme de fonctionnalités. Notre impression est très bonne par rapport aux tests effectués fin 2015, début 2016. Nous restons néanmoins quelque peu sur notre réserve par rapport aux ressources (nombre de serveurs) nécessaires simplement pour mettre en place un cluster. À l’évidence, Kubernetes/OpenShift n’est pas réellement adapté pour de petits projets. L’utilisation de Rancher/Cattle nous semble toujours pertinente, même si nous avons de plus en plus le sentiment que Rancher Labs va finir par abandonner le développement de Cattle.

Pour valider nos compétences OpenShift, nous développons notamment différents “proof-of-concepts” et en particulier une démonstration de plateforme d’intégration et déploiement continu d’une solution développée par notre département Geospatial et nommée GeoMapFish. Cette démo ne se contente pas d’utiliser les primitives d’orchestration Docker de  Kubernetes, mais fait appel à la très grande majorité des possibilités d’OpenShift. Elle utilise notamment les processus de création des images Docker Source-to-Image(S2I), les possibilités d’intégration Jenkins ou encore l’utilisation de Helm conjointement à OpenShift pour encapsuler les composants déployés. Cette démo a notamment été présentée lors du dernier Red Hat Forum qui s’est déroulé dernièrement à Zürich.

Septembre 2017, sortie de Rancher 2.0

Notre sentiment par rapport à l’avenir de Rancher/Cattle se confirme le 26 septembre 2017 avec l’annonce de Rancher Labs concernant la sortie de la version 2.0 de Rancher. Après avoir abstrait différents orchestrateurs dans sa solution, Rancher Labs décide de revoir sa stratégie et de finalement tout miser sur Kubernetes en dévoilant sa nouvelle version majeure. La communication qui suit cette annonce apportent des éléments rassurants pour les utilisateurs de Rancher/Cattle. Notamment le fait que la version 1.6 de Cattle sera maintenue au minimum jusqu’à mi 2018 et que la transition entre Rancher Cattle et Kubernetes sera facilitée par le fait par une importante couche de rétro-compatibilité.

Futur

Cette convergence vers Kubernetes n’était pas écrite d’avance, mais d’une certaine manière elle a le mérite de clarifier une situation complexe en recentrant les efforts de nombreux contributeurs open source (comme Camptocamp) vers un écosystème cohérent autour du projet Kubernetes et sous la gouvernance de la Cloud Native Computing Foundation (CNCF).

Du côté de Camptocamp, nous souhaitons clairement poursuivre et intensifier nos efforts autour de la solution OpenShift qui arrive à maturité sans pour autant tourner le dos à d’autres plateformes comme Rancher qui s’appuient également sur Kubernetes. Créer des applications déployables sur différents cluster Kubernetes est tout à fait possible, le projet Helm va clairement dans cette direction, et nous espérons que notre expérience de développement de providers Terraform pourra contribuer à améliorer l’automatisation des déploiements basés sur Helm.

Red Hat a ajouté à Kubernetes des services extrêmement utiles pour des déploiements “on-premise” et pour des clients qui souhaitent garder un haut niveau de contrôle sur leur infrastructure. Utiliser des conteneurs ne se limite clairement pas au choix de l’orchestrateur : beaucoup d’autres aspects (pas seulement techniques) doivent être repensés et adressés et c’est sans doute sur ces aspects que Camptocamp a le plus investi et appris depuis plus de 2 ans. Une expérience que nous mettons quotidiennement au profit de nos clients, aux travers de très nombreux projets ou via nos propres plateformes applicatives.

  1. *
  2. *
  3. *
  4. *