Au programme :
Nomad, l'orchestration made in HashiCorp
Déployer des conteneurs en production n’est pas aussi simple qu’il n’y paraît, et de nouveaux concepts doivent être utilisés pour y parvenir.
La notion d’orchestration apparaît, et l’appliquer à ses containers a des avantages :
- rationalisation de l’infrastructure déployée
- simplification de la gestion des containers
- standardisation du déploiement des applications
- ordonnancement des tâches
- pilotage de l’infrastructure via des API
- sécurisation des accès externes et internes
- priorisation des tâches et applications
- densification des noeuds d'exécution
Après un rapide tour d’horizon des orchestrateurs existants, Bastien a fait un focus sur la solution developpée par HashiCorp, Nomad. Nomad est nativement distribué et sait gérer le multi-datacenter, le multi-cloud, et la haute disponibilité par l’utilisation du consensus via l’algorithme RAFT. L’outil est flexible car il tourne sur n’importe quel OS, il peut gérer du service ou du batch, et il y a une isolation des ressources allouées ainsi qu’une abstraction dans la définition des jobs. La solution est simple dans sa conception grâce à une configuration réduite, une binaire unique, et des librairies stables.
Après ces quelques explications, Bastien a réalisé une démonstration en partant d’un besoin réel : déployer une application sur une infrastructure de containers. Ce déploiement a été fait en plusieurs étapes montrant une évolution sur plusieurs datacenters à travers le monde, et chez plusieurs fournisseurs de cloud. Une application a été déployée et mise à jour suivant les évolutions de l’infrastructure.
L’ensemble des étapes ont été illustrées à la fois par de l’interaction en lignes de commandes ainsi que des fichiers de configuration utilisés lors de la démo.
Les slides sont disponibles ici et les sources là.
From Zero to Full Cloud : a journey to AWS
En partant d’une expérience de migration d’une infrastructure VMWare vers AWS, Laurent nous a présenté les avantages à l’utilisation de Terraform :
- il permet de déployer tous les éléments d’une infrastructure
- il n’est pas dédié à un fournisseur comme peut l’être CloudFormation
- les dépendances entre éléments sont gérés
- l’infrastructure est immutable
- la gestion de l’état de l’infrastructure est garantie.
Les fichiers d’état peuvent être externalisés de façon à permettre le déploiement de l’infrastructure par différentes personnes d’une équipe tout en gardant une infrastructure consistante. Ces déploiements multiples sont protégés par un lock afin d’éviter plusieurs exécutions simultanées.
Par la suite, Laurent a effectué une description de l’ensemble des commandes disponibles. Pour finir, il a introduit l’outil Terraforming, qui permet de récupérer le contenu d’une plateforme existante AWS dans des fichiers Terraform (description d’infrastructure ou fichier d’état).
Théo a réalisé un talk principalement constitué de démonstrations autour d’un cas concret : les différents clients ont différents comptes sur AWS. Une problématique de sécurité se pose dès lors, il faut en effet protéger les différents accès. C’est à ce moment là qu’intervient Vault. Il s’agit d’une “simple” API Rest qui enregistre les données chiffrées dans des backends (Consul, MySQL, etc …). De plus, Vault est capable de se connecter à AWS afin de créer des identifiants de connexion temporaires.
Place à la démo qui constituera l’essentiel du talk. L’architecture sera créé à l’aide de Terraform. Une fois cela effectué, il faut mettre en place le cluster Vault. En effet, afin de chiffrer les données, Vault utilise une clé qui est répartie sur plusieurs noeuds. Les données qui seront chiffrées auront dans un chemin défini (/secret/* par exemple). L’authentification sur un cluster Vault peut se faire au travers de backends (ldap par exemple). Afin de ne pas avoir à se réauthentifier régulièrement et gérer la durée de vie, l’utilisation de tokens est faite. Grâce à ces tokens, il est possible de créer des règles permettant de définir les permissions pour chaque utilisateur pour chaque chemin. Après avoir mis cela en place, Théo réalise des tests afin de démontrer le bon fonctionnement.
Enfin, Théo nous a présenté l’utilisation du backend AWS et comment cela a résolu le problème initial. La bonne pratique avancée par Amazon est d’avoir un compte central, puis de rebondir sur les autres roles en utilisant la directive assumeRole. En associant les policy Vault, et l’identification AWS on parvient à créer un environnement sécurisé de connexion à AWS géré par des tokens ayant une durée de vie limitée et dont les capacités sont limitées.
Les slides sont disponibles ici et les sources là.
Conclusion
Si vous voulez venir à un prochain meetup, n’hésitez pas à vous inscrire au groupe sur meetup.com. Et si vous avez envie de présenter, vous pouvez contacter les organisateurs du groupe via le même site.
Actualités
Actualités