Gestion de votre infrastructure AWS à l'échelle · 2016-08-02 · Amazon Web Services –...

Gestion de votre infrastructure AWS à l'échelle

Shaun Pearce

Steven Bryen

Février 2015

Amazon Web Services – Gestion de votre infrastructure AWS à l'échelle Février 2015

sur 32

© 2015, Amazon Web Services, Inc. ou ses affiliés. Tous droits réservés.

Mentions légales Ce document est fourni à titre informatif uniquement. Il présente l'offre de produits et les

pratiques actuelles d'AWS à la date de publication de ce document, des informations qui

sont susceptibles d'être modifiées sans avis préalable. Il incombe aux clients de procéder

à leur propre évaluation indépendante des informations contenues dans ce document et

chaque client est responsable de son utilisation des produits ou services AWS, chacun

étant fourni « en l'état », sans garantie d'aucune sorte, qu'elle soit explicite ou implicite. Ce

document ne crée pas de garanties, représentations, engagements contractuels, conditions

ou assurances à l'encontre d'AWS, de ses affiliés, fournisseurs ou donneurs de licence. Les

responsabilités et obligations d'AWS vis-à-vis de ses clients sont régies par les contrats

AWS. Le présent document ne fait partie d'aucun et ne modifie aucun contrat entre AWS

et ses clients.


sur 32

Table des matières

Résumé 4

Introduction 4

Mise en service de nouvelles instances EC2 6

Création de votre propre AMI 7

Gestion des versions d'AMI 10

Configuration dynamique 12

Script de votre propre solution 12

Utilisation des outils de gestion de la configuration 16

AWS Elastic Beanstalk 22

AWS OpsWorks 23

AWS CloudFormation 24

Données utilisateur 24

cfn-init 25

Utilisation des services ensemble 26

Gestion de l'état de l'application et des instances 27

Données d'application structurées 28

Amazon RDS 28

Amazon DynamoDB 29

Données d'application non structurées 29

Données de session utilisateur 29

Amazon ElastiCache 29

Métriques du système 30

Amazon CloudWatch 30

Gestion des journaux 31

Amazon CloudWatch Logs 31

Conclusion 32

Suggestions de lecture 32


sur 32

Résumé Amazon Web Services (AWS) permet aux organisations de déployer des infrastructures

d'applications à grande échelle sur plusieurs sites géographiques. Lors du déploiement de

ces volumineuses applications basées sur le cloud, il est important de s'assurer que le coût

et la complexité de gestion de ces systèmes n'augmentent pas en proportion directe avec

leur taille.

Ce livre blanc est destiné aux clients existants et à venir, notamment les architectes,

les développeurs et les administrateurs système, désireux de déployer et de gérer leur

infrastructure de manière évolutive et prévisible sur AWS.

Dans ce livre blanc, nous décrivons les outils et les techniques de mise en service des

nouvelles instances, de configuration des instances en fonction de vos exigences et de

déploiement de votre code d'application. Nous présentons également les stratégies qui

permettent de maintenir vos instances sans état, afin que l'architecture obtenue soit plus

évolutive et plus tolérante aux pannes. Grâce à ces techniques, votre service peut passer

d'une seule instance à plusieurs milliers, tout en conservant un ensemble cohérent de

processus et d'outils pour les gérer.

Dans le cadre de ce livre blanc, nous supposons que vous maîtrisez l'élaboration de scripts

basiques et les services essentiels tels qu'Amazon Elastic Compute Cloud (Amazon EC2).

Introduction Lors de la conception et de l'implémentation d'applications volumineuses basées sur le

cloud, il est important de tenir compte de la façon dont votre infrastructure sera gérée, de

manière à limiter le coût et la complexité de l'administration de ce système. Lorsque vous

utilisez Amazon EC2 pour la première fois, la gestion de vos instances EC2 est aussi facile

que celle des serveurs virtualisés conventionnels qui s'exécutent dans votre centre de données.

Vous pouvez créer une instance, vous connecter, configurer le système d'exploitation, installer

n'importe quel package supplémentaire et installer votre code d'application. Vous pouvez

assurer la maintenance de l'instance en installant des patchs de sécurité, en réalisant de

nouveaux déploiements de votre code et en modifiant la configuration en fonction des besoins.

En dépit de la surcharge de fonctionnement, vous pouvez continuer de gérer vos instances

ainsi pendant un bon moment.

Malgré tout, vos instances vont inévitablement commencer à diverger de leur spécification

initiale, ce qui peut provoquer des incohérences avec les autres instances du même

environnement. Cet écart par rapport à une base connue peut devenir un énorme obstacle

à surmonter lorsqu'il s'agit de gérer d'importantes flottes d'instances sur plusieurs environnements.

Cette difficulté risque, au final, de créer des problèmes de service car vos environnements

deviendront moins prévisibles et plus délicats à gérer.


sur 32

La plateforme AWS met à votre disposition tout un ensemble d'outils permettant de gérer ce

défi de manière différente. En utilisant Amazon EC2 et les services associés, vous pouvez

préciser et gérer l'état final voulu pour votre infrastructure, indépendamment des instances

EC2 et des autres composants d'exécution.

Par exemple, si vous adoptez une approche traditionnelle, vous modifiez la configuration

d'un serveur Apache s'exécutant sur l'ensemble de vos serveurs web en vous connectant

à chaque serveur un par un, pour effectuer manuellement les modifications. Grâce à la

plateforme AWS, l'approche est différente : il vous suffit de modifier la spécification sous-

jacente de vos serveurs web, puis de lancer les nouvelles instances EC2 pour remplacer

les anciennes. Vous vous assurez ainsi que chaque instance reste identique et l'effort

d'implémentation de la modification est moindre, tout comme le risque d'introduction d'erreur.

Lorsque vous commencez à considérer votre infrastructure comme une entité définie

indépendamment des instances EC2 exécutées et des autres composants de vos

environnements, vous pouvez davantage tirer parti des environnements de cloud dynamiques :

Infrastructure définie par logiciel – En définissant votre infrastructure à l'aide d'un

ensemble d'artefacts logiciels, vous pouvez profiter des nombreux outils et techniques

utilisés lors du développement des composants logiciels. Ainsi, vous pouvez notamment

gérer l'évolution de votre infrastructure dans un système de contrôle de versions, utiliser

les processus d'intégration continue (CI) pour tester en permanence et valider les

modifications apportées à l'infrastructure avant de les déployer en production.

Auto Scaling et réparation automatique – Si vous mettez vos nouvelles instances

en service à partir d'une spécification cohérente, vous pouvez utiliser les groupes

Auto Scaling pour gérer le nombre d'instances dans une flotte EC2. Par exemple, vous

pouvez définir une condition pour ajouter au groupe Auto Scaling de nouvelles instances

EC2 par incréments, quand l'utilisation moyenne de votre flotte EC2 est élevée. Vous

pouvez également utiliser Auto Scaling pour détecter les instances EC2 dégradées et

les applications défectueuses, ainsi que pour remplacer les instances sans votre

intervention.

Mises en service d'environnements rapides – Vous pouvez rapidement et facilement

mettre en service des environnements homogènes, offrant de nouvelles voies d'utilisation

à vos équipes. Vous pouvez, par exemple, mettre en place un nouvel environnement

permettant aux testeurs de valider une nouvelle version de votre application dans leurs

propres environnements de test, isolés des autres modifications.

Réduction des coûts – Etant donné que vous pouvez désormais mettre rapidement en

service les environnements, vous pouvez tout aussi facilement les supprimer lorsqu'ils

ne vous sont plus utiles. Vous diminuez ainsi vos coûts en ne payant que pour les

ressources dont vous avez besoin.


sur 32

Blue-green deployments (déploiements continus) – Vous pouvez développer les nouvelles versions de votre application en mettant en service de nouvelles instances (contenant une nouvelle version du code) parallèlement à votre infrastructure existante. Vous pouvez faire basculer le trafic d'un environnement à l'autre dans le cadre d'une approche appelée « blue-green deployment ». Cette alternative aux stratégies de déploiement traditionnelles présente de nombreux avantages, notamment la capacité de retirer rapidement et facilement un déploiement en cas de problème.

Pour profiter de ces atouts, votre infrastructure doit être dotée des fonctionnalités suivantes :

1. Les composants de la nouvelle infrastructure sont automatiquement mis en service sur la base d'une référence connue, contrôlée par la version, de manière reproductible et prévisible.

