Lab Cloud : s’exercer avec des buckets S3, des files SQS et des tables DynamoDB en ligne de commande AWS

Ce lab donne à chaque élève son propre cloud d’entraînement : MiniStack, un émulateur qui répond aux mêmes requêtes que trois services d’Amazon Web Services, S3 pour les fichiers, SQS pour les files de messages et DynamoDB pour les tables. L’élève se sert de la ligne de commande AWS, le même outil que sur le vrai service, ce qu’il tape se transpose donc. Il accompagne le module de pratique du cloud, dont les travaux portent sur des réponses capturées.

Ce n’est pas un lab d’attaque et ce n’est pas AWS. Chaque copie n’a aucune route vers internet ni vers un autre élève, rien n’y est facturé, et elle n’a pas de page web : tout se tape dans le terminal à côté. Seuls les trois services sont activés : Lambda est volontairement désactivé, car ses fonctions exécuteraient le code de l’élève dans la pile.

Ce que les élèves apprennent

Comment on se sert d’un service cloud en ligne de commande : un bucket contient des objets retrouvés par leur clé (aws s3 mb, cp et ls), une file contient des messages qu’on reçoit puis qu’on supprime pour les terminer (aws sqs create-queue, send-message, receive-message et delete-message), et une table contient des éléments rangés sous une clé qu’une requête lit ensemble (aws dynamodb create-table, put-item, get-item et query). Ils lisent les réponses, dont l’erreur pour une clé absente, NoSuchKey pour S3, et découvrent une différence entre services : un élément DynamoDB absent est une réponse vide et non une erreur. Ils voient aussi ce qu’est un émulateur, une copie d’entraînement qui n’est pas le vrai service. Il convient à une introduction à l’informatique en nuage, ou à la partie stockage et messagerie d’un cours de génie logiciel.

Le lancer dans votre navigateur

Le lab démarre un seul service, cloud, et attend qu’il réponde. Le terminal a la ligne de commande AWS mais aucune clé pour la pile, la leçon commence donc par donner une clé inventée, une région et l’adresse de la pile, http://cloud:4566. La pile ne vérifie aucun mot de passe, et sur le vrai AWS vous ne donneriez pas l’adresse.

  1. Ouvrir la page Conteneur. Ouvrez « Créer » dans la barre et choisissez « Lancer un conteneur ». Tout le monde peut ouvrir la page, et le lab Git et le lab SQL se lancent sans compte. Tous les autres labs demandent un compte gratuit : créez-en un, connectez-vous, puis appuyez sur « Démarrer ».
  2. Trouver le lab. La carte « Laboratoires d’exemple » liste tous les exemples. Trouvez Cloud (MiniStack).
  3. Appuyer sur Démarrer. « Démarrer » le lance tel quel, en un clic. « Modifier le fichier d’abord » ouvre le fichier compose pour que vous puissiez le changer avant de démarrer.
  4. L’ouvrir. Sur la page du lab, appuyez sur « Ouvrir le terminal ». Il n’y a aucun lien sous « Dans votre navigateur », car la pile n’a pas de page web. Tapez export AWS_ACCESS_KEY_ID=test AWS_SECRET_ACCESS_KEY=test AWS_DEFAULT_REGION=us-east-1 AWS_ENDPOINT_URL=http://cloud:4566, puis aws s3 mb s3://lab-bucket, et le terminal répond make_bucket: lab-bucket. aws s3 ls le liste.

Que demander aux élèves de rendre

Les réponses d’une courte session à eux : un bucket avec un objet envoyé, listé et lu, une file avec un message envoyé, reçu et supprimé, une table avec un élément ajouté, lu et interrogé, et l’erreur pour une clé absente. Puis une phrase sur ce que MiniStack n’est pas. Une bonne réponse dit que c’est un émulateur, une copie d’entraînement, et non AWS.

A basic lesson on this lab

Cloud Services Basics est une petite leçon qui se fait dans ce lab. L’élève y donne la clé et l’adresse, crée un bucket et y range puis lit un objet, demande une clé absente, crée une file et y envoie, reçoit et supprime un message, crée une table et y ajoute, lit et interroge des éléments. Il apprend aussi que seuls trois services sont activés et que ce qu’il crée est conservé quand le lab est arrêté puis relancé.

Les comptes personnels gratuits l’ont dans le module Basics, qui se trouve sur l’« Accueil », chaque établissement peut la copier depuis le dossier Basics de la Bibliothèque, et un nouvel établissement l’a dans un module appelé DevOps Labs (Sample). Elle est volontairement petite : elle montre à un enseignant ce qu’est une leçon qui se fait dans un lab, et le lab fait le reste. Copiez-la dans un module à vous pour la modifier.

Le code sur GitHub

Le fichier compose n’a pas de Dockerfile : il lance une image publique standard, ministackorg/ministack, figée à une version, avec 256 Mo de mémoire et son état dans un volume nommé. MiniStack est sous licence MIT et n’est pas distribué par nous. Un réglage du fichier n’active que S3, SQS et DynamoDB, et toute demande d’un autre service, Lambda compris, est refusée avec une erreur. Le lab n’a aucun accès à internet et aucun mot de passe, puisque rien d’autre ne peut atteindre la pile. C’est un seul service, et un émulateur : des détails des vrais services, comme le numéro de compte dans l’adresse d’une file, diffèrent.

En faire un travail

Indiquez dans la tâche ce qu’il faut rendre.

  1. Créer le lab. Dans votre module, ajoutez une tâche et choisissez la carte « Lab de conteneurs », puis « Dans un dépôt GitHub ». Indiquez https://github.com/mitsurutech/lab-cloud avec la branche main. Le fichier compose par défaut est compose.yaml. Faites d’abord un fork du dépôt si vous voulez le modifier.
  2. Publier et l’essayer. « Publier » fige le commit qui vous a été montré : un changement ultérieur dans le dépôt ne modifie donc pas un lab que vous avez déjà proposé. Démarrez d’abord votre propre copie.
  3. Le distribuer. Attribuez-le comme n’importe quelle tâche, avec une échéance si vous le souhaitez, et indiquez dans la tâche ce qu’il faut faire et ce qu’il faut rendre.
  4. Noter ce qui est rendu. Ouvrez la copie d’un élève et le travail rendu, notez-le et renvoyez-le avec un motif s’il demande un complément.

Essayer ce lab, et ce qu’il coûte

Un compte personnel gratuit permet de suivre les leçons de base de ce lab, avec chaque mois assez de crédit gratuit pour suivre la plupart des leçons, sans carte. Pour une classe, un établissement a ses 365 premiers jours gratuits pour 50 élèves au plus, puis paie par élève et par an, tous les labs compris et les enseignants gratuits.

Questions fréquentes

Est-ce AWS ?
Non. C’est MiniStack, un émulateur qui répond aux mêmes requêtes pour S3, SQS et DynamoDB. Rien n’y est facturé ni ne quitte la copie, et il ne vérifie aucun mot de passe. La ligne de commande AWS est la vraie, ce que les élèves tapent se transpose donc à un compte à eux.
Pourquoi Lambda est-il désactivé ?
Une fonction Lambda est du code que l’élève écrit, et l’émulateur l’exécuterait dans le conteneur même de la pile. Désactiver le service, c’est n’avoir rien pour l’exécuter : une demande pour Lambda est refusée avec une erreur. Le lab enseigne le stockage, les files et les tables, qui n’en ont pas besoin.
Pourquoi la leçon donne-t-elle d’abord une clé et une adresse ?
Le terminal du lab a la ligne de commande AWS mais aucune clé pour la pile. La leçon donne une clé inventée, que l’émulateur ne vérifie pas, et l’adresse de la pile, dont le vrai AWS n’aurait pas besoin.
Que reste-t-il après avoir arrêté puis relancé le lab ?
Les buckets, objets, files et tables que vous avez créés. La pile garde son état dans un volume nommé, que la plateforme conserve, et le relit au démarrage. Le terminal oublie la clé et l’adresse : la première commande de la leçon est à relancer.