24
oct

Pause Cloud & DevOps
spéciale DockerCon Eu

 

Aujourd’hui, la Pause est dédiée à notre retour sur la DockerCon Europe qui se déroulait à Copenhague du 16 au 19 octobre.

L’occasion de faire une pause et de suivre l’actualité de Docker, résumée pour vous en français par les consultants d’Objectif Libre présents sur place : Maxime Cottret et Sandrine Perrin.

Prenez un café et quelques minutes : faites une pause !

 

Au menu :

  • Retour sur les keynotes
  • La DockerConEu vue par Maxime : BlackBelt et sécurité
  • La DockerConEu vue par Sandrine : Cas d’utilisation de Docker
  • Retour sur le projet Moby (Moby-Summit)

 

Les vidéos des présentations sont mises à disposition sur le site de la conférence, les deux keynotes sont déjà disponibles.

Les keynotes: beaucoup de MTA et un peu de Kubernetes

L’orientation « Entreprise »

Docker devient de plus en plus Docker Inc et les deux keynotes ont bien marqué l’essor du produit Docker EE et l’orientation « Entreprise » prise par Docker.

Docker explique : toute les sociétés s’orientent vers des activités de fournisseurs de services logiciels – cf. par exemple l’automobile avec les voitures connectées et autonomes. Toutes vont donc avoir besoin de leur « supply chain » logicielle et Docker est là pour fournir la plateforme socle avec Docker EE.

Le programme MTA

La volonté affichée de Docker Inc est de permettre une migration vers la « supply chain » logicielle sans rupture, sans remise en cause de l’existant. Pour cela, Docker a mis en place le programme MTA (pour Modernize Traditionnal Applications) en association avec des sociétés de services partenaires proposant une méthodologie de transition (qui rappelle les grands principes du DevOps), et de l’outillage comme le Docker Application Converter, capable de prendre le backup d’une VM et de créer le Dockerfile associé.

 

Pour appuyer le discours, Metlife est venu présenter son retour d’expérience (et retour sur investissement) du programme MTA.

 

S’ensuit une rapide présentation de quelques fonctionnalités intéressantes de Docker EE permettant de mettre en place cette supply chain :
* Sécurité de bout en bout, dans Swarm comme dans le registre avec DTR (communication avec TLS, signatures d’images, etc)
* Mise en œuvre d’accès basé sur les rôles
* Nouveau dans la dernière version de DTR, des politique de contrôle et de gestion des images permettant de promouvoir automatiquement des images à partir de certains critères comme l’absence de vulnérabilités connues, la taille de l’image ou l’adhésion à une liste blanche de binaires.

Intégration de Kubernetes

Solomon Hykes, fondateur et CTO de Docker, arrive ensuite pour présenter LA nouveauté de cette DockerconEU: l’intégration de Kubernetes comme orchestrateur de premier ordre dans Docker !


Il s’agit d’une réelle intégration (et pas d’un simple wrapper) et la première démonstration de déploiement d’un docker-compose sur des nœuds Kubernetes fait son petit effet.

 

Le cluster reste pilotable avec la CLI de Kubernetes, notamment les objets stack implémentés comme des CustomResources. L’utilisation d’une version non-modifiée laisse espérer un suivi relativement proche des montées de version de Kubernetes.

Kubernetes sera disponible dans Docker EE, Docker4mac et Docker4windows. On apprendra ensuite, au déjeuner de la communauté française, que CE sous linux arrivera plus tard, l’intégration étant moins évidente que Docker4mac et Docker4windows, deux solutions complètement packagées.

 

Docker devient donc une distribution Kubernetes à part entière, en attendant de pouvoir utiliser un cluster existant. Kubernetes dans Docker sera disponible en Q1 2018 et il est possible de s’enregistrer pour tester les beta sur www.docker.com/kubernetes.

Rapprochement Moby-Kubernetes

Cette présentation est l’opportunité de parler du rapprochement des communautés Moby et Kubernetes et d’annoncer la donation en cours de Notary, le système de signature des images Docker, à la CNCF.

Keynotes #2

La seconde keynote était moins riche en annonces : les intervenants se sont succédés pour parler de MTA sans présenter de cas réel de migration, et pour présenter leur solution, comme le nouveau partenaire IBM avec sa solution de cloud Bluemix.