2. Toutes les instances sont sans état afin de pouvoir être retirées et détruites à tout moment, sans risquer de perdre l'état de l'application ou les données du système.

La figure suivante illustre le processus global :

Figure 1 : Cycle de vie et gestion de l'état de l'instance

Les sections suivantes décrivent les outils et techniques que vous pouvez utiliser pour élaborer

un système doté de ces fonctionnalités. En optant pour une architecture au sein de laquelle

vos instances peuvent être facilement mises en service et détruites sans perte de données,

vous pouvez radicalement changer le mode de gestion de votre infrastructure. Enfin, vous

pouvez faire évoluer votre infrastructure dans le temps sans augmenter considérablement la

surcharge de fonctionnement.

Mise en service de nouvelles instances EC2 Un certain nombre d'événements externes exigent que vous mettiez en service de nouvelles instances dans vos environnements :

la création de nouvelles instances ou la réplication d'environnements existants ;

le remplacement d'une instance défectueuse dans un environnement existant ;

la réponse à un événement de « mise à l'échelle ascendante » visant à ajouter d'autres instances à un groupe Auto Scaling ;

1 2

Instance EC2 Système contrôlé par versions

Stockage durable


sur 32

le déploiement d'une nouvelle version de votre stack logiciel (en utilisant des « blue-green deployments »).

Certains de ces événements sont difficiles, voire impossibles, à prévoir. Il est donc important que le processus de création de nouvelles instances dans votre environnement soit totalement automatisé, reproductible et cohérent.

Le processus de création et de mise en service automatiques des nouvelles instances

s'appelle action d'amorçage (bootstrap). Vos instances Amazon EC2 comportent plusieurs

approches des actions d'amorçage. Les deux méthodes les plus utilisées consistent à créer

votre propre Amazon Machine Image (AMI) ou à utiliser une configuration dynamique. Ces

deux approches sont décrites dans les sections suivantes.

Création de votre propre AMI Une Amazon Machine Image (AMI) est un template qui fournit toutes les informations requises pour lancer une instance Amazon EC2. Elle contient, au minimum, le système d'exploitation de base, mais elle peut aussi inclure une configuration et un logiciel supplémentaires. Vous pouvez lancer plusieurs instances d'une AMI, ainsi que différents types d'instances à partir d'une seule AMI.

Vous disposez de plusieurs options de lancement d'une nouvelle instance EC2 :

Sélectionnez une AMI fournie par AWS.

Sélectionnez une AMI fournie par la communauté.

Sélectionnez une AMI contenant le logiciel préconfiguré à partir d'AWS Marketplace1.

Créez une AMI personnalisée.

Si vous lancez une instance à partir d'une AMI de base contenant uniquement le système d'exploitation, vous pouvez personnaliser davantage l'instance avec d'autres configurations et logiciels après son lancement. Si vous créez une AMI personnalisée, vous pouvez lancer une instance qui contient déjà votre stack logiciel complet et éviter ainsi la nécessité de disposer d'une configuration d'exécution. Toutefois, avant de décider de créer une AMI personnalisée, vous devez en comprendre les avantages et les inconvénients.

Avantages des AMI personnalisées

Vitesse accrue – Toute la configuration est comprise dans l'AMI elle-même, ce qui

augmente nettement la vitesse de lancement des nouvelles instances. Cet avantage

est particulièrement utile en cas d'événements d'Auto Scaling.

Diminution des dépendances externes – Le fait de tout regrouper dans une AMI

signifie que vous ne dépendez nullement de la disponibilité des services externes pour

lancer les nouvelles instances (par exemple, référentiels de package ou de code).

1 https://aws.amazon.com/marketplace


sur 32

Suppression du recours aux scripts de configuration complexes au moment du

lancement – Le fait de préconfigurer votre AMI permet de ne plus être tributaire de la

réussite de l'exécution des scripts de configuration au lancement des événements de

mise à l'échelle et de remplacements d'instances. Le risque de problème opérationnel

provoqué par des scripts erronés diminue ainsi considérablement.

Inconvénients des AMI personnalisées

Perte d'agilité – Le fait de tout regrouper dans une AMI signifie que même les

modifications simples apportées au code et les corrections de défaut nécessitent que

vous produisiez une nouvelle AMI. Le temps nécessaire au développement, au test,

aux améliorations des versions et aux corrections de votre application augmente donc

nettement.

Complexité – La gestion du processus d'élaboration de l'AMI peut s'avérer complexe.

Vous avez besoin d'un processus permettant de créer des AMI cohérentes et reproductibles,

dans lesquelles les modifications apportées entre les révisions sont identifiables et

contrôlables.

Exigences en matière de configuration d'exécution – Vous risquez d'avoir besoin

de personnaliser davantage vos AMI en fonction des informations d'exécution encore

inconnues au moment de la création de l'AMI. Par exemple, la chaîne de connexion de

la base de données requise par votre application peut varier en fonction de l'emplacement

d'utilisation de l'AMI.

Face à ces avantages et inconvénients, nous vous recommandons d'adopter une approche

hybride : élaborez des composants statiques de stack dans les AMI et configurez les aspects

