Orchestration de conteneurs chez Facebook avec Tupperware

Dans cet article, je présenterai la solution d’orchestration de conteneurs mise en place par Facebook, appelée Tupperware.

Qu’est-ce que Tupperware ?

Tupperware est un framework fait maison écrit et utilisé en interne par Facebook. Tupperware est un orchestrateur de conteneurs qui vise à gérer des applications et des tâches exécutées à l’intérieur de conteneurs Linux. En tant qu’orchestrateur, il permet l’exécution parallèle de plusieurs tâches pour exécuter des services de Facebook. Il fournit également l’isolation des environnements d’exécution et le contrôle des ressources.

Architecture

Le tableau suivant compare les composants habituellement utilisés par l’industrie avec ceux de Tupperware :

Facebook utilise le même modèle que l’industrie pour déployer des conteneurs. La principale différence est que tous les moteurs et gestionnaires de ressources sont gérés par Tupperware, pas de Swarm, pas de moteur Docker, pas de KVM … A noter, Docker Swarm peut utiliser la découverte basée sur Zookeeper.

Nous pouvons imaginer que Facebook a commencé à utiliser Tupperware il y a plusieurs années et que seul Zookeeper était disponible en tant que solution mature et testée.

Agents Tupperware

Les agents Tupperware sont le cœur de Tupperware. Ils fonctionnent sur les hôtes de Facebook et gèrent chaque couche de l’application en cours d’exécution. Ils sont composés de :

• Gestionnaire des tâches
• Gestionnaire de paquets
• Gestionnaire de volumes
• Gestionnaire de ressources
• Planificateur heartbeat

Lancement de conteneurs

Chaque conteneur est lancé de la même manière. Au début, ils contiennent une image BTRFS. Ils utilisent des spnapshots ReadWrite sur une base ReadOnly. Les paquets de Facebook et d’autres outils communs sont pré-installés. Ils permettent une initialisation systemd en utilisant nspawn. Les conteneurs utilisent également les cgroups v2.

Couches d’une image

Chaque image sur Tupperware est découpée en couches superposées comme suit :

• Tâche en cours
• Image d’application
• Image Facebook
• Image de l’OS de base

L’image de base du système d’exploitation est basée sur RedHat OS. C’est l’image officielle de base (Facebook contribue parfois aux corrections de bugs, par la suite appliquées et distribuées dans les versions ultérieures)

L’image Facebook s’applique à la personnalisation générale de l’image de base Facebook comme les référentiels personnalisés, les programmes internes, les modules (pensons à YARN !) et les personnalisations réseau.

Ces deux couches sont identiques sur la majorité des tâches en cours chez Facebook.

L’image de l’application contient les instructions requises par la tâche en cours d’exécution.

Pourquoi BTRFS

En lisant cet article, vous pouvez vous demander pourquoi BTRFS est utilisé pour la couche inférieure de l’image. Il a été choisi car il offre les fonctionnalités suivantes :

• Copy on write
• Subvolumes
  • un conteneur peut monter des volumes
  • facile à gérer
• Instantanés (RO et RW)
  • il permet de remonter dans le temps facilement
• Diffs binaires
  • espace disque minimal
  • usage des IO disques optimal
  • amélioration de la mise en cache des données de disque
  • couches de version indépendante
  • différents horaires de mise à jour pour les calques
• Quotas
  • Utilisation complète pour empêcher le conteneur de prendre tout l’espace disque sur les autres conteneurs
• Contrôle d’IO de Cgroups
  • fournit l’isolation des ressources
  • isolation de disque
  • isolation de la mémoire
  • isolation du processeur

Construction d’une image

Les images sont construites en utilisant Buick build.

Buick build a été choisi pour ses caractéristiques suivantes :

• Construction d’image déclarative
• Constructions parallèles rapides
• Constructions reproductibles
• Constructions incrémentielles
• Séparation de la construction et de l’exécution
• Entièrement autonome
• Fournit une véritable isolation FS
• Testable

Initialisation avec Systemd

Pour finir, nous allons plonger dans la façon dont les conteneurs sont lancés avec Systemd.

Systemd est conscient du conteneur et permet via SSH des accès à l’intérieur du conteneur, ce qui est utile pour le débogage ou l’exécution de commandes spécifiques. Il utilise la fonction systemd-nspawn et permet également la journalisation en dehors du conteneur. Enfin (mais non conseillé), il peut exécuter des conteneurs au moment de la construction (Docker par exemple ne l’autorise pas).

Conclusion

Pour conclure, nous pouvons dire que Facebook est au courant des pratiques de l’industrie. Cependant, au lieu de s’appuyer sur les technologies actuelles communes à la majorité des acteurs, ils développent et maintiennent une pile interne différente. Je pense que ce choix a été fait à une époque où l’industrie découvrait les conteneurs et ne fournissait pas d’outils répondant aux critères de stabilité et de fonctionnalités requit par Facebook.

Facebook n’est pas le seul à avoir développé sa plateforme maison. Elasticsearch l’a également fait avec ECE. C’est ce que la conférence a souligné : il est parfois logique pour les entreprises de démarrer et d’utiliser leur propre solution. C’est un choix raisonnable lorsque aucune solution disponible sur le marché ne répond aux critères et contraintes internes.