Les fondamentaux du cloud computing
DevOps et infrastructure as code
Comment le développement et les opérations ont fusionné en une seule pratique continue, ce que chaque étape d'un pipeline CI/CD détecte, et comment décrire l'infrastructure sous forme de code, plutôt que de cliquer dans une console, garde les environnements cohérents et reproductibles.
- Expliquer ce que DevOps change dans la façon dont les équipes de développement et d'exploitation travaillent ensemble
- Décrire les étapes d'un pipeline CI/CD et ce que chaque étape détecte avant qu'un changement n'atteigne la production
- Expliquer comment l'infrastructure as code remplace les changements manuels dans une console par une configuration versionnée et déclarative
- Identifier la dérive de configuration et pourquoi elle survient quand l'infrastructure est modifiée en dehors de sa définition en code
- Comparer le flux planifier puis appliquer d'un outil déclaratif d'infrastructure as code à la réalisation du même changement à la main
La dernière leçon vous a laissé avec plus de pièces mobiles qu'un seul déploiement ne peut gérer
La dernière leçon vous a laissé avec une équipe qui fait tourner un nombre croissant de services déployables indépendamment, chacun livré selon son propre rythme. Livrer une seule application à la main, testée manuellement et copiée sur un serveur par la personne de garde, était déjà lent et source d'erreurs. Livrer 10 services de cette façon n'est pas seulement plus lent, cela cesse d'être quelque chose qu'une personne peut faire de manière fiable. DevOps, et les pratiques construites autour, existent pour répondre exactement à ce problème.
Ce que DevOps change réellement
Avant DevOps, développement et exploitation formaient généralement 2 équipes séparées : les développeurs écrivaient le code et le transmettaient, l'exploitation le déployait et le faisait tourner, et chaque camp blâmait l'autre quand une mise en production cassait quelque chose. DevOps, dans le cadre défini par AWS, est une combinaison de philosophies culturelles, de pratiques et d'outils qui augmente la capacité d'une organisation à livrer des applications et des services à haute vélocité. En pratique, cela signifie que la même équipe écrit, teste, déploie et exploite ses propres services, ce qui lui donne un intérêt direct à rendre le déploiement lui-même rapide et sûr, plutôt que de lancer un build par-dessus un mur en espérant que ça passe.
Intégration continue, livraison continue : ce qui se passe réellement à chaque étape
| Étape | Ce qui se passe | Ce qu'elle détecte |
|---|---|---|
| Source | Un développeur pousse du code vers un dépôt partagé | Rien encore, cela ne fait que démarrer le pipeline |
| Build | Le code compile et s'empaquette en artefact déployable | Les erreurs de syntaxe, les dépendances manquantes |
| Test | Une suite de tests automatisés s'exécute sur le build | Les régressions dans le comportement existant |
| Staging | Le build se déploie sur un environnement de pré-production | Les problèmes d'intégration et de configuration |
| Production | Le build se déploie auprès des utilisateurs réels | Rien de plus, c'est la mise en production |
Suivez un commit à travers ce pipeline. Un développeur pousse un correctif sur le service de paiement de la leçon précédente. L'intégration continue construit une nouvelle image de conteneur et exécute la suite de tests contre elle ; si un test échoue, le pipeline s'arrête immédiatement, et le changement n'atteint jamais le staging, encore moins la production. Si tous les tests passent, la livraison continue prend le relais, déployant automatiquement ce même build sur le staging, et, une fois les vérifications passées là aussi, promouvant ce build exact en production. Aucune étape n'est sautée, et aucun humain ne copie un fichier à la main.
name: ci
on: [push]
jobs:
build-and-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: docker build -t service-paiement:${{ github.sha }} .
- run: docker run service-paiement:${{ github.sha }} npm test
Infrastructure as code : la même idée, appliquée à l'infrastructure
CI/CD automatise la livraison du code applicatif. L'infrastructure as code applique la même discipline aux serveurs, réseaux et services sur lesquels ce code tourne : provisionner et gérer l'infrastructure avec du code plutôt qu'avec des processus manuels et des clics dans une console. Un bucket de stockage créé en cliquant dans une console ne laisse aucune trace de qui l'a créé, pourquoi, ni comment le recréer. Le même bucket déclaré dans un fichier, si.
resource "aws_s3_bucket" "uploads" {
bucket = "mon-app-uploads"
}
Des outils comme Terraform fonctionnent en 3 étapes : écrire la configuration, planifier (prévisualiser exactement ce qui sera créé, modifié ou détruit pour correspondre à cette configuration), et appliquer (exécuter ces changements dans le bon ordre de dépendance). Cette configuration est déclarative : elle décrit l'état final voulu, pas les commandes individuelles pour y arriver, et l'outil se charge du reste.
Le piège : "un correctif manuel rapide dans la console ne fait pas de mal"
Il est tentant de penser qu'un correctif rapide dans la console, augmenter la mémoire d'une instance surchargée à 2 heures du matin pendant un incident, est sans danger tant qu'il résout le problème immédiat. Ce n'est pas le cas : le fichier d'infrastructure as code décrit toujours l'ancienne instance, plus petite, donc le code et l'infrastructure réelle ont discrètement divergé. La prochaine fois que quelqu'un applique ce code, il peut annuler le correctif d'urgence sans que personne ne le veuille, ou l'équipe cesse simplement de faire confiance au code pour refléter ce qui tourne réellement. Cet écart s'appelle la dérive de configuration, et la solution est la discipline, pas l'astuce : mettre à jour le code pour qu'il corresponde au changement d'urgence immédiatement, ou annuler le changement manuel et refaire le même correctif à travers le code.
Repères d'examen : reconnaître le bon choix dans un scénario
| L'énoncé dit... | Pointe vers |
|---|---|
| "Build, test et déploiement automatisés à chaque commit" | Pipeline CI/CD |
| "Infrastructure définie dans des fichiers versionnés" | Infrastructure as code |
| "Un changement manuel effectué en dehors du pipeline de déploiement" | Risque de dérive de configuration |
| "Prévisualiser les changements avant qu'ils ne soient appliqués" | Étape de planification déclarative de l'infrastructure as code |
Ce qu'il faut retenir
DevOps, CI/CD et infrastructure as code rendent durable tout ce que les 2 dernières leçons ont couvert à l'échelle réelle : une fonction serverless ou une image de conteneur n'est fiable qu'autant que le pipeline qui la construit, la teste et la livre, et l'infrastructure sur laquelle elle tourne n'est cohérente qu'autant que le code qui la décrit. Le prochain domaine de ce cours s'attaque à ce qui garde les systèmes sécurisés et disponibles une fois en fonctionnement, le modèle de responsabilité partagée, l'identité, le chiffrement et la reprise après sinistre, des pratiques que l'infrastructure as code rend bien plus faciles à appliquer de la même façon dans chaque environnement.