dynamiques qui changent régulièrement (comme le code d'application) au moment de

l'exécution.

Tenez compte des facteurs suivants pour vous aider à choisir la configuration à inclure

dans une AMI personnalisée, ainsi que les éléments figurant dans les scripts dynamiques

d'exécution :

Fréquence des déploiements – A quelle fréquence êtes-vous susceptible de déployer

des améliorations dans votre système et à quel niveau de votre stack effectuerez-vous

les déploiements ? Vous pouvez, par exemple, déployer chaque jour les modifications

dans votre application, tout en mettant votre version JVM à niveau beaucoup moins

fréquemment.

Diminution des dépendances externes – Si la configuration de votre système

dépend d'autres systèmes externes, vous pouvez décider de réaliser ces étapes de

configuration dans le cadre du développement d'une AMI plutôt qu'au moment du

lancement d'une instance.

Exigences pour une mise à l'échelle rapide – Votre application utilisera-t-elle les

groupes Auto Scaling pour s'adapter aux variations de charge ? Le cas échéant,

à quelle vitesse la charge sur l'application augmentera-t-elle ? Cet élément décidera

de la vitesse à laquelle vous devrez allouer de nouvelles instances à votre flotte EC2.


sur 32

Une fois votre stack d'applications évalué en fonction des critères précédents, vous pouvez

choisir les éléments de votre stack à inclure dans une AMI personnalisée et déterminer ceux

qui seront configurés dynamiquement au moment du lancement.

La figure suivante illustre un stack d'application Java web typique, ainsi que la façon dont il

peut être géré selon les AMI et les scripts dynamiques.

Figure 2 : Modèles d'AMI de base, de création et complètes

Dans le modèle AMI de base, seule l'image du système d'exploitation est conservée

sous forme d'AMI. L'AMI peut être constituée d'une image gérée par AWS ou une AMI

que vous gérez qui contient votre propre image de système d'exploitation.

Dans le modèle d'AMI de création, les éléments d'un stack qui changent peu

souvent (par exemple, les composants tels que la machine virtuelle Java et le

serveur d'applications) sont élaborés dans l'AMI.

Dans le modèle d'AMI complète, tous les éléments du stack sont élaborés dans

l'AMI. Ce modèle est utile si votre application change peu souvent ou si elle obéit à

des exigences d'auto-scaling rapide (ce qui signifie que l'installation dynamique de

l'application est infaisable). Malgré tout, même si vous élaborez votre application

dans l'AMI, il peut toujours être avantageux de configurer dynamiquement

l'application au moment de l'exécution de manière à accroître la flexibilité de l'AMI.

Cela vous permet, par exemple, d'utiliser vos AMI dans plusieurs environnements.


sur 32

Gestion des versions d'AMI Bon nombre de personnes commencent par configurer manuellement leurs AMI en

faisant appel à un processus semblable à ce qui suit :

1. Lancez la toute dernière version de l'AMI.

2. Connectez-vous à l'instance et reconfigurez-la manuellement (en réalisant, par

exemple, des mises à jour des packages ou en installant de nouvelles

applications).

3. Créez une nouvelle AMI basée sur l'instance d'exécution.

Même si ce processus manuel est suffisant pour les applications simples, il est

difficile de gérer des environnements plus complexes au sein desquels les mises à

jour des AMI sont régulièrement requises. Il est essentiel de disposer d'un processus

homogène et reproductible pour créer vos AMI. Il est tout aussi important d'être en

mesure de contrôler ce qui a changé d'une version à l'autre de vos AMI.

Pour cela, vous pouvez, par exemple, gérer la personnalisation d'une AMI de base à l'aide

de scripts automatisés. Vous pouvez développer vos propres scripts ou utiliser un outil de

gestion de la configuration. Pour plus d'informations sur les outils de gestion de la configuration,

consultez la section Utilisation des outils de gestion de la configuration de ce livre blanc.

L'utilisation de scripts automatisés offre de nombreux avantages par rapport à la

méthode manuelle. L'automatisation accélère nettement le processus de création de

l'AMI. En outre, vous pouvez utiliser le contrôle de version pour vos fichiers de

script/configuration, ce qui permet de bénéficier d'un processus reproductible où les

changements d'une version d'AMI à l'autre sont transparents et contrôlables.

Ce processus automatisé est semblable au processus manuel :

1. Lancez la toute dernière version de l'AMI.

2. Exécutez la configuration automatisée à l'aide de l'outil de votre choix.

3. Créez une nouvelle image d'AMI basée sur l'instance d'exécution.

Vous pouvez utiliser un outil tiers tel que Packer2

pour faciliter l'automatisation du processus.

Toutefois, de nombreuses personnes considèrent cette approche trop fastidieuse dans un

environnement renfermant plusieurs versions d'AMI fréquentes, s'exécutant sur des

environnements multiples.

Si vous utilisez le système d'exploitation Linux, vous pouvez diminuer le temps nécessaire

pour créer une nouvelle AMI en personnalisant un volume Amazon Elastic Block Store

(Amazon EBS) plutôt qu'une instance d'exécution. Un volume Amazon EBS est un dispositif

de stockage durable au niveau bloc que vous pouvez attacher à une instance Amazon EC2

unique. Vous pouvez créer un volume Amazon EBS à partir d'un instantané d'AMI de base

et personnaliser ce volume avant de le stocker sous forme de nouvelle AMI. Vous remplacez

ainsi le temps nécessaire pour initialiser une instance EC2 par celui, bien plus court, requis

pour créer et attacher un volume EBS.

2 https://packer.io


sur 32

Par ailleurs, cette approche s'appuie sur la nature incrémentielle des instantanés Amazon

EBS. Un instantané EBS est une sauvegarde ponctuelle d'un volume EBS stocké dans

Amazon S3. Les instantanés sont des sauvegardes incrémentielles, ce qui signifie que seuls

les blocs du périphérique qui ont changé depuis l'instantané le plus récent sont enregistrés.

Par exemple, si une mise à jour de configuration change uniquement 100 Mo de blocs sur

un volume EBS de 8 Go, seuls 100 Mo seront stockés sur Amazon S3.

Pour y parvenir, vous avez besoin d'une instance EC2 longue, chargée d'attacher un nouveau

volume EBS en fonction de la toute dernière version d'AMI, en exécutant les scripts

nécessaires pour personnaliser le volume, en créant un instantané du volume et en

enregistrant l'instantané en tant que nouvelle version de votre AMI. Par exemple, Netflix

utilise cette technique pour son outil Open source appelé aminator.3

La figure suivante illustre ce processus.

Figure 3 : Utilisation des instantanés EBS pour accélérer les déploiements

1. Créez le volume à partir du tout dernier instantané d'AMI.

2. Attachez le volume à l'instance chargée de l'élaboration des nouvelles AMI.

3. Exécutez les scripts d'allocation automatisée pour mettre à jour la configuration de l'AMI.

4. Effectuez un instantané du volume.

5. Enregistrez l'instantané en tant que nouvelle version de l'AMI.

3 https://github.com/Netflix/aminator


sur 32

Configuration dynamique Maintenant que vous avez déterminé les éléments à inclure dans votre AMI et ce qui doit être configuré dynamiquement au moment de l'exécution, vous devez décider comment achever la configuration dynamique et le processus d'action d'amorçage. Il existe de nombreux outils et techniques que vous pouvez utiliser pour configurer vos instances : ils vont des simples scripts aux outils complexes et centralisés de gestion de la configuration.

Script de votre propre solution Selon le niveau de pré-configuration inclus dans votre AMI, vous pouvez avoir besoin d'un seul script ou d'un ensemble de scripts de façon à configurer simplement et élégamment les éléments finaux de votre stack d'applications.

Données utilisateur et cloud-init

Lorsque vous lancez une nouvelle instance EC2 en utilisant AWS Management Console ou l'API, vous pouvez communiquer les données utilisateur à l'instance. Vous pouvez récupérer les données utilisateur dans l'instance via le service de metadonnées EC2 et les utiliser afin d'exécuter des tâches automatisées pour configurer les instances lors de leur premier lancement.

Lorsqu'une instance Linux est lancée, les instructions d'initialisation communiquées à l'instance par l'intermédiaire des données utilisateur sont exécutées à l'aide d'une technologie appelée cloud-init. Le package cloud-init est une application Open source développée par

Canonical. Il est inclus dans de nombreuses AMI basées sur Linux (pour savoir si votre distribution est compatible avec cloud-init, consultez la documentation spécifique à la

distribution). Amazon Linux, une distribution Linux créée et gérée par AWS, contient une

version personnalisée de cloud-init.

Vous pouvez transmettre deux types de données utilisateur : les directives de scripts shell ou cloud-init, vers cloud-init s'exécutant sur votre instance EC2. Par exemple, le

script shell suivant peut être transmis à une instance afin de mettre à jour tous les packages installés et de configurer l'instance sous forme de serveur web PHP :

Les données utilisateur suivantes parviennent au même résultat, en utilisant toutefois un

ensemble de directives cloud-init :

#!/bin/sh

yum update -y

yum -y install httpd php php-mysql

chkconfig httpd on

/etc/init.d/httpd start

#cloud-config


sur 32

Les AMI Windows AWS contiennent un autre service, EC2Config, qui est installé par AWS.

Le service EC2Config effectue des tâches sur l'instance comme, par exemple, l'activation de

Windows, la configuration du mot de passe Administrateur, l'écriture sur la console AWS et

l'exécution d'un fichier sysprep en un clic depuis l'application. Si vous lancez une instance

Windows, le service EC2Config peut également exécuter les scripts transmis à l'instance par

l'intermédiaire des données utilisateur. Les données peuvent être disponibles sous la forme

de commandes que vous exécutez à l'invite de commande cmd.exe ou Windows

PowerShell.

Cette approche est idéale pour les cas d'utilisation simples. Toutefois, lorsque le nombre de

rôles d'instance (web, base de données, etc.) augmente, tout comme le nombre d'environnements

que vous devez gérer, vos scripts risquent de devenir volumineux et difficiles à exploiter.

Par ailleurs, les données utilisateur sont limitées à 16 Ko. Par conséquent, en présence d'un

nombre de tâches de configuration et de logiques associées important, nous vous recommandons

d'utiliser les données utilisateur pour télécharger d'autres scripts depuis Amazon S3 pour

pouvoir alors les exécuter.

Exploitation des metadonnées EC2

Lorsque vous configurez une nouvelle instance, vous devez généralement comprendre

le contexte dans lequel l'instance est lancée. Par exemple, vous pouvez avoir besoin de

connaître le nom d'hôte de l'instance, ou bien la région ou la zone de disponibilité dans

laquelle l'instance a été lancée. Vous pouvez émettre une requête auprès du service de

metadonnées EC2 afin d'obtenir des informations sur le contexte d'une instance, ainsi que

pour récupérer les données utilisateur. Pour accéder aux metadonnées de l'instance depuis

une instance en cours d'exécution, vous pouvez émettre une demande standard HTTP GET

à l'aide d'outils tels que cURL ou la commande GET. Par exemple, pour récupérer le nom

d'hôte de l'instance, vous pouvez émettre une demande HTTP GET à l'URL suivante :

repo_update: true

repo_upgrade: all

packages:

- httpd

- php

- php-mysql

runcmd:

- service httpd start

- chkconfig httpd on

http://169.254.169.254/latest/meta-data/hostname

http://169.254.169.254/latest/meta-data/hostname


sur 32

environnement = production

rôle = web

Balisage des ressources

Pour faciliter la gestion de vos ressources EC2, vous pouvez attribuer vos propres

metadonnées à chaque instance, en plus des metadonnées EC2 utilisées pour définir les

noms d'hôte, les zones de disponibilité et les autres ressources. Pour cela, utilisez les

balises. Chaque balise est constituée d'une clé et d'une valeur, que vous définissez lorsque

l'instance est lancée.

Vous pouvez utiliser les balises EC2 pour affiner la définition du contexte de l'instance lancée.

Vous pouvez, par exemple, baliser vos instances pour différents environnements et rôles,

comme l'indique la figure suivante.

Clé

i-1bbb2637

i-f2871ade

Figure 4 : Exemple d'utilisation des balises EC2

Tant que votre instance EC2 dispose d'un accès à Internet, ces balises peuvent être

récupérées à l'aide de l'interface ligne de commande (CLI) AWS dans les scripts d'action

d'amorçage, afin de configurer vos instances en fonction de leur rôle et de l'environnement

dans lequel elles sont lancées.

Récapitulation

La figure suivante représente un processus d'action d'amorçage typique utilisant les

données utilisateur et un ensemble de scripts de configuration hébergé sur Amazon S3.

Valeur

environnement = dév.

rôle = app.


sur 32

Figure 5 : Exemple de flux de travail intégral

Dans cet exemple, les données utilisateur sont utilisées comme mécanisme simplifié de téléchargement d'un script de configuration de base depuis Amazon S3. Le script est chargé de configurer le système par rapport à une référence sur toutes les instances, quels que soient le rôle et l'environnement (par exemple, le script peut installer les agents de surveillance et s'assurer que le système d'exploitation est corrigé).

Ce script de configuration de base utilise la CLI pour récupérer les balises des instances. En fonction de la valeur de la balise du « rôle », le script télécharge un script de cache complémentaire, chargé de la configuration supplémentaire requise pour que l'instance joue son rôle spécifique (par exemple, installer Apache sur un serveur web). Enfin, le script utilise la balise « environnement » des instances pour télécharger un script de cache de l'environnement permettant d'effectuer la configuration finale de l'environnement dans lequel l'instance réside (par exemple, en configurant les niveaux de consignation sur DEBUG dans l'environnement de développement).

