Editions ENI Livres | Vidéos | e-Formations
Images et instances
Introduction
Au chapitre précédent nous avons passé en revue les outils et les services AWS pour gérer la sécurité et l’accès aux ressources. Nous allons maintenant nous attaquer aux ressources elles-mêmes, en commençant sans surprise, avec la plus connue et utilisée, le EC2 (Elastic Computer Cloud). On va donc couvrir tout ce qui est essentiel pour la compréhension et l’utilisation de ce service, tel que les termes, les concepts et les terminologies de base, les principaux cas d’utilisation ainsi que des stratégies tarifaires recommandées afin de minimiser les coûts. Mais notre propos n’étant pas de faire double emploi avec la documentation officielle AWS, cette dernière est à votre disposition pour des informations de dernière heure et d’autres détails qui, pour des raisons faciles à comprendre, ne pourront pas être couverts ici.
Démarrer avec EC2
Si vous êtes comme moi, vous vous souvenez peut-être du tracas lié au processus d’approvisionnement et d’installation de l’infrastructure d’il y a dix ans, processus qu’on appelait en bon français procurement. Tout ce temps qu’on passait à attendre la réception des serveurs, tous les efforts déployés par nos chers administrateurs système, réseau et DBA pour installer et configurer des machines, des volumes de stockage, des systèmes d’exploitation, des bases de données, des câbles et d’autres infrastructures réseau ! Sans compter les nombreux problèmes et obstacles qui apparaissaient et qui nécessitaient l’intervention de services supports des constructeurs et éditeurs qui, entre parenthèses, n’étaient jamais d’accord et nous baladaient de l’un à l’autre ! Et la pléthore de spécialistes que tout cela nécessitait, et les coûts monstrueux ! Eh bien, depuis le 25 août 2006, date à laquelle Amazon sortit la première version beta de son produit phare EC2, tout cela est devenu de l’histoire ancienne.
EC2 est un service qui fournit aux utilisateurs de la capacité de traitement sur demande, avec facturation à l’usage. Cette capacité de traitement est évidemment virtuelle...
Cas d’utilisation typiques de l’infrastructure EC2
Pour mieux comprendre tous les avantages que AWS EC2 apporte, examinons ici les cas d’utilisation les plus typiques de cette infrastructure.
-
Hébergement : EC2 peut être utilisé pour héberger des environnements des plus variés, des applications et des services, sites web, jeux en ligne, etc. Le caractère dynamique et extensible de cette plateforme permet une utilisation parfaitement adaptée à tous les besoins, la capacité de traitement augmentant et diminuant en fonction des demandes, ce qui assure une qualité de service optimale. Des sociétés connues comme Netflix, Reddit, Ubisoft et d’autres utilisent EC2 comme environnement d’hébergement
-
Environnement de développement et test : l’activité de développement et de test a comme particularité le fait qu’elle peut exiger ponctuellement une infrastructure proche de celle de production. Une fois les sprints terminés, celle-ci peut ne plus être indispensable, jusqu’à la fois prochaine lors des prochains sprints, etc. Il s’agit donc d’un type d’utilisation très discontinu qui a toujours posé de gros problèmes aux organisations qui ne voulaient ni immobiliser une infrastructure importante et couteuse pour une utilisation ponctuelle, ni effectuer...
Démarrer avec des images et instances
La technologie de virtualisation n’est pas nouvelle, elle existe déjà depuis une dizaine d’années. À ce jour, la plupart des organisations font tourner leurs charges de travail sur des plateformes virtuelles comme VMware, Citrix ou Xen. Microsoft s’y est également mis avec Hyper-V, c’est dire !
Chez AWS on utilise une version modifiée de Xen qui, contrairement aux autres technologies de virtualisation, a l’avantage d’être open source. Ce que l’on appelle donc image et instance en terminologie AWS ne sont rien d’autre que des machines virtuelles. Mais c’est là que s’arrête la ressemblance, car, contrairement aux simples machines virtuelles, que n’importe qui peut créer et utiliser grâce aux outils mentionnés et de nombreux autres, chez AWS on a déployé des efforts importants pour concevoir et structurer ces images et instances, pour qu’elles restent légères, démarrent rapidement et soient facilement manipulées. Essayons de regarder plus en détail ces notions d’instances et images.
1. Comprendre les images
Une image n’est rien d’autre qu’un modèle préconfiguré servant de base pour la création d’instances. En terminologie AWS, les images sont appelées AMI (Amazon Machine Images). Chaque AMI contient un système d’exploitation équipé de différentes applications et services optionnels, par exemple des serveurs web, des serveurs d’application, etc. En ce qui concerne les systèmes d’exploitation, l’offre va des distributions Linux diverses et variées jusqu’à Windows.
Il est important quand même de comprendre que les AMI sont statiques de par leur nature, ce qui signifie que, une fois créées, leur état reste inchangé. On peut démarrer autant d’instances que nécessaire, à partir d’une seule et unique AMI et, ensuite, procéder à leurs modifications. Ainsi, les instances ont un caractère...
Options tarifaires pour EC2
En plus de la classification selon leur type, les instances EC2 se classifient aussi en fonction des options tarifaires comme suit :
-
Instances à la demande
-
Instances réservées
-
Instances spot
1. Les instances à la demande
Ce type d’instances est probablement le plus utilisé. Il s’agit d’instances créées dynamiquement, lorsque les conditions d’exploitation le requièrent. Leur utilisation est facturée à l’heure, sans versement initial ou engagement sur une durée fixe. Par défaut, un compte AWS standard a droit au maximum à vingt instances à la demande. Si vos besoins sont plus importants, vous devez adresser une requête spéciale au service support. À titre d’exemple, une instance de type t2.micro coûte $0.013 par heure dans la région UE Paris. Ce qui signifie que si elle est exécutée toute la journée, une telle instance vous coûtera $0.312.
2. Les instances réservées
Déployer des instances en utilisant le modèle de paiement à la demande présente quand même un inconvénient : AWS ne garantit pas son déploiement. Pourquoi ? Eh bien, la réponse courte est qu’AWS peut satisfaire vos besoins de créations dynamiques, à la volée, d’instances AMI uniquement sous...
Cas d’utilisation typiques
Maintenant que l’on vient de faire le tour des concepts de base sur les images et les instances AWS, passons à la partie la plus amusante : déployer nos propres instances dans le cloud. On va utiliser de manière alternative la console AWS, AWS CLI et Terraform, comme nous l’avions déjà fait au chapitre précédent, pour créer notre première instance de type t2.micro. On va également voir les opérations liées au cycle de vie de l’instance, à savoir le démarrage, l’arrêt, l’initialisation, etc.
Pour commencer, connectons-nous à la console AWS avec les accréditations IAM créées lors du chapitre précédent. Puis, cliquez sur le lien EC2. Vous allez être redirigé vers le tableau de bord EC2 contenant, dans le volet de navigation à gauche de l’écran, des liens vers les principales rubriques comme Instances, Images, Réseaux et sécurité, Équilibrage des charges, Auto-scaling, etc. Il affiche aussi des informations sur les zones de disponibilité et les régions. Dans notre cas, nous opérons dans la région EU West(Paris) qui propose plusieurs zones de disponibilité : eu-west-3a, eu-west-3b, ey-west-3c. Prenez quelques minutes pour vous familiariser avec le tableau de bord EC2.
Maintenant, on va lancer notre première instance en cliquant sur Lancer une instance dans le tableau de bord EC2, comme montré ci-dessous :
Lancement instance EC2
Le processus de lancement de nouvelles instances est un processus à plusieurs étapes. Passons-les en revue.
1. Étape 1 - le choix de l’AMI
Toute instance est créée à partir d’une AMI et, par conséquent, il faut commencer par choisir l’AMI à partir de laquelle notre instance sera générée. Le tableau de bord EC2 nous présente une multitude d’AMI allant des distributions Linux comme Ubuntu, RedHat, Suse et Amazon Linux, jusqu’à Windows. Il propose aussi un guide qui peut s’avérer très utile.
Chaque AMI dispose d’un identifiant unique, appelé AMI ID, très pratique pour gérer nos AMI avec AWS CLI ou Terraform, comme nous le verrons...
Se connecter à la nouvelle instance
Maintenant que notre nouvelle instance EC2 est créée et lancée, utilisons-la en tant que serveur web, en y installant Apache HTTP Server. Pour cela, la première chose à faire c’est donc de se connecter à l’instance.
Plusieurs méthodes de connexion à une instance sont disponibles, chacune avec ses avantages et inconvénients. On va les examiner toutes, une par une.
1. Connexion via le navigateur web
AWS fournit un plug-in Java pour navigateur, appelé MindTerm, constituant une méthode très convenable pour se connecter à une nouvelle instance. Mais attention, cette méthode est basée sur NPAPI (Netscape Plugin Application Programming), un vieux coucou du temps de Netscape, que tous les navigateurs ne supportent pas. Par exemple, si comme moi vous utilisez Chrome, alors vous ne pourrez pas vous y connecter, car Chrome ne supporte plus NPAPI.
La bonne nouvelle c’est que vous pourrez quand même le faire en utilisant Firefox ou Internet 9. En utilisant un de ces deux navigateurs, cliquez sur le bouton Connexion et la boîte de dialogue suivante vous sera présentée :
Connexion via le navigateur web
Il faut renseigner le nom de l’utilisateur qui, pour une AMI de type Amazon Linux, est ec2-user ainsi que le chemin où vous aviez sauvegardé le fichier PEM lors de la création...
Configurer la nouvelle instance
Notre instance EC2 est dorénavant active et prête à être utilisée. Nous savons comment nous y connecter et il ne nous reste plus qu’à y installer Apache HTTP Server. Bien que ceci ne relève pas directement de notre sujet, nous présentons ci-dessous le listing de la session de travail.
C:\Users\Nicolas DUMINIL\Downloads>ssh -i amikey.pem -l ec2-user
35.180.138.255
Last login: Thu May 23 17:01:55 2019 from
aputeaux-656-1-7-113.w83-204.abo.wanadoo.fr
__| __|_ )
_| ( / Amazon Linux 2 AMI
___|\___|___|
https://aws.amazon.com/amazon-linux-2/
1 package(s) needed for security, out of 1 available
Run "sudo yum update" to apply all updates.
[ec2-user@ip-172-31-40-26 ~]$ df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 475M 0 475M 0% /dev
tmpfs 492M 0 492M 0% /dev/shm
tmpfs 492M 388K 492M 1% /run
tmpfs 492M 0 492M 0% /sys/fs/cgroup
/dev/xvda1 8.0G 1.2G 6.8G 15% /
tmpfs 99M 0 99M 0% /run/user/1000
[ec2-user@ip-172-31-40-26 ~]$ sudo yum update -y
Loaded plugins: extras_suggestions, langpacks, priorities,
update-motd
amzn2-core
| 2.4 kB 00:00:00
amzn2extra-docker
| 1.3 kB 00:00:00
Resolving Dependencies
--> Running transaction check
---> Package python-urllib3.noarch 0:1.24.1-1.amzn2.0.1 will be updated
---> Package python-urllib3.noarch 0:1.24.3-1.amzn2.0.1 will be an update
--> Finished Dependency Resolution
Dependencies Resolved
==========================================================================
============================================
Package Arch Version
Repository ...Gestion des instances EC2 via AWS CLI
Si comme moi vous préférez la simplicité de la ligne de commande à la navigation compliquée, alors ce paragraphe est pour vous. Place à l’action !
1. Étape 1 - création de la clé d’accès
Tout d’abord, générons la clé d’accès qu’on va associer à la future instance EC2.
C:\Users\Nicolas DUMINIL>aws ec2 create-key-pair --key-name
amikey --output text > amikey.pem Création clé d’accès
Ici nous créons une clé d’accès nommée "amikey" qu’on va sauvegarder en format texte sous forme d’un fichier en syntaxe PEM.
2. Étape 2 - création du groupe de sécurité
L’accès à notre future instance EC2 sera contrôlé par un groupe de sécurité, comme nous l’avions expliqué auparavant. Créons-le ici :
C:\Users\Nicolas DUMINIL>aws ec2 create-security-group --group-
name amisecgroup --description "A short description"
{
"GroupId": "sg-0df710d8417319d8e"
} Création groupe de sécurité
3. Étape 3 - ajouter des règles de sécurité à notre nouveau groupe
Le groupe de sécurité ainsi créé, la prochaine chose à faire c’est d’y rajouter des règles. Ce sujet sera traité de façon plus détaillée au chapitre suivant, pour l’instant gardons les choses simples.
C:\Users\Nicolas DUMINIL>aws ec2 authorize-security-group-ingress
--group-name amisecgroup --protocol http --port 22 --cidr 0.0.0.0/0
C:\Users\Nicolas DUMINIL>aws ec2 authorize-security-group-ingress
--group-name amisecgroup --protocol http --port 80 --cidr 0.0.0.0/0 Ajouter des règles de sécurité
Ici, nous ajoutons à notre groupe de sécurité deux règles de sécurité consistant à ouvrir le trafic entrant sur les ports 22 et 80, pour le protocole TCP, afin de laisser passer les flux SSH et HTTP.
4. Étape 4 - démarrage de l’instance
Tous les éléments sont configurés...
Gestion des instances AWS avec Terraform
Terraform est un véritable langage de programmation IAC et, en tant que tel, il adopte une approche différente d’AWS CLI qui ne propose, lui, qu’un enchaînement de commandes disparates. Ainsi, un script Terraform peut utiliser des variables et interpoler leur contenu de manière à augmenter le caractère abstrait du traitement. Le listing suivant montre le script Terraform qu’on va utiliser pour la création de notre infrastructure.
terraform {
required_version = ">= 0.11, < 0.12"
}
provider "aws" {
region = "eu-west-3"
version = "~> 1.53"
}
variable "key_name" {
type = "string"
default = "amikey"
}
resource "tls_private_key" "example" {
algorithm = "RSA"
rsa_bits = 4096
}
resource "aws_key_pair" "generated_key" {
key_name = "${var.key_name}"
public_key = "${tls_private_key.example.public_key_openssh}"
}
resource "aws_instance" "a_test_instance" {
ami = "ami-17c6736a"
instance_type = "t2.micro"
security_groups = [
"${aws_security_group.a_test_instance_default.name}" ]
key_name = "${aws_key_pair.generated_key.key_name}"
tags {
ServerType = "WebServer"
}
}
resource "aws_security_group" "a_test_instance_default" {
name = "a_test_instance_default"
description = "Default security group that allows inbound and
outbound traffic from all instances in the VPC"
ingress {
from_port = "22"
to_port = "22"
protocol = "tcp"
cidr_blocks = [
"0.0.0.0/0"]
}
ingress {
from_port = "80"
to_port = "80" ...
