Déploiement d’une application sur l’infrastructure AMAZON (1/3)

Ce premier billet est le point de départ d’une série de 3 articles consacrés à un retour d’expérience sur la mise en œuvre d’une application sur la plateforme cloud-computing d’AMAZON (AWS – AMAZON Web Services).

Voici brièvement le contexte : nous sommes en janvier 2010, sur une étude qui doit traiter l’offre AMAZON selon les points suivants :

  • Facilité de mise en œuvre
  • Montée en charge
  • Coût

Les deux premiers articles combinent deux formes : source d’information et tutoriel, tandis que la dernière partie est une synthèse moins technique.

Dans ce premier billet, nous verrons le pourquoi du choix AMAZON puis après une rapide description des services proposés, nous détaillerons l’utilisation d’EC2 – la partie exécution.

Pourquoi AMAZON ?

La liste des compagnies qui offrent des services liés au cloud-computing est assez conséquente. Quelles plateformes sont les plus pertinentes ? Trois noms reviennent fréquemment : AMAZON, GOOGLE et MICROSOFT. Les autres acteurs, comme Salesforces.com, RightScale, GoGrid et bien d’autres, ont eux aussi des offres pertinentes. Il n’en reste pas moins que les « big three » sont incontournables, que ce soit par leur statut de précurseur du cloud-computing (cas d’AMAZON) ou bien leur position de leader sur le secteur informatique (cas de GOOGLE et MICROSOFT).

Le choix d’AMAZON répond aux critères de sélection définis au lancement de l’étude, à savoir : une plateforme qui impacte le plus faiblement possible la portabilité des applications, que ce soit pour porter une application interne sur le cloud ou bien rapatrier une application du cloud vers une infrastructure interne, tout en étant intéressante au niveau des coûts. Nous plaçons donc la portabilité et le coût comme critères clés.

Le critère du coût n’est pas déterminant puisque les trois offres semblent être alignées.

Il reste donc l’aspect portabilité pour différencier les trois prétendants. A ce stade, je vous invite à consulter l’article de Marc BOJOLY sur la segmentation des offres de cloud Computing. Outre la classification par types de contrats (IAAS, PAAS, SAAS), l’un des points importants relevé par Marc est que le choix d’une solution PAAS créera un lien entre le fournisseur et le client puisque les applicatifs devra utiliser une API propre au fournisseur. A contrario une solution IAAS préservera l’indépendance de l’application vis à vis du contexte d’exécution. Etant la seule offre IAAS, notre choix s’est porté sur AMAZON.

Néanmoins, il convient de modérer la « portabilité » d’AMAZON selon les services utilisés. En effet, la partie exécution d’AWS offre une grande indépendance vis à vis de la plateforme puisqu’elle basée sur des machines virtuelles gérées par l’utilisateur. Mais cela devient de moins en moins vrai au fur et à mesure que l’on intègre d’autres services AWS tels que la messagerie middleware (SQS) ou le stockage non-relationnel (SimpleDB), puisque même si ils reposent sur des standards (SOAP/REST), ces services nécessiteront des modifications de code lors d’un rapatriement depuis AWS. A contrario, les choix de GOOGLE avec notamment son système de base de données issus de sa R&D (BigTable) et les limitations de prises en charge de certaines librairies JAVA, offriront une plus grande rapidité de développement et une promesse de scalabilité plus importante en compensation d’une portabilité limitée. AMAZON propose donc une plateforme plus intéressante que celle de GOOGLE si l’on privilégie la portabilité.



Les services d’AMAZON

Brièvement

Par souci de clarté, avant d’aller plus loin dans la description des services AMAZON que nous avons utilisés, en voici un bref récapitulatif. Pour plus de détails, vous pouvez consulter l’article de Marc BOJOLY.

  • Exécution : Elastic Cloud Compute – EC2. C’est la partie exécution de la plateforme AMAZON. EC2 repose sur des machines virtuelles appelées instances une fois lancées.
  • Stockage
    • Elastic Block Storage – EBS. Un EBS est un stockage vu comme un disque physique par une instance EC2. Une instance peut avoir plusieurs EBS. Le cycle de vie d’une EBS est indépendant des instances EC2 auxquelles il a été attaché. AMAZON assure la réplication des EBS et offre la possibilité d’en faire des snapshots pour créer de nouveaux EBS
    • Simple Storage Service – S3. Solution de stockage sur Internet qui met en avant la disponibilité du système et des données en plus d’une grande simplicité d’utilisation.
  • Base de données
    • Simple DB. Gestion de données non relationnelles où l’on crée des tables mais aucune liaison entre elles ne peut être implémentée par le service.
    • Relational Data Base – RDS. SGBDR basé sur MySQL
  • Middleware : Simple Queue Service – SQS. Messagerie middleware de type MOM
  • Monitoring / gestion des instances
    • CloudWatch. Service pour la surveillance des ressources qui agrège un certain nombre de données : utilisation CPU, disques, réseaux
    • AutoScaling : Permet d’augmenter ou diminuer le nombre d’instances EC2 pour répondre à des variations de charges