Demande de

lancement de

l'instance

Réception des données

utilisateur et exposition

via le service de

metadonnées

describe-tags

describe-tags

Données utilisateur

Service de metadonnées EC2

Configuration

de base

Scripts du cache du rôledu serveur

Scripts du cache de l'environnement

Action d'amorçage terminée

API EC2 Instance Amazon EC2 Compartiment Amazon S3

Récupération et traitement

des données utilisateur

Téléchargement et

exécution de la config.

de base

Récupération du rôle du serveur sur l'API EC2,

téléchargement et exécution

du script approprié

Récupération de l'environnement du serveur

sur l'API EC2, téléchargement et exécution

du script approprié


sur 32

Pour protéger les informations sensibles éventuellement présentes dans vos scripts, vous

devez limiter l'accès à ces éléments en utilisant les rôles IAM.4

Utilisation des outils de gestion de la configuration Même si l'élaboration de scripts pour vos propres solutions fonctionne, cette option peut

rapidement devenir complexe lorsqu'il s'agit de gérer les environnements volumineux. Il peut

également s'avérer difficile de maîtriser et de contrôler votre environnement, pour identifier

les modifications ou résoudre les problèmes de configuration, par exemple. Vous pouvez

solutionner certains de ces problèmes en utilisant un outil de gestion de la configuration pour

gérer les configurations des instances.

Les outils de gestion de la configuration vous permettent de définir la configuration de votre

environnement en code, en utilisant, généralement, une langue spécifique au domaine. Ces

langues spécifiques au domaine s'appuient sur une approche déclarative du code, dans

laquelle le code décrit l'état final et ne correspond pas à un script exécutable. Etant donné

que l'environnement est défini à l'aide du code, vous pouvez assurer le suivi des

modifications apportées à la configuration et appliquer le contrôle des versions. De

nombreux outils de gestion de la configuration proposent également d'autres fonctionnalités

comme la conformité, le contrôle et la recherche.

Comparaison entre les modèles Push et Pull

Les outils de gestion de la configuration s'appuient généralement sur un des deux

modèles : Push (pousser) ou Pull (tirer). Le modèle utilisé par un outil est défini par la façon

dont un nœud (une instance EC2 cible dans AWS) communique avec le serveur principal

de gestion de la configuration.

Dans un modèle Push, un serveur principal de gestion de la configuration connaît les nœuds

dont il a besoin pour assurer la gestion et pousse la configuration vers ces nœuds à distance.

Ces nœuds doivent être enregistrés préalablement sur le serveur principal. Certains outils

Push sont sans agent et exécutent la configuration à distance, en utilisant les protocoles

existants, comme SSH. Les autres poussent un package, qui est ensuite exécuté localement

à l'aide d'un agent. Le modèle Push présente généralement certaines contraintes en cas

d'exploitation de ressources AWS dynamiques et évolutives :

Le serveur principal doit disposer des informations sur les nœuds dont il a besoin pour

gérer la configuration. Lorsque vous utilisez des outils tels que Auto Scaling, où les

nœuds peuvent aller et venir, ceci peut s'avérer difficile.

Les systèmes Push qui procèdent à l'exécution à distance n'évoluent pas aussi bien que

les systèmes dans lesquels les modifications de configuration sont déchargées et

exécutées localement sur un nœud. Dans les environnements volumineux, le serveur

principal risque d'être surchargé si plusieurs systèmes sont configurés en parallèle.

4http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html


sur 32

La connexion aux nœuds à distance exige que vous autorisiez l'accès entrant de ports spécifiques vers vos nœuds. Pour certains outils d'exécution à distance, cette autorisation inclut un protocole SSH distant.

Le second modèle est le modèle Pull. Les outils de gestion de la configuration qui utilisent un système Pull font appel à un agent installé sur un nœud. L'agent demande la configuration au serveur principal. Un nœud peut récupérer sa configuration au moment du démarrage ou les agents peuvent être convertis en programmes fantômes de façon à extraire régulièrement les modifications de configuration. Les systèmes Pull sont particulièrement utiles pour gérer les environnements AWS dynamiques et évolutifs. Le modèle Pull offre les avantages suivants :

Les nœuds peuvent croître et diminuer facilement car le serveur principal n'a pas besoin de connaître leur existence pour qu'ils puissent être configurés. Les nœuds s'enregistrent simplement tout seuls avec le serveur.

Les nœuds principaux de gestion de la configuration requièrent moins de dimensionnement en cas d'utilisation d'un système Pull car l'ensemble du traitement est déchargé et exécuté localement, sur le nœud distant.

Aucun port spécifique ne doit être ouvert en entrée vers les nœuds. La plupart des outils permettent à l'agent de communiquer avec le serveur principal en utilisant les ports sortants typiques, comme HTTPS.

Exemple de Chef

De nombreux outils de gestion de la configuration fonctionnent avec AWS. Les plus populaires sont, notamment, Chef, Puppet, Ansible et SaltStack. A titre d'exemple dans cette section, nous utilisons l'outil Chef afin de démontrer l'action d'amorçage avec un outil de gestion de la configuration. Vous pouvez utiliser d'autres outils et appliquer les mêmes principes.

Chef est un outil de gestion de la configuration Open source qui utilise un agent (client Chef) pour extraire la configuration disponible sur un serveur principal (serveur Chef). Notre exemple illustre la façon d'amorcer les nœuds en récupérant la configuration sur un serveur Chef au moment du démarrage.

L'exemple s'appuie sur les hypothèses suivantes :

Vous avez configuré un serveur Chef.

Vous disposez d'une AMI dont les outils de ligne de commande AWS sont installés et configurés.

Le client Chef est installé et inclus dans votre AMI.

Observons tout d'abord ce que nous allons configurer dans Chef. Nous allons créer un simple livre de recettes Chef qui installe un serveur web Apache et déploie un site « Hello World ». Un livre de recettes Chef recueille des recettes ; une recette correspond à une définition de ressource à configurer sur un nœud. Cette recette peut inclure des fichiers, des packages, des autorisations, et d'autres choses encore. La recette par défaut pour le livre de recettes Apache peut ressembler à ce qui suit :


sur 32

Dans cette recette, nous installons, activons et démarrons le serveur HTTPD (HTTP daemon).

Nous générons ensuite un template pour index.html et le plaçons dans le répertoire

/var/www/html. Dans le cas présent, le template index.html.erb est une page HTML très

simple :

