AWS CloudFormation meilleures pratiques - AWS CloudFormation

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.

AWS CloudFormation meilleures pratiques

Les meilleures pratiques sont des recommandations qui peuvent vous aider à l'utiliser de manière AWS CloudFormation plus efficace et plus sûre tout au long de son flux de travail. Découvrez comment planifier et organiser vos piles, comment créer des modèles qui décrivent vos ressources et les applications qui y sont exécutées, et comment gérer vos piles et leurs ressources. Les meilleures pratiques suivantes sont basées sur l'expérience réelle des CloudFormation clients actuels.

Raccourcissement de la boucle de rétroaction pour améliorer la vitesse de diffusion

Adoptez des pratiques et des outils qui vous aident à raccourcir la boucle de rétroaction pour votre infrastructure que vous décrivez à l'aide CloudFormation de modèles. Il s'agit notamment de procéder à un linting et à des tests précoces de vos modèles sur votre poste de travail ; vous pouvez ainsi détecter d'éventuels problèmes de syntaxe et de configuration avant même de soumettre vos contributions à un référentiel de code source. La détection précoce de ces problèmes permet d'éviter qu'ils atteignent les environnements formels du cycle de vie, tels que le développement, l'assurance qualité et la production. Cette approche de test précoce et d'interruption immédiate vous permet de réduire le temps d'attente pour le remaniement, de réduire les zones d'impact potentielles et d'accroître votre niveau de confiance dans la réussite des opérations de dimensionnement.

Parmi les outils qui vous aident à adopter des pratiques rapides, citons le AWS CloudFormation Linter (cfn-lint) et les outils de ligne de commande. TaskCat L'outil cfn-lint vous permet de valider vos CloudFormation modèles par rapport à la AWS CloudFormation spécification des ressources. Il s'agit notamment de vérifier les valeurs valides des propriétés des ressources, ainsi que les meilleures pratiques. Des plugins de cfn-lint sont disponibles pour un certain nombre d'éditeurs de code ; cela vous permet de visualiser les problèmes dans votre éditeur et d'obtenir des commentaires directs de l'outil Linter. Vous pouvez également choisir d'intégrer cfn-lint dans la configuration de votre référentiel de code source, afin de pouvoir valider les modèles lors de la validation de vos contributions. Pour plus d'informations, consultez la section Validation préalable des AWS CloudFormation modèles par Git avec cfn-lint. Une fois que vous avez effectué votre linting initial et que vous avez résolu tous les problèmes que cfn-lint aurait pu soulever, vous pouvez tester vos modèles en créant des piles par programmation TaskCat dans les régions de votre choix. AWS TaskCatgénère également un rapport avec des notes de réussite ou d'échec pour chaque région que vous avez choisie.

Pour une step-by-step présentation pratique de la façon d'utiliser les deux outils pour raccourcir la boucle de rétroaction, suivez le laboratoire de peluchage et de test de l'AWS CloudFormation atelier.

Organisation des piles par cycle de vie et propriétaire

Utilisez le cycle de vie et la propriété de vos AWS ressources pour vous aider à décider quelles ressources doivent figurer dans chaque pile. Au départ, une pile peut suffire à contenir toutes vos ressources. Toutefois, à mesure que votre pile s'agrandit et se diversifie, sa gestion peut devenir longue et compliquée. En regroupant les ressources par cycle de vie et par propriétaire, les utilisateurs peuvent apporter des modifications à leur ensemble de ressources avec leurs propres processus et leur planification sans affecter les autres ressources.

Par exemple, imaginez une équipe de développeurs et d'ingénieurs qui possèdent un site web hébergé dans des instances Auto Scaling derrière un équilibreur de charge. Comme le site web a son propre cycle de vie et qu'il est géré par l'équipe web, vous pouvez créer une pile pour le site web et ses ressources. Imaginez maintenant que le site web utilise également des bases de données principales, qui se trouvent dans une pile distincte où elles sont gérées par les administrateurs de base de données qui en sont également les propriétaires. Chaque fois que les membres de l'équipe web ou de l'équipe de base de données doivent mettre à jour leurs ressources, ils peuvent le faire sans affecter la pile de l'autre équipe. Si toutes les ressources étaient dans une seule pile, la coordination et la communication des mises à jour pourraient être difficiles.