Ressentis côté communauté

A l’issue des keynotes, beaucoup de participants restent sur leur faim et le manque d’annonces côté fonctionnel se fait sentir, y compris au niveau de DockerEE.

Une solution de stockage intégrée, suite au rachat de infinit.sh il y a maintenant un an, était particulièrement attendue par l’auditoire … et puis rien de ce côté pour le moment. On apprendra également au déjeuner de la communauté française que le problème du stockage est relativement complexe, avec bien plus de cas d’usages que le réseau par exemple, et que Docker ne souhaite pas se tromper alors que sa solution part de plus en plus en production. Solomon a cependant évoqué que des cas d’usages sont bien à l’étude.

 

Les sessions de la DockerConEU – vues par Maxime

Par Maxime Cottret, Consultant Cloud @Objectif Libre

 

J’ai principalement participé aux sessions de la Black Belt, track relativement technique et focalisée sur les mécanismes de bas niveau. J’ai tout de même fait une entorse pour assister à la session sur la sécurité par Diogo Monica, « M. Sécurité » chez Docker. Ci-dessous un résumé des sessions les plus intéressantes.

Linuxkit Deep Dive

Premier effort officiel du projet Moby, LinuxKit est une solution de création de serveur complet basé sur des conteneurs:

  • Un fichier de description permet de définir un noyau linux, une version de RunC et ContainerD puis un ensemble de conteneurs.
  • Le système de compilation permet ensuite de générer une image de serveur dans différents formats: AWS, raw, qcow2, iso ou simplement un répertoire.
  • Une commande linuxkit run permet même d’exécuter l’image créée directement depuis un terminal.

 

LinuxKit est donc une solution de création automatisée d’appliance logicielle et se présente comme la première brique de fabrication d’une chaîne de production dite immutable où les serveurs ne sont plus mis-à-jour mais reconstruits. Cette technologie est utilisée comme socle des produits Docker4Mac et Docker4Windows ainsi que des produits Cloud.

How and why prometheus’ new storage engine pushes the limits of time series database

Prometheus est la solution de monitoring la plus en vue dans le monde du cloud et des conteneurs grâce à ses fonctions de découverte automatique des services, d’un système de requêtage puissant et d’un système d’alerting relativement expressif. Cependant, Prometheus 1.X souffre de nombreux problèmes, notamment au niveau du backend de stockage.

 

Cette session présentait les efforts fait au niveau de l’architecture du stockage des index (méta-données sous forme de clé/valeurs associés à une métrique) et les données temporelles en elle-mêmes. Le présentateur a notamment appuyé sur les efforts faits pour gérer des métriques limitées dans le temps: contrairement à un serveur classique, les conteneurs dans une architecture type ont une durée de vie limitée.

 

Les benchmarks comparatifs montrent une réelle progression dans les capacités de traitement de Prometheus, tant au niveau stockage pur que consommation en CPU/RAM du serveur.

Pour plus de détails, en attendant la mise en ligne des slides et de la vidéo, je vous invite à lire cet article de CoreOS reprenant l’essentiel de la session.

Cilium: Kernel native security et DDOS mitigation for microservices with BPF

Cilium est un nouveau venu dans le monde des plugins réseaux pour les solutions de conteneurs (Docker, K8S, Mesos/Marathon,Cloudfoundry). Il apporte cependant une réelle innovation: l’utilisation des Berkeley Packet Filter (BPF) et eXpress Data Path (XDP) pour gérer le routage, la répartition de charge et les politiques de sécurité réseaux.

 

BPF et XDP sont des capacités récentes du noyau linux permettant d’injecter du bytecode à la volée dans le noyau ou directement au niveau de l’interface physique de façon sécurisée, via de l’analyse de code statique auquel l’équipe de Cilium a participé. L’utilisation de ces technologies permet de réduire drastiquement la charge induite sur le CPU pour le traitement réseau, voire même avec XDP de filtrer les paquets avant même leur prise en compte par l’OS. Ces deux technologies ont d’ailleurs déjà été adoptées par de grands noms de l’internet comme Facebook ou Cloudflare.