Le livre de recettes est ensuite téléchargé sur le serveur Chef. Chef permet de regrouper les

livres de recettes en rôles. Les rôles sont utiles dans les environnements à grande échelle

où les serveurs peuvent avoir de nombreux rôles différents dans votre environnement et les

livres de recettes risquent d'avoir des rôles redondants. Dans notre exemple, nous ajoutons

ce livre de recettes à un rôle appelé « webserver ».

Désormais, lorsque nous lançons les instances EC2 (nœuds), nous pouvons fournir les

données utilisateur EC2 afin de les amorcer à l'aide de Chef. Pour rendre ce processus

aussi dynamique que possible, nous pouvons utiliser une balise EC2 pour définir le rôle

Chef à appliquer à notre nœud. Ceci nous permet d'utiliser le même script de données

utilisateur pour tous les nœuds, quel que soit le rôle attribué. Par exemple, un serveur web

et un serveur de base de données peuvent utiliser les mêmes données utilisateur si vous

attribuez différentes valeurs à la balise de ‘rôle’ dans EC2.

#

# Cookbook Name:: apache

# Recipe:: default

#

# Copyright 2014,

VOTRE_NOM_D'ENTREPRISE

#

# Tous droits réservés - Ne pas diffuser

#

package "httpd"

#Permettre à Apache de démarrer sur le

service de démarrage "httpd" do

action [:enable, :start] end

#Ajouter le template HTML au template

racine web "/var/www/html/index.html" do

source "index.html.erb" mode

"0644"

fin

<h1>Hello World</h1>


sur 32

Nous devons également tenir compte de la façon dont notre nouvelle instance s'authentifiera avec le serveur Chef. Nous pouvons enregistrer notre clé privée dans un compartiment Amazon S3 chiffré à l'aide du chiffrement côté serveur Amazon S3,

5 et nous

pouvons limiter l'accès à ce compartiment grâce aux rôles IAM. La clé peut ensuite être utilisée pour l'authentification avec le serveur Chef. Le client Chef utilise un fichier validator.pem pour l'authentification sur le serveur Chef lors de l'enregistrement de nouveaux nœuds.

Nous avons également besoin de savoir de quel serveur Chef extraire notre configuration. Nous pouvons enregistrer un fichier client.rb pré-rempli dans Amazon S3 et le copier dans notre script de données utilisateur. Vous pouvez vouloir compléter dynamiquement ce fichier client.rb en fonction de l'environnement. Cependant, pour notre exemple, nous partons de l'hypothèse selon laquelle nous ne disposons que d'un seul serveur Chef et qu'un fichier client.rb pré-rempli est suffisant. Vous pouvez également inclure ces deux fichiers dans votre version d'AMI personnalisée.

Les données utilisateur ressembleront à ce qui suit :

#!/bin/bash

cd /etc/chef

#Copier la clé privée du serveur Chef depuis le compartiment S3

aws s3 cp s3://s3-bucket/orgname-validator.pem orgname-

validator.pem

#Copier le fichier de configuration du client Chef

depuis le compartiment S3 aws s3 cp s3://s3-

bucket/client.rb client.rb

#Changer les autorisations sur la clé privée du

serveur Chef. chmod 400 /etc/chef/orgname-

validator.pem

#Obtenir l'ID d'instance EC2 auprès du service des

metadonnées ID_INSTANCE=`curl -s

http://169.254.169.254/latest/meta- data/instance-id`

#Obtenir la balise avec la clé du ‘rôle’ pour cette instance

EC2 BALISE_ROLE=$(aws ec2 describe-tags --filters

"Name=resource- id,Values=$INSTANCE_ID"

"Name=key,Values=role" --output text)

#Obtenir la valeur de la balise avec la clé du ‘rôle’ sous

forme de chaîne VALEUR_BALISE_ROLE=$(echo $ROLE_TAG | awk

'NF>1{print $NF}')

#Créer le fichier first_boot.json dynamiquement en

ajoutant la valeur de la balise en tant que rôle de Chef

dans la liste d'exécution

echo "{\"run_list\":[\"role[$ROLE_TAG_VALUE]\"]}"

>first_boot.json

5 http://docs.aws.amazon.com/AmazonS3/latest/dev/UsingServerSideEncryption.html

http://169.254.169.254/latest/meta-

http://docs.aws.amazon.com/AmazonS3/latest/dev/UsingServerSideEncryption.html


sur 32

Comme le montre l'exemple précédent de données utilisateur, nous copions nos fichiers de

configuration client depuis un compartiment S3 privé. Nous utilisons ensuite un service de

metadonnées EC2 afin d'obtenir des informations sur l'instance (dans cet exemple, il s'agit

de l'ID de l'instance). Puis, nous demandons à l'API Amazon EC2 les balises avec la clé du

‘rôle’ et configurons dynamiquement une liste d'exécution Chef, avec un rôle Chef pour cette

valeur. Enfin, nous exécutons le premier client Chef en fournissant les options first_boot.json,

qui comprennent notre nouvelle liste d'exécution. Nous exécutions ensuite le client Chef une

fois de plus mais, cette fois, nous l'exécutons dans une configuration de programme fantôme

afin de récupérer la configuration toutes les 5 minutes.

Nous disposons maintenant de quelques données utilisateur EC2 réutilisables que nous

pouvons appliquer à n'importe quelle nouvelle instance EC2. Tant qu'une balise ‘rôle’ est

fournie avec une valeur qui correspond à un rôle sur le serveur Chef cible, l'instance sera

configurée avec les livres de recettes Chef correspondants.

Récapitulation

La figure suivante représente un flux de travail typique, du lancement de l'instance à une

instance intégralement configurée, prête à servir le trafic.

#exécuter le client Chef en utilisant le client Chef de

config. first_boot.json -j first_boot.json

#convertir en programme fantôme le client Chef pour

exécuter toutes les 5 minutes le client Chef -d -i

300 -s 30


sur 32

Figure 6 : Exemple de flux de travail intégral

Réception des données

utilisateur et exposition

via le service de

metadonnées

describe-tags

describe-tags

Données utilisateur

Service de metadonnées EC2

Fichiers de config. Chef

API EC2

API EC2 Action d'amorçage

terminée

Instance Amazon EC2 Compartiment Amazon S3

Récupération et traitement

des données utilisateur

Téléchargement de la clé

privée et du fichier

client.rb depuis le

compartiment S3

Récupération du rôle du

serveur sur l'API EC2

Configuration de

first_boot.son pour utiliser

le rôle Chef avec la valeur

de la balise

Extraction de la config.

depuis le serveur Chef et

configuration de l'instance

Demande de

lancement de

l'instance


sur 32

Utilisation des services AWS pour faciliter la gestion de vos environnements Dans les sections précédentes, nous avons découvert les outils et techniques que les

administrateurs système et les développeurs peuvent utiliser pour allouer les instances

EC2 de manière automatisée, prévisible et reproductible. AWS fournit également toute

une gamme de services de gestion d'applications, qui simplifient ce processus et optimisent

sa productivité. La figure suivante indique comme sélectionner le service adapté à votre

application en fonction du niveau de contrôle requis.

Figure 7 : Services de déploiement et de gestion AWS

Ces services ne se contentent pas de mettre les instances EC2 en service : ils peuvent

également vous aider à mettre en service d'autres composants AWS associés dont vous

avez besoin dans vos systèmes, comme les groupes Auto Scaling, les équilibreurs de

charge et les composants de mise en réseau. Vous trouverez d'autres informations sur

le mode d'utilisation de ces services dans les sections suivantes.

AWS Elastic Beanstalk AWS Elastic Beanstalk permet aux développeurs web de télécharger facilement du code sans

se préoccuper de la gestion ou de l'implémentation des composants sous-jacents de

l'infrastructure. Elastic Beanstalk gère le déploiement, l'allocation de la capacité, la répartition

de la charge, le dimensionnement automatique et la surveillance de l'état de l'application. Il

convient de noter qu'Elastic Beanstalk n'est pas un service en boîte noire : vous disposez

d'une pleine visibilité et d'un contrôle total sur les ressources AWS sous-jacentes déployées,

comme les instances EC2 et les équilibreurs de charge.

Elastic Beanstalk prend en charge le déploiement de Java, .NET, Ruby, PHP, Python,

Node.js et Docker sur des serveurs connus comme Apache, Nginx, Passenger et IIS. Elastic