Pour plus d'informations sur l'organisation de vos piles, vous pouvez utiliser deux structures communes : une architecture multicouche et une architecture orientée services (SOA).

Une architecture multicouche organise les piles dans plusieurs couches horizontales qui se chevauchent et où chaque couche dépend de la couche sous-jacente. Vous pouvez avoir une ou plusieurs piles dans chaque couche. Toutefois, les ressources AWS des piles de chaque couche doivent avoir des cycles de vie et un propriétaire similaires.

Avec une architecture orientée services, vous pouvez organiser les problématiques stratégiques d'une entreprise en portions gérables. Chacune de ces portions est un service dont l'objectif est clairement défini et qui représente une unité autonome de fonctionnalités. Vous pouvez mapper ces services avec des piles, où chaque pile a son propre cycle de vie et ses propriétaires. Ces services (piles) peuvent être reliés pour qu'ils puissent interagir les uns avec les autres.

Utilisation de références entre piles pour exporter des ressources partagées

Lorsque vous organisez vos AWS ressources en fonction du cycle de vie et de la propriété, vous souhaiterez peut-être créer une pile qui utilise des ressources se trouvant dans une autre pile. Vous pouvez coder en dur des valeurs ou utiliser des paramètres d'entrée pour transmettre les noms et les ID de ressources. Toutefois, ces méthodes peuvent rendre difficile la réutilisation de modèles ou accroître les traitements nécessaires à l'exécution d'une pile. Utilisez plutôt des références entre piles pour exporter les ressources d'une pile et ainsi les mettre à la disposition d'autres piles. Les piles peuvent utiliser les ressources exportées en les appelant à l'aide de la fonction Fn::ImportValue.

Par exemple, si vous disposez d'une pile de réseau constituée d'un VPC, d'un groupe de sécurité et d'un sous-réseau, et que vous souhaitez que toutes les applications web publiques utilisent ces ressources, vous devez exporter ces dernières. Toutes les piles dotées d'applications web publiques pourront ainsi les utiliser. Pour plus d’informations, consultez Procédure pas à pas : création de références à des sorties de ressources dans une autre pile AWS CloudFormation.

Vérification des quotas pour tous les types de ressource

Avant de lancer une pile, assurez-vous de pouvoir créer toutes les ressources que vous souhaitez sans atteindre les limites de votre AWS compte. Si vous atteignez une limite, vous ne CloudFormation créerez pas votre pile avec succès tant que vous n'aurez pas augmenté votre quota ou supprimé des ressources supplémentaires. Chaque service peut imposer des limites différentes que vous devez connaître avant de lancer une pile. Par exemple, par défaut, vous ne pouvez lancer que 2 000 CloudFormation piles par région dans votre Compte AWS. Pour plus d'informations sur les limites et sur l'augmentation des limites par défaut, consultez service quotas AWS dans Références générales AWS.

Réutilisation de modèles pour répliquer des piles dans plusieurs environnements

Une fois que les piles et les ressources sont configurées, vous pouvez réutiliser vos modèles afin de répliquer votre infrastructure dans plusieurs environnements. Par exemple, vous pouvez créer des environnements de développement, de test et de production afin de pouvoir tester les modifications avant de les migrer en production. Pour que les modèles soient réutilisables, recourez aux sections Parameters, Mappings et Conditions afin de personnaliser les piles lorsque vous les créez. Par exemple, pour vos environnements de développement, vous pouvez spécifier un type d'instance qui coûte moins cher que votre environnement de production, mais où toutes les autres configurations et tous les autres paramètres restent les mêmes. Pour plus d'informations sur les paramètres, les mappages et les conditions, consultez Anatomie du modèle.

Utiliser des modules pour réutiliser les configurations de ressources