Elastic Compute Cloud – EC2

Il s’agit de la brique de base de toute application s’exécutant sur AWS. EC2 permet à un utilisateur de lancer plusieurs instances EC2 en parallèle à partir de la même image. Le Service Level Agreement est de 99,95 % soit un peu plus de 4 heures 20 minutes de pannes par an.

Le service EC2 est indissociable de la notion d’Amazon Machine Image – AMI. L’AMI est en effet l’image d’une machine virtuelle qui va être exécutée. Puisqu’EC2 repose sur une virtualisation XEN, il est assez aisé de déplacer des serveurs XEN vers EC2.

Pour utiliser EC2, un utilisateur lambda doit suivre les étapes suivantes :

  • Obtenir une AMI correspondante à ses besoins. Deux possibilités se présente à lui, soit identifier l’AMI qui lui convient parmi celles qui sont disponibles, soit créer sa propre AMI contenant les applicatifs, données et configurations propres à son usage
  • Lors du lancement de la machine virtuelle, choisir le profil des ressources matérielles à allouer (CPU, RAM, espace disque) pour l’AMI. Ce choix n’est pas sans conséquence puisque le rapport de prix entre la configuration matérielle la moins chère et la plus chère peut être de 30. Aujourd’hui il existe 8 profils matériels, de 1.7 Go de RAM avec un CPU 1.2 GHz jusqu’au très haut de gamme : 64 Go RAM, 8 cœurs à 3.6 GHz
  • L’utilisateur pourra alors effectuer les actions standards : arrêter la machine, rajouter des instances du même type …

Nous en reparlerons dans les billets suivants mais l’API EC2 peut être appelée de différentes manières :

  • Deux ensembles de lignes de commande JAVA : le premier est dédié aux AMI, le second aux instances EC2
  • Une console WEB : AWS Management Console.
  • Les librairies existantes : JAVA, PHP, RUBY, .Net
  • L’appel direct aux web-services SOAP ou de type Query

AMAZON Machine Image

Les AMI sont des images de machines virtuelles. Elles peuvent être publiques (visibles par tout utilisateur AWS) ou privées (visibles par un seul utilisateur AWS), gratuites ou payantes.

De plus, une distinction est faite entre les AMI qui sont stockées sur un instantané de volume EBS (EBS backed AMI) et celles stockées directement dans S3 (instance store).

Voici un comparatif des deux types d’AMI :

Caractéristique EBS backed AMI Instance Store
Temps de démarrage Moins d’une minute Moins de 5 minutes
Taille limite 1 To 10 Go
Emplacement Volume EBS S3
Persistance des données Les données persistent en cas d’arrêt imprévu et peuvent persister après un arrêt de l’instance EC2 Les données persistent aussi longtemps que l’instance EC2 est en exécution. Il est possible de monter des volumes EBS en supplément
Mise à jour Le type d’instance, la RAM et les données utilisateur peuvent être changé lorsque l’instance est arrêtée Les attributs de l’instance EC2 sont figés tant que l’instance est lancée
Tarification Selon l’utilisation de l’instance EC2 et du volume EBS. En outre, le stockage de l’AMI sur l’instantané EBS est payant Selon l’utilisation de l’instance EC2 plus le stockage de l’AMI sur S3.
Création de l’AMI Appel à une seule commande Requiert l’installation d’outils spécifiques (AMI tools)
Arrêt Peut être placée dans un état d’arrêt (équivalent d’un état de pause) où l’instance EC2 n’est pas en exécution mais peut être relancée. L’instance est en exécution ou non. Une fois terminée, l’instance ne peut pas être récupérée.

Dans notre cas, nous avons opté pour des AMI ‘instance store’ pour deux raisons :

  • Chaque EBS crée génère un coût d’utilisation supplémentaire
  • La limite de taille des AMI Instance Store à 10 Go ne constituait pas un problème dans notre cas

