eadl:bloc5:fm3:td2

Différences

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

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision
Révision précédente
eadl:bloc5:fm3:td2 [2026/09/27 19:43] – [Préparation — vérifier les éléments disponibles] jcheroneadl:bloc5:fm3:td2 [2026/09/28 07:17] (Version actuelle) – [5.2 Vérifier les chemins S3] jcheron
Ligne 162: Ligne 162:
 </WRAP> </WRAP>
  
-===== 1.4 Paire de clés EC2 (accès SSH) =====+ 
 +===== 1.4 Faire le rapprochement avec le TD1 ===== 
 + 
 +Complétez le tableau avant de poursuivre. Une case peut contenir plusieurs services : EMR décrit des **rôles de nœuds**, et non une correspondance stricte « un conteneur = un service ». 
 + 
 +^ Dans EMR ^ Dans le TD1 Docker Compose ^ Services principalement associés ^ Peut contenir des blocs HDFS ? ^ 
 +| Primary / Master |  |  |  |  
 +| Core |  |  |  |  
 +| Task |  |  |  |  
 + 
 +Répondez : 
 + 
 +  - Dans le TD1, quel conteneur jouait le rôle du NameNode ? Et du ResourceManager ? 
 +  - Pourquoi les nœuds core portent-ils généralement les DataNodes ? 
 +  - Pourquoi un nœud task ne doit-il pas être considéré comme une copie supplémentaire des données HDFS ? 
 +  - Dans un cluster réel, que se passe-t-il si vous ajoutez 10 nœuds task mais aucun nœud core ? 
 +  - Le nombre de nœuds choisi suffit-il à démontrer une tolérance de panne réelle ? Pourquoi ? 
 + 
 +===== 1.5 Réseau ===== 
 + 
 +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. 
 + 
 +Dans la section réseau de l'assistant de création : 
 + 
 +  1. vérifiez que le VPC proposé est bien le VPC par défaut (``vpc-xxxxxxxx (default)``) ; 
 +  2. un subnet est présélectionné : laissez la valeur proposée ; 
 +  3. les security groups sont créés automatiquement par EMR (un pour le master, un pour les core/task) si vous ne modifiez rien. 
 + 
 +Notez les valeurs proposées automatiquement : 
 + 
 +^ Paramètre réseau ^ Valeur ^ Observation ^ 
 +| 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> 
 + 
 +Répondez : 
 + 
 +  - 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) =====
  
 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. 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.
Ligne 190: Ligne 236:
 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)**. 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)**.
  
-===== 1.4 Faire le rapprochement avec le TD1 =====+===== 1.7 Rôles IAM =====
  
-Complétez le tableau avant de poursuivre. Une case peut contenir plusieurs services : EMR décrit des **rôles de nœuds**, et non une correspondance stricte « un conteneur = un service ».+EMR nécessite deux rôles IAM pour fonctionner :
  
-^ Dans EMR ^ Dans le TD1 Docker Compose ^ Services principalement associés ^ Peut contenir des blocs HDFS ? ^ +  * un **rôle de service EMR** (permet à EMR de gérer les ressources EC2, réseau, etc. en votre nom) ; 
-| Primary / Master |  |  |  |  +  * un **rôle de profil d'instance EC2** (attaché aux nœuds du cluster, permet l'accès à S3, CloudWatch, etc.).
-| Core |  |  |  |  +
-| Task |  |  |  | +
  
-Répondez :+Dans la section **Rôle IAM**, AWS propose deux options pour chacun de ces deux rôles :
  
-  - Dans le TD1, quel conteneur jouait le rôle du NameNode ? Et du ResourceManager ? +  * **Choisir une fonction du service existant** : sélectionne un rôle déjà créé auparavant ; 
-  - Pourquoi les nœuds core portent-ils généralement les DataNodes ? +  * **Créer une fonction du service** : AWS crée automatiquement le rôle nécessaire.
-  - Pourquoi un nœud task ne doit-il pas être considéré comme une copie supplémentaire des données HDFS ? +
-  - Dans un cluster réel, que se passe-t-il si vous ajoutez 10 nœuds task mais aucun nœud core ? +
-  - 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 =====+<WRAP tip round> 
 +**Cas attendu : votre compte est un compte AWS standard (personnel, free tier ou passé en basic)**
  
-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 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).
  
-  - rôle de service EMR ; +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.
-  - 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 ». +
- +
-^ Élément IAM ^ Valeur sélectionnée ^ À quoi sert-il ? ^ +
-| 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> +
-**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.+
 </WRAP> </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 ?+<WRAP important> 
 +**Cas exceptionnel : erreur de création (droits IAM restreints ou rôle déjà partiellement créé)**
  
-===== 1.6 Choisir le réseau =====+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.
  
-Dans la section réseau :+Si vous tentez **Créer une fonction du service** pour le champ **Fonction du service EC2** et obtenez une erreur du type :
  
-  1. sélectionnez le VPC pédagogique indiqué ; +<code> 
-  2. choisissez le subnet autorisé ; +É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. 
-  3. 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 ; +</code>
-  4. choisissez ou créez les security groups recommandés par la formation ; +
-  5. 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 :+**Marche à suivre dans ce cas :**
  
-^ Paramètre réseau ^ Valeur ^ Observation ^ +  - Retournez sur **Choisir une fonction du service existant** pour le champ **Fonction du service EC2** ; 
-| VPC |  |  |  +  - 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) ; 
-| Subnet |  | public, privé ou autre |  +  - sélectionnez-le s'il apparaît.
-| Security group master |  | ports autorisés |  +
-| Security group core/task |  | accès interne entre nœuds |  +
-| Adresse publique du master |  | oui / non | +
  
-Répondez : +**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>
-  - 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.7 Associer la clé SSH et créer le cluster =====+===== 1.8 Associer la clé SSH et créer le cluster =====
  
 1. Sélectionnez la paire de clés EC2 fournie ou créée pour le TD. 1. Sélectionnez la paire de clés EC2 fournie ou créée pour le TD.
Ligne 265: Ligne 290:
 </WRAP> </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 ====== ====== Mission 2 — Explorer le cluster depuis le master ======
Ligne 289: Ligne 305:
 </sxh> </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. À 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 604: Ligne 620:
 </sxh> </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 ===== ===== 5.3 Lancer le job =====
  • eadl/bloc5/fm3/td2.1790531033.txt.gz
  • Dernière modification : il y a 16 heures
  • de jcheron