Déploiement, provisionnement et automatisation
Déployer une instance EC2
Lors de la création d’une EC2, on peut ajouter un script pour automatiser l’installation des derniers paquets propre à Amazon Linux et configurer le serveur web :
#!/bin/bash
dnf update -y
dnf install httpd -y
echo "<html><body><h1>Hello Cloud Gurus</h1></body></html>" >/var/www/html/index.html
systemctl start httpd
systemctl enable httpd
Les IP crées par EC2 sont désormais visible, pour visiter son site internet il faut aller sur l’IP publique. Attention aux pare-feu et proxys entreprise.
Les Elastick Block Store
Stockage liée à EC2. C’est comme un disque dur. On peut créer des systèmes de fichiers, faire tourner une base de donnée, un OS ou encore installer des applications. Utile pour la production
Haute disponibilité : elle se réplique automatiquement dans la même AZ (comme un second disque dur utilisé en RAID 1 ou mirroring).
Scale : on peut changer la capacité et même le type de stockage.
General Purpose SSD (gp2 et gp3) : Solid state disk, équilibre coût/performance
Provisioned IOPS SSD (io1 et io3) : tout pour la performance, le plus cher.
Io2 block express : c’est un SAN, latence inférieur à des milisecondes
Throughput Optimized HDD (st1) : low cost HDD, utilisé pour bcp de data. Intéressant en terme de coûts. Ce n’est pas un boot volume.
Cold HDD (sc1) : le moins cher.
Qu’est-ce qu’un bastion ?
Permet la connexion SSH ou RDP vers des instances privées depuis un réseau non sécurisé. Un bastion a une IP publique, réduit la surface d’attaque. Best practice security.
Un bastion fait partie d’un sous réseau public, relié à internet.
Elastic Load Balancer
Distribution automatique le trafic réseau vers nos serveurs. Il existe plusieurs load balancer centré soit sur le HTTP/HTTPS ou sur le TCP. Un nouveau service, Gateway Load Balancer, est une appli disponible depuis le marketplace AWS.
Application load balancer : Couche 7 OSI, HTTP/HTTPS - Il est spécifique aux web-serv. Network Load balancer : TCP et haute performance, couche 4 OSI.
Classic Load Balancer : Service “legacy” qui fait TCP et HTTP/S. X-Forwarded-For : ajoute un en-tête sur les demandes HTTP/S afin d’indiquer au serveur quelle IP externe y fait appel.
Dû à une mauvaise config d’un load balancer, des messages d’erreurs peuvent survenir, voici les plus fréquent :
Mise en place : 2 EC2 et un ELB + Configs
On nomme ensuite une règle de groupe de sécurité, on ajoute le code bootstrap et on lance l’instance.
Pour la seconde instance, on sélectionne eu-west-b et on sélectionne la même règle de groupe de sécurité.
On se rend ensuite dans la colonne de gauche pour sélectionner Load Balancer puis Create.
Il faut nommer notre ELB puis sélectionner les subnets sélectionnés lors de la création de nos instances dans mapping. Puis, on va sélectionner uniquement notre security group dans Listeners and routing.
On clique sur suivant, on sélectionne nos instances et on valide.
De retour sur l’ELB, on actualise et on sélectionne le target group :
Il ne reste plus qu’à créer notre ELB puis patienter quelques minutes pour la création.
Une fois sur la page de notre ELB, on copie-colle le DNS vers notre navigateur, et nous avons accès à notre page HTML !
Pour avoir un bon suivi monitoring, on va utiliser Cloudwatch. On l’exécute depuis la console et on va sélectionner “All metrics”.
On a accès des infos comme :
HealthyHostCount
UnHealthyHostCount
RequestCount
TargetResponseTime
HTTP Status Codes
Pour créer et inspecter les logs, on va éditer notre ELB et le lier à un S3 (ou en créer un si nécessaire). Rdv sur notre S3 et allez dans les permissions. On clique sur Edit bucket policy et on intègre un fichier JSON.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::009996457667:root"
},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::logbucket77/*"
}
]
}
Le 009996457667 de la ligne “Principal” {“AWS” est l’ID de l’ELB de notre région de déploiement (dans notre cas, Eu WEST 3 pour Paris). Le logbucket77 est le S3 qui servira à stocker les logs (et là où on rentre ce script).
La liste des log, tous encrypté, est à télécharger et ouvrir avec 7zip/Winrar pour consulter les informations :
http 2024-04-09T07:14:46.323594Z app/my-load-balancer/caa878e0106076bb 114.96.103.33:55857 172.31.19.63:80 0.001 0.001 0.000 200 200 531 320 "GET http://35.181.205.237:80/ HTTP/1.1" "Mozilla/5.0 (iPhone; CPU iPhone OS 13_2_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.3 Mobile/15E148 Safari/604.1" - - arn:aws:elasticloadbalancing:eu-west-3:730335444497:targetgroup/my-target-group/acfeab626c957d2a "Root=1-6614eae6-6a17b1da51cf70b579923f29" "-" "-" 0 2024-04-09T07:14:46.321000Z "forward" "-" "-" "172.31.19.63:80" "200" "-" "-"
Les sticky sessions
Une sticky session permet de passer outre les algorithmes de répartition de charges (Round Robin (flux envoyé distinctivement à chaque serv) et Least Outstanding Requests, LSO (envoie le flux au serv qui a le moins de requêtes).
Configurer un ELB basé sur des adresses IP
Faire deux serveurs web EC2 avec deux sous-réseaux différents (eu west 3C et eu west 3B).
Injecter le bootstrap suivant :
#!/bin/bash
yum update -y
yum install httpd -y
echo "<html><body><h1>Hello Cloud Gurus</h1></body></html>" >/var/www/html/index.html
systemctl start httpd
systemctl enable httpd
On crée ensuite un Load Balancer de type “application” (HTTP/S) avec les configurations basiques (sélection des subnet, security group créé précédemment (my-web-dmz2). Dans Listener (port 80), on créé un groupe de security. Une nouvelle page s’ouvre puis on va sélectionner IP addresses :
On va le nommer “my-target-group2”, on indique le Health path et on clique sur suivant.
Arrivée à la deuxième étape, on va inscrire nos adresses IP privée de nos EC2
On clique sur “Pending” et on ferme la page en cliquant sur le bouton en bas à droite. Puis, de retour sur l’ELB, on rafraîchit les recherches de target group pour ajouter celui qu’on vient de créer. Il ne reste plus qu’à créer le groupe puis d’attendre la création du LB.
On sélectionne le DNS de notre ELB, on l’ouvre sur un nouvel onglet : ça fonctionne !
EC2 Image Builder
Automatise le processus de création d’instances (AMI et container). On peut ajouter des OS, logiciels …
Place à la création ! Pour cela, on va créer un rôle depuis l’application IAM et sélectionner ces deux politiques :
Rendez-vous sur le service EC2 Image Builder et “Create Pipeline”. On peut définir automatiquement un planning de créations d’instances :
On va sélectionner “manual” pour l’exercice. Sur la page suivante, on peut sélectionner le type d’image (Amazon Machine Image ou Docker), les updates à faire (on part sur les dernières update de sécurité), le(s) type(s) de test souhaité (on sélectionne le simple boot test) puis suivant. On clique sur “next” et on sélectionne la case Create new infrastructure configuration. On nomme, on sélectionne le rôle IAM créé précédemment, on choisit l’instance t2micro. On peut personnaliser ces éléments suivants :
On finit l’installation sans rentrer dans les détails et on crée le pipeline.
On sélectionne le pipeline et on le lance.
De retour sur notre page EC2, on voit que l’instance est en train d’être créée. Néanmoins, cela peut prendre jusqu’à 20mn !
Notre AMI est créée ! On peut la retrouver dans le service EC2 et cliquer sur “AMI” dans la colonne de gauche.
CloudFormation
Mise en pratique :
Premièrement, on va dans le dashboard EC2 et sélectionner Key pairs pour en créer une.
On va dans CloudFormation, et sélectionner un template déja existant, voici celui qu’on va utilisé :
AWSTemplateFormatVersion: 2010-09-09
Description: Template to create an EC2 instance and enable SSH
Parameters:
KeyName:
Description: Name of SSH KeyPair
Type: 'AWS::EC2::KeyPair::KeyName'
ConstraintDescription: Provide the name of an existing SSH key pair
Resources:
MyEC2Instance:
Type: 'AWS::EC2::Instance'
Properties:
InstanceType: t3.micro
ImageId: ami-0facbf2a36e11b9dd
KeyName: !Ref KeyName
SecurityGroups:
- !Ref InstanceSecurityGroup
Tags:
- Key: Name
Value: My CF Instance
InstanceSecurityGroup:
Type: 'AWS::EC2::SecurityGroup'
Properties:
GroupName: MyDMZSecurityGroup
GroupDescription: Enable SSH access via port 22
SecurityGroupIngress:
IpProtocol: tcp
FromPort: 22
ToPort: 22
CidrIp: 0.0.0.0/0
Outputs:
InstanceID:
Description: The Instance ID
Value: !Ref MyEC2Instance
On importe ce fichier YAML et CloudFormation crée un S3 pour stocker notre fichier YAML. On clique sur suivant et on sélectionne notre Key Pair. On ne mettra pas plus de détails, on finalise la création de notre stack :
Les différents onglets comme Outputs ou Parameters indiquent les informations inscrites dans notre code YAML.
Pour se connecter en SSH, on ouvre le CMD et on se déplace vers le dossier où la clé de paire est stockée. Puis on lance la commande SSH :
It works !
Les erreurs communes dans CloudFormation relèvent souvent de permissions insuffisantes (IAM : il faut l’autorisation de créer des instances EC2), de limites (hardware et d’instances) ou un rollback qui ne fonctionne pas.
CloudFormation Best Practice :
Blue & Green Deployment
Si tout va bien avec la nouvelle version, le trafic des clients sera envoyé vers cette version. On peut conserver l’ancien environnement si besoin.
Très utile pour :
Déployer et introduire une nouvelle version de notre application
On peut faire un rollback facilement
On réduit les risques
Rolling Deployments (Batches)
L’objectif est de sélectionner deux serveurs pour insérer la nouvelle version d’Apache. Un des avantages est que ce déploiement coûte moins cher néanmoins, il y aura des versions live entre l’ancienne et la nouvelle version.
Canary Deployments
L’objectif est de déployer un nouveau service sur un petit nombre de serveurs, de diriger une mince partie du trafic sur ceux-ci pour créer un early warning system (monitoring, l’analyse et appliquer des corrections. Une fois que tout est ok, on passe tous les serveurs sur la nouvelle version. Réduction des risques de déploiements, Rollback facile et envoie du trafic sur la version originale.
Automatiser les tâches avec AWS Systems Manager (SSM)
SSM est un outil de management, organise et regroupe les EC2 et automatise les tâches courantes simultanément comme le patching, l’installation d’applis, lancer des scripts …
Cet outil est génial si on a une grande flotte d’instances.
Run Command est l’outil pour gérer les instances simultanément. Il peut :
Prédéfinir des commandes et scripts sur une ou plusieurs instances EC2
Arrêter, relancer, supprimer ou redimensionner les instances.
Attacher ou détacher les EBS volumes
installer ou patcher des packages grâce à Patch Manager
= Serveur web Apache
Il faut configurer les groupes de sécurité pour autoriser la liaison entre notre instance privée et le bastion (SSH & RDP). est un bastion.
Lors de la création des EC2, on va indiquer deux subnet différents (eu-west-a comme exemple ci dessous) :
On va créer un target group, renseigner nos services (ici des instances), donner un nom à ce group puis indiquer le nom du fichier pour la partie Health check protocol :
On repasse sur notre ELB, on clique sur Action => Edit Load balancers Attributes puis :
Un répertoire de fichier sur les log sera créé : AWSLog
