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
- le réseau : ajouter le run --net none ou host (carte reseau du host)
- exposer le port avec -p
- le tout génère une ligne iptables, on a rien inventé
-
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.
- On peut regarder CLAIR pour analyser le contenu ou
- Docker Bench For Security pour analyser les host et les configs
- container-diff, a tool for quickly comparing container images
- des orchestrateurs : mesos, kubernetes, AWS ECS, SWARM,
- de la gestion de conf: chef, puppet, ansible
- découvrir les services automatiquement : zookeeper, consul
- atteindre les services haproxy, traefik, envoy, linkerd
- cadvisor (simple et local)
- prometheus, le fork de BorgMon de Google
- datadog et Sysdig : ce sont des produits payant mais assez aboutis
- et fluentd pour les lires logs
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.
- les dev : sur les laptops des developpeurs, plus léger que VM comme vagrant, plus facile à distribuer, base connue mais sous réserve, un
docker run elasticsearchpas prêt pour la production. Le dev peut même installer une docker machine s'il n'a pas l'environnement adapté. - intégration continue et tests, on verra une présentation à ce sujet ensuite,
- le production : oui ça marche !
- Qu'en est il de la stabilité des API : politique de versioning = 1 release par mois
- est-ce possible de durcir la sécurité en jouant avec les capabilities segcomp, .... ? oui configurable container par container. Le tout n'est donc pas aussi bien isolé qu'un hyperviseur
- Est-ce certifié PCI-DSS : non.
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 :
- sur sa propre machine : Docs d'install'
- Avec une docker machine
- dans notre lab AWS : tu popup une VM dans EC2 ou directement un container via ECS
- dans notre lab OpenNebula : tu popup une VM CentOS ou SLES
- une bonne vulgarisation de la couche réseau sur Medium par Mark Betz
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.
[
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 :
- pods : un même namespace/cgroup. Dans ce pod on met des containers. Il est possible de un sidecar (container à côté si besoin) pas forcément que du docker. Lire la documentation. Le pod, c'est un peu comme la vm qui spawne des containers dockers. Dans les options de deploiement, on peut utiliser une clé réplicas pour définir le nombre de pods. kubernetes essaye de faire ce qui est declaré dans le plan deploiement. Il n'y arrive pas forcément. Le sidecar peut par exemple être uncontainer de monitoring dans un daemonset pour être sûr que l'application tourne partout.
- service : c'est un peu la description de l'expostion -p du run docker. On ne fait pas de port forwarding, mais on déclare des services.
- ingress : là où on défini le loadbalancer
- statefulset : pour définir les données persistantess dans les containers.
- autres : de quoi gérer des crons, des secret, des jobs, des networkpolicy, ... Il est possible de faire soi mmeme son type d'objet
- cluster : un cluster est une région, mais bien sûr attention à la latence réseau. NE PAS faire de cluster mondiaux, préférer l'ajout de de fédérations par dessus.
En terme d'architecture logicielle, on a besoin d'un
- etcd pour un couple de clé/valeurs distribué. Il annonce à une apiserver via grpc. L'API stateless assigne des services à un scheduler pour faire tourner les pods là où c'était prévu, les peuvent tourner en isolation.
- il faut donc un agent kubernetes ssur le serveur, kubelet, pour annoncer l'état de santé, des info cpu/ram/etc .... et poller le scheduler. Il faut penser à décrire les règles d'affinité, genre la base de données à côté de l'application, ou pas justement.
- un proxy, kube-proxy qui fait ni plus ni moins que de l'ipvs/ipable. Il est recommandé à ce jour de ne pas dépasser 100 pods par proxy issue.
- tous les containers discutent en NAT avec tous les containers, tous les noeuds discutent avec tous les containers
- les runtimes de containers supportés sont variés : docker, cri-o, frakti, rkt
- KubeDNS, basé pour l'instant sur dnsmasq permet la résolution DNS interne
- dashboard : liste objet, stats, ...
- ingress controllers (gcp, aws lb, haproxy, ....)
- heapster : collecteur vers grafana/influxdb
- Il est possible d'ajouter manuellement des capabilities linux dans les pods
- Il est possibilité de poser des quotas sur les namespaces mais pas sur les pods
- Il existe un objet PodSecurityPolicy : intégration de selinux dans le container
- possibilités RBAC possibilité de mettre des pod-reader sur des clusters de dev par exemple.
- helm = package manager avec des receipes
- Kops / Kube-AWS / Bootkube : tous ces outils permettent d'installer Kubernetes de façon simple et assistée.
- kube-lego : pour générer des certificats letsencrypt
- minikube : un moyen particulièrement simple pour découvrir le produit.
- la documentation, très bien faite.
- une référence pour comprendre : Kubernetes the hard way
- Lors des meetups lillois, on a pu voir :
- Yann Pelud a fait une démo de k8s dont les sources sont sur github sur un Meetup Docker,
- Christophe Furmaniak a fait une introduction très proche lors d'un meetup GDG/Devops. Elle comportait des tuyaux orientés "quotidien de l'Ops de prod', sur Slideshare.
- chez Techsys, un Rancher 2.0 est installé sur le lab AWS, c'est une distribution Kubernetes, modifiable via les cli kubectl ou rancher.
- chez Techsys, nous contribuons à kubernetes-the-hard-way, venez essayer avec nous !
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 :
- des cluster on premise over vm toujours avec des CentOS.
- un cluster d'integration de 100 pods et 400 containers
- 3 clusters pour la production, 400 pods et 4000 containers, 2,6 To de RAM, 640 vCPUs
- 1 cluster de PRA chez AWS: 1 master, 2 nodes, et un autoscale à 80 nodes. Le PRA marche !
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 :
- CNM vs CNI : lire le comparatif ici
- flannel difficile à appréhender, génère facilement des lignes iptables, mais vite indigeste
- cache dns à optimiser
Il a fallu produire un tas d'outil pour l'admin courante, on les retrouve sur github.
Il a fallu adapter la collecte de logs pour passer à un graylog en nom de domaine (mais à l'époque pb de cache dns) kubeproxy est en cours de remplcament par un développement interne en go sur le haproxy pour faire de l'affinité simple-ha-go.
- Respecter le 12 factors apps
- chez etf1 : alpine, logs transmis à graylog avec le x-request-id.
- La configuration interne doit être KISS : def.json, env.json + ENV_VARS pour surcharger si besoin
- Ajout de routes de monitoring :
- /metrics vers prometheus
- /liveness : pour faire l'autorestart via k8s
- /readyness : pas de restart, mais arrêt du flux
- Le dev doit prévoir le dashboard dans grafana, ex.
- l'appli doit intégrer un "circuit breaker" pour générer une coupure propre
- des tests de charge
- L'équipe développent devient responsable de toute la chaine du dev à la prod.
Le monde containers et kubernetes est très vivant, il faut toujours chercher les nouveaux projets, ceux qui ont été retenus :
- Istio & Mesh
- Linkerd & Mesh
- API en GRPC
- développer les applis en serverless
- Qu'est-ce qui est en place point de vue sécurité : rien à ce jour, au mieux il est imposé un build d'une image récentes
- Plan de Reprise d'acivités : des tests en réel sont planifiés régulièrement
Ce REX est formidable à plusieurs points de vue :
- ça peut marcher
- ça marche
- même pour des applis legacy on peut migrer vers du microservice/docker mais l'orchestrateur devient indispensable
- l'équipe DOIT éponger la dette technique et se réorganiser
- Kubernetes est une bon outil d'intégration de cloud hybride / PRA / PCA.
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.
- Si ok, la merge request est possible : ça détruit la branch d'integration, puis ça lance le pipeline jenkins (script groovy) sur les autres branches. Chaque service doit embarquer ses tests unitaires.
- Si ko, rejet, le dev DOIT reprendre son code.
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.
- difficilement applicable car Pillar est un dev interne, peu de liens vers les bons outils dans Jenkins, nos clients utilisent peu Github/Slack pour leur propre code mais
- ça donne de bonnes idées d'intégration
- et une bonne idée du quotidien d'un SRE : ici, donner des moyens techniques pour réduire ce fameux Time To Market.
Très utile à celui ou celle qui souhaite avoir une synthèse de qualité qui aborde la technique bien sûr, mais surtout les limites, la projection sur nos métiers, les usages, ce qui marche, ce qui marche pas, ...
Merci Olivier !