A mesure que votre infrastructure s'agrandit, des tendances peuvent émerger où vous déclarez les mêmes composants dans chacun de vos modèles. Les modules vous permettent d'empaqueter des configurations de ressources pour les inclure dans les modèles de pile, de manière transparente, gérable et reproductible. Les modules peuvent encapsuler les configurations de service courantes et les bonnes pratiques en tant que blocs de création modulaires et personnalisables à inclure dans vos modèles de pile.

Ces blocs de construction peuvent être destinés à une seule ressource, telle que les bonnes pratiques pour définir une instance Amazon Elastic Compute Cloud (Amazon EC2), ou à plusieurs ressources pour définir des modèles communs d'architecture d'application. Ces éléments de base peuvent être imbriqués dans d'autres modules, afin que vous puissiez regrouper vos meilleures pratiques dans des éléments de base de niveau supérieur. CloudFormation les modules sont disponibles dans le CloudFormation registre, vous pouvez donc les utiliser comme une ressource native. Lorsque vous utilisez un CloudFormation module, le modèle de module est développé dans le modèle de consommation, ce qui vous permet d'accéder aux ressources du module à l'aide d'un Ref ou d'un Fn : : GetAtt. Pour plus d'informations, consultez la section Modules.

Utiliser des AWS types de paramètres spécifiques

Si votre modèle nécessite des entrées pour AWS des valeurs spécifiques existantes, telles que des identifiants Amazon Virtual Private Cloud existants ou un nom de paire de clés Amazon EC2, AWS utilisez des types de paramètres spécifiques. Par exemple, vous pouvez spécifier un paramètre en tant que typeAWS::EC2::KeyPair::KeyName, qui prend le nom d'une paire de clés existante qui se trouve dans votre AWS compte et dans la région où vous créez la pile. AWS CloudFormation peut rapidement valider les valeurs pour des types de paramètres AWS spécifiques avant de créer votre pile. De plus, si vous utilisez la CloudFormation console, elle CloudFormation affiche une liste déroulante de valeurs valides, de sorte que vous n'avez pas à rechercher ou à mémoriser les identifiants VPC ou les noms de paires de clés corrects. Pour plus d’informations, consultez Paramètres.

Utilisation de contraintes de paramètre

Avec les contraintes, vous pouvez décrire les valeurs d'entrée autorisées afin CloudFormation de détecter toute valeur non valide avant de créer une pile. Vous pouvez définir des contraintes comme une longueur minimale, une longueur maximale et des modèles autorisés. Par exemple, vous pouvez définir des contraintes au niveau de la valeur du nom d'utilisateur d'une base de données, de sorte qu'elle contienne au moins huit caractères alphanumériques. Pour plus d’informations, consultez Paramètres.

Utiliser des pseudoparamètres pour promouvoir la portabilité

Vous pouvez utiliser des pseudo-paramètres dans vos modèles comme arguments pour des fonctions intrinsèques, telles que Ref et Fn::Sub. Les pseudo-paramètres sont des paramètres prédéfinis par CloudFormation. Vous ne les déclarez pas dans le modèle. L'utilisation de pseudo-paramètres dans les fonctions intrinsèques augmente la portabilité de vos modèles de pile entre les régions et les comptes.

Par exemple, imaginez que vous souhaitiez créer un modèle dans lequel, pour une propriété de ressource donnée, vous devez spécifier l'Amazon Resource Name (ARN) d'une autre ressource existante. Dans ce cas, la ressource existante est une ressource AWS Systems Manager Parameter Store avec l'ARN suivant : arn:aws:ssm:us-east-1:111122223333:parameter/MySampleParameter. Vous devrez adapter le format ARN à votre AWS partition cible, à votre région et à votre identifiant de compte. Au lieu de coder ces valeurs en dur, vous pouvez utiliser des pseudo-paramètres AWS::Partition, AWS::Region et AWS::AccountId pour rendre votre modèle plus portable. Dans ce cas, l'exemple suivant montre comment concaténer des éléments d'un ARN avec :. CloudFormation !Sub 'arn:${AWS::Partition}:ssm:${AWS::Region}:${AWS::AccountId}:parameter/MySampleParameter