Beanstalk fournit une configuration par défaut ; vous pouvez cependant étendre la

configuration au gré de vos besoins. Par exemple, vous pouvez vouloir installer d'autres

packages à partir d'un référentiel yum ou copier les fichiers de configuration dont votre

application a besoin comme, par exemple, un substitut à httpd.conf pour remplacer les

paramètres spécifiques.


sur 32

Vous pouvez rédiger les fichiers de configuration au format YAML ou JSON et créer les fichiers avec une extension de fichier .config. Vous placez ensuite les fichiers dans un dossier dans la racine de l'application appelée .ebextensions. Vous pouvez utiliser les fichiers de configuration pour gérer les packages et les services, exploiter les fichiers et exécuter les commandes.

Pour plus d'informations sur l'utilisation et l'extension d'Elastic Beanstalk, consultez la documentation d'AWS Elastic Beanstalk.

6

AWS OpsWorks AWS OpsWorks est un service de gestion d'applications qui facilite le déploiement et la

gestion des applications et de leurs ressources AWS requises. Avec AWS OpsWorks, vous

élaborez les stacks d'applications constitués d'une ou plusieurs layers. Pour configurer une

layer, utilisez une configuration AWS OpsWorks et/ou une configuration personnalisée. AWS

OpsWorks utilise Chef, l'outil Open source de gestion de la configuration, pour configurer les

ressources AWS. Vous avez ainsi la possibilité de proposer vos propres recettes

personnalisées ou celles de la communauté Chef.

AWS OpsWorks s'accompagne de tout un ensemble d'événements de cycle de vie

(Installation,Configuration, Déploiement, Annulation de déploiement et Arrêt) qui exécutent

automatiquement les recettes appropriées, au moment opportun, sur chaque instance. AWS

OpsWorks propose quelques layers gérées par AWS pour les stacks typiques d'applications.

Ces layers sont ouvertes et personnalisables, ce qui signifie que vous pouvez ajouter des

recettes personnalisées supplémentaires aux layers fournies par AWS OpsWorks ou créer

intégralement des layers personnalisées en utilisant vos recettes existantes.

Il est important de s'assurer que les recettes correctes sont associées aux événements de

cycle de vie appropriés. Les événements de cycle de vie se produisent aux étapes suivantes :

Installation : se produit sur une nouvelle instance après la réussite de son démarrage.

Configuration : se produit sur toutes les instances de stack lorsqu'une instance accède

à l'état en ligne ou le quitte.

Déploiement : se produit lorsque vous déployez une application.

Annulation de déploiement : se produit lorsque vous supprimez une application.

Arrêt : se produit lorsque vous arrêtez une instance.

Par exemple, l'événement de configuration est utile lors de l'élaboration des systèmes

distribués ou pour tout système qui doit savoir quand de nouvelles instances sont ajoutées

ou supprimées du stack. Vous pouvez utiliser cet événement pour mettre à jour un

équilibreur de charge lorsque de nouveaux serveurs web sont ajoutés au stack.

6 http://aws.amazon.com/documentation/elastic-beanstalk/

http://aws.amazon.com/documentation/elastic-beanstalk/


sur 32

Outre la configuration typique du serveur, AWS OpsWorks gère le déploiement des

applications et s'intègre au référentiel du code de vos applications. Ceci vous permet

d'assurer le suivi des versions des applications et le rétablissement des déploiements,

si nécessaire.

Pour plus d'informations sur AWS OpsWorks, consultez la documentation d'AWS OpsWorks.

7

AWS CloudFormation AWS CloudFormation permet aux développeurs et aux administrateurs système de créer

et de gérer facilement un ensemble de ressources AWS liées entre elles, de les mettre en

service et de les actualiser de manière ordonnée et prévisible. Comparé à Elastic Beanstalk

et AWS OpsWorks, AWS CloudFormation vous offre davantage de maîtrise et de flexibilité

sur la mise en service des ressources.

AWS CloudFormation vous permet de gérer un vaste ensemble de ressources AWS. Dans le

cadre de ce livre blanc, nous nous sommes concentrés sur les fonctionnalités que vous

pouvez utiliser pour amorcer vos instances EC2.

Données utilisateur Plus haut dans ce livre blanc, nous avons décrit le processus d'utilisation des données

utilisateur pour configurer et personnaliser vos instances EC2 (consultez la section Script de

votre propre solution). Vous pouvez également inclure les données utilisateur dans un

template AWS CloudFormation, qui s'exécute sur l'instance dès sa création. Vous pouvez

inclure les données utilisateur lorsque vous désignez une seule instance EC2 tout comme

lorsque vous indiquez une configuration de lancement. L'exemple suivant montre une

configuration de lancement qui alloue les instances configurées aux serveurs web PHP :

7 http://aws.amazon.com/documentation/opsworks/

"MyLaunchConfig" : {

"Type" : "AWS::AutoScaling::LaunchConfiguration",

"Properties" : {

"ImageId" : "i-123456",

"SecurityGroups" : "MySecurityGroup",

"InstanceType" : "m3.medium", "KeyName"

: "MyKey",

"UserData": {"Fn::Base64": {"Fn::Join":["",[

"#!/bin/bash\n",

"yum update -y\n",

"yum -y install httpd php php-mysql\n",

"chkconfig httpd on\n", "/etc/init.d/httpd

start\n"

]]}}

http://aws.amazon.com/documentation/opsworks/


sur 32

cfn-init Le script cfn-init est un script d'assistant AWS CloudFormation que vous pouvez utiliser

pour indiquer l'état final d'une instance EC2 de manière plus déclarative. Le script cfn-init

est installé par défaut sur Amazon Linux et sur les AMI Windows fournies par AWS. Les

administrateurs peuvent également installer cfn-init sur d'autres distributions Linux, puis les

inclure dans leur propre AMI, si nécessaire.

Le script cfn-init analyse les metadonnées issues du template AWS CloudFormation et les

utilise pour personnaliser l'instance comme il convient. Le script cfn-init peut effectuer les

opérations suivantes :

installer les packages depuis les référentiels de packages (comme yum et apt-get) ;

télécharger et décompresser les archives, comme les fichiers .zip et .tar ;

enregistrer les fichiers sur le disque ;

exécuter des commandes arbitraires ;

créer des utilisateurs et des groupes ;

activer/désactiver et arrêter/démarrer des services.

Dans un template AWS CloudFormation, le script d'assistant cfn-init est appelé depuis les

données utilisateur. Une fois appelé, il inspecte les metadonnées associées aux ressources

communiquées dans la demande, puis agit comme il convient. Par exemple, vous pouvez

utiliser les metadonnées suivantes de configuration de lancement pour ordonner à cfn-init de

configurer une instance EC2 pour qu'elle devienne un serveur web PHP (ce qui est semblable

à l'exemple précédent de données utilisateur) :

}

}

"MyLaunchConfig" : {

"Type" : "AWS::AutoScaling::LaunchConfiguration",

"Metadata" : {

"AWS::CloudFormation::Init" : {

"config" : {

"packages" : {

"yum" : {

"httpd" : [],

"php" : [],

"php-mysql" : []

}

},

"services" : {

"sysvinit" : {

"httpd" : {


sur 32

Pour connaître la procédure détaillée d'amorçage des instances EC2 à l'aide d'AWS

CloudFormation et de ses scripts d'assistant associés, consultez le livre blanc sur

l'action d'amorçage des applications via AWS CloudFormation.8

Utilisation des services ensemble Vous pouvez utiliser les services séparément pour vous aider à mettre en service de

nouveaux composants de l'infrastructure. Vous pouvez cependant aussi les combiner de

manière à créer une solution unique. Cette approche possède de nets avantages. Vous

pouvez ainsi modeler toute une architecture, y compris les configurations de mise en réseau

et de base de données, directement dans un template AWS CloudFormation, puis déployer

et gérer votre application à l'aide d'AWS Elastic Beanstalk ou AWS OpsWorks. Cette approche

homogénéise la gestion des ressources et des applications, et facilite l'application du

contrôle des versions à l'ensemble de votre architecture.

8 https://s3.amazonaws.com/cloudformation-examples/BoostrappingApplicationsWithAWSCloudFormation.pdf

"enabled" : "true",

"ensureRunning" : "true"

}

}

}

}

}

},

"Properties" : { "ImageId"

: "i-123456",

"SecurityGroups" : "MySecurityGroup",

"InstanceType" : "m3.medium", "KeyName"

: "MyKey",

"UserData": {"Fn::Base64": {"Fn::Join":["",[

"#!/bin/bash\n",

"yum update -y aws-cfn-bootstrap\n",

"/opt/aws/bin/cfn-init --stack ", { "Ref" :

"AWS::StackId" }, " --resource MyLaunchConfig ",

" --region ", { "Ref" : "AWS::Region" }, "\n",

]]}}

}

}