Il existe des centaines d’AMI avec une large variété d’OS (Windows, Linux, Solaris).

Voici comment créer une AMI instance store contenant à partir d’une AMI Ubuntu.

  • Pour commencer il faut effectuer un certain nombre de pré requis :
    • Créer un compte AMAZON AWS
    • Copier sur votre machine le couple certificat X509/clé privée attribué par AMAZON, ainsi qu’une clé privée générée pour EC2. Dans la suite, cette clé est nommée key1.pem
    • Installer les outils en ligne de commande et configurer certaines variables d’environnement : EC2_CERT, EC2_HOME, EC2_URL, EC2_KEY
    • Ensuite il convient de trouver l’identifiant (AMI-id) d’une AMI qui approche le plus possible celle que vous désirez obtenir. Comment faire ? AWS Management Console permet de rechercher selon certains filtres (plateforme, architecture 32 ou 64 bits, publique ou privée) mais le gros défaut est que l’on a très peu d’informations sur le contenu de l’AMI. Même remarque pour la commande ec2-describe-images qui propose moins de filtres que l’AWS Management Console. Finalement, la meilleure solution est de chercher sur des sites spécialisés tels que CloudMarket. Pour la suite de l’exemple, nous prendrons l’AMI ami-605b7014 qui est fournie par ALESTIC, un site spécialisé dans les AMI Ubuntu.
    • Avant de lancer une instance, il nous faut définir un groupe de sécurité (rôle qui définit des règles de pare-feu) qui lui sera attaché. Le rôle par défaut (default) n’a aucun droit, c’est à dire qu’il est impossible d’accéder à une machine depuis l’extérieur du Datacenter. Dans notre cas, nous allons vouloir nous connecter à notre instance par ssh et transférer des fichiers par sftp. C’est pourquoi nous allons ouvrir le port 22. ATTENTION : nous ne le faisons pas dans cet exemple, mais il recommandé d’ajouter un filtrage sur l’IP source lors d’une ouverture de port

  • La commande ec2-run-instances permet de lancer l’instance en précisant la clé et le groupe de sécurité à utiliser. La commande retourne entre autres l’identifiant de la machine virtuelle. Nous pouvons alors connaître l’état de l’instance grâce à ec2-describe-instances qui nous retourne son DNS public une fois qu’elle est lancée.

  • L’installation de vos applications passera sans doute par
    • une connexion distante ssh

Ssh –i key.pem ubuntu @ec2-79-125-39-141.eu-west-1.compute.amazonaws.com

  • du transfert de fichier sftp

  • Vous pouvez ensuite créer votre AMI grâce aux utilitaires qui sont déjà installé dans l’AMI ALESTIC. Le cas échéant, c’est à vous de les installer. Avant de débuter la création d’AMI, vous devez préalablement copier sur l’instance EC2 les fichiers suivants : le certificat X.509 et sa clé associée respectivement nommés : cert-XXXXXX.pem et pk-XXXXXXXX.pem. De plus vous devrez fournir l’ACCESS KEY ID et la clé secrète associée ainsi que votre AWS account id. Tous ces éléments sont accessibles depuis le site d’AMAZON dans la section Security Credentials. Maintenant, exécutez les commandes suivantes

ec2-bundle-vol -k pk-XXXXXXXX.pem -c cert-XXXXXX.pem -u votre_uid_sans_tiret –r i386

ec2-upload-bundle -b bucket_de_destination -m image.manifest.xml -a votre_access_key_id -s votre_cle_secrete

ec2-register bucket_de_destination /image.manifest.xml -n votre_nom_d_image, qui retourne l’ami-id de la nouvelle AMI.

  • Tester l’AMI créée
  • Arrêter l’instance EC2 initiale

Pour ceux qui sont allergiques aux lignes de commande, voici un tutoriel qui explique comment lancer une instance EC2 et s’y connecter avec AWS Management Console.

Il est aussi possible de convertir des images au format AMI vers ou depuis des images VMWare.

2 commentaires sur “Déploiement d’une application sur l’infrastructure AMAZON (1/3)”

  • >Le Service Level Agreement est de 99,95 % soit un peu plus de 3 heures 30 de pannes par mois. n'y a t'il pas une erreur de calcul ?
  • Autant pour moi! Merci de le signaler, c'est corrigé.
    1. Laisser un commentaire

      Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *


      Ce formulaire est protégé par Google Recaptcha