Pour un autre exemple, supposons que vous souhaitez utiliser Procédure pas à pas : création de références à des sorties de ressources dans une autre pile AWS CloudFormation pour faire référence aux sorties de ressources d'une autre CloudFormation pile. Dans cet exemple, supposons que vous avez créé un sous-réseau pour votre VPC, puis que vous avez exporté son identifiant pour l'utiliser avec d'autres piles du même compte et de la même région. Dans une autre pile, vous faites référence à la valeur exportée de l'ID de sous-réseau lorsque vous décrivez une instance Amazon EC2.

Les exportations de pile doivent être uniques par compte et par région. Dans ce cas, vous pouvez donc utiliser le pseudo paramètre AWS::StackName pour créer un préfixe pour votre exportation. Comme les noms de pile doivent également être uniques par compte et par région, l'utilisation de ce pseudo paramètre comme préfixe augmente la possibilité d'avoir un nom d'exportation unique, tout en promouvant une approche réutilisable dans les piles à partir desquelles vous exportez des valeurs. Vous pouvez également utiliser un préfixe de votre choix.

Pour un exemple détaillé de l’utilisation du champ de sortie Export et de la fonction intrinsèque Fn::ImportValue, consultez Procédure pas à pas : création de références à des sorties de ressources dans une autre pile AWS CloudFormation.

Utilisation d'AWS::CloudFormation::Init pour déployer des applications dans des instances Amazon Amazon EC2

Lorsque vous lancez des piles, vous pouvez installer et configurer des applications logicielles sur des instances Amazon EC2 via le script d'assistant cfn-init et la ressource AWS::CloudFormation::Init. Avec AWS::CloudFormation::Init, vous pouvez décrire les configurations de votre choix au lieu de créer des scripts pour chaque étape de la procédure. Vous pouvez également mettre à jour les configurations sans avoir à recréer les instances. Et en cas de problème avec votre configuration, CloudFormation génère des journaux que vous pouvez utiliser pour étudier les problèmes.

Dans le modèle, spécifiez les états de l'installation et de la configuration dans la ressource AWS::CloudFormation::Init. Pour voir une procédure qui décrit comment utiliser cfn-init et AWS::CloudFormation::Init, veuillez consulter la rubrique Déploiement d'applications sur Amazon EC2 avec AWS CloudFormation.

Utilisation des derniers scripts d'assistant

Les scripts d'assistant sont régulièrement mis à jour. Veillez à inclure la commande suivante dans la propriété UserData de votre modèle avant d'appeler les scripts d'assistant pour vous assurer que vos instances lancées obtiennent les derniers scripts d'assistant :

yum install -y aws-cfn-bootstrap

Pour plus d'informations sur les derniers scripts d'assistant, consultez CloudFormation référence des scripts d'assistance.

Validation des modèles avant leur utilisation

Avant d'utiliser un modèle pour créer ou mettre à jour une pile, vous pouvez l'utiliser CloudFormation pour le valider. La validation d'un modèle peut vous aider à détecter les erreurs de syntaxe et certaines erreurs sémantiques, telles que les dépendances circulaires, avant de CloudFormation créer des ressources. Si vous utilisez la CloudFormation console, celle-ci valide automatiquement le modèle une fois que vous avez spécifié les paramètres d'entrée. Pour l' CloudFormation API AWS CLI or, utilisez la aws cloudformation validate-templatecommande ou ValidateTemplatel'opération API.

Lors de la validation, CloudFormation vérifiez d'abord si le modèle est un JSON valide. Si ce n'est pas le cas, CloudFormation vérifie si le modèle est YAML valide. Si les deux vérifications échouent, CloudFormation renvoie une erreur de validation du modèle.

Valider les modèles pour la conformité des politiques de l'organisation