sur 32

Gestion de l'état de l'application et des instances Dès lors qu'un processus adapté permettant de mettre en service automatiquement les

nouveaux composants de l'infrastructure est en place, votre système possède la capacité de

créer de nouvelles instances EC2 et même de nouveaux environnements entiers, de manière

rapide, reproductible et prévisible. Malgré tout, dans un environnement cloud dynamique,

vous devez également tenir compte du mode de suppression des instances EC2 de vos

environnements, ainsi que de l'impact de cette opération sur le service que vous proposez

à vos utilisateurs. Plusieurs raisons peuvent motiver la suppression d'une instance de votre

système :

L'instance est résiliée à la suite d'un dysfonctionnement matériel ou logiciel.

L'instance est résiliée en réponse à un événement de « mise à l'échelle

descendante » visant à supprimer des instances d'un groupe Auto Scaling.

L'instance est résiliée car vous avez déployé une nouvelle version de votre stack

logiciel en utilisant des « blue-green deployments » (les instances s'exécutant sur

l'ancienne version de l'application sont résiliées après le déploiement).

Pour gérer la suppression des instances sans affecter votre service, vous devez veiller

à ce que vos instances d'application soient sans état. Ainsi, tous les états du système et

des applications sont enregistrés et gérés en dehors des instances elles-mêmes. Il existe de

nombreuses formes d'états du système et des applications à prendre en compte lors de la

conception de votre système, comme le montre le tableau suivant.

Etat Exemples

Données d'application non structurées

Journaux des applications et du système

Le fait d'exécuter des instances d'applications sans état signifie qu'aucune instance d'une flotte n'est différente de ses équivalents. Cette particularité offre un certain nombre d'avantages :

Un service robuste – Les instances peuvent répondre à n'importe quelle demande de n'importe quel utilisateur, à tout moment. En cas d'échec de l'instance, les demandes suivantes peuvent être orientées vers d'autres instances pendant le remplacement de l'instance défectueuse. Cette opération de bascule peut s'effectuer sans interruption du service pour vos utilisateurs.

Métriques des applications et du système

Données d'application structurées

Données de session utilisateur

Commandes client

Images et documents

Position dans l'application ; contenu d'un panier d'achat

Charge de l'UC ; utilisation du réseau

Journaux d'accès ; journaux de contrôle de sécurité


sur 32

Action d'amorçage plus rapide et moins compliquée – Etant donné que vos instances ne contiennent pas d'état dynamique, votre processus d'amorçage ne doit gérer que la mise en service de votre système jusqu'à la layer des applications. Il n'est pas nécessaire de tenter derécupérer un état et des données, qui sont souvent volumineuses, ce qui risque donc d'augmenter considérablement les délais d'amorçage.

Instances EC2 sous forme d'unité de déploiement – Etant donné que tous les états

sont conservés hors des instances EC2, vous pouvez remplacer les instances tout en

organisant les déploiements d'applications. Cette possibilité simplifie vos processus de

déploiement et permet d'appliquer de nouvelles techniques de déploiement, comme les

« blue-green deployments ».

La section suivante décrit chaque forme d'état d'application et d'instance. Elle détaille

également quelques outils et techniques que vous pouvez utiliser pour vous assurer que cet

état est stocké séparément et indépendamment des instances d'application.

Données d'application structurées La plupart des applications produisent des données textuelles structurées, comme des

commandes client dans un système de gestion des commandes ou une liste de pages web

dans un CMS. Très souvent, il est plus adapté d'enregistrer ce type de contenu dans une

base de données. Selon la structure des données et les exigences en termes de vitesse

d'accès et de simultanéité, vous pouvez décider d'utiliser un système de gestion de base

de données relationnelle ou un stockage de données NoSQL. Quel que soit le cas, il est

important de conserver ce contenu dans un système durable et extrêmement disponible,

à l'écart des instances qui exécutent votre application. Vous éviterez ainsi que le service

offert à vos utilisateurs ne soit interrompu ou que leurs données ne soient perdues, même

en cas de dysfonctionnement d'une instance.

AWS propose des bases de données relationnelles et NoSQL que vous pouvez utiliser

comme layer de persistance pour vos applications. Nous détaillerons ces options de bases

de données dans les sections suivantes.

Amazon RDS Amazon Relational Database Service (Amazon RDS) est un service Web qui facilite l'installation,

l'exploitation et le dimensionnement d'une base de données relationnelle dans le cloud. Il

vous permet de continuer de travailler avec les moteurs de bases de données relationnelles

que vous connaissez, notamment MySQL, Oracle, Microsoft SQL Server ou PostgreSQL.

Cela signifie que le code, les applications et les outils opérationnels que vous utilisez déjà

fonctionnent avec Amazon RDS. Amazon RDS gère également les fastidieuses tâches de

gestion de base de données, comme les sauvegardes et les récupérations de données,

ainsi que la gestion des patchs, ce qui libère vos administrateurs de base de données et

leur permet de se consacrer à des opérations à plus forte valeur ajoutée, comme le

développement d'applications ou l'ajustement des bases de données.


sur 32

En outre, les déploiements multi-AZ Amazon RDS augmentent la disponibilité de votre base de données et protègent celle-ci des interruptions imprévues. Votre service bénéficie ainsi d'un niveau supplémentaire de résilience.

Amazon DynamoDB

Amazon DynamoDB est un service de base de données entièrement opéré par NoSQL et offrant des modèles de documents (JSON) et de données de valeur clé. DynamoDB a été repensé de manière à assurer une latence homogène, de l'ordre de la milliseconde, à n'importe quelle échelle. Il est donc parfaitement adapté aux applications à trafic dense exigeant un accès aux données à faible latence. DynamoDB gère le dimensionnement et le partitionnement de l'infrastructure pour vous. Lorsque vous créez un tableau, vous indiquez le niveau de capacité de demande voulu. Si vos exigences changent en termes de rendement, vous pouvez mettre à jour cette capacité, sans affecter le service.

Données d'application non structurées Outre les données structurées créées par la plupart des applications, certains systèmes exigent également de recevoir et de stocker des ressources non structurées comme des documents, des images et d'autres données binaires. Ce peut être le cas, par exemple, dans un CMS où l'éditeur télécharge des images et des fichiers PDF à héberger sur un site web.

Dans la plupart des cas, une base de données ne constitue pas un mécanisme de stockage adapté à ce type de contenu. Vous pouvez, en revanche, utiliser Amazon Simple Storage Service (Amazon S3). Amazon S3 offre un stockage hautement disponible et durable, idéal pour le stockage de ce type de données. Une fois vos données stockées dans Amazon S3, vous pouvez diffuser ces fichiers directement à vos utilisateurs finaux depuis Amazon S3, via un protocole HTTP(S), sans que ces demandes passent par vos instances d'application.

Données de session utilisateur De nombreuses applications produisent des informations associées à la position actuelle d'un utilisateur au sein d'une application. Par exemple, lorsque les utilisateurs naviguent dans un site d'e-commerce, ils peuvent commencer à ajouter divers articles dans leur panier d'achat. Ces informations sont appelées état de session. Il serait frustrant pour les utilisateurs que les articles insérés dans leurs paniers d'achat disparaissent sans avertissement. Il est donc important de stocker l'état de session à l'écart des instances d'applications elles-mêmes. Vous êtes ainsi certain que les paniers d'achat conservent leurs articles, même si les demandes des utilisateurs sont dirigées vers une autre instance, située derrière votre équilibreur de charge, ou si l'instance actuelle est retirée du service, pour quelque raison que ce soit.

La plateforme AWS propose un certain nombre de services que vous pouvez utiliser pour offrir un magasin de session extrêmement disponible.

Amazon ElastiCache Amazon ElastiCache facilite le déploiement, l'utilisation et le dimensionnement d'un magasin de données en mémoire dans AWS. Les magasins de données en mémoire sont parfaits pour stocker les données de session temporaires en raison de la faible latence de ces technologies. ElastiCache prend en charge deux moteurs de mise en cache mémoire en Open source :


sur 32

