ContainerCon jour 2 et 3 : Think Open

Ce salon était une première pour Osones, nous avons donc décidé d'y aller en petit comité.

Les Keynotes : Brandon Philips, CTO, CoreOS

Brendon parle de la securité dans les conteneurs et les VM, notamment sur la plate-forme de build Quay.io et de la manière de s'assurer que les builds des utilisateurs n'en affectent pas d'autres. La réponse est dans le titre de la Keynote : Un mélange de conteneurs et de machines virtuelles.

Les machines virtuelles ont beaucoup fait parler d'elles durant cette Containercon. Notamment la nouvelle tendance de faire fonctionner des machines virtuelles dans des conteneurs. C'est déjà possible, notamment dans rkt et Google le fait depuis des années avec Borg. Pourquoi une telle tendance ? D'une part pour des raisons de securité et/ou de multi tenancy : l'isolation des machines virtuelles étant plus complète que celle des namespaces Linux, d'autre part, parce que les machines virtuelles tournant dans des conteneurs Linux profitent ainsi de la souplesse des COE (Container Orchestration Engine) et d'une isolation maximale.

Et maintenant, un petit tour du côté des sessions.

CoreOS : architecture et sécurité de rkt

Rkt est le container runtime créé par CoreOS et Open Source. L'architecture de rkt diffère de celle de Docker. Tout d'abord rkt n'est pas un daemon et n'implémente pas toutes les fonctionnalités de runtime des conteneurs.

- systemd/bash/runit
  - rkt (stage 0)
    - stage 1
      - stage 2 (applications)

Il s'appuie sur des composants existants et externes afin de fournir des fonctionnalités. Rkt est divisé en stage :

• stage0 : rkt, récupère les images, vérifie l'intégrité, crée l'environnement du pod, gère le durée de vie du pod.
• stage1 : environnement d'exécution du pod, quelle isolation ? Le stage 1 est interchangeable :
  • stage1-coreos : basé sur systemd-nspawn + systemd (namespaces et cgroups pour isolation)
  • stage1-kvm : basé sur lkvm + systemd (machine virtuelle pour l'isolation)
  • stage1-fly : pure chroot
  • stage1-qemu : basé sur qemu
• stage2 : les différentes applications présentent dans pods, peuvent partager des namespaces

Par défaut, rkt réutilise systemd, que se passe-t-il en pratique ? Systemd supporte déjà la redirection d'IO, les volumes, les privilèges etc. Ce qu'il est possible de faire avec Docker peut également être réalisé avec rkt + systemd.

A l'instar de Docker, rkt crée un systemd-pid1 dans le pod, dans le cas où plusieurs applications sont utilisées, ce qui permet d'avoir les fonctionnalités de monitoring de processus propres à un init system. De plus rkt s'intègre parfaitement avec les outils systemd :

• journalctl
• machinectl
• systemd-status

En terme de sécurité, comme Docker, rkt et systemd sont dépendants des fonctionnalités incluses dans le Kernel (seccomp, cgroups, capabilities) et sont affectés par leurs vulnérabilités.

En ce qui concerne l'intégration avec des COE (Container Orchestration Engine), rkt est dans la philosophie Kubernetes avec la notion de pods. De plus rkt est déjà compatible avec CNI (Container Networking Interface) sur laquelle s'appuie Kubernetes.

CoreOS et rkt travaillent avec Kubernetes afin de standardiser CRI (Containeur Runtime Interface) et permettre aux différents container runtime d'être pilotés simplement par Kubernetes.

Ce projet est appelé rktnetes et se base sur rktlet.

Sysdig, monitoring pour les microservices:

Sysdig est une solution de monitoring qui va permettre d'apporter un peu de visibilité au vaste écosystème des conteneurs. Notamment dans les COE comme Kubernetes, Swarm ou Mesos.

Sysdig est un vrai couteau suisse qui permet d'analyser quasiment tout ce qu'il se passe sur un système : system calls, processus, activité des utilisateurs, IO, etc. La solution a pour but d'être très light, production ready et de supporter nativement de multiples technologies de conteneurisation, que ce soit les COE cités précédemment mais encore Docker, rkrt ou LXC.

Le cloud et les conteneurs ont ajouté beaucoup de complexité, de par la distribution des applications. Mais comment superviser un cluster composé de multiples systèmes et de microservices ? Comment corréler les données de tout un cluster ?

Options : - monitorer l'hyperviseur : pas assez d'information - agent dans les instances/conteneurs : ne scale pas, ajoute de l'overhead, surtout pour les conteneurs - monitorer les OS hôtes des conteneurs : comme pour les hyperviseurs, toujours un manque d'information

Sysdig data collection utilise un module Kernel pour intercepter et analyser les system calls

Sysdig propose également une version Cloud : Sysdig Cloud, qui permet d'envoyer et d'aggréger les métriques de différents systèmes monitorés et supporte de multiples applications (Hadoop, Docker, Nginx, etc), dans le même style que Datadog, une autre solution de monitoring orientée Cloud.

Sysdig travaille également sur Sysdig Falco, pour la détection d'anomalie, par exemple vous avertir si un shell est executé sur un conteneur. La solution est basée sur le moteur de Sysdig et est completement configurable via des règles de détection.

Zuul "Test it like you Deploy it".

Monty Taylor, bien connu dans le monde OpenStack, nous présente Zuul, un système d'intégration continue multi-cloud. C'est le système utilisé par OpenStack, qui fait tourner environ 2000 jobs par heure, pour un total d'environ 10 000 changements validés par mois. Une des particularités de Zuul est qu'il est capable de déployer des machines virtuelles spécifiques pour jouer des tests qui nécessitent des droits root.

Zuul fait la distinction entre trois types de tâches : * Periodic : démarrées via un timer, comme par exemple une crontab, * Post : executées après un changement, typiquement lors d'un merge github d'une branche de développement vers la branche master, * Check : exécutées lorsqu'un changement est proposé. Elles se retrouvent principalement dans les systèmes de review comme gerrit. * Gate : Ces tâches se déroulent entre l'approbation et la livraison effective.

Zuul permet d'exécuter des tests complets à chaque commit, en traitant de manière complètement automatisée toutes les tâches, jusqu'au "Gated commits", qui posent problème sur les autres systèmes de CI. L'autre intérêt de Zuul, non négligeable, est qu'il est capable de scaler massivement. Avec Jenkins, il est préférable de créer plusieurs masters pour satisfaire des besoins comme la CI d'OpenStack.

Aujourd'hui, Zuul est développé principalement en tenant compte des contraintes liées à la complexité et à l'échelle du build d'OpenStack. La suite ? Réaliser la chaîne de build du projet Ansible.

Vous pouvez retrouver la présentation ici

La LinuxFoundation fête les 25 ans de Linux !

Mercredi soir, la Linux Foundation fêtait les 25 ans de Linux. 25 ans de Linux, ça se fête, surtout lorsque l'on regarde le chemin parcouru et les difficultés que nous avons eues pour faire adopter cette technologie face aux logiciels propriétaires. Nous avons tous, chacun à notre niveau, contribué à l'adoption de cette technologie. Bref, nous aurions aimé que cet évenement soit plus festif, comme vous pouvez le voir sur ce tweet :

Et c'est la fin !

La ContainerCon touche à sa fin, à l'heure ou nous écrivons ces quelques lignes, la keynote finale se déroule devant nous.

Rendez-vous dans quelques semaines pour l'OpenStack Summit à Barcelone !

Pierre Freund - @ospierrefreund
Kevin Lefevre - @ArchiFleKs