Formation DevOps écrite

Comment déployer du code à faible risque dans votre environnement de production en DevOps ?

Dans de nombreux services informatiques, les déploiements en production sont lourds et stressants. Pour limiter les tensions, les organisations ont tendance à déployer le moins souvent possible. Elles finissent inévitablement par déployer des lots plus importants, qui causent des problèmes encore plus graves. Ce cercle vicieux ne fait que s’aggraver et représente malheureusement la situation de la plupart des grandes organisations, même de celles dont le cœur de métier est le logiciel et la technologie.

Votre équipe DevOps intègre des mécanismes de contrôle et de réduction des risques

Dans un service informatique classique, l’équipe de développement construit le logiciel et l’équipe d’exploitation se charge de le déployer. Avec le DevOps, les contrôles et la réduction des risques relèvent de votre propre équipe compétente et autonome. Elle s’appuie sur ses processus de déploiement automatisé et de revue par les pairs.

Les environnements de production et les autres environnements sont aussi importants que le logiciel produit par votre équipe DevOps. Votre équipe applique donc trois principes :

1. Assurez la cohérence de tous les environnements quant aux systèmes d’exploitation, aux composants, aux interfaces, aux niveaux de correctifs, aux autres dépendances et, bien sûr, à vos propres logiciels et configurations.
2. Corriger tout obstacle qui compromet la cohérence de vos environnements est une priorité absolue.
3. Utilisez les mêmes techniques de déploiement dans tous les environnements pour répéter les déploiements en production dans le cadre de votre travail quotidien.

Votre mécanisme intégré de déploiement en libre-service

Voici les étapes de votre mécanisme automatisé de déploiement en libre-service.

1. Écrire le code et l’intégrer au tronc.
2. Construire les paquets déployables.
3. Vérifier que les paquets déployables, les dépendances et la configuration sont prêts.
4. Vérifier que l’environnement est prêt.
5. Exécuter les tests automatisés.
6. Consigner tous les résultats des validations et tests automatisés à des fins d’audit et de conformité.
7. Déployer les paquets dans l’environnement cible.
8. Exécuter les tests automatisés dans l’environnement cible pour valider le déploiement.
9. Surveiller les indicateurs de système, de performance et d’activité de l’environnement cible.
10. Fournir un retour rapide et corriger ou annuler le déploiement en cas de problème.

Le déploiement et la mise à disposition sont deux opérations distinctes

Grâce à un mécanisme de déploiement automatisé en libre-service dans les environnements de production et hors production, votre équipe DevOps peut déployer son code chaque jour. Chaque déploiement ne correspond pas à une nouvelle fonctionnalité ou à un avantage pour les clients. L’équipe doit donc concevoir ses applications ou ses environnements, ou les deux, pour qu’une mise à disposition ne nécessite ni modification du code ni déploiement supplémentaire.

Modèle de déploiement bleu-vert

L’un des défis du déploiement automatisé est le basculement, qui fait passer le logiciel de la dernière phase de test à la production. Il faut généralement l’effectuer rapidement pour limiter l’indisponibilité. Le déploiement bleu-vert utilise deux environnements de production aussi identiques que possible. À tout moment, l’un des deux, par exemple le bleu, est en service. Lorsque vous préparez une nouvelle version, vous effectuez les derniers tests dans l’environnement vert. Une fois le logiciel opérationnel dans cet environnement, vous basculez le routeur pour que toutes les requêtes entrantes aillent vers le vert. L’environnement bleu devient alors inactif.

Modèle de déploiement canari
(aussi appelé lancement invisible)

Autrefois, on utilisait couramment des canaris comme système d’alerte précoce dans les mines de charbon. Les gaz toxiques de la mine, comme le méthane ou le dioxyde de carbone, tuaient l’oiseau avant de toucher les mineurs. Les signes de détresse de l’oiseau signalaient aux mineurs un danger.

Inspiré de l’usage des canaris dans les mines, le déploiement canari consiste à mettre une version à disposition d’une partie des utilisateurs ou des serveurs. On commence par déployer le changement sur quelques serveurs et le tester, puis on l’étend aux autres serveurs. Le déploiement canari sert de système d’alerte précoce et limite l’indisponibilité. En cas d’échec, les autres serveurs ne sont pas touchés.

Facebook, Google et de nombreux géants de la technologie utilisent un modèle de déploiement canari appelé « lancement invisible » (dark launch). Ils mettent progressivement les nouvelles fonctionnalités à la disposition d’un petit nombre d’utilisateurs et les testent avant de les ouvrir à tous. Ils peuvent ainsi voir si elles vous plaisent et mesurer leur effet sur les performances du système. Facebook appelle son outil de lancement invisible « Gatekeeper », car il contrôle l’accès des utilisateurs à chaque nouvelle fonctionnalité.

On parle de lancement invisible parce que ces mises à disposition ne font généralement pas l’objet d’une annonce. Elles sont déployées discrètement auprès de 1 %, puis de 5 %, puis de 30 % des utilisateurs, et ainsi de suite. Parfois, une fonctionnalité est disponible discrètement quelques jours et vous ne la revoyez jamais. C’est probablement parce qu’elle n’a pas donné de bons résultats ou que l’entreprise souhaitait seulement obtenir de premiers retours pour orienter le développement.

Modèle de mise en production avec système immunitaire du cluster

Ce modèle prolonge le déploiement canari. Il nécessite des systèmes de supervision des performances et de l’activité du logiciel étroitement intégrés au processus de mise en production.

Dans le modèle de déploiement canari présenté ci-dessus, une fois le premier déploiement effectué sur le serveur orange, vos systèmes de supervision enregistrent tous les indicateurs de système, de performance et d’activité du logiciel. Ils donnent rapidement l’alerte lorsque les problèmes dépassent certains seuils. Le code installé sur le serveur orange fait alors automatiquement l’objet d’un retour en arrière.

Si les tests automatisés sur le serveur orange et le système de supervision donnent des résultats positifs, votre équipe DevOps peut déployer son code sur les autres groupes de serveurs bleus avec bien plus de confiance. En résumé, le modèle de mise en production avec système immunitaire du cluster offre à votre équipe DevOps :

• Une protection supplémentaire contre les problèmes que les tests automatisés pourraient ne pas détecter.
• Un retour rapide et un retour en arrière automatisé en cas de problème en production.

Interrupteurs de fonctionnalité

Les interrupteurs de fonctionnalité permettent d’activer ou de désactiver des fonctionnalités de votre application. Une fois tout le code nécessaire déployé en production, il suffit d’actionner l’interrupteur pour mettre la fonctionnalité à disposition. Ces interrupteurs sont généralement des paramètres dans des fichiers ou des bases de données de configuration du système à l’exécution.

Grâce aux interrupteurs de fonctionnalité, votre équipe DevOps peut désactiver une fonctionnalité si un déploiement canari entraîne des erreurs ou dégrade l’expérience utilisateur. Vous pouvez aussi désactiver des fonctions gourmandes en ressources et relativement peu importantes si votre système peine à passer à l’échelle. Ainsi, même si le système ne tient pas la charge avec toutes les fonctions activées, vos clients continuent de bénéficier des meilleures performances possibles sur les fonctions essentielles. Sur un site de commerce en ligne, vous pouvez par exemple désactiver temporairement l’affichage des factures afin de libérer des ressources de calcul et de mémoire pour le paiement.

Dans une architecture orientée services, vos équipes DevOps peuvent déployer différentes versions de services sans les activer. Une fois toutes les nouvelles versions nécessaires à une fonctionnalité ou à un flux de service déployées, vous pouvez activer leurs interrupteurs pour ouvrir ce nouveau flux.

Concevez une architecture qui sécurise les mises en production

Aucune architecture ne convient parfaitement à tous les produits et services logiciels, à toutes les échelles.

Lors de la création de la plateforme informatique d’une jeune entreprise, une architecture monolithique est le plus souvent choisie pour accéder au marché le plus vite et au moindre coût, et valider la justification économique du projet. Dans une architecture monolithique, les éléments fonctionnellement distincts, comme les fonctions principales et complémentaires, les interfaces utilisateur et système et les intégrations, sont tous imbriqués plutôt que séparés en composants architecturaux. Beaucoup de grandes entreprises, dont Amazon, Google, Facebook et Ebay, ont dû abandonner leur architecture monolithique pour passer rapidement à l’échelle, mettre en production avec peu de risques et étendre les fonctionnalités offertes aux clients. Elles se sont ensuite tournées vers des architectures orientées services ou microservices avec le modèle de l’application étrangleuse.

Le modèle de l’application étrangleuse pour migrer vers les microservices à faible risque

Remplacer complètement un système complexe peut représenter un chantier considérable. Souvent, vous devez migrer progressivement vers le nouveau système et conserver l’ancien pour les fonctionnalités qui n’ont pas encore été transférées. Faire fonctionner deux versions distinctes d’une application oblige toutefois les clients à savoir où se trouvent les fonctionnalités. À chaque migration de fonctionnalité ou de service, les clients doivent être mis à jour pour viser le nouvel emplacement.

Le modèle de l’application étrangleuse remplace progressivement des fonctionnalités précises par de nouvelles applications et de nouveaux services. Créez une façade qui intercepte les requêtes destinées au système hérité en arrière-plan. Elle les dirige vers l’application existante ou les nouveaux services. Vous pouvez migrer progressivement les fonctionnalités vers le nouveau système, et les consommateurs continuent à utiliser la même interface sans remarquer la migration.

Ebay figure parmi les premières entreprises à avoir utilisé le modèle de l’application étrangleuse pour migrer d’une architecture monolithique existante vers des microservices. Pour commencer, l’entreprise a placé ses applications derrière des API universelles bien définies dans l’écosystème Ebay, ce qui lui a évité de réécrire tout le code en une seule migration. Elle a réorganisé ses groupes d’ingénierie en petites équipes de six à dix ingénieurs. Une équipe d’une dizaine de personnes peut désormais gérer l’API universelle de la plateforme d’enchères, l’API d’enchères la plus utilisée au monde.

CONCLUSION

Dans la plupart des services informatiques, les équipes ne sont pas chargées de construire des modèles de déploiement pérennes, évolutifs et sûrs, ni les architectures correspondantes. Pourtant, concevoir une architecture et des fonctionnalités qui permettent des déploiements plus rapides et plus sûrs est une condition importante de la réussite du DevOps.

Pour tirer parti du déploiement continu et mettre vos versions à disposition sans difficulté, vos équipes doivent pouvoir effectuer des déploiements quotidiens, rapides et à faible risque.