Un benchmark comparatif avec iptables montre des résultats vraiment très intéressants dans un cas de configuration anti-DDOS.

 

L’autre fonctionnalité présentée est la capacité de créer des politiques de sécurité non seulement de niveau L4 mais également de niveau L7 pour différents protocoles ; à l’heure actuelle, http, kafka et grpc.

 

Cilium parait donc un plugin réseau à étudier sérieusement malgré quelques limitations pour la production comme sa jeunesse ou sa dépendance à des noyaux linux récents (mais un backport sous forme de module existe pour Redhat/Centos).

Using docker to secure traditional applications without code changes

Diogo Monica est « M. Sécurité » chez Docker, et par ailleurs un excellent orateur. Dans cette session, il revient sur les dangers liés à un surcroît de sécurité: par définition, la sécurité est un état d’absence de danger ou de menaces. Hors dès que vous êtes connectés à Internet, vous ne pouvez plus être en sécurité.

 

En faisant le parallèle avec le monde de l’indy500 ou de la F1, il décrit comment passer de la sécurité à la sûreté des systèmes logiciels dans le but de protéger ce qu’il y a de plus important dans les deux cas: le pilote en indy500/F1, les données en informatique.

Je vous invite fortement à regarder la vidéo de la session lorsqu’elle sera disponible.

Les autres sessions

Pour finir, quelques mots sur les autres sessions vues:

  • Container relevant upstream kernel development: les nouveautés à venir du noyau linux, donc notamment Wireguard, un nouveau système de VPN ultra performant.
  • Container orchestration from theory to practice: intéressant pour la comparaison des modèles mis en oeuvre dans Swarm et K8S.
  • Gordon’s secret session: tenue secrète car il s’agit d’un retour sur l’intégration de Kubernetes dans la suite Docker grâce à CRI-containerD, Linuxkit, CNI-libnetwork et les objets de type CustomResources de Kubernetes.

 

Les sessions de la DockerConEU – vues par Sandrine

Par Sandrine Perrin, Consultante Cloud @ Objectif Libre

 

J’ai suivi les présentations relatives à des cas pratiques d’utilisation de Docker. Ci-dessous un résumé des points les plus intéressants.

Kubernetes

La grande nouvelle de cette DockerConEU est bien l’intégration de Kubernetes à Docker comme orchestrateur supporté.

Kubernetes était présent dans beaucoup de présentations dans différents contextes  :

  • dans UCP (Universal Control Plane) de docker, présenté dans la première keynote
  • avec Bitbucket pour faire de l’intégration continue (CI)
  • avec Rancher version 2.0 pour avoir une surcouche pour l’orchestration des conteneurs. Rancher est également compatible avec Docker Swarm, l’orchestrateur propre de Docker.
  • avec des environnements serverless avec le projet fnproject Function as a Service compute Plateforme
  • avec les bases de données, notamment la solution distribuée de RedisLabs

Moby

Cette session a présenté le projet « Slynet vs Planet of the Apes » dont le but est de tester la résilience et la scalabilité de cluster multi-cloud avec ChaosMonkey (version Spinnaker).

Cet exercice est une mise en pratique intéressante et amusante d’outils proposés par Moby tels que:

  • LinuxKit pour construire le système d’exploitation dédié, petit et immutable. Les OS sont construits à partir de fichier yaml décrivant leur contenu puis poussés sur différents fournisseurs de cloud;
  • Infrakit pour provisionner le cluster utilisant différents clouds après suppression aléatoire de conteneurs.

Cette approche repose sur le principe de décentralisation des données et des applications, entre les répartissant dans plusieurs datacenters.

Les outils du projet Moby permettent de répondre à deux besoins :

  • disposer d’OS minimaux ;
  • privilégier la reconstruction par rapport à la mise à jour, avec une solution simple et facilement automatisable.

Cf. la fin du billet pour une présentation plus détaillée du projet Moby.

Architecture serverless ou FaaS

L’approche serverless ou FaaS (Function as a Server) a fait l’objet de plusieurs présentations pendant la DockerCon.
Les conteneurs sont une bonne approche pour exécuter des fonctions à la demande de manière rapide et reproductible. L’outil OpenFaaS est un bon exemple de mise en pratique de cette approche.