Memcached – Système largement répandu de mise en cache des objets en mémoire. ElastiCache offre une conformité de protocole avec Memcached, qui est déjà compatible avec de nombreuses applications Open source comme plateforme de stockage de session en mémoire.

Redis – Magasin de valeurs clés Open source en mémoire très usité, qui prend en charge les structures de données comme les ensembles et les listes triés. ElastiCache prend en charge la réplication principal/subordonné et multi-AZ, que vous pouvez utiliser pour bénéficier de la redondance entre les différentes zones de disponibilité.

Outre les magasins de données en mémoire proposés par Memcached et Redis sur ElastiCache, certaines applications exigent une plateforme de stockage plus durable pour leurs données de session. Pour ces applications, Amazon DynamoDB offre une solution durable, extrêmement évolutive, à faible latence. DynamoDB réplique les données sur les trois installations dans une région AWS de manière à assurer une tolérance aux pannes en cas de dysfonctionnement du serveur ou d'interruption du service dans la zone de disponibilité.

Pour aider les clients à intégrer facilement DynamoDB sous forme de magasin de session dans leurs applications, AWS propose des gestionnaires de session DynamoDB préalablement incorporés pour les applications Java

9 basées sur Tomcat et les applications PHP.

10

Métriques du système Pour prendre correctement en charge un système de production, les équipes opérationnelles doivent accéder aux métriques du système qui indiquent l'état global du système et la charge correspondante, en cours de fonctionnement. Dans un environnement traditionnel, ces informations sont souvent accessibles en se connectant à l'une des instances et en observant les métriques au niveau du système d'exploitation, comme la charge du système ou l'utilisation de l'UC. Cependant, dans un environnement exécutant plusieurs instances, qui peuvent elles-mêmes apparaître et disparaître à tout moment, cette approche devient vite inefficace et difficile à gérer. Vous devriez, au contraire, pousser ces données vers un système de surveillance externe à des fins de collecte et d'analyse.

Amazon CloudWatch Amazon CloudWatch est un service de surveillance intégralement géré pour les ressources AWS et les applications que vous exécutez sur ces ressources. Vous pouvez utiliser Amazon CloudWatch pour collecter et conserver les métriques sur une plateforme durable, distincte et indépendante de votre propre infrastructure. Ainsi, vos équipes opérationnelles ont accès aux métriques, même lorsque les instances ont été résiliées.

Outre le suivi des métriques, vous pouvez utiliser Amazon CloudWatch pour déclencher des alarmes lorsque ces métriques franchissent certains seuils. Vous pouvez utiliser les alarmes pour avertir les équipes et lancer d'autres actions automatisées conçues pour gérer les problèmes et ramener votre système dans ses tolérances de fonctionnement normales. Par exemple, une action automatisée peut lancer une règle Auto Scaling de manière à augmenter ou diminuer le nombre d'instances dans un groupe Auto Scaling.

9http://docs.aws.amazon.com/AWSSdkDocsJava/latest/DeveloperGuide/java-dg-tomcat-session-manager.html

10

http://docs.aws.amazon.com/aws-sdk-php/guide/latest/feature-dynamodb-session-handler.html

http://docs.aws.amazon.com/AWSSdkDocsJava/latest/DeveloperGuide/java-dg-tomcat-session-manager.html

http://docs.aws.amazon.com/aws-sdk-php/guide/latest/feature-dynamodb-session-handler.html


sur 32

Par défaut, Amazon CloudWatch peut surveiller toute une gamme de métriques sur vos ressources AWS. Ceci dit, il convient également de ne pas oublier qu'AWS n'a pas accès au système d'exploitation ou aux applications s'exécutant sur vos instances EC2. C'est pourquoi Amazon CloudWatch ne peut pas surveiller automatiquement les métriques accessibles uniquement dans le système d'exploitation, comme la mémoire et l'utilisation du volume du disque. Si vous voulez surveiller les métriques du système d'exploitation et des applications en utilisant Amazon CloudWatch, vous pouvez publier vos propres métriques dans CloudWatch via une simple demande API. Cette approche vous permet de gérer ces métriques comme vous géreriez d'autres métriques natifs, notamment la configuration des alarmes et les actions liées.

Vous pouvez utiliser service EC2Config11

pour pousser d'autres métriques de fonctionnement au niveau du système d'exploitation, sans avoir à coder manuellement par rapport aux API de

CloudWatch. Si vous exécutez des AMI Linux, vous pouvez utiliser l'ensemble d'exemples de scripts Perl

12 fournis par AWS qui montrent comment produire et tirer parti des métriques

personnalisés Amazon CloudWatch.

Outre CloudWatch, vous pouvez utiliser des solutions de surveillance tierces dans AWS afin

d'accroître vos capacités de surveillance.

Gestion des journaux Les données des journaux sont utilisées par votre équipe opérationnelle afin de mieux

comprendre les performances du système et de diagnostiquer tout problème susceptible de se produire. Les données des journaux peuvent être produites par l'application elle-

même, mais aussi par des composants du système situés à un niveau inférieur du stack. Ces composants peuvent inclure aussi bien des journaux d'accès produits par votre serveur

web, que des journaux de contrôle de sécurité générés par le système d'exploitation lui-même.

Votre équipe opérationnelle doit pouvoir accéder à ces journaux librement, à tout moment, que l'instance qui a produit initialement le journal concerné existe toujours ou pas. C'est

pourquoi il est important de déplacer les données des journaux de l'instance vers une plateforme de stockage plus durable, en temps quasi-réel, si possible.

Amazon CloudWatch Logs Amazon CloudWatch Logs est un service qui vous permet de déplacer facilement et rapidement vos journaux du système et des applications des instances EC2 vers une plateforme de stockage centralisée et durable (Amazon S3). Les données sont ainsi toujours

disponibles, même si l'instance a été résiliée. Vous assurez également la gestion de la politique de rétention des journaux afin que tous vos journaux soient conservés pendant la période voulue. Le service CloudWatch Logs fournit un agent de gestion des journaux que

vous pouvez installer sur vos instances EC2 afin de gérer l'insertion de vos journaux dans le service de gestion des journaux.

11

http://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/UsingConfig_WinAMI.html

12

http://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/mon-scripts-perl.html

http://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/UsingConfig_WinAMI.html

http://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/mon-scripts-perl.html


sur 32

Le service CloudWatch Logs ne se contente pas de déplacer vos journaux vers un stockage

durable : il vous permet également de surveiller en temps quasi-réel l'apparition dans vos

journaux de phrases, valeurs ou modèles (métriques) spécifiques. Ces métriques sont

exploitables de la même manière que les autres métriques CloudWatch. Vous pouvez, par

exemple, créer une alarme CloudWatch réglée sur le nombre d'erreurs relevées par votre

application ou sur le moment où certaines actions suspectes sont détectées dans vos

journaux de contrôle de sécurité.

Conclusion Ce livre blanc vous a montré comment effectuer les opérations suivantes :

mettre rapidement en service des composants de la nouvelle infrastructure, de

manière automatisée, reproductible et prévisible ;

vous assurer qu'aucune instance EC2 dans votre environnement n'est unique et que

toutes les instances sont sans état et donc facilement remplacées.

Grâce à ces fonctionnalités, vous pouvez aborder la mise en service et la gestion des

composants de l'infrastructure d'une toute autre manière que dans les environnements

traditionnels.

Au lieu d'élaborer chaque instance et de préserver l'homogénéité manuellement sur tout un

ensemble de vérifications et de répartitions opérationnelles, vous pouvez traiter votre

infrastructure comme s'il s'agissait d'un logiciel. En indiquant l'état final recherché pour votre

infrastructure grâce aux outils et processus de type logiciel décrits dans ce livre blanc, vous

pouvez fondamentalement changer la façon dont votre infrastructure est gérée, en tirant

pleinement partie de la nature dynamique, élastique et automatisée du cloud AWS.

Suggestions de lecture Documentation d'AWS Elastic Beanstalk

Documentation d'AWS OpsWorks

Applications d'actions d'amorçage via le livre blanc d'AWS CloudFormation

Utilisation de l'outil Chef avec AWS CloudFormation

Intégration d'AWS CloudFormation avec Puppet

Gestion de votre infrastructure AWS à l'échelle · 2016-08-02 · Amazon Web Services –...

Documents

Transcript of Gestion de votre infrastructure AWS à l'échelle · 2016-08-02 · Amazon Web Services –...