diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml index f455c344c..d8ceffb91 100644 --- a/.github/workflows/main.yml +++ b/.github/workflows/main.yml @@ -40,3 +40,5 @@ jobs: job_template: "Workshop teardown Job" extra_vars: "ec2_name_prefix=github-action-test-sep19" validate_certs: false + env: + pull_request_event: ${{ github.event.pull_request.number }} diff --git a/exercises/ansible_rhel/1.1-setup/README.es.md b/exercises/ansible_rhel/1.1-setup/README.es.md index 5d3db94c4..04fcae9a3 100644 --- a/exercises/ansible_rhel/1.1-setup/README.es.md +++ b/exercises/ansible_rhel/1.1-setup/README.es.md @@ -1,98 +1,149 @@ -# Workshop Ejercicio - Validación de los pre-requisitos +# Ejercicio del Taller - Verificar los Prerrequisitos -**Leer esto en otros idiomas**: -
![uk](../../../images/uk.png) [English](README.md), ![japan](../../../images/japan.png)[日本語](README.ja.md), ![brazil](../../../images/brazil.png) [Portugues do Brasil](README.pt-br.md), ![france](../../../images/fr.png) [Française](README.fr.md),![Español](../../../images/col.png) [Español](README.es.md). +**Lee esto en otros idiomas**: +
![uk](../../../images/uk.png) [Inglés](README.md), ![japan](../../../images/japan.png)[日本語](README.ja.md), ![brazil](../../../images/brazil.png) [Português do Brasil](README.pt-br.md), ![france](../../../images/fr.png) [Francés](README.fr.md),![Español](../../../images/col.png) [Español](README.es.md). -## Tabla de contenidos +## Tabla de Contenidos -* [Objetivos](#Objetivos) -* [Guía](#Guía) -* [Su entorno de laboratorio](#Su-entorno-de-laboratorio) -* [Paso 1 - Acceso al entorno](#Paso-1---Acceso-al-entorno) -* [Paso 2 - Trabajar los laboratorios](#Paso-2---Trabajar-los-laboratorios) -* [Paso 3 - Laboratorios de desafío](#Paso-3---Laboratorios-de-desafío) +- [Ejercicio del Taller - Verificar los Prerrequisitos](#ejercicio-del-taller---verificar-los-prerrequisitos) + - [Tabla de Contenidos](#tabla-de-contenidos) + - [Objetivo](#objetivo) + - [Guía](#guía) + - [Tu Entorno de Laboratorio](#tu-entorno-de-laboratorio) + - [Paso 1 - Acceder al Entorno](#paso-1---acceder-al-entorno) + - [Paso 2 - Usando la Terminal](#paso-2---usando-la-terminal) + - [Paso 3 - Examinar los Entornos de Ejecución](#paso-3---examinar-los-entornos-de-ejecución) + - [Paso 4 - Examinar la configuración de ansible-navigator](#paso-4---examinar-la-configuración-de-ansible-navigator) + - [Paso 5 - Labs de Desafío](#paso-5---labs-de-desafío) -# Objetivos +## Objetivos -- Comprender la topología de laboratorio y cómo acceder al entorno. -- Comprender cómo trabajar los ejercicios del taller -- Comprender los laboratorios de desafío +* Entender la Topología del Laboratorio: Familiarízate con el entorno de laboratorio y los métodos de acceso. +* Dominar los Ejercicios del Taller: Adquiere competencia en la navegación y ejecución de las tareas del taller. +* Resolver los desafíos del taller: Aprende a aplicar tus conocimientos en escenarios prácticos -# Guía +## Guía -## Su entorno de laboratorio +La fase inicial de este taller se centra en las utilidades de línea de comandos de Ansible Automation Platform, como: -En este laboratorio se trabaja en un entorno de laboratorio preconfigurado. Tendrá acceso a los siguientes hosts: -| Role | Inventory name | -| ---------------------| ---------------| -| Ansible Control Host | ansible | -| Managed Host 1 | node1 | -| Managed Host 2 | node2 | -| Managed Host 3 | node3 | +- [ansible-navigator](https://github.com/ansible/ansible-navigator) - una Interfaz de Usuario basada en Texto (TUI) para ejecutar y desarrollar contenido de Ansible. +- [ansible-core](https://docs.ansible.com/core.html) - el ejecutable base que proporciona el marco, lenguaje y funciones que sustentan Ansible Automation Platform, incluyendo herramientas de línea de comandos como `ansible`, `ansible-playbook` y `ansible-doc`. +- [Entornos de Ejecución](https://docs.ansible.com/automation-controller/latest/html/userguide/execution_environments.html) - Imágenes de contenedor pre-construidas con colecciones soportadas por Red Hat. +- [ansible-builder](https://github.com/ansible/ansible-builder) - automatiza el proceso de construcción de Entornos de Ejecución. No es un enfoque principal en este taller. -## Paso 1 - Acceso al entorno +Si necesitas más información sobre los nuevos componentes de la Plataforma de Automatización Ansible, guarda esta página principal [https://red.ht/AAP-20](https://red.ht/AAP-20) -Inicie sesión en el host de control a través de SSH: -> **Advertencia** -> -> Reemplace **11.22.33.44** por la **IP** que se le proporciona, y la **X** por student**X** con el número de estudiante que se le proporcionó. +### Tu Entorno de Laboratorio - ssh studentX@11.22.33.44 +Trabajarás en un entorno pre-configurado con los siguientes hosts: -> **Consejo** -> -> La contraseña sera proporcionada por el instructor -Para pasarse a usuario root: +| Rol | Nombre en el inventario | +| ---------------------| -----------------------| +| Host de Control Ansible | ansible-1 | +| Host Gestionado 1 | node1 | +| Host Gestionado 2 | node2 | +| Host Gestionado 3 | node3 | - [student@ansible ~]$ sudo -i +### Paso 1 - Acceder al Entorno -La mayoría de las tareas de requisitos previos ya se han realizado por usted: +Recomendamos usar Visual Studio Code para este taller por su navegador de archivos integrado, editor con resaltado de sintaxis y terminal en el navegador. El acceso directo SSH también está disponible. Consulta este tutorial de YouTube sobre cómo acceder a tu entorno de trabajo. - - Se instala el software Ansible +NOTA: Se proporciona un breve video de YouTube si necesitas claridad adicional: +[Ansible Workshops - Acceder a tu entorno de trabajo](https://youtu.be/Y_Gx4ZBfcuk) - - Conexión SSH y las claves están configuradas - - `sudo` se ha configurado en los hosts administrados para ejecutar comandos que requieren privilegios de root. +1. Conéctate a Visual Studio Code a través de la página de lanzamiento del taller. + ![página de lanzamiento](images/launch_page.png) -Compruebe que Ansible se ha instalado correctamente +2. Ingresa la contraseña proporcionada para iniciar sesión. - [root@ansible ~]# ansible --version - ansible 2.7.0 - [...] + ![inicio de sesión en vs code](images/vscode_login.png) -> **Nota** -> -> Ansible mantiene la administración de la configuración simple. Ansible no requiere base de datos ni demonios en ejecución y puede ejecutarse fácilmente en un portátil. En los hosts administrados no necesita ningún agente en ejecución. -Cierre la sesión de la cuenta root de nuevo: +### Paso 2 - Usando la Terminal - [root@ansible ~]# exit - logout +1. Abre una terminal en Visual Studio Code: -> **Nota** -> ->En todos los ejercicios posteriores, debe trabajar como el usuario student\ en el nodo de control si no se le indica explícitamente de forma diferente. + ![imagen de nueva terminal](images/vscode-new-terminal.png) -## Paso 2 - Trabajar los laboratorios +2. Navega al directorio `rhel-workshop` en la terminal del nodo de control de Ansible. -Es posible que ya haya adivinado que este laboratorio está bastante centrado en la línea de comandos... :-) +```bash +[student@ansible-1 ~]$ cd ~/rhel-workshop/ +[student@ansible-1 rhel-workshop]$ pwd +/home/student/rhel-workshop +``` - - No escriba todo manualmente, utilice copiar y pegar desde el navegador cuando sea apropiado. Pero detente a pensar y entender. +* `~`: atajo para el directorio home `/home/student` +* `cd`: comando para cambiar de directorio +* `pwd`: imprime la ruta completa del directorio de trabajo actual. - - Todos los laboratorios fueron preparados usando **Vim**, pero entendemos que no a todo el mundo le encanta. Siéntase libre de usar editores alternativos. En el entorno de laboratorio que proporcionamos **Midnight Commander** (simplemente ejecute **mc**, se puede acceder a las teclas de función a través de Esc-\, y simplemente haga clic con el ratón) o **Nano** (ejecutar **nano**). Aquí hay un breve [introducción del editor](.. /0.0-support-docs/editor_intro.md). +### Paso 3 - Examinar los Entornos de Ejecución +1. Ejecuta `ansible-navigator images` para ver los Entornos de Ejecución configurados. +2. Usa el número correspondiente para investigar un EE, por ejemplo, presionando 2 para abrir `ee-supported-rhel8` -> **Consejo** -> -> En los comandos de la guía de laboratorio que se supone que debe ejecutar se muestran con o sin la salida esperada, lo que tenga más sentido en el contexto. +```bash +$ ansible-navigator images +``` -## Paso 3 - Laboratorios de desafío +![ansible-navigator images](images/navigator-images.png) + + +> Nota: La salida que veas puede diferir de la salida anterior + + +![menú principal ee](images/navigator-ee-menu.png) + +Seleccionar `2` para `Versión de Ansible y colecciones` nos mostrará todas las Colecciones de Ansible instaladas en ese EE particular, y la versión de `ansible-core`: + +![información ee](images/navigator-ee-collections.png) + +### Paso 4 - Examinar la configuración de ansible-navigator + +1. Visualiza el contenido de `~/.ansible-navigator.yml` usando Visual Studio Code o el comando `cat`. + +```bash +$ cat ~/.ansible-navigator.yml +--- +ansible-navigator: + ansible: + inventory: + entries: + - /home/student/lab_inventory/hosts + + execution-environment: + image: registry.redhat.io/ansible-automation-platform-20-early-access/ee-supported-rhel8:2.0.0 + enabled: true + container-engine: podman + pull: + policy: missing + volume-mounts: + - src: "/etc/ansible/" + dest: "/etc/ansible/" +``` + +2. Observa los siguientes parámetros dentro del archivo `ansible-navigator.yml`: + +* `inventories`: muestra la ubicación del inventario de ansible que se está utilizando +* `execution-environment`: donde se establece el entorno de ejecución predeterminado + +Para una lista completa de cada configuración configurable consulta la [documentación](https://ansible.readthedocs.io/projects/navigator/settings/) + +<<<<<<< HEAD +### Paso 5 - Desafíos del taller + +Cada capítulo del taller viene con un desafío. Estas tareas prueban tu comprensión y aplicación de los conceptos aprendidos. Las soluciones se proporcionan bajo un signo de advertencia para referencia. +======= +### Paso 5 - Labs de Desafío + +Cada capítulo viene con un Lab de Desafío. Estas tareas prueban tu comprensión y aplicación de los conceptos aprendidos. Las soluciones se proporcionan bajo un signo de advertencia para referencia. +>>>>>>> daf03aad826095b4ee06f20aa28c409189bb47b9 -Pronto descubrirá que muchos capítulos de esta guía de laboratorio vienen con una sección de "Laboratorio de desafío". Estos laboratorios están destinados a darle una pequeña tarea para resolver utilizando lo que ha aprendido hasta ahora. La solución de la tarea se muestra debajo de un signo de advertencia. ---- **Navegación** diff --git a/exercises/ansible_rhel/1.1-setup/README.fr.md b/exercises/ansible_rhel/1.1-setup/README.fr.md index a3aef477f..d3e33e50e 100644 --- a/exercises/ansible_rhel/1.1-setup/README.fr.md +++ b/exercises/ansible_rhel/1.1-setup/README.fr.md @@ -1,119 +1,104 @@ -# Atelier - Vérifier les prérequis +# Exercice de l'Atelier - Vérifier les Prérequis -**Lisez ceci dans d'autres langues**: -
![uk](../../../images/uk.png) [English](README.md), ![japan](../../../images/japan.png)[日本語](README.ja.md), ![brazil](../../../images/brazil.png) [Portugues do Brasil](README.pt-br.md), ![france](../../../images/fr.png) [Français](README.fr.md),![Español](../../../images/col.png) [Español](README.es.md). +**Lisez ceci dans d'autres langues** : +
![uk](../../../images/uk.png) [Anglais](README.md), ![japan](../../../images/japan.png) [日本語](README.ja.md), ![brazil](../../../images/brazil.png) [Portugais du Brésil](README.pt-br.md), ![france](../../../images/fr.png) [Français](README.fr.md), ![Español](../../../images/col.png) [Espagnol](README.es.md). -## Table des matières +## Table des Matières -- [Atelier - Vérifier les prérequis](#atelier---vérifier-les-prérequis) - - [Table des matières](#table-des-matières) +- [Exercice de l'Atelier - Vérifier les Prérequis](#exercice-de-latelier---vérifier-les-prérequis) + - [Table des Matières](#table-des-matières) - [Objectif](#objectif) - [Guide](#guide) - - [Votre Environment](#votre-environnement) - - [Etape 1 - Accéder à l'environnement](#etape-1---accéder-à-l'environnement) - - [Etape 2 - Utiliser le terminal](#etape-2---utiliser-le-terminal) - - [Etape 3 - Examiner les Environnements d'Execution](#etape-3---examiner-les-environnements-d'execution) - - [Etape 4 - Examiner la configuration de ansible-navigator](#etape-4---examiner-la-configuration-de-ansible-navigator) - - [Etape 5 - Défis](#etape-5---défis) + - [Votre Environnement de Laboratoire](#votre-environnement-de-laboratoire) + - [Étape 1 - Accéder à l'Environnement](#étape-1---accéder-à-lenvironnement) + - [Étape 2 - Utiliser le Terminal](#étape-2---utiliser-le-terminal) + - [Étape 3 - Examiner les Environnements d'Exécution](#étape-3---examiner-les-environnements-dexécution) + - [Étape 4 - Examiner la configuration de ansible-navigator](#étape-4---examiner-la-configuration-de-ansible-navigator) + - [Étape 5 - Labs de Défi](#étape-5---labs-de-défi) ## Objectif -* Comprendre la topologie du lab et comment accéder à l'environnement -* Comprendre comment les exercices de l'atelier fonctionnent -* Comprendre les défis +* Comprendre la Topologie du Laboratoire : Familiarisez-vous avec l'environnement de laboratoire et les méthodes d'accès. +* Maîtriser les Exercices de l'Atelier : Acquérir de la compétence dans la navigation et l'exécution des tâches de l'atelier. +* Embrasser les Labs de Défi : Apprenez à appliquer vos connaissances dans des scénarios de défi pratiques. -Ces premiers exercices explorent les utilitaires en ligne de commande (CLI) de Ansible Automation Platform. +## Guide -- [ansible-navigator](https://github.com/ansible/ansible-navigator) - un utilitaire en ligne de commande et une interface utilisateur en mode texte (TUI) pour exécuter et développer du contenu d'automatisation Ansible. -- [ansible-core](https://docs.ansible.com/core.html) - l'exécutable de base qui fournit le framework, le langage et les fonctions qui soutiennent Ansible Automation Platform. Il comprend également les divers outils CLI comme `ansible`, `ansible-playbook` et `ansible-doc`. Ansible Core agit comme un pont entre la communauté upstream et la version gratuite de Ansible et avec la version downstream d'automatisation d'entreprise offerte par Red Hat : Ansible Automation Platform. -- [Environnement d'Execution](https://docs.ansible.com/automation-controller/latest/html/userguide/execution_environments.html) - ne seront pas couvert particulièrement dans cet atelier car la version intégrée dans Ansible des Environnement d'Execution fournit déjà toutes les collections supportées par Red Hat, ce qui inclut les collections utilisées dans cet atelier. Les Environnements d'Execution sont des images de conteneur qui peuvent être utilisées pour exécuter de l'automatisation Ansible. -- [ansible-builder](https://github.com/ansible/ansible-builder) - ne sera pas particulièrement couvert dans cet atelier, `ansible-builder` est un utilitaire en ligne de commande pour automatiser le processuss de construction des Environnements d'Execution. +La phase initiale de cet atelier se concentre sur les utilitaires en ligne de commande de la Plateforme d'Automatisation Ansible, tels que : -S'il vous faut davatange d'informations sur les nouveaux composants de Ansible Automation Platform, ajoutez en favori cette page [https://red.ht/AAP-20](https://red.ht/AAP-20) +- [ansible-navigator](https://github.com/ansible/ansible-navigator) - une Interface Utilisateur Textuelle (TUI) pour exécuter et développer du contenu Ansible. +- [ansible-core](https://docs.ansible.com/core.html) - l'exécutable de base qui fournit le cadre, le langage et les fonctions qui sous-tendent la Plateforme d'Automatisation Ansible, y compris les outils CLI comme `ansible`, `ansible-playbook` et `ansible-doc`. +- [Environnements d'Exécution](https://docs.ansible.com/automation-controller/latest/html/userguide/execution_environments.html) - Images de conteneurs pré-construites avec des collections soutenues par Red Hat. +- [ansible-builder](https://github.com/ansible/ansible-builder) - automatise le processus de construction des Environnements d'Exécution. Pas un focus principal dans cet atelier. -## Guide +Si vous avez besoin de plus d'informations sur les nouveaux composants de la Plateforme d'Automatisation Ansible, mettez cette page d'accueil en signet [https://red.ht/AAP-20](https://red.ht/AAP-20) -### Votre Environnement +### Votre Environnement de Laboratoire -Dans ce lab, vous travaillez avec un environement préconfiguré. Vous aurez accès aux hôtes suivants: +Vous travaillerez dans un environnement pré-configuré avec les hôtes suivants : -| Role | Inventory name | -| ---------------------| ---------------| -| Ansible Control Host | ansible-1 | -| Managed Host 1 | node1 | -| Managed Host 2 | node2 | -| Managed Host 3 | node3 | +| Rôle | Nom d'inventaire | +| --------------------- | ---------------- | +| Hôte de Contrôle Ansible | ansible-1 | +| Hôte Géré 1 | node1 | +| Hôte Géré 2 | node2 | +| Hôte Géré 3 | node3 | -### Etape 1 - Accéder à l'environnement +### Étape 1 - Accéder à l'Environnement - - - - - - -
Il est fortement recommandé d'utiliser Visual Studio Code pour faire les exercices de l'atelier. Visual Studio Code fournit: -
    -
  • Un navigateur de fichiers
    • -
  • Un éditeur de texte avec coloration syntaxique
    • -
  • Un terminal intégré au navigateur
    • -
- L'accès SSH direct est disponible en secours, ou si un Visual Studio Code n'est pas suffisant. Cette vidéo Youtube apporte plus de clarification si nécessaire: Ansible Workshops - Accessing your workbench environment. -
+Nous recommandons d'utiliser Visual Studio Code pour cet atelier pour son navigateur de fichiers intégré, son éditeur avec mise en évidence de la syntaxe et son terminal dans le navigateur. L'accès SSH direct est également disponible. Consultez ce tutoriel YouTube sur l'accès à votre environnement de travail. -- Connectez-vous à Visual Studio Code depuis la page de l'atelier (fournie par votre instructeur). Le mot de passe est fourni sous le lien WebUI. +NOTE : Une courte vidéo YouTube est fournie si vous avez besoin de précisions supplémentaires : +[Ateliers Ansible - Accéder à votre environnement de travail](https://youtu.be/Y_Gx4ZBfcuk) - ![launch page](images/launch_page.png) +1. Connectez-vous à Visual Studio Code via la page de lancement de l'atelier. -- Entrez votre mot de passe pour vous connecter. + ![page de lancement](images/launch_page.png) - ![login vs code](images/vscode_login.png) +2. Entrez le mot de passe fourni pour vous connecter. - - Ouvrez le répertoire `rhel-workshop` dans Visual Studio Code: + ![connexion vs code](images/vscode_login.png) -### Etape 2 - Utiliser le terminal +### Étape 2 - Utiliser le Terminal -- Ouvrez un terminal dans Visual Studio Code: +1. Ouvrez un terminal dans Visual Studio Code : - ![picture of new terminal](images/vscode-new-terminal.png) + ![image d'un nouveau terminal](images/vscode-new-terminal.png) -Naviguer vers le répertoire `rhel-workshop` sur le terminal du noeud de contrôle Ansible. +2. Naviguez vers le répertoire `rhel-workshop` sur le terminal du nœud de contrôle Ansible. ```bash [student@ansible-1 ~]$ cd ~/rhel-workshop/ [student@ansible-1 rhel-workshop]$ pwd /home/student/rhel-workshop -[student@ansible-1 rhel-workshop]$ ``` -* `~` - le tilde dans ce contexte est un raccourci pour le répertoire home, ici `/home/student` -* `cd` - commande Linux pour changer de répertoire -* `pwd` - commande Linux pour afficher le répertoire de travail courant. Le chemin complet du répertoire courant sera affiché. +* `~` : raccourci pour le répertoire home `/home/student` +* `cd` : commande pour changer de répertoires +* `pwd` : imprime le chemin complet du répertoire de travail actuel. -### Etape 3 - Examiner les Environnements d'Execution +### Étape 3 - Examiner les Environnements d'Exécution -Exécuter la commande `ansible-navigator` avec l'argument `images` pour lister les Environnements d'Execution configurés sur le noeud de contrôle Ansible: +1. Exécutez `ansible-navigator images` pour voir les Environnements d'Exécution configurés. +2. Utilisez le numéro correspondant pour enquêter sur un EE, par exemple, en appuyant sur 2 pour ouvrir `ee-supported-rhel8` ```bash $ ansible-navigator images ``` -![ansible-navigator images](images/navigator-images.png) - - -> Note: Le résultat obtenu peut différer légèrement du résultat ci-dessus. +![images ansible-navigator](images/navigator-images.png) -Cette commande vous donne des informations sur les Environnements d'Execution (EE) actuellement installés. Renseignez-vous sur un EE en tapant le numéro correspondant. Par exemple taper **2** dans l'exemple ci-dessus ouvre l'environnement d'exécution `ee-supported-rhel8`: +> Note : La sortie que vous voyez peut différer de la sortie ci-dessus -![ee main menu](images/navigator-ee-menu.png) +![menu principal ee](images/navigator-ee-menu.png) -Sélectionner `2` pour `Ansible version and collections` affiche les collections Ansible installées sur cet EE, et la version de `ansible-core`: +Sélectionner `2` pour `Version d'Ansible et collections` nous montrera toutes les Collections Ansible installées sur cet EE particulier, et la version de `ansible-core` : -![ee info](images/navigator-ee-collections.png) +![informations ee](images/navigator-ee-collections.png) -### Etape 4 - Examiner la configuration de ansible-navigator +### Étape 4 - Examiner la configuration de ansible-navigator -Au choix, utilisez Visual Studio Code ou la commande `cat` pour voir le contenu du fichier `ansible-navigator.yml`. Le fichier est situé dans le répertoire home: +1. Visualisez le contenu de `~/.ansible-navigator.yml` en utilisant Visual Studio Code ou la commande `cat`. ```bash $ cat ~/.ansible-navigator.yml @@ -135,16 +120,16 @@ ansible-navigator: dest: "/etc/ansible/" ``` -Notez les paramètres suivants dans le fichier `ansible-navigator.yml`: +2. Notez les paramètres suivants dans le fichier `ansible-navigator.yml` : -* `inventories`: donne l'emplacement de l'inventaire Ansible utilisé -* `execution-environment`: donne l'emplacement de l'environnement d'exécution par défaut +* `inventories` : montre l'emplacement de l'inventaire ansible utilisé +* `execution-environment` : où l'environnement d'exécution par défaut est défini -Pour une liste complète des éléments configurables, consultez la [documentation](https://ansible.readthedocs.io/projects/navigator/settings/) +Pour une liste complète de chaque bouton configurable, consultez la [documentation](https://ansible.readthedocs.io/projects/navigator/settings/) -### Etape 5 - Défis +### Étape 5 - Labs de Défi -Certains chapitres de cet atelier comportent une section "Défi". Ces labs sont pensés pour vous donner une taĉhe à compléter en utilisant ce que vous avez appris jusque là. La solution est donnée en dessous du signe warning. +Chaque chapitre est accompagné d'un Lab de Défi. Ces tâches testent votre compréhension et l'application des concepts appris. Les solutions sont fournies sous un signe d'avertissement pour référence. --- **Navigation** diff --git a/exercises/ansible_rhel/1.1-setup/README.ja.md b/exercises/ansible_rhel/1.1-setup/README.ja.md index 81f78820b..70862cc42 100644 --- a/exercises/ansible_rhel/1.1-setup/README.ja.md +++ b/exercises/ansible_rhel/1.1-setup/README.ja.md @@ -1,117 +1,104 @@ # ワークショップ演習 - 前提条件の確認 -**他の言語でもお読みいただけます**: -
![uk](../../../images/uk.png) [English](README.md)、![japan](../../../images/japan.png)[日本語](README.ja.md)、![brazil](../../../images/brazil.png) [Portugues do Brasil](README.pt-br.md)、![france](../../../images/fr.png) [Française](README.fr.md)、![Español](../../../images/col.png) [Español](README.es.md) +**他の言語で読む**: +
![uk](../../../images/uk.png) [英語](README.md), ![japan](../../../images/japan.png) [日本語](README.ja.md), ![brazil](../../../images/brazil.png) [ブラジルのポルトガル語](README.pt-br.md), ![france](../../../images/fr.png) [フランス語](README.fr.md), ![Español](../../../images/col.png) [スペイン語](README.es.md). ## 目次 -* [目的](#目的) -* [ガイド](#ガイド) - * [ラボ環境](#ラボ環境) - * [ステップ 1 - 環境へのアクセス](#ステップ-1---環境へのアクセス) - * [ステップ 2 - ターミナルの使用](#ステップ-2---ターミナルの使用) - * [ステップ 3 - 実行環境の検証](#ステップ-3---実行環境の検証) - * [ステップ 4 - ansible-navigator 設定の検証](#ステップ-4---ansible-navigator-設定の検証) - * [ステップ 5 - チャレンジラボ](#ステップ-5---チャレンジラボ) +- [ワークショップ演習 - 前提条件の確認](#ワークショップ演習---前提条件の確認) + - [目次](#目次) + - [目的](#目的) + - [ガイド](#ガイド) + - [あなたのラボ環境](#あなたのラボ環境) + - [ステップ 1 - 環境へのアクセス](#ステップ-1---環境へのアクセス) + - [ステップ 2 - ターミナルの使用](#ステップ-2---ターミナルの使用) + - [ステップ 3 - 実行環境の検討](#ステップ-3---実行環境の検討) + - [ステップ 4 - ansible-navigatorの設定の検討](#ステップ-4---ansible-navigatorの設定の検討) + - [ステップ 5 - チャレンジラボ](#ステップ-5---チャレンジラボ) ## 目的 -* ラボトポロジーと環境へのアクセス方法を理解する。 -* ワークショップの演習の仕組みを理解する。 -* チャレンジラボについて理解する。 +* ラボトポロジーを理解する：ラボ環境とアクセス方法に慣れる。 +* ワークショップの演習をマスターする：ワークショップのタスクをナビゲートし、実行するスキルを習得する。 +* チャレンジラボを受け入れる：実践的なチャレンジシナリオで知識を適用する方法を学ぶ。 -この最初のいくつかのラボ演は、Ansible Automation Platform のコマンドラインユーティリティーを使用します。これには、以下が含まれます。 +## ガイド -- [ansible-navigator](https://github.com/ansible/ansible-navigator) - Ansible オートメーションコンテンツを実行・開発するためのコマンドラインユーティリティとテキストベースのユーザーインターフェース（TUI）。 -- [ansible-core](https://docs.ansible.com/core.html) - Ansible Automation Platform を支えるフレームワーク、言語、機能を提供する基本的な実行ファイルです。また、`ansible`、`ansible-playbook`、`ansible-doc` などのさまざまなクリエートツールも含まれています。Ansible Coreは、無料でオープンソースの Ansible を提供するアップストリームのコミュニティと、Red Hat が提供するダウンストリームのエンタープライズオートメーション製品であるAnsible Automation Platform との橋渡しの役割を果たします。 -- [実行環境](https://docs.ansible.com/automation-controller/latest/html/userguide/execution_environments.html) - このワークショップでは特に取り上げません。なぜなら、ビルトインの Ansible 実行環境には、Red Hatがサポートするすべてのコレクションがすでに含まれており、このワークショップで使用するすべてのコレクションも含まれているからです。実行環境とは、Ansible の実行環境として利用できるコンテナイメージです。 -- [ansible-builder](https://github.com/ansible/ansible-builder) - このワークショップでは特に取り上げませんが、`ansible-builder` は実行環境の構築プロセスを自動化するためのコマンドラインユーティリティです。 +このワークショップの初期段階は、Ansibleオートメーションプラットフォームのコマンドラインユーティリティに焦点を当てています。例えば: -Ansible Automation Platformの新しいコンポーネントに関する情報が必要な場合は、このランディングページをブックマークしてください [https://red.ht/AAP-20](https://red.ht/AAP-20) +- [ansible-navigator](https://github.com/ansible/ansible-navigator) - Ansibleコンテンツを実行および開発するためのテキストベースのユーザーインターフェイス（TUI）。 +- [ansible-core](https://docs.ansible.com/core.html) - `ansible`、`ansible-playbook`、`ansible-doc`などのCLIツールを含む、Ansibleオートメーションプラットフォームを支えるフレームワーク、言語、機能を提供するベース実行可能ファイル。 +- [実行環境](https://docs.ansible.com/automation-controller/latest/html/userguide/execution_environments.html) - Red Hatがサポートするコレクションを含む、事前に構築されたコンテナイメージ。 +- [ansible-builder](https://github.com/ansible/ansible-builder) - 実行環境の構築プロセスを自動化します。このワークショップでは主な焦点ではありません。 -## ガイド +新しいAnsibleオートメーションプラットフォームコンポーネントの詳細については、このランディングページをブックマークしてください [https://red.ht/AAP-20](https://red.ht/AAP-20) -### ラボ環境 +### あなたのラボ環境 -このラボでは、事前設定されたラボ環境で作業します。ここでは、以下のホストにアクセスできます。 +以下のホストを含む事前設定された環境で作業します: -| Role | Inventory name | -| ---------------------| ---------------| -| Ansible Control Host | ansible-1 | -| Managed Host 1 | node1 | -| Managed Host 2 | node2 | -| Managed Host 3 | node3 | +| 役割 | インベントリ名 | +| ----------------------- | --------------- | +| Ansibleコントロールホスト | ansible-1 | +| 管理ホスト1 | node1 | +| 管理ホスト2 | node2 | +| 管理ホスト3 | node3 | ### ステップ 1 - 環境へのアクセス - - - - - - -
ワークショップの演習には、Visual Studio Codeの使用が強く推奨されます。Visual Studio Codeは以下を提供します。 -
    -
  • ファイルブラウザ
    • -
  • 構文強調表示の機能付きテキストエディタ
    • -
  • ブラウザ内ターミナル
    • -
- バックアップとして、あるいはVisual Studio Codeでは不十分な場合には、SSHによる直接アクセスが可能です。さらなる説明が必要な場合は、短い YouTube ビデオが用意されています。 Ansible Workshops - ワークベンチ環境へのアクセス -
+このワークショップでは、統合ファイルブラウザ、構文強調表示エディタ、ブラウザ内ターミナルを備えたVisual Studio Codeの使用をお勧めします。直接SSHアクセスも利用可能です。ワークベンチ環境へのアクセスに関するこのYouTubeチュートリアルをチェックしてください。 -- ワークショップの起動ページ（講師が用意したもの）からVisual Studio Codeに接続します。パスワードは、WebUIのリンクの下に記載されています。 +注意: 追加の明確化が必要な場合は、短いYouTubeビデオが提供されています： +[Ansible Workshops - ワークベンチ環境へのアクセス](https://youtu.be/Y_Gx4ZBfcuk) - ![launch page](images/launch_page.png) +1. ワークショップの起動ページからVisual Studio Codeに接続します。 -- 接続する提供されたパスワードを入力します。 + ![起動ページ](images/launch_page.png) - ![login vs code](images/vscode_login.png) +2. 提供されたパスワードを入力してログインします。 - - Visual Studio Code で `rhel-workshop` ディレクトリーを開きます。 + ![VS Codeのログイン](images/vscode_login.png) ### ステップ 2 - ターミナルの使用 -- Visual Studio Code でターミナルを開きます。 +1. Visual Studio Codeでターミナルを開きます: - ![picture of new terminal](images/vscode-new-terminal.png) + ![新しいターミナルの画像](images/vscode-new-terminal.png) -Ansible コントロールノードターミナルで `rhel-workshop` ディレクトリーに移動します。 +2. Ansibleコントロールノードのターミナルで`rhel-workshop`ディレクトリに移動します。 ```bash [student@ansible-1 ~]$ cd ~/rhel-workshop/ [student@ansible-1 rhel-workshop]$ pwd /home/student/rhel-workshop -[student@ansible-1 rhel-workshop]$ ``` -* `~` - このコンテキストでのチルダは `/home/student` のショートカットです -* `cd` - ディレクトリーを変更する Linux コマンド -* `pwd` - 作業ディレクトリーを印刷するための Linux コマンド。これにより、現在の作業ディレクトリーへのフルパスが表示されます。 +* `~`: ホームディレクトリ`/home/student`のショートカット +* `cd`: ディレクトリを変更するコマンド +* `pwd`: 現在の作業ディレクトリの完全なパスを表示します。 -### ステップ 3 - 実行環境の検証 +### ステップ 3 - 実行環境の検討 -`ansible-navigator` 引数を指定して `images` コマンドを実行し、コントロールノードに設定された実行環境を確認します。 +1. `ansible-navigator images`を実行して、設定された実行環境を表示します。 +2. 対応する番号を使用してEEを調査します。例えば、`ee-supported-rhel8`を開くために2を押します。 ```bash $ ansible-navigator images ``` -![ansible-navigator images](images/navigator-images.png) - - -> 注意: 表示される出力は、上記の出力とは異なる場合があります +![ansible-navigatorの画像](images/navigator-images.png) -このコマンドは、現在インストールされているすべての実行環境（略してEE）に関する情報を提供します。対応する番号を押すことで、EE を調べることができます。例えば、上記の例で **2** を押すと、`ee-supported-rhel8` の実行環境が表示されます。 +> 注意: あなたが見る出力は上記の出力と異なる場合があります -![ee メインメニュー](images/navigator-ee-menu.png) +![eeメインメニュー](images/navigator-ee-menu.png) -`2` に `Ansible version and collections` を選択すると、その特定の EE にインストールされたすべての Ansible Collections と、`ansible-core` のバージョンが表示されます。 +`2`を選択すると`Ansibleバージョンとコレクション`が表示され、その特定のEEにインストールされているすべてのAnsibleコレクションと`ansible-core`のバージョンが表示されます： -![ee info](images/navigator-ee-collections.png) +![ee情報](images/navigator-ee-collections.png) -### ステップ 4 - ansible-navigator 設定の検証 +### ステップ 4 - ansible-navigatorの設定の検討 -Visual Studio Code を使用して `ansible-navigator.yml` ファイルを開くか、`cat` コマンドを使用してファイルの内容を表示します。このファイルはホームディレクトリーにあります。 +1. Visual Studio Codeまたは`cat`コマンドを使用して`~/.ansible-navigator.yml`の内容を表示します。 ```bash $ cat ~/.ansible-navigator.yml @@ -133,16 +120,16 @@ ansible-navigator: dest: "/etc/ansible/" ``` -`ansible-navigator.yml` ファイル内の次のパラメータに注意してください。 +2. `ansible-navigator.yml`ファイル内の以下のパラメーターに注意してください： -* `inventories`: 使用されている Ansible インベントリーの場所を示します +* `inventories`: 使用されているansibleインベントリの場所を示します * `execution-environment`: デフォルトの実行環境が設定されている場所 -設定可能なすべての knob の詳細な一覧については、[ドキュメント](https://ansible-navigator.readthedocs.io/en/latest/settings/) を参照してください。 +設定可能なすべてのノブの完全なリストについては、[ドキュメント](https://ansible.readthedocs.io/projects/navigator/settings/)をチェックしてください。 ### ステップ 5 - チャレンジラボ -これらのラボガイドの多数の章には、「チャレンジラボ」セクションが用意されています。これらのラボは、これまで学んだ知識で解決するための小さなタスクを行うことを目的としています。タスクの回答は、警告サインの下に表示されます。 +各章にはチャレンジラボが付属しています。これらのタスクは、学んだ概念の理解と適用をテストします。解決策は警告サインの下に提供されています。 --- **ナビゲーション** diff --git a/exercises/ansible_rhel/1.1-setup/README.pt-br.md b/exercises/ansible_rhel/1.1-setup/README.pt-br.md index 133f7e602..a53199675 100644 --- a/exercises/ansible_rhel/1.1-setup/README.pt-br.md +++ b/exercises/ansible_rhel/1.1-setup/README.pt-br.md @@ -1,84 +1,137 @@ -# Exercício 1.1 - Verifique os pré-requisitos +# Exercício de Workshop - Verificar os Pré-requisitos -**Leia em outras linguagens**: -
![uk](../../../images/uk.png) [English](README.md), ![japan](../../../images/japan.png)[日本語](README.ja.md), ![brazil](../../../images/brazil.png) [Portugues do Brasil](README.pt-br.md), ![france](../../../images/fr.png) [Française](README.fr.md),![Español](../../../images/col.png) [Español](README.es.md). +**Leia isso em outros idiomas**: +
![uk](../../../images/uk.png) [Inglês](README.md), ![japan](../../../images/japan.png) [日本語](README.ja.md), ![brazil](../../../images/brazil.png) [Português do Brasil](README.pt-br.md), ![france](../../../images/fr.png) [Francês](README.fr.md),![Español](../../../images/col.png) [Espanhol](README.es.md). -* [Seu ambiente de Laboratório](#seu-ambiente-de-laboratório) -* [Passo 1.1 - Acesse o ambiente](#passo-11---acesse-o-ambiente) -* [Passo 1.2 - Trabalhando nos laboratórios](#passo-12---trabalhando-nos-laboratórios) -* [Passo 1.3 - Troca de Labs](#passo-13---troca-de-labs) +## Índice -## Seu ambiente de Laboratório +- [Exercício de Workshop - Verificar os Pré-requisitos](#exercício-de-workshop---verificar-os-pré-requisitos) + - [Índice](#índice) + - [Objetivo](#objetivo) + - [Guia](#guia) + - [Seu Ambiente de Laboratório](#seu-ambiente-de-laboratório) + - [Etapa 1 - Acessar o Ambiente](#etapa-1---acessar-o-ambiente) + - [Etapa 2 - Usando o Terminal](#etapa-2---usando-o-terminal) + - [Etapa 3 - Examinando Ambientes de Execução](#etapa-3---examinando-ambientes-de-execução) + - [Etapa 4 - Examinando a configuração do ansible-navigator](#etapa-4---examinando-a-configuração-do-ansible-navigator) + - [Etapa 5 - Labs de Desafio](#etapa-5---labs-de-desafio) -Neste workshop, você irá trabalhar em um ambiente de laboratório pré-configurado. Você terá acesso aos seguintes hosts: +## Objetivo -| Role | Inventory name | -| ---------------------| ---------------| -| Ansible Control Host | ansible | -| Managed Host 1 | node1 | -| Managed Host 2 | node2 | -| Managed Host 2 | node3 | +* Compreender a Topologia do Laboratório: Familiarize-se com o ambiente de laboratório e métodos de acesso. +* Dominar os Exercícios do Workshop: Obtenha proficiência na navegação e execução das tarefas do workshop. +* Abraçar os Labs de Desafio: Aprenda a aplicar seu conhecimento em cenários práticos de desafio. -## Passo 1.1 - Acesse o ambiente +## Guia -Faça Login com seu Ansible Control Host via SSH: +A fase inicial deste workshop se concentra nas utilidades de linha de comando da Plataforma de Automação Ansible, como: -> **ATENÇÃO** -> -> Substitua **11.22.33.44** pelo seu **IP** fornecido a você, e o **X** em student**X** pelo número do aluno fornecido a você. - ssh studentX@11.22.33.44 +- [ansible-navigator](https://github.com/ansible/ansible-navigator) - uma Interface de Usuário Baseada em Texto (TUI) para executar e desenvolver conteúdo Ansible. +- [ansible-core](https://docs.ansible.com/core.html) - o executável base que fornece a estrutura, linguagem e funções que sustentam a Plataforma de Automação Ansible, incluindo ferramentas CLI como `ansible`, `ansible-playbook` e `ansible-doc`. +- [Ambientes de Execução](https://docs.ansible.com/automation-controller/latest/html/userguide/execution_environments.html) - Imagens de contêiner pré-construídas com coleções suportadas pela Red Hat. +- [ansible-builder](https://github.com/ansible/ansible-builder) - automatiza o processo de construção de Ambientes de Execução. Não é um foco principal neste workshop. -> **Dica** -> -> A senha é **instructor provides this** +Se você precisar de mais informações sobre os novos componentes da Plataforma de Automação Ansible, marque esta página inicial [https://red.ht/AAP-20](https://red.ht/AAP-20) -Torne-se Root: +### Seu Ambiente de Laboratório - [student@ansible ~]$ sudo -i +Você trabalhará em um ambiente pré-configurado com os seguintes hosts: -A maioria dos pré-requisitos já foram feitos pra você: +| Função | Nome no Inventário | +| ---------------------| -------------------| +| Host de Controle Ansible | ansible-1 | +| Host Gerenciado 1 | node1 | +| Host Gerenciado 2 | node2 | +| Host Gerenciado 3 | node3 | - - O Ansible já está instalado. +### Etapa 1 - Acessar o Ambiente - - Conexão SSH e chaves estão configuradas. +Recomendamos o uso do Visual Studio Code para este workshop por seu navegador de arquivos integrado, editor com destaque de sintaxe e terminal dentro do navegador. O acesso direto via SSH também está disponível. Confira este tutorial do YouTube sobre como acessar seu ambiente de trabalho. - - `sudo` foi configurado nos hosts para executar comandos que requerem privilégios de root. +NOTA: Um vídeo curto do YouTube é fornecido caso você precise de clareza adicional: +[Workshops Ansible - Acessando seu ambiente de trabalho](https://youtu.be/Y_Gx4ZBfcuk) -Verificando se o Ansible foi instalado corretamente +1. Conecte-se ao Visual Studio Code através da página de lançamento do Workshop. - [root@ansible ~]# ansible --version - ansible 2.7.0 - [...] + ![página de lançamento](images/launch_page.png) -> **Nota** -> -> O Ansible possui uma configuração simples. Não requer banco de dados ou daemons em execução e pode ser executado facilmente em um notebook. Nos hosts gerenciados, ele não precisa de agente em execução. +2. Insira a senha fornecida para fazer login. -Saia do root novamente: + ![login no vs code](images/vscode_login.png) - [root@ansible ~]# exit - logout +### Etapa 2 - Usando o Terminal -> **Nota** -> -> Em todos os exercícios subsequentes, você deve trabalhar como usuário student\ no nó de controle, a menos que seja explicitamente informado para ser feito de maneira diferente. +1. Abra um terminal no Visual Studio Code: -## Passo 1.2 - Trabalhando nos laboratórios + ![imagem de um novo terminal](images/vscode-new-terminal.png) -Você já deve ter percebido que este laboratório é centralizado em linha de comando…​ :-) +2. Navegue até o diretório `rhel-workshop` no terminal do nó de controle Ansible. - - Não digite tudo manualmente, use copiar e colar no navegador quando apropriado. Mas pare para pensar e entender. +```bash +[student@ansible-1 ~]$ cd ~/rhel-workshop/ +[student@ansible-1 rhel-workshop]$ pwd +/home/student/rhel-workshop +``` - - Todos os laboratórios foram preparados com o **Vim**, mas entendemos que nem todo mundo gosta dele. Sinta-se livre para usar editores alternativos. No ambiente de laboratório, fornecemos **Midnight Commander** (basta executar **mc**, as teclas de função podem ser acessadas via Esc-\ ou simplesmente clicadas com o mouse) ou **Nano** (excução **nano**). Aqui está uma breve introdução do [editor](../0.0-support-docs/editor_intro.md). +* `~`: atalho para o diretório home `/home/student` +* `cd`: comando para mudar de diretórios +* `pwd`: imprime o caminho completo do diretório de trabalho atual. -> **Dica** -> -> No guia do laboratório, os comandos que você deve executar são mostrados com ou sem a saída esperada, o que fizer mais sentido no contexto. +### Etapa 3 - Examinando Ambientes de Execução -## Passo 1.3 - Troca de Labs +1. Execute `ansible-navigator images` para visualizar Ambientes de Execução configurados. +2. Use o número correspondente para investigar um EE, por exemplo, pressionando 2 para abrir `ee-supported-rhel8` + +```bash +$ ansible-navigator images +``` + +![imagens do ansible-navigator](images/navigator-images.png) + +> Nota: A saída que você vê pode diferir da saída acima + +![menu principal do ee](images/navigator-ee-menu.png) + +Selecionar `2` para `Versão do Ansible e coleções` nos mostrará todas as Coleções Ansible instaladas nesse EE específico, e a versão do `ansible-core`: + +![informações do ee](images/navigator-ee-collections.png) + +### Etapa 4 - Examinando a configuração do ansible-navigator + +1. Visualize o conteúdo do `~/.ansible-navigator.yml` usando o Visual Studio Code ou o comando `cat`. + +```bash +$ cat ~/.ansible-navigator.yml +--- +ansible-navigator: + ansible: + inventory: + entries: + - /home/student/lab_inventory/hosts + + execution-environment: + image: registry.redhat.io/ansible-automation-platform-20-early-access/ee-supported-rhel8:2.0.0 + enabled: true + container-engine: podman + pull: + policy: missing + volume-mounts: + - src: "/etc/ansible/" + dest: "/etc/ansible/" +``` + +2. Observe os seguintes parâmetros dentro do arquivo `ansible-navigator.yml`: + +* `inventories`: mostra a localização do inventário ansible sendo usado +* `execution-environment`: onde o ambiente de execução padrão é definido + +Para uma lista completa de todos os ajustes configuráveis, consulte a [documentação](https://ansible.readthedocs.io/projects/navigator/settings/) + +### Etapa 5 - Labs de Desafio + +Cada capítulo vem com um Lab de Desafio. Essas tarefas testam seu entendimento e aplicação dos conceitos aprendidos. As soluções são fornecidas sob um sinal de advertência para referência. -Você descobrirá em breve que muitos capítulos deste guia de laboratório vêm com uma seção "Laboratório de Desafios". Esses laboratórios possuem uma pequena tarefa a ser resolvida usando o que você aprendeu até agora. A solução da tarefa é mostrada sob um sinal de aviso. ---- diff --git a/exercises/ansible_rhel/1.2-thebasics/README.es.md b/exercises/ansible_rhel/1.2-thebasics/README.es.md index 9dd4ab21b..a3d4c395b 100644 --- a/exercises/ansible_rhel/1.2-thebasics/README.es.md +++ b/exercises/ansible_rhel/1.2-thebasics/README.es.md @@ -1,36 +1,29 @@ -# Workshop - Ejecución de comandos Ad-hoc +# Ejercicio del Taller - Los Fundamentos de Ansible -**Leer esto en otros idiomas**: +**Lea esto en otros idiomas**: +
![uk](../../../images/uk.png) [Inglés](README.md), ![japan](../../../images/japan.png) [日本語](README.ja.md), ![brazil](../../../images/brazil.png) [Portugués de Brasil](README.pt-br.md), ![france](../../../images/fr.png) [Francés](README.fr.md),![Español](../../../images/col.png) [Español](README.es.md). -
![uk](../../../images/uk.png) [English](README.md), ![japan](../../../images/japan.png)[日本語](README.ja.md), ![brazil](../../../images/brazil.png) [Portugues do Brasil](README.pt-br.md), ![france](../../../images/fr.png) [Française](README.fr.md),![Español](../../../images/col.png) [Español](README.es.md). +## Tabla de Contenidos -## Tabla de contenidos +- [Objetivo](#objetivo) +- [Guía](#guía) + - [Fundamentos del Archivo de Inventario](#fundamentos-del-archivo-de-inventario) + - [Descubrimiento de Módulos](#descubrimiento-de-módulos) + - [Acceso a la Documentación de Módulos](#acceso-a-la-documentación-de-módulos) -* [Objetivos](#Objetivos) -* [Guía](#Guía) -* [Paso 1 - Trabaje con su inventario](#Paso-1---Trabaje-con-su-inventario) -* [Paso 2 - Los archivos de configuración de Ansible](#Paso-2---Los-archivos-de-configuración-de-Ansible) -* [Paso 3 - Ping a un host](#Paso-3---Ping-a-un-host) -* [Paso 4 - Listado de módulos y obtención de ayuda](#Paso-4---Listado-de-módulos-y-obtención-de-ayuda) -* [Paso 5 - Utilice el módulo de comandos:](#Paso-5---Utilice-el-módulo-de-comandos) -* [Paso 6 - Los módulos de copiar y de permisos](#Paso-6---Los-módulos-de-copiar-y-de-permisos) -* [Laboratorios de desafío: Módulos](#Laboratorios-de-desafío) +## Objetivo -# Objetivos +En este ejercicio, vamos a explorar la última utilidad de línea de comandos de Ansible `ansible-navigator` para aprender cómo trabajar con archivos de inventario y el listado de módulos cuando se necesita asistencia. El objetivo es familiarizarse con cómo funciona `ansible-navigator` y cómo puede ser utilizado para enriquecer su experiencia con Ansible. -Para nuestro primer ejercicio, vamos a ejecutar algunos comandos ad hoc para ayudarle a hacerse una idea de cómo funciona Ansible. Los comandos Ad-Hoc de Ansible le permiten realizar tareas en nodos remotos sin tener que escribir un playbook. Son muy útiles cuando simplemente necesita hacer una o dos cosas rápida y a menudo, a muchos nodos remotos. +## Guía -Este ejercicio cubrirá -- Localización y comprensión del archivo de configuración de Ansible (`ansible.cfg`) -- Localización y comprensión de un archivo de inventario con formato `ini` -- Ejecución de comandos ad hoc +### Fundamentos del Archivo de Inventario +Un archivo de inventario es un archivo de texto que especifica los nodos que serán gestionados por la máquina de control. Los nodos a gestionar pueden incluir una lista de nombres de host o direcciones IP de esos nodos. El archivo de inventario permite organizar los nodos en grupos declarando un nombre de grupo de host entre corchetes ([]). -# Guía +### Explorando el Inventario -## Paso 1 - Trabaje con su inventario - -Para utilizar el comando ansible para la administración de hosts, debe proporcionar un archivo de inventario que defina una lista de hosts que se administrarán desde el nodo de control. En este laboratorio, el inventario lo proporciona el instructor. El inventario es un archivo con formato ini que enumera los hosts, ordenados en grupos, además de proporcionar algunas variables. Se parece a esto: +Para usar el comando `ansible-navigator` para la gestión de hosts, necesita proporcionar un archivo de inventario que define una lista de hosts a ser gestionados desde el nodo de control. En este laboratorio, el inventario es proporcionado por su instructor. El archivo de inventario es un archivo formateado `ini` que lista sus hosts, ordenados en grupos, proporcionando además algunas variables. Un ejemplo puede verse de la siguiente manera: ```bash [web] @@ -39,262 +32,137 @@ node2 ansible_host= node3 ansible_host= [control] -ansible ansible_host=44.55.66.77 -``` - -Ansible ya está configurado para usar el inventario específico de su entorno. Le mostraremos en el siguiente paso cómo se hace. Por ahora, ejecutaremos algunos comandos simples para trabajar con el inventario. - -Para hacer referencia a hosts de inventario, proporcione un patrón de host al comando ansible. Ansible tiene una opción `--list-hosts` que puede ser útil para aclarar a qué hosts administrados hace referencia el patrón de host en un comando ansible. - -El patrón de host más básico es el nombre de un único host administrado que aparece en el archivo de inventario. Esto especifica que el host será el único en el archivo de inventario que actuará por el comando ansible. Ejecutar: - -```bash -[studentansible ~]$ ansible node1 --list-hosts - hosts (1): - node1 -``` - -Un archivo de inventario puede contener mucha más información, puede organizar los hosts en grupos o definir variables. En nuestro ejemplo, el inventario actual tiene los grupos `web` y `control`. Ejecute Ansible con estos patrones de host y observe la salida: - -```bash -[studentansible ~]$ ansible web --list-hosts -[studentansible ~]$ ansible web,ansible --list-hosts -[studentansible ~]$ ansible 'node*' --list-hosts -[studentansible ~]$ ansible all --list-hosts -``` - -Como usted ve está bien poner los sistemas en más de un grupo. Por ejemplo, un servidor podría ser un servidor web y un servidor de base de datos. Tenga en cuenta que en Ansible los grupos no son necesariamente jerárquicos. - -> **Consejo** -> -> El inventario puede contener más datos. Por ejemplo, si tiene hosts que se ejecutan en puertos SSH no estándar, puede colocar el número de puerto después del nombre de host con dos puntos. O bien, puede definir nombres específicos de Ansible y hacer que apunten a la dirección IP o al nombre de host. - -## Paso 2 - Los archivos de configuración de Ansible - -El comportamiento de Ansible se puede personalizar modificando la configuración en el archivo de configuración de estilo ini de Ansible. Ansible seleccionará su archivo de configuración de una de las varias ubicaciones posibles en el nodo de control, consulte la [documentación](https://docs.ansible.com/ansible/latest/reference_appendices/config.html). - -> **Consejo** -> -> La práctica recomendada es crear un archivo `ansible.cfg` en el directorio desde el que se ejecutan los comandos Ansible. Este directorio también contendría los archivos utilizados por el proyecto de Ansible, como el inventario y los playbooks. Otra práctica recomendada es crear un archivo `.ansible.cfg` en el directorio home del usuario. - -En el entorno de laboratorio que se le ha proporcionado, ya se ha creado un archivo `.ansible.cfg` y se ha llenado con los detalles necesarios en el directorio home del usuario `student` en el nodo de control: - -```bash -[student@ansible ~]$ ls -la .ansible.cfg --rw-r--r--. 1 student student 231 14. Mai 17:17 .ansible.cfg -``` - -Salida del contendio del archivo: +ansible-1 ansible_host=44.55.66.77 +``` + +Para ver su inventario con ansible-navigator, use el comando `ansible-navigator inventory --list -m stdout`. Este comando muestra todos los nodos y sus respectivos grupos. + +```bash +[student@ansible-1 rhel_workshop]$ cd /home/student +[student@ansible-1 ~]$ ansible-navigator inventory --list -m stdout +{ + "_meta": { + "hostvars": { + "ansible-1": { + "ansible_host": "3.236.186.92" }, + "node1": { + "ansible_host": "3.239.234.187" + }, + "node2": { + "ansible_host": "75.101.228.151" + }, + "node3": { + "ansible_host": "100.27.38.142" + } + } + }, + "all": { + "children": [ + "control", + "ungrouped", + "web" + ] + }, + "control": { + "hosts": [ + "ansible-1" + ] + }, + "web": { + "hosts": [ + "node1", + "node2", + "node3" + ] + } +} -```bash -[student@ansible ~]$ cat .ansible.cfg -[defaults] -stdout_callback = community.general.yaml -connection = smart -timeout = 60 -deprecation_warnings = False -host_key_checking = False -retry_files_enabled = False -inventory = /home/student/lab_inventory/hosts ``` -Se proporcionan varios indicadores de configuración. La mayoría de ellos no son de interés aquí, pero asegúrese de anotar la última línea: allí se proporciona la ubicación del inventario. Esa es la forma en que Ansible sabía en los comandos anteriores a qué máquinas conectarse. +NOTA: `-m` es la abreviatura de `--mode`, que permite cambiar el modo a salida estándar en lugar de usar la interfaz de usuario basada en texto (TUI). -Salida del contenido de su archivo de inventario dedicado: +Para una vista menos detallada, `ansible-navigator inventory --graph -m stdout` ofrece una representación visual de los agrupamientos. ```bash -[student@ansible ~]$ cat /home/student/lab_inventory/hosts -[web] -node1 ansible_host=11.22.33.44 -node2 ansible_host=22.33.44.55 -node3 ansible_host=33.44.55.66 +[student@ansible-1 ~]$ ansible-navigator inventory --graph -m stdout +@all: + |--@control: + | |--ansible-1 + |--@ungrouped: + |--@web: + | |--node1 + | |--node2 + | |--node3 -[control] -ansible ansible_host=44.55.66.77 ``` -> **Consejo** -> -> Tenga en cuenta que cada estudiante tiene un entorno de laboratorio individual. Las direcciones IP mostradas anteriormente son solo un ejemplo y las direcciones IP de sus entornos individuales son diferentes. Al igual que con los otros casos, reemplace **\** el número de alumno con el número de estudiante asignado a usted. - -## Paso 3 - Ping a un host - -> **Advertencia** -> -> **No olvide ejecutar los comandos desde el directorio home de su usuario student, `/home/student`. Ahí es donde se encuentra su archivo `.ansible.cfg`, sin él Ansible no sabrá qué inventario usar.** +Podemos ver claramente que los nodos: `node1`, `node2`, `node3` son parte del grupo `web`, mientras que `ansible-1` es parte del grupo `control`. -Comencemos con algo realmente básico - haciendo ping a un hosts. Para ello utilizamos el módulo Ansible 'ping'. El módulo "ping" se asegura de que nuestros hosts de destino respondan. Básicamente, se conecta al host administrado, ejecuta un pequeño script allí y recopila los resultados. Esto garantiza que el host administrado es accesible y que Ansible puede ejecutar comandos correctamente en él. +Un archivo de inventario puede organizar sus hosts en grupos o definir variables. En nuestro ejemplo, el inventario actual tiene los grupos `web` y `control`. Ejecute `ansible-navigator` con estos patrones de host y observe la salida: -> **Consejo** -> -> Piense en un módulo como una herramienta que está diseñada para llevar a cabo una tarea específica. - -Ansible necesita saber que debe usar el módulo `ping`: la opción` -m` define qué módulo de Ansible usar. Las opciones se pueden pasar al módulo especificado utilizando la opción `-a`. +Usando el comando `ansible-navigator inventory`, puede ejecutar comandos que proporcionan información solo para un host o grupo. Por ejemplo, ejecute los siguientes comandos y observe sus diferentes salidas. ```bash -[student@ansible ~]$ ansible web -m ping -node2 | SUCCESS => { - "ansible_facts": { - "discovered_interpreter_python": "/usr/bin/python" - }, - "changed": false, - "ping": "pong" -} -[...] -``` -A medida que se ejecuta, cada nodo informa de la ejecución correcta y el resultado real - aquí "pong". - -## Paso 4 - Listado de módulos y obtención de ayuda - -Ansible viene con una gran cantidad de módulos por defecto. Para listar todos los módulos ejecute: - -```bash -[student@ansible ~]$ ansible-doc -l +[student@ansible-1 ~]$ ansible-navigator inventory --graph web -m stdout +[student@ansible-1 ~]$ ansible-navigator inventory --graph control -m stdout +[student@ansible-1 ~]$ ansible-navigator inventory --host node1 -m stdout ``` > **Consejo** > -> En `ansible-doc` dejar pulsando la letra `q`. Utilice las flechas `arriba`/`abajo` para desplazarse por el contenido. - -Para encontrar un módulo intente, por ejemplo: - -```bash -[student@ansible ~]$ ansible-doc -l | grep -i user -``` +> El inventario puede contener más datos. Por ejemplo, si tiene hosts que se ejecutan en puertos SSH no estándar, puede poner el número de puerto después del nombre de host con dos puntos. También se pueden definir nombres específicos para Ansible y hacer que apunten a la IP o nombre de host. -Obtenga ayuda para un módulo específico que incluya ejemplos de uso: +### Descubrimiento de Módulos -```bash -[student@ansible ~]$ ansible-doc user -``` +La Plataforma de Automatización Ansible viene con múltiples Entornos de Ejecución (EE) soportados. Estos EE vienen con colecciones soportadas empaquetadas que contienen contenido soportado, incluyendo módulos. > **Consejo** > -> Las opciones obligatorias están marcadas con un "=" en `ansible-doc`. +> En `ansible-navigator`, salga presionando el botón `ESC`. -## Paso 5 - Utilice el módulo de comandos: - -Ahora veamos cómo podemos ejecutar un buen comando de Linux creado y formatear la salida usando el módulo `command`. Simplemente ejecuta el comando especificado en un host administrado: +Para explorar los módulos disponibles, primero ingrese al modo interactivo: ```bash -[student@ansible ~]$ ansible node1 -m command -a "id" -node1 | CHANGED | rc=0 >> -uid=1001(student1) gid=1001(student1) Gruppen=1001(student1) Kontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 +$ ansible-navigator ``` -En este caso, el módulo se llama `command` y la opción pasada con `-a` es el comando real que se ejecutará. Intente ejecutar este comando ad hoc en todos los hosts administrados mediante el patrón de host `all`. +![imagen de ansible-navigator](images/interactive-mode.png) -Otro ejemplo: Echa un vistazo rápido a las versiones del kernel que se esta ejecutando en los hosts: +Navegue por una colección escribiendo `:collections` ```bash -[student@ansible ~]$ ansible all -m command -a 'uname -r' +:collections ``` -A veces es deseable tener la salida para un host en una línea: +![imagen de ansible-navigator](images/interactive-collections.png) -```bash -[student@ansible ~]$ ansible all -m command -a 'uname -r' -o -``` +### Acceso a la Documentación de Módulos -> **Consejo** -> -> Al igual que muchos comandos de Linux, `ansible` permite opciones de forma larga, así como de forma corta. Por ejemplo, `ansible web --module-name ping` es lo mismo que ejecutar `ansible web -m ping`. Vamos a utilizar las opciones de forma corta a lo largo de este taller. - -## Paso 6 - Los módulos de copiar y de permisos +Para explorar los módulos de una colección específica, ingrese el número al lado del nombre de la colección. -Mediante el módulo `copy`, ejecute un comando ad hoc en `node1` para cambiar el contenido del archivo `/etc/motd`. **El contenido se entrega al módulo a través de una opción en este caso**. - -Ejecute lo siguiente, pero **espere un error**: +Por ejemplo, en la captura de pantalla anterior, el número `0` corresponde a la colección `amazon.aws`. Para acercarse a la colección, escriba el número `0`. ```bash -[student@ansible ~]$ ansible node1 -m copy -a 'content="Managed by Ansible\n" dest=/etc/motd' +0 ``` -Como se mencionó, esto produce un **error**: +![imagen de ansible-navigator](images/interactive-aws.png) -```bash - node1 | FAILED! => { - "changed": false, - "checksum": "a314620457effe3a1db7e02eacd2b3fe8a8badca", - "failed": true, - "msg": "Destination /etc not writable" - } -``` - -La salida del comando ad hoc está gritando **FAILED** en rojo. ¿por qué? Debido a que el usuario **student\** no puede escribir el archivo motd. - -Ahora este es un caso para el escalado de privilegios y el `sudo` tiene que ser configurado correctamente. Tenemos que indicar a Ansible que use `sudo` para ejecutar el comando como root usando el parámetro `-b` (piense en "become/convertirse en"). - - -> **Consejo** -> -> Ansible se conectará a las máquinas con su nombre de usuario actual (student\ en este caso), al igual que SSH. Para invalidar el nombre de usuario remoto, puede usar el parámetro `-u`. - -Para nosotros está bien conectarse como `student` porque `sudo` está configurado. Cambie el comando para utilizar el parámetro `-b` y vuelva a ejecutar: +Acceda directamente a la documentación detallada de cualquier módulo especificando su número correspondiente. Por ejemplo, el módulo `ec2_tag` corresponde a `24`. ```bash -[student@ansible ~]$ ansible node1 -m copy -a 'content="Managed by Ansible\n" dest=/etc/motd' -b -``` - -Esta vez el comando es un éxito: -``` -node1 | CHANGED => { - "changed": true, - "checksum": "4458b979ede3c332f8f2128385df4ba305e58c27", - "dest": "/etc/motd", - "gid": 0, - "group": "root", - "md5sum": "65a4290ee5559756ad04e558b0e0c4e3", - "mode": "0644", - "owner": "root", - "secontext": "system_u:object_r:etc_t:s0", - "size": 19, - "src": "/home/student1/.ansible/tmp/ansible-tmp-1557857641.21-120920996103312/source", - "state": "file", - "uid": 0 +:24 ``` -Utilice Ansible con el módulo genérico `command` para comprobar el contenido del archivo motd: - -```bash -[student@ansible ~]$ ansible node1 -m command -a 'cat /etc/motd' -node1 | CHANGED | rc=0 >> -Managed by Ansible -``` -Ejecute el comando `ansible node1 -m copy …​` desde arriba de nuevo. Verifique: - - - El color de salida diferente (configuración de terminal adecuada proporcionada). - - El cambio de `"changed": true,` a `"changed": false,`. - - La primera línea dice `SUCCESS` en lugar de `CHANGED`. - +Desplazándose hacia abajo usando las teclas de flecha o página arriba y página abajo puede mostrarnos documentación y ejemplos. -> **Consejo** -> -> Esto hace que sea mucho más fácil detectar los cambios y lo que Ansible realmente hizo. - -## Laboratorios de desafío: Módulos - - - Usando `ansible-doc` - - - Encuentre un módulo que utilice Yum para administrar paquetes de software. - - - Busque los ejemplos de ayuda del módulo para obtener información sobre cómo instalar un paquete en la versión más reciente (latest). +![imagen de ansible-navigator](images/interactive-ec2-tag.png) - - Ejecute un comando Ansible ad hoc para instalar el paquete "squid" en la última versión en `node1`. +Puede acceder directamente a un módulo en particular simplemente escribiendo `:doc namespace.collection.module-name`. Por ejemplo, escribir `:doc amazon.aws.ec2_tag` lo llevaría directamente a la página final mostrada arriba. > **Consejo** > -> Utilice el comando copy ad hoc de arriba como ejemplo y cambie el módulo y las opciones. - -> **Advertencia** -> -> **Solución a continuación\!** - -``` -[student@ansible ~]$ ansible-doc -l | grep -i yum -[student@ansible ~]$ ansible-doc yum -[student@ansible ~]$ ansible node1 -m yum -a 'name=squid state=latest' -b -``` +> Diferentes entornos de ejecución pueden tener acceso a diferentes colecciones y diferentes versiones de esas colecciones. Al usar la documentación integrada, sabe que será precisa para esa versión particular de la colección. ---- **Navegación** diff --git a/exercises/ansible_rhel/1.2-thebasics/README.fr.md b/exercises/ansible_rhel/1.2-thebasics/README.fr.md index 226602c49..a12248784 100644 --- a/exercises/ansible_rhel/1.2-thebasics/README.fr.md +++ b/exercises/ansible_rhel/1.2-thebasics/README.fr.md @@ -1,31 +1,29 @@ -# Exercice - Les Bases d'Ansible +# Exercice d'Atelier - Les Fondamentaux d'Ansible -**Lisez ceci dans d'autres langues**: -
![uk](../../../images/uk.png) [English](README.md), ![japan](../../../images/japan.png)[日本語](README.ja.md), ![brazil](../../../images/brazil.png) [Portugues do Brasil](README.pt-br.md), ![france](../../../images/fr.png) [Français](README.fr.md),![Español](../../../images/col.png) [Español](README.es.md). +**Lisez ceci dans d'autres langues** : +
![uk](../../../images/uk.png) [Anglais](README.md), ![japan](../../../images/japan.png) [日本語](README.ja.md), ![brazil](../../../images/brazil.png) [Portugais du Brésil](README.pt-br.md), ![france](../../../images/fr.png) [Français](README.fr.md), ![Español](../../../images/col.png) [Espagnol](README.es.md). -## Table des matières +## Table des Matières - [Objectif](#objectif) - [Guide](#guide) - - [Étape 1 - Travailler avec votre inventaire](#Étape-1---travailler-avec-votre-inventaire) - - [Étape 2 - Liste des modules et obtention d'aide](#Étape-4---liste-des-modules-et-obtention-d-aide) + - [Les Bases du Fichier d'Inventaire](#les-bases-du-fichier-dinventaire) + - [Découverte de Modules](#découverte-de-modules) + - [Accès à la Documentation des Modules](#accès-à-la-documentation-des-modules) ## Objectif -Dans cet exercice, nous allons explorer le dernier utilitaire en ligne de commande `ansible-navigator` pour apprendre comment travailler avec les fichiers d'inventaire et obtenir la liste des modules en cas de besoin. Le but est de vous familiariser avec le fcontionnement de `ansible-navigator` et la façon dont il peut être utilisé pour enrichir votre expérience Ansible. - -Cet exercice couvrira -* L'utilisation de fichiers d'inventaire -* La localisation et la compréhension d'un fichier d'inventaire au format `ini` -* L'obtention de la liste des modules et d'aide pour les utiliser +Dans cet exercice, nous allons explorer le dernier utilitaire de ligne de commande d'Ansible `ansible-navigator` pour apprendre à travailler avec des fichiers d'inventaire et la liste des modules lorsqu'une assistance est nécessaire. L'objectif est de vous familiariser avec le fonctionnement d'`ansible-navigator` et comment il peut être utilisé pour enrichir votre expérience avec Ansible. ## Guide -### Étape 1 - Travailler avec votre inventaire +### Les Bases du Fichier d'Inventaire + +Un fichier d'inventaire est un fichier texte qui spécifie les nœuds qui seront gérés par la machine de contrôle. Les nœuds à gérer peuvent inclure une liste de noms d'hôtes ou d'adresses IP de ces nœuds. Le fichier d'inventaire permet d'organiser les nœuds en groupes en déclarant un nom de groupe d'hôtes entre crochets ([]). -Un fichier d'inventaire est un fichier texte qui spécifie les noeuds qui seront gérés par la machine de contrôle. Les noeuds à gérer peuvent inclure une liste de hostnames ou les adresses IP de ces hôtes. Le fichier d'inventaire permet d'organiser les noeuds dans des groupes en déclarant un nom de groupe d'hôtes entre des crochets ([]). +### Explorer l'Inventaire -Pour gérer les hôtes avec la commande `ansible-navigator`, vous devez fournir un fichier d'inventaire qui définit une liste d'hôtes à gérer depuis le noeud de contrôle. Dans ce lab, l'inventaire est déjà fourni. Le ficher d'inventaire est un fichier au format `ini` qui liste les hôtes, rangés par groupes, avec des varaiables additionnelles. Il ressemble à ceci : +Pour utiliser la commande `ansible-navigator` pour la gestion des hôtes, vous devez fournir un fichier d'inventaire qui définit une liste d'hôtes à gérer depuis le nœud de contrôle. Dans ce laboratoire, l'inventaire est fourni par votre instructeur. Le fichier d'inventaire est un fichier formaté `ini` listant vos hôtes, triés par groupes, fournissant également certaines variables. Un exemple peut ressembler à ce qui suit : ```bash [web] @@ -37,9 +35,7 @@ node3 ansible_host= ansible-1 ansible_host=44.55.66.77 ``` -Ansible est déjà configuré pour utiliser l'inventaire propre à votre environnement. Nous allons vous montrer dans la prochaine étape comment c'est réalisé. Pour le moment, nous allons exécuter des commandes simples pour travailler avec l'inventaire. - -Pour employer tous les hôtes de l'inventaire, vous fournissez un pattern à la commande `ansible-navigator`. La commande `ansible-navigator inventory` a une option `--list` qui peut être utile pour afficher tous les hôtes qui sont dans un fichier d'inventaire, en incluant les groupes auxquels ils sont associés. +Pour voir votre inventaire avec ansible-navigator, utilisez la commande `ansible-navigator inventory --list -m stdout`. Cette commande affiche tous les nœuds et leurs groupes respectifs. ```bash [student@ansible-1 rhel_workshop]$ cd /home/student @@ -83,9 +79,9 @@ Pour employer tous les hôtes de l'inventaire, vous fournissez un pattern à la ``` -NOTE: `-m` est le raccourci de `--mode` qui permet de changer le mode en output standard au lieu d'utiliser l'interface en mode texte (TUI). +NOTE : `-m` est l'abréviation de `--mode` qui permet de passer au mode de sortie standard au lieu d'utiliser l'interface utilisateur basée sur le texte (TUI). -Si `--list` est trop verbeux, l'option `--graph` peut être utilisée pour fournir une version plus compacte de `--list`. +Pour une vue moins détaillée, `ansible-navigator inventory --graph -m stdout` offre une représentation visuelle des groupements. ```bash [student@ansible-1 ~]$ ansible-navigator inventory --graph -m stdout @@ -100,11 +96,11 @@ Si `--list` est trop verbeux, l'option `--graph` peut être utilisée pour fourn ``` -On peut bien voir que les noeuds: `node1`, `node2`, `node3` sont dans le groupe `web` group, tandis que `ansible-1` est dans le groupe `control`. +Nous pouvons clairement voir que les nœuds : `node1`, `node2`, `node3` font partie du groupe `web`, tandis que `ansible-1` fait partie du groupe `control`. -Un fichier d'inventaire peut contenir bien plus d'informations, il peut organiser les hôtes dans des groupes ou définir des variables. Dans notre exemple, l'inventaire courant a les groupes `web` et `control`. Lancez Ansible avec ces patterns d'hôtes et observez le résultat. +Un fichier d'inventaire peut organiser vos hôtes en groupes ou définir des variables. Dans notre exemple, l'inventaire actuel a les groupes `web` et `control`. Exécutez `ansible-navigator` avec ces modèles d'hôtes et observez la sortie : -En utilisant la commande `ansible-navigator inventory`, on peut aussi lancer des commandes qui fournissent des informations uniquement sur un hôte ou un groupe. Par exemple, essayez la commande suivante pour observer son résultat: +En utilisant la commande `ansible-navigator inventory`, vous pouvez exécuter des commandes qui fournissent des informations uniquement pour un hôte ou un groupe. Par exemple, exécutez les commandes suivantes et observez leurs différentes sorties. ```bash [student@ansible-1 ~]$ ansible-navigator inventory --graph web -m stdout @@ -112,57 +108,62 @@ En utilisant la commande `ansible-navigator inventory`, on peut aussi lancer des [student@ansible-1 ~]$ ansible-navigator inventory --host node1 -m stdout ``` -> **Astuce** +> **Conseil** > -> L'inventaire contient plus de données. Par exemple, si vous avez des hôtes qui exposent un port SSH non standard, vous pouvez renseigner le numéro de port après le nom d'hôte à l'aide des deux-points (:). Ou encore, vous pouvez renseignez dess noms propres à Ansible et les faire pointer vers les adresse IP ou nom d'hôtes réels. +> L'inventaire peut contenir plus de données. Par exemple, si vous avez des hôtes qui fonctionnent sur des ports SSH non standard, vous pouvez mettre le numéro de port après le nom d'hôte avec deux points. On peut également définir des noms spécifiques à Ansible et les faire pointer vers l'IP ou le nom d'hôte. -### Etape 2 - Liste des modules et obtention d aide +### Découverte de Modules -Ansible Automation Platform est livré avec plusieurs Environnements d'Execution (EE) supportés. Ces EE sont fournis avec des collections supportées qui contiennent du contenu supporté, comme des modules. +La Plateforme d'Automatisation Ansible est livrée avec plusieurs Environnements d'Exécution (EE) pris en charge. Ces EE sont livrés avec des collections prises en charge groupées contenant du contenu pris en charge, y compris des modules. -> **Astuce** +> **Conseil** > -> Dans `ansible-navigator` quittez en pressant la touche `ESC`. +> Dans `ansible-navigator`, sortez en appuyant sur le bouton `ESC`. -Pour consulter les modules disponibles, entrez dans le mode interactif: +Pour parcourir vos modules disponibles, entrez d'abord en mode interactif : ```bash $ ansible-navigator ``` -![picture of ansible-navigator](images/interactive-mode.png) +![image d'ansible-navigator](images/interactive-mode.png) -Commencez par consulter une collection en tapant `:collections` +Parcourez une collection en tapant `:collections` ```bash :collections ``` -![picture of ansible-navigator](images/interactive-collections.png) +![image d'ansible-navigator](images/interactive-collections.png) -Pour consulter le contenu d'une collection spécifique, tapez le numéro correspondant. Par exemple, sur la capture d'écran ci-dessus, le numéro `0` correspond à la collection `amazon.aws`. Pour zoomer dans cette collection, tapez `0`. +### Accès à la Documentation des Modules + +Pour explorer les modules d'une collection spécifique, entrez le numéro à côté du nom de la collection. + +Par exemple, dans la capture d'écran ci-dessus, le numéro `0` correspond à la collection `amazon.aws`. Pour zoomer sur la collection, tapez le numéro `0`. ```bash 0 ``` -![picture of ansible-navigator](images/interactive-aws.png) +![image d'ansible-navigator](images/interactive-aws.png) -Obtenez de l'aide pour un module spécifique et son utilisation en zoomant davantage. Par exemple, le module `ec2_tag` correspond à `24`. +Accédez directement à la documentation détaillée de n'importe quel module en spécifiant son numéro correspondant. Par exemple, le module `ec2_tag` correspond à `24`. ```bash :24 ``` -Naviguez vers le bas, en utilisant les flèches ou les boutons page-haut et page-bas, pour obtenir de la documentation et des exemples. +En faisant défiler vers le bas à l'aide des touches fléchées ou de page en haut et page en bas, nous pouvons voir la documentation et les exemples. -![picture of ansible-navigator](images/interactive-ec2-tag.png) +![image d'ansible-navigator](images/interactive-ec2-tag.png) -Vous pouvez aussi sauter directement sur un module particulier en tapant simplement `:doc namespace.collection.module-name`. Par exemple, taper `:doc amazon.aws.ec2_tag` vous amène directement sur la dernière page affichée ci-dessus. +Vous pouvez accéder directement à un module particulier en tapant simplement `:doc namespace.collection.module-name`. Par exemple, taper `:doc amazon.aws.ec2_tag` vous amènerait directement à la page finale montrée ci-dessus. -> **Astuce** +> **Conseil** > -> Différents EE peuvent avoir accès à différentes collections, et différentes versions de ces collections. En utilisant la documentation embarquée, vous savez qu'elle sera appropriée pour cette version particulière de cette collection. +> Différents environnements d'exécution peuvent avoir accès à différentes collections et à différentes versions de ces collections. En utilisant la documentation intégrée, vous savez qu'elle sera précise pour cette version particulière de la collection. + --- **Navigation** diff --git a/exercises/ansible_rhel/1.2-thebasics/README.ja.md b/exercises/ansible_rhel/1.2-thebasics/README.ja.md index eb2488f48..3c25b1122 100644 --- a/exercises/ansible_rhel/1.2-thebasics/README.ja.md +++ b/exercises/ansible_rhel/1.2-thebasics/README.ja.md @@ -1,32 +1,29 @@ -# ワークショップ演習 - Ansible の基本 +# ワークショップ演習 - Ansibleの基本 -**他の言語でもお読みいただけます**: -
![uk](../../../images/uk.png) [English](README.md)、![japan](../../../images/japan.png)[日本語](README.ja.md)、![brazil](../../../images/brazil.png) [Portugues do Brasil](README.pt-br.md)、![france](../../../images/fr.png) [Française](README.fr.md)、![Español](../../../images/col.png) [Español](README.es.md) +**他の言語で読む**: +
![uk](../../../images/uk.png) [英語](README.md), ![japan](../../../images/japan.png) [日本語](README.ja.md), ![brazil](../../../images/brazil.png) [ブラジルのポルトガル語](README.pt-br.md), ![france](../../../images/fr.png) [フランス語](README.fr.md), ![Español](../../../images/col.png) [スペイン語](README.es.md). -## 目次 +## 目次 -* [目的](#目的) -* [ガイド](#ガイド) - * [ステップ 1 - インベントリーの操作](#ステップ-1---インベントリーの操作) - * [ステップ 2 - モジュールの一覧表示とヘルプの利用](#ステップ-2---モジュールの一覧表示とヘルプの利用) +- [目的](#目的) +- [ガイド](#ガイド) + - [インベントリファイルの基本](#インベントリファイルの基本) + - [モジュールの発見](#モジュールの発見) + - [モジュールドキュメントへのアクセス](#モジュールドキュメントへのアクセス) ## 目的 -この演習では、最新の Ansible コマンドラインユーティリティー`ansible-navigator` を使用して、インベントリーファイルの操作方法や、サポートが必要な場合のモジュールの一覧表示について学びます。その目的は`ansible-navigator` がどのように機能するか、また、Ansible の経験を豊かにするためにどのように使用できるかを理解することです。 - -この演習の内容 - -* インベントリーファイルの使用 -* `ini` 形式のインベントリーファイルの場所の確認と理解 -* モジュールの一覧表示と、モジュール使用の際のヘルプの利用 +この演習では、最新のAnsibleコマンドラインユーティリティ `ansible-navigator` を探索し、インベントリファイルの取り扱いと必要なときのモジュールリストの利用方法を学びます。目標は、`ansible-navigator` の動作方法と、Ansible体験を豊かにするための使用方法に慣れることです。 ## ガイド -### ステップ 1 - インベントリーの操作 +### インベントリファイルの基本 -インベントリーファイルとは、コントロールマシンが管理するノードを特定するためのテキストファイルです。管理対象となるノードには、そのノードのホスト名や IP アドレスのリストを含めることができます。インベントリーファイルでは、大かっこ（[]）の中にホストグループ名を宣言することで、ノードをグループにまとめることができます。 +インベントリファイルは、コントロールマシンによって管理されるノードを指定するテキストファイルです。管理されるノードには、それらのノードのホスト名またはIPアドレスのリストが含まれる場合があります。インベントリファイルを使用すると、ホストグループ名を角括弧([])内に宣言することで、ノードをグループに整理できます。 -ホストの管理に `ansible-navigator` コマンドを使用するには、インベントリーファイルを指定する必要があります。このファイルは、コントロールノードから管理されるホストの一覧を定義します。このラボでは、インベントリーはインストラクターから渡されます。このインベントリーファイルは `ini` 形式のファイルです。このファイルでは、グループで並び替えられたホストの一覧があります。また、変数いくつか指定しています。 +### インベントリの探索 + +`ansible-navigator` コマンドをホスト管理に使用するには、コントロールノードから管理されるホストのリストを定義するインベントリファイルを提供する必要があります。このラボでは、インベントリはあなたのインストラクターによって提供されます。インベントリファイルは、ホストをグループに分類してリストし、さらにいくつかの変数を提供する `ini` 形式のファイルです。例は以下のようになります： ```bash [web] @@ -38,10 +35,7 @@ node3 ansible_host= ansible-1 ansible_host=44.55.66.77 ``` -Ansible はすでに、お使いの環境に固有のインベントリーを使用するように設定されています。これを行うための次の手順を説明します。今のところは、簡単なコマンドをいくつか実行して、インベントリーの操作を行います。 - -すべてのインベントリホストを参照するには、`ansible-navigator` コマンドにパターンを指定します。 `ansible-navigator inventory` には `--list` オプションがあり、インベントリファイルに含まれるすべてのホストを、それらが関連付けられているグループも含めて表示するのに便利です。 - +ansible-navigator でインベントリを表示するには、コマンド `ansible-navigator inventory --list -m stdout` を使用します。このコマンドは、すべてのノードとそれぞれのグループを表示します。 ```bash [student@ansible-1 rhel_workshop]$ cd /home/student @@ -50,8 +44,7 @@ Ansible はすでに、お使いの環境に固有のインベントリーを使 "_meta": { "hostvars": { "ansible-1": { - "ansible_host": "3.236.186.92" - }, + "ansible_host": "3.236.186.92" }, "node1": { "ansible_host": "3.239.234.187" }, @@ -86,9 +79,9 @@ Ansible はすでに、お使いの環境に固有のインベントリーを使 ``` -注記: `-m` は `--mode` の略で、テキストベースのユーザーインターフェース (TUI) を使用する代わりに、モードを標準出力に切り替えることができます。 +注意：`-m` は `--mode` の略で、テキストベースのユーザーインターフェース (TUI) を使用する代わりに標準出力にモードを切り替えることができます。 -`--list` が冗長すぎる場合は、`--graph` のオプションを使用して、より補正されたバージョンの `--list` を提供することができます。 +より詳細なビューが不要な場合、`ansible-navigator inventory --graph -m stdout` はグルーピングの視覚的表現を提供します。 ```bash [student@ansible-1 ~]$ ansible-navigator inventory --graph -m stdout @@ -103,12 +96,11 @@ Ansible はすでに、お使いの環境に固有のインベントリーを使 ``` -ノード `node1`、`node2`、`node3` が `web` グループの一部であることを明確に確認することができます。`ansible-1` は `control` グループの一部であることが分かります。 +明らかに、`node1`、`node2`、`node3` は `web` グループの一部であり、`ansible-1` は `control` グループの一部です。 +インベントリファイルは、ホストをグループに整理したり、変数を定義したりすることができます。私たちの例では、現在のインベントリには `web` と `control` のグループがあります。これらのホストパターンで `ansible-navigator` を実行し、出力を観察してください： -インベントリーファイルにはより多くの情報が含まれます。また、このファイルは、グループでホストを整理したり、変数を定義したりできます。この例では、現在のインベントリーにグループ `web` と `control` がります。Ansible をこれらのホストパターンで実行し、出力を確認します。 - -`ansible-navigator inventory` コマンドを使用して、1つのホストまたはグループに情報を提供するコマンドを実行することもできます。たとえば、以下のコマンドを実行すると出力が表示されます。 +`ansible-navigator inventory` コマンドを使用すると、1つのホストまたはグループにのみ情報を提供するコマンドを実行できます。例えば、以下のコマンドを実行し、それぞれの出力を観察してください。 ```bash [student@ansible-1 ~]$ ansible-navigator inventory --graph web -m stdout @@ -118,55 +110,59 @@ Ansible はすでに、お使いの環境に固有のインベントリーを使 > **ヒント** > -> このイベントリーには、その他のデータを含めることができます。たとえば、標準以外の SSH ポートで実行するホストがある場合は、コロン付きのホスト名の後にポート番号を指定できます。あるいは、Ansible 固有の名前を定義して、真の IP またはホスト名に参照するようにできます。 +> インベントリには、より多くのデータを含めることができます。例えば、標準ではないSSHポートで実行されているホストがある場合、ホスト名の後にコロンとポート番号を置くことができます。Ansibleに特有の名前も定義して、それをIPアドレスまたはホスト名に指すことができます。 + +### モジュールの発見 +Ansibleオートメーションプラットフォームには、複数のサポートされている実行環境 (EE) が付属しています。これらのEEには、サポートされているコンテンツ、モジュールを含むサポートされたコレクションがバンドルされています。 -### ステップ 2 - モジュールの一覧表示とヘルプの利用 +> **ヒント** +> +> `ansible-navigator` では、`ESC` ボタンを押すことで終了できます。 -Ansible Automation Platform には、サポートされる複数の実行環境 (EE) が同梱されています。これらの EE には、モジュールを含む、サポートされているコンテンツが含まれるバンドルされたサポート対象のコレクションが同梱されています。利用可能なモジュールを参照するには、最初にインタラクティブモードに入ります。 +利用可能なモジュールをブラウズするには、まずインタラクティブモードに入ります： ```bash $ ansible-navigator ``` -![picture of ansible-navigator](images/interactive-mode.png) - -> **ヒント** -> -> 終了するには、`ansible-navigator` で `ESC` ボタンを押します。 +![ansible-navigatorの画像](images/interactive-mode.png) -まず、`:collections` と入力してコレクションを参照します +`:collections` と入力してコレクションをブラウズします。 ```bash -$ :collections +:collections ``` -![picture of ansible-navigator](images/interactive-collections.png) +![ansible-navigatorの画像](images/interactive-collections.png) + +### モジュールドキュメントへのアクセス -特定のコレクションのコンテンツを参照するには、対応する番号を入力します。たとえば、上記のスクリーンショットの例では、数字 `0` は `amazon.aws` コレクションに対応します。コレクションタイプにズームインするには、番号 `0` を入力します。 +特定のコレクションのモジュールを探索するには、コレクション名の隣にある番号を入力します。 + +例えば、上のスクリーンショットでは、`0` の番号が `amazon.aws` コレクションに対応しています。コレクションにズームインするには、`0` と入力します。 ```bash -$ 0 +0 ``` -![picture of ansible-navigator](images/interactive-aws.png) - +![ansible-navigatorの画像](images/interactive-aws.png) -さらにズームすることで、使用など特定のモジュールに関するヘルプを利用します。たとえば、モジュール `ec2_tag` は `24` に対応します。 +任意のモジュールの詳細なドキュメントに直接アクセスするには、その対応する番号を指定します。例えば、モジュール `ec2_tag` は `24` に対応しています。 ```bash -$ :24 +:24 ``` -矢印キーまたはページアップとページダウンを使用してスクロールダウンすると、ドキュメントと例が表示されます。 +矢印キーまたはページアップ、ページダウンを使用してスクロールすると、ドキュメントと例を表示できます。 -![picture of ansible-navigator](images/interactive-ec2-tag.png) +![ansible-navigatorの画像](images/interactive-ec2-tag.png) -`:doc namespace.collection.module-name` を入力して、特定のモジュールに直接ジャンプすることもできます。たとえば、`:doc amazon.aws.ec2_tag` を入力すると、上記の最後のページに直接ジャンプします。 +`:doc namespace.collection.module-name` と入力するだけで、特定のモジュールに直接スキップできます。例えば `:doc amazon.aws.ec2_tag` と入力すると、上に示した最後のページに直接スキップします。 > **ヒント** > -> 実行環境によって、アクセスできるコレクションおよびそのコレクションのバージョンが異なります。組み込みのドキュメントを使用して、コレクションのその特定のバージョンに対して正確であることが分かります。 +> 異なる実行環境では、異なるコレクションやそれらのコレクションの異なるバージョンにアクセスできます。組み込みのドキュメントを使用することで、その特定のコレクションのバージョンに対して正確であることがわかります。 --- **Navigation** diff --git a/exercises/ansible_rhel/1.2-thebasics/README.pt-br.md b/exercises/ansible_rhel/1.2-thebasics/README.pt-br.md index e36f7ab7c..3895258a3 100644 --- a/exercises/ansible_rhel/1.2-thebasics/README.pt-br.md +++ b/exercises/ansible_rhel/1.2-thebasics/README.pt-br.md @@ -1,24 +1,29 @@ -# Exercício - Executando comandos ad-hoc +# Exercício de Workshop - Os Fundamentos do Ansible -**Leia em outras linguagens**: -
![uk](../../../images/uk.png) [English](README.md), ![japan](../../../images/japan.png)[日本語](README.ja.md), ![brazil](../../../images/brazil.png) [Portugues do Brasil](README.pt-br.md), ![france](../../../images/fr.png) [Française](README.fr.md),![Español](../../../images/col.png) [Español](README.es.md). +**Leia isso em outros idiomas**: +
![uk](../../../images/uk.png) [Inglês](README.md), ![japan](../../../images/japan.png) [日本語](README.ja.md), ![brazil](../../../images/brazil.png) [Português do Brasil](README.pt-br.md), ![france](../../../images/fr.png) [Francês](README.fr.md),![Español](../../../images/col.png) [Espanhol](README.es.md). -Em nosso primeiro exercício, executaremos alguns comandos ad-hoc para ajudá-lo a entender como o Ansible funciona. Os comandos ad-hoc permitem executar tarefas em nós remotos sem precisar escrever um manual. Eles são muito úteis quando você simplesmente precisa fazer uma ou duas coisas de maneira rápida e frequente para muitos nós remotos. +## Índice de Conteúdos -## Table of Contents +- [Objetivo](#objetivo) +- [Guia](#guia) + - [Noções Básicas de Arquivo de Inventário](#noções-básicas-de-arquivo-de-inventário) + - [Descoberta de Módulos](#descoberta-de-módulos) + - [Acessando Documentação de Módulos](#acessando-documentação-de-módulos) -* [Passo 1 - Trabalhe com seu inventário](#passo-1---trabalhe-com-seu-inventário) -* [Passo 2 - Arquivos de configuração Ansible](#passo-2---arquivos-de-configuração-ansible) -* [Passo 3 - Pingando um host](#passo-3---pingando-um-host) -* [Passo 4 - Como listar módulos e obter ajuda](#passo-4---como-listar-módulos-e-obter-ajuda) -* [Passo 5 - Use o módulo de command:](#passo-5---use-o-módulo-de-command) -* [Passo 6 - O módulo de cópia e permissões](#passo-6---o-módulo-de-cópia-e-permissões) -* [Laboratório de Desafios: Módulos](#laboratório-de-desafios-módulos) +## Objetivo +Neste exercício, vamos explorar a mais recente ferramenta de linha de comando do Ansible, o `ansible-navigator`, para aprender a trabalhar com arquivos de inventário e a listar módulos quando precisarmos de ajuda. O objetivo é familiarizar-se com o funcionamento do `ansible-navigator` e como ele pode ser utilizado para enriquecer sua experiência com o Ansible. -## Passo 1 - Trabalhe com seu inventário +## Guia -Para usar o comando ansible para gerenciamento de host, é necessário fornecer um arquivo de inventário que defina uma lista de hosts a serem gerenciados a partir do nó de controle. Neste laboratório, o inventário é fornecido pelo seu instrutor. O inventário é um arquivo listando seus hosts, classificando em grupos, além de fornecer algumas variáveis. É parecido com isso: +### Noções Básicas de Arquivo de Inventário + +Um arquivo de inventário é um arquivo de texto que especifica os nós que serão gerenciados pela máquina de controle. Os nós a serem gerenciados podem incluir uma lista de nomes de host ou endereços IP desses nós. O arquivo de inventário permite organizar os nós em grupos, declarando um nome de grupo de host entre colchetes ([]). + +### Explorando o Inventário + +Para usar o comando `ansible-navigator` para gerenciamento de hosts, você precisa fornecer um arquivo de inventário que define uma lista de hosts a serem gerenciados a partir do nó de controle. Neste laboratório, o inventário é fornecido pelo seu instrutor. O arquivo de inventário é um arquivo formatado em `ini` que lista seus hosts, organizados em grupos, fornecendo também algumas variáveis. Um exemplo pode ser visto a seguir: ```bash [web] @@ -27,261 +32,137 @@ node2 ansible_host= node3 ansible_host= [control] -ansible ansible_host=44.55.66.77 -``` - -O Ansible já está configurado para usar o inventário específico para o seu ambiente. Mostraremos na próxima etapa como isso é feito. Por enquanto, executaremos alguns comandos simples para trabalhar com o inventário. - -Para referenciar hosts de inventário, você fornece um padrão de host ao comando ansible. O Ansible possui a opção `--list-hosts` que pode ser útil para esclarecer quais hosts gerenciados são referenciados pelo padrão de host em um comando ansible. - -O padrão de host mais básico é o nome de um único host gerenciado listado no arquivo de inventário. Isso especifica que o host será o único no arquivo de inventário que será acionado pelo comando ansible. Execute: - -```bash -[studentansible ~]$ ansible node1 --list-hosts - hosts (1): - node1 -``` - -Um arquivo de inventário pode conter muitas outras informações, como organizar seus hosts em grupos ou definir variáveis. No nosso exemplo, o inventário atual possui os grupos `web` e `control`. Execute o Ansible com esses padrões de host e observe a saída: - -```bash -[studentansible ~]$ ansible web --list-hosts -[studentansible ~]$ ansible web,ansible --list-hosts -[studentansible ~]$ ansible 'node*' --list-hosts -[studentansible ~]$ ansible all --list-hosts -``` - -Como você pode ver, não há problema em colocar sistemas em mais de um grupo. Por exemplo, um servidor pode ser um servidor web e um servidor de banco de dados. Observe que no Ansible os grupos não são necessariamente hierárquicos. - -> **Dica** -> -> O inventário pode conter mais dados. Por exemplo, se você possui hosts que executam em portas SSH não padrão, pode colocar o número da porta após o nome do host com dois pontos. Ou pode definir nomes específicos para o Ansible e fazer com que aponte para o IP ou nome de host "real". - -## Passo 2 - Arquivos de configuração Ansible - -O comportamento do Ansible pode ser personalizado modificando as configurações no arquivo de configuração do Ansible. O Ansible selecionará seu arquivo de configuração em um dos vários locais possíveis no nó de controle, consulte a [documentação](https://docs.ansible.com/ansible/latest/reference_appendices/config.html). - -> **Dica** -> -> A prática recomendada é criar um arquivo `ansible.cfg` no diretório a partir do qual você executa os comandos Ansible. Esse diretório também contém todos os arquivos usados pelo seu projeto Ansible, como o inventário e os playbooks. Outra prática recomendada é criar um arquivo `.ansible.cfg` no seu diretório pessoal. - -No ambiente de laboratório fornecido a você, um arquivo `.ansible.cfg` já foi criado e preenchido com os detalhes necessários no diretório inicial do seu usuário `student` no nó de controle: - -```bash -[student@ansible ~]$ ls -la .ansible.cfg --rw-r--r--. 1 student student 231 14. Mai 17:17 .ansible.cfg -``` - -Saída do conteúdo do arquivo: +ansible-1 ansible_host=44.55.66.77 +``` + +Para visualizar seu inventário com ansible-navigator, use o comando `ansible-navigator inventory --list -m stdout`. Este comando exibe todos os nós e seus respectivos grupos. + +```bash +[student@ansible-1 rhel_workshop]$ cd /home/student +[student@ansible-1 ~]$ ansible-navigator inventory --list -m stdout +{ + "_meta": { + "hostvars": { + "ansible-1": { + "ansible_host": "3.236.186.92" }, + "node1": { + "ansible_host": "3.239.234.187" + }, + "node2": { + "ansible_host": "75.101.228.151" + }, + "node3": { + "ansible_host": "100.27.38.142" + } + } + }, + "all": { + "children": [ + "control", + "ungrouped", + "web" + ] + }, + "control": { + "hosts": [ + "ansible-1" + ] + }, + "web": { + "hosts": [ + "node1", + "node2", + "node3" + ] + } +} -```bash -[student@ansible ~]$ cat .ansible.cfg -[defaults] -stdout_callback = community.general.yaml -connection = smart -timeout = 60 -deprecation_warnings = False -host_key_checking = False -retry_files_enabled = False -inventory = /home/student/lab_inventory/hosts ``` -Existem vários sinalizadores de configuração fornecidos. A maioria deles não é interessante aqui, mas lembre-se da última linha: lá é fornecida a localização do inventário. Essa é a maneira que o Ansible sabe nos comandos anteriores a que máquinas se conectar. +NOTA: `-m` é uma abreviação para `--mode` que permite alternar o modo para saída padrão em vez de usar a interface de usuário baseada em texto (TUI). -Saída de conteúdo do seu inventário dedicado: +Para uma visão menos detalhada, `ansible-navigator inventory --graph -m stdout` oferece uma representação visual dos agrupamentos. ```bash -[student@ansible ~]$ cat /home/student/lab_inventory/hosts -[web] -node1 ansible_host=11.22.33.44 -node2 ansible_host=22.33.44.55 -node3 ansible_host=33.44.55.66 - -[control] -ansible ansible_host=44.55.66.77 -``` - -> **Dica** -> -> Observe que cada aluno tem um ambiente de laboratório individual. Os endereços IP mostrados acima são apenas um exemplo e os endereços IP de seus ambientes individuais são diferentes. Como nos outros casos, substitua **\** pelo número real do aluno. - -## Passo 3 - Pingando um host - -> **ATENÇÃO** -> -> **Não se esqueça de executar os comandos no diretório inicial do usuário do aluno, `/home/student`. É aí que o seu arquivo `.ansible.cfg` está localizado, sem ele o Ansible não saberá qual inventário usar.** - -Vamos começar com algo realmente básico - executando ping em um host. Para fazer isso, usamos o módulo `ping`. O módulo `ping` garante que nossos hosts de destino sejam responsivos. Basicamente, ele se conecta ao host gerenciado, executa um pequeno script e coleta os resultados. Isso garante que o host gerenciado esteja acessível e que o Ansible possa executar comandos corretamente nele. - -> **Dica** -> -> Pense em um módulo como uma ferramenta projetada para realizar uma tarefa específica. - -O Ansible precisa saber que deve usar o módulo `ping` : A opção `-m` define qual módulo usar. As opções podem ser passadas para o módulo especificado usando a opção `-a`. +[student@ansible-1 ~]$ ansible-navigator inventory --graph -m stdout +@all: + |--@control: + | |--ansible-1 + |--@ungrouped: + |--@web: + | |--node1 + | |--node2 + | |--node3 -```bash -[student@ansible ~]$ ansible web -m ping -node2 | SUCCESS => { - "ansible_facts": { - "discovered_interpreter_python": "/usr/bin/python" - }, - "changed": false, - "ping": "pong" -} -[...] ``` -Como você vê cada nó relata a execução bem-sucedida e o resultado real - "pong". +Podemos ver claramente que os nós: `node1`, `node2`, `node3` fazem parte do grupo `web`, enquanto `ansible-1` faz parte do grupo `control`. -## Passo 4 - Como listar módulos e obter ajuda +Um arquivo de inventário pode organizar seus hosts em grupos ou definir variáveis. Em nosso exemplo, o inventário atual possui os grupos `web` e `control`. Execute `ansible-navigator` com esses padrões de host e observe a saída: -O Ansible vem com muitos módulos por padrão. Para listar todos os módulos, execute: +Usando o comando `ansible-navigator inventory`, você pode executar comandos que fornecem informações apenas para um host ou grupo. Por exemplo, execute os seguintes comandos e observe suas saídas diferentes. ```bash -[student@ansible ~]$ ansible-doc -l +[student@ansible-1 ~]$ ansible-navigator inventory --graph web -m stdout +[student@ansible-1 ~]$ ansible-navigator inventory --graph control -m stdout +[student@ansible-1 ~]$ ansible-navigator inventory --host node1 -m stdout ``` > **Dica** > -> No `ansible-doc`, pressione o botão `q`. Use as setas `up`/`down` para rolar pelo conteúdo. +> O inventário pode conter mais dados. Por exemplo, se você tem hosts que rodam em portas SSH não padrão, você pode colocar o número da porta após o nome do host com dois pontos. Também é possível definir nomes específicos para o Ansible e fazê-los apontar para o IP ou nome do host. -Para encontrar um módulo, tente por exemplo: +### Descoberta de Módulos -```bash -[student@ansible ~]$ ansible-doc -l | grep -i user -``` - -Obtenha ajuda para um módulo específico, incluindo exemplos de uso: - -```bash -[student@ansible ~]$ ansible-doc user -``` +A Plataforma de Automação Ansible vem com vários Ambientes de Execução suportados (EEs). Esses EEs vêm com coleções suportadas agrupadas que contêm conteúdo suportado, incluindo módulos. > **Dica** > -> As opções obrigatórias são marcadas com "=" em `ansible-doc`. +> Em `ansible-navigator`, saia pressionando o botão `ESC`. -## Passo 5 - Use o módulo de command: - -Agora vamos ver como podemos executar um bom e velho comando Linux e formatar a saída usando o módulo `command`. Ele simplesmente executa o comando especificado em um host gerenciado: - -```bash -[student@ansible ~]$ ansible node1 -m command -a "id" -node1 | CHANGED | rc=0 >> -uid=1001(student1) gid=1001(student1) Gruppen=1001(student1) Kontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 -``` -Nesse caso, o módulo é chamado de `command` e a opção passada com `-a` é o comando real a ser executado. Tente executar este comando ad hoc em todos os hosts gerenciados usando o padrão de host `all`. - -Outro exemplo: Veja rapidamente as versões do kernel que seus hosts estão executando: +Para navegar pelos seus módulos disponíveis, primeiro entre no modo interativo: ```bash -[student@ansible ~]$ ansible all -m command -a 'uname -r' +$ ansible-navigator ``` -Às vezes, é desejável ter a saída para um host em uma linha: - -```bash -[student@ansible ~]$ ansible all -m command -a 'uname -r' -o -``` - -> **Dica** -> -> Como muitos comandos do Linux, o `ansible` permite opções longas e curtas. Por exemplo, `ansible web --module-name ping` é o mesmo que executar `ansible web -m ping`. Usaremos as opções resumidas ao longo deste workshop. - -## Passo 6 - O módulo de cópia e permissões - -Usando o módulo `copy`, execute um comando ad hoc no `node1` para alterar o conteúdo do arquivo `/etc/motd`. **Neste caso o conteúdo é entregue ao módulo através de uma opção**. - -Execute o seguinte, mas **espere um erro**: +![imagem do ansible-navigator](images/interactive-mode.png) -```bash -[student@ansible ~]$ ansible node1 -m copy -a 'content="Managed by Ansible\n" dest=/etc/motd' -``` -Como mencionado, isso produz um **erro**: +Navegue por uma coleção digitando `:collections` ```bash - node1 | FAILED! => { - "changed": false, - "checksum": "a314620457effe3a1db7e02eacd2b3fe8a8badca", - "failed": true, - "msg": "Destination /etc not writable" - } +:collections ``` -A saída do comando ad hoc está alertando **FAILED** em vermelho para você. Por quê? Porque o usuário **student\** não tem permissão para gravar o arquivo motd. +![imagem do ansible-navigator](images/interactive-collections.png) -Este é um caso de escalonamento de privilégios e a razão pela qual o `sudo` precisa ser configurado corretamente. Precisamos instruir o Ansible a usar o `sudo` para executar o comando como root usando o parâmetro `-b` (pense em "Become"). +### Acessando Documentação de Módulos -> **Dica** -> -> O Ansible se conectará às máquinas usando seu nome de usuário atual (aluno\ neste caso), assim como o SSH faria. Para substituir o nome de usuário remoto, você pode usar o parâmetro `-u`. +Para explorar os módulos de uma coleção específica, insira o número ao lado do nome da coleção. -Para nós, não há problema em se conectar como `student` porque o `sudo` está configurado. Mude o comando para usar o parâmetro `-b` e execute novamente: +Por exemplo, na captura de tela acima, o número `0` corresponde à coleção `amazon.aws`. Para ampliar a visualização da coleção, digite o número `0`. ```bash -[student@ansible ~]$ ansible node1 -m copy -a 'content="Managed by Ansible\n" dest=/etc/motd' -b +0 ``` -Desta vez, o comando é um sucesso: - -```bash -node1 | CHANGED => { - "changed": true, - "checksum": "4458b979ede3c332f8f2128385df4ba305e58c27", - "dest": "/etc/motd", - "gid": 0, - "group": "root", - "md5sum": "65a4290ee5559756ad04e558b0e0c4e3", - "mode": "0644", - "owner": "root", - "secontext": "system_u:object_r:etc_t:s0", - "size": 19, - "src": "/home/student1/.ansible/tmp/ansible-tmp-1557857641.21-120920996103312/source", - "state": "file", - "uid": 0 -``` +![imagem do ansible-navigator](images/interactive-aws.png) -Use Ansible com o módulo genérico `command` para verificar o conteúdo do arquivo motd: +Acesse diretamente a documentação detalhada de qualquer módulo especificando seu número correspondente. Por exemplo, o módulo `ec2_tag` corresponde ao número `24`. ```bash -[student@ansible ~]$ ansible node1 -m command -a 'cat /etc/motd' -node1 | CHANGED | rc=0 >> -Managed by Ansible +:24 ``` -Execute o comando `ansible node1 -m copy…​` de cima novamente. Nota: +Rolando para baixo usando as teclas de seta ou page-up e page-down, podemos ver documentação e exemplos. - - A cor de saída diferente (configuração de terminal adequada fornecida). -   - A mudança de `"changed": true,` para `"changed": false,`. -   - A primeira linha diz `SUCCESS` em vez de`CHANGED`. +![imagem do ansible-navigator](images/interactive-ec2-tag.png) -> **Dica** -> -> Isso facilita muito a identificação de alterações e o que o Ansible realmente fez. - -## Laboratório de Desafios: Módulos - - - Usando o `ansible-doc` - -       - Encontre um módulo que use o Yum para gerenciar pacotes de software. - -       - Procure os exemplos de ajuda do módulo para saber como instalar um pacote na versão mais recente. - -   - Execute um comando Ansible ad hoc para instalar o pacote "squid" na versão mais recente no `node1`. +Você pode ir diretamente para um módulo específico simplesmente digitando `:doc namespace.collection.module-name`. Por exemplo, digitar `:doc amazon.aws.ec2_tag` iria direto para a página final mostrada acima. > **Dica** > -> Use o comando ad hoc copy de cima como modelo e altere o módulo e as opções. - -> **ATENÇÃO** -> -> **Solução abaixo\!** - -```bash -[student@ansible ~]$ ansible-doc -l | grep -i yum -[student@ansible ~]$ ansible-doc yum -[student@ansible ~]$ ansible node1 -m yum -a 'name=squid state=latest' -b -``` +> Ambientes de execução diferentes podem ter acesso a diferentes coleções e diferentes versões dessas coleções. Ao usar a documentação integrada, você sabe que será precisa para aquela versão específica da coleção. ---- diff --git a/exercises/ansible_rhel/1.3-playbook/README.es.md b/exercises/ansible_rhel/1.3-playbook/README.es.md index 06d7a17be..4b386905b 100644 --- a/exercises/ansible_rhel/1.3-playbook/README.es.md +++ b/exercises/ansible_rhel/1.3-playbook/README.es.md @@ -1,351 +1,113 @@ -# Workshop - Escribir su primer Playbook +# Ejercicio del Taller - Escribiendo Tu Primer Playbook -**Leer esto en otros idiomas**: -
![uk](../../../images/uk.png) [English](README.md), ![japan](../../../images/japan.png)[日本語](README.ja.md), ![brazil](../../../images/brazil.png) [Portugues do Brasil](README.pt-br.md), ![france](../../../images/fr.png) [Française](README.fr.md),![Español](../../../images/col.png) [Español](README.es.md). +**Lea esto en otros idiomas**: +
![uk](../../../images/uk.png) [Inglés](README.md), ![japan](../../../images/japan.png) [日本語](README.ja.md), ![brazil](../../../images/brazil.png) [Portugués de Brasil](README.pt-br.md), ![france](../../../images/fr.png) [Francés](README.fr.md), ![Español](../../../images/col.png) [Español](README.es.md). -## Tabla de contenidos +## Índice de Contenidos -- [Objetivos](#objective) -- [Guía](#guide) - - [Paso 1 - Fundamentos del los playbooks](#step-1---playbook-basics) - - [Paso 2 - Creación de una estructura de directorios y un archivo para su Playbook](#step-2---creating-a-directory-structure-and-file-for-your-playbook) - - [Paso 3 - Ejecución del Playbook](#step-3---running-the-playbook) - - [Paso 4 - Extiende tu Playbook: Iniciar & Habilitar Apache](#step-4---extend-your-playbook-start--enable-apache) - - [Paso 5 - Extiende tu Playbook: Crear un web.html](#step-5---extend-your-playbook-create-an-indexhtml) - - [Paso 6 - Práctica: Aplicar a múltiples hosts](#step-6---practice-apply-to-multiple-host) +- [Ejercicio del Taller - Escribiendo Tu Primer Playbook](#ejercicio-del-taller---escribiendo-tu-primer-playbook) + - [Objetivo](#objetivo) + - [Guía](#guía) + - [Paso 1 - Fundamentos del Playbook](#paso-1---fundamentos-del-playbook) + - [Paso 2 - Creando Tu Playbook](#paso-2---creando-tu-playbook) + - [Paso 3 - Ejecutando el Playbook](#paso-3---ejecutando-el-playbook) + - [Paso 4 - Verificando el Playbook](#paso-4---verificando-el-playbook) -# Objetivos +## Objetivos -Este ejercicio cubre el uso de Ansible para crear dos servidores web Apache en Red Hat Enterprise Linux. Este ejercicio cubre los siguientes fundamentos de Ansible: +En este ejercicio, utilizarás Ansible para realizar tareas básicas de configuración del sistema en un servidor Red Hat Enterprise Linux. Te familiarizarás con módulos fundamentales de Ansible como `dnf` y `user`, y aprenderás cómo crear y ejecutar playbooks. -- Comprender los parámetros de los módulos de ansible -- Comprender y utilizar los siguientes módulos - - [módulo yum](https://docs.ansible.com/ansible/latest/modules/yum_module.html) - - [módulo service](https://docs.ansible.com/ansible/latest/modules/service_module.html) - - [módulo copy](https://docs.ansible.com/ansible/latest/modules/copy_module.html) -- Comprender la [Idempotencia](https://en.wikipedia.org/wiki/Idempotence) y cómo los módulos Ansible pueden ser idempotentes +## Guía -# Guía +Los playbooks en Ansible son esencialmente scripts escritos en formato YAML. Se utilizan para definir las tareas y configuraciones que Ansible aplicará a tus servidores. -Aunque los comandos ad hoc de Ansible son útiles para operaciones sencillas, no son adecuados para escenarios complejos de administración de configuraciones o orquestación. Para estos casos de uso *playbooks* son el camino a seguir. +### Paso 1 - Fundamentos del Playbook +Primero, crea un archivo de texto en formato YAML para tu playbook. Recuerda: +- Comenzar con tres guiones (`---`). +- Utilizar espacios, no tabulaciones, para la indentación. -Los Playbooks son archivos que describen las configuraciones deseadas o los pasos para implementar en hosts administrados. Los playbooks pueden cambiar tareas administrativas largas y complejas en rutinas fácilmente repetibles con resultados predecibles y exitosos. +Conceptos Clave: +- `hosts`: Especifica los servidores o dispositivos objetivo para que tu playbook se ejecute en contra. +- `tasks`: Las acciones que Ansible realizará. +- `become`: Permite la escalada de privilegios (ejecutar tareas con privilegios elevados). -Un playbook es donde puedes tomar algunos de esos comandos ad hoc que acabas de ejecutar y ponerlos en un conjunto repetible de *plays* y *tasks*. +> NOTA: Un playbook de Ansible está diseñado para ser idempotente, lo que significa que si lo ejecutas varias veces en los mismos hosts, asegura el estado deseado sin hacer cambios redundantes. -Un playbook puede tener varias jugadas y una jugada puede tener una o varias tareas. En una tarea se llama a un *módulo*, como los módulos del capítulo anterior. El objetivo de un *play* es mapear un grupo de hosts. El objetivo de una *tarea* es implementar módulos en esos hosts. - -> **Consejo** -> -> Aquí hay una buena analogía: Cuando los módulos Ansible son las herramientas en su taller, el inventario son los materiales y los Playbooks son las instrucciones. - -## Paso 1 - Fundamentos del los playbooks - -Los Playbooks son archivos de texto escritos en formato YAML y por lo tanto necesitan: - - - empezar con tres guiones (`---`) - - - sangría adecuada utilizando espacios y **no** tabuladores\! - - -Hay algunos conceptos importantes: - - - **hosts**: los hosts administrados para realizar las tareas en - - - **tasks**: las operaciones a realizar invocando módulos Ansible y pasándoles las opciones necesarias. - - - **become**: privilege escalation in Playbooks, same as using `-b` in the ad hoc command. - -> **Advertencia** -> -> El orden de los contenidos dentro de un Playbook es importante, ya que Ansible ejecuta jugadas y tareas en el orden en que se presentan. - -Un Playbook debe ser **idempotente**, por lo que si un Playbook se ejecuta una vez para poner los hosts en el estado correcto, debe ser seguro ejecutarlo una segunda vez y no debe realizar más cambios en los hosts. - -> **Consejo** -> -> La mayoría de los módulos Ansible son idempotentes, por lo que es relativamente fácil asegurarse de que esto sea cierto. - - -## Paso 2 - Creación de una estructura de directorios y un archivo para su Playbook - -Suficiente teoría, es hora de crear tu primer Ansible Playbook. En este laboratorio se crea un playbook para configurar un servidor web Apache en tres pasos: - - 1. Instalar el paquete httpd - - 2. Habilitar/iniciar el servicio httpd - - 3. Copiar sobre un archivo web.html en cada host web - -Este Playbook se asegura de que el paquete que contiene el servidor web Apache esté instalado en `node1`. - -Hay una documento de [mejores prácticas](https://docs.ansible.com/ansible/latest/user_guide/playbooks_best_practices.html) en las estructuras de directorio preferidas para los playbooks. Le recomendamos encarecidamente que lea y entienda estas prácticas a medida que desarrolla sus habilidades ninja en Ansible. Dicho esto, nuestro playbook de hoy es muy básico y la creación de una estructura compleja sólo confundirá las cosas. - -En su lugar, vamos a crear una estructura de directorios muy simple para nuestro playbook, y añadir sólo un par de archivos a él. - -En el host de control **ansible**, cree un directorio llamado `ansible-files` en el directorio principal y cambie los directorios en él: - -```bash -[student@ansible ~]$ mkdir ansible-files -[student@ansible ~]$ cd ansible-files/ -``` - -Agregue un archivo llamado `apache.yml` con el siguiente contenido. Como se ha explicado en los ejercicios anteriores, utilice `vi`/`vim` o, si es nuevo en los editores de la línea de comandos, consulte [editor intro](../0.0-support-docs/editor_intro.md) de nuevo. - -```yaml ---- -- name: Apache server installed - hosts: node1 - become: yes -``` - -Esto muestra uno de los puntos fuertes de Ansible: la sintaxis del playbook es fácil de leer y entender. En este Playbook: - - - Se da un nombre para el play a través de `name:`. - - - El host donde se ejecuta el playbook se define a través de `hosts:`. - - - Habilitamos la escalada de privilegios de usuario con `become:`. - -> **Consejo** -> -> Obviamente, necesita usar la escalada de privilegios para instalar un paquete o ejecutar cualquier otra tarea que requiera permisos de usuario root. Esto se hace en el Playbook con `become: yes`. - -Ahora que hemos definido el play, vamos a añadir una tarea para hacer algo. Agregaremos una tarea en la que yum se asegurará de que el paquete Apache esté instalado en la última versión. Modifique el archivo para que tenga el aspecto como el siguiente: - - -```yaml ---- -- name: Apache server installed - hosts: node1 - become: yes - tasks: - - name: latest Apache version installed - yum: - name: httpd - state: latest -``` -> **Consejo** -> -> Dado que los playbooks están escritos en YAML, la alineación de las líneas y palabras clave es crucial. Asegúrese de alinear verticalmente el *t* en `task` con el *b* en `become`. Una vez que esté más familiarizado con Ansible, asegúrese de tomarse un tiempo y estudiar un poco la [Sintaxis YAML](http://docs.ansible.com/ansible/YAMLSyntax.html). - -En las líneas añadidas: - - - Comenzamos la parte de tareas con la palabra clave `tasks:`. - - - Se nombra una tarea y se hace referencia al módulo de la tarea. Aquí utiliza el módulo `yum`. - - - Se añaden parámetros para el módulo: - - - `name:` para identificar el nombre del paquete - - `state:` para definir el estado deseado del paquete - -> **Consejo** -> -> Los parámetros del módulo son individuales para cada módulo. En caso de duda, búsquelos de nuevo con `ansible-doc`. - -Guarde su playbook y salga de su editor. - -## Paso 3 - Ejecución del Playbook - -Los Playbooks ansibles se ejecutan mediante el comando `ansible-playbook` en el nodo de control. Antes de ejecutar un nuevo Playbook, es una buena idea comprobar si hay errores de sintaxis: +### Paso 2 - Creando Tu Playbook +Antes de crear tu primer playbook, asegúrate de estar en el directorio correcto cambiando a `~/lab_inventory`: ```bash -[student@ansible ansible-files]$ ansible-playbook --syntax-check apache.yml +cd ~/lab_inventory ``` -Ahora deberías estar listo para ejecutar tu playbook: - -``` -[student@ansible ansible-files]$ ansible-playbook apache.yml -``` - -La salida no debe informar de ningún error, sino proporcionar una visión general de las tareas ejecutadas y un resumen de reproducción que resume lo que se ha hecho. También hay una tarea llamada "Gathering Facts/Recopilar hechos" enumerada allí: esta es una tarea integrada que se ejecuta automáticamente al principio de cada jugada. Recopila información sobre los nodos administrados. Los ejercicios posteriores cubrirán esto con más detalle. - -``` -[student@ansible ansible-files]$ ssh node1 -Last login: Wed May 15 14:03:45 2019 from 44.55.66.77 -Managed by Ansible -``` - -Utilice el comando `rpm -qi httpd` para verificar que httpd está instalado: - -``` -[student@node1 ~]$ rpm -qi httpd -Name : httpd -Version : 2.4.6 -[...] -``` - -¡Cierre la sesión de `node1` con el comando `exit` para que vuelva al host de control y verifique el paquete instalado con un comando Ad hoc de Ansible\! - -```bash -[student@ansible ansible-files]$ ansible node1 -m command -a 'rpm -qi httpd' -``` - -Ejecute el Playbook una segunda vez y compare la salida: la salida ha cambiado de "changed" a "ok", y el color cambió de amarillo a verde. También el "PLAY RECAP" es diferente ahora. Esto hace que sea fácil detectar lo que Ansible realmente hizo. - -## Paso 4 - Extiende tu Playbook: Iniciar & Habilitar Apache - -La siguiente parte del Ansible Playbook se asegura de que la aplicación Apache esté habilitada e iniciada en `node1`. - -En el host de control, como usuario student, edite el archivo `~/ansible-files/apache.yml` para agregar una segunda tarea mediante el módulo `service`. El Playbook ahora debería tener este aspecto: +Ahora crea un playbook llamado `system_setup.yml` para realizar la configuración básica del sistema: +- Actualizar todos los paquetes relacionados con la seguridad. +- Crear un nuevo usuario llamado ‘myuser’. +La estructura básica se ve de la siguiente manera: ```yaml --- -- name: Apache server installed +- name: Basic System Setup hosts: node1 - become: yes + become: true tasks: - - name: latest Apache version installed - yum: - name: httpd - state: latest - - name: Apache enabled and running - service: - name: httpd - enabled: true - state: started -``` - -Una vez más: lo que hacen estas líneas es fácil de entender: + - name: Update all security-related packages + ansible.builtin.dnf: + name: '*' + state: latest + security: true - - se crea una segunda tarea y se nombra - - - se especifica un módulo (`service`) - - - se suministran los parámetros del módulo - -Por lo tanto, con la segunda tarea nos aseguramos de que el servidor Apache se está ejecutando en la máquina de destino. Ejecuta tu Playbook extendido: - -```bash -[student@ansible ansible-files]$ ansible-playbook apache.yml + - name: Create a new user + ansible.builtin.user: + name: myuser + state: present + create_home: true ``` -Tenga en cuenta la salida ahora: Algunas tareas se muestran como "ok" en verde y una se muestra como "changed" en amarillo. - - Utilice un comando Ansible ad hoc de nuevo para asegurarse de que Apache se ha habilitado e iniciado, por ejemplo, con: `systemctl status httpd`. - - - Ejecutar el Playbook una segunda vez para acostumbrarse a los cambios en la salida del comando. -## Paso 5 - Extiende tu Playbook: Crear un web.html +> NOTA: Actualizar los paquetes puede tardar unos minutos antes de completar el playbook de Ansible. -Compruebe que las tareas se han ejecutado correctamente y Apache está aceptando conexiones: realice una solicitud HTTP utilizando el módulo `uri` de Ansible en un comando ad hoc desde el nodo de control. Asegúrese de reemplazar el valor de la **\** con la dirección IP del nodo del inventario. +* Acerca del módulo `dnf`: Este módulo se utiliza para la gestión de paquetes con DNF (YUM mejorado) en RHEL y otros sistemas basados en Fedora. -> **Advertencia** -> ->**¡Espere una gran cantidad de líneas rojas y un estado 403\!** +* Acerca del módulo `user`: Este módulo se utiliza para gestionar cuentas de usuario. -```bash -[student@ansible ansible-files]$ ansible localhost -m uri -a "url=http://" -``` +### Paso 3 - Ejecutando el Playbook -Hay un montón de líneas rojas y un error: Mientras no haya al menos un archivo `web.html` para ser servido por Apache, lanzará un feo estado "HTTP Error 403: Forbidden" y Ansible informará de un error. - -Entonces, ¿por qué no usar Ansible para implementar un simple archivo `web.html`? En el host de control ansible, como usuario `student`, cree el directorio `files` para contener los recursos de archivo en `~/ansible-files/`': +Ejecuta tu playbook utilizando el comando `ansible-navigator`: ```bash -[student@ansible ansible-files]$ mkdir files +[student@ansible-1 lab_inventory]$ ansible-navigator run system_setup.yml -m stdout ``` -A continuación, cree el archivo `~/ansible-files/files/web.html` en el nodo de control: +Revisa la salida para asegurarte de que cada tarea se haya completado con éxito. -```html - -

Apache is running fine

- -``` - -Ya ha utilizado el módulo `copy` de Ansible para escribir el texto proporcionado en la línea de comandos en un archivo. Ahora usarás el módulo de tu Playbook para copiar un archivo: - -En el nodo de control, mientras el usuario del student edita el archivo `/ansible-files/apache.yml` y agrega una nueva tarea utilizando el módulo `copy`. Ahora debería tener este aspecto: +### Paso 4 - Verificando el Playbook +Ahora, vamos a crear un segundo playbook para verificaciones posteriores a la configuración, llamado `system_checks.yml`: ```yaml --- -- name: Apache server installed +- name: System Configuration Checks hosts: node1 - become: yes + become: true tasks: - - name: latest Apache version installed - yum: - name: httpd - state: latest - - name: Apache enabled and running - service: - name: httpd - enabled: true - state: started - - name: copy web.html - copy: - src: web.html - dest: /var/www/html/index.html -``` + - name: Check user existence + ansible.builtin.command: + cmd: id myuser + register: user_check -Te estás acostumbrando a la sintaxis de Playbook, así que ¿qué pasa? La nueva tarea utiliza el módulo `copy` y define las opciones de origen y destino para la operación de copia como parámetros. - -Ejecuta tu Playbook extendido: - -```bash -[student@ansible ansible-files]$ ansible-playbook apache.yml + - name: Report user status + ansible.builtin.debug: + msg: "User 'myuser' exists." + when: user_check.rc == 0 ``` - - Echar un buen vistazo a la salida - - - Ejecute el comando ad hoc usando el módulo "uri" de más arriba de nuevo para probar Apache: El comando ahora debe devolver una línea verde amigable "status: 200", entre otra información. - -## Paso 6 - Práctica: Aplicar a múltiples hosts - -Esto fue agradable, pero el verdadero poder de Ansible es aplicar el mismo conjunto de tareas de forma fiable a muchos hosts. - - - Entonces, ¿qué pasa con cambiar el Playbook apache.yml para que se ejecute en `node1` **y** `node2` **y** `node3`? - -Como puede recordar, el inventario enumera todos los nodos como miembros del grupo `web`: - -```ini -[web] -node1 ansible_host=11.22.33.44 -node2 ansible_host=22.33.44.55 -node3 ansible_host=33.44.55.66 -``` - -> **Consejo** -> -> Las direcciones IP que se muestran aquí son solo ejemplos, sus nodos tendrán diferentes direcciones IP. - -Cambie el Playbook para que apunte al grupo "web": - -```yaml ---- -- name: Apache server installed - hosts: web - become: yes - tasks: - - name: latest Apache version installed - yum: - name: httpd - state: latest - - name: Apache enabled and running - service: - name: httpd - enabled: true - state: started - - name: copy web.html - copy: - src: web.html - dest: /var/www/html/index.html -``` - -Ahora ejecute el Playbook: +Ejecuta el playbook de verificaciones: ```bash -[student@ansible ansible-files]$ ansible-playbook apache.yml +[student@ansible-1 lab_inventory]$ ansible-navigator run system_checks.yml -m stdout ``` -Por último, compruebe si Apache se está ejecutando en ambos servidores. Identifique primero las direcciones IP de los nodos de su inventario y, a continuación, utilícelas cada una en el comando ad hoc con el módulo uri como ya hicimos con el `node1` anterior. Toda la salida debe ser verde. - -> **Consejo** -> -> Una forma alternativa de verificar que Apache se está ejecutando en ambos servidores es utilizar el comando `ansible node2,node3 -m uri -a "url=http://localhost/"`. - +Revisa la salida para asegurarte de que la creación del usuario haya sido exitosa. ---- **Navegación** diff --git a/exercises/ansible_rhel/1.3-playbook/README.fr.md b/exercises/ansible_rhel/1.3-playbook/README.fr.md index 5ad0efc90..29c64a859 100644 --- a/exercises/ansible_rhel/1.3-playbook/README.fr.md +++ b/exercises/ansible_rhel/1.3-playbook/README.fr.md @@ -1,473 +1,114 @@ -# Exercice - Rédaction de votre premier Playbook +# Exercice de l'Atelier - Rédaction de Votre Premier Playbook -**Lisez ceci dans d'autres langues:**: -
![uk](../../../images/uk.png) [English](README.md), ![japan](../../../images/japan.png)[日本語](README.ja.md), ![brazil](../../../images/brazil.png) [Portugues do Brasil](README.pt-br.md), ![france](../../../images/fr.png) [Français](README.fr.md),![Español](../../../images/col.png) [Español](README.es.md). +**Lire ceci dans d'autres langues** : +
![uk](../../../images/uk.png) [Anglais](README.md), ![japan](../../../images/japan.png) [日本語](README.ja.md), ![brazil](../../../images/brazil.png) [Portugais du Brésil](README.pt-br.md), ![france](../../../images/fr.png) [Français](README.fr.md), ![Español](../../../images/col.png) [Espagnol](README.es.md). -## Table des matières +## Table des Matières -- [Exercice - Rédaction de votre premier Playbook](#exercice---rédaction-de-votre-premier-playbook) - - [Table des matières](#table-des-matières) +- [Exercice de l'Atelier - Rédaction de Votre Premier Playbook](#exercice-de-latelier---rédaction-de-votre-premier-playbook) - [Objectif](#objectif) - [Guide](#guide) - - [Etape 1 - Principes de base d'un Playbook](#Etape-1---Principes-de-base-d'un-Playbook) - - [Etape 2 - Création d'une structure pour votre Playbook](#Etape-2---Création-d-une-structure-pour-votre-Playbook) - - [Etape 3 - Exécution du Playbook](#Etape-3---Exécution-du-Playbook) - - [Etape 4 - Ajout de tache: Démarrage et activation de Apache](#Etape-4---Ajout-de-tache-Démarrage-et-activation-de-Apache) - - [Etape 5 - Ajout de tache: Création de fichier html](#Etape-5---Ajout-de-tache-Création-de-fichier-html) - - [Etape 6 - Application à plusieurs hôtes](#Etape-6---Application-à-plusieurs-hôtes) + - [Étape 1 - Les Bases du Playbook](#étape-1---les-bases-du-playbook) + - [Étape 2 - Création de Votre Playbook](#étape-2---création-de-votre-playbook) + - [Étape 3 - Exécution du Playbook](#étape-3---exécution-du-playbook) + - [Étape 4 - Vérification du Playbook](#étape-4---vérification-du-playbook) -## Objectif -Cet exercice couvre l'utilisation d'Ansible pour créer deux serveurs Web Apache sur Red Hat Enterprise Linux. Cet exercice couvre les principes de base d'Ansible suivants: +## Objectif -* Comprendre les paramètres du module Ansible -* Comprendre et utiliser les modules suivants - * [module dnf](https://docs.ansible.com/ansible/latest/modules/dnf_module.html) - * [module service](https://docs.ansible.com/ansible/latest/modules/service_module.html) - * [module copy](https://docs.ansible.com/ansible/latest/modules/copy_module.html) -* Comprendre l'[idempotence](https://en.wikipedia.org/wiki/Idempotence) et comment les modules Ansible peuvent être idempotents +Dans cet exercice, vous utiliserez Ansible pour effectuer des tâches de configuration système de base sur un serveur Red Hat Enterprise Linux. Vous vous familiariserez avec les modules fondamentaux d'Ansible comme `dnf` et `user`, et apprendrez à créer et exécuter des playbooks. ## Guide -Les Playbooks sont des fichiers qui décrivent les configurations souhaitées ou les étapes pour les implémenter sur les hôtes gérés. Les Playbooks peuvent transformer des tâches longues et complexes d'un point de vue administratif en routines facilement reproductibles avec des résultats prévisibles et réussis. - -Un playbook peut avoir plusieurs "plays" et un "play" peut avoir une ou plusieurs tâches. Dans une tâche, un module est appelé, comme les modules du chapitre précédent. Le but d'un play est de cartographier un groupe d'hôtes. Le but d'une tâche est d'implémenter des modules sur ces hôtes. - -> **Astuce** -> -> Voici une belle analogie: lorsque les modules Ansible sont les outils de votre atelier, l'inventaire est le matériel et les Playbooks les instructions. - -### Etape 1 - Principes de base d'un Playbook - -Les playbooks sont des fichiers texte écrits au format YAML et nécessitent donc: - - * de commencer par trois tirets (`---`) - * une indentation appropriée en utilisant des espaces et **surtout pas** de tabulation \! - -Il existe quelques concepts importants: - - * **hosts**: les hôtes sur lesquels seront effectués les tâches - * **tasks**: les opérations à effectuer en appelant les modules Ansible et en leur passant les options nécessaires. - * **become**: élévation de privilèges dans les playbooks, identique à l'utilisation de `-b` dans la commande Ad-hoc. - -> **Avertissement** -> -> L'ordre des contenus dans un Playbook est important, car Ansible exécute les play et les tâches dans l'ordre où ils sont présentés. - -Un Playbook doit être **idempotent**, donc si un Playbook est exécuté une fois pour mettre les hôtes dans l'état correct, il devrait être sûr de l'exécuter une deuxième fois et il ne devrait plus apporter de modifications aux hôtes. - -> **Astuce** -> -> La plupart des modules Ansible sont idempotents, il est donc relativement facile de s'assurer que cela est vrai. - -### Etape 2 - Création d'une structure pour votre Playbook - -Assez de théorie, il est temps de créer votre premier Playbook Ansible. Dans ce laboratoire, vous créez un playbook pour configurer un serveur Web Apache en trois étapes: - 1. Installez le package httpd - 2. Activer/démarrer le service httpd - 3. Copiez un fichier web.html sur chaque hôte Web - -Ce Playbook s'assure que le paquet contenant le serveur Web Apache est installé sur `node1`. - -Il existe un guide des [bonnes pratiques](https://docs.ansible.com/ansible/latest/user_guide/playbooks_best_practices.html) sur les structures de répertoires à utiliser pour les Playbooks. Nous vous encourageons fortement à lire et à comprendre ces pratiques lorsque vous développez vos compétences de maitre ninja Ansible. Cela dit, notre Playbook d'aujourd'hui est très basique et créer une structure complexe ne fera que rendre les choses confuses. - -Au lieu de cela, nous allons créer une structure de répertoire très simple pour notre playbook et y ajouter seulement quelques fichiers. - -Sur votre hôte de contrôle **ansible**, créez un répertoire appelé `ansible-files` dans votre répertoire personnel, et rentrez dedans. - -```bash -[student@ansible-1 ~]$ mkdir ansible-files -[student@ansible-1 ~]$ cd ansible-files/ -``` - -Ajoutez un fichier appelé `apache.yml` avec le contenu suivant. Comme expliqué dans les exercices précédents, utilisez à nouveau `vi`/`vim` ou, si vous débutez avec les éditeurs sur la ligne de commande, consultez à nouveau [introduction à l'éditeur](../0.0-support-docs/editor_intro.md). - -```yaml ---- -- name: Apache server installed - hosts: node1 - become: yes -``` - -Cela montre l'une des forces d'Ansible: la syntaxe Playbook est facile à lire et à comprendre. Dans ce Playbook: -* Un nom est donné pour le play via `name:`. -* L'hôte sur lequel sera exécuter le playbook est défini via `hosts:`. -* Nous activons l'escalade de privilèges utilisateur avec `become:`. - -> **Astuce** -> -> Vous devez évidemment utiliser une élévation de privilèges pour installer un package ou exécuter toute autre tâche nécessitant des autorisations root. Cela se fait dans le Playbook par `become: yes`. - -Maintenant que nous avons défini le play, ajoutons une tâche pour faire quelque chose. Nous ajouterons une tâche dans laquelle dnf s'assurera que le package Apache est installé dans la dernière version. Modifiez le fichier pour qu'il ressemble à la liste suivante: - -```yaml ---- -- name: Apache server installed - hosts: node1 - become: yes - tasks: - - - name: Install Apache - ansible.builtin.dnf: - name: httpd -``` - -> **Astuce** -> -> Les playbooks étant écrits en YAML, l'alignement des lignes et des mots-clés est crucial. Assurez-vous d'aligner verticalement le *t* dans `tâche` avec le *b* dans `become`. Une fois que vous vous serez familiarisé avec Ansible, assurez-vous de prendre un peu de temps et d'étudier un peu la [Syntaxe YAML](http://docs.ansible.com/ansible/YAMLSyntax.html). - -Dans les lignes ajoutées: -* Nous avons commencé la partie tâches avec le mot clé `tasks:`. -* Une tâche est nommée et le module de la tâche est référencé. Ici, il utilise le module `dnf`. -* Des paramètres pour le module sont ajoutés: - * `name:` pour identifier le nom du paquet - * `state:` pour définir l'état souhaité du paquet - -> **Astuce** -> -> Les paramètres du module sont individuels pour chaque module. En cas de doute, recherchez-les à nouveau avec la documentation dans `ansible-navigator`. - -Enregistrez votre playbook et quittez votre éditeur. - -### Etape 3 - Exécution du Playbook - -Depuis Ansible Automation Platform 2, un certain nombre de nouveaux composants sont introduits dans le cadre de l'expérience développeur. Les Environnements d'Execution ont été introduits pour fournir un environnement prévisible lors de l'exécution de l'automatisation. Toutes les dépendances en terme de collections sont contenues dans l'EE pour garantir que l'automatisation créée dans l'environnement de développement est exécutée à l'identique dans les environnements de production. - -Que trouve-t-on dans un Environnement d'Execution? -* RHEL UBI 8 -* Ansible 2.9 ou Ansible Core 2.11 -* Python 3.8 -* Des collections -* Des dépendances Python ou binaires pour les collections - -Pourquoi utiliser des Environnements d'Execution ? - -Ils fournissent un moyen standardisé de définir, construire et distribuer les environnements dans lesquels l'automatisation tourne. En résumé, les EE sont des images de conteneurs qui permettent une administration facilitée de Ansible par l'administrateur de la plateforme. - -En considérant le déplacement vers l'exécution conteneurisée de l'automatisation, le processus et l'outillage de développement de l'automatisation qui existait avant Ansible Automation Platform 2 ont du être réminaginés. En résumé, `ansible-navigator` remplace `ansible-playbook` et les autres commandes utilitaires en ligne de commande `ansible-*`. - -Avec ce changement, les Playbooks Ansible sont exécutés à l'aide de la commande `ansible-navigator` sur le noeud de contrôle. - -Les prérequis et bonnes pratiques pour l'utilisation de `ansible-navigator` ont été traités pour vous dans ce lab. - -Cela inclut: -* L'installation du package `ansible-navigator` -* La création de paramètres par défaut dans `/home/student/.ansible-navigator.yml` pour tous vos projets (optionnel) -* Tous les logs des EE sont stockés dans `/home/student/.ansible-navigator/logs/ansible-navigator.log` -* Les artéfacts de Playbooks sont sauvegardés dans `/tmp/artifact.json` - -Pour plus d'informations sur les [paramètres de Ansible navigator](https://github.com/ansible/ansible-navigator/blob/main/docs/settings.rst) - -> **Astuce** -> -> Le sparamètres de `ansible-navigator` peuvent être modifiés pour votre environnement spécifique. Les paramètres actuels utilisent un `ansible-navigator.yml` par défaut pour tous les projets, mais un `ansible-navigator.yml` spécifique peut être créé pour chaque projet, et c'est la pratique recommandée. - -Pour lancer votre Playbook, utilisez la commande `ansible-navigator run ` comme suit: - -```bash -[student@ansible-1 ansible-files]$ ansible-navigator run apache.yml -``` - -> **Astuce** -> -> Le fichier `ansible-navigator.yml` existant fournit l'emplacement de votre fichier d'inventaire. Si ce n'était pas renseigné dans votre fichier `ansible-navigator.yml`, alors la commande pour lancer le Playboko serait: `ansible-navigator run apache.yml -i /home/student/lab_inventory/hosts` - -Pendant l'exécution du playbook, vous aurez une interface en mode texte (TUI) qui affiche le nom du Play, et d'autres informations sur le playbook en cours. - -```bash - PLAY NAME OK CHANGED UNREACHABLE FAILED SKIPPED IGNORED IN PROGRESS TASK COUNT PROGRESS -0│Apache server installed 2 1 0 0 0 0 0 2 COMPLETE -``` - -Si vous remarquez, avant le nom du Play `Apache server installed`, vous verrez un `0`. EN pressant la touche `0` sur votre clavier, vous obtiendrez une nouvelle fenêtre qui affiche les différentes tâches qui ont tourné pour ce Playbook. Dnas cet exemple, ces tâches incluent "Gathering Facts" et "Install Apache". La tâche "Gathering Facts" est intégrée et tourne automatiquement au début de chaque Play. Elle collecte des informations sur les noeuds gérés. Les exercices ultérieurs couvriront ce concept plus en détail. La tâche "Install Apache" est la tâche créée dans le fichier `apache.yml` qui installe `httpd`. - -Le résultat devrait ressembler à ceci: - -```bash - RESULT HOST NUMBER CHANGED TASK TASK ACTION DURATION -0│OK node1 0 False Gathering Facts gather_facts 1s -1│OK node1 1 True Install Apache dnf 4s -``` - -En regardant de plus près, vous rmarquerez que chaque tâche est associée à un numéro. La tâche 1, "Install Apache", marque un changemenet et a utilisé le module `dnf`. Dans ce cas le changement est l'installation de Aache (paquet `httpd`) sur l'hôte `node1`. - -En pressant `0` ou `1` sur votre clavier, vous pouvez voir plus de détails sur les tâches exécutées. Si vous souhaitez un affichage plus traditionnel, tapez `:st` dans l'interface texte. - -Une fois terminé, vous pouvez quitter la TUI avec la touche Echap de votre clavier. - -> **Astuce** -> -> La touche Echap vous ramène simplement à l'écran précédent. Une fois sur l'écran principal, appuyer sur Echap vous ramène au terminal. - -Une fois le playbook complété, connectez vous à `node1` via SSH pour vous assurer que Apache a été installé: - -```bash -[student@ansible-1 ansible-files]$ ssh node1 -Last login: Wed May 15 14:03:45 2019 from 44.55.66.77 -Managed by Ansible -``` - -Utilisez la commande `rpm -qi httpd` pour vérifier que httpd est installé: - -```bash -[ec2-user@node1 ~]$ rpm -qi httpd -Name : httpd -Version : 2.4.37 -[...] -``` - -Déconnectez-vous de `node1` avec la commande `exit` pour revenir sur l'hôte de contrôle et vérifier le paquet installé avec un Playbook Ansible intitulé `package.yml` +Les playbooks dans Ansible sont essentiellement des scripts écrits au format YAML. Ils sont utilisés pour définir les tâches et configurations qu'Ansible appliquera à vos serveurs. -{% raw %} -```yaml ---- -- name: Check packages - hosts: node1 - become: true - vars: - package: "httpd" - - tasks: - - name: Gather the package facts - ansible.builtin.package_facts: - manager: auto +### Étape 1 - Les Bases du Playbook +Tout d'abord, créez un fichier texte au format YAML pour votre playbook. Souvenez-vous : +- Commencez par trois tirets (`---`). +- Utilisez des espaces, pas des tabulations, pour l'indentation. - - name: Check whether a {{ package }} is installed - ansible.builtin.debug: - msg: "{{ package }} {{ ansible_facts.packages[ package ][0].version }} is installed!" - when: "package in ansible_facts.packages" +Concepts Clés : +- `hosts` : Spécifie les serveurs ou appareils cibles sur lesquels votre playbook s'exécutera. +- `tasks` : Les actions qu'Ansible effectuera. +- `become` : Permet l'escalade de privilèges (exécution de tâches avec des privilèges élevés). -``` -{% endraw %} +> NOTE : Un playbook Ansible est conçu pour être idempotent, ce qui signifie que si vous l'exécutez plusieurs fois sur les mêmes hôtes, il assure l'état souhaité sans effectuer de changements redondants. +### Étape 2 - Création de Votre Playbook +Avant de créer votre premier playbook, assurez-vous d'être dans le bon répertoire en changeant pour `~/lab_inventory` : ```bash -[student@ansible-1 ~]$ ansible-navigator run package.yml -m stdout -``` - -```bash - -PLAY [Check packages] ********************************************************** - -TASK [Gathering Facts] ********************************************************* -ok: [ansible] - -TASK [Gather the package facts] ************************************************ -ok: [ansible] - -TASK [Check whether a httpd is installed] ************************************* -ok: [ansible] => { - "msg": "httpd 2.4.37 is installed!" -} - -PLAY RECAP ********************************************************************* -ansible : ok=3 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 +cd ~/lab_inventory ``` -Lancez le Playbook `ansible-navigator run apache.yml` une seconde fois, et comparez le résultat. Le compteur "CHANGED" montre à présent `0` au lieu de `1` et la couleur est passée de jaune à vert. Cela rend plus facile le repérage des changements lors des lancements de Playbooks Ansible. - -### Etape 4 - Ajout de tache: Démarrage et activation de Apache - -La partie suivante du Playbook Ansible s'assure que l'application Apache est activée et démarrée sur `node1`. +Créez maintenant un playbook nommé `system_setup.yml` pour effectuer la configuration système de base : +- Mettre à jour tous les paquets liés à la sécurité. +- Créer un nouvel utilisateur nommé ‘myuser’. -Sur l'hôte de contrôle, en tant qu'utilisateur student, modifiez le fichier `~/ansible-files/apache.yml` pour ajouter une deuxième tâche à l'aide du module `service`. Le Playbook devrait maintenant ressembler à ceci: +La structure de base se présente comme suit : ```yaml --- -- name: Apache server installed +- name: Basic System Setup hosts: node1 become: true tasks: - - - name: Install Apache + - name: Update all security-related packages ansible.builtin.dnf: - name: httpd - - - name: Apache enabled and running - ansible.builtin.service: - name: httpd - enabled: true - state: started -``` - -Quels changements avons-nous faits ? -* une deuxième tâche est créée et nommée -* un module est spécifié (`service`) -* Le module `service` prend le nom du service (`httpd`), renseigne son activation (`enabled`), et son état actuel (`started`) - -Ainsi, avec la seconde tâche on s'assure que le serveur Apache est bien en route sur la machine cible. Lancez votre Playbook étendu: - -```bash -[student@ansible-1 ~]$ ansible-navigator run apache.yml -``` - -Notez dans le résultat, on voir que le Play avait `1` élément "CHANGED" affiché en jaune et si on presse `0` pour entrer dans la sortie du Play, on peut voir que la tâche 2, "Apache enabled and running", éait la tâche qui incorporait les derniers changements grâce à la valeur de "CHANGED" passée à True et colorée en jaune. - -* Lancez le Playbook une seconde fois en utilisant `ansible-navigator` pour vous habituer aux changements dans le résultat. - -* Utilisez un Playbook Ansible institulé `service_state.yml` pour vous assurer que le service Apache (httpd) est lancé sur `node1`, c'est-à-dire avec: `systemctl status httpd`. - -{% raw %} -```yaml ---- -- name: Check Status - hosts: node1 - become: true - vars: - package: "httpd" - - tasks: - - name: Check status of {{ package }} service - ansible.builtin.service_facts: - register: service_state + name: '*' + state: latest + security: true - - ansible.builtin.debug: - var: service_state.ansible_facts.services["{{ package }}.service"].state + - name: Create a new user + ansible.builtin.user: + name: myuser + state: present + create_home: true ``` -```bash -{% endraw %} - -[student@ansible-1 ~]$ ansible-navigator run service_state.yml -``` - -### Etape 5 - Ajout de tache: Création de fichier html - -Vérifiez que les tâches ont été exécutées correctement et qu'Apache accepte les connexions: effectuez une requête HTTP à l'aide du module `uri` d'Ansible dans un Playbook intitulé `check_httpd.yml` depuis le noeud de contrôle vers `node1`. +> NOTE : La mise à jour des paquets peut prendre quelques minutes avant la fin de l'exécution du playbook Ansible. -{% raw %} -```yaml ---- -- name: Check URL - hosts: control - vars: - node: "node1" - - tasks: - - name: Check that you can connect (GET) to a page and it returns a status 200 - ansible.builtin.uri: - url: "http://{{ node }}" - -``` -{% endraw %} +* À propos du module `dnf` : Ce module est utilisé pour la gestion des paquets avec DNF (YUM Dandifié) sur RHEL et d'autres systèmes basés sur Fedora. -> **Avertissement** -> -> **Attendez-vous à beaucoup de lignes rouges et un statut 403 \!** +* À propos du module `user` : Ce module est utilisé pour gérer les comptes d'utilisateurs. -```bash -[student@ansible-1 ~]$ ansible-navigator run check_httpd.yml -m stdout -``` +### Étape 3 - Exécution du Playbook -Il y a beaucoup de lignes rouges et une erreur: tant qu'il n'y a pas le fichier `web.html` servi par Apache, il affichera un vilain statut ""HTTP Error 403: Forbidden"" et Ansible signalera une erreur. - -Alors pourquoi ne pas utiliser Ansible pour déployer un simple fichier `web.html`? Sur l'hôte de contrôle ansible, en tant qu'utilisateur `student`, créez le répertoire `files` pour contenir les fichiers ressources dans `~/ ansible-files/`: +Exécutez votre playbook en utilisant la commande `ansible-navigator` : ```bash -[student@ansible-1 ansible-files]$ mkdir files -``` - -Créez ensuite le fichier `~/ansible-files/files/web.html` sur le nœud de contrôle: - -```html - -

Apache is running fine

- +[student@ansible-1 lab_inventory]$ ansible-navigator run system_setup.yml -m stdout ``` -Vous avez déjà utilisé le module `copy` d'Ansible pour écrire le texte fourni sur la ligne de commande dans un fichier. Vous allez maintenant utiliser le module de votre Playbook pour copier un fichier. +Revoyez la sortie pour vous assurer que chaque tâche est terminée avec succès. -Sur le nœud de contrôle, en tant qu'utilisateur `student`, modifiez le fichier `~/ansible-files/apache.yml` et ajoutez une nouvelle tâche en utilisant le module `copy`. Il devrait maintenant ressembler à ceci: +### Étape 4 - Vérification du Playbook +Maintenant, créons un second playbook pour les vérifications post-configuration, nommé `system_checks.yml` : ```yaml --- -- name: Apache server installed +- name: System Configuration Checks hosts: node1 become: true tasks: + - name: Check user existence + ansible.builtin.command: + cmd: id myuser + register: user_check - - name: Install Apache - ansible.builtin.dnf: - name: httpd - - - name: Apache enabled and running - ansible.builtin.service: - name: httpd - enabled: true - state: started - - - name: Copy index.html - ansible.builtin.copy: - src: web.html - dest: /var/www/html/index.html - mode: '644' -``` - -Que fait cette nouvelle tâche de copie ? La nouvelle tâche utilise le module `copy` et définit la source et la destination pour l'opération de copie en tant que paramètres. - -Exécutez votre Playbook étendu: - -```bash -[student@ansible-1 ansible-files]$ ansible-navigator run apache.yml -m stdout -``` - -* Regardez bien la sortie, notez les changements "CHANGED" et les tâches associées à ces changements. - -* Exécutez à nouveau le Playbook `check_httpd.yml` avec le module `uri` employé ci-dessus pour tester Apache. La commande devrait maintenant renvoyer une ligne verte "status: 200" entre autres informations. - -### Etape 6 - Application à plusieurs hôtes - -Bien que les manipulations précédentes montrent la simplicité d'appliquer des changements sur un hôte particulier, qu'en est-il de propager des changements à de nombreux hôtes ? C'est maintenant qu'on constate le vrai pouvoir de Ansible, alors qu'il applique les mêmes jeux de tâches de manière fiable sur de nombreux hôtes. - -* Alors, qu'en est-il de changer le Playbook apache.yml pour qu'il fonctionne sur `node1` **et** `node2` **et** `node3`? - -Comme vous vous en souvenez peut-être, l'inventaire répertorie tous les nœuds en tant que membres du groupe `web`: - -```ini -[web] -node1 ansible_host=11.22.33.44 -node2 ansible_host=22.33.44.55 -node3 ansible_host=33.44.55.66 -``` - -> **Astuce** -> -> Les adresses IP présentées ici ne sont que des exemples, vos nœuds auront des adresses IP différentes. - -Modifiez le paramètre `hosts` du Playbook pour pointer vers le groupe `web` au lieu de `node1`: - -```yaml ---- -- name: Apache server installed - hosts: web - become: true - tasks: - - - name: Install Apache - ansible.builtin.dnf: - name: httpd - - - name: Apache enabled and running - ansible.builtin.service: - name: httpd - enabled: true - state: started - - - name: Copy index.html - ansible.builtin.copy: - src: web.html - dest: /var/www/html/index.html - mode: '644' - + - name: Report user status + ansible.builtin.debug: + msg: "L'utilisateur 'myuser' existe." + when: user_check.rc == 0 ``` -Maintenant, lancez le Playbook: +Exécutez le playbook de vérifications : ```bash -[student@ansible-1 ansible-files]$ ansible-navigator run apache.yml -m stdout +[student@ansible-1 lab_inventory]$ ansible-navigator run system_checks.yml -m stdout ``` -Enfin, vérifiez si Apache fonctionne maintenant sur tous les serveurs web (node1, node2, node3). Toute sortie doit être verte. +Revoyez la sortie pour vous assurer que la création de l'utilisateur a été réussie. --- **Navigation** diff --git a/exercises/ansible_rhel/1.3-playbook/README.ja.md b/exercises/ansible_rhel/1.3-playbook/README.ja.md index 6516cbb5f..6411fae30 100644 --- a/exercises/ansible_rhel/1.3-playbook/README.ja.md +++ b/exercises/ansible_rhel/1.3-playbook/README.ja.md @@ -1,483 +1,124 @@ -# ワークショップ演習 - はじめての Playbook の作成 +# ワークショップの演習 - 最初のプレイブックを書く -**他の言語でもお読みいただけます**: -
![uk](../../../images/uk.png) [English](README.md)、![japan](../../../images/japan.png)[日本語](README.ja.md)、![brazil](../../../images/brazil.png) [Portugues do Brasil](README.pt-br.md)、![france](../../../images/fr.png) [Française](README.fr.md)、![Español](../../../images/col.png) [Español](README.es.md) +**他の言語で読む**: +
![uk](../../../images/uk.png) [英語](README.md), ![japan](../../../images/japan.png) [日本語](README.ja.md), ![brazil](../../../images/brazil.png) [ブラジルのポルトガル語](README.pt-br.md), ![france](../../../images/fr.png) [フランス語](README.fr.md), ![Español](../../../images/col.png) [スペイン語](README.es.md). ## 目次 -* [目的](#目的) -* [ガイド](#ガイド) - * [ステップ 1 - Playbook の基本](#ステップ-1---playbook-の基本) - * [ステップ 2 - Playbook 用のディレクトリー構造とファイルの作成](#ステップ-2---playbook-用のディレクトリー構造とファイルの作成) - * [ステップ 3 - Playbook の実行](#ステップ-3---playbook-の実行) - * [ステップ 4 - Playbook の拡張: Apache の起動と有効化](#ステップ-4---playbook-の拡張-apache-の起動と有効化) - * [ステップ 5 - Playbook の拡張: web.html の作成](#ステップ-5---playbook-の拡張-webhtml-の作成) - * [ステップ 6 - 練習: 複数ホストへの適用](#ステップ-6---練習-複数ホストへの適用) +- [ワークショップの演習 - 最初のプレイブックを書く](#ワークショップの演習---最初のプレイブックを書く) + - [目的](#目的) + - [ガイド](#ガイド) + - [ステップ1 - プレイブックの基本](#ステップ1---プレイブックの基本) + - [ステップ2 - プレイブックの作成](#ステップ2---プレイブックの作成) + - [ステップ3 - プレイブックの実行](#ステップ3---プレイブックの実行) + - [ステップ4 - プレイブックの確認](#ステップ4---プレイブックの確認) ## 目的 -この演習では、Ansible を使用して Red Hat Enterprise Linux 上に 2 つの Apache Web サーバーを構築します。この動画では、以下の Ansible の基礎を取り上げます。 - -* Ansible モジュールパラメーターについて -* 以下のモジュールの概要および使用 - * [yum モジュール](https://docs.ansible.com/ansible/latest/modules/yum_module.html) - * [service モジュール](https://docs.ansible.com/ansible/latest/modules/service_module.html) - * [copyモジュール](https://docs.ansible.com/ansible/latest/modules/copy_module.html) -* [べき等性](https://en.wikipedia.org/wiki/Idempotence) の概要および Ansible モジュールのべき等性について +この演習では、Ansibleを使用してRed Hat Enterprise Linuxサーバーで基本的なシステム設定タスクを行います。`dnf`や`user`などの基本的なAnsibleモジュールに慣れ親しんで、プレイブックの作成と実行方法を学びます。 ## ガイド -Playbook は、管理ホストに実装する必要な設定または手順を記述するファイルです。Playbook は、長く複雑な管理タスクを、予測できる成功する結果で、簡単に繰り返し可能なルーチンに変更できます。 - -1 つの Playbook には複数のプレイを含めることができ、単一または複数のタスクを指定できます。1つのタスクでは、前章のモジュールのように *module* が呼び出されます。*play* の目的は、ホストのグループをマッピングすることです。*task* の目的は、それらのホストにモジュールを実装することです。 - -> **ヒント** -> ->良い例を紹介します。Ansible モジュールがワークショップでのツールであるとすれば、インベントリーは素材で、Playbook は指示書のようなものです。 - -### ステップ 1 - Playbook の基本 - -Playbook は YAML 形式で記述されたテキストファイルなので、以下が必要になります。 - -* 3 つのダッシュ (`---`) で開始 - -* タブ**ではなく**、スペースを使用した正しいインデント - -重要な点を以下に示します。 - -* **hosts**: タスクを実行する管理対象ホスト - -* **tasks**: Ansible モジュールを呼び出して必要なオプションを渡すことで実行される操作 - -* **become**: Playbook における特権昇格 - -> **警告** -> -> Playbook 内のコンテンツの順序は、Ansible が提示された順序でプレイやタスクを実行するため重要です。 - -Playbook は **冪等** である必要があります。そのため、Playbook を 1 回実行してホストを正しい状態にできるのであれば、2 回目の実行でも安全であるため、ホストをさらに変更する必要はありません。 - -> **ヒント** -> -> 多くの Ansible モジュールは冪等です。そのため、この作業は比較的簡単です。 - -### ステップ 2 - Playbook 用のディレクトリー構造とファイルの作成 - -実践的な説明に移ります。はじめての Ansible Playbook を作成してみましょう。このラボでは、以下の 3 つの手順で Apache Web サーバーをセットアップする Playbook を作成します。 - -1. httpd のインストール -2. httpd サービスの有効化と起動 -3. web.html ファイルを各 Web ホストにコピーします。 - -この Playbook により、Apache Web サーバーを含むパッケージが `node1` にインストールされます。 - -Playbook に推奨されるディレクトリー構造についての [ベストプラクティス](https://docs.ansible.com/ansible/latest/user_guide/playbooks_best_practices.html) があります。Ansible スキルを発展させるためにも、これらのプラクティスを読んで理解することをお勧めします。とはいえ、現在の Playbook は非常に基本的です。複雑な構造を作ると、混乱するだけです。 - -代わりに、Playbook 用に非常に簡単なディレクトリー構造を作成し、そこにいくつかのファイルを追加します。 - -コントロールホスト **ansible** で、ホームディレクトリーに `ansible-files` というディレクトリーを作成し、そのディレクトリーにディレクトリーを変更します。 - -```bash -[student@ansible-1 ~]$ mkdir ansible-files -[student@ansible-1 ~]$ cd ansible-files/ -``` - -以下の内容の `apache.yml` というファイルを追加します。前回の演習でも説明したように、`vi`/`vim` を使います。あるいは、コマンドラインのエディターになれていない場合は、[エディター紹介](../0.0-support-docs/editor_intro.md) を参照してください。 - -```yaml ---- -- name: Apache server installed - hosts: node1 - become: yes -``` - -これは、Ansible の強みの 1 つである、Playbook 構文が読みやすく、理解しやすいという特徴を示しています。この Playbook では以下のような特徴があります。 - -* `name:` からのプレイ用に名前が指定されます。 -* Playbook を実行するホストは、`hosts:` で定義します。 -* `become:` でユーザー特権昇格を有効にします。 - -> **ヒント** -> -> 特権昇格は、パッケージのインストールや、root パーミッションが必要な他のタスクの実行に必要です。これは `become: yes` で、Playbook で行います。 - -プレイは定義できました。次は、何か実行するタスクを追加してみましょう。Apache パッケージが最新バージョンでインストールされていることを yum が確認するタスクを追加します。以下のようにファイルを変更します。 - -```yaml ---- -- name: Apache server installed - hosts: node1 - become: yes - tasks: - - name: latest Apache version installed - yum: - name: httpd - state: latest -``` - -> **ヒント** -> -> Playbook は YAML で記述されているため、行やキーワードを調整することが重要になります。`task` の *t* は、`become` の *b* に垂直にそろえるようにしてください。Ansible に慣れてきたら、[YAML 構文](https://docs.ansible.com/ansible/latest/reference_appendices/YAMLSyntax.html) を勉強するとよいでしょう。 +Ansibleのプレイブックは、基本的にYAML形式で書かれたスクリプトです。Ansibleがサーバーに適用するタスクと設定を定義するために使用されます。 -追加した行: +### ステップ1 - プレイブックの基本 +まず、プレイブック用のYAML形式のテキストファイルを作成します。覚えておくべきこと: +- 三つのダッシュ(`---`)から始めます。 +- インデントにはタブではなくスペースを使用します。 -* `tasks:` というキーワードでタスクの一部を開始しました。 -* タスクには名前が付けられ、タスクのモジュールが参照されます。ここでは、`yum` モジュールを使用します。 -* モジュールのパラメーターが追加されます。 - * パッケージ名を識別する `name:` - * パッケージの必要状態を定義する `state:` +主な概念: +- `hosts`: プレイブックが実行される対象のサーバーやデバイスを指定します。 +- `tasks`: Ansibleが実行するアクションです。 +- `become`: 権限の昇格（権限を持った状態でタスクを実行）を可能にします。 -> **ヒント** -> -> モジュールパラメーターは、各モジュールに個別で指定します。不明な場合は、`ansible-doc` で再度確認します。 +> 注: Ansibleのプレイブックは冪等性が設計されています。つまり、同じホストに対して複数回実行しても、望ましい状態を保証し、冗長な変更を加えないことを意味します。 -Playbook を保存し、エディターを終了します。 - -### ステップ 3 - Playbook の実行 - -Ansible Automation Platform 2 の導入に伴い、開発者の体験全体の一部として、いくつかの新しいキーコンポーネントが導入されています。実行環境は、オートメーションの実行時に使用する予測可能な環境を提供するために導入されました。すべてのコレクションの依存関係は実行環境に含まれ、開発環境で作成されたオートメーションが本番環境と同じように実行されることを確実にしています。 - -実行環境内で何が見つかるものについて - -* RHEL UBI 8 -* Ansible 2.9 または Ansible Core 2.11 -* Python 3.8 -* コンテンツコレクションについて -* Python またはバイナリーの依存関係のコレクション。 - -実行環境について - -オートメーションが実行される環境を定義、構築、配布するための標準的な方法を提供します。一言で言えば、オートメーションの実行環境とは、プラットフォームの管理者が Ansible の管理を容易にするためのコンテナイメージです。 - -自動化の実行がコンテナー化されていくことを考えると、Ansible Automation Platform 2 以前に存在していた自動化開発のワークフローやツールは、再構築する必要があります。つまり、`ansible-navigator` は、`ansible-playbook` やその他の`ansible-*` コマンドラインユーティリティーに取って代わります。 - -この変更により、Ansible Playbook はコントロールノードの `ansible-navigator` コマンドを使用して実行されます。 - -`ansible-navigator` を使用するための前提条件およびベストプラクティスが、このラボで行われています。 - -これらには以下が含まれます。 -* `ansible-navigator` パッケージのインストール -* 全プロジェクトに対するデフォルト設定 `/home/student/.ansible-navigator.yml` の作成（オプション） -* すべての実行環境(EE)ログは `/home/student/.ansible-navigator/logs/ansible-navigator.log` 内に保存されます -* Playbook アーティファクトは `/tmp/artifact.json` 下に保存されます - -[Ansible ナビゲーター設定](https://github.com/ansible/ansible-navigator/blob/main/docs/settings.rst) の詳細 - -> **ヒント** -> -ansible-navigato rのパラメーターは、ユーザーの環境に合わせて変更することができます。現在の設定では、すべてのプロジェクトにデフォルトの`ansible-navigator.yml` を使用していますが、プロジェクトごとに特定の`ansible-navigator.yml` を作成することができ、これは推奨される方法です。 - -Playbook を実行するには、`ansible-navigator run ` コマンドを使用します。 - -```bash -[student@ansible-1 ansible-files]$ ansible-navigator run apache.yml -``` - -> **ヒント** -> -既存の`ansible-navigator.yml` ファイルでは、インベントリファイルの場所が指定されています。これが`ansible-navigator.yml` ファイル内で設定されていない場合、プレイブックを実行するコマンドは次のようになります。 `ansible-navigator run apache.yml -i /home/student/lab_inventory/hosts` - -Playbook の実行時に、現在実行中の Playbook に関する他の情報間でプレイ名を表示するテキストユーザーインターフェース(TUI)が表示されます。 +### ステップ2 - プレイブックの作成 +最初のプレイブックを作成する前に、`~/lab_inventory`に移動して正しいディレクトリにいることを確認します: ```bash - PLAY NAME OK CHANGED UNREACHABLE FAILED SKIPPED IGNORED IN PROGRESS TASK COUNT PROGRESS -0│Apache server installed 2 1 0 0 0 0 0 2 COMPLETE +cd ~/lab_inventory ``` -お気づきかもしれませんが、play 名 `Apache server installed` の前に`0` が表示されています。キーボードの `0` キーを押すと、Playbook 完了までに実行されたさまざまなタスクを表示する新しいウィンドウビューが表示されます。この例では、「Gathering Facts」と「latest Apache version installed」のタスクが表示されています。「Gathering Facts」は、各 play の開始時に自動的に実行されるビルトインタスクです。管理対象のノードに関する情報を収集します。この後の演習では、これについて詳しく説明します。「latest Apache version installed」は、`apache.yml` ファイル内に作成されたタスクで、`httpd`をインストールするものでした。 - -表示は以下のようになります。 +次に、基本的なシステム設定を行う`system_setup.yml`という名前のプレイブックを作成します: +- セキュリティ関連のすべてのパッケージを更新します。 +- `myuser`という新しいユーザーを作成します。 -```bash - RESULT HOST NUMBER CHANGED TASK TASK ACTION DURATION -0│OK node1 0 False Gathering Facts gather_facts 1s -1│OK node1 1 True latest Apache version installed yum 4s -``` +基本的な構造は以下の通りです: -よく見ると、各タスクには番号がついています。タスク1の「latest Apache version installed」は、変更があり、`yum` モジュールを使用しています。この場合の変更点は、ホスト`node1` に Apache (`httpd` パッケージ) をインストールしたことです。 - -キーボードで`0` または`1` を押すと、実行中のタスクの詳細を見ることができます。より伝統的な出力表示が必要な場合は、テキストユーザーインターフェースで `:st` と入力してください。 - -Ansible Playbook を確認してから、キーボードの Esc キーを使用して TUI から終了できます。 - -> **ヒント** -> -Esc キーは前の画面に戻るだけです。メインの概要画面でEscキーを押すと、ターミナルウィンドウに戻ります。 - - -Playbook が完了したら、SSH で `node1` に接続し、Apache がインストールされていることを確認します。 - -```bash -[student@ansible-1 ansible-files]$ ssh node1 -Last login: Wed May 15 14:03:45 2019 from 44.55.66.77 -Managed by Ansible -``` - -`rpm -qi httpd` コマンドを使用して、httpd がインストールされていることを確認します。 - -```bash -[ec2-user@node1 ~]$ rpm -qi httpd -Name : httpd -Version : 2.4.37 -[...] -``` - -コントロールホストに戻るように `exit` コマンドで `node1` からログアウトし、package.ymlと名前を付けたAnsible Playbookを作成、実行し、インストールしたパッケージを確認します。 - -{% raw %} ```yaml --- -- name: Check packages +- name: Basic System Setup hosts: node1 become: true - vars: - package: "httpd" - tasks: - - name: Gather the package facts - ansible.builtin.package_facts: - manager: auto - - - name: Check whether a {{ package }} is installed - ansible.builtin.debug: - msg: "{{ package }} {{ ansible_facts.packages[ package ][0].version }} is installed!" - when: "package in ansible_facts.packages" + - name: Update all security-related packages + ansible.builtin.dnf: + name: '*' + state: latest + security: true + - name: Create a new user + ansible.builtin.user: + name: myuser + state: present + create_home: true ``` -{% endraw %} +> 注: パッケージの更新はAnsibleのプレイブックが完了する前に数分かかる場合があります。 -```bash -[student@ansible-1 ~]$ ansible-navigator run package.yml -m stdout -``` +* `dnf`モジュールについて: このモジュールは、RHELおよびその他のFedoraベースのシステムでDNF（Dandified YUM）を使用したパッケージ管理に使用されます。 -```bash +* `user`モジュールについて: このモジュールは、ユーザーアカウントの管理に使用されます。 -PLAY [Check packages] ********************************************************** +### ステップ3 - プレイブックの実行 -TASK [Gathering Facts] ********************************************************* -ok: [ansible] - -TASK [Gather the package facts] ************************************************ -ok: [ansible] - -TASK [Check whether a httpd is installed] ************************************* -ok: [ansible] => { - "msg": "httpd 2.4.37 is installed!" -} - -PLAY RECAP ********************************************************************* -ansible : ok=3 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 -``` - -`ansible-navigator run apache.yml` Playbook を 2 回ずつ実行し、出力を比較します。出力「CHANGED」には `1` ではなく `0` が表示され、色が黄色から緑色に変更されます。これにより、Ansible Playbook の実行時に変更が生じると、その変更を簡単に配置できるようになります。 - -### ステップ 4 - Playbook の拡張: Apache の起動と有効化 - -Ansible Playbook の次の部分では、Apache アプリケーションが `node1` で有効化されて起動するようにします。 - -コントロールホストで、`~/ansible-files/apache.yml` を編集し、`service` モジュールを使用して 2 番目のタスクを追加します。実際の Playbook は以下のようになります。 - -```yaml ---- -- name: Apache server installed - hosts: node1 - become: yes - tasks: - - name: latest Apache version installed - yum: - name: httpd - state: latest - - name: Apache enabled and running - service: - name: httpd - enabled: true - state: started -``` - -何を行ったのでしょうか? - -* 「Apache enabled and running」という名前の 2 番目のタスクが作成されます。 -* モジュールが指定されます (`service`) -* モジュール `service` はサービス名 (`httpd`) を取ります。これを永続的に設定する必要がある場合は(`enabled`)、および現在の状態 (`started`) を使用します。 - - -つまり、2 番目のタスクにより、Apache サーバーがターゲットマシンで実行されるようにしています。拡張 Playbook を実行します。 +`ansible-navigator`コマンドを使用してプレイブックを実行します: ```bash -[student@ansible-1 ~]$ ansible-navigator run apache.yml +[student@ansible-1 lab_inventory]$ ansible-navigator run system_setup.yml -m stdout ``` -この出力では、プレイに `1` "CHANGED" が表示されますが、`0` を押してプレイの出力に入ることができます。そのタスク 2「Apache enabled and running」は、"CHANGED" 値が True に設定され、黄色でで強調表示されているタスクでした。 - +各タスクが正常に完了したことを確認するために出力を確認してください。 -* 出力内の変更に慣れるためにも、`ansible-navigator` を使用して Playbook を再び実行してみてください。 +### ステップ4 - プレイブックの確認 +次に、設定後のチェック用に`system_checks.yml`という名前の2つ目のプレイブックを作成しましょう: -* service_state.yml と名前を付けた Ansible Playbook を作成、実行し、`node1` 上で Apache（httpd）サービスが実行されていることを確認します（`systemctl status httpd` と同じように）。 - -{% raw %} ```yaml --- -- name: Check Status +- name: System Configuration Checks hosts: node1 become: true - vars: - package: "httpd" - tasks: - - name: Check status of {{ package }} service - service_facts: - register: service_state - - - debug: - var: service_state.ansible_facts.services["{{ package }}.service"].state -``` - -```bash -{% endraw %} - -[student@ansible-1 ~]$ ansible-navigator run service_state.yml -``` - -### ステップ 5 - Playbook の拡張: web.html の作成 - -タスクが正しく実行され、Apache が接続を受け入れることを確認します。 Ansible の `uri` モジュールを使用して、コントロールノードから `node1` に HTTP リクエストを作成する、check_httpd.yml という名前の Playbook を作成、実行します。 - -{% raw %} -```yaml ---- -- name: Check URL - hosts: control - vars: - node: "node1" - - tasks: - - name: Check that you can connect (GET) to a page and it returns a status 200 - uri: - url: "http://{{ node }}" - -``` -{% endraw %} - -> **警告** -> -> **赤い行と 403 ステータスが多く表示されます。** - -```bash -[student@ansible-1 ~]$ ansible-navigator run check_httpd.yml -m stdout -``` - -赤い行やエラーが多く表示されます。Apache によって提供される `web.html` ファイルがなければ、「HTTP Error 403: Forbidden」ステータスが表示され、Ansible はエラーを報告します。 + - name: Check user existence + ansible.builtin.command: + cmd: id myuser + register: user_check -では、Ansible を使用してシンプルな `web.html` ファイルをデプロイしてはどうでしょうか。ansible コントロールホストで、`student` ユーザーとして `~/ansible-files/` にファイルリソースを保持するディレクトリー `files` を作成します。 - -```bash -[student@ansible-1 ansible-files]$ mkdir files -``` - -次に、コントロールノードに `~/ansible-files/files/web.html` ファイルを作成します。 - -```html - -

Apache は正常に動作しています

- -``` - -以前の例では、Ansible の `copy` モジュールを使用してコマンドラインに出力されたテキストをファイルに書き込みました。次は、Playbook でモジュールを使用してファイルをコピーします。 - -コントロールノードで、ファイル `~/ansible-files/apache.yml` を編集して、`copy` モジュールを使用して新しいタスクを追加します。以下のようになります。 - -```yaml ---- -- name: Apache server installed - hosts: node1 - become: yes - tasks: - - name: latest Apache version installed - yum: - name: httpd - state: latest - - name: Apache enabled and running - service: - name: httpd - enabled: true - state: started - - name: copy web.html - copy: - src: web.html - dest: /var/www/html/index.html -``` - -この新しいコピータスクで何が起きるのでしょうか。この新しいタスクは、`copy` モジュールを使用し、コピー操作のソースオプションおよび宛先オプションをパラメーターとして定義します。 - -拡張 Playbook を実行します。 - -```bash -[student@ansible-1 ansible-files]$ ansible-navigator run apache.yml -m stdout -``` - -* 出力を確認し、「CHANGED」と、その変更に関連するタスクが変更されたことに注意してください。 - -* 上記の「uri」モジュールを再度使用して playbook (check_httpd.yml) を実行し、Apache をテストします。これで、このコマンドは、その他の情報とともに正常の「status: 200」の行が返されるはずです。 - -### ステップ 6 - 練習: 複数ホストへの適用 - -上記では、特定のホストに変更を加えることを簡単に説明しました。では、多くのホストに変更を加えたい場合はどうでしょうか。ここで Ansible の真価が発揮されます。Ansible は、同じタスクセットを多くのホストに確実に適用します。 - -* そのため、`node1` **と** `node2` **と** `node3`で実行するように apache.yml Playbook を変更するのはどうでしょうか。 - -覚えているとおもいますが、インベントリーは、すべてのノードをグループ `web` のメンバーとして一覧表示します。 - -```ini -[web] -node1 ansible_host=11.22.33.44 -node2 ansible_host=22.33.44.55 -node3 ansible_host=33.44.55.66 -``` - -> **ヒント** -> -> こちらに表示される IP アドレスは例です。実際のノードの IP アドレスは異なります。 - -Playbook の `hosts` パラメーターを、`node1` ではなく `web` を参照するように変更します。 - -```yaml ---- -- name: Apache server installed - hosts: web - become: yes - tasks: - - name: latest Apache version installed - yum: - name: httpd - state: latest - - name: Apache enabled and running - service: - name: httpd - enabled: true - state: started - - name: copy web.html - copy: - src: web.html - dest: /var/www/html/index.html + - name: Report user status + ansible.builtin.debug: + msg: "User 'myuser' exists." + when: user_check.rc == 0 ``` -次に Playbook を実行します。 +チェック用のプレイブックを実行します: ```bash -[student@ansible-1 ansible-files]$ ansible-navigator run apache.yml -m stdout +[student@ansible-1 lab_inventory]$ ansible-navigator run system_checks.yml -m stdout ``` -Apache がすべての Web サーバー（node1、node2、node3）で実行されているかどうかを確認します。すべての出力が緑色である必要があります。 +ユーザー作成が成功したことを確認するために出力を確認してください。 --- **ナビゲーション** -
- {% if page.url contains 'ansible_rhel_90' %} -[Previous Exercise](../2-thebasics) - [Next Exercise](../4-variables) +[前の演習](../2-thebasics) - [次の演習](../4-variables) {% else %} -[Previous Exercise](../1.2-thebasics) - [Next Exercise](../1.4-variables) +[前の演習](../1.2-thebasics) - [次の演習](../1.4-variables) {% endif %}

-[Click here to return to the Ansible for Red Hat Enterprise Linux Workshop](../README.md#section-1---ansible-engine-exercises) + +
+ +[Red Hat Enterprise Linux用Ansibleワークショップに戻る](../README.md)"" + diff --git a/exercises/ansible_rhel/1.3-playbook/README.md b/exercises/ansible_rhel/1.3-playbook/README.md index cf3479a50..f40af2f5d 100644 --- a/exercises/ansible_rhel/1.3-playbook/README.md +++ b/exercises/ansible_rhel/1.3-playbook/README.md @@ -6,488 +6,125 @@ ## Table of Contents - [Workshop Exercise - Writing Your First Playbook](#workshop-exercise---writing-your-first-playbook) - - [Table of Contents](#table-of-contents) - [Objective](#objective) - [Guide](#guide) - [Step 1 - Playbook Basics](#step-1---playbook-basics) - - [Step 2 - Creating a Directory Structure and File for your Playbook](#step-2---creating-a-directory-structure-and-file-for-your-playbook) + - [Step 2 - Creating Your Playbook](#step-2---creating-your-playbook) - [Step 3 - Running the Playbook](#step-3---running-the-playbook) - - [Step 4 - Extend your Playbook: Start \& Enable Apache](#step-4---extend-your-playbook-start--enable-apache) - - [Step 5 - Extend your Playbook: Create an web.html](#step-5---extend-your-playbook-create-an-webhtml) - - [Step 6 - Practice: Apply to Multiple Host](#step-6---practice-apply-to-multiple-host) + - [Step 4 - Checking the Playbook](#step-4---checking-the-playbook) -## Objective -This exercise covers using Ansible to build two Apache web servers on Red Hat Enterprise Linux. This exercise covers the following Ansible fundamentals: +## Objective -* Understanding Ansible module parameters -* Understanding and using the following modules - * [dnf module](https://docs.ansible.com/ansible/latest/modules/dnf_module.html) - * [service module](https://docs.ansible.com/ansible/latest/modules/service_module.html) - * [copy module](https://docs.ansible.com/ansible/latest/modules/copy_module.html) -* Understanding [Idempotence](https://en.wikipedia.org/wiki/Idempotence) and how Ansible modules can be idempotent +In this exercise, you'll use Ansible to conduct basic system setup tasks on a +Red Hat Enterprise Linux server. You will become familiar with fundamental +Ansible modules like `dnf` and `user`, and learn how to create and run +playbooks. ## Guide -Playbooks are files which describe the desired configurations or steps to implement on managed hosts. Playbooks can change lengthy, complex administrative tasks into easily repeatable routines with predictable and successful outcomes. - -A playbook can have multiple plays and a play can have one or multiple tasks. In a task a *module* is called, like the modules in the previous chapter. The goal of a *play* is to map a group of hosts. The goal of a *task* is to implement modules against those hosts. - -> **Tip** -> -> Here is a nice analogy: When Ansible modules are the tools in your workshop, the inventory is the materials and the Playbooks are the instructions. +Playbooks in Ansible are essentially scripts written in YAML format. They are +used to define the tasks and configurations that Ansible will apply to your +servers. ### Step 1 - Playbook Basics +First, create a text file in YAML format for your playbook. Remember: +- Start with three dashes (`---`). +- Use spaces, not tabs, for indentation. -Playbooks are text files written in YAML format and therefore need: - -* to start with three dashes (`---`) - -* proper indentation using spaces and **not** tabs\! - -There are some important concepts: - -* **hosts**: the managed hosts to perform the tasks on - -* **tasks**: the operations to be performed by invoking Ansible modules and passing them the necessary options - -* **become**: privilege escalation in playbooks - -> **Warning** -> -> The ordering of the contents within a Playbook is important, because Ansible executes plays and tasks in the order they are presented. - -A Playbook should be **idempotent**, so if a Playbook is run once to put the hosts in the correct state, it should be safe to run it a second time and it should make no further changes to the hosts. +Key Concepts: +- `hosts`: Specifies the target servers or devices for your playbook to run against. +- `tasks`: The actions Ansible will perform. +- `become`: Allows privilege escalation (running tasks with elevated privileges). -> **Tip** -> -> Most Ansible modules are idempotent, so it is relatively easy to ensure this is true. +> NOTE: An Ansible playbook is designed to be idempotent, meaning if you run it multiple times on the same hosts, it ensures the desired state without making redundant changes. -### Step 2 - Creating a Directory Structure and File for your Playbook - -Enough theory, it’s time to create your first Ansible playbook. In this lab you create a playbook to set up an Apache web server in three steps: - -1. Install httpd package -2. Enable/start httpd service -3. Copy over an web.html file to each web host - -This Playbook makes sure the package containing the Apache web server is installed on `node1`. - -There is a [best practice](https://docs.ansible.com/ansible/latest/user_guide/playbooks_best_practices.html) on the preferred directory structures for playbooks. We strongly encourage you to read and understand these practices as you develop your Ansible ninja skills. That said, our playbook today is very basic and creating a complex structure will just confuse things. - -Instead, we are going to create a very simple directory structure for our playbook, and add just a couple of files to it. - -On your control host **ansible**, create a directory called `ansible-files` in your home directory and change directories into it: +### Step 2 - Creating Your Playbook +Before creating your first playbook, ensure you are in the correct directory by changing to `~/lab_inventory`: ```bash -[student@ansible-1 ~]$ mkdir ansible-files -[student@ansible-1 ~]$ cd ansible-files/ +cd ~/lab_inventory ``` -Add a file called `apache.yml` with the following content. As discussed in the previous exercises, use `vi`/`vim` or, if you are new to editors on the command line, check out the [editor intro](../0.0-support-docs/editor_intro.md) again. - -```yaml ---- -- name: Apache server installed - hosts: node1 - become: yes -``` +Now create a playbook named `system_setup.yml` to perform basic system setup: +- Update all security related packages. +- Create a new user named ‘myuser’. -This shows one of Ansible’s strengths: The Playbook syntax is easy to read and understand. In this Playbook: - -* A name is given for the play via `name:`. -* The host to run the playbook against is defined via `hosts:`. -* We enable user privilege escalation with `become:`. - -> **Tip** -> -> You obviously need to use privilege escalation to install a package or run any other task that requires root permissions. This is done in the Playbook by `become: yes`. - -Now that we've defined the play, let's add a task to get something done. We will add a task in which dnf will ensure that the Apache package is installed in the latest version. Modify the file so that it looks like the following listing: +The basic structure looks as follows: ```yaml --- -- name: Apache server installed +- name: Basic System Setup hosts: node1 - become: yes + become: true tasks: - - - name: Install Apache + - name: Update all security-related packages ansible.builtin.dnf: - name: httpd + name: '*' + state: latest + security: true + + - name: Create a new user + ansible.builtin.user: + name: myuser + state: present + create_home: true ``` -> **Tip** -> -> Since playbooks are written in YAML, alignment of the lines and keywords is crucial. Make sure to vertically align the *t* in `task` with the *b* in `become`. Once you are more familiar with Ansible, make sure to take some time and study a bit the [YAML Syntax](https://docs.ansible.com/ansible/latest/reference_appendices/YAMLSyntax.html). - -In the added lines: +> NOTE: Updating the packages may take a few minutes prior to the Ansible playbook completing. -* We started the tasks part with the keyword `tasks:`. -* A task is named and the module for the task is referenced. Here it uses the `dnf` module. -* Parameters for the module are added: - * `name:` to identify the package name - * `state:` to define the wanted state of the package +* About the `dnf` module: This module is used for package management with DNF (Dandified YUM) on RHEL and other Fedora-based systems. -> **Tip** -> -> The module parameters are individual to each module. If in doubt, look them up again with `ansible-doc`. - -Save your playbook and exit your editor. +* About the `user` module: This module is used to manage user accounts. ### Step 3 - Running the Playbook -With the introduction of Ansible Automation Platform 2, several new key components are being introduced as a part of the overall developer experience. Execution environments have been introduced to provide predictable environments to be used during automation runtime. All collection dependencies are contained within the execution environment to ensure that automation created in development environments runs the same as in production environments. - -What do you find within an execution environment? - -* RHEL UBI 8 -* Ansible 2.9 or Ansible Core 2.11 -* Python 3.8 -* Any content Collections -* Collection python or binary dependencies. - -Why use execution environments? - -They provide a standardized way to define, build and distribute the environments that the automation runs in. In a nutshell, Automation execution environments are container images that allow for easier administration of Ansible by the platform administrator. - -Considering the shift towards containerized execution of automation, automation development workflow and tooling that existed before Ansible Automation Platform 2 have had to be reimagined. In short, `ansible-navigator` replaces `ansible-playbook` and other `ansible-*` command line utilities. - -With this change, Ansible playbooks are executed using the `ansible-navigator` command on the control node. - -The prerequisites and best practices for using `ansible-navigator` have been done for you within this lab. - -These include: -* Installing the `ansible-navigator` package -* Creating a default settings `/home/student/.ansible-navigator.yml` for all your projects (optional) -* All execution environment (EE) logs are stored within `/home/student/.ansible-navigator/logs/ansible-navigator.log` -* Playbook artifacts are saved under `/tmp/artifact.json` - -For more information on the [Ansible navigator settings](https://github.com/ansible/ansible-navigator/blob/main/docs/settings.rst) - -> **Tip** -> -> The parameters for ansible-navigator maybe modified for your specific environment. The current settings use a default `ansible-navigator.yml` for all projects, but a specific `ansible-navigator.yml` can be created for each project and is the recommended practice. - -To run your playbook, use the `ansible-navigator run ` command as follows: - -```bash -[student@ansible-1 ansible-files]$ ansible-navigator run apache.yml -``` - -> **Tip** -> -> The existing `ansible-navigator.yml` file provides the location of your inventory file. If this was not set within your `ansible-navigator.yml` file, the command to run the playbook would be: `ansible-navigator run apache.yml -i /home/student/lab_inventory/hosts` - -When running the playbook, you'll be displayed a text user interface (TUI) that displays the play name among other information about the playbook that is currently run. - -```bash - PLAY NAME OK CHANGED UNREACHABLE FAILED SKIPPED IGNORED IN PROGRESS TASK COUNT PROGRESS -0│Apache server installed 2 1 0 0 0 0 0 2 COMPLETE -``` - -If you notice, prior to the play name `Apache server installed`, you'll see a `0`. By pressing the `0` key on your keyboard, you will be provided a new window view displaying the different tasks that ran for the playbook completion. In this example, those tasks included the "Gathering Facts" and "Install Apache". The "Gathering Facts" is a built-in task that runs automatically at the beginning of each play. It collects information about the managed nodes. Exercises later on will cover this in more detail. The "Install Apache" was the task created within the `apache.yml` file that installed `httpd`. - -The display should look something like this: +Execute your playbook using the `ansible-navigator` command: ```bash - RESULT HOST NUMBER CHANGED TASK TASK ACTION DURATION -0│OK node1 0 False Gathering Facts gather_facts 1s -1│OK node1 1 True Install Apache dnf 4s +[student@ansible-1 lab_inventory]$ ansible-navigator run system_setup.yml -m stdout ``` -Taking a closer look, you'll notice that each task is associated with a number. Task 1, "Install Apache", had a change and used the `dnf` module. In this case, the change is the installation of Apache (`httpd` package) on the host `node1`. +Review the output to ensure each task is completed successfully. -By pressing `0` or `1` on your keyboard, you can see further details of the task being run. If a more traditional output view is desired, type `:st` within the text user interface. +### Step 4 - Checking the Playbook +Now, let’s create a second playbook for post-configuration checks, named `system_checks.yml`: -Once you've completed, reviewing your Ansible playbook, you can exit out of the TUI via the Esc key on your keyboard. - -> **Tip** -> -> The Esc key only takes you back to the previous screen. Once at the main overview screen an additional Esc key will take you back to the terminal window. - - -Once the playbook has completed, connect to `node1` via SSH to make sure Apache has been installed: - -```bash -[student@ansible-1 ansible-files]$ ssh node1 -Last login: Wed May 15 14:03:45 2019 from 44.55.66.77 -Managed by Ansible -``` - -Use the command `rpm -qi httpd` to verify httpd is installed: - -```bash -[ec2-user@node1 ~]$ rpm -qi httpd -Name : httpd -Version : 2.4.37 -[...] -``` - -Log out of `node1` with the command `exit` so that you are back on the control host and verify the installed package with an Ansible playbook labeled `package.yml` - -{% raw %} ```yaml --- -- name: Check packages +- name: System Configuration Checks hosts: node1 become: true - vars: - package: "httpd" - tasks: - - name: Gather the package facts - ansible.builtin.package_facts: - manager: auto - - - name: Check whether a {{ package }} is installed + - name: Check user existence + ansible.builtin.command: + cmd: id myuser + register: user_check + + - name: Report user status ansible.builtin.debug: - msg: "{{ package }} {{ ansible_facts.packages[ package ][0].version }} is installed!" - when: "package in ansible_facts.packages" - -``` -{% endraw %} - - -```bash -[student@ansible-1 ~]$ ansible-navigator run package.yml -m stdout -``` - -```bash - -PLAY [Check packages] ********************************************************** - -TASK [Gathering Facts] ********************************************************* -ok: [ansible] - -TASK [Gather the package facts] ************************************************ -ok: [ansible] - -TASK [Check whether a httpd is installed] ************************************* -ok: [ansible] => { - "msg": "httpd 2.4.37 is installed!" -} - -PLAY RECAP ********************************************************************* -ansible : ok=3 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 -``` - -Run the the `ansible-navigator run apache.yml` playbook for a second time, and compare the output. The output "CHANGED" now shows `0` instead of `1` and the color changed from yellow to green. This makes it easier to spot when changes have occured when running the Ansible playbook. - -### Step 4 - Extend your Playbook: Start & Enable Apache - -The next part of the Ansible playbook makes sure the Apache application is enabled and started on `node1`. - -On the control host, as your student user, edit the file `~/ansible-files/apache.yml` to add a second task using the `service` module. The Playbook should now look like this: - -```yaml ---- -- name: Apache server installed - hosts: node1 - become: true - tasks: - - - name: Install Apache - ansible.builtin.dnf: - name: httpd - - - name: Apache enabled and running - ansible.builtin.service: - name: httpd - enabled: true - state: started -``` - -What exactly did we do? - -* a second task named "Apache enabled and running" is created -* a module is specified (`service`) -* The module `service` takes the name of the service (`httpd`), if it should be permanently set (`enabled`), and its current state (`started`) - - -Thus with the second task we make sure the Apache server is indeed running on the target machine. Run your extended Playbook: - -```bash -[student@ansible-1 ~]$ ansible-navigator run apache.yml -``` - -Notice in the output, we see the play had `1` "CHANGED" shown in yellow and if we press `0` to enter the play output, you can see that task 2, "Apache enabled and running", was the task that incorporated the latest change by the "CHANGED" value being set to True and highlighted in yellow. - - -* Run the playbook a second time using `ansible-navigator` to get used to the change in the output. - -* Use an Ansible playbook labeled service_state.yml to make sure the Apache (httpd) service is running on `node1`, e.g. with: `systemctl status httpd`. - -{% raw %} -```yaml ---- -- name: Check Status - hosts: node1 - become: true - vars: - package: "httpd" - - tasks: - - name: Check status of {{ package }} service - ansible.builtin.service_facts: - register: service_state - - - ansible.builtin.debug: - var: service_state.ansible_facts.services["{{ package }}.service"].state -``` - -```bash -{% endraw %} - -[student@ansible-1 ~]$ ansible-navigator run service_state.yml -``` - -### Step 5 - Extend your Playbook: Create an web.html - -Check that the tasks were executed correctly and Apache is accepting connections: Make an HTTP request using Ansible’s `uri` module in a playbook named check_httpd.yml from the control node to `node1`. - -{% raw %} -```yaml ---- -- name: Check URL - hosts: control - vars: - node: "node1" - - tasks: - - name: Check that you can connect (GET) to a page and it returns a status 200 - ansible.builtin.uri: - url: "http://{{ node }}" - -``` -{% endraw %} - -> **Warning** -> -> **Expect a lot of red lines and a 403 status\!** - -```bash -[student@ansible-1 ~]$ ansible-navigator run check_httpd.yml -m stdout -``` - -There are a lot of red lines and an error: As long as there is not at least an `web.html` file to be served by Apache, it will throw an ugly "HTTP Error 403: Forbidden" status and Ansible will report an error. - -So why not use Ansible to deploy a simple `web.html` file? On the ansible control host, as the `student` user, create the directory `files` to hold file resources in `~/ansible-files/`: - -```bash -[student@ansible-1 ansible-files]$ mkdir files -``` - -Then create the file `~/ansible-files/files/web.html` on the control node: - -```html - -

Apache is running fine

- + msg: "User 'myuser' exists." + when: user_check.rc == 0 ``` -In a previous example, you used Ansible’s `copy` module to write text supplied on the command line into a file. Now you’ll use the module in your playbook to copy a file. - -On the control node as your student user edit the file `~/ansible-files/apache.yml` and add a new task utilizing the `copy` module. It should now look like this: - -```yaml ---- -- name: Apache server installed - hosts: node1 - become: true - tasks: - - - name: Install Apache - ansible.builtin.dnf: - name: httpd - - - name: Apache enabled and running - ansible.builtin.service: - name: httpd - enabled: true - state: started - - - name: Copy index.html - ansible.builtin.copy: - src: web.html - dest: /var/www/html/index.html - mode: '644' -``` - -What does this new copy task do? The new task uses the `copy` module and defines the source and destination options for the copy operation as parameters. - -Run your extended Playbook: +Run the checks playbook: ```bash -[student@ansible-1 ansible-files]$ ansible-navigator run apache.yml -m stdout +[student@ansible-1 lab_inventory]$ ansible-navigator run system_checks.yml -m stdout ``` -* Have a good look at the output, notice the changes of "CHANGED" and the tasks associated with that change. - -* Run the Ansible playbook check_httpd.yml using the "uri" module from above again to test Apache. The command should now return a friendly green "status: 200" line, amongst other information. - -### Step 6 - Practice: Apply to Multiple Host - -While the above, shows the simplicity of applying changes to a particular host. What about if you want to set changes to many hosts? This is where you'll notice the real power of Ansible as it applies the same set of tasks reliably to many hosts. - -* So what about changing the apache.yml Playbook to run on `node1` **and** `node2` **and** `node3`? - -As you might remember, the inventory lists all nodes as members of the group `web`: - -```ini -[web] -node1 ansible_host=11.22.33.44 -node2 ansible_host=22.33.44.55 -node3 ansible_host=33.44.55.66 -``` - -> **Tip** -> -> The IP addresses shown here are just examples, your nodes will have different IP addresses. - -Change the playbook `hosts` parameter to point to `web` instead of `node1`: - -```yaml ---- -- name: Apache server installed - hosts: web - become: true - tasks: - - - name: Install Apache - ansible.builtin.dnf: - name: httpd - - - name: Apache enabled and running - ansible.builtin.service: - name: httpd - enabled: true - state: started - - - name: Copy index.html - ansible.builtin.copy: - src: web.html - dest: /var/www/html/index.html - mode: '644' - -``` - -Now run the playbook: - -```bash -[student@ansible-1 ansible-files]$ ansible-navigator run apache.yml -m stdout -``` - -Verify if Apache is now running on all web servers (node1, node2, node3). All output should be green. +Review the output to ensure the user creation was successful. --- **Navigation** -
- {% if page.url contains 'ansible_rhel_90' %} [Previous Exercise](../2-thebasics) - [Next Exercise](../4-variables) {% else %} [Previous Exercise](../1.2-thebasics) - [Next Exercise](../1.4-variables) {% endif %}

-[Click here to return to the Ansible for Red Hat Enterprise Linux Workshop](../README.md#section-1---ansible-engine-exercises) + +
+ +[Click here to return to the Ansible for Red Hat Enterprise Linux Workshop](../README.md) + diff --git a/exercises/ansible_rhel/1.3-playbook/README.pt-br.md b/exercises/ansible_rhel/1.3-playbook/README.pt-br.md index ee1bbe6ac..1550f83b1 100644 --- a/exercises/ansible_rhel/1.3-playbook/README.pt-br.md +++ b/exercises/ansible_rhel/1.3-playbook/README.pt-br.md @@ -1,321 +1,124 @@ -# Exercício - Escrevendo seu primeiro Playbook +# Exercício do Workshop - Escrevendo Seu Primeiro Playbook -**Leia em outras linguagens**: -
![uk](../../../images/uk.png) [English](README.md), ![japan](../../../images/japan.png)[日本語](README.ja.md), ![brazil](../../../images/brazil.png) [Portugues do Brasil](README.pt-br.md), ![france](../../../images/fr.png) [Française](README.fr.md),![Español](../../../images/col.png) [Español](README.es.md). +**Leia isso em outros idiomas**: +
![uk](../../../images/uk.png) [Inglês](README.md), ![japan](../../../images/japan.png) [日本語](README.ja.md), ![brazil](../../../images/brazil.png) [Português do Brasil](README.pt-br.md), ![france](../../../images/fr.png) [Francês](README.fr.md), ![Español](../../../images/col.png) [Espanhol](README.es.md). -* [Passo 1 - Noções básicas do Playbook](#passo-1---noções-básicas-do-playbook) -* [Passo 2 - Criando uma estrutura de diretórios e um arquivo para o seu Playbook](#passo-2---criando-uma-estrutura-de-diretórios-e-um-arquivo-para-o-seu-playbook) -* [Passo 3 - Rodando o Playbook](#passo-3---rodando-o-playbook) -* [Passo 4 - Amplie seu playbook: Apache Start & Enable](#passo-4---amplie-seu-playbook-apache-start--enable) -* [Passo 5 - Ampliando seu Playbook: Criando um aquivo web.html](#passo-5---ampliando-seu-playbook-criando-um-aquivo-indexhtml) -* [Passo 6 - Pratique: Aplicar a vários hosts](#passo-6---pratique-aplicar-a-vários-hosts) +## Índice de Conteúdos -Embora os comandos Ansible ad hoc sejam úteis para operações simples, eles não são adequados para cenários complexos de gerenciamento ou orquestração de configurações. Para tais casos de uso, os playbooks são o caminho a percorrer. +- [Exercício do Workshop - Escrevendo Seu Primeiro Playbook](#exercício-do-workshop---escrevendo-seu-primeiro-playbook) + - [Objetivo](#objetivo) + - [Guia](#guia) + - [Etapa 1 - Básicos do Playbook](#etapa-1---básicos-do-playbook) + - [Etapa 2 - Criando Seu Playbook](#etapa-2---criando-seu-playbook) + - [Etapa 3 - Executando o Playbook](#etapa-3---executando-o-playbook) + - [Etapa 4 - Verificando o Playbook](#etapa-4---verificando-o-playbook) -Playbooks são arquivos que descrevem as configurações ou etapas desejadas para implementar em hosts gerenciados. Os Playbooks podem transformar tarefas administrativas complexas e longas em rotinas facilmente repetíveis, com resultados previsíveis e bem-sucedidos. +## Objetivo -Um Playbook é onde você pode pegar alguns desses comandos ad-hoc que você acabou de executar e colocá-los em um conjunto repetitivo de *plays* e *tasks*. +Neste exercício, você usará o Ansible para realizar tarefas básicas de configuração do sistema em um servidor Red Hat Enterprise Linux. Você se familiarizará com módulos fundamentais do Ansible como `dnf` e `user`, e aprenderá a criar e executar playbooks. -Um Playbook pode ter várias plays e uma play pode ter uma ou várias tasks. Em uma task, um *módulo* é chamado, como os módulos do capítulo anterior. O objetivo de um *play* é mapear um grupo de hosts. O objetivo de uma *task* é implementar módulos nesses hosts. +## Guia -> **Dica** -> -> Uma boa analogia: quando os módulos Ansible são as ferramentas da sua oficina, o inventário é o material e os Playbooks são as instruções. +Os playbooks no Ansible são basicamente scripts escritos em formato YAML. Eles são usados para definir as tarefas e configurações que o Ansible aplicará aos seus servidores. -## Passo 1 - Noções básicas do Playbook +### Etapa 1 - Básicos do Playbook +Primeiro, crie um arquivo de texto em formato YAML para o seu playbook. Lembre-se de: +- Começar com três traços (`---`). +- Usar espaços, não tabs, para indentação. -Playbooks são arquivos de texto escritos no formato YAML e, portanto, precisam: +Conceitos Principais: +- `hosts`: Especifica os servidores ou dispositivos alvo para o seu playbook ser executado. +- `tasks`: As ações que o Ansible realizará. +- `become`: Permite a escalada de privilégios (executar tarefas com privilégios elevados). - - Começar com três traços (`---`) +> NOTA: Um playbook do Ansible é projetado para ser idempotente, o que significa que se você executá-lo várias vezes nos mesmos hosts, ele garante o estado desejado sem fazer mudanças redundantes. - - Recuo adequado usando espaços e **não** tabs\! - -Existem alguns conceitos importantes: - - - **hosts**: Os hosts gerenciados para executar as tasks. - - - **tasks**: As operações a serem executadas chamando os módulos e passando as opções necessárias. - - - **become**: Escalação de privilégios nos Playbooks, o mesmo que usar `-b` no comando ad hoc. - -> **ATENÇÃO** -> -> A ordem do conteúdo em um Playbook é importante, porque o Ansible executa plays e tasks na ordem em que são apresentadas. - -Um Playbook deve ser **idempotente**, portanto se um Playbook for executado uma vez para colocar os hosts no estado correto, deve ser seguro executá-lo uma segunda vez e não deverá fazer mais alterações nos hosts. - -> **Dica** -> -> A maioria dos módulos Ansible é idempotente, portanto é relativamente fácil garantir que isso seja verdade. - -## Passo 2 - Criando uma estrutura de diretórios e um arquivo para o seu Playbook - -Chega de teoria, é hora de criar seu primeiro Playbook. Neste laboratório, você cria um Playbook para configurar um servidor web Apache em três etapas: - - - 1ª Etapa: Instalar o pacote httpd - - - 2ª Etapa: Enable/start o serviço httpd - - - 3ª Etapa: Criar um aquivo web.html - -Este Playbook garante que o pacote que contém o servidor Apache esteja instalado no `node1`. - -Há uma [melhor prática](https://docs.ansible.com/ansible/latest/user_guide/playbooks_best_practices.html) nas estruturas de diretório recomendadas para playbooks. Nós recomendamos a ler e entender essas práticas ao desenvolver suas habilidades de Ansible ninja. Dito isto, nosso Playbook hoje é muito básico e criar uma estrutura complexa apenas confundirá as coisas. - -Em vez disso, vamos criar uma estrutura de diretórios muito simples para nosso playbook e adicionar apenas alguns arquivos a ele. - -No host de controle **ansible**, crie um diretório chamado `ansible-files` no seu diretório pessoal e altere os diretórios para ele: +### Etapa 2 - Criando Seu Playbook +Antes de criar seu primeiro playbook, certifique-se de estar no diretório correto mudando para `~/lab_inventory`: ```bash -[student@ansible ~]$ mkdir ansible-files -[student@ansible ~]$ cd ansible-files/ -``` - -Adicione um arquivo chamado `apache.yml` com o seguinte conteúdo. Conforme discutido nos exercícios anteriores, use `vi`/`vim` ou, se você é novo nos editores na linha de comando, consulte a [introdução do editor](../0.0-support-docs/editor_intro.md) novamente. - -```yaml ---- -- name: Apache server instalado - hosts: node1 - become: yes +cd ~/lab_inventory ``` -Isso mostra uma das forças do Ansible: a sintaxe do Playbook é fácil de ler e entender. Neste manual: +Agora, crie um playbook chamado `system_setup.yml` para realizar a configuração básica do sistema: +- Atualize todos os pacotes relacionados à segurança. +- Crie um novo usuário chamado ‘myuser’. - - Um nome é dado para a Play via `name:`. - - - O host para qual irá executar o Playbook é definido por meio de`hosts:`. - - - Ativamos a escalação de privilégios de usuário com `become:`. - -> **Dica** -> -> Obviamente, você precisa usar a escalação de privilégios para instalar um pacote ou executar qualquer outra task que exija permissões de root. Isso é feito no Playbook por `Become: yes'. - -Agora que definimos a play, vamos adicionar uma task para fazer algo. Adicionaremos uma task na qual o yum garantirá que o pacote Apache esteja instalado na versão mais recente. Modifique o arquivo para que ele se pareça com a seguinte listagem: +A estrutura básica é a seguinte: ```yaml --- -- name: Apache server instalado +- name: Basic System Setup hosts: node1 - become: yes + become: true tasks: - - name: Ultima versao do apache server instalado - yum: - name: httpd - state: latest -``` -> **Dica** -> -> Como os playbooks são escritos em YAML, o alinhamento das linhas e das palavras-chave é crucial. Certifique-se de alinhar verticalmente o *t* em `task` com o *b* em` become`. Quando você estiver mais familiarizado com o Ansible, reserve um tempo e estude um pouco a [Sintaxe YAML](http://docs.ansible.com/ansible/YAMLSyntax.html). - -Nas linhas adicionadas: - - - Começamos a parte das tasks com a palavra-chave `tasks:`. - - - Uma task é nomeada e o módulo da task é referenciado. Aqui ele usa o módulo `yum`. - - - Parâmetros para o módulo são adicionados: - - - `name:` identifica o nome do pacote. - - `state:` para definir o estado desejado do pacote. - -> **Dica** -> -> Os parâmetros do módulo são individuais para cada módulo. Em caso de dúvida, procure-os novamente com `ansible-doc`. + - name: Update all security-related packages + ansible.builtin.dnf: + name: '*' + state: latest + security: true -Salve seu Playbook e saia do Editor. - -## Passo 3 - Rodando o Playbook - -Playbooks são executados usando o comando `ansible-playbook` no nó de controle. Antes de executar um novo Playbook, é uma boa ideia verificar se há erros de sintaxe: - -```bash -[student@ansible ansible-files]$ ansible-playbook --syntax-check apache.yml + - name: Create a new user + ansible.builtin.user: + name: myuser + state: present + create_home: true ``` -Agora você deve estar pronto para executar seu Playbook: +> NOTA: A atualização dos pacotes pode levar alguns minutos antes de o playbook do Ansible ser concluído. -```bash -[student@ansible ansible-files]$ ansible-playbook apache.yml -``` -A saída não deve relatar nenhum erro, e sim fornecer uma visão geral das tasks executadas e uma recapitulação de reprodução resumindo o que foi feito. Há também uma task chamada "Gathering Facts" listada: esta é uma task interna que é executada automaticamente no início de cada Play. Ele coleta informações sobre os nós gerenciados. Os exercícios posteriores abordarão isso com mais detalhes. +* Sobre o módulo `dnf`: Este módulo é usado para gerenciamento de pacotes com DNF (YUM Dandificado) no RHEL e outros sistemas baseados em Fedora. -Use o SSH para garantir que o Apache tenha sido instalado no `node1`. O endereço IP necessário é fornecido no inventário. +* Sobre o módulo `user`: Este módulo é usado para gerenciar contas de usuário. -```bash -[student@ansible ansible-files]$ grep node1 ~/lab_inventory/hosts -node1 ansible_host=11.22.33.44 -[student@ansible ansible-files]$ ssh 11.22.33.44 -student@11.22.33.44's password: -Last login: Wed May 15 14:03:45 2019 from 44.55.66.77 -Managed by Ansible -[student@node1 ~]$ rpm -qi httpd -Name : httpd -Version : 2.4.6 -[...] -``` +### Etapa 3 - Executando o Playbook -Efetue logout do `node1` com o comando `exit` para voltar ao host de controle e verifique o pacote instalado com o comando Ansible ad hoc\! +Execute seu playbook usando o comando `ansible-navigator`: ```bash -[student@ansible ansible-files]$ ansible node1 -m command -a 'rpm -qi httpd' +[student@ansible-1 lab_inventory]$ ansible-navigator run system_setup.yml -m stdout ``` -Execute o Playbook pela segunda vez e compare a saída: A saída mudou de "changed" para "ok" e a cor mudou de amarelo para verde. Além disso, o "PLAY RECAP" é diferente agora. Isso facilita a identificação do que o Ansible realmente fez. - -## Passo 4 - Amplie seu playbook: Apache Start & Enable +Revise a saída para garantir que cada tarefa seja concluída com sucesso. -A próxima parte do Playbook garante que o servidor Apache esteja startado e habilitado no `node1`. - -No host de controle, como seu usuário student, edite o arquivo `~/ansible-files/apache.yml` para adicionar uma segunda task usando o módulo `service`. O Playbook agora deve ficar assim: +### Etapa 4 - Verificando o Playbook +Agora, vamos criar um segundo playbook para verificações pós-configuração, chamado `system_checks.yml`: ```yaml --- -- name: Apache server instalado +- name: System Configuration Checks hosts: node1 - become: yes + become: true tasks: - - name: Ultima versao do apache server instalado - yum: - name: httpd - state: latest - - name: Apache started e enable - service: - name: httpd - enabled: true - state: started -``` + - name: Check user existence + ansible.builtin.command: + cmd: id myuser + register: user_check -Novamente: o que essas linhas fazem é fácil de entender: - - - uma segunda task é criada e nomeada - - - um módulo é especificado (`service`) - - - parâmetros para o módulo são fornecidos - -Assim, com a segunda task, garantimos que o servidor Apache esteja realmente em execução na máquina de destino. Execute seu Playbook estendido: - -```bash -[student@ansible ansible-files]$ ansible-playbook apache.yml -``` - -Observe a saída agora: algumas tasks são mostradas como "ok" em verde e uma é mostrada como "changed" em amarelo. - - - Use um comando Ansible ad hoc novamente para garantir que o Apache tenha sido ativado e iniciado, por exemplo com: `systemctl status httpd`. - - - Execute o Playbook uma segunda vez para se acostumar com a alteração na saída. - -## Passo 5 - Ampliando seu Playbook: Criando um aquivo web.html - -Verifique se as tasks foram executadas corretamente e o Apache está aceitando conexões: faça uma solicitação HTTP usando o módulo `uri` em um comando ad hoc a partir do nó de controle. Certifique-se de substituir **\** pelo IP do nó do inventário. - -> **ATENÇÃO** -> -> **Espere muitas linhas vermelhas e um status 403\!** - -```bash -[student@ansible ansible-files]$ ansible localhost -m uri -a "url=http://" -``` - -Há muitas linhas vermelhas e um erro: Contanto que não haja pelo menos um arquivo `web.html` a ser consumido pelo Apache, ele emitirá um status feio "HTTP Error 403: Forbidden" e o Ansible relatará um erro. - -Então, por que não usar o Ansible para implantar um simples arquivo `web.html` ? Crie o arquivo `~/ansible-files/web.html` no nó de controle: - -```html - -

O Apache esta funcionando bem

- -``` - -Você já usou o módulo `copy` para gravar o texto fornecido na linha de comando em um arquivo. Agora você usará o módulo no seu Playbook para copiar um arquivo: - -No nó de controle, com o seu usuário student, edite o arquivo `~/ansible-files/apache.yml` e adicione uma nova task utilizando o módulo`copy`. Agora deve ficar assim: - -```yaml ---- -- name: Apache server instalado - hosts: node1 - become: yes - tasks: - - name: Ultima versao do apache server instalado - yum: - name: httpd - state: latest - - name: Apache started e enable - service: - name: httpd - enabled: true - state: started - - name: Copiar web.html - copy: - src: ~/ansible-files/web.html - dest: /var/www/html/index.html + - name: Report user status + ansible.builtin.debug: + msg: "Usuário 'myuser' existe." + when: user_check.rc == 0 ``` -Você está se acostumando com a sintaxe do Playbook, então o que acontece? A nova task usa o módulo `copy` e define as opções de origem e destino para a operação de cópia como parâmetros. - -Execute seu Playbook ampliado: +Execute o playbook de verificações: ```bash -[student@ansible ansible-files]$ ansible-playbook apache.yml -``` - - - Observe bem a saída. - - - Execute o comando ad hoc usando o módulo "uri" mais acima novamente para testar o Apache: O comando agora deve retornar uma linha verde "status: 200" amigável, entre outras informações. - -## Passo 6 - Pratique: Aplicar a vários hosts - -Isso foi legal, mas o verdadeiro poder do Ansible é aplicar o mesmo conjunto de tasks de maneira confiável a muitos hosts. - - - Então, que tal mudar o apache.yml Playbook para executar no `node1` **e**` node2` **e** `node3`? - -Como você deve se lembrar, o inventário lista todos os nós como membros do grupo `web`: - -```ini -[web] -node1 ansible_host=11.22.33.44 -node2 ansible_host=22.33.44.55 -node3 ansible_host=33.44.55.66 +[student@ansible-1 lab_inventory]$ ansible-navigator run system_checks.yml -m stdout ``` -> **Dica** -> -> Os endereços IP mostrados aqui são apenas exemplos, seus nós terão diferentes endereços IP. +Revise a saída para garantir que a criação do usuário foi bem-sucedida. -Altere o Playbook para apontar para o grupo "web": - -```yaml --- -- name: Apache server instalado - hosts: web - become: yes - tasks: - - name: Ultima versao do apache server instalado - yum: - name: httpd - state: latest - - name: Apache started e enable - service: - name: httpd - enabled: true - state: started - - name: Copiar web.html - copy: - src: ~/ansible-files/web.html - dest: /var/www/html/index.html -``` - -Agora, execute o playbook: - -```bash -[student@ansible ansible-files]$ ansible-playbook apache.yml -``` +**Navegação** +{% if page.url contains 'ansible_rhel_90' %} +[Exercício Anterior](../2-thebasics) - [Próximo Exercício](../4-variables) +{% else %} +[Exercício Anterior](../1.2-thebasics) - [Próximo Exercício](../1.4-variables) +{% endif %} +

-Por fim, verifique se o Apache está em execução nos dois servidores. Primeiro identifique os endereços IP dos nós no seu inventário e depois use cada um no comando ad hoc com o módulo uri, como já fizemos com o `node1` acima. Todas saídas devem estar verde. +
----- +[Clique aqui para retornar ao Workshop de Ansible para Red Hat Enterprise Linux](../README.md)"" -[Clique aqui para retornar ao Workshop Ansible for Red Hat Enterprise Linux](../README.pt-br.md) diff --git a/exercises/ansible_rhel/1.4-variables/README.es.md b/exercises/ansible_rhel/1.4-variables/README.es.md index c554ef0a4..3e003be87 100644 --- a/exercises/ansible_rhel/1.4-variables/README.es.md +++ b/exercises/ansible_rhel/1.4-variables/README.es.md @@ -1,253 +1,157 @@ -# Workshop - Uso de variables +# Ejercicio de Taller - Uso de Variables -**Leer esto en otros idiomas**: -
![uk](../../../images/uk.png) [English](README.md), ![japan](../../../images/japan.png)[日本語](README.ja.md), ![brazil](../../../images/brazil.png) [Portugues do Brasil](README.pt-br.md), ![france](../../../images/fr.png) [Française](README.fr.md),![Español](../../../images/col.png) [Español](README.es.md). +**Lea esto en otros idiomas**: +
![uk](../../../images/uk.png) [Inglés](README.md), ![japan](../../../images/japan.png) [日本語](README.ja.md), ![brazil](../../../images/brazil.png) [Portugués de Brasil](README.pt-br.md), ![france](../../../images/fr.png) [Francés](README.fr.md), ![Español](../../../images/col.png) [Español](README.es.md). -## Tabla de contenidos +## Índice de Contenidos -* [Objetivos](#Objetivos) -* [Guía](#Guía) -* [Introducción a variables](#Introducción-a-variables) -* [Paso 1 - Crear archivos de variables](#Paso-1---Crear-archivos-de-variables) -* [Paso 2 - Crear archivos index.html](#paso-2---Crear-archivos-indexhtml) -* [Paso 3 - Crear el Playbook](#Paso-3---Crear-el-Playbook) -* [Paso 4 - Prueba el resultado](#Paso-4---Prueba-el-resultado) -* [Paso 5 - Ansible Facts](#Paso-5---Ansible-Facts) -* [Paso 6 - Laboratorios de desafío: Facts](#Paso-6---Laboratorios-de-desafío-Facts) -* [Paso 7 - Uso de Facts en playbooks](#Paso-7---Uso-de-Facts-en-playbooks) +- [Ejercicio de Taller - Uso de Variables](##ejercicio-de-taller---uso-de-variables) + - [Objetivo](#objetivo) + - [Guía](#guía) + - [Paso 1 - Entendiendo las Variables](#paso-1---entendiendo-las-variables) + - [Paso 2 - Sintaxis y Creación de Variables](#paso-2---sintaxis-y-creación-de-variables) + - [Paso 3 - Ejecutando el Playbook Modificado](#paso-3---ejecutando-el-playbook-modificado) + - [Paso 4 - Uso Avanzado de Variables en el Playbook de Verificaciones](#paso-4---uso-avanzado-de-variables-en-el-playbook-de-verificaciones) -# Objetivos -Ansible admite variables para almacenar valores que se pueden utilizar en Playbooks. Las variables se pueden definir en una variedad de lugares y tienen una prioridad clara. Ansible sustituye la variable por su valor cuando se ejecuta una tarea. +## Objetivo +Extendiendo nuestros playbooks del Ejercicio 1.3, el enfoque se centra en la creación y uso de variables en Ansible. Aprenderás la sintaxis para definir y usar variables, una habilidad esencial para crear playbooks dinámicos y adaptables. -Este ejercicio abarca variables, específicamente -- Cómo utilizar los delimitadores de variables `{{` and `}}` -- Qué son los `host_vars` y los `group_vars` y cuándo utilizarlos -- Cómo utilizar `ansible_facts` -- Cómo utilizar el módulo `debug` para imprimir variables en la ventana de la consola +## Guía +Las variables en Ansible son herramientas poderosas para hacer tus playbooks flexibles y reutilizables. Te permiten almacenar y reutilizar valores, haciendo tus playbooks más dinámicos y adaptables. -# Guía +### Paso 1 - Entendiendo las Variables +Una variable en Ansible es una representación nombrada de algún dato. Las variables pueden contener valores simples como cadenas y números, o datos más complejos como listas y diccionarios. -## Introducción a variables +### Paso 2 - Sintaxis y Creación de Variables +La creación y uso de variables involucra una sintaxis específica: -Se hace referencia a las variables en Playbooks colocando el nombre de la variable entre llaves dobles: +1. Definición de Variables: Las variables se definen en la sección `vars` de un playbook o en archivos separados para proyectos más grandes. +2. Nombramiento de Variables: Los nombres de las variables deben ser descriptivos y seguir reglas tales como: + * Comenzar con una letra o un guión bajo. + * Contener solo letras, números y guiones bajos. +3. Uso de Variables: Las variables se referencian en las tareas utilizando las llaves dobles en comillas `"{{ nombre_variable }}"`. Esta sintaxis indica a Ansible que la reemplace con el valor de la variable en tiempo de ejecución. - -```yaml -Here comes a variable {{ variable1 }} -``` - - -Las variables y sus valores se pueden definir en varios lugares: el inventario, archivos adicionales, en la línea de comandos, etc. - -La práctica recomendada para proporcionar variables en el inventario es definirlas en archivos ubicados en dos directorios denominados `host_vars` y `group_vars`: - - - Para definir variables para un grupo llamado "servers", se crea un archivo YAML denominado `group_vars/servers.yml` con las definiciones de variables. - - - Para definir variables específicamente para un host `node1`, se crea el archivo `host_vars/node1.yml` con las definiciones de variables. - -> **Consejo** -> -> Las variables de host tienen prioridad sobre las variables de grupo (puede encontrar más infromación sobre la prioridad en este [documento](https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#variable-precedence-where-should-i-put-a-variable)). - - -## Paso 1 - Crear archivos de variables - -Para la comprensión y la práctica vamos a hacer un laboratorio. Siguiendo el tema "Vamos a crear un servidor web. O dos. O incluso más... ", cambiará el `index.html` para mostrar el entorno de desarrollo (dev/prod) en el que se implementa un servidor. - -En el host de control ansible, como usuario `student`, cree los directorios que contendran las definiciones de variables en `~/ansible-files/`: - -```bash -[student@ansible ansible-files]$ mkdir host_vars group_vars -``` - -Ahora cree dos archivos que contengan definiciones de variables. Definiremos una variable denominada `stage` que apuntará a diferentes entornos, `dev` o `prod`: - - - Cree el archivo `~/ansible-files/group_vars/web.yml` con este contenido: - -```yaml ---- -stage: dev -``` - - Cree el archivo `~/ansible-files/host_vars/node2.yml` con este contenido: +Actualiza el playbook `system_setup.yml` para incluir y usar una variable: ```yaml --- -stage: prod +- name: Basic System Setup + hosts: node1 + become: true + vars: + user_name: 'Roger' + tasks: + - name: Update all security-related packages + ansible.builtin.dnf: + name: '*' + state: latest + security: true + + - name: Create a new user + ansible.builtin.user: + name: "{{ user_name }}" + state: present + create_home: true ``` -¿De qué se trata esto? - - - Para todos los servidores del grupo `web` se define la variable `stage` con el valor `dev`. Por lo tanto, de forma predeterminada los marcamos como miembros del entorno de desarrollo. - - - Para el servidor `node2` esto se anula y el host se marca como un servidor de producción. -## Paso 2 - Crear archivos index.html +Ejecuta este playbook con `ansible-navigator`. -Ahora, cree dos archivos en `~/ansible-files/files/`: +### Paso 3 - Ejecutando el Playbook Modificado -Uno llamado `prod_web.html` con el siguiente contenido: +Ejecuta el playbook actualizado: -```html - -

This is a production webserver, take care!

- +```bash +[student@ansible-1 lab_inventory]$ ansible-navigator run system_setup.yml -m stdout ``` -Y el otro llamado `dev_web.html` con el siguiente contenido: - -```html - -

This is a development webserver, have fun!

- ``` +PLAY [Basic System Setup] ****************************************************** -## Paso 3 - Crear el Playbook - -Ahora necesitas un Playbook que copie el archivo prod o dev `web.html` - de acuerdo con la variable "stage". - -Cree un nuevo Playbook llamado `deploy_index_html.yml` en el directorio '`~/ansible-files/`. - -> **Consejo** -> -> Tenga en cuenta cómo se utiliza la variable "stage" en el nombre del archivo que se va a copiar. +TASK [Gathering Facts] ********************************************************* +ok: [node1] - -```yaml ---- -- name: Copy web.html - hosts: web - become: yes - tasks: - - name: copy web.html - copy: - src: "{{ stage }}_web.html" - dest: /var/www/html/index.html -``` - +TASK [Update all security-related packages] ************************************ +ok: [node1] - - Ejecute el Playbook: +TASK [Create a new user] ******************************************************* +changed: [node1] -```bash -[student@ansible ansible-files]$ ansible-playbook deploy_index_html.yml +PLAY RECAP ********************************************************************* +node1 : ok=3 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 ``` -## Paso 4 - Prueba el resultado +Observa cómo el playbook actualizado muestra un estado de "cambiado" en la tarea de Crear un nuevo usuario. El usuario, ‘Roger’, especificado en la sección vars ha sido creado. -El Playbook debe copiar diferentes archivos como index.html a los hosts, utilice `curl` para probarlo. Compruebe el archivo de inventario de nuevo si olvidó las direcciones IP de los nodos. +Verifica la creación del usuario mediante: ```bash -[student@ansible ansible-files]$ grep node ~/lab_inventory/hosts -node1 ansible_host=11.22.33.44 -node2 ansible_host=22.33.44.55 -node3 ansible_host=33.44.55.66 -[student@ansible ansible-files]$ curl http://11.22.33.44 - -

This is a development webserver, have fun!

- -[student1@ansible ansible-files]$ curl http://22.33.44.55 - -

This is a production webserver, take care!

- -[student1@ansible ansible-files]$ curl http://33.44.55.66 - -

This is a development webserver, have fun!

- +[student@ansible-1 lab_inventory]$ ssh node1 id Roger ``` -> **Consejo** -> -> Si a estas alturas piensas: tiene que haber una manera más inteligente de cambiar el contenido en los archivos... tienes toda la razón. Este laboratorio se hizo para introducir variables, está a punto de aprender acerca de las plantillas en uno de los siguientes capítulos. - -## Paso 5 - Ansible Facts +### Paso 4 - Uso Avanzado de Variables en el Playbook de Verificaciones +Mejora el playbook `system_checks.yml` para verificar la existencia del usuario ‘Roger’ en el sistema utilizando la variable `register` y la declaración condicional `when`. -Los facts de ansible son variables que Ansible detecta automáticamente desde un host administrado. ¿Recuerdas la tarea "Gathering Facts" que aparece en la salida de cada ejecución de `ansible-playbook`? En ese momento se recopilan los facts para cada nodo administrado. Los facts también se pueden extraer mediante el módulo `setup`. Contienen información útil almacenada en variables que los administradores pueden reutilizar. +La palabra clave `register` en Ansible se utiliza para capturar la salida de una tarea y guardarla como una variable. -Para hacerse una idea de los facts que Ansible recopila de forma predeterminada, en el nodo de control como usuario student ejecúte: - -```bash -[student@ansible ansible-files]$ ansible node1 -m setup -``` - -Esto puede ser un poco demasiado, puede utilizar filtros para limitar la salida a ciertos facts, las expresiones son comodines de estilo shell: - -```bash -[student@ansible ansible-files]$ ansible node1 -m setup -a 'filter=ansible_eth0' -``` -O qué pasa con sólo buscar facts relacionados con la memoria: +Actualiza el playbook `system_checks.yml`: -```bash -[student@ansible ansible-files]$ ansible node1 -m setup -a 'filter=ansible_*_mb' +```yaml +--- +- name: System Configuration Checks + hosts: node1 + become: true + vars: + user_name: 'Roger' + tasks: + - name: Check user existence + ansible.builtin.command: + cmd: "id {{ user_name }}" + register: user_check + + - name: Report user status + ansible.builtin.debug: + msg: "El usuario {{ user_name }} existe." + when: user_check.rc == 0 ``` -## Paso 6 - Laboratorios de desafío: Facts +Detalles del Playbook: - - Intente buscar e imprimir la distribución (Red Hat) de los hosts administrados. En una línea, por favor. +* `register: user_check:` Esto captura la salida del comando id en la variable user_check. +* `when: user_check.rc == 0:` Esta línea es una declaración condicional. Verifica si el código de retorno (rc) de la tarea anterior (almacenado en user_check) es 0, lo que indica éxito. El mensaje de depuración solo se mostrará si se cumple esta condición. -> **Consejo** -> -> Utilice grep para encontrar el facts y, a continuación, aplique un filtro para imprimir solo este fact. +Esta configuración proporciona un ejemplo práctico de cómo se pueden usar las variables para controlar el flujo de tareas basado en los resultados de pasos anteriores. -> **Advertencia** -> -> **Solución a continuación\!** +Ejecuta el playbook de verificaciones: ```bash -[student@ansible ansible-files]$ ansible node1 -m setup|grep distribution -[student@ansible ansible-files]$ ansible node1 -m setup -a 'filter=ansible_distribution' -o +[student@ansible-1 lab_inventory]$ ansible-navigator run system_checks.yml -m stdout ``` -## Paso 7 - Uso de Facts en playbooks +Salida: -Los facts se pueden utilizar en un playbook como variables, utilizando el nombre adecuado, por supuesto. Cree este Playbook como `facts.yml` en el directorio `~/ansible-files/`: - - -```yaml ---- -- name: Output facts within a playbook - hosts: all - tasks: - - name: Prints Ansible facts - debug: - msg: The default IPv4 address of {{ ansible_fqdn }} is {{ ansible_default_ipv4.address }} ``` - - -> **Consejo** -> -> El módulo "debug" es útil para, por ejemplo, depurar variables o expresiones. - -Ejecútelo para ver cómo se imprimen los facts: - -```bash -[student@ansible ansible-files]$ ansible-playbook facts.yml - -PLAY [Output facts within a playbook] ****************************************** +PLAY [System Configuration Checks] ********************************************* TASK [Gathering Facts] ********************************************************* -ok: [node3] -ok: [node2] ok: [node1] -ok: [ansible] - -TASK [Prints Ansible facts] **************************************************** -ok: [node1] => - msg: The default IPv4 address of node1 is 172.16.190.143 -ok: [node2] => - msg: The default IPv4 address of node2 is 172.16.30.170 -ok: [node3] => - msg: The default IPv4 address of node3 is 172.16.140.196 -ok: [ansible] => - msg: The default IPv4 address of ansible is 172.16.2.10 + +TASK [Check user existence] **************************************************** +changed: [node1] + +TASK [Report user status] ****************************************************** +ok: [node1] => { + "msg": "El usuario Roger existe." +} PLAY RECAP ********************************************************************* -ansible : ok=2 changed=0 unreachable=0 failed=0 -node1 : ok=2 changed=0 unreachable=0 failed=0 -node2 : ok=2 changed=0 unreachable=0 failed=0 -node3 : ok=2 changed=0 unreachable=0 failed=0 +node1 : ok=3 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 ``` ----- +Revisa la salida para confirmar que la verificación de la existencia del usuario está utilizando correctamente la variable y la lógica condicional. +--- **Navegación**
-[Ejercicio anterior](../1.3-playbook/README.es.md) - [Próximo Ejercicio](../1.5-handlers/README.es.md) -[Haga clic aquí para volver al Taller Ansible for Red Hat Enterprise Linux](../README.md#section-1---ansible-engine-exercises) +[Ejercicio Anterior](../1.3-playbook/README.es.md) - [Siguiente Ejercicio](../1.5-handlers/README.es.md) +

+[Haz clic aquí para volver al Taller de Ansible para Red Hat Enterprise Linux](../README.md)" diff --git a/exercises/ansible_rhel/1.4-variables/README.fr.md b/exercises/ansible_rhel/1.4-variables/README.fr.md index 1d3db446a..e16f4ad43 100644 --- a/exercises/ansible_rhel/1.4-variables/README.fr.md +++ b/exercises/ansible_rhel/1.4-variables/README.fr.md @@ -1,353 +1,158 @@ -# Exercice - Utilisation des variables +# Exercice de l'atelier - Utilisation des Variables -**Lisez ceci dans d'autres langues**: -
![uk](../../../images/uk.png) [English](README.md), ![japan](../../../images/japan.png)[日本語](README.ja.md), ![brazil](../../../images/brazil.png) [Portugues do Brasil](README.pt-br.md), ![france](../../../images/fr.png) [Français](README.fr.md),![Español](../../../images/col.png) [Español](README.es.md). +**Lire ceci dans d'autres langues** : +
![uk](../../../images/uk.png) [Anglais](README.md), ![japan](../../../images/japan.png) [日本語](README.ja.md), ![brazil](../../../images/brazil.png) [Portugais du Brésil](README.pt-br.md), ![france](../../../images/fr.png) [Français](README.fr.md), ![Español](../../../images/col.png) [Espagnol](README.es.md). -## Table des matières +## Table des Matières -* [Objectif](#objectif) -* [Guide](#guide) -* [Introduction aux variables](#introduction-aux-variables) -* [Étape 1 - Création des fichiers de variables](#Étape-1---Création-des-fichiers-de-variables) -* [Étape 2 - Création des fichiers html](#Étape-2---Création-des-fichiers-html) -* [Étape 3 - Création du Playbook](#Étape-3---Création-du-playbook) -* [Étape 4 - Teste du résultat](#Étape-4---teste-du-résultat) -* [Étape 5 - Les Faits Ansible](#Étape-5---les-faits-ansible) -* [Étape 6 - Défi: Les faits](#Étape-6---défi-les-faits) -* [Étape 7 - Utilisation des faits dans un playbook](#Étape-7---utilisation-des-faits-dans-un-playbook) +- [Exercice de l'atelier - Utilisation des Variables](##exercice-de-l'atelier---utilisation-des-variables) + - [Objectif](#objectif) + - [Guide](#guide) + - [Étape 1 - Comprendre les Variables](#étape-1---comprendre-les-variables) + - [Étape 2 - Syntaxe et Création de Variables](#étape-2---syntaxe-et-création-de-variables) + - [Étape 3 - Exécution du Playbook Modifié](#étape-3---exécution-du-playbook-modifié) + - [Étape 4 - Utilisation Avancée des Variables dans le Playbook de Vérifications](#étape-4---utilisation-avancée-des-variables-dans-le-playbook-de-vérifications) -# Objectif - -Ansible prend en charge des variables pour stocker des valeurs pouvant être utilisées dans Playbooks. Les variables peuvent être définies à divers endroits et ont une précédence claire. Ansible remplace la variable par sa valeur lorsqu'une tâche est exécutée. - -Cet exercice couvre des variables, en particulier -* Comment utiliser les délimiteurs de variables `{{` et `}}` -* Qu'est-ce que `host_vars` et `group_vars` et quand les utiliser -* Comment utiliser `ansible_facts` -* Comment utiliser le module `debug` pour imprimer des variables dans la fenêtre de la console +## Objectif +Prolongeant nos playbooks de l'Exercice 1.3, l'accent est mis sur la création et l'utilisation de variables dans Ansible. Vous apprendrez la syntaxe pour définir et utiliser les variables, une compétence essentielle pour créer des playbooks dynamiques et adaptables. ## Guide +Les variables dans Ansible sont des outils puissants pour rendre vos playbooks flexibles et réutilisables. Elles vous permettent de stocker et de réutiliser des valeurs, rendant vos playbooks plus dynamiques et adaptables. -### Introduction aux variables - -Les variables sont référencées dans les Playbooks en plaçant le nom de la variable entre deux accolades: - - - -```yaml -Here comes a variable {{ variable1 }} -``` - - - -Les variables et leurs valeurs peuvent être définies à différents endroits: l'inventaire, les fichiers supplémentaires, sur la ligne de commande, etc. - -La pratique recommandée pour fournir des variables dans l'inventaire est de les définir dans des fichiers situés dans deux répertoires nommés `host_vars` et `group_vars`: -* Pour définir des variables pour un groupe `serveurs`, utilisez un fichier YAML nommé `group_vars/servers.yml` pour la définitions des variables. -* Pour définir des variables spécifiquement pour un hôte `node1`, utilisez le fichier `host_vars/node1.yml` pour la définition des variables. - -> **Astuce** -> -> Les variables hôtes ont priorité sur les variables de groupe (plus d'informations sur la priorité peuvent être trouvées dans la [documentation](https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#variable-precedence-where-should-i-put-a-variable). - -### Step 1 - Création des fichiers de variables - -Pour comprendre et pratiquer, faisons un exercice. Dans le prolongement du thème "Construisons un serveur Web. Ou deux. Ou même plus ...", vous allez changer le `index.html` pour montrer l'environnement de développement (dev/prod) dans lequel un serveur est déployé. - -Sur l'hôte de contrôle Ansible, en tant qu'utilisateur `student`, créez les répertoires pour contenir les définitions des variables dans `~/ansible-files/`: - -```bash -[student@ansible-1 ansible-files]$ mkdir host_vars group_vars -``` - -Créez maintenant deux fichiers contenant des définitions de variables. Nous allons définir une variable nommée `stage` qui pointera vers différents environnements, `dev` ou `prod`: - -* Créez le fichier `~/ansible-files/group_vars/web.yml` avec ce contenu: - -```yaml ---- -stage: dev -``` - -* Créez le fichier `~/ansible-files/host_vars/node2.yml` avec ce contenu: - -```yaml ---- -stage: prod -``` - -De quoi s'agit-il ? - -* Pour tous les serveurs du groupe `web`, la variable `stage` avec la valeur `dev` est définie. Donc, par défaut, nous les signalons comme membres de l'environnement de développement. -* Pour le serveur `node2`, la declaration ci-dessus est remplacé et l'hôte est marqué comme serveur de production. - -### Step 2 - Création des fichiers html - -Créez maintenant deux fichiers dans `~/ansible-files/files/`: - -L'un appelé `prod_web.html` avec le contenu suivant: - -```html - -

This is a production webserver, take care!

- -``` - -Et l'autre appelé `dev_web.html` avec comme contenu: - -```html - -

This is a development webserver, have fun!

- -``` +### Étape 1 - Comprendre les Variables +Une variable dans Ansible est une représentation nommée de certaines données. Les variables peuvent contenir des valeurs simples comme des chaînes de caractères et des nombres, ou des données plus complexes comme des listes et des dictionnaires. -### Step 3 - Création du Playbook +### Étape 2 - Syntaxe et Création de Variables +La création et l'utilisation de variables impliquent une syntaxe spécifique : -Vous avez maintenant besoin d'un Playbook qui copie le fichier prod ou dev `web.html` - selon la variable "stage". +1. Définition des Variables : Les variables sont définies dans la section `vars` d'un playbook ou dans des fichiers séparés pour les projets plus importants. +2. Nomination des Variables : Les noms de variables doivent être descriptifs et respecter des règles telles que : + * Commencer par une lettre ou un souligné. + * Ne contenir que des lettres, des chiffres et des soulignés. +3. Utilisation des Variables : Les variables sont référencées dans les tâches en utilisant les doubles accolades entre guillemets `"{{ nom_variable }}"`. Cette syntaxe indique à Ansible de la remplacer par la valeur de la variable au moment de l'exécution. -Créez un nouveau Playbook appelé `deploy_index_html.yml` dans le répertoire `~/ansible-files/`. - -> **Astuce** -> -> Notez comment la variable "stage" est utilisée dans le nom du fichier à copier. - - +Mettez à jour le playbook `system_setup.yml` pour inclure et utiliser une variable : ```yaml --- -- name: Copy web.html - hosts: web +- name: Basic System Setup + hosts: node1 become: true + vars: + user_name: 'Roger' tasks: - - name: copy web.html - ansible.builtin.copy: - src: "{{ stage }}_web.html" - dest: /var/www/html/index.html -``` - - + - name: Update all security-related packages + ansible.builtin.dnf: + name: '*' + state: latest + security: true -* Lancez le Playbook: - -```bash -[student@ansible-1 ansible-files]$ ansible-navigator run deploy_index_html.yml + - name: Create a new user + ansible.builtin.user: + name: "{{ user_name }}" + state: present + create_home: true ``` -### Step 4 - Testez le résultat +Exécutez ce playbook avec `ansible-navigator`. -Le Playbook Ansible copie différents fichiers index.html sur les hôtes, utilisez `curl` pour le tester. +### Étape 3 - Exécution du Playbook Modifié -Pour node1: +Exécutez le playbook mis à jour : ```bash -[student@ansible-1 ansible-files]$ curl http://node1 - -

This is a development webserver, have fun!

- +[student@ansible-1 lab_inventory]$ ansible-navigator run system_setup.yml -m stdout ``` -Pour node2: - -```bash -[student@ansible-1 ansible-files]$ curl http://node2 - -

This is a production webserver, take care!

- ``` +PLAY [Basic System Setup] ****************************************************** -Pour node3: - -```bash -[student@ansible-1 ansible-files]$ curl http://node3 - -

This is a development webserver, have fun!

- -``` - -> **Astuce** -> -> Si vous êtes en train de penser: il doit y avoir un moyen plus intelligent de modifier le contenu des fichiers… vous avez absolument raison. Cet exercice a été fait pour introduire les variables, vous êtes sur le point d'en apprendre davantage sur les modèles dans l'un des chapitres suivants. - -### Step 5 - Les Faits Ansible - -Les faits Ansible sont des variables qui sont automatiquement découvertes par Ansible sur un hôte géré. Vous souvenez-vous de la tâche "Gathering Facts" répertoriée dans la sortie de chaque exécution de `ansible-navigator`? À ce moment, les Faits sont collectés pour chaque noeud géré. Les Faits peuvent également être collectés par le module `setup`. Ils contiennent des informations utiles stockées dans des variables que les administrateurs peuvent réutiliser. - -Pour avoir une idée des Faits collectés par défaut par Ansible, sur votre noeud de contrôle avec votre utilisateur `student`, lancez le Playbook suivant pour obtenir les détails de `setup` sur `node1`: - -```yaml ---- -- name: Capture Setup - hosts: node1 +TASK [Gathering Facts] ********************************************************* +ok: [node1] - tasks: +TASK [Update all security-related packages] ************************************ +ok: [node1] - - name: Collect only facts returned by facter - ansible.builtin.setup: - gather_subset: - - 'all' - register: setup +TASK [Create a new user] ******************************************************* +changed: [node1] - - ansible.builtin.debug: - var: setup +PLAY RECAP ********************************************************************* +node1 : ok=3 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 ``` -```bash -[student@ansible-1 ansible-files]$ cd ~ -[student@ansible-1 ~]$ ansible-navigator run setup.yml -m stdout -``` +Remarquez comment le playbook mis à jour montre un statut de changement dans la tâche Créer un nouvel utilisateur. L'utilisateur, ‘Roger’, spécifié dans la section vars a été créé. -C'est peut être un peu trop d'information, vous pouvez utiliser des filtres pour limiter la sortie à certains faits, l'expression est un caractère wildcard de style shell dans votre Playbook. Créez un Playbook intitulé `setup_filter.yml` comme indiqué ci-dessous. Dans cet exemple, on filtre pour obtenir les Faits `eth0` ainsi que le détail sur la mémoire de `node1`. - -```yaml ---- -- name: Capture Setup - hosts: node1 - - tasks: - - - name: Collect only specific facts - ansible.builtin.setup: - filter: - - 'ansible_eth0' - - 'ansible_*_mb' - register: setup - - - debug: - var: setup -``` +Vérifiez la création de l'utilisateur via : ```bash -[student@ansible-1 ansible-files]$ ansible-navigator run setup_filter.yml -m stdout +[student@ansible-1 lab_inventory]$ ssh node1 id Roger ``` -### Step 6 - Défi: Les Faits - -* Essayez de trouver et d'imprimer la distribution (Red Hat) de vos hôtes gérés en utilisant un playbook. +### Étape 4 - Utilisation Avancée des Variables dans le Playbook de Vérifications +Améliorez le playbook `system_checks.yml` pour vérifier l'utilisateur ‘Roger’ dans le système en utilisant la variable `register` et la déclaration conditionnelle `when`. -> **Astuce** -> -> Utilisez un caractère wildcard pour trouver le Fait dans votre filtre, puis appliquez un filtre pour imprimer uniquement ce fait. +Le mot-clé `register` dans Ansible est utilisé pour capturer la sortie d'une tâche et la sauvegarder en tant que variable. -> **Avertissement ** -> -> **Solution ci-dessous \!** +Mettez à jour le playbook `system_checks.yml` : ```yaml --- -- name: Capture Setup +- name: System Configuration Checks hosts: node1 - + become: true + vars: + user_name: 'Roger' tasks: + - name: Check user existence + ansible.builtin.command: + cmd: "id {{ user_name }}" + register: user_check - - name: Collect only specific facts - ansible.builtin.setup: - filter: - - '*distribution' - register: setup - - - ansible.builtin.debug: - var: setup + - name: Report user status + ansible.builtin.debug: + msg: "L'utilisateur {{ user_name }} existe." + when: user_check.rc == 0 ``` -Avec le caractère wildcard, la sortie montre: +Détails du Playbook : -```bash +* `register: user_check:` Cela capture la sortie de la commande id dans la variable user_check. +* `when: user_check.rc == 0:` Cette ligne est une déclaration conditionnelle. Elle vérifie si le code de retour (rc) de la tâche précédente (stockée dans user_check) est 0, indiquant le succès. Le message de débogage ne sera affiché que si cette condition est remplie. -TASK [debug] ******************************************************************* -ok: [ansible] => { - "setup": { - "ansible_facts": { - "ansible_distribution": "RedHat" - }, - "changed": false, - "failed": false - } -} -``` +Cette configuration fournit un exemple pratique de la manière dont les variables peuvent être utilisées pour contrôler le flux des tâches en fonction des résultats des étapes précédentes. -Avec ceci, on peut conclure que la variable qu'on cherche est intitulée `ansible_distribution`. - -On peut maintenant mettre à jour le playbook pour être explicite dans sa recherche et changer la ligne suivante: - -```yaml -filter: -- '*distribution' -``` - -en: - -```yaml -filter: -- 'ansible_distribution' -``` +Exécutez le playbook de vérifications : ```bash -[student@ansible-1 ansible-files]$ ansible-navigator run setup_filter.yml -m stdout -``` - -### Step 7 - Utilisation des Faits dans un Playbook - -Les faits peuvent être utilisés dans un Playbook comme des variables, en utilisant le bon nom, bien sûr. Créez ce Playbook nommé `facts.yml` dans le répertoire `~/ansible-files/`: - - - -```yaml ---- -- name: Output facts within a playbook - hosts: all - tasks: - - name: Prints Ansible facts - ansible.builtin.debug: - msg: The default IPv4 address of {{ ansible_fqdn }} is {{ ansible_default_ipv4.address }} +[student@ansible-1 lab_inventory]$ ansible-navigator run system_checks.yml -m stdout ``` - - -> **Astuce** -> -> Le module "debug" peut être pratique pour débugger les variables ou expressions. +Sortie : -Exécutez-le pour voir comment les faits sont affichés: - -```bash -[student@ansible-1 ansible-files]$ ansible-navigator run facts.yml ``` - -Dans l'interface texte (TUI), tapez `:st` pour capturer la sortie suivante: - -```bash -PLAY [Output facts within a playbook] ****************************************** +PLAY [System Configuration Checks] ********************************************* TASK [Gathering Facts] ********************************************************* -ok: [node3] -ok: [node2] ok: [node1] -ok: [ansible-1] - -TASK [Prints Ansible facts] **************************************************** -ok: [node1] => - msg: The default IPv4 address of node1 is 172.16.190.143 -ok: [node2] => - msg: The default IPv4 address of node2 is 172.16.30.170 -ok: [node3] => - msg: The default IPv4 address of node3 is 172.16.140.196 -ok: [ansible-1] => - msg: The default IPv4 address of ansible is 172.16.2.10 + +TASK [Check user existence] **************************************************** +changed: [node1] + +TASK [Report user status] ****************************************************** +ok: [node1] => { + "msg": "L'utilisateur Roger existe." +} PLAY RECAP ********************************************************************* -ansible-1 : ok=2 changed=0 unreachable=0 failed=0 -node1 : ok=2 changed=0 unreachable=0 failed=0 -node2 : ok=2 changed=0 unreachable=0 failed=0 -node3 : ok=2 changed=0 unreachable=0 failed=0 +node1 : ok=3 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 ``` +Examinez la sortie pour confirmer que la vérification de l'existence de l'utilisateur utilise correctement la variable et la logique conditionnelle. --- **Navigation**
-{% if page.url contains 'ansible_rhel_90' %} -[Exercise précédent](../3-playbook/README.fr.md) - [Exercise suivant](../5-surveys/README.fr.md) -{% else %} -[Exercise précédent](../1.3-playbook/README.fr.md) - [Exercise suivant](../1.5-handlers/README.fr.md) -{% endif %} +[Exercice Précédent](../1.3-playbook/README.fr.md) - [Prochain Exercice](../1.5-handlers/README.fr.md)

+[Cliquez ici pour retourner à l'atelier Ansible pour Red Hat Enterprise Linux](../README.md)" + diff --git a/exercises/ansible_rhel/1.4-variables/README.ja.md b/exercises/ansible_rhel/1.4-variables/README.ja.md index 7532137bf..f3ea40bb1 100644 --- a/exercises/ansible_rhel/1.4-variables/README.ja.md +++ b/exercises/ansible_rhel/1.4-variables/README.ja.md @@ -1,356 +1,151 @@ -# ワークショップ演習 - 変数の使用 +# ワークショップの演習 - 変数の使用 -**他の言語でもお読みいただけます**: -
![uk](../../../images/uk.png) [English](README.md)、![japan](../../../images/japan.png)[日本語](README.ja.md)、![brazil](../../../images/brazil.png) [Portugues do Brasil](README.pt-br.md)、![france](../../../images/fr.png) [Française](README.fr.md)、![Español](../../../images/col.png) [Español](README.es.md) +**他の言語で読む**: +
![uk](../../../images/uk.png) [英語](README.md), ![japan](../../../images/japan.png)[日本語](README.ja.md), ![brazil](../../../images/brazil.png) [ブラジルのポルトガル語](README.pt-br.md), ![france](../../../images/fr.png) [フランス語](README.fr.md), ![Español](../../../images/col.png) [スペイン語](README.es.md). ## 目次 -* [目的](#目的) -* [ガイド](#ガイド) -* [変数の概要](#変数の概要) - * [ステップ 1 - 変数ファイルの作成](#ステップ-1---変数ファイルの作成) - * [ステップ 2 - web.html ファイルの作成](#ステップ-2---webhtml-ファイルの作成) - * [ステップ 3 - Playbook の作成](#ステップ-3---playbook-の作成) - * [ステップ 4 - 結果のテスト](#ステップ-4---結果のテスト) - * [ステップ 5 - Ansible ファクト](#ステップ-5---ansible-ファクト) - * [ステップ 6 - チャレンジラボ: ファクト](#ステップ-6---チャレンジラボ-ファクト) - * [ステップ 7 - Playbook でのファクトの使用](#ステップ-7---playbook-でのファクトの使用) +- [ワークショップの演習 - 変数の使用](##ワークショップの演習---変数の使用) + - [目的](#目的) + - [ガイド](#ガイド) + - [ステップ 1 - 変数の理解](#ステップ-1---変数の理解) + - [ステップ 2 - 変数の構文と作成](#ステップ-2---変数の構文と作成) + - [ステップ 3 - 変更されたプレイブックの実行](#ステップ-3---変更されたプレイブックの実行) + - [ステップ 4 - チェックプレイブックでの高度な変数の使用](#ステップ-4---チェックプレイブックでの高度な変数の使用) ## 目的 - -Ansibleは、Playbook で使用できる値を格納するための変数をサポートしています。変数はさまざまな場所で定義でき、明確な優先順位があります。Ansible は、タスクの実行時に変数をその値に置き換えます。 - -この演習では、特に以下についての変数について説明します。 - -* 変数区切り文字 `{{`や `}}` の使用方法 -* `host_vars` と `group_vars` について、また使用するとき -* `ansible_facts` の使い方 -* `debug` モジュールを使用して、コンソールウィンドウに変数を出力する方法 +演習 1.3 からのプレイブックを拡張し、Ansible での変数の作成と使用に焦点を当てます。変数を定義し、使用するための構文を学び、動的で適応可能なプレイブックを作成するための不可欠なスキルを習得します。 ## ガイド +Ansible の変数は、プレイブックを柔軟で再利用可能にする強力なツールです。値を保存して再利用することができ、プレイブックをより動的で適応可能にします。 -### 変数の概要 - -変数は、変数名を二重中括弧で囲むことにより、AnsiblePlaybooks で参照されます。 - - - -```yaml -こちらが変数です。{{ variable1 }} -``` - - - -変数とその値は、インベントリー、追加ファイル、コマンドラインなどのさまざまな場所で定義できます。 - -インベントリーで変数を使う場合は、`host_vars` と `group_vars` という名前の 2 つのディレクトリーにあるファイルで変数を定義することが推奨されます。 - -* グループ「servers」の変数を定義するために、変数定義のある `group_vars/servers.yml` という YAML ファイルが作成されます。 -* ホスト `node1` 専用の変数を定義するために、変数定義のある `host_vars/node1.yml` ファイルが作成されます。 - -> **ヒント** -> -> ホスト変数はグループ変数よりも優先されます (優先順位の詳細については、[docs](https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#variable-precedence-where-should-i-put-a-variable) を参照してください)。 - -### ステップ 1 - 変数ファイルの作成 +### ステップ 1 - 変数の理解 +Ansible での変数は、あるデータの名前付き表現です。変数には、文字列や数値のような単純な値や、リストや辞書のような複雑なデータを含めることができます。 -理解を深め練習するためにも、ラボをみていきましょう。「Webサーバーを構築しましょう。1 つまたは 2 つ。またはそれ以上…」というテーマに続いて、`index.html` を変更し、サーバーがデプロイされている開発環境 (dev / prod)を表示します。 +### ステップ 2 - 変数の構文と作成 +変数の作成と使用には、特定の構文が関与します： -Ansible コントロールホストでは、`student` ユーザーとして、`~/ansible-files/` に変数定義を保持するディレクトリーを作成します。 +1. 変数の定義：変数は、プレイブックの `vars` セクションや、大規模なプロジェクトのための別々のファイルで定義されます。 +2. 変数名の命名：変数名は説明的であるべきで、以下のようなルールに従うべきです： + * 文字またはアンダースコアで始まること。 + * 文字、数字、アンダースコアのみを含むこと。 +3. 変数の使用：タスク内で変数は `"{{ variable_name }}"` というダブルカーリーブレイスを引用符で囲んで参照されます。この構文は、実行時に Ansible に変数の値で置き換えるよう指示します。 -```bash -[student@ansible-1 ansible-files]$ mkdir host_vars group_vars -``` - -次に、変数定義を含む 2 つのファイルを作成します。異なる環境 `dev` または `prod` を参照する `stage` を定義します。 - -* 以下の内容で `~/ansible-files/group_vars/web.yml` ファイルを作成します。 - -```yaml ---- -stage: dev -``` - -* 以下の内容で `~/ansible-files/host_vars/node2.yml` ファイルを作成します。 +`system_setup.yml` プレイブックを更新して、変数を含めて使用します： ```yaml --- -stage: prod -``` - -これはなんでしょうか。 - -* `web` グループのサーバーすべてには、値 `dev` を持つ `stage` が定義されています。そのため、デフォルトでは、開発環境のメンバーとしてフラグを立てます。 -* サーバー `node2` については、これはオーバーライドされ、ホストは実稼働サーバーとしてフラグが立てられます。 - -### ステップ 2 - web.html ファイルの作成 - -次に、`~/ansible-files/files/` で 2 つのファイルを作成します。 - -1 つは、以下の内容の `prod_web.html` と呼ばれます。 - -```html - -

これは稼働 Web サーバーです。それでは！

- -``` - -もう 1 つは、以下のない用の `dev_web.html` と呼ばれるファイルです。 - -```html - -

これは開発用ウェブサーバーです。お楽しみください！

- -``` - -### ステップ 3 - Playbook の作成 - -次に、「stage」変数にしたがって、prod または dev `web.html` ファイルをコピーする Playbook が必要です。 - -`~/ansible-files/` ディレクトリーに `deploy_index_html.yml` という新しい Playbook を作成します。 - -> **ヒント** -> -> 変数「stage」がどのように、コピーするファイルの名前で使用さているかに注意してください。 - - - -```yaml ---- -- name: Copy web.html - hosts: web +- name: 基本的なシステムセットアップ + hosts: node1 become: true + vars: + user_name: 'Roger' tasks: - - name: copy web.html - copy: - src: "{{ stage }}_web.html" - dest: /var/www/html/index.html -``` - - - -* Playbook を実行します。 + - name: セキュリティ関連のパッケージをすべて更新する + ansible.builtin.dnf: + name: '*' + state: latest + security: true -```bash -[student@ansible-1 ansible-files]$ ansible-navigator run deploy_index_html.yml + - name: 新しいユーザーを作成する + ansible.builtin.user: + name: "{{ user_name }}" + state: present + create_home: true ``` -### ステップ 4 - 結果のテスト - -Ansible Playbook は、さまざまなファイルを index.html としてホストにコピーし、`curl` を使用してテストします。 - -node1: +"`ansible-navigator`を使用してこのプレイブックを実行してください。 -```bash -[student@ansible-1 ansible-files]$ curl http://node1 - -

This is a development webserver, have fun!

- -``` - -node2: - -```bash -[student@ansible-1 ansible-files]$ curl http://node2 - -

This is a production webserver, take care!

- -``` +### ステップ 3 - 修正されたプレイブックの実行 -node3: +更新されたプレイブックを実行します: ```bash -[student@ansible-1 ansible-files]$ curl http://node3 - -

This is a development webserver, have fun!

- +[student@ansible-1 lab_inventory]$ ansible-navigator run system_setup.yml -m stdout ``` -> **ヒント** -> -> おそらくこのような考えがありませんでしょうか。ファイルの内容を変更する、もっと賢い方法があるはず...。その通りです。このラボは、変数の説明を行うためのものでした。次の章では、テンプレートについて学びます。 - -### ステップ 5 - Ansible ファクト - -Ansible ファクトは、管理対象ホストから Ansible によって自動的に検出される変数です。それぞれの `ansible-navigator` 実行の出力にリストされている「ファクトの収集」タスクを覚えていますか？その時点で、管理対象ノードごとにファクトが収集されます。ファクトは、`setup` モジュールでプルできます。これらには、管理者が再利用できる変数に格納された有用な情報が含まれています。 - -Ansible がデフォルトで収集する情報を把握するために、学習者ユーザーとしてコントロールノード上で以下の Playbook を実行し、`node1` のセットアップの詳細を確認します。 - ```yaml ---- -- name: Capture Setup - hosts: node1 - - tasks: - - - name: Collect only facts returned by facter - ansible.builtin.setup: - gather_subset: - - 'all' - register: setup - - - debug: - var: setup -``` - -```bash -[student@ansible-1 ansible-files]$ cd ~ -[student@ansible-1 ~]$ ansible-navigator run setup.yml -m stdout -``` +PLAY [基本システム設定] ****************************************************** -これはビットが大きすぎる可能性があり、フィルターを使用して出力を特定のファクトに制限することができます。式は Playbook 内でシェルスタイルのワイルドカードです。この例では、`setup_filter.yml` というラベルが付けられた Playbook を作成します。この例では、`eth0` ファクトを取得し、`node1` のメモリー詳細を取得するようにフィルターします。 - -```yaml ---- -- name: Capture Setup - hosts: node1 +TASK [事実の収集] ********************************************************* +ok: [node1] - tasks: +TASK [すべてのセキュリティ関連のパッケージを更新する] ************************************ +ok: [node1] - - name: Collect only specific facts - ansible.builtin.setup: - filter: - - 'ansible_eth0' - - 'ansible_*_mb' - register: setup +TASK [新しいユーザーを作成] ******************************************************* +changed: [node1] - - debug: - var: setup +PLAY RECAP ********************************************************************* +node1 : ok=3 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 ``` -```bash -[student@ansible-1 ansible-files]$ ansible-navigator run setup_filter.yml -m stdout -``` +更新されたプレイブックで「新しいユーザーを作成」タスクのステータスが変更されたことに注目してください。varsセクションに指定されたユーザー「Roger」が作成されました。 -### ステップ 6 - チャレンジラボ: ファクト +ユーザー作成を確認するには: -* 管理対象ホストのディストリビューション (Red Hat) の検索と出力を試行します。これは Playbook で行います。 +ステップ 4 - チェックプレイブック内の高度な変数使用 +system_checks.ymlプレイブックを強化して、register変数とwhen条件文を使用し、システム内の「Roger」ユーザーの存在を確認します。 -> **ヒント** -> -> フィルター内でワイルドカードを使用してファクトを検索し、フィルターを適用して、このファクトのみを出力します。 +Ansibleのregisterキーワードは、タスクの出力をキャプチャして変数に保存するために使用されます。 -> **警告** -> -> **回答を以下に示します。** +`system_checks.yml` プレイブックを更新します: ```yaml --- -- name: Capture Setup +- name: システム設定チェック hosts: node1 - + become: true + vars: + user_name: 'Roger' tasks: + - name: ユーザー存在チェック + ansible.builtin.command: + cmd: "id {{ user_name }}" + register: user_check - - name: Collect only specific facts - ansible.builtin.setup: - filter: - - '*distribution' - register: setup - - - debug: - var: setup + - name: ユーザー状態の報告 + ansible.builtin.debug: + msg: "ユーザー {{ user_name }} は存在します。" + when: user_check.rc == 0 ``` -ワイルドカードが導入されると、出力は以下のようになります。 +プレイブックの詳細: -```bash +* `register: user_check:` これはidコマンドの出力を変数user_checkにキャプチャします。 -TASK [debug] ******************************************************************* -ok: [ansible] => { - "setup": { - "ansible_facts": { - "ansible_distribution": "RedHat" - }, - "changed": false, - "failed": false - } -} -``` - -これにより、検索する変数に `ansible_distribution` というラベルが付けられます。 - -次に、Playbook を更新して、検索で明示的な指定を行い、以下の行を変更できます。 - -```yaml -filter: -- '*distribution' -``` +* `when: user_check.rc == 0:` この行は条件文です。これは、前のタスクの戻り値（user_checkに保存されています）が0であるかどうかをチェックし、成功を示します。この条件が満たされると、デバッグメッセージが表示されます。 +この設定は、前のステップの結果に基づいてタスクの流れを制御するために変数を使用する方法の実用的な例を提供します。 -以下のように変更します。 - -```yaml -filter: -- 'ansible_distribution' -``` +チェックプレイブックを実行します: ```bash -[student@ansible-1 ansible-files]$ ansible-navigator run setup_filter.yml -m stdout +[student@ansible-1 lab_inventory]$ ansible-navigator run system_checks.yml -m stdout ``` -### ステップ 7 - Playbook でのファクトの使用 - -もちろん、ファクトは、正しい名前を使用して、変数のように Playbook で使用できます。このプレイブックを次のように、`~/ansible-files/` ディレクトリーに `facts.yml` として作成します。 - - - -```yaml ---- -- name: Output facts within a playbook - hosts: all - tasks: - - name: Prints Ansible facts - debug: - msg: The default IPv4 address of {{ ansible_fqdn }} is {{ ansible_default_ipv4.address }} -``` - - - -> **ヒント** -> -> 「debug」モジュールは、変数と式のデバッグを行うのに便利です。 - -それを実行して、ファクトがどのように出力されるかを確認します。 - ```bash -[student@ansible-1 ansible-files]$ ansible-navigator run facts.yml -``` +PLAY [システム設定チェック] ********************************************* -テキストユーザーインターフェース(TUI)ウィンドウ内で、以下の出力をキャプチャーするために `:st` と入力します。 +TASK [事実の収集] ********************************************************* +ok: [node1] -```bash -PLAY [Output facts within a playbook] ****************************************** +TASK [ユーザー存在チェック] **************************************************** +changed: [node1] -TASK [Gathering Facts] ********************************************************* -ok: [node3] -ok: [node2] -ok: [node1] -ok: [ansible-1] - -TASK [Prints Ansible facts] **************************************************** -ok: [node1] => - msg: The default IPv4 address of node1 is 172.16.190.143 -ok: [node2] => - msg: The default IPv4 address of node2 is 172.16.30.170 -ok: [node3] => - msg: The default IPv4 address of node3 is 172.16.140.196 -ok: [ansible-1] => - msg: The default IPv4 address of ansible is 172.16.2.10 +TASK [ユーザー状態の報告] ****************************************************** +ok: [node1] => { + "msg": "ユーザー Roger は存在します。" +} PLAY RECAP ********************************************************************* -ansible-1 : ok=2 changed=0 unreachable=0 failed=0 -node1 : ok=2 changed=0 unreachable=0 failed=0 -node2 : ok=2 changed=0 unreachable=0 failed=0 -node3 : ok=2 changed=0 unreachable=0 failed=0 +node1 : ok=3 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 ``` --- **ナビゲーション**
-{% if page.url contains 'ansible_rhel_90' %} -[Previous Exercise](../3-playbook) - [Next Exercise](../5-surveys) -{% else %} -[Previous Exercise](../1.3-playbook) - [Next Exercise](../1.5-handlers) -{% endif %} +[前のエクササイズ](../1.3-playbook/README.ja.md) -[次のエクササイズ](../1.5-handlers/README.ja.md)

-[Click here to return to the Ansible for Red Hat Enterprise Linux Workshop](../README.md) +[Ansible for Red Hat Enterprise Linux ワークショップに戻る](../README.md) + diff --git a/exercises/ansible_rhel/1.4-variables/README.md b/exercises/ansible_rhel/1.4-variables/README.md index 6134e294f..c6f85ea42 100644 --- a/exercises/ansible_rhel/1.4-variables/README.md +++ b/exercises/ansible_rhel/1.4-variables/README.md @@ -5,344 +5,152 @@ ## Table of Contents -* [Objective](#objective) -* [Guide](#guide) -* [Intro to Variables](#intro-to-variables) -* [Step 1 - Create Variable Files](#step-1---create-variable-files) -* [Step 2 - Create index.html Files](#step-2---create-indexhtml-files) -* [Step 3 - Create the Playbook](#step-3---create-the-playbook) -* [Step 4 - Test the Result](#step-4---test-the-result) -* [Step 5 - Ansible Facts](#step-5---ansible-facts) -* [Step 6 - Challenge Lab: Facts](#step-6---challenge-lab-facts) -* [Step 7 - Using Facts in Playbooks](#step-7---using-facts-in-playbooks) +- [Workshop Exercise - Using Variables](##workshop-exercise---using-variables) + - [Objective](#objective) + - [Guide](#guide) + - [Step 1 - Understanding Variables](#step-1---understanding-variables) + - [Step 2 - Variable Syntax and Creation](#step-2---variable-syntax-and-creation) + - [Step 3 - Running the Modified Playbook](#step-3---running-the-modified-playbook) + - [Step 4 - Advanced Variable Usage in Checks Playbook](#step-4---advanced-variable-usage-in-checks-playbook) -## Objective - -Ansible supports variables to store values that can be used in Ansible playbooks. Variables can be defined in a variety of places and have a clear precedence. Ansible substitutes the variable with its value when a task is executed. -This exercise covers variables, specifically - -* How to use variable delimiters `{{` and `}}` -* What `host_vars` and `group_vars` are and when to use them -* How to use `ansible_facts` -* How to use the `debug` module to print variables to the console window +## Objective +Extending our playbooks from Exercise 1.3, the focus turns to the creation and usage of variables in Ansible. You'll learn the syntax for defining and using variables, an essential skill for creating dynamic and adaptable playbooks. ## Guide +Variables in Ansible are powerful tools for making your playbooks flexible and reusable. They allow you to store and reuse values, making your playbooks more dynamic and adaptable. -### Intro to Variables - -Variables are referenced in Ansible Playbooks by placing the variable name in double curly braces: - - - -```yaml -Here comes a variable {{ variable1 }} -``` - - - -Variables and their values can be defined in various places: the inventory, additional files, on the command line, etc. - -The recommended practice to provide variables in the inventory is to define them in files located in two directories named `host_vars` and `group_vars`: - -* To define variables for a group "servers", a YAML file named `group_vars/servers.yml` with the variable definitions is created. -* To define variables specifically for a host `node1`, the file `host_vars/node1.yml` with the variable definitions is created. - -> **Tip** -> -> Host variables take precedence over group variables (more about precedence can be found in the [docs](https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#variable-precedence-where-should-i-put-a-variable)). - -### Step 1 - Create Variable Files - -For understanding and practice let’s do a lab. Following up on the theme "Let’s build a web server. Or two. Or even more…​", you will change the `index.html` to show the development environment (dev/prod) a server is deployed in. - -On the ansible control host, as the `student` user, create the directories to hold the variable definitions in `~/ansible-files/`: - -```bash -[student@ansible-1 ansible-files]$ mkdir host_vars group_vars -``` - -Now create two files containing variable definitions. We’ll define a variable named `stage` which will point to different environments, `dev` or `prod`: - -* Create the file `~/ansible-files/group_vars/web.yml` with this content: - -```yaml ---- -stage: dev -``` - -* Create the file `~/ansible-files/host_vars/node2.yml` with this content: +### Step 1 - Understanding Variables +A variable in Ansible is a named representation of some data. Variables can contain simple values like strings and numbers, or more complex data like lists and dictionaries. -```yaml ---- -stage: prod -``` - -What is this about? - -* For all servers in the `web` group the variable `stage` with value `dev` is defined. So as default we flag them as members of the dev environment. -* For server `node2` this is overridden and the host is flagged as a production server. - -### Step 2 - Create web.html Files - -Now create two files in `~/ansible-files/files/`: - -One called `prod_web.html` with the following content: - -```html - -

This is a production webserver, take care!

- -``` - -And the other called `dev_web.html` with the following content: - -```html - -

This is a development webserver, have fun!

- -``` - -### Step 3 - Create the Playbook +### Step 2 - Variable Syntax and Creation +The creation and usage of variables involve a specific syntax: -Now you need a Playbook that copies the prod or dev `web.html` file - according to the "stage" variable. +1. Defining Variables: Variables are defined in the `vars` section of a playbook or in separate files for larger projects. +2. Variable Naming: Variable names should be descriptive and adhere to rules such as: + * Starting with a letter or underscore. + * Containing only letters, numbers, and underscores. +3. Using Variables: Variables are referenced in tasks using the double curly braces in quotes `"{{ variable_name }}"`. This syntax tells Ansible to replace it with the variable's value at runtime. -Create a new Playbook called `deploy_index_html.yml` in the `~/ansible-files/` directory. - -> **Tip** -> -> Note how the variable "stage" is used in the name of the file to copy. - - +Update the `system_setup.yml` playbook to include and use a variable: ```yaml --- -- name: Copy web.html - hosts: web +- name: Basic System Setup + hosts: node1 become: true + vars: + user_name: 'Roger' tasks: - - name: copy web.html - ansible.builtin.copy: - src: "{{ stage }}_web.html" - dest: /var/www/html/index.html -``` + - name: Update all security-related packages + ansible.builtin.dnf: + name: '*' + state: latest + security: true - - -* Run the Playbook: - -```bash -[student@ansible-1 ansible-files]$ ansible-navigator run deploy_index_html.yml + - name: Create a new user + ansible.builtin.user: + name: "{{ user_name }}" + state: present + create_home: true ``` -### Step 4 - Test the Result +Run this playbook with `ansible-navigator`. -The Ansible Playbook copies different files as index.html to the hosts, use `curl` to test it. +### Step 3 - Running the Modified Playbook -For node1: +Execute the updated playbook: ```bash -[student@ansible-1 ansible-files]$ curl http://node1 - -

This is a development webserver, have fun!

- +[student@ansible-1 lab_inventory]$ ansible-navigator run system_setup.yml -m stdout ``` -For node2: - -```bash -[student@ansible-1 ansible-files]$ curl http://node2 - -

This is a production webserver, take care!

- -``` - -For node3: - -```bash -[student@ansible-1 ansible-files]$ curl http://node3 - -

This is a development webserver, have fun!

- ``` +PLAY [Basic System Setup] ****************************************************** -> **Tip** -> -> If by now you think: There has to be a smarter way to change content in files…​ you are absolutely right. This lab was done to introduce variables, you are about to learn about templates in one of the next chapters. - -### Step 5 - Ansible Facts - -Ansible facts are variables that are automatically discovered by Ansible from a managed host. Remember the "Gathering Facts" task listed in the output of each `ansible-navigator` execution? At that moment the facts are gathered for each managed nodes. Facts can also be pulled by the `setup` module. They contain useful information stored into variables that administrators can reuse. - -To get an idea what facts Ansible collects by default, on your control node as your student user run the following playbook to get the setup details of `node1`: - -```yaml ---- -- name: Capture Setup - hosts: node1 - - tasks: +TASK [Gathering Facts] ********************************************************* +ok: [node1] - - name: Collect only facts returned by facter - ansible.builtin.setup: - gather_subset: - - 'all' - register: setup +TASK [Update all security-related packages] ************************************ +ok: [node1] - - ansible.builtin.debug: - var: setup -``` +TASK [Create a new user] ******************************************************* +changed: [node1] -```bash -[student@ansible-1 ansible-files]$ cd ~ -[student@ansible-1 ~]$ ansible-navigator run setup.yml -m stdout +PLAY RECAP ********************************************************************* +node1 : ok=3 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 ``` -This might be a bit too much, you can use filters to limit the output to certain facts, the expression is shell-style wildcard within your playbook. Create a playbook labeled `setup_filter.yml` as shown below. In this example, we filter to get the `eth0` facts as well as memory details of `node1`. - -```yaml ---- -- name: Capture Setup - hosts: node1 - - tasks: +Notice how the updated playbook shows a status of changed in the Create a new user task. The user, ‘Roger’, specified within the vars section has been created. - - name: Collect only specific facts - ansible.builtin.setup: - filter: - - 'ansible_eth0' - - 'ansible_*_mb' - register: setup - - - debug: - var: setup -``` +Verify the user creation via: ```bash -[student@ansible-1 ansible-files]$ ansible-navigator run setup_filter.yml -m stdout +[student@ansible-1 lab_inventory]$ ssh node1 id Roger ``` -### Step 6 - Challenge Lab: Facts +### Step 4 - Advanced Variable Usage in Checks Playbook +Enhance the `system_checks.yml` playbook to check for the ‘Roger’ user within the system using the `register` variable and `when` conditional statement. -* Try to find and print the distribution (Red Hat) of your managed hosts using a playbook. +The register keyword in Ansible is used to capture the output of a task and save it as a variable. -> **Tip** -> -> Use the wildcard to find the fact within your filter, then apply a filter to only print this fact. -> **Warning** -> -> **Solution below\!** +Update the `system_checks.yml` playbook: ```yaml --- -- name: Capture Setup +- name: System Configuration Checks hosts: node1 - + become: true + vars: + user_name: 'Roger' tasks: + - name: Check user existence + ansible.builtin.command: + cmd: "id {{ user_name }}" + register: user_check - - name: Collect only specific facts - ansible.builtin.setup: - filter: - - '*distribution' - register: setup - - - ansible.builtin.debug: - var: setup + - name: Report user status + ansible.builtin.debug: + msg: "User {{ user_name }} exists." + when: user_check.rc == 0 ``` -With the wildcard in place, the output shows: +Playbook Details: -```bash +* `register: user_check:` This captures the output of the id command into the variable user_check. +* `when: user_check.rc == 0:` This line is a conditional statement. It checks if the return code (rc) of the previous task (stored in user_check) is 0, indicating success. The debug message will only be displayed if this condition is met. -TASK [debug] ******************************************************************* -ok: [ansible] => { - "setup": { - "ansible_facts": { - "ansible_distribution": "RedHat" - }, - "changed": false, - "failed": false - } -} -``` +This setup provides a practical example of how variables can be used to control the flow of tasks based on the outcomes of previous steps. -With this we can conclude the variable we are looking for is labeled `ansible_distribution`. -Then we can update the playbook to be explicit in its findings and change the following line: - -```yaml -filter: -- '*distribution' -``` - -to: - -```yaml -filter: -- 'ansible_distribution' -``` +Run the checks playbook: ```bash -[student@ansible-1 ansible-files]$ ansible-navigator run setup_filter.yml -m stdout -``` - -### Step 7 - Using Facts in Playbooks - -Facts can be used in a Playbook like variables, using the proper naming, of course. Create this Playbook as `facts.yml` in the `~/ansible-files/` directory: - - - -```yaml ---- -- name: Output facts within a playbook - hosts: all - tasks: - - name: Prints Ansible facts - ansible.builtin.debug: - msg: The default IPv4 address of {{ ansible_fqdn }} is {{ ansible_default_ipv4.address }} +[student@ansible-1 lab_inventory]$ ansible-navigator run system_checks.yml -m stdout ``` - +Output: -> **Tip** -> -> The "debug" module is handy for e.g. debugging variables or expressions. - -Execute it to see how the facts are printed: - -```bash -[student@ansible-1 ansible-files]$ ansible-navigator run facts.yml ``` - -Within the text user interface (TUI) window, type `:st` to capture the following output: - -```bash -PLAY [Output facts within a playbook] ****************************************** +PLAY [System Configuration Checks] ********************************************* TASK [Gathering Facts] ********************************************************* -ok: [node3] -ok: [node2] ok: [node1] -ok: [ansible-1] - -TASK [Prints Ansible facts] **************************************************** -ok: [node1] => - msg: The default IPv4 address of node1 is 172.16.190.143 -ok: [node2] => - msg: The default IPv4 address of node2 is 172.16.30.170 -ok: [node3] => - msg: The default IPv4 address of node3 is 172.16.140.196 -ok: [ansible-1] => - msg: The default IPv4 address of ansible is 172.16.2.10 + +TASK [Check user existence] **************************************************** +changed: [node1] + +TASK [Report user status] ****************************************************** +ok: [node1] => { + "msg": "User Roger exists." +} PLAY RECAP ********************************************************************* -ansible-1 : ok=2 changed=0 unreachable=0 failed=0 -node1 : ok=2 changed=0 unreachable=0 failed=0 -node2 : ok=2 changed=0 unreachable=0 failed=0 -node3 : ok=2 changed=0 unreachable=0 failed=0 +node1 : ok=3 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 ``` +Review the output to confirm the user existence check is correctly using the variable and conditional logic. --- **Navigation**
diff --git a/exercises/ansible_rhel/1.4-variables/README.pt-br.md b/exercises/ansible_rhel/1.4-variables/README.pt-br.md index 4a371b86b..e97764167 100644 --- a/exercises/ansible_rhel/1.4-variables/README.pt-br.md +++ b/exercises/ansible_rhel/1.4-variables/README.pt-br.md @@ -1,239 +1,151 @@ -# Exercício - Usando variáveis +# Exercício do Workshop - Usando Variáveis -**Leia em outras linguagens**: -
![uk](../../../images/uk.png) [English](README.md), ![japan](../../../images/japan.png)[日本語](README.ja.md), ![brazil](../../../images/brazil.png) [Portugues do Brasil](README.pt-br.md), ![france](../../../images/fr.png) [Française](README.fr.md),![Español](../../../images/col.png) [Español](README.es.md). +**Leia isto em outros idiomas**: +
![uk](../../../images/uk.png) [Inglês](README.md), ![japan](../../../images/japan.png) [日本語](README.ja.md), ![brazil](../../../images/brazil.png) [Português do Brasil](README.pt-br.md), ![france](../../../images/fr.png) [Francês](README.fr.md), ![Español](../../../images/col.png) [Espanhol](README.es.md). -* [Passo 1 - Criando arquivos de variáveis](#passo-1---criando-arquivos-de-variáveis) -* [Passo 2 - Criando o arquivo index.html](#passo-2---criando-o-arquivo-indexhtml) -* [Passo 3 - Criando o Playbook](#passo-3---criando-o-playbook) -* [Passo 4 - Teste o Resultado](#passo-4---teste-o-resultado) -* [Passo 5 - Ansible Facts](#passo-5---ansible-facts) -* [Passo 6 - Laboratório de desafios: Facts](#passo-6---laboratório-de-desafios-facts) -* [Passo 7 - Usando Facts em Playbooks](#passo-7---usando-facts-em-playbooks) +## Índice -Os exercícios anteriores mostraram os conceitos básicos do Ansible Engine. Nos próximos exercícios, ensinaremos algumas habilidades mais avançadas que adicionarão flexibilidade e poder aos seus Playbooks. +- [Exercício do Workshop - Usando Variáveis](##workshop-exercise---using-variables) + - [Objetivo](#objetivo) + - [Guia](#guia) + - [Passo 1 - Entendendo Variáveis](#passo-1---entendendo-variáveis) + - [Passo 2 - Sintaxe e Criação de Variáveis](#passo-2---sintaxe-e-criação-de-variáveis) + - [Passo 3 - Executando o Playbook Modificado](#passo-3---executando-o-playbook-modificado) + - [Passo 4 - Uso Avançado de Variáveis no Playbook de Verificações](#passo-4---uso-avançado-de-variáveis-no-playbook-de-verificações) -O Ansible existe para tornar as tarefas simples e repetíveis. Também sabemos que nem todos os sistemas são exatamente iguais e geralmente exigem algumas alterações na maneira como um Playbook do Ansible é executado. +## Objetivo +Estendendo nossos playbooks do Exercício 1.3, o foco se volta para a criação e uso de variáveis no Ansible. Você aprenderá a sintaxe para definir e usar variáveis, uma habilidade essencial para criar playbooks dinâmicos e adaptáveis. -O Ansible suporta variáveis para armazenar valores que podem ser usados nos Playbooks. As variáveis podem ser definidas em vários lugares e têm uma clara precedência. Ansible substitui a variável pelo seu valor quando uma task é executada. +## Guia +Variáveis no Ansible são ferramentas poderosas para tornar seus playbooks flexíveis e reutilizáveis. Elas permitem armazenar e reutilizar valores, tornando seus playbooks mais dinâmicos e adaptáveis. -As variáveis são referenciadas nos Playbooks, colocando o nome da variável entre chaves duplas: +### Passo 1 - Entendendo Variáveis +Uma variável no Ansible é uma representação nomeada de algum dado. Variáveis podem conter valores simples como strings e números, ou dados mais complexos como listas e dicionários. - -```yaml -Isso é uma variável {{ variable1 }} -``` - - -As variáveis e seus valores podem ser definidos em vários locais: no inventário, arquivos adicionais, na linha de comando etc. - -A prática recomendada para fornecer variáveis no inventário é defini-las em arquivos localizados em dois diretórios denominados `host_vars` e `group_vars`: - - - Para definir variáveis para um grupo "servers", é criado um arquivo YAML chamado `group_vars/servers` com as definições de variáveis. - - - Para definir variáveis especificamente para um host `node1`, o arquivo `host_vars/node1` com as definições de variáveis é criado. - -> **Dica** -> -> Variáveis de host têm precedência sobre variáveis de grupo (mais sobre precedência pode ser encontrada em [docs](https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#variable-precedence-where-should-i-put-a-variable)). - -## Passo 1 - Criando arquivos de variáveis +### Passo 2 - Sintaxe e Criação de Variáveis +A criação e uso de variáveis envolvem uma sintaxe específica: -Para entender e praticar, vamos fazer um laboratório. Seguindo o tema "Vamos construir um servidor Web, ou dois, ou ainda mais...​", você alterará o `index.html` para mostrar o ambiente de desenvolvimento (dev/prod) em que um servidor está implantado. +1. Definindo Variáveis: Variáveis são definidas na seção `vars` de um playbook ou em arquivos separados para projetos maiores. +2. Nomeando Variáveis: Os nomes das variáveis devem ser descritivos e aderir a regras como: + * Começar com uma letra ou sublinhado. + * Conter apenas letras, números e sublinhados. +3. Usando Variáveis: Variáveis são referenciadas em tarefas usando as chaves duplas em aspas `"{{ nome_da_variável }}"`. Esta sintaxe indica ao Ansible para substituí-la pelo valor da variável em tempo de execução. -No host de controle ansible, como usuário `student`, crie os diretórios para conter as definições de variáveis em `~/ansible-files/` : - -```bash -[student@ansible ansible-files]$ mkdir host_vars group_vars -``` - -Agora crie dois arquivos contendo definições de variáveis. Definiremos uma variável chamada `stage` que apontará para diferentes ambientes,`dev` ou `prod`: - - - Crie o arquivo `~/ansible-files/group_vars/web` com este conteúdo: +Atualize o playbook `system_setup.yml` para incluir e usar uma variável: ```yaml --- -stage: dev +- name: Configuração Básica do Sistema + hosts: node1 + become: true + vars: + user_name: 'Roger' + tasks: + - name: Atualizar todos os pacotes relacionados à segurança + ansible.builtin.dnf: + name: '*' + state: latest + security: true + + - name: Criar um novo usuário + ansible.builtin.user: + name: "{{ user_name }}" + state: present + create_home: true ``` - - Crie o arquivo `~/ansible-files/host_vars/node2` com este conteúdo: - -```yaml ---- -stage: prod -``` +Execute este playbook com ansible-navigator. -O que é isso? +### Passo 3 - Executando o Playbook Modificado +Execute o playbook atualizado: - - Para todos os servidores no grupo `web`, a variável `stage` com o valor `dev` é definida. Portanto, como padrão sinalizamos como membros do ambiente de desenvolvimento. +```bash +[student@ansible-1 lab_inventory]$ ansible-navigator run system_setup.yml -m stdout - - Para o servidor `node2`, isso é substituído e o host é sinalizado como um servidor de produção. +PLAY [Configuração Básica do Sistema] ****************************************************** -## Passo 2 - Criando o arquivo index.html +TASK [Coletando Fatos] ********************************************************* +ok: [node1] -Agora, crie dois aquivos em `~/ansible-files/`: +TASK [Atualizar todos os pacotes relacionados à segurança] ************************************ +ok: [node1] -Um chamado `prod_index.html` com o seguinte conteúdo: +TASK [Criar um novo usuário] ******************************************************* +changed: [node1] -```html - -

Esse eh um servidor web de producao, tenha cuidado!

- +PLAY RECAP ********************************************************************* +node1 : ok=3 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 ``` -E um chamado `dev_index.html` com o seguinte conteúdo: +Observe como o playbook atualizado mostra um status de alterado na tarefa Criar um novo usuário. O usuário, 'Roger', especificado na seção vars, foi criado. -```html - -

Esse eh um servidor web de desenvolvimento, divirta-se!

- -``` +Verifique a criação do usuário via: -## Passo 3 - Criando o Playbook +```bash +[student@ansible-1 lab_inventory]$ ssh node1 id Roger + +``` -Agora você precisa de um Playbook que copie o arquivo prod ou dev `index.html` - de acordo com a variável "stage". +### Passo 4 - Uso Avançado de Variáveis no Playbook de Verificações +Aprimore o playbook `system_checks.yml` para verificar a existência do usuário 'Roger' no sistema usando a variável `register` e a declaração condicional `when`. -Crie um novo playbook, chamado `deploy_index_html.yml` no diretório `~/ansible-files/`. +A palavra-chave register no Ansible é usada para capturar a saída de uma tarefa e salvá-la como uma variável. -> **Dica** -> -> Observe como a variável "stage" é usada no nome do arquivo a ser copiado. +Atualize o playbook `system_checks.yml`: - ```yaml --- -- name: Copia index.html - hosts: web - become: yes +- name: Verificações de Configuração do Sistema + hosts: node1 + become: true + vars: + user_name: 'Roger' tasks: - - name: Copia index.html - copy: - src: ~/ansible-files/{{ stage }}_index.html - dest: /var/www/html/index.html + - name: Verificar existência do usuário + ansible.builtin.command: + cmd: "id {{ user_name }}" + register: user_check + + - name: Relatar status do usuário + ansible.builtin.debug: + msg: "O usuário {{ user_name }} existe." + when: user_check.rc == 0 ``` - - - Execute o Playbook: +Detalhes do Playbook: -```bash -[student@ansible ansible-files]$ ansible-playbook deploy_index_html.yml -``` - -## Passo 4 - Teste o Resultado +* `register: user_check:` Isso captura a saída do comando id na variável user_check. +* `when: user_check.rc == 0:` Esta linha é uma declaração condicional. Ela verifica se o código de retorno (rc) da tarefa anterior (armazenado em user_check) é 0, indicando sucesso. A mensagem de depuração só será exibida se esta condição for atendida. +Esta configuração fornece um exemplo prático de como as variáveis podem ser usadas para controlar o fluxo de tarefas com base nos resultados das etapas anteriores. -O Playbook deve copiar arquivos diferentes como index.html para os hosts, use `curl` para testá-lo. Verifique o inventário novamente se você esqueceu os endereços IP dos seus nós. +Execute o playbook de verificações: ```bash -[student@ansible ansible-files]$ grep node ~/lab_inventory/hosts -node1 ansible_host=11.22.33.44 -node2 ansible_host=22.33.44.55 -node3 ansible_host=33.44.55.66 -[student@ansible ansible-files]$ curl http://11.22.33.44 - -

Esse eh um servidor web de desenvolvimento, divirta-se!

- -[student1@ansible ansible-files]$ curl http://22.33.44.55 - -

Esse eh um servidor web de producao, tenha cuidado!

- -[student1@ansible ansible-files]$ curl http://33.44.55.66 - -

Esse eh um servidor web de desenvolvimento, divirta-se!

- -``` +[student@ansible-1 lab_inventory]$ ansible-navigator run system_checks.yml -m stdout -> **Dica** -> -> Agora você pensa: "Tem que haver uma maneira mais inteligente de alterar o conteúdo dos arquivos..." e você está absolutamente certo. Este laboratório foi realizado para introduzir variáveis, você está prestes a aprender sobre templates em um dos próximos capítulos. +PLAY [Verificações de Configuração do Sistema] ********************************************* -## Passo 5 - Ansible Facts - -Facts são variáveis que são descobertas automaticamente pelo Ansible a partir de um host gerenciado. Lembra da task "Gathering Facts" listada na saída de cada execução do `ansible-playbook`? Nesse momento, os facts são reunidos para cada nó gerenciado. Os fatos também podem ser obtidos pelo módulo `setup`. Eles contêm informações úteis armazenadas em variáveis que os administradores podem reutilizar. - -Para ter uma ideia dos facts que o Ansible coleta por padrão, em seu nó de controle enquanto o usuário student executa: - -```bash -[student@ansible ansible-files]$ ansible node1 -m setup -``` - -Isso pode ser demais, você pode usar filtros para limitar a saída a certos facts, a expressão é curinga no estilo shell: - -```bash -[student@ansible ansible-files]$ ansible node1 -m setup -a 'filter=ansible_eth0' -``` -Ou que tal procurar apenas facts relacionados à memória: - -```bash -[student@ansible ansible-files]$ ansible node1 -m setup -a 'filter=ansible_*_mb' -``` - -## Passo 6 - Laboratório de desafios: Facts - - - Tente encontrar e imprimir a distribuição (Red Hat) de seus hosts gerenciados. Em uma linha, por favor. +TASK [Coletando Fatos] ********************************************************* +ok: [node1] -> **Dica** -> -> Use grep para procurar o fact, e aplique um filtro para imprimir apenas esse fact. +TASK [Verificar existência do usuário] **************************************************** +changed: [node1] -> **ATENÇÃO** -> -> **Solução abaixo\!** +TASK [Relatar status do usuário] ****************************************************** +ok: [node1] => { + "msg": "O usuário Roger existe." +} -```bash -[student@ansible ansible-files]$ ansible node1 -m setup|grep distribution -[student@ansible ansible-files]$ ansible node1 -m setup -a 'filter=ansible_distribution' -o +PLAY RECAP ********************************************************************* +node1 : ok=3 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 ``` -## Passo 7 - Usando Facts em Playbooks +Revise a saída para confirmar que a verificação da existência do usuário está usando corretamente a variável e a lógica condicional. -Os facts podem ser usados em um Playbook como variáveis, usando a nomeação apropriada. Crie este Playbook como `facts.yml` no diretório `~/ansible-files/`: - - -```yaml --- -- name: Saida de facts em um playbook - hosts: all - tasks: - - name: Print ansible facts - debug: - msg: O endereco IPv4 padrao de {{ ansible_fqdn }} eh {{ ansible_default_ipv4.address }} -``` - - -> **Dica** -> -> O módulo "debug" é útil para, por exemplo variáveis ou expressões de depuração. - -Execute-o para ver como os facts são impressos: +**Navegação** -```bash -[student@ansible ansible-files]$ ansible-playbook facts.yml - -PLAY [Saida de facts em um playbook] ****************************************** - -TASK [Gathering Facts] ********************************************************* -ok: [node3] -ok: [node2] -ok: [node1] -ok: [ansible] - -TASK [Print ansible facts] **************************************************** -ok: [node1] => - msg: O endereco IPv4 padrao de node1 eh 172.16.190.143 -ok: [node2] => - msg: O endereco IPv4 padrao de node2 eh 172.16.30.170 -ok: [node3] => - msg: O endereco IPv4 padrao de node3 eh 172.16.140.196 -ok: [ansible] => - msg: O endereco IPv4 padrao de ansible eh 172.16.2.10 - -PLAY RECAP ********************************************************************* -ansible : ok=2 changed=0 unreachable=0 failed=0 -node1 : ok=2 changed=0 unreachable=0 failed=0 -node2 : ok=2 changed=0 unreachable=0 failed=0 -node3 : ok=2 changed=0 unreachable=0 failed=0 -``` +[Exercício Anterior](../1.3-playbook/README.pt-br.md) - [Próximo Exercício](../1.5-handlers/README.pt-br.md) ----- +[Clique aqui para retornar ao Workshop de Ansible para Red Hat Enterprise Linux](../README.md) -[Clique aqui para retornar ao Workshop Ansible for Red Hat Enterprise Linux](../README.pt-br.md#seção-1---exercícios-do-ansible-engine) diff --git a/exercises/ansible_rhel/1.5-handlers/README.es.md b/exercises/ansible_rhel/1.5-handlers/README.es.md index c61d7080e..a1f7fc9d6 100644 --- a/exercises/ansible_rhel/1.5-handlers/README.es.md +++ b/exercises/ansible_rhel/1.5-handlers/README.es.md @@ -1,242 +1,248 @@ -# Workshop - Condicionales, controladores y bucles +# Ejercicio del Taller - Condicionales, Manejadores y Bucles -**Read this in other languages**: -
![uk](../../../images/uk.png) [English](README.md), ![japan](../../../images/japan.png)[日本語](README.ja.md), ![brazil](../../../images/brazil.png) [Portugues do Brasil](README.pt-br.md), ![france](../../../images/fr.png) [Française](README.fr.md),![Español](../../../images/col.png) [Español](README.es.md). +**Lee esto en otros idiomas**: +
![uk](../../../images/uk.png) [Inglés](README.md), ![japan](../../../images/japan.png) [日本語](README.ja.md), ![brazil](../../../images/brazil.png) [Português do Brasil](README.pt-br.md), ![france](../../../images/fr.png) [Français](README.fr.md), ![Español](../../../images/col.png) [Español](README.es.md). -## Table of Contents +# Ejercicios del Taller - Usando Condicionales, Manejadores y Bucles -* [Objetivos](#Objetivos) -* [Guía](#Guía) -* [Paso 1 - Condicionales](#Paso-1---Condicionales) -* [Paso 2 - Controladores](#Paso-2---Controladores) -* [Paso 3 - Bucles simples](#Paso-3---Bucles-simples) -* [Paso 4 - Bucles sobre hashes](#Paso-4---Bucles-sobre-hashes) +## Tabla de Contenidos -# Objetivos +- [Objetivo](#objetivo) +- [Guía](#guía) + - [Paso 1 - Entendiendo Condicionales, Manejadores y Bucles](#paso-1---entendiendo-condicionales-manejadores-y-bucles) + - [Paso 2 - Condicionales](#paso-2---condicionales) + - [Paso 3 - Manejadores](#paso-3---manejadores) + - [Paso 4 - Bucles](#paso-4---bucles) -Tres características fundamentales de Ansible son: -- [Condicionales](https://docs.ansible.com/ansible/latest/user_guide/playbooks_conditionals.html) -- [Controladores](https://docs.ansible.com/ansible/latest/user_guide/playbooks_intro.html#handlers-running-operations-on-change) -- [Bucles](https://docs.ansible.com/ansible/latest/user_guide/playbooks_loops.html) +## Objetivo -# Guía +Expandiendo el Ejercicio 1.4, este ejercicio introduce la aplicación de condicionales, manejadores y bucles en los libros de jugadas de Ansible. Aprenderás a controlar la ejecución de tareas con condicionales, gestionar respuestas de servicios con manejadores y manejar tareas repetitivas de manera eficiente usando bucles. -## Paso 1 - Condicionales +## Guía -Ansible puede usar condicionales para ejecutar tareas o plays cuando se cumplen ciertas condiciones. +Los condicionales, manejadores y bucles son características avanzadas en Ansible que mejoran el control, la eficiencia y la flexibilidad en tus libros de jugadas de automatización. -Para implementar un condicional, se debe usar la instrucción `when`, seguida de la condición para probar. La condición se expresa utilizando uno de los operadores disponibles, como por ejemplo para comparacion: +### Paso 1 - Entendiendo Condicionales, Manejadores y Bucles -| | | -| ---- | ---------------------------------------------------------------------- | -| \== | Compara dos objetos para la igualdad. | -| \!= | Compara dos objetos para la desigualdad. | -| \> | cierto si el lado izquierdo es mayor que el lado derecho. | -| \>= | cierto si el lado izquierdo es mayor o igual al lado derecho. | -| \< | cierto si el lado izquierdo es más bajo que el lado derecho. | -| \<= | cierto si el lado izquierdo es inferior o igual al lado derecho. | +- **Condicionales**: Permiten que las tareas se ejecuten basadas en condiciones específicas. +- **Manejadores**: Tareas especiales desencadenadas por una directiva `notify`, típicamente usadas para reiniciar servicios después de cambios. +- **Bucles**: Se utilizan para repetir una tarea varias veces, especialmente útil cuando la tarea es similar pero necesita aplicarse a diferentes elementos. -Para obtener más información, consulte la documentación: +### Paso 2 - Condicionales -Como ejemplo, le gustaría instalar un servidor FTP, pero solo en hosts que se encuentran en el grupo de inventario "ftpserver". +Los condicionales en Ansible controlan si una tarea debe ejecutarse basada en ciertas condiciones. +Vamos a añadir al libro de jugadas system_setup.yml la capacidad de instalar el Servidor HTTP Apache (`httpd`) solo en hosts que pertenezcan al grupo `web` en nuestro inventario. -Para ello, primero edite el inventario para agregar otro grupo y coloque `node2` en él. Aseegurese que esa dirección IP del `node2` es siempre la misma cuando lista el `node2`. Edite el inventario `~/lab_inventory/hosts` para que se parezca a la siguiente lista: - -```ini -[web] -node1 ansible_host=11.22.33.44 -node2 ansible_host=22.33.44.55 -node3 ansible_host=33.44.55.66 - -[ftpserver] -node2 ansible_host=22.33.44.55 - -[control] -ansible ansible_host=44.55.66.77 -``` -A continuación, cree el archivo `ftpserver.yml` en el host de control en el directorio `~/ansible-files/`: +> NOTA: Ejemplos anteriores tenían hosts configurados como node1 pero ahora está configurado como all. Esto significa que cuando ejecutes este libro de jugadas actualizado de Ansible notarás actualizaciones para los nuevos sistemas automatizados, el usuario Roger creado en todos los nuevos sistemas y el paquete del servidor web Apache httpd instalado en todos los hosts dentro del grupo web. ```yaml --- -- name: Install vsftpd on ftpservers +- name: Configuración Básica del Sistema hosts: all - become: yes + become: true + vars: + user_name: 'Roger' + package_name: httpd tasks: - - name: Install FTP server when host in ftpserver group - yum: - name: vsftpd + - name: Actualizar todos los paquetes relacionados con la seguridad + ansible.builtin.dnf: + name: '*' state: latest - when: inventory_hostname in groups["ftpserver"] -``` - -> **Consejo** -> -> A estas alturas ya deberías saber cómo ejecutar Ansible Playbooks, empezaremos a ser menos detallados en esta guía. Vaya a crearlo y ejecútelo. :-) + security: true + update_only: true -Ejecútelo y examine la salida. El resultado esperado: la tarea se omite en node1, node3 y el host ansible (su host de control) porque no están en el grupo ftpserver del archivo de inventario. + - name: Crear un nuevo usuario + ansible.builtin.user: + name: "{{ user_name }}" + state: present + create_home: true -```bash -TASK [Install FTP server when host in ftpserver group] ******************************************* -skipping: [ansible] -skipping: [node1] -skipping: [node3] -changed: [node2] + - name: Instalar Apache en servidores web + ansible.builtin.dnf: + name: "{{ package_name }}" + state: present + when: inventory_hostname in groups['web'] ``` -# Paso 2 - Controladores - -A veces, cuando una tarea realiza un cambio en el sistema, es posible que sea necesario ejecutar una tarea o tareas adicionales. Por ejemplo, un cambio en el archivo de configuración de un servicio puede requerir que se reinicie el servicio para que la configuración modificada surta efecto. +En este ejemplo, inventory_hostname in groups['web'] es la declaración condicional. inventory_hostname se refiere al nombre del host actual en el que Ansible está trabajando en el libro de jugadas. La condición verifica si este host es parte del grupo web definido en tu archivo de inventario. Si es verdadero, la tarea se ejecutará e instalará Apache en ese host. -Aquí entran en juego los controladores de Ansible. Los controladores se pueden ver como tareas inactivas que solo se desencadenan cuando se invocan explícitamente mediante la instrucción "notify". Leer más sobre ellos en la documentación de [Ansible Handlers](http://docs.ansible.com/ansible/latest/playbooks_intro.html#handlers-running-operations-on-change). +Paso 3 - Manejadores +Los manejadores se utilizan para tareas que solo deben ejecutarse cuando son notificadas por otra tarea. Típicamente, se usan para reiniciar servicios después de un cambio de configuración. -Como ejemplo, vamos a escribir un Playbook que: +Digamos que queremos asegurarnos de que el firewall esté configurado correctamente en todos los servidores web y luego recargar el servicio de firewall para aplicar cualquier nueva configuración. Definiremos un manejador que recargue el servicio de firewall y es notificado por una tarea que asegura que las reglas de firewall deseadas estén en su lugar: - - gestiona el archivo de configuración de Apache `/etc/httpd/conf/httpd.conf` en todos los hosts del grupo `web` +```yaml +--- +- name: Configuración Básica del Sistema + hosts: all + become: true + . + . + . + - name: Instalar firewalld + ansible.builtin.dnf: + name: firewalld + state: present - - reinicia Apache cuando el archivo ha cambiado + - name: Asegurar que firewalld esté corriendo + ansible.builtin.service: + name: firewalld + state: started + enabled: true -Primero necesitamos el archivo que Ansible implementará, vamos a tomar el del nodo1. Recuerde reemplazar la dirección IP que se muestra en la lista siguiente con la dirección IP de su `node1`. + - name: Permitir tráfico HTTPS en servidores web + ansible.posix.firewalld: + service: https + permanent: true + state: enabled + when: inventory_hostname in groups['web'] + notify: Recargar Firewall -``` -[student@ansible ansible-files]$ scp 11.22.33.44:/etc/httpd/conf/httpd.conf ~/ansible-files/files/. -student@11.22.33.44's password: -httpd.conf -``` + handlers: + - name: Recargar Firewall + ansible.builtin.service: + name: firewalld + state: reloaded -A continuación, cree el Playbook `httpd_conf.yml`. Asegúrese de que se encuentra en el directorio `~/ansible-files`. -```yaml ---- -- name: manage httpd.conf - hosts: web - become: yes - tasks: - - name: Copy Apache configuration file - copy: - src: httpd.conf - dest: /etc/httpd/conf/ - notify: - - restart_apache - handlers: - - name: restart_apache - service: - name: httpd - state: restarted ``` -¿Qué hay de nuevo aquí? - - - La sección "notify" llama al controlador solo cuando la tarea de copia cambia realmente el archivo. De este modo, el servicio solo se reinicia si es necesario, y no cada vez que se ejecuta el playbook. - - La sección "handlers" define una tarea que solo se ejecuta en la notificación. -
+El manejador Recargar Firewall solo se activa si la tarea "Permitir tráfico HTTPS en servidores web" realiza algún cambio. -Ejecute el Playbook. Todavía no hemos cambiado nada en el archivo, por lo que no debería haber ninguna línea `changed` en la salida y, por supuesto, el controlador no debería dispararse. +> NOTA: Observa cómo el nombre del manejador se utiliza dentro de la sección notify de la tarea de configuración "Recargar Firewall". Esto asegura que se ejecute el manejador adecuado ya que puede haber múltiples manejadores dentro de un libro de jugadas de Ansible. - - Ahora cambie la línea `Listen 80` en `~/ansible-files/files/httpd.conf` por: +```yaml +PLAY [Configuración Básica del Sistema] ****************************************************** + +TASK [Recolectando Hechos] ********************************************************* +ok: [node1] +ok: [node2] +ok: [ansible-1] +ok: [node3] + +TASK [Actualizar todos los paquetes relacionados con la seguridad] ************************************ +ok: [node2] +ok: [node1] +ok: [ansible-1] +ok: [node3] + +TASK [Crear un nuevo usuario] ******************************************************* +ok: [node1] +ok: [node2] +ok: [ansible-1] +ok: [node3] + +TASK [Instalar Apache en servidores web] ******************************************* +skipping: [ansible-1] +ok: [node2] +ok: [node1] +ok: [node3] + +TASK [Instalar firewalld] ******************************************************* +changed: [ansible-1] +changed: [node2] +changed: [node1] +changed: [node3] -```ini -Listen 8080 -``` - - Ejecute el Playbook de nuevo. Ahora la salida de Ansible debería ser mucho más interesante: +TASK [Asegurar que firewalld esté corriendo] ********************************************* +changed: [node3] +changed: [ansible-1] +changed: [node2] +changed: [node1] - - httpd.conf debería haber sido copiado +TASK [Permitir tráfico HTTPS en servidores web] ************************************** +skipping: [ansible-1] +changed: [node2] +changed: [node1] +changed: [node3] - - El controlador debería haber reiniciado Apache +MANEJADOR EN EJECUCIÓN [Recargar Firewall] ********************************************** +changed: [node2] +changed: [node1] +changed: [node3] +RECUENTO DE JUEGO ********************************************************************* +ansible-1 : ok=5 changed=2 unreachable=0 failed=0 skipped=2 rescued=0 ignored=0 +node1 : ok=8 changed=4 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 +node2 : ok=8 changed=4 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 +node3 : ok=8 changed=4 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 -Apache debería escuchar ahora en el puerto 8080. Lo suficientemente fácil de verificar: -```bash -[student1@ansible ansible-files]$ curl http://22.33.44.55 -curl: (7) Failed connect to 22.33.44.55:80; Connection refused -[student1@ansible ansible-files]$ curl http://22.33.44.55:8080 - -

This is a production webserver, take care!

- ``` -Sientase libre de cambiar el archivo httpd.conf de nuevo y ejecutar el playbook. -## Paso 3 - Bucles simples +### Paso 4 - Bucles +Los bucles en Ansible te permiten realizar una tarea múltiples veces con diferentes valores. Esta característica es particularmente útil para tareas como crear múltiples cuentas de usuario en nuestro ejemplo dado. +En el libro de jugadas system_setup.yml original del Ejercicio 1.4, teníamos una tarea para crear un solo usuario: -Los bucles nos permiten repetir la misma tarea una y otra vez. Por ejemplo, supongamos que desea crear varios usuarios. Mediante el uso de un bucle de Ansible, puede hacerlo en una sola tarea. Los bucles también pueden recorrer en iteración algo más que las listas básicas. Por ejemplo, si tiene una lista de usuarios con su correspondinte grupo, el bucle también puede iterar sobre ellos. Obtenga más información sobre los bucles en el la documentación de [Ansible Loops](https://docs.ansible.com/ansible/latest/user_guide/playbooks_loops.html). +```yaml +- name: Crear un nuevo usuario + ansible.builtin.user: + name: "{{ user_name }}" + state: present + create_home: true -Para mostrar la función de bucles generaremos tres nuevos usuarios en `node1`. Para ello, cree el archivo `loop_users.yml` en `~/ansible-files` en el nodo de control como usuario student. Usaremos el módulo `user` para generar las cuentas de usuario. +``` + +Ahora, modifiquemos esta tarea para crear múltiples usuarios usando un bucle: - ```yaml ---- -- name: Ensure users - hosts: node1 - become: yes +- name: Crear un nuevo usuario + ansible.builtin.user: + name: "{{ item }}" + state: present + create_home: true + loop: + - alice + - bob + - carol - tasks: - - name: Ensure three users are present - user: - name: "{{ item }}" - state: present - loop: - - dev_user - - qa_user - - prod_user ``` - -Comprancion del playbook y la salida - - - Los nombres no se proporcionan directamente al módulo de usuario. En lugar de eso, solo hay una variable que se llama `{{ item }}` para el parámetro `name`. +¿Qué cambió? - - La palabra clave `loop` enumera los nombres de usuario reales. Estos reemplazan el `{{ item }}` durante la ejecución real del playbook. +1. Directiva de Bucle: La palabra clave loop se usa para iterar sobre una lista de elementos. En este caso, la lista contiene los nombres de los usuarios que queremos crear: alice, bob y carol. - - Durante la ejecución, la tarea solo aparece una vez, pero hay tres cambios listados debajo de ella. - +2. Creación de Usuarios con Bucle: En lugar de crear un solo usuario, la tarea modificada ahora itera sobre cada elemento en la lista de bucle. El marcador de posición `{{ item }}` se reemplaza dinámicamente con cada nombre de usuario en la lista, por lo que el módulo ansible.builtin.user crea cada usuario a su vez. -## Paso 4 - Bucles sobre hashes +Cuando ejecutes el libro de jugadas actualizado, esta tarea se ejecutará tres veces, una vez para cada usuario especificado en el bucle. Es una forma eficiente de manejar tareas repetitivas con datos de entrada variables. -Como los bucles mencionados también pueden estar sobre las listas de hashes. Imagine que los usuarios deben asignarse a diferentes grupos adicionales: +Fragmento de la salida para crear un nuevo usuario en todos los nodos. -```yaml -- username: dev_user - groups: ftp -- username: qa_user - groups: ftp -- username: prod_user - groups: apache -``` -El módulo `user` tiene el parámetro opcional `groups` para enumerar usuarios adicionales. Para hacer referencia a los elementos de un hash, por ejemplo, la palabra clave `{{ item }}` debe hacer referencia a la subclave: `{{ item.groups }}` por ejemplo. +```bash +[student@ansible-1 ~lab_inventory]$ ansible-navigator run system_setup.yml -m stdout -Vamos a reescribir el playbook para crear los usuarios con derechos de usuario adicionales: +PLAY [Configuración Básica del Sistema] ****************************************************** - -```yaml ---- -- name: Ensure users - hosts: node1 - become: yes +. +. +. - tasks: - - name: Ensure three users are present - user: - name: "{{ item.username }}" - state: present - groups: "{{ item.groups }}" - loop: - - { username: 'dev_user', groups: 'ftp' } - - { username: 'qa_user', groups: 'ftp' } - - { username: 'prod_user', groups: 'apache' } +TASK [Crear un nuevo usuario] ******************************************************* +changed: [node2] => (item=alice) +changed: [ansible-1] => (item=alice) +changed: [node1] => (item=alice) +changed: [node3] => (item=alice) +changed: [node1] => (item=bob) +changed: [ansible-1] => (item=bob) +changed: [node3] => (item=bob) +changed: [node2] => (item=bob) +changed: [node1] => (item=carol) +changed: [node3] => (item=carol) +changed: [ansible-1] => (item=carol) +changed: [node2] => (item=carol) -``` - +. +. +. -Compruebe la salida: - - Una vez más la tarea se enumera una vez, pero se enumeran tres cambios. Se muestra cada bucle con su contenido. +RECUENTO DE JUEGO ********************************************************************* +ansible-1 : ok=5 changed=1 unreachable=0 failed=0 skipped=2 rescued=0 ignored=0 +node1 : ok=7 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 +node2 : ok=7 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 +node3 : ok=7 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 -Compruebe que el usuario `dev_user` se creó efectivamente en `node1`: -```bash -[student@ansible ansible-files]$ ansible node1 -m command -a "id dev_user" -node1 | CHANGED | rc=0 >> -uid=1002(dev_user) gid=1002(dev_user) Gruppen=1002(dev_user),50(ftp) ``` ---- diff --git a/exercises/ansible_rhel/1.5-handlers/README.fr.md b/exercises/ansible_rhel/1.5-handlers/README.fr.md index 61af108df..83a9bd357 100644 --- a/exercises/ansible_rhel/1.5-handlers/README.fr.md +++ b/exercises/ansible_rhel/1.5-handlers/README.fr.md @@ -1,253 +1,255 @@ -# Atelier - Les conditions, Handlers et boucles +# Exercice de l'Atelier - Conditionnels, Gestionnaires et Boucles -**Lisez ceci dans d'autres langues**: -
![uk](../../../images/uk.png) [English](README.md), ![japan](../../../images/japan.png)[日本語](README.ja.md), ![brazil](../../../images/brazil.png) [Portugues do Brasil](README.pt-br.md), ![france](../../../images/fr.png) [Française](README.fr.md),![Español](../../../images/col.png) [Español](README.es.md). +**Lisez ceci dans d'autres langues** : +
![uk](../../../images/uk.png) [Anglais](README.md), ![japan](../../../images/japan.png) [日本語](README.ja.md), ![brazil](../../../images/brazil.png) [Portugais du Brésil](README.pt-br.md), ![france](../../../images/fr.png) [Français](README.fr.md), ![Español](../../../images/col.png) [Espagnol](README.es.md). +# Exercices de l'Atelier - Utilisation des Conditionnels, Gestionnaires et Boucles -## Table des matières +## Table des Matières -* [Objectif](#objectif) -* [Guide](#guide) -* [Étape 1 - Les Conditions](#Étape-1---les-conditions) -* [Étape 2 - Les handlers](#Étape-2---les-handlers) -* [Étape 3 - Les boucles simples](#Étape-3---les-boucles-simples) -* [Étape 4 - Les Boucles complexes](#Étape-4---les-boucles-complexes) +- [Objectif](#objectif) +- [Guide](#guide) + - [Étape 1 - Comprendre les Conditionnels, Gestionnaires et Boucles](#étape-1---comprendre-les-conditionnels-gestionnaires-et-boucles) + - [Étape 2 - Conditionnels](#étape-2---conditionnels) + - [Étape 3 - Gestionnaires](#étape-3---gestionnaires) + - [Étape 4 - Boucles](#étape-4---boucles) -# Objectif +## Objectif -Les trois fonctionnalités fondamentales d'Ansible sont les suivantes: -- [Conditions](https://docs.ansible.com/ansible/latest/user_guide/playbooks_conditionals.html) -- [Gestionnaires](https://docs.ansible.com/ansible/latest/user_guide/playbooks_intro.html#handlers-running-operations-on-change) -- [Boucles](https://docs.ansible.com/ansible/latest/user_guide/playbooks_loops.html) +En élargissant l'exercice 1.4, cet exercice introduit l'application des conditionnels, gestionnaires et boucles dans les playbooks Ansible. Vous apprendrez à contrôler l'exécution des tâches avec des conditionnels, à gérer les réponses des services avec des gestionnaires et à gérer efficacement les tâches répétitives à l'aide de boucles. -# Guide +## Guide -## Étape 1 - Les conditions +Les conditionnels, gestionnaires et boucles sont des fonctionnalités avancées dans Ansible qui améliorent le contrôle, l'efficacité et la flexibilité dans vos playbooks d'automatisation. -Ansible peut utiliser des conditions pour exécuter des tâches ou des plays lorsque certaines conditions sont remplies. +### Étape 1 - Comprendre les Conditionnels, Gestionnaires et Boucles -Pour implémenter un conditionnel, l'instruction `when` doit être utilisée, suivie de la condition à tester. La condition est exprimée en utilisant l'un des opérateurs disponibles ci-dessous: +- **Conditionnels** : Permettent l'exécution des tâches basée sur des conditions spécifiques. +- **Gestionnaires** : Tâches spéciales déclenchées par une directive `notify`, généralement utilisées pour redémarrer les services après des modifications. +- **Boucles** : Utilisées pour répéter une tâche plusieurs fois, particulièrement utile lorsque la tâche est similaire mais doit être appliquée à différents éléments. -| | | -| ---- | ------------------------------------------------------------ | -| \ == | Compare deux objets pour l'égalité. | -| \! = | Compare deux objets pour l'inégalité. | -| \> | true si le côté gauche est supérieur au côté droit. | -| \> = | true si le côté gauche est supérieur ou égal au côté droit. | -| \< | true si le côté gauche est plus bas que le côté droit. | -| \< = | true si le côté gauche est inférieur ou égal au côté droit. | +### Étape 2 - Conditionnels -Pour plus d'informations à ce sujet, veuillez vous référer à la documentation: +Les conditionnels dans Ansible contrôlent si une tâche doit être exécutée en fonction de certaines conditions. +Ajoutons à notre playbook system_setup.yml la capacité d'installer le Serveur HTTP Apache (`httpd`) uniquement sur les hôtes qui appartiennent au groupe `web` dans notre inventaire. -À titre d'exemple, nous allons installé un serveur FTP, mais uniquement sur les hôtes qui se trouvent dans le groupe d'inventaire "ftpserver". - -Pour ce faire, modifiez d'abord l'inventaire pour ajouter un autre groupe et placez `node2` dedans. Assurez-vous que l'adresse IP de `node2` est toujours la même lorsque `node2` est répertorié. Modifiez l'inventaire `~/lab_inventory/hosts` pour qu'il ressemble à la liste suivante: - -```ini -[web] -node1 ansible_host=11.22.33.44 -node2 ansible_host=22.33.44.55 -node3 ansible_host=33.44.55.66 - -[ftpserver] -node2 ansible_host=22.33.44.55 - -[control] -ansible ansible_host=44.55.66.77 -``` - -Créez ensuite le fichier `ftpserver.yml` sur votre hôte de contrôle dans le répertoire `~/ansible-files/`: +> REMARQUE : Les exemples précédents avaient des hôtes définis sur node1 mais maintenant il est défini sur all. Cela signifie que lorsque vous exécutez ce playbook Ansible mis à jour, vous remarquerez des mises à jour pour les nouveaux systèmes automatisés, l'utilisateur Roger créé sur tous les nouveaux systèmes et le paquet du serveur web Apache httpd installé sur tous les hôtes du groupe web. ```yaml --- -- name: Install vsftpd on ftpservers +- name: Configuration Système de Base hosts: all - become: yes + become: true + vars: + user_name: 'Roger' + package_name: httpd tasks: - - name: Install FTP server when host in ftpserver group - yum: - name: vsftpd + - name: Mettre à jour tous les paquets liés à la sécurité + ansible.builtin.dnf: + name: '*' state: latest - when: inventory_hostname in groups["ftpserver"] -``` + security: true + update_only: true -> **Astuce** -> -> À présent, vous devez savoir comment exécuter les Playbooks Ansible, nous allons commencer à être moins verbeux dans ce guide. - -Exécutez-le et examinez la sortie. Résultat attendu: la tâche est ignorée sur node1, node3 et l'hôte ansible (votre hôte de contrôle) car ils ne font pas partie du groupe ftpserver dans votre fichier d'inventaire. + - name: Créer un nouvel utilisateur + ansible.builtin.user: + name: "{{ user_name }}" + state: present + create_home: true -```bash -TASK [Install FTP server when host in ftpserver group] ******************************************* -skipping: [ansible] -skipping: [node1] -skipping: [node3] -changed: [node2] + - name: Installer Apache sur les serveurs web + ansible.builtin.dnf: + name: "{{ package_name }}" + state: present + when: inventory_hostname in groups['web'] ``` -## Étape 2 - Les handlers - -Parfois, lorsqu'une tâche apporte une modification au système, une ou plusieurs tâches supplémentaires peuvent devoir être exécutées. Par exemple, une modification du fichier de configuration d'un service peut alors nécessiter le redémarrage du service pour que la configuration modifiée prenne effet. - -Ici, les handlers d'Ansible entrent en jeu. Les handlers peuvent être considérés comme des tâches inactives qui ne sont déclenchées que lorsqu'elles sont explicitement invoquées à l'aide de l'instruction "notify". En savoir plus à leur sujet dans la documentation [Ansible Handlers](http://docs.ansible.com/ansible/latest/playbooks_intro.html#handlers-running-operations-on-change). +Dans cet exemple, `inventory_hostname in groups['web']` est la déclaration conditionnelle. `inventory_hostname` fait référence au nom de l'hôte actuel sur lequel Ansible travaille dans le playbook. La condition vérifie si cet hôte fait partie du groupe web défini dans votre fichier d'inventaire. Si c'est vrai, la tâche s'exécutera et installera Apache sur cet hôte. -À titre d'exemple, écrivons un Playbook qui: +### Étape 3 - Gestionnaires - - gère le fichier de configuration d'Apache `/etc/httpd/conf/httpd.conf` sur tous les hôtes du groupe `web` +Les gestionnaires sont utilisés pour les tâches qui ne doivent s'exécuter que lorsqu'elles sont notifiées par une autre tâche. Typiquement, ils sont utilisés pour redémarrer les services après un changement de configuration. - - redémarre Apache lorsque le fichier a changé +Disons que nous voulons nous assurer que le pare-feu est correctement configuré sur tous les serveurs web, puis recharger le service pare-feu pour appliquer les nouveaux paramètres. Nous définirons un gestionnaire qui recharge le service pare-feu et est notifié par une tâche qui assure que les règles de pare-feu souhaitées sont en place : -Nous avons d'abord besoin du fichier qu'Ansible déploiera, prenons simplement celui de node1. N'oubliez pas de remplacer l'adresse IP indiquée dans la liste ci-dessous par l'adresse IP de votre `node1` personnel. - -``` -[student@ansible ansible-files]$ scp 11.22.33.44:/etc/httpd/conf/httpd.conf ~/ansible-files/files/. -student@11.22.33.44's password: -httpd.conf -``` - -Ensuite, créez le Playbook `httpd_conf.yml`. Assurez-vous que vous êtes dans le répertoire `~/ansible-files`. ```yaml --- -- name: manage httpd.conf - hosts: web - become: yes - tasks: - - name: Copy Apache configuration file - copy: - src: httpd.conf - dest: /etc/httpd/conf/ - notify: - - restart_apache - handlers: - - name: restart_apache - service: - name: httpd - state: restarted -``` - -Alors quoi de neuf ici? - - - La section "notifier" n'appelle le handler que lorsque la tâche de copie modifie réellement le fichier. De cette façon, le service est redémarré uniquement si nécessaire - et non à chaque exécution du playbook. +- name: Configuration Système de Base + hosts: all + become: true + . + . + . + - name: Installer firewalld + ansible.builtin.dnf: + name: firewalld + state: present - - La section "handlers" définit une tâche qui n'est exécutée que sur notification. -
+ - name: S'assurer que firewalld est en cours d'exécution + ansible.builtin.service: + name: firewalld + state: started + enabled: true -Exécutez le Playbook. Nous n'avons encore rien modifié dans le fichier, donc il ne devrait pas y avoir de lignes "modifies" dans la sortie et bien sûr le handler n'a pas dû se déclencher. + - name: Autoriser le trafic HTTPS sur les serveurs web + ansible.posix.firewalld: + service: https + permanent: true + state: enabled + when: inventory_hostname in groups['web'] + notify: Recharger le Pare-feu - - Maintenant, changez la ligne `Listen 80` dans `/etc/httpd/conf/httpd.conf` en: + handlers: + - name: Recharger le Pare-feu + ansible.builtin.service: + name: firewalld + state: reloaded -```ini -Listen 8080 ``` -- Exécutez à nouveau le Playbook. Maintenant, la sortie d'Ansible devrait être beaucoup plus intéressante: - - - httpd.conf a dû être copié +Le gestionnaire Recharger le Pare-feu est déclenché uniquement si la tâche "Autoriser le trafic HTTPS sur les serveurs web" effectue des modifications. - - Le handler a dû redémarrer Apache +> REMARQUE : Remarquez comment le nom du gestionnaire est utilisé dans la section notify de la tâche de configuration "Recharger le Pare-feu". Cela garantit que le bon gestionnaire est exécuté car il peut y avoir plusieurs gestionnaires dans un playbook Ansible. -Apache devrait maintenant écouter sur le port 8080. Assez facile à vérifier: - -```bash -[student1@ansible ansible-files]$ curl http://22.33.44.55 -curl: (7) Failed connect to 22.33.44.55:80; Connection refused -[student1@ansible ansible-files]$ curl http://22.33.44.55:8080 - -

This is a production webserver, take care!

- ``` -N'hésitez pas à modifier à nouveau le fichier httpd.conf et à exécuter le playbook. +PLAY [Configuration Système de Base] ****************************************************** + +TASK [Collecte des Faits] ********************************************************* +ok: [node1] +ok: [node2] +ok: [ansible-1] +ok: [node3] + +TASK [Mettre à jour tous les paquets liés à la sécurité] ************************************ +ok: [node2] +ok: [node1] +ok: [ansible-1] +ok: [node3] + +TASK [Créer un nouvel utilisateur] ******************************************************* +ok: [node1] +ok: [node2] +ok: [ansible-1] +ok: [node3] + +TASK [Installer Apache sur les serveurs web] ******************************************* +skipping: [ansible-1] +ok: [node2] +ok: [node1] +ok: [node3] + +TASK [Installer firewalld] ******************************************************* +changed: [ansible-1] +changed: [node2] +changed: [node1] +changed: [node3] -## Étape 3 - Les boucles simples +TASK [S'assurer que firewalld est en cours d'exécution] ********************************************* +changed: [node3] +changed: [ansible-1] +changed: [node2] +changed: [node1] -Les boucles nous permettent de répéter la même tâche encore et encore. Par exemple, supposons que vous souhaitiez créer plusieurs utilisateurs. En utilisant une boucle Ansible, vous pouvez le faire en une seule tâche. Les boucles peuvent également parcourir plus que les listes de base. Par exemple, si vous avez une liste d'utilisateurs avec leur groupe correspondant, la boucle peut également les parcourir. En savoir plus sur les boucles dans la documentation [Ansible Loops](https://docs.ansible.com/ansible/latest/user_guide/playbooks_loops.html). +TASK [Autoriser le trafic HTTPS sur les serveurs web] ************************************** +skipping: [ansible-1] +changed: [node2] +changed: [node1] +changed: [node3] -Pour montrer la fonction des boucles, nous allons générer trois nouveaux utilisateurs sur `node1`. Pour cela, créez le fichier `loop_users.yml` dans `~/ansible-files` sur votre nœud de contrôle en tant qu'utilisateur student. Nous utiliserons le module `utilisateur` pour générer les comptes utilisateurs. +GESTIONNAIRE EN COURS [Recharger le Pare-feu] ********************************************** +changed: [node2] +changed: [node1] +changed: [node3] +COMPTE RENDU DU JEU ********************************************************************* +ansible-1 : ok=5 changed=2 unreachable=0 failed=0 skipped=2 rescued=0 ignored=0 +node1 : ok=8 changed=4 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 +node2 : ok=8 changed=4 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 +node3 : ok=8 changed=4 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 - -```yaml ---- -- name: Ensure users - hosts: node1 - become: yes - - tasks: - - name: Ensure three users are present - user: - name: "{{ item }}" - state: present - loop: - - dev_user - - qa_user - - prod_user ``` - - -Comprendre le playbook et la sortie: - - - - Les noms ne sont pas fournis directement au module utilisateur. Au lieu de cela, il n'y a qu'une variable appelée `{{item}}` pour le paramètre `name`. - - Le mot clé `loop` répertorie les noms d'utilisateur réels. Ceux-ci remplacent le `{{item}}` pendant l'exécution réelle du playbook. +### Étape 4 - Boucles - - Pendant l'exécution, la tâche n'est répertoriée qu'une seule fois, mais trois modifications sont répertoriées en dessous. - - -## Étape 4 - Les boucles complexes - -Comme mentionné, les boucles peuvent également se trouver sur des listes de hachages. Imaginez que les utilisateurs doivent être affectés à différents groupes supplémentaires: +Les boucles dans Ansible vous permettent d'effectuer une tâche plusieurs fois avec différentes valeurs. Cette fonctionnalité est particulièrement utile pour des tâches comme la création de plusieurs comptes utilisateurs dans notre exemple donné. +Dans le playbook system_setup.yml original de l'exercice 1.4, nous avions une tâche pour créer un seul utilisateur : ```yaml -- username: dev_user - groups: ftp -- username: qa_user - groups: ftp -- username: prod_user - groups: apache -``` +- name: Créer un nouvel utilisateur + ansible.builtin.user: + name: "{{ user_name }}" + state: present + create_home: true -Le module `user` a le paramètre optionnel `groups` pour l'assigner à un groupe. Pour référencer des éléments dans un hachage, le mot clé `{{item}}` doit référencer la sous-clé: `{{item.groups}}` par exemple. +``` -Réécrivons le playbook pour créer les utilisateurs avec des droits d'utilisateur supplémentaires: +Maintenant, modifions cette tâche pour créer plusieurs utilisateurs à l'aide d'une boucle : - ```yaml ---- -- name: Ensure users - hosts: node1 - become: yes +- name: Créer un nouvel utilisateur + ansible.builtin.user: + name: "{{ item }}" + state: present + create_home: true + loop: + - alice + - bob + - carol +``` - tasks: - - name: Ensure three users are present - user: - name: "{{ item.username }}" - state: present - groups: "{{ item.groups }}" - loop: - - { username: 'dev_user', groups: 'ftp' } - - { username: 'qa_user', groups: 'ftp' } - - { username: 'prod_user', groups: 'apache' } +Qu'est-ce qui a changé ? -``` - +1. Directive de Boucle : Le mot-clé loop est utilisé pour itérer sur une liste d'éléments. Dans ce cas, la liste contient les noms des utilisateurs que nous souhaitons créer : alice, bob et carol. -Vérifiez la sortie: +2. Création d'Utilisateurs avec Boucle : Au lieu de créer un seul utilisateur, la tâche modifiée itère maintenant sur chaque élément de la liste de boucle. Le placeholder `{{ item }}` est dynamiquement remplacé par chaque nom d'utilisateur dans la liste, de sorte que le module ansible.builtin.user crée chaque utilisateur à son tour. - - Encore une fois, la tâche est répertoriée une fois, mais trois modifications sont répertoriées. Chaque boucle avec son contenu est affichée. +Lorsque vous exécutez le playbook mis à jour, cette tâche est exécutée trois fois, une fois pour chaque utilisateur spécifié dans la boucle. C'est une manière efficace de gérer les tâches répétitives avec des données d'entrée variables. -Vérifiez que l'utilisateur `dev_user` a bien été créé sur `node1`: +Extrait de la sortie pour la création d'un nouvel utilisateur sur tous les nœuds. ```bash -[student@ansible ansible-files]$ ansible node1 -m command -a "id dev_user" -node1 | CHANGED | rc=0 >> -uid=1002(dev_user) gid=1002(dev_user) Gruppen=1002(dev_user),50(ftp) +[student@ansible-1 ~lab_inventory]$ ansible-navigator run system_setup.yml -m stdout + +PLAY [Configuration Système de Base] ****************************************************** + +. +. +. + +TASK [Créer un nouvel utilisateur] ******************************************************* +changed: [node2] => (item=alice) +changed: [ansible-1] => (item=alice) +changed: [node1] => (item=alice) +changed: [node3] => (item=alice) +changed: [node1] => (item=bob) +changed: [ansible-1] => (item=bob) +changed: [node3] => (item=bob) +changed: [node2] => (item=bob) +changed: [node1] => (item=carol) +changed: [node3] => (item=carol) +changed: [ansible-1] => (item=carol) +changed: [node2] => (item=carol) + +. +. +. + + +COMPTE RENDU DU JEU ********************************************************************* +ansible-1 : ok=5 changed=1 unreachable=0 failed=0 skipped=2 rescued=0 ignored=0 +node1 : ok=7 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 +node2 : ok=7 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 +node3 : ok=7 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 ``` + + ---- **Navigation**
[Exercise précédent](../1.4-variables/README.fr.md) - [Exercise suivant](../1.6-templates/README.fr.md) [Cliquez ici pour revenir à l'atelier Ansible pour Red Hat Enterprise Linux](../README.fr.md) + + diff --git a/exercises/ansible_rhel/1.5-handlers/README.ja.md b/exercises/ansible_rhel/1.5-handlers/README.ja.md index 00260bc47..3c9b866a7 100644 --- a/exercises/ansible_rhel/1.5-handlers/README.ja.md +++ b/exercises/ansible_rhel/1.5-handlers/README.ja.md @@ -1,303 +1,250 @@ -# ワークショップ演習 - 条件、ハンドラー、ループ +# ワークショップ演習 - 条件分岐、ハンドラー、ループ -**他の言語でもお読みいただけます**: -
![uk](../../../images/uk.png) [English](README.md)、![japan](../../../images/japan.png)[日本語](README.ja.md)、![brazil](../../../images/brazil.png) [Portugues do Brasil](README.pt-br.md)、![france](../../../images/fr.png) [Française](README.fr.md)、![Español](../../../images/col.png) [Español](README.es.md) +**他の言語で読む**: +
![uk](../../../images/uk.png) [英語](README.md), ![japan](../../../images/japan.png) [日本語](README.ja.md), ![brazil](../../../images/brazil.png) [ブラジルのポルトガル語](README.pt-br.md), ![france](../../../images/fr.png) [フランス語](README.fr.md), ![Español](../../../images/col.png) [スペイン語](README.es.md). + +# ワークショップ演習 - 条件分岐、ハンドラー、ループの使用 ## 目次 -* [目的](#目的) -* [ガイド](#ガイド) - * [ステップ 1 - 条件](#ステップ-1---条件) - * [ステップ 2 - ハンドラー](#ステップ-2---ハンドラー) - * [ステップ 3 - 簡単なループ](#ステップ-3---簡単なループ) - * [ステップ 4 - ハッシュのループ](#ステップ-4---ハッシュのループ) +- [目的](#目的) +- [ガイド](#ガイド) + - [ステップ 1 - 条件分岐、ハンドラー、ループの理解](#ステップ-1---条件分岐ハンドラーループの理解) + - [ステップ 2 - 条件分岐](#ステップ-2---条件分岐) + - [ステップ 3 - ハンドラー](#ステップ-3---ハンドラー) + - [ステップ 4 - ループ](#ステップ-4---ループ) ## 目的 -3 つの基本的な Ansible 機能は次のとおりです。 - -* [条件](https://docs.ansible.com/ansible/latest/user_guide/playbooks_conditionals.html) -* [ハンドラー](https://docs.ansible.com/ansible/latest/user_guide/playbooks_intro.html#handlers-running-operations-on-change) -* [ループ](https://docs.ansible.com/ansible/latest/user_guide/playbooks_loops.html) +演習 1.4 を基に、この演習では Ansible プレイブックでの条件分岐、ハンドラー、ループの応用を紹介します。条件分岐を使ったタスク実行の制御、ハンドラーを使ったサービス応答の管理、ループを使った繰り返しタスクの効率的な処理方法を学びます。 ## ガイド -### ステップ 1 - 条件 - -Ansible は条件を使用して、特定の条件が満たされたときにタスクまたは再生を実行できます。 - -条件を実装するには、`when` ステートメントを使用します。その後にテストする条件が続きます。条件は、たとえば比較のような利用可能なオペレーターのひとつを使って表現します。 - -| | | -| ---- | ---------------------------------------------------------------------- | -| \== | Compares two objects for equality. | -| \!= | Compares two objects for inequality. | -| \> | true if the left hand side is greater than the right hand side. | -| \>= | true if the left hand side is greater or equal to the right hand side. | -| \< | true if the left hand side is lower than the right hand side. | -| \<= | true if the left hand side is lower or equal to the right hand side. | - -詳細は、以下のドキュメントを参照してください。 - -例として、FTP サーバーをインストールしたいと思っていますが、「ftpserver」インベントリーグループにあるホストにのみにインストールしたいとします。 - -これを行うには、インベントリーを編集して別のグループを追加し、`node2` を配置します。追加するセクションは以下のとおりです。 - -``` ini -[ftpserver] -node2 -``` - -それらの行を追加するために `~/lab_inventory/hosts` を編集します。 完了すると、以下のリストのような表示になります。 - - +条件分岐、ハンドラー、ループは Ansible の高度な機能であり、自動化プレイブックの制御、効率、柔軟性を向上させます。 -> **ヒント** -> -> ansible_host 変数はノードに対して一度だけ指定する必要があります。 -> 他のグループへノードを追加する場合、再度変数を指定する必要はありません。 +### ステップ 1 - 条件分岐、ハンドラー、ループの理解 -**重要** 以下の例をコピー&ペーストしないでください。 ファイルを編集して、上記の行を追加するだけです。 +- **条件分岐**: 特定の条件に基づいてタスクを実行できるようにします。 +- **ハンドラー**: `notify` ディレクティブによってトリガーされる特別なタスクで、通常は変更後にサービスを再起動するために使用されます。 +- **ループ**: タスクを複数回繰り返し実行するために使用され、タスクが類似しているが異なるアイテムに適用する必要がある場合に特に便利です。 -```ini -[web] -node1 ansible_host=xx.xx.xx.xx -node2 ansible_host=xx.xx.xx.xx -node3 ansible_host=xx.xx.xx.xx +### ステップ 2 - 条件分岐 -[ftpserver] -node2 - -[control] -ansible-1 ansible_host=xx.xx.xx.xx -``` +Ansible の条件分岐は、特定の条件に基づいてタスクが実行されるかどうかを制御します。 +インベントリ内の `web` グループに属するホストにのみ Apache HTTP サーバー (`httpd`) をインストールする機能を system_setup.yml プレイブックに追加しましょう。 -次に、`~/ansible-files/` ディレクトリーのコントロールホストで `ftpserver.yml` ファイルを作成します。 +> 注: 以前の例ではホストを node1 に設定していましたが、現在は all に設定されています。これは、この更新された Ansible プレイブックを実行すると、自動化対象の新しいシステムの更新、新しいシステム上に作成されたユーザー Roger、web グループ内のすべてのホストにインストールされた Apache Web サーバーパッケージ httpd が表示されることを意味します。 ```yaml --- -- name: Install vsftpd on ftpservers +- name: 基本的なシステム設定 hosts: all become: true + vars: + user_name: 'Roger' + package_name: httpd tasks: - - name: Install FTP server when host in ftpserver group - yum: - name: vsftpd + - name: セキュリティ関連のパッケージをすべて更新 + ansible.builtin.dnf: + name: '*' state: latest - when: inventory_hostname in groups["ftpserver"] -``` - -> **ヒント** -> -> これで、Ansible Playbook の実行方法をご理解いただけたと思いますので、これからは説明を少し簡潔にしていき、作成して実行するというスタイルにします。 + security: true + update_only: true -そして、それを実行して結果を検証します。予期される結果: このタスクは、node1、node3、ansible ホスト (コントロールホスト)ではスキップされます。これは、インベントリーファイルの ftpserver グループに存在しないためです。 + - name: 新しいユーザーを作成 + ansible.builtin.user: + name: "{{ user_name }}" + state: present + create_home: true -```bash -TASK [Install FTP server when host in ftpserver group] ******************************************* -skipping: [ansible-1] -skipping: [node1] -skipping: [node3] -changed: [node2] + - name: Web サーバーに Apache をインストール + ansible.builtin.dnf: + name: "{{ package_name }}" + state: present + when: inventory_hostname in groups['web'] ``` -### ステップ 2 - ハンドラー - -タスクがシステムに変更を加える場合は時折、その他の単一のタスクまたは複数タスクを実行しなければならない場合があります。たとえば、サービスの設定ファイルを変更すると、変更した構成の有効化にサービスを再起動しなければならないことがあります。 - -ここで、Ansible のハンドラーが機能します。ハンドラーは、「notify」ステートメントを使用して明示的に呼び出された場合にのみトリガーされる非アクティブなタスクと見なすことができます。詳細は、[Ansible ハンドラー](http://docs.ansible.com/ansible/latest/playbooks_intro.html#handlers-running-operations-on-change) のドキュメントをご覧ください。 +この例では、`inventory_hostname in groups['web']` が条件文です。`inventory_hostname` はプレイブックで Ansible が作業している現在のホストの名前を指します。この条件は、このホストがインベントリファイルで定義された `web` グループの一部であるかどうかを確認します。真の場合、タスクが実行され、そのホストに Apache がインストールされます。 -例として、次のような playbook を作成しましょう。 +### ステップ 3 - ハンドラー -* `web` グループのすべてのホスト上で Apache の設定ファイル `/etc/httpd/conf/httpd.conf` を管理 -* ファイルが変更されたときに Apache を再起動 +ハンドラーは、別のタスクによって通知されたときにのみ実行されるべきタスクに使用されます。通常、設定変更後にサービスを再起動するために使用されます。 -まず、Ansible がデプロイするファイルが必要です。node1 からファイルを取得しましょう。以下のリストに示されている IP アドレスは、個人の `node1` の IP アドレスに置き換えることを忘れないでください。 - -```bash -[student@ansible-1 ansible-files]$ scp node1:/etc/httpd/conf/httpd.conf ~/ansible-files/files/. -httpd.conf -``` - -次に、Playbook `httpd_conf.yml` を作成します。ディレクトリー `~/ansible-files` にいることを確認してください。 +例えば、すべての Web サーバーでファイアウォールが正しく設定されていることを確認し、その後、新しい設定を適用するためにファイアウォールサービスをリロードしたいとしましょう。希望するファイアウォールルールが適切に設置されていることを確認するタスクによって通知されるファイアウォールサービスをリロードするハンドラーを定義します: ```yaml --- -- name: manage httpd.conf - hosts: web +- name: 基本的なシステム設定 + hosts: all become: true - tasks: - - name: Copy Apache configuration file - copy: - src: httpd.conf - dest: /etc/httpd/conf/ - notify: - - restart_apache - handlers: - - name: restart_apache - service: - name: httpd - state: restarted -``` - -さて、なにがこれまでと違うのでしょうか。 - -* 「notify」セクションは、コピータスクが実際にファイルを変更したときにのみハンドラーを呼び出します。そうすれば、そのサービスは必要なときだけ再起動され、プレイブックが実行されるたびに再起動されなくなります。 -* 「handlers」セクションは、通知時にのみ実行されるタスクを定義します。 - -
+ . + . + . + - name: firewalld をインストール + ansible.builtin.dnf: + name: firewalld + state: present -playbook を実行します。このファイルではまだ何も変更していないので `changed` の行は出力に表示されません。もちろん、ハンドラーは起動していません。 + - name: firewalld が実行中であることを確認 + ansible.builtin.service: + name: firewalld + state: started + enabled: true -* 今すぐ、`~/ansible-files/files/httpd.conf` の `Listen 80` を以下に変更します。 + - name: Web サーバーで HTTPS トラフィックを許可 + ansible.posix.firewalld: + service: https + permanent: true + state: enabled + when: inventory_hostname in groups['web'] + notify: ファイアウォールをリロード -```ini -Listen 8080 + handlers: + - name: ファイアウォールをリロード + ansible.builtin.service: + name: firewalld + state: reloaded ``` -* playbook を再び実行します。これで、Ansible の出力はもっと興味深いものになるはずです。 +「Web サーバーで HTTPS トラフィックを許可」タスクに変更がある場合にのみ、ハンドラー「ファイアウォールをリロード」がトリガーされます。 - * httpd.conf がコピーされているはずです - * ハンドラーは Apache を再起動しているはずです +> 注: 「ファイアウォールをリロード」設定タスクの notify セクション内でハンドラーの名前が使用されていることに注意してください。これにより、Ansible プレイブック内に複数のハンドラーが存在する場合でも、適切なハンドラーが実行されることが保証されます。 -Apache はポート 8080 でリッスンするはずです。確認は簡単です。 ```bash -[student@ansible-1 ansible-files]$ curl http://node1 -curl: (7) Failed to connect to node1 port 80: Connection refused -[student@ansible-1 ansible-files]$ curl http://node1:8080 - -

Apache is running fine

- -``` +PLAY [基本的なシステム設定] ****************************************************** -8080 番ポートでリッスンする設定のままにします。後でこれを使用します。 - -### ステップ 3 - 簡単なループ - -ループを使用すると、同じタスクを何度も繰り返すことができます。たとえば、複数のユーザーを作成するとします。Ansibleループを使用することで、1 つのタスクでそれを行うことができます。ループは、基本的なリスト以上のものを繰り返すこともできます。たとえば、対応するグループを持つユーザーのリストがある場合、ループはそれらを反復処理することもできます。ループの詳細については、[Ansible Loops](https://docs.ansible.com/ansible/latest/user_guide/playbooks_loops.html) のドキュメントをご覧ください。 +TASK [事実の収集] ********************************************************* +ok: [node1] +ok: [node2] +ok: [ansible-1] +ok: [node3] -ループ機能のデモとして、`node1` で 3 つの新しいユーザーをつくります。この作業用に、お使いの学習者ユーザーとしてコントロールノードの `~/ansible-files` に `loop_users.yml` ファイルを作成します。`user` モジュールを使用して、ユーザーアカウントを生成します。 +TASK [セキュリティ関連のパッケージをすべて更新] ************************************ +ok: [node2] +ok: [node1] +ok: [ansible-1] +ok: [node3] - +TASK [新しいユーザーを作成] ******************************************************* +ok: [node1] +ok: [node2] +ok: [ansible-1] +ok: [node3] -```yaml ---- -- name: Ensure users - hosts: node1 - become: true +TASK [Web サーバーに Apache をインストール] ******************************************* +skipping: [ansible-1] +ok: [node2] +ok: [node1] +ok: [node3] - tasks: - - name: Ensure three users are present - user: - name: "{{ item }}" - state: present - loop: - - dev_user - - qa_user - - prod_user -``` +TASK [firewalld をインストール] ******************************************************* +changed: [ansible-1] +changed: [node2] +changed: [node1] +changed: [node3] - +TASK [firewalld が実行中であることを確認] ********************************************* +changed: [node3] +changed: [ansible-1] +changed: [node2] +changed: [node1] -Playbook と出力の概要: +TASK [Web サーバーで HTTPS トラフィックを許可] ************************************** +skipping: [ansible-1] +changed: [node2] +changed: [node1] +changed: [node3] - +RUNNING HANDLER [ファイアウォールをリロード] ********************************************** +changed: [node2] +changed: [node1] +changed: [node3] -* この名前はユーザーモジュールに直接指定されません。代わりに、パラメーター `name` 用の `{{ item }}` と呼ばれる変数のみがあります -* `loop` キーワードは実際のユーザー名をリストします。これらは、Playbook を実際に実行しているときに `{{ item }}` を置き換えます。 -* 実行中、タスクは1回だけリストされますが、その下に 3 つの変更がリストされます。 +PLAY RECAP ********************************************************************* +ansible-1 : ok=5 changed=2 unreachable=0 failed=0 skipped=2 rescued=0 ignored=0 +node1 : ok=8 changed=4 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 +node2 : ok=8 changed=4 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 +node3 : ok=8 changed=4 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 - +``` -### ステップ 4 - ハッシュのループ +### ステップ 4 - ループ -前述のように、ループはハッシュのリストでも実行できます。ユーザーを別の追加グループに割り当てる必要があると想像してください。 +Ansible のループを使用すると、異なる値を使って複数回タスクを実行できます。この機能は、与えられた例のように複数のユーザーアカウントを作成するタスクなど、特に便利です。演習 1.4 からの元の system_setup.yml プレイブックでは、1人のユーザーを作成するタスクがありました: ```yaml -- username: dev_user - groups: ftp -- username: qa_user - groups: ftp -- username: prod_user - groups: apache +- name: 新しいユーザーを作成 + ansible.builtin.user: + name: "{{ user_name }}" + state: present + create_home: true ``` -`user` モジュールには、その他のユーザーを一覧表示するためのオプションのパラメーター `groups` があります。ハッシュでアイテムを参照するには、`{{ item }}` キーワードが、サブキーを参照する必要があります (例: `{{item.groups }}`)。 - -Playbook を書き直して、追加のユーザー権限を持つユーザーを作成しましょう。 - - +これで、ループを使用して複数のユーザーを作成するようにこのタスクを変更しましょう: ```yaml ---- -- name: Ensure users - hosts: node1 - become: true - - tasks: - - name: Ensure three users are present - user: - name: "{{ item.username }}" - state: present - groups: "{{ item.groups }}" - loop: - - { username: 'dev_user', groups: 'ftp' } - - { username: 'qa_user', groups: 'ftp' } - - { username: 'prod_user', groups: 'apache' } - +- name: 新しいユーザーを作成 + ansible.builtin.user: + name: "{{ item }}" + state: present + create_home: true + loop: + - alice + - bob + - carol ``` - +変更点は何ですか？ -出力を確認します。 +1. ループディレクティブ: ループキーワードは、アイテムのリストを繰り返し処理するために使用されます。この場合、リストには作成したいユーザーの名前が含まれています: alice、bob、および carol。 -* ここでも、タスクは 1 回リストされていますが、3 つの変更がリストされています。各ループとその内容が表示されます。 +2. ループを使ったユーザー作成: 1人のユーザーを作成する代わりに、変更されたタスクはループリストの各アイテムを繰り返し処理します。{{ item }} プレースホルダーはリスト内の各ユーザー名に動的に置き換えられるため、ansible.builtin.user モジュールは順番に各ユーザーを作成します。 -以下の Playbook を使用して、`dev_user` が `node1` で作成されたことを確認します。 +更新されたプレイブックを実行すると、このタスクはループ内の各ユーザーについて一度に実行されます。入力データが異なる繰り返しタスクを効率的に処理する方法です。 -{% raw %} -```yaml ---- -- name: Get user ID - hosts: node1 - vars: - myuser: "dev_user" - tasks: - - name: Get {{ myuser }} info - getent: - database: passwd - key: "{{ myuser }}" - - debug: - msg: - - "{{ myuser }} uid: {{ getent_passwd[myuser].1 }}" -``` -{% endraw %} +すべてのノードで新しいユーザーを作成するための出力のスニペットです。 ```bash -$ ansible-navigator run user_id.yml -m stdout +[student@ansible-1 ~lab_inventory]$ ansible-navigator run system_setup.yml -m stdout -PLAY [Get user ID] ************************************************************* +PLAY [基本的なシステム設定] ****************************************************** -TASK [Gathering Facts] ********************************************************* -ok: [node1] +. +. +. -TASK [Get dev_user info] ******************************************************* -ok: [node1] +TASK [新しいユーザーを作成] ******************************************************* +changed: [node2] => (item=alice) +changed: [ansible-1] => (item=alice) +changed: [node1] => (item=alice) +changed: [node3] => (item=alice) +changed: [node1] => (item=bob) +changed: [ansible-1] => (item=bob) +changed: [node3] => (item=bob) +changed: [node2] => (item=bob) +changed: [node1] => (item=carol) +changed: [node3] => (item=carol) +changed: [ansible-1] => (item=carol) +changed: [node2] => (item=carol) + +. +. +. -TASK [debug] ******************************************************************* -ok: [node1] => { - "msg": [ - "dev_user uid: 1002" - ] -} PLAY RECAP ********************************************************************* -node1 : ok=3 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 +ansible-1 : ok=5 changed=1 unreachable=0 failed=0 skipped=2 rescued=0 ignored=0 +node1 : ok=7 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 +node2 : ok=7 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 +node3 : ok=7 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 ``` + --- **ナビゲーション**
-[前の演習](../1.4-variables) - [次の演習](../1.6-templates) +[前の演習](../1.4-variables/README.ja.md) -[次の演習](../1.6-templates/README.ja.md) [Click here to return to the Ansible for Red Hat Enterprise Linux Workshop](../README.md#section-1---ansible-engine-exercises) + + diff --git a/exercises/ansible_rhel/1.5-handlers/README.md b/exercises/ansible_rhel/1.5-handlers/README.md index 560cc0ac0..19a474eb5 100644 --- a/exercises/ansible_rhel/1.5-handlers/README.md +++ b/exercises/ansible_rhel/1.5-handlers/README.md @@ -1,303 +1,249 @@ - -# Workshop Exercise - Conditionals, Handlers and Loops +# Workshop Exercise - Conditionals, Handlers and Loops **Read this in other languages**:
![uk](../../../images/uk.png) [English](README.md), ![japan](../../../images/japan.png)[日本語](README.ja.md), ![brazil](../../../images/brazil.png) [Portugues do Brasil](README.pt-br.md), ![france](../../../images/fr.png) [Française](README.fr.md),![Español](../../../images/col.png) [Español](README.es.md). - -## Table of Contents +# Workshop Exercises - Using Conditionals, Handlers, and Loops +## Table of Contents - [Objective](#objective) - [Guide](#guide) - - [Step 1 - Conditionals](#step-1---conditionals) - - [Step 2 - Handlers](#step-2---handlers) - - [Step 3 - Simple Loops](#step-3---simple-loops) - - [Step 4 - Loops over hashes](#step-4---loops-over-hashes) + - [Step 1 - Understanding Conditionals, Handlers, and Loops](#step-1---understanding-conditionals-handlers-and-loops) + - [Step 2 - Conditionals](#step-2---conditionals) + - [Step 3 - Handlers](#step-3---handlers) + - [Step 4 - Loops](#step-4---loops) ## Objective -Three foundational Ansible features are: - -* [Conditionals](https://docs.ansible.com/ansible/latest/user_guide/playbooks_conditionals.html) -* [Handlers](https://docs.ansible.com/ansible/latest/user_guide/playbooks_intro.html#handlers-running-operations-on-change) -* [Loops](https://docs.ansible.com/ansible/latest/user_guide/playbooks_loops.html) +Expanding on Exercise 1.4, this exercise introduces the application of conditionals, handlers, and loops in Ansible playbooks. You'll learn to control task execution with conditionals, manage service responses with handlers, and efficiently handle repetitive tasks using loops. ## Guide -### Step 1 - Conditionals - -Ansible can use conditionals to execute tasks or plays when certain conditions are met. - -To implement a conditional, the `when` statement must be used, followed by the condition to test. The condition is expressed using one of the available operators like e.g. for comparison: - -| | | -| ---- | ---------------------------------------------------------------------- | -| \== | Compares two objects for equality. | -| \!= | Compares two objects for inequality. | -| \> | true if the left hand side is greater than the right hand side. | -| \>= | true if the left hand side is greater or equal to the right hand side. | -| \< | true if the left hand side is lower than the right hand side. | -| \<= | true if the left hand side is lower or equal to the right hand side. | - -For more on this, please refer to the documentation: +Conditionals, handlers, and loops are advanced features in Ansible that enhance control, efficiency, and flexibility in your automation playbooks. -As an example you would like to install an FTP server, but only on hosts that are in the "ftpserver" inventory group. +### Step 1 - Understanding Conditionals, Handlers, and Loops -To do that, first edit the inventory to add another group, and place `node2` in it. The section to add looks like this: +- **Conditionals**: Enable tasks to be executed based on specific conditions. +- **Handlers**: Special tasks triggered by a `notify` directive, typically used for restarting services after changes. +- **Loops**: Used to repeat a task multiple times, particularly useful when the task is similar but needs to be applied to different items. -``` ini -[ftpserver] -node2 -``` - -Edit the inventory `~/lab_inventory/hosts` to add those lines. When you are done, it will look similar to the following listing: - -> **Tip** -> -> The ansible_host variable only needs to be specified once for a node. When adding a node to other groups, you do not need to -> specify the variable again. +### Step 2 - Conditionals -**Important** Do not copy/paste the example below. Just edit the file to add the above lines. +Conditionals in Ansible control whether a task should run based on certain conditions. +Let's add to the system_setup.yml playbook the ability to install the Apache HTTP Server (`httpd`) only on hosts that belong to the `web` group in our inventory. -```ini -[web] -node1 ansible_host=xx.xx.xx.xx -node2 ansible_host=xx.xx.xx.xx -node3 ansible_host=xx.xx.xx.xx - -[ftpserver] -node2 - -[control] -ansible-1 ansible_host=xx.xx.xx.xx -``` - -Next create the file `ftpserver.yml` on your control host in the `~/ansible-files/` directory: +> NOTE: Previous examples had hosts set to node1 but now it is set to all. This means when you run this updated Ansible playbook you will notice updates for the new systems being automated against, the user Roger created on all new systems and the Apache web server package httpd installed on all the hosts within the web group. ```yaml --- -- name: Install vsftpd on ftpservers +- name: Basic System Setup hosts: all become: true + vars: + user_name: 'Roger' + package_name: httpd tasks: - - name: Install FTP server when host in ftpserver group - ansible.builtin.yum: - name: vsftpd + - name: Update all security-related packages + ansible.builtin.dnf: + name: '*' state: latest - when: inventory_hostname in groups["ftpserver"] -``` - -> **Tip** -> -> By now you should know how to run Ansible Playbooks, we’ll start to be less verbose in this guide. Go create and run it. :-) + security: true + update_only: true -Run it and examine the output. The expected outcome: The task is skipped on node1, node3 and the ansible host (your control host) because they are not in the ftpserver group in your inventory file. + - name: Create a new user + ansible.builtin.user: + name: "{{ user_name }}" + state: present + create_home: true -```bash -TASK [Install FTP server when host in ftpserver group] ******************************************* -skipping: [ansible-1] -skipping: [node1] -skipping: [node3] -changed: [node2] + - name: Install Apache on web servers + ansible.builtin.dnf: + name: "{{ package_name }}" + state: present + when: inventory_hostname in groups['web'] ``` -### Step 2 - Handlers - -Sometimes when a task does make a change to the system, an additional task or tasks may need to be run. For example, a change to a service’s configuration file may then require that the service be restarted so that the changed configuration takes effect. - -Here Ansible’s handlers come into play. Handlers can be seen as inactive tasks that only get triggered when explicitly invoked using the "notify" statement. Read more about them in the [Ansible Handlers](http://docs.ansible.com/ansible/latest/playbooks_intro.html#handlers-running-operations-on-change) documentation. +In this example, `inventory_hostname in groups['web']` is the conditional statement. `inventory_hostname` refers to the name of the current host that Ansible is working on in the playbook. The condition checks if this host is part of the `web` group defined in your inventory file. If true, the task will execute and install Apache on that host. -As a an example, let’s write a playbook that: +### Step 3 - Handlers -* manages Apache’s configuration file `/etc/httpd/conf/httpd.conf` on all hosts in the `web` group -* restarts Apache when the file has changed +Handlers are used for tasks that should only run when notified by another task. Typically, they are used to restart services after a configuration change. -First we need the file Ansible will deploy, let’s just take the one from node1. Remember to replace the IP address shown in the listing below with the IP address from your individual `node1`. - -```bash -[student@ansible-1 ansible-files]$ scp node1:/etc/httpd/conf/httpd.conf ~/ansible-files/files/. -httpd.conf -``` +Let's say we want to ensure the firewall is configured correctly on all web servers and then reload the firewall service to apply any new settings. We'll define a handler that reloads the firewall service and is notified by a task that ensures the desired firewall rules are in place: -Next, create the Playbook `httpd_conf.yml`. Make sure that you are in the directory `~/ansible-files`. ```yaml --- -- name: Manage httpd.conf - hosts: web +- name: Basic System Setup + hosts: all become: true - tasks: + . + . + . + - name: Install firewalld + ansible.builtin.dnf: + name: firewalld + state: present - - name: Copy Apache configuration file - ansible.builtin.copy: - src: httpd.conf - dest: /etc/httpd/conf/ - mode: '644' - notify: - - Restart_apache + - name: Ensure firewalld is running + ansible.builtin.service: + name: firewalld + state: started + enabled: true + + - name: Allow HTTPS traffic on web servers + ansible.posix.firewalld: + service: https + permanent: true + state: enabled + when: inventory_hostname in groups['web'] + notify: Reload Firewall handlers: - - name: Restart_apache + - name: Reload Firewall ansible.builtin.service: - name: httpd - state: restarted -``` - -So what’s new here? - -* The "notify" section calls the handler only when the copy task actually changes the file. That way the service is only restarted if needed - and not each time the playbook is run. -* The "handlers" section defines a task that is only run on notification. + name: firewalld + state: reloaded -
+``` -Run the playbook. We didn’t change anything in the file yet so there should not be any `changed` lines in the output and of course the handler shouldn’t have fired. +The handler Restart Apache is triggered only if the task “Allow HTTPS traffic on web servers” makes any changes. -* Now change the `Listen 80` line in `~/ansible-files/files/httpd.conf` to: +> NOTE: Notice how the name of the handler is used within the notify section of the “Reload Firewall” configuration task. This ensures that the proper handler is executed as there can be multiple handlers within an Ansible playbook. -```ini -Listen 8080 ``` +PLAY [Basic System Setup] ****************************************************** -* Run the playbook again. Now the Ansible’s output should be a lot more interesting: - - * httpd.conf should have been copied over - * The handler should have restarted Apache +TASK [Gathering Facts] ********************************************************* +ok: [node1] +ok: [node2] +ok: [ansible-1] +ok: [node3] -Apache should now listen on port 8080. Easy enough to verify: +TASK [Update all security-related packages] ************************************ +ok: [node2] +ok: [node1] +ok: [ansible-1] +ok: [node3] -```bash -[student@ansible-1 ansible-files]$ curl http://node1 -curl: (7) Failed to connect to node1 port 80: Connection refused -[student@ansible-1 ansible-files]$ curl http://node1:8080 - -

Apache is running fine

- -``` +TASK [Create a new user] ******************************************************* +ok: [node1] +ok: [node2] +ok: [ansible-1] +ok: [node3] -Leave the setting for listen on port 8080. We'll use this in a later exercise. +TASK [Install Apache on web servers] ******************************************* +skipping: [ansible-1] +ok: [node2] +ok: [node1] +ok: [node3] -### Step 3 - Simple Loops +TASK [Install firewalld] ******************************************************* +changed: [ansible-1] +changed: [node2] +changed: [node1] +changed: [node3] -Loops enable us to repeat the same task over and over again. For example, lets say you want to create multiple users. By using an Ansible loop, you can do that in a single task. Loops can also iterate over more than just basic lists. For example, if you have a list of users with their coresponding group, loop can iterate over them as well. Find out more about loops in the [Ansible Loops](https://docs.ansible.com/ansible/latest/user_guide/playbooks_loops.html) documentation. +TASK [Ensure firewalld is running] ********************************************* +changed: [node3] +changed: [ansible-1] +changed: [node2] +changed: [node1] -To show the loops feature we will generate three new users on `node1`. For that, create the file `loop_users.yml` in `~/ansible-files` on your control node as your student user. We will use the `user` module to generate the user accounts. +TASK [Allow HTTPS traffic on web servers] ************************************** +skipping: [ansible-1] +changed: [node2] +changed: [node1] +changed: [node3] - +RUNNING HANDLER [Reload Firewall] ********************************************** +changed: [node2] +changed: [node1] +changed: [node3] -```yaml ---- -- name: Ensure users - hosts: node1 - become: true +PLAY RECAP ********************************************************************* +ansible-1 : ok=5 changed=2 unreachable=0 failed=0 skipped=2 rescued=0 ignored=0 +node1 : ok=8 changed=4 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 +node2 : ok=8 changed=4 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 +node3 : ok=8 changed=4 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 - tasks: - - name: Ensure three users are present - ansible.builtin.user: - name: "{{ item }}" - state: present - loop: - - dev_user - - qa_user - - prod_user ``` - +### Step 4 - Loops -Understand the playbook and the output: +Loops in Ansible allow you to perform a task multiple times with different values. This feature is particularly useful for tasks like creating multiple user accounts in our given example. +In the original system_setup.yml playbook from Exercise 1.4, we had a task for creating a single user: - -* The names are not provided to the user module directly. Instead, there is only a variable called `{{ item }}` for the parameter `name`. -* The `loop` keyword lists the actual user names. Those replace the `{{ item }}` during the actual execution of the playbook. -* During execution the task is only listed once, but there are three changes listed underneath it. - - +```yaml +- name: Create a new user + ansible.builtin.user: + name: "{{ user_name }}" + state: present + create_home: true -### Step 4 - Loops over hashes +``` -As mentioned loops can also be over lists of hashes. Imagine that the users should be assigned to different additional groups: +Now, let's modify this task to create multiple users using a loop: ```yaml -- username: dev_user - groups: ftp -- username: qa_user - groups: ftp -- username: prod_user - groups: apache +- name: Create a new user + ansible.builtin.user: + name: "{{ item }}" + state: present + create_home: true + loop: + - alice + - bob + - carol ``` -The `user` module has the optional parameter `groups` to list additional users. To reference items in a hash, the `{{ item }}` keyword needs to reference the subkey: `{{ item.groups }}` for example. +What Changed? -Let's rewrite the playbook to create the users with additional user rights: +1. Loop Directive: The loop keyword is used to iterate over a list of items. In this case, the list contains the names of users we want to create: alice, bob, and carol. - +2. User Creation with Loop: Instead of creating a single user, the modified task now iterates over each item in the loop list. The `{{ item }}` placeholder is dynamically replaced with each username in the list, so the ansible.builtin.user module creates each user in turn. -```yaml ---- -- name: Ensure users - hosts: node1 - become: true +When you run the updated playbook, this task is executed three times, once for each user specified in the loop. It's an efficient way to handle repetitive tasks with varying input data. - tasks: - - name: Ensure three users are present - ansible.builtin.user: - name: "{{ item.username }}" - state: present - groups: "{{ item.groups }}" - loop: - - { username: 'dev_user', groups: 'ftp' } - - { username: 'qa_user', groups: 'ftp' } - - { username: 'prod_user', groups: 'apache' } +Snippet of the output for creating a new user on all the nodes. ``` +[student@ansible-1 ~lab_inventory]$ ansible-navigator run system_setup.yml -m stdout - +PLAY [Basic System Setup] ****************************************************** -Check the output: - -* Again the task is listed once, but three changes are listed. Each loop with its content is shown. - -Verify that the user `dev_user` was indeed created on `node1` using the following playbook: - -{% raw %} -```yaml ---- -- name: Get user ID - hosts: node1 - vars: - myuser: "dev_user" - tasks: - - name: Get {{ myuser }} info - ansible.builtin.getent: - database: passwd - key: "{{ myuser }}" - - ansible.builtin.debug: - msg: - - "{{ myuser }} uid: {{ getent_passwd[myuser].1 }}" -``` -{% endraw %} +. +. +. -```bash -$ ansible-navigator run user_id.yml -m stdout +TASK [Create a new user] ******************************************************* +changed: [node2] => (item=alice) +changed: [ansible-1] => (item=alice) +changed: [node1] => (item=alice) +changed: [node3] => (item=alice) +changed: [node1] => (item=bob) +changed: [ansible-1] => (item=bob) +changed: [node3] => (item=bob) +changed: [node2] => (item=bob) +changed: [node1] => (item=carol) +changed: [node3] => (item=carol) +changed: [ansible-1] => (item=carol) +changed: [node2] => (item=carol) -PLAY [Get user ID] ************************************************************* +. +. +. -TASK [Gathering Facts] ********************************************************* -ok: [node1] -TASK [Get dev_user info] ******************************************************* -ok: [node1] +PLAY RECAP ********************************************************************* +ansible-1 : ok=5 changed=1 unreachable=0 failed=0 skipped=2 rescued=0 ignored=0 +node1 : ok=7 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 +node2 : ok=7 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 +node3 : ok=7 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 -TASK [debug] ******************************************************************* -ok: [node1] => { - "msg": [ - "dev_user uid: 1002" - ] -} -PLAY RECAP ********************************************************************* -node1 : ok=3 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 ``` --- **Navigation** diff --git a/exercises/ansible_rhel/1.5-handlers/README.pt-br.md b/exercises/ansible_rhel/1.5-handlers/README.pt-br.md index 4afa9072e..cf6d69386 100644 --- a/exercises/ansible_rhel/1.5-handlers/README.pt-br.md +++ b/exercises/ansible_rhel/1.5-handlers/README.pt-br.md @@ -1,235 +1,250 @@ -# Exercício - Condicionais, Handlers and Loops +# Exercício do Workshop - Condicionais, Manipuladores e Loops -**Leia em outras linguagens**: -
![uk](../../../images/uk.png) [English](README.md), ![japan](../../../images/japan.png)[日本語](README.ja.md), ![brazil](../../../images/brazil.png) [Portugues do Brasil](README.pt-br.md), ![france](../../../images/fr.png) [Française](README.fr.md),![Español](../../../images/col.png) [Español](README.es.md). +**Leia isto em outros idiomas**: +
![uk](../../../images/uk.png) [Inglês](README.md), ![japan](../../../images/japan.png) [Japonês](README.ja.md), ![brazil](../../../images/brazil.png) [Português do Brasil](README.pt-br.md), ![france](../../../images/fr.png) [Francês](README.fr.md), ![Español](../../../images/col.png) [Espanhol](README.es.md). -* [Passo 1 - Condicionais](#passo-1---condicionais) -* [Passo 2 - Handlers](#passo-2---handlers) -* [Passo 3 - Loops simples](#passo-3---loops-simples) -* [Passo 4 - Loops sobre hashes](#passo-4---loops-sobre-hashes) +# Exercícios do Workshop - Usando Condicionais, Manipuladores e Loops -## Passo 1 - Condicionais +## Índice -O Ansible pode usar condicionais para executar tasks ou plays quando determinadas condições forem atendidas. +- [Objetivo](#objetivo) +- [Guia](#guia) + - [Passo 1 - Entendendo Condicionais, Manipuladores e Loops](#passo-1---entendendo-condicionais-manipuladores-e-loops) + - [Passo 2 - Condicionais](#passo-2---condicionais) + - [Passo 3 - Manipuladores](#passo-3---manipuladores) + - [Passo 4 - Loops](#passo-4---loops) -Para implementar uma condicional, a instrução `when` deve ser usada, seguida pela condição. A condição é expressa usando um dos operadores disponíveis, como por exemplo para comparação: +## Objetivo -| | | -| ---- | ---------------------------------------------------------------------- | -| \== | Compara se dois objetos são iguais. | -| \!= | Compara se dois objetos não são iguais. | -| \> | Verdadeiro se um objeto for maior que o outro. | -| \>= | Verdadeiro se um objeto for maior ou igual ao outro. | -| \< | Verdadeiro se um objeto for menor que o outro. | -| \< = | Verdadeiro se um objeto for menor ou igual ao outro. | +Expandindo o Exercício 1.4, este exercício introduz a aplicação de condicionais, manipuladores e loops em playbooks Ansible. Você aprenderá a controlar a execução de tarefas com condicionais, gerenciar respostas de serviços com manipuladores e lidar eficientemente com tarefas repetitivas usando loops. -Para mais informações, consulte a documentação: +## Guia -Como exemplo, você gostaria de instalar um servidor FTP, apenas em hosts que estão no grupo de inventário "ftpserver". +Condicionais, manipuladores e loops são recursos avançados no Ansible que aumentam o controle, a eficiência e a flexibilidade em seus playbooks de automação. -Para fazer isso, edite primeiro o inventário para adicionar outro grupo e coloque o `node2` nele. Certifique-se de que o endereço IP do `node2` seja sempre o mesmo quando o `node2` estiver listado. Edite o inventário `~/lab_inventory/hosts`, ele deve ficar semelhante a: +### Passo 1 - Entendendo Condicionais, Manipuladores e Loops -```ini -[web] -node1 ansible_host=11.22.33.44 -node2 ansible_host=22.33.44.55 -node3 ansible_host=33.44.55.66 +- **Condicionais**: Permitem que tarefas sejam executadas com base em condições específicas. +- **Manipuladores**: Tarefas especiais acionadas por uma diretiva `notify`, normalmente usadas para reiniciar serviços após alterações. +- **Loops**: Usados para repetir uma tarefa várias vezes, particularmente útil quando a tarefa é semelhante, mas precisa ser aplicada a itens diferentes. -[ftpserver] -node2 ansible_host=22.33.44.55 +### Passo 2 - Condicionais -[control] -ansible ansible_host=44.55.66.77 -``` +Condicionais no Ansible controlam se uma tarefa deve ser executada com base em certas condições. +Vamos adicionar ao playbook system_setup.yml a capacidade de instalar o Servidor HTTP Apache (`httpd`) apenas nos hosts que pertencem ao grupo `web` no nosso inventário. -Depois, crie o arquivo `ftpserver.yml` no seu host de controle no diretório `~/ansible-files/`: +> NOTA: Exemplos anteriores tinham hosts configurados como node1, mas agora está configurado para todos. Isso significa que, ao executar este playbook Ansible atualizado, você notará atualizações para os novos sistemas sendo automatizados, o usuário Roger criado em todos os novos sistemas e o pacote do servidor web Apache httpd instalado em todos os hosts dentro do grupo web. ```yaml --- -- name: Instalar vsftpd no ftpserver +- name: Configuração Básica do Sistema hosts: all - become: yes + become: true + vars: + user_name: 'Roger' + package_name: httpd tasks: - - name: Instalar servidor FTP quando host fizer parte do grupo ftpserver - yum: - name: vsftpd + - name: Atualizar todos os pacotes relacionados à segurança + ansible.builtin.dnf: + name: '*' state: latest - when: inventory_hostname in groups["ftpserver"] -``` - -> **Dica** -> -> Agora você já deve saber como executar um playbook do Ansible, por isso começaremos a ser menos detalhados neste guia. Crie o playbook e execute-o. :-) + security: true + update_only: true -Execute-o e examine a saída. O resultado esperado: a task é ignorada no node1, node3 e no host ansible (seu host de controle) porque eles não estão no grupo ftpserver no seu arquivo de inventário. + - name: Criar um novo usuário + ansible.builtin.user: + name: "{{ user_name }}" + state: present + create_home: true -```bash -TASK [Instalar servidor FTP quando host fizer parte do grupo ftpserver] ******************************************* -skipping: [ansible] -skipping: [node1] -skipping: [node3] -changed: [node2] + - name: Instalar o Apache em servidores web + ansible.builtin.dnf: + name: "{{ package_name }}" + state: present + when: inventory_hostname in groups['web'] ``` -## Passo 2 - Handlers - -As vezes, quando uma task faz uma alteração no sistema, pode ser necessário executar uma task ou tasks adicionais. Por exemplo, uma alteração no arquivo de configuração de um serviço pode exigir que o serviço seja reiniciado para que a configuração alterada entre em vigor. - -Aqui, os handlers entram em cena. Os handlers podem ser vistos como tasks inativas que só são acionadas quando invocadas explicitamente usando a instrução "notify". Leia mais sobre eles na documentação [Ansible Handlers](http://docs.ansible.com/ansible/latest/playbooks_intro.html#handlers-running-operations-on-change). +Neste exemplo, `inventory_hostname in groups['web']` é a declaração condicional. `inventory_hostname` refere-se ao nome do host atual em que o Ansible está trabalhando no playbook. A condição verifica se este host faz parte do grupo `web` definido no seu arquivo de inventário. Se verdadeiro, a tarefa será executada e o Apache será instalado nesse host. -Como exemplo, vamos escrever um Playbook que: +### Passo 3 - Manipuladores - - Gerencia o arquivo de configuração do Apache `httpd.conf` em todos os hosts no grupo `web`. +Manipuladores são usados para tarefas que só devem ser executadas quando notificadas por outra tarefa. Tipicamente, eles são usados para reiniciar serviços após uma mudança de configuração. - - Reinicia o Apache quando o arquivo é alterado. - -Primeiro, precisamos que o arquivo Ansible seja implantado, vamos pegar node1. Lembre-se de substituir o endereço IP mostrado na lista abaixo pelo endereço IP do seu `node1` individual. - -```bash -[student@ansible ansible-files]$ scp 11.22.33.44:/etc/httpd/conf/httpd.conf ~/ansible-files/. -student@11.22.33.44's password: -httpd.conf -``` - -Depois, crie o playbook `httpd_conf.yml`. Verifique se você está no diretório `~/ansible-files`. +Vamos supor que queremos garantir que o firewall esteja configurado corretamente em todos os servidores web e, em seguida, recarregar o serviço de firewall para aplicar quaisquer novas configurações. Vamos definir um manipulador que recarrega o serviço de firewall e é notificado por uma tarefa que garante que as regras de firewall desejadas estejam em vigor: ```yaml --- -- name: Manage httpd.conf - hosts: web - become: yes - tasks: - - name: Copiar arquivo de configuracao do Apache - copy: - src: httpd.conf - dest: /etc/httpd/conf/ - notify: - - restart_apache - handlers: - - name: restart_apache - service: - name: httpd - state: restarted -``` - -Então, o que há de novo aqui? - - - A seção "notify" chama o handler somente quando a task de cópia realmente altera o arquivo. Dessa forma, o serviço será reiniciado apenas se necessário - e não sempre que o playbook for executado. - - - A seção "handlers" define uma task que é executada apenas na notificação. +- name: Configuração Básica do Sistema + hosts: all + become: true + . + . + . + - name: Instalar firewalld + ansible.builtin.dnf: + name: firewalld + state: present -Execute o Playbook. Ainda não alteramos nada no arquivo, portanto, não deve haver linhas 'alteradas' na saída e o manipulador não deveria ter disparado. + - name: Garantir que o firewalld esteja em execução + ansible.builtin.service: + name: firewalld + state: started + enabled: true - - Agora mude a linha `Listen 80` no httpd.conf para: + - name: Permitir tráfego HTTPS em servidores web + ansible.posix.firewalld: + service: https + permanent: true + state: enabled + when: inventory_hostname in groups['web'] + notify: Recarregar Firewall + handlers: + - name: Recarregar Firewall + ansible.builtin.service: + name: firewalld + state: reloaded -```ini -Listen 8080 ``` - - Execute o Playbook novamente. Agora a saída do Ansible deve ser muito mais interessante: +O manipulador Recarregar Firewall é acionado apenas se a tarefa "Permitir tráfego HTTPS em servidores web" fizer alguma mudança. - - httpd.conf deve ter sido copiado. +> NOTA: Observe como o nome do manipulador é usado na seção `notify` da tarefa de configuração "Recarregar Firewall". Isso garante que o manipulador correto seja executado, pois pode haver vários manipuladores dentro de um playbook Ansible. - - O handler deve ter reiniciado o Apache. - -O Apache agora deve escutar na porta 8080. Fácil o suficiente para verificar: ```bash -[student1@ansible ansible-files]$ curl http://22.33.44.55 -curl: (7) Failed connect to 22.33.44.55:80; Connection refused -[student1@ansible ansible-files]$ curl http://22.33.44.55:8080 - -

Esse eh um servidor web de producao, tenha cuidado!

- -``` -Sinta-se livre para alterar o arquivo httpd.conf novamente e executar o Playbook. +PLAY [Configuração Básica do Sistema] ****************************************************** + +TASK [Coletando Fatos] ********************************************************* +ok: [node1] +ok: [node2] +ok: [ansible-1] +ok: [node3] + +TASK [Atualizar todos os pacotes relacionados à segurança] ************************************ +ok: [node2] +ok: [node1] +ok: [ansible-1] +ok: [node3] + +TASK [Criar um novo usuário] ******************************************************* +ok: [node1] +ok: [node2] +ok: [ansible-1] +ok: [node3] + +TASK [Instalar o Apache em servidores web] ******************************************* +skipping: [ansible-1] +ok: [node2] +ok: [node1] +ok: [node3] + +TASK [Instalar firewalld] ******************************************************* +changed: [ansible-1] +changed: [node2] +changed: [node1] +changed: [node3] -## Passo 3 - Loops simples +TASK [Garantir que o firewalld esteja em execução] ********************************************* +changed: [node3] +changed: [ansible-1] +changed: [node2] +changed: [node1] -Os loops nos permitem repetir a mesma task. Por exemplo, digamos que você queira criar vários usuários. Usando um loop, você pode fazer isso em uma única task. Os loops também podem iterar mais do que apenas listas básicas. Por exemplo, se você tiver uma lista de usuários com seu grupo de correspondência, o loop também poderá iterar sobre eles. Saiba mais sobre loops na documentação [Ansible Loops](https://docs.ansible.com/ansible/latest/user_guide/playbooks_loops.html). +TASK [Permitir tráfego HTTPS em servidores web] ************************************** +skipping: [ansible-1] +changed: [node2] +changed: [node1] +changed: [node3] -Para mostrar o recurso de loops, geramos três novos usuários no `node1`. Para isso, crie o arquivo `loop_users.yml` em `~/ansible-files` no seu nó de controle com seu usuário student. Usaremos o módulo `user` para gerar as contas de usuário. +MANIPULADOR EM EXECUÇÃO [Recarregar Firewall] ********************************************** +changed: [node2] +changed: [node1] +changed: [node3] - -```yaml ---- -- name: Garantir usuarios - hosts: node1 - become: yes +RECAPITULAÇÃO DO JOGO ********************************************************************* +ansible-1 : ok=5 changed=2 unreachable=0 failed=0 skipped=2 rescued=0 ignored=0 +node1 : ok=8 changed=4 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 +node2 : ok=8 changed=4 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 +node3 : ok=8 changed=4 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 - tasks: - - name: Garantir a presenca de tres usuarios - user: - name: "{{ item }}" - state: present - loop: - - dev_user - - qa_user - - prod_user ``` - - -Entenda o playbook e a saída: - - - - Os nomes não são fornecidos diretamente ao módulo do usuário. Em vez disso, existe apenas uma variável chamada `{{ item }}` para o parâmetro `name`. - - A palavra-chave `loop` lista os nomes de usuário reais. O `{{ item }}` é substituido durante a execução real do Playbook. +### Passo 4 - Loops - - Durante a execução, a task é listada apenas uma vez, mas há três alterações listadas abaixo dela. - - -## Passo 4 - Loops sobre hashes - -Como mencionado, os loops também podem estar sobre listas de hashes. Imagine que os usuários devam ser atribuídos a diferentes grupos adicionais: +Loops no Ansible permitem que você execute uma tarefa várias vezes com diferentes valores. Este recurso é particularmente útil para tarefas como a criação de várias contas de usuário, como no exemplo dado. No playbook original system_setup.yml do Exercício 1.4, tínhamos uma tarefa para criar um único usuário: ```yaml -- username: dev_user - groups: ftp -- username: qa_user - groups: ftp -- username: prod_user - groups: apache +- name: Criar um novo usuário + ansible.builtin.user: + name: "{{ user_name }}" + state: present + create_home: true ``` -O módulo `user` possui o parâmetro opcional `groups` para listar usuários adicionais. Para referenciar itens em um hash, a palavra-chave `{{ item }}` precisa fazer referência à subchave: `{{ item.groups }}` por exemplo. - -Vamos reescrever o Playbook para criar os usuários com direitos adicionais: +Agora, vamos modificar essa tarefa para criar vários usuários usando um loop: - ```yaml ---- -- name: Garantir usuarios - hosts: node1 - become: yes +- name: Criar um novo usuário + ansible.builtin.user: + name: "{{ item }}" + state: present + create_home: true + loop: + - alice + - bob + - carol +``` - tasks: - - name: Garantir a presenca de tres usuarios - user: - name: "{{ item.username }}" - state: present - groups: "{{ item.groups }}" - loop: - - { username: 'dev_user', groups: 'ftp' } - - { username: 'qa_user', groups: 'ftp' } - - { username: 'prod_user', groups: 'apache' } +O que mudou? -``` - +1. Diretiva Loop: A palavra-chave loop é usada para iterar sobre uma lista de itens. Neste caso, a lista contém os nomes dos usuários que queremos criar: alice, bob e carol. -Verifique a saída: +2. Criação de Usuário com Loop: Em vez de criar um único usuário, a tarefa modificada agora itera sobre cada item na lista do loop. O espaço reservado `{{ item }}` é substituído dinamicamente por cada nome de usuário na lista, de modo que o módulo ansible.builtin.user cria cada usuário por vez. - - Novamente, a task é listada uma vez, mas três alterações são listadas. Cada loop com seu conteúdo é mostrado. +Quando você executa o playbook atualizado, essa tarefa é executada três vezes, uma para cada usuário especificado no loop. É uma maneira eficiente de lidar com tarefas repetitivas com dados de entrada variáveis. -Verifique se o usuário `prod_user` foi realmente criado no `node1`: +Trecho da saída para a criação de um novo usuário em todos os nós. ```bash -[student@ansible ansible-files]$ ansible node1 -m command -a "id dev_user" -node1 | CHANGED | rc=0 >> -uid=1002(dev_user) gid=1002(dev_user) Gruppen=1002(dev_user),50(ftp) +[student@ansible-1 ~lab_inventory]$ ansible-navigator run system_setup.yml -m stdout + +PLAY [Configuração Básica do Sistema] ****************************************************** + +. +. +. + +TASK [Criar um novo usuário] ******************************************************* +changed: [node2] => (item=alice) +changed: [ansible-1] => (item=alice) +changed: [node1] => (item=alice) +changed: [node3] => (item=alice) +changed: [node1] => (item=bob) +changed: [ansible-1] => (item=bob) +changed: [node3] => (item=bob) +changed: [node2] => (item=bob) +changed: [node1] => (item=carol) +changed: [node3] => (item=carol) +changed: [ansible-1] => (item=carol) +changed: [node2] => (item=carol) + +. +. +. + +RECAPITULAÇÃO DO JOGO ********************************************************************* +ansible-1 : ok=5 changed=1 unreachable=0 failed=0 skipped=2 rescued=0 ignored=0 +node1 : ok=7 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 +node2 : ok=7 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 +node3 : ok=7 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 ``` ----- +--- +**Navegação** +
+[Exercício Anterior](../1.4-variables/README.pt-br.md) - [Próximo Exercício](../1.6-templates/READMW.pt-br.md) + +[Clique aqui para retornar ao Workshop de Ansible para Red Hat Enterprise Linux](../README.md#section-1---ansible-engine-exercises) + -[Clique aqui para retornar ao Workshop Ansible for Red Hat Enterprise Linux](../README.pt-br.md#seção-1---exercícios-do-ansible-engine) diff --git a/exercises/ansible_rhel/1.6-templates/README.es.md b/exercises/ansible_rhel/1.6-templates/README.es.md index fde52080e..fe3dcd35c 100644 --- a/exercises/ansible_rhel/1.6-templates/README.es.md +++ b/exercises/ansible_rhel/1.6-templates/README.es.md @@ -1,121 +1,114 @@ -# Workshop - Plantillas +# Ejercicio de Taller - Plantillas -**Read this in other languages**: -
![uk](../../../images/uk.png) [English](README.md), ![japan](../../../images/japan.png)[日本語](README.ja.md), ![brazil](../../../images/brazil.png) [Portugues do Brasil](README.pt-br.md), ![france](../../../images/fr.png) [Française](README.fr.md),![Español](../../../images/col.png) [Español](README.es.md). +**Leer esto en otros idiomas**: +
![uk](../../../images/uk.png) [Inglés](README.md), ![japan](../../../images/japan.png) [Japonés](README.ja.md), ![brazil](../../../images/brazil.png) [Portugués de Brasil](README.pt-br.md), ![france](../../../images/fr.png) [Francés](README.fr.md), ![Español](../../../images/col.png) [Español](README.es.md). -## Tabla de contenidos +## Tabla de Contenidos -* [Objetivos](#Objetivos) -* [Guía](#Guía) -* [Paso 1 - Uso de plantillas en Playbooks](#Paso-1---Uso-de-plantillas-en-Playbooks) -* [Paso 2 - Laboratorios de desafío](#Paso-2---Laboratorios-de-desafío) +- [Objetivo](#objetivo) +- [Guía](#guía) + - [Paso 1 - Introducción a las Plantillas Jinja2](#paso-1---introducción-a-las-plantillas-jinja2) + - [Paso 2 - Creando Tu Primera Plantilla](#paso-2---creando-tu-primera-plantilla) + - [Paso 3 - Desplegando la Plantilla con un Playbook](#paso-3---desplegando-la-plantilla-con-un-playbook) + - [Paso 4 - Ejecutando el Playbook](#paso-4---ejecutando-el-playbook) -# Objetivos +## Objetivo -Este ejercicio cubrirá las plantillas de Jinja2. Ansible utiliza plantillas de Jinja2 para modificar archivos antes de que se distribuyan a hosts administrados. Jinja2 es uno de los motores de plantillas más utilizados para Python (). +El Ejercicio 1.5 introduce las plantillas Jinja2 dentro de Ansible, una característica poderosa para generar archivos dinámicos a partir de plantillas. Aprenderás cómo elaborar plantillas que incorporan datos específicos del host, permitiendo la creación de archivos de configuración personalizados para cada host gestionado. -# Guía +## Guía -## Paso 1 - Uso de plantillas en Playbooks +### Paso 1 - Introducción a las Plantillas Jinja2 -Cuando se ha creado una plantilla para un archivo, se puede implementar en los hosts administrados mediante el módulo `template`, que admite la transferencia de un archivo local desde el nodo de control a los hosts administrados. +Ansible utiliza Jinja2, un lenguaje de plantillas ampliamente utilizado para Python, permitiendo la generación de contenido dinámico dentro de los archivos. Esta capacidad es particularmente útil para configurar archivos que deben diferir de un host a otro. -Como ejemplo de uso de plantillas, cambiará el archivo motd para que contenga datos específicos del host. +### Paso 2 - Creando Tu Primera Plantilla -En primer lugar, cree el directorio `templates` que contendrá los recursos de plantilla en `~/ansible-files/`: +Las plantillas terminan con una extensión `.j2` y mezclan contenido estático con marcadores de posición dinámicos encerrados en `{{ }}`. +En el siguiente ejemplo, vamos a crear una plantilla para el Mensaje del Día (MOTD) que incluye información dinámica del host. + +#### Configurar el Directorio de Plantillas: + +Asegúrate de que exista un directorio de plantillas dentro de tu directorio lab_inventory para organizar tus plantillas. ```bash -[student@ansible ansible-files]$ mkdir templates +mkdir -p ~/lab_inventory/templates ``` -A continuación, en el directorio `~/ansible-files/templates/`, cree el archivo de plantilla `motd-facts.j2`: - -```html+jinja -Welcome to {{ ansible_hostname }}. -{{ ansible_distribution }} {{ ansible_distribution_version}} -deployed on {{ ansible_architecture }} architecture. +#### Desarrollar la Plantilla MOTD: + +Crea un archivo llamado `motd.j2` en el directorio de plantillas con el siguiente contenido: + +```jinja +Bienvenido a {{ ansible_hostname }}. +SO: {{ ansible_distribution }} {{ ansible_distribution_version }} +Arquitectura: {{ ansible_architecture }} ``` - -El archivo de plantilla contiene el texto básico que se copiará más adelante. También contiene variables que se reemplazarán en las máquinas de destino individualmente. +Esta plantilla muestra dinámicamente el nombre del host, la distribución del SO, la versión y la arquitectura de cada host gestionado. -A continuación, necesitamos un playbook para usar esta plantilla. En el directorio `~/ansible-files/`, cree el Playbook `motd-facts.yml`: +### Paso 3 - Desplegando la Plantilla con un Playbook + +Utiliza el módulo `ansible.builtin.template` en un playbook para distribuir y renderizar la plantilla a través de tus hosts gestionados. + +Modifica el Playbook `system_setup.yml` con el siguiente contenido: ```yaml --- -- name: Fill motd file with host data - hosts: node1 +- name: Configuración Básica del Sistema + hosts: all become: true tasks: - - template: - src: motd-facts.j2 + - name: Actualizar MOTD desde Plantilla Jinja2 + ansible.builtin.template: + src: templates/motd.j2 dest: /etc/motd - owner: root - group: root - mode: 0644 + handlers: + - name: Recargar Firewall + ansible.builtin.service: + name: firewalld + state: reloaded ``` -Usted ha hecho esto un par de veces por ahora: - - - Entender lo que hace el Playbook. - - - Ejecutar el Playbook `motd-facts.yml`. - - - Inicie sesión en node1 a través de SSH y compruebe el mensaje del contenido del día. - - Cierre la sesión del nodo1. - -Debería ver cómo Ansible reemplaza las variables con los facts que descubrió del sistema. - -## Paso 2 - Laboratorios de desafío - -Agregue una línea a la plantilla para listar el kernel actual del nodo administrado. - - - Encuentra un fact que contenga la versión del kernel usando los comandos que aprendiste en el capítulo "Ansible Facts". +El módulo `ansible.builtin.template` toma la plantilla `motd.j2` y genera un archivo `/etc/motd` en cada host, llenando los marcadores de posición de la plantilla con los hechos reales del host. +### Paso 4 - Ejecutando el Playbook -> **Consejo** -> -> Hacer un `grep -i` para el kernel +Ejecuta el playbook para aplicar tu MOTD personalizado en todos los hosts gestionados: - - Modificar la plantilla para utilizar el fact que encontró. - - - Ejecute el Playbook de nuevo. - - -> **Advertencia** -> -> **Solución a continuación\!** - - - - Encuentra el fact: ```bash -[student@ansible ansible-files]$ ansible node1 -m setup|grep -i kernel - "ansible_kernel": "3.10.0-693.el7.x86_64", -``` - - - Modificar la plantilla `motd-facts.j2`: - -```html+jinja -Welcome to {{ ansible_hostname }}. -{{ ansible_distribution }} {{ ansible_distribution_version}} -deployed on {{ ansible_architecture }} architecture -running kernel {{ ansible_kernel }}. +[student@ansible-1 lab_inventory]$ ansible-navigator run system_setup.yml -m stdout + +PLAY [Configuración Básica del Sistema] **************************************** +. +. +. + +TASK [Actualizar MOTD desde Plantilla Jinja2] ********************************** +changed: [node1] +changed: [node2] +changed: [node3] +changed: [ansible-1] + +RECAP ************************************************************************** +ansible-1 : ok=6 changed=1 unreachable=0 failed=0 skipped=2 rescued=0 ignored=0 +node1 : ok=8 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 +node2 : ok=8 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 +node3 : ok=8 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 ``` - - - Ejecute el playbook. -``` -[student1@ansible ~]$ ansible-playbook motd-facts.yml -``` +Verifica los cambios conectándote por SSH al nodo, y deberías ver el mensaje del día: - - Verifique el nuevo mensaje a través del login por SSH al `node1`. -``` -[student1@ansible ~]$ ssh node1 -Welcome to node1. -RedHat 8.1 -deployed on x86_64 architecture -running kernel 4.18.0-147.8.1.el8_1.x86_64. +```bash +[rhel@control ~]$ ssh node1 + +Bienvenido a node1. +SO: RedHat 8.7 +Arquitectura: x86_64 +Registra este sistema en Red Hat Insights: insights-client --register +Crea una cuenta o ve todos tus sistemas en https://red.ht/insights-dashboard +Último acceso: Lun Ene 29 16:30:31 2024 desde 10.5.1.29 ``` ---- @@ -124,3 +117,4 @@ running kernel 4.18.0-147.8.1.el8_1.x86_64. [Ejercicio anterior](../1.5-handlers/README.es.md) - [Próximo Ejercicio](../1.7-role/README.es.md) [Haga clic aquí para volver al Taller Ansible for Red Hat Enterprise Linux](../README.md#section-1---ansible-engine-exercises) + diff --git a/exercises/ansible_rhel/1.6-templates/README.fr.md b/exercises/ansible_rhel/1.6-templates/README.fr.md index c77c2da20..848d4f597 100644 --- a/exercises/ansible_rhel/1.6-templates/README.fr.md +++ b/exercises/ansible_rhel/1.6-templates/README.fr.md @@ -1,125 +1,125 @@ -# Atelier - Les templates +# Exercice de l'Atelier - Modèles -**Lisez ceci dans d'autres langues**: -
![uk](../../../images/uk.png) [English](README.md), ![japan](../../../images/japan.png)[日本語](README.ja.md), ![brazil](../../../images/brazil.png) [Portugues do Brasil](README.pt-br.md), ![france](../../../images/fr.png) [Française](README.fr.md),![Español](../../../images/col.png) [Español](README.es.md). +**Lisez ceci dans d'autres langues** : +
![uk](../../../images/uk.png) [Anglais](README.md), ![japan](../../../images/japan.png) [Japonais](README.ja.md), ![brazil](../../../images/brazil.png) [Portugais du Brésil](README.pt-br.md), ![france](../../../images/fr.png) [Français](README.fr.md), ![Español](../../../images/col.png) [Espagnol](README.es.md). -## Table des matières +## Table des Matières -* [Objectif](#objectif) -* [Guide](#guide) -* [Étape 1 - Utilisation des templates](#Étape-1---utilisation-des-templates) -* [Étape 2 - Défi: Les templates](#Étape-2---défi-les-templates) +- [Objectif](#objectif) +- [Guide](#guide) + - [Étape 1 - Introduction à la Templatisation Jinja2](#étape-1---introduction-à-la-templatisation-jinja2) + - [Étape 2 - Création de Votre Premier Modèle](#étape-2---création-de-votre-premier-modèle) + - [Étape 3 - Déploiement du Modèle avec un Playbook](#étape-3---déploiement-du-modèle-avec-un-playbook) + - [Étape 4 - Exécution du Playbook](#étape-4---exécution-du-playbook) -# Objectif +## Objectif -Cet exercice couvre les templates. Ansible utilise les templates Jinja2 pour modifier les fichiers avant qu'ils ne soient distribués aux hôtes gérés. Jinja2 est l'un des moteurs de modèles les plus utilisés pour Python (). +L'Exercice 1.5 introduit la templatisation Jinja2 au sein d'Ansible, une fonctionnalité puissante pour générer des fichiers dynamiques à partir de modèles. Vous apprendrez à créer des modèles qui intègrent des données spécifiques à l'hôte, permettant la création de fichiers de configuration sur mesure pour chaque hôte géré. -# Guide +## Guide -## Étape 1 - Utilisation des templates +### Étape 1 - Introduction à la Templatisation Jinja2 -Lorsqu'un template de fichier a été créé, il peut être déployé sur les hôtes gérés à l'aide du module `template`, qui prend en charge le transfert d'un fichier local du nœud de contrôle vers les hôtes gérés. +Ansible utilise Jinja2, un langage de templatisation largement utilisé pour Python, permettant la génération de contenu dynamique dans les fichiers. Cette capacité est particulièrement utile pour configurer des fichiers qui doivent différer d'un hôte à l'autre. -Comme exemple d'utilisation d'un template, vous allez modifier le fichier motd pour qu'il contienne des données spécifiques à l'hôte. +### Étape 2 - Création de Votre Premier Modèle -Créez d'abord le répertoire `templates` pour contenir les ressources de template dans `~/ansible-files/`: -```bash -[student@ansible ansible-files]$ mkdir templates -``` +Les modèles se terminent par une extension `.j2` et mélangent du contenu statique avec des espaces réservés dynamiques entourés de `{{ }}`. -Ensuite, dans le répertoire `~/ansible-files/templates/` créez le template `motd-facts.j2`: +Dans l'exemple suivant, créons un modèle pour le Message du Jour (MOTD) qui inclut des informations dynamiques sur l'hôte. - -```html+jinja -Welcome to {{ ansible_hostname }}. -{{ ansible_distribution }} {{ ansible_distribution_version}} -deployed on {{ ansible_architecture }} architecture. -``` - +#### Configuration du Répertoire des Modèles : -Le template contient le texte de base qui sera ensuite recopié. Il contient également des variables qui seront remplacées individuellement sur les machines cibles. +Assurez-vous qu'un répertoire de modèles existe dans votre répertoire lab_inventory pour organiser vos modèles. -Ensuite, nous avons besoin d'un playbook pour utiliser ce modèle. Dans le répertoire `~/ansible-files/` créez le Playbook `motd-facts.yml`: -```yaml ---- -- name: Fill motd file with host data - hosts: node1 - become: true - tasks: - - template: - src: motd-facts.j2 - dest: /etc/motd - owner: root - group: root - mode: 0644 +```bash +mkdir -p ~/lab_inventory/templates ``` -Vous l'avez déjà fait plusieurs fois: - - - Comprenez ce que fait le Playbook. +#### Développement du Modèle MOTD : - - Exécutez le Playbook `motd-facts.yml`. +Créez un fichier nommé `motd.j2` dans le répertoire des modèles avec le contenu suivant : - - Connectez-vous à `node1` via SSH et vérifiez le contenu du message du jour. - - - Déconnectez-vous de `node1`. - -Vous devriez voir comment Ansible remplace les variables par les faits qu'il a découverts dans le système. +```jinja +Bienvenue sur {{ ansible_hostname }}. +OS : {{ ansible_distribution }} {{ ansible_distribution_version }} +Architecture : {{ ansible_architecture }} +``` -## Étape 2 - Défi: Les templates +Ce modèle affiche dynamiquement le nom d'hôte, la distribution de l'OS, la version et l'architecture de chaque hôte géré. -Ajoutez une ligne au template pour afficher le noyau utilisé du nœud géré. +### Étape 3 - Déploiement du Modèle avec un Playbook - - Trouvez un fait qui contient la version du noyau en utilisant les commandes que vous avez apprises dans le chapitre sur les "faits". +Utilisez le module `ansible.builtin.template` dans un playbook pour distribuer et rendre le modèle sur vos hôtes gérés. -> **Astuce** -> -> Faites un `grep -i` pour le noyau +Modifiez le playbook `system_setup.yml` avec le contenu suivant : - - Modifiez le modèle pour utiliser le fait que vous avez trouvé. +```yaml +--- +- name: Configuration Système de Base + hosts: all + become: true + tasks: + - name: Mise à jour de MOTD à partir du modèle Jinja2 + ansible.builtin.template: + src: templates/motd.j2 + dest: /etc/motd - - Exécutez à nouveau le Playbook. + handlers: + - name: Recharger le Pare-feu + ansible.builtin.service: + name: firewalld + state: reloaded +``` - - Vérifiez motd en vous connectant à node1 +Le module `ansible.builtin.template` prend le modèle `motd.j2` et génère un fichier `/etc/motd` sur chaque hôte, en remplissant les espaces réservés du modèle avec les faits réels de l'hôte. -> **Avertissement** -> -> **Solution ci-dessous \!** +### Étape 4 - Exécution du Playbook +Exécutez le playbook pour appliquer votre MOTD personnalisé sur tous les hôtes gérés : - - Trouvez le fait: ```bash -[student@ansible ansible-files]$ ansible node1 -m setup|grep -i kernel - "ansible_kernel": "3.10.0-693.el7.x86_64", +[student@ansible-1 lab_inventory]$ ansible-navigator run system_setup.yml -m stdout ``` - - Modifiez le template `motd-facts.j2`: - -```html+jinja -Welcome to {{ ansible_hostname }}. -{{ ansible_distribution }} {{ ansible_distribution_version}} -deployed on {{ ansible_architecture }} architecture -running kernel {{ ansible_kernel }}. +```plaintext +PLAY [Configuration Système de Base] ******************************************* +. +. +. + +TASK [Mise à jour de MOTD à partir du modèle Jinja2] *************************** +changed: [node1] +changed: [node2] +changed: [node3] +changed: [ansible-1] + +RECAP ************************************************************************* +ansible-1 : ok=6 changed=1 unreachable=0 failed=0 skipped=2 rescued=0 ignored=0 +node1 : ok=8 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 +node2 : ok=8 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 +node3 : ok=8 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 ``` - - - Executez le playbook. -``` -[student1@ansible ~]$ ansible-playbook motd-facts.yml -``` +Vérifiez les changements en vous connectant au nœud via SSH, et vous devriez voir le message du jour: - - Vérifiez le nouveau message via la connexion SSH pour `node1`. -``` -[student1@ansible ~]$ ssh node1 -Welcome to node1. -RedHat 8.1 -deployed on x86_64 architecture -running kernel 4.18.0-147.8.1.el8_1.x86_64. +```plaintext +[rhel@control ~]$ ssh node1 + +Bienvenue sur node1. +OS : RedHat 8.7 +Architecture : x86_64 +Enregistrez ce système auprès de Red Hat Insights : insights-client --register +Créez un compte ou consultez tous vos systèmes sur https://red.ht/insights-dashboard +Dernière connexion : Lun 29 Jan 16:30:31 2024 depuis 10.5.1.29 ``` + ---- **Navigation**
[Exercise précédent](../1.5-handlers/README.fr.md) - [Exercise suivant](../1.7-role/README.fr.md) [Cliquez ici pour revenir à l'atelier Ansible pour Red Hat Enterprise Linux](../README.fr.md) + + diff --git a/exercises/ansible_rhel/1.6-templates/README.ja.md b/exercises/ansible_rhel/1.6-templates/README.ja.md index 22c5a6fc1..9c7d2f0c9 100644 --- a/exercises/ansible_rhel/1.6-templates/README.ja.md +++ b/exercises/ansible_rhel/1.6-templates/README.ja.md @@ -1,165 +1,122 @@ # ワークショップ演習 - テンプレート -**他の言語でもお読みいただけます**: -
![uk](../../../images/uk.png) [English](README.md)、![japan](../../../images/japan.png)[日本語](README.ja.md)、![brazil](../../../images/brazil.png) [Portugues do Brasil](README.pt-br.md)、![france](../../../images/fr.png) [Française](README.fr.md)、![Español](../../../images/col.png) [Español](README.es.md) +**他の言語で読む**: +
![uk](../../../images/uk.png) [英語](README.md), ![japan](../../../images/japan.png) [日本語](README.ja.md), ![brazil](../../../images/brazil.png) [ブラジルポルトガル語](README.pt-br.md), ![france](../../../images/fr.png) [フランス語](README.fr.md), ![Español](../../../images/col.png) [スペイン語](README.es.md). ## 目次 -* [目的](#目的) -* [ガイド](#ガイド) - * [ステップ 1 - Playbooks でのテンプレートの使用](#ステップ-1---playbooks-でのテンプレートの使用) - * [ステップ 2 - チャレンジラボ](#ステップ-2---チャレンジラボ) +- [目的](#目的) +- [ガイド](#ガイド) + - [ステップ 1 - Jinja2 テンプレーティングへの導入](#ステップ-1---jinja2-テンプレーティングへの導入) + - [ステップ 2 - はじめてのテンプレートを作成する](#ステップ-2---はじめてのテンプレートを作成する) + - [ステップ 3 - プレイブックでテンプレートを展開する](#ステップ-3---プレイブックでテンプレートを展開する) + - [ステップ 4 - プレイブックを実行する](#ステップ-4---プレイブックを実行する) ## 目的 -この演習では、Jinja2 テンプレートについて説明します。Ansible は Jinja2 テンプレートを使用して、ファイルが管理対象ホストに配布される前にファイルを変更します。Jinja2は、Python で最も使用されているテンプレートエンジンの1つです ()。 +演習 1.5 では、Ansible 内での Jinja2 テンプレーティングが紹介されます。これは、テンプレートから動的なファイルを生成するための強力な機能です。ホスト固有のデータを組み込んだテンプレートを作成する方法を学び、管理されている各ホストに合わせた設定ファイルを作成できるようになります。 ## ガイド -### ステップ 1 - Playbooks でのテンプレートの使用 +### ステップ 1 - Jinja2 テンプレーティングへの導入 -ファイルのテンプレートが作成されると、`template` モジュールを使用して管理対象ホストに展開できます。これは、制御ノードから管理対象ホストへのローカルファイルの転送に対応しています。 +Ansible は Jinja2 を活用しています。Jinja2 は Python 用の広く使用されているテンプレート言語で、ファイル内で動的なコンテンツの生成を可能にします。この機能は、ホストごとに異なる必要がある設定ファイルを構成する場合に特に便利です。 -テンプレートの使用例として、ホスト固有のデータを含むように motd ファイルを変更します。 +### ステップ 2 - はじめてのテンプレートを作成する -最初に、テンプレートリソースを保持するディレクトリー `templates` を `~/ansible-files/` に作成します。 +テンプレートは `.j2` 拡張子で終わり、静的なコンテンツと `{{ }}` で囲まれた動的なプレースホルダーを混在させます。 -```bash -[student@ansible-1 ansible-files]$ mkdir templates -``` +次の例では、動的なホスト情報を含む「本日のメッセージ」(MOTD) のテンプレートを作成しましょう。 -その後、`~/ansible-files/templates/` ディレクトリーに、テンプレートファイル `motd-facts.j2` を作成します。 +#### テンプレートディレクトリの設定: - +テンプレートを整理するために、lab_inventory ディレクトリ内にテンプレートディレクトリが存在することを確認してください。 -```html+jinja -Welcome to {{ ansible_hostname }}. -{{ ansible_distribution }} {{ ansible_distribution_version}} -deployed on {{ ansible_architecture }} architecture. +```bash +mkdir -p ~/lab_inventory/templates ``` - +#### MOTD テンプレートの開発: -このテンプレートファイルには、後でコピーされる基本的なテキストが含まれています。また、ターゲットマシンで個別に置き換えられる変数も含まれています。 +テンプレートディレクトリに `motd.j2` という名前のファイルを作成し、以下の内容を含めます: -次に、このテンプレートを使用するための Playbook が必要です。`~/ansible-files/` ディレクトリーで、Playbook `motd-facts.yml` を作成します。 - -```yaml ---- -- name: Fill motd file with host data - hosts: node1 - become: true - tasks: - - template: - src: motd-facts.j2 - dest: /etc/motd - owner: root - group: root - mode: 0644 +```jinja +{{ ansible_hostname }} へようこそ。 +OS: {{ ansible_distribution }} {{ ansible_distribution_version }} +アーキテクチャ: {{ ansible_architecture }} ``` -この操作はこれまで数回行ってきました。 - -* Playbook の内容を把握します。 -* Playbook `motd-facts.yml` を実行します。 -* SSH 経由で node1 にログインし、その日の内容のメッセージを確認します。 -* node1 からログアウトします。 - -Ansible がシステムから検出したファクトに変数置き換える方法を確認してください。 - -### ステップ 2 - チャレンジラボ - -テンプレートに行を追加して、管理対象ノードの現在のカーネルを一覧表示します。 - -* 「Ansible ファクト」の章で学習したコマンドを使用して、カーネルバージョンを含むファクトを見つけます。 - -> *ヒント** -> -> カーネルのフィルター - -> 新規作成された Playbook を実行してファクト名を検索します。 - -* テンプレートを変更して、見つけたファクトを使用します。 +このテンプレートは、管理されている各ホストのホスト名、OS の配布、バージョン、およびアーキテクチャを動的に表示します。 -* 再び motd Playbook を実行します。 +### ステップ 3 - プレイブックでテンプレートを展開する -* node1 にログインして motd を確認します +プレイブック内で `ansible.builtin.template` モジュールを使用して、管理されているホストにテンプレートを配布し、レンダリングします。 -> **警告** -> -> **回答を以下に示します。** - -* ファクトを見つけます。 +以下の内容で `system_setup.yml` プレイブックを変更します: ```yaml --- -- name: Capture Kernel Version - hosts: node1 - +- name: 基本的なシステムセットアップ + hosts: all + become: true tasks: + - name: Jinja2 テンプレートから MOTD を更新 + ansible.builtin.template: + src: templates/motd.j2 + dest: /etc/motd - - name: Collect only kernel facts - ansible.builtin.setup: - filter: - - '*kernel' - register: setup - - - debug: - var: setup -``` - -ワイルドカードが導入されると、出力は以下のようになります。 - -```bash - -TASK [debug] ******************************************************************* -ok: [node1] => { - "setup": { - "ansible_facts": { - "ansible_kernel": "4.18.0-305.12.1.el8_4.x86_64" - }, - "changed": false, - "failed": false - } -} + handlers: + - name: ファイアウォールの再読み込み + ansible.builtin.service: + name: firewalld + state: reloaded ``` -これにより、検索する変数に `ansible_kernel` というラベルが付けられます。 +`ansible.builtin.template` モジュールは `motd.j2` テンプレートを取り、各ホストに `/etc/motd` ファイルを生成し、テンプレートのプレースホルダーを実際のホストの事実で埋めます。 -次に、motd-facts.j2 テンプレートを更新して、メッセージの一部として `ansible_kernel` を含めることができます。 +### ステップ 4 - プレイブックを実行する -* テンプレート `motd-facts.j2` 変更します。 +管理されているすべてのホストにカスタム MOTD を適用するために、プレイブックを実行します: - +```bash +[student@ansible-1 lab_inventory]$ ansible-navigator run system_setup.yml -m stdout +``` -```html+jinja -Welcome to {{ ansible_hostname }}. -{{ ansible_distribution }} {{ ansible_distribution_version}} -deployed on {{ ansible_architecture }} architecture -running kernel {{ ansible_kernel }}. +```plaintext +PLAY [基本的なシステムセットアップ] ********************************************* +. +. +. + +TASK [Jinja2 テンプレートから MOTD を更新] ************************************** +changed: [node1] +changed: [node2] +changed: [node3] +changed: [ansible-1] + +RECAP ************************************************************************ +ansible-1 : ok=6 changed=1 unreachable=0 failed=0 skipped=2 rescued=0 ignored=0 +node1 : ok=8 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 +node2 : ok=8 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 +node3 : ok=8 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 ``` - + ノードにSSHで接続して変更を確認し、その日のメッセージが表示されるはずです： -* Playbook を実行します。 +```plaintext +[rhel@control ~]$ ssh node1 -```bash -[student@ansible-1 ~]$ ansible-navigator run motd-facts.yml -m stdout +node1 へようこそ。 +OS: RedHat 8.7 +アーキテクチャ: x86_64 +このシステムを Red Hat Insights に登録する：insights-client --register +アカウントを作成するか、https://red.ht/insights-dashboard で全てのシステムを表示する +最終ログイン：2024年1月29日 月曜日 16:30:31 から 10.5.1.29 ``` -* `node1` への SSH ログインを介して新しいメッセージを確認します。 - -```bash -[student@ansible-1 ~]$ ssh node1 -Welcome to node1. -RedHat 8.1 -deployed on x86_64 architecture -running kernel 4.18.0-305.12.1.el8_4.x86_64. -``` --- **ナビゲーション**
-[前の演習](../1.5-handlers) - [次の演習](../1.7-role) +[前の演習](../1.5-handlers/README.ja.md) - [次の演習](../1.7-role/README.ja.md) -[Click here to return to the Ansible for Red Hat Enterprise Linux Workshop](../README.md#section-1---ansible-engine-exercises) diff --git a/exercises/ansible_rhel/1.6-templates/README.md b/exercises/ansible_rhel/1.6-templates/README.md index 3ccb06f1e..d66747077 100644 --- a/exercises/ansible_rhel/1.6-templates/README.md +++ b/exercises/ansible_rhel/1.6-templates/README.md @@ -3,161 +3,126 @@ **Read this in other languages**:
![uk](../../../images/uk.png) [English](README.md), ![japan](../../../images/japan.png)[日本語](README.ja.md), ![brazil](../../../images/brazil.png) [Portugues do Brasil](README.pt-br.md), ![france](../../../images/fr.png) [Française](README.fr.md),![Español](../../../images/col.png) [Español](README.es.md). + ## Table of Contents -* [Objective](#objective) -* [Guide](#guide) -* [Step 1 - Using Templates in Playbooks](#step-1---using-templates-in-playbooks) -* [Step 2 - Challenge Lab](#step-2---challenge-lab) +- [Objective](#objective) +- [Guide](#guide) + - [Step 1 - Introduction to Jinja2 Templating](#step-1---introduction-to-jinja2-templating) + - [Step 2 - Crafting Your First Template](#step-2---crafting-your-first-template) + - [Step 3 - Deploying the Template with a Playbook](#step-3---deploying-the-template-with-a-playbook) + - [Step 4 - Executing the Playbook](#step-4---executing-the-playbook) ## Objective -This exercise will cover Jinja2 templating. Ansible uses Jinja2 templating to modify files before they are distributed to managed hosts. Jinja2 is one of the most used template engines for Python (). +Exercise 1.5 introduces Jinja2 templating within Ansible, a powerful feature for generating dynamic files from templates. You'll learn how to craft templates that incorporate host-specific data, enabling the creation of tailored configuration files for each managed host. ## Guide -### Step 1 - Using Templates in Playbooks +### Step 1 - Introduction to Jinja2 Templating + +Ansible leverages Jinja2, a widely-used templating language for Python, allowing dynamic content generation within files. This capability is particularly useful for configuring files that must differ from host to host. + +### Step 2 - Crafting Your First Template -When a template for a file has been created, it can be deployed to the managed hosts using the `template` module, which supports the transfer of a local file from the control node to the managed hosts. +Templates end with a `.j2` extension and mix static content with dynamic placeholders enclosed in `{{ }}`. -As an example of using templates you will change the motd file to contain host-specific data. +In the following example, let's create a template for the Message of the Day (MOTD) that includes dynamic host information. -First create the directory `templates` to hold template resources in `~/ansible-files/`: +#### Set Up the Template Directory: + +Ensure a templates directory exists within your lab_inventory directory to organize your templates. ```bash -[student@ansible-1 ansible-files]$ mkdir templates +mkdir -p ~/lab_inventory/templates ``` -Then in the `~/ansible-files/templates/` directory create the template file `motd-facts.j2`: +#### Develop the MOTD Template: - +Create a file named `motd.j2` in the templates directory with the following content: -```html+jinja +```jinja Welcome to {{ ansible_hostname }}. -{{ ansible_distribution }} {{ ansible_distribution_version}} -deployed on {{ ansible_architecture }} architecture. +OS: {{ ansible_distribution }} {{ ansible_distribution_version }} +Architecture: {{ ansible_architecture }} ``` - +This template dynamically displays the hostname, OS distribution, version, and architecture of each managed host. + +### Step 3 - Deploying the Template with a Playbook -The template file contains the basic text that will later be copied over. It also contains variables which will be replaced on the target machines individually. +Utilize the `ansible.builtin.template` module in a playbook to distribute and render the template across your managed hosts. -Next we need a playbook to use this template. In the `~/ansible-files/` directory create the Playbook `motd-facts.yml`: +Modify the `system_setup.yml` Playbook with the following content: ```yaml --- -- name: Fill motd file with host data - hosts: node1 +- name: Basic System Setup + hosts: all become: true tasks: - - ansible.builtin.template: - src: motd-facts.j2 +. +. +. + - name: Update MOTD from Jinja2 Template + ansible.builtin.template: + src: templates/motd.j2 dest: /etc/motd - owner: root - group: root - mode: 0644 -``` - -You have done this a couple of times by now: - -* Understand what the Playbook does. -* Execute the Playbook `motd-facts.yml`. -* Login to node1 via SSH and check the message of the day content. -* Log out of node1. - -You should see how Ansible replaces the variables with the facts it discovered from the system. - -### Step 2 - Challenge Lab - -Add a line to the template to list the current kernel of the managed node. - -* Find a fact that contains the kernel version using the commands you learned in the "Ansible Facts" chapter. - -> **Tip** -> -> filter for kernel - -> Run the newly created playbook to find the fact name. - -* Change the template to use the fact you found. - -* Run the motd playbook again. - -* Check motd by logging in to node1 -> **Warning** -> -> **Solution below\!** -* Find the fact: + handlers: + - name: Reload Firewall + ansible.builtin.service: + name: firewalld + state: reloaded -```yaml ---- -- name: Capture Kernel Version - hosts: node1 +``` - tasks: +The `ansible.builtin.template` module takes the `motd.j2` template and generates an `/etc/motd` file on each host, filling in the template's placeholders with the actual host facts. - - name: Collect only kernel facts - ansible.builtin.setup: - filter: - - '*kernel' - register: setup +### Step 4 - Executing the Playbook - - ansible.builtin.debug: - var: setup -``` - -With the wildcard in place, the output shows: +Run the playbook to apply your custom MOTD across all managed hosts: ```bash - -TASK [debug] ******************************************************************* -ok: [node1] => { - "setup": { - "ansible_facts": { - "ansible_kernel": "4.18.0-305.12.1.el8_4.x86_64" - }, - "changed": false, - "failed": false - } -} +[student@ansible-1 lab_inventory]$ ansible-navigator run system_setup.yml -m stdout ``` -With this we can conclude the variable we are looking for is labeled `ansible_kernel`. -Then we can update the motd-facts.j2 template to include `ansible_kernel` as part of its message. +```plaintext +PLAY [Basic System Setup] ****************************************************** +. +. +. -* Modify the template `motd-facts.j2`: +TASK [Update MOTD from Jinja2 Template] **************************************** +changed: [node1] +changed: [node2] +changed: [node3] +changed: [ansible-1] - - -```html+jinja -Welcome to {{ ansible_hostname }}. -{{ ansible_distribution }} {{ ansible_distribution_version}} -deployed on {{ ansible_architecture }} architecture -running kernel {{ ansible_kernel }}. +PLAY RECAP ********************************************************************* +ansible-1 : ok=6 changed=1 unreachable=0 failed=0 skipped=2 rescued=0 ignored=0 +node1 : ok=8 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 +node2 : ok=8 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 +node3 : ok=8 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 ``` - +Verify the changes by SSHing into the node, and you should see the message of the day: -* Run the playbook. - -```bash -[student@ansible-1 ~]$ ansible-navigator run motd-facts.yml -m stdout +```plaintext +[rhel@control ~]$ ssh node1 +``` ``` - -* Verify the new message via SSH login to `node1`. - -```bash -[student@ansible-1 ~]$ ssh node1 Welcome to node1. -RedHat 8.1 -deployed on x86_64 architecture -running kernel 4.18.0-305.12.1.el8_4.x86_64. +OS: RedHat 8.7 +Architecture: x86_64 +Register this system with Red Hat Insights: insights-client --register +Create an account or view all your systems at https://red.ht/insights-dashboard +Last login: Mon Jan 29 16:30:31 2024 from 10.5.1.29 + ``` ---- **Navigation**
[Previous Exercise](../1.5-handlers) - [Next Exercise](../1.7-role) diff --git a/exercises/ansible_rhel/1.6-templates/README.pt-br.md b/exercises/ansible_rhel/1.6-templates/README.pt-br.md index 6fb518f46..7dd9cc4fd 100644 --- a/exercises/ansible_rhel/1.6-templates/README.pt-br.md +++ b/exercises/ansible_rhel/1.6-templates/README.pt-br.md @@ -1,101 +1,123 @@ -# Exercicio - Templates +# Exercício de Workshop - Templates -**Leia em outras linguagens**: -
![uk](../../../images/uk.png) [English](README.md), ![japan](../../../images/japan.png)[日本語](README.ja.md), ![brazil](../../../images/brazil.png) [Portugues do Brasil](README.pt-br.md), ![france](../../../images/fr.png) [Française](README.fr.md),![Español](../../../images/col.png) [Español](README.es.md). +**Leia isto em outros idiomas**: +
![uk](../../../images/uk.png) [Inglês](README.md), ![japan](../../../images/japan.png) [Japonês](README.ja.md), ![brazil](../../../images/brazil.png) [Português do Brasil](README.pt-br.md), ![france](../../../images/fr.png) [Francês](README.fr.md), ![Español](../../../images/col.png) [Espanhol](README.es.md). -* [Passo 1 - Usando Templates em Playbooks](#passo-1---usando-templates-em-playbooks) -* [Passo 2 - Laboratório de Desafios](#passo-2---laboratório-de-desafios) +## Índice -O Ansible usa o template Jinja2 para modificar arquivos antes de serem distribuídos para hosts gerenciados. O Jinja2 é um dos mecanismos de template mais usados para o Python (). +- [Objetivo](#objetivo) +- [Guia](#guia) + - [Passo 1 - Introdução ao Templating Jinja2](#passo-1---introdução-ao-templating-jinja2) + - [Passo 2 - Criando Seu Primeiro Template](#passo-2---criando-seu-primeiro-template) + - [Passo 3 - Implementando o Template com um Playbook](#passo-3---implementando-o-template-com-um-playbook) + - [Passo 4 - Executando o Playbook](#passo-4---executando-o-playbook) -## Passo 1 - Usando Templates em Playbooks +## Objetivo -Quando um template é criado, ele pode ser implantado nos hosts gerenciados usando o módulo `template`, que suporta a transferência de um arquivo local do nó de controle para os hosts gerenciados. +O Exercício 1.5 introduz o templating Jinja2 dentro do Ansible, um recurso poderoso para gerar arquivos dinâmicos a partir de templates. Você aprenderá como criar templates que incorporam dados específicos do host, permitindo a criação de arquivos de configuração personalizados para cada host gerenciado. -Como exemplo de uso de templates, você irá alterar o arquivo motd para conter dados específicos do host. +## Guia +### Passo 1 - Introdução ao Templating Jinja2 -No diretório `~/ansible-files/` crie o arquivo de template `motd-facts.j2`: +O Ansible utiliza o Jinja2, uma linguagem de templating amplamente usada para Python, permitindo a geração de conteúdo dinâmico dentro dos arquivos. Essa capacidade é particularmente útil para configurar arquivos que devem variar de host para host. - -```html+jinja -Bem vindo ao {{ ansible_hostname }}. -{{ ansible_distribution }} {{ ansible_distribution_version}} -implementado na arquitetura {{ ansible_architecture }}. -``` - - -O arquivo de template contém o texto básico que mais tarde será copiado. Ele também contém variáveis que serão substituídas nas máquinas de destino individualmente. - -Em seguida, precisamos de um Playbook para usar este modelo. No diretório `~/ansible-files/` crie o Playbook `motd-facts.yml`: +### Passo 2 - Criando Seu Primeiro Template -```yaml ---- -- name: Preencher arquivo motd com dados do host - hosts: node1 - become: yes - tasks: - - template: - src: motd-facts.j2 - dest: /etc/motd - owner: root - group: root - mode: 0644 -``` +Os templates terminam com a extensão `.j2` e misturam conteúdo estático com espaços reservados dinâmicos envolvidos em `{{ }}`. -Você já fez isso algumas vezes até agora: +No exemplo a seguir, vamos criar um template para a Mensagem do Dia (MOTD) que inclui informações dinâmicas do host. - - Entender o que o Playbook faz. +#### Configurando o Diretório de Templates: - - Executar o Playbook `motd-facts.yml`. +Certifique-se de que um diretório de templates exista dentro do seu diretório lab_inventory para organizar seus templates. - - Efetue login no node1 via SSH e verifique a mensagem do conteúdo do dia. +```bash +mkdir -p ~/lab_inventory/templates +``` - - Efetue Logout no node1. +#### Desenvolvendo o Template MOTD: -Você deve ter visto como o Ansible substitui as variáveis pelos dados descobertos no sistema. +Crie um arquivo chamado `motd.j2` no diretório de templates com o seguinte conteúdo: -## Passo 2 - Laboratório de Desafios +```jinja +Bem-vindo ao {{ ansible_hostname }}. +SO: {{ ansible_distribution }} {{ ansible_distribution_version }} +Arquitetura: {{ ansible_architecture }} +``` -Adicione uma linha ao template para listar o kernel atual do nó gerenciado. +Este template exibe dinamicamente o nome do host, a distribuição do sistema operacional, a versão e a arquitetura de cada host gerenciado. - - Encontre um fact que contenha a versão do kernel usando os comandos que você aprendeu no capítulo "Ansible Facts". +### Passo 3 - Implementando o Template com um Playbook -> **Dica** -> -> Use `grep -i` para o kernel +Utilize o módulo `ansible.builtin.template` em um playbook para distribuir e renderizar o template em seus hosts gerenciados. - - Mude o template para usar o fact que você encontrou. +Modifique o playbook `system_setup.yml` com o seguinte conteúdo: - - Execute o Playbook novamente. +```yaml +--- +- name: Configuração Básica do Sistema + hosts: all + become: true + tasks: + - name: Atualizar MOTD a partir do Template Jinja2 + ansible.builtin.template: + src: templates/motd.j2 + dest: /etc/motd - - Verifique o motd efetuando login no node1 + handlers: + - name: Recarregar Firewall + ansible.builtin.service: + name: firewalld + state: reloaded +``` -> **ATENÇÃO** -> -> **Solução abaixo\!** +O módulo `ansible.builtin.template` pega o template `motd.j2` e gera um arquivo `/etc/motd` em cada host, preenchendo os espaços reservados do template com os fatos reais do host. +### Passo 4 - Executando o Playbook - - Procure o fact: +Execute o playbook para aplicar seu MOTD personalizado em todos os hosts gerenciados: ```bash -[student@ansible ansible-files]$ ansible node1 -m setup|grep -i kernel - "ansible_kernel": "3.10.0-693.el7.x86_64", +[student@ansible-1 lab_inventory]$ ansible-navigator run system_setup.yml -m stdout +``` + +```plaintext +PLAY [Configuração Básica do Sistema] ***************************************** +. +. +. + +TASK [Atualizar MOTD a partir do Template Jinja2] ***************************** +changed: [node1] +changed: [node2] +changed: [node3] +changed: [ansible-1] + +RECAP ************************************************************************ +ansible-1 : ok=6 changed=1 unreachable=0 failed=0 skipped=2 rescued=0 ignored=0 +node1 : ok=8 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 +node2 : ok=8 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 +node3 : ok=8 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 ``` - - Modifique o template `motd-facts.j2`: +Verifique as alterações fazendo SSH para o nó, e você deverá ver a mensagem do dia: - -```html+jinja -Bem vindo ao {{ ansible_hostname }}. -{{ ansible_distribution }} {{ ansible_distribution_version}} -implementado na arquitetura {{ ansible_architecture }} -executando o kernel {{ ansible_kernel }}. +```plaintext +[rhel@control ~]$ ssh node1 + +Bem-vindo ao node1. +SO: RedHat 8.7 +Arquitetura: x86_64 +Registre este sistema no Red Hat Insights: insights-client --register +Crie uma conta ou visualize todos os seus sistemas em https://red.ht/insights-dashboard +Último login: Seg Jan 29 16:30:31 2024 de 10.5.1.29 ``` - - - Execute o playbook. - - Verifique a nova mensagem via login SSH no `node1`. ---- +**Navegação** +
+[Exercício anterior](../1.5-handlers/README.pt-br.md) - [Próximo exercício](../1.7-role/README.pt-br.md) + +[Clique aqui para voltar ao workshop de Ansible para Red Hat Enterprise Linux](../README.md) -[Clique aqui para retornar ao Workshop Ansible for Red Hat Enterprise Linux](../README.pt-br.md#seção-1---exercícios-do-ansible-engine) diff --git a/exercises/ansible_rhel/1.7-role/README.es.md b/exercises/ansible_rhel/1.7-role/README.es.md index 0f9af5f60..61107ffec 100644 --- a/exercises/ansible_rhel/1.7-role/README.es.md +++ b/exercises/ansible_rhel/1.7-role/README.es.md @@ -1,297 +1,263 @@ -# Workshop - Roles: Hacer que tus playbooks sean reutilizables +# Ejercicio del Taller - Roles: Haciendo tus playbooks reutilizables -**Read this in other languages**: -
![uk](../../../images/uk.png) [English](README.md), ![japan](../../../images/japan.png)[日本語](README.ja.md), ![brazil](../../../images/brazil.png) [Portugues do Brasil](README.pt-br.md), ![france](../../../images/fr.png) [Française](README.fr.md),![Español](../../../images/col.png) [Español](README.es.md). +**Leer esto en otros idiomas**: +
![uk](../../../images/uk.png) [Inglés](README.md), ![japan](../../../images/japan.png) [Japonés](README.ja.md), ![brazil](../../../images/brazil.png) [Portugués de Brasil](README.pt-br.md), ![france](../../../images/fr.png) [Francés](README.fr.md), ![Español](../../../images/col.png) [Español](README.es.md). -## Table of Contents +## Tabla de Contenidos -* [Objetivos](#Objetivos) -* [Guía](#Guía) -* [Paso 1 - Comprender la estructura de roles ansible](#Paso-1---Comprender-la-estructura-de-roles-ansible) -* [Paso 2 - Crear una estructura de directorio básico de roles](#Paso-2---Crear-una-estructura-de-directorio-básico-de-roles) -* [Paso 3 - Crear el archivo de tareas](#Paso-3---Crear-el-archivo-de-tareas) -* [Paso 4 - Crear el controlador](#Paso-4---Crear-el-controlador) -* [Paso 5 - Crear la plantilla de archivo de configuración web.html y vhost](#Paso-5---Crear-la-plantilla-de-archivo-de-configuración-webhtml-y-vhost) -* [Paso 6 - Probar el role](#Paso-6---Probar-el-role) +- [Objetivo](#objetivo) +- [Guía](#guía) + - [Paso 1 - Conceptos Básicos de Roles](#paso-1---conceptos-básicos-de-roles) + - [Paso 2 - Limpieza del Entorno](#paso-2---limpieza-del-entorno) + - [Paso 3 - Construyendo el Rol de Apache](#paso-3---construyendo-el-rol-de-apache) + - [Paso 4 - Integración del Rol en un Playbook](#paso-4---integración-del-rol-en-un-playbook) + - [Paso 5 - Ejecución y Validación del Rol](#paso-5---ejecución-y-validación-del-rol) + - [Paso 6 - Verificar que Apache esté Corriendo](#paso-6---verificar-que-apache-esté-corriendo) -# Objetivos +## Objetivo -Si bien es posible escribir un playbook en un archivo como lo hemos hecho a lo largo de este taller, con el tiempo querrás reutilizar archivos y empezar a organizar las cosas. +Este ejercicio se basa en los ejercicios anteriores y avanza tus habilidades en Ansible guiándote a través de la creación de un rol que configura Apache (httpd). Tomarás el conocimiento que has aprendido para ahora integrar variables, manejadores y una plantilla para un index.html personalizado. Este rol demuestra cómo encapsular tareas, variables, plantillas y manejadores en una estructura reutilizable para una automatización eficiente. -Los roles ansibles son la forma en que hacemos esto. Cuando se crea un rol, se descompone el playbook en partes y esas partes se encuentran en una estructura de directorios. Esto se explica con más detalle en el link de [mejores prácticas](http://docs.ansible.com/ansible/playbooks_best_practices.html). +## Guía -Este ejercicio cubrirá: -- la estructura de carpetas de un role de Ansible -- cómo construir un role de ansible -- Crear un Ansible Play para usar y ejecutar un role +### Paso 1 - Conceptos Básicos de Roles -# Guía +Los roles en Ansible organizan tareas de automatización relacionadas y recursos, como variables, plantillas y manejadores, en un directorio estructurado. Este ejercicio se centra en crear un rol de configuración de Apache, enfatizando la reutilización y modularidad. -## Paso 1 - Comprender la estructura de roles ansible +### Paso 2 - Limpieza del Entorno -Los roles son básicamente automatización construida en torno a directivas *include* y realmente no contienen mucha magia adicional más allá de algunas mejoras en el manejo de rutas de búsqueda para los archivos a los que se hace referencia. +Basándonos en nuestro trabajo previo con la configuración de Apache, vamos a crear un playbook de Ansible dedicado a limpiar nuestro entorno. Este paso allana el camino para que introduzcamos un nuevo rol de Apache, proporcionando una visión clara de los ajustes realizados. A través de este proceso, obtendremos una comprensión más profunda de la versatilidad y reutilización que ofrecen los Roles de Ansible. -Los roles siguen una estructura de directorios definida; un role es nombrado por el directorio de nivel superior. Algunos de los subdirectorios contienen archivos YAML, denominados `main.yml`. Los subdirectorios de archivos y plantillas pueden contener objetos a los que hacen referencia los archivos YAML. - -Una estructura de proyecto de ejemplo podría tener este aspecto, el nombre del role sería "apache": - -```text -apache/ -├── defaults -│ └── main.yml -├── files -├── handlers -│ └── main.yml -├── meta -│ └── main.yml -├── README.md -├── tasks -│ └── main.yml -├── templates -├── tests -│ ├── inventory -│ └── test.yml -└── vars - └── main.yml -``` -Los diversos archivos `main.yml` contienen contenido dependiendo de su ubicación en la estructura de directorios que se muestra arriba. Por ejemplo, `vars/main.yml` hace referencia a variables,`handlers/main.yaml` describe controladores, y así sucesivamente. Tenga en cuenta que, a diferencia de los playbooks, los archivos `main.yml` solo contienen el contenido específico y no información adicional del playbook como los hosts,`become` u otras palabras clave. - -> **Consejo** -> -> En realidad, hay dos directorios para las variables: `vars` y `default`: las variables predeterminadas/default tienen la prioridad más baja y normalmente contienen valores predeterminados establecidos por los autores de roles y se utilizan a menudo cuando se pretende que sus valores se invaliden., Las variables se pueden establecer en `vars/main.yml` o `defaults/main.yml`, pero no en ambos lugares. - -El uso de roles en un Playbook es sencillo: +Ejecute el siguiente playbook de Ansible para limpiar el entorno: ```yaml --- -- name: launch roles - hosts: web - roles: - - role1 - - role2 +- name: Cleanup Environment + hosts: all + become: true + vars: + package_name: httpd + tasks: + - name: Remove Apache from web servers + ansible.builtin.dnf: + name: "{{ package_name }}" + state: absent + when: inventory_hostname in groups['web'] + + - name: Remove firewalld + ansible.builtin.dnf: + name: firewalld + state: absent + + - name: Delete created users + ansible.builtin.user: + name: "{{ item }}" + state: absent + remove: true # Use 'remove: true’ to delete home directories + loop: + - alice + - bob + - carol + - Roger + + - name: Reset MOTD to an empty message + ansible.builtin.copy: + dest: /etc/motd + content: '' ``` -Para cada role, las tareas, controladores y variables de ese role se incluirán en el Playbook, en ese orden. Cualquier tarea de copia, script, plantilla o inclusión en el role puede hacer referencia a los archivos (files), plantillas (templates) o tareas (tasks) relevantes *sin nombres de ruta absolutos o relativos*. Ansible los buscará en los archivos, plantillas o tareas del role, respectivamente, en función de su uso. - -## Paso 2 - Crear una estructura de directorio básico de roles +### Paso 3 - Construyendo el Rol de Apache -Ansible busca roles en un subdirectorio denominado `roles` en el directorio del proyecto. Esto se puede invalidar en la configuración de Ansible. Cada role tiene su propio directorio. Para facilitar la creación de un nuevo role se puede utilizar la herramienta `ansible-galaxy`. +Desarrollaremos un rol llamado `apache` para instalar, configurar y gestionar Apache. -> **Consejo** -> -> Ansible Galaxy es su hub para encontrar, reutilizar y compartir el mejor contenido de Ansible. `ansible-galaxy` ayuda a interactuar con Ansible Galaxy. Por ahora, lo usaremos como ayudante para crear la estructura de directorios. - -Bien, empecemos a construir un role. Crearemos un role que instale y configure Apache para servir a un host virtual. Ejecute estos comandos en el directorio `~/ansible-files`: - -```bash -[student@ansible ansible-files]$ mkdir roles -[student@ansible ansible-files]$ ansible-galaxy init --offline roles/apache_vhost -``` +1. Generar Estructura del Rol: -Echa un vistazo a los directorios de roles y su contenido: +Cree el rol usando ansible-galaxy, especificando el directorio de roles para la salida. ```bash -[student@ansible ansible-files]$ tree roles +[student@ansible-1 lab_inventory]$ mkdir roles +[student@ansible-1 lab_inventory]$ ansible-galaxy init --offline roles/apache ``` -## Paso 3 - Crear el archivo de tareas - -El archivo `main.yml` del subdirectorio tasks del role debe hacer lo siguiente: - - - Asegúrese de que httpd está instalado +2. Definir Variables del Rol: - - Asegúrese de que httpd está iniciado y habilitado +Poblamos `/home/student/lab_inventory/roles/apache/vars/main.yml` con variables específicas de Apache: - - Poner contenido HTML en la carpeta de datos de Apache - - - Instalar la plantilla proporcionada para configurar el vhost +```yaml +--- +# vars file for roles/apache +apache_package_name: httpd +apache_service_name: httpd +``` -> **ADVERTENCIA** -> -> **El `main.yml` (y otros archivos posiblemente incluidos por main.yml) sólo pueden contener tareas, *no* Playbooks completos!** +3. Configurar Tareas del Rol: -Cambie al directorio `roles/apache_vhost`. Edite el archivo `tasks/main.yml`: +Ajustamos `/home/student/lab_inventory/roles/apache/tasks/main.yml` para incluir tareas para la instalación y gestión del servicio Apache: ```yaml --- -- name: install httpd - yum: - name: httpd - state: latest - -- name: start and enable httpd service - service: - name: httpd +# tasks file for ansible-files/roles/apache +- name: Install Apache web server + ansible.builtin.package: + name: "{{ apache_package_name }}" + state: present + +- name: Ensure Apache is running and enabled + ansible.builtin.service: + name: "{{ apache_service_name }}" state: started enabled: true -``` -Tenga en cuenta que aquí solo se agregaron tareas. Los detalles de un playbook no están presentes. +- name: Install firewalld + ansible.builtin.dnf: + name: firewalld + state: present -Las tareas añadidas hasta ahora: +- name: Ensure firewalld is running + ansible.builtin.service: + name: firewalld + state: started + enabled: true - - Instale el paquete httpd utilizando el módulo yum +- name: Allow HTTPS traffic on web servers + ansible.posix.firewalld: + service: https + permanent: true + state: enabled + when: inventory_hostname in groups['web'] + notify: Reload Firewall +``` - - Utilice el módulo de servicio para habilitar e iniciar httpd +4. Implementar Manejadores: -A continuación, agregamos dos tareas más para garantizar una estructura de directorios vhost y copiar contenido html: +En `/home/student/lab_inventory/roles/apache/handlers/main.yml`, creamos un manejador para reiniciar firewalld si su configuración cambia: - ```yaml -- name: ensure vhost directory is present - file: - path: "/var/www/vhosts/{{ ansible_hostname }}" - state: directory - -- name: deliver html content - copy: - src: web.html - dest: "/var/www/vhosts/{{ ansible_hostname }}/index.html" +--- +# handlers file for ansible-files/roles/apache +- name: Reload Firewall + ansible.builtin.service: + name: firewalld + state: reloaded ``` - - Tenga en cuenta que el directorio vhost se crea/se garantiza mediante el módulo `file`. +5. Crear y Desplegar Plantilla: - La última tarea que agregamos utiliza el módulo de template para crear el archivo de configuración vhost a partir de una plantilla j2: +Utilizamos una plantilla Jinja2 para un `index.html` personalizado. Almacene la plantilla en `templates/index.html.j2`: -```yaml -- name: template vhost file - template: - src: vhost.conf.j2 - dest: /etc/httpd/conf.d/vhost.conf - owner: root - group: root - mode: 0644 - notify: - - restart_httpd +```html + + +Welcome to {{ ansible_hostname }} + + +

Hello from {{ ansible_hostname }}

+ + ``` -Tenga en cuenta que está utilizando un controlador para reiniciar httpd después de una actualización de configuración. -El archivo completo `tasks/main.yml` es: +6. Actualizar `tasks/main.yml` para desplegar esta plantilla `index.html`: - ```yaml ---- -- name: install httpd - yum: - name: httpd - state: latest - -- name: start and enable httpd service - service: - name: httpd - state: started - enabled: true - -- name: ensure vhost directory is present - file: - path: "/var/www/vhosts/{{ ansible_hostname }}" - state: directory - -- name: deliver html content - copy: - src: web.html - dest: "/var/www/vhosts/{{ ansible_hostname }}" - -- name: template vhost file - template: - src: vhost.conf.j2 - dest: /etc/httpd/conf.d/vhost.conf - owner: root - group: root - mode: 0644 - notify: - - restart_httpd +- name: Deploy custom index.html + ansible.builtin.template: + src: index.html.j2 + dest: /var/www/html/index.html ``` - - -## Paso 4 - Crear el controlador +### Paso 4 - Integración del Rol en un Playbook -Cree el controlador en el archivo `handlers/main.yml` para reiniciar httpd cuando sea notificado por la tarea de plantilla: +Incruste el rol `apache` en un playbook llamado `deploy_apache.yml` dentro de `/home/student/lab_inventory` para aplicarlo a sus hosts del grupo 'web' (node1, node2, node3). ```yaml ---- -# handlers file for roles/apache_vhost -- name: restart_httpd - service: - name: httpd - state: restarted +- name: Setup Apache Web Servers + hosts: web + become: true + roles: + - apache ``` -## Paso 5 - Crear la plantilla de archivo de configuración web.html y vhost - -Cree el contenido HTML que mostrará el servidor web. +### Paso 5 - Ejecución y Validación del Rol - - Crear un archivo web.html en el directorio "src" del role, `files`: +Lanza tu playbook para configurar Apache en los servidores web designados: ```bash -[student@ansible ansible-files]$ echo 'simple vhost index' > ~/ansible-files/roles/apache_vhost/files/web.html +ansible-navigator run deploy_apache.yml -m stdout ``` - - Cree el archivo de plantilla `vhost.conf.j2` en el subdirectorio `templates` del role. - -``` -# {{ ansible_managed }} - - - ServerAdmin webmaster@{{ ansible_fqdn }} - ServerName {{ ansible_fqdn }} - ErrorLog logs/{{ ansible_hostname }}-error.log - CustomLog logs/{{ ansible_hostname }}-common.log common - DocumentRoot /var/www/vhosts/{{ ansible_hostname }}/ - - - Options +Indexes +FollowSymlinks +Includes - Order allow,deny - Allow from all - - -``` - +#### Salida: -## Paso 6 - Probar el role +```plaintext +PLAY [Setup Apache Web Servers] ************************************************ -Está listo para probar el role con `node2`. Pero dado que un role no se puede asignar directamente a un nodo, primero cree un playbook que conecte el role y el host. Cree el archivo `test_apache_role.yml` en el directorio `~/ansible-files`: +TASK [Gathering Facts] ********************************************************* +ok: [node2] +ok: [node1] +ok: [node3] -```yaml ---- -- name: use apache_vhost role playbook - hosts: node2 - become: true +TASK [apache : Install Apache web server] ************************************** +changed: [node1] +changed: [node2] +changed: [node3] - pre_tasks: - - debug: - msg: 'Beginning web server configuration.' +TASK [apache : Ensure Apache is running and enabled] *************************** +changed: [node2] +changed: [node1] +changed: [node3] - roles: - - apache_vhost +TASK [apache : Deploy custom index.html] *************************************** +changed: [node1] +changed: [node2] +changed: [node3] + +RUNNING HANDLER [apache : Reload Firewall] ************************************* +ok: [node2] +ok: [node1] +ok: [node3] - post_tasks: - - debug: - msg: 'Web server has been configured.' +PLAY RECAP ********************************************************************* +node1 : ok=5 changed=3 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 +node2 : ok=5 changed=3 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 +node3 : ok=5 changed=3 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 ``` -Observe las palabras clave ``pre_tasks` y `post_tasks`. Normalmente, las tareas de los roles se ejecutan antes que las tareas de un playbook. Para controlar el orden de ejecución, se realiza la pre_tasks antes de aplicar los roles. El `post_tasks` se realiza una vez completados todos los roles. Aquí sólo los usamos para resaltar mejor cuando se ejecuta el role real. +### Paso 6 - Verificar que Apache esté Corriendo -Ahora ya estás listo para ejecutar tu playbook: +Una vez completado el playbook, verifica que `httpd` esté corriendo en todos los nodos web. ```bash -[student@ansible ansible-files]$ ansible-playbook test_apache_role.yml +[rhel@control ~]$ ssh node1 "systemctl status httpd" +● httpd.service - The Apache HTTP Server + Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled) + Active: active (running) since Mon 2024-01-29 16:49:13 UTC; 3min 46s ago ``` -Ejecute un comando curl contra `node2` para confirmar que el role funcionó: +```bash +[rhel@control ~]$ ssh node2 "systemctl status httpd" +● httpd.service - The Apache HTTP Server + Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled) + Active: active (running) since Mon 2024-01-29 16:49:13 UTC; 3min 58s ago +``` + +Una vez que se haya verificado que `httpd` está corriendo, comprueba si el servidor web Apache está sirviendo el archivo `index.html` apropiado: ```bash -[student@ansible ansible-files]$ curl -s http://node2:8080 -simple vhost index +[student@ansible-1 lab_inventory]$ curl http://node1 + + +Welcome to node1 + + +

Hello from node1

+ + ``` -¿Todo se ve bien? ¡Felicitaciones! ¡Has completado con éxito los Ejercicios del Taller de Ansible Engine! ----- +--- **Navegación**
-[Ejercicio anterior](../1.6-templates) +[Ejercicio anterior](../1.6-templates/README.es.md) - [Próximo ejercicio](../1.8-troubleshoot/README.es.md) + +[Haz clic aquí para volver al taller de Ansible para Red Hat Enterprise Linux](../README.md#section-1---ansible-engine-exercises) -[Haga clic aquí para volver al Taller Ansible for Red Hat Enterprise Linux](../README.md#section-1---ansible-engine-exercises) diff --git a/exercises/ansible_rhel/1.7-role/README.fr.md b/exercises/ansible_rhel/1.7-role/README.fr.md index 748b1d481..cd100ff55 100644 --- a/exercises/ansible_rhel/1.7-role/README.fr.md +++ b/exercises/ansible_rhel/1.7-role/README.fr.md @@ -1,298 +1,263 @@ -# Atelier - Rôles: Rendre vos playbook réutilisables +# Exercice de l'Atelier - Rôles : Rendre vos playbooks réutilisables -**Lisez ceci dans d'autres langues**: -
![uk](../../../images/uk.png) [English](README.md), ![japan](../../../images/japan.png)[日本語](README.ja.md), ![brazil](../../../images/brazil.png) [Portugues do Brasil](README.pt-br.md), ![france](../../../images/fr.png) [Française](README.fr.md),![Español](../../../images/col.png) [Español](README.es.md). +**Lire ceci dans d'autres langues** : +
![uk](../../../images/uk.png) [Anglais](README.md), ![japan](../../../images/japan.png) [Japonais](README.ja.md), ![brazil](../../../images/brazil.png) [Portugais du Brésil](README.pt-br.md), ![france](../../../images/fr.png) [Français](README.fr.md), ![Español](../../../images/col.png) [Espagnol](README.es.md). -## Table des matières +## Table des Matières -* [Objectif](#objectif) -* [Guide](#guide) -* [Étape 1 - Comprendre la structure des rôles](#étape-1---comprendre-la-structure-des-rôles) -* [Étape 2 - Création d'un rôle de base](#étape-2---création-d-un-rôle-de-base) -* [Étape 3 - Création du fichier de tâches](#étape-3---création-du-fichier-de-tâches) -* [Étape 4 - Création du handler](#étape-4---création-du-handler) -* [Étape 5 - Création des templates](#étape-5---création-des-templates) -* [Étape 6 - Teste du rôle](#étape-6---teste-du-rôle) +- [Objectif](#objectif) +- [Guide](#guide) + - [Étape 1 - Bases des Rôles](#étape-1---bases-des-rôles) + - [Étape 2 - Nettoyage de l'Environnement](#étape-2---nettoyage-de-lenvironnement) + - [Étape 3 - Construction du Rôle Apache](#étape-3---construction-du-rôle-apache) + - [Étape 4 - Intégration du Rôle dans un Playbook](#étape-4---intégration-du-rôle-dans-un-playbook) + - [Étape 5 - Exécution et Validation du Rôle](#étape-5---exécution-et-validation-du-rôle) + - [Étape 6 - Vérification du Fonctionnement d'Apache](#étape-6---vérification-du-fonctionnement-dapache) -# Objectif +## Objectif -Bien qu'il soit possible d'écrire un playbook dans un fichier comme nous l'avons fait tout au long de cet atelier, vous souhaiterez éventuellement réutiliser des fichiers et commencer à organiser les choses. +Cet exercice s'appuie sur les exercices précédents et approfondit vos compétences en Ansible en vous guidant à travers la création d'un rôle qui configure Apache (httpd). Vous utiliserez les connaissances acquises pour intégrer des variables, des gestionnaires et un modèle pour un index.html personnalisé. Ce rôle montre comment encapsuler des tâches, des variables, des modèles et des gestionnaires dans une structure réutilisable pour une automatisation efficace. -Les rôles Ansible sont notre façon de procéder. Lorsque vous créez un rôle, vous déconstruisez votre playbook en parties et ces parties se trouvent dans une structure de répertoires. Ceci est expliqué plus en détail dans la [meilleure pratique](http://docs.ansible.com/ansible/playbooks_best_practices.html). +## Guide -Cet exercice couvrira: -- la structure des dossiers d'un rôle Ansible -- comment construire un rôle Ansible -- création d'un playbook pour utiliser et exécuter un rôle +### Étape 1 - Bases des Rôles -# Guide +Les rôles dans Ansible organisent des tâches d'automatisation et des ressources connexes, telles que des variables, des modèles et des gestionnaires, dans un répertoire structuré. Cet exercice se concentre sur la création d'un rôle de configuration Apache, en mettant l'accent sur la réutilisabilité et la modularité. -## Étape 1 - Comprendre la structure des rôles +### Étape 2 - Nettoyage de l'Environnement -Les rôles sont des éléments réutilisables comprenant des fichiers Ansible et a pour but de simplifier la gestion des fichiers référencés. +En nous appuyant sur notre travail précédent avec la configuration d'Apache, créons un playbook Ansible dédié au nettoyage de notre environnement. Cette étape ouvre la voie à l'introduction d'un nouveau rôle Apache, offrant une vision claire des ajustements effectués. Grâce à ce processus, nous approfondirons notre compréhension de la polyvalence et de la réutilisabilité offertes par les Rôles Ansible. -Les rôles suivent une structure de répertoires définie; un rôle est nommé par le répertoire de niveau supérieur. Certains sous-répertoires contiennent des fichiers YAML, nommés `main.yml`. Les sous-répertoires de fichiers et de template peuvent contenir des objets utilisés par les fichiers YAML. +Exécutez le playbook Ansible suivant pour nettoyer l'environnement : -Un exemple de structure de projet pourrait ressembler à ceci, le nom du rôle serait "apache": - -```text -apache/ -├── defaults -│ └── main.yml -├── files -├── handlers -│ └── main.yml -├── meta -│ └── main.yml -├── README.md -├── tasks -│ └── main.yml -├── templates -├── tests -│ ├── inventory -│ └── test.yml -└── vars - └── main.yml -``` - -Les différents fichiers `main.yml` contiennent du contenu en fonction de leur emplacement dans la structure de répertoires indiquée ci-dessus. Par exemple, `vars/main.yml` fait référence à des variables, `handlers/main.yaml` décrit les handlers, etc. Notez que contrairement aux playbooks, les fichiers `main.yml` contiennent uniquement le contenu spécifique et non des informations supplémentaires sur le playbook comme les hôtes, `become` ou d'autres mots clés. - -> **Astuce** -> -> Il existe en fait deux répertoires pour les variables: `vars` et `default`: les variables par défaut ont la priorité la plus faible et contiennent généralement des valeurs par défaut définies par les auteurs du rôle et sont souvent utilisées lorsqu'il est prévu que leurs valeurs soient remplacées. Les variables peuvent être définis dans `vars/main.yml` ou `defaults/main.yml`, mais pas aux deux endroits. - -L'utilisation de rôles dans un Playbook est simplement: ```yaml --- -- name: launch roles - hosts: web - roles: - - role1 - - role2 +- name: Cleanup Environment + hosts: all + become: true + vars: + package_name: httpd + tasks: + - name: Remove Apache from web servers + ansible.builtin.dnf: + name: "{{ package_name }}" + state: absent + when: inventory_hostname in groups['web'] + + - name: Remove firewalld + ansible.builtin.dnf: + name: firewalld + state: absent + + - name: Delete created users + ansible.builtin.user: + name: "{{ item }}" + state: absent + remove: true # Use 'remove: true’ to delete home directories + loop: + - alice + - bob + - carol + - Roger + + - name: Reset MOTD to an empty message + ansible.builtin.copy: + dest: /etc/motd + content: '' ``` -Pour chaque rôle, les tâches, les handlers et les variables de ce rôle seront inclus dans le Playbook, dans cet ordre. Toute tâche de copie, de script, de template ou d'inclusion peuvent référencer les fichiers par leur *nom de chemin absolu ou relatif*. Ansible les recherchera respectivement dans les fichiers en fonction de leur utilisation. - -## Étape 2 - Création d un rôle de base +### Étape 3 - Construction du Rôle Apache -Ansible recherche les rôles dans un sous-répertoire appelé `roles` dans le répertoire du projet. Cela peut être remplacé dans la configuration Ansible. Chaque rôle a son propre répertoire. Pour faciliter la création d'un nouveau rôle, l'outil `ansible-galaxy` peut être utilisé. +Nous allons développer un rôle nommé `apache` pour installer, configurer et gérer Apache. -> **Astuce** -> -> Ansible Galaxy est votre hub pour trouver, réutiliser et partager le meilleur contenu Ansible. `ansible-galaxy` aide à interagir avec Ansible Galaxy. Pour l'instant, nous allons simplement l'utiliser comme aide pour construire la structure du répertoire. +1. Générer la Structure du Rôle : -Bien, commençons à construire un rôle. Nous allons créer un rôle qui installe et configure Apache pour servir un `virtual host`. Exécutez ces commandes dans votre répertoire `~/ansible-files`: +Créez le rôle à l'aide d'ansible-galaxy, en spécifiant le répertoire des rôles pour la sortie. ```bash -[student@ansible ansible-files]$ mkdir roles -[student@ansible ansible-files]$ ansible-galaxy init --offline roles/apache_vhost +[student@ansible-1 lab_inventory]$ mkdir roles +[student@ansible-1 lab_inventory]$ ansible-galaxy init --offline roles/apache ``` -Jetez un œil aux répertoires de rôles et à leur contenu: - -```bash -[student@ansible ansible-files]$ tree roles -``` +2. Définir les Variables du Rôle : -## Étape 3 - Création du fichier de tâches +Remplissez `/home/student/lab_inventory/roles/apache/vars/main.yml` avec des variables spécifiques à Apache : -Le fichier `main.yml` dans le sous-répertoire `tasks` du rôle doit faire ce qui suit: - - - S'assurer que httpd est installé - - - S'assurer que httpd est démarré et activé - - - Mettre du contenu HTML dans la racine du document Apache - - - Installer le template fourni pour configurer le vhost +```yaml +--- +# vars file for roles/apache +apache_package_name: httpd +apache_service_name: httpd +``` -> **AVERTISSEMENT** -> -> ** Le `main.yml` (et d'autres fichiers éventuellement inclus par main.yml) ne peut contenir que des tâches, et non de Playbook complet!** +3. Configurer les Tâches du Rôle : -Accédez au répertoire `roles/apache_vhost`. Editez le fichier `tasks/main.yml`: +Ajustez `/home/student/lab_inventory/roles/apache/tasks/main.yml` pour inclure des tâches pour l'installation d'Apache et la gestion des services : ```yaml --- -- name: install httpd - yum: - name: httpd - state: latest - -- name: start and enable httpd service - service: - name: httpd +# tasks file for ansible-files/roles/apache +- name: Install Apache web server + ansible.builtin.package: + name: "{{ apache_package_name }}" + state: present + +- name: Ensure Apache is running and enabled + ansible.builtin.service: + name: "{{ apache_service_name }}" state: started enabled: true -``` -Notez qu'ici, seules les tâches ont été ajoutées. Les détails d'un playbook ne sont pas présents. +- name: Install firewalld + ansible.builtin.dnf: + name: firewalld + state: present -Les tâches ajoutées jusqu'ici font: +- name: Ensure firewalld is running + ansible.builtin.service: + name: firewalld + state: started + enabled: true - - Installez le package httpd à l'aide du module yum +- name: Allow HTTPS traffic on web servers + ansible.posix.firewalld: + service: https + permanent: true + state: enabled + when: inventory_hostname in groups['web'] + notify: Reload Firewall +``` - - Utilisez le module de service pour activer et démarrer httpd +4. Implémenter les Gestionnaires : -Ensuite, nous ajoutons deux tâches supplémentaires pour garantir une structure de répertoire vhost et copier le contenu html: +Dans `/home/student/lab_inventory/roles/apache/handlers/main.yml`, créez un gestionnaire pour redémarrer firewalld si sa configuration change : - ```yaml -- name: ensure vhost directory is present - file: - path: "/var/www/vhosts/{{ ansible_hostname }}" - state: directory - -- name: deliver html content - copy: - src: web.html - dest: "/var/www/vhosts/{{ ansible_hostname }}/index.html" +--- +# handlers file for ansible-files/roles/apache +- name: Reload Firewall + ansible.builtin.service: + name: firewalld + state: reloaded ``` - -Notez que le répertoire vhost est créé en utilisant le module `file`. +5. Créer et Déployer le Modèle : -La dernière tâche que nous ajoutons utilise le module template pour créer le fichier de configuration vhost à partir d'un modèle j2: +Utilisez un modèle Jinja2 pour un `index.html` personnalisé. Stockez le modèle dans `templates/index.html.j2` : -```yaml -- name: template vhost file - template: - src: vhost.conf.j2 - dest: /etc/httpd/conf.d/vhost.conf - owner: root - group: root - mode: 0644 - notify: - - restart_httpd +```html + + +Welcome to {{ ansible_hostname }} + + +

Hello from {{ ansible_hostname }}

+ + ``` -Notez qu'il utilise un handler pour redémarrer httpd après une mise à jour de configuration. -Le fichier complet `tasks/main.yml` est: +6. Mettre à jour `tasks/main.yml` pour déployer ce modèle `index.html` : - ```yaml ---- -- name: install httpd - yum: - name: httpd - state: latest - -- name: start and enable httpd service - service: - name: httpd - state: started - enabled: true - -- name: ensure vhost directory is present - file: - path: "/var/www/vhosts/{{ ansible_hostname }}" - state: directory - -- name: deliver html content - copy: - src: web.html - dest: "/var/www/vhosts/{{ ansible_hostname }}" - -- name: template vhost file - template: - src: vhost.conf.j2 - dest: /etc/httpd/conf.d/vhost.conf - owner: root - group: root - mode: 0644 - notify: - - restart_httpd +- name: Deploy custom index.html + ansible.builtin.template: + src: index.html.j2 + dest: /var/www/html/index.html ``` - +### Étape 4 - Intégration du Rôle dans un Playbook -## Étape 4 - Création du handler - -Créez le handler dans le fichier `handlers/main.yml` pour redémarrer httpd lorsqu'il est notifié par la tâche de modèle: +Intégrez le rôle `apache` dans un playbook nommé `deploy_apache.yml` situé dans `/home/student/lab_inventory` pour l'appliquer à vos hôtes du groupe 'web' (node1, node2, node3). ```yaml ---- -# handlers file for roles/apache_vhost -- name: restart_httpd - service: - name: httpd - state: restarted +- name: Setup Apache Web Servers + hosts: web + become: true + roles: + - apache ``` -## Étape 5 - Création des templates - -Créez le contenu HTML qui sera servi par le serveur Web. +### Étape 5 - Exécution et Validation du Rôle - - Créez un fichier web.html dans le répertoire "src" du rôle, `files`: +Lancez votre playbook pour configurer Apache sur les serveurs web désignés : ```bash -[student@ansible ansible-files]$ echo 'simple vhost index' > ~/ansible-files/roles/apache_vhost/files/web.html +ansible-navigator run deploy_apache.yml -m stdout ``` -- Créez le fichier de modèle `vhost.conf.j2` dans le sous-répertoire `templates` du rôle. +#### Sortie : - -``` -# {{ ansible_managed }} - - - ServerAdmin webmaster@{{ ansible_fqdn }} - ServerName {{ ansible_fqdn }} - ErrorLog logs/{{ ansible_hostname }}-error.log - CustomLog logs/{{ ansible_hostname }}-common.log common - DocumentRoot /var/www/vhosts/{{ ansible_hostname }}/ - - - Options +Indexes +FollowSymlinks +Includes - Order allow,deny - Allow from all - - -``` - +```plaintext +PLAY [Setup Apache Web Servers] ************************************************ -## Étape 6 - Teste du rôle +TASK [Gathering Facts] ********************************************************* +ok: [node2] +ok: [node1] +ok: [node3] -Vous êtes prêt à tester le rôle sur `node2`. Mais comme un rôle ne peut pas être attribué directement à un nœud, créez d'abord un playbook qui connecte le rôle et l'hôte. Créez le fichier `test_apache_role.yml` dans le répertoire `~/ansible-files`: +TASK [apache : Install Apache web server] ************************************** +changed: [node1] +changed: [node2] +changed: [node3] -```yaml ---- -- name: use apache_vhost role playbook - hosts: node2 - become: true +TASK [apache : Ensure Apache is running and enabled] *************************** +changed: [node2] +changed: [node1] +changed: [node3] - pre_tasks: - - debug: - msg: 'Beginning web server configuration.' +TASK [apache : Deploy custom index.html] *************************************** +changed: [node1] +changed: [node2] +changed: [node3] - roles: - - apache_vhost +RUNNING HANDLER [apache : Reload Firewall] ************************************* +ok: [node2] +ok: [node1] +ok: [node3] - post_tasks: - - debug: - msg: 'Web server has been configured.' +PLAY RECAP ********************************************************************* +node1 : ok=5 changed=3 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 +node2 : ok=5 changed=3 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 +node3 : ok=5 changed=3 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 ``` -Notez les mots clés `pre_tasks` et `post_tasks`. Normalement, les tâches des rôles s'exécutent avant les tâches d'un playbook. Pour contrôler l'ordre d'exécution, des `pre_tasks` sont effectuées avant l'application des rôles. Les `post_tasks` sont effectués une fois tous les rôles terminés. Ici, nous les utilisons simplement pour mieux mettre en évidence lorsque le rôle réel est exécuté. +### Étape 6 - Vérification du Fonctionnement d'Apache -Vous êtes maintenant prêt à exécuter votre playbook: +Une fois le playbook terminé, vérifiez que `httpd` fonctionne bien sur tous les nœuds web. ```bash -[student@ansible ansible-files]$ ansible-playbook test_apache_role.yml +[rhel@control ~]$ ssh node1 "systemctl status httpd" +● httpd.service - The Apache HTTP Server + Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled) + Active: active (running) since Mon 2024-01-29 16:49:13 UTC; 3min 46s ago ``` -Exécutez une commande curl contre `node2` pour confirmer que le rôle a fonctionné: +```bash +[rhel@control ~]$ ssh node2 "systemctl status httpd" +● httpd.service - The Apache HTTP Server + Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled) + Active: active (running) since Mon 2024-01-29 16:49:13 UTC; 3min 58s ago +``` + +Une fois que `httpd` a été vérifié comme étant en fonctionnement, vérifiez si le serveur web Apache sert bien le fichier `index.html` approprié : ```bash -[student@ansible ansible-files]$ curl -s http://node2:8080 -simple vhost index +[student@ansible-1 lab_inventory]$ curl http://node1 + + +Welcome to node1 + + +

Hello from node1

+ + ``` -Tout va bien? Toutes nos félicitations! Vous avez terminé avec succès les exercices d'atelier Ansible Engine! ----- +--- **Navigation**
-[Exercise précédent](../1.6-templates/README.fr.md) +[Exercice précédent](../1.6-templates/README.fr.md) - [Exercice suivant](../1.8-troubleshoot/README.fr.md) + +[Cliquez ici pour revenir à l'atelier Ansible pour Red Hat Enterprise Linux](../README.md#section-1---ansible-engine-exercises) -[Cliquez ici pour revenir à l'atelier Ansible pour Red Hat Enterprise Linux](../README.fr.md) diff --git a/exercises/ansible_rhel/1.7-role/README.ja.md b/exercises/ansible_rhel/1.7-role/README.ja.md index fd7ab9d94..671f05689 100644 --- a/exercises/ansible_rhel/1.7-role/README.ja.md +++ b/exercises/ansible_rhel/1.7-role/README.ja.md @@ -1,342 +1,264 @@ -# ワークショップ演習 - ロール: Playbook を再利用可能にする +# ワークショップ演習 - ロール: プレイブックを再利用可能にする -**他の言語でもお読みいただけます**: -
![uk](../../../images/uk.png) [English](README.md)、![japan](../../../images/japan.png)[日本語](README.ja.md)、![brazil](../../../images/brazil.png) [Portugues do Brasil](README.pt-br.md)、![france](../../../images/fr.png) [Française](README.fr.md)、![Español](../../../images/col.png) [Español](README.es.md) +**他の言語で読む**: +
![uk](../../../images/uk.png) [英語](README.md), ![japan](../../../images/japan.png) [日本語](README.ja.md), ![brazil](../../../images/brazil.png) [ブラジルのポルトガル語](README.pt-br.md), ![france](../../../images/fr.png) [フランス語](README.fr.md), ![Español](../../../images/col.png) [スペイン語](README.es.md). ## 目次 -* [目的](#目的) -* [ガイド](#ガイド) - * [ステップ 1 - Ansible ロール構造について](#ステップ-1---ansible-ロール構造について) - * [ステップ 2 - 基本的なロールディレクトリー構造の作成](#ステップ-2---基本的なロールディレクトリー構造の作成) - * [ステップ 3 - タスクファイルの作成](#ステップ-3---タスクファイルの作成) - * [ステップ 4 - ハンドラーの作成](#ステップ-4---ハンドラーの作成) - * [ステップ 5 - web.html と vhost 設定ファイルテンプレートの作成](#ステップ-5---webhtml-と-vhost-設定ファイルテンプレートの作成) - * [ステップ 6 - ロールのテスト](#ステップ-6---ロールのテスト) -* [トラブルシューティング問題](#トラブルシューティング問題) +- [目的](#目的) +- [ガイド](#ガイド) + - [ステップ 1 - ロールの基本](#ステップ-1---ロールの基本) + - [ステップ 2 - 環境のクリーンアップ](#ステップ-2---環境のクリーンアップ) + - [ステップ 3 - Apacheロールの構築](#ステップ-3---Apacheロールの構築) + - [ステップ 4 - プレイブックでのロールの統合](#ステップ-4---プレイブックでのロールの統合) + - [ステップ 5 - ロールの実行と検証](#ステップ-5---ロールの実行と検証) + - [ステップ 6 - Apacheが稼働していることを確認](#ステップ-6---Apacheが稼働していることを確認) ## 目的 -このワークショップ全体で行ったように、1 つのファイルで Playbook を作成することは可能ですが、最終的には複数のファイルを再利用して、整理することをお勧めします。 - -これを行うには、Ansible Roles を使用します。ロールを作成するときは、Playbook を複数のパーツに分け、それらのパーツをディレクトリー構造に配置します。これについては、[ヒントとコツ](https://docs.ansible.com/ansible/latest/user_guide/playbooks_best_practices.html) および [Ansible 設定の例](https://docs.ansible.com/ansible/latest/user_guide/sample_setup.html) で詳しく説明されています。 - -この演習では、以下について説明します。 - -* Ansible Role のフォルダー構造 -* Ansible Role を構築する方法 -* ロールを使用して実行するための Ansible Play の作成 -* Ansible を使用した node2 での Apache VirtualHost の作成 +この演習は、前の演習を基にしており、Apache（httpd）を設定するロールの作成を通じて、Ansibleスキルをさらに進化させます。変数、ハンドラー、カスタムindex.htmlのテンプレートを統合した知識を活用します。このロールは、タスク、変数、テンプレート、ハンドラーを再利用可能な構造にカプセル化し、効率的な自動化を実現する方法を示します。 ## ガイド -### ステップ 1 - Ansible ロール構造について - -ロールは、定義されたディレクトリ構造に従います。ロールは、最上位ディレクトリーによって名前が付けられます。一部のサブディレクトリーには、`main.yml` という YAML ファイルが含まれています。ファイルとテンプレートのサブディレクトリーには、YAML ファイルによって参照されるオブジェクトを含めることができます。 - -プロジェクト構造の例は次のようになります。ロールの名前は「apache」になります。 - -```text -apache/ -├── defaults -│ └── main.yml -├── files -├── handlers -│ └── main.yml -├── meta -│ └── main.yml -├── README.md -├── tasks -│ └── main.yml -├── templates -├── tests -│ ├── inventory -│ └── test.yml -└── vars - └── main.yml -``` +### ステップ 1 - ロールの基本 -さまざまな `main.yml` ファイルには、上記のディレクトリー構造内の場所に応じたコンテンツが含まれています。例えば、`vars/main.yml` は変数を参照し、`handlers/main.yaml` はハンドラーなどについて説明します。Playbook とは対照的に、`main.yml` ファイルには特定のコンテンツのみが含まれ、ホスト、`become` またはその他のキーワードなどの追加の Playbook 情報は含まれません。 +Ansibleのロールは、関連する自動化タスクやリソース（変数、テンプレート、ハンドラーなど）を構造化されたディレクトリに整理します。この演習では、再利用性とモジュール性に重点を置いて、Apache設定ロールを作成することに焦点を当てます。 -> **ヒント** -> -> `vars` と `default` には、実際には 2 つのディレクトリーがあります。デフォルトの変数 `defaults/main.yml` には最も低い優先度が付けられます。また、ロールの作成者によって設定されたデフォルト値が含まれます。これは、これらの値のオーバーライドが意図されているときに使用されます。`vars/main.yml` で設定されている変数は、変更しないことを想定した変数です。 +### ステップ 2 - 環境のクリーンアップ -Playbook でのロールの使用は簡単です。 +Apache設定に関する以前の作業を踏まえ、環境を整理するためのAnsibleプレイブックを作成しましょう。このステップは、新しいApacheロールを導入するための準備を整え、行われた調整のクリアなビューを提供します。このプロセスを通じて、Ansibleロールによって提供される多様性と再利用性についての理解を深めます。 + +環境をクリーンアップするために以下のAnsibleプレイブックを実行します： ```yaml --- -- name: launch roles - hosts: web - roles: - - role1 - - role2 +- name: Cleanup Environment + hosts: all + become: true + vars: + package_name: httpd + tasks: + - name: Remove Apache from web servers + ansible.builtin.dnf: + name: "{{ package_name }}" + state: absent + when: inventory_hostname in groups['web'] + + - name: Remove firewalld + ansible.builtin.dnf: + name: firewalld + state: absent + + - name: Delete created users + ansible.builtin.user: + name: "{{ item }}" + state: absent + remove: true # Use 'remove: true’ to delete home directories + loop: + - alice + - bob + - carol + - Roger + + - name: Reset MOTD to an empty message + ansible.builtin.copy: + dest: /etc/motd + content: '' ``` -各ロールについては、そのロールのタスク、ハンドラー、および変数が、その順序で Playbook に含まれます。ロール内のコピー、スクリプト、テンプレート、またはインクルードタスクは、*絶対パス名または相対パス名なしで*関連するファイル、テンプレート、またはタスクを参照できます。Ansible は、それらの使用に基づいて、ロールのファイル、テンプレート、またはタスクで検索します。 - +### ステップ 3 - Apacheロールの構築 -### ステップ 2 - 基本的なロールディレクトリー構造の作成 +`apache`という名前のロールを開発して、Apacheをインストール、設定、管理します。 -Ansible は、プロジェクト内の `roles` というサブディレクトリーを探します。これは、Ansible 構成でオーバーライドできます。各ロールには独自のディレクトリーがあります。新しいロールの作成を容易にするには、`ansible-galaxy` というツールを使用できます。 +1. ロール構造を生成する： -> **ヒント** -> -> Ansible Galaxy は、最適な Ansible コンテンツの検索、再利用、共有を行うためのハブです。`ansible-galaxy` は、Ansible Galaxy とのやりとりに便利です。今の時点では、ディレクトリー構造の構築を行うためのヘルパーとして使用します。 - -さて、ロールを作ってみましょう。仮想ホストにサービスを提供するように Apache をインストールして構成するロールを構築します。これらのコマンドは `~/ansible-files` ディレクトリーで実行します。 +ansible-galaxyを使用してロールを作成し、出力のためにロールディレクトリを指定します。 ```bash -[student@ansible-1 ansible-files]$ mkdir roles -[student@ansible-1 ansible-files]$ ansible-galaxy init --offline roles/apache_vhost +[student@ansible-1 lab_inventory]$ mkdir roles +[student@ansible-1 lab_inventory]$ ansible-galaxy init --offline roles/apache ``` -ロールディレクトリーとその内容を見てください。 +2. ロール変数を定義する： -```bash -[student@ansible-1 ansible-files]$ tree roles -``` +Apacheに固有の変数で `/home/student/lab_inventory/roles/apache/vars/main.yml` を埋めます： -```text -roles/ -└── apache_vhost - ├── defaults - │ └── main.yml - ├── files - ├── handlers - │ └── main.yml - ├── meta - │ └── main.yml - ├── README.md - ├── tasks - │ └── main.yml - ├── templates - ├── tests - │ ├── inventory - │ └── test.yml - └── vars - └── main.yml +```yaml +--- +# vars file for roles/apache +apache_package_name: httpd +apache_service_name: httpd ``` -### ステップ 3 - タスクファイルの作成 +3. ロールタスクを設定する： -ロールのタスクサブディレクトリーの `main.yml` は、以下を行う必要があります。 - -* httpd がインストールされていることを確認 -* httpd が起動し、有効になっていることを確認 -* HTML コンテンツを Apache ドキュメントルートに配置 -* vhost の設定用のテンプレートのインストール - -> **警告** -> -> **`main.yml` (main.yml に含まれる可能性のあるその他ファイル) は、完全な Playbook *ではなく* タスクのみを含めることができます。** - -`roles/apache_vhost/tasks/main.yml` ファイルを編集します。 +Apacheのインストールとサービス管理のタスクを含むように `/home/student/lab_inventory/roles/apache/tasks/main.yml` を調整します： ```yaml --- -- name: install httpd - yum: - name: httpd - state: latest - -- name: start and enable httpd service - service: - name: httpd +# tasks file for ansible-files/roles/apache +- name: Install Apache web server + ansible.builtin.package: + name: "{{ apache_package_name }}" + state: present + +- name: Ensure Apache is running and enabled + ansible.builtin.service: + name: "{{ apache_service_name }}" state: started enabled: true -``` -タスクが追加されたことに注意してください。Playbook の詳細は表示されません。 +- name: Install firewalld + ansible.builtin.dnf: + name: firewalld + state: present -これまで追加されたタスクは以下を行います。 +- name: Ensure firewalld is running + ansible.builtin.service: + name: firewalld + state: started + enabled: true -* yum モジュールを使用した httpd パッケージのインストール -* サービスモジュールを使用した httpd の有効化と起動 +- name: Allow HTTPS traffic on web servers + ansible.posix.firewalld: + service: https + permanent: true + state: enabled + when: inventory_hostname in groups['web'] + notify: Reload Firewall +``` -次に、vhost ディレクトリー構造を確認し、html コンテンツをコピーするための、さらに 2 つのタスクを追加します。 +4. ハンドラーを実装する： - +設定が変更された場合にfirewalldを再起動するハンドラーを `/home/student/lab_inventory/roles/apache/handlers/main.yml` に作成します： ```yaml -- name: ensure vhost directory is present - file: - path: "/var/www/vhosts/{{ ansible_hostname }}" - state: directory - -- name: deliver html content - copy: - src: web.html - dest: "/var/www/vhosts/{{ ansible_hostname }}/index.html" +--- +# handlers file for ansible-files/roles/apache +- name: Reload Firewall + ansible.builtin.service: + name: firewalld + state: reloaded ``` - - -vhost ディレクトリーは、`file` モジュールで作成/確認されることに注意してください。 +5. テンプレートを作成して展開する： -追加する最後のタスクはテンプレートモジュールを使用して、j2-template から vhost 構成ファイルを作成します。 +カスタムの `index.html` のためのJinja2テンプレートを使用します。テンプレートを `templates/index.html.j2` に保存します： -```yaml -- name: template vhost file - template: - src: vhost.conf.j2 - dest: /etc/httpd/conf.d/vhost.conf - owner: root - group: root - mode: 0644 - notify: - - restart_httpd +```html + + +Welcome to {{ ansible_hostname }} + + +

Hello from {{ ansible_hostname }}

+ + ``` -構成の更新後にハンドラーを使用して httpd を再起動していることに注意してください。 - -完全な `tasks/main.yml` ファイルは以下の通りです。 - - +6. この `index.html` テンプレートを展開するために `tasks/main.yml` を更新します： ```yaml ---- -- name: install httpd - yum: - name: httpd - state: latest - -- name: start and enable httpd service - service: - name: httpd - state: started - enabled: true - -- name: ensure vhost directory is present - file: - path: "/var/www/vhosts/{{ ansible_hostname }}" - state: directory - -- name: deliver html content - copy: - src: web.html - dest: "/var/www/vhosts/{{ ansible_hostname }}/index.html" - -- name: template vhost file - template: - src: vhost.conf.j2 - dest: /etc/httpd/conf.d/vhost.conf - owner: root - group: root - mode: 0644 - notify: - - restart_httpd +- name: Deploy custom index.html + ansible.builtin.template: + src: index.html.j2 + dest: /var/www/html/index.html ``` - +### ステップ 4 - プレイブックでのロールの統合 -### ステップ 4 - ハンドラーの作成 - -`roles/apache_vhost/handlers/main.yml` ファイルにハンドラーを作成し、テンプレートタスクで通知されたときに httpd を再起動します。 +`/home/student/lab_inventory` 内の `deploy_apache.yml` というプレイブックに `apache` ロールを埋め込んで、'web' グループホスト（node1、node2、node3）に適用します。 ```yaml ---- -# handlers file for roles/apache_vhost -- name: restart_httpd - service: - name: httpd - state: restarted +- name: Setup Apache Web Servers + hosts: web + become: true + roles: + - apache ``` -### ステップ 5 - web.html と vhost 設定ファイルテンプレートの作成 +### ステップ 5 - ロールの実行と検証 -Web サーバーによってサービスされる HTML コンテンツを作成します。 - -* ロールの「src」ディレクトリー `files` に web.html ファイルを作成します。 +デザインされたWebサーバーにApacheを設定するためにプレイブックを起動します： ```bash -#> echo 'simple vhost index' > ~/ansible-files/roles/apache_vhost/files/web.html +ansible-navigator run deploy_apache.yml -m stdout ``` -* ロールの `templates` サブディレクトリーに `vhost.conf.j2` テンプレートを作成します。 - -`vhost.conf.j2` テンプレートファイルの内容を以下に示します。 +#### 出力： - +```plaintext +PLAY [Setup Apache Web Servers] ************************************************ -```text -# {{ ansible_managed }} +TASK [Gathering Facts] ********************************************************* +ok: [node2] +ok: [node1] +ok: [node3] - - ServerAdmin webmaster@{{ ansible_fqdn }} - ServerName {{ ansible_fqdn }} - ErrorLog logs/{{ ansible_hostname }}-error.log - CustomLog logs/{{ ansible_hostname }}-common.log common - DocumentRoot /var/www/vhosts/{{ ansible_hostname }}/ - - - Options +Indexes +FollowSymlinks +Includes - Order allow,deny - Allow from all - - -``` +TASK [apache : Install Apache web server] ************************************** +changed: [node1] +changed: [node2] +changed: [node3] - +TASK [apache : Ensure Apache is running and enabled] *************************** +changed: [node2] +changed: [node1] +changed: [node3] -### ステップ 6 - ロールのテスト +TASK [apache : Deploy custom index.html] *************************************** +changed: [node1] +changed: [node2] +changed: [node3] -`node2` に対してロールをテストする準備が整いました。ただし、役割をノードに直接割り当てることはできないため、最初に役割とホストを接続する Playbook を作成します。ファイル `test_apache_role.yml` をディレクトリー `~/ansible-files` に作成します。 +RUNNING HANDLER [apache : Reload Firewall] ************************************* +ok: [node2] +ok: [node1] +ok: [node3] -```yaml ---- -- name: use apache_vhost role playbook - hosts: node2 - become: true - - pre_tasks: - - debug: - msg: 'Beginning web server configuration.' - - roles: - - apache_vhost - - post_tasks: - - debug: - msg: 'Web server has been configured.' +PLAY RECAP ********************************************************************* +node1 : ok=5 changed=3 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 +node2 : ok=5 changed=3 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 +node3 : ok=5 changed=3 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 ``` -`pre_tasks` および `post_tasks` キーワードに注目してください。通常、Playbook のタスクの前に、ロールのタスクが実行されます。実行の順序を制御するため、ロールが適用される前に `pre_tasks` が実行されます。`post_tasks` は、すべてのロールが完了した後に実行されます。ここでは、これを使用して、実際のロールが実行されたときに、わかりやすくなるようにします。 +### ステップ 6 - Apacheが稼働していることを確認 -これで、Playbook を実行する準備が整いました。 +プレイブックの完了後、すべてのWebノードで `httpd` が実際に稼働していることを確認します。 ```bash -[student@ansible-1 ansible-files]$ ansible-navigator run test_apache_role.yml +[rhel@control ~]$ ssh node1 "systemctl status httpd" +● httpd.service - The Apache HTTP Server + Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled) + Active: active (running) since Mon 2024-01-29 16:49:13 UTC; 3min 46s ago ``` -`node2` に curl コマンドを実行して、ロールが動作したことを確認します。 - ```bash -[student@ansible-1 ansible-files]$ curl -s http://node2:8080 -simple vhost index +[rhel@control ~]$ ssh node2 "systemctl status httpd" +● httpd.service - The Apache HTTP Server + Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled) + Active: active (running) since Mon 2024-01-29 16:49:13 UTC; 3min 58s ago ``` -おめでとうございます。これでこの演習は終わりです。 - -## トラブルシューティング問題 - -最後の curl は動作しましたか？ ss コマンドを実行すると、Web サーバーが動作しているポートを確認できます。 +`httpd` が稼働していることを確認したら、Apache Webサーバーが適切な `index.html` ファイルを提供しているかどうかをチェックします： ```bash -#> sudo ss -tulpn | grep httpd +[student@ansible-1 lab_inventory]$ curl http://node1 + + +Welcome to node1 + + +

Hello from node1

+ + ``` -次のような行があるはずです。 - -```bash -tcp LISTEN 0 511 *:8080 *:* users:(("httpd",pid=182567,fd=4),("httpd",pid=182566,fd=4),("httpd",pid=182565,fd=4),("httpd",pid=182552,fd=4)) -``` - -これが機能していない場合は、`/etc/httpd/conf/httpd.conf` に `Listen 8080` が指定されていることを確認してください。これは、[演習 1.5](../1.5-handlers) で変更しています。 --- **ナビゲーション**
-[前の演習](../1.6-templates) - [次の演習](../2.1-intro) +[前の演習](../1.6-templates/README.ja.md) -[次の演習](../1.8-troubleshoot/README.ja.md) + +[Red Hat Enterprise Linux のための Ansible ワークショップに戻る](../README.md#section-1---ansible-engine-exercises) + -[Click here to return to the Ansible for Red Hat Enterprise Linux Workshop](../README.md#section-1---ansible-engine-exercises) diff --git a/exercises/ansible_rhel/1.7-role/README.md b/exercises/ansible_rhel/1.7-role/README.md index 998cdccbd..f83daa5f1 100644 --- a/exercises/ansible_rhel/1.7-role/README.md +++ b/exercises/ansible_rhel/1.7-role/README.md @@ -5,338 +5,258 @@ ## Table of Contents -* [Objective](#objective) -* [Guide](#guide) - * [Step 1 - Understanding the Ansible Role Structure](#step-1---understanding-the-ansible-role-structure) - * [Step 2 - Create a Basic Role Directory Structure](#step-2---create-a-basic-role-directory-structure) - * [Step 3 - Create the Tasks File](#step-3---create-the-tasks-file) - * [Step 4 - Create the handler](#step-4---create-the-handler) - * [Step 5 - Create the web.html and vhost configuration file template](#step-5---create-the-webhtml-and-vhost-configuration-file-template) - * [Step 6 - Test the role](#step-6---test-the-role) -* [Troubleshooting problems](#troubleshooting-problems) +- [Objective](#objective) +- [Guide](#guide) + - [Step 1 - Role Basics](#step-1---role-basics) + - [Step 2 - Cleaning up the Environment](#step-2---cleaning-up-the-environment) + - [Step 3 - Building the Apache Role](#step-3---building-the-apache-role) + - [Step 4 - Role Integration in a Playbook](#step-4---role-integration-in-a-playbook) + - [Step 4 - Role Execution and Validation](#step-4---role-execution-and-validation) + - [Step 5 - Verify the Apache is Running](#step-5---verify-the-apache-is-running) ## Objective -While it is possible to write a playbook in one file as we've done throughout this workshop, eventually you’ll want to reuse files and start to organize things. - -Ansible Roles are the way we do this. When you create a role, you deconstruct your playbook into parts and those parts sit in a directory structure. This is explained in more details in the [Tips and tricks](https://docs.ansible.com/ansible/latest/user_guide/playbooks_best_practices.html) and the [Sample Ansible setup](https://docs.ansible.com/ansible/latest/user_guide/sample_setup.html). - -This exercise will cover: - -* the folder structure of an Ansible Role -* how to build an Ansible Role -* creating an Ansible Play to use and execute a role -* using Ansible to create a Apache VirtualHost on node2 +This exercise builds upon the previous exercises and advances your Ansible skills by guiding you through the creation of a role that configures Apache (httpd). You'll take the knowledge you learned to now integrate variables, handlers, and a template for a custom index.html. This role demonstrates how to encapsulate tasks, variables, templates, and handlers into a reusable structure for efficient automation. ## Guide -### Step 1 - Understanding the Ansible Role Structure - -Roles follow a defined directory structure; a role is named by the top level directory. Some of the subdirectories contain YAML files, named `main.yml`. The files and templates subdirectories can contain objects referenced by the YAML files. - -An example project structure could look like this, the name of the role would be "apache": - -```text -apache/ -├── defaults -│ └── main.yml -├── files -├── handlers -│ └── main.yml -├── meta -│ └── main.yml -├── README.md -├── tasks -│ └── main.yml -├── templates -├── tests -│ ├── inventory -│ └── test.yml -└── vars - └── main.yml -``` +### Step 1 - Role Basics -The various `main.yml` files contain content depending on their location in the directory structure shown above. For instance, `vars/main.yml` references variables, `handlers/main.yaml` describes handlers, and so on. Note that in contrast to playbooks, the `main.yml` files only contain the specific content and not additional playbook information like hosts, `become` or other keywords. +Roles in Ansible organize related automation tasks and resources, such as variables, templates, and handlers, into a structured directory. This exercise focuses on creating an Apache configuration role, emphasizing reusability and modularity. -> **Tip** -> -> There are actually two directories for variables: `vars` and `default`. Default variables, `defaults/main.yml`, have the lowest precedence and usually contain default values set by the role authors and are often used when it is intended that their values will be overridden. Variables set in `vars/main.yml` are for variables not intended to be modified. +### Step 2 - Cleaning up the Environment -Using roles in a Playbook is straight forward: +Building on our previous work with Apache configuration, let's craft an Ansible playbook dedicated to tidying up our environment. This step paves the way for us to introduce a new Apache role, providing a clear view of the adjustments made. Through this process, we'll gain deeper insights into the versatility and reusability afforded by Ansible Roles. + +Run the following Ansible playbook to clean the environment: ```yaml --- -- name: launch roles - hosts: web - roles: - - role1 - - role2 +- name: Cleanup Environment + hosts: all + become: true + vars: + package_name: httpd + tasks: + - name: Remove Apache from web servers + ansible.builtin.dnf: + name: "{{ package_name }}" + state: absent + when: inventory_hostname in groups['web'] + + - name: Remove firewalld + ansible.builtin.dnf: + name: firewalld + state: absent + + - name: Delete created users + ansible.builtin.user: + name: "{{ item }}" + state: absent + remove: true # Use 'remove: true’ to delete home directories + loop: + - alice + - bob + - carol + - Roger + + - name: Reset MOTD to an empty message + ansible.builtin.copy: + dest: /etc/motd + content: '' ``` -For each role, the tasks, handlers and variables of that role will be included in the Playbook, in that order. Any copy, script, template, or include tasks in the role can reference the relevant files, templates, or tasks *without absolute or relative path names*. Ansible will look for them in the role's files, templates, or tasks respectively, based on their -use. +### Step 3 - Building the Apache Role -### Step 2 - Create a Basic Role Directory Structure +We'll develop a role named `apache` to install, configure, and manage Apache. -Ansible looks for roles in a subdirectory called `roles` in the project directory. This can be overridden in the Ansible configuration. Each role has its own directory. To ease creation of a new role the tool `ansible-galaxy` can be used. +1. Generate Role Structure: -> **Tip** -> -> Ansible Galaxy is your hub for finding, reusing and sharing the best Ansible content. `ansible-galaxy` helps to interact with Ansible Galaxy. For now we'll just using it as a helper to build the directory structure. - -Okay, lets start to build a role. We'll build a role that installs and configures Apache to serve a virtual host. Run these commands in your `~/ansible-files` directory: +Create the role using ansible-galaxy, specifying the roles directory for output. ```bash -[student@ansible-1 ansible-files]$ mkdir roles -[student@ansible-1 ansible-files]$ ansible-galaxy init --offline roles/apache_vhost +[student@ansible-1 lab_inventory]$ mkdir roles +[student@ansible-1 lab_inventory]$ ansible-galaxy init --offline roles/apache ``` -Have a look at the role directories and their content: +2. Define Role Variables: -```bash -[student@ansible-1 ansible-files]$ tree roles -``` +Populate `/home/student/lab_inventory/roles/apache/vars/main.yml` with Apache-specific variables: -```text -roles/ -└── apache_vhost - ├── defaults - │ └── main.yml - ├── files - ├── handlers - │ └── main.yml - ├── meta - │ └── main.yml - ├── README.md - ├── tasks - │ └── main.yml - ├── templates - ├── tests - │ ├── inventory - │ └── test.yml - └── vars - └── main.yml +```yaml +--- +# vars file for roles/apache +apache_package_name: httpd +apache_service_name: httpd ``` -### Step 3 - Create the Tasks File - -The `main.yml` file in the tasks subdirectory of the role should do the following: - -* Make sure httpd is installed -* Make sure httpd is started and enabled -* Put HTML content into the Apache document root -* Install the template provided to configure the vhost +3. Configure Role Tasks: -> **WARNING** -> -> **The `main.yml` (and other files possibly included by main.yml) can only contain tasks, *not* complete playbooks!** - -Edit the `roles/apache_vhost/tasks/main.yml` file: +Adjust `/home/student/lab_inventory/roles/apache/tasks/main.yml` to include tasks for Apache installation and service management: ```yaml --- -- name: install httpd - ansible.builtin.yum: - name: httpd - state: latest +# tasks file for ansible-files/roles/apache +- name: Install Apache web server + ansible.builtin.package: + name: "{{ apache_package_name }}" + state: present -- name: start and enable httpd service +- name: Ensure Apache is running and enabled ansible.builtin.service: - name: httpd + name: "{{ apache_service_name }}" state: started enabled: true -``` -Note that here just tasks were added. The details of a playbook are not present. +- name: Install firewalld + ansible.builtin.dnf: + name: firewalld + state: present -The tasks added so far do: +- name: Ensure firewalld is running + ansible.builtin.service: + name: firewalld + state: started + enabled: true -* Install the httpd package using the yum module -* Use the service module to enable and start httpd +- name: Allow HTTPS traffic on web servers + ansible.posix.firewalld: + service: https + permanent: true + state: enabled + when: inventory_hostname in groups['web'] + notify: Reload Firewall +``` -Next we add two more tasks to ensure a vhost directory structure and copy html content: +4. Implement Handlers: - +In `/home/student/lab_inventory/roles/apache/handlers/main.yml`, create a handler to restart firewalld if its configuration changes: ```yaml -- name: ensure vhost directory is present - ansible.builtin.file: - path: "/var/www/vhosts/{{ ansible_hostname }}" - state: directory - -- name: deliver html content - ansible.builtin.copy: - src: web.html - dest: "/var/www/vhosts/{{ ansible_hostname }}/index.html" +--- +# handlers file for ansible-files/roles/apache +- name: Reload Firewall + ansible.builtin.service: + name: firewalld + state: reloaded ``` - +5. Create and Deploy Template: -Note that the vhost directory is created/ensured using the `file` module. +Use a Jinja2 template for a custom `index.html`. Store the template in `templates/index.html.j2`: -The last task we add uses the template module to create the vhost configuration file from a j2-template: - -```yaml -- name: template vhost file - ansible.builtin.template: - src: vhost.conf.j2 - dest: /etc/httpd/conf.d/vhost.conf - owner: root - group: root - mode: 0644 - notify: - - restart_httpd +```html + + +Welcome to {{ ansible_hostname }} + + +

Hello from {{ ansible_hostname }}

+ + ``` -Note it is using a handler to restart httpd after an configuration update. - -The full `tasks/main.yml` file is: - - +6. Update `tasks/main.yml` to deploy this `index.html` template: ```yaml ---- -- name: install httpd - ansible.builtin.yum: - name: httpd - state: latest - -- name: start and enable httpd service - ansible.builtin.service: - name: httpd - state: started - enabled: true - -- name: ensure vhost directory is present - ansible.builtin.file: - path: "/var/www/vhosts/{{ ansible_hostname }}" - state: directory - -- name: deliver html content - ansible.builtin.copy: - src: web.html - dest: "/var/www/vhosts/{{ ansible_hostname }}/index.html" - -- name: template vhost file +- name: Deploy custom index.html ansible.builtin.template: - src: vhost.conf.j2 - dest: /etc/httpd/conf.d/vhost.conf - owner: root - group: root - mode: 0644 - notify: - - restart_httpd + src: index.html.j2 + dest: /var/www/html/index.html ``` - +### Step 4 - Role Integration in a Playbook -### Step 4 - Create the handler - -Create the handler in the file `roles/apache_vhost/handlers/main.yml` to restart httpd when notified by the template task: +Embed the `apache` role in a playbook named `deploy_apache.yml` within `/home/student/lab_inventory` to apply it to your 'web' group hosts (node1, node2, node3). ```yaml ---- -# handlers file for roles/apache_vhost -- name: restart_httpd - ansible.builtin.service: - name: httpd - state: restarted +- name: Setup Apache Web Servers + hosts: web + become: true + roles: + - apache ``` -### Step 5 - Create the web.html and vhost configuration file template +### Step 4 - Role Execution and Validation -Create the HTML content that will be served by the webserver. - -* Create an web.html file in the "src" directory of the role, `files`: +Launch your playbook to configure Apache across the designated web servers: ```bash -#> echo 'simple vhost index' > ~/ansible-files/roles/apache_vhost/files/web.html +ansible-navigator run deploy_apache.yml -m stdout ``` -* Create the `vhost.conf.j2` template file in the role's `templates` subdirectory. - -The contents of the `vhost.conf.j2` template file are found below. - - +#### Output: -```text -# {{ ansible_managed }} +```plaintext +PLAY [Setup Apache Web Servers] ************************************************ - - ServerAdmin webmaster@{{ ansible_fqdn }} - ServerName {{ ansible_fqdn }} - ErrorLog logs/{{ ansible_hostname }}-error.log - CustomLog logs/{{ ansible_hostname }}-common.log common - DocumentRoot /var/www/vhosts/{{ ansible_hostname }}/ +TASK [Gathering Facts] ********************************************************* +ok: [node2] +ok: [node1] +ok: [node3] - - Options +Indexes +FollowSymlinks +Includes - Order allow,deny - Allow from all - - -``` - - - -### Step 6 - Test the role - -You are ready to test the role against `node2`. But since a role cannot be assigned to a node directly, first create a playbook which connects the role and the host. Create the file `test_apache_role.yml` in the directory `~/ansible-files`: +TASK [apache : Install Apache web server] ************************************** +changed: [node1] +changed: [node2] +changed: [node3] -```yaml ---- -- name: use apache_vhost role playbook - hosts: node2 - become: true +TASK [apache : Ensure Apache is running and enabled] *************************** +changed: [node2] +changed: [node1] +changed: [node3] - pre_tasks: - - ansible.builtin.debug: - msg: 'Beginning web server configuration.' +TASK [apache : Deploy custom index.html] *************************************** +changed: [node1] +changed: [node2] +changed: [node3] - roles: - - apache_vhost +RUNNING HANDLER [apache : Reload Firewall] ************************************* +ok: [node2] +ok: [node1] +ok: [node3] - post_tasks: - - ansible.builtin.debug: - msg: 'Web server has been configured.' +PLAY RECAP ********************************************************************* +node1 : ok=5 changed=3 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 +node2 : ok=5 changed=3 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 +node3 : ok=5 changed=3 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 ``` -Note the `pre_tasks` and `post_tasks` keywords. Normally, the tasks of roles execute before the tasks of a playbook. To control order of execution `pre_tasks` are performed before any roles are applied. The `post_tasks` are performed after all the roles have completed. Here we just use them to better highlight when the actual role is executed. +### Step 5 - Verify the Apache is Running -Now you are ready to run your playbook: +Once the playbook has completed, verify that `httpd` is indeed running on all the web nodes. ```bash -[student@ansible-1 ansible-files]$ ansible-navigator run test_apache_role.yml +[rhel@control ~]$ ssh node1 "systemctl status httpd" +● httpd.service - The Apache HTTP Server + Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled) + Active: active (running) since Mon 2024-01-29 16:49:13 UTC; 3min 46s ago ``` -Run a curl command against `node2` to confirm that the role worked: - -```bash -[student@ansible-1 ansible-files]$ curl -s http://node2:8080 -simple vhost index -``` - -Congratulations! You have successfully completed this exercise! - -## Troubleshooting problems - -Did the final curl work? You can see what ports the web server is running by using the ss command: - ```bash -#> sudo ss -tulpn | grep httpd +[rhel@control ~]$ ssh node2 "systemctl status httpd" +● httpd.service - The Apache HTTP Server + Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled) + Active: active (running) since Mon 2024-01-29 16:49:13 UTC; 3min 58s ago ``` -There should be a line like this: +Once `httpd` has been verified it is running, check to see if the Apache webserver is serving the appropriate `index.html` file: ```bash -tcp LISTEN 0 511 *:8080 *:* users:(("httpd",pid=182567,fd=4),("httpd",pid=182566,fd=4),("httpd",pid=182565,fd=4),("httpd",pid=182552,fd=4)) +[student@ansible-1 lab_inventory]$ curl http://node1 + + +Welcome to node1 + + +

Hello from node1

+ + ``` -Pay close attention to the fifth column of the above output. It should be `*:8080`. If it is `*:80` instead or if it is not working, then make sure that the `/etc/httpd/conf/httpd.conf` file has `Listen 8080` in it. This should have been changed by [Exercise 1.5](../1.5-handlers) --- **Navigation**
-[Previous Exercise](../1.6-templates) - [Next Exercise](../2.1-intro) +[Previous Exercise](../1.6-templates) - [Next Exercise](../1.8-troubleshoot) [Click here to return to the Ansible for Red Hat Enterprise Linux Workshop](../README.md#section-1---ansible-engine-exercises) diff --git a/exercises/ansible_rhel/1.7-role/README.pt-br.md b/exercises/ansible_rhel/1.7-role/README.pt-br.md index c75676f44..7eac04211 100644 --- a/exercises/ansible_rhel/1.7-role/README.pt-br.md +++ b/exercises/ansible_rhel/1.7-role/README.pt-br.md @@ -1,283 +1,265 @@ -# Exercício - Roles: Tornando seus playbooks reutilizáveis - -**Leia em outras linguagens**: -
![uk](../../../images/uk.png) [English](README.md), ![japan](../../../images/japan.png)[日本語](README.ja.md), ![brazil](../../../images/brazil.png) [Portugues do Brasil](README.pt-br.md), ![france](../../../images/fr.png) [Française](README.fr.md),![Español](../../../images/col.png) [Español](README.es.md). - -* [Passo 1 - Entendendo a estrutura da Role](#passo-1---entendendo-a-estrutura-da-role) -* [Passo 2 - Criando uma estrutura básica de diretório de roles](#passo-2---criando-uma-estrutura-básica-de-diretório-de-roles) -* [Passo 3 - Criando o arquivo de tasks](#passo-3---criando-o-arquivo-de-tasks) -* [Passo 4 - Criando o handler](#passo-4---criando-o-handler) -* [Passo 5 - Criando o index.html e template de arquivo de configuração do vhost](#passo-5---criando-o-indexhtml-e-template-de-arquivo-de-configuração-do-vhost) -* [Passo 6 - Teste a role](#passo-6---teste-a-role) - -Embora seja possível escrever um playbook em um arquivo, como fizemos neste workshop, você poderá reutilizar arquivos e começar a organizar as coisas. - -Roles são a maneira como fazemos isso. Quando você cria uma role, desconstrói seu playbook em partes e essas partes ficam em uma estrutura de diretórios. Isso é explicado em mais detalhes nas [melhores práticas](http://docs.ansible.com/ansible/playbooks_best_practices.html) já mencionadas no exercício 3. - -## Passo 1 - Entendendo a estrutura da Role - -As roles são basicamente a automação criada em torno das diretivas *include* e realmente não contêm muita magia adicional além de algumas melhorias no processamento do caminho de pesquisa para arquivos referenciados. - -As roles seguem uma estrutura de diretórios definida; uma role é nomeada pelo diretório de nível superior. Alguns dos subdiretórios contêm arquivos YAML, denominados `main.yml`. Os subdiretórios arquivos e templates podem conter objetos referenciados pelos arquivos YAML. - -Um exemplo de estrutura de projeto pode ser assim, o nome da role seria "apache": - -```text -apache/ -├── defaults -│ └── main.yml -├── files -├── handlers -│ └── main.yml -├── meta -│ └── main.yml -├── README.md -├── tasks -│ └── main.yml -├── templates -├── tests -│ ├── inventory -│ └── test.yml -└── vars - └── main.yml -``` +# Exercício do Workshop - Papéis: Tornando seus playbooks reutilizáveis -Os arquivos `main.yml` contêm conteúdo, dependendo da sua localização na estrutura de diretórios mostrada acima. Por exemplo, `vars/main.yml` faz referência a variáveis,`handlers/main.yaml` descreve handlers, e assim por diante. Observe que, ao contrário dos playbooks, os arquivos `main.yml` contêm apenas o conteúdo específico e não informações adicionais, como hosts, `become` ou outras palavras-chave. +**Leia isto em outros idiomas**: +
![uk](../../../images/uk.png) [Inglês](README.md), ![japan](../../../images/japan.png) [Japonês](README.ja.md), ![brazil](../../../images/brazil.png) [Português do Brasil](README.pt-br.md), ![france](../../../images/fr.png) [Francês](README.fr.md), ![Español](../../../images/col.png) [Espanhol](README.es.md). -> **Dica** -> -> Na verdade, existem dois diretórios para variáveis: `vars` e `default`: as variáveis padrão têm a menor precedência e geralmente contêm valores padrão definidos pelos autores da função e são frequentemente usadas quando pretende que seus valores sejam substituídos. pode ser definido em `vars/main.yml` ou `defaults/main.yml`, mas não nos dois lugares. +## Índice -O uso de roles em um Playbook é direto: +- [Objetivo](#objetivo) +- [Guia](#guia) + - [Etapa 1 - Fundamentos de Papéis](#etapa-1---fundamentos-de-papéis) + - [Etapa 2 - Limpando o Ambiente](#etapa-2---limpando-o-ambiente) + - [Etapa 3 - Construindo o Papel do Apache](#etapa-3---construindo-o-papel-do-apache) + - [Etapa 4 - Integração do Papel em um Playbook](#etapa-4---integração-do-papel-em-um-playbook) + - [Etapa 5 - Execução e Validação do Papel](#etapa-5---execução-e-validação-do-papel) + - [Etapa 6 - Verificando se o Apache está Executando](#etapa-6---verificando-se-o-apache-está-executando) -```yaml ---- -- name: Iniciando roles - hosts: web - roles: - - role1 - - role2 -``` +## Objetivo -As tasks, handlers e variáveis dessa role serão incluídas no Playbook, nessa ordem. Qualquer cópia, script, template ou task de inclusão na role pode fazer referência aos arquivos, templates ou tasks relevantes *sem nomes de caminho absolutos ou relativos*. O Ansible procurará por eles nos arquivos, templates ou task da role, respectivamente, com base em seu uso. +Este exercício se baseia nos exercícios anteriores e avança suas habilidades no Ansible ao guiá-lo através da criação de um papel que configura o Apache (httpd). Você usará o conhecimento adquirido para agora integrar variáveis, manipuladores e um modelo para um index.html personalizado. Este papel demonstra como encapsular tarefas, variáveis, modelos e manipuladores em uma estrutura reutilizável para automação eficiente. -## Passo 2 - Criando uma estrutura básica de diretório de roles +## Guia -Ansible procura por roles em um subdiretório chamado `roles` no diretório do projeto. Isso pode ser substituído na configuração Ansible. Cada role tem seu próprio diretório. Para facilitar a criação de um novo role, a ferramenta `ansible-galaxy` pode ser usada. +### Etapa 1 - Fundamentos de Papéis -> **Dica** -> -> Ansible Galaxy é o seu hub para encontrar, reutilizar e compartilhar o melhor conteúdo Ansible. Por enquanto, vamos usá-lo apenas como um auxiliar para criar a estrutura de diretórios. +Papéis no Ansible organizam tarefas de automação relacionadas e recursos, como variáveis, modelos e manipuladores, em um diretório estruturado. Este exercício foca na criação de um papel de configuração do Apache, enfatizando a reutilização e modularidade. -Ok, vamos começar a criar uma role. Criaremos uma role que instala e configura o Apache para servir um host virtual. Execute estes comandos no diretório `~/ansible-files`: +### Etapa 2 - Limpando o Ambiente -```bash -[student@ansible ansible-files]$ mkdir roles -[student@ansible ansible-files]$ ansible-galaxy init --offline roles/apache_vhost -``` +Com base em nosso trabalho anterior com a configuração do Apache, vamos criar um playbook do Ansible dedicado a limpar nosso ambiente. Esta etapa prepara o caminho para introduzirmos um novo papel do Apache, fornecendo uma visão clara dos ajustes realizados. Por meio desse processo, ganharemos uma compreensão mais profunda da versatilidade e reutilização oferecidas pelos Papéis do Ansible. -Dê uma olhada nos diretórios de role e seu conteúdo: +Execute o seguinte playbook do Ansible para limpar o ambiente: -```bash -[student@ansible ansible-files]$ tree roles +```yaml +--- +- name: Cleanup Environment + hosts: all + become: true + vars: + package_name: httpd + tasks: + - name: Remove Apache from web servers + ansible.builtin.dnf: + name: "{{ package_name }}" + state: absent + when: inventory_hostname in groups['web'] + + - name: Remove firewalld + ansible.builtin.dnf: + name: firewalld + state: absent + + - name: Delete created users + ansible.builtin.user: + name: "{{ item }}" + state: absent + remove: true # Use 'remove: true’ to delete home directories + loop: + - alice + - bob + - carol + - Roger + + - name: Reset MOTD to an empty message + ansible.builtin.copy: + dest: /etc/motd + content: '' ``` -## Passo 3 - Criando o arquivo de tasks +### Etapa 3 - Construindo o Papel do Apache -O arquivo `main.yml` no subdiretório de taks da role deve fazer o seguinte: +Desenvolveremos um papel chamado `apache` para instalar, configurar e gerenciar o Apache. - - Verificar se o httpd está instalado +1. Gerar Estrutura do Papel: - - Verificar se o httpd está iniciado e habilitado +Crie o papel usando o ansible-galaxy, especificando o diretório de papéis para saída. - - Colocar o conteúdo HTML na raiz do documento Apache +```bash +[student@ansible-1 lab_inventory]$ mkdir roles +[student@ansible-1 lab_inventory]$ ansible-galaxy init --offline roles/apache +``` + +2. Definir Variáveis do Papel: + +Preencha `/home/student/lab_inventory/roles/apache/vars/main.yml` com variáveis específicas do Apache: - - Instalar o template fornecido para configurar o vhost +```yaml +--- +# vars file for roles/apache +apache_package_name: httpd +apache_service_name: httpd +``` -> **ATENÇÃO** -> -> **O `main.yml` (e outros arquivos possivelmente incluídos pelo main.yml) podem conter apenas tasks, *não* Playbooks completos!** +3. Configurar Tarefas do Papel: -Mude para o diretório `functions/apache_vhost`. Edite o arquivo `tasks/main.yml`: +Ajuste `/home/student/lab_inventory/roles/apache/tasks/main.yml` para incluir tarefas para instalação e gerenciamento de serviço do Apache: ```yaml --- -- name: Instalar httpd - yum: - name: httpd - state: latest - -- name: Start e enable o servico httpd - service: - name: httpd +# tasks file for ansible-files/roles/apache +- name: Install Apache web server + ansible.builtin.package: + name: "{{ apache_package_name }}" + state: present + +- name: Ensure Apache is running and enabled + ansible.builtin.service: + name: "{{ apache_service_name }}" state: started enabled: true -``` -Observe que aqui apenas as tasks foram adicionadas. Os detalhes de um Playbook não estão presentes. +- name: Install firewalld + ansible.builtin.dnf: + name: firewalld + state: present -As tasks que foram adicionadas até o momento: +- name: Ensure firewalld is running + ansible.builtin.service: + name: firewalld + state: started + enabled: true - - Instalar o pacote httpd usando o módulo yum +- name: Allow HTTPS traffic on web servers + ansible.posix.firewalld: + service: https + permanent: true + state: enabled + when: inventory_hostname in groups['web'] + notify: Reload Firewall +``` - - Usar o módulo de serviço para dar start e enable no httpd +4. Implementar Manipuladores: -Em seguida, adicionamos mais duas tasks para garantir uma estrutura de diretórios vhost e copiar o conteúdo html: +Em `/home/student/lab_inventory/roles/apache/handlers/main.yml`, crie um manipulador para reiniciar o firewalld se sua configuração mudar: - ```yaml -- name: Verificar se o diretoio vhost esta presente - file: - path: "/var/www/vhosts/{{ ansible_hostname }}" - state: directory - -- name: Entregar conteúdo html - copy: - src: index.html - dest: "/var/www/vhosts/{{ ansible_hostname }}" +--- +# handlers file for ansible-files/roles/apache +- name: Reload Firewall + ansible.builtin.service: + name: firewalld + state: reloaded ``` - -Note que o diretório vhost é criado/garantido usando o módulo `file`. +5. Criar e Implementar Modelo: -A última task que adicionamos usa o módulo de template para criar o arquivo de configuração do vhost a partir de um template j2: +Use um modelo Jinja2 para um `index.html` personalizado. Armazene o modelo em `templates/index.html.j2`: -```yaml -- name: Template arquivo vhost - template: - src: vhost.conf.j2 - dest: /etc/httpd/conf.d/vhost.conf - owner: root - group: root - mode: 0644 - notify: - - restart_httpd +```html + + +Welcome to {{ ansible_hostname }} + + +

Hello from {{ ansible_hostname }}

+ + ``` -Observe que ele está usando um handler para reiniciar o httpd após uma atualização de configuração. -O arquivo completo `tasks/main.yml` é: +6. Atualize `tasks/main.yml` para implementar este modelo `index.html`: - ```yaml ---- -- name: Instalar httpd - yum: - name: httpd - state: latest - -- name: Start e enable o servico httpd - service: - name: httpd - state: started - enabled: true - -- name: Verificar se o diretório vhost está presente - file: - path: "/var/www/vhosts/{{ ansible_hostname }}" - state: directory - -- name: Entregar conteúdo html - copy: - src: index.html - dest: "/var/www/vhosts/{{ ansible_hostname }}" - -- name: Template arquivo vhost - template: - src: vhost.conf.j2 - dest: /etc/httpd/conf.d/vhost.conf - owner: root - group: root - mode: 0644 - notify: - - restart_httpd +- name: Deploy custom index.html + ansible.builtin.template: + src: index.html.j2 + dest: /var/www/html/index.html ``` - - -## Passo 4 - Criando o handler +### Etapa 4 - Integração do Papel em um Playbook -Crie o handler no arquivo `handlers/main.yml` para reiniciar o httpd quando notificado pela task do template: +Incorpore o papel `apache` em um playbook chamado `deploy_apache.yml` dentro de `/home/student/lab_inventory` para aplicá-lo aos seus hosts do grupo 'web' (node1, node2, node3). ```yaml ---- -# arquivo de handlers para roles/apache_vhost -- name: restart_httpd - service: - name: httpd - state: restarted +- name: Setup Apache Web Servers + hosts: web + become: true + roles: + - apache ``` -## Passo 5 - Criando o index.html e template de arquivo de configuração do vhost - -Crie o conteúdo HTML que será exibido pelo servidor web. +### Etapa 5 - Execução e Validação do Papel - - Crie um arquivo index.html no diretório "src" da role, `files` : +Execute seu playbook para configurar o Apache nos servidores web designados: ```bash -[student@ansible ansible-files]$ echo 'vhost index' > ~/ansible-files/roles/apache_vhost/files/index.html +ansible-navigator run deploy_apache.yml -m stdout ``` - - Crie o arquivo de template `vhost.conf.j2` no subdiretório `templates` da role. +#### Saída: - -```html -# {{ ansible_managed }} - - - ServerAdmin webmaster@{{ ansible_fqdn }} - ServerName {{ ansible_fqdn }} - ErrorLog logs/{{ ansible_hostname }}-error.log - CustomLog logs/{{ ansible_hostname }}-common.log common - DocumentRoot /var/www/vhosts/{{ ansible_hostname }}/ - - - Options +Indexes +FollowSymlinks +Includes - Order allow,deny - Allow from all - - -``` - +```plaintext +PLAY [Setup Apache Web Servers] ************************************************ -## Passo 6 - Teste a role +TASK [Gathering Facts] ********************************************************* +ok: [node2] +ok: [node1] +ok: [node3] -Você está pronto para testar a role no `node2`. Mas como uma role não pode ser atribuída diretamente a um nó, primeiro crie um Playbook que conecte a role e o host. Crie o arquivo `test_apache_role.yml` no diretório `~/ansible-files`: +TASK [apache : Install Apache web server] ************************************** +changed: [node1] +changed: [node2] +changed: [node3] -```yaml ---- -- name: Use apache_vhost role playbook - hosts: node2 - become: true +TASK [apache : Ensure Apache is running and enabled] *************************** +changed: [node2] +changed: [node1] +changed: [node3] - pre_tasks: - - debug: - msg: 'Iniciando a configuracao do servidor web.' +TASK [apache : Deploy custom index.html] *************************************** +changed: [node1] +changed: [node2] +changed: [node3] - roles: - - apache_vhost +RUNNING HANDLER [apache : Reload Firewall] ************************************* +ok: [node2] +ok: [node1] +ok: [node3] - post_tasks: - - debug: - msg: 'Servidor web foi configurado.' +PLAY RECAP ********************************************************************* +node1 : ok=5 changed=3 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 +node2 : ok=5 changed=3 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 +node3 : ok=5 changed=3 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 ``` -Observe as palavras-chave `pre_tasks` e` post_tasks`. Normalmente, as tasks das roles são executadas antes das tasks de um Playbook. Para controlar a ordem de execução, as `pre_tasks` são executadas antes que quaisquer roles sejam aplicadas. As `post_tasks` são executadas após a conclusão de todas as roles. Aqui, apenas as usamos para destacar melhor quando a role real é executada. +### Etapa 6 - Verificando se o Apache está Executando + +Após a conclusão do playbook, verifique se o `httpd` está realmente em execução em todos os nós web. -Agora você está pronto para executar seu playbook: +```bash +[rhel@control ~]$ ssh node1 "systemctl status httpd" +● httpd.service - The Apache HTTP Server + Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled) + Active: active (running) since Mon 2024-01-29 16:49:13 UTC; 3min 46s ago +``` ```bash -[student@ansible ansible-files]$ ansible-playbook test_apache_role.yml +[rhel@control ~]$ ssh node2 "systemctl status httpd" +● httpd.service - The Apache HTTP Server + Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled) + Active: active (running) since Mon 2024-01-29 16:49:13 UTC; 3min 58s ago ``` -Execute um comando curl no `node2` para confirmar que a role funcionou: +Uma vez verificado que o `httpd` está em execução, verifique se o servidor web Apache está servindo o arquivo `index.html` apropriado: ```bash -[student@ansible ansible-files]$ curl -s http://node2:8080 -vhost index +[student@ansible-1 lab_inventory]$ curl http://node1 + + +Welcome to node1 + + +

Hello from node1

+ + ``` -Deu tudo certo? Parabéns! Você concluiu com êxito os exercícios do Workshop do Ansible Engine! ----- +--- +**Navegação** +
+[Exercício anterior](../1.6-templates/README.pt-br.md) - [Próximo exercício](../1.8-troubleshoot/README.pt-br.md) + +[Clique aqui para retornar ao workshop de Ansible para Red Hat Enterprise Linux](../README.md#section-1---ansible-engine-exercises) + + -[Clique aqui para retornar ao Workshop Ansible for Red Hat Enterprise Linux](../README.pt-br.md#seção-1---exercícios-do-ansible-engine) diff --git a/exercises/ansible_rhel/1.8-troubleshoot/README.es.md b/exercises/ansible_rhel/1.8-troubleshoot/README.es.md new file mode 100644 index 000000000..4651cc384 --- /dev/null +++ b/exercises/ansible_rhel/1.8-troubleshoot/README.es.md @@ -0,0 +1,161 @@ +# Ejercicio del Taller - Depuración y Manejo de Errores + +**Leer esto en otros idiomas**: +
![uk](../../../images/uk.png) [Inglés](README.md), ![japan](../../../images/japan.png) [Japonés](README.ja.md), ![brazil](../../../images/brazil.png) [Portugués de Brasil](README.pt-br.md), ![france](../../../images/fr.png) [Francés](README.fr.md), ![Español](../../../images/col.png) [Español](README.es.md). + +## Índice de Contenidos + +- [Objetivo](#objetivo) +- [Guía](#guía) + - [Paso 1 - Introducción a la Depuración en Ansible](#paso-1---introducción-a-la-depuración-en-ansible) + - [Paso 2 - Utilizando el Módulo de Depuración](#paso-2---utilizando-el-módulo-de-depuración) + - [Paso 3 - Manejo de Errores con Bloques](#paso-3---manejo-de-errores-con-bloques) + - [Paso 4 - Ejecución en Modo Verboso](#paso-4---ejecución-en-modo-verboso) + - [Resumen](#resumen) + +## Objetivo + +Basándose en el conocimiento fundamental de los ejercicios anteriores, esta sesión se centra en la depuración y el manejo de errores dentro de Ansible. Aprenderás técnicas para solucionar problemas en los playbooks, gestionar errores de forma elegante y garantizar que tu automatización sea robusta y fiable. + +## Guía + +### Paso 1 - Introducción a la Depuración en Ansible + +La depuración es una habilidad crítica para identificar y resolver problemas dentro de tus playbooks de Ansible. Ansible proporciona varios mecanismos para ayudarte a depurar tus scripts de automatización, incluyendo el módulo de depuración, niveles de verbosidad aumentados y estrategias de manejo de errores. + +### Paso 2 - Utilizando el Módulo de Depuración + +El módulo `debug` es una herramienta simple pero poderosa para imprimir los valores de las variables, lo cual puede ser instrumental para entender el flujo de ejecución del playbook. + +En este ejemplo, añade tareas de depuración a tu rol de Apache en el `tasks/main.yml` para mostrar el valor de las variables o mensajes. + +#### Implementar Tareas de Depuración: + +Inserta tareas de depuración para mostrar los valores de las variables o mensajes personalizados para la solución de problemas: + +```yaml +- name: Display Variable Value + ansible.builtin.debug: + var: apache_service_name + +- name: Display Custom Message + ansible.builtin.debug: + msg: "Apache service name is {{ apache_service_name }}" +``` + +### Paso 3 - Manejo de Errores con Bloques + +Ansible permite agrupar tareas usando `block` y manejar errores con secciones `rescue`, similar a try-catch en la programación tradicional. + +En este ejemplo, añade un bloque para manejar errores potenciales durante la configuración de Apache dentro del archivo `tasks/main.yml`. + +1. Agrupar Tareas y Manejar Errores: + +Envuelve las tareas que podrían fallar potencialmente en un bloque y define una sección de rescate para manejar los errores: + +```yaml +- name: Apache Configuration with Potential Failure Point + block: + - name: Copy Apache configuration + ansible.builtin.copy: + src: "{{ apache_conf_src }}" + dest: "/etc/httpd/conf/httpd.conf" + rescue: + - name: Handle Missing Configuration + ansible.builtin.debug: + msg: "Missing Apache configuration file '{{ apache_conf_src }}'. Using default settings." +``` + +2. Añade una variable `apache_conf_src` dentro de `vars/main.yml` del rol apache. + +```yaml +apache_conf_src: "files/missing_apache.conf" +``` + +> NOTA: Este archivo no existe explícitamente para que podamos activar la parte de rescate de nuestro `tasks/main.yml` + +### Paso 4 - Ejecución en Modo Verboso + +El modo verboso de Ansible (-v, -vv, -vvv o -vvvv) aumenta el detalle de la salida, proporcionando más información sobre la ejecución del playbook y los problemas potenciales. + +#### Ejecutar el Playbook en Modo Verboso: + +Ejecuta tu playbook con la opción `-vv` para obtener registros detallados: + +```bash +ansible-navigator run deploy_apache.yml -m stdout -vv +``` + +``` +. +. +. + +TASK [apache : Display Variable Value] ***************************************** +task path: /home/rhel/ansible-files/roles/apache/tasks/main.yml:20 +ok: [node1] => { + "apache_service_name": "httpd" +} +ok: [node2] => { + "apache_service_name": "httpd" +} +ok: [node3] => { + "apache_service_name": "httpd" +} + +TASK [apache : Display Custom Message] ***************************************** +task path: /home/rhel/ansible-files/roles/apache/tasks/main.yml:24 +ok: [node1] => { + "msg": "Apache service name is httpd" +} +ok: [node2] => { + "msg": "Apache service name is httpd" +} +ok: [node3] => { + "msg": "Apache service name is httpd" +} + +TASK [apache : Copy Apache configuration] ************************************** +task path: /home/rhel/ansible-files/roles/apache/tasks/main.yml:30 +An exception occurred during task execution. To see the full traceback, use -vvv. The error was: If you are using a module and expect the file to exist on the remote, see the remote_src option +fatal: [node3]: FAILED! => {"changed": false, "msg": "Could not find or access 'files/missing_apache.conf'\nSearched in:\n\t/home/student/lab_inventory/roles/apache/files/files/missing_apache.conf\n\t/home/student/lab_inventory/roles/apache/files/missing_apache.conf\n\t/home/student/lab_inventory/roles/apache/tasks/files/files/missing_apache.conf\n\t/home/student/lab_inventory/roles/apache/tasks/files/missing_apache.conf\n\t/home/student/lab_inventory/files/files/missing_apache.conf\n\t/home/student/lab_inventory/files/missing_apache.conf on the Ansible Controller.\nIf you are using a module and expect the file to exist on the remote, see the remote_src option"} +An exception occurred during task execution. To see the full traceback, use -vvv. The error was: If you are using a module and expect the file to exist on the remote, see the remote_src option +fatal: [node1]: FAILED! => {"changed": false, "msg": "Could not find or access 'files/missing_apache.conf'\nSearched in:\n\t/home/student/lab_inventory/roles/apache/files/files/missing_apache.conf\n\t/home/student/lab_inventory/roles/apache/files/missing_apache.conf\n\t/home/student/lab_inventory/roles/apache/tasks/files/files/missing_apache.conf\n\t/home/student/lab_inventory/roles/apache/tasks/files/missing_apache.conf\n\t/home/student/lab_inventory/files/files/missing_apache.conf\n\t/home/student/lab_inventory/files/missing_apache.conf on the Ansible Controller.\nIf you are using a module and expect the file to exist on the remote, see the remote_src option"} +An exception occurred during task execution. To see the full traceback, use -vvv. The error was: If you are using a module and expect the file to exist on the remote, see the remote_src option +fatal: [node2]: FAILED! => {"changed": false, "msg": "Could not find or access 'files/missing_apache.conf'\nSearched in:\n\t/home/student/lab_inventory/roles/apache/files/files/missing_apache.conf\n\t/home/student/lab_inventory/roles/apache/files/missing_apache.conf\n\t/home/student/lab_inventory/roles/apache/tasks/files/files/missing_apache.conf\n\t/home/student/lab_inventory/roles/apache/tasks/files/missing_apache.conf\n\t/home/student/lab_inventory/files/files/missing_apache.conf\n\t/home/student/lab_inventory/files/missing_apache.conf on the Ansible Controller.\nIf you are using a module and expect the file to exist on the remote, see the remote_src option"} + + +TASK [apache : Handle Missing Configuration] *********************************** +task path: /home/rhel/ansible-files/roles/apache/tasks/main.yml:39 +ok: [node1] => { + "msg": "Missing Apache configuration file 'files/missing_apache.conf'. Using default settings." +} +ok: [node2] => { + "msg": "Missing Apache configuration file 'files/missing_apache.conf'. Using default settings." +} +ok: [node3] => { + "msg": "Missing Apache configuration file 'files/missing_apache.conf'. Using default settings." +} + +PLAY RECAP ********************************************************************* +node1 : ok=7 changed=0 unreachable=0 failed=0 skipped=0 rescued=1 ignored=0 +node2 : ok=7 changed=0 unreachable=0 failed=0 skipped=0 rescued=1 ignored=0 +node3 : ok=7 changed=0 unreachable=0 failed=0 skipped=0 rescued=1 ignored=0 + +``` + +Observa cómo el playbook muestra que hubo un error al copiar el archivo de configuración de Apache, pero el playbook pudo manejarlo a través del bloque de rescate proporcionado. Si notas, la tarea final 'Handle Missing Configuration' detalla que faltaba el archivo y se usarían los ajustes predeterminados. + +El Resumen Final del Juego nos muestra que se utilizó un bloque rescatado a través de `rescued=1` por nodo en el grupo web. + +## Resumen + +En este ejercicio, has explorado técnicas esenciales de depuración y mecanismos de manejo de errores en Ansible. Al incorporar tareas de depuración, usar bloques para el manejo de errores y aprovechar el modo verboso, puedes solucionar problemas de manera efectiva y mejorar la fiabilidad de tus playbooks de Ansible. Estas prácticas son fundamentales en el desarrollo de una automatización robusta de Ansible que pueda manejar problemas inesperados de manera elegante y garantizar resultados consistentes y predecibles. + +--- +**Navegación** +
+[Ejercicio Anterior](../1.7-role) - [Próximo Ejercicio](../2.1-intro) + +[Haz clic aquí para volver al Taller de Ansible para Red Hat Enterprise Linux](../README.md#section-1---ansible-engine-exercises) + diff --git a/exercises/ansible_rhel/1.8-troubleshoot/README.fr.md b/exercises/ansible_rhel/1.8-troubleshoot/README.fr.md new file mode 100644 index 000000000..ad7a22d8d --- /dev/null +++ b/exercises/ansible_rhel/1.8-troubleshoot/README.fr.md @@ -0,0 +1,161 @@ +# Exercice de l'Atelier - Débogage et Gestion des Erreurs + +**Lire ceci dans d'autres langues** : +
![uk](../../../images/uk.png) [Anglais](README.md), ![japan](../../../images/japan.png) [Japonais](README.ja.md), ![brazil](../../../images/brazil.png) [Portugais du Brésil](README.pt-br.md), ![france](../../../images/fr.png) [Français](README.fr.md), ![Español](../../../images/col.png) [Espagnol](README.es.md). + +## Table des Matières + +- [Objectif](#objectif) +- [Guide](#guide) + - [Étape 1 - Introduction au Débogage dans Ansible](#étape-1---introduction-au-débogage-dans-ansible) + - [Étape 2 - Utilisation du Module Debug](#étape-2---utilisation-du-module-debug) + - [Étape 3 - Gestion des Erreurs avec les Blocs](#étape-3---gestion-des-erreurs-avec-les-blocs) + - [Étape 4 - Exécution en Mode Verbeux](#étape-4---exécution-en-mode-verbeux) + - [Résumé](#résumé) + +## Objectif + +En s'appuyant sur les connaissances de base des exercices précédents, cette session se concentre sur le débogage et la gestion des erreurs dans Ansible. Vous apprendrez des techniques pour dépanner les playbooks, gérer les erreurs de manière élégante et assurer la robustesse et la fiabilité de votre automatisation. + +## Guide + +### Étape 1 - Introduction au Débogage dans Ansible + +Le débogage est une compétence essentielle pour identifier et résoudre les problèmes au sein de vos playbooks Ansible. Ansible propose plusieurs mécanismes pour vous aider à déboguer vos scripts d'automatisation, y compris le module debug, les niveaux de verbosité augmentés et les stratégies de gestion des erreurs. + +### Étape 2 - Utilisation du Module Debug + +Le module `debug` est un outil simple mais puissant pour imprimer les valeurs des variables, ce qui peut être essentiel pour comprendre le flux d'exécution du playbook. + +Dans cet exemple, ajoutez des tâches de débogage à votre rôle Apache dans le `tasks/main.yml` pour afficher la valeur des variables ou des messages. + +#### Implémenter des Tâches de Débogage : + +Insérez des tâches de débogage pour afficher les valeurs des variables ou des messages personnalisés pour le dépannage : + +```yaml +- name: Display Variable Value + ansible.builtin.debug: + var: apache_service_name + +- name: Display Custom Message + ansible.builtin.debug: + msg: "Le nom du service Apache est {{ apache_service_name }}" +``` + +### Étape 3 - Gestion des Erreurs avec les Blocs + +Ansible permet de regrouper des tâches en utilisant `block` et de gérer les erreurs avec des sections `rescue`, similaires à try-catch dans la programmation traditionnelle. + +Dans cet exemple, ajoutez un bloc pour gérer les erreurs potentielles lors de la configuration d'Apache dans le fichier `tasks/main.yml`. + +1. Grouper les Tâches et Gérer les Erreurs : + +Enveloppez les tâches qui pourraient potentiellement échouer dans un bloc et définissez une section de secours pour gérer les erreurs : + +```yaml +- name: Configuration d'Apache avec Point de Défaillance Potentiel + block: + - name: Copier la configuration d'Apache + ansible.builtin.copy: + src: "{{ apache_conf_src }}" + dest: "/etc/httpd/conf/httpd.conf" + rescue: + - name: Gérer la Configuration Manquante + ansible.builtin.debug: + msg: "Fichier de configuration Apache manquant '{{ apache_conf_src }}'. Utilisation des paramètres par défaut." +``` + +2. Ajoutez une variable `apache_conf_src` dans `vars/main.yml` du rôle apache. + +```yaml +apache_conf_src: "files/missing_apache.conf" +``` + +> NOTE : Ce fichier n'existe pas explicitement pour que nous puissions déclencher la partie rescue de notre `tasks/main.yml` + +### Étape 4 - Exécution en Mode Verbeux + +Le mode verbeux d'Ansible (-v, -vv, -vvv ou -vvvv) augmente le détail de la sortie, fournissant plus d'informations sur l'exécution du playbook et les problèmes potentiels. + +#### Exécuter le Playbook en Mode Verbeux : + +Exécutez votre playbook avec l'option `-vv` pour obtenir des journaux détaillés : + +```bash +ansible-navigator run deploy_apache.yml -m stdout -vv +``` + +``` +. +. +. + +TASK [apache : Display Variable Value] ***************************************** +task path: /home/rhel/ansible-files/roles/apache/tasks/main.yml:20 +ok: [node1] => { + "apache_service_name": "httpd" +} +ok: [node2] => { + "apache_service_name": "httpd" +} +ok: [node3] => { + "apache_service_name": "httpd" +} + +TASK [apache : Display Custom Message] ***************************************** +task path: /home/rhel/ansible-files/roles/apache/tasks/main.yml:24 +ok: [node1] => { + "msg": "Le nom du service Apache est httpd" +} +ok: [node2] => { + "msg": "Le nom du service Apache est httpd" +} +ok: [node3] => { + "msg": "Le nom du service Apache est httpd" +} + +TASK [apache : Copy Apache configuration] ************************************** +task path: /home/rhel/ansible-files/roles/apache/tasks/main.yml:30 +Une exception s'est produite pendant l'exécution de la tâche. Pour voir la trace complète, utilisez -vvv. L'erreur était : Si vous utilisez un module et vous attendez à ce que le fichier existe sur le distant, consultez l'option remote_src +fatal: [node3]: FAILED! => {"changed": false, "msg": "Impossible de trouver ou d'accéder à 'files/missing_apache.conf'\nRecherché dans :\n\t/home/student/lab_inventory/roles/apache/files/files/missing_apache.conf\n\t/home/student/lab_inventory/roles/apache/files/missing_apache.conf\n\t/home/student/lab_inventory/roles/apache/tasks/files/files/missing_apache.conf\n\t/home/student/lab_inventory/roles/apache/tasks/files/missing_apache.conf\n\t/home/student/lab_inventory/files/files/missing_apache.conf\n\t/home/student/lab_inventory/files/missing_apache.conf sur le contrôleur Ansible.\nSi vous utilisez un module et vous attendez à ce que le fichier existe sur le distant, consultez l'option remote_src"} +Une exception s'est produite pendant l'exécution de la tâche. Pour voir la trace complète, utilisez -vvv. L'erreur était : Si vous utilisez un module et vous attendez à ce que le fichier existe sur le distant, consultez l'option remote_src +fatal: [node1]: FAILED! => {"changed": false, "msg": "Impossible de trouver ou d'accéder à 'files/missing_apache.conf'\nRecherché dans :\n\t/home/student/lab_inventory/roles/apache/files/files/missing_apache.conf\n\t/home/student/lab_inventory/roles/apache/files/missing_apache.conf\n\t/home/student/lab_inventory/roles/apache/tasks/files/files/missing_apache.conf\n\t/home/student/lab_inventory/roles/apache/tasks/files/missing_apache.conf\n\t/home/student/lab_inventory/files/files/missing_apache.conf\n\t/home/student/lab_inventory/files/missing_apache.conf sur le contrôleur Ansible.\nSi vous utilisez un module et vous attendez à ce que le fichier existe sur le distant, consultez l'option remote_src"} +Une exception s'est produite pendant l'exécution de la tâche. Pour voir la trace complète, utilisez -vvv. L'erreur était : Si vous utilisez un module et vous attendez à ce que le fichier existe sur le distant, consultez l'option remote_src +fatal: [node2]: FAILED! => {"changed": false, "msg": "Impossible de trouver ou d'accéder à 'files/missing_apache.conf'\nRecherché dans :\n\t/home/student/lab_inventory/roles/apache/files/files/missing_apache.conf\n\t/home/student/lab_inventory/roles/apache/files/missing_apache.conf\n\t/home/student/lab_inventory/roles/apache/tasks/files/files/missing_apache.conf\n\t/home/student/lab_inventory/roles/apache/tasks/files/missing_apache.conf\n\t/home/student/lab_inventory/files/files/missing_apache.conf\n\t/home/student/lab_inventory/files/missing_apache.conf sur le contrôleur Ansible.\nSi vous utilisez un module et vous attendez à ce que le fichier existe sur le distant, consultez l'option remote_src"} + + +TASK [apache : Handle Missing Configuration] *********************************** +task path: /home/rhel/ansible-files/roles/apache/tasks/main.yml:39 +ok: [node1] => { + "msg": "Fichier de configuration Apache manquant 'files/missing_apache.conf'. Utilisation des paramètres par défaut." +} +ok: [node2] => { + "msg": "Fichier de configuration Apache manquant 'files/missing_apache.conf'. Utilisation des paramètres par défaut." +} +ok: [node3] => { + "msg": "Fichier de configuration Apache manquant 'files/missing_apache.conf'. Utilisation des paramètres par défaut." +} + +PLAY RECAP ********************************************************************* +node1 : ok=7 changed=0 unreachable=0 failed=0 skipped=0 rescued=1 ignored=0 +node2 : ok=7 changed=0 unreachable=0 failed=0 skipped=0 rescued=1 ignored=0 +node3 : ok=7 changed=0 unreachable=0 failed=0 skipped=0 rescued=1 ignored=0 + +``` + +Remarquez comment le playbook indique qu'il y avait une erreur lors de la copie du fichier de configuration Apache, mais que le playbook a pu la gérer via le bloc de secours fourni. Si vous remarquez, la tâche finale 'Gérer la Configuration Manquante' indique que le fichier était manquant et qu'il utiliserait les paramètres par défaut. + +Le Récapitulatif Final de la Lecture nous montre qu'un bloc secouru a été utilisé via `rescued=1` par nœud dans le groupe web. + +## Résumé + +Dans cet exercice, vous avez exploré des techniques de débogage essentielles et des mécanismes de gestion des erreurs dans Ansible. En intégrant des tâches de débogage, en utilisant des blocs pour la gestion des erreurs et en tirant parti du mode verbeux, vous pouvez efficacement dépanner et améliorer la fiabilité de vos playbooks Ansible. Ces pratiques sont fondamentales dans le développement d'une automatisation robuste avec Ansible qui peut gérer de manière élégante les problèmes inattendus et assurer des résultats cohérents et prévisibles. + +--- +**Navigation** +
+[Exercice Précédent](../1.7-role/README.fr.md) - [Prochain Exercice](../2.1-intro/README.fr.md) + +[Cliquez ici pour retourner à l'atelier Ansible pour Red Hat Enterprise Linux](../README.md#section-1---ansible-engine-exercises) + diff --git a/exercises/ansible_rhel/1.8-troubleshoot/README.ja.md b/exercises/ansible_rhel/1.8-troubleshoot/README.ja.md new file mode 100644 index 000000000..c95b928ae --- /dev/null +++ b/exercises/ansible_rhel/1.8-troubleshoot/README.ja.md @@ -0,0 +1,159 @@ +# ワークショップ演習 - デバッグとエラーハンドリング + +**他の言語で読む** : +
![uk](../../../images/uk.png) [英語](README.md), ![japan](../../../images/japan.png) [日本語](README.ja.md), ![brazil](../../../images/brazil.png) [ブラジルのポルトガル語](README.pt-br.md), ![france](../../../images/fr.png) [フランス語](README.fr.md), ![Español](../../../images/col.png) [スペイン語](README.es.md). + +## 目次 + +- [目的](#目的) +- [ガイド](#ガイド) + - [ステップ 1 - Ansibleでのデバッグ入門](#ステップ-1---Ansibleでのデバッグ入門) + - [ステップ 2 - デバッグモジュールの利用](#ステップ-2---デバッグモジュールの利用) + - [ステップ 3 - ブロックによるエラーハンドリング](#ステップ-3---ブロックによるエラーハンドリング) + - [ステップ 4 - 詳細モードでの実行](#ステップ-4---詳細モードでの実行) + - [まとめ](#まとめ) + +## 目的 + +これまでの演習で得た基礎知識を基に、このセッションではAnsible内でのデバッグとエラーハンドリングに焦点を当てます。プレイブックのトラブルシューティング、エラーの上手な管理、堅牢で信頼性の高い自動化を実現するためのテクニックを学びます。 + +## ガイド + +### ステップ 1 - Ansibleでのデバッグ入門 + +デバッグは、Ansibleプレイブック内の問題を特定し解決するための重要なスキルです。Ansibleはデバッグモジュール、詳細度レベルの増加、エラーハンドリング戦略など、自動化スクリプトのデバッグを支援するいくつかのメカニズムを提供します。 + +### ステップ 2 - デバッグモジュールの利用 + +`debug` モジュールは、変数の値を出力するためのシンプルだが強力なツールであり、プレイブックの実行フローを理解する上で重要です。 + +この例では、変数の値またはメッセージを出力するデバッグタスクを `tasks/main.yml` のApacheロールに追加します。 + +#### デバッグタスクの実装 : + +変数の値やカスタムメッセージを表示するデバッグタスクを挿入します : + +```yaml +- name: Display Variable Value + ansible.builtin.debug: + var: apache_service_name + +- name: Display Custom Message + ansible.builtin.debug: + msg: "Apacheサービス名は {{ apache_service_name }} です" +``` + +### ステップ 3 - ブロックによるエラーハンドリング + +Ansibleでは `block` を使用してタスクをグループ化し、`rescue` セクションでエラーを処理できます。これは伝統的なプログラミングのtry-catchに似ています。 + +この例では、`tasks/main.yml` ファイル内でApacheの設定中に発生する可能性のあるエラーを処理するためのブロックを追加します。 + +1. タスクのグループ化とエラーの処理 : + +失敗する可能性のあるタスクをブロックでラップし、エラーを処理するためのレスキューセクションを定義します : + +```yaml +- name: Apache Configuration with Potential Failure Point + block: + - name: Copy Apache configuration + ansible.builtin.copy: + src: "{{ apache_conf_src }}" + dest: "/etc/httpd/conf/httpd.conf" + rescue: + - name: Handle Missing Configuration + ansible.builtin.debug: + msg: "Apache設定ファイル '{{ apache_conf_src }}' が見つかりません。デフォルト設定を使用します。" +``` + +2. apacheロールの `vars/main.yml` 内に `apache_conf_src` 変数を追加します。 + +```yaml +apache_conf_src: "files/missing_apache.conf" +``` + +> 注: このファイルは意図的に存在しないため、`tasks/main.yml` のレスキュー部分をトリガーすることができます。 + +### ステップ 4 - 詳細モードでの実行 + +Ansibleの詳細モード(-v, -vv, -vvv, -vvvv)は出力の詳細度を高め、プレイブックの実行と潜在的な問題に関するより多くの洞察を提供します。 + +#### 詳細モードでプレイブックを実行 : + +詳細なログを取得するために `-vv` オプションを使用してプレイブックを実行します : + +```bash +ansible-navigator run deploy_apache.yml -m stdout -vv +``` + +``` +. +. +. + +TASK [apache : Display Variable Value] ***************************************** +task path: /home/rhel/ansible-files/roles/apache/tasks/main.yml:20 +ok: [node1] => { + "apache_service_name": "httpd" +} +ok: [node2] => { + "apache_service_name": "httpd" +} +ok: [node3] => { + "apache_service_name": "httpd" +} + +TASK [apache : Display Custom Message] ***************************************** +task path: /home/rhel/ansible-files/roles/apache/tasks/main.yml:24 +ok: [node1] => { + "msg": "Apacheサービス名は httpd です" +} +ok: [node2] => { + "msg": "Apacheサービス名は httpd です" +} +ok: [node3] => { + "msg": "Apacheサービス名は httpd です" +} + +TASK [apache : Copy Apache configuration] ************************************** +task path: /home/rhel/ansible-files/roles/apache/tasks/main.yml:30 +タスク実行中に例外が発生しました。完全なトレースバックを見るには -vvv を使用してください。エラーは次の通りです : モジュールを使用していて、ファイルがリモートに存在することを期待している場合は、remote_srcオプションを確認してください +fatal: [node3]: FAILED! => {"changed": false, "msg": "'files/missing_apache.conf' を見つけることができないかアクセスできません\n検索された場所:\n\t/home/student/lab_inventory/roles/apache/files/files/missing_apache.conf\n\t/home/student/lab_inventory/roles/apache/files/missing_apache.conf\n\t/home/student/lab_inventory/roles/apache/tasks/files/files/missing_apache.conf\n\t/home/student/lab_inventory/roles/apache/tasks/files/missing_apache.conf\n\t/home/student/lab_inventory/files/files/missing_apache.conf\n\t/home/student/lab_inventory/files/missing_apache.conf on the Ansible Controller.\nモジュールを使用していて、ファイルがリモートに存在することを期待している場合は、remote_srcオプションを確認してください"} +fatal: [node1]: FAILED! => {"changed": false, "msg": "'files/missing_apache.conf' を見つけることができないかアクセスできません\n検索された場所:\n\t/home/student/lab_inventory/roles/apache/files/files/missing_apache.conf\n\t/home/student/lab_inventory/roles/apache/files/missing_apache.conf\n\t/home/student/lab_inventory/roles/apache/tasks/files/files/missing_apache.conf\n\t/home/student/lab_inventory/roles/apache/tasks/files/missing_apache.conf\n\t/home/student/lab_inventory/files/files/missing_apache.conf\n\t/home/student/lab_inventory/files/missing_apache.conf on the Ansible Controller.\nモジュールを使用していて、ファイルがリモートに存在することを期待している場合は、remote_srcオプションを確認してください"} +fatal: [node2]: FAILED! => {"changed": false, "msg": "'files/missing_apache.conf' を見つけることができないかアクセスできません\n検索された場所:\n\t/home/student/lab_inventory/roles/apache/files/files/missing_apache.conf\n\t/home/student/lab_inventory/roles/apache/files/missing_apache.conf\n\t/home/student/lab_inventory/roles/apache/tasks/files/files/missing_apache.conf\n\t/home/student/lab_inventory/roles/apache/tasks/files/missing_apache.conf\n\t/home/student/lab_inventory/files/files/missing_apache.conf\n\t/home/student/lab_inventory/files/missing_apache.conf on the Ansible Controller.\nモジュールを使用していて、ファイルがリモートに存在することを期待している場合は、remote_srcオプションを確認してください"} + + +TASK [apache : Handle Missing Configuration] *********************************** +task path: /home/rhel/ansible-files/roles/apache/tasks/main.yml:39 +ok: [node1] => { + "msg": "'files/missing_apache.conf' のApache設定ファイルが見つかりません。デフォルト設定を使用します。" +} +ok: [node2] => { + "msg": "'files/missing_apache.conf' のApache設定ファイルが見つかりません。デフォルト設定を使用します。" +} +ok: [node3] => { + "msg": "'files/missing_apache.conf' のApache設定ファイルが見つかりません。デフォルト設定を使用します。" +} + +PLAY RECAP ********************************************************************* +node1 : ok=7 changed=0 unreachable=0 failed=0 skipped=0 rescued=1 ignored=0 +node2 : ok=7 changed=0 unreachable=0 failed=0 skipped=0 rescued=1 ignored=0 +node3 : ok=7 changed=0 unreachable=0 failed=0 skipped=0 rescued=1 ignored=0 + +``` + +プレイブックがApache設定ファイルのコピー中にエラーが発生したこと、しかし提供されたレスキューブロックを通じてそれを処理できたことを示しています。最終タスク「Handle Missing Configuration」はファイルが見つからず、デフォルト設定を使用することを詳述しています。 + +最終的なプレイリキャップは、Webグループのノードごとに `rescued=1` を介して使用されたレスキューブロックがあることを示しています。 + +## まとめ + +この演習では、Ansibleでの重要なデバッグ技術とエラーハンドリングメカニズムを探求しました。デバッグタスクを組み込み、エラーハンドリングのためにブロックを使用し、詳細モードを活用することで、Ansibleプレイブックのトラブルシューティングを効果的に行い、信頼性を向上させることができます。これらの実践は、予期しない問題を優雅に処理し、一貫性のある予測可能な結果を保証する堅牢なAnsible自動化を開発するための基礎です。 + +--- +**ナビゲーション** +
+[前の演習](../1.7-role/README.ja.md) - [次の演習](../2.1-intro/README.ja.md) + +[Red Hat Enterprise LinuxのためのAnsibleワークショップに戻る](../README.md#section-1---ansible-engine-exercises) + diff --git a/exercises/ansible_rhel/1.8-troubleshoot/README.md b/exercises/ansible_rhel/1.8-troubleshoot/README.md new file mode 100644 index 000000000..c00ccbeb5 --- /dev/null +++ b/exercises/ansible_rhel/1.8-troubleshoot/README.md @@ -0,0 +1,162 @@ +# Workshop Exercise - Debugging and Error Handling + +**Read this in other languages**: +
![uk](../../../images/uk.png) [English](README.md), ![japan](../../../images/japan.png)[日本語](README.ja.md), ![brazil](../../../images/brazil.png) [Portugues do Brasil](README.pt-br.md), ![france](../../../images/fr.png) [Française](README.fr.md),![Español](../../../images/col.png) [Español](README.es.md). + + +## Table of Contents + +- [Objective](#objective) +- [Guide](#guide) + - [Step 1 - Introduction to Debugging in Ansible](#step-1---introduction-to-debugging-in-ansible) + - [Step 2 - Utilizing the Debug Module](#step-2---utilizing-the-debug-module) + - [Step 3 - Error Handling with Blocks](#step-3---error-handling-with-blocks) + - [Step 4 - Running with Verbose Mode](#step-4---running-with-verbose-mode) + - [Summary](#summary) + +## Objective + +Building on the foundational knowledge from previous exercises, this session focuses on debugging and error handling within Ansible. You'll learn techniques to troubleshoot playbooks, manage errors gracefully, and ensure your automation is robust and reliable. + +## Guide + +### Step 1 - Introduction to Debugging in Ansible + +Debugging is a critical skill for identifying and resolving issues within your Ansible playbooks. Ansible provides several mechanisms to help you debug your automation scripts, including the debug module, increased verbosity levels, and error handling strategies. + +### Step 2 - Utilizing the Debug Module + +The `debug` module is a simple yet powerful tool for printing variable values, which can be instrumental in understanding playbook execution flow. + +In this example, add debug tasks to your Apache role in the `tasks/main.yml` to output the value of variables or messages. + +#### Implement Debug Tasks: + +Insert debug tasks to display the values of variables or custom messages for troubleshooting: + +```yaml +- name: Display Variable Value + ansible.builtin.debug: + var: apache_service_name + +- name: Display Custom Message + ansible.builtin.debug: + msg: "Apache service name is {{ apache_service_name }}" +``` + +### Step 3 - Error Handling with Blocks + +Ansible allows grouping tasks using `block` and handling errors with `rescue` sections, similar to try-catch in traditional programming. + +In this example, add a block to handle potential errors during the Apache configuration within the `tasks/main.yml` file. + +1. Group Tasks and Handle Errors: + +Wrap tasks that could potentially fail in a block and define a rescue section to handle errors: + +```yaml +- name: Apache Configuration with Potential Failure Point + block: + - name: Copy Apache configuration + ansible.builtin.copy: + src: "{{ apache_conf_src }}" + dest: "/etc/httpd/conf/httpd.conf" + rescue: + - name: Handle Missing Configuration + ansible.builtin.debug: + msg: "Missing Apache configuration file '{{ apache_conf_src }}'. Using default settings." +``` + +2. Add an `apache_conf_src` variable within `vars/main.yml` of the apache role. + +```yaml +apache_conf_src: "files/missing_apache.conf" +``` + +> NOTE: This file explicitly does not exist so that we can trigger the rescue portion from our `tasks/main.yml` + +### Step 4 - Running with Verbose Mode + +Ansible's verbose mode (-v, -vv, -vvv, or -vvvv) increases the output detail, providing more insights into playbook execution and potential issues. + +#### Execute Playbook in Verbose Mode: + +Run your playbook with the `-vv` option to get detailed logs: + +```bash +ansible-navigator run deploy_apache.yml -m stdout -vv +``` + +``` +. +. +. + + +TASK [apache : Display Variable Value] ***************************************** +task path: /home/rhel/ansible-files/roles/apache/tasks/main.yml:20 +ok: [node1] => { + "apache_service_name": "httpd" +} +ok: [node2] => { + "apache_service_name": "httpd" +} +ok: [node3] => { + "apache_service_name": "httpd" +} + +TASK [apache : Display Custom Message] ***************************************** +task path: /home/rhel/ansible-files/roles/apache/tasks/main.yml:24 +ok: [node1] => { + "msg": "Apache service name is httpd" +} +ok: [node2] => { + "msg": "Apache service name is httpd" +} +ok: [node3] => { + "msg": "Apache service name is httpd" +} + +TASK [apache : Copy Apache configuration] ************************************** +task path: /home/rhel/ansible-files/roles/apache/tasks/main.yml:30 +An exception occurred during task execution. To see the full traceback, use -vvv. The error was: If you are using a module and expect the file to exist on the remote, see the remote_src option +fatal: [node3]: FAILED! => {"changed": false, "msg": "Could not find or access 'files/missing_apache.conf'\nSearched in:\n\t/home/student/lab_inventory/roles/apache/files/files/missing_apache.conf\n\t/home/student/lab_inventory/roles/apache/files/missing_apache.conf\n\t/home/student/lab_inventory/roles/apache/tasks/files/files/missing_apache.conf\n\t/home/student/lab_inventory/roles/apache/tasks/files/missing_apache.conf\n\t/home/student/lab_inventory/files/files/missing_apache.conf\n\t/home/student/lab_inventory/files/missing_apache.conf on the Ansible Controller.\nIf you are using a module and expect the file to exist on the remote, see the remote_src option"} +An exception occurred during task execution. To see the full traceback, use -vvv. The error was: If you are using a module and expect the file to exist on the remote, see the remote_src option +fatal: [node1]: FAILED! => {"changed": false, "msg": "Could not find or access 'files/missing_apache.conf'\nSearched in:\n\t/home/student/lab_inventory/roles/apache/files/files/missing_apache.conf\n\t/home/student/lab_inventory/roles/apache/files/missing_apache.conf\n\t/home/student/lab_inventory/roles/apache/tasks/files/files/missing_apache.conf\n\t/home/student/lab_inventory/roles/apache/tasks/files/missing_apache.conf\n\t/home/student/lab_inventory/files/files/missing_apache.conf\n\t/home/student/lab_inventory/files/missing_apache.conf on the Ansible Controller.\nIf you are using a module and expect the file to exist on the remote, see the remote_src option"} +An exception occurred during task execution. To see the full traceback, use -vvv. The error was: If you are using a module and expect the file to exist on the remote, see the remote_src option +fatal: [node2]: FAILED! => {"changed": false, "msg": "Could not find or access 'files/missing_apache.conf'\nSearched in:\n\t/home/student/lab_inventory/roles/apache/files/files/missing_apache.conf\n\t/home/student/lab_inventory/roles/apache/files/missing_apache.conf\n\t/home/student/lab_inventory/roles/apache/tasks/files/files/missing_apache.conf\n\t/home/student/lab_inventory/roles/apache/tasks/files/missing_apache.conf\n\t/home/student/lab_inventory/files/files/missing_apache.conf\n\t/home/student/lab_inventory/files/missing_apache.conf on the Ansible Controller.\nIf you are using a module and expect the file to exist on the remote, see the remote_src option"} + + +TASK [apache : Handle Missing Configuration] *********************************** +task path: /home/rhel/ansible-files/roles/apache/tasks/main.yml:39 +ok: [node1] => { + "msg": "Missing Apache configuration file 'files/missing_apache.conf'. Using default settings." +} +ok: [node2] => { + "msg": "Missing Apache configuration file 'files/missing_apache.conf'. Using default settings." +} +ok: [node3] => { + "msg": "Missing Apache configuration file 'files/missing_apache.conf'. Using default settings." +} + +PLAY RECAP ********************************************************************* +node1 : ok=7 changed=0 unreachable=0 failed=0 skipped=0 rescued=1 ignored=0 +node2 : ok=7 changed=0 unreachable=0 failed=0 skipped=0 rescued=1 ignored=0 +node3 : ok=7 changed=0 unreachable=0 failed=0 skipped=0 rescued=1 ignored=0 + +``` + +Notice how the playbook shows there was an error copying the Apache Configuration file but the playbook was able to handle it via the rescue block that was provided. If you notice the final task ‘Handle Missing Configuration’ details that the file was missing and it would use the default settings. + +The final Play Recap shows us that there was a rescued block used via the `rescued=1` per node in the web group. + +## Summary + +In this exercise, you've explored essential debugging techniques and error handling mechanisms in Ansible. By incorporating debugging tasks, using blocks for error handling, and leveraging verbose mode, you can effectively troubleshoot and enhance the reliability of your Ansible playbooks. These practices are fundamental in developing robust Ansible automation that can gracefully handle unexpected issues and ensure consistent, predictable outcomes. + +--- +**Navigation** +
+[Previous Exercise](../1.7-role) - [Next Exercise](../2.1-intro) + +[Click here to return to the Ansible for Red Hat Enterprise Linux Workshop](../README.md#section-1---ansible-engine-exercises) diff --git a/exercises/ansible_rhel/1.8-troubleshoot/README.pt-br.md b/exercises/ansible_rhel/1.8-troubleshoot/README.pt-br.md new file mode 100644 index 000000000..e74b59ab9 --- /dev/null +++ b/exercises/ansible_rhel/1.8-troubleshoot/README.pt-br.md @@ -0,0 +1,159 @@ +# Exercício do Workshop - Depuração e Tratamento de Erros + +**Leia isso em outros idiomas**: +
![uk](../../../images/uk.png) [Inglês](README.md), ![japan](../../../images/japan.png) [Japonês](README.ja.md), ![brazil](../../../images/brazil.png) [Português do Brasil](README.pt-br.md), ![france](../../../images/fr.png) [Francês](README.fr.md), ![Español](../../../images/col.png) [Espanhol](README.es.md). + +## Índice + +- [Objetivo](#objetivo) +- [Guia](#guia) + - [Etapa 1 - Introdução à Depuração no Ansible](#etapa-1---introdução-à-depuração-no-ansible) + - [Etapa 2 - Utilizando o Módulo de Depuração](#etapa-2---utilizando-o-módulo-de-depuração) + - [Etapa 3 - Tratamento de Erros com Blocos](#etapa-3---tratamento-de-erros-com-blocos) + - [Etapa 4 - Executando em Modo Verbose](#etapa-4---executando-em-modo-verbose) + - [Resumo](#resumo) + +## Objetivo + +Baseando-se no conhecimento fundamental dos exercícios anteriores, esta sessão foca na depuração e tratamento de erros dentro do Ansible. Você aprenderá técnicas para solucionar problemas em playbooks, gerenciar erros de forma elegante e garantir que sua automação seja robusta e confiável. + +## Guia + +### Etapa 1 - Introdução à Depuração no Ansible + +A depuração é uma habilidade crucial para identificar e resolver problemas dentro dos seus playbooks do Ansible. O Ansible oferece vários mecanismos para ajudá-lo a depurar seus scripts de automação, incluindo o módulo de depuração, níveis de verbosidade aumentados e estratégias de tratamento de erros. + +### Etapa 2 - Utilizando o Módulo de Depuração + +O módulo `debug` é uma ferramenta simples, porém poderosa, para imprimir os valores das variáveis, o que pode ser fundamental para entender o fluxo de execução do playbook. + +Neste exemplo, adicione tarefas de depuração ao seu papel do Apache no `tasks/main.yml` para exibir o valor das variáveis ou mensagens. + +#### Implementar Tarefas de Depuração: + +Insira tarefas de depuração para exibir os valores das variáveis ou mensagens personalizadas para solução de problemas: + +```yaml +- name: Display Variable Value + ansible.builtin.debug: + var: apache_service_name + +- name: Display Custom Message + ansible.builtin.debug: + msg: "O nome do serviço Apache é {{ apache_service_name }}" +``` + +### Etapa 3 - Tratamento de Erros com Blocos + +O Ansible permite agrupar tarefas usando `block` e tratar erros com seções `rescue`, semelhante ao try-catch na programação tradicional. + +Neste exemplo, adicione um bloco para tratar erros potenciais durante a configuração do Apache no arquivo `tasks/main.yml`. + +1. Agrupar Tarefas e Tratar Erros: + +Envolver as tarefas que podem falhar potencialmente em um bloco e definir uma seção de resgate para tratar os erros: + +```yaml +- name: Configuração do Apache com Ponto de Falha Potencial + block: + - name: Copiar configuração do Apache + ansible.builtin.copy: + src: "{{ apache_conf_src }}" + dest: "/etc/httpd/conf/httpd.conf" + rescue: + - name: Tratar Configuração Ausente + ansible.builtin.debug: + msg: "Arquivo de configuração do Apache '{{ apache_conf_src }}' ausente. Usando configurações padrão." +``` + +2. Adicione uma variável `apache_conf_src` dentro de `vars/main.yml` do papel apache. + +```yaml +apache_conf_src: "files/missing_apache.conf" +``` + +> NOTA: Este arquivo explicitamente não existe para que possamos acionar a parte do resgate em nosso `tasks/main.yml` + +### Etapa 4 - Executando em Modo Verbose + +O modo verbose do Ansible (-v, -vv, -vvv ou -vvvv) aumenta o detalhe da saída, fornecendo mais insights sobre a execução do playbook e possíveis problemas. + +#### Executar o Playbook em Modo Verbose: + +Execute seu playbook com a opção `-vv` para obter logs detalhados: + +```bash +ansible-navigator run deploy_apache.yml -m stdout -vv +``` + +``` +. +. +. + +TASK [apache : Display Variable Value] ***************************************** +task path: /home/rhel/ansible-files/roles/apache/tasks/main.yml:20 +ok: [node1] => { + "apache_service_name": "httpd" +} +ok: [node2] => { + "apache_service_name": "httpd" +} +ok: [node3] => { + "apache_service_name": "httpd" +} + +TASK [apache : Display Custom Message] ***************************************** +task path: /home/rhel/ansible-files/roles/apache/tasks/main.yml:24 +ok: [node1] => { + "msg": "O nome do serviço Apache é httpd" +} +ok: [node2] => { + "msg": "O nome do serviço Apache é httpd" +} +ok: [node3] => { + "msg": "O nome do serviço Apache é httpd" +} + +TASK [apache : Copy Apache configuration] ************************************** +task path: /home/rhel/ansible-files/roles/apache/tasks/main.yml:30 +Ocorreu uma exceção durante a execução da tarefa. Para ver o rastreamento completo, use -vvv. O erro foi: Se você está usando um módulo e espera que o arquivo exista no remoto, veja a opção remote_src +fatal: [node3]: FAILED! => {"changed": false, "msg": "Não foi possível encontrar ou acessar 'files/missing_apache.conf'\nProcurado em:\n\t/home/student/lab_inventory/roles/apache/files/files/missing_apache.conf\n\t/home/student/lab_inventory/roles/apache/files/missing_apache.conf\n\t/home/student/lab_inventory/roles/apache/tasks/files/files/missing_apache.conf\n\t/home/student/lab_inventory/roles/apache/tasks/files/missing_apache.conf\n\t/home/student/lab_inventory/files/files/missing_apache.conf\n\t/home/student/lab_inventory/files/missing_apache.conf no Controlador Ansible.\nSe você está usando um módulo e espera que o arquivo exista no remoto, veja a opção remote_src"} +fatal: [node1]: FAILED! => {"changed": false, "msg": "Não foi possível encontrar ou acessar 'files/missing_apache.conf'\nProcurado em:\n\t/home/student/lab_inventory/roles/apache/files/files/missing_apache.conf\n\t/home/student/lab_inventory/roles/apache/files/missing_apache.conf\n\t/home/student/lab_inventory/roles/apache/tasks/files/files/missing_apache.conf\n\t/home/student/lab_inventory/roles/apache/tasks/files/missing_apache.conf\n\t/home/student/lab_inventory/files/files/missing_apache.conf\n\t/home/student/lab_inventory/files/missing_apache.conf no Controlador Ansible.\nSe você está usando um módulo e espera que o arquivo exista no remoto, veja a opção remote_src"} +fatal: [node2]: FAILED! => {"changed": false, "msg": "Não foi possível encontrar ou acessar 'files/missing_apache.conf'\nProcurado em:\n\t/home/student/lab_inventory/roles/apache/files/files/missing_apache.conf\n\t/home/student/lab_inventory/roles/apache/files/missing_apache.conf\n\t/home/student/lab_inventory/roles/apache/tasks/files/files/missing_apache.conf\n\t/home/student/lab_inventory/roles/apache/tasks/files/missing_apache.conf\n\t/home/student/lab_inventory/files/files/missing_apache.conf\n\t/home/student/lab_inventory/files/missing_apache.conf no Controlador Ansible.\nSe você está usando um módulo e espera que o arquivo exista no remoto, veja a opção remote_src"} + + +TASK [apache : Tratar Configuração Ausente] *********************************** +task path: /home/rhel/ansible-files/roles/apache/tasks/main.yml:39 +ok: [node1] => { + "msg": "Arquivo de configuração do Apache 'files/missing_apache.conf' ausente. Usando configurações padrão." +} +ok: [node2] => { + "msg": "Arquivo de configuração do Apache 'files/missing_apache.conf' ausente. Usando configurações padrão." +} +ok: [node3] => { + "msg": "Arquivo de configuração do Apache 'files/missing_apache.conf' ausente. Usando configurações padrão." +} + +PLAY RECAP ********************************************************************* +node1 : ok=7 changed=0 unreachable=0 failed=0 skipped=0 rescued=1 ignored=0 +node2 : ok=7 changed=0 unreachable=0 failed=0 skipped=0 rescued=1 ignored=0 +node3 : ok=7 changed=0 unreachable=0 failed=0 skipped=0 rescued=1 ignored=0 + +``` + +Observe como o playbook mostra que houve um erro ao copiar o arquivo de configuração do Apache, mas o playbook conseguiu tratá-lo por meio do bloco de resgate fornecido. Se você observar a tarefa final 'Tratar Configuração Ausente', ela detalha que o arquivo estava ausente e seria usada a configuração padrão. + +O Resumo Final da Execução nos mostra que foi usado um bloco resgatado por meio de `rescued=1` por nó no grupo web. + +## Resumo + +Neste exercício, você explorou técnicas essenciais de depuração e mecanismos de tratamento de erros no Ansible. Incorporando tarefas de depuração, usando blocos para tratamento de erros e aproveitando o modo verbose, você pode efetivamente solucionar problemas e aprimorar a confiabilidade de seus playbooks do Ansible. Essas práticas são fundamentais no desenvolvimento de automação robusta com Ansible que pode tratar problemas inesperados de forma elegante e garantir resultados consistentes e previsíveis. + +--- +**Navegação** +
+[Exercício Anterior](../1.7-role/README.pt-br.md) - [Próximo Exercício](../2.1-intro/README.pt-br.md) + +[Clique aqui para retornar ao Workshop de Ansible para Red Hat Enterprise Linux](../README.md#section-1---ansible-engine-exercises) + diff --git a/exercises/ansible_rhel/2.2-cred/README.es.md b/exercises/ansible_rhel/2.2-cred/README.es.md index f91bb95ed..32d40b1bb 100644 --- a/exercises/ansible_rhel/2.2-cred/README.es.md +++ b/exercises/ansible_rhel/2.2-cred/README.es.md @@ -1,202 +1,62 @@ -# Workshop - Inventarios, credenciales y comandos ad hoc +# Ejercicio del Taller: Inventarios y Credenciales en el Controlador de Automatización de Ansible -**Lee esto en otros idiomas**: -
![uk](../../../images/uk.png) [English](README.md),![japan](../../../images/japan.png)[日本語](README.ja.md),![france](../../../images/fr.png) [Française](README.fr.md),![Español](../../../images/col.png) [Español](README.es.md). +**Leer esto en otros idiomas**: +
![uk](../../../images/uk.png) [Inglés](README.md), ![japan](../../../images/japan.png) [Japonés](README.ja.md), ![france](../../../images/fr.png) [Francés](README.fr.md), ![Español](../../../images/col.png) [Español](README.es.md). +## Objetivo +Este taller está diseñado para proporcionar una comprensión práctica de cómo gestionar inventarios y credenciales dentro del Controlador de Automatización de Ansible. Aprenderás cómo navegar por un inventario precargado, entender su estructura y explorar la configuración y uso de credenciales de máquina para acceder a los hosts gestionados. -## Tabla de contenidos +## Índice de Contenidos +1. [Introducción a los Inventarios](#1-introducción-a-los-inventarios) +2. [Explorando el 'Inventario del Taller'](#2-explorando-el-inventario-del-taller) +3. [Entendiendo las Credenciales de Máquina](#3-entendiendo-las-credenciales-de-máquina) +4. [Tipos Adicionales de Credenciales](#4-tipos-adicionales-de-credenciales) +5. [Conclusión](#5-conclusión) -* [Objetivos](#Objetivos) -* [Guía](#Guía) -* [Examinar un inventario](#Examinar-un-inventario) -* [Credenciales de máquina](#Credenciales-de-máquina) -* [Configurar credenciales de máquina](#Examinar-las-credenciales-de-la-máquina) -* [Ejecutar comandos Ad Hoc](#Ejecutar-comandos-ad-hoc) -* [Laboratorios de desafío: Comandos Ad Hoc](#Laboratorios-de-desafío-Comandos-Ad-Hoc) +### 1. Introducción a los Inventarios +Los inventarios en el Controlador de Automatización de Ansible son cruciales para definir y organizar los hosts contra los cuales se ejecutarán tus playbooks. Pueden ser estáticos, con una lista fija de hosts, o dinámicos, extrayendo listas de hosts de fuentes externas. -# Objetivos +### 2. Explorando el 'Inventario del Taller' +El 'Inventario del Taller' está precargado en tu entorno de laboratorio, representando un inventario estático típico: -Explore y comprenda el entorno de laboratorio. Este ejercicio cubrirá -- Ubicación y comprensión: - - Ansible Tower [**Inventarios**](https://docs.ansible.com/ansible-tower/latest/html/userguide/inventories.html) - - Ansible Tower [**Credenciales**](https://docs.ansible.com/ansible-tower/latest/html/userguide/credentials.html) -- Ejecución de comandos ad hoc a través de la interfaz de usuario web de Ansible Tower +- **Accediendo al Inventario:** Navega a `Recursos → Inventarios` en la interfaz web, y selecciona 'Inventario del Taller'. +- **Viendo Hosts:** Haz clic en el botón 'Hosts' para revelar las configuraciones de host precargadas, similares a lo que podrías encontrar en un archivo de inventario de Ansible tradicional, como: -# Guía -## Examinar un inventario - -Lo primero que necesitamos es un inventario de sus hosts administrados. Esto es el equivalente de un archivo de inventario en Ansible Engine. Hay mucho más (como inventarios dinámicos), pero comencemos con lo básico. - - - Ya debería tener abierta la interfaz de usuario web, si no: Apunte su navegador a la dirección URL que se le dio, de forma similar a **https://student\.workshopname.rhdemo.io** (reemplazar "\" con su numero de estudiante y "nombre de taller" con el nombre de su taller actual) e inicie sesión como `admin`. La contraseña será proporcionada por el instructor. - -Habrá un inventario, **Workshop Inventory**. Haga clic en el **Workshop Inventory** y, a continuación, haga clic en el botón **Hosts** - -La información de inventario en `~/lab_inventory/hosts` fue precargado en el inventario de Ansible Tower como parte del proceso de aprovisionamiento. - -```bash -$ cat ~/lab_inventory/hosts -[web] -node1 ansible_host=22.33.44.55 -node2 ansible_host=33.44.55.66 -node3 ansible_host=44.55.66.77 - -[control] -ansible ansible_host=11.22.33.44 +```yaml +[web_servers] +web1 ansible_host=22.33.44.55 +web2 ansible_host=33.44.55.66 +... ``` -> **Advertencia** -> -> En su inventario las direcciones IP serán diferentes. - -## Examinar las credenciales de la máquina - -Ahora examinaremos las credenciales para acceder a nuestros hosts administrados desde Tower. Como parte del proceso de aprovisionamiento para este Taller Ansible, ya se ha configurado las **Workshop Credential**. - -En el menú **RESOURCES**, elija **Credentials**. Ahora haga clic en la **Workshop Credential**. - -Tenga en cuenta la siguiente información: - - - - - - - - - - - - - - - - - - -
ParámetroValor
Credential TypeMachine- Las credenciales de máquina definen el acceso a la escalación de privilegios ssh y de nivel de usuario para los playbooks. Se utilizan al enviar trabajos para ejecutar playbook en un host remoto.
usernameec2-user- que coincide con nuestro nombre de usuario de inventario Ansible de la línea de comandos para los otros nodos de Linux
SSH PRIVATE KEYENCRYPTED - tomar nota de que en realidad no se puede examinar la clave privada SSH una vez que alguien la entrega a Ansible Tower
- -## Ejecutar comandos Ad Hoc - -También es posible ejecutar comandos ad hoc desde Ansible Tower. - - - En la interfaz de usuario web vaya a **RESOURCES → Inventories → Workshop Inventory** - - Haga clic en el botón **HOSTS** para cambiar a la vista de hosts y seleccione los tres hosts marcando las casillas a la izquierda de las entradas del host. - - Haga clic en **RUN COMMANDS**. En la siguiente pantalla debe especificar el comando ad hoc: - - - - - - - - - - - - - - - - -
ParámetroValor
MODULEping
MACHINE CREDENTIALWorkshop Credentials
+### 3. Entendiendo las Credenciales de Máquina +Las credenciales de máquina son esenciales para establecer conexiones SSH a tus hosts gestionados: - - Haga clic en **LAUNCH** y observe la salida. +- **Accediendo a Credenciales:** Desde el menú principal, elige `Recursos → Credenciales` y selecciona 'Credencial del Taller'. +- **Detalles de Credenciales:** La 'Credencial del Taller' está preestablecida con parámetros como: +- **Tipo de Credencial:** Máquina, para acceso SSH. +- **Nombre de Usuario:** Un usuario predefinido, por ejemplo, `ec2-user`. +- **Clave Privada SSH:** Encriptada, proporcionando acceso seguro a tus hosts. +### 4. Tipos Adicionales de Credenciales +El Controlador de Automatización de Ansible admite varios tipos de credenciales para diferentes escenarios de automatización: -
+- **Credenciales de Red:** Para la gestión de dispositivos de red. +- **Credenciales de Control de Fuente:** Para el acceso a la gestión de control de fuente. +- **Credenciales de Servicios Web de Amazon:** Para la integración con Amazon AWS. -El módulo simple **ping** no necesita opciones. Para otros módulos, debe proporcionar el comando para que se ejecute como argumento. Pruebe el módulo **command** para buscar el ID de usuario del usuario en ejecución mediante un comando ad hoc. +Cada tipo está adaptado a requisitos específicos, mejorando la flexibilidad y seguridad de tu automatización. +### 5. Conclusión +Este taller introduce los conceptos fundamentales de inventarios y credenciales dentro del Controlador de Automatización de Ansible. Comprender estos componentes es crucial para gestionar eficientemente tus tareas de automatización y asegurar el acceso a tu infraestructura. - - - - - - - - - - - - - -
ParámetroValor
MODULEcommand
ARGUMENTSid
- -> **Consejo** -> -> Después de elegir el módulo que se va a ejecutar, Tower proporcionará un enlace a la página de documentos del módulo al hacer clic en el signo de interrogación situado junto a "Arguments". Esto es útil, pruébalo. - -
- -¿Qué tal si tratamos de obtener información secreta del sistema? Intente imprimir */etc/shadow*. - - - - - - - - - - - - - - - -
ParámetroValor
MODULEcommand
ARGUMENTScat /etc/shadow
- - -> **Advertencia** -> -> **¡Espere un error!** - -Oops, el último no salió bien, todo rojo. - -Vuelva a ejecutar el último comando ad hoc, pero esta vez marque la casilla **ENABLE PRIVILEGE ESCALATION**. - -Como ves, esta vez funcionó. Para las tareas que tienen que ejecutarse como root, debe escalar los privilegios. Esto es lo mismo que el **become: yes** utilizado en sus Playbooks de Ansible. - -## Laboratorio de Desafíos: Comandos Ad Hoc - -Bien, un pequeño desafío: Ejecuta un comando ad hoc para asegurarte de que el paquete "tmux" está instalado en todos los hosts. Si no está seguro, consulte la documentación a través de la interfaz de usuario web como se muestra arriba o ejecutando `[ansible@tower ]$ ansible-doc yum` en el host de control de Tower. - - -> **Advertencia** -> -> **Solución a continuación\!** - - - - - - - - - - - - - - - - - - -
ParámetroValor
yumcommand
ARGUMENTSname=tmux
ENABLE PRIVILEGE ESCALATION✓
- -> **Consejo** -> -> La salida amarilla del comando indica que Ansible ha hecho algo (aquí se necesita instalar el paquete). Si ejecuta el comando ad hoc por segunda vez, la salida será verde e informará de que el paquete ya estaba instalado. Así que el amarillo en Ansible no significa "tener cuidado"... ;-). - - ----- +--- **Navegación**
-[Ejercicio anterior](../2.1-intro/README.es.md) - [Próximo Ejercicio](../2.3-projects/README.es.md) +[Ejercicio Anterior](../2.1-intro/README.es.md) - [Próximo Ejercicio](../2.3-projects/README.es.md) + +[Haz clic aquí para volver al Taller de Ansible para Red Hat Enterprise Linux](../README.md#section-2---ansible-tower-exercises) -[Haga clic aquí para volver al Taller Ansible for Red Hat Enterprise Linux](../README.md#Sección-2---Ejercicios-de-Ansible-Tower) diff --git a/exercises/ansible_rhel/2.2-cred/README.fr.md b/exercises/ansible_rhel/2.2-cred/README.fr.md index 99191334c..fe976cc22 100644 --- a/exercises/ansible_rhel/2.2-cred/README.fr.md +++ b/exercises/ansible_rhel/2.2-cred/README.fr.md @@ -1,190 +1,62 @@ -# Atelier - Les inventaires, identifications et commandes Ad-hoc +# Exercice de l'Atelier : Inventaires et Identifiants dans le Contrôleur d'Automatisation Ansible -**Lisez ceci dans d'autres langues**: -
![uk](../../../images/uk.png) [English](README.md),![japan](../../../images/japan.png)[日本語](README.ja.md),![france](../../../images/fr.png) [Française](README.fr.md),![Español](../../../images/col.png) [Español](README.es.md). +**Lire ceci dans d'autres langues** : +
![uk](../../../images/uk.png) [Anglais](README.md), ![japan](../../../images/japan.png) [Japonais](README.ja.md), ![france](../../../images/fr.png) [Français](README.fr.md), ![Español](../../../images/col.png) [Espagnol](README.es.md). -## Table des matières +## Objectif +Cet atelier est conçu pour fournir une compréhension pratique de la gestion des inventaires et des identifiants au sein du Contrôleur d'Automatisation Ansible. Vous apprendrez à naviguer dans un inventaire préchargé, à comprendre sa structure et à explorer la configuration et l'utilisation des identifiants de machine pour accéder aux hôtes gérés. -* [Objectif](#objectif) -* [Guide](#guide) -* [Examiner un inventaire](#examiner-un-inventaire) -* [Examination des informations d'identifications](#Examination-des-informations-d-identification) -* [Exécution des commandes Ad-hoc](#exécution-des-commandes-ad-hoc) -* [Défi: Les commandes Ad-hoc](#défi-les-commandes-ad-hoc) +## Table des Matières +1. [Introduction aux Inventaires](#1-introduction-aux-inventaires) +2. [Exploration de l'Inventaire de l'Atelier](#2-exploration-de-linventaire-de-latelier) +3. [Compréhension des Identifiants de Machine](#3-compréhension-des-identifiants-de-machine) +4. [Types d'Identifiants Supplémentaires](#4-types-didentifiants-supplémentaires) +5. [Conclusion](#5-conclusion) -# Objectif +### 1. Introduction aux Inventaires +Les inventaires dans le Contrôleur d'Automatisation Ansible sont essentiels pour définir et organiser les hôtes sur lesquels vos playbooks seront exécutés. Ils peuvent être statiques, avec une liste fixe d'hôtes, ou dynamiques, en extrayant des listes d'hôtes de sources externes. -Explorez et comprenez l'environnement du laboratoire. Cet exercice couvrira -- Localisation et compréhension: - - Tour Ansible [**Inventaire**](https://docs.ansible.com/ansible-tower/latest/html/userguide/inventories.html) - - Tour Ansible [**Informations d'identification **](https://docs.ansible.com/ansible-tower/latest/html/userguide/credentials.html) -- Exécution de commandes ad hoc via l'interface utilisateur Web d'Ansible Tower +### 2. Exploration de l'Inventaire de l'Atelier +L'Inventaire de l'Atelier est préchargé dans votre environnement de laboratoire, représentant un inventaire statique typique : -# Guide +- **Accéder à l'Inventaire :** Naviguez jusqu'à `Ressources → Inventaires` dans l'interface web, et sélectionnez 'Inventaire de l'Atelier'. +- **Visualiser les Hôtes :** Cliquez sur le bouton 'Hôtes' pour révéler les configurations d'hôte préchargées, similaires à ce que vous pourriez trouver dans un fichier d'inventaire Ansible traditionnel, tel que : -## Examiner un inventaire -La première chose dont nous avons besoin est un inventaire de vos hôtes gérés. C'est l'équivalent d'un fichier d'inventaire dans Ansible Engine. Il y en a beaucoup plus (comme les inventaires dynamiques), mais commençons par les bases. - - Vous devriez déjà avoir l'interface utilisateur Web ouverte, sinon: pointez votre navigateur sur l'URL qui vous a été donnée, similaire à **https://student\.workshopname.rhdemo.io** (remplacez "\ "avec votre numéro d'étudiant et" workshopname "avec le nom de votre atelier actuel) et connectez-vous en tant qu'"admin". Le mot de passe sera fourni par l'instructeur. +```yaml +[web_servers] +web1 ansible_host=22.33.44.55 +web2 ansible_host=33.44.55.66 +... +``` -Il y aura un seul inventaire, l'**inventaire de l'atelier**. Cliquez sur **Workshop Inventory** puis sur le bouton **Hôtes** -Les informations d'inventaire dans `~/lab_inventory/hosts` ont été préchargées dans l'inventaire de la tour Ansible dans le cadre du processus d'approvisionnement. +### 3. Compréhension des Identifiants de Machine +Les identifiants de machine sont essentiels pour établir des connexions SSH avec vos hôtes gérés : -```bash -$ cat ~/lab_inventory/hosts -[web] -node1 ansible_host=22.33.44.55 -node2 ansible_host=33.44.55.66 -node3 ansible_host=44.55.66.77 +- **Accéder aux Identifiants :** Depuis le menu principal, choisissez `Ressources → Identifiants` et sélectionnez 'Identifiant de l'Atelier'. +- **Détails de l'Identifiant :** L' 'Identifiant de l'Atelier' est prédéfini avec des paramètres tels que : +- **Type d'Identifiant :** Machine, pour l'accès SSH. +- **Nom d'Utilisateur :** Un utilisateur prédéfini, par exemple, `ec2-user`. +- **Clé Privée SSH :** Cryptée, fournissant un accès sécurisé à vos hôtes. -[control] -ansible ansible_host=11.22.33.44 -``` -> **Avertissement** -> -> Dans votre inventaire, les adresses IP seront différentes. - -## Examination des informations d identification - -Nous allons maintenant examiner les informations d'identification pour accéder à nos hôtes gérés depuis Tower. Dans le cadre du processus d'approvisionnement de cet atelier Ansible, **les informations d'identification de l'atelier** ont déjà été configurées. - -Dans le menu **RESSOURCES**, choisissez **INFORMATIONS D’IDENTIFICATION**. Maintenant, cliquez sur **Workshop Credential**. - -Notez les informations suivantes: - - - - - - - - - - - - - - - - - - -
ParameterValue
Credential TypeMachine- Machine credentials define ssh and user-level privilege escalation access for playbooks. They are used when submitting jobs to run playbooks on a remote host.
usernameec2-user which matches our command-line Ansible inventory username for the other linux nodes
SSH PRIVATE KEYENCRYPTED - take note that you can't actually examine the SSH private key once someone hands it over to Ansible Tower
- - -## Exécution des commandes Ad hoc - -Il est également possible d'exécuter des commandes ad hoc à partir d'Ansible Tower. - - - Dans l'interface utilisateur Web, accédez à **RESSOURCES → Inventaires → Workshop Inventory** - - - Cliquez sur le bouton **HÔTES** pour passer à la vue des hôtes et sélectionnez les trois hôtes en cochant les cases à gauche des entrées d'hôte. - - - Cliquez sur **EXÉCUTER COMMANDE**. Dans l'écran suivant, vous devez spécifier la commande ad hoc: - - - - - - - - - - - - - -
ParametreValeur
MODULEping
MACHINE CREDENTIALWorkshop Credentials
- - - Click **LAUNCH**, and watch the output. - -
- -Le module **ping** simple n'a pas besoin d'options. Pour les autres modules, vous devez fournir la commande à exécuter comme argument. Essayez le module **command** pour trouver l'ID utilisateur de l'utilisateur exécutant à l'aide d'une commande ad hoc. - - - - - - - - - - - - - -
ParametreValeur
MODULEcommand
ARGUMENTSid
- -> **Astuce** -> -> Après avoir choisi le module à exécuter, Tower fournira un lien vers la page de documentation du module en cliquant sur le point d'interrogation à côté de "Arguments". C'est pratique, essayez-le. - -
- -Que diriez-vous d'essayer d'obtenir des informations secrètes du système? Essayez d'afficher le fichier */etc/shadow*. - - - - - - - - - - - - - - -
ParametreValeur
MODULEcommand
ARGUMENTScat /etc/shadow
- - -> **Avertissement** -> -> **Attendez-vous à une erreur \!** - -Oups, le dernier ne s'est pas bien passé, tout rouge. - -Réexécutez la dernière commande Ad-hoc mais cette fois cochez la case **Activer l’élévation des privilèges**. - -Comme vous le voyez, cette fois, cela a fonctionné. Pour les tâches qui doivent s'exécuter en tant que root, vous devez augmenter les privilèges. C'est la même chose que le **become: yes** utilisé dans vos Playbooks Ansible. - -## Défi: Les commandes Ad hoc - -D'accord, un petit défi: exécutez un ad hoc pour vous assurer que le package "tmux" est installé sur tous les hôtes. En cas de doute, consultez la documentation soit via l'interface utilisateur Web comme indiqué ci-dessus, soit en exécutant `[ansible @ tower ~] $ ansible-doc yum` sur votre hôte de contrôle Tower. - -> **Avertissement** -> -> **Solution ci-dessous \!** - - - - - - - - - - - - - - - - - - -
ParametreValeur
yumcommand
ARGUMENTSname=tmux
Activer l’élévation des privilèges✓
- -> **Astuce** -> -> La sortie jaune de la commande indique qu'Ansible a réellement fait quelque chose (ici, il fallait installer le paquet). Si vous exécutez la commande ad hoc une deuxième fois, la sortie sera verte et vous informera que le package a déjà été installé. Donc, le jaune dans Ansible ne signifie pas "soyez prudent"… ;-). ----- +### 4. Types d'Identifiants Supplémentaires +Le Contrôleur d'Automatisation Ansible prend en charge divers types d'identifiants pour différents scénarios d'automatisation : + +- **Identifiants Réseau :** Pour la gestion des appareils réseau. +- **Identifiants de Contrôle de Source :** Pour l'accès à la gestion du contrôle de source. +- **Identifiants des Services Web Amazon :** Pour l'intégration avec Amazon AWS. + +Chaque type est adapté à des exigences spécifiques, améliorant la flexibilité et la sécurité de votre automatisation. + +### 5. Conclusion +Cet atelier introduit les concepts fondamentaux des inventaires et des identifiants au sein du Contrôleur d'Automatisation Ansible. Comprendre ces composants est crucial pour gérer efficacement vos tâches d'automatisation et sécuriser l'accès à votre infrastructure. + +--- **Navigation**
-[Exercice précédent](../2.1-intro/README.fr.md) - [Exercice suivant](../2.3-projects/README.fr.md) +[Exercice Précédent](../2.1-intro/README.fr.md) - [Prochain Exercice](../2.3-projects/README.fr.md) + +[Cliquez ici pour retourner à l'Atelier Ansible pour Red Hat Enterprise Linux](../README.md#section-2---ansible-tower-exercises) -[Cliquez ici pour revenir à l'atelier Ansible pour Red Hat Enterprise Linux](../README.fr.md) diff --git a/exercises/ansible_rhel/2.2-cred/README.ja.md b/exercises/ansible_rhel/2.2-cred/README.ja.md index 5ea7972d0..ed182e94e 100644 --- a/exercises/ansible_rhel/2.2-cred/README.ja.md +++ b/exercises/ansible_rhel/2.2-cred/README.ja.md @@ -1,179 +1,62 @@ -# ワークショップ演習 - インベントリー、認証情報、およびアドホックコマンド +# ワークショップ演習: Ansibleオートメーションコントローラーのインベントリとクレデンシャル -**他の言語でもお読みいただけます**: -
![uk](../../../images/uk.png) [English](README.md)、![japan](../../../images/japan.png)[日本語](README.ja.md)、![france](../../../images/fr.png) [Française](README.fr.md)、![Español](../../../images/col.png) [Español](README.es.md) - -## 目次 - -* [目的](#目的) -* [ガイド](#ガイド) -* [インベントリーの検証](#インベントリーの検証) -* [マシンの認証情報の検証](#マシンの認証情報の検証) -* [アドホックコマンドの実行](#アドホックコマンドの実行) -* [チャレンジラボ: アドホックコマンド](#チャレンジラボ-アドホックコマンド) +**他の言語で読む** : +
![uk](../../../images/uk.png) [英語](README.md), ![japan](../../../images/japan.png) [日本語](README.ja.md), ![france](../../../images/fr.png) [フランス語](README.fr.md), ![Español](../../../images/col.png) [スペイン語](README.es.md). ## 目的 +このワークショップは、Ansibleオートメーションコントローラー内でインベントリとクレデンシャルを管理する方法についての実践的な理解を提供することを目的としています。プリロードされたインベントリをナビゲートし、その構造を理解し、管理されたホストへのアクセスに使用するマシンクレデンシャルの設定と使用方法を探ります。 -ラボ環境を調べて理解します。この演習では、以下を対象とします。 - -* 以下を見つけて理解: - - * Ansible 自動コントローラー [**インベントリー**](https://docs.ansible.com/automation-controller/latest/html/userguide/inventories.html) - * Ansible 自動コントローラー [**認証情報**](https://docs.ansible.com/automation-controller/latest/html/userguide/credentials.html) - -* Ansible 自動コントローラー WebUI を介したアドホックコマンドの実行 - -## ガイド - -### インベントリーの検証 +## 目次 +1. [インベントリの紹介](#1-インベントリの紹介) +2. ['ワークショップインベントリ'の探索](#2-ワークショップインベントリの探索) +3. [マシンクレデンシャルの理解](#3-マシンクレデンシャルの理解) +4. [追加のクレデンシャルタイプ](#4-追加のクレデンシャルタイプ) +5. [結論](#5-結論) -最初に必要なのは、管理対象ホストのインベントリーです。これは、Ansible Engine のインベントリファイルーに相当します。それ以外にもたくさんありますが、まずは基本から始めましょう。 +### 1. インベントリの紹介 +Ansibleオートメーションコントローラーのインベントリは、プレイブックが実行されるホストを定義して整理するために不可欠です。インベントリは静的で、固定リストのホストを持つことも、外部ソースからホストリストを引き出す動的なものもあります。 -* すでに Web UI を開いているはずですが、開いていない場合は、指定された URL をブラウザーで開きます。これは、`https://student.workshopname.demoredhat.com` のような URL です。"workshopname" は現在のワークショップの名前に変更します。`admin` としてログインします。このパスワードは、インストラクターから渡されます。 +### 2. 'ワークショップインベントリ'の探索 +'ワークショップインベントリ'は、典型的な静的インベントリを表すものとして、ラボ環境にプリロードされています： -**Workshop Inventory** というインベントリーが現れます。**Workshop Inventory** をクリックして、**Hosts** ボタンをクリックします。 +- **インベントリへのアクセス:** Web UIの `リソース → インベントリ` に移動し、'ワークショップインベントリ'を選択します。 +- **ホストの表示:** 'ホスト'ボタンをクリックすると、従来のAnsibleインベントリファイルで見つかるかもしれないプリロードされたホスト構成が表示されます。例えば： -`~/lab_inventory/hosts` のインベントリー情報は、プロビジョニング目的の一環として Ansible 自動コントローラーインベントリーに事前にロードされていました。 -```bash -$ cat ~/lab_inventory/hosts -[web] -node1 ansible_host=22.33.44.55 -node2 ansible_host=33.44.55.66 -node3 ansible_host=44.55.66.77 -[control] -ansible ansible_host=11.22.33.44 +```yaml +[web_servers] +web1 ansible_host=22.33.44.55 +web2 ansible_host=33.44.55.66 +... ``` -> **警告** -> -> 実際の環境のインベントリーでは、IP アドレスが異なることがあります。 - -### マシンの認証情報の検証 - -次に、自動コントローラーから管理対象ホストにアクセスするための認証情報を調べます。この Ansible ワークショップのプロビジョニングプロセスの一環として、**ワークショップ資格情報**はすでに設定されています。 - -**Resource** メニューで **Credentials** を選択します。次に、*Workshop Credential** をクリックします。 - -次の情報に注意してください。 - - - - - - - - - - - - - - - - - - -
パラメーター値
Credential TypeMachine- Machine credentials define ssh and user-level privilege escalation access for playbooks. They are used when submitting jobs to run playbooks on a remote host.
Usernameec2-user which matches our command-line Ansible inventory username for the other Linux nodes
SSH Private KeyEncrypted - take note that you can't actually examine the SSH private key once someone hands it over to Ansible Automation controller
- -### アドホックコマンドの実行 - -Ansible 自動コントローラーからアドホックコマンドを実行することもできます。 - -* Web UIで、**Resource → Inventories → Workshop Inventory** に移動します。 - -* **Host** タブをクリックしてホストビューに変更し、ホストエントリーの左側にあるボックスにチェックマークを付けて 3 つのホストを選択します。 - -* **Run Command** ボタンをクリックします。次の画面で、アドホックコマンドを指定する必要があります。 - -**Details** ウィンドウで、**Module** `ping` を選択し、**Next** をクリックします。 - -**Execution Environment** ウィンドウで **Default execution environment** を選択し、**Next** をクリックします。 - -**Machine Credential**ウィンドウで、**Workshop Credentials** を選択し、**Launch** をクリックします。 - -> **ヒント** -> -> 結果の出力は、コマンドが完了すると表示されます。 -> - -
- -単純な **ping** モジュールにはオプションは必要ありません。他のモジュールの場合、引数として実行するコマンドを指定する必要があります。**command** モジュールを試して、アドホックコマンドを使用して実行中のユーザーのユーザー ID を見つけてください。 - -* Web UIで、**Resource → Inventories → Workshop Inventory** に移動します。 -* **Host** タブをクリックしてホストビューに変更し、ホストエントリーの左側にあるボックスにチェックマークを付けて 3 つのホストを選択します。 +### 3. マシンクレデンシャルの理解 +管理されたホストへのSSH接続を確立するために、マシンクレデンシャルは不可欠です： -* **Run Command** ボタンをクリックします。次の画面で、アドホックコマンドを指定する必要があります。 +- **クレデンシャルへのアクセス:** メインメニューから `リソース → クレデンシャル` を選択し、'ワークショップクレデンシャル'を選択します。 +- **クレデンシャルの詳細:** 'ワークショップクレデンシャル'は、以下のようなパラメータで事前設定されています： +- **クレデンシャルタイプ:** マシン、SSHアクセス用。 +- **ユーザー名:** 事前定義されたユーザー、例えば `ec2-user`。 +- **SSHプライベートキー:** 暗号化され、ホストへの安全なアクセスを提供します。 -**Details** ウィンドウで、**Arguments** タイプ `id` で **Module** `command` を選択し、**Next** をクリックします。 +### 4. 追加のクレデンシャルタイプ +Ansibleオートメーションコントローラーは、異なる自動化シナリオのためにさまざまなクレデンシャルタイプをサポートしています： -**Execution Environment** ウィンドウで **Default execution environment** を選択し、**Next** をクリックします。 +- **ネットワーククレデンシャル:** ネットワークデバイスの管理用。 +- **ソースコントロールクレデンシャル:** ソースコントロール管理へのアクセス用。 +- **アマゾンウェブサービスクレデンシャル:** Amazon AWSとの統合用。 -**Machine Credential**ウィンドウで、**Workshop Credentials** を選択し、**Launch** をクリックします。 +各タイプは特定の要件に合わせて調整され、自動化の柔軟性とセキュリティを向上させます。 - -> **ヒント** -> -> 実行するモジュールを選択します。"Arguments" の隣の疑問符をクリックすると、Ansible 自動コントローラーにより、モジュールの docs ページへのリンクが表示されます。これは便利なのでお試しください。 - -
- -システムから秘密情報を取得してみるのはどうでしょうか？*/etc/shadow* を出力してみましょう。 - -* Web UIで、**Resource → Inventories → Workshop Inventory** に移動します。 - -* **Host** タブをクリックしてホストビューに変更し、ホストエントリーの左側にあるボックスにチェックマークを付けて 3 つのホストを選択します。 - -* **Run Command** ボタンをクリックします。次の画面で、アドホックコマンドを指定する必要があります。 - -**Details** ウィンドウで、**Arguments** `cat /etc/shadow` で **Module** `command` を選択し、**次へ** をクリックします。 - -**Execution Environment** ウィンドウで **Default execution environment** を選択し、**Next** をクリックします。 - -**Machine Credential**ウィンドウで、**Workshop Credentials** を選択し、**Launch** をクリックします。 - -> **警告** -> -> **エラーが発生します** - -最後のはうまく動作しません。すべて赤く表示されています。 - -最後のアドホックコマンドを再実行しますが、今回は **Enable privilege escalation** にチェックマークを付けます。 - -ご覧のとおり、今度は成功しました。`root` として実行する必要があるタスクの場合は、特権を昇格する必要があります。これは、AnsiblePlaybook で使用されている **become:yes** と同じです。 - -### チャレンジラボ: アドホックコマンド - -さて、小チャレンジです。アドホックを実行して、パッケージ「tmux」がすべてのホストにインストールされていることを確認します。不明な場合は、上記の Web UI を介して、または自動コントローラー制御ホストで `[ansible@controller ~]$ ansible-doc yum` を実行してドキュメントを参照してください。 - -> **警告** -> -> **回答を以下に示します。** - -* Web UIで、**Resource → Inventories → Workshop Inventory** に移動します。 - -* **Host** タブをクリックしてホストビューに変更し、ホストエントリーの左側にあるボックスにチェックマークを付けて 3 つのホストを選択します。 - -* **Run Command** ボタンをクリックします。次の画面で、アドホックコマンドを指定する必要があります。 - -**Details** ウィンドウで、**Module** `yum` を選択し、**Arguments** タイプ `name=tmux` で **Enable privilege escalation** をチェックし、**Next** をクリックします。 - -**Execution Environment** ウィンドウで **Default execution environment** を選択し、**Next** をクリックします。 - -**Machine Credential**ウィンドウで、**Workshop Credentials** を選択し、**Launch** をクリックします。 - - - -> **ヒント** -> -「CHANGED」という出力でパッケージがインストールされたことに注目してください。この ad hoc コマンドを2回目に実行すると、出力には「SUCCESS」と表示され、messageパラメータで「何もすることはありません」と通知されます。 +### 5. 結論 +このワークショップは、Ansibleオートメーションコントローラー内のインベントリとクレデンシャルの基礎的な概念を紹介します。これらのコンポーネントを理解することは、自動化タスクを効率的に管理し、インフラストラクチャへの安全なアクセスを保証するために不可欠です。 --- **ナビゲーション**
[前の演習](../2.1-intro) - [次の演習](../2.3-projects) -[Click here to return to the Ansible for Red Hat Enterprise Linux Workshop](../README.md#section-2---ansible-tower-exercises) +[Ansible for Red Hat Enterprise Linux Workshopに戻る](../README.md#section-2---ansible-tower-exercises) + diff --git a/exercises/ansible_rhel/2.2-cred/README.md b/exercises/ansible_rhel/2.2-cred/README.md index 94c7a8165..ba4e90856 100644 --- a/exercises/ansible_rhel/2.2-cred/README.md +++ b/exercises/ansible_rhel/2.2-cred/README.md @@ -1,177 +1,57 @@ -# Workshop Exercise - Inventories, credentials and ad hoc commands +# Workshop Exercise: Inventories and Credentials in Ansible Automation Controller **Read this in other languages**:
![uk](../../../images/uk.png) [English](README.md),![japan](../../../images/japan.png)[日本語](README.ja.md),![france](../../../images/fr.png) [Française](README.fr.md),![Español](../../../images/col.png) [Español](README.es.md). -## Table of Contents - -- [Workshop Exercise - Inventories, credentials and ad hoc commands](#workshop-exercise---inventories-credentials-and-ad-hoc-commands) - - [Table of Contents](#table-of-contents) - - [Objective](#objective) - - [Guide](#guide) - - [Examine an Inventory](#examine-an-inventory) - - [Examine Machine Credentials](#examine-machine-credentials) - - [Run Ad Hoc commands](#run-ad-hoc-commands) - - [Challenge Lab: Ad Hoc Commands](#challenge-lab-ad-hoc-commands) - ## Objective +This workshop is designed to provide a practical understanding of how to manage inventories and credentials within the Ansible Automation Controller. You'll learn how to navigate a preloaded inventory, understand its structure, and explore the setup and use of machine credentials for accessing managed hosts. -Explore and understand the lab environment. This exercise will cover - -* Locating and understanding: - - * Ansible Automation Controller [**Inventory**](https://docs.ansible.com/automation-controller/latest/html/userguide/inventories.html) - * Ansible Automation Controller [**Credentials**](https://docs.ansible.com/automation-controller/latest/html/userguide/credentials.html) - -* Running ad hoc commands via the Ansible Automation Controller web UI - -## Guide - -### Examine an Inventory +## Table of Contents +1. [Introduction to Inventories](#1-introduction-to-inventories) +2. [Exploring the 'Workshop Inventory'](#2-exploring-the-workshop-inventory) +3. [Understanding Machine Credentials](#3-understanding-machine-credentials) +4. [Additional Credential Types](#4-additional-credential-types) +5. [Conclusion](#5-conclusion) -The first thing we need is an inventory of your managed hosts. This is the equivalent of an inventory file in command-line Ansible. There is a lot more to it (like dynamic inventories) but let’s start with the basics. +### 1. Introduction to Inventories +Inventories in the Ansible Automation Controller are crucial for defining and organizing the hosts your playbooks will run against. They can be static, with a fixed list of hosts, or dynamic, pulling host lists from external sources. -* You should already have the web UI open, if not: Point your browser to the URL you were given, similar to `https://student.workshopname.demoredhat.com` (replace "\" with your student number and "workshopname" with the name of your current workshop) and log in as `admin`. The password will be provided by the instructor. +### 2. Exploring the 'Workshop Inventory' +The 'Workshop Inventory' is preloaded into your lab environment, representing a typical static inventory: -There will be one inventory, the **Workshop Inventory**. Click the **Workshop Inventory** then click the **Hosts** button +- **Accessing the Inventory:** Navigate to `Resources → Inventories` in the web UI, and select 'Workshop Inventory'. +- **Viewing Hosts:** Click the 'Hosts' button to reveal the preloaded host configurations, similar to what you might find in a traditional Ansible inventory file, such as: -The inventory information at `~/lab_inventory/hosts` was pre-loaded into the Ansible Automation controller Inventory as part of the provisioning process. -```bash -$ cat ~/lab_inventory/hosts -[web] -node1 ansible_host=22.33.44.55 -node2 ansible_host=33.44.55.66 -node3 ansible_host=44.55.66.77 -[control] -ansible ansible_host=11.22.33.44 +```yaml +[web_servers] +web1 ansible_host=22.33.44.55 +web2 ansible_host=33.44.55.66 +... ``` -> **Warning** -> -> In your inventory the IP addresses will be different. - -### Examine Machine Credentials - -Now we will examine the credentials to access our managed hosts from Automation controller. As part of the provisioning process for this Ansible Workshop the **Workshop Credential** has already been setup. - -In the **Resources** menu choose **Credentials**. Now click on the **Workshop Credential**. - -Note the following information: - - - - - - - - - - - - - - - - - - -
ParameterValue
Credential TypeMachine- Machine credentials define ssh and user-level privilege escalation access for playbooks. They are used when submitting jobs to run playbooks on a remote host.
Usernameec2-user which matches our command-line Ansible inventory username for the other Linux nodes
SSH Private KeyEncrypted - take note that you can't actually examine the SSH private key once someone hands it over to Ansible Automation controller
- -### Run Ad Hoc commands - -It is possible to run run ad hoc commands from Ansible Automation controller as well. - -* In the web UI go to **Resources → Inventories → Workshop Inventory** - -* Click the **Hosts** tab to change into the hosts view and select the three hosts by ticking the boxes to the left of the host entries. - -* Click **Run Command** button. In the next screen you have to specify the ad hoc command. - -Within the **Details** window, select **Module** `ping` and click **Next**. - -Within the **Execution Environment** window, select **Default execution environment** and click **Next**. - -Within the **Machine Credential** window, select **Workshop Credentials** and click **Launch**. - -> **Tip** -> -> The output of the results is displayed once the command has completed. -> - -
- -The simple **ping** module doesn’t need options. For other modules you need to supply the command to run as an argument. Try the **command** module to find the userid of the executing user using an ad hoc command. - -* In the web UI go to **Resources → Inventories → Workshop Inventory** - -* Click the **Hosts** tab to change into the hosts view and select the three hosts by ticking the boxes to the left of the host entries. -* Click **Run Command** button. In the next screen you have to specify the ad hoc command. +### 3. Understanding Machine Credentials +Machine credentials are essential for establishing SSH connections to your managed hosts: -Within the **Details** window, select **Module** `command`, in **Arguments** type `id` and click **Next**. +- **Accessing Credentials:** From the main menu, choose `Resources → Credentials` and select 'Workshop Credential'. +- **Credential Details:** The 'Workshop Credential' is pre-set with parameters like: +- **Credential Type:** Machine, for SSH access. +- **Username:** A predefined user, e.g., `ec2-user`. +- **SSH Private Key:** Encrypted, providing secure access to your hosts. -Within the **Execution Environment** window, select **Default execution environment** and click **Next**. +### 4. Additional Credential Types +The Ansible Automation Controller supports various credential types for different automation scenarios: -Within the **Machine Credential** window, select **Workshop Credentials** and click **Launch**. +- **Network Credentials:** For managing network devices. +- *Source Control Credentials:** For source control management access. +- **Amazon Web Services Credentials:** For integration with Amazon AWS. +Each type is tailored to specific requirements, enhancing your automation's flexibility and security. -> **Tip** -> -> After choosing the module to run, Ansible Automation Controller will provide a link to the docs page for the module when clicking the question mark next to "Arguments". This is handy, give it a try. - -
- -How about trying to get some secret information from the system? Try to print out */etc/shadow*. - -* In the web UI go to **Resources → Inventories → Workshop Inventory** - -* Click the **Hosts** tab to change into the hosts view and select the three hosts by ticking the boxes to the left of the host entries. - -* Click **Run Command** button. In the next screen you have to specify the ad hoc command. - -Within the **Details** window, select **Module** `command`, in **Arguments** type `cat /etc/shadow` and click **Next**. - -Within the **Execution Environment** window, select **Default execution environment** and click **Next**. - -Within the **Machine Credential** window, select **Workshop Credentials** and click **Launch**. - -> **Warning** -> -> **Expect an error\!** - -Oops, the last one didn’t went well, all red. - -Re-run the last ad hoc command but this time check the checkbox labeled **Enable privilege escalation**. - -As you see, this time it worked. For tasks that have to run as `root` you need to escalate the privileges. This is the same as the **become: yes** used in your Ansible Playbooks. - -### Challenge Lab: Ad Hoc Commands - -Okay, a small challenge: Run an ad hoc to make sure the package "tmux" is installed on all hosts. If unsure, consult the documentation either via the web UI as shown above or by running `[ansible@controller ~]$ ansible-doc yum` on your Automation controller control host. - -> **Warning** -> -> **Solution below\!** - -* In the web UI go to **Resources → Inventories → Workshop Inventory** - -* Click the **Hosts** tab to change into the hosts view and select the three hosts by ticking the boxes to the left of the host entries. - -* Click **Run Command** button. In the next screen you have to specify the ad hoc command. - -Within the **Details** window, select **Module** `yum`, in **Arguments** type `name=tmux`, check **Enable privilege escalation** and click **Next**. - -Within the **Execution Environment** window, select **Default execution environment** and click **Next**. - -Within the **Machine Credential** window, select **Workshop Credentials** and click **Launch**. - - - -> **Tip** -> -> Notice how the package was instaled via the "CHANGED" output. If you run the ad hoc command a second time, the output will mention "SUCCESS" and inform you via the message parameter that there is nothing to do. +### 5. Conclusion +This workshop introduces the foundational concepts of inventories and credentials within the Ansible Automation Controller. Understanding these components is crucial for efficiently managing your automation tasks and securing access to your infrastructure. --- **Navigation** @@ -179,3 +59,5 @@ Within the **Machine Credential** window, select **Workshop Credentials** and cl [Previous Exercise](../2.1-intro) - [Next Exercise](../2.3-projects) [Click here to return to the Ansible for Red Hat Enterprise Linux Workshop](../README.md#section-2---ansible-tower-exercises) + + diff --git a/exercises/ansible_rhel/2.2-cred/README.pt-br.md b/exercises/ansible_rhel/2.2-cred/README.pt-br.md new file mode 100644 index 000000000..efc63f214 --- /dev/null +++ b/exercises/ansible_rhel/2.2-cred/README.pt-br.md @@ -0,0 +1,62 @@ +# Exercício do Workshop: Inventários e Credenciais no Controlador de Automação Ansible + +**Leia isto em outros idiomas**: +
![uk](../../../images/uk.png) [Inglês](README.md), ![japan](../../../images/japan.png) [Japonês](README.ja.md), ![france](../../../images/fr.png) [Francês](README.fr.md), ![Español](../../../images/col.png) [Espanhol](README.es.md). + +## Objetivo +Este workshop é projetado para fornecer um entendimento prático de como gerenciar inventários e credenciais dentro do Controlador de Automação Ansible. Você aprenderá como navegar em um inventário pré-carregado, entender sua estrutura e explorar a configuração e uso de credenciais de máquina para acessar hosts gerenciados. + +## Índice de Conteúdos +1. [Introdução aos Inventários](#1-introdução-aos-inventários) +2. [Explorando o 'Inventário do Workshop'](#2-explorando-o-inventário-do-workshop) +3. [Entendendo as Credenciais de Máquina](#3-entendendo-as-credenciais-de-máquina) +4. [Tipos Adicionais de Credenciais](#4-tipos-adicionais-de-credenciais) +5. [Conclusão](#5-conclusão) + +### 1. Introdução aos Inventários +Inventários no Controlador de Automação Ansible são cruciais para definir e organizar os hosts nos quais seus playbooks serão executados. Eles podem ser estáticos, com uma lista fixa de hosts, ou dinâmicos, puxando listas de hosts de fontes externas. + +### 2. Explorando o 'Inventário do Workshop' +O 'Inventário do Workshop' está pré-carregado no seu ambiente de laboratório, representando um inventário estático típico: + +- **Acessando o Inventário:** Navegue até `Recursos → Inventários` na interface web e selecione 'Inventário do Workshop'. +- **Visualizando Hosts:** Clique no botão 'Hosts' para revelar as configurações de host pré-carregadas, semelhantes ao que você poderia encontrar em um arquivo de inventário Ansible tradicional, como: + + + +```yaml +[web_servers] +web1 ansible_host=22.33.44.55 +web2 ansible_host=33.44.55.66 +... +``` + + +### 3. Entendendo as Credenciais de Máquina +As credenciais de máquina são essenciais para estabelecer conexões SSH com seus hosts gerenciados: + +- **Acessando Credenciais:** A partir do menu principal, escolha `Recursos → Credenciais` e selecione 'Credencial do Workshop'. +- **Detalhes da Credencial:** A 'Credencial do Workshop' está pré-definida com parâmetros como: +- **Tipo de Credencial:** Máquina, para acesso SSH. +- **Nome de Usuário:** Um usuário pré-definido, por exemplo, `ec2-user`. +- **Chave Privada SSH:** Criptografada, fornecendo acesso seguro aos seus hosts. + +### 4. Tipos Adicionais de Credenciais +O Controlador de Automação Ansible suporta vários tipos de credenciais para diferentes cenários de automação: + +- **Credenciais de Rede:** Para gerenciamento de dispositivos de rede. +- **Credenciais de Controle de Fonte:** Para acesso à gestão de controle de versão. +- **Credenciais dos Serviços Web da Amazon:** Para integração com a Amazon AWS. + +Cada tipo é adaptado a requisitos específicos, melhorando a flexibilidade e segurança da sua automação. + +### 5. Conclusão +Este workshop introduz os conceitos fundamentais de inventários e credenciais dentro do Controlador de Automação Ansible. Compreender esses componentes é crucial para gerenciar eficientemente suas tarefas de automação e garantir o acesso seguro à sua infraestrutura. + +--- +**Navegação** +
+[Exercício Anterior](../2.1-intro/README.pt-br.md) - [Próximo Exercício](../2.3-projects/README.pt-br.md) + +[Clique aqui para retornar ao Workshop de Ansible para Red Hat Enterprise Linux](../README.md#section-2---ansible-tower-exercises) + diff --git a/provisioner/workshop_specific/auto_satellite.yml b/provisioner/workshop_specific/auto_satellite.yml index 4004ee113..7020acc1d 100644 --- a/provisioner/workshop_specific/auto_satellite.yml +++ b/provisioner/workshop_specific/auto_satellite.yml @@ -305,7 +305,7 @@ scm_url: 'https://github.com/ansible/awx-facts-playbooks.git' wait: true controller_templates: - - name: SETUP / Satellite + - name: Z / CaC / Satellite project: Automated Management playbook: setup_satellite.yml inventory: Workshop Inventory @@ -315,7 +315,7 @@ extra_vars: refresh_satellite_manifest: false ask_variables_on_launch: true - - name: SETUP / Controller + - name: Z / CaC / Controller project: Automated Management playbook: setup_controller.yml inventory: Workshop Inventory @@ -346,9 +346,9 @@ - name: Final workshop preparations - workshop mode when: provision_mode == "workshop" block: - - name: Run SETUP / Satellite job template + - name: Run Z / CaC / Satellite job template awx.awx.job_launch: - job_template: "SETUP / Satellite" + job_template: "Z / CaC / Satellite" extra_vars: refresh_satellite_manifest: true controller_username: admin @@ -356,7 +356,7 @@ controller_host: "https://{{ student }}.{{ ec2_name_prefix }}.{{ workshop_dns_zone }}" register: setupsatjob - - name: "Check API until SETUP / Satellite job is successful" + - name: "Check API until Z / CaC / Satellite job is successful" ansible.builtin.uri: url: "https://{{ student }}.{{ ec2_name_prefix }}.{{ workshop_dns_zone }}/api/v2/jobs/{{ setupsatjob.id }}/?format=json" user: admin @@ -371,12 +371,43 @@ delay: 20 # Every 20 seconds retries: 45 # 15 minutes 15*60/20 + - name: Run Z / CaC / Controller job template + awx.awx.job_launch: + job_template: "Z / CaC / Controller" + controller_username: admin + controller_password: "{{ admin_password }}" + controller_host: "https://{{ student }}.{{ ec2_name_prefix }}.{{ workshop_dns_zone }}" + register: setupcontroljob + + - name: "Check API until Z / CaC / Controller job is successful" + ansible.builtin.uri: + url: "https://{{ student }}.{{ ec2_name_prefix }}.{{ workshop_dns_zone }}/api/v2/jobs/{{ setupcontroljob.id }}/?format=json" + user: admin + password: "{{ admin_password }}" + force_basic_auth: true + method: GET + return_content: true + status_code: 200 + validate_certs: false + register: workshop_job_templates02 + until: workshop_job_templates02.json.status == "successful" + delay: 20 # Every 20 seconds + retries: 15 # 5 minutes 5*60/20 + + - name: Run Z / SETUP / Workshop deployment workflow template + awx.awx.workflow_launch: + workflow_template: "Z / SETUP / Workshop deployment" + controller_username: admin + controller_password: "{{ admin_password }}" + controller_host: "https://{{ student }}.{{ ec2_name_prefix }}.{{ workshop_dns_zone }}" + timeout: 3900 # 63 minutes + - name: Final workshop preparations - demo mode when: provision_mode == "demo" block: - - name: Run SETUP / Satellite job template + - name: Run Z / CaC / Satellite job template awx.awx.job_launch: - job_template: "SETUP / Satellite" + job_template: "Z / CaC / Satellite" extra_vars: refresh_satellite_manifest: true controller_username: admin @@ -384,7 +415,7 @@ controller_host: "https://{{ student }}.{{ ec2_name_prefix }}.{{ workshop_dns_zone }}" register: setupsatjob - - name: "Check API until SETUP / Satellite job is successful" + - name: "Check API until Z / CaC / Satellite job is successful" ansible.builtin.uri: url: "https://{{ student }}.{{ ec2_name_prefix }}.{{ workshop_dns_zone }}/api/v2/jobs/{{ setupsatjob.id }}/?format=json" user: admin @@ -399,15 +430,15 @@ delay: 20 # Every 20 seconds retries: 45 # 15 minutes 15*60/20 - - name: Run SETUP / Controller job template + - name: Run Z / CaC / Controller job template awx.awx.job_launch: - job_template: "SETUP / Controller" + job_template: "Z / CaC / Controller" controller_username: admin controller_password: "{{ admin_password }}" controller_host: "https://{{ student }}.{{ ec2_name_prefix }}.{{ workshop_dns_zone }}" register: setupcontroljob - - name: "Check API until SETUP / Controller job is successful" + - name: "Check API until Z / CaC / Controller job is successful" ansible.builtin.uri: url: "https://{{ student }}.{{ ec2_name_prefix }}.{{ workshop_dns_zone }}/api/v2/jobs/{{ setupcontroljob.id }}/?format=json" user: admin diff --git a/roles/workshop_check_setup/tasks/main.yml b/roles/workshop_check_setup/tasks/main.yml index ea0d17f31..f5800ad93 100644 --- a/roles/workshop_check_setup/tasks/main.yml +++ b/roles/workshop_check_setup/tasks/main.yml @@ -30,9 +30,10 @@ - name: make sure DNS name is 65 characters or less vars: test_name: "studentXXX-code.{{ ec2_name_prefix|lower }}.{{ workshop_dns_zone }}" + test_name_length: "{{ test_name | length }}" assert: that: - - "{{ test_name|length }} <= 65" + - test_name_length | int <= 65 msg: "you must make sure your DNS name is shorter" - name: make sure security_console is set to a correct value