Contactez-nous
-
Cloud Native

Du garage à un acteur prépondérant du cloud : l'exemple CoreOS

Du garage à un acteur prépondérant du cloud : l'exemple CoreOS

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 spécifiquement pour Clair. Continuez à nous suivre, nous reviendrons prochainement plus en détails sur certains projets.