Orchestration Tools

Présentation

Enseignants : D. Donsez, GP. Bonneau

Sujet : Orchestration Tools : Puppet vs. Chef vs. Ansible vs. Salt

Abstract

There is more and more data center in the world, and virtualization is massively used. With the emergence of the cloud, automatics deployments of new systems to guarantee and maintain a quality of service are necessary. So, the number of physical or virtual servers managed by a sysadmin becomes quickly exponential. A manual administration is, obviously, not a realistic option anymore.

The administration, previously realized by a local and physical connection to the server, is now remote and massive (multiples servers). Orchestration tools are an answer to this need. These tools will have to be able to setup a configuration, and guarantee a good behavior of the managed services.

Résumé

Il y a de plus en plus de datacenters dans le monde, la virtualisation de serveurs est massivement présente. Avec l'émergence du cloud, des solutions de déploiement automatique de nouveaux serveurs pour assurer et maintenir une qualité de service sont nécessaires. Ainsi, le nombre de serveurs physiques ou virtuels à la charge d'un administrateur système devient rapidement exponentiel. Une administration manuelle n'est plus possible, le besoin d'une automatisation des configurations est évident.

L'administration qui pouvait auparavant être réalisée en se connectant localement sur un serveur est maintenant distante et massive. C'est à ce niveau que se positionnent les outils d'orchestration, qui vont avoir pour rôle d'assurer la mise en place d'une configuration sur un ensemble de machines, mais aussi le bon fonctionnement des services.

Synthèse écrite

Introduction

Avec la généralisation des solutions faisant intervenir le cloud et le besoin de dynamicité dans les architectures mise en œuvre, les outils d'orchestration sont rapidement devenus indispensables. Là où auparavant, un site web était hébergé sur un unique serveur facilement administrable, la plupart des hébergeurs proposent maintenant des solutions intégrant de la répartition de charge (load balancing) selon les besoins dynamiques du site. Ces sociétés ont donc un fort besoin d'orchestration: installation d'une nouvelle machine, installation des services associés, intégration avec le service en cours d’exécution, entre autres.

Tout administrateur système, quelle que soit la taille du parc informatique qu’il a sous sa responsabilité; va chercher à automatiser au possible les tâches pénibles ou répétitives. On pourrait bien entendu imaginer dans un premier temps une connexion distante réalisée manuellement par l’administrateur : une connexion ssh suivie d’un script bash que l’on exécute. Cependant, cette solution est très limitée, il faut connaitre les mots de passe de chaque machine auxquelles on veut se connecter, ce qui devient très rapidement une perte de temps majeure dans une infrastructure conséquente. De plus, l’aspect répétitif reste encore très présent et pour peu que les machines aient quelques différences de configuration, le script qui fonctionne sur une ne fonctionnera pas nécessairement sur l’autre. Il est très fréquent dans les parcs informatiques assez anciens d’avoir plusieurs versions de différents logiciels en cours d’utilisation suivant la date d’installation du service. Les mises à jour deviennent très rapidement un casse-tête, et ne sont très souvent jamais réalisées (bien que d’autres problématiques interviennent pour cet exemple, telles que la compatibilité de l’application courante). Sans pour autant vouloir assurer une mise à jour, la modification d’un paramètre commun à l’ensemble des machines devient ingérable. De manière générale, un parc informatique va très rapidement être très hétérogène, ce qui tend à complexifier l’administration.

En tant qu’administrateur système, on va vouloir conserver autant que possible une vue générale de notre parc informatique, en décrivant au travers d’outils de haut niveau la configuration souhaitée, sans se préoccuper de sa réalisation effective. Autrement dit, se concentrer que le « quoi » plus que sur le « comment ». Ce paradigme est dit « déclaratif », et plusieurs outils présentés par la suite vont choisir cette approche. D’autres auront une approche un peu plus mixte, se rapprochant du paradigme « impératif » et de la réalisation concrète des actions (le « comment » évoqué ci-dessus). Avec les deux paradigmes évoqués, nous touchons directement un concept qui résume parfaitement l’idée des outils d’orchestration : « infrastructure as code ». Quel que soit l’outil utilisé, nous allons chercher à décrire notre infrastructure, les configurations souhaitées sous forme de « code » plus ou moins haut-niveau. Ces outils intègrent également les notions de push et pull, présentes dans les outils de versioning, tel que Git.

Un point reste à mentionner, avant de commencer cette étude : la différence entre outils d’automatisation et outils d’orchestration, entre « tache » et « processus ». L’optimisation d’un processus ne peut pas être réalisée simplement en automatisant des tâches. L’automatisation va être autour d’une seule tâche, l’orchestration va être sur l’ensemble du workflow, sur le processus global. Par exemple, on va pouvoir automatiser l’installation des différents composants d’une architecture trois-tiers. L’outil d’orchestration ne va pas se limiter à installer ces composants, mais s’assurer qu’ils sont déployés dans le bon ordre, en optimisant le processus global.

Étude comparative

Chronologie des principaux outils d'orchestration

Puppet

La première version de Puppet est publiée en 2005. Luke Kanies, un utilisateur de CFEngine (CFEngine 2 à l’époque) n’est pas satisfait de la façon dont est géré le projet, et décide de lancer le projet « Puppet ».

Puppet en quelques lignes :

• Un langage dédié, inspiré du Ruby pour la description des configurations (Une bonne connaissance du Ruby est recommandée)
• Une configuration client-serveur, avec un ou des serveurs dits « masters » qui vont centraliser les descriptions des configurations des clients. Chaque machine devra être équipée en conséquence du package « serveur » ou « client » de Puppet.
• Plateforme : Multiplateforme
• Paradigme : déclaratif
• Prix : environ 100$ / nœud /an pour le support “standard”
• Les communications entre le serveur et le client s’effectuent via HTTPS.

Principe de fonctionnement :

Auparavant, les échanges été réalisés sous la forme d’appels XML-RPC sur HTTPS, depuis la version 3 de Puppet, le fonctionnement a changé, on utilise désormais une API REST, accessible via HTTPS endpoints (autrement dit, une url). Le fonctionnement global reste identique.

Puppet est également capable de fonctionner avec un ENC (External Node Classifier). Par défaut, les scénarios à appliquer à un nœud (client) sont définis dans un unique fichier, lu par le serveur master. Cependant, ce fichier peut devenir très lourd et illisible, pour peu que l’on ait un nombre important de nœuds à gérer. Il est alors possible de décharger cela vers un programme externe appelé par le serveur (programme écrit dans le langage de notre choix), auquel on transmet le FQDN du client (Fully qualified domain name). On peut par exemple choisir de faire fonctionner Puppet avec un annuaire LDAP dans lequel seraient stockés les scénarios à appliquer.

Références

• CFEngine
• Puppet Labs
• Chef
• Salt
• Ansible
• "Infrastructure as Code" - DevOps
• Automatisation vs Orchestration
• Détail des communications HTTPS client-serveur Puppet (attention, le diagramme décrit un fonctionnement qui n'est plus tout à fait l'actuel)
• Documentation API Puppet
• Puppet avec un ENC...