La deuxième édition de Paris Container Day a eu lieu le 14 juin et nous y étions. Cette année le thème était “Les containers en Production”. L’objectif étant de montrer qu’en plus de toute la hype qu’il y a autour du sujet des containers avec Docker et Kubernetes, par exemple, il y a actuellement des infrastructures qui utilisent les containers pour des workloads de production et que cela ne se limite pas aux environnements de build ou de développement.
Il est toujours difficile de faire un compte rendu d’une conférence : on a tendance a être très subjectif notamment via notre propre expérience et de ses propres attentes. Globalement la journée était intéressante et il y a eu de bons talks.
Ce qu’il faut en retenir
Pour ne pas rentrer dans un résumé de chaque talk qui aurait peu d’interêt (mieux vaut les revoir dès qu’ils seront disponibles sur Youtube, voici ma vision de la journée via les trois grands thèmes qui sont le plus souvent revenus.
Orchestration / scheduling
On aurait pu s’attendre à voir une déferlente de talks sur Kubernetes. Ça n’a pas été le cas. Bien au contraire, il y en a eu pour tous les goûts. Si c’est un choix des organisateurs, c’est très bien, cela permet de montrer la richesse des solutions actuelles et d’apporter des axes de réflexion supplémentaires en dehors de l’effet de mode ou du marketing autour de certaines solutions.
Si je devais m’hasarder à classer les solutions présentées :
Kubernetes / rkt
Kubernetes est sans doute la solution la plus avancée et la plus adaptée aujourd’hui pour des infrastructures Web.
Le système de packaging Helm apporte des fonctionnalités supplémentaires à K8s notamment via le templating. On peut ainsi créer de nouvelles solutions aux développeurs (rappelons que l’autonomie et l’automatisation sont des points promordiaux dans une démarche devops). Janson Hansen (Microsoft/Deis), auteur de Helm, a d’ailleurs présenté Draft, un nouvel outil pour aider les développeurs à déployer leurs applications en apportant une couche d’abstraction à la création d’un container Docker : Draft détecte l’application et s’occupe de toutes les opérations nécessaires pour la création du container et son déploiement sur un cluster Kubernetes. Draft va même “surveiller” les modifications et relancer la chaine de build automatiquement. On se retrouve avec une sorte de “CI/CD” locale, pendant la phase de développement. La vocation de Draft reste le développement. Pour la production, on continuera d’utiliser nos solutions préférées (Gitlab CI, Jenkins, etc).
Toutefois, BlaBlaCar a montré qu’il est possible à la fois de se passer de Docker et aussi de Kubernetes en présentant son infrastructure à base de rkt. Peut-être qu’aujourd’hui ils ne feraient pas le même choix mais à l’époque, la maturité des solutions n’étaient pas satisfaisantes et rkt répondait à leurs besoins. Actuellement, après pas mal d’adaptation et la création de nouveaux outils pour l’exploitation de leur archictecture, plus de 4000 containers sont en production. Le site BlaBlaCar.fr est sans doute l’une des architectures en production la plus importante avec rkt. Très satisfait du résultat et de la stabilité, pour le moment, il n’est pas envisagé de changer “quelque chose qui marche” !
Mesos
La solution la plus mature, capable aussi bien de déployer des workloads de map reduce que des containers (il faut bien s’adapter à son temps). Avec Mesos, on est sur des concepts robustes. On pourrait évidement déployer a peu prês n’importe quoi mais je pense que cette solution à plus de sens sur du “job” (sa raison première d’être) que pour faire tourner son application Web. Mais, ça reste possible et peut-être une bonne solution si un cluster est déjà existant.
Mesos apporte une gestion fine des ressources: RAM, CPU, Disk et donc du “placement” des jobs.
Nomad
La “petite dernière” des solutions de scheduling de chez Hashicorp. Malgré sa relative jeunesse, c’est aujourd’hui un outil robuste s’appuyant sur des fondamentaux qu’on retrouvent dans tous les outils d’Hashicorp:
- Raft
- Hashicorp Configuration Language
- Intégration avec les outils : Vault et Consul
Avec Nomad on peut aussi bien déployer des scripts bash, des binaires que des containers. C’est donc une solution relativement flexible.
La configuration est simple, la création d’une tâche aussi et on peut déployer des applications (service) ou des tâches éphémères (cron par exemple). Comme Mesos, il y a une gestion des ressources (ce dont j’ai besoin pour ma tâche vs les ressources disponibles sur les différents noeuds). On peut facilement créer des clusters “multi datacenter” :
- haute disponibilité, par exemple, multi-cloud
- pratique pour déplacer des workloads d’un cloud vers un autre (ou du on-premise vers le cloud) en faisant tout cohabiter dans le même cluster de ressource et en jouant simplement avec le “placement” des tâches
Le seul bémol, pour l’avoir utilisé, c’est le manque de clarté sur l’état des tâches.
Monitoring
Non content d’apporter de nouveaux paradigmes dans la gestion de l’infrastructure, dans le développement ou encore dans le cycle de déploiement, les containers remettent aussi en cause nos vieux concepts de monitoring. Nous avons déjà abordé ce point lors d’un Meetup Paris monitoring.
Le monitoring est un terme un peu fourre-tout dans lequel il y a 3 “familles” ou 3 attentes :
- La métrologie
- Le monitoring (est-ce que ça fonctionne ?)
- La gestion des logs
Tout ce que nous pouvions faire avec des infrastructures classiques n’est plus possible avec les containers :
- on ne va pas déployer un agent de monitoring dans chaque container
- les logs nécessitent d’être centralisés (on ne se connecte par sur un container) et assez détaillés pour l’analyse a posteriori
- on se focalise sur le service rendu, un container qui tombe ou qui crash est un comportement “normal” (le scheduler se charge de le relancer)
Quelles recommandations par rapport à l’expérience des plateformes en production ?
- Évidement Prometheus reste une solution à privilégier lors d’un déploiement de Kubernetes: très bonne intégration (notamment avec Prometheus Operator)
- On va monitorer le host des containers et pas forcement les containers eux même (un seul processus par container)
- Les containers doivent exposer des API pour être monitorés (métrologie ou surveillance)
- Cela demande donc d’impliquer les développeurs dans le cadre des containers “applicatifs”
- Le monitoring métier doit être la première source d’alerte
- pas assez de commande sur le site: est-ce qu’il y a un probleme ?
- un container qui crash mais le service est toujours disponible : pas d’alerte
- La centralisation des logs devient indispensable : on ne peut plus aller chercher les logs à la main, on ne sait pas où sont vraiment les containers ou où ils étaient
- on retrouve donc beacoup le pattern : rsyslog / fluentd,kafka,etc / logstash / Elasticsearch / Kibana comme outils utilisés
Sécurité
Jessie Frazelle a fait un point sur les posibilités actuelles et à venir concernant la sécurité des containers et de Kubernetes. Que ce soit avec les namespace, BPF ou encore Seccomp, pas mal de configuration sont envisageables. Je vous conseille vivement de regarder la présentation, cela sera plus pertinent qu’un résumé :
Autres
Durant les présentations, deux outils ont attiré mon attention.
Le premier est Linkerd. C’est un outil de Trafic Management. Il est utilisé par VentePrivé sur leur plateforme Kubernetes. Le produit semble très intéressant, beaucoup de fonctionnalité dont le support de gRPC. A creuser comme alternative à Traefic, Fabio ou encore Istio.
Le deuxième est WireGuard. C’est un outil qui se présente comme une alternative aux VPN SSL et VPN IPSEC: plus performant et plus simple. Idem, à creuser et à tester.
Conclusion
Malgré un format un peu dense (et en plus il y avait plusieurs Meetup organisés en soirée !), c’est une des meilleures conférences à laquelle j’ai pu participer depuis longtemps: un contenu de qualité, dans l’ensemble les présentations étaient toutes intéressantes et enrichissantes.
Rendez-vous l’année prochaine sans aucun doute ;)
Auteur : Guillaume Leccese