Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Bonnes pratiques : Gestion et déploiement des applications et des livres de recettes
Important
Le AWS OpsWorks Stacks service a pris fin le 26 mai 2024 et a été désactivé tant pour les nouveaux clients que pour les clients existants. Nous recommandons vivement aux clients de migrer leurs charges de travail vers d'autres solutions dès que possible. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur AWS Re:Post
AWS OpsWorks Stacks déploie des applications et des livres de recettes sur chaque nouvelle instance à partir d'un référentiel distant. Au cours de la durée de vie d'une instance, vous devez souvent mettre à jour les applications ou les livres de recettes sur les instances en ligne de la pile pour ajouter des fonctions, corriger les bogues, etc. Il existe une grande variété de moyens pour gérer les applications et les livres de recettes d'une pile, mais l'approche que vous utilisez doit répondre aux exigences générales suivantes :
-
Toutes les instances de pile en production doivent avoir le même code d'application et de livre de recettes personnalisé, avec des exceptions limitées telles que les tests A/B.
-
Le déploiement d'une mise à jour ne doit pas interrompre le fonctionnement du site, même en cas de problème.
Cette section décrit les pratiques recommandées concernant la gestion et le déploiement d'applications et de livres de recettes personnalisés.
Maintien de la cohérence
En général, vous devez conserver un contrôle strict sur le code de l'application ou du livre de recettes qui s'exécute sur votre pile en production. En général, toutes les instances doivent exécuter la version actuellement approuvée du code. Les exceptions se produisent lors de la mise à jour de vos applications ou livres de recettes, comme décrit plus tard, et lors de certains cas particuliers, comme l'exécution des tests A/B.
Le code de l'application et du livre de recettes est déployé depuis un référentiel source spécifié vers les instances de votre pile de deux façons :
-
Lorsque vous démarrez une instance, AWS OpsWorks Stacks déploie automatiquement le code actuel de l'application et du livre de recettes sur l'instance.
-
Pour les instances en ligne, vous devez déployer manuellement le code actuel de l'application ou du livre de recettes en exécutant une commande Deploy (pour les applications) ou une commande Update Custom Cookbooks (pour les livres de recettes).
Comme il existe deux mécanismes de déploiement, il est essentiel que vous gériez votre code source soigneusement afin d'éviter qu'un autre code ne s'exécute par inadvertance sur d'autres instances. Par exemple, si vous déployez des applications ou des livres de recettes à partir d'une branche principale de Git, AWS OpsWorks Stacks déploie le contenu de cette branche à ce moment-là. Si vous mettez à jour le code dans la branche principale, puis démarrez une nouvelle instance, cette instance possède une version plus récente du code que les instances plus anciennes. La version la plus récente peut même ne pas être approuvée pour la production.
- Recommandation : Amazon S3 Archives
-
Pour garantir que toutes vos instances disposent de la version de code approuvée, nous vous recommandons de déployer vos applications et livres de recettes à partir d'une archive Amazon Simple Storage Service (Amazon S3). Cela garantit que le code est un artefact statique (un fichier .zip ou un autre fichier d'archive) qui doit être explicitement mis à jour. En outre, Amazon S3 est extrêmement fiable, de sorte que vous ne pourrez que rarement, voire jamais, accéder à l'archive. Pour garantir davantage de cohérence, versionnez explicitement chaque fichier d'archive en utilisant une convention de dénomination ou en utilisant le versionnement d'Amazon S3, qui fournit une piste d'audit et permet de revenir facilement à une version antérieure.
Par exemple, vous pouvez créer un pipeline de déploiement à l'aide d'un outil tel que Jenkins
. Une fois que le code que vous souhaitez déployer a été validé et testé, créez un fichier d'archive et chargez-le sur Amazon S3. Tous les déploiements d'application ou mises à jour de livre de recettes installent le code dans ce fichier d'archives et chaque instance possède le même code. - Recommandation : référentiels Git ou Subversion
-
Si vous préférez utiliser un référentiel Git ou Subversion, ne le déployez pas à partir de la branche principale. Au lieu de cela, balisez la version approuvée et spécifiez cette version comme la source de l'application ou du livre de recettes.
Déploiement du code sur les instances en ligne
AWS OpsWorks Stacks ne déploie pas automatiquement le code mis à jour sur les instances en ligne. Vous devez effectuer cette opération manuellement, ce qui nécessite de relever les défis suivants :
-
Déployer la mise à jour efficacement sans compromettre la capacité du site à gérer les demandes des clients pendant le processus de déploiement.
-
Gérer un déploiement ayant échoué, en raison de problèmes liés à l'application ou aux livres de recettes déployés, ou de problèmes liés au processus de déploiement lui-même.
L'approche la plus simple consiste à exécuter une commande Deploy par défaut (pour les applications) ou une commande Update Custom Cookbooks (pour les livres de recettes), qui déploie la mise à jour sur chaque instance simultanément. Cette approche est simple et rapide, mais il n'y a aucune marge d'erreur. Si le déploiement échoue ou que le code mis à jour rencontre des problèmes, chaque instance de votre pile en production peut être affectée, ce qui perturbe ou désactive éventuellement votre site jusqu'à ce que vous puissiez résoudre le problème ou revenir à la version précédente.
Recommandation : utilisez une stratégie de déploiement robuste, qui permet aux instances exécutant l'ancienne version du code de poursuivre le traitement des demandes jusqu'à ce que vous ayez vérifié que le déploiement ait réussi et que vous puissiez transférer en toute confiance l'ensemble du trafic entrant vers la nouvelle version.
Les sections suivantes fournissent deux exemples de stratégies de déploiement robustes, suivis d'une discussion sur la manière de gérer une base de données principale pendant le déploiement. Pour être bref, elles décrivent les mises à jour des applications, mais vous pouvez utiliser des stratégies similaires pour les livres de recettes.
Rubriques
Utilisation d'un déploiement roulant
Un déploiement roulant met à jour une application sur les instances serveur d'applications en ligne d'une pile en plusieurs phases. Avec chaque phase, vous mettez à jour un sous-ensemble des instances en ligne et vérifiez que la mise à jour a réussi avant de commencer la phase suivante. Si vous rencontrez des problèmes, les instances qui continuent d'exécuter l'ancienne version de l'application peuvent continuer à gérer le trafic entrant jusqu'à ce que vous ayez résolu les problèmes.
L'exemple suivant suppose que vous utilisiez la pratique recommandée en matière de répartition des instances serveur d'applications de votre pile entre plusieurs zones de disponibilité.
Pour effectuer un déploiement roulant
-
Sur la page Deploy App (Déployer l'application), choisissez Advanced (Avancé), sélectionnez une seule instance serveur d'applications et déployez l'application sur cette instance.
Si vous souhaitez être prudent, vous pouvez supprimer l'instance de l'équilibreur de charge avant de déployer l'application. Les utilisateurs sont ainsi assurés de ne pas rencontrer l'application mise à jour jusqu'à ce que vous ayez vérifié qu'elle fonctionne correctement. Si vous utilisez Elastic Load Balancing, supprimez l'instance de l'équilibreur de charge à l'aide de la console Elastic Load Balancing, de la CLI ou d'un SDK.
-
Vérifiez que l'application mise à jour fonctionne correctement et que l'instance présente des métriques de performance acceptables.
Si vous avez supprimé l'instance d'un équilibreur de charge Elastic Load Balancing, utilisez la console Elastic Load Balancing, la CLI ou un SDK pour la restaurer. La version d'application mise à jour gère désormais les requêtes utilisateur.
-
Déployez la mise à jour sur le reste des instances de la zone de disponibilité et vérifiez que les instances fonctionnent correctement et ont des métriques acceptables.
-
Répétez l'étape 3 pour les autres zones de disponibilité de la pile, une zone à la fois. Si vous voulez être particulièrement prudent, répétez les étapes 1 à 3.
Note
Si vous utilisez un équilibreur de charge Elastic Load Balancing, vous pouvez utiliser son bilan de santé pour vérifier que le déploiement a réussi. Cependant, définissez le chemin d'accès ping vers une application qui contrôle les dépendances et vérifie que tout fonctionne correctement, pas vers un fichier statique qui confirme simplement que le serveur d'applications est en cours d'exécution.
Utilisation de piles distinctes
Une autre approche pour gérer les applications consiste à utiliser une pile distincte pour chaque phase du cycle de vie de l'application. Les différentes piles sont parfois appelées environnements. Cette organisation vous permet d'effectuer le développement et les tests sur des piles qui ne sont pas accessibles publiquement. Lorsque vous êtes prêt à déployer une mise à jour, basculez le trafic utilisateur à partir de la pile qui héberge la version actuelle de l'application vers la pile qui héberge la version mise à jour.
Rubriques
Utilisation des piles de développement, des piles intermédiaires et des piles de production
L'approche la plus courante utilise les piles suivantes.
- Pile de développement
-
Utilisez une pile de développement pour des tâches telles que la mise en œuvre de nouvelles fonctionnalités ou la correction de bogues. Une pile de développement est essentiellement un prototype de pile de production, avec les mêmes couches, applications, ressources, etc., qui sont inclus dans votre pile de production. Comme, généralement, la pile de développement n'a pas à gérer la même charge que la pile de production, vous utilisez habituellement moins d'instances ou des instances plus petites.
Les piles de développement ne sont pas exposées publiquement ; vous contrôlez l'accès comme suit :
-
Limitez l'accès réseau en configurant les règles de trafic entrant des groupes de sécurité du serveur d'applications ou de l'équilibreur de charge de façon à n'accepter que les demandes entrantes émanant d'adresses IP ou de plages d'adresses IP spécifiées.
Par exemple, limitez l'accès HTTP, HTTPS et SSH aux adresses de votre plage d'adresses d'entreprise.
-
Contrôlez l'accès à la fonctionnalité de gestion des AWS OpsWorks piles Stacks en utilisant la page Permissions de la pile.
Par exemple, accordez le niveau d'autorisations Manage à l'équipe de développement et le niveau Show à tous les autres employés.
-
- Pile intermédiaire
-
Utilisez une pile intermédiaire pour tester et finaliser les candidats d'une pile en production mise à jour. Lorsque vous avez terminé le développement, créez une pile intermédiaire en clonant la pile de développement. Puis, exécutez votre suite de tests sur la pile intermédiaire et déployez les mises à jour sur la pile pour résoudre les problèmes qui surviennent.
Les piles de transit ne sont pas exposées au public ; vous contrôlez la pile et l'accès réseau de la même façon que vous le faites pour la pile de développement. Notez que lorsque vous clonez une pile de développement pour créer une pile intermédiaire, vous pouvez cloner les autorisations accordées par la gestion des autorisations de AWS OpsWorks Stacks. Cependant, le clonage n'affecte pas les autorisations accordées par les stratégies IAM des utilisateurs. Vous devez utiliser la console IAM, l'interface de ligne de commande ou un kit SDK pour modifier ces autorisations. Pour de plus amples informations, veuillez consulter Gestion des autorisations utilisateur.
- Pile de production
-
La pile de production est la pile exposée au public et qui prend en charge votre application en cours. Lorsque la pile intermédiaire a passé les tests, vous la promouvez en pile de production et retirez l'ancienne pile de production. Pour obtenir un exemple montrant la façon de procéder, consultez Utilisation d'une stratégie de déploiement blue-green.
Note
Au lieu d'utiliser la console AWS OpsWorks Stacks pour créer des piles manuellement, créez un AWS CloudFormation modèle pour chaque pile. Cette méthode offre les avantages suivants :
-
Rapidité et commodité : lorsque vous lancez le modèle, il crée AWS CloudFormation automatiquement la pile, y compris toutes les instances requises.
-
Cohérence : stockez le modèle pour chaque pile dans votre référentiel source afin de vous assurer que les développeurs utilisent la même pile dans le même but.
Utilisation d'une stratégie de déploiement blue-green
Une stratégie de déploiement bleu-vert est une solution courante pour utiliser efficacement des piles distinctes et déployer une mise à jour de l'application en production.
-
L'environnement bleu est la pile de production, qui héberge l'application en cours.
-
L'environnement vert est la pile intermédiaire, qui héberge l'application mise à jour.
Lorsque vous êtes prêt à déployer l'application mise à jour en production, vous basculez le trafic des utilisateurs de la pile bleue vers la pile verte, qui devient la nouvelle pile de production. Vous retirez alors l'ancienne pile bleue.
L'exemple suivant décrit comment effectuer un déploiement bleu vert avec des AWS OpsWorks stacks, en conjonction avec Route 53 et un pool d'équilibreurs de charge Elastic Load Balancing. Avant de procéder au basculement, vous devez vous assurer des points suivants :
-
La mise à jour de l'application sur la pile verte a passé les tests avec succès et est prête pour la production.
-
La pile verte est identique à la pile bleue, sauf qu'elle inclut l'application mise à jour et qu'elle n'est pas exposée au public.
Les deux piles ont les mêmes autorisations, les mêmes nombre et type d'instance dans chaque couche, les mêmes configurations à date définie et à charge définie, etc.
-
Toutes les instances 24/7 et les instances planifiées basés à date définie de la pile verte sont en ligne.
-
Vous disposez d'un pool d'équilibreurs de charge Elastic Load Balancing qui peuvent être attachés dynamiquement à une couche dans l'une ou l'autre des piles et qui peuvent être préchauffés
pour gérer le volume de trafic attendu. -
Vous avez utilisé la fonctionnalité de routage pondéré Route 53 pour créer un ensemble d'enregistrements dans une zone hébergée qui inclut vos équilibreurs de charge groupés.
-
Vous avez attribué un poids différent de zéro à l'équilibreur de charge attaché à la couche serveur d'applications de votre pile bleue et un poids zéro aux équilibreurs de charge inutilisés. Cela garantit que l'équilibreur de charge de la pile bleue gère tout le trafic entrant.
Pour basculer les utilisateurs vers la pile verte
-
Attachez un des équilibreurs de charge inutilisés du pool à la couche du serveur d'application de la pile verte. Dans certains scénarios, comme lorsque vous prévoyez un trafic flash ou que vous ne pouvez pas configurer un test de charge de manière à augmenter progressivement le trafic, préchauffez
l'équilibreur de charge afin de gérer le trafic attendu. -
Une fois que toutes les instances de la pile verte ont passé avec succès le test de santé d'Elastic Load Balancing, modifiez les pondérations du jeu d'enregistrements Route 53 afin que l'équilibreur de charge de la pile verte ait une pondération différente de zéro et que le poids de l'équilibreur de charge de la pile bleue soit réduit en conséquence. Nous vous recommandons de commencer par ce que la pile verte gère un petit pourcentage de requêtes, peut-être 5 %, la pile bleue gérant le reste. Vous avez maintenant deux piles de production, avec la pile verte gérant certaines demandes entrantes et la pile bleue gérant le reste.
-
Surveillez les métriques de performance de la pile verte. Si elles sont acceptables, augmentez le poids de la pile verte afin qu'elle gère peut-être 10 % du trafic entrant.
-
Répétez l'étape 3 jusqu'à ce que la pile verte gère environ la moitié du trafic entrant. Tous les problèmes ayant dû être identifiés à ce stade, si la pile verte s'exécute correctement, vous pouvez terminer le processus en réduisant à zéro le poids de la pile bleue. La pile verte est désormais la nouvelle pile bleue et gère tout le trafic entrant.
-
Détachez l'équilibreur de charge de la couche serveur d'applications de l'ancienne pile bleue et retournez-le au pool.
-
Même si l'ancienne pile bleue ne gère plus les requêtes utilisateur, nous vous recommandons de la conserver quelque temps en cas de problèmes avec la nouvelle pile bleue. Dans ce cas, vous pouvez annuler la mise à jour en rétablissant la procédure et en redirigeant le trafic entrant vers l'ancienne pile bleue. Lorsque vous êtes sûr que la nouvelle pile bleue fonctionne correctement, arrêtez l'ancienne pile bleue.
Gestion d'une base de données principale
Si votre application dépend d'une base de données principale, vous devrez passer de l'ancienne application à la nouvelle. AWS OpsWorks Stacks prend en charge les options de base de données suivantes.
- Couche Amazon RDS
-
Avec une couche Amazon Relational Database Service (Amazon RDS), vous créez l'instance de base de données RDS séparément, puis vous l'enregistrez dans votre stack. Vous pouvez enregistrer une instance DB RDS avec une seule pile à la fois, mais vous pouvez basculer une instance DB RDS d'une pile vers une autre.
AWS OpsWorks Stacks installe un fichier contenant les données de connexion sur vos serveurs d'applications dans un format facilement utilisable par votre application. AWS OpsWorks Stacks ajoute également les informations de connexion à la base de données aux attributs de configuration et de déploiement de la pile, accessibles par des recettes. Vous pouvez également utiliser JSON pour fournir des données de connexion aux applications. Pour de plus amples informations, veuillez consulter Connexion à une base de données.
La mise à jour d'une application qui repose sur une base de données pose deux défis élémentaires :
-
S'assurer que chaque transaction est correctement enregistrée pendant la transition tout en évitant également les conditions de concurrence entre les ancienne et nouvelle versions de l'application.
-
Procéder à la transition d'une manière qui limite l'impact sur les performances de votre site, et réduit ou élimine les temps d'arrêt.
Lorsque vous utilisez les stratégies de déploiement décrites dans cette rubrique, vous ne pouvez pas simplement détacher la base de données de l'ancienne application et la rattacher à la nouvelle. Les deux versions de l'application s'exécutent en parallèle pendant la transition et doivent avoir accès aux mêmes données. Les lignes suivantes décrivent deux approches de la gestion de la transition, les deux présentant des avantages et posant des défis.
- Approche 1 : Avoir deux applications qui se connectent à la même base de données
-
- Avantages
-
-
Il n'existe aucune interruption de service pendant la transition.
Une application cesse progressivement d'accéder à la base de données, tandis que l'autre prend progressivement le contrôle.
-
Vous n'avez pas à synchroniser les données entre les deux bases de données.
-
- Défis
-
-
Comme les deux applications accèdent à la même base de données, vous devez gérer l'accès pour éviter la perte ou corruption de données.
-
Si vous avez besoin de migrer vers un nouveau schéma de base de données, l'ancienne version de l'application doit être en mesure d'utiliser le nouveau schéma.
-
Si vous utilisez des piles distinctes, cette approche convient probablement mieux à Amazon RDS, car l'instance n'est pas liée de façon permanente à une pile particulière et est accessible aux applications exécutées sur différentes piles. Cependant, comme vous ne pouvez pas enregistrer une instance de base de données RDS avec plus d'une pile à la fois, vous devez fournir les données de connexion aux deux applications, par exemple en utilisant JSON. Pour de plus amples informations, veuillez consulter Utilisation d'une recette personnalisée.
Si vous utilisez une mise à niveau progressive, l'ancienne et la nouvelle version de l'application sont hébergées sur la même pile. Vous pouvez donc utiliser une couche Amazon RDS ou MySQL.
- Approche 2 : Offrir à chaque version de l'application sa propre base de données
-
- Avantages
-
-
Chaque version ayant sa propre base de données, les schémas n'ont pas à être compatibles.
-
- Défis
-
-
Synchroniser les données entre les deux bases de données pendant la transition sans perte ou corruption des données.
-
S'assurer que votre procédure de synchronisation n'entraîne pas de temps d'arrêt significatifs ou ne dégrade pas considérablement les performances du site.
-
Si vous utilisez des piles distinctes, chacune d'elles a sa propre base de données. Si vous utilisez un déploiement roulant, vous pouvez attacher deux bases de données à la pile, une pour chaque application. Si l'ancienne application et l'application mise à jour n'ont pas de schémas de base de données compatibles, cette approche est préférable.
Recommandation : En général, nous recommandons d'utiliser une couche Amazon RDS comme base de données principale d'une application, car elle est plus flexible et peut être utilisée pour n'importe quel scénario de transition. Pour plus d'informations sur la gestion des transitions, consultez le guide de l'utilisateur Amazon RDS.