Vous pouvez également valider la conformité de votre modèle aux directives de la politique de l'organisation. AWS CloudFormation Guard (cfn-guard) est un outil d'interface de ligne de commande (CLI) open source qui fournit un policy-as-code langage permettant de définir des règles permettant de vérifier les configurations de ressources requises et interdites. Il vous permet ensuite de valider vos modèles par rapport à ces règles. Par exemple, les administrateurs peuvent créer des règles pour garantir que les utilisateurs créent toujours des compartiments Amazon S3 chiffrés.

Vous pouvez utiliser cfn-guard soit localement lors de la modification des modèles, soit automatiquement dans le cadre d'un pipeline IC/DC pour arrêter le déploiement de ressources non conformes.

En outre, cfn-guard inclut une fonctionnalité qui vous permet d'extraire des règles à partir de CloudFormation modèles conformes existants. rulegen

Pour plus d'informations, consultez le référentiel cfn-guard sur. GitHub

Gérez toutes les ressources de la pile via AWS CloudFormation

Après avoir lancé une pile, utilisez la CloudFormation console, l'API ou la AWS CLI pour mettre à jour les ressources de votre pile. N'apportez pas de modifications pour empiler des ressources à l'extérieur de CloudFormation. Cette approche peut générer un décalage entre le modèle de votre pile et l'état actuel de ses ressources, ce qui peut entraîner des erreurs si vous mettez à jour ou supprimez la pile. Pour plus d’informations, consultez Procédure de mise à jour d'une pile.

Création de jeux de modification avant la mise à jour des piles

Les ensembles de modifications vous permettent de voir comment les modifications proposées à une pile peuvent avoir un impact sur vos ressources courantes avant de les implémenter. CloudFormation n'apporte aucune modification à votre pile tant que vous n'avez pas exécuté l'ensemble de modifications, ce qui vous permet de décider de poursuivre les modifications proposées ou de créer un autre ensemble de modifications.

Utilisez les jeux de modification pour vérifier l'impact possible des modifications sur les ressources exécutées, notamment les ressources critiques. Par exemple, si vous modifiez le nom d'une instance de base de données Amazon RDS, CloudFormation vous créez une nouvelle base de données et supprimez l'ancienne ; vous perdrez les données de l'ancienne base de données à moins que vous ne les ayez déjà sauvegardées. Si vous générez un jeu de modification, vous verrez que la modification remplacera la base de données. Vous pouvez donc vous préparer à la mise à jour la pile en conséquence. Pour plus d’informations, consultez Mise à jour des piles à l'aide de jeux de modifications.

Utilisation des politiques de pile

Les politiques de pile contribuent à protéger les ressources critiques d'une pile contre toute mise à jour accidentelle qui pourrait entraîner l'interruption des ressources, voire leur remplacement. Une politique de pile est un document JSON qui décrit les actions de mise à jour qui peuvent être effectuées au niveau des ressources désignées. Spécifiez une politique de pile chaque fois que vous créez une pile qui contient des ressources critiques.

Pendant une mise à jour de la pile, vous devez spécifier explicitement les ressources protégées que vous souhaitez mettre à jour. Dans le cas contraire, aucune modification ne sera apportée aux ressources protégées. Pour plus d’informations, consultez Empêcher les mises à jour des ressources de la pile.

Utilisation des révisions de code et des contrôles de révision pour gérer les modèles

Vos modèles de pile décrivent la configuration de vos AWS ressources, telles que les valeurs de leurs propriétés. Pour passer en revue les modifications et pour conserver un historique précis de vos ressources, utilisez les révisions de code et les contrôles de révision. Ces méthodes vous permettent de suivre les modifications apportées entre différentes versions de vos modèles, ce qui peut vous aider à identifier les modifications apportées aux ressources de votre pile. En outre, en conservant un historique, vous pouvez toujours restaurer la pile sur la base d'une certaine version de votre modèle.

Mettez à jour régulièrement vos instances Amazon EC2

Sur toutes vos instances Amazon EC2 Windows et les instances Amazon EC2 Linux créées CloudFormation avec, exécutez régulièrement yum update la commande pour mettre à jour le package RPM. Cela garantit que vous obtenez les derniers correctifs et mises à jour de sécurité.