The Doppler Quarterly (FRANÇAIS) Hiver 2016 | Page 47

Démystifier le paysage des outils de conteneurs Docker

Jon Baier
Voilà ce que nous pensons sur les capacités des meilleurs outils d ’ orchestration de conteneurs et les tendances du marché .
Le paysage d ’ outils d ’ orchestration
Il y a beaucoup de mouvement , d ’ excitation et d ’ énergie autour de Docker et des conteneurs , et un grand enthousiasme à l ’ idée d ’ adopter ce nouveau paradigme , au moins dans les environnements de développement et de tests . Avec toute cette agitation , et l ’ adoption par les développeurs , les entreprises ont bien raison de se demander comment elles vont gérer le chaos de leurs conteneurs .
Notre but est de clarifier les choses et de décrire ce que nous pouvons attendre des prochains mois .
L ’ une des difficultés associées aux outils actuels est qu ’ ils ne se chevauchent que sur certains éléments , et ne peuvent pas être comparés , point par point , pour l ’ intégralité de leurs fonctionnalités . Bien que beaucoup d ’ outils puissent se substituer les uns aux autres , dans certains cas , ils peuvent être utilisés conjointement . Dans le but de dissiper un peu le brouillard ( dans lequel le porte-conteneurs se trouve !), nous avons évalué les outils par rapport à cinq qualités clés : haute disponibilité , évolutivité et utilisation en situation réelle , facilité d ’ adoption , mise en réseau , et extensibilité au-delà des conteneurs . Dans cette dernière catégorie , nous avons cherché la capacité à s ’ intégrer à divers projets de développement , et notamment ceux qui sont peu ou pas liés aux conteneurs .
Haute disponibilité
Trois fonctionnalités ont été sélectionnées pour leur facilité de comparaison , et pour leur importance dans l ’ implémentation de la haute disponibilité , en particulier pour la mise en clusters . Nous nous penchons d ’ abord sur le basculement maître , et cela comprend la capacité d ’ un cluster maître à basculer et à choisir une machine existante comme nouveau maître . Nous examinons ensuite le suivi de l ’ état de santé , ou la capacité du système de savoir quand l ’ application et le cluster sont réellement disponibles . Enfin , nous étudions la replanification automatique en cas de défaillance . Si une partie d ’ un cluster subit une défaillance , nous voulons savoir quand notre charge de travail de conteneur est replanifiée et redémarrée . Mesos a un mode haute disponibilité qui utilise Apache ZooKeeper en interne . En mode haute disponibilité , plusieurs maîtres sont exécutés . Un maître actif est désigné pour être le leader . Si ce leader connaît une défaillance , un autre est désigné . Swarm et Kubernetes prennent également en charge une configuration maître « haute disponibilité ». Ce n ’ est pas une fonctionnalité prête à l ’ emploi , mais des guides existent pour la configuration pour les deux outils .
Swarm , Mesos et Kubernetes ont tous des méthodes TCP / HTTP pour le suivi de l ’ état de santé . Le suivi de l ’ état de santé en lignes de commandes va un peu plus loin en permettant l ’ exécution et la vérification de commandes spécifiques . K8s prend en charge ce type de vérifications en natif depuis un certain temps , déjà . De plus , Kubernetes a des structures intégrées de services , et le suivi de santé peut être utilisé pour évaluer les hôtes en état de santé suffisant pour recevoir du trafic de services . Mesos prend également en charge des suivis d ’ état de santé en lignes de commandes et a récemment corrigé certains problèmes qui empêchaient leur utilisation .
HIVER 2016 | THE DOPPLER | 45