Sysadmin Days #7
Grace à Techsys, j'ai eu l'occasion de participer à la 7e édition des Sysadmin Days. C'est un cycle de conférence très orientées OPS, par des barbus pour des barbus. Cette année, gros focus sur la conteneurisation et les outils DEVOPS. Note : ce mot est assez tabou, on ne l'entend pas, on entend d'avantage SRE, ouf. Nous avons donc rendez-vous dans les locaux de Mozilla. Le second sponsor, pour les goodies et la bière est Newlode.
Merci à Olivier Marquant pour ses relecture et corrections.
Par Renaud Chaput, Talegraph
Les containers … un mot que l'on entend partout en ce moment. Mais que sont-ils vraiment, quels sont leurs réseaux ?
docker c'est pour développeurs,
docker, c'est magique,
c'est en production en 2 minutes
c'est la mort du métier
Cette conf est vraiment chouette et reprend bien la base de la philosophie et entre en matière de façon assez poussée. On rappel que tout cela est basé sur les namespaces et cgroups disponibles depuis 15 ans dans le kernel linux. Pour les curieux, j'ai discuté de çà lors des RMLL de Metz. Quelques années plus tard, ça donnait un patch décrit sur Wikipedia.
Le tout a été enrobé, standardisé, marketté, ça a donné : docker
Tout ça marche avec un Dockerfile
Un fichier !
FROM pour commencer d'une image existante, ex: alpine (libc+busybox, et rappelons au passage que la libc n'est pas exactement la glibc : Wikipedia )
RUN pour passer des commandes de customisation de l'image initiale
COPY / ADD / ... ajout de fichiers
tout ça fait une image découpée, en layer, ce découpage permet une gestion de cache . Les images sont habituellement stockées dans des registry (sur S3, Gitlab, Porthus). En gros, l'image généré c'est du unionfs en read only couplé à un thinlayer en read write, ça se rapproche du Copy-On-Write du ZFS.
pour le démarrer, il faut gérer
ajouter éventuellement des volumes (local, nfs, drbd, aws, ....)
Il y aurait 2 milliards de containers déployés par semaine chez Google (source). Quid de la sécurité de l'image elle même). Comment mettre à jour les dépendances.
Avant tout Docker c'est un produit avec une entreprise et des services marchands même s'il existe aussi version communautaire, Moby comme offre d'appel. Docker c'est maintenant 1000 employés autour d'une offre marquetting.
Elle est issue de la Linux Foundation, c'est l'incubeteur de projets. containerd, rocket, kubernetes, prometheus ont été donnés à la fondation
CoreOs développe une alternative à Docker., fourni une distribution Kubernetes, tectonic ou encore la registry Quay.
Redhat, Google, RancherLabs, .... un tas d'entreprises cherchent à gagner de l'argent autour de l'écosystème.
docker run elasticsearch
pas prêt pour la production. Le dev peut même installer une docker machine s'il n'a pas l'environnement adapté.Des réunions informelles se tiennent de façon à peu près mensuelles. Elles ont généralement lieu sous forme de Forum Ouvert. Pour connaître les prochaines dates, rendez-vous sur Meetup.com. Techsys en avait organisé un en mars 2015 dans les locaux de Solidd. Le prochain n'est pas encore planifié. Vous pouvez rejoindre la communauté Slack. Inscription au Slack ici.
On peut s'entraîner sur le lab "online" fourni par Docker sur Play With Docker.
Docker propose également des courts en ligne. Les plus agguerris aimeront passer une certification. On peut aussi suivre un MOOC sur OpenClassroom.
Et, comme on l'a vu plus haut, installer Docker c'est facile :
Par Renaud Chaput, Talegraph
De l'historique à l'architecture technique, tout pour avoir une première compréhension de cet orchestrateur et pouvoir ensuite approfondir.
[](https://www.youtube.com/watch?v=Ompowc9pkBw"Introduction à Kubernetes - Renaud Chaput")
Kubernes est issu d'un développement Google, Borg. La version 1.0 voit le jour en 2015, elle a alors été donnée à la Container Fondation. Il y avait une volonté de la part de Google de ne pas rendre Bord opensource. C'est le projet le plus actif github avec près de 200 PR par jour !
Ce projet a été créé afin de scinder l'infrastructure de l'application. Il y a des le départ un vrai objectif de scalabilité, comme rappelé dans le Google SRE Book. Une belle vitrine a été le jeu Pokemon Go de Niantic qui oscille de 5000 à 20000 serveurs. Il y a de suit besoin de le rendre générique et flexible Kubernetes, pas comme Borg. Il est écrit en GO, il est prévu pour être portable, automatisable et extensible via des modules complémentaires.
C'est un très gros projet, il y a donc eu rapidement besoin de structurer le développement. On trouve donc un Code Of Conduct, un Contributor Level Agreement, une documentation claire et complète, et un même un guide pour comprendre comment contribuer au projet : code, documentation, bug report, ....
On trouve également une communauté slack, des groupes éphémères ou à la demande.
Le projet est piloté par des Committees composés d'employés à plein temps par Google, Redhat, ...
dans votre entreprise, vous n'avez pas 1500 développeurs sur un seul projet
Tout cela donne un aspect rassurant dans la stabilité de ce logiciel libre.
Les releases sont sur un rythme régulier : une release sur github apporte des features, des issue et un bot. On a une nouvelle version tous les 3 mois. Les features sortent sous forme de feature flag avec un binaire unique production et développement, ce n'est qu'un flag à activer pour bénéficier du bloc de features.
Un fichier de desciprtion d' objets en yaml sous forme de liste clé valeur. Le plus important en premier, la version de l'api. Ensuite, on retrouve le vocabulaire décris ci-desosus, le metadata, etc .... Kind, metadata, ....
Les Objets que l'on trouvera :
En terme d'architecture logicielle, on a besoin d'un
Par Raphael Mazelier, eTF1
Oui, Kubernetes, ça marche en production. Voyons comment réussir une migration avec succès.
etf1, c'est une équipe de 12 personnes pour gérer les applications d'une chaîne de télé qu diffuse essentiellement des vidéos sur un volume d'environ le 1/4 de Dailymotion, avec des pics à 180Gb/s.
Il s'agissait donc de migrer 1200 VMsVMWare hébergées chez Equinix. Le tout héberge une cinquantaine d'applications. Le socle, c'est 99% de CentOS qui font tourner du PHP, NodeJS, Capistrano (Ruby), Shell. Tout cela est administré à coup de shell et puppet. La plus visible étant bien sûr www.tf1.fr
Face à l'impossibilité de maintenir cet amas, tenir des objectifs de charge, la DSI choisi une revue d'architecture et se lance dans une migration vers docker. L'idée est d'en profiter pour passer tout le code en mode microservices. A l'époque les dev produisent des containers Docker mais en production, on a encore des VMs.
Clairement, ça ne marche pas.
Rapidement, besoin d'orchestrateur se fait sentir: ils effectuent des tests mesos avec marathon, et le choix se porte sur kubernetes en 2016.
L'infrastructure est maintenant très simple :
Toujours plein de scripts, Kubernetes a été déployé avec kubernetes-anywhere et kps pour l'admin quotidienne.
Ils regrettent, pour bien comprendre le fonctionnement de Kubernetes, rien ne vaut le Kubernetes the hard way
Désormais, les configurations sont livrées avec ansible et foreman on premises et AWS. terraform a été identifié trop tard dans le projet, il n'est donc pas utilisé.
La découverte de services est permise par 3 etcd hors docker, le réseau est géré par flanel en mode host-gw, il sera probablement remplacé par kube-router.
lci.fr est passé de 30 à 10 microservices.
L'objectif est d'avoir 90% de la prod à fin 2017
docker est imposé , on y met du rabbitmq, du nginx, et tout un tas d'application mais pas encore l'Offload SSL . En cherchant une doc KISS sur ce sujet, je suis tombé sur cet assistant assez cool : un générateur de configuration SSL ; un tuto pour HAProxy.
Toutes les data persistentes sont imposées sur s3, les datastores ne sont pas gérés dans Kubernetes.
Des politiques de restart, autohealth ont été implémentés mais attention, au début, c'était un peu de la magie, même si l'API est simple. Une bonne pratique a été de metre des labels partout et surtout d'utiliser du continuous delivery.
La production est identique on premise et sur AWS pour un PRA voire un PCA.
Ils sont arrivés à une maturité de déploiement continue qui emmène docker/github/jenkins.
Il a fallu réduire la dette technologique : minimum à apprendre. Exemple, les développeurs utilisaient docker uniquement avec docker-compose initiallement, rien à voir avec K8s.
Le monitoring est à réinventer : les objets, l'état des services/endpoints, le manque de visibilité initial, l'autorecovery masque les problèmes comme un memory leak nodejs, là encore il a fallu apprendre le fonctionnement.
Il faut maintenant remettre un peu d'ordre et de conformité sur la création des pods (ex limite de cpu/ram/affinité de noeuds).
Le vrai problème reste le réseau :
Le monde containers et kubernetes est très vivant, il faut toujours chercher les nouveaux projets, ceux qui ont été retenus :
Ce REX est formidable à plusieurs points de vue :
Par Florent Paulais et Guillaume Morin, Alkemics
Intégration continue et validation des tests avec des containers docker.
L'application se compse de 30 microservices codés en python & go répartis sur 4 environnements production/preprod/intégration/développement.
L'équipe est composée de 42 ingénieurs data scientists, des category managers et des SRE. En gros, un SRE chez eux c'est un syadmin qui fait du devops et de la QA pour faire de l'infra, de la prod, du tooling, de l'automation.
Quand il a fallu passer d'un serveur à plusieurs servers, ils ont choisi d'utiliser un produit maison, appelé Pillar.
En gros, quand un dev push sur le repo git, un bot notifie slack et crée une branche d'integration, lance un pipeline jenkins, ce job renvoie dans le slack si succes/ko et sur le github.
Il crée une branche d'intégration car les développeurs forkent le projet, on n'est pas sûr que leur branche de dev soit à jour, donc besoin de tester toute SA branche de travail. Tout se passe sur github en Saas.
Par définition, un test unitaire valide la plus petite partie de l'application, il n'est pas censé utiliser d'autres briques (base de données, ....).
C'est jenkins qui spawn les containers Docker: host, credential, capé à 100 pipelines.
Pour être utulisable par les SRE, le job est normé, il contient l'id du Jira pour savoir à quel besoin il doit répondre. Jenkins peut montrer les détails de l'échec qui remontent dans le Jira.
C'est un outil écrit en python pour orchestrer le lancement des dockers sur scénarios. Il crée les environnements via docker-compose. Une fois le pipeline accomplit, il archive les logs et détruit l'environnement créé. Le tout est orchestré avec BrowserStack. Il utilise shmid pour les injections de données en base.
Pillar, c'est 6 mois de travail à 2 personnes pour l'intégrer. Maintenant, cela ajoute du temps sur chaque PullRequest (3min35 entre build et test) mais le TimeToMarket est vraiment réduit : de 25 à 30 minutes entre build et mise en production.
Ils ont surtout diminé de 28% du nombre de bugs découvert par les clients !
Certains services ont été plus difficile à gérer (S3 par exemple). Ils ont ajouté des mock autant que possible.
Il a fallu imposer une norme : une montée de version à la fois.
Les principales difficultées du modèle : l'instabilité d'Azure.