Les outils qui se sont imposés dans la chaîne du DevOps
En rapprochant les équipes de développement logiciel, de recette et de production IT, le DevOps répond à l'un des principaux défis de l'économie digitale : la rapidité d'exécution. Une nouvelle application doit être lancée rapidement. Il n'est plus possible de patienter six mois avant de la livrer. L'informatique s'aligne désormais sur la sortie des produits et services et plus l'inverse. Face à ce changement de paradigme, tout un écosystème de nouveaux outils open source a vu le jour en moins d'une décennie. Parmi eux des cadors ont commencé à s'imposer sur certains maillons de chaîne du DevOps (voir l'infographie ci-dessous). Toutes les solutions évoquées ci-dessous sont unanimement plébiscitées par les experts interrogés dans le cadre de cet article.
En amont, GitLab se positionne à la fois dans l'intégration et le déploiement continus (CI/CD), mais aussi dans la gestion de versions logicielles via la brique open source Git. "GitLab intègre très bien Git. C'est là l'une de ses principales forces", note Hervé Leclerc, directeur technique au sein de la société de services Alter Way. A la différence notamment de son concurrent Subversion, Git repose sur un modèle décentralisé. Ce qui peut troubler certains débutants. "Du coup, il faudra systématiquement penser à publier chaque branche d'un projet que l'on souhaite rendre publique dans Git", souligne Alexandre Garnier, consultant IT pour le cabinet de conseil Zenika.
"YAML est un langage qui n'est pas forcément évident. Mais il faudra s'y habituer car il est aussi utilisé par Kubernetes et Swarm"
Du côté d'Ansible, c'est l'architecture sans agent qui est plébiscitée. Le protocole SSH suffit pour le déployer. "Il permet de réaliser des déploiements, exécuter de tâches et gérer la configuration sur plusieurs machines en même temps. Il est particulièrement adapté pour paramétrer et maintenir une couche middleware, avec un serveur Apache, une base MySQL, ou autres", explique Hervé Leclerc. Alexandre Garnier ajoute : "Le traitement s'effectue en mode séquentiel, par le biais de script. De ce point de vue, le ticket d'entrée pour prendre en main Ansible est peu élevé."
Pour autant, attention à ne pas tomber dans un piège : recourir à Ansible comme système de scripting. "Il faudra correctement concevoir les playbooks et les rôles, et avoir en tête la notion d'idempotence qui signifie qu'une opération aura le même effet quel que soit le nombre de fois qu'elle est exécutée", détaille Alexandre Garnier. Autre remarque, les playbooks Ansible sont décrits en YAML. "C'est un langage qui n'est pas forcément évident. Mais il faudra s'y habituer car il est aussi utilisé pour les descripteurs Kubernetes et Swarm", prévient Alexandre Garnier. Et Hervé Leclerc de renchérir : "YAML n'est pas simple pour créer des boucles ou des conditions."
Une infrastructure as a code non-portable
La logique de Terraform est encore différente. Portée par la société HashiCorp, la solution d'infrastructure as a code repose en effet sur une gestion par état et non basée sur un mode séquentielle. "Il faudra s'y habituer, ce n'est pas du scripting", prévient Alexandre Garnier. Concrètement, il s'agira de décrire les ressources machines (RAM, CPU, stockage) et autres services attendus (SSH…) pour le cloud ciblé, qu'il soit privé ou public. "Il faudra bien veiller à sauvegarder et maintenir le fichier décrivant l'état", insiste Hervé Leclerc. Et si l'infrastructure désirée n'existe pas encore ? "Mettons que vous avez fait le choix du cloud d'Amazon, Terraform la générera avec les paramètres voulus en se connectant aux API de ce dernier", précise Alexandre Garnier.
Principale contrainte de Terraform : les codes décrivant les infrastructures (qui devront être écrits en HCL, un langage inspiré de Json) ne sont pas portables d'un cloud à l'autre. "C'est le revers de la médaille. Les providers présentent de nombreuses disparités en matière de services et d'API. Créer une couche Terraform d'invocation qui puisse s'adapter à n'importe quel cloud est par conséquent difficilement concevable", analyse Alexandre Garnier.
A notez l'existence d'un projet open source baptisé Terracognita (lancé par le français Cycloid) qui permet de générer un code HCL à partir d'une infrastructure existante. Un outil ingénieux qui pourra faire gagner de nombreuses heures de travail.
"Terraform n'est pas un véritable outil d'infrastructure as a code"
Le directeur technique d'Alter Way, pondère néanmoins : "Terraform n'est pas un véritable outil d'infrastructure as a code à la différence de Pulumi par exemple." Hervé Leclerc explique : "Pulumi est moins limitatif en termes de langages. Il a aussi bien recours à du JavaScript qu'à du Python pour décrire les infrastructures. Ce qui pour beaucoup de développeurs se révélera nettement plus simple. D'autant que ces langages donneront du même coup la possibilité d'introduire de l'algorithmie aux fichiers de gestion d'état."
En aval de la chaîne du DevOps, les containers Docker, compte tenu de leur légèreté, sont désormais considérés comme l'environnement idéal pour packager les applications. Quant à Kubernetes, il s'est imposé en quelques années comme l'orchestrateur de référence pour piloter l'exécution des applications containérisées sur des clusters de machines. "Kubernetes est souple, puissant et résilient en cas de panne. La contrepartie est une certaine complexité", rappelle Alexandre Garnier. A la différence de l'orchestrateur conçu par la société Docker, Swarm, qui, lui, s'articule autour d'un service unique pour plus de simplicité, Kubernetes met en musique plusieurs services : les pods pour gérer les tâches unitaires d'un container, les ReplicaSet pour maintenir le nombre de pods souhaité, des services réseau (équilibrage de charge, NotePort, Cluster IP...) Une surcouche comme Knative permettra de masquer une partie de cette complexité.
Monitoring et gestion des secrets
Côté monitoring, trois environnements sont évoqués par les experts. D'abord, Prometheus qui s'articule autour d'une base de données temporelles (ou time series) taillée pour l'alerting. Son architecture de supervision, en mode pull, évite l'installation d'agents de collecte sur chaque composant à analyser. Ensuite, le triptyque Telegraf, Influxdb et Grafana est mis en avant. A chacun des trois outils son rôle : Telegraf pour la remontée des métriques, Influxdb pour fédérer ces dernières, et Grafana pour les exploiter et les mettre en forme. Principal inconvénient de la solution : à la différence de Prometheus, il sera ici nécessaire d'installer des agents. Enfin, Kibana complète l'édifice. "Prometheus et Grafana sont conçus pour faire remonter des indicateurs de mesure, mais pas les logs des applications. Kibana sera idéal pour jouer ce rôle", précise Hervé Leclerc.
Reste à évoquer la question de la sécurité du pipeline. Un rôle dévolu à des outils comme Anchore ou Clair dessinés pour scanner les images de container pour y dénicher d'éventuelles vulnérabilités. Chez Alter Way, Hervé Leclerc évoque aussi Vault, une brique dite de gestion des secrets qui se chargera de stocker les mots de passe, certificats, clés d'API ou tokens nécessaires pour accéder aux différents composants d'une architecture applicative.