Sommaire
- Docker : la conteneurisation
- Kubernetes : l'orchestration de conteneurs
- L'intégration et le déploiement continus (CI/CD)
- Terraform : l'infrastructure as code
- Ansible : la configuration des serveurs
- GitOps : Argo CD et Flux
- L'observabilité : savoir ce qui se passe en production
- Le cloud et les fournisseurs cloud
- En résumé
Il existe des centaines d'outils DevOps, et il est facile de s'y perdre au moment de structurer la chaîne de livraison d'un projet. Cet article fait le tour des outils que nous utilisons au quotidien chez theTribe, et explique ce que chacun apporte une fois en place. L'objectif reste le même qu'à l'époque où nous avons écrit la première version de cet article : livrer souvent, sans stress, et sans dépendre d'une intervention manuelle.
Docker : la conteneurisation
Docker reste la brique de base. Un conteneur embarque l'application et tout ce dont elle a besoin pour tourner : runtime, dépendances, configuration système. Il est construit à partir d'une image, qui se lance à l'identique sur le poste d'un développeur, dans la CI ou en production.
La logique « un service, un conteneur » pousse à découper l'application en briques indépendantes, qu'on peut faire évoluer et redéployer séparément.
Ce que ça apporte
- Des environnements identiques du poste de dev à la production : fini le « ça marche chez moi ».
- Des images versionnées : on peut revenir à la version précédente en quelques secondes.
- Une installation réduite au minimum sur les serveurs, qui n'ont besoin que d'un moteur de conteneurs.
- Une isolation entre services : un conteneur ne peut pas casser son voisin.
Kubernetes : l'orchestration de conteneurs
Dès qu'une application compte plusieurs services, ou qu'elle doit tenir la charge, il faut un orchestrateur. Kubernetes s'est imposé comme le standard : il décide où tournent les conteneurs, combien d'instances lancer, comment les exposer et quoi faire quand l'une d'elles tombe.
Son principal atout pour la livraison est le déploiement progressif. Plutôt que de remplacer d'un coup l'ancienne version par la nouvelle, Kubernetes la remplace instance par instance (rolling update) et vérifie à chaque étape que les nouvelles instances répondent correctement. Avec des outils comme Argo Rollouts, on va plus loin : la nouvelle version ne reçoit d'abord qu'une petite part du trafic (déploiement canary), puis de plus en plus si les indicateurs restent bons, avec un retour automatique en arrière dans le cas contraire.
Ce que ça apporte
- Des mises en production sans interruption de service.
- Un retour arrière automatique si la nouvelle version se comporte mal.
- La mise à l'échelle selon la charge (autoscaling).
- La relance automatique des conteneurs défaillants.
- La répartition de charge et le routage du trafic.
Kubernetes n'est pas toujours nécessaire. Pour un projet modeste, une plateforme comme Coolify ou un PaaS du marché offre l'essentiel (déploiement de conteneurs, certificats, retour arrière) pour une fraction de la complexité. Le choix se fait projet par projet.
L'intégration et le déploiement continus (CI/CD)
La CI/CD déroule automatiquement une série de vérifications à chaque modification du code : tests, analyse statique (linter), contrôle des dépendances vulnérables, build de l'image, puis déploiement. L'équipe sait en quelques minutes si ce qu'elle vient de pousser fonctionne, bien avant que le problème n'arrive en production.
Chez theTribe, nous utilisons GitHub Actions en priorité. Les workflows sont décrits en YAML dans le dépôt, à côté du code, et s'exécutent sur chaque pull request et à chaque fusion. GitLab CI est l'équivalent naturel pour les projets hébergés sur GitLab.
Ce que ça apporte
- Un code vérifié à chaque modification, avant d'être fusionné.
- Des retours rapides pour les développeurs.
- Des déploiements automatiques sur les environnements de recette, puis de production.
- Une trace de chaque livraison : qui, quand, quelle version.
Terraform : l'infrastructure as code
L'infrastructure as code consiste à décrire l'infrastructure dans des fichiers versionnés plutôt qu'à la configurer à la main dans une console. Terraform, et son fork open source OpenTofu, permettent de déclarer les ressources voulues (serveurs, réseaux, bases de données, clusters Kubernetes, DNS) chez la plupart des fournisseurs cloud, puis de les créer, les modifier ou les détruire en une commande.
Lancé depuis la CI, Terraform permet par exemple de monter un environnement de test complet le temps d'une validation, puis de le détruire pour ne pas payer de ressources inutilisées.
Ce que ça apporte
- Des environnements reproductibles et identiques entre eux.
- Une infrastructure relue et versionnée comme le code, avec un historique des changements.
- Moins d'erreurs humaines.
- Une documentation vivante : toute l'infrastructure est décrite dans le dépôt.
Ansible : la configuration des serveurs
Ansible automatise la configuration de serveurs à partir de scripts déclaratifs (playbooks) : installation de paquets, configuration d'un serveur web, gestion des utilisateurs. Avec la généralisation des conteneurs et des services managés, son rôle s'est réduit : il y a moins de serveurs à configurer à la main. Il reste utile pour les serveurs classiques, l'infrastructure existante ou les machines qui ne tournent pas sous Kubernetes.
GitOps : Argo CD et Flux
Le GitOps pousse la logique de l'infrastructure as code jusqu'au déploiement. L'état voulu de l'application (quelle version, quelle configuration) est décrit dans un dépôt Git, et un outil comme Argo CD ou Flux se charge en permanence d'aligner le cluster Kubernetes sur ce dépôt.
Déployer revient alors à modifier un fichier dans Git, avec relecture et historique. Revenir en arrière revient à annuler ce changement.
Ce que ça apporte
- Un historique complet de ce qui tourne en production.
- Des déploiements relus comme du code.
- La détection et la correction automatique des écarts entre ce qui est déclaré et ce qui tourne.
L'observabilité : savoir ce qui se passe en production
Livrer souvent n'a de sens que si l'on voit tout de suite l'effet d'une livraison. L'observabilité regroupe trois types de signaux :
- les métriques (temps de réponse, taux d'erreur, consommation de ressources), avec Prometheus et Grafana ;
- les logs, centralisés pour être consultés et recherchés en un seul endroit ;
- les traces, qui suivent une requête à travers les différents services, avec OpenTelemetry.
Ce sont aussi ces indicateurs qui pilotent les déploiements progressifs : si le taux d'erreur de la nouvelle version monte, le déploiement s'arrête de lui-même.
Le cloud et les fournisseurs cloud
Les fournisseurs cloud mettent à disposition, en quelques minutes, des serveurs, des bases de données managées, des clusters Kubernetes ou des registres d'images. Parmi eux : AWS, Google Cloud, Azure, et des acteurs européens comme Scaleway ou OVHcloud, souvent privilégiés pour des raisons de souveraineté des données.
Couplé à l'infrastructure as code, le cloud permet de créer et de détruire des environnements à la volée, de manière totalement automatisée.
En résumé
| Besoin | Outils |
|---|---|
| Emballer l'application | Docker |
| Faire tourner et mettre à l'échelle | Kubernetes, ou Coolify et PaaS pour les projets plus simples |
| Vérifier et livrer à chaque modification | GitHub Actions, GitLab CI |
| Décrire l'infrastructure | Terraform, OpenTofu |
| Configurer des serveurs | Ansible |
| Déployer depuis Git | Argo CD, Flux |
| Voir ce qui se passe en production | Prometheus, Grafana, OpenTelemetry |
Maîtriser ces outils, c'est pour une équipe de développement l'assurance de livrer plus souvent, avec moins de risques, et sans dépendre d'une équipe d'exploitation pour chaque mise en production. Pour une entreprise, c'est la condition pour proposer un service fiable, qui tient la charge et évolue sans interruption.
Pour voir ces outils assemblés dans une chaîne complète, lisez notre article pratique : DevOps : mettre en place le déploiement continu avec Docker, GitHub Actions et Kubernetes.