Il fonctionne avec Docker sur un cluster Kubernetes. Il est possible de l’installer sur les principaux fournisseurs de cloud, en s’affranchissant de passer par leurs syntaxes respectives pour l’écriture des fonctions.

En savoir plus : https://github.com/openfaas/faas

Stockage distribués de données persistantes

Le stockage fait partie des points critiques de la « dockerisation » des applications. Il n’existe pas de solution globale, cependant des solutions dédiées à une problématique commencent à apparaître sur le marché.

 

La société {code} a présenté son plugin de volume docker : REX-Ray. C’est une solution open-source de stockage distribué de données persistantes entre plusieurs fournisseurs de cloud.

Le plugin est compatible avec les principaux orchestrateurs de conteneurs : Kubernetes, Swarm, Mesos ainsi que les principaux fournisseurs de cloud.

La solution repose sur le CSI (Cloud Storage Initiative), une initiative engagée dans l’adoption et la standardisation du stockage dans le cloud qui promeut l’interopérabilité et la portabilité des données sauvagardées dans le cloud.

 

La société Redis a présenté de son côté une solution dédiée au stockage distribué pour les bases de données Redis.

Elle propose une image docker pour la base de données Redis sous Kubernetes, une démo est disponible avec un cluster créer dans GCE.

La solution de Redis peut être vue comme un orchestrateur de base de données sur un orchestrateur de conteneurs, elle supporte les principaux orchestrateurs (Kubernetes, Swarm et Mesosphère).

 

En savoir plus :

Sécurité

La sécurité est un questionnement important pour mettre en production une application conteneurisée.

Avant toutes solutions techniques, la sécurité repose sur l‘application de bonnes pratiques tout au long de la chaîne: depuis le développement d’application secure à la mise en production, l’approche DevOps aide au partage de connaissance nécessaire entre les devs et les ops.

 

Un des points importants est la gestion des secretsCyberark a développé Conjur sur cette question.

Son approche est de lier trois entités : les secrets, des identités, des applications.

Ainsi, l’identité est un pré-requis pour obtenir les secrets et accéder à une application avec des droits spécifiques, au travers de policy établie pour les utilisateurs et les applications. Cette solution permet de révoquer rapidement tous les secrets.

 

En savoir plus :

CI/CD

Docker + CI/CD est une association qui fonctionne bien et qui a très vite montré les avantages que les tests pouvaient tirer des conteneurs : rapidité, efficacité et exécution dans des environnements contrôlés.

 

Le gestionnaire de version de code Bitbucket d’Atlassian a montré le nouveau module ajouté sur l’intégration continue (CI) et le déploiement continu (CD).

La CI lancée sur un dépôt de code git permet de déclencher, dans des conteneurs, un pipeline avec les étapes de build d’image docker, de test sur l’application et de push sur un registre.

L’exécution se fait sur un cluster Kubernetes qui est scalé en fonction de la demande, assurant de bonnes performances. Cette solution est présentée comme une alternative à Jenkins, plus simple à mettre en place. La configuration d’un pipeline se fait avec un fichier yaml.

La solution proposée est très proche de celle déjà disponible dans Gitlab-ci.

 

En savoir plus :

Point sur le Moby Submit

Le projet Moby a été présenté lors de la dernière DockerCon à Austin: il s’agissait pour Docker de séparer l’effort Opensource (le côté « bidouille » comme dit Solomon) du nom et des produits de la société Docker Inc.

 

L’idée est également de permettre la réutilisation des technologies de bases créées par Docker dans d’autres cas d’utilisation comme par exemple le moteur de conteneur IoT Balena.

 

Les projets principaux de Moby sont:

  • ContainerD: le moteur de conteneurisation (aujourd’hui géré par la CNCF) ;
  • Linuxkit ;
  • Infrakit: moteur de déploiement d’infrastructure avec réparation automatique s’appuyant sur l’outil Terraform d’Hashicorp ;
  • Notary: l’outil de gestion des signatures d’images (en cours de donation à la CNCF).

Nous reviendrons plus en détail sur certaines de ces technologies, lorsque nos consultants auront pu les éprouver un peu.