Sommaire
La genèse
Tout a commencé en 2013 dans un garage de Palo Alto où 4 amis (qui se connaissent depuis l’université) se sont réunis avec une idée un peu folle : permettre à chacun d’avoir un système d’exploitation similaire aux grands du Web. Ce concept peut être résumé dans l’acronyme GIFEE (Google Infrastructure For Everyone Else), c’est à dire avoir un système scalable, sécurisé et tout simplement efficace.
Les 4 amis sont :
- Alex Polvi, qui n’en est pas à son coup d’essai, il avait en effet lancé la société Cloudkick, spécialisée dans le monitoring d’instances cloud, ensuite rachetée par RackSpace.
- Brandon Philips, développeur Linux, qui a travaillé pour RackSpace sur les solutions de monitoring cloud.
- Michael Marineau, ancien développeur Google.
- Greg Kroah-Hartman, qui travaille sur le kernel Linux, membre de la Linux Foundation et qui agira en tant que conseil dans la société.
De cette idée est née la société CoreOS et son système d’exploitation éponyme (aujourd’hui nommé Container Linux OS).
Container Linux OS
Cette distribution, basée sur ChromeOS, se veut minimaliste. En effet, elle ne contient que le minimum nécessaire pour utiliser un serveur, sans système de gestion de packages, les applications ayant vocation à être lancées dans des containers.
La configuration de celle-ci se fait au démarrage, via l’utilisation de Cloud Config (par les user-datas sur une instance EC2, une clé USB pour une machine virtuelle VMWare par exemple). Cloud Config permet de configurer les utilisateurs du système ainsi que la clé SSH associée, les services CoreOS à démarrer (etcd, le service d’update), les unités SystemD (un container Docker avec Nginx, …), ainsi que des fichiers à déposer sur le serveur à son démarrage. Cela en fait un système facilement et rapidement remplaçable en cas de problème.
Cette approche minimaliste permet d’obtenir un système qui se révèle plus sécurisé, la surface d’attaque étant plus faible. De plus, des mises à jour sont réalisées régulièrement, en prenant pour base de sécurité les listes de CVE (Common Vulnerabilities and Exposures) du NIST, Debian, Ubuntu, Alpine. Dès lors, c’est à l’utilisateur de prendre en charge la gestion de la sécurité des applicatifs déployés dans des containers.
Nous allons faire un zoom sur le système de mise à jour. Il s’agit d’un daemon qui vérifie l’existence de mise à jour au démarrage du système et par la suite une fois par heure. Le système étant basé sur ChromeOS, 2 partitions /usr sont présentes. De ce fait, lorsqu’une mise à jour est disponible, celle-ci est installée sur la partition non utilisée à ce moment là. Cela permet un retour rapide sur l’ancienne version en cas de problème en utilisant cgpt pour manipuler la table de partition :
# Récupération de la table de partition
$ cgpt show /dev/xvda
start size part contents
0 1 Hybrid MBR
1 1 Pri GPT header
2 32 Pri GPT table
4096 262144 1 Label: "EFI-SYSTEM"
Type: EFI System Partition
UUID: 6971C1B2-434C-4425-AB9C-F57360A6E6A5
Attr: Legacy BIOS Bootable
266240 4096 2 Label: "BIOS-BOOT"
Type: BIOS Boot Partition
UUID: 92D8C090-D0A6-4B9B-A1CF-BC6BA36B39C5
270336 2097152 3 Label: "USR-A"
Type: Alias for coreos-rootfs
UUID: 7130C94A-213A-4E5A-8E26-6CCE9662F132
Attr: priority=1 tries=0 successful=1
2367488 2097152 4 Label: "USR-B"
Type: Alias for coreos-rootfs
UUID: E03DD35C-7C2D-4A47-B3FE-27F15780A57C
Attr: priority=0 tries=0 successful=0
4464640 262144 6 Label: "OEM"
Type: Alias for linux-data
UUID: 6C1D9CA1-F47F-4C6E-AD7A-266D797F53DA
4726784 131072 7 Label: "OEM-CONFIG"
Type: CoreOS reserved
UUID: 5942691F-0326-49EC-B937-21BF5594E5A7
4857856 11919327 9 Label: "ROOT"
Type: CoreOS auto-resize
UUID: 64B90315-C28D-4A2E-867A-B3CEC27016ED
16777183 32 Sec GPT table
16777215 1 Sec GPT header
# Quelle partition sert actuellement /usr ?
$ rootdev -s /usr
/dev/xvda3
# Quelle partition /usr est disponible
$ cgpt find -t coreos-usr | grep --invert-match "$(rootdev -s /usr)"
/dev/xvda4
# La commande précédente retourne /dev/xvda4, nous indiquons donc que celle-ci doit être utilisée au prochain boot
$ cgpt prioritize -i 4 /dev/xvda
Suite à une mise à jour, plusieurs possibilités s’offrent à vous quant au redémarrage du système : un redémarrage immédiat, pas de redémarrage automatique ou enfin un redémarrage par lock ETCD. Cette dernière option est utile dans le cadre d’un cluster Container Linux OS, ce qui permet un redémarrage progressif du parc. Le réglage de la stratégie de redémarrage se fait via Cloud Config que nous avons abordé précédemment.
Nous venons de voir qu’il est possible d’avoir un cluster Container Linux OS. Il est assez simple de le mettre en place. En effet, il suffit d’utiliser Cloud Config pour chaque hôte avec une configuration ETCD de ce type :
etcd:
# Il faut créer un token pour tout nouveau cluster : https://discovery.etcd.io/new?size=3
# en indiquant la taille initiale du cluster
discovery: https://discovery.etcd.io/<token>
advertise_client_urls: http://{PRIVATE_IPV4}:2379,http://{PRIVATE_IPV4}:4001
initial_advertise_peer_urls: http://{PRIVATE_IPV4}:2380
# Définition des ports d’écoute
listen_client_urls: http://0.0.0.0:2379,http://0.0.0.0:4001
listen_peer_urls: http://{PRIVATE_IPV4}:2380
Une fois les serveurs démarrés, le cluster est en place et fonctionnel.
A partir de là, un ensemble de projets a vu le jour, développant un écosystème autour de Container Linux OS.
L’écosystème
ETCD
ETCD est utilisé au sein de Container Linux OS afin de configurer un cluster. C’est un outil de stockage clé/valeur avec chiffrement TLS par défaut, avec une API. Il fonctionne en mode cluster, l’élection du noeud maître se faisant via l'algorithme RAFT.
De plus, cet outil est utilisé au coeur de Kubernetes, un des orchestrateurs de containers phares du moment.
RKT
Après avoir créé un système d’exploitation dédié aux containers, quoi de plus naturel que de s’impliquer dans l’écosystème des containers runtime. Nous avions abordé RKT en commençant par la théorie puis par la pratique. Les équipes de CoreOS proposent donc désormais 2 éléments indispensables dans le monde du Cloud.
Clair
Un des problèmes que rencontre tout utilisateur d’un système, qu’il soit containerisé ou non, est la sécurité du système et des applicatifs. Pour cela, Clair est né. Clair est un analyseur de vulnérabilités sur les images de containers. L’analyse se fait directement à partir du contenu de l’image, sans besoin de démarrer un container. L’outil se base sur les listes de CVE que nous avons indiquées précédemment.
Le logiciel est hautement configurable, il est en effet possible de modifier la plupart des composants, en modifiant le code écrit en Go, afin de faire correspondre Clair à ses besoins spécifiques. Enfin, l’ensemble des données est stocké en base de données, ce qui permet de ne pas avoir à analyser de nouveau les images lors de la publication de nouvelles CVEs et d’être en même temps informé des failles des images.
Tectonic
La forte participation des développeurs de CoreOS à Kubernetes, alliée aux produits existants, a permis le développement de Tectonic, qui se trouve être une solution de déploiement automatisé et de management d’un cluster Kubernetes. Ce cluster est basé sur Container Linux OS. Bien évidemment, le système de mises à jour automatiques de Container Linux OS est disponible, la mise à jour de Kubernetes étant prise en charge également.
Comme nous avons pu le voir, ces différents projets sont adoptés et sont désormais intégrés dans l’effort de standardisation autour du cloud. Toutefois, ce ne sont pas les seuls efforts des équipes de CoreOS dans la standardisation.
Standardisation
Container Network Interface
Ce standard vise au travers d’une spécification et d’un ensemble de librairies et plugins à définir comment se configurent les interfaces réseaux dans les containers. Cela permet la création et la destruction d’interfaces réseaux à l’aide d’une configuration simple en JSON. Il est tout à fait possible de créer ses propres plugins. Ce standard est désormais utilisé dans de nombreux projets tels que RKT, Kubernetes, Mesos, Calico, Weave et Infoblox, pour ne citer qu’eux.
Open Container Initiative
Après avoir proposé AppC, un standard définissant ce que doit être un container et son image, CoreOS a choisi de participer à OCI, supporté par la Linux Foundation et qui regroupe de nombreux acteurs influents (Docker, Google, RedHat, Pivotal, ...). Le but d’OCI est donc de promouvoir ce que doit être un container runtime ainsi qu’une image de container, afin d’assurer une standardisation et une inter-opérabilité des images.
Cloud Native Computing Foundation
La Cloud Native Computing Foundation est une autre émanation de la Linux Foundation, qui a pour but de promouvoir les applications “cloud natives”. De ce fait, un certain nombre de projets sont supportés, tels que Docker, RKT, CoreDNS ou Prometheus par exemple. Des membres de CoreOS sont présents dans les différents comités techniques et board de cette fondation.
Conclusion
Comme nous pouvons le constater, le mythe de la Silicon Valley d’un projet qui débute dans un garage et finit par devenir un acteur important s’est une nouvelle fois réalisé. Si l’écosystème présenté vous intéresse, nous ne pouvons que vous inviter à tester les logiciels présentés dans cet article et les nombreux autres projets autour. Une documentation importante pour vous aider est présente ici pour CoreOS, les outils et là spécifiquement pour Clair. Continuez à nous suivre, nous reviendrons prochainement plus en détails sur certains projets.
