Différences

Ci-dessous, les différences entre deux révisions de la page.

--- eadl:bloc5:fm3:td2 [2026/09/27 18:05] – [1.2 Choisir les logiciels] jcheron
+++ eadl:bloc5:fm3:td2 [2026/09/28 15:37] (Version actuelle) – jcheron
@@ Ligne 13: / Ligne 13: @@
 Ce TD utilise la console AWS et quelques commandes exécutées depuis un terminal. Il s’agit d’une découverte **manuelle** d’Amazon EMR. N’utilisez ni Terraform ni CloudFormation dans ce TD : l’automatisation de cette infrastructure fera l’objet du TD3.
-AWS est un environnement payant. Chaque binôme doit utiliser le compte, la région et les limites de coûts indiqués par l’enseignant. Ne créez aucune ressource supplémentaire.
+AWS est un environnement payant. Pensez à activer une alerte sur AWS Budget si vous dépassez une limite de 5$.
 </WRAP>
@@ Ligne 81: / Ligne 81: @@
   - récupérez `mapper.py` et `reducer.py` du TD1 ;
   - vérifiez que vous avez accès à la console AWS ;
-  - sélectionnez la région demandée par l’enseignant ;
+  - sélectionnez la région AWS ''eu-west-3''.
-  - récupérez ou créez une paire de clés EC2 selon la procédure du cours ;
-  - identifiez le bucket S3 attribué à votre binôme ou créez-en un uniquement si l’enseignant l’autorise.
-<WRAP important round>
-**Ne mettez jamais une clé AWS, un mot de passe, une clé privée SSH ou un jeton dans un fichier envoyé sur S3.** Une clé SSH privée doit rester sur votre poste, avec des permissions restrictives :
-<sxh bash;gutter:false>
-chmod 400 ma-cle-emr.pem
-</sxh>
-</WRAP>
 ----
@@ Ligne 139: / Ligne 129: @@
 | Applications non sélectionnées | Pig, Oozie, HBase, Presto, Trino, Zeppelin, Flink, TensorFlow, Zookeeper, Phoenix, Hue, JupyterHub, HCatalog, AmazonCloudWatchAgent | hors périmètre du TD (streaming, NoSQL, ML, orchestration, monitoring avancé) |
+<WRAP info round>
 **Remarque** : YARN, HDFS et MapReduce ne sont pas des cases à cocher séparées dans la console EMR — ils font partie intégrante du socle Hadoop installé dès que "Hadoop" est sélectionné (ce qui est automatique avec l'offre Spark Interactive). Il n'y a donc pas de choix à faire les concernant, seulement à vérifier leur présence et leur version dans les détails du cluster une fois créé.
+</WRAP>
 ===== 1.3 Comprendre les nœuds =====
-Dans la section matériel / instance groups ou instance fleets, choisissez une configuration pédagogique petite. Une configuration typique est :
+Dans la section matériel, la console AWS propose un choix entre **groupes d'instances uniformes** (par défaut) et **flottes d'instances flexibles**. Gardez le mode par défaut pour ce TD.
-  * **1 nœud primaire (master)** ;
+La console affiche alors trois rôles :
-  * **2 nœuds core** ;
-  * **0 ou 1 nœud task** selon le quota et la consigne de l’enseignant.
-Le type d’instance doit être celui autorisé dans votre compte de formation. Pour ce TD, cherchez une instance généraliste peu coûteuse, avec suffisamment de mémoire pour Hadoop. Ne choisissez pas une instance accélérée ou surdimensionnée « pour aller plus vite » sans validation.
+  * **Primaire** ;
+  * **Unité principale** ;
+  * **Tâche - 1** (et suivantes si plusieurs nœuds de ce type).
+Remplacez le type d'instance par défaut par une instance généraliste standard, plus universellement compatible :
 <sxh text>
-Exemple pédagogique à adapter aux quotas du compte :
+Configuration recommandée pour ce TD :
-  Primary / Master : 1 instance généraliste
+  Primaire         : m5.xlarge
-  Core            : 2 instances généralistes
+  Unité principale : m5.xlarge
-  Task            : 0 au départ
+  Tâche - 1        : m5.xlarge
 </sxh>
-^ Groupe EMR ^ Nombre choisi ^ Type d’instance ^ Rôle attendu ^
+^ Groupe EMR ^ Nombre choisi ^ Type d'instance ^ Rôle attendu ^
-| Primary / Master |  |  | services de coordination, NameNode, ResourceManager |
+| Primaire | 1 | m5.xlarge | services de coordination, NameNode, ResourceManager |
-| Core |  |  | stockage HDFS et exécution YARN |
+| Unité principale | 1 | m5.xlarge | stockage HDFS et exécution YARN |
-| Task |  |  | exécution YARN sans stockage HDFS durable du cluster |
+| Tâche - 1 | 1 | m5.xlarge | exécution YARN sans stockage HDFS durable du cluster |
+<WRAP tip round>
+La famille **m5** est une famille d'instances généralistes (x86_64, Intel), le choix le plus répandu et documenté pour EMR/Hadoop. Elle offre un bon équilibre CPU/mémoire, suffisant pour ce TD.
+À noter : avec une seule instance d'unité principale, la réplication HDFS par défaut (facteur 3) ne peut pas être pleinement respectée (il faudrait au moins 3 instances d'unité principale pour avoir 3 copies sur des machines différentes). C'est acceptable dans ce contexte pédagogique à petite échelle, mais c'est un point à mentionner dans vos observations si on vous interroge sur la tolérance aux pannes de ce cluster.
+</WRAP>
 ===== 1.4 Faire le rapprochement avec le TD1 =====
@@ Ligne 179: / Ligne 180: @@
   - Le nombre de nœuds choisi suffit-il à démontrer une tolérance de panne réelle ? Pourquoi ?
-===== 1.5 Configurer les rôles IAM =====
+===== 1.5 Réseau =====
-La console propose des rôles IAM pour EMR et EC2, souvent créés automatiquement ou sélectionnés parmi des rôles par défaut :
+Sur un compte AWS standard, un **VPC par défaut** existe déjà dans chaque région, avec un subnet public dans chaque zone de disponibilité. EMR le sélectionne automatiquement : **il n'y a rien à créer ni configurer manuellement** pour ce TD.
-  - rôle de service EMR ;
+Dans la section réseau de l'assistant de création :
-  - profil d’instance EC2 pour les nœuds ;
-  - rôle souvent associé à l’auto-scaling selon les options retenues.
-Utilisez les rôles pédagogiques déjà fournis lorsque l’enseignant les a préparés. Sinon, choisissez l’option de création recommandée par la console, sans ajouter de permissions administrateur « pour simplifier ».
+. vérifiez que le VPC proposé est bien le VPC par défaut (``vpc-xxxxxxxx (default)``) ;
+. un subnet est présélectionné : laissez la valeur proposée ;
+. les security groups sont créés automatiquement par EMR (un pour le master, un pour les core/task) si vous ne modifiez rien.
-^ Élément IAM ^ Valeur sélectionnée ^ À quoi sert-il ? ^
+Notez les valeurs proposées automatiquement :
-| EMR service role |  | autoriser EMR à gérer les ressources nécessaires |
-| EC2 instance profile |  | permettre aux instances d’appeler les services autorisés, notamment S3 selon la configuration |
-| Rôle d’auto-scaling |  | seulement si l’option est utilisée |
-<WRAP important round>
+^ Paramètre réseau ^ Valeur ^ Observation ^
-**Ne confondez pas authentification et autorisation.** La clé SSH permet l’accès système à une instance autorisée. Les rôles IAM permettent aux services et aux instances d’appeler d’autres services AWS. Une clé SSH ne donne pas, à elle seule, les droits S3.
+| VPC |  | par défaut |
+| Subnet |  | public (zone de disponibilité) |
+| Security group master |  | créé automatiquement par EMR |
+| Security group core/task |  | créé automatiquement par EMR |
+| Adresse publique du master |  | oui, par défaut sur subnet public |
+<WRAP tip round>
+Le security group du master créé par défaut n'autorise pas le SSH entrant. Il faudra l'ouvrir manuellement après la création du cluster (voir section suivante) pour pouvoir vous connecter.
 </WRAP>
-Question : quelles permissions minimales votre job doit-il avoir pour lire `s3://.../input/` et écrire `s3://.../output/` ? Pourquoi est-il préférable de limiter les droits au bucket et aux préfixes du TD ?
+Répondez :
-===== 1.6 Choisir le réseau =====
+  - Pourquoi un cluster peut-il avoir besoin d'une communication interne même si vous ne vous connectez qu'au master ?
+  - Pourquoi les nœuds core et task ne doivent-ils généralement pas être ouverts directement à Internet ?
+  - Dans Docker Compose, quelles règles de réseau étaient implicites ou locales ?
+===== 1.6 Paire de clés EC2 (accès SSH) =====
-Dans la section réseau :
+Pour pouvoir se connecter en SSH au nœud primaire du cluster (console, exécution manuelle de commandes Hadoop, consultation de fichiers de logs), une **paire de clés EC2** est nécessaire.
-. sélectionnez le VPC pédagogique indiqué ;
+  - Si vous possédez déjà une paire de clés EC2 dans la région utilisée, vous pouvez la réutiliser.
-. choisissez le subnet autorisé ;
+  - Sinon, créez-en une nouvelle **avant** de lancer le cluster :
-. si le master doit être joint en SSH depuis Internet, vérifiez que le subnet est public et qu’une route vers une Internet Gateway existe, selon la consigne de l’enseignant ;
-. choisissez ou créez les security groups recommandés par la formation ;
-. activez l’accès SSH uniquement depuis votre adresse IP lorsque la console le permet, jamais depuis `0.0.0.0/0` sauf démonstration explicitement encadrée et immédiatement supprimée.
-Notez :
+<sxh text>
+Étapes (en dehors de la création du cluster EMR) :
+  EC2 > Réseau et sécurité > Paires de clés > Créer une paire de clés
+  Nom : td-hadoop-votrenom
+  Type de clé : RSA
+  Format de fichier privé :
+     - .pem si vous vous connectez depuis Linux/Mac ou WSL
+     - .ppk si vous utilisez PuTTY sous Windows
+</sxh>
-^ Paramètre réseau ^ Valeur ^ Observation ^
+<WRAP important>
-| VPC |  |  |
+Le fichier de clé privée est **téléchargé une seule fois**. Conservez-le précieusement (par exemple dans votre dossier utilisateur, avec des droits restreints) : il ne pourra pas être retéléchargé depuis la console AWS.
-| Subnet |  | public, privé ou autre |
-| Security group master |  | ports autorisés |
-| Security group core/task |  | accès interne entre nœuds |
-| Adresse publique du master |  | oui / non |
-Répondez :
+Sous Linux/Mac, pensez à restreindre les droits du fichier avant de l'utiliser :
+<sxh bash>
+chmod 400 td-hadoop-votrenom.pem
+</sxh>
+</WRAP>
-  - Pourquoi un cluster peut-il avoir besoin d’une communication interne même si vous ne vous connectez qu’au master ?
+Dans la configuration du cluster EMR, section **Sécurité**, sélectionnez cette paire de clés dans le menu déroulant **Paire de clés EC2 (SSH)**.
-  - Pourquoi les nœuds core et task ne doivent-ils généralement pas être ouverts directement à Internet ?
-  - Dans Docker Compose, quelles règles de réseau étaient implicites ou locales ?
+===== 1.7 Rôles IAM =====
+EMR nécessite deux rôles IAM pour fonctionner :
+  * un **rôle de service EMR** (permet à EMR de gérer les ressources EC2, réseau, etc. en votre nom) ;
+  * un **rôle de profil d'instance EC2** (attaché aux nœuds du cluster, permet l'accès à S3, CloudWatch, etc.).
+Dans la section **Rôle IAM**, AWS propose deux options pour chacun de ces deux rôles :
+  * **Choisir une fonction du service existant** : sélectionne un rôle déjà créé auparavant ;
+  * **Créer une fonction du service** : AWS crée automatiquement le rôle nécessaire.
+<WRAP tip round>
+**Cas attendu : votre compte est un compte AWS standard (personnel, free tier ou passé en basic)**
+Sur ce type de compte, vous disposez normalement des droits IAM complets. Choisissez **Créer une fonction du service** pour les deux champs. AWS génère automatiquement les rôles nécessaires, généralement nommés :
+  - ``EMR_DefaultRole`` ou ``AmazonEMR-ServiceRole-xxxx`` (rôle de service) ;
+  - ``EMR_EC2_DefaultRole`` ou ``AmazonEMR-InstanceProfile-xxxx`` (profil d'instance EC2).
+Ces rôles seront ensuite proposés automatiquement lors des prochaines créations de cluster. C'est le cas normal et attendu pour ce TD.
+</WRAP>
+<WRAP important>
+**Cas exceptionnel : erreur de création (droits IAM restreints ou rôle déjà partiellement créé)**
+Il peut arriver, même sur un compte standard, qu'**un des deux rôles existe déjà** (par exemple suite à un essai antérieur) **sans que le second n'existe**. Ce n'est pas incohérent : ce sont deux ressources IAM indépendantes.
+Si vous tentez **Créer une fonction du service** pour le champ **Fonction du service EC2** et obtenez une erreur du type :
+<code>
+Échec de la création du rôle EMR_EC2_DefaultRole. Vous n'obtenez peut-être pas l'autorisation nécessaire pour effectuer cette action.
+</code>
+**Marche à suivre dans ce cas :**
+  - Retournez sur **Choisir une fonction du service existant** pour le champ **Fonction du service EC2** ;
+  - vérifiez si un rôle apparaît dans la liste déroulante, par exemple ``EMR_EC2_DefaultRole`` (déjà créé lors d'un essai précédent) ;
+  - sélectionnez-le s'il apparaît.
+</WRAP>
-===== 1.7 Associer la clé SSH et créer le cluster =====
+===== 1.8 Associer la clé SSH et créer le cluster =====
 . Sélectionnez la paire de clés EC2 fournie ou créée pour le TD.
@@ Ligne 237: / Ligne 288: @@
 </WRAP>
-===== Bilan de la mission 1 =====
-Complétez :
-  - Le temps entre le clic sur « créer » et l’état utilisable est de : `__________`.
-  - Les choix qui ont demandé le plus de réflexion sont : `__________`.
-  - La différence principale entre un cluster EMR et les conteneurs du TD1 est : `__________`.
-----
 ====== Mission 2 — Explorer le cluster depuis le master ======
@@ Ligne 261: / Ligne 303: @@
 </sxh>
-Le nom d’utilisateur dépend de l’image et de la configuration affichées par l’enseignant. Pour une AMI EMR standard, `hadoop` est couramment utilisé ; ne remplacez pas ce nom au hasard si la consigne de votre compte indique autre chose.
+Le nom d’utilisateur dépend de l’image. Pour une AMI EMR standard, `hadoop` est couramment utilisé ; ne remplacez pas ce nom au hasard si la consigne de votre compte indique autre chose.
 À la première connexion, vérifiez l’empreinte proposée. Si vous obtenez `Permission denied (publickey)`, contrôlez le chemin de la clé, `chmod 400`, le nom d’utilisateur et la règle SSH du security group.
@@ Ligne 348: / Ligne 390: @@
 ===== 3.2 Mettre en place un tunnel local =====
-Gardez une première session SSH ouverte. Dans un second terminal, créez des redirections locales vers les ports web du master. Les numéros de ports peuvent varier selon la release ; utilisez ceux affichés dans la console ou par l’enseignant.
+Gardez une première session SSH ouverte. Dans un second terminal, créez des redirections locales vers les ports web du master. Les numéros de ports peuvent varier selon la release ; utilisez ceux affichés dans la console.
 <sxh bash>
@@ Ligne 576: / Ligne 618: @@
 </sxh>
-Hadoop refuse généralement d’écrire dans un répertoire de sortie déjà présent. Utilisez un nouveau préfixe ou supprimez uniquement votre ancien résultat de test si l’enseignant l’autorise.
+Hadoop refuse généralement d’écrire dans un répertoire de sortie déjà présent.
 ===== 5.3 Lancer le job =====
@@ Ligne 661: / Ligne 703: @@
 | Task |  |  |  |  |
-Le coût réel dépend notamment de la région, du type d’instance, du modèle de facturation, des options EMR, du stockage et d’éventuels transferts. Utilisez l’outil d’estimation ou la page tarifaire validée par l’enseignant plutôt que de mémoriser un montant.
+Le coût réel dépend notamment de la région, du type d’instance, du modèle de facturation, des options EMR, du stockage et d’éventuels transferts.
 Pour une estimation simplifiée :
@@ Ligne 766: / Ligne 808: @@
 <sxh bash>
 aws s3 ls s3://NOM_DU_BUCKET/td2/binomeXX/ --recursive
-# À exécuter seulement si l'enseignant demande la suppression :
 aws s3 rm s3://NOM_DU_BUCKET/td2/binomeXX/ --recursive
 </sxh>
@@ Ligne 870: / Ligne 911: @@
 <WRAP important round>
-Dernière vérification avant de quitter AWS : votre cluster est terminé, vos instances de test ne tournent plus, et les objets S3 restants correspondent exactement à la consigne de l’enseignant.
+Dernière vérification avant de quitter AWS : votre cluster est terminé, vos instances de test ne tournent plus, et les objets S3 sont supprimés.
 </WRAP>