Différences
Ci-dessous, les différences entre deux révisions de la page.
| 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] jcheron | eadl:bloc5:fm3:td2 [2026/09/28 07:17] (Version actuelle) – [5.2 Vérifier les chemins S3] jcheron | ||
|---|---|---|---|
| Ligne 162: | Ligne 162: | ||
| </ | </ | ||
| - | ===== 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' | ||
| + | |||
| + | 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' | ||
| + | </ | ||
| + | |||
| + | 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é**, | Dans la configuration du cluster EMR, section **Sécurité**, | ||
| - | ===== 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 | + | EMR nécessite deux rôles |
| - | ^ Dans EMR ^ Dans le TD1 Docker Compose ^ Services principalement associés ^ Peut contenir des blocs HDFS ? ^ | + | * un **rôle de service |
| - | | Primary / Master | | | | | + | |
| - | | Core | | | | | + | |
| - | | Task | | | | | + | |
| - | Répondez | + | Dans la section **Rôle IAM**, AWS propose deux options pour chacun de ces deux rôles |
| - | | + | |
| - | - Pourquoi les nœuds core portent-ils généralement les DataNodes ? | + | |
| - | - Pourquoi | + | |
| - | | + | |
| - | - Le nombre de nœuds choisi suffit-il à démontrer | + | |
| - | ===== 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 | + | Sur ce type de compte, vous disposez normalement |
| + | - ``EMR_DefaultRole`` ou ``AmazonEMR-ServiceRole-xxxx`` (rôle de service) ; | ||
| + | - ``EMR_EC2_DefaultRole`` ou ``AmazonEMR-InstanceProfile-xxxx`` (profil d' | ||
| - | - rôle de service EMR ; | + | Ces rôles |
| - | - profil d’instance EC2 pour les nœuds ; | + | |
| - | - rôle souvent associé à l’auto-scaling selon les options retenues. | + | |
| - | + | ||
| - | Utilisez les rôles | + | |
| - | + | ||
| - | ^ É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 | + | |
| - | + | ||
| - | <WRAP important round> | + | |
| - | **Ne confondez pas authentification | + | |
| </ | </ | ||
| - | Question | + | <WRAP important> |
| + | **Cas exceptionnel | ||
| - | ===== 1.6 Choisir | + | Il peut arriver, même sur un compte standard, qu' |
| - | 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é ; | + | < |
| - | 2. choisissez le subnet autorisé ; | + | Échec de la création du rôle EMR_EC2_DefaultRole. Vous n' |
| - | 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 | | | | + | |
| - | | 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 : | + | **Si l' |
| - | + | </ | |
| - | - 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 | + | |
| - | - 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: | ||
| </ | </ | ||
| - | ===== 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: | ||
| </ | </ | ||
| - | Le nom d’utilisateur dépend de l’image | + | 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)`, | À la première connexion, vérifiez l’empreinte proposée. Si vous obtenez `Permission denied (publickey)`, | ||
| Ligne 604: | Ligne 620: | ||
| </ | </ | ||
| - | 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 ===== | ||