Différences

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

--- eadl:bloc5:fm3:td2 [2026/09/27 19:44] – [1.4 Paire de clés EC2 (accès SSH)] jcheron
+++ eadl:bloc5:fm3:td2 [2026/09/28 07:17] (Version actuelle) – [5.2 Vérifier les chemins S3] jcheron
@@ Ligne 180: / 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 Associer la clé SSH et créer le cluster =====
+===== 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.
+**Si l'erreur persiste ou si aucun rôle n'apparaît**, signalez-le à l'enseignant : cela peut indiquer une restriction particulière sur votre compte à vérifier.
+</WRAP>
+===== 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 238: / Ligne 290: @@
 </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 262: / Ligne 305: @@
 </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 577: / Ligne 620: @@
 </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 =====