Stratégies de déploiement
Les stratégies pour livrer un changement sur une charge de travail qui sert déjà du trafic, et les réglages AWS qui produisent chacune d'elles : instance refresh, update policies CloudFormation, stratégies de déploiement ECS, alias Lambda et blue/green RDS.
Tout déploiement livre le même code. Ce qui change d'une stratégie à l'autre, c'est le nombre d'utilisateurs qui rencontrent le problème avant que vous le remarquiez, et le temps qu'il faut pour revenir en arrière. Ce sujet commence par le vocabulaire (all at once, rolling, immutable, blue/green, canary, linear), puis passe aux champs AWS précis qui produisent chaque forme, parce qu'à l'examen la bonne réponse est en général un pourcentage ou un nom de policy plutôt qu'un concept.
Ce que couvre ce sujet
- Les 2 questions derrière chaque stratégie : modifier les serveurs existants ou en construire de nouveaux, et quelle part du trafic atteint la nouvelle version d'un coup
- Ce que chaque stratégie coûte en capacité supplémentaire, en utilisateurs exposés et en vitesse de rollback, avec le calcul d'une taille de lot en rolling
- La frontière entre blue/green et canary, exprimée par le mécanisme de trafic et non par le nombre d'environnements
- Pourquoi la couche de données est la partie qu'aucune stratégie ne règle : schémas partagés, écritures non réversibles et état de session
- L'instance refresh Auto Scaling : pourcentages minimum et maximum d'instances saines, warmup, checkpoints, skip matching, et les conditions qui rendent le rollback indisponible
- Les 3 update policies CloudFormation d'un Auto Scaling group, et les valeurs par défaut qui vident une flotte
- Les déploiements rolling ECS, l'arrondi qui bloque les petits services, le deployment circuit breaker, et les stratégies natives blue/green, linear et canary avec bake time et lifecycle hooks
- Les versions, alias et routage pondéré de Lambda, et comment savoir quelle version a servi une requête
- Les déploiements blue/green managés de RDS et le sort de l'ancien environnement après la bascule
Pourquoi c'est important
Les questions d'examen sur ce sujet demandent rarement ce que veut dire blue/green. Elles vous donnent un service avec 2 tasks et un déploiement bloqué, un instance refresh qui ne peut pas revenir en arrière, ou une mise à jour CloudFormation qui a mis toute une flotte hors service, et elles demandent ce qui s'est passé. Chacun de ces cas a un réglage précis derrière lui.
La pression du métier est la même. La plupart des incidents de production ne viennent pas d'un mauvais code, mais de la façon dont il a été livré, qui a rendu le problème grand avant que quiconque puisse le voir.