diff --git a/README.md b/README.md index 2e1cb1ece..0af4378b8 100644 --- a/README.md +++ b/README.md @@ -21,7 +21,6 @@ The Red Hat Ansible Automation Workshops project is intended for effectively dem | **[Ansible Red Hat Enterprise Linux Workshop](./exercises/ansible_rhel)**
focused on automating Linux platforms like Red Hat Enterprise Linux | [PDF](./decks/ansible_rhel.pdf) | [Google Source](https://docs.google.com/presentation/d/1O2Gj5r_fhjM5Pi5FizrZRInmZ37IlpeKPTP6jSZxEKs/edit?usp=sharing) | [Exercises](./exercises/ansible_rhel) | `workshop_type: rhel` | | **[Ansible Config as Code Workshop](./exercises/ansible_config_as_code)**
focused on config as code for AAP | [PDF](./decks/config_as_code.pdf) | [Google Source](https://docs.google.com/presentation/d/1F6W8p0MG878AC3Q1CsNZHfhX5VkEyGKbwDHACQtoLPI) | [Exercises](./exercises/ansible_config_as_code) | `workshop_type: configascode` | | **[Ansible Network Automation Workshop](./exercises/ansible_network)**
focused on router and switch platforms like Arista, Cisco, Juniper | [PDF](./decks/ansible_network.pdf) | [Google Source](https://docs.google.com/presentation/d/1PIT-kGAGMVEEK8PsuZCoyzFC5CIzLBwdnftnUsdUNWQ/edit?usp=sharing) | [Exercises](./exercises/ansible_network) | `workshop_type: network` | -| **[Ansible Security Automation](./exercises/ansible_security)**
focused on automation of security tools like Check Point Firewall, IBM QRadar and the IDS Snort | [PDF](./decks/ansible_security.pdf) | [Google Source](https://docs.google.com/presentation/d/19gVCBz1BmxC15tDDj-FUlUd_jUUUKay81E8F24cyUjk/edit?usp=sharing) | [Exercises](./exercises/ansible_security) | `workshop_type: security` | | **[Ansible Windows Automation Workshop](./exercises/ansible_windows)**
focused on automation of Microsoft Windows | [PDF](./decks/ansible_windows.pdf) | [Google Source](https://docs.google.com/presentation/d/1RO5CQiCoqLDES1NvTI_1fQrR-oWM1NuW-uB0JRvtJzE) | [Exercises](./exercises/ansible_windows) | `workshop_type: windows` | | **[Smart Management Automation Workshop](./exercises/ansible_smart_mgmt)**
focused on automation of security and lifecycle management with Red Hat Satellite Server | [PDF](./decks/ansible_smart_mgmt.pdf) | [Google Source](https://docs.google.com/presentation/d/135lid9AeSioN4bJexBbv9q0fkJwDibpUQg8aeYjxzTY) | [Exercises](./exercises/ansible_smart_mgmt) | `workshop_type: smart_mgmt` | **[RHEL In-place Upgrade Automation Workshop](./exercises/ansible_ripu)**
focused on automation of RHEL in-place upgrades at enterprise scale | [PDF](./decks/ansible_ripu.pdf) | [Google Source](https://docs.google.com/presentation/d/1U6i006Th7MQNuL1_0a0KhOSY4GfF1wFsINusDvJvXvo) | [Exercises](./exercises/ansible_ripu) | `workshop_type: ripu` @@ -78,9 +77,5 @@ The Red Hat Ansible Automation Workshops project is intended for effectively dem - ![french](https://github.com/ansible/workshops/raw/devel/images/fr.png) [Automatiser votre réseau avec Red Hat](https://www.redhat.com/rhdc/managed-files/ma-network-automation-technical-e-book-f28378-202104-a4-fr.pdf) - ![italian](https://github.com/ansible/workshops/raw/devel/images/it.png) [Automatizzare la rete con Red Hat](https://www.redhat.com/rhdc/managed-files/ma-network-automation-technical-e-book-f28378-202104-a4-it.pdf) -### E-Books for Ansible Security Automation - - - [Simplify your security operations center](https://www.redhat.com/en/resources/security-automation-ebook?extIdCarryOver=true&sc_cid=7013a000002gyQ2AAI) - --- ![Red Hat Ansible Automation](https://github.com/ansible/workshops/raw/devel/images/rh-ansible-automation-platform.png) diff --git a/_layouts/default.html b/_layouts/default.html index 4afc642e2..045c20f68 100644 --- a/_layouts/default.html +++ b/_layouts/default.html @@ -9,7 +9,7 @@ gtag('js', new Date()); gtag('config', 'G-LJWQBHM62Z'); - + @@ -50,15 +50,12 @@ Network - - Security - Windows Config as Code - + Open an Issue @@ -79,7 +76,7 @@ alt="Red Hat" /> -

Copyright © 2022 Red Hat, Inc.

+

Copyright © 2024 Red Hat, Inc.

Privacy statement | diff --git a/exercises/ansible_rhel/1.4-variables/facts.yml b/exercises/ansible_rhel/1.4-variables/facts.yml index 6125e63b2..0257aa6a4 100644 --- a/exercises/ansible_rhel/1.4-variables/facts.yml +++ b/exercises/ansible_rhel/1.4-variables/facts.yml @@ -3,5 +3,5 @@ hosts: all tasks: - name: Prints Ansible facts - debug: + ansible.builtin.debug: msg: The default IPv4 address of {{ ansible_fqdn }} is {{ ansible_default_ipv4.address }} diff --git a/exercises/ansible_rhel/1.5-handlers/README.fr.md b/exercises/ansible_rhel/1.5-handlers/README.fr.md index 83a9bd357..4b2bb8e1d 100644 --- a/exercises/ansible_rhel/1.5-handlers/README.fr.md +++ b/exercises/ansible_rhel/1.5-handlers/README.fr.md @@ -35,6 +35,8 @@ Ajoutons à notre playbook system_setup.yml la capacité d'installer le Serveur > 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: Configuration Système de Base @@ -64,6 +66,8 @@ Ajoutons à notre playbook system_setup.yml la capacité d'installer le Serveur when: inventory_hostname in groups['web'] ``` + + 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. ### Étape 3 - Gestionnaires @@ -72,6 +76,7 @@ Les gestionnaires sont utilisés pour les tâches qui ne doivent s'exécuter que 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 : + ```yaml --- @@ -108,6 +113,8 @@ Disons que nous voulons nous assurer que le pare-feu est correctement configuré ``` + + 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. > 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. @@ -175,6 +182,8 @@ node3 : ok=8 changed=4 unreachable=0 failed=0 s 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 - name: Créer un nouvel utilisateur ansible.builtin.user: @@ -183,9 +192,12 @@ Dans le playbook system_setup.yml original de l'exercice 1.4, nous avions une t create_home: true ``` + Maintenant, modifions cette tâche pour créer plusieurs utilisateurs à l'aide d'une boucle : + + ```yaml - name: Créer un nouvel utilisateur ansible.builtin.user: @@ -198,11 +210,16 @@ Maintenant, modifions cette tâche pour créer plusieurs utilisateurs à l'aide - carol ``` + + + + 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. 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. + 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. diff --git a/exercises/ansible_rhel/1.5-handlers/README.md b/exercises/ansible_rhel/1.5-handlers/README.md index b6a5bd0c9..25bd4d1a4 100644 --- a/exercises/ansible_rhel/1.5-handlers/README.md +++ b/exercises/ansible_rhel/1.5-handlers/README.md @@ -89,12 +89,14 @@ Let's say we want to ensure the firewall is configured correctly on all web serv ansible.builtin.dnf: name: firewalld state: present + when: inventory_hostname in groups['web'] - name: Ensure firewalld is running ansible.builtin.service: name: firewalld state: started enabled: true + when: inventory_hostname in groups['web'] - name: Allow HTTPS traffic on web servers ansible.posix.firewalld: @@ -144,14 +146,14 @@ ok: [node1] ok: [node3] TASK [Install firewalld] ******************************************************* -changed: [ansible-1] +skipping: [ansible-1] changed: [node2] changed: [node1] changed: [node3] TASK [Ensure firewalld is running] ********************************************* +skipping: [ansible-1] changed: [node3] -changed: [ansible-1] changed: [node2] changed: [node1] diff --git a/exercises/ansible_rhel/1.6-templates/README.fr.md b/exercises/ansible_rhel/1.6-templates/README.fr.md index 848d4f597..3a0adb94f 100644 --- a/exercises/ansible_rhel/1.6-templates/README.fr.md +++ b/exercises/ansible_rhel/1.6-templates/README.fr.md @@ -24,7 +24,9 @@ Ansible utilise Jinja2, un langage de templatisation largement utilisé pour Pyt ### Étape 2 - Création de Votre Premier Modèle + 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 `{{ }}`. + Dans l'exemple suivant, créons un modèle pour le Message du Jour (MOTD) qui inclut des informations dynamiques sur l'hôte. @@ -40,12 +42,16 @@ mkdir -p ~/lab_inventory/templates Créez un fichier nommé `motd.j2` dans le répertoire des modèles avec le contenu suivant : + + ```jinja Bienvenue sur {{ ansible_hostname }}. OS : {{ ansible_distribution }} {{ ansible_distribution_version }} Architecture : {{ ansible_architecture }} ``` + + 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é. ### Étape 3 - Déploiement du Modèle avec un Playbook diff --git a/exercises/ansible_rhel/README.fr.md b/exercises/ansible_rhel/README.fr.md index 61509ac37..fe8ecabea 100644 --- a/exercises/ansible_rhel/README.fr.md +++ b/exercises/ansible_rhel/README.fr.md @@ -4,63 +4,68 @@
![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/es.png) [Español](README.es.md).
-Ansible est un moteur d'automatisation informatique simple mais puissant pour le déploiement d'applications, la gestion de la configuration et l'orchestration que vous pouvez apprendre rapidement. +**Ceci est une documentation pour Ansible Automation Platform 2** -Dans la première section de ce laboratoire, vous apprendrez à utiliser Ansible Engine pour l'automatisation, des bases aux concepts plus avancés. +Si vous êtes nouveau dans l'automatisation Ansible, cet atelier se compose de deux parties : 1) commencer par les bases de la compréhension des activités de ligne de commande fondamentales et 2) appliquer ce que vous avez appris pour implémenter le contrôleur d'automatisation Ansible dans vos cas d'utilisation en entreprise. Vous commencerez par écrire votre premier playbook Ansible, travailler sur des modèles Jinja et implémenter des rôles Ansible de haut niveau. Ensuite, vous commencerez avec le contrôleur d'automatisation, comprendrez la gestion des inventaires et des informations d'identification, les projets, les modèles de tâches, les enquêtes, les workflows et plus encore. -La deuxième section de ce laboratoire couvre Tower et donne à l'utilisateur un aperçu de ce qu'est Tower, de son fonctionnement et de ses avantages. +Après avoir terminé ce laboratoire, vous serez prêt à commencer à utiliser Ansible pour vos besoins d'automatisation. -Après avoir terminé ce laboratoire, vous êtes prêt à commencer à utiliser Ansible pour vos besoins d'automatisation. +## Table des matières + +- [Atelier Ansible - Ansible pour Red Hat Enterprise Linux](#atelier-ansible---ansible-pour-red-hat-enterprise-linux) + - [Table des matières](#table-des-matières) + - [Présentations](#présentations) + - [Planification du temps](#planification-du-temps) + - [Diagramme du laboratoire](#diagramme-du-laboratoire) + - [Section 1 - Exercices en ligne de commande Ansible](#section-1---exercices-en-ligne-de-commande-ansible) + - [Section 2 - Exercices sur la plateforme d'automatisation Ansible](#section-2---exercices-sur-la-plateforme-dautomatisation-ansible) + - [Exercices supplémentaires](#exercices-supplémentaires) ## Présentations -Les exercices sont explicites et guident les participants à travers tout le laboratoire. Tous les concepts sont expliqués lors de leur introduction. +Les exercices sont auto-explicatifs et guident les participants tout au long du laboratoire. Tous les concepts sont expliqués lorsqu'ils sont introduits. -Une présentation facultative est disponible pour soutenir les ateliers et expliquer l'automatisation, les bases d'Ansible et les sujets des exercices plus en détail: -[Ansible RHEL Automation](../../decks/ansible_rhel.pdf) +Il existe une présentation optionnelle disponible pour soutenir les ateliers et expliquer l'automatisation, les bases d'Ansible et les sujets des exercices plus en détail : [Ansible RHEL Automation](../../decks/ansible_rhel.pdf) -Jetez également un œil à notre plate-forme des meilleures pratiques Ansible: -[Ansible Best Practices](../../decks/ansible_best_practices.pdf) +Consultez également notre présentation sur les meilleures pratiques Ansible : [Ansible Best Practices](../../decks/ansible_best_practices.pdf) ## Planification du temps +Le temps nécessaire pour réaliser les ateliers dépend fortement de plusieurs facteurs : le nombre de participants, leur familiarité avec Linux en général et la quantité de discussions entre les participants. -Le temps requis pour faire les ateliers dépend fortement de plusieurs facteurs: le nombre de participants, leur familiarité avec Linux en général et le nombre de discussions qui se font entre les deux. - -Cela dit, les exercices eux-mêmes devraient prendre environ 4 à 5 heures. La première section est légèrement plus longue que la seconde. La présentation qui l'accompagne ajoute une heure de plus. +Cela dit, les exercices eux-mêmes devraient prendre environ 4-5 heures. La première section est légèrement plus longue que la deuxième. La présentation accompagnante ajoute une heure supplémentaire. -Si votre expérience est différente dans la planification de ces ateliers, veuillez nous en informer et créer un ticket. +## Diagramme du laboratoire +![diagramme du laboratoire ansible rhel](../../images/rhel_lab_diagram.png) -## Section 1 - Exercices sur le moteur Ansible +## Section 1 - Exercices en ligne de commande Ansible - - [Exercise 1.1 - Vérifiez les prérequis](1.1-setup/README.fr.md) - - [Exercise 1.2 - Running Ad-hoc Commands](1.2-adhoc/README.fr.md) - - [Exercise 1.3 - Writing Your First Playbook](1.3-playbook/README.fr.md) - - [Exercise 1.4 - Using Variables](1.4-variables/README.fr.md) - - [Exercise 1.5 - Conditionals, Handlers and Loops](1.5-handlers/README.fr.md) - - [Exercise 1.6 - Templates](1.6-templates/README.fr.md) - - [Exercise 1.7 - Roles](1.7-role/README.fr.md) +* [Exercice 1.1 - Vérifier les prérequis](1.1-setup/README.fr.md) +* [Exercice 1.2 - Les bases d'Ansible](1.2-thebasics/README.fr.md) +* [Exercice 1.3 - Écrire votre premier playbook](1.3-playbook/README.fr.md) +* [Exercice 1.4 - Utilisation des variables](1.4-variables/README.fr.md) +* [Exercice 1.5 - Conditionnels, gestionnaires etboucles](1.5-handlers/README.fr.md) +* [Exercice 1.6 - Modèles](1.6-templates/README.fr.md) +* [Exercice 1.7 - Rôles](1.7-role/README.fr.md) +* [Exercice 1.8 - Débogage et gestion des erreurs](1.8-troubleshoot/README.fr.md) -## Section 2 - Exercices sur Ansible Tower +## Section 2 - Exercices sur la plateforme d'automatisation Ansible - - [Exercise 2.1 - Introduction to Tower](2.1-intro/README.fr.md) - - [Exercise 2.2 - Inventories, credentials and ad hoc commands](2.2-cred/README.fr.md) - - [Exercise 2.3 - Projects & job templates](2.3-projects/README.fr.md) - - [Exercise 2.4 - Surveys](2.4-surveys/README.fr.md) - - [Exercise 2.5 - Role based access control](2.5-rbac/README.fr.md) - - [Exercise 2.6 - Workflows](2.6-workflows/README.fr.md) - - [Exercise 2.7 - Wrap up](2.7-wrap/README.fr.md) +* [Exercice 2.1 - Introduction au contrôleur d'automatisation Ansible](2.1-intro/README.fr.md) +* [Exercice 2.2 - Inventaires et informations d'identification dans le contrôleur d'automatisation Ansible](2.2-cred/README.fr.md) +* [Exercice 2.3 - Projets et modèles de tâches](2.3-projects/README.fr.md) +* [Exercice 2.4 - Enquêtes](2.4-surveys/README.fr.md) +* [Exercice 2.5 - Contrôle d'accès basé sur les rôles](2.5-rbac/README.fr.md) +* [Exercice 2.6 - Workflows](2.6-workflows/README.fr.md) +* [Exercice 2.7 - Conclusion](2.7-wrap/README.fr.md) ## Exercices supplémentaires -Il existe également une série d'exercices qui vont au-delà de notre contenu normal de l'atelier. Veuillez consulter nos exercices supplémentaires si vous souhaitez en savoir plus sur le contenu. - - - [Exercices supplémentaires](supplemental) +Il existe également une série d'exercices qui vont au-delà du contenu normal de notre atelier. Veuillez consulter nos exercices supplémentaires si vous souhaitez plus de contenu pour apprendre. -## Information additionnelle - - - [Prise en main d'Ansible](http://docs.ansible.com/ansible/latest/intro_getting_started.html) +* [Exercices supplémentaires](supplemental) --- ![Red Hat Ansible Automation](../../images/rh-ansible-automation-platform.png) + diff --git a/exercises/ansible_rhel/ansible-files/files/ftpserver.yml b/exercises/ansible_rhel/ansible-files/files/ftpserver.yml index d0d747b24..79aa8a944 100644 --- a/exercises/ansible_rhel/ansible-files/files/ftpserver.yml +++ b/exercises/ansible_rhel/ansible-files/files/ftpserver.yml @@ -4,7 +4,7 @@ become: true tasks: - name: Install FTP server when host in ftpserver group - yum: + ansible.builtin.yum: name: vsftpd state: latest when: inventory_hostname in groups["ftpserver"] diff --git a/exercises/rhdp_auto_satellite/1-compliance/README.fr.md b/exercises/rhdp_auto_satellite/1-compliance/README.fr.md new file mode 100644 index 000000000..ac911a907 --- /dev/null +++ b/exercises/rhdp_auto_satellite/1-compliance/README.fr.md @@ -0,0 +1,217 @@ +Atelier Automated Satellite : Configurer et exécuter une analyse OpenSCAP +================================================================================ + +**Lisez ceci dans d'autres langues**: +
![uk](../../../images/uk.png) [English](README.md), ![france](../../../images/fr.png) [Française](README.fr.md). +
+ +Dans cet exercice, nous allons apprendre à configurer et à effectuer une analyse OpenSCAP à l'aide de playbooks dans Ansible Automation Platform 2 avec Satellite. Lorsque vous exécutez plusieurs systèmes Red Hat Enterprise Linux, il est important de maintenir tous ces systèmes conformes à une politique de sécurité et d'effectuer des analyses de sécurité fréquemment. OpenSCAP est un projet open source qui est utilisé par des agences gouvernementales, des entreprises, ainsi que par dans entreprise de commerce électronique (pour ne citer que quelques exemples). OpenSCAP fournit des outils pour la vérification automatique des vulnérabilités. Il es possilbe d'installer des manifeste SCAP workbench v1.2.0-8 en format RPM qui fournira des capacités d'analyse. Satellite vient avec le manifeste de sécurité SCAP v0.1.54-3 pour les systèmes RHEL7 et CentOS fournissant les tests XCCDF appropriés pour la conformité PCI et STIG. Cet exercice se concentrera sur les systèmes RHEL. + +Environnement +----------- + +- Red Hat Satellite v6.x, Ansible Automation Platform 2.x + +- 3 clients Red Hat Enterprise Linux v7.9 + +Préalables +-------------------------------------------------------------------------------------- + +- Exercice 0 : Lab de configuration + +- Organisation à utiliser = Organisation par défaut + +- Content View = RHEL7 + +- Environnements de cycle de vie = Dev, QA, Prod + +Exercice +-------- + +#### 1\. Se connecter à Satellite + +- Utilisez un navigateur web sur votre ordinateur pour accéder à l'interface utilisateur Satellite fourni, puis connectez-vous avec l'utilisateur admin. + +![login screen](images/1-compliance-aap2-Satellite_login.png) + +- Vous verrez le tableau de bord Satellite lorsque vous vous connectez + +![satellite_dash](images/1-compliance-aap2-Satellite_Dashboard.png) + +#### 2\. Créer une nouvelle politique de conformité + +Maintenant, nous allons commencer à configurer une politique de conformité que nous pouvons utiliser pour analyser nos systèmes RHEL. + +- Allez sur 'Hosts' à partir du menu sur le côté gauche, puis cliquez sur 'Policies' + +- Cliquez sur le bouton « New Policy » et remplissez les détails comme suit à l'étape 3. + +![satellite_policy](images/1-compliance-aap2-Satellite_SCAP.png) + +#### 3\. Configurer une nouvelle politique de conformité + +Maintenant, nous allons commencer à configurer notre serveur Satellite pour pouvoir gérer une politique de conformité + +- Sélectionnez "Manual" dans les options de déploiement et cliquez sur "Next" + +![satellite_policy](images/1-compliance-aap2-Satellite_SCAP1.png) + +- Créer le nom de la politique "PCI_Compliance" et fournir la description que vous souhaitez. Puis cliquez sur "Next" + +![satellite_policy](images/1-compliance-aap2-Satellite_SCAP2.png) + +- Sélectionnez le contenu par défaut "Red Hat rhel7" et "PCI-DSS v3.2.1 Control Baseline for Red Hat Enterprise Linux 7". Il n'y a pas de fichier d'adaptation (tailoring). Puis cliquez sur "Next" + +![satellite_policy](images/1-compliance-aap2-Satellite_SCAP3.png) + +- Il faut établir un calendrier afin de déterminer à quelle fréquence l'analyse sera exécutée. Vous pouvez sélectionner "Weekly" et "Monday" aux fins de cet exercice. Puis cliquez sur "Next" + +![satellite_policy](images/1-compliance-aap2-Satellite_SCAP4.png) + +- Laissez les valeurs par défaut pour les étapes 5, 6 et 7. Cliquez sur "Next" pour "Location", et "Organizations". Puis à "Hostgroups" cliquez sur "Submit" + +![satellite_policy](images/1-compliance-aap2-Satellite_SCAP5.png) + +#### 4\. Se connecter à la plate-forme d'automatisation Ansible + +- Utilisez un navigateur web sur votre ordinateur pour accéder à l'interface utilisateur Ansible via le lien trouvé dans votre environnement puis connectez-vous avec l'utilisateur admin. + +![login screen](images/1-compliance-aap2-login.png) + +- Une fois que vous vous êtes connecté à Ansible Automation Platform 2, vous serez affiché la page la plus récente visitée. + +![aap_dashboard](images/1-compliance-aap2-dashboard.png) + +#### 5\. Configurer et lancer une template Ansible pour exécuter une analyse OpenSCAP. + +Cette étape nous permettra de scanner un seul hôte rhel7 avec la politique ```PCI_Compliance``` que nous avons configurée sur Satellite. + +- Dans Ansible Automation Platform cliquez sur 'Templates' dans le menu de la pane latérale gauche + +- Cliquez sur le bouton en bleu 'Add' et sélectionnez 'Add job template' dans le menu déroulant. Remplir les détails comme suit: + + Name: SATELLITE / Compliance - OpenSCAP_Configure + + Job Type: Run + + Inventory: RHEL7 Development (Cliquez sur l'icône de la loupe pour sélectionner.) + + Project: Automated Management (Cliquez sur l'icône de la loupe pour sélectionner.) + + Execution Environment: smart_mgmt workshop execution environment (Cliquez sur l'icône de la loupe pour sélectionner.) + + Playbook: configure_openscap.yml (Cliquez sur le menu déroulant pour sélectionner.) + + Credentials: Workshop Credential, et Satellite Credential + (Cliquez sur l'icône de la loupe pour sélectionner.) + REMARQUE : Dans ce nouveau menu. Sélectionnez le bouton radio Workshop Credential + La "Catégorie sélectionnée" est "Machine". Ensuite, utilisez le menu déroulant + Selected Category " pour sélectionner Satellite_Collection. + Vous choisirez alors Satellite Credential. Vous aurez ainsi deux type de credential sélectionnés. En cliquant sur "Select", vous enregistrez vos modifications + et vous quitterez le menu. + + Extra Variables (Respectez l'espacement exact indiqué ci-dessous. Notez que les + extra-vars que nous fournissons doivent être au format YAML): + + --- + HOSTS: node1.example.com + policy_name: + - PCI_Compliance + +![aap_template](images/1-compliance-aap2-template1.png) + +- Laissez le reste des champs comme ils sont, et cliquez sur 'Save'. Vous pouvez +ensuite sélectionnez 'Launch' pour éxecuter la job template. + + +Vous allez être amené à la fenêtre de sortie **Jobs > SATELLITE / Compliance - OpenSCAP_Configure** où vous pourrez suivre chaque tâche exécutée. Cela prendra environ 3 minutes pour terminer. Attendez que l'éxécution se termine avant de passer à l'étape suivante. + +![aap_output](images/1-compliance-aap2-OpenSCAP_Configure-output1.png) + + +#### 6\. Aller de nouveau sur Satellite pour examiner le rapport de l'analyse Openscap (fichier Asset Reporting (ARF)). + +- Survoler 'Hosts' dans le menu de la pane latérale, puis cliquez sur 'Reports'. + +- Cliquez sur le bouton 'Full Report', sous Actions, pour 'node1.example.com' afin de réviser le résultat + +- En sélectionnant une règle, vous trouverez d'autres renseignements concernant la validation effectuée ainsi qu'une description de la règle qui comprend des références de sécurité et des identifiants. + +- Retournez à la section **Rule Overview**. Vous pouvez trier par "Pass", "Fail", "Fixed", ou par tout nombre de qualificatifs souhaité ainsi que des règles de groupe par "Severity" + +![aap_arf](images/1-compliance-aap2-Satellite_ARF.png) + +- Maintenant, décochez tout sauf la case **fail**. Ensuite, faites défiler. +cliquez sur le test "Prevent Login to Accounts With Empty Password" + +- Si vous défilez la page, vous remarquerez plusieurs options de rémédiation, y compris +un snippet 'Ansible'. Cliquez sur "show" à côté du "Remediation Ansible Snippett", +qui présente ensuite des tâches que vous pouvez inclure dans un playbook pour automatiser +la rémédiation sur les systèmes touchés. + +![aap_arf](images/1-compliance-aap2-Satellite_ARF2.png) + +#### 7\. Extension des analyses OpenSCAP + +Cette étape élargira notre analyse OpenSCAP pour ajouter un autre profil de conformité XCCDF appelé ```STIG_Compliance```. Nous allons également étendre pour inclure tous les systèmes dans l'inventaire 'RHEL7 Development' en ajustant la variable supplémentaire 'HOSTS' à 'all' au lieu de spécifier un système unique. + +- Dans Satellite, passez par "Hosts" dans le menu à gauche de l'écran, puis cliquez sur "Policies". + +- Cliquez sur le bouton "New Compliance Policy" + +- Sélectionnez "Manual" dans les options de déploiement et cliquez sur "Next" + +![satellite_policy](images/1-compliance-aap2-Satellite_SCAP6.png) + +- Créer le nom de la politique "STIG_Compliance" et fournir la description que vous souhaitez. Puis cliquez sur "Next" + +![satellite_policy](images/1-compliance-aap2-Satellite_SCAP7.png) + +- Sélectionnez le contenu par défaut "Red Hat rhel7" et "DISA STIG for Red Hat Enterprise Linux 7". Il n'y a pas de fichier d'adaptation (tailoring). Puis cliquez sur "Next" + +![satellite_policy](images/1-compliance-aap2-Satellite_SCAP8.png) + +- Il faut établir un calendrier afin de déterminer à quelle fréquence l'analyse sera exécutée. Vous pouvez sélectionner "Weekly" et "Monday" à des fins de laboratoire. Puis cliquez sur "Next" + +![satellite_policy](images/1-compliance-aap2-Satellite_SCAP9.png) + +- Laissez les valeurs par défaut pour les étapes 5, 6 et 7. Cliquez sur "Next" pour "Location", et "Organizations". Puis à "Hostgroups" cliquez sur "Submit + +![satellite_policy](images/1-compliance-aap2-Satellite_SCAP10.png) + +- Maintenant, nous allons mettre à jour notre template OpenSCAP_Configure dans Ansible Automation Platform et lancer un autre analayse de conformité qui va inclure PCI et la nouvelle analyse STIG. +- Dans Ansible Automation Platform, cliquez sur 'Templates' dans le menu de la pane latérale gauche +- Sélectionnez la job template Satellite/Compliiance - OpenSCAP_Configure, et cliquez sur éditer en bas de la job pour apporter des modifications aux « Variables Extra » : + + Extra Variables (Respectez l'espacement exact indiqué ci-dessous. + Notez que les extra-vars que nous fournissons doivent être + au format YAML): + + --- + HOSTS: all + policy_name: + - PCI_Compliance + - STIG_Compliance + +![aap_template](images/1-compliance-aap2-template2-fix.png) + +- Laissez le reste des champs comme ils sont, et cliquez sur 'Save'. Vous pouvez ensuite sélectionner 'Launch' pour éxécutez la job template. + +- L'éxécution va vous conduira à la fenêtre de sortie **Jobs > SATELLITE / Compliance - OpenSCAP_Configure**. Cela prendra environ 5 minutes pour terminer. Attendez que l'éxécution se termine avant de passer à l'étape suivante. + +![aap_output](images/1-compliance-aap2-OpenSCAP_Configure-output2-fix.png) + +#### 8\. Naviguez de nouveau sur Satellite pour examiner le rapport d'analyse (fichier Asset Reporting File (ARF)). + +- Survoler "Hosts" dans le menu à gauche de l'écran, puis cliquez sur "Reports". + +- Notez que nous avons six nouvelles analyses, 2 analyses pour chaque noeud, un pour PCI_Compliance et l'autre pour STIG_Compliance. + +![aap_arf](images/1-compliance-aap2-Satellite_ARF-Final.png) + +- Chaque rapport peut être examiné indépendamment des autres analyses + +#### 9\. Fin du laboratoire + +- Félicitations, vous avez terminé le laboratoire ! +- Continuer à [Exercice 2: Gestion des correctifs ](../2-patching/README.fr.md), OU [Retour à la page principale de l'atelier](../README.fr.md) diff --git a/exercises/rhdp_auto_satellite/1-compliance/README.md b/exercises/rhdp_auto_satellite/1-compliance/README.md new file mode 100644 index 000000000..4318f8555 --- /dev/null +++ b/exercises/rhdp_auto_satellite/1-compliance/README.md @@ -0,0 +1,274 @@ +Automated Satellite Workshop: Configuring and performing an OpenSCAP Scan +================================================================================ + +**Read this in other languages**: +
![uk](../../../images/uk.png) [English](README.md), ![france](../../../images/fr.png) [Français](README.fr.md). +
+ +In this exercise, we will learn how to configure and perform an OpenSCAP scan using playbooks in Ansible Automation Platform 2 with Satellite. + +When running multiple Red Hat Enterprise Linux systems, it's important to keep all of these systems compliant with a meaningful security policy and perform security scans often. +OpenSCAP is an open source project that defines the language used to express compliance checklists in human and machine readable form (XML). +Government agencies, corporations, and e-commerce organizations, for example, provide their compliance checklists using OpenSCAP. +The OpenSCAP project also develops tools for automated compliance checking. +Red Hat Satellite is configured with openscap integration enabled by default. +This installs openscap ansible modules, roles, and related tools. Satellite is also loaded with the SCAP security guide (SSG)(scap-seruity-guide.noarch). +The SSG contains the checklist files for multiple standards, for multiple operating systems and releases. +These checklists allow for scanning systems to evaluate benchmarks for like CIS, PCI, HIPPA, Justice and DISA-STIG compliance. + +The SCAP packages are available with every install of RHEL. +You can also install the RPM package for the SCAP workbench (e.g. scap-workbench.x86_64) which provides the ability to load and examine the checklists in a user friendly GUI. +You can create a tailoring file for any of the included profiles that allows you to turn on or turn off specific checks to meet the your organization's unique requirements. You can launch and test scans based on your profiles using the tool. +Your tailoring files and the profile can be loaded into Satellite and assigned to groups of systems customize scanning and reporting. Satellite produces reports to meet audit specifications. + +This exercise will focus on standard profiles for PCI and DISA STIG for RHEL systems. Tailoring and other operating systems will be out of scope. + +== Environment + +- Red Hat Satellite v6.x, Ansible Automation Platform 4.x + +- 3 x Red Hat Enterprise Linux clients v7.9 + +Pre-requisites +-------------------------------------------------------------------------------------- + +- Organization to be used = Default Organization + +- Content view = RHEL7 + +- Lifecycle environments = Dev, QA, Prod + +Exercise +-------- + +#### 1\. Logging into Satellite + +- Use a web browser on your computer to access the Satellite GUI provided , then login using the following nomenclature: *admin /* <*password*> + +![login screen](images/1-compliance-aap2-Satellite_login.png) + +- After entering the username and password on the login page, you will see the Satellite dashboard. + +![satellite_dash](images/1-compliance-aap2-Satellite_Dashboard.png) + +#### 2\. Creating a new compliance policy + +Now we will start configuring a compliance policy that we can use to scan our RHEL nodes. + +- In Satellite hover over 'Hosts' from the menu pane on the left side, and then click on 'Policies' + +- Click on the "New Policy" button, and fill out the details as in step 3 below. + +![satellite_policy](images/1-compliance-aap2-Satellite_SCAP.png) + +#### 3\. Configuring a new compliance policy + +Now we will start configuring our Satellite server to be able to manage a compliance policy + +- Select "Manual" from the deployment options and click "Next" + +![satellite_policy](images/1-compliance-aap2-Satellite_SCAP1.png) + +- Create the policy name "PCI_Compliance" and provide any description you like. Then click "Next" + +![satellite_policy](images/1-compliance-aap2-Satellite_SCAP2.png) + +- Select the "Red Hat rhel7 default content" and "PCI-DSS v4.0 Control Baseline for Red Hat Enterprise Linux 7". There is no tailoring file. Then click "Next" + +![satellite_policy](images/1-compliance-aap2-Satellite_SCAP3.png) + +- It is necessary to set a schedule when creating a new compliance policy. You can select "Monthly" and "1" for Day of Month for the purposes of this exercise. Then click "Next" + +![satellite_policy](images/1-compliance-aap2-Satellite_SCAP4.png) + +- Steps 5, 6, and 7 as part of the New Compliance Policy can use default values. Click "Next" through "Locations", and "Organizations". For "Hostgroups" click "Submit" + +![satellite_policy](images/1-compliance-aap2-Satellite_SCAP5.png) + +- After clicking "Submit", you will be presented with the Compliance Policies view, where the new ```PCI_Compliance``` policy is listed. + +![satellite_policy](images/1-compliance-aap2-Satellite_Compliance_Policies.png) + +#### 4\. Logging into the Ansible Automation Platform + +- Use a web browser on your computer to access the Ansible Automation Platform 2 Web UI via the link found in your Environment then login using the following nomenclature: *admin /* <*password*> + +![login screen](images/1-compliance-aap2-login.png) + +- Once you have logged into Ansible Automation Platform 2, you will be shown the most recently visited page, or in case of first login, you will be presented with the main dashboard. + +![aap_dashboard](images/1-compliance-aap2-dashboard.png) + +#### 5\. Configure and launch an Ansible Automation Platform template to run an OpenSCAP scan. + +This step will allow us to scan a single RHEL 7 host with the ```PCI_Compliance``` policy that we configured on Satellite. + +- In Ansible Automation Platform click 'Templates' from the menu pane on the left side + +- Click the BLUE 'Add' drop-down icon and select 'Add job template' from the drop-down selection menu. Fill out the details as follows: + + Name: SATELLITE / Compliance - OpenSCAP Scan + + Job Type: Run + + Inventory: EC2 Dynamic Inventory (Click the magnifying glass icon to select.) + + Project: Automated Management (Click the magnifying glass icon to select.) + + Execution Environment: auto_satellite workshop execution environment (Click the + magnifying glass icon to select.) + + Playbook: configure_openscap.yml (Click drop-down to select.) + + Credentials: Workshop Credential, and Satellite Credential + (Click the magnifying glass icon to select.) + NOTE: In this new menu. Select the Workshop Credential radio button. + The 'Selected Category' for this is 'Machine'. Next, use the + 'Selected Category' drop-down menu again to select Satellite_Collection. + You will choose the Satellite Credential. This will provide you with + two sets of credentials. Choosing 'Select' will save your changes + and exit the menu. + + Variables (Keep the exact spacing provided below. Note that the + extra-vars that we are supplying need to be in YAML format): + + --- + policy_name: + - PCI_Compliance + ... + + Limit: Check the box "Prompt on launch" +![aap_template](images/1-compliance-aap2-template1.png) + +- Leave the rest of the fields blank or as they are, and click 'Save'. + +- With the job template saved, on the top right click the Survey tab, then click on the blue "Add" button. Fill out the details as follows: + + Question: Select inventory group + + Description: inventory group + + Answer variable name: dynamic_inventory_group + + Answer type: Multiple Choice (single select) + + Multiple Choice Options: RHEL7_Dev (click the check box to make it default) + all + +![aap_template](images/1-compliance-aap2-template2.png) + +- Once the survey details are configured, click "Save". + +- With the survey created, click the slider next to the gray "Survey Disabled". You should now see "Survey Enabled". + +![aap_template](images/1-compliance-aap2-template3.png) + +- Click the Details tab and then on the bottom left select 'Launch' to run the job template. + +- On the survey, enter "node1.example.com" for the Limit and click Next. For "Select inventory group", leave the default selection for "RHEL7_Dev" and click Next. Review the entries on the launch Preview and notice scrolling down confirms the entries made during the survey. + +![aap_template](images/1-compliance-aap2-template4.png) + +- Select "Launch". + +- You will be presented with the ```Jobs[SATELLITE / Compliance - OpenSCAP Scan]``` output window where you will be able to follow the job as each task in the playbook executed. + This will take approximately 3 mins to complete. + Wait for the job template to complete before proceeding to the next step. + +![aap_output](images/1-compliance-aap2-OpenSCAP_Scan-output1.png) + +#### 6\. Navigate back to Satellite to examine the Asset Reporting File (ARF). + +- Switch to the browser tab with the Satellite UI and hover over 'Hosts' from the side pane menu and then click on 'Reports'. + +![aap_arf](images/1-compliance-aap2-Satellite_ARF.png) + +- Click on the 'Full Report' button, under Actions, for 'node1.example.com' to see the report (This may take a few seconds). The Openscap Capsule field will reflect your workshop Satellite host. + +- Scroll down to the **Rule Overview** section. You can filter by "Pass", "Fail", "Fixed", or any number of qualifiers as well as group rules by "Severity" + +![aap_arf](images/1-compliance-aap2-Satellite_ARF.png) + +> **NOTE:** +> *Firefox browser* - Currently Firefox browsers are unable to display the Rule Overview filters. + +- Selecting a rule presents detailed information regarding rationale as well as a description of the rule that includes references and identifiers. +- Uncheck everything except the *fail* checkbox. For the "Group rules by" drop down menu, select "Severity". + +![aap_arf](images/1-compliance-aap2-Satellite_ARF1.png) + +- Scroll down and click on the failure "Prevent Login to Accounts With Empty Password". + +- If you scroll the page you will notice multiple remediation option selections in green, including a 'Remediate Ansible snippet'. +Click "Activate to reveal" arrow next to the 'Remediation Ansible snippet', which then presents Ansible tasks you can include within a playbook to automate remediation across affected systems. + +![aap_arf](images/1-compliance-aap2-Satellite_ARF2.png) + +#### 7\. Expanding OpenSCAP policy scans + +This step will expand our OpenSCAP policy scan to add another XCCDF compliance profile called ```STIG_Compliance```. We will also expand to include all systems in the 'RHEL7 Development' inventory by leaving the job run ```limit survey``` blank instead of specifying a single system. + +- In Satellite, hover over "Hosts" from the menu on the left side of the screen, and then click on "Policies". + +- Click on the "New Compliance Policy" button + +- Select "Manual" from the deployment options and click "Next" + +![satellite_policy](images/1-compliance-aap2-Satellite_SCAP6.png) + +- Create the policy name "STIG_Compliance" and provide any description you like. Then click "Next" + +![satellite_policy](images/1-compliance-aap2-Satellite_SCAP7.png) + +- Select the "Red Hat rhel7 default content" and "DISA STIG for Red Hat Enterprise Linux 7". There is no tailoring file. Then click "Next" + +![satellite_policy](images/1-compliance-aap2-Satellite_SCAP8.png) + +- It is necessary to set a schedule when creating a new compliance policy. You can select "Monthly" and "1" for Day of Month for the purposes of this exercise. Then click "Next" + +![satellite_policy](images/1-compliance-aap2-Satellite_SCAP9.png) + +- Steps 5, 6, and 7 as part of the New Compliance Policy can use default values. Click "Next" through "Locations", "Organizations", and "Hostgroups". On "Hostgroups" click "Submit" to create the policy. + +![satellite_policy](images/1-compliance-aap2-Satellite_SCAP10.png) + +- After clicking "Submit", you will be presented with the Compliance Policies view, where the new ```STIG_Compliance``` policy is listed, along with the ```PCI_Compliance``` policy created earlier in the exercise. + +![satellite_policy](images/1-compliance-aap2-Satellite_Compliance_Policies2.png) + +- Now, we will update our OpenSCAP Scan job template in Ansible Automation Platform and run another PCI compliance scan, plus the STIG compliance scan. +- Navigate back to the Ansible Automation Platform UI and click 'Templates' from the left side pane menu +- Select the OpenSCAP Scan job template, and click edit at the bottom of the template to modify the "Variables" section and add the ```STIG_Compliance``` policy to the ```policy_name``` list: + + Variables (Keep the exact spacing provided below. + Note that the extra-vars that we are supplying need to be + in YAML format): + + --- + policy_name: + - PCI_Compliance + - STIG_Compliance + +![aap_template](images/1-compliance-aap2-template2-fix.png) + +- Leave the rest of the fields blank or as they are, and click 'Save'. You can then select 'Launch' to deploy the job template. + +- On the survey, leave the Limit field empty, as we are going to target all instances in the inventory group and click Next. For "Select inventory group", leave the default selection for "RHEL7_Dev" and click Next. Review the entries on the launch Preview and notice scrolling down confirms the entries made during the survey. Click "Launch". +- You will be presented with ```Jobs[SATELLITE / Compliance - OpenSCAP Scan]``` output window. This will take approximately 5 minutes to complete. Wait for the job template to complete before proceeding to the next step. + +![aap_output](images/1-compliance-aap2-OpenSCAP_Configure-output2-fix.png) + +#### 8\. Navigate back to Satellite to examine the Asset Reporting File (ARF). + +- Switch to the browser tab with the Satellite UI and hover over "Hosts" from the menu on the left side of the screen, and then click on "Reports". + +- Notice that we've now easily scaled to six policy scans, with each node being scanned for the ```PCI_Compliance``` policy and for ```STIG_Compliance``` policy. + +![aap_arf](images/1-compliance-aap2-Satellite_ARF-Final.png) + +- Each report can be reviewed independent of other node scans and remediations for rule findings can be completed according to the requirements of your own internal policies. + +#### 9\. End of Exercise + +- You have finished Exercise 1. +- Continue to [Exercise 2: Patch Management / OS](../2-patching/README.md), OR [Return to the main workshop page](../README.md) diff --git a/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-OpenSCAP_Configure-output1.png b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-OpenSCAP_Configure-output1.png new file mode 100644 index 000000000..4b313a65f Binary files /dev/null and b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-OpenSCAP_Configure-output1.png differ diff --git a/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-OpenSCAP_Configure-output2-fix.png b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-OpenSCAP_Configure-output2-fix.png new file mode 100644 index 000000000..49c7136b2 Binary files /dev/null and b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-OpenSCAP_Configure-output2-fix.png differ diff --git a/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-OpenSCAP_Configure-success1.png b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-OpenSCAP_Configure-success1.png new file mode 100644 index 000000000..20ad7b27c Binary files /dev/null and b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-OpenSCAP_Configure-success1.png differ diff --git a/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-OpenSCAP_Configure-success2.png b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-OpenSCAP_Configure-success2.png new file mode 100644 index 000000000..68c0dd9fc Binary files /dev/null and b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-OpenSCAP_Configure-success2.png differ diff --git a/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-OpenSCAP_Scan-output1.png b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-OpenSCAP_Scan-output1.png new file mode 100644 index 000000000..b6283cef9 Binary files /dev/null and b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-OpenSCAP_Scan-output1.png differ diff --git a/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_ARF-Final.png b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_ARF-Final.png new file mode 100644 index 000000000..02d975643 Binary files /dev/null and b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_ARF-Final.png differ diff --git a/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_ARF.png b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_ARF.png new file mode 100644 index 000000000..92d4bb9d9 Binary files /dev/null and b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_ARF.png differ diff --git a/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_ARF1.png b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_ARF1.png new file mode 100644 index 000000000..7450ac84a Binary files /dev/null and b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_ARF1.png differ diff --git a/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_ARF2.png b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_ARF2.png new file mode 100644 index 000000000..f5d4c415a Binary files /dev/null and b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_ARF2.png differ diff --git a/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_Compliance_Policies.png b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_Compliance_Policies.png new file mode 100644 index 000000000..a37428939 Binary files /dev/null and b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_Compliance_Policies.png differ diff --git a/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_Compliance_Policies2.png b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_Compliance_Policies2.png new file mode 100644 index 000000000..dd94cdee5 Binary files /dev/null and b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_Compliance_Policies2.png differ diff --git a/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_Dashboard.png b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_Dashboard.png new file mode 100644 index 000000000..fe3481a72 Binary files /dev/null and b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_Dashboard.png differ diff --git a/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_SCAP.png b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_SCAP.png new file mode 100644 index 000000000..af3cc3f4e Binary files /dev/null and b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_SCAP.png differ diff --git a/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_SCAP1.png b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_SCAP1.png new file mode 100644 index 000000000..ea01c6e80 Binary files /dev/null and b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_SCAP1.png differ diff --git a/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_SCAP10.png b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_SCAP10.png new file mode 100644 index 000000000..0e58b7fc4 Binary files /dev/null and b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_SCAP10.png differ diff --git a/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_SCAP2.png b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_SCAP2.png new file mode 100644 index 000000000..4018bce3b Binary files /dev/null and b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_SCAP2.png differ diff --git a/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_SCAP3.png b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_SCAP3.png new file mode 100644 index 000000000..fefe3cc52 Binary files /dev/null and b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_SCAP3.png differ diff --git a/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_SCAP4.png b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_SCAP4.png new file mode 100644 index 000000000..1e98af2f4 Binary files /dev/null and b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_SCAP4.png differ diff --git a/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_SCAP5.png b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_SCAP5.png new file mode 100644 index 000000000..0e58b7fc4 Binary files /dev/null and b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_SCAP5.png differ diff --git a/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_SCAP6.png b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_SCAP6.png new file mode 100644 index 000000000..ea01c6e80 Binary files /dev/null and b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_SCAP6.png differ diff --git a/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_SCAP7.png b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_SCAP7.png new file mode 100644 index 000000000..5a85b605a Binary files /dev/null and b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_SCAP7.png differ diff --git a/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_SCAP8.png b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_SCAP8.png new file mode 100644 index 000000000..caa24926a Binary files /dev/null and b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_SCAP8.png differ diff --git a/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_SCAP9.png b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_SCAP9.png new file mode 100644 index 000000000..1e98af2f4 Binary files /dev/null and b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_SCAP9.png differ diff --git a/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_login.png b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_login.png new file mode 100644 index 000000000..252aba1de Binary files /dev/null and b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-Satellite_login.png differ diff --git a/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-dashboard.png b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-dashboard.png new file mode 100644 index 000000000..8923ebcde Binary files /dev/null and b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-dashboard.png differ diff --git a/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-login.png b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-login.png new file mode 100644 index 000000000..24bc6f3bd Binary files /dev/null and b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-login.png differ diff --git a/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-template1.png b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-template1.png new file mode 100644 index 000000000..26117e0f6 Binary files /dev/null and b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-template1.png differ diff --git a/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-template1_launch.png b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-template1_launch.png new file mode 100644 index 000000000..26d9591de Binary files /dev/null and b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-template1_launch.png differ diff --git a/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-template2-fix.png b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-template2-fix.png new file mode 100644 index 000000000..cb52e0d87 Binary files /dev/null and b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-template2-fix.png differ diff --git a/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-template2.png b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-template2.png new file mode 100644 index 000000000..fddf3e37a Binary files /dev/null and b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-template2.png differ diff --git a/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-template2_launch.png b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-template2_launch.png new file mode 100644 index 000000000..3b775c794 Binary files /dev/null and b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-template2_launch.png differ diff --git a/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-template3.png b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-template3.png new file mode 100644 index 000000000..41c968ae2 Binary files /dev/null and b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-template3.png differ diff --git a/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-template4.png b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-template4.png new file mode 100644 index 000000000..2b4062fb9 Binary files /dev/null and b/exercises/rhdp_auto_satellite/1-compliance/images/1-compliance-aap2-template4.png differ diff --git a/exercises/rhdp_auto_satellite/2-patching/README.fr.md b/exercises/rhdp_auto_satellite/2-patching/README.fr.md new file mode 100644 index 000000000..bb0fd6875 --- /dev/null +++ b/exercises/rhdp_auto_satellite/2-patching/README.fr.md @@ -0,0 +1,139 @@ +Atelier Automated Satellite : Automatisation de la gestion des correctifs +================================================================ + +**Lisez ceci dans d'autres langues**: +
![uk](../../../images/uk.png) [English](README.md), ![france](../../../images/fr.png) [Française](README.fr.md). +
+ +Dans cette partie de l'atelier, nous apprendrons comment utiliser des workflows dans Ansible Automation Platform pour orchestrer la gestion de correctifs pour plusieurs serveurs linux. Automatiser la gestion des correctifs réduit les erreurs humaines et améliore la configuration et la précision des correctifs. En outre, l'automatisation fournit des capacités pour réduire l'entrée manuelle associée aux systèmes d'identification, de test et de patching. L'utilisation de la plateforme Ansible Automation permet des scénarios de gestion de correctifs plus complexe. + +Environnement +----------- + +- Satellite 6.x, Ansible Automation Platform 2.x + +- 3 clients Red Hat Enterprise Linux v7.9 + +Préalables +-------------- + +- Exercice 0 : Lab de configuration + +- Organisation à utiliser = Organisation par défaut + +- Lieu à utiliser = Lieu par défaut + +- Content View = RHEL7 + +- Environnements de cycle de vie = Dev, QA, Prod + +Exercice +-------- + +#### 1\. Se connecter à la plate-forme d'automatisation Ansible + +- Utilisez un navigateur web sur votre ordinateur pour accéder à l'interface utilisateur Ansible Automation Platform. + +![login screen](images/2-patching-aap2-login.png) + +- Une fois dans la plateforme d'automatisation, vous pourrez voir un tableau de bord + +![tableau de bord](images/2-patching-aap2-dashboard.png) + +#### 2\. Création d'un nouveau flux de travail de gestion de correctif + +Maintenant, nous allons commencer à configurer un workflow qui comprend la publication d'un Content View, sa promotion, une analyse de faits, ainsi que le mise en application des correctifs de sécurité. L'objectif est de publier un nouveau Content View et de promouvoir notre environnement rhel7_DEV à QA. + +- Commencez en cliquant sur "Templates" dans le menu à gauche, puis cliquez sur le bouton "Add" et choisissez "Add workflow template". + +- Inscrire le nom "SATELLITE / Patching Workflow" et cliquez sur Save (il n'y a pas d'autres options nécessaires à sélectionner sur cette page). + +- Cela devrait ouvrir un flux de travail vierge, offrant de commencer à le construire en choisissant le bouton vert Start. Vous pouvez toujours revenir à ce flux de travail à partir de template en sélectionnant l'onglet 'Visualizer'. + +![workflow start](images/2-patching-aap2-workflow-start.png) + +- Sélectionnez Start pour ajouter un noeud. Dans le menu déroulant "Node Type" sélectionnez "Inventory Source Sync" et cliquez sur "EC2 Dynamic Source - RHEL7 Development". Ceci établit l'inventaire que vous utiliserez dans votre flux de travail. Cliquez sur 'Save'. + +![workflow inventory source](images/2-patching-aap2-workflow-inventory-source.png) + +- Séléctionner Start de nouveau et ajouter un second noeud (Cliquez sur l'affiche "+"). Dans le menu déroulant "Node Type" sélectionnez "Job Template" puis sélectionnez "SATELLITE / RHEL - Publish Content View". Laissez "Convergence" sur "Any". Cliquez sur Next - un formulaire est joint à cette template, vous aurez besoin de sélectionner le bon content view pour les serveurs que nous allons patcher. Sélectionnez le contente view 'RHEL7' et cliquez sur 'next'. Vous devrez alors confirmer l'aperçu de ce noeud de workflow en cliquant sur 'Save': + +![workflow inventory source](images/2-patching-aap2-workflow-publish-CV-preview.png) + +Cette étape dans le workflow ajoute votre première Job Template qui exécute un playbook appelé 'satellite_publish.yml'. + +- Ajouter le troisième noeud au flux de travail en survolant votre nœud d'inventaire 'EC2 Dynamic Source - RHEL7 Development' et sélectionnez l'icône + pour générer un autre noeud de workflow. Dans la fenêtre pop-up, sélectionnez 'On Success', puis Suivant. Dans la fenêtre de suivi, Node Type sera 'Job Template'. Sélectionnez 'SERVER / RHEL7 - Fact Scan', laissez 'Convergence' à 'Any' et sélectionnez Suivant. Cette étape dans le workflow analysera les noeuds dans notre inventaire satellite pour vérifier les mises à jour des paquets et errata. Vous n'avez pas besoin de limiter la job template, alors cliquez sur Suivant, puis Enregistrer pour terminer la configuration. + +À ce stade, votre flux de travail devrait ressembler à ce qui suit: + +![workflow factscan](images/2-patching-aap2-workflow-factscan.png) + +- Il y a deux autres noeuds à ajouter à ce flux de travail. Sur le noeud 'SATELLITE / RHEL - Publish Content View' cliquez sur l'icône +. Dans la fenêtre pop-up, sélectionnez 'On Success' et ensuite Suivant. Ajoutez la job template 'SATELLITE / RHEL - Promote Content View' et laissez 'Convergence' à 'Any' à nouveau. Il y a un formulaire qui nécessite des variables pour le Content View, l'environnement actuel du cycle de vie et l'environnement du cycle de vie suivant. Aux fins de ce laboratoire, nous allons promouvoir Dev à QA. + +- Sélectionnez RHEL7 pour 'Content View ' + +- Sélectionnez RHEL7_Dev pour 'Current Lifecycle Environment ' + +- Sélectionnez RHEL7_QA pour 'Next Lifecycle Environment ' + +Cliquez sur Next et sur Save. + +- Ajouter le dernier noeud en survolant 'SATELLITE / RHEL- Promote Content View' et en sélectionnant l'icône +. Dans la fenêtre pop-up, sélectionnez 'On Success', puis Suivant. Ajoutez la job template 'SERVER / RHEL7 - Patch', laissez 'Convergence' à 'Any' à nouveau et sélectionnez Next. Cete template à également un formulaire joint. Vous devrez sélectionner dans la liste déroulante 'Select Environment' l'environnement que vous aimeriez patcher. Choisissez 'RHEL7_Dev'. La liste déroulante 'Check' est une sélection qui indique à server_patch.yml s'il faut ou non appliquer les mises à jour aux serveurs de notre inventaire. Comme nous voulons appliquer les correctifs, nous allons sélectionner 'No'. Cliquez sur 'Next' en bas de la fenêtre et cliquez sur 'Save'. + +- Avant de pouvoir terminer le workflow, nous devons relier 'SERVER / RHEL7 - Fact Scan' à 'SERVER / RHEL7 - Patch' sur un succès. Passez sur 'SERVER / RHEL7 - Fact Scan' et cliquez sur l'icône de la chaîne. Cliquez ensuite sur la droite du nœud 'SERVER / RHEL7 - Patch' pour lier. Une nouvelle fenêtre vous permettera de choisir 'On Success'. Cliquez sur 'Save'. Vous devrez ensuite cliquer sur le bouton 'SERVER / RHEL7 - Patch', modifier le noeud et sélectionner 'ALL' depuis le menu deroulant CONVERGENCE. Continuer avec Next, Next et Save. + +Votre workflow devrait ressembler à ce qui suit : + +![workflow final](images/2-patching-aap2-workflow-final.png) + +Vous pouvez maintenant sauvegarder et sortir du modèle de workflow. + +#### 3\. Se connecter à Satellite + +- Utilisez un navigateur web sur votre ordinateur pour accéder à l'interface Satellite + +![Accès par satellite](images/2-patching-aap2-Satellite-login.png) + +- Une fois dans Satellite, vous pourrez voir un tableau de bord. + +![Tableau de bord par satellite](images/2-patching-aap2-Satellite-dashboard.png) + +#### 4\. Exploration de la configuration de l'hôte Satellite + +- Passez la souris sur "Hosts" et sélectionnez 'Content Hosts'. Observer les correction de bugs, améliorations et mises à jour de paquets disponibles pour chaque serveur, qui variera selon la date de l'atelier. De plus, prenez note de l'environnement du cycle de vie. + +![Hébergeurs de contenu satellite](images/2-patching-aap2-Satellite-contenthosts.png) + + +- Naviguez sur 'Content' et sélectionnez 'Content Views'. Puisque les serveurs avec lesquels nous travaillons sont RHEL7 sélectionnez la vue sur le contenu RHEL7. Afin de rendre des nouveaux correctifs disponible avec Satellite, il faut publier une nouvelle version du Content View, mais nous l'avons configuré dans le cadre de notre flux de travail ! (Remarque : votre version du content view peut différer de cet exemple, c'est normal). + +![Satellite RHEL7 CV](images/2-patching-aap-Satellite-CV-RHEL7.png) + +- Cliquez sur 'Content' puis 'Content Views' et sélectionnez RHEL7. Remarquez la nouvelle version du content view. + +- Naviguez sur Hosts > All Hosts et selectionnez node1.example.com. Sélectionnez l'onglet « content » sous Détails. C'est votre nombre d'errata avant d'exécuter votre flux de travail de patch. + +#### 5\. Allez sur Ansible Automation Platform et lancez le workflow de patch + +- Cliquez sur Templates et chercher la job template 'SATELLITE / Patching Workflow'. Vous pouvez soit cliquer sur la fusée à droite de la template, soit sélectionner la template et sélectionner LAUNCH. + +- Observez le démarrage de la tâche dans Ansible. Vous devez attendre que ce flux de travail se termine avant de passer à l'étape suivante. Ce workflow devrait prendre ~ 6 minutes pour terminer. Observez les boîtes vertes qui s'étendent et se contractent dans chacun des nœuds de flux de travail. La case du nœud devient verte lorsque l'étape est terminée - vous pouvez également passer la souris sur un nœud de flux de travail pour voir son statut. + +![AAP Workflow in progress](images/2-patching-aap2-workflow-in-progress.png) + +#### 6\. Alelz dans Satellite pour voir le résultat + +- Cliquez sur 'Content' puis 'Content Views' et sélectionnez RHEL7. Remarquez la nouvelle version du content view. + +- Naviguez vers Hosts > All Hosts et selectionnez node1.example.com. Sélectionnez l'onglet « content » sous Détails. Notez que les errata installables ont diminué. Cela indique que nous avons appliqué nos mises à jour. + +![errata réduite](images/2-patching-aap2-Satellite-reduced-installable-errata.png) + +- Vous pouvez remarquer que tous les problèmes ne sont pas résolus. C'est pour montrer que vous pouvez exclure des mises à jour en fonction du type. Dans ce cas, nous n'avons pas appliquer les mises à jour du kernel. Ceci peut bien sûr être configuré en utilisant le module yum dans le playbook server_patch.yml + +![patchs du noyau exclus](images/2-patching-aap2-server-patching-kernel-exclude.png) + +#### 7\. Fin du laboratoire + +- Félicitions, vou avez terminé le laboratoire ! +- Continuer à [Exercice 3: CentOS/RHEL migration et mise à niveau](../3-convert2rhel/README.fr.md), OU [Retour à la page principale de l'atelier](../README.fr.md) diff --git a/exercises/rhdp_auto_satellite/2-patching/README.md b/exercises/rhdp_auto_satellite/2-patching/README.md new file mode 100644 index 000000000..185d874da --- /dev/null +++ b/exercises/rhdp_auto_satellite/2-patching/README.md @@ -0,0 +1,183 @@ +Automated Satellite Workshop: Automating Patch Management exercise +================================================================ + +**Read this in other languages**: +
![uk](../../../images/uk.png) [English](README.md), ![france](../../../images/fr.png) [Français](README.fr.md). +
+ +In this exercise, we will learn how to leverage the use of workflows in Ansible Automation Platform to orchestrate patch management for several linux servers . Automating patch management reduces human error and improves configuration and patch accuracy. Additionally, automation provides capabilities to reduce the manual input associated with identifying, testing and patching systems. Utilizing Ansible Automation Platform also provides capabilities for more complicated patching scenarios. + +Environment +----------- + +- Satellite 6.x, Ansible Automation Platform 4.x + +- 3 x Red Hat Enterprise Linux clients v7.9 + +Pre-requisites +-------------- + +- Organization to be used = Default Organization + +- Location to be used = Default Location + +- A content view = RHEL7 + +- Lifecycle environments = Dev, QA, Prod + +Exercise +-------- + +#### 1\. Logging into the Ansible Automation Platform + +- Use a web browser on your computer to access the Ansible Automation Platform GUI via the link found in the Environment information. Use the username and password provided to login: admin / password_provided + +![login screen](images/2-patching-aap2-login.png) + +- Once you have logged into Ansible Automation Platform 2, you will be presented with the dashboard. + +![dashboard](images/2-patching-aap2-dashboard.png) + +#### 2\. Creating a new Patching Workflow + +Now we will start configuring a workflow that encompasses publishing a content view, promoting a content view, a fact scan, as well as a server patching. The goal is to publish a new content view and promote our RHEL7 Dev environment to QA. + +- Start by clicking "Templates" from the left side pane menu, and then click on the blue "Add" dropdown button and choose "Add workflow template". + +- Create the name "SATELLITE / Patching Workflow" and click Save (there are no other options necessary to select on this page). + +- This should open a blank workflow. Start building it by choosing the green Start button. You can always get back to this workflow from the template by selecting the 'Visualizer' tab. + +![workflow start](images/2-patching-aap2-workflow-start.png) + +* Select Start to add a node. + * From the drop-down menu "Node Type" select "Inventory Source Sync" and enter "RHEL" in the Name filter and press Enter. + * Select "RHEL7 Development". This defines the inventory that will be utilized in the workflow and ensures the most up-to-date inventory configuration is utilized with each workflow invocation. + * Click "Save". + +![workflow inventory source](images/2-patching-aap2-workflow-inventory-source.png) + +* Hover over Start again to add a second node (Click on the appearing "+"). + * From the drop-down menu "Node Type" select "Job Template" then look up and click on 'SATELLITE / RHEL - Publish Content View'. + * Leave "Convergence" on "Any". + * Click Next - a survey is attached to this template so you will need to select the correct content view for the servers we will patch. + * Select the 'RHEL7' content view and click "Next". + * You will then need to confirm the preview of this workflow node by clicking "Save". + +![workflow inventory source](images/2-patching-aap2-workflow-publish-CV-preview.png) + +This step in the workflow adds your first job template which runs a playbook called 'satellite_publish.yml'. + +* Add a third node to the workflow by hovering over your 'RHEL7 Development' inventory node and select the + icon to generate another workflow node. + * In the pop-up window, select 'On Success', and then Next. + * In the follow-on window, Node Type will be 'Job Template'. + * Select 'SERVER / Fact Scan', leave 'Convergence' to 'Any' again and select Next. + * Leave the Limit field empty to target all instances and select "Next". + * Leave the "Select inventory group" drop down on the default "RHEL7_Dev" selection and select "Next". + * This step in the workflow will scan the nodes in the inventory defined to check for current package information. + * Click "Save" to finish the node setup. + +At this point your workflow should resemble the following: + +![workflow factscan](images/2-patching-aap2-workflow-factscan.png) + +There are two more nodes to add to this workflow. + +* Hover over the 'SATELLITE / RHEL - Publish Content View' node and click the + icon. + * In the pop-up window, select 'On Success' and then Next. + * Add the 'SATELLITE / RHEL - Promote Content View' Job Template, and leave 'Convergence' to 'Any' again. + * There is a survey attached that requires variables for content view, current lifecycle environment, and next lifecycle environment. For the purpose of this lab we're going to promote Dev to QA. + * Select RHEL7 for 'Content View' + * Select RHEL7_Dev for 'Current Lifecycle Environment' + * Select RHEL7_QA for 'Next Lifecycle Environment' + * Click 'Next'. You will then need to 'Save' the preview. + +* Add the last node by hovering over 'SATELLITE / RHEL- Promote Content View' and selecting the + icon. + * In the pop-up window, select 'On Success', and then Next. + * Add the 'OS / Patch OS to latest' Job Template, leave 'Convergence' to 'Any' again and select Next. + * This template also has a survey attached. + * Leave the Limit field empty to target all instances and select "Next". + * From the drop-down list 'Select Environment', set the environment you would like to patch: "RHEL7_Dev". + * For 'Include kernel updates?', perhaps we have a situation where a reboot is not feasible at this time, but we still want to update everything else. As such, set the 'Include kernel updates?' selection to 'no'. + * The 'Check for updates only? Do not patch at this time?' drop-down is a selection that provides a choice between applying updates versus only checking to see what updates are to be performed. In this case, we want to apply the patches, so leave the selection at 'no'. + * Click "Next" at the bottom of the window and then click "Save" at the preview. + +![patch latest](images/2-patching-aap2-workflow-patch-latest.png) + +Before we can finish the workflow we need to link 'SERVER / Fact Scan' to 'OS / Patch OS to latest' and coverage on success. + +* Hover over 'SERVER / Fact Scan' and click on the chain icon, then click to the right of the 'OS / Patch OS to latest' node to link. + * You will be prompted with an "Add Link" menu for the Run options. Leave the selection defined for 'On Success'. + * Click "Save". + * You will then need to hover over the 'OS / Patch OS to latest' node and edit the node by clicking on the pencil icon. Scroll down to the "Convergence" drop-down and select 'All'. + * Continue with clicking "Next", "Next" and "Save". + +Your workflow should resemble the following: + +![workflow final](images/2-patching-aap2-workflow-final.png) + +Save and exit the workflow template editor by clicking on "Save" on the top right. + +#### 3\. Logging into Satellite + +- Use a web browser on your computer to access the Satellite UI via the link found in the Environment information. + +![Satellite login](images/2-patching-aap2-Satellite-login.png) + +* Once logged in to Satellite, you'll be able to see the dashboard. + +![Satellite dashboard](images/2-patching-aap2-Satellite-dashboard.png) + +#### 4\. Exploring the Satellite host configuration + +* In the Satellite UI on the left menu pane, hover over 'Hosts' and select 'Content Hosts'. + * Observe the multiple security, bug fix, enhancements and package updates available for each server, which will vary depending on the date of when the workshop takes place. + * Further, take note of the life cycle environment: RHEL7_Dev. + +![Satellite content hosts](images/2-patching-aap2-Satellite-contenthosts.png) + +* In the Satellite UI on the left menu pane, navigate to 'Content' and select 'Content Views'. + * Since the servers that we are working with are RHEL7 select the 'RHEL7' content view. + * We may need to publish a new content view version, however, we set that up as part of our workflow! + * Note: your content view version may differ from this example, that is OK + +![Satellite RHEL7 CV](images/2-patching-aap-Satellite-CV-RHEL7.png) + +* In the Satellite UI on the left menu pane, navigate to Hosts > All Hosts and select node1.example.com. + * Select the "content" tab under Details. + * Notice the Installable errata; this is your number of errata before running your patch workflow. + +#### 5\. Navigate back to Ansible Automation Platform and launch workflow job + +* Click on Templates to locate the 'SATELLITE / Patching Workflow' template. + * You can either click on the rocketship to the right of the template or select the template and select LAUNCH. (they do the same thing). +* Observe the job kicking off in Ansible. + * You need to wait for this workflow to complete before moving on to the next step. + * This workflow should take ~5 mins to complete. + * Watch the green boxes expanding and contracting in each of the workflow nodes. + * The node box will go green when the step is complete - you can also hover over a workflow node to see a status. + +![AAP Workflow in progress](images/2-patching-aap2-workflow-in-progress.png) + +#### 6\. Navigate back to Satellite to examine automation effects + +* In the Satellite UI on the left menu pane, navigate to 'Content' then 'Content Views' and select RHEL7. + * Notice the new content view version. +* In the Satellite UI on the left menu pane, navigate to Hosts > All Hosts and select node1.example.com. + * Select the 'content' tab under Details. + * Notice that the Installable errata has decreased. + * This indicates that we have applied our updates. + +![errata reduced](images/2-patching-aap2-Satellite-reduced-installable-errata.png) + +* You may notice that not all issues are remediated. + * This is to showcase that you can exclude updates based on type. + * In this case we're not pushing out updates for kernel changes. + * Of course this can be configurable through use of the exclude definition for ```ansible.builtin.yum``` module in the server_patch.yml playbook. + +![kernel patches excluded](images/2-patching-aap2-server-patching-kernel-exclude.png) + +#### 7\. End of Exercise + +- You have finished the exercise. +- Continue to [Exercise 3: CentOS conversion to RHEL](../3-convert2rhel/README.md), OR [Return to the main workshop page](../README.md) diff --git a/exercises/rhdp_auto_satellite/2-patching/images/2-patching-aap-Satellite-CV-RHEL7.png b/exercises/rhdp_auto_satellite/2-patching/images/2-patching-aap-Satellite-CV-RHEL7.png new file mode 100644 index 000000000..12287f5d4 Binary files /dev/null and b/exercises/rhdp_auto_satellite/2-patching/images/2-patching-aap-Satellite-CV-RHEL7.png differ diff --git a/exercises/rhdp_auto_satellite/2-patching/images/2-patching-aap2-Satellite-contenthosts.png b/exercises/rhdp_auto_satellite/2-patching/images/2-patching-aap2-Satellite-contenthosts.png new file mode 100644 index 000000000..008a85f93 Binary files /dev/null and b/exercises/rhdp_auto_satellite/2-patching/images/2-patching-aap2-Satellite-contenthosts.png differ diff --git a/exercises/rhdp_auto_satellite/2-patching/images/2-patching-aap2-Satellite-dashboard.png b/exercises/rhdp_auto_satellite/2-patching/images/2-patching-aap2-Satellite-dashboard.png new file mode 100644 index 000000000..fe3481a72 Binary files /dev/null and b/exercises/rhdp_auto_satellite/2-patching/images/2-patching-aap2-Satellite-dashboard.png differ diff --git a/exercises/rhdp_auto_satellite/2-patching/images/2-patching-aap2-Satellite-login.png b/exercises/rhdp_auto_satellite/2-patching/images/2-patching-aap2-Satellite-login.png new file mode 100644 index 000000000..252aba1de Binary files /dev/null and b/exercises/rhdp_auto_satellite/2-patching/images/2-patching-aap2-Satellite-login.png differ diff --git a/exercises/rhdp_auto_satellite/2-patching/images/2-patching-aap2-Satellite-reduced-installable-errata.png b/exercises/rhdp_auto_satellite/2-patching/images/2-patching-aap2-Satellite-reduced-installable-errata.png new file mode 100644 index 000000000..6fced3078 Binary files /dev/null and b/exercises/rhdp_auto_satellite/2-patching/images/2-patching-aap2-Satellite-reduced-installable-errata.png differ diff --git a/exercises/rhdp_auto_satellite/2-patching/images/2-patching-aap2-dashboard.png b/exercises/rhdp_auto_satellite/2-patching/images/2-patching-aap2-dashboard.png new file mode 100644 index 000000000..8923ebcde Binary files /dev/null and b/exercises/rhdp_auto_satellite/2-patching/images/2-patching-aap2-dashboard.png differ diff --git a/exercises/rhdp_auto_satellite/2-patching/images/2-patching-aap2-login.png b/exercises/rhdp_auto_satellite/2-patching/images/2-patching-aap2-login.png new file mode 100644 index 000000000..24bc6f3bd Binary files /dev/null and b/exercises/rhdp_auto_satellite/2-patching/images/2-patching-aap2-login.png differ diff --git a/exercises/rhdp_auto_satellite/2-patching/images/2-patching-aap2-server-patching-kernel-exclude.png b/exercises/rhdp_auto_satellite/2-patching/images/2-patching-aap2-server-patching-kernel-exclude.png new file mode 100644 index 000000000..b23d0b934 Binary files /dev/null and b/exercises/rhdp_auto_satellite/2-patching/images/2-patching-aap2-server-patching-kernel-exclude.png differ diff --git a/exercises/rhdp_auto_satellite/2-patching/images/2-patching-aap2-workflow-factscan.png b/exercises/rhdp_auto_satellite/2-patching/images/2-patching-aap2-workflow-factscan.png new file mode 100644 index 000000000..c1faf0e30 Binary files /dev/null and b/exercises/rhdp_auto_satellite/2-patching/images/2-patching-aap2-workflow-factscan.png differ diff --git a/exercises/rhdp_auto_satellite/2-patching/images/2-patching-aap2-workflow-final.png b/exercises/rhdp_auto_satellite/2-patching/images/2-patching-aap2-workflow-final.png new file mode 100644 index 000000000..6983b1595 Binary files /dev/null and b/exercises/rhdp_auto_satellite/2-patching/images/2-patching-aap2-workflow-final.png differ diff --git a/exercises/rhdp_auto_satellite/2-patching/images/2-patching-aap2-workflow-in-progress.png b/exercises/rhdp_auto_satellite/2-patching/images/2-patching-aap2-workflow-in-progress.png new file mode 100644 index 000000000..84fa45d53 Binary files /dev/null and b/exercises/rhdp_auto_satellite/2-patching/images/2-patching-aap2-workflow-in-progress.png differ diff --git a/exercises/rhdp_auto_satellite/2-patching/images/2-patching-aap2-workflow-inventory-source.png b/exercises/rhdp_auto_satellite/2-patching/images/2-patching-aap2-workflow-inventory-source.png new file mode 100644 index 000000000..15e9050e6 Binary files /dev/null and b/exercises/rhdp_auto_satellite/2-patching/images/2-patching-aap2-workflow-inventory-source.png differ diff --git a/exercises/rhdp_auto_satellite/2-patching/images/2-patching-aap2-workflow-patch-latest.png b/exercises/rhdp_auto_satellite/2-patching/images/2-patching-aap2-workflow-patch-latest.png new file mode 100644 index 000000000..3f10215cf Binary files /dev/null and b/exercises/rhdp_auto_satellite/2-patching/images/2-patching-aap2-workflow-patch-latest.png differ diff --git a/exercises/rhdp_auto_satellite/2-patching/images/2-patching-aap2-workflow-publish-CV-preview.png b/exercises/rhdp_auto_satellite/2-patching/images/2-patching-aap2-workflow-publish-CV-preview.png new file mode 100644 index 000000000..1c2e46d24 Binary files /dev/null and b/exercises/rhdp_auto_satellite/2-patching/images/2-patching-aap2-workflow-publish-CV-preview.png differ diff --git a/exercises/rhdp_auto_satellite/2-patching/images/2-patching-aap2-workflow-start.png b/exercises/rhdp_auto_satellite/2-patching/images/2-patching-aap2-workflow-start.png new file mode 100644 index 000000000..533e34c4e Binary files /dev/null and b/exercises/rhdp_auto_satellite/2-patching/images/2-patching-aap2-workflow-start.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.1-setup/README.md b/exercises/rhdp_auto_satellite/3-convert2rhel/1.1-setup/README.md new file mode 100644 index 000000000..7e588de6e --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/1.1-setup/README.md @@ -0,0 +1,127 @@ +# Workshop Exercise - Your Lab Environment + +## Table of Contents + +- [Workshop Exercise - Your Lab Environment](#workshop-exercise---your-lab-environment) + - [Table of Contents](#table-of-contents) + - [Objectives](#objectives) + - [Guide](#guide) + - [Your Lab Environment](#your-lab-environment) + - [Step 1 - Access the Environment](#step-1---access-the-environment) + - [Step 2 - Open a Terminal Session](#step-2---open-a-terminal-session) + - [Step 3 - Access the AAP Web UI](#step-3---access-the-aap-web-ui) + - [Step 4 - Access the Satellite Web UI](#step-4---access-the-satellite-web-ui) + - [Step 5 - Access the RHEL Web Console](#step-5---access-the-centos-web-console) + - [Step 6 - Challenge Labs](#step-6---challenge-labs) + - [Conclusion](#conclusion) + +## Objectives + +* Understand the lab topology and how to access the environment +* Understand how to perform the workshop exercises +* Understand challenge labs + +## Guide + +### Your Lab Environment + +The workshop is provisioned with a pre-configured lab environment. You will have access to a host deployed with Ansible Automation Platform (AAP) which you will use to control the playbook and workflow jobs that automate the CentOS conversion workflow steps. You will also have access to three CentOS hosts. These are the hosts where we will be converting the CentOS operating system (OS) to Red Hat Enterprise Linux. + +| Role | Inventory name | +| ------------------------------------| ---------------| +| Automation controller | ansible-1 | +| Satellite Server | satellite | +| Managed Host 1 - RHEL | node1 | +| Managed Host 2 - RHEL | node2 | +| Managed Host 3 - RHEL | node3 | +| Managed Host 4 - CentOS/OracleLinux | node4 | +| Managed Host 5 - CentOS/OracleLinux | node5 | +| Managed Host 6 - CentOS/OracleLinux | node6 | + +### Step 1 - Access the Environment + +We will use Visual Studio Code (VS Code) as it provides a convenient and intuitive way to use a web browser to edit files and access terminal sessions. If you are a command line hero, direct SSH access is available if VS Code is not to your liking. There is a short YouTube video to explain if you need additional clarity: Ansible Workshops - Accessing your workbench environment. + +- You can open VS Code in your web browser using the "Console URL" link under "Visual Studio Code" on the workshop landing page. The password is provided below the link. For example: + + ![Example link to VS Code WebUI](images/vscode_link.png) + +- After opening the link, type in the provided password to access your instance of VS Code. + +> **Note** +> +> A welcome wizard may appear to guide you through configuring your VS Code user experience. This is optional as the default settings will work fine for this workshop. Feel free to step though the wizard to explore the VS code bells and whistles or you may just skip it. + +### Step 2 - Open a Terminal Session + +Terminal sessions provide access to the OS commands and utilities that will help us understand what's going on "behind the curtain" when the CentOS conversion automation is doing its thing. + +- Use VS Code to open a terminal session. For example: + + ![Example of how to open a terminal session in VS Code](images/new_term.svg) + +- This terminal session will be running on the AAP control host `ansible-1`. Next, use the `ssh` command to login to one of your CentOS hosts. Finally, use the highlighted commands confirm the CentOS version and kernel version installed. + + For example: + + ![Example ssh login to CentOS app host](images/ssh_login.png) + +- In the example above, the command `ssh node4` connects us to a new session on the node4 host. Then the commands `cat /etc/redhat-release` and `uname -r` are used to output the OS release information `CentOS Linux release 7.9.2009 (Core)` and kernel version `3.10.0-1160.102.1.el7.x86_64` from that host. + +### Step 3 - Access the AAP Web UI + +The AAP Web UI is where we will go to submit and check the status of the Ansible playbook jobs we will use to automate the CentOS conversion workflow. + +- Let's open the AAP Web UI in a new web browser tab using the "Console" link under "Red Hat Ansible Automation Controller" on the workshop launch page. For example: + + ![Example link to AAP Web UI](images/aap_link.png) + +- Enter the username `admin` and the password provided. This will bring you to your AAP Web UI dashboard like the example below: + + ![Example AAP Web UI dashboard](images/aap_console_example.svg) + +- We will learn more about how to use the AAP Web UI in the next exercise. + +### Step 4 - Access the Satellite Web UI + +The Satellite Web UI is where we will go to review the Lifecycle Environments, Content Views and Activation Keys configured on the Satellite, as well as tracking the status of the CentOS hosts as we proceed through the conversion workflow through to when they become RHEL hosts. + +- Let's open the Satellite Web UI in a new web browser tab using the "Console" link under "Red Hat Satellite" on the workshop launch page. For example: + + ![Example link to Satellite Web UI](images/satellite_link.png) + +- Enter the username `admin` and the password provided. This will bring you to your Satellite Web UI dashboard like the example below: + + ![Example Satellite Web UI dashboard](images/satellite_console_example.png) + +### Step 5 - Access the RHEL Web Console + +We will use the RHEL Web Console to review the results of the Convert2RHEL pre-conversion analysis reports we generate for our three-tier app servers. + +- Open a new web browser tab using the link under "RHEL Web Console Interactive Server Admin Interface" on the workshop launch page. For example: + + ![Example link to RHEL Web Console](images/cockpit_link.png) + +- Enter the username `student` and the password provided. This will bring you to a RHEL Web Console Overview page like the example below: + + ![Example RHEL Web Console](images/cockpit_example.png) + +- We will revisit the RHEL Web Console when we are ready to review our pre-conversion reports in an upcoming exercise. + +### Step 6 - Challenge Labs + +You will soon discover that many exercises in the workshop come with a "Challenge Lab" step. These labs are meant to give you a small task to solve using what you have learned so far. The solution of the task is shown underneath a warning sign. + +## Conclusion + +In this exercise, we learned about the lab environment we will be using to continue through the workshop exercises. We verified that we are able to use VS Code in our web browser and from there we can open terminal sessions. We verified access to the AAP Web UI which will be the "self-service portal" we use to perform the next steps of the CentOS conversion automation workflow. We also made sure we are able to access the Satellite Web UI where we can review the repositories providing the packages for the CentOS conversion automation workflow, as well as the status of the hosts themselves. Finally, we connected to the RHEL Web Console where we will soon be reviewing pre-conversion analysis reports. + +Use the link below to move on the the next exercise. + +--- + +**Navigation** + +[Next Exercise](../1.2-three-tier-app/README.md) + +[Home](../README.md) diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.1-setup/images/aap_console_example.svg b/exercises/rhdp_auto_satellite/3-convert2rhel/1.1-setup/images/aap_console_example.svg new file mode 100644 index 000000000..c97421583 --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/1.1-setup/images/aap_console_example.svg @@ -0,0 +1,2931 @@ + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.1-setup/images/aap_link.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.1-setup/images/aap_link.png new file mode 100644 index 000000000..219d48535 Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.1-setup/images/aap_link.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.1-setup/images/cockpit_example.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.1-setup/images/cockpit_example.png new file mode 100644 index 000000000..154c57259 Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.1-setup/images/cockpit_example.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.1-setup/images/cockpit_example.svg b/exercises/rhdp_auto_satellite/3-convert2rhel/1.1-setup/images/cockpit_example.svg new file mode 100644 index 000000000..426c5977f --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/1.1-setup/images/cockpit_example.svg @@ -0,0 +1,4950 @@ + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.1-setup/images/cockpit_link.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.1-setup/images/cockpit_link.png new file mode 100644 index 000000000..4fd63ec0f Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.1-setup/images/cockpit_link.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.1-setup/images/new_term.svg b/exercises/rhdp_auto_satellite/3-convert2rhel/1.1-setup/images/new_term.svg new file mode 100644 index 000000000..e6eb04ecc --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/1.1-setup/images/new_term.svg @@ -0,0 +1,7861 @@ + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.1-setup/images/satellite_console_example.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.1-setup/images/satellite_console_example.png new file mode 100644 index 000000000..6ee3030e6 Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.1-setup/images/satellite_console_example.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.1-setup/images/satellite_link.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.1-setup/images/satellite_link.png new file mode 100644 index 000000000..bb35ac651 Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.1-setup/images/satellite_link.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.1-setup/images/ssh_login.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.1-setup/images/ssh_login.png new file mode 100644 index 000000000..a6da142d4 Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.1-setup/images/ssh_login.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.1-setup/images/ssh_login.svg b/exercises/rhdp_auto_satellite/3-convert2rhel/1.1-setup/images/ssh_login.svg new file mode 100644 index 000000000..1091eb4fd --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/1.1-setup/images/ssh_login.svg @@ -0,0 +1,70 @@ + + + + + + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.1-setup/images/vscode_link.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.1-setup/images/vscode_link.png new file mode 100644 index 000000000..6808d4969 Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.1-setup/images/vscode_link.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/README.md b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/README.md new file mode 100644 index 000000000..b125b1a0b --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/README.md @@ -0,0 +1,215 @@ +# Workshop Exercise - Three Tier App + +## Table of Contents + +- [Workshop Exercise - Three Tier App](#workshop-exercise---three-tier-app) + - [Table of Contents](#table-of-contents) + - [Objectives](#objectives) + - [Guide](#guide) + - [Three Tier App](#three-tier-app) + - [Step 1 - Set Instance Tags](#step-1---set-instance-tags) + - [Step 2 - Update Ansible Inventory](#step-2---update-ansible-inventory) + - [Step 3 - Install Three Tier Application](#step-3---install-three-tier-application) + - [Step 4 - Smoke Test Three Tier Application](#step-4---open-a-terminal-session) + - [Conclusion](#conclusion) + +## Objectives + +* Install a three tier application stack to provide example of application/workload functionality testing pre/post conversion. + +## Guide + +### Three Tier App + +This use-case will focus on conversion from CentOS (though this could be another RHEL derivitive) to RHEL while maintaining a 3 tier application stack (do no harm). We will utilize an additional project in Ansible Automation Platform, "Three Tier App / Prod", which will allow us to install a three tier application stack, consisting of HAProxy, Tomcat, and PostgreSQL, across the three CentOS nodes. Additionally, the project also provides a means to test/verify functionality of the application components, which we will perform before and after CentOS to RHEL conversions. + +| Role | Inventory name | +| ---------------------------------------| ---------------| +| Automation controller | ansible-1 | +| Satellite Server | satellite | +| CentOS/OracleLinux Host 4 - HAProxy | node4 | +| CentOS/OracleLinux Host 5 - Tomcat | node5 | +| CentOS/OracleLinux Host 6 - PostgreSQL | node6 | + +| **A Note about using Satellite vs. Ansible Automation Platform for this...**
| +| ------------- | +| Out of the box, Satellite 6 supports [RHEL systems roles](https://access.redhat.com/articles/3050101) (a collection of Ansible Roles) for a limited set of administration tasks. Satellite can be used to do OS conversions and upgrades, however an Ansible Automation Platform Subscription is required to execute complicated OS conversions and upgrades that require logic to meet up-time requirements. Using these two solutions together ensures you have the best tool for the job for:
- Content Management (Satellite)
- OS Patching & Standardized Operating Environments (Satellite)
- Provisioning: OS, Infra Services and Applications/Other (Satellite and/or Ansible Automation Platform)
- Configuration of Infra and Apps (Ansible Automation Platform)

Reference: [Converting CentOS to RHEL with Red Hat Satellite 6](https://www.redhat.com/en/blog/steps-converting-centos-linux-convert2rhel-and-red-hat-satellite) and [Leapp Upgrade with Satellite 6](https://www.redhat.com/en/blog/leapp-upgrade-using-red-hat-satellite-6)| + +### Step 1 - Set Instance Tags + +- Return to the AAP Web UI browser tab you opened in step 3 of the previous exercise. Navigate to Resources > Templates by clicking on "Templates" under the "Resources" group in the navigation menu. This will bring up a list of job templates that can be used to run playbook jobs on target hosts: + + ![Job templates filtered list](images/set_instance_tags_01.png) + +- In the filter box enter **Set instance** and click the magnifying glass. + + ![Access job template details](images/set_instance_tags_02.png) + +- Click on the job template named **EC2 / Set instance tag - CentOS** to view the job template details. ( Click on `EC2 / Set instance tag - OracleLinux7` if you have Oracle Linux nodes) + + ![View job template details](images/set_instance_tags_03.png) + +- Click on the Source variable section expansion icon to view the entire variable definition for the job template. + + ![Expanded job template variables](images/set_instance_tags_04.png) + +- Note the **group_tag_map**...each node is being mapped to a group name which corresponds to the particular application tier role that the node is to serve. Looking at the Ansible playbook that corresonds to this job template: + + ![Ansible playbook for group tags](images/set_instance_tags_06.png) + +- We can see that the **group_tag_map** dictionary is looped through, selecting a particular instace via the *resource: "{{ host_ec2_instance_id[item.key] }}"* filter and then setting the "AnsibleGroup" tag via *AnsibleGroup: "{{ item.value }}"* + +- Additionally, the **app_stack_name** tag is set to designate that each node is a member of the same application stack. + +- Click "Done" and then click "Launch" on the **EC2 / Set instance tag - CentOS** job template screen. + + ![View job run details](images/set_instance_tags_05.png) + +- The job run should complete in 8 to 10 seconds. Note the item --> key, value output listing, which corresponds to the instance tag "AnsibleGroup" that is being set respectively on each instance. + +### Step 2 - Update Ansible Inventory + +- Now that we have application tier group tags set, we can update the Ansible inventory to include inventory groups associated with our application stack tiers. However, before we do, let's review how the Ansible inventory update works behind the scenes. + + ![Controller inventories](images/update_controller_inventory_01.png) + +- On the left menu bar, navigate to Resources > Inventories by clicking on "Inventories" under the "Resources" group in the navigation menu, then click on "EC2 Dynamic Inventory". + + ![Controller inventories details](images/update_controller_inventory_02.png) + +- Initially, the **EC2 Dynamic Inventory** inventory details tab will be displayed. Click on the "Sources" tab. + + ![Controller inventories sources](images/update_controller_inventory_03.png) + +- The **EC2 Dynamic Inventory** inventory sources tab will be displayed. Click on the "CentOS7 Development" inventory source. + + ![Controller inventories details expand](images/update_controller_inventory_04.png) + +- The **CentOS7 Development** inventory source **Details** view will be displayed. Click on the variables expansion button on the side right. + + ![Controller inventories keyed_groups](images/update_controller_inventory_05.png) + +- Scroll down the source variables section until you see "keyed_groups". [Keyed groups](https://docs.ansible.com/ansible/latest/plugins/inventory.html#:~:text=with%20the%20constructed-,keyed_groups,-option.%20The%20option) are where you can define dynamic inventory groups based on instance tags. In this case, when a dynamic inventory generation event is executed, if the EC2 inventory plugin comes across an instance with the "app_stack_name" and "AnsibleGroup" tags, then it will create an inventory group with the name beginning with the value assigned to the "app_stack_name" tag, an "_" (underscore) and then the value assigned to the "AnsibleGroup" tag...so in this case, if the "app_stack_name" tag is currently set to "stack02" and the "AnsibleGroup" tag is set to "appdbs", then the inventory group "stack02_appdbs" will be created (or confirmed if already existing) and that instance will be assigned to the group. + +- Click on "Done" in the Source variables exapanded view. + + ![Controller inventories group](images/update_controller_inventory_sync.png) + +- While still on the **CentOS7 Development** Details view, click on "Sync". The sync should complete in a few seconds. Now, let's verify our dynamic inventory group. + + ![Controller inventories groups](images/update_controller_inventory_06.png) + +- In the menu bar on the left, select "Inventories" --> "EC2 Dynamic Inventories". Once the **EC2 Dynamic Inventory** details screen is displayed, click on the "Groups" tab. + + ![Controller inventories group](images/update_controller_inventory_07.png) + +- The **Groups** defined for the **EC2 Dynamic Inventory** screen is displayed. Scroll down and click on the `stack02_appdbs` group. + + ![Controller inventories group](images/update_controller_inventory_08.png) + +- Initially, the "Details" tab will display. Click on the "Hosts" tab and we will see that `node6.example.com` is present in the "stack02_appdbs" group. Remember earlier, when we reviewed the variables section of the **EC2 / Set instance tag - CentOS** job template? The **app_stack_name** and **group_tag_map** match up: + +``` + "group_tag_map": { + "node4.example.com": "frontends", + "node5.example.com": "apps", + "node6.example.com": "appdbs" + }, + "app_stack_name": "stack02" +``` + +- Rather than having to navigate to **Inventories > EC2 Dynamic Inventory > Sources > _inventory_source_name_** and clicking "Sync" to initiate sync events, we have put together a job template with surveys and associated Ansible playbook that provides a more convenient method to utilize for this task. Let's review: + +- Navigate to Resources > Templates by clicking on "Templates" under the "Resources" group in the navigation menu. This will bring up a list of job templates that can be used to run playbook jobs on target hosts: + + ![Job templates listed on AAP Web UI](images/update_inventory_01.png) + +- Click ![launch](images/convert2rhel-aap2-launch.png) to the right of **CONTROLLER / Update inventories via dynamic sources**. + + ![Inventory update job survey prompt on AAP Web UI](images/update_inventory_02.png) + +- Next we see the job template survey prompt. A survey is a customizable set of prompts that can be configured from the Survey tab of the job template. For this job template, the survey allows for choosing which part of the inventory will be updated. For "Select inventory to update" choose "CentOS7" from the drop-down and for "Choose Environment" select "Dev" and click the "Next" button. + + ![Inventory update job launch details on AAP Web UI](images/update_inventory_03.png) + +- This will bring you to a preview of the selected job options and variable settings. Click "Launch". + + ![Inventory update job output on AAP Web UI](images/update_inventory_04.png) + +- Survey the job output details...this job run only takes about 5 to 6 seconds to complete. + +### Step 3 - Install Three Tier Application + +- In the AAP Web UI, navigate to Resources > Templates by clicking on "Templates" under the "Resources" group in the navigation menu. This will bring up a list of job templates that can be used to run playbook jobs on target hosts: + + ![Job templates listed on AAP Web UI](images/aap_templates.png) + +- Click ![launch](images/convert2rhel-aap2-launch.png) to the right of **CONVERT2RHEL / 98 - Three Tier App deployment** to launch the job. + +![3tier-install-stack](images/convert2rhel-3tier-install_01.png) + +- For `Choose application stack name`, remember earlier in the inventory tags section, "app_stack_name" was set to "stack02", so we choose "stack02" from the drop down selection. Then click **Next** then on the preview screen click **Launch**. + +This will take ~2 minutes to complete. + +![3tier-install](images/convert2rhel-3tier-install_02.png) + +### Step 4 - Smoke Test Three Tier Application + +Now that our three tier application is installed, let's cover the application stack layout. + +| Host | Component | Port | +| ------------------|------------|-------| +| node4.example.com | HAProxy | 80 | +| node5.example.com | Tomcat | 8080 | +| node6.example.com | PostgreSQL | 5432 | + +node4.example.com proxies incoming requests on port 80 and forwards them to port 8080 on node5.example.com, where Tomcat is running a simple java application that, upon an incoming request to the servlet, creates a table in the PostgreSQL database on node6.example.com, with the table name being constructed from the date and time of the request. For example: + +`Table "06-06-2024-18-00" has been created!` + +If you'd like to manually test the application stack, you can run the following commands by switching your browser to Visual Studio Code terminal, then from `ansible-1` prompt: + +```curl http://node4.example.com``` + +Remember, node4.example.com is a proxy, so the above command displays the default page on node5.example.com + +```curl http://node4.example.com/3ta/connectordbbservlet?``` + +The above will make a request to the Tomcat servlet, where the database table described earlier will be created on the PostgreSQL database on node6.example.com. Without writing out a complete PostgreSQL command cheat sheet, if desired, you can follow the following example command line trail (commands outlined in red rectangles) and check out the PostgreSQL system yourself: + +![3tier-db-check](images/convert2rhel-3tier-db-check.png) + +- Now that we understand the application stack layout, rather than having to use the command line and checking all of the various components manually, let's look at how we can test application stack functionality...via automation! + + ![Job templates listed on AAP Web UI 2](images/aap_templates_2.png) + +- Use the side pane menu on the left to select **Templates**. + +- Click ![launch](images/convert2rhel-aap2-launch.png) to the right of **CONVERT2RHEL / 99 - Three Tier App smoke test** to launch the application test job. + + ![3tier-smoke-test-select](images/convert2rhel-3tier-smoke-select.png) + +- For `Choose application stack name`, remember earlier in the inventory tags section, "app_stack_name" was set to "stack02", so we choose "stack02" from the drop down selection. Then click **Next**, then on the preview screen click **Launch**. + +This should take ~15 seconds to complete. + + ![3tier-smoke-test-output](images/convert2rhel-3tier-smoke-output.png) + +- The Ansible playbook utilized by this job template makes a request to the Tomcat servlet via the HAproxy node and records the name of the database table that is presented. The database is then connected to and verifies that in fact a table with the recorded name is present in the database. By utilizing current time and date stamps, we are demonstrating that we are truly working with live systems in real time. + +- If the job template completes successfully, then we have verified that our three tier application stack is functioning correctly. If it fails, we know that something with the application stack is malfunctioning and we can begin the debugging process to determine where the problem resides. + +## Conclusion + +In this exercise, we learned about how to set instance tags to assist with identifying instances. We then turned to looking into how Ansible Automation Platform dynamic inventory sources can be utilized to generate various host groups with a given inventory. We followed that with performing an automated installation of an example three tier application stack. Finally, we verified the three tier application stack functionality via an automated application smoke test. + +Use the link below to move on the the next exercise. + +--- + +**Navigation** + +[Previous Exercise](../1.1-setup/README.md) - [Next Exercise](../1.3-analysis/README.md) + +[Home](../README.md) diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/aap_console_example.svg b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/aap_console_example.svg new file mode 100644 index 000000000..c97421583 --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/aap_console_example.svg @@ -0,0 +1,2931 @@ + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/aap_link.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/aap_link.png new file mode 100644 index 000000000..2810a51be Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/aap_link.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/aap_templates.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/aap_templates.png new file mode 100644 index 000000000..7c43fc5e4 Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/aap_templates.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/aap_templates_2.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/aap_templates_2.png new file mode 100644 index 000000000..bc86ec7eb Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/aap_templates_2.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/convert2rhel-3tier-db-check.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/convert2rhel-3tier-db-check.png new file mode 100644 index 000000000..07ff9d6b6 Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/convert2rhel-3tier-db-check.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/convert2rhel-3tier-install_01.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/convert2rhel-3tier-install_01.png new file mode 100644 index 000000000..4aa361cdd Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/convert2rhel-3tier-install_01.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/convert2rhel-3tier-install_02.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/convert2rhel-3tier-install_02.png new file mode 100644 index 000000000..4a4dfdfa0 Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/convert2rhel-3tier-install_02.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/convert2rhel-3tier-smoke-output.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/convert2rhel-3tier-smoke-output.png new file mode 100644 index 000000000..5d6314814 Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/convert2rhel-3tier-smoke-output.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/convert2rhel-3tier-smoke-select.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/convert2rhel-3tier-smoke-select.png new file mode 100644 index 000000000..36a01d1ff Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/convert2rhel-3tier-smoke-select.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/convert2rhel-aap2-launch.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/convert2rhel-aap2-launch.png new file mode 100644 index 000000000..7246c1d95 Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/convert2rhel-aap2-launch.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/set_instance_tags_01.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/set_instance_tags_01.png new file mode 100644 index 000000000..7e9634898 Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/set_instance_tags_01.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/set_instance_tags_02.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/set_instance_tags_02.png new file mode 100644 index 000000000..61af881b6 Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/set_instance_tags_02.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/set_instance_tags_03.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/set_instance_tags_03.png new file mode 100644 index 000000000..1ccb45a40 Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/set_instance_tags_03.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/set_instance_tags_04.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/set_instance_tags_04.png new file mode 100644 index 000000000..a647f925a Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/set_instance_tags_04.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/set_instance_tags_05.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/set_instance_tags_05.png new file mode 100644 index 000000000..2351a3b2f Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/set_instance_tags_05.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/set_instance_tags_06.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/set_instance_tags_06.png new file mode 100644 index 000000000..31feb3a4b Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/set_instance_tags_06.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/update_controller_inventory_01.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/update_controller_inventory_01.png new file mode 100644 index 000000000..a40d8534c Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/update_controller_inventory_01.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/update_controller_inventory_02.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/update_controller_inventory_02.png new file mode 100644 index 000000000..727fd780c Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/update_controller_inventory_02.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/update_controller_inventory_03.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/update_controller_inventory_03.png new file mode 100644 index 000000000..ac61c305a Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/update_controller_inventory_03.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/update_controller_inventory_04.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/update_controller_inventory_04.png new file mode 100644 index 000000000..598f9c00c Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/update_controller_inventory_04.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/update_controller_inventory_05.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/update_controller_inventory_05.png new file mode 100644 index 000000000..02250c2ea Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/update_controller_inventory_05.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/update_controller_inventory_06.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/update_controller_inventory_06.png new file mode 100644 index 000000000..7f5774c19 Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/update_controller_inventory_06.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/update_controller_inventory_07.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/update_controller_inventory_07.png new file mode 100644 index 000000000..deca61b21 Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/update_controller_inventory_07.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/update_controller_inventory_08.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/update_controller_inventory_08.png new file mode 100644 index 000000000..0c1bd646a Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/update_controller_inventory_08.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/update_controller_inventory_sync.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/update_controller_inventory_sync.png new file mode 100644 index 000000000..002a60782 Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/update_controller_inventory_sync.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/update_inventory_01.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/update_inventory_01.png new file mode 100644 index 000000000..55396084f Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/update_inventory_01.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/update_inventory_02.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/update_inventory_02.png new file mode 100644 index 000000000..0c82b1668 Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/update_inventory_02.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/update_inventory_03.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/update_inventory_03.png new file mode 100644 index 000000000..73ef90c54 Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/update_inventory_03.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/update_inventory_04.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/update_inventory_04.png new file mode 100644 index 000000000..e2f964e99 Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.2-three-tier-app/images/update_inventory_04.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/README.md b/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/README.md new file mode 100644 index 000000000..24e5df6d9 --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/README.md @@ -0,0 +1,201 @@ +# Workshop Exercise - Run Pre-conversion Analysis Jobs + +## Table of Contents + +- [Workshop Exercise - Run Pre-conversion Analysis Jobs](#workshop-exercise---run-pre-conversion-jobs) + - [Table of Contents](#table-of-contents) + - [Objectives](#objectives) + - [Guide](#guide) + - [Step 1 - CentOS Conversion Automation Workflow](#step-1---centos-conversion-automation-workflow) + - [Analysis](#analysis) + - [Convert](#convert) + - [Commit](#commit) + - [Let's Get Started](#lets-get-started) + - [Step 2 - Patch OS to latest package versions](#step-2---patch-os-to-latest-package-versions) + - [Step 3 - Use AAP to Launch an Analysis Playbook Job](#step-3---use-aap-to-launch-an-analysis-playbook-job) + - [Step 4 - Review the Playbook Job Output](#step-3---review-the-playbook-job-output) + - [Step 5 - Challenge Lab: Analysis Playbook](#step-4---challenge-lab-analysis-playbook) + - [Conclusion](#conclusion) + +## Objectives + +* Understand the end-to-end CentOS conversion workflow +* Understand how to use AAP job templates to run Ansible playbooks +* Run the pre-conversion analysis jobs + +## Guide + +### Step 1 - CentOS Conversion Automation Workflow + +Red Hat provides the Convert2RHEL utility, a tool to convert RHEL-like systems to their RHEL counterparts. The [Convert2RHEL documentation](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/converting_from_an_rpm-based_linux_distribution_to_rhel/index) guides users on how to use the Convert2RHEL utility to manually convert a RHEL host. This is fine if there only a few CentOS hosts to convert, but what if you are a large enterprise with tens, hundreds, or even thousands of CentOS hosts? The manual process does not scale. Using automation, the end-to-end process for converting a RHEL host is reduced to a matter of days and the total downtime required for the actual conversion is measured in hours or less. + +Our CentOS conversion automation approach follows a workflow with three phases: + +![Three phase workflow: Analysis, Convert, Commit](images/conversion-workflow.svg) + +> **Note** +> +> The ![arrow pointing down at server](images/playbook_icon.svg) icon indicates workflow steps that are automated by Ansible playbooks. + +#### Analysis + +During the analysis phase, no changes are made yet. When the analysis playbook is executed, it uses the Convert2RHEL utility to scan the host for issues or blockers that may prevent a successful conversion. Then it generates a report listing any potential risks found. The report also includes recommended actions that should be followed to reduce the likelihood of the reported issues impacting the conversion. If any recommended remediation actions are performed, the analysis scan should be run again to verify the risks are resolved. This iteration continues until everyone reviewing the report is comfortable that any remaining findings are acceptable. + + + +#### Convert + +After the analysis phase is done and the report indicates acceptable risk, a maintenance window can be scheduled and the conversion phase can begin. It is during this phase that the conversion playbooks are executed using a workflow job template. The first playbook creates a snapshot that can be used for rolling back if anything goes wrong with the conversion. After the snapshot is created, the second playbook uses the [convert role from the infra.convert2rhel Ansible collection](https://github.com/redhat-cop/infra.convert2rhel/tree/main/roles/convert), where the automation is a convenience wrapper around the Convert2RHEL utility, to perform the operation where the CentOS host is converted to RHEL. The host will not be available for login or application access during the conversion. When the conversion is finished, the host will reboot under the newly converted RHEL system. Now the ops and app teams can assess if the conversion was successful by verifying all application services are working as expected. + +#### Commit + +If there are any application impacts discovered that can't be easily corrected within the scheduled maintenance window, the decision can be made to undo the conversion by rolling back the snapshot. This will revert all changes and return the host back to the previous CentOS version. However, if there are no issues found, the commit phase begins. During the commit phase, the host can be returned to normal operation while keeping the snapshot just in case any issues are uncovered later. +> **ⓘ** This is LVM specific: However, while the snapshots are kept, regular disk writes to volume groups will continue to consume the free space allocated to the snapshots. The amount of time this takes will depend on the amount of free space initially available and the volume of write i/o activity to the volume groups. Before the snapshot space is exhausted, the snapshots must be deleted and then there is no turning back. + +Once comfortable with the converted host, the commit playbook should be executed to delete the snapshot. The CentOS conversion to RHEL is complete. + +#### Let's Get Started + +The CentOS conversion automation approach workflow is designed to reduce the risks inherent in doing an in-place conversion versus deploying a new RHEL host. Decision points at the end of the analysis and conversion phases allow the process to be rolled back and restarted with the benefit of lessons learned through reporting checks and actual conversion results. Of course, the best practice for avoiding production impacts or outages is to proceed with conversions in properly configured Dev and Test environments before moving on to Production hosts. + +### Step 2 - Patch OS to latest package versions + +One of the prerequisites for successful Convert2RHEL OS conversions is that the conversion must be performed with the latest packages from the minor version of the OS that is supported for the conversion. This is to ensure the rollback feature can be utilized in case the conversion fails. + + > **Note** + > + > While the Convert2RHEL rollback feature does work in a great many cases, Red Hat recommends that an additional means of backup external to the Convert2RHEL utility be implemented, with verification in advance of conversion operations that systems can be restored if needed. + +- Switching to the Satellite Web UI browser tab and navigate to Hosts > Content Hosts by hovering over "Hosts" in the left navigation menu and then clicking "Content Hosts": + + ![Job templates listed on AAP Web UI](images/satellite_content_hosts.png) + +- We can see that the CentOS hosts have some package updates that can be applied. + +- Return to the AAP Web UI browser tab and navigate to Resources > Templates by clicking on "Templates" under the "Resources" group in the navigation menu: + + ![Job templates listed on AAP Web UI](images/aap_templates_2.png) + +- Click ![launch](images/convert2rhel-aap2-launch.png) to the right of **OS / Patch OS to latest** to launch the OS patch job. This will display the job template limit and variable dialog: + + !["OS / Patch OS to latest" limit dialog](images/patch_os_limit_dialog.png) + +- Click "Next". The survey dialog will display: + + !["OS / Patch OS to latest" survey dialog](images/patch_os_survey_dialog.png) + +- Next we see the job template survey dialog. A survey is a customizable set of prompts that can be configured from the Survey tab of the job template. For this job template, the survey allows for selecting the Ansible inventory group, as well as whether or not to include kernel package updates and whether or not to perform a "Check only" operation and not actually update packages, but verify what packages would be updated if we were to perform the update at this moment. We are working with the **CentOS7_Dev** inventory group, so click the "Select inventory group" drop down menu and select "CentOS7_Dev". Leave "Include kernel updates?" at the default "yes" and leave "Check for updates only?" at the default "no". Click "Next". + + !["OS / Patch OS to latest" review dialog](images/patch_os_review_dialog.png) + +- Review the various settings and prompted values for the **OS / Patch OS to latest** job launch. Click "Launch". This job run will require anywhere from three to five minutes to complete. + + !["OS / Patch OS to latest" job output](images/patch_os_job_output.png) + +- With a successful job completion, we are ready to proceed with the pre-conversion OS analysis. + +### Step 3 - Use AAP to Launch an Analysis Playbook Job + +As we progress through the workshop, we'll refer back to this diagram to track where we are in our automation approach workflow. We are starting now in the highlighted block below: + +![Automation approach workflow diagram with analysis step highlighted](images/conversion-workflow-hl-analysis.svg) + +The first step in converting our three tier app hosts will be executing the analysis playbook to generate the Convert2RHEL pre-conversion analysis report for each host. To do this, we will use the Ansible Automation Platform (AAP) automation controller host that has been pre-configured in your workshop lab environment. + +- Return to the AAP Web UI browser tab and navigate to Resources > Templates by clicking on "Templates" under the "Resources" group in the navigation menu: + + ![Job templates listed on AAP Web UI](images/aap_templates.png) + +- Click on the "CONVERT2RHEL / 01 Analysis" job template. This will display the Details tab of the job template: + + !["CONVERT2RHEL / 01 Analysis" job templates seen on AAP Web UI](images/analysis_template.png) + +- From here, we could use the "Edit" button if we wanted to make any changes to the job template. This job template is already configured, so we are ready to use it to submit a playbook job. To do this, use the "Launch" button which will bring up a series of prompts. + + > **Note** + > + > The prompts that each job template presents can be configured using the "Prompt on launch" checkboxes seen when editing a job template. + + ![Analysis job variables prompt on AAP Web UI](images/analysis_limit_prompt.png) + +- The first prompt as seen above allows for limiting the scope of the automation across a grouping of hosts by defining specific hosts within the inventory group. We don't need to do this at this time, so just click the "Next" button to move on. + + ![Analysis job survey prompt on AAP Web UI](images/analysis_survey_prompt.png) + +- For this job template, the survey allows for choosing a group of hosts on which the job will execute the playbook, as well as the target RHEL package lifecycle environment from Satellite to be utilized during the conversion analysis. For "Select EL Group to analyze" choose "CentOS_Dev" from the drop-down and for "Select RHEL Lifecycle Environment to use for analysis" select "RHEL7_Dev" and click the "Next" button. This will bring you to a preview of the selected job options and variable settings. + + ![Analysis job preview on AAP Web UI](images/analysis_preview.png) + +- If you are satisfied with the job preview, use the "Launch" button to start the playbook job. + +### Step 4 - Review the Playbook Job Output + +After launching the analysis playbook job, the AAP Web UI will navigate automatically to the job output page for the job you just started. + +- While the playbook job is running, you can monitor its progress by clicking the "Follow" button. When you are in follow mode, the output will scroll automatically as task results are streamed to the bottom of job output shown in the AAP Web UI. + +- The analysis playbook will run the Convert2RHEL pre-conversion system analysis. This will take about nine to ten minutes to complete. When it is done, you can find a "PLAY RECAP" at the end of the job output showing the success or failure status for the playbook runs executed on each host. A status of "failed=0" indicates a successful playbook run. Scroll to the bottom of the job output and you should see that your job summary looks like this example: + + ![Analysis job "PLAY RECAP" as seen at the end of the job output](images/analysis_job_recap.png) + +### Step 4 - Challenge Lab: Analysis Playbook + +Let's take a closer look at the playbook we just ran. + +> **Tip** +> +> Try looking at the configuration details of the "Automated Management" project and the "CONVERT2RHEL / 01 Analysis" job template. + +Can you find the upstream source repo and playbook code? + +> **Warning** +> +> **Solution below\!** + +- In the AAP Web UI, navigate to Resources > Projects > Automated Management. Under the Details tab, you will see the "Source Control URL" setting that defines where job templates of this project will go to pull their playbooks. We see it is pointing to this git repo on GitHub: [https://github.com/redhat-partner-tech/automated-satellite](https://github.com/redhat-partner-tech/automated-satellite). Open this URL in a new browser tab. + + ![automated-satellite repo review](images/aap-project-branch-selection.png) + +- With the new tab opened and the `redhat-partner-tech/automated-satellite` repo displayed, on the left side of the browser, click the drop down for the branch selection where `main` is displayed. Click the `aap2-rhdp-prod` branch to select this branch for viewing. + +- Go back to the AAP Web UI and now navigate to Resources > Templates > CONVERT2RHEL / 01 Analysis. Under the Details tab, you will see the "Playbook" setting with the name of the playbook this job template runs when it is used to submit a job. The playbook name is `c2r_analysis.yml`. In your GitHub browser tab, you can find `c2r_analysis.yml` listed in the files of the git repo. Click on it to see the playbook contents. + +- Notice that the `Analyze CentOS 7.9 systems` tasks is comprised of the following: +``` + - name: Analyze CentOS 7.9 systems + when: + - "ansible_distribution == 'CentOS'" + - "ansible_distribution_major_version | int == 7" + - "ansible_distribution_version.split('.')[1] | int >= 9" + ansible.builtin.import_tasks: c2r_analysis_centos.yml +``` +- Since our CentOS nodes match all of these `when` tests, the tasks from `c2r_analysis_centos.yml` are going to be imported into our playbook run. In your GitHub browser tab, find `c2r_analysis_centos.yml` and click on it to review the playbook contents. + +- Notice that after some intial preparations are performed, the `Generate pre-conversion analysis report` task of the playbook imports the `analysis` role from the `infra.convert2rhel` Ansible collection. +``` +- name: Generate pre-conversion analysis report + ansible.builtin.import_role: + name: infra.convert2rhel.analysis +``` +By checking the `collections/requirements.yml` file in the `redhat-partner-tech/automated-satellite` git repo, we can discover that this role comes from another git repo at [https://github.com/heatmiser/infra.convert2rhel](https://github.com/heatmiser/infra.convert2rhel). It is the `analysis` role under this second git repo that provides all the automation tasks that ultimately runs the Convert2RHEL analysis scan and generates the report. *NOTE* We are utilizing a fork of the upstream infra.convert2rhel Ansible collection [https://github.com/redhat-cop/infra.convert2rhel](https://github.com/redhat-cop/infra.convert2rhel). Because the upstream collections is a fast moving project, we utilize a fork where we can closely manage the state of the code base to ensure optimal stability for the lab/workshop/demo environment. + +- In a new browser tab/instance, open the [https://github.com/heatmiser/infra.convert2rhel](https://github.com/heatmiser/infra.convert2rhel) URL. Drill down to the `roles/analysis` directory in this git repo to review the README and yaml source files. + +When you are ready to develop your own custom playbooks to run conversions for your enterprise, you should consider using roles from the `infra.convert2rhel` Ansible collection to make your job easier. + +## Conclusion + +In this exercise, we learned about the end-to-end workflow used by our automation approach for doing RHEL-like OS conversions. We used a job template in AAP to submit a playbook job that ran the Convert2RHEL pre-conversion analysis on our three tier application servers. In the challenge lab, we explored the playbook that we ran and how it includes a role from an Ansible collection. + +In the next exercise, we will review the analysis reports we just generated. + +--- + +**Navigation** + +[Previous Exercise](../1.2-three-tier-app/README.md) - [Next Exercise](../1.4-report/README.md) + +[Home](../README.md) diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/aap-project-branch-selection.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/aap-project-branch-selection.png new file mode 100644 index 000000000..5d898048e Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/aap-project-branch-selection.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/aap_templates.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/aap_templates.png new file mode 100644 index 000000000..acfe70543 Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/aap_templates.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/aap_templates_2.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/aap_templates_2.png new file mode 100644 index 000000000..f5b1e442e Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/aap_templates_2.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/analysis_job_recap.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/analysis_job_recap.png new file mode 100644 index 000000000..9ce10c62c Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/analysis_job_recap.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/analysis_limit_prompt.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/analysis_limit_prompt.png new file mode 100644 index 000000000..b38f72fe3 Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/analysis_limit_prompt.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/analysis_preview.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/analysis_preview.png new file mode 100644 index 000000000..2a8aade80 Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/analysis_preview.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/analysis_survey_prompt.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/analysis_survey_prompt.png new file mode 100644 index 000000000..57d833394 Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/analysis_survey_prompt.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/analysis_template.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/analysis_template.png new file mode 100644 index 000000000..c5d96da96 Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/analysis_template.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/analysis_vars_prompt.svg b/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/analysis_vars_prompt.svg new file mode 100644 index 000000000..d81fa0f19 --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/analysis_vars_prompt.svg @@ -0,0 +1,1386 @@ + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/conversion-workflow-hl-analysis.svg b/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/conversion-workflow-hl-analysis.svg new file mode 100644 index 000000000..aa26a704b --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/conversion-workflow-hl-analysis.svg @@ -0,0 +1,770 @@ + + + +ReviewReportLooksOK?YESNOAnalysis PhaseConversion PhaseCommit PhaseLooksOK?App TeamValidationsCan Fix?RollbackYESNONOYESDeleteSnapshotDoneStartApplyRecommendedRemediationRunPre-conversionAnalysisRunIn-placeConversionCreateSnapshot diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/conversion-workflow.svg b/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/conversion-workflow.svg new file mode 100644 index 000000000..33bfd2ea4 --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/conversion-workflow.svg @@ -0,0 +1,760 @@ + + + +ReviewReportLooksOK?YESNOAnalysis PhaseConversion PhaseCommit PhaseLooksOK?App TeamValidationsCan Fix?RollbackYESNONOYESDeleteSnapshotDoneStartApplyRecommendedRemediationRunPre-conversionAnalysisRunIn-placeConversionCreateSnapshot diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/convert2rhel-aap2-launch.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/convert2rhel-aap2-launch.png new file mode 100644 index 000000000..7246c1d95 Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/convert2rhel-aap2-launch.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/patch_os_job_output.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/patch_os_job_output.png new file mode 100644 index 000000000..406b8ef48 Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/patch_os_job_output.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/patch_os_limit_dialog.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/patch_os_limit_dialog.png new file mode 100644 index 000000000..69439eff2 Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/patch_os_limit_dialog.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/patch_os_review_dialog.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/patch_os_review_dialog.png new file mode 100644 index 000000000..c98701589 Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/patch_os_review_dialog.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/patch_os_survey_dialog.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/patch_os_survey_dialog.png new file mode 100644 index 000000000..b090437dc Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/patch_os_survey_dialog.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/playbook_icon.svg b/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/playbook_icon.svg new file mode 100644 index 000000000..049810f10 --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/playbook_icon.svg @@ -0,0 +1,67 @@ + + + + + + + + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/satellite_content_hosts.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/satellite_content_hosts.png new file mode 100644 index 000000000..d975584b4 Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.3-analysis/images/satellite_content_hosts.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/README.md b/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/README.md new file mode 100644 index 000000000..c0fc32495 --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/README.md @@ -0,0 +1,129 @@ +# Workshop Exercise - Review Pre-conversion Reports + +## Table of Contents + +- [Workshop Exercise - Review Pre-conversion Reports](#workshop-exercise---review-pre-conversion-reports) + - [Table of Contents](#table-of-contents) + - [Objectives](#objectives) + - [Guide](#guide) + - [Step 1 - Managing Convert2RHEL Pre-conversion Results](#step-1---managing-convert2rhel-pre-conversion-results) + - [Step 2 - Navigating the CentOS Web Console](#step-2---navigating-the-rhel-web-console) + - [Step 3 - Review Convert2RHEL Pre-conversion Report of CentOS 7 Host](#step-3---review-convert2rhel-pre-conversion-report-of-centos-7-host) + - [Challenge Lab: What About Ignoring So Many High Findings?](#challenge-lab-what-about-ignoring-so-many-high-findings) + - [Conclusion](#conclusion) + +## Objectives + +* Understand the different options for reviewing Convert2RHEL pre-conversion reports +* Use the RHEL/CentOS Web Console to review the reports we generated +* Embrace failure! + +## Guide + +### Step 1 - Managing Convert2RHEL Pre-conversion Results + +In the previous exercise, we used a job template/playbook to analyze our CentOS7 app servers. Behind the scenes, the `analysis` module from the `infra.convert2rhel` Ansible collection launched a Convert2RHEL pre-conversion analysis on each of our CentOS 7 app servers and once complete, parsed the pre-conversion analysis report for any issues that would either block the conversion from initiating or potentially failing. If any problems were found, then the Ansible Automation Platform automation job would have reported a failure. + +- If we are using the Convert2RHEL utility to manually convert just a single CentOS host, we could simply get to a shell prompt on the host and look at the local report file output. In [Exercise 1.1, Step 2](../1.1-setup/README.md#step-2---open-a-terminal-session), we learned how to open an ssh session to one of our app servers. Follow those steps and after logging in, use this command to review the local Convert2RHEL pre-conversion report file: + + ``` + less /var/log/convert2rhel/convert2rhel-pre-conversion.txt + ``` + + This is a "quick and dirty" way to review the report, but doesn't scale if you need to review reports for a large number of hosts. + + > **Note** + > + > Use the up and down arrow keys to scroll through the file and type `q` when you are ready to quit the `less` command. + +- CentOS 7 includes an optional administration web console based on [Cockpit](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/managing_systems_using_the_rhel_8_web_console/index#what-is-the-RHEL-web-console_getting-started-with-the-rhel-8-web-console) called the CentOS Web Console. We will explore how to review the Convert2RHEL pre-conversion reports using the CentOS Web Console in the next step of this exercise. + +- In addition to writing the plain text `convert2rhel-pre-conversion.txt` file, a JSON format `convert2rhel-pre-conversion.json` file is also generated. This file includes the same report results as the plain text file, but in JSON format which is perfect for being ingested by log management tools like Elastic/Kibana or Splunk. Many large enterprises will push their pre-conversion report data to one of these tools to develop their own custom dashboards that can filter reports by environment (e.g., Dev/Test/Prod), location, app ID, owning team, etc. + +### Step 2 - Navigating the CentOS Web Console + +For this workshop, we will be using the CentOS Web Console to access the Convert2RHEL pre-conversion reports we generated. + +- Return to the RHEL Web Console browser tab you opened from [Exercise 1.1, Step 4](../1.1-setup/README.md#step-4---access-the-rhel-web-console). This is the RHEL Web Console of the AAP controller host, but we need to access our CentOS 7 app server hosts to see their pre-conversion reports. Do this by clicking the "student​@​ansible-1.example.com" box in the top left corner of the AAP RHEL Web Console to reveal the remote host menu. For example: + + ![Remote host menu listing all workbench app servers](images/remote_host_menu_with_pets.png) + +- You can use the remote host menu to navigate to the web consoles of each of your CentOS 7 app servers. Try selecting one of your CentOS 7 app servers now. The Web Console system overview page will show the operating system version installed. For example, we can see node4 is confirmed as running CentOS 7: + + ![node4 running CentOS Linux 7 (Core)](images/centos7_os.png) + +- Additionally, if you'd like, take note/record the `Asset Tag` and `Machine ID` values. You can compare these values post conversion to prove the base hardware/virtualization instance is the same. + +- When you navigate to different hosts in the Web Console, look out for the "limited access mode" warning: + + ![Web console is running in limited access mode](images/limited_access.svg) + + If you see this, use the button to switch to administrative access mode before proceeding. A confirmation will appear like this: + + ![You now have administrative access](images/administrative_access.svg) + +- Take some time to explore the navigation menus available with the Web Console of your different CentOS 7 app servers. Once you feel comfortable navigating around the console and switching between hosts, move on to the next step where we will look at our first pre-conversion report. + +### Step 3 - Review Convert2RHEL Pre-conversion Report of CentOS 7 Host + +We are now here in the automation approach workflow: + +![Automation approach workflow diagram with review report step highlighted](images/conversion-workflow-hl-review.svg) + +Now, let's use the Web Console to review the Convert2RHEL pre-conversion reports. We will start by looking at one of the CentOS 7 hosts. + +- Navigate to the RHEL Web Console remote host menu and click on the hostname of one of your CentOS 7 app servers (should be node4, node5, or node6). Remember as we learned in the previous step, you can confirm the CentOS version on the system overview page. + +- Having verified you are looking at one of the CentOS 7 app servers, use the main menu to navigate to Tools > Terminal. This will display a shell terminal on the host system. In order to review the Convert2RHEL pre-conversion report that was generated for host, copy the following command line and paste into the terminal and press `Enter` or `return`: + +``` +less /var/log/convert2rhel/convert2rhel-pre-conversion.txt +``` + + For example, the analysis output might look like this: + + ![Example pre-conversion report of CentOS 7 host](images/centos7_analysis_output.png) + + > **Note** + > + > The contents of your report may differ from the example above because of updates made to the Convert2RHEL framework and other RHEL packages released over time since this workshop was written. If you discover any differences that materially break the flow of the exercises in the workshop, kindly let us know by raising an issue [here](https://github.com/redhat-partner-tech/automated-satellite/issues/new). + +- When the pre-conversion report is generated, the Convert2RHEL framework collects system data and assesses convertability based on a large collection of checks. When any of these checks uncovers a potential risk, it is recorded as a finding in the report. + +- The good news is that the warning regarding the "third party" package `katello-ca-consumer-satellite` is something we can ignore, as this package is part of the registration of the CentOS system to Satellite. And we can ignore the warnings about an outdated version of convert2rhel, as we know that we are not using the most up to date version. + +### Challenge Lab: What if we were to experience warnings we are unsure of? + +You may be wondering what if there are many warning issues listed in the report? Why would we be going forward with attempting a conversion without first resolving all the findings on the report? It's a fair question. + +> **Tip** +> +> Think back to the three key features that we introduced at the beginning of the exercise. + +Is there a specific feature that helps with reducing risk? + +> **Warning** +> +> **Solution below\!** + +Of course, the answer is our automated snapshot/rollback capability. + +- If any of the findings listed in the pre-conversion analysis report ultimately leads to the conversion failing or results in application compatibility impact, we can quickly get back to where we started by rolling back the snapshot. Before rolling back, we can debug the root cause and use the experience to understand the best way to develop remediation and eliminate the risk of that failure or impact happening in the future. + +- There is a concept explained quite well in the famous article [Fail Fast](http://www.martinfowler.com/ieeeSoftware/failFast.pdf) published in *IEEE Software*. The article dates back to 2004, so this is hardly a new concept. Unfortunately, there is a stigma associated with failure that can lead to excessively risk-averse behavior. The most important benefit of having automated snapshots is being able to quickly revert failures. That allows us to safely adopt a "fail fast / fail smart" mantra. + +- Of course, there are many best practices we can follow to reduce risk. Obviously, start with testing for application impacts by trying conversions in your lower environments first. Any issues that can be worked out with Dev and Test servers will help you be prepared to avoid those issues in Production. + +- When present, the findings reported by the Convert2RHEL pre-conversion analysis report are there to make us aware of potential failure modes, but experience has shown that sometimes they are not a problem. Do not become petrified when you see those warnings on the report. Assess findings, develop automation to remediate any issues, and then run through the conversion process, reverting back to step one to loop through the process as your arsenal of remediation automation builds over time. Convert early _and_ often! + +## Conclusion + +In this exercise, we learned about the different options for managing Convert2RHEL pre-conversion analysis reports. We used the CentOS Web Console to look at the reports we generated in the previous exercise. In the challenge lab, we reviewed the importance of snapshots and learned to embrace failure. + +--- + +**Navigation** + +[Previous Exercise](../1.3-analysis/README.md) - [Next Exercise](../2.1-convert/README.md) + +[Home](../README.md) diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/administrative_access.svg b/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/administrative_access.svg new file mode 100644 index 000000000..f38097461 --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/administrative_access.svg @@ -0,0 +1,339 @@ + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/centos7_analysis_output.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/centos7_analysis_output.png new file mode 100644 index 000000000..b97a76b46 Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/centos7_analysis_output.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/centos7_os.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/centos7_os.png new file mode 100644 index 000000000..b3b5000e3 Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/centos7_os.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/conversion-workflow-hl-review.svg b/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/conversion-workflow-hl-review.svg new file mode 100644 index 000000000..83b53a5fc --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/conversion-workflow-hl-review.svg @@ -0,0 +1,770 @@ + + + +ReviewReportLooksOK?YESNOAnalysis PhaseConversion PhaseCommit PhaseLooksOK?App TeamValidationsCan Fix?RollbackYESNONOYESDeleteSnapshotDoneStartApplyRecommendedRemediationRunPre-conversionAnalysisRunIn-placeConversionCreateSnapshot diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/enablerepo_info_finding.svg b/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/enablerepo_info_finding.svg new file mode 100644 index 000000000..b1edb1c22 --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/enablerepo_info_finding.svg @@ -0,0 +1,3182 @@ + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/excluded_repos_finding.svg b/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/excluded_repos_finding.svg new file mode 100644 index 000000000..6281ee889 --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/excluded_repos_finding.svg @@ -0,0 +1,2232 @@ + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/grub_core_finding.svg b/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/grub_core_finding.svg new file mode 100644 index 000000000..fcfafffc1 --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/grub_core_finding.svg @@ -0,0 +1,1521 @@ + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/leapp_bug_finding.svg b/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/leapp_bug_finding.svg new file mode 100644 index 000000000..67c4a121f --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/leapp_bug_finding.svg @@ -0,0 +1,1744 @@ + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/limited_access.svg b/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/limited_access.svg new file mode 100644 index 000000000..55290ef80 --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/limited_access.svg @@ -0,0 +1,422 @@ + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/missing_answers_inhibitor.svg b/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/missing_answers_inhibitor.svg new file mode 100644 index 000000000..b0b3c9929 --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/missing_answers_inhibitor.svg @@ -0,0 +1,2124 @@ + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/python_finding.svg b/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/python_finding.svg new file mode 100644 index 000000000..bf2f790e0 --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/python_finding.svg @@ -0,0 +1,2183 @@ + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/remote_host_menu_with_pets.png b/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/remote_host_menu_with_pets.png new file mode 100644 index 000000000..2e3f58838 Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/remote_host_menu_with_pets.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/remote_host_menu_with_pets.svg b/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/remote_host_menu_with_pets.svg new file mode 100644 index 000000000..ba8d35c84 --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/remote_host_menu_with_pets.svg @@ -0,0 +1,833 @@ + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/remote_root_logins_finding.svg b/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/remote_root_logins_finding.svg new file mode 100644 index 000000000..9cde352b5 --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/remote_root_logins_finding.svg @@ -0,0 +1,2318 @@ + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/rhel7_os.svg b/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/rhel7_os.svg new file mode 100644 index 000000000..cca590656 --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/rhel7_os.svg @@ -0,0 +1,1231 @@ + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/rhel7_report.svg b/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/rhel7_report.svg new file mode 100644 index 000000000..baa3b8e99 --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/rhel7_report.svg @@ -0,0 +1,4909 @@ + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/rhel8_os.svg b/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/rhel8_os.svg new file mode 100644 index 000000000..5b85e68ba --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/rhel8_os.svg @@ -0,0 +1,925 @@ + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/rhel8_report.svg b/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/rhel8_report.svg new file mode 100644 index 000000000..da293fd93 --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/rhel8_report.svg @@ -0,0 +1,4889 @@ + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/root_account_inhibitor.svg b/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/root_account_inhibitor.svg new file mode 100644 index 000000000..c5c1f1eb4 --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/1.4-report/images/root_account_inhibitor.svg @@ -0,0 +1,2323 @@ + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/2.1-convert/README.md b/exercises/rhdp_auto_satellite/3-convert2rhel/2.1-convert/README.md new file mode 100644 index 000000000..1d97f8445 --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/2.1-convert/README.md @@ -0,0 +1,68 @@ +# Workshop Exercise - Run EL OS Conversion Jobs + +## Table of Contents + +- [Workshop Exercise - Run EL OS Conversion Jobs](#workshop-exercise---run-el-os-conversion-jobs) + - [Table of Contents](#table-of-contents) + - [Objectives](#objectives) + - [Guide](#guide) + - [Step 1 - Launch the Conversion Workflow Job Template](#step-1---launch-the-conversion-workflow-job-template) + - [Step 2 - Learn More About Convert2RHEL](#step-2---learn-more-about-leapp) + - [Conclusion](#conclusion) + +## Objectives + +* Use a workflow job template to create snapshots and start the coverversions +* Learn about how the Convert2RHEL framework goes about converting CentOS to RHEL + +## Guide + +We are ready to start the conversion phase of our CentOS to RHEL automation journey: + +![Automation approach workflow diagram with conversion step highlighted](images/conversion-workflow-hl-conversion.svg) + +It is during this phase that the conversion playbooks are executed using a workflow job template. The first playbook clears yum cache in order to ensure that the maximum amount of space is available for the conversions process. The second playbook creates a snapshot that can be used for rolling back if anything goes wrong with the conversion. After the snapshot is created, the third playbook uses the Convert2RHEL utility to perform the conversion where the host is advanced to the new RHEL major version. + +### Step 1 - Launch the Conversion Workflow Job Template + +We are about to start the CentOS conversion of our application servers. When the conversion is finished, the hosts will reboot under the newly converted RHEL major version. + +Conversions typically take less than an hour, although they can run for longer if there are applications that shutdown slowly or with bare metal hosts that have a long reboot cycle. The cloud instances provisioned for our workshop lab environment will convert fairly quickly as they are very lightweight compared to traditional enterprise app servers. + +- Return to the AAP Web UI tab in your web browser. Navigate to Resources > Templates and then open the "CONVERT2RHEL / 02 Convert" job template. Here is what it looks like: + + ![AAP Web UI showing the conversion job template details view](images/convert_template.png) + +- Click the "Launch" button which will bring up the prompts for submitting the job starting with the variables prompt: + + ![Conversion job variables prompt on AAP Web UI](images/convert_vars_prompt.png) + +- We are going to convert all of our CentOS application hosts using a single job, so we can leave the `Limit` field empty. We don't need to change any of the variables settings, so click the "Next" button to move on. + + ![Conversion job survey prompt on AAP Web UI](images/convert_survey_prompt.png) + +- Next we see the job template survey prompt asking us to `Select EL Group to convert`. Choose the `CentOS7_Dev` inventory group. For the `Select target RHEL Lifecycle Environment to convert to` option, we want to utilize the comparable `RHEL7_Dev` Content View for our RPM package sources during the conversion, so choose `RHEL7_Dev` and click the "Next" button. This will bring you to a preview of the selected job options and variable settings. + + ![Conversion job preview on AAP Web UI](images/convert_preview.png) + +- If you are satisfied with the job preview, use the "Launch" button to start the job. + +### Step 2 - Learn More About Convert2RHEL + +After launching the conversion job, the AAP Web UI will navigate automatically to the workflow job output page of the job we just started. This job will take up to 20 minutes to finish, so let's take this time to learn a little more about how the Convert2RHEL framework converts your EL OS to the associated RHEL major version. + +- Keep in mind that the Convert2RHEL framework is responsible only for converting the CentOS packages. Additional tasks required for upgrading your standard agents, tools, middleware, etc., need to be included in the conversion playbooks you develop to deal with the specific requirements of your organization's environment. + +## Conclusion + +In this exercise, we launched a workflow job template to create snapshots and start the conversions of our CentOS app servers. We learned more about the Convert2RHEL framework to better understand what is happening as the CentOS systems are being converted. + +In the next exercise, we'll learn more about how snapshots work. + +--- + +**Navigation** + +[Previous Exercise](../1.4-report/README.md) - [Next Exercise](../2.2-snapshots/README.md) + +[Home](../README.md) diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/2.1-convert/images/conversion-workflow-hl-conversion.svg b/exercises/rhdp_auto_satellite/3-convert2rhel/2.1-convert/images/conversion-workflow-hl-conversion.svg new file mode 100644 index 000000000..0ff442928 --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/2.1-convert/images/conversion-workflow-hl-conversion.svg @@ -0,0 +1,781 @@ + + + +ReviewReportLooksOK?YESNOAnalysis PhaseConversion PhaseCommit PhaseLooksOK?App TeamValidationsCan Fix?RollbackYESNONOYESDeleteSnapshotDoneStartApplyRecommendedRemediationRunPre-conversionAnalysisRunIn-placeConversionCreateSnapshot diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/2.1-convert/images/convert_preview.png b/exercises/rhdp_auto_satellite/3-convert2rhel/2.1-convert/images/convert_preview.png new file mode 100644 index 000000000..f0ff9988f Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/2.1-convert/images/convert_preview.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/2.1-convert/images/convert_survey_prompt.png b/exercises/rhdp_auto_satellite/3-convert2rhel/2.1-convert/images/convert_survey_prompt.png new file mode 100644 index 000000000..fcfe2fb91 Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/2.1-convert/images/convert_survey_prompt.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/2.1-convert/images/convert_template.png b/exercises/rhdp_auto_satellite/3-convert2rhel/2.1-convert/images/convert_template.png new file mode 100644 index 000000000..2b6a317aa Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/2.1-convert/images/convert_template.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/2.1-convert/images/convert_vars_prompt.png b/exercises/rhdp_auto_satellite/3-convert2rhel/2.1-convert/images/convert_vars_prompt.png new file mode 100644 index 000000000..d3ac97c8a Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/2.1-convert/images/convert_vars_prompt.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/2.1-convert/images/inplace-upgrade-workflow-gbg.svg b/exercises/rhdp_auto_satellite/3-convert2rhel/2.1-convert/images/inplace-upgrade-workflow-gbg.svg new file mode 100644 index 000000000..59072e2b4 --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/2.1-convert/images/inplace-upgrade-workflow-gbg.svg @@ -0,0 +1,2585 @@ + + + + + + + + + + + + + image/svg+xml + + + + + + + + + Main Phases + + Leapp Upgrade Flow + + + Pre-FactsCollection + + + + Facts Collection + + + + Post-FactsCollection + + + + Pre-Checks + + + + Checks + + + + Post-Checks + + + + + + + + + + + + + + + + + + + + + + + + + + + Start + + + + Pre-Report + + + + Report + + + + Post-Report + + + + Pre-Download + + + + Download + + + + Post-Download + + + + Pre-InterimPreparation + + + + InterimPreparation + + + + Post-InterimPreparation + + + + Pre-InitramReboot + + + + Initram Start + + + + Post-InitramStart + + + + Pre-LateTests + + + + Late Tests + + + + Post-LateTests + + + + PrePreparation + + + + Preparation + + + + PostPreparation + + + + Pre-RPMUpgrade + + + + RPM Upgrade + + + + Post-RPMUpgrade + + + + PreApplications + + + + Applications + + + + PostApplications + + + + Pre-Third PartyApplications + + + + Third PartyApplications + + + + Post-Third PartyApplications + + + + PreFinalization + + + + Finalization + + + + PostFinalization + + + + PreReboot + + + + Reboot + + + + PostReboot + + + + Pre-FirstBoot + + + + First Boot + + + + Post-FirstBoot + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Report + + User Interaction + + + + + + + + + + + + + + + + + + + New System + Interim System (Initrd) + Old System + + + + + + + + + Pre-Target TransactionFactsCollection + + + + Target TransactionFacts Collection + + + + Post-Target TransactionFacts Collection + + + + + + + + + + + + + + + + + Pre-Target TransactionCheck + + + Target TransactionCheck + + + Post-Target TransactionCheck + + + + + + + + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/2.1-convert/images/upgrade_preview.svg b/exercises/rhdp_auto_satellite/3-convert2rhel/2.1-convert/images/upgrade_preview.svg new file mode 100644 index 000000000..408b716f5 --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/2.1-convert/images/upgrade_preview.svg @@ -0,0 +1,1882 @@ + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/2.1-convert/images/upgrade_survey_prompt.svg b/exercises/rhdp_auto_satellite/3-convert2rhel/2.1-convert/images/upgrade_survey_prompt.svg new file mode 100644 index 000000000..b96efa2ad --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/2.1-convert/images/upgrade_survey_prompt.svg @@ -0,0 +1,1011 @@ + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/2.1-convert/images/upgrade_template.svg b/exercises/rhdp_auto_satellite/3-convert2rhel/2.1-convert/images/upgrade_template.svg new file mode 100644 index 000000000..b5386b0f6 --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/2.1-convert/images/upgrade_template.svg @@ -0,0 +1,3332 @@ + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/2.1-convert/images/upgrade_vars_prompt.svg b/exercises/rhdp_auto_satellite/3-convert2rhel/2.1-convert/images/upgrade_vars_prompt.svg new file mode 100644 index 000000000..fb566968b --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/2.1-convert/images/upgrade_vars_prompt.svg @@ -0,0 +1,1122 @@ + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/2.2-snapshots/README.md b/exercises/rhdp_auto_satellite/3-convert2rhel/2.2-snapshots/README.md new file mode 100644 index 000000000..e81d8632f --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/2.2-snapshots/README.md @@ -0,0 +1,172 @@ +# Workshop Exercise - Let's Talk About Snapshots + +## Table of Contents + +- [Workshop Exercise - Let's Talk About Snapshots](#workshop-exercise---lets-talk-about-snapshots) + - [Table of Contents](#table-of-contents) + - [Objectives](#objectives) + - [Guide](#guide) + - [Step 1 - What are Snapshots and What are They Not](#step-1---what-are-snapshots-and-what-are-they-not) + - [Step 2 - Assessing Different Snapshot Solutions](#step-2---assessing-different-snapshot-solutions) + - [LVM](#lvm) + - [VMware](#vmware) + - [Amazon EBS](#amazon-ebs) + - [Break Mirror](#break-mirror) + - [ReaR](#rear) + - [Step 3 - Snapshot Scope](#step-3---snapshot-scope) + - [Step 4 - Choosing the Best Snapshot Solution](#step-4---choosing-the-best-snapshot-solution) + - [Conclusion](#conclusion) + +## Objectives + +* Understand the difference between backups and snapshots +* Learn about some of the different ways of doing snapshots +* Be prepared for the challenges and barriers you may encounter automating snapshots +* Consider the appropriate snapshot scope for your organization + +## Guide + +In the previous exercise, we launched the automation to start the CentOS conversions of our three tier application servers. The second step of the conversion workflow template is to create a snapshot for each CentOS instance being converted. If something goes wrong with a conversion, the snapshot makes it possible to quickly undo the conversion. + +Automating snapshots can be one of the most difficult features of the CentOS conversion solution approach. In this exercise, we will explore some of the challenges that enterprises face and look at strategies for overcoming them. + +Let's start by defining exactly what we mean when we talk about snapshots. + +### Step 1 - What are Snapshots and What They are Not + +Most organizations with a mature, traditional computing environment will have standards and tools implemented for doing backups. Typically, backups will be performed on a periodic schedule. More critical or more dynamic data might be backed up more frequently than mostly static data. There is often a strategy where full backups are performed only occasionally and incremental backups are used to save changed files and data more often. + +The reason for doing backups is to be able to recover data that has been lost for any reason. If data is corrupted because of an operations issue, software defect or accidentally deleted, backups make it easy to turn the clock back and restore the lost data. + +But when an entire server is lost, using backups to recover is more difficult because a new operating system must first be installed before anything can be restored from the backup. The data can be spread out across a full backup as well as multiple incremental backups, further increasing the time for a full server recovery. Most organizations only use their backup solution to restore individual files or directories, but they are not as prepared to recover everything on a server. Even if they are, such a recovery will take a long time. + +Snapshots are different in that they do not backup and restore individual files. Instead, backups operate at a storage device level, instantly saving the contents of an entire logical volume or virtual disk. Unlike backups, snapshots do not make a copy of the data being backed up, but rather mark a point in time after which a copy of all modified data is copied going forward. For this reason, the underlying technique used for snapshots is often referred to as "copy-on-write" or COW. + +While COW snapshots are not a substitute for traditional full and incremental backups, they do offer a number of advantages. The most important advantage is that creating and rolling back snapshots happens almost instantaneously as compared to hours or longer for traditional backup and restore. It is this ability to quickly take an entire server "back in time" that makes snapshots ideal for reducing the risk of performing CentOS conversions. + +### Step 2 - Assessing Different Snapshot Solutions + +There are a number of different types of snapshot solutions you may choose from. Each has their own benefits and drawbacks as summarized in the table below: + +| Snapshot type | Works with | Benefits | Drawbacks | +| ------------- | ---------- | -------- | --------- | +| LVM |||| +| VMware |||| +| Amazon EBS |||| +| Break Mirror |||| +| ReaR |||| + +The following sections explain the pros and cons in detail. + +#### LVM + +The Logical Volume Manager (LVM) is a set of tools included in CentOS that provide a way to create and manage virtual block devices known as logical volumes. LVM logical volumes are typically used as the block devices from which CentOS filesystems are mounted. The LVM tools support creating and rolling back logical volume snapshots. Automating these actions from an Ansible playbook is relatively simple. + +> **Note** +> +> The snapshot and rollback automation capability implemented for our workshop lab environment creates LVM snapshots managed using Ansible roles from the [`infra.lvm_snapshots`](https://github.com/swapdisk/infra.lvm_snapshots#readme) collection. + +Logical volumes are contained in a storage pool known as a volume group. The storage available in a volume group comes from one or more physical volumes, that is, block devices underlying actual disks or disk partitions. Typically, the logical volumes where the CentOS OS is installed will be in a "rootvg" volume group. If best practices are followed, applications and app data will be isolated in their own logicial volumes either in the same volume group or a separate volume group, "appvg" for example. + +To create logical volume snapshots, there must be free space in the volume group. That is, the total size of the logical volumes in the volume group must be less than the total size of the volume group. The `vgs` command can be used query volume group free space. For example: + +``` +# vgs + VG #PV #LV #SN Attr VSize VFree + VolGroup00 1 7 0 wz--n- 29.53g 9.53g +``` + +In the example above, the `VolGroup00` volume group total size is 29.53 GiB and there is 9.53 GiB of free space in the volume group. This should be enough free space to support rolling back a CentOS conversion. + +If there is not enough free space in the volume group, there are a few ways we can make space available: + +- Adding another physical volume to the volume group (i.e., `pvcreate` and `vgextend`). For a VM, you would first configure an additional virtual disk. +- Temporarily remove a logical volume you don't need. For example, on bare metal servers, there is often a large /var/crash empty filesystem. Removing this filesystem from `/etc/fstab` and then using `lvremove` to remove the logical volume from which it was mounted will free up space in the volume group. +- Reducing the size of one or more logical volumes. This is tricky because first, the filesystem in the logical volume needs to be shrunk. XFS filesystems do not support shrinking. EXT filesystems do support shrinking, but not while the filesystem is mounted. Until recently, this way of freeing up volume group space was considered a last resort to be attempted by only the most skilled Linux admin, but it is now possible to safely automate shrinking logical volumes using the [`shrink_lv`](https://github.com/swapdisk/infra.lvm_snapshots/tree/main/roles/shrink_lv#readme) role of the aforementioned `infra.lvm_snapshots` collection. + +After a snapshot is created, COW data will start to utilize the free space of the snapshot logical volume as blocks are written to the origin logical volume. Unless the snapshot is created with the same size as the origin, there is a chance that the snapshot could fill up and become invalid. Testing should be performed during the development of the LVM snapshot automation to determine snapshot sizings with enough cushion to prevent this. The `snapshot_autoextend_percent` and `snapshot_autoextend_threshold` settings in lvm.conf can also be used to reduce the risk of snapshots running out of space. The [`lvm_snapshots`](https://github.com/swapdisk/infra.lvm_snapshots/tree/main/roles/lvm_snapshots#readme) role of the `infra.lvm_snapshots` collection supports variables that may be used to automatically configure the autoextend settings. + +Unless you have the luxury of creating snapshots with the same size as their origin volumes, LVM snapshot sizing needs to be thoroughly tested and free space usage carefully monitored. However, if that challenge can be met, LVM snapshots offer a reliable snapshot solution without the headache of depending on external infrastructure such as VMware. + +#### VMware + +A VMware snapshot preserves the state and data of a VM at a specific point in time. Because VMware snapshots operate at the hypervisor level, they are completely independent of the guest OS. This makes them foolproof to anything that can go wrong during a CentOS conversion. Even if a conversion fails so badly that the OS can't even be booted up again, reverting the VMware snapshot will still save the day. For these reasons, VMware snapshots appear to be a very compelling snapshot option. + +VMware snapshots can be manually created and reverted using the vSphere management UI. To create or revert a VMware snapshot automatically from an Ansible playbook, access permissions to the required vSphere API calls must be authorized for the AAP control node. + +In our experience, having this access granted can be extremely challenging. The team that controls the VMware environment in most organizations is deeply invested in the "ClickOps" model of doing everything manually using the vSphere management UI. They may also be hesitant to trust that automation developed outside of their team can be trusted to perform the operations they would do manually to create a VMware snapshot, including checking for sufficient free space in the VMFS data store where the snapshot will be created. + +The VMware team may resist supporting snapshots because of limited storage space. While standard VMDK files are fixed in size, COW snapshots will grow over time and require careful monitoring with data stores in VMware environments often running tight on capacity. + +Another justification for pushing back on supporting automated snapshots will be the VMware vendor recommendation that snapshots should never be used for more than 72 hours (see KB article [Best practices for using VMware snapshots in the vSphere environment](https://kb.vmware.com/s/article/1025279)). Unfortunately, app teams usually need more than 3 days of soak time before they are comfortable that no impact to their apps has resulted from a CentOS conversion. + +VMware snapshots work great when they can be automated. If you are considering this option, engage early with the team that controls the VMware environment for your organization and be prepared for potential resistance. + +#### Amazon EBS + +Amazon Elastic Block Store (Amazon EBS) provides the block storage volumes used for the virtual disks attached to AWS EC2 instances. When a snapshot is created for an EBS volume, the COW data is written to Amazon S3 object storage. + +While EBS snapshots operate independently from the guest OS running on the EC2 instance, the similarity to VMware snapshots ends there. An EBS snapshot saves the data of the source EBS volume, but does not save the state or memory of the EC2 instance to which the volume is attached. Also unlike with VMware, EBS snapshots can be created for an OS volume only while leaving any separate application volumes as is. + +Automating EBS snapshot creation and rollback is fairly straightforward assuming your playbooks can access the required AWS APIs. The tricky bit of the automation is identifying the EC2 instance and attached EBS volume that corresponds to the target host in the Ansible inventory managed by AAP, but this can be solved by setting identifying tags on your EC2 instances. + +#### Break Mirror + +This method is an alternative to LVM that can be used with bare metal servers where the root disk is on a hardware RAID mirror set. Technically speaking, it is not a snapshot, but it still provides a near instantaneous rollback capability. + +Instead of creating a snapshot just before starting the conversion, the automation reconfigures the RAID controller to break the mirror set of the root disk so then it's just two JBOD disks. One of the JBOD disks is used going forward with the conversion while the other is left untouched. To perform a rollback, the mirror set is reconstructed from the untouched JBOD. + +Most bare metal servers support out-of-band management and those manufactured in the last decade will support APIs based on the [Redfish](https://www.dmtf.org/standards/redfish) standard. These APIs can be used by automation to break and reconstruct the mirror set, but be prepared for a significant development and testing effort because the API implementations are not always the same across different vendors and server models. + +#### ReaR + +ReaR (Relax and Recover) is a backup and recovery tool that is available to utilize with CentOS. ReaR doesn't use snapshots, but it does make it very easy to perform a full backup and restore of your CentOS server. When taking a full backup, ReaR creates a bootable ISO image with the current state of the server. To use a ReaR backup to revert a CentOS conversion, we simply boot the server from the ISO image and then choose the "Automatic Recover" option from the menu. + +While ReaR backup and recovery is not instantaneous like rolling back a snapshot, it is remarkably fast compared to recovery tools that require you to perform a fresh OS install and then manually recover at a file level. + +Refer to the [Relax-and-Recover (ReaR) User Guide Documentation](https://relax-and-recover.org/rear-user-guide/) to learn more. + +### Step 3 - Snapshot Scope + +A best practice for allocating the local storage of servers is to configure volumes that separate the OS from the apps and app data. For example, the OS filesystems would be under a "rootvg" volume group while the apps and app data would be in an "appvg" volume group or at least in their own dedicated logical volumes. This separation helps isolate the storage usage requirements of these two groups so they can be manged based on their individual requirements and are less likely to impact each other. For example, the backup profile for the OS is likely different than for the apps and app data. + +This practice helps to enforce a key tenet of the CentOS conversion approach: that is that the OS conversion should leave the applications untouched with the expectation that system library forward compatibility and middleware runtime abstraction reduces the risk of the CentOS to RHEL conversion impacting app functionality. + +With these concepts in mind, let's consider if we want to include the apps and app data in what gets rolled back if we need to revert the CentOS conversion: + +| Snapshot scope | Benefits | Drawbacks | +| -------------- | -------- | --------- | +| OS only ||| +| OS and apps/data ||| + +When snapshots only include the converted OS volumes, the best practice of isolating OS changes from app changes is followed. In this case, it is important to resist the temptation to make some heroic app changes in an attempt to avoid rolling back in the face of application impact after a CentOS conversion. For the sake of safety and soundness, gather the evidence required to help understand what caused any app impact, but then do a rollback. Don't make any app changes that could be difficult to untangle after rolling back the OS. + +Unfortunately, a VMware snapshot saves the full state of a VM instance including all virtual disks irrespective of whether they contain OS or app data. This can prove challenging for a couple reasons. First, more storage space will be required for the snapshots and it is more difficult to anticipate how much snapshot growth will result because of app data activity. The other problem is that rolling back app data may result in the app state becoming out of sync with external systems leading to unpredictable issues. When rolling back app data for any reason, be aware of the potential headaches that may result. + +### Step 4 - Choosing the Best Snapshot Solution + +There are a number of factors you should consider when deciding which method of snapshot/rollback will work best in your environment. + +- What is your mix of bare metal servers versus VMware or cloud instances? +- Where can free space most readily be made available? +- Can you get unfettered access to your VMware inventory and vSphere APIs? +- What is the appropriate snapshot scope for your organization? +- Which snapshot solution can you most easily make fully automated? + +Consider a belt and suspenders approach, that is, offer support for more than one method. Maybe it makes sense to recommend one method for bare metal and another for VMs. + +Whatever your decision, remember that an effective snapshot/rollback capability integrated with your end-to-end automation is the most important feature of any CentOS conversion solution. + +## Conclusion + +In this exercise, we learned about the pros and cons of a number of different methods of achieving an automated snapshot/rollback capability. We also considered the risks that can happen because of rolling back app data that isn't isolated from OS changes. With this knowledge, you are ready to make more informed decisions when designing your snapshot/rollback automation approach. + +In the next exercise, we'll go back to look at how the CentOS conversions are progressing on our three tier application servers. + +--- + +**Navigation** + +[Previous Exercise](../2.1-convert/README.md) - [Next Exercise](../2.3-check-convert/README.md) + +[Home](../README.md) diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/2.3-check-convert/README.md b/exercises/rhdp_auto_satellite/3-convert2rhel/2.3-check-convert/README.md new file mode 100644 index 000000000..5f94da589 --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/2.3-check-convert/README.md @@ -0,0 +1,101 @@ +# Workshop Exercise - Check if the Conversions Were Successful + +## Table of Contents + +- [Workshop Exercise - Check if the Conversions Were Successful](#workshop-exercise---check-if-the-conversions-were-successful) + - [Table of Contents](#table-of-contents) + - [Objectives](#objectives) + - [Guide](#guide) + - [Step 1 - Review the Conversion Playbook Job Log](#step-1---review-the-conversion-playbook-job-log) + - [Step 2 - Verify the Hosts are Converted to Next RHEL Version](#step-2---verify-the-hosts-are-converted-to-next-rhel-version) + - [Conclusion](#conclusion) + +## Objectives + +* Review the conversion playbook job log +* Verify our three tier application servers are running the new RHEL version + +## Guide + +In the previous exercises, we reviewed pre-conversion analyis reports, as well as reviewing the potential for incorporating remediations. After all of that, you finally launched the Ansible playbook jobs to run the CentOS conversions on your servers. + +It's time to verify the results of the conversions and let our application team assess if their three tier application stack is in working order. We are here in our CentOS in-place conversion automation workflow: + +![Automation approach workflow diagram with app validation steps highlighted](images/ripu-workflow-hl-validate.svg) + +Let's get started! + +### Step 1 - Review the Conversion Playbook Job Log + +The first thing we want to do is see if the job running the conversion playbook has finished successfully. + +- Return to the AAP Web UI tab in your web browser. Navigate to Views > Jobs and then open the "## - OS / Convert to RHEL7" playbook run entry (## will be a number) to see the log output from the conversions. + + > **Note** + > + > When looking in the Jobs view, you will also see an entry for the "## - CONVERT2RHEL / 02 Convert" workflow job. Workflow jobs launch a number of playbook runs. To see the conversion playbook log output, we need to open the job entry for the conversion playbook run, not the workflow job entry. + + For example: + + ![AAP Web UI listing conversion job entries](images/conversion_jobs.png) + +- If the playbook run finished without any failed tasks, you should see "Successful" displayed with a green checkmark. + + > **Note** + > + > If you see "Running" with spinning arrows, the playbook is still running. Wait for the playbook run to finish before moving on with this exercise. + + Scroll down to the end of the log output to see the "PLAY RECAP" indicating the success or failure status for the playbook run executed on each host. Here is what you should expect to see: + + ![AAP Web UI showing successful conversion playbook run play recap](images/conversion_play_recap.png) + + If there are no failed runs, the CentOS in-place conversion is complete on all of our application servers. + +### Step 2 - Verify the Hosts are Upgraded to Next RHEL Version + +Now let's make sure our application servers have actually converted to RHEL. + +- In [Exercise 1.3: Step 2](../1.3-report/README.md#step-2---navigating-the-rhel-web-console), you used the RHEL Web Console to check the installed CentOS versions on your application servers. Let's repeat those steps to see the RHEL versions reported after our conversions. + + Return to your RHEL Web Console browser tab and use the remote host menu to navigate to the web consoles of each of your application servers. The RHEL Web Console system overview page should now show the converted versions. + + > **Note** + > + > You may need to refresh the browser using Ctrl-R to see the newly reported RHEL version. + + For example, the node4 application server that previously had CentOS 7.9 is now reporting RHEL 7.9: + + ![node4 running Red Hat Enterprise Linux 7.9 (Plow)](images/rhel7_converted.png) + +- Additionally, if you recorded the `Asset Tag` and `Machine ID`, note that they are the same, serving as verification that this is indeed the same system that was previously operating with CentOS 7. + +- You can also check the RHEL and kernel versions from the command line following the steps you used with [Exercise 1.4: Step 2](../1.4-report/README.md###step-3---review-convert2rhel-pre-conversion-report-of-centos-7-host). + + At the shell prompt of your application servers, use the `cat /etc/redhat-release` and `uname -r` commands. Here's an example showing that application server `node4` was converted to RHEL 7: + + ![command output showing RHEL7 is installed](images/rhel7_commands.png) + +- Additionally, we can check Satellite to review the content host status for these systems. Switch over to the browser instance for Satellite and in the left navigation pane, select `Hosts > Content Hosts`. Note that the OS for node4, node5 and node6 now show to be RHEL 7.9: + + ![content hosts in Satellite](images/satellite_content_hosts.png) + +## Conclusion + +In this exercise, we observed that the conversion playbook runs completed successfully. We then used the RHEL Web Console,the command line, as well as Satellite to verify the new RHEL versions were installed. + +Continue to the following exercise to verify the three tier application is still functioning as expected after the CentOS to RHEL conversions: + +- [Exercise 2.4 - How is the Three Tier App Doing?](../2.4-check-three-tier-app/README.md) + +Otherwise, you may skip ahead to the next section of the workshop where we will demonstrate rolling back the CentOS conversion, starting with these exercises: + +- [Exercise 3.1 - (Optional) Trash the Instance](../3.1-error-condition/README.md) +- [Exercise 3.2 - Run Rollback Job](../3.2-rollback/README.md) + +--- + +**Navigation** + +[Previous Exercise](../2.2-snapshots/README.md) - [Next Exercise](../2.4-check-three-tier-app/README.md) + +[Home](../README.md) diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/2.3-check-convert/images/conversion_jobs.png b/exercises/rhdp_auto_satellite/3-convert2rhel/2.3-check-convert/images/conversion_jobs.png new file mode 100644 index 000000000..9ba4e60ef Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/2.3-check-convert/images/conversion_jobs.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/2.3-check-convert/images/conversion_play_recap.png b/exercises/rhdp_auto_satellite/3-convert2rhel/2.3-check-convert/images/conversion_play_recap.png new file mode 100644 index 000000000..7b0679b1d Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/2.3-check-convert/images/conversion_play_recap.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/2.3-check-convert/images/rhel7_commands.png b/exercises/rhdp_auto_satellite/3-convert2rhel/2.3-check-convert/images/rhel7_commands.png new file mode 100644 index 000000000..91d191a87 Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/2.3-check-convert/images/rhel7_commands.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/2.3-check-convert/images/rhel7_converted.png b/exercises/rhdp_auto_satellite/3-convert2rhel/2.3-check-convert/images/rhel7_converted.png new file mode 100644 index 000000000..977f02bc8 Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/2.3-check-convert/images/rhel7_converted.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/2.3-check-convert/images/rhel9_commands.svg b/exercises/rhdp_auto_satellite/3-convert2rhel/2.3-check-convert/images/rhel9_commands.svg new file mode 100644 index 000000000..1f3efce83 --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/2.3-check-convert/images/rhel9_commands.svg @@ -0,0 +1,136 @@ + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/2.3-check-convert/images/ripu-workflow-hl-validate.svg b/exercises/rhdp_auto_satellite/3-convert2rhel/2.3-check-convert/images/ripu-workflow-hl-validate.svg new file mode 100644 index 000000000..84ad1e55f --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/2.3-check-convert/images/ripu-workflow-hl-validate.svg @@ -0,0 +1,781 @@ + + + +ReviewReportLooksOK?YESNOAnalysis PhaseConversion PhaseCommit PhaseLooksOK?App TeamValidationsCan Fix?RollbackYESNONOYESDeleteSnapshotDoneStartApplyRecommendedRemediationRunPre-conversionAnalysisRunIn-placeConversionCreateSnapshot diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/2.3-check-convert/images/satellite_content_hosts.png b/exercises/rhdp_auto_satellite/3-convert2rhel/2.3-check-convert/images/satellite_content_hosts.png new file mode 100644 index 000000000..9eff1d2af Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/2.3-check-convert/images/satellite_content_hosts.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/2.4-check-three-tier-app/README.md b/exercises/rhdp_auto_satellite/3-convert2rhel/2.4-check-three-tier-app/README.md new file mode 100644 index 000000000..8aec6db15 --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/2.4-check-three-tier-app/README.md @@ -0,0 +1,71 @@ +# Workshop Exercise - How is the Three Tier App Doing? + +## Table of Contents + +- [Workshop Exercise - How is the Three Tier App Doing?](#workshop-exercise---how-is-the-three-tier-app-doing) + - [Table of Contents](#table-of-contents) + - [Objectives](#objectives) + - [Guide](#guide) + - [Step 1 - Retest our Three Tier Application](#step-1---retest-our-three-tier-application) + - [Conclusion](#conclusion) + +## Objectives + +* Confirm our three tier application is still functioning as expected after the conversion +* Add new records to the app database to see what happens when rolling back + +## Guide + +In [Exercise 1.2](../1.2-three-tier-app/README.md) we installed a sample three tier application and tested application functionality via automation. Now that we have converted our CentOS application servers to RHEL, let's retest to see if there has been any impact. + +### Step 1 - Retest our Three Tier Application + +It's time to repeat the testing you did for [Step 4](../1.2-three-tier-app/README.md#step-4---smoke-test-three-tier-application) in exercise 1.2. + + ![Job templates listed on AAP Web UI 2](images/aap_templates_2.png) + +- Use the side pane menu on the left to select **Templates**. + +- Click ![launch](images/convert2rhel-aap2-launch.png) to the right of **CONVERT2RHEL / 99 - Three Tier App smoke test** to launch the application test job. + + ![3tier-smoke-test-select](images/convert2rhel-3tier-smoke-select.png) + +- For `Choose application stack name`, remember earlier in the inventory tags section, "app_stack_name" was set to "stack02", so we choose "stack02" from the drop down selection. Then click **Next**, then on the preview screen click **Launch**. + +This should take ~15 seconds to complete. + + ![3tier-smoke-test-output](images/convert2rhel-3tier-smoke-output.png) + +- If the job template completes successfully, then we have verified that our three tier application stack is functioning correctly. If it fails, we know that something with the application stack is malfunctioning and we can begin the debugging process to determine where the problem resides. + +- If you observe any changes in your application behavior or the application isn't working at all, troubleshoot the issue to try to narrow down the root cause. Make note of any issues so you can retest after rolling back the conversion. + +### Step 2 - Add More Records to the Database + +In [Exercise 2.2](../2.2-snapshots/README.md), we considered the potential pitfalls of including app data in the scope of our snapshot. Imagine what would happen if your app at first appeared fine after the conversion, but an issue was later discovered after the app had been returned to production use. + +- Wait at least one minute since running the previous smoke test job template and add a new table to the database via an additional run of of the **CONVERT2RHEL / 99 - Three Tier App smoke test** job template. Check the job template output for a task _similar_ to this, typically the last task in the job run: + +`TASK [Fail if database db01 did not contain table 06-06-2024-04-01]` + +Remember and/or record this table name to see what happens after we revert the OS conversion in the next section of the workshop. + +> **Note** + > + > The three tier application uses the current time and date to generate the new table names. Your table names are going to be different from the ones listed here in these exercises, as the instructions here were generated in the past. + +- What will be the business impact if data updates are rolled back with the conversion? That is exactly the problem we will demonstrate next, because the three tier application servers deployed in this workshop do not have separate volumes to isolate the OS from the app data. + +## Conclusion + +In this exercise, we observed that the CentOS conversion to RHEL left our application untouched and we found that it still works as expected after the conversion. Then we added some new app data to demonstrate what will happen after rolling back the conversion. + +This concludes the CentOS conversion section of the workshop. In the next and final section, we will be rolling back the CentOS conversion, taking us right back to where we started. + +--- + +**Navigation** + +[Previous Exercise](../2.3-check-convert/README.md) - [Next Exercise](../3.1-error-condition/README.md) + +[Home](../README.md) diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/2.4-check-three-tier-app/images/aap_templates_2.png b/exercises/rhdp_auto_satellite/3-convert2rhel/2.4-check-three-tier-app/images/aap_templates_2.png new file mode 100644 index 000000000..bc86ec7eb Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/2.4-check-three-tier-app/images/aap_templates_2.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/2.4-check-three-tier-app/images/convert2rhel-3tier-smoke-output.png b/exercises/rhdp_auto_satellite/3-convert2rhel/2.4-check-three-tier-app/images/convert2rhel-3tier-smoke-output.png new file mode 100644 index 000000000..5fb1a0a64 Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/2.4-check-three-tier-app/images/convert2rhel-3tier-smoke-output.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/2.4-check-three-tier-app/images/convert2rhel-3tier-smoke-select.png b/exercises/rhdp_auto_satellite/3-convert2rhel/2.4-check-three-tier-app/images/convert2rhel-3tier-smoke-select.png new file mode 100644 index 000000000..36a01d1ff Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/2.4-check-three-tier-app/images/convert2rhel-3tier-smoke-select.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/2.4-check-three-tier-app/images/convert2rhel-aap2-launch.png b/exercises/rhdp_auto_satellite/3-convert2rhel/2.4-check-three-tier-app/images/convert2rhel-aap2-launch.png new file mode 100644 index 000000000..7246c1d95 Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/2.4-check-three-tier-app/images/convert2rhel-aap2-launch.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/3.1-error-condition/README.md b/exercises/rhdp_auto_satellite/3-convert2rhel/3.1-error-condition/README.md new file mode 100644 index 000000000..f3a119082 --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/3.1-error-condition/README.md @@ -0,0 +1,89 @@ +# Workshop Exercise - Simulate conversion failure + +## Table of Contents + +- [Workshop Exercise - Simulate conversion failure](#workshop-exercise---simulate-conversion-failure) + - [Table of Contents](#table-of-contents) + - [Optional Exercise](#optional-exercise) + - [Objectives](#objectives) + - [Guide](#guide) + - [Step 1 - Select an Application Stack Server](#step-1---select-an-application-stack-server) + - [Step 2 - Break your application](#step-2---break-your-application) + - [Conclusion](#conclusion) + +## Optional Exercise + +This is an optional exercise. It is not required to successfully complete the workshop, but it will help demonstrate the effectiveness of rolling back a CentOS to RHEL conversion. Review the objectives listed in the next section to decide if you want to do this exercise or if you would rather skip ahead to the next exercise: + +* [Exercise 3.2 - Run Rollback Job](3.2-rollback/README.md) + +## Objectives + +* Simulate a failed CentOS conversion or application impact +* Demonstrate the scope of rolling back a snapshot + +## Guide + +In this exercise, we are going to intentionally misconfigure one of our application stack servers to demonstrate how rolling back can save the day. + +Let's get started! + +### Step 1 - Select an Application Stack Server + +In the next exercise, we will be rolling back the CentOS to RHEL conversion across our three tier application servers. + +- Choose one of the servers. It can be the HAproxy node, or the Tomcat node, or the PostgreSQL node. In this example, the PostgreSQL node, node6, will be utilized. + +- Follow the steps you used with [Exercise 1.1: Step 2](../1.1-setup/README.md#step-2---open-a-terminal-session) to open a terminal session on the application stack server you have chosen misconfigure. + +- At the shell prompt, ssh to node6: `ssh node6` and then use the `sudo -i` command to switch to the root user. For example: + +``` +[student@ansible-1 ~]$ ssh node6 +Last login: Thu Jun 6 20:45:47 2024 from ip-192-168-0-233.us-east-2.compute.internal +[ec2-user@node6 ~]$ sudo su - +Last login: Thu Jun 6 02:58:51 UTC 2024 on pts/0 +[root@node6 ~]# +``` + + Verify you see a root prompt like the example above. + +### Step 2 - Break your application + + What if there was an issue with the PostgreSQL package conversion? Our application stack relies on the database to function. Without it, our application stack will be broken. We can simulate this by manually removing the postgresql-related packages like this: + + ``` + [root@node6 ~]# yum -y remove postgresql + ``` + + Once the postgresql package removal has completed, let's try testing the application via the **CONVERT2RHEL / 99 - Three Tier App smoke test** automation job. Switch to the browser instance with the AAP Web UI. + + ![Job templates listed on AAP Web UI 2](images/aap_templates_2.png) + +- Use the side pane menu on the left to select **Templates**. + +- Click ![launch](images/convert2rhel-aap2-launch.png) to the right of **CONVERT2RHEL / 99 - Three Tier App smoke test** to launch the application test job. + + ![3tier-smoke-test-select](images/convert2rhel-3tier-smoke-select.png) + +- For `Choose application stack name`, remember earlier in the inventory tags section, "app_stack_name" was set to "stack02", so we choose "stack02" from the drop down selection. Then click **Next**, then on the preview screen click **Launch**. + +This should take ~15 seconds to complete. + + ![3tier-smoke-test-output](images/convert2rhel-3tier-smoke-output.png) + + This simulates an example application impact that can be reversed by rolling back the conversion. + +## Conclusion + +Congratulations, you have broken the application stack. Wasn't that fun? + +In the next exercise, you will correct the issue by rolling back the conversion. + +--- + +**Navigation** + +[Previous Exercise](../2.4-check-three-tier-app/README.md) - [Next Exercise](../3.2-rollback/README.md) + +[Home](../README.md) diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/3.1-error-condition/images/aap_templates_2.png b/exercises/rhdp_auto_satellite/3-convert2rhel/3.1-error-condition/images/aap_templates_2.png new file mode 100644 index 000000000..bc86ec7eb Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/3.1-error-condition/images/aap_templates_2.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/3.1-error-condition/images/convert2rhel-3tier-smoke-output.png b/exercises/rhdp_auto_satellite/3-convert2rhel/3.1-error-condition/images/convert2rhel-3tier-smoke-output.png new file mode 100644 index 000000000..bd9d070fb Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/3.1-error-condition/images/convert2rhel-3tier-smoke-output.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/3.1-error-condition/images/convert2rhel-3tier-smoke-select.png b/exercises/rhdp_auto_satellite/3-convert2rhel/3.1-error-condition/images/convert2rhel-3tier-smoke-select.png new file mode 100644 index 000000000..36a01d1ff Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/3.1-error-condition/images/convert2rhel-3tier-smoke-select.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/3.1-error-condition/images/convert2rhel-aap2-launch.png b/exercises/rhdp_auto_satellite/3-convert2rhel/3.1-error-condition/images/convert2rhel-aap2-launch.png new file mode 100644 index 000000000..7246c1d95 Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/3.1-error-condition/images/convert2rhel-aap2-launch.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/3.2-rollback/README.md b/exercises/rhdp_auto_satellite/3-convert2rhel/3.2-rollback/README.md new file mode 100644 index 000000000..72a301d13 --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/3.2-rollback/README.md @@ -0,0 +1,97 @@ +# Workshop Exercise - Run Rollback Job + +## Table of Contents + +- [Workshop Exercise - Run Rollback Job](#workshop-exercise---run-rollback-job) + - [Table of Contents](#table-of-contents) + - [Objectives](#objectives) + - [Guide](#guide) + - [Step 1 - Launch the Rollback Job Template](#step-1---launch-the-rollback-job-template) + - [Step 2 - Observe the Rollback Job Output](#step-2---observe-the-rollback-job-output) + - [Step 3 - Check the CentOS Version](#step-3---check-the-centos-version) + - [Conclusion](#conclusion) + +## Objectives + +* Demonstrate using an Ansible playbook for rolling back a CentOS conversion +* Verify the CentOS major version is reverted back + +## Guide + +In this exercise, we will demonstrate rolling back our three tier application servers, just as we would if the CentOS conversion had failed or if we had found the conversion caused unexpected impacts to the application. + +We are now here in our exploration of the CentOS conversion workflow: + +![Automation approach workflow diagram with rollback playbook highlighted](images/conversion-workflow-hl-rollback.png) + +After rolling back, the three tier application stack will be restored to as it was just before entering the conversion phase of the workflow. + +### Step 1 - Launch the Rollback Job Template + +In this step, we will be rolling back the CentOS conversion for our entire three tier application server stack. + +> **Note** +> +> In this case, only one of our nodes has an issue. Depending on overall thoughts on how to best proceed, an argument could be made for just rolling back the PostgreSQL node, node6, and leave node4 and node5 as they are. However, in this case, we are going to demonstrate the ability to simulataneously roll back an entire application stack of systems at once. + +- Return to the AAP Web UI tab in your web browser. Navigate to Resources > Templates and then open the "CONVERT2RHEL / 03 Rollback" workflow template. Here is what it looks like: + + ![AAP Web UI showing the rollback workflow template details view](images/rollback_template.png) + +- Click the "Launch" button which will bring up the prompts for submitting the workflow starting with the limit and prompt. We want to do a rollback of the entire three tier application stack. To do this, we will not enter any values into the "Limit" prompt. + + ![AAP Web UI showing the rollback job limit prompt](images/rollback_prompts.png) + + Click the "Next" button to proceed. + + ![AAP Web UI showing the rollback job survey prompt](images/rollback_survey.png) + +- Next we see the job template survey prompt asking us to select an inventory group. Our systems were converted to RHEL7 and we looked in Satellite and verified that the nodes were in fact registered as RHEL7 nodes, configured to consume the RHEL7_Dev content view. So, we should choose "RHEL7_Dev" for our inventory group, yes? Actually, no. We have not _committed_ to keeping the converted systems, our system tags that define the current OS and content view have not been updated...so the Ansible inventory still recognizes these systems as members of the "CentOS7_Dev" inventory group. So if we have not initiated the commit automation to accept the converted systems as RHEL7_Dev nodes, we choose the "CentOS7_Dev" option and click the "Next" button. + +- This will bring you to the preview of the selected job options and variable settings, for example: + + ![AAP Web UI showing the rollback job preview prompt](images/rollback_preview.png) + + If everything looks good, use the "Launch" button to start the playbook job. + +### Step 2 - Observe the Rollback Job Output + +After launching the rollback workflow job, the AAP Web UI will navigate automatically to the workflow output visualizer page. + + ![Rollback workflow job visualizer](images/rollback_workflow_job_visual.png) + +- The automated rollback takes only a few minutes to run. You can monitor the log output as the playbook run progresses by clicking directly on the "UTILITY / Snapshot Instance" node in the workflow visualizer. + +- When all of the workflow job nodes have completed (green check mark), if you haven't done so already, click on the "UTILITY / Snapshot Instance" node in the workflow visualizer. Once the "UTILITY / Snapshot Instance" job details displays, click on the "Output" tab and scroll to the bottom of the job output. If it finished successfully, you should see "failed=0" status for each node in the job summary, like this example: + + ![Rollback job "PLAY RECAP" as seen at the end of the job output](images/rollback_job_recap.png) + + Notice in the example above, we see the job completed in aproximately two and a half minutes. However, most of that time was spent in the final "Wait for the snapshot to drain" task which holds the job until the snapshot merges finish in the background. The instance was actually rolled back and service ready in just under a minute. Impressive, right? + +### Step 3 - Check the CentOS Version + +Repeat the steps you followed with [Exercise 2.3: Step 2](../2.3-check-upg/README.md#step-2---verify-the-hosts-are-converted-to-next-rhel-version), this time to verify that the CentOS version is reverted back. + +- For example, if the three tier host you rolled back had been converted from CentOS7 to RHEL7, you should now see it is back to CentOS7: + + ![command output showing the host is back to CentOS7 installed](images/commands_after_rollback.png) + +- Additionally, we can check Satellite to verify node status. Switching to the Satellite UI in your brwoser, hover over "Hosts" in the left hand menu and then click on "Content Hosts": + + ![Satellite Content Hosts showing CentOS7](images/rollback_satellite_content_hosts.png) + +We can see that the three tier application stack nodes are all reverted to CentOS7 and set to utilize the CentOS7_Dev content view + +## Conclusion + +In this exercise, we used automation to quickly reverse the CentOS to RHEL conversion and restore the app server back to its original state. + +In the next exercise, we'll dig deeper to validate that all changes and impacts caused by the conversion are now undone. + +--- + +**Navigation** + +[Previous Exercise](../3.1-error-condition/README.md) - [Next Exercise](../3.3-check-undo/README.md) + +[Home](../README.md) diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/3.2-rollback/images/commands_after_rollback.png b/exercises/rhdp_auto_satellite/3-convert2rhel/3.2-rollback/images/commands_after_rollback.png new file mode 100644 index 000000000..7f7f042b4 Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/3.2-rollback/images/commands_after_rollback.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/3.2-rollback/images/commands_after_rollback.svg b/exercises/rhdp_auto_satellite/3-convert2rhel/3.2-rollback/images/commands_after_rollback.svg new file mode 100644 index 000000000..cc43d3cf8 --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/3.2-rollback/images/commands_after_rollback.svg @@ -0,0 +1,24 @@ + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/3.2-rollback/images/conversion-workflow-hl-rollback.png b/exercises/rhdp_auto_satellite/3-convert2rhel/3.2-rollback/images/conversion-workflow-hl-rollback.png new file mode 100644 index 000000000..417ee0346 Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/3.2-rollback/images/conversion-workflow-hl-rollback.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/3.2-rollback/images/conversion-workflow.svg b/exercises/rhdp_auto_satellite/3-convert2rhel/3.2-rollback/images/conversion-workflow.svg new file mode 100644 index 000000000..33bfd2ea4 --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/3.2-rollback/images/conversion-workflow.svg @@ -0,0 +1,760 @@ + + + +ReviewReportLooksOK?YESNOAnalysis PhaseConversion PhaseCommit PhaseLooksOK?App TeamValidationsCan Fix?RollbackYESNONOYESDeleteSnapshotDoneStartApplyRecommendedRemediationRunPre-conversionAnalysisRunIn-placeConversionCreateSnapshot diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/3.2-rollback/images/ripu-workflow-hl-rollback.svg b/exercises/rhdp_auto_satellite/3-convert2rhel/3.2-rollback/images/ripu-workflow-hl-rollback.svg new file mode 100644 index 000000000..1c3f1267b --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/3.2-rollback/images/ripu-workflow-hl-rollback.svg @@ -0,0 +1,786 @@ + + + +ReviewReportLooksOK?YESNOAnalysis PhaseUpgrade PhaseCommit PhaseLooksOK?App TeamValidationsCan Fix?RollbackYESNONOYESDeleteSnapshotDoneStartApplyRecommendedRemediationRunPre-upgradeAnalysisRunIn-placeUpgradeCreateSnapshot diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/3.2-rollback/images/rollback_job_recap.png b/exercises/rhdp_auto_satellite/3-convert2rhel/3.2-rollback/images/rollback_job_recap.png new file mode 100644 index 000000000..656516df4 Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/3.2-rollback/images/rollback_job_recap.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/3.2-rollback/images/rollback_job_recap.svg b/exercises/rhdp_auto_satellite/3-convert2rhel/3.2-rollback/images/rollback_job_recap.svg new file mode 100644 index 000000000..11f6f0ff9 --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/3.2-rollback/images/rollback_job_recap.svg @@ -0,0 +1,24 @@ + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/3.2-rollback/images/rollback_preview.png b/exercises/rhdp_auto_satellite/3-convert2rhel/3.2-rollback/images/rollback_preview.png new file mode 100644 index 000000000..f2cca5d3e Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/3.2-rollback/images/rollback_preview.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/3.2-rollback/images/rollback_prompts.png b/exercises/rhdp_auto_satellite/3-convert2rhel/3.2-rollback/images/rollback_prompts.png new file mode 100644 index 000000000..9c7b36888 Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/3.2-rollback/images/rollback_prompts.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/3.2-rollback/images/rollback_satellite_content_hosts.png b/exercises/rhdp_auto_satellite/3-convert2rhel/3.2-rollback/images/rollback_satellite_content_hosts.png new file mode 100644 index 000000000..a496a37bf Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/3.2-rollback/images/rollback_satellite_content_hosts.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/3.2-rollback/images/rollback_survey.png b/exercises/rhdp_auto_satellite/3-convert2rhel/3.2-rollback/images/rollback_survey.png new file mode 100644 index 000000000..ec1436e72 Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/3.2-rollback/images/rollback_survey.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/3.2-rollback/images/rollback_template.png b/exercises/rhdp_auto_satellite/3-convert2rhel/3.2-rollback/images/rollback_template.png new file mode 100644 index 000000000..03c3578ce Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/3.2-rollback/images/rollback_template.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/3.2-rollback/images/rollback_workflow_job_visual.png b/exercises/rhdp_auto_satellite/3-convert2rhel/3.2-rollback/images/rollback_workflow_job_visual.png new file mode 100644 index 000000000..e310327f2 Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/3.2-rollback/images/rollback_workflow_job_visual.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/3.3-check-undo/README.md b/exercises/rhdp_auto_satellite/3-convert2rhel/3.3-check-undo/README.md new file mode 100644 index 000000000..6c53b080e --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/3.3-check-undo/README.md @@ -0,0 +1,67 @@ +# Workshop Exercise - Check if Conversion Undone + +## Table of Contents + +- [Workshop Exercise - Check if Conversion Undone](#workshop-exercise---check-if-conversion-undone) + - [Table of Contents](#table-of-contents) + - [Objectives](#objectives) + - [Guide](#guide) + - [Step 1 - Our State After Rolling Back](#step-1---our-state-after-rolling-back) + - [Step 2 - What's Next?](#step-2---whats-next) + - [Conclusion](#conclusion) + +## Objectives + +* Validate that all changes and impacts caused by the conversion are undone after rolling back +* Revisit the topic of snapshot scope +* Consider next steps after rolling back + +## Guide + +In the previous exercise, we rolled back our three tier application servers. Now we will take a closer look at where that has left us and consider next steps. + +### Step 1 - Our State After Rolling Back + +In this step, we will repeat the observations we made on our host after the conversion with the expectation that everything is back as it was before the conversion. + +- In the previous exercise, we checked that the CentOS version is reverted back. You can verify this at a shell prompt using commands like `cat /etc/redhat-release` and `uname -r` to output the OS release information and kernel version. You can also refresh the RHEL Web Console to confirm the CentOS version shown on the system overview page. + +- If you inflicted some damage to any of the three tier application servers with the optional [Simulate conversion failure](../3.1-error-condition/README.md) exercise, you will now find no evidence of that. You could switch over to the Ansible Automation Platform UI and run the `CONVERT2RHEL / 99 - Three Tier App smoke test` job template to verify complete application stack functinality. Or check via some of the following: + + For example, did you delete everything with the `rm -rf /*` command or remove the standard C library with the `rpm -e --nodeps glibc` command? Your efforts to nuke the OS have been nullified! + + Did you break your three tier applicationlication by removing the PostgreSQL package on node6? If you check now with the `yum list 'postgresql*'` command, you will see that postgresql packages are installed. + + If you filled up your disk, check now with the `df -h /` command. You will see there is now plenty of free space reported. + + Look for any app data you added or modified after the conversion and you will find that all those changes are lost. What does this tell us about the snapshot scope implemented by our rollback playbook? + + Business units will not be happy about loss of data, so make sure to raise awareness of the risk to application data when "everything scope" snapshots are employed. + +### Step 2 - What's Next? + +No matter what the reason is for rolling back, the next step will be to decide what to do next. + +- Maybe you rolled back because there was a failure with the Convert2RHEL conversion itself or some custom automation meant to deal with your standard tools and agents. If so, assess what happened and use the experience to improve your automation to prevent similar issues going forward. + + Developing robust automation is an iterative process. Remember, it's good to fail fast! Failed conversions early in the development of your automation should be accepted as a possibility. Analysis of these issues will inform you about what adjustments need to be implemented along the way. Having an automated rollback capability helps accelerate the development of robust playbooks. + +- What if you rolled back because application impact was discovered after the conversion. In this case, it's important for the app team to investigate the cause of the impact. Once the cause is understood, roll back so what was learned can be applied to avoid the issue for subsequent conversions. + + Understanding the cause of application impacts is also an iterative process. App teams must take the time required to fully assess any application issues when upgrading their dev and test servers, rolling back as often as needed. Use the lower environments in this manner so full preparations can be made before moving to production. + +- After rolling back, the last pre-conversion report generated before the conversion will still be available. If no significant changes are made after rolling back, it is not necessary to generate a fresh pre-conversion report before implementing any new/additional automation and trying another conversion. + +## Conclusion + +In this exercise section, we reviewed the state of our three tier application servers after rolling back and we considered next steps for some different scenarios. + +In the next and final section of the exercise, we'll review what we learned and explore some additional things you may want to play with in the workshop lab environment. + +--- + +**Navigation** + +[Previous Exercise](../3.2-rollback/README.md) - [Next Exercise](../3.4-conclusion/README.md) + +[Home](../README.md) diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/3.4-conclusion/README.md b/exercises/rhdp_auto_satellite/3-convert2rhel/3.4-conclusion/README.md new file mode 100644 index 000000000..f1e813691 --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/3.4-conclusion/README.md @@ -0,0 +1,79 @@ +# Workshop Exercise - Rinse and Repeat + +## Table of Contents + +- [Workshop Exercise - Rinse and Repeat](#workshop-exercise---rinse-and-repeat) + - [Table of Contents](#table-of-contents) + - [Objectives](#objectives) + - [Guide](#guide) + - [Step 1 - What You Learned](#step-1---what-you-learned) + - [Step 2 - Activities for Extra Credit](#step-2---activities-for-extra-credit) + - [Step 3 - Look at the Code](#step-3---look-at-the-code) + - [redhat-cop/infra.convert2rhel](#redhat-copinfraconvert2rhel) + - [redhat-partner-tech/automated-satellite](#redhat-partner-techautomated-satellite) + - [redhat-cop/infra.lvm_snapshots](#redhat-copinfralvm_snapshots) + - [Thank You!](#thank-you) + +## Objectives + +* Review what we have learned in this workshop +* Consider ideas for further exploration +* Look at the code and get involved upstream + +## Guide + +Congratulations! You have reached the end of the CentOS to RHEL Conversion Automation exercises. You are now armed with the knowledge needed to start developing an automation solution to help your organization manage CentOS conversions at scale. + +Let's review what we learned and think about what's next. + +### Step 1 - What You Learned + +With these exercises, you gained hands-on experience while learning about a prescriptive approach to automating CentOS to RHEL conversions. + +- You converted a handful of CentOS cloud instances while progressing through the workshop exercises, but with the power of an enterprise deployment of AAP, this approach can be rolled out at scale across a large fleet of CentOS hosts. + +- You learned why automated snapshot/rollback is one of the most important capabilities required to successfully deliver CentOS to RHEL conversion automation. Snapshots/backups not only eliminate the risk and anxiety experienced by an app team facing a CentOS conversion, but they also help accelerate the development of robust conversion automation playbooks. + +- But the most important lesson we learned is "You can do this!" + +### Step 2 - Activities for Extra Credit + +Hopefully, these exercises have opened your eyes to what is possible, but we have just scratched the surface. + +- Is it possible to convert/upgrade from CentOS7 directly to RHEL8 or RHEL9? While the Convert2RHEL and Leapp frameworks do not support a "conversion plus upgrades" directly, it is possible to take a host that was converted from CentOS7 to RHEL7 and then upgrade from there to RHEL8 and, if desired, upgrade onwards to RHEL 9. You can follow this path in this workshop via the next exercise in this workshop series, **Automated Satellite Workshop: RHEL In-place Upgrade Automation exercise** + + There are a couple things to be aware of if you want to continue through to the RHEL In Place Upgrade content. If you stepped through the conversion rollback exercise, you will have to perform the conversion again and once verified as successful, you will need to run the "CONVERT2RHEL / 04 Commit" playbook job template. This job will delete the snapshot created for your CentOS7 to RHEL7 conversion, so be sure you are happy with everything before you do this. While rolling back to CentOS7 will no longer be possible, you will be able to roll back to RHEL7 if needed after upgrading to RHEL8. + + Another consideration with going from CentOS7 to RHEL9 is the increased risk of application impacts. While RHEL system library forward binary compatibility is solid between each RHEL major version, "N+2" compatibility is not guaranteed. Of course, the only way to know for sure is to try it! + +- If you skipped over any of the optional exercises, it is not too late to go back and try them now. + +- The workshop lab environment is now yours to play with. Dream up your own ideas for additional learning and experimentation. Remember you can upgrade and roll back as often as you like. Rinse and repeat! + +### Step 3 - Look at the Code + +All of the Ansible roles and playbooks used in this workshop are maintained in upstream repositories that can be found on GitHub. Take some time to review the code and get engaged with the communities supporting these resources. + +#### [redhat-cop/infra.convert2rhel](https://github.com/redhat-cop/infra.convert2rhel) + +- The `infra.convert2rhel` Ansible collection provides the Ansible role that generates the pre-conversion analysis reports and another that is used to perform conversions for EL rebuild OS's. This collection serves as a framework around the Convert2RHEL utility for conversions from CentOS7, Oracle Linux 7 and more. The collection is published on Ansible Galaxy [here](https://galaxy.ansible.com/ui/repo/published/infra/convert2rhel/) and also available from Ansible Automation Hub validated content [here - Red Hat account required](https://console.redhat.com/ansible/automation-hub/repo/validated/infra/convert2rhel/). If you are planning to do EL conversions for your organization, these Ansible collections will help you quickly roll out proof-of-concept automation and start upgrading. + +#### [redhat-partner-tech/automated-satellite](https://github.com/redhat-partner-tech/automated-satellite) + +- This is where you will find all of the AAP job templates and Ansible playbooks included in the workshop, specifically the `aap2-rhdp-prod` and `aap2-rhdp-dev` code branches. You can also explore the infrastructure/configuration as code (IaC/CaC) magic that is used to provision the workshop lab environment. + +#### [redhat-cop/infra.lvm_snapshots](https://github.com/redhat-cop/infra.lvm_snapshots) + +- Here you will find the upstream project used to build the Ansible collection for managing snapshot sets using LVM. If you are interested in automating LVM snapshots as explained in the [Let's Talk About Snapshots](../2.2-snapshots/README.md#lvm) exercise, review this collection project to get in on the action. + +## Thank You! + +If you enjoyed this workshop, please take a moment to give it a rating or write a review. If you have any ideas for improvements or new features, don't hesitate to raise an issue [here](https://github.com/redhat-cop/agnosticd/issues/new/choose), reference the workshop name `Ansible Workshop - Automated Satellite Workshop` and tagging/mentioning `@heatmiser` within the issue. All ideas and feedback are welcome! + +--- + +**Navigation** + +[Previous Exercise](../3.3-check-undo/README.md) + +[Home](../README.md) diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/README.md b/exercises/rhdp_auto_satellite/3-convert2rhel/README.md new file mode 100644 index 000000000..535eb3d1e --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/README.md @@ -0,0 +1,81 @@ +# Automated Satellite Workshop: CentOS to RHEL Conversion exercise + + > **Note** + > + > This workshop is available with either CentOS 7 or Oracle Linux 7 nodes. In the case where Oracle Linux nodes are present, substitute "Oracle Linux" wherever "CentOS" is mentioned in the exercise instructions. + +This exercise will introduce a comprehensive approach to automate conversions of CentOS 7 to Red Hat Enterprise Linux (RHEL) 7. The solution uses Ansible Automation Platform (AAP) to execute upgrades at enterprise scale across a large estate of CentOS hosts. The exercise demonstrates how to use an example of this approach to perform conversions of CentOS7 to RHEL7. You will also learn about how this solution can be customized to meet the special requirements of your enterprise environment. + +There are three key features that the solution approach recommends to deliver success at scale: + +![Automate Everything, Snapshot/rollback, Reporting Dashboard](images/conversions_key_features.svg) + +As you progress through this exercise, you will learn more about the importance of these features and the different options for how you might implement them in your enterprise. For this exercise, we assume you have at least some experience using Ansible Automation Platform and working with Ansible playbooks and roles. If you're new to Ansible, consider first completing the workshop [Ansible for Red Hat Enterprise Linux](https://aap2.demoredhat.com/exercises/ansible_rhel). + +## Table of Contents + +- [Automated Satellite Workshop: CentOS to RHEL Conversion exercise](#automated-satellite-workshop:-centos-to-rhel-conversion-exercise) + - [Table of Contents](#table-of-contents) + - [Presentations](#presentations) + - [Time Planning](#time-planning) + - [Lab Diagram](#lab-diagram) + - [Exercise Sections](#exercise-sections) + - [Section 1 - Pre-upgrade Analysis](#section-1---pre-upgrade-analysis) + - [Section 2 - CentOS OS Conversion](#section-2---centos-os-conversion) + - [Section 3 - Rolling Back](#section-3---rolling-back) + - [Supplemental Exercises](#supplemental-exercises) + - [Exercise Navigation](#exercise-navigation) + +## Presentations + +The exercise sections are self explanatory and guide the participants through all the phases of an automated CentOS to RHEL conversion. All concepts are explained as they are introduced. + +There is an optional presentation deck available with additional information on the benefits of the approach demonstrated in this exercise: +[RHEL In-place Upgrades and Conversions Automation](../decks/ansible_ripu_conversion.pdf) + +## Time Planning + +The time required to complete the exercise depends on the number of participants and how familiar they are with Linux and Ansible. The exercises themselves should take a minimum of ~45 minutes. The introduction in the optional presentation adds 20 to 30 minutes. There are some optional exercises which can be skipped, but are recommended if time allows. Additionally, supplemental exercises at the end of the exercise provide for open-ended experimentation and exploring customizations that may apply to your specific environment and requirements. The lab environment provisioned could even be used for a multi-day deep dive workshop, but that is beyond the scope of this guide. + +## Lab Diagram + +The lab environment provisioned for the exercise includes an Ansible Automation Platform (AAP) controller, a Red Hat Satellite, and number of RHEL and CentOS instances. The AAP instance is used to run playbook and workflow automation jobs. For this exercise, the jobs are executed against the CentOS hosts which will be converted to RHEL 7. The automation uses LVM to manage the snapshot/rollback capability. + +![RHEL In-place Upgrade Automation Workshop lab diagram](images/auto_satellite_lab_diagram.png) + +## Exercise Sections + +The exercise is composed of three sections each of which includes a number of exercises. Each exercise builds upon the steps performed and concepts learned in the previous exercises, so it is important to do them in the prescribed order. + +### Section 1 - Pre-upgrade Analysis + +* [1.1 - Workshop Lab Environment](1.1-setup/README.md) +* [1.2 - (Optional) Deploy a Three Tier App](1.2-three-tier-app/README.md) +* [1.3 - Run Pre-conversion Analysis](1.3-preupg/README.md) +* [1.4 - Review Pre-conversion Analysis Reports](1.4-report/README.md) +* [1.5 - Perform Remediations](1.5-remediate/README.md) +* [1.6 - (Optional) Custom Pre-upgrade Checks](1.6-custom-modules/README.md) + +### Section 2 - CentOS OS Conversion + +* [2.1 - Run OS Conversion Jobs](2.1-upgrade/README.md) +* [2.2 - Let's Talk About Snapshots](2.2-snapshots/README.md) +* [2.3 - Check if the Conversion Worked](2.3-check-convert/README.md) +* [2.4 - (Optional) How is the Three Tier App Doing?](2.4-check-three-tier-app/README.md) + +### Section 3 - Rolling Back + +* [3.1 - (Optional) Trash an Instance](3.1-error-condition/README.md) +* [3.2 - Run Rollback Job](3.2-rollback/README.md) +* [3.3 - Check if Conversion Undone](3.3-check-undo/README.md) +* [3.4 - Rinse and Repeat](3.4-conclusion/README.md) + +## Workshop Navigation + +Your will find links to the previous and next exercises at the bottom of each exercise page. Click the link below to get started. + +--- + +**Navigation** + +[Next Exercise](1.1-setup/README.md) diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/images/auto_satellite_lab_diagram.png b/exercises/rhdp_auto_satellite/3-convert2rhel/images/auto_satellite_lab_diagram.png new file mode 100644 index 000000000..ea2bac126 Binary files /dev/null and b/exercises/rhdp_auto_satellite/3-convert2rhel/images/auto_satellite_lab_diagram.png differ diff --git a/exercises/rhdp_auto_satellite/3-convert2rhel/images/conversions_key_features.svg b/exercises/rhdp_auto_satellite/3-convert2rhel/images/conversions_key_features.svg new file mode 100644 index 000000000..73c4e9b7e --- /dev/null +++ b/exercises/rhdp_auto_satellite/3-convert2rhel/images/conversions_key_features.svg @@ -0,0 +1,243 @@ + +image/svg+xml diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/README.md b/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/README.md new file mode 100644 index 000000000..4ffd08da3 --- /dev/null +++ b/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/README.md @@ -0,0 +1,160 @@ +# Automated Satellite Workshop: RHEL In-place Upgrade Automation Exercise - Your Lab Environment + +## Table of Contents + +- [Workshop Exercise - Your Lab Environment](#workshop-exercise---your-lab-environment) + - [Table of Contents](#table-of-contents) + - [Objectives](#objectives) + - [Guide](#guide) + - [Your Lab Environment](#your-lab-environment) + - [Step 1 - Access the Environment](#step-1---access-the-environment) + - [Step 2 - Open a Terminal Session](#step-2---open-a-terminal-session) + - [Step 3 - Access the AAP Web UI](#step-3---access-the-aap-web-ui) + - [Step 4 - Access the Satellite Web UI](#step-4---access-the-satellite-web-ui) + - [Step 5 - Access the RHEL Web Console](#step-5---access-the-rhel-web-console) + - [Step 6 - RHEL In-place Upgrade Automation exercise job template deploy](#step-6---rhel-in---place-upgrade-automation-exercise-job-template-deploy) + - [Step 7 - Challenge Labs](#step-7---challenge-labs) + - [Conclusion](#conclusion) + +## Objectives + +* Understand the lab topology and how to access the environment +* Understand how to perform the workshop exercises +* Understand challenge labs + +## Guide + +### Your Lab Environment + +The workshop is provisioned with a pre-configured lab environment. You will have access to a host deployed with Ansible Automation Platform (AAP) which you will use to control the playbook and workflow jobs that automation the RHEL in-place upgrade workflow steps. You will also have access to three RHEL hosts. These are the hosts where we will be upgrading the RHEL operating system (OS). + +| Role | Inventory name | +| ------------------------------------| ---------------| +| Automation controller | ansible-1 | +| Satellite Server | satellite | +| Managed Host 1 - RHEL | node1 | +| Managed Host 2 - RHEL | node2 | +| Managed Host 3 - RHEL | node3 | +| Managed Host 4 - CentOS/OracleLinux | node4 | +| Managed Host 5 - CentOS/OracleLinux | node5 | +| Managed Host 6 - CentOS/OracleLinux | node6 | + +### Step 1 - Access the Environment + +We will use Visual Studio Code (VS Code) as it provides a convenient and intuitive way to use a web browser to edit files and access terminal sessions. If you are a command line hero, direct SSH access is available if VS Code is not to your liking. There is a short YouTube video to explain if you need additional clarity: Ansible Workshops - Accessing your workbench environment. + +- You can open VS Code in your web browser using the "Console URL" link under "Visual Studio Code" on the workshop landing page. The password is provided below the link. For example: + + ![Example link to VS Code WebUI](images/vscode_link.png) + +- After opening the link, type in the provided password to access your instance of VS Code. + +> **Note** +> +> A welcome wizard may appear to guide you through configuring your VS Code user experience. This is optional as the default settings will work fine for this workshop. Feel free to step though the wizard to explore the VS code bells and whistles or you may just skip it. + +### Step 2 - Open a Terminal Session + +Terminal sessions provide access to the RHEL commands and utilities that will help us understand what's going on "behind the curtain" when the RHEL in-place upgrade automation is doing its thing. + +- Use VS Code to open a terminal session. For example: + + ![Example of how to open a terminal session in VS Code](images/new_term.svg) + +- This terminal session will be running on the AAP control host `ansible-1`. Next, use the `ssh` command to login to one of your RHEL hosts. Finally, use the highlighted commands confirm the RHEL OS version and kernel version installed. + + For example: + + ![Example ssh login to RHEL host](images/ssh_login.png) + +- In the example above, the command `ssh node1` connects us to a new session on the node1 host. Then the commands `cat /etc/redhat-release` and `uname -r` are used to output the OS release information `Red Hat Enterprise Linux Server release 7.9 (Maipo)` and kernel version `3.10.0-1160.102.1.el7.x86_64` from that host. + +### Step 3 - Access the AAP Web UI + +The AAP Web UI is where we will go to submit and check the status of the Ansible playbook jobs we will use to automate the RHEL in-place upgrade workflow. + +- Let's open the AAP Web UI in a new web browser tab using the "Console" link under "Red Hat Ansible Automation Controller" on the workshop launch page. For example: + + ![Example link to AAP Web UI](images/aap_link.png) + +- Enter the username `admin` and the password provided. This will bring you to your AAP Web UI dashboard like the example below: + + ![Example AAP Web UI dashboard](images/aap_console_example.svg) + +- We will learn more about how to use the AAP Web UI in the next exercise. + +### Step 4 - Access the Satellite Web UI + +The Satellite Web UI is where we will go to review the Lifecycle Environments, Content Views and Activation Keys configured on the Satellite, as well as tracking the status of the RHEL hosts as we proceed through the upgrade workflow through as they move to the next RHEL major version. + +- Let's open the Satellite Web UI in a new web browser tab using the "Console" link under "Red Hat Satellite" on the workshop launch page. For example: + + ![Example link to Satellite Web UI](images/satellite_link.png) + +- Enter the username `admin` and the password provided. This will bring you to your Satellite Web UI dashboard like the example below: + + ![Example Satellite Web UI dashboard](images/satellite_console_example.png) + +### Step 5 - Access the RHEL Web Console + +We will use the RHEL Web Console to review the results of the Leapp pre-upgrade reports we generate for our three-tier app servers. + +- Open a new web browser tab using the link under "RHEL Web Console Interactive Server Admin Interface" on the workshop launch page. For example: + + ![Example link to RHEL Web Console](images/cockpit_link.png) + +- Enter the username `student` and the password provided. This will bring you to a RHEL Web Console Overview page like the example below: + + ![Example RHEL Web Console](images/cockpit_example.png) + +- We will revisit the RHEL Web Console when we are ready to review our pre-upgrade reports in an upcoming exercise. + +### Step 6 - RHEL In-place Upgrade Automation exercise job template deploy + +- Before we proceed into the exercise steps, we need to launch some automation to further configure our workshop environment. The **Automated Satellite Workshop** covers a wide range of topics and as such, in order to keep a smaller number of job templates to work through, the `RHEL In Place Upgrade` job templates are not populated on the AAP Controller by default. Switch to the browser tab with the AAP Web UI and on the left menu bar, select `Resources > Templates`. + + ![Enter RIPU filter on AAP Web UI](images/ripu_cac_01.png) + +- In the filter box, enter `RIPU` and click the magnifying glass to filter the job templates displayed. + + ![Enter RIPU filter on AAP Web UI](images/ripu_cac_02.png) + +- Click ![launch](images/ripu_aap2_launch.png) to the right of **Z / CaC / Controller / RIPU scenario** to launch the job. + + ![RIPU other prompts survey on AAP Web UI](images/ripu_cac_03.png) + +- At `Other prompts` verify default variables provided and click `Next`. + + ![RIPU job survey on AAP Web UI](images/ripu_cac_04.png) + +- For the `Choose RIPU version to prepare on Controller` survey, if you are proceeding through this exercise for the first time with RHEL7 hosts, select `RHEL8`. If you have already upgraded your hosts from RHEL7 to RHEL8 and are now looking to continue by upgrading from RHEL8 to RHEL9, then select `RHEL9`. Click `Next`. + + ![RIPU preview survey on AAP Web UI](images/ripu_cac_05.png) + +- Verify variables and settings on the job preview. click `Launch`. + + ![RIPU job output on AAP Web UI](images/ripu_cac_06.png) + +- The **Z / CaC / Controller / RIPU scenario** job should require just under 2 minutes to complete. + + ![RIPU job templates on AAP Web UI](images/ripu_cac_07.png) + +- Once the **Z / CaC / Controller / RIPU scenario** job has completed, on the left menu bar, select `Resources > Templates`. In the filter box, enter `leapp` and click the magnifying glass to filter the job templates displayed. The newly populated job templates for our RHEL In-place Upgrade Automation exercises are now available to use. + +### Step 7 - Challenge Labs + +You will soon discover that many exercises in the workshop come with a "Challenge Lab" step. These labs are meant to give you a small task to solve using what you have learned so far. The solution of the task is shown underneath a warning sign. + +## Conclusion + +In this exercise, we learned about the lab environment we will be using to continue through the workshop exercises. We verified that we are able to use VS Code in our web browser and from there we can open terminal sessions. We also made sure we are able to access the AAP Web UI which will be the "self-service portal" we use to perform the next steps of the RHEL in-place upgrade automation workflow. We also made sure we are able to access the Satellite Web UI where we can review the repositories providing the packages for the RHEL in-place upgrade automation workflow, as well as the status of the hosts themselves. Finally, we connected to the RHEL Web Console where we will soon be reviewing pre-upgrade reports. + +Use the link below to move on the the next exercise. + +--- + +**Navigation** + +[Next Exercise](../1.2-three-tier-app/README.md) + +[Home](../README.md) diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/aap_console_example.svg b/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/aap_console_example.svg new file mode 100644 index 000000000..c97421583 --- /dev/null +++ b/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/aap_console_example.svg @@ -0,0 +1,2931 @@ + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/aap_link.png b/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/aap_link.png new file mode 100644 index 000000000..219d48535 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/aap_link.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/cockpit_example.png b/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/cockpit_example.png new file mode 100644 index 000000000..154c57259 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/cockpit_example.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/cockpit_example.svg b/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/cockpit_example.svg new file mode 100644 index 000000000..426c5977f --- /dev/null +++ b/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/cockpit_example.svg @@ -0,0 +1,4950 @@ + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/cockpit_link.png b/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/cockpit_link.png new file mode 100644 index 000000000..4fd63ec0f Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/cockpit_link.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/new_term.svg b/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/new_term.svg new file mode 100644 index 000000000..e6eb04ecc --- /dev/null +++ b/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/new_term.svg @@ -0,0 +1,7861 @@ + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/ripu_aap2_launch.png b/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/ripu_aap2_launch.png new file mode 100644 index 000000000..7246c1d95 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/ripu_aap2_launch.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/ripu_cac_01.png b/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/ripu_cac_01.png new file mode 100644 index 000000000..2c31cf6ed Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/ripu_cac_01.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/ripu_cac_02.png b/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/ripu_cac_02.png new file mode 100644 index 000000000..b98a88114 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/ripu_cac_02.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/ripu_cac_03.png b/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/ripu_cac_03.png new file mode 100644 index 000000000..474d3ecba Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/ripu_cac_03.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/ripu_cac_04.png b/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/ripu_cac_04.png new file mode 100644 index 000000000..2fe611b91 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/ripu_cac_04.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/ripu_cac_05.png b/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/ripu_cac_05.png new file mode 100644 index 000000000..5d63548d0 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/ripu_cac_05.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/ripu_cac_06.png b/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/ripu_cac_06.png new file mode 100644 index 000000000..37c2403fe Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/ripu_cac_06.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/ripu_cac_07.png b/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/ripu_cac_07.png new file mode 100644 index 000000000..0299cddac Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/ripu_cac_07.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/satellite_console_example.png b/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/satellite_console_example.png new file mode 100644 index 000000000..6ee3030e6 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/satellite_console_example.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/satellite_link.png b/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/satellite_link.png new file mode 100644 index 000000000..bb35ac651 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/satellite_link.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/ssh_login.png b/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/ssh_login.png new file mode 100644 index 000000000..25e63cdb7 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/ssh_login.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/ssh_login.svg b/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/ssh_login.svg new file mode 100644 index 000000000..1091eb4fd --- /dev/null +++ b/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/ssh_login.svg @@ -0,0 +1,70 @@ + + + + + + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/vscode_link.png b/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/vscode_link.png new file mode 100644 index 000000000..6808d4969 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.1-setup/images/vscode_link.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/README.md b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/README.md new file mode 100644 index 000000000..e002edbc6 --- /dev/null +++ b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/README.md @@ -0,0 +1,215 @@ +# Workshop Exercise - Three Tier App + +## Table of Contents + +- [Workshop Exercise - Three Tier App](#workshop-exercise---three-tier-app) + - [Table of Contents](#table-of-contents) + - [Objectives](#objectives) + - [Guide](#guide) + - [Three Tier App](#three-tier-app) + - [Step 1 - Set Instance Tags](#step-1---set-instance-tags) + - [Step 2 - Update Ansible Inventory](#step-2---update-ansible-inventory) + - [Step 3 - Install Three Tier Application](#step-3---install-three-tier-application) + - [Step 4 - Smoke Test Three Tier Application](#step-4---open-a-terminal-session) + - [Conclusion](#conclusion) + +## Objectives + +* Install a three tier application stack to provide example of application/workload functionality testing pre/post upgrade. + +## Guide + +### Three Tier App + +This use-case will focus on the in-place upgrade of RHEL to the next major version while maintaining a 3 tier application stack (do no harm). We will utilize an additional project in Ansible Automation Platform, "Three Tier App / Prod", which will allow us to install a three tier application stack, consisting of HAProxy, Tomcat, and PostgreSQL, across the three RHEL nodes. Additionally, the project also provides a means to test/verify functionality of the application components, which we will perform before and after RHEL in-place upgrades. + +| Role | Inventory name | +| -------------------------| ---------------| +| Automation controller | ansible-1 | +| Satellite Server | satellite | +| RHEL Host 1 - HAProxy | node1 | +| RHEL Host 2 - Tomcat | node2 | +| RHEL Host 3 - PostgreSQL | node3 | + +| **A Note about using Satellite vs. Ansible Automation Platform for this...**
| +| ------------- | +| Out of the box, Satellite 6 supports [RHEL systems roles](https://access.redhat.com/articles/3050101) (a collection of Ansible Roles) for a limited set of administration tasks. Satellite can be used to do OS conversions and upgrades, however an Ansible Automation Platform Subscription is required to execute complicated OS conversions and upgrades that require logic to meet up-time requirements. Using these two solutions together ensures you have the best tool for the job for:
- Content Management (Satellite)
- OS Patching & Standardized Operating Environments (Satellite)
- Provisioning: OS, Infra Services and Applications/Other (Satellite and/or Ansible Automation Platform)
- Configuration of Infra and Apps (Ansible Automation Platform)

Reference: [Converting CentOS to RHEL with Red Hat Satellite 6](https://www.redhat.com/en/blog/steps-converting-centos-linux-convert2rhel-and-red-hat-satellite) and [Leapp Upgrade with Satellite 6](https://www.redhat.com/en/blog/leapp-upgrade-using-red-hat-satellite-6)| + +### Step 1 - Set Instance Tags + +- Return to the AAP Web UI browser tab you opened in step 3 of the previous exercise. Navigate to Resources > Templates by clicking on "Templates" under the "Resources" group in the navigation menu. This will bring up a list of job templates that can be used to run playbook jobs on target hosts: + + ![Job templates filtered list](images/set_instance_tags_01.png) + +- In the filter box enter **set instance** and click the magnifying glass. + + ![Access job template details](images/set_instance_tags_02.png) + +- Click on the job template named **EC2 / Set instance tag - RHEL** to view the job template details. + + ![View job template details](images/set_instance_tags_03.png) + +- Click on the variable section expansion icon to view the entire variable definition for the job template. + + ![Expanded job template variables](images/set_instance_tags_04.png) + +- Note the **group_tag_map**...each node is being mapped to a group name which corresponds to the particular application tier role that the node is to serve. Looking at the Ansible playbook that corresonds to this job template: + + ![Ansible playbook for group tags](images/set_instance_tags_06.png) + +- We can see that the **group_tag_map** dictionary is looped through, selecting a particular instace via the *resource: "{{ host_ec2_instance_id[item.key] }}"* filter and then setting the "AnsibleGroup" tag via *AnsibleGroup: "{{ item.value }}" + +- Additionally, the **app_stack_name** tag is set to designate that each node is a member of the same application stack. + +- Click "Done" and then click "Launch" on the **EC2 / Set instance tag - RHEL** job template screen. + + ![View job run details](images/set_instance_tags_05.png) + +- The job run should complete in 8 to 10 seconds. Note the item --> key, value output listing, which corresponds to the instance tag "AnsibleGroup" that is being set respectively on each instance. + +### Step 2 - Update Ansible Inventory + +- Now that we have application tier group tags set, we can update the Ansible inventory to include inventory groups associated with our application stack tiers. However, before we do, let's review how the Ansible inventory update works behind the scenes. + + ![Controller inventories](images/update_controller_inventory_01.png) + +- On the left menu bar, navigate to Resources > Inventories by clicking on "Inventories" under the "Resources" group in the navigation menu, then click on "EC2 Dynamic Inventory". + + ![Controller inventories details](images/update_controller_inventory_02.png) + +- Initially, the **EC2 Dynamic Inventory** inventory details tab will be displayed. Click on the "Sources" tab. + + ![Controller inventories sources](images/update_controller_inventory_03.png) + +- The **EC2 Dynamic Inventory** inventory sources tab will be displayed. Scroll down and click on the "RHEL7 Development" inventory source. + + ![Controller inventories details expand](images/update_controller_inventory_04.png) + +- The **RHEL7 Development** inventory source **Details** view will be displayed. Click on the Source variables expansion button on the side right. + + ![Controller inventories keyed_groups](images/update_controller_inventory_05.png) + +- Scroll down the source variables section until you see "keyed_groups". [Keyed groups](https://docs.ansible.com/ansible/latest/plugins/inventory.html#:~:text=with%20the%20constructed-,keyed_groups,-option.%20The%20option) are where you can define dynamic inventory groups based on instance tags. In this case, when a dynamic inventory generation event is executed, if the EC2 inventory plugin comes across an instance with the "app_stack_name" and "AnsibleGroup" tags, then it will create an inventory group with the name beginning with the value assigned to the "app_stack_name" tag, an "_" (underscore) and then the value assigned to the "AnsibleGroup" tag...so in this case, if the "app_stack_name" tag is currently set to "stack01" and the "AnsibleGroup" tag is set to "appdbs", then the inventory group "stack01_appdbs" will be created (or confirmed if already existing) and that instance will be assigned to the group. + +- Click on "Done" in the Source variables exapanded view. + + ![Controller inventories group](images/update_controller_inventory_sync.png) + +- While still on the **RHEL7 Development** Details view, click on "Sync". The sync should complete in a few seconds. Now, let's verify our dynamic inventory group. + + ![Controller inventories groups](images/update_controller_inventory_06.png) + +- In the menu bar on the left, select "Inventories" --> "EC2 Dynamic Inventories". Once the **EC2 Dynamic Inventory** details screen is displayed, click on the "Groups" tab. + + ![Controller inventories group](images/update_controller_inventory_07.png) + +- The **Groups** defined for the **EC2 Dynamic Inventory** screen is displayed. Scroll down and click on the `stack01_appdbs` group. + + ![Controller inventories group](images/update_controller_inventory_08.png) + +- Initially, the "Details" tab will display. Click on the "Hosts" tab and we will see that `node3.example.com` is present in the "stack01_appdbs" group. Remember earlier, when we reviewed the variables section of the **EC2 / Set instance tag - RHEL** job template? The **group_tag_map** matches up: + +``` + "group_tag_map": { + "node1.example.com": "frontends", + "node2.example.com": "apps", + "node3.example.com": "appdbs" + }, + "app_stack_name": "stack01" +``` + +- Rather than having to navigate to **Inventories > EC2 Dynamic Inventory > Sources > _inventory_source_name_** and clicking "Sync" to initiate sync events, we have put together a job template with surveys and associated Ansible playbook that provides a more convenient method to utilize for this task. Let's review: + +- Navigate to Resources > Templates by clicking on "Templates" under the "Resources" group in the navigation menu. This will bring up a list of job templates that can be used to run playbook jobs on target hosts: + + ![Job templates listed on AAP Web UI](images/update_inventory_01.png) + +- Click ![launch](images/convert2rhel-aap2-launch.png) to the right of **CONTROLLER / Update inventories via dynamic sources**. + + ![Inventory update job survey prompt on AAP Web UI](images/update_inventory_02.png) + +- Next we see the job template survey prompt. A survey is a customizable set of prompts that can be configured from the Survey tab of the job template. For this job template, the survey allows for choosing which part of the inventory will be updated. For "Select inventory to update" choose "RHEL7" from the drop-down and for "Choose Environment" select "Dev" and click the "Next" button. + + ![Inventory update job launch details on AAP Web UI](images/update_inventory_03.png) + +- This will bring you to a preview of the selected job options and variable settings. Click "Launch". + + ![Inventory update job output on AAP Web UI](images/update_inventory_04.png) + +- Survey the job output details...this job run only takes about 5 to 7 seconds to complete. + +### Step 3 - Install Three Tier Application + +- In the AAP Web UI, navigate to Resources > Templates by clicking on "Templates" under the "Resources" group in the navigation menu. This will bring up a list of job templates that can be used to run playbook jobs on target hosts: + + ![Job templates listed on AAP Web UI](images/aap_templates.png) + +- Click ![launch](images/convert2rhel-aap2-launch.png) to the right of **CONVERT2RHEL / 98 - Three Tier App deployment** to launch the job. + +![3tier-install-stack](images/convert2rhel-3tier-install_01.png) + +- For `Choose application stack name`, remember earlier in the inventory tags section, "app_stack_name" was set to "stack01"? So we choose "stack01" from the drop down selection. Then click **Next** and then on the preview screen, click **Launch**. + +This will take ~2 minutes to complete. + +![3tier-install](images/convert2rhel-3tier-install_02.png) + +### Step 4 - Smoke Test Three Tier Application + +Now that our three tier application is installed, let's cover the application stack layout. + +| Host | Component | Port | +| ------------------|------------|-------| +| node1.example.com | HAProxy | 80 | +| node2.example.com | Tomcat | 8080 | +| node3.example.com | PostgreSQL | 5432 | + +node1.example.com proxies incoming requests on port 80 and forwards them to port 8080 on node2.example.com, where Tomcat is running a simple java application that, upon an incoming request to the servlet, creates a table in the PostgreSQL database on node3.example.com, with the table name being constructed from the date and time of the request. For example: + +`Table "21-06-2024-20-52" has been created!` + +If you'd like to manually test the application stack, you can run the following commands by switching your browser to Visual Studio Code terminal, then from `ansible-1` prompt: + +```curl http://node1.example.com``` + +Remember, node1.example.com is a proxy, so the above command displays the default page on node2.example.com + +```curl http://node1.example.com/3ta/connectordbbservlet?``` + +The above will make a request to the Tomcat servlet, where the database table described earlier will be created on the PostgreSQL database on node3.example.com. Without writing out a complete PostgreSQL command cheat sheet, if desired, you can follow the following example command line trail (commands outlined in red rectangles) and check out the PostgreSQL system yourself: + +![3tier-db-check](images/convert2rhel-3tier-db-check.png) + +- Now that we understand the application stack layout, rather than having to use the command line and checking all of the various components manually, let's look at how we can test application stack functionality...via automation! + + ![Job templates listed on AAP Web UI 2](images/aap_templates_2.png) + +- Use the side pane menu on the left to select **Templates**. + +- Click ![launch](images/convert2rhel-aap2-launch.png) to the right of **CONVERT2RHEL / 99 - Three Tier App smoke test** to launch the application test job. + + ![3tier-smoke-test-select](images/convert2rhel-3tier-smoke-select.png) + +- For `Choose application stack name`, remember earlier in the inventory tags section, "app_stack_name" was set to "stack01", so we choose "stack01" from the drop down selection. Then click **Next**, and then on the preview screen, click **Launch**. + +This should take ~15 seconds to complete. + + ![3tier-smoke-test-output](images/convert2rhel-3tier-smoke-output.png) + +- The Ansible playbook utilized by this job template makes a request to the Tomcat servlet via the HAproxy node and records the name of the database table that is presented. The database is then connected to and verifies that in fact a table with the recorded name is present in the database. By utilizing current time and date stamps, we are demonstrating that we are truly working with live systems in real time. + +- If the job template completes successfully, then we have verified that our three tier application stack is functioning correctly. If it fails, we know that something with the application stack is malfunctioning and we can begin the debugging process to determine where the problem resides. + +## Conclusion + +In this exercise, we learned about how to set instance tags to assist with identifying instances. We then turned to looking into how Ansible Automation Platform dynamic inventory sources can be utilized to generate various host groups with a given inventory. We followed that with performing an automated installation of an example three tier application stack. Finally, we verified the three tier application stack functionality via an automated application smoke test. + +Use the link below to move on the the next exercise. + +--- + +**Navigation** + +[Previous Exercise](../1.1-setup/README.md) - [Next Exercise](../1.3-preupg/README.md) + +[Home](../README.md) diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/aap_console_example.svg b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/aap_console_example.svg new file mode 100644 index 000000000..c97421583 --- /dev/null +++ b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/aap_console_example.svg @@ -0,0 +1,2931 @@ + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/aap_link.png b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/aap_link.png new file mode 100644 index 000000000..2810a51be Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/aap_link.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/aap_templates.png b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/aap_templates.png new file mode 100644 index 000000000..7c43fc5e4 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/aap_templates.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/aap_templates_2.png b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/aap_templates_2.png new file mode 100644 index 000000000..bc86ec7eb Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/aap_templates_2.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/convert2rhel-3tier-db-check.png b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/convert2rhel-3tier-db-check.png new file mode 100644 index 000000000..ed3198742 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/convert2rhel-3tier-db-check.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/convert2rhel-3tier-install_01.png b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/convert2rhel-3tier-install_01.png new file mode 100644 index 000000000..d892bfac8 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/convert2rhel-3tier-install_01.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/convert2rhel-3tier-install_02.png b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/convert2rhel-3tier-install_02.png new file mode 100644 index 000000000..7366946e4 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/convert2rhel-3tier-install_02.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/convert2rhel-3tier-smoke-output.png b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/convert2rhel-3tier-smoke-output.png new file mode 100644 index 000000000..ed5163cb4 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/convert2rhel-3tier-smoke-output.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/convert2rhel-3tier-smoke-select.png b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/convert2rhel-3tier-smoke-select.png new file mode 100644 index 000000000..740956d71 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/convert2rhel-3tier-smoke-select.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/convert2rhel-aap2-launch.png b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/convert2rhel-aap2-launch.png new file mode 100644 index 000000000..7246c1d95 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/convert2rhel-aap2-launch.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/set_instance_tags_01.png b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/set_instance_tags_01.png new file mode 100644 index 000000000..7e9634898 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/set_instance_tags_01.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/set_instance_tags_02.png b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/set_instance_tags_02.png new file mode 100644 index 000000000..f6d64fc2b Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/set_instance_tags_02.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/set_instance_tags_03.png b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/set_instance_tags_03.png new file mode 100644 index 000000000..24da8b47c Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/set_instance_tags_03.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/set_instance_tags_04.png b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/set_instance_tags_04.png new file mode 100644 index 000000000..8ac43d013 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/set_instance_tags_04.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/set_instance_tags_05.png b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/set_instance_tags_05.png new file mode 100644 index 000000000..0b5511a85 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/set_instance_tags_05.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/set_instance_tags_06.png b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/set_instance_tags_06.png new file mode 100644 index 000000000..31feb3a4b Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/set_instance_tags_06.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/update_controller_inventory_01.png b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/update_controller_inventory_01.png new file mode 100644 index 000000000..a40d8534c Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/update_controller_inventory_01.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/update_controller_inventory_02.png b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/update_controller_inventory_02.png new file mode 100644 index 000000000..727fd780c Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/update_controller_inventory_02.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/update_controller_inventory_03.png b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/update_controller_inventory_03.png new file mode 100644 index 000000000..1044a0f5a Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/update_controller_inventory_03.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/update_controller_inventory_04.png b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/update_controller_inventory_04.png new file mode 100644 index 000000000..8de8fbe5a Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/update_controller_inventory_04.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/update_controller_inventory_05.png b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/update_controller_inventory_05.png new file mode 100644 index 000000000..02250c2ea Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/update_controller_inventory_05.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/update_controller_inventory_06.png b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/update_controller_inventory_06.png new file mode 100644 index 000000000..7f5774c19 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/update_controller_inventory_06.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/update_controller_inventory_07.png b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/update_controller_inventory_07.png new file mode 100644 index 000000000..6ff48924d Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/update_controller_inventory_07.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/update_controller_inventory_08.png b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/update_controller_inventory_08.png new file mode 100644 index 000000000..9793fd509 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/update_controller_inventory_08.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/update_controller_inventory_sync.png b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/update_controller_inventory_sync.png new file mode 100644 index 000000000..2c0339062 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/update_controller_inventory_sync.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/update_inventory_01.png b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/update_inventory_01.png new file mode 100644 index 000000000..55396084f Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/update_inventory_01.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/update_inventory_02.png b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/update_inventory_02.png new file mode 100644 index 000000000..6d5cb3e5f Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/update_inventory_02.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/update_inventory_03.png b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/update_inventory_03.png new file mode 100644 index 000000000..4b4937040 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/update_inventory_03.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/update_inventory_04.png b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/update_inventory_04.png new file mode 100644 index 000000000..9ce46d3e1 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.2-three-tier-app/images/update_inventory_04.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/README.md b/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/README.md new file mode 100644 index 000000000..fa5adbc7b --- /dev/null +++ b/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/README.md @@ -0,0 +1,179 @@ +# Workshop Exercise - Run Pre-upgrade Jobs + +## Table of Contents + +- [Workshop Exercise - Run Pre-upgrade Jobs](#workshop-exercise---run-pre-upgrade-jobs) + - [Table of Contents](#table-of-contents) + - [Objectives](#objectives) + - [Guide](#guide) + - [Step 1 - RHEL In-place Upgrade Automation Workflow](#step-1---rhel-in-place-upgrade-automation-workflow) + - [Analysis](#analysis) + - [Upgrade](#upgrade) + - [Commit](#commit) + - [Let's Get Started](#lets-get-started) + - [Step 2 - Use AAP to Launch an Analysis Playbook Job](#step-2---use-aap-to-launch-an-analysis-playbook-job) + - [Step 3 - Review the Playbook Job Output](#step-3---review-the-playbook-job-output) + - [Step 4 - Challenge Lab: Analysis Playbook](#step-4---challenge-lab-analysis-playbook) + - [Conclusion](#conclusion) + +## Objectives + +* Understand the end-to-end RHEL in-place upgrade workflow +* Understand how to use AAP job templates to run Ansible playbooks +* Run the pre-upgrade analysis jobs + +## Guide + +### Step 1 - RHEL In-place Upgrade Automation Workflow + +Red Hat Enterprise Linux (RHEL) provides the Leapp utility, the underlying framework that our automation approach uses to upgrade the operating system to the next major version. The [Leapp documentation](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/upgrading_from_rhel_7_to_rhel_8/index) guides users on how to use the Leapp framework to manually upgrade a RHEL host. This is fine if you only have a few RHEL hosts to upgrade, but what if you are a large enterprise with tens, hundreds, a thousand, or even tens of thousands of RHEL hosts? The manual process does not scale. Using automation, the end-to-end process for upgrading a RHEL host is reduced to a matter of days and the total downtime required for the actual upgrade is measured in hours or less. + +Our RHEL in-place upgrade automation approach follows a workflow with three phases: + +![Three phase workflow: Analysis, Upgrade, Commit](images/ripu-workflow.svg) + +> **Note** +> +> The ![arrow pointing down at server](images/playbook_icon.svg) icon indicates workflow steps that are automated by Ansible playbooks. + +#### Analysis + +During the analysis phase, no changes are made yet. When the analysis playbook is executed, it uses the Leapp utility to scan the host for issues or blockers that may prevent a successful upgrade. Then it generates a detailed report listing any potential risks found. The report also includes recommended actions that should be followed to reduce the likelihood of the reported issues impacting the upgrade. If any recommended remediation actions are performed, the analysis scan should be run again to verify the risks are resolved. This iteration continues until everyone reviewing the report is comfortable that any remaining findings are acceptable. + + + +#### Upgrade + +After the analysis phase is done and the report indicates acceptable risk, a maintenance window can be scheduled and the upgrade phase can begin. It is during this phase that the upgrade playbooks are executed using a workflow job template. The first playbook creates a snapshot that can be used for rolling back if anything goes wrong with the upgrade. After the snapshot is created, the second playbook uses the Leapp utility to perform the upgrade where the RHEL OS is advanced to the new major version. The host will not be available for login or application access during the upgrade. When the upgrade is finished, the host will reboot under the newly upgraded RHEL major version. Now the ops and app teams can assess if the upgrade was successful by verifying all application services are working as expected. + +#### Commit + +If there are any application impacts discovered that can't be easily corrected within the scheduled maintenance window, the decision can be made to undo the upgrade by rolling back the snapshot. This will revert all changes and return the host back to the previous RHEL version. If there are no issues immediately found, the commit phase begins. During the commit phase, the host can be returned to normal operation while keeping the snapshot just in case any issues are uncovered later. After everyone is comfortable with the upgraded host, the commit playbook should be executed to delete the snapshot. The RHEL in-place upgrade is done. + +#### Let's Get Started + +The RHEL in-place upgrade automation approach workflow is designed to reduce the risks inherent in doing an in-place upgrade versus deploying a new RHEL host. Decision points at the end of the analysis and upgrade phases allow the process to be rolled back and restarted with the benefit of lessons learned through reporting checks and actual upgrade results. Of course, the best practice for avoiding production impacts or outages is to proceed with upgrades in properly configured Development and Test environments before moving on to Production hosts. + +### Step 2 - Use AAP to Launch an Analysis Playbook Job + +As we progress through the workshop, we'll refer back to this diagram to track where we are in our automation approach workflow. We are starting now in the highlighted block below: + +![Automation approach workflow diagram with analysis step highlighted](images/ripu-workflow-hl-analysis.svg) + +The first step in upgrading our pet app hosts will be executing the analysis playbook to generate the Leapp pre-upgrade report for each host. To do this, we will use the Ansible Automation Platform (AAP) automation controller host that has been pre-configured in your workshop lab environment. + +- Return to the AAP Web UI browser tab you opened in step 3 of the previous exercise. Navigate to Resources > Templates by clicking on "Templates" under the "Resources" group in the navigation menu. This will bring up a list of job templates that can be used to run playbook jobs on target hosts. + +- Before we launch the analysis, all of our RHEL nodes need to be updated to the latest packages available. If you worked through the second exercise in this workshop, **Automating Patch Management**, depending on what options you chose, you might have already patched your RHEL nodes and applied all of the latest package updates available. You can verify if any package updates are available by reviewing the Content Hosts in Satellite. Switch to the broser tab with Satellite and on the left menu bar, select `Hosts > Content Hosts`: + + ![Select Content Hosts on Satellite Web UI](images/satellite_content_hosts_01.png) + +- Here we can see that installed updates are available to be applied. + + ![Content Hosts on Satellite Web UI](images/satellite_content_hosts_02.png) + +- Return to the AAP Web UI browser tab and Navigate to Resources > Templates by clicking on "Templates" under the "Resources" group in the navigation menu. This will bring up a list of job templates that can be used to run playbook jobs on target hosts. + + ![Patch OS to latest on AAP Web UI](images/patch_to_latest_template_menu.png) + +- Click on the **OS / Patch OS to latest** job template. This will display the Details tab of the job template: + + ![Patch OS to latest details on AAP Web UI](images/patch_to_latest_template_details.png) + +- From here, we could use the "Edit" button if we wanted to make any changes to the job template. This job template is already configured, so we are ready to use it to submit a playbook job. To do this, use the "Launch" button. This will display the job template limit and variable dialog: + + !["OS / Patch OS to latest" limit dialog](images/patch_os_limit_dialog.png) + +- We do not need to limit the job to specific hosts, so leave the `Limit` field empty and click "Next". The survey dialog will display: + + !["OS / Patch OS to latest" survey dialog](images/patch_os_survey_dialog.png) + +- Next we see the job template survey dialog. A survey is a customizable set of prompts that can be configured from the Survey tab of the job template. For this job template, the survey allows for selecting the Ansible inventory group, as well as whether or not to include kernel package updates and whether or not to perform a "Check only" operation and not actually update packages, but verify what packages would be updated if we were to perform the update at this moment. We are working with the **RHEL7_Dev** inventory group, so click the "Select inventory group" drop down menu and select "RHEL7_Dev". Leave "Include kernel updates?" at the default "yes" and leave "Check for updates only?" at the default "no". Click "Next". + + !["OS / Patch OS to latest" review dialog](images/patch_os_review_dialog.png) + +- Review the various settings and prompted values for the **OS / Patch OS to latest** job launch. Click "Launch". This job run will require anywhere from three to five minutes to complete. + + !["OS / Patch OS to latest" job output](images/patch_os_job_output.png) + +- With a successful job completion, we are ready to proceed with the pre-upgrade OS analysis. + + !["LEAPP / 01 Analysis" job template seen on AAP Web UI](images/analysis_template.png) + +- On the left menu bar, select `Resources > Templates`. In the filter box, enter `leapp` and click the magnifying glass to filter the job templates displayed. Once the LEAPP job templates are displayed, click ![launch](images/template-aap2-launch.png) to the right of **LEAPP / 01 Analysis** to launch the Leapp analysis job. This will display the job template limit and variable survey dialog: + + ![Analysis job limit prompt on AAP Web UI](images/analysis_limit_prompt.png) + +- The first prompt as seen above allows for limiting the nodes that the analysis job will run against. We want to analyze all of our nodes at this time, so just click the "Next" button to move on. + + ![Analysis job inventory prompt on AAP Web UI](images/analysis_inventory_prompt.png) + +- Next we see the inventory survey prompt. A survey is a customizable set of prompts that can be configured from the Survey tab of the job template. For this job template, the survey allows for choosing a group of hosts on which the job will execute the playbook. Choose the "RHEL7_Dev" option and click the "Next" button. This will bring you to a preview of the selected job options and variable settings. + + ![Analysis job preview on AAP Web UI](images/analysis_preview.png) + +- On the preview dialog, scroll down on the "Prompted Values" section. Note that for our inventory group survey prompt selection of `RHEL7_Dev` in the previous step, the variable `dynamic_inventory_group` has been set to `RHEL7_Dev`. Once satisfied with the job preview, use the "Launch" button to start the playbook job. + +### Step 3 - Review the Playbook Job Output + +After launching the analysis playbook job, the AAP Web UI will navigate automatically to the job output page for the job you just started. + +- While the playbook job is running, you can monitor its progress by clicking the "Follow" button. When you are in follow mode, the output will scroll automatically as task results are streamed to the bottom of job output shown in the AAP Web UI. + +- The analysis playbook will run the Leapp pre-upgrade scan. This will take about three or four minutes to complete. When it is done, you can find a "PLAY RECAP" at the end of the job output showing the success or failure status for the playbook runs executed on each host. A status of "failed=0" indicates a successful playbook run. Scroll to the bottom of the job output and you should see that your job summary looks like this example: + + ![Analysis job "PLAY RECAP" as seen at the end of the job output](images/analysis_job_recap.png) + +### Step 4 - Challenge Lab: Analysis Playbook + +Let's take a closer look at the playbook we just ran. + +> **Tip** +> +> Try looking at the configuration details of the "Automated Management" project and the "LEAPP / 01 Analysis" job template. + +Can you find the upstream source repo and playbook code? + +> **Warning** +> +> **Solution below\!** + +- In the AAP Web UI, navigate to Resources > Projects > Automated Management. Under the Details tab, you will see the "Source Control URL" setting that defines where job templates of this project will go to pull their playbooks. We see it is pointing to this git repo on GitHub: [https://github.com/redhat-partner-tech/automated-satellite](https://github.com/redhat-partner-tech/automated-satellite). Open this URL in a new browser tab. + + ![automated-satellite repo review](images/aap-project-branch-selection.png) + +- With the new tab opened and the `redhat-partner-tech/automated-satellite` repo displayed, on the left side of the browser, click the drop down for the branch selection where `main` is displayed. Click the `aap2-rhdp-prod` branch to select this branch for viewing. + +- Go back to the AAP Web UI and now navigate to Resources > Templates > LEAPP / 01 Analysis. Under the Details tab, you will see the "Playbook" setting with the name of the playbook this job template runs when it is used to submit a job. The playbook name is `leapp_analysis.yml`. In your GitHub browser tab, you can find `leapp_analysis.yml` listed in the files of the git repo. Click on it to see the playbook contents. + +- Notice that after performing some initial automation prepatory steps, the playbook executes the `analysis` role from the `infra.leapp` Ansible collection. +``` + roles: + - infra.leapp.analysis +``` +By checking the `collections/requirements.yml` file in the git repo, we can discover that this role comes from another git repo at [https://github.com/heatmiser/ansible-leapp](https://github.com/heatmiser/ansible-leapp). It is the `analysis` role under this second git repo that provides all the automation tasks that ultimately runs the Leapp pre-upgrade analysis and generates the report. + +*NOTE* We are utilizing a fork of the upstream `infra.leapp` Ansible collection [https://github.com/redhat-cop/infra.leapp](https://github.com/redhat-cop/infra.leapp). Because the upstream collections is a fast moving project, we utilize a fork where we can closely manage the state of the code base to ensure optimal stability for the lab/workshop/demo environment. + + ![infra.leapp fork analysis role](images/infra_leapp_fork_analysis.png) + +- In a new browser tab/instance, open the [https://github.com/heatmiser/ansible-leapp](https://github.com/heatmiser/ansible-leapp/tree/2024-01-07.01) URL. Drill down to the `roles/analysis` directory in this git repo to review the README and yaml source files. + +When you are ready to develop your own custom playbooks to run conversions for your enterprise, you should consider using roles from the `infra.leapp` Ansible collection to make the RHEL in-place upgrade process easier. + +## Conclusion + +In this exercise, we learned about the end-to-end workflow used by our automation approach for doing RHEL in-place upgrades. We used a job template in AAP to submit a playbook job that ran the Leapp pre-upgrade analysis on our three tier application servers. In the challenge lab, we explored the playbook that we ran and how it includes a role from an upstream Ansible collection. + +In the next exercise, we will review the pre-upgrade reports we just generated and take action to resolve any high-risk findings that were identified. + +--- + +**Navigation** + +[Previous Exercise](../1.2-three-tier-app/README.md) - [Next Exercise](../1.4-report/README.md) + +[Home](../README.md) diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/aap-project-branch-selection.png b/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/aap-project-branch-selection.png new file mode 100644 index 000000000..5d898048e Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/aap-project-branch-selection.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/analysis_inventory_prompt.png b/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/analysis_inventory_prompt.png new file mode 100644 index 000000000..d35b45cb9 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/analysis_inventory_prompt.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/analysis_job_recap.png b/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/analysis_job_recap.png new file mode 100644 index 000000000..186da9e1d Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/analysis_job_recap.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/analysis_job_recap.svg b/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/analysis_job_recap.svg new file mode 100644 index 000000000..8706f9dd2 --- /dev/null +++ b/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/analysis_job_recap.svg @@ -0,0 +1,6340 @@ + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/analysis_limit_prompt.png b/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/analysis_limit_prompt.png new file mode 100644 index 000000000..13c003688 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/analysis_limit_prompt.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/analysis_preview.png b/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/analysis_preview.png new file mode 100644 index 000000000..11b01b9e5 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/analysis_preview.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/analysis_template.png b/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/analysis_template.png new file mode 100644 index 000000000..510cc2c4c Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/analysis_template.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/infra_leapp_fork_analysis.png b/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/infra_leapp_fork_analysis.png new file mode 100644 index 000000000..2fc207fe7 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/infra_leapp_fork_analysis.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/patch_os_job_output.png b/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/patch_os_job_output.png new file mode 100644 index 000000000..325405561 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/patch_os_job_output.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/patch_os_limit_dialog.png b/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/patch_os_limit_dialog.png new file mode 100644 index 000000000..69439eff2 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/patch_os_limit_dialog.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/patch_os_review_dialog.png b/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/patch_os_review_dialog.png new file mode 100644 index 000000000..ee634e9eb Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/patch_os_review_dialog.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/patch_os_survey_dialog.png b/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/patch_os_survey_dialog.png new file mode 100644 index 000000000..456347379 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/patch_os_survey_dialog.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/patch_to_latest_template_details.png b/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/patch_to_latest_template_details.png new file mode 100644 index 000000000..551fdcdd8 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/patch_to_latest_template_details.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/patch_to_latest_template_menu.png b/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/patch_to_latest_template_menu.png new file mode 100644 index 000000000..a6be13fa8 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/patch_to_latest_template_menu.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/playbook_icon.svg b/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/playbook_icon.svg new file mode 100644 index 000000000..049810f10 --- /dev/null +++ b/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/playbook_icon.svg @@ -0,0 +1,67 @@ + + + + + + + + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/ripu-workflow-hl-analysis.svg b/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/ripu-workflow-hl-analysis.svg new file mode 100644 index 000000000..6d28f0406 --- /dev/null +++ b/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/ripu-workflow-hl-analysis.svg @@ -0,0 +1,769 @@ + + + +ReviewReportLooksOK?YESNOAnalysis PhaseUpgrade PhaseCommit PhaseLooksOK?App TeamValidationsCan Fix?RollbackYESNONOYESDeleteSnapshotDoneStartApplyRecommendedRemediationRunPre-upgradeAnalysisRunIn-placeUpgradeCreateSnapshot diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/ripu-workflow.svg b/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/ripu-workflow.svg new file mode 100644 index 000000000..889e8d16d --- /dev/null +++ b/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/ripu-workflow.svg @@ -0,0 +1,759 @@ + + + +ReviewReportLooksOK?YESNOAnalysis PhaseUpgrade PhaseCommit PhaseLooksOK?App TeamValidationsCan Fix?RollbackYESNONOYESDeleteSnapshotDoneStartApplyRecommendedRemediationRunPre-upgradeAnalysisRunIn-placeUpgradeCreateSnapshot diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/satellite_content_hosts_01.png b/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/satellite_content_hosts_01.png new file mode 100644 index 000000000..36d7f710c Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/satellite_content_hosts_01.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/satellite_content_hosts_02.png b/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/satellite_content_hosts_02.png new file mode 100644 index 000000000..700abd249 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/satellite_content_hosts_02.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/template-aap2-launch.png b/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/template-aap2-launch.png new file mode 100644 index 000000000..7246c1d95 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.3-preupg/images/template-aap2-launch.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.4-report/README.md b/exercises/rhdp_auto_satellite/4-ripu/1.4-report/README.md new file mode 100644 index 000000000..c4ef8001f --- /dev/null +++ b/exercises/rhdp_auto_satellite/4-ripu/1.4-report/README.md @@ -0,0 +1,171 @@ +# Workshop Exercise - Review Pre-upgrade Reports + +## Table of Contents + +- [Workshop Exercise - Review Pre-upgrade Reports](#workshop-exercise---review-pre-upgrade-reports) + - [Table of Contents](#table-of-contents) + - [Objectives](#objectives) + - [Guide](#guide) + - [Step 1 - Managing Leapp Pre-upgrade Results](#step-1---managing-leapp-pre-upgrade-results) + - [Step 2 - Navigating the RHEL Web Console](#step-2---navigating-the-rhel-web-console) + - [Step 3 - Review Leapp Pre-upgrade Report of RHEL7 Host](#step-3---review-leapp-pre-upgrade-report-of-rhel7-host) + - [Challenge Lab: What About Ignoring So Many High Findings?](#challenge-lab-what-about-ignoring-so-many-high-findings) + - [Conclusion](#conclusion) + +## Objectives + +* Understand the different options for managing Leapp pre-upgrade reports +* Use the RHEL Web Console to review the reports we generated +* Learn how to filter pre-upgrade report entries +* Embrace failure! + +## Guide + +### Step 1 - Managing Leapp Pre-upgrade Results + +In the previous exercise, we used a playbook job template to generate a Leapp pre-upgrade report on each of our three tier app servers. Now we need to review the findings listed in those reports. There are a number of different ways that we can access the reports. Let's review these and consider the pros and cons: + +- If we we're using the Leapp framework to manually upgrade just a single RHEL host, we could simply get to a shell prompt on the host and look at the local report file output. In [Exercise 1.1, Step 2](../1.1-setup/README.md#step-2---open-a-terminal-session), we learned how to open an ssh session to one of our three tier app servers. Follow those steps and after logging in, use this command to review the local Leapp pre-upgrade report file: + + ``` + less /var/log/leapp/leapp-report.txt + ``` + + This is a "quick and dirty" way to review the report, but doesn't scale if you need to review reports for a large number of hosts. + + > **Note** + > + > Use the up and down arrow keys to scroll through the file and type `q` when you are ready to quit the `less` command. + +- If your RHEL hosts are registered to [Red Hat Insights](https://www.redhat.com/en/technologies/management/insights), you can see the Leapp pre-upgrade reports on your Insights console. The three tier app servers provisioned for this workshop are not registered to Insights, so we can't demonstrate this here. Read the blog article [Take the unknowns out of RHEL upgrades with Red Hat Insights](https://www.redhat.com/en/blog/take-unknowns-out-rhel-upgrades-red-hat-insights) to see an example of how Insights can be used to review and manage Leapp pre-upgrades. + +- RHEL includes an optional administration web console based on [Cockpit](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/managing_systems_using_the_rhel_8_web_console/index#what-is-the-RHEL-web-console_getting-started-with-the-rhel-8-web-console) that we call the RHEL Web Console. We will explore how to review the Leapp pre-upgrade reports using the RHEL Web Console in the next step of this exercise. + +- In addition to writing the plain text `leapp-report.txt` file, Leapp also generates a JSON format `leapp-report.json` file. This file includes the same report results as the plain text file, but in JSON format which is perfect for being ingested by log management tools like Elastic/Kibana or Splunk. Many large enterprises will push their pre-upgrade report data to one of these tools to develop their own custom dashboards that can filter reports by environment (e.g., Dev/Test/Prod), location, app ID, owning team, etc. + +### Step 2 - Navigating the RHEL Web Console + +For this workshop, we will be using the RHEL Web Console to access the Leapp pre-upgrade reports we generated. + +- Return to the RHEL Web Console browser tab you opened from [Exercise 1.1, Step 5](../1.1-setup/README.md#step-5---access-the-rhel-web-console). This is the RHEL Web Console of the AAP controller host, but we need to access our three tier app server hosts to see their pre-upgrade reports. Do this by clicking the "student​@​ansible-1.example.com" box in the top left corner of the RHEL Web Console to reveal the remote host menu. For example: + + ![remote host menu listing all three tier app servers](images/remote_host_menu_with_three_tiers.png) + +- You can use the remote host menu to navigate to the web consoles of each of your three tier app servers. Try selecting one of your three tier servers now. The RHEL Web Console system overview page will show the operating system version installed. For example, this three tier app server is running RHEL7: + + ![Operating System Red Hat Enterprise Linux Server 7.9 (Maipo)](images/rhel7_os.png) + +- When navigating to different hosts in the RHEL Web Console, look out for the "limited access mode" warning: + + ![Web console is running in limited access mode](images/limited_access.svg) + + If you see this, use the button to switch to administrative access mode before proceeding. A confirmation will appear like this: + + ![You now have administrative access](images/administrative_access.svg) + +- Take some time to explore the navigation menus available with the RHEL Web Console of your different three tier app servers. Once you feel comfortable navigating around the console and switching between hosts, move on to the next step where we will look at our first pre-upgrade report. + +### Step 3 - Review Leapp Pre-upgrade Report of RHEL7 Host + +Now let's take a look at the report from one of our RHEL7 hosts. + +- Navigate to the RHEL Web Console remote host menu and click on `node1` from your RHEL7 three tier app servers. Verify the host you have chosen is RHEL7. Then use the main menu to navigate to Tools > Upgrade Report. This will bring up the Leapp pre-upgrade report for the selected host. For example, the report might look like this: + + ![Example pre-upgrade report of RHEL7 host](images/rhel7_report.png) + + > **Note** + > + > The contents of your report may differ from the example above because of updates made to the Leapp framework and other RHEL packages released over time since this workshop was written. If you discover any differences that materially break the flow of the exercises in this workshop, kindly let us know by raising an issue [here](https://github.com/redhat-partner-tech/automated-satellite/issues/new). + +- When the pre-upgrade report is generated, the Leapp framework collects system data and assesses upgradeability based on a large collection of checks. When any of these checks uncovers a potential risk, it is recorded as a finding in the report. These findings are listed in order from highest risk to lowest. In the report for our RHEL7 three tier app server above, we see there are six high risk findings and two of those are inhibitor findings. Let's start by reviewing the high risk findings that are not inhibitors. + +- At the top of the list we see the "Packages available in excluded repositories will not be installed" finding. Clicking on the finding to bring up the detailed view, we see this: + + ![Details view of packages available in excluded repositories will not be installed](images/excluded_repos_finding.png) + + This message means the listed packages will not be upgraded as "they are available only in target system repositories that are intentionally excluded from the list of repositories used during the upgrade". + + This finding is warning that packages python3-pyxattr and rpcgen will not be upgraded but then refers to a report message titled "Excluded target system repositories" for details, with the next sentences referencing the packages and the specific repos that supply the packages: `codeready-builder-for-rhel-8-x86_64-rpms`. + + If the packages are required for the system and needs to be upgraded, we have one of two options: + + - Manually enable the relevant repository and install the packages after the in-place upgrade is finished; OR + - Execute leapp with the --enablerepo option with the relevant repository during the in-place upgrade as below + + We can always add follow-up automation that takes care of the package updates post upgrade. And the second option assumes we are manually running the `leapp` command. In an upcoming exercise, we'll explore how this option can be given by setting a variable when submitting the upgrade playbook job. However,the Leapp engineering team most likely has good reason for excluding certain repositories during the upgrade process, so most likely we would want to proceed with option one. + +- The next high risk entry on the list is the "Difference in Python versions and support in RHEL8" finding: + + ![Details view of Difference in Python versions and support in RHEL8 finding](images/python_finding.png) + + This finding could be a concern if we have any apps on our three tier server that are using the system-provided Python interpreter. Let's assume we don't have any of those in which case we can blissfully ignore this finding. + +- The third finding we see listed is titled "Detected modified files of the in-place upgrade tooling." Reviewing the detailed description, the leapp utility has detected "that some files of the tooling processing the in-place upgrade have been modified. Note that such modifications can be allowed only after consultation with Red Hat", specifically mentioning `/var/log/leapp`. The `infra.leapp` Ansible Validated collection that we are utilizing does work within the `/var/log/leapp` directory to monitor the status of leapp utility related processes and actions, however this automation collection is directly sanctioned by Red Hat, so we can ignore this finding. + +- The fourth finding we see listed has the title "GRUB2 core will be automatically updated during the upgrade." You can see additional details for any finding by clicking on it in the list. For example, clicking on the GRUB2 core finding: + + ![Details view of grub core finding](images/grub_core_finding.png) + + Like the finding says, no action is necessary prior to the upgrade, however, a post upgrade verification could be implemented. We'll ignore this one for now, but make a mental note as we may revisit this with a Challenge Lab in a later exercise. + +- That leaves us with our two inhibitor findings. The first is the "Possible problems with remote login using root account" finding. You know the drill; click on the finding to review the details: + + ![Details view of possible problems with remote login using root account inhibitor finding](images/root_account_inhibitor.png) + + Remember that with inhibitor findings, if we don't take action to resolve the inhibitor, the Leapp framework will block the RHEL in-place upgrade from going forward. + +- The other inhibitor is the "Missing required answers in the answer file" finding. Here are the details for this one: + + ![Details view of missing required answers in the answer file](images/missing_answers_inhibitor.png) + + Here again, we will need to take action to remediate this finding. Don't panic! In the next exercise, we will explore different options for automating the required remediation actions and recommendations. + + Additionally, take the time to review the other medium and low risk factor findings across your systems. In this case, we are upgrading our three tier application stack. Reviewing the remainder of the medium and low risk factor findings on node1, nothing significant jumps out. Turning to node2 in the RHEL Web Console and reviewing the Upgrade Report, we see the same high risk factor findings with inhibitors that we already reviewed for node1, same for medium and low risk factors. Finally, doing the same for node3 in the RHEL Web Console and reviewing the Upgrade report, more of the same; high risk factor findings with inhibitors that we are familar with. However, moving on to review the medium and low risk factor findings, we see the following medium finding: + +- "PostgreSQL (postgresql-server) has been detected on your system". Here are the details for this one: + + ![Details view of postgresql detection](images/postgresql_detection.png) + + Details from the finding listing state: "PostgreSQL server component will be upgraded. Since RHEL-8 includes PostgreSQL server 10 by default, which is incompatible with 9.2 included in RHEL-7, it is necessary to proceed with additional steps for the complete upgrade of the PostgreSQL data." + + Remediation recommendation in the listing states: "Back up your data before proceeding with the upgrade and follow steps in the documentation section 'Migrating to a RHEL 8 version of PostgreSQL' after the upgrade." + + So in this case, we'll need to put together some post upgrade automation to work through the updating of PostgreSQL server versions, along with migrating data. + +### Challenge Lab: What About Ignoring So Many High Findings? + +You may be wondering why are we are mostly worrying about the inhibitor findings. What about all the other high risk findings showing up in red on the report? Red means danger! Why would we be going forward with attempting an upgrade without first resolving all the findings on the report? It's a fair question. + +> **Tip** +> +> Think back to the four key features that we introduced at the beginning of the workshop. + +Is there a specific feature that helps with reducing risk? + +> **Warning** +> +> **Solution below\!** + +Of course, the answer is our automated snapshot/rollback capability. + +- If any of the high risk findings listed in the pre-upgrade report ultimately leads to the upgrade failing or results in application compatibility impact, we can quickly get back to where we started by rolling back the snapshot. Before rolling back, we can debug the root cause and use the experience to understand the best way to eliminate the risk of that failure or impact happening in the future. + +- There is a concept explained quite well in the famous article [Fail Fast](http://www.martinfowler.com/ieeeSoftware/failFast.pdf) published in *IEEE Software*. The article dates back to 2004, so this is hardly a new concept. Unfortunately, there is a stigma associated with failure that can lead to excessively risk-averse behavior. The most important benefit of having automated snapshots is being able to quickly revert failures. That allows us to safely adopt a fail fast and fail smart mantra. + +- Of course, there are many best practices we can follow to reduce risk. Obviously, test for application impacts by trying upgrades in your lower environments first. Any issues that can be worked out with Dev and Test servers will help you be prepared to avoid those issues in Production. + +- The high risk findings reported by the Leapp pre-upgrade report are there to make us aware of potential failure modes, but experience has shown that they are not a problem in many cases. Don't become petrified when you see those red findings on the report. Upgrade early and often! + +## Conclusion + +In this exercise, we learned about the different options for managing Leapp pre-upgrade reports. We used the RHEL Web Console to look at the reports we generated in the previous exercise and reviewed a number of the reported findings. In the challenge lab, we explored the importance of snapshots and learned to embrace failure. + +In the next exercise, we are going to look at how to automate the remediation actions required to resolve our inhibitor findings. + +--- + +**Navigation** + +[Previous Exercise](../1.3-preupg/README.md) - [Next Exercise](../1.5-remediate/README.md) + +[Home](../README.md) diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.4-report/images/administrative_access.svg b/exercises/rhdp_auto_satellite/4-ripu/1.4-report/images/administrative_access.svg new file mode 100644 index 000000000..f38097461 --- /dev/null +++ b/exercises/rhdp_auto_satellite/4-ripu/1.4-report/images/administrative_access.svg @@ -0,0 +1,339 @@ + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.4-report/images/excluded_repos_finding.png b/exercises/rhdp_auto_satellite/4-ripu/1.4-report/images/excluded_repos_finding.png new file mode 100644 index 000000000..829afb07e Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.4-report/images/excluded_repos_finding.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.4-report/images/grub_core_finding.png b/exercises/rhdp_auto_satellite/4-ripu/1.4-report/images/grub_core_finding.png new file mode 100644 index 000000000..693d84635 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.4-report/images/grub_core_finding.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.4-report/images/limited_access.svg b/exercises/rhdp_auto_satellite/4-ripu/1.4-report/images/limited_access.svg new file mode 100644 index 000000000..55290ef80 --- /dev/null +++ b/exercises/rhdp_auto_satellite/4-ripu/1.4-report/images/limited_access.svg @@ -0,0 +1,422 @@ + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.4-report/images/missing_answers_inhibitor.png b/exercises/rhdp_auto_satellite/4-ripu/1.4-report/images/missing_answers_inhibitor.png new file mode 100644 index 000000000..7009b995c Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.4-report/images/missing_answers_inhibitor.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.4-report/images/postgresql_detection.png b/exercises/rhdp_auto_satellite/4-ripu/1.4-report/images/postgresql_detection.png new file mode 100644 index 000000000..5ea7c31ba Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.4-report/images/postgresql_detection.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.4-report/images/python_finding.png b/exercises/rhdp_auto_satellite/4-ripu/1.4-report/images/python_finding.png new file mode 100644 index 000000000..681266a2c Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.4-report/images/python_finding.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.4-report/images/remote_host_menu_with_three_tiers.png b/exercises/rhdp_auto_satellite/4-ripu/1.4-report/images/remote_host_menu_with_three_tiers.png new file mode 100644 index 000000000..4c4b1fd87 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.4-report/images/remote_host_menu_with_three_tiers.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.4-report/images/rhel7_os.png b/exercises/rhdp_auto_satellite/4-ripu/1.4-report/images/rhel7_os.png new file mode 100644 index 000000000..ec1628e49 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.4-report/images/rhel7_os.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.4-report/images/rhel7_report.png b/exercises/rhdp_auto_satellite/4-ripu/1.4-report/images/rhel7_report.png new file mode 100644 index 000000000..5538422ac Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.4-report/images/rhel7_report.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.4-report/images/ripu-workflow-hl-review.svg b/exercises/rhdp_auto_satellite/4-ripu/1.4-report/images/ripu-workflow-hl-review.svg new file mode 100644 index 000000000..8e874a9f5 --- /dev/null +++ b/exercises/rhdp_auto_satellite/4-ripu/1.4-report/images/ripu-workflow-hl-review.svg @@ -0,0 +1,769 @@ + + + +ReviewReportLooksOK?YESNOAnalysis PhaseUpgrade PhaseCommit PhaseLooksOK?App TeamValidationsCan Fix?RollbackYESNONOYESDeleteSnapshotDoneStartApplyRecommendedRemediationRunPre-upgradeAnalysisRunIn-placeUpgradeCreateSnapshot diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.4-report/images/root_account_inhibitor.png b/exercises/rhdp_auto_satellite/4-ripu/1.4-report/images/root_account_inhibitor.png new file mode 100644 index 000000000..e21d5c823 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.4-report/images/root_account_inhibitor.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/README.md b/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/README.md new file mode 100644 index 000000000..13cbbff33 --- /dev/null +++ b/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/README.md @@ -0,0 +1,121 @@ +# Workshop Exercise - Perform Recommended Remediation + +## Table of Contents + +- [Workshop Exercise - Perform Recommended Remediation](#workshop-exercise---perform-recommended-remediation) + - [Table of Contents](#table-of-contents) + - [Objectives](#objectives) + - [Guide](#guide) + - [Step 1 - Explore Options for Resolving Inhibitors](#step-1---explore-options-for-resolving-inhibitors) + - [Step 2 - Managing the Leapp Answer File](#step-2---managing-the-leapp-answer-file) + - [Step 3 - Resolving Inhibitors Using a Remediation Playbook](#step-3---resolving-inhibitors-using-a-remediation-playbook) + - [Conclusion](#conclusion) + +## Objectives + +* Consider different options for resolving inhibitor risk findings +* Learn how to use the `leapp_answerfile` variable of the `analysis` role +* Use a remediation playbook to proactively prepare for pre-upgrade + +## Guide + +### Step 1 - Explore Options for Resolving Inhibitors + +In the previous exercise, we reviewed the Leapp pre-upgrade reports that were generated for our RHEL7 three tier application servers. There were a couple inhibitors reported for the RHEL7 hosts. We must take action to resolve them before those hosts can be upgraded. + +We are now here in our automation approach workflow: + +![Automation approach workflow diagram with apply recommended remediations step highlighted](images/ripu-workflow-hl-remediate.svg) + +- Let's start by dissecting one of our inhibitor findings: + + ![Details view of missing required answers in the answer file](images/missing_answers_dissected.svg) + + ![1.](images/circle_1.svg) Each finding has a unique title. + + ![2.](images/circle_2.svg) A risk factor is assigned to each finding, but as we discussed in the previous exercise, this may be more nuanced than can be indicated by a simple High, Medium, Low or Info rating. + + ![3.](images/circle_3.svg) The summary provides a detailed explanation of the risk and solution recommendation. + + ![4.](images/circle_4.svg) Under remediation, we are given a fairly prescriptive recommendation. + + ![5.](images/circle_5.svg) Sometimes, the remediation also includes an exact command like this one. + +- When a remediation command is given such as with the example above, there are a number of options we can choose from for how to execute the command. Obviously, we could go with the quick and dirty method of getting to a root shell prompt on the host to cut and paste the command or manually edit the answerfile. Of course, going that way is prone to human error and doesn't scale well. Another option would be to use the "Run Remediation" button shown above the command. Using this option, the RHEL Web Console executes the command for us. While doing this is less prone to human error, it still doesn't scale well as it's only going to run on this single host. + +- In the next steps, we'll look at how we can use the scale of Ansible Automation Platform (AAP) to perform remediations in bulk across a large RHEL estate. + +### Step 2 - Understanding the Leapp Answer File + +The Leapp framework uses an answer file as a means of accepting user input choices. This is explained in greater detail in the [Asking user questions](https://leapp.readthedocs.io/en/latest/dialogs.html) section of the Leapp developer documentation. The inhibitor finding we dissected in the previous step is looking for us to make a decision or, more specifically, asking us to acknowledge we are aware that Leapp will disable the pam_pkcs11 PAM module during the RHEL upgrade. + +- In [Exercise 1.2 - Run Pre-upgrade Jobs](../1.2-preupg/README.md), we launched a playbook that runs the pre-upgrade report using the `analysis` role from the `infra.leapp` Ansible collection. In reviewing the [documentation for this role](https://github.com/redhat-cop/infra.leapp/blob/main/roles/analysis/README.md), we see that the `analysis` role supports a `leapp_answerfile` input variable. We can set the variable to automatically populate the Leapp answer file during analysis. While that's a convenient way to resolve an answerfile inhibitor, our next inhibitor can't be resolved that way...and we are going to need to perform additional remediations anyway, so we will take care of the Leapp Answer File remediation with a set of remediation automation. + +### Step 3 - Resolving Inhibitors Using a Remediation Playbook + +- Here is our other inhibitor finding: + + ![Details view of missing required answers in the answer file](images/root_account_inhibitor.png) + + Like the previous inhibitor finding, this one also provides a detailed summary and a a fairly prescriptive recommended remediation. However, it does not recommend an exact remediation command. Instead, the remediation recommends making edits to the `/etc/ssh/sshd_config` file. + +- Of course, we're not going to just login to a root shell and `vi` the configuration file, are we? Right, let's make a playbook to automate the required remediations. Here's a task that should do the trick: + + ```yaml + - name: Configure sshd + ansible.builtin.lineinfile: + path: "/etc/ssh/sshd_config" + regex: "^(#)?{{ item.key }}" + line: "{{ item.key }} {{ item.value }}" + state: present + loop: + - {key: "PermitRootLogin", value: "prohibit-password"} + - {key: "PasswordAuthentication", value: "no"} + notify: + - Restart sshd + ``` + + While we're at it, let's also add a task to take care of the answer file inhibitor using the `leapp answer` command. For example: + + ```yaml + - name: Remove pam_pkcs11 module + ansible.builtin.shell: | + set -o pipefail + leapp answer --section remove_pam_pkcs11_module_check.confirm=True + args: + executable: /bin/bash + ``` + +- You will find the tasks above in the playbook [`remediate_rhel7.yml`](https://github.com/redhat-partner-tech/automated-satellite/blob/39b6e82ea9fec5a43d43aa0ab8f9f6e0c7ae1fcf/remediate_rhel7.yml#L22-L39). There are a few more remediation task examples in this playbook as well. The "OS / Remediation" job template is already set up to execute this playbook, so let's use it to remediate our RHEL7 hosts. + +![OS remediation job](images/aap_job_templates_remediate.png) + +- Return to your AAP Web UI browser tab. Navigate to Resources > Templates on the AAP Web UI and find the **OS / Remediation** job template. Click ![launch](images/template-aap2-launch.png) to the right of **OS / Remediation** to launch the remediation job. + +- This will bring you to the job template survey prompt. Again, leave the "Limit" field empty and click "Next". Choose the `RHEL7_Dev` option at the "Select inventory group" prompt. Then click the "Next" button. Review the job preview details and then when ready, click the "Launch" button to submit the job. This playbook includes only a small number of lightweight tasks and should run pretty quickly, completing in approximately 30 seconds. + +- When the **OS / Remediation** job is finished, launch the "LEAPP / 01 Analysis" job template one more time, again leaving the "Limit" field empty and taking care to choose the "RHEL7_Dev" option at the "Select inventory group" prompt. When the job completes, go back to the RHEL Web Console of your RHEL7 `node1` host and refresh the report. You should now see there are no inhibitors: + + ![Pre-upgrade report of RHEL7 host with no more inhibitors](images/rhel7_no_inhibitors.png) + + With the high risk factor inhibitors remediated on our RHEL7 systems, we are ready to proceed along our RHEL upgrade process. + +## Conclusion + +In this exercise, we looked at the different ways we can resolve inhibitor risk findings. We learned that we could potentially utilize the `leapp_answerfile` variable of the `analysis` role to manage the Leapp answer file. Finally, we employed a remediation playbook to demonstrate how we could address pre-upgrade inhibitor findings at scale across our RHEL estate. + +Now we are ready to try upgrading our RHEL three tier app servers, but before we get to that, there are two more optional exercises in this section of the workshop: + +- [Exercise 1.5 - Custom Pre-upgrade Checks](../1.6-custom-modules/README.md) + +These exercises are not required to successfully complete the workshop, but we recommend doing them if time allows. If you can't wait and want skip ahead to upgrading your RHEL hosts, strap in for this exciting exercise: + +- [Exercise 2.1 - Run the RHEL Upgrade Jobs](../2.1-upgrade/README.md) + +--- + +**Navigation** + +[Previous Exercise](../1.4-report/README.md) - [Next Exercise](../1.6-custom-modules/README.md) + +[Home](../README.md) diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/images/aap_job_templates_remediate.png b/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/images/aap_job_templates_remediate.png new file mode 100644 index 000000000..f031d2e0d Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/images/aap_job_templates_remediate.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/images/analysis_leapp_answerfile.svg b/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/images/analysis_leapp_answerfile.svg new file mode 100644 index 000000000..7c2f038c0 --- /dev/null +++ b/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/images/analysis_leapp_answerfile.svg @@ -0,0 +1,3105 @@ + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/images/analysis_survey_rhel7_only.svg b/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/images/analysis_survey_rhel7_only.svg new file mode 100644 index 000000000..af8c01220 --- /dev/null +++ b/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/images/analysis_survey_rhel7_only.svg @@ -0,0 +1,2379 @@ + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/images/circle_1.svg b/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/images/circle_1.svg new file mode 100644 index 000000000..248d75562 --- /dev/null +++ b/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/images/circle_1.svg @@ -0,0 +1,60 @@ + + + + + + + + + + 1 + + + diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/images/circle_2.svg b/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/images/circle_2.svg new file mode 100644 index 000000000..f34f7fb35 --- /dev/null +++ b/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/images/circle_2.svg @@ -0,0 +1,60 @@ + + + + + + + + + + 2 + + + diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/images/circle_3.svg b/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/images/circle_3.svg new file mode 100644 index 000000000..d0f31b7b2 --- /dev/null +++ b/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/images/circle_3.svg @@ -0,0 +1,60 @@ + + + + + + + + + + 3 + + + diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/images/circle_4.svg b/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/images/circle_4.svg new file mode 100644 index 000000000..a0177ee6a --- /dev/null +++ b/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/images/circle_4.svg @@ -0,0 +1,60 @@ + + + + + + + + + + 4 + + + diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/images/circle_5.svg b/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/images/circle_5.svg new file mode 100644 index 000000000..807f47b71 --- /dev/null +++ b/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/images/circle_5.svg @@ -0,0 +1,60 @@ + + + + + + + + + + 5 + + + diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/images/missing_answers_dissected.svg b/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/images/missing_answers_dissected.svg new file mode 100644 index 000000000..05156ae25 --- /dev/null +++ b/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/images/missing_answers_dissected.svg @@ -0,0 +1,147 @@ + + + + + + + + + + + + 1 + + + + 2 + + + + 3 + + + + 4 + + + + 5 + + diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/images/rhel7_answer_fixed.svg b/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/images/rhel7_answer_fixed.svg new file mode 100644 index 000000000..4dae9890a --- /dev/null +++ b/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/images/rhel7_answer_fixed.svg @@ -0,0 +1,4766 @@ + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/images/rhel7_no_inhibitors.png b/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/images/rhel7_no_inhibitors.png new file mode 100644 index 000000000..992ee4444 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/images/rhel7_no_inhibitors.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/images/rhel7_no_inhibitors.svg b/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/images/rhel7_no_inhibitors.svg new file mode 100644 index 000000000..7eae7ee1b --- /dev/null +++ b/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/images/rhel7_no_inhibitors.svg @@ -0,0 +1,4776 @@ + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/images/ripu-workflow-hl-remediate.svg b/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/images/ripu-workflow-hl-remediate.svg new file mode 100644 index 000000000..273ad524c --- /dev/null +++ b/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/images/ripu-workflow-hl-remediate.svg @@ -0,0 +1,769 @@ + + + +ReviewReportLooksOK?YESNOAnalysis PhaseUpgrade PhaseCommit PhaseLooksOK?App TeamValidationsCan Fix?RollbackYESNONOYESDeleteSnapshotDoneStartApplyRecommendedRemediationRunPre-upgradeAnalysisRunIn-placeUpgradeCreateSnapshot diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/images/root_account_inhibitor.png b/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/images/root_account_inhibitor.png new file mode 100644 index 000000000..e21d5c823 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/images/root_account_inhibitor.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/images/template-aap2-launch.png b/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/images/template-aap2-launch.png new file mode 100644 index 000000000..7246c1d95 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/1.5-remediate/images/template-aap2-launch.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.6-custom-modules/README.md b/exercises/rhdp_auto_satellite/4-ripu/1.6-custom-modules/README.md new file mode 100644 index 000000000..950dff24b --- /dev/null +++ b/exercises/rhdp_auto_satellite/4-ripu/1.6-custom-modules/README.md @@ -0,0 +1,164 @@ +# !!WIP!! Workshop Exercise - Custom Modules !!WIP!! +This exercise still needs to be fully completed. + +## Table of Contents + +- [Workshop Exercise - Custom Modules](#workshop-exercise---custom-modules) + - [Table of Contents](#table-of-contents) + - [Optional Exercise](#optional-exercise) + - [Objectives](#objectives) + - [Guide](#guide) + - [Step 1 - What are Custom Modules?](#step-1---what-are-custom-modules) + - [Step 2 - Install a Leapp Custom Actor](#step-2---install-a-leapp-custom-actor) + - [Step 3 - Generate a New Pre-upgrade Report](#step-3---generate-a-new-pre-upgrade-report) + - [Step 4 - Learn More About Customizing the In-place Upgrade](#step-4---learn-more-about-customizing-the-in-place-upgrade) + - [Conclusion](#conclusion) + +## Optional Exercise + +This is an optional exercise. It is not required to successfully complete the workshop, but it's recommended if time allows. Review the objectives listed in the next section to decide if you want to do this exercise or if you would rather skip ahead to the next exercise: + +* [Exercise 2.1 - Run the RHEL Upgrade Jobs](../2.1-upgrade/README.md) + +## Objectives + +* Learn what are custom modules +* Install a Leapp custom actor to implement additional pre-upgrade checks +* See where to go to learn more about making your own custom actors + +## Guide + +### Step 1 - What are Custom Modules? + +Custom modules is a generic term that refers to any custom capabilities that may be layered on the RHEL in-place upgrades automation approach to meet any special requirements unique to your enterprise. + +- For example, maybe your organization has established a standard set of policies that must be followed before doing any system maintenance. In that case, you could implement a Leapp custom actor that will raise a pre-upgrade inhibitor if any conditions are detected that do not comply with your policies. + +- Another use case for custom modules is to deal with 3rd-party tools and agents that are present in your standard RHEL server builds. For example, if you use Chef for configuration convergence, you could implement additional tasks in your upgrade playbook to take care of updating the Chef client package and making any required changes to the Chef node attributes and run list that would be required under the new OS version. + +- We use the generic term "custom modules" because there is no single blueprint for how to design and implement the logic and automation for different organization's diverse requirements. Custom module requirements may call for a Leapp custom actor, custom Ansible automation, or even an integrated design utilizing both. + +- Custom Leapp actors are best for implementing any additional pre-upgrade checks you may need because the results of these checks will be seamlessly included in the pre-upgrade report generated by the Leapp framework. Custom Leapp actors should also be used for any automated tasks that need to be run during the [interim system phase of the Leapp upgrade](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html-single/upgrading_from_rhel_7_to_rhel_8/index#performing-the-upgrade-from-rhel-7-to-rhel-8_upgrading-from-rhel-7-to-rhel-8:~:text=In%20this%20phase%2C%20the%20system%20boots%20into%20a%20RHEL%208%2Dbased%20initial%20RAM%20disk%20image%2C%20initramfs.%20Leapp%20upgrades%20all%20packages%20and%20automatically%20reboots%20to%20the%20RHEL%208%20system.). + +- Developing Leapp custom actors is not as easy compared to just adding tasks to a playbook, so most custom automation requirements are best achieved using Ansible. Tasks can be included in your upgrade playbook before and after the task that imports the `upgrade` role from the `infra.leapp` collection as part of the overall RHEL OS upgrade process. + +### Step 2 - Install a Leapp Custom Actor + +There is a collection of example custom actor at the GitHub repo [oamg/leapp-supplements](https://github.com/oamg/leapp-supplements). We will use one of these to demonstrate adding a custom check to our pre-upgrade reports. + +- The example custom actor we are going to install implements checks for compliance with an imaginary organization's "reboot hygiene" policy. The actor will block the upgrade by reporting inhibitor risk if any of the following conditions are detected: + + - The host uptime is greater than the maximum defined by the policy. + + - The running kernel version does not match the default kernel version configured in the bootloader. + + - The /boot directory has any files that have been modified since the last reboot. + +- Go to your VS Code browser tab and open a terminal session. Refer back to [Exercise 1.1, Step 2](../1.1-setup/README.md#step-2---open-a-terminal-session) if you need a reminder of how we did that. + +- Login to one of your three tier app servers using the `ssh` command. For example: + + ``` + ssh node1 + ``` + +- Now we will install the RPM package that provides our custom actor. Run the following command on your three tier app server: + + ``` + sudo yum -y --enablerepo=leapp-supplements install leapp-upgrade-\*-supplements + ``` + + > **Note** + > + > We are installing the package manually just for the purpose of demonstrating this custom actor. If we were ready to roll out custom actors at enterprise scale, we would include the package installation at the beginning of our analysis playbook. + +- This is an example of the output you should expect to see if the package is installed successfully: + + ``` + Resolving Dependencies + --> Running transaction check + ---> Package leapp-upgrade-el7toel8-supplements.noarch 0:1.0.0-47.demo.el7 will be installed + --> Finished Dependency Resolution + + Dependencies Resolved + + ========================================================================================== + Package Arch Version Repository Size + ========================================================================================== + Installing: + leapp-upgrade-el7toel8-supplements noarch 1.0.0-47.demo.el7 leapp-supplements 12 k + + Transaction Summary + ========================================================================================== + Install 1 Package + + Total download size: 12 k + Installed size: 18 k + Downloading packages: + leapp-upgrade-el7toel8-supplements-1.0.0-47.demo.el7.noarch.rpm | 12 kB 00:00:00 + Running transaction check + Running transaction test + Transaction test succeeded + Running transaction + Installing : leapp-upgrade-el7toel8-supplements-1.0.0-47.demo.el7.noarch 1/1 + Verifying : leapp-upgrade-el7toel8-supplements-1.0.0-47.demo.el7.noarch 1/1 + + Installed: + leapp-upgrade-el7toel8-supplements.noarch 0:1.0.0-47.demo.el7 + + Complete! + ``` + +- To demonstrate the custom actor at work, let's create a condition that violates our policy so that an inhibitor finding will be reported. Use this command: + + ``` + sudo touch /boot/policy-violation + ``` + + With this command, we just created a file under /boot with a timestamp later than the last reboot. This host is now out of compliance with our reboot hygiene policy! + +### Step 3 - Generate a New Pre-upgrade Report + +We are now ready to try running a pre-upgrade report including the checks from our custom actor. + +- Return to your AAP Web UI browser tab. Navigate to Resources > Templates and open the "LEAPP / 01 Analysis" job template. Launch the job leaving "Limit" field empty and choosing the "RHEL7_Dev" option at the "Select inventory group" prompt. + +- When the job completes, go back to the RHEL Web Console and use the remote host menu to navigate to the three tier app server "node1" where you installed the custom actor package. Refresh the pre-upgrade report. You should now see there is a new inhibitor finding. For example: + + ![Pre-upgrade report showing inhibitor finding from custom actor](images/reboot_hygiene.svg) + +- Click on the finding to open the detail view. Here we see the summary with an explanation of the finding and the remediation hint which politely says please reboot: + + ![Finding details reported by reboot hygiene custom actor](images/reboot_hygiene_finding.svg) + +- Reboot the host to resolve the inhibitor finding. For example: + + ``` + sudo reboot + ``` + +- Now generate another pre-upgrade analysis report after rebooting. Verify that this inhibitor finding has disappeared with the new report. + +### Step 4 - Learn More About Customizing the In-place Upgrade + +Read the knowledge article [Customizing your Red Hat Enterprise Linux in-place upgrade](https://access.redhat.com/articles/4977891) to understand best practices for handling the upgrade of third-party packages using custom repositories for an in-place upgrade or custom actors. + +The gritty details of developing Leapp custom actors are beyond the scope of this workshop. Here are some resources you can check out to learn more on your own: + + - [Developer Documentation for Leapp](https://leapp.readthedocs.io/en/latest/): this documentation covers the internal workflow architecture of the Leapp framework and how to develop and test your own custom actors. + + - [Leapp Dashboard](https://oamg.github.io/leapp-dashboard/#/): dig around here to make sure the custom actor functionality you are considering doesn't already exist in the mainstream Leapp framework. + + - [oamg/leapp-supplements](https://github.com/oamg/leapp-supplements): GitHub repo where you can find example custom actors and contribute your own. It also has the `Makefile` for custom actor RPM packaging. + +## Conclusion + +In this exercise, we learned that custom modules can be Leapp custom actors or simply custom tasks added to your upgrade playbook. We demonstrated installing an RPM package that provides an example custom actor with additional pre-upgrade checks and generated a new pre-upgrade report to see it in action. + +--- + +**Navigation** + +[Previous Exercise](../1.5-remediate/README.md) - [Next Exercise](../2.1-upgrade/README.md) + +[Home](../README.md) diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.6-custom-modules/images/reboot_hygiene.svg b/exercises/rhdp_auto_satellite/4-ripu/1.6-custom-modules/images/reboot_hygiene.svg new file mode 100644 index 000000000..23cf9de13 --- /dev/null +++ b/exercises/rhdp_auto_satellite/4-ripu/1.6-custom-modules/images/reboot_hygiene.svg @@ -0,0 +1,4629 @@ + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/4-ripu/1.6-custom-modules/images/reboot_hygiene_finding.svg b/exercises/rhdp_auto_satellite/4-ripu/1.6-custom-modules/images/reboot_hygiene_finding.svg new file mode 100644 index 000000000..f1ff51f6d --- /dev/null +++ b/exercises/rhdp_auto_satellite/4-ripu/1.6-custom-modules/images/reboot_hygiene_finding.svg @@ -0,0 +1,1546 @@ + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/4-ripu/2.1-upgrade/README.md b/exercises/rhdp_auto_satellite/4-ripu/2.1-upgrade/README.md new file mode 100644 index 000000000..65e6fa217 --- /dev/null +++ b/exercises/rhdp_auto_satellite/4-ripu/2.1-upgrade/README.md @@ -0,0 +1,84 @@ +# Workshop Exercise - Run OS Upgrade Jobs + +## Table of Contents + +- [Workshop Exercise - Run OS Upgrade Jobs](#workshop-exercise---run-os-upgrade-jobs) + - [Table of Contents](#table-of-contents) + - [Objectives](#objectives) + - [Guide](#guide) + - [Step 1 - Launch the Upgrade Workflow Job Template](#step-1---launch-the-upgrade-workflow-job-template) + - [Step 2 - Learn More About Leapp](#step-2---learn-more-about-leapp) + - [Conclusion](#conclusion) + +## Objectives + +* Use a workflow job template to create snapshots and start the upgrades +* Learn about how the Leapp framework goes about upgrading the RHEL OS + +## Guide + +We are ready to start the upgrade phase of our RHEL in-place automation journey: + +![Automation approach workflow diagram with upgrade step highlighted](images/ripu-workflow-hl-upgrade.svg) + +It is during this phase that the upgrade playbooks are executed using a workflow job template. The first playbook creates a snapshot that can be used for rolling back if anything goes wrong with the upgrade. After the snapshot is created, the second playbook employs the Leapp utility to perform the upgrade where the host is advanced to the new RHEL major version. + +### Step 1 - Launch the Upgrade Workflow Job Template + +We are about to initiate the RHEL in-place upgrade process for our three tier application servers. The hosts will not be available for login or application access during the upgrade. When the upgrade is finished, the hosts will reboot under the newly upgraded RHEL major version. + +Upgrades typically take less than an hour, although they can run for longer if there are applications that shutdown slowly or with bare metal hosts that have a long reboot cycle. The cloud instances provisioned for our workshop lab environment will upgrade "fairly quickly" as they are very lightweight compared to traditional enterprise app servers. + +- Return to the AAP Web UI tab in your web browser. Navigate to Resources > Templates and then open the "LEAPP / 02 Upgrade" job template. Here is what it looks like: + + ![AAP Web UI showing the upgrade job template details view](images/upgrade_template.png) + +- Click the "Launch" button which will bring up prompts for submitting the job starting with "Other prompts": + + ![Upgrade job limit prompt on AAP Web UI](images/upgrade_limit_prompt.png) + +- Leave the `Limit` field empty and click "Next". + + ![Upgrade job survey prompt on AAP Web UI](images/upgrade_survey_prompt.png) + +- Next we see the survey prompt dialog asking us to select an inventory group. We are going to upgrade all of our "RHEL7_Dev" three tier app hosts using a single job, so choose the `RHEL7_Dev` option and click the "Next" button. This will display a preview of the selected job options and variable settings. + + ![Upgrade job preview on AAP Web UI](images/upgrade_preview.png) + +- Once satisfied with the job preview, use the "Launch" button to start the job. + +### Step 2 - Learn More About Leapp + +After launching the upgrade job, the AAP Web UI will navigate automatically to the workflow job output page of the job we just started. + + ![Leapp upgrade workflow output](images/upgrade_workflow_output.png) + +This job will take up to 20 minutes to finish, so let's take this time to learn a little more about how the Leapp framework upgrades your OS to next RHEL major version. + +- Keep in mind that the Leapp framework is responsible only for upgrading the RHEL OS packages. Additional tasks required for upgrading your standard agents, tools, middleware, databases etc., need to be included in the upgrade playbooks you develop to deal with the specific requirements of your organization's workloads. + +- The Leapp framework performs the RHEL in-place upgrade by following a sequence of phases. These phases are represented in the following diagram: + + ![Leapp upgrade flow diagram](images/inplace-upgrade-workflow-gbg.svg) + +- The steps of the RHEL in-place upgrade are implemented in modules known as Leapp actors. The Leapp framework is message-driven. The execution of actors is dependent on the data produced by other actors running before them. Actors running in the early phases scan the system to produce messages that add findings to the pre-upgrade report as well as messages that later actors use to make decisions or apply changes during the upgrade. + +- Each phase includes three defined stages: before, main, and after. Before and after stages are used to further refine when an actor will be run in relation to any other actors in the phase. Actors are tagged to define the phase and stage during which they are to run. + +- There are three groups of phases: Old System, Interim System, and New System. Phases under the Old System group run under the existing RHEL installed version. The Interim System phases starts after the InitRamStart phase reboots the host to an upgrade initramfs environment under which the network and other services are not started. It is at this time that all RHEL packages can be upgraded. Once all the packages are upgraded, another reboot brings the host up under the new RHEL major version and the FirstBoot phase starts. This final phase runs a few post-upgrade actors that require network access and then the upgrade is complete. + +- Being aware of these phases helps if you need to troubleshoot an issue during the Leapp upgrade and is especially important if you are planning to develop any custom Leapp actors. You can learn more about the Leapp framework architecture and internal design by reading the upstream [Leapp Developer Documentation](https://leapp.readthedocs.io/en/latest/index.html). + +## Conclusion + +In this exercise, we launched a workflow job template to create snapshots and start the upgrade of our three tier app servers. We learned more about the Leapp framework to better understand the RHEL OS upgrade process. + +In the next exercise, we'll learn more about how snapshots work. + +--- + +**Navigation** + +[Previous Exercise](../1.6-custom-modules/README.md) - [Next Exercise](../2.2-snapshots/README.md) + +[Home](../README.md) diff --git a/exercises/rhdp_auto_satellite/4-ripu/2.1-upgrade/images/inplace-upgrade-workflow-gbg.svg b/exercises/rhdp_auto_satellite/4-ripu/2.1-upgrade/images/inplace-upgrade-workflow-gbg.svg new file mode 100644 index 000000000..59072e2b4 --- /dev/null +++ b/exercises/rhdp_auto_satellite/4-ripu/2.1-upgrade/images/inplace-upgrade-workflow-gbg.svg @@ -0,0 +1,2585 @@ + + + + + + + + + + + + + image/svg+xml + + + + + + + + + Main Phases + + Leapp Upgrade Flow + + + Pre-FactsCollection + + + + Facts Collection + + + + Post-FactsCollection + + + + Pre-Checks + + + + Checks + + + + Post-Checks + + + + + + + + + + + + + + + + + + + + + + + + + + + Start + + + + Pre-Report + + + + Report + + + + Post-Report + + + + Pre-Download + + + + Download + + + + Post-Download + + + + Pre-InterimPreparation + + + + InterimPreparation + + + + Post-InterimPreparation + + + + Pre-InitramReboot + + + + Initram Start + + + + Post-InitramStart + + + + Pre-LateTests + + + + Late Tests + + + + Post-LateTests + + + + PrePreparation + + + + Preparation + + + + PostPreparation + + + + Pre-RPMUpgrade + + + + RPM Upgrade + + + + Post-RPMUpgrade + + + + PreApplications + + + + Applications + + + + PostApplications + + + + Pre-Third PartyApplications + + + + Third PartyApplications + + + + Post-Third PartyApplications + + + + PreFinalization + + + + Finalization + + + + PostFinalization + + + + PreReboot + + + + Reboot + + + + PostReboot + + + + Pre-FirstBoot + + + + First Boot + + + + Post-FirstBoot + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Report + + User Interaction + + + + + + + + + + + + + + + + + + + New System + Interim System (Initrd) + Old System + + + + + + + + + Pre-Target TransactionFactsCollection + + + + Target TransactionFacts Collection + + + + Post-Target TransactionFacts Collection + + + + + + + + + + + + + + + + + Pre-Target TransactionCheck + + + Target TransactionCheck + + + Post-Target TransactionCheck + + + + + + + + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/4-ripu/2.1-upgrade/images/ripu-workflow-hl-upgrade.svg b/exercises/rhdp_auto_satellite/4-ripu/2.1-upgrade/images/ripu-workflow-hl-upgrade.svg new file mode 100644 index 000000000..954e14f7c --- /dev/null +++ b/exercises/rhdp_auto_satellite/4-ripu/2.1-upgrade/images/ripu-workflow-hl-upgrade.svg @@ -0,0 +1,780 @@ + + + +ReviewReportLooksOK?YESNOAnalysis PhaseUpgrade PhaseCommit PhaseLooksOK?App TeamValidationsCan Fix?RollbackYESNONOYESDeleteSnapshotDoneStartApplyRecommendedRemediationRunPre-upgradeAnalysisRunIn-placeUpgradeCreateSnapshot diff --git a/exercises/rhdp_auto_satellite/4-ripu/2.1-upgrade/images/upgrade_limit_prompt.png b/exercises/rhdp_auto_satellite/4-ripu/2.1-upgrade/images/upgrade_limit_prompt.png new file mode 100644 index 000000000..b5d417fa6 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/2.1-upgrade/images/upgrade_limit_prompt.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/2.1-upgrade/images/upgrade_preview.png b/exercises/rhdp_auto_satellite/4-ripu/2.1-upgrade/images/upgrade_preview.png new file mode 100644 index 000000000..cfb255e44 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/2.1-upgrade/images/upgrade_preview.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/2.1-upgrade/images/upgrade_preview.svg b/exercises/rhdp_auto_satellite/4-ripu/2.1-upgrade/images/upgrade_preview.svg new file mode 100644 index 000000000..408b716f5 --- /dev/null +++ b/exercises/rhdp_auto_satellite/4-ripu/2.1-upgrade/images/upgrade_preview.svg @@ -0,0 +1,1882 @@ + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/4-ripu/2.1-upgrade/images/upgrade_survey_prompt.png b/exercises/rhdp_auto_satellite/4-ripu/2.1-upgrade/images/upgrade_survey_prompt.png new file mode 100644 index 000000000..41a1afb5e Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/2.1-upgrade/images/upgrade_survey_prompt.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/2.1-upgrade/images/upgrade_template.png b/exercises/rhdp_auto_satellite/4-ripu/2.1-upgrade/images/upgrade_template.png new file mode 100644 index 000000000..1e3ecf2a4 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/2.1-upgrade/images/upgrade_template.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/2.1-upgrade/images/upgrade_vars_prompt.svg b/exercises/rhdp_auto_satellite/4-ripu/2.1-upgrade/images/upgrade_vars_prompt.svg new file mode 100644 index 000000000..fb566968b --- /dev/null +++ b/exercises/rhdp_auto_satellite/4-ripu/2.1-upgrade/images/upgrade_vars_prompt.svg @@ -0,0 +1,1122 @@ + + + + + + + + + diff --git a/exercises/rhdp_auto_satellite/4-ripu/2.1-upgrade/images/upgrade_workflow_output.png b/exercises/rhdp_auto_satellite/4-ripu/2.1-upgrade/images/upgrade_workflow_output.png new file mode 100644 index 000000000..e0b01a885 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/2.1-upgrade/images/upgrade_workflow_output.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/2.2-snapshots/README.md b/exercises/rhdp_auto_satellite/4-ripu/2.2-snapshots/README.md new file mode 100644 index 000000000..366c2e4a4 --- /dev/null +++ b/exercises/rhdp_auto_satellite/4-ripu/2.2-snapshots/README.md @@ -0,0 +1,172 @@ +# Workshop Exercise - Let's Talk About Snapshots + +## Table of Contents + +- [Workshop Exercise - Let's Talk About Snapshots](#workshop-exercise---lets-talk-about-snapshots) + - [Table of Contents](#table-of-contents) + - [Objectives](#objectives) + - [Guide](#guide) + - [Step 1 - What are Snapshots and What are They Not](#step-1---what-are-snapshots-and-what-are-they-not) + - [Step 2 - Assessing Different Snapshot Solutions](#step-2---assessing-different-snapshot-solutions) + - [LVM](#lvm) + - [VMware](#vmware) + - [Amazon EBS](#amazon-ebs) + - [Break Mirror](#break-mirror) + - [ReaR](#rear) + - [Step 3 - Snapshot Scope](#step-3---snapshot-scope) + - [Step 4 - Choosing the Best Snapshot Solution](#step-4---choosing-the-best-snapshot-solution) + - [Conclusion](#conclusion) + +## Objectives + +* Understand the difference between backups and snapshots +* Learn about some of the different ways of doing snapshots +* Be prepared for the challenges and barriers you may encounter automating snapshots +* Consider the appropriate snapshot scope for your organization + +## Guide + +In the previous exercise, we launched the automation to start the RHEL in-place upgrades of our three tier application servers. The first step of the upgrade workflow template is to create a snapshot for each RHEL instance being upgraded. If something goes wrong with an upgrade, the snapshot makes it possible to quickly roll back the upgrade. + +Automating snapshots can be one of the most difficult features of the RHEL in-place upgrade solution approach. In this exercise, we will explore some of the challenges that enterprises face and look at strategies for overcoming them. + +Before proceeding, it is necessary to establish what we are referring to when utilizing the term "snapshots". + +### Step 1 - What Snapshots _Are_ and What They _Are_ _Not_ + +Most organizations with a mature traditional computing environment will have standards and tools implemented for performing backups. Typically, backups will be performed on a periodic schedule. Mission critical or highly dynamic data might be backed up more frequently than mostly static data. Often times, a strategy where full backups are performed occasionally in concert with frequent incremental backups. + +The reason for utilizing backups is to be able to recover data that has been lost for any reason. If data is corrupted because of an operations issue, software defect, or accidentally deleted, backups make it easy to turn the clock back and restore lost data. + +However, when an entire server is lost, using backups to recover is increasingly difficult, because a new operating system must first be installed before anything can be restored from the backup. The data can be spread out across a full backup as well as multiple incremental backups, further increasing the time for a full server recovery. Most organizations only use backup solutions to restore individual files or directories, with full server recoveries often an impossibility. Even if accounted for, full system recoveries require a substantial amount of time to accomplish. + +Snapshots are different in that they do not backup and restore individual files. Instead, backups operate at a storage device level, instantly saving the contents of an entire logical volume or virtual disk. Unlike backups, snapshots do not make a copy of the data being backed up, but rather mark a point in time after which a copy of all modified data is copied going forward. For this reason, the underlying technique used for snapshots is often referred to as "copy-on-write" or COW. + +While COW snapshots are not a substitute for traditional full and incremental backups, they do offer a number of advantages. The most important advantage is that creating and rolling back snapshots happens almost instantaneously as compared to hours or longer for traditional backup and restore. It is this ability to quickly take an entire server back in time that makes snapshots ideal for reducing the risk of performing RHEL in-place upgrades. + +### Step 2 - Assessing Different Snapshot Solutions + +There are a number of different types of snapshot solutions you may choose from. Each has their own benefits and drawbacks as summarized in the table below: + +| Snapshot type | Works with | Benefits | Drawbacks | +| ------------- | ---------- | -------- | --------- | +| LVM |||| +| VMware |||| +| Amazon EBS |||| +| Break Mirror |||| +| ReaR |||| + +The following sections explain the pros and cons in detail. + +#### LVM + +The Logical Volume Manager (LVM) is a set of tools included in RHEL that provide a way to create and manage virtual block devices known as logical volumes. LVM logical volumes are typically used as the block devices from which RHEL OS filesystems are mounted. The LVM tools support creating and rolling back logical volume snapshots. Automating these actions from an Ansible playbook is relatively simple. + +> **Note** +> +> The snapshot and rollback automation capability implemented for our workshop lab environment creates LVM snapshots managed using Ansible roles from the [`infra.lvm_snapshots`](https://github.com/swapdisk/infra.lvm_snapshots#readme) collection. + +Logical volumes are contained in a storage pool known as a volume group. The storage available in a volume group comes from one or more physical volumes, that is, block devices underlying actual disks or disk partitions. Typically, the logical volumes where the RHEL OS is installed will be in a "rootvg" volume group. If best practices are followed, applications and app data will be isolated in their own logicial volumes either in the same volume group or a separate volume group, "appvg" for example. + +To create logical volume snapshots, there must be free space in the volume group. That is, the total size of the logical volumes in the volume group must be less than the total size of the volume group. The `vgs` command can be used query volume group free space. For example: + +``` +# vgs + VG #PV #LV #SN Attr VSize VFree + VolGroup00 1 7 0 wz--n- 29.53g 9.53g +``` + +In the example above, the `VolGroup00` volume group total size is 29.53 GiB and there is 9.53 GiB of free space in the volume group. This should be enough free space to support rolling back a RHEL upgrade. + +If there is not enough free space in the volume group, there are a few ways we can make space available: + +- Adding another physical volume to the volume group (i.e., `pvcreate` and `vgextend`). For a VM, you would first configure an additional virtual disk. +- Temporarily remove a logical volume you don't need. For example, on bare metal servers, there is often a large /var/crash empty filesystem. Removing this filesystem from `/etc/fstab` and then using `lvremove` to remove the logical volume from which it was mounted will free up space in the volume group. +- Reducing the size of one or more logical volumes. This is tricky, because first the filesystem in the logical volume needs to be shrunk. XFS filesystems do not support shrinking. EXT filesystems do support shrinking, but not while the filesystem is mounted. Until recently, this method of freeing up volume group space was considered a last resort to be attempted by only the most skilled Linux admin...but it is _now_ possible to safely automate shrinking logical volumes using the [`shrink_lv`](https://github.com/swapdisk/infra.lvm_snapshots/tree/main/roles/shrink_lv#readme) role of the aforementioned `infra.lvm_snapshots` collection. + +After a snapshot is created, COW data will start to utilize the free space of the snapshot logical volume as blocks are written to the origin logical volume. Unless the snapshot is created with the same size as the origin, there is a chance that the snapshot could fill up and become invalid. Testing should be performed during the development of the LVM snapshot automation to determine snapshot sizings with enough cushion to prevent this. The `snapshot_autoextend_percent` and `snapshot_autoextend_threshold` settings in lvm.conf can also be used to reduce the risk of snapshots running out of space. The [`lvm_snapshots`](https://github.com/swapdisk/infra.lvm_snapshots/tree/main/roles/lvm_snapshots#readme) role of the `infra.lvm_snapshots` collection supports variables that may be used to automatically configure the autoextend settings. + +Unless you have the luxury of creating snapshots with the same size as their origin volumes, LVM snapshot sizing needs to be thoroughly tested, with free space usage carefully monitored. However, if that challenge can be met, LVM snapshots offer a conveneient _and_ reliable snapshot solution without the headache of depending on external infrastructure and/or tooling. + +#### VMware + +A VMware snapshot preserves the state and data of a VM at a specific point in time. Because VMware snapshots operate at the hypervisor level, they are completely independent of the guest OS. This makes them foolproof to anything that can go wrong during a RHEL upgrade. Even if an upgrade fails so badly that the OS can't even be booted up again, reverting the VMware snapshot will still save the day. For these reasons, VMware snapshots appear to be a very compelling snapshot option. + +VMware snapshots can be manually created and reverted using the vSphere management UI. To create or revert a VMware snapshot automatically from an Ansible playbook, access permissions to the required vSphere API calls must be authorized for the AAP control node. + +In our experience, having this access granted can be extremely challenging. The team that controls the VMware environment in most organizations is deeply invested in the "ClickOps" model of doing everything manually using the vSphere management UI. They may also be hesitant to trust that automation developed outside of their team can be trusted to perform the operations they would do manually to create a VMware snapshot, including checking for sufficient free space in the VMFS data store where the snapshot will be created. + +The VMware team may resist supporting snapshots because of limited storage space. While standard VMDK files are fixed in size, COW snapshots will grow over time and require careful monitoring with data stores in VMware environments often running tight on capacity. + +Another justification for pushing back on supporting automated snapshots will be the VMware vendor recommendation that snapshots should never be used for more than 72 hours (see KB article [Best practices for using VMware snapshots in the vSphere environment](https://kb.vmware.com/s/article/1025279)). Unfortunately, app teams usually require more than 3 days of soak time before they are comfortable reporting that no impacts have resulted from a RHEL major version upgrade. + +VMware snapshots work great when they can be automated. If you are considering this option, engage early with the team that controls the VMware environment for your organization and be prepared for potential resistance. + +#### Amazon EBS + +Amazon Elastic Block Store (Amazon EBS) provides the block storage volumes used for the virtual disks attached to AWS EC2 instances. When a snapshot is created for an EBS volume, the COW data is written to Amazon S3 object storage. + +While EBS snapshots operate independently from the guest OS running on the EC2 instance, the similarity to VMware snapshots ends there. An EBS snapshot saves the data of the source EBS volume, but does not save the state or memory of the EC2 instance to which the volume is attached. Also unlike with VMware, EBS snapshots can be created for an OS volume only while leaving any separate application volumes as is. + +Automating EBS snapshot creation and rollback is fairly straightforward, assuming your playbooks can access the required AWS APIs. The tricky bit of the automation is identifying the EC2 instance and attached EBS volume that corresponds to the target host in the Ansible inventory managed by AAP, however, this can be managed by setting identifying tags on your EC2 instances in combination with proper utilization of the modules provided via the `amazon.aws` Ansible collection. + +#### Break Mirror + +This method is an alternative to LVM that can be used with bare metal servers where the root disk is on a hardware RAID mirror set. Technically speaking, it is not a snapshot, but it still provides a near instantaneous rollback capability. + +Instead of creating a snapshot just before starting the upgrade, the automation reconfigures the RAID controller to break the mirror set of the root disk so then it's just two JBOD disks. One of the JBOD disks is used going forward with the upgrade while the other is left untouched. To perform a rollback, the mirror set is reconstructed from the untouched JBOD. + +Most bare metal servers support out-of-band management and those manufactured in the last decade will support APIs based on the [Redfish](https://www.dmtf.org/standards/redfish) standard. These APIs can be used by automation to break and reconstruct the mirror set, but be prepared for a significant development and testing effort because the API implementations are not always the same across different vendors and server models. + +#### ReaR + +ReaR (Relax and Recover) is a backup and recovery tool that is included with RHEL. ReaR doesn't use snapshots, but it does make it very easy to perform a full backup and restore of your RHEL server. When taking a full backup, ReaR creates a bootable ISO image with the current state of the server. To use a ReaR backup to revert an in-place upgrade, we simply boot the server from the ISO image and then choose the "Automatic Recover" option from the menu. + +While ReaR backup and recovery is not instantaneous like rolling back a snapshot, it is remarkably fast compared to recovery tools that require you to perform a fresh OS install and then manually recover at a file level. + +Read the article [ReaR: Backup and recover your Linux server with confidence](https://www.redhat.com/sysadmin/rear-backup-and-recover) to learn more. + +### Step 3 - Snapshot Scope + +The best practice for allocating the local storage of a RHEL servers is to configure volumes that separate the OS from the apps and app data. For example, the OS filesystems would be under a "rootvg" volume group while the apps and app data would be in an "appvg" volume group or at least in their own dedicated logical volumes. This separation helps isolate the storage usage requirements of these two groups so they can be manged based on their individual requirements and are less likely to impact each other. For example, the backup profile for the OS is likely different than for the apps and app data. + +This practice helps to enforce a key tenet of the RHEL in-place upgrade approach: that is that the OS upgrade should leave the applications untouched with the expectation that system library forward compatibility and middleware runtime abstraction reduces the risk of the RHEL upgrade impacting app functionality. + +With these concepts in mind, let's consider if we want to include the apps and app data in what gets rolled back if we need to revert the RHEL upgrade: + +| Snapshot scope | Benefits | Drawbacks | +| -------------- | -------- | --------- | +| OS only ||| +| OS and apps/data ||| + +When snapshots only include the upgraded OS volumes, the best practice of isolating OS changes from app changes is followed. In this case, it is important to resist the temptation to make some heroic app changes in an attempt to avoid rolling back in the face of application impact after a RHEL upgrade. For the sake of safety and soundness, gather the evidence required to help understand what caused any app impact, but then do a rollback. Don't make any app changes that could be difficult to untangle after rolling back the OS. + +Unfortunately, a VMware snapshot saves the full state of a VM instance including all virtual disks irrespective of whether they contain OS or app data. This can prove challenging for a couple reasons. First, more storage space will be required for the snapshots and it is more difficult to anticipate how much snapshot growth will result because of app data activity. The other problem is that rolling back app data may result in the app state becoming out of sync with external systems leading to unpredictable issues. When rolling back app data for any reason, be aware of the potential headaches that may result. + +### Step 4 - Choosing the Best Snapshot Solution + +There are a number of factors you should consider when deciding which method of snapshot/rollback will work best in your environment. + +- What is your mix of bare metal servers versus VMware or cloud instances? +- Where can free space most readily be made available? +- Can you get unfettered access to your VMware inventory and vSphere APIs? +- What is the appropriate snapshot scope for your organization? +- Which snapshot solution can you most easily make fully automated? + +Consider a belt and suspenders approach, that is, offer support for more than one method. Maybe it makes sense to recommend one method for bare metal and another for VMs. + +Whatever your decision, remember that an effective snapshot/rollback capability integrated with your end-to-end automation is the most important feature of any RHEL in-place upgrade solution. + +## Conclusion + +In this exercise, we learned about the pros and cons of a number of different methods of achieving an automated snapshot/rollback capability. We also considered the risks that can happen because of rolling back app data that isn't isolated from OS changes. With this knowledge, you are ready to make more informed decisions when designing your snapshot/rollback automation approach. + +In the next exercise, we'll go back to look at how the RHEL in-place upgrades are progressing on our three tier application servers. + +--- + +**Navigation** + +[Previous Exercise](../2.1-upgrade/README.md) - [Next Exercise](../2.3-check-upg/README.md) + +[Home](../README.md) diff --git a/exercises/rhdp_auto_satellite/4-ripu/2.3-check-upg/README.md b/exercises/rhdp_auto_satellite/4-ripu/2.3-check-upg/README.md new file mode 100644 index 000000000..08f478d04 --- /dev/null +++ b/exercises/rhdp_auto_satellite/4-ripu/2.3-check-upg/README.md @@ -0,0 +1,95 @@ +# Workshop Exercise - Check for successful upgrades + +## Table of Contents + +- [Workshop Exercise - Check for successful upgrades](#workshop-exercise---check-for-successful-upgrades) + - [Table of Contents](#table-of-contents) + - [Objectives](#objectives) + - [Guide](#guide) + - [Step 1 - Review the Upgrade Playbook Job Log](#step-1---review-the-upgrade-playbook-job-log) + - [Step 2 - Verify the Hosts are Upgraded to Next RHEL Version](#step-2---verify-the-hosts-are-upgraded-to-next-rhel-version) + - [Conclusion](#conclusion) + +## Objectives + +* Review the upgrade playbook job log +* Verify our three tier application servers are running the newer RHEL version + +## Guide + +In the previous exercises, we reviewed pre-upgrade reports and performed some recommended remediations. If you tried the optional exercise, you also learned about custom pre-upgrade checks. Subsequently, you launched an Ansible Automation Platform job template to automate the RHEL in-place upgrades on your RHEL three tier application servers. + +It's time to verify the result of the upgrade automation and assess if our three tier application stack is functioning properly. Our current state in regards to the RHEL in-place upgrade automation workflow is as follows: + +![Automation approach workflow diagram with app validation steps highlighted](images/ripu-workflow-hl-validate.svg) + +Let's get started! + +### Step 1 - Review the Upgrade Playbook Job Log + +The first thing we want to do is see if the job running the upgrade playbooks has finished successfully. + +- Return to the AAP Web UI tab in your web browser. Navigate to Views > Jobs and then open the "job number - OS / Upgrade" playbook run entry to see the log output from the upgrades. + + > **Note** + > + > You will also see an entry for the "LEAPP / 02 Upgrade" workflow job. Workflow jobs launch a number of playbook runs. To see the playbook log output, we need to open the specific playbook run entry, not the workflow job entry. + + For example: + + ![AAP Web UI listing upgrade job entries](images/upgrade_jobs.png) + +- If the playbook run finished without any failed tasks, you should see "Successful" displayed with a green checkmark. + + > **Note** + > + > If you see "Running" with spinning arrows, the playbook is still running. Wait for the playbook run to finish before moving on with this exercise. + + Scroll down to the end of the log output to see the "PLAY RECAP" indicating the success or failure status for the playbook run executed on each host. Here is what you should expect to see: + + ![AAP Web UI showing successful upgrade playbook run play recap](images/upgrade_play_recap.png) + + If there are no failed runs, the RHEL in-place upgrade has completed on all of our three tier app servers. + +### Step 2 - Verify the Hosts are Upgraded to Next RHEL Version + +Now, let's verify that all three tier app servers are upgraded to the next RHEL version. + +- In [Exercise 1.4: Step 2](../1.4-report/README.md#step-2---navigating-the-rhel-web-console), the RHEL Web Console was utilized to verify the installed RHEL versions on all three tier app servers. Let's repeat the same steps to verify the RHEL versions reported after the upgrades. + + Return to your RHEL Web Console browser tab and use the remote host menu to navigate to the web consoles of each of your three tier app servers. The RHEL Web Console system overview page should now show the upgraded versions. + + > **Note** + > + > You may need to refresh the browser using Ctrl-R to see the newly reported RHEL version. + + For example, three tier app server `node1` that was previously RHEL7 is now reporting RHEL8: + + ![node1 running Red Hat Enterprise Linux Server 8.8 (Oopta)](images/rhel8_upgraded.png) + +- You can also check the RHEL and kernel versions from the command line following the steps you used with [Exercise 1.1: Step 2](../1.1-setup/README.md#step-2---open-a-terminal-session). + + At the shell prompt of your three tier app servers, use the `cat /etc/redhat-release` and `uname -r` commands. Here's an example showing that three tier app server node1 was upgraded to RHEL8: + + ![command output showing RHEL8 is installed](images/rhel8_commands.png) + +## Conclusion + +In this exercise, we observed that the upgrade playbook job completed successfully. We then used the RHEL Web Console and the command line to verify that the new major RHEL version upgrade was applied. + +If you deployed the sample three tier application in the earlier optional exercise 1.2, continue in the following exercise to verify that the three tier application is still functioning as expected after the RHEL upgrades: + +- [Exercise 2.4 - Check three tier app](../2.4-check-three-tier-app/README.md) + +Otherwise, you may skip ahead to the next section of the workshop where we will demonstrate rolling back the RHEL upgrade, starting with these exercises: + +- [Exercise 3.1 - (Optional) Trash the Instance](../3.1-error-condition/README.md) +- [Exercise 3.2 - Run Rollback Job](../3.2-rollback/README.md) + +--- + +**Navigation** + +[Previous Exercise](../2.2-snapshots/README.md) - [Next Exercise](../2.4-check-three-tier-app/README.md) + +[Home](../README.md) diff --git a/exercises/rhdp_auto_satellite/4-ripu/2.3-check-upg/images/postgresql_database_upgrade_details.png b/exercises/rhdp_auto_satellite/4-ripu/2.3-check-upg/images/postgresql_database_upgrade_details.png new file mode 100644 index 000000000..79e5c1aa8 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/2.3-check-upg/images/postgresql_database_upgrade_details.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/2.3-check-upg/images/rhel8_commands.png b/exercises/rhdp_auto_satellite/4-ripu/2.3-check-upg/images/rhel8_commands.png new file mode 100644 index 000000000..f9dcbcd96 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/2.3-check-upg/images/rhel8_commands.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/2.3-check-upg/images/rhel8_upgraded.png b/exercises/rhdp_auto_satellite/4-ripu/2.3-check-upg/images/rhel8_upgraded.png new file mode 100644 index 000000000..76db96667 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/2.3-check-upg/images/rhel8_upgraded.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/2.3-check-upg/images/ripu-app-failure.png b/exercises/rhdp_auto_satellite/4-ripu/2.3-check-upg/images/ripu-app-failure.png new file mode 100644 index 000000000..ffd9d4565 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/2.3-check-upg/images/ripu-app-failure.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/2.3-check-upg/images/ripu-workflow-hl-validate.svg b/exercises/rhdp_auto_satellite/4-ripu/2.3-check-upg/images/ripu-workflow-hl-validate.svg new file mode 100644 index 000000000..5c7cf1997 --- /dev/null +++ b/exercises/rhdp_auto_satellite/4-ripu/2.3-check-upg/images/ripu-workflow-hl-validate.svg @@ -0,0 +1,780 @@ + + + +ReviewReportLooksOK?YESNOAnalysis PhaseUpgrade PhaseCommit PhaseLooksOK?App TeamValidationsCan Fix?RollbackYESNONOYESDeleteSnapshotDoneStartApplyRecommendedRemediationRunPre-upgradeAnalysisRunIn-placeUpgradeCreateSnapshot diff --git a/exercises/rhdp_auto_satellite/4-ripu/2.3-check-upg/images/upgrade_jobs.png b/exercises/rhdp_auto_satellite/4-ripu/2.3-check-upg/images/upgrade_jobs.png new file mode 100644 index 000000000..cd7f27653 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/2.3-check-upg/images/upgrade_jobs.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/2.3-check-upg/images/upgrade_play_recap.png b/exercises/rhdp_auto_satellite/4-ripu/2.3-check-upg/images/upgrade_play_recap.png new file mode 100644 index 000000000..bcab4424c Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/2.3-check-upg/images/upgrade_play_recap.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/2.4-check-three-tier-app/README.md b/exercises/rhdp_auto_satellite/4-ripu/2.4-check-three-tier-app/README.md new file mode 100644 index 000000000..ec6000c85 --- /dev/null +++ b/exercises/rhdp_auto_satellite/4-ripu/2.4-check-three-tier-app/README.md @@ -0,0 +1,128 @@ +# Workshop Exercise - How is the Three Tier App Doing? + +## Table of Contents + +- [Workshop Exercise - How is the Three Tier App Doing?](#workshop-exercise---how-is-the-three-tier-app-doing) + - [Table of Contents](#table-of-contents) + - [Objectives](#objectives) + - [Guide](#guide) + - [Step 1 - Retest our Three Tier Application](#step-1---retest-our-three-tier-application) + - [Step 2 - Upgrade Three Tier Application Database Version](#step-2---upgrade-three-tier-application-database-version) + - [Step 3 - Test our Three Tier Application - Again](#step-3---test-our-three-tier-application---again) + - [Conclusion](#conclusion) + +## Objectives + +* Confirm our three tier application is still functioning as expected after the conversion +* Understand additional post upgrade automation needs external to Leapp utility +* Add new records to the app database to see what happens when rolling back + +## Guide + +In [Exercise 1.2](../1.2-three-tier-app/README.md) we installed a sample three tier application and tested application functionality via automation. Now that we have upgrade upgrade our RHEL7 application servers to RHEL8, let's retest to see if there has been any impact. + +### Step 1 - Retest our Three Tier Application + +It's time to repeat the testing utilized in [Step 4](../1.2-three-tier-app/README.md#step-4---smoke-test-three-tier-application) of exercise 1.2. + + ![Job templates listed on AAP Web UI 2](images/aap_templates_2.png) + +- Use the side pane menu on the left to select **Templates**. + +- Click ![launch](images/convert2rhel-aap2-launch.png) to the right of **CONVERT2RHEL / 99 - Three Tier App smoke test** to launch the application test job. + + ![3tier-smoke-test-select](images/convert2rhel-3tier-smoke-select.png) + +- For `Choose application stack name`, remember earlier in the inventory tags section, "app_stack_name" was set to "stack01"? So, we choose "stack01" from the drop down selection. Click **Next**, and then on the preview screen, click **Launch**. + +This should take ~15 seconds to complete. + + ![3tier-smoke-test-output](images/rhel8_smoke_test_output_01.png) + +- Uh oh! Something with the application stack is malfunctioning. No worries, though...we have systems snapshots we can rollback to when needed. Inthe meantime, we can begin the debugging process to determine where the problem resides. Hmmm, remember when we were reviewing the high, medium, and low risk factors while reviewing the pre upgrade report? node3 had a medium risk factor that listed postgreSQL as something to keep in mind. + +- Let's check the PostgreSQL service from the command line following the steps you used with [Exercise 1.1: Step 2](../1.1-setup/README.md#step-2---open-a-terminal-session). + + ssh to the PostgreSQL system, node3, and as root, use the `systemctl status postgresql` command to check the PostgreSQL service. Here is an example of the commands utilized: + + ![command output showing postgresql error](images/postgresql_commands.png) + +- Back in when reviewing the pre-upgrade analysis reports in [Exercise 1.4: Step 3](../1.1-setup/README.md# step-3---review-leapp-pre---upgrade-report-of-rhel7-host), for node3, there was a medium risk factor finding for PostgreSQL and the detailed information for that finding stated "...it is necessary to proceed with additional steps for the complete upgrade of the PostgreSQL data." + + This scenario is where the automation team would circle up with the three tier stack PostgreSQL DBAs and put together some automation to work through upgrading the PostgreSQL database to the new version format. For example, the [UpgradePostgres_3TA_AWS.yml](https://github.com/heatmiser/ansible-3tier-app/blob/production/UpgradePostgres_3TA_AWS.yml) playbook in the `Three Tier App / Prod` project. + +### Step 2 - Upgrade Three Tier Application Database Version + +Let's run some automation against the PostgreSQL system to update the PostgreSQL database version. + + ![Job templates listed on AAP Web UI 3](images/aap_templates_3.png) + +- Use the side pane menu on the left to select **Templates**. + +- Click ![launch](images/convert2rhel-aap2-launch.png) to the right of **SERVER / Three Tier App postgresql upgrade** to launch the database upgrade job. + + ![3tier-upgrade-survey](images/convert2rhel-3tier-upgrade-survey.png) + +- For `Choose application stack name`, remember earlier in the inventory tags section, "app_stack_name" was set to "stack01"? So, we choose "stack01" from the drop down selection. + +- For `Select target PostgreSQL version`, the information message provided when we exectuted `systemctl status postgres` on node3 stated "...upgrade to version '10'". Choose "10" from the drop down selection. + +- Click **Next**, and then on the preview screen, click **Launch**. + +This should take just under a minute to complete. + + ![3tier-upgrade-output](images/convert2rhel-3tier-upgrade-output.png) + +### Step 3 - Test our Three Tier Application - Again + +With the PostgreSQL database upgraded, if you are still ssh'ed in as root on node3, you can verify that the database upgrade was successful by executing `systemctl status postgres` from the command line: + + ![command output showing postgresql active](images/postgresql_active.png) + +However, we want to ensure that our application stack is 100% fully functional, so let's use our automated application testing: + + ![Job templates listed on AAP Web UI 2](images/aap_templates_2.png) + +- Use the side pane menu on the left to select **Templates**. + +- Click ![launch](images/convert2rhel-aap2-launch.png) to the right of **CONVERT2RHEL / 99 - Three Tier App smoke test** to launch the application test job. + + ![3tier-smoke-test-select](images/convert2rhel-3tier-smoke-select.png) + +- For `Choose application stack name`, choose "stack01" from the drop down selection. Click **Next**, and then on the preview screen, click **Launch**. + +This should take ~15 seconds to complete. + + ![3tier-smoke-test-output](images/rhel8_smoke_test_output_02.png) + +Success! Our three tier application stack is fully functional, with all nodes running RHEL8! + +### Step 4 - Verify and Record Database Tables + +In [Exercise 2.2](../2.2-snapshots/README.md), we considered the potential pitfalls of including app data in the scope of our snapshot. Imagine what would happen if your app at first appeared fine after the conversion, but an issue was later discovered after the app had been returned to production use. + +- In the Ansible Automtion Platform browser tab, go back and review the previous **CONVERT2RHEL / 99 - Three Tier App smoke test** job output and check the job template output for a task _similar_ to the following line, typically the last task in the job run: + +`TASK [Fail if database db01 did not contain table 26-06-2024-17-56]` + +Remember and/or record this table name to see what happens after we revert the OS conversion in the next section of the workshop. + +> **Note** + > + > The three tier application uses the current time and date to generate the new table names. Your table names are going to be different from the ones listed here in these exercises, as the instructions here were generated in the past. + +- What will be the business impact if data updates are rolled back with the conversion? That is exactly the problem we will demonstrate next, because the three tier application servers deployed in this workshop do not have separate volumes to isolate the OS from the app data. + +## Conclusion + +In this exercise, we observed that while the RHEL In-place Upgrade was successful from a functional operating system standpoint, we found that the three tier application stack was broken after the upgrade process, prompting the need for additional, post-upgrade automation steps. Then we added some new app data via our application functionality verification automation testing. This will permit exploration and understanding of circumstances that can occur after rolling back the upgrade. + +This concludes the RHEL In-Place Upgrade section of the exercise. In the next and final sections, we will be rolling back the upgrade, taking us right back to where we started. + +--- + +**Navigation** + +[Previous Exercise](../2.3-check-upg/README.md) - [Next Exercise](../3.1-error-condition/README.md) + +[Home](../README.md) diff --git a/exercises/rhdp_auto_satellite/4-ripu/2.4-check-three-tier-app/images/aap_templates_2.png b/exercises/rhdp_auto_satellite/4-ripu/2.4-check-three-tier-app/images/aap_templates_2.png new file mode 100644 index 000000000..bc86ec7eb Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/2.4-check-three-tier-app/images/aap_templates_2.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/2.4-check-three-tier-app/images/aap_templates_3.png b/exercises/rhdp_auto_satellite/4-ripu/2.4-check-three-tier-app/images/aap_templates_3.png new file mode 100644 index 000000000..4e4168d9c Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/2.4-check-three-tier-app/images/aap_templates_3.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/2.4-check-three-tier-app/images/convert2rhel-3tier-smoke-output.png b/exercises/rhdp_auto_satellite/4-ripu/2.4-check-three-tier-app/images/convert2rhel-3tier-smoke-output.png new file mode 100644 index 000000000..5fb1a0a64 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/2.4-check-three-tier-app/images/convert2rhel-3tier-smoke-output.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/2.4-check-three-tier-app/images/convert2rhel-3tier-smoke-select.png b/exercises/rhdp_auto_satellite/4-ripu/2.4-check-three-tier-app/images/convert2rhel-3tier-smoke-select.png new file mode 100644 index 000000000..740956d71 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/2.4-check-three-tier-app/images/convert2rhel-3tier-smoke-select.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/2.4-check-three-tier-app/images/convert2rhel-3tier-upgrade-output.png b/exercises/rhdp_auto_satellite/4-ripu/2.4-check-three-tier-app/images/convert2rhel-3tier-upgrade-output.png new file mode 100644 index 000000000..0aa9dfca1 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/2.4-check-three-tier-app/images/convert2rhel-3tier-upgrade-output.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/2.4-check-three-tier-app/images/convert2rhel-3tier-upgrade-survey.png b/exercises/rhdp_auto_satellite/4-ripu/2.4-check-three-tier-app/images/convert2rhel-3tier-upgrade-survey.png new file mode 100644 index 000000000..a80147218 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/2.4-check-three-tier-app/images/convert2rhel-3tier-upgrade-survey.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/2.4-check-three-tier-app/images/convert2rhel-aap2-launch.png b/exercises/rhdp_auto_satellite/4-ripu/2.4-check-three-tier-app/images/convert2rhel-aap2-launch.png new file mode 100644 index 000000000..7246c1d95 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/2.4-check-three-tier-app/images/convert2rhel-aap2-launch.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/2.4-check-three-tier-app/images/postgresql_active.png b/exercises/rhdp_auto_satellite/4-ripu/2.4-check-three-tier-app/images/postgresql_active.png new file mode 100644 index 000000000..38fce012e Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/2.4-check-three-tier-app/images/postgresql_active.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/2.4-check-three-tier-app/images/postgresql_commands.png b/exercises/rhdp_auto_satellite/4-ripu/2.4-check-three-tier-app/images/postgresql_commands.png new file mode 100644 index 000000000..c409e663a Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/2.4-check-three-tier-app/images/postgresql_commands.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/2.4-check-three-tier-app/images/rhel8_smoke_test_output_01.png b/exercises/rhdp_auto_satellite/4-ripu/2.4-check-three-tier-app/images/rhel8_smoke_test_output_01.png new file mode 100644 index 000000000..e9d7683bb Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/2.4-check-three-tier-app/images/rhel8_smoke_test_output_01.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/2.4-check-three-tier-app/images/rhel8_smoke_test_output_02.png b/exercises/rhdp_auto_satellite/4-ripu/2.4-check-three-tier-app/images/rhel8_smoke_test_output_02.png new file mode 100644 index 000000000..7e18c333f Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/2.4-check-three-tier-app/images/rhel8_smoke_test_output_02.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/3.1-error-condition/README.md b/exercises/rhdp_auto_satellite/4-ripu/3.1-error-condition/README.md new file mode 100644 index 000000000..75b7fbd6f --- /dev/null +++ b/exercises/rhdp_auto_satellite/4-ripu/3.1-error-condition/README.md @@ -0,0 +1,105 @@ +# Workshop Exercise - Simulate upgrade failure + +## Table of Contents + +- [Workshop Exercise - Simulate upgrade failure](#workshop-exercise---simulate-upgrade-failure) + - [Table of Contents](#table-of-contents) + - [Optional Exercise](#optional-exercise) + - [Objectives](#objectives) + - [Guide](#guide) + - [Step 1 - Select a Three Tier Application Server](#step-1---select-a-three-tier-application-server) + - [Step 2 - Break your application](#step-2---break-your-application) + - [Conclusion](#conclusion) + +## Optional Exercise + +This is an optional exercise. It is not required to successfully complete the workshop, but it will help demonstrate the effectiveness of rolling back a RHEL upgrade. Review the objectives listed in the next section to decide if you want to do this exercise or if you would rather skip ahead to the next exercise: + +* [Exercise 3.2 - Run Rollback Job](3.2-rollback/README.md) + +## Objectives + +* Simulate a failed OS upgrade or application impact +* Demonstrate the scope of rolling back a snapshot + +## Guide + +Have you ever wanted to try doing `rm -rf /*` on a RHEL host just to see what happens? Or maybe you have accidentally done an equally destructive recursive command and already know the consequences. In this exercise, we are going to intentionally break one of the servers from our three tier application stack to demonstrate how rolling back can save the day. + +Let's get started! + +### Step 1 - Select a Three Tier Application Server + +In the next exercise, we will be rolling back the RHEL upgrade on our three tier application stack. + +- Choose one of the systems from the three tier application stack "stack01": node1, node2, or node3. + +- Follow the steps you used with [Exercise 1.1: Step 2](../1.1-setup/README.md#step-2---open-a-terminal-session) to open a terminal session on the app server you have chosen to break. In this example, we are going to break the tomcat application tier server, node2. + +- At the shell prompt, ssh to node2 and use the `sudo -i` command to switch to the root user. For example: + + ``` + [student@ansible-1 ~]$ ssh node2 + Last login: Wed Jun 26 20:23:52 2024 from 192.168.0.85 + [ec2-user@node2 ~]$ sudo -i + Last login: Wed Jun 26 20:24:06 UTC 2024 on pts/0 + [root@node2 ~]# + ``` + + Verify you see a root prompt like the example above. + +### Step 2 - Break your application + +- When utilizing a 3rd-party JDK runtime package, a pre-upgrade finding warning of a potential risk may occur in some cases. The issue is that in the event that unresolvable dependencies are present, some 3rd-party JDK runtime packages might be removed during the upgrade. Of course, this did not happen in our case, as the three tier application stack utilizes OpenJDK packages provided by Red Hat and our application stack is functioning correctly. + + But what if we were using a 3rd-party JDK and the package was removed? Our three tier application stack utilizes a tomcat application and tomcat requires a JDK runtime to function. Without it, the tomcat application will be broken. We can simulate this by manually removing the package like this: + + ``` + rpm -e --nodeps java-1.8.0-openjdk java-1.8.0-openjdk-headless + ``` + + Now if you `reboot` node2, the three tier application stack will no longer function correctly, as the tomcat application will not be able to start and the following error will be seen when checking the tomcat service status on node2: + + ``` + [root@node2 ~]# reboot + Shared connection to node2 closed. + [student@ansible-1 ~]$ ssh node2 + Web console: https://node2.example.com:9090/ or https://192.168.0.216:9090/ + + Last login: Wed Jun 26 20:42:49 2024 from 192.168.0.85 + [ec2-user@node2 ~]$ sudo -i + [root@node2 ~]# systemctl status tomcat + ● tomcat.service - Apache Tomcat Web Application Container + Loaded: loaded (/usr/lib/systemd/system/tomcat.service; enabled; vendor preset: disabled) + Active: failed (Result: exit-code) since Wed 2024-06-26 21:35:06 UTC; 6min ago + Process: 1286 ExecStart=/usr/libexec/tomcat/server start (code=exited, status=127) + Main PID: 1286 (code=exited, status=127) + + Jun 26 21:35:06 node2.example.com server[1286]: /usr/libexec/tomcat/server: Failed to set JAVACMD + Jun 26 21:35:06 node2.example.com server[1286]: Java virtual machine used: + Jun 26 21:35:06 node2.example.com server[1286]: classpath used: /usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar: + Jun 26 21:35:06 node2.example.com server[1286]: main class used: org.apache.catalina.startup.Bootstrap + Jun 26 21:35:06 node2.example.com server[1286]: flags used: -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory + Jun 26 21:35:06 node2.example.com server[1286]: options used: -Dcatalina.base=/usr/share/tomcat -Dcatalina.home=/usr/share/tomcat -Djava.endorsed.dirs= -Dj> + Jun 26 21:35:06 node2.example.com server[1286]: arguments used: start + Jun 26 21:35:06 node2.example.com server[1286]: /usr/libexec/tomcat/functions: line 24: exec: : not found + Jun 26 21:35:06 node2.example.com systemd[1]: tomcat.service: Main process exited, code=exited, status=127/n/a + Jun 26 21:35:06 node2.example.com systemd[1]: tomcat.service: Failed with result 'exit-code'. + lines 1-16/16 (END) + ``` + + This is a realistic example of an application impact during upgrades that can be reversed by rolling back the upgrade. + +## Conclusion + +Congratulations, you have broken the application stack. Wasn't that fun? + +In the next exercise, you will correct the issue by rolling back the upgrade. + +--- + +**Navigation** + +[Previous Exercise](../2.4-check-pet-app/README.md) - [Next Exercise](../3.2-rollback/README.md) + +[Home](../README.md) diff --git a/exercises/rhdp_auto_satellite/4-ripu/3.2-rollback/README.md b/exercises/rhdp_auto_satellite/4-ripu/3.2-rollback/README.md new file mode 100644 index 000000000..6dac43786 --- /dev/null +++ b/exercises/rhdp_auto_satellite/4-ripu/3.2-rollback/README.md @@ -0,0 +1,95 @@ +# Workshop Exercise - Run Rollback Job + +## Table of Contents + +- [Workshop Exercise - Run Rollback Job](#workshop-exercise---run-rollback-job) + - [Table of Contents](#table-of-contents) + - [Objectives](#objectives) + - [Guide](#guide) + - [Step 1 - Launch the Rollback Job Template](#step-1---launch-the-rollback-job-template) + - [Step 2 - Observe the Rollback Job Output](#step-2---observe-the-rollback-job-output) + - [Step 3 - Check the RHEL Version](#step-3---check-the-rhel-version) + - [Conclusion](#conclusion) + +## Objectives + +* Demonstrate using an Ansible playbook for rolling back a RHEL upgrade +* Verify the RHEL major version is reverted back + +## Guide + +In this exercise, we will demonstrate rolling back the three tier application stack servers, just as we would if the RHEL upgrade had failed or if we had found that the upgrade caused unexpected impacts to the application. + +We are now in the rollback phase of our exploration of the RHEL in-place automation workflow: + +![Automation approach workflow diagram with rollback playbook highlighted](images/ripu-workflow-hl-rollback.svg) + +After rolling back, the three tier application stack will be restored to as it was just before entering the upgrade phase of the workflow. + +### Step 1 - Launch the Rollback Job Template + +In this step, we will be rolling back the RHEL in-place upgrade for our entire three tier application server stack. + +> **Note** +> +> In this case, only one of our nodes has an issue. Depending on overall thoughts on how to best proceed, an argument could be made for just rolling back the tomcat application node, node2, and leave node1 and node3 as they are. However, in this case, we are going to demonstrate the ability to simulataneously roll back an entire application stack of systems at once. + +- Return to the AAP Web UI tab in your web browser. Navigate to Resources > Templates and then open the "LEAPP / 03 Rollback" job template. Here is what it looks like: + + ![AAP Web UI showing the rollback job template details view](images/rollback_template.png) + +- Click the "Launch" button which will bring up the prompts for submitting the workflow starting with the limit prompt. We want to do a rollback of the entire three tier application stack. To do this, we will not enter any values into the "Limit" prompt. + + ![AAP Web UI showing the rollback job limit prompt](images/rollback_prompts.png) + + Click the "Next" button to proceed. + + ![AAP Web UI showing the rollback job survey prompt](images/rollback_survey.png) + +- Next we see the job template survey prompt asking us to select an inventory group. Our systems were upgraded to RHEL8 and we looked in Satellite and verified that the nodes were in fact registered as RHEL8 nodes, configured to consume the RHEL8_Dev content view. So, we should choose "RHEL8_Dev" for our inventory group, yes? Actually, no. We have not _committed_ to keeping the upgraded systems, our system tags that define the current OS and content view have not been updated...so the Ansible inventory still recognizes these systems as members of the "RHEL7_Dev" inventory group. So if we have not initiated the commit automation to accept the converted systems as RHEL8_Dev nodes, we choose the "RHEL7_Dev" option and click the "Next" button. + + ![AAP Web UI showing the rollback job preview prompt](images/rollback_preview.png) + + If everything looks good, use the "Launch" button to start the playbook job. + +### Step 2 - Observe the Rollback Job Output + +After launching the rollback workflow job, the AAP Web UI will navigate automatically to the workflow output visualizer page. + + ![Rollback workflow job visualizer](images/rollback_workflow_job_visual.png) + +- The automated rollback takes only a few minutes to run. You can monitor the log output as the playbook run progresses by clicking directly on the "UTILITY / Snapshot Instance" node in the workflow visualizer. + +- When all of the workflow job nodes have completed (green check mark), if you haven't done so already, click on the "UTILITY / Snapshot Instance" node in the workflow visualizer. Once the "UTILITY / Snapshot Instance" job details displays, click on the "Output" tab and scroll to the bottom of the job output. If it finished successfully, you should see "failed=0" status for each node in the job summary, like this example: + + ![Rollback job "PLAY RECAP" as seen at the end of the job output](images/rollback_job_recap.png) + + Notice in the example above, we see the job completed in aproximately four minutes. However, most of that time was spent in the final "Wait for the snapshot to drain" task which holds the job until the snapshot merges finish in the background. The instance was actually rolled back and service ready in just under a minute. Impressive, right? + +### Step 3 - Check the RHEL Version + +Repeat the steps you followed with [Exercise 2.3: Step 2](../2.3-check-upg/README.md#step-2---verify-the-hosts-are-upgraded-to-next-rhel-version), this time to verify that the RHEL version is reverted back. + +- For example, if the three tier host you rolled back had been upgraded from RHEL7 to RHEL8, you should now see it is back to RHEL7: + + ![command output showing the host is back to RHEL7 installed](images/commands_after_rollback.png) + +- Additionally, we can check Satellite to verify node status. Switching to the Satellite UI in your brwoser, hover over "Hosts" in the left hand menu and then click on "Content Hosts": + + ![Satellite Content Hosts showing RHEL7](images/rollback_satellite_content_hosts.png) + +We can see that the three tier application stack nodes are all reverted to RHEL7 and set to utilize the RHEL7_Dev content view + +## Conclusion + +In this exercise, we used automation to quickly reverse the RHEL in-place upgrade and restore the three tier application stack servers back to their original state. + +In the next exercise, we'll dig deeper to validate that all changes and impacts caused by the upgrade are now undone. + +--- + +**Navigation** + +[Previous Exercise](../3.1-rm-rf/README.md) - [Next Exercise](../3.3-check-undo/README.md) + +[Home](../README.md) diff --git a/exercises/rhdp_auto_satellite/4-ripu/3.2-rollback/images/commands_after_rollback.png b/exercises/rhdp_auto_satellite/4-ripu/3.2-rollback/images/commands_after_rollback.png new file mode 100644 index 000000000..3dbf76955 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/3.2-rollback/images/commands_after_rollback.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/3.2-rollback/images/ripu-workflow-hl-rollback.svg b/exercises/rhdp_auto_satellite/4-ripu/3.2-rollback/images/ripu-workflow-hl-rollback.svg new file mode 100644 index 000000000..1c3f1267b --- /dev/null +++ b/exercises/rhdp_auto_satellite/4-ripu/3.2-rollback/images/ripu-workflow-hl-rollback.svg @@ -0,0 +1,786 @@ + + + +ReviewReportLooksOK?YESNOAnalysis PhaseUpgrade PhaseCommit PhaseLooksOK?App TeamValidationsCan Fix?RollbackYESNONOYESDeleteSnapshotDoneStartApplyRecommendedRemediationRunPre-upgradeAnalysisRunIn-placeUpgradeCreateSnapshot diff --git a/exercises/rhdp_auto_satellite/4-ripu/3.2-rollback/images/rollback_job_recap.png b/exercises/rhdp_auto_satellite/4-ripu/3.2-rollback/images/rollback_job_recap.png new file mode 100644 index 000000000..3458c6d72 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/3.2-rollback/images/rollback_job_recap.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/3.2-rollback/images/rollback_preview.png b/exercises/rhdp_auto_satellite/4-ripu/3.2-rollback/images/rollback_preview.png new file mode 100644 index 000000000..36686ee25 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/3.2-rollback/images/rollback_preview.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/3.2-rollback/images/rollback_prompts.png b/exercises/rhdp_auto_satellite/4-ripu/3.2-rollback/images/rollback_prompts.png new file mode 100644 index 000000000..c156d5482 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/3.2-rollback/images/rollback_prompts.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/3.2-rollback/images/rollback_satellite_content_hosts.png b/exercises/rhdp_auto_satellite/4-ripu/3.2-rollback/images/rollback_satellite_content_hosts.png new file mode 100644 index 000000000..102f2b61f Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/3.2-rollback/images/rollback_satellite_content_hosts.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/3.2-rollback/images/rollback_survey.png b/exercises/rhdp_auto_satellite/4-ripu/3.2-rollback/images/rollback_survey.png new file mode 100644 index 000000000..8eeefbd1a Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/3.2-rollback/images/rollback_survey.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/3.2-rollback/images/rollback_template.png b/exercises/rhdp_auto_satellite/4-ripu/3.2-rollback/images/rollback_template.png new file mode 100644 index 000000000..90502dcec Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/3.2-rollback/images/rollback_template.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/3.2-rollback/images/rollback_workflow_job_visual.png b/exercises/rhdp_auto_satellite/4-ripu/3.2-rollback/images/rollback_workflow_job_visual.png new file mode 100644 index 000000000..f1442e09a Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/3.2-rollback/images/rollback_workflow_job_visual.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/3.3-check-undo/README.md b/exercises/rhdp_auto_satellite/4-ripu/3.3-check-undo/README.md new file mode 100644 index 000000000..e19d075e4 --- /dev/null +++ b/exercises/rhdp_auto_satellite/4-ripu/3.3-check-undo/README.md @@ -0,0 +1,123 @@ +# Workshop Exercise - Check if Upgrade Undone + +## Table of Contents + +- [Workshop Exercise - Check if Upgrade Undone](#workshop-exercise---check-if-upgrade-undone) + - [Table of Contents](#table-of-contents) + - [Objectives](#objectives) + - [Guide](#guide) + - [Step 1 - Our State After Rolling Back](#step-1---our-state-after-rolling-back) + - [Step 2 - What's Next?](#step-2---whats-next) + - [Conclusion](#conclusion) + +## Objectives + +* Validate that all changes and impacts caused by the upgrade are undone after rolling back +* Revisit the topic of snapshot scope +* Consider next steps after rolling back + +## Guide + +In the previous exercise, we rolled back our three tier application servers. Now we will take a closer look at where that has left us and consider next steps. + +### Step 1 - Our State After Rolling Back + +In this step, we will repeat the observations we made on our host after the upgrade with the expectation that everything is back as it was before the upgrade. + +- In the previous exercise, we checked that the RHEL version is reverted back. You can verify this at a shell prompt using commands like `cat /etc/redhat-release` and `uname -r` to output the OS release information and kernel version. You can also refresh the RHEL Web Console to confirm the RHEL version shown on the system overview page. + +- If you inflicted some damage to any of the three tier application servers with the optional [Simulate conversion failure](../3.1-error-condition/README.md) exercise, you will now find no evidence of that. You could switch over to the Ansible Automation Platform UI and run the `CONVERT2RHEL / 99 - Three Tier App smoke test` job template to verify complete application stack functinality. Or check via some of the following: + + For example, did you delete everything with the `rm -rf /*` command or remove the standard C library with the `rpm -e --nodeps glibc` command? Your efforts to nuke the OS have been nullified! + + Did you break your tomcat application server by removing the JDK runtime package? If you check node2 now with the `rpm -qa | grep openjdk` command, you will see the package is installed. + + If you filled up your disk, check now with the `df -h /` command. You will see there is now plenty of free space reported. + + Looking for any app data you added or modified after the upgrade and you will find that all those changes are lost. + + ``` + [student@ansible-1 ~]$ ssh node3 + Last login: Thu Jun 27 05:08:29 2024 from ip-192-168-0-85.us-east-2.compute.internal + [ec2-user@node3 ~]$ sudo su - postgres + Last login: Fri Jun 21 20:48:59 UTC 2024 on pts/0 + -bash-4.2$ psql + psql (9.2.24) + Type "help" for help. + + postgres=# \l + List of databases + Name | Owner | Encoding | Collate | Ctype | Access privileges + -----------+----------+----------+------------+------------+----------------------- + db01 | postgres | UTF8 | en_US.utf8 | en_US.utf8 | =Tc/postgres + + | | | | | postgres=CTc/postgres+ + | | | | | user01=CTc/postgres + postgres | postgres | UTF8 | en_US.utf8 | en_US.utf8 | + template0 | postgres | UTF8 | en_US.utf8 | en_US.utf8 | =c/postgres + + | | | | | postgres=CTc/postgres + template1 | postgres | UTF8 | en_US.utf8 | en_US.utf8 | =c/postgres + + | | | | | postgres=CTc/postgres + (4 rows) + + postgres=# \c db01 + You are now connected to database "db01" as user "postgres". + db01=# \dt + List of relations + Schema | Name | Type | Owner + --------+------------------+-------+-------- + public | 14-06-2024-21-53 | table | user01 + public | 14-06-2024-21-59 | table | user01 + public | 14-06-2024-22-02 | table | user01 + public | 15-06-2024-19-54 | table | user01 + public | 15-06-2024-20-16 | table | user01 + public | 17-06-2024-04-39 | table | user01 + public | 21-06-2024-20-52 | table | user01 + public | 21-06-2024-21-41 | table | user01 + public | 27-06-2024-05-08 | table | user01 + (9 rows) + + db01=# \q + -bash-4.2$ exit + logout + [ec2-user@node3 ~]$ exit + logout + Shared connection to node3 closed. + [student@ansible-1 ~]$ + ``` + Earlier in [exercise section 2.4](../2.4-check-three-tier-app/README.md), the `CONVERT2RHEL / 99 - Three Tier App smoke test` job template was launched to verify application stack functionality prior to rolling back the upgrade. The last task in the job output provided the table name to record: + +`TASK [Fail if database db01 did not contain table 26-06-2024-17-56]` + + Looking at the table listing above, there is a table `27-06-2024-05-08` which corresponds to application functionality verification after the rollback was completed, however, table `26-06-2024-17-56` is not present. + + What does this tell us about the snapshot scope implemented by our rollback playbook? + + Business units will not be happy about loss of data, so make sure to raise awareness of the risk to application data when "everything scope" snapshots are employed. + +### Step 2 - What's Next? + +No matter what the reason is for rolling back, the next step will be to decide what to do next. + +- Maybe you rolled back because there was a failure with the Leapp upgrade itself or some custom automation meant to deal with your standard tools and agents. If so, assess what happened and use the experience to improve your automation to prevent similar issues going forward. + + Developing robust automation is an iterative process. Remember it's good to fail fast! Failed upgrades early in the development of your automation should be expected and will inform you about what adjustments need to be implemented along the way. Having an automated rollback capability helps accelerate the development of robust playbooks. + +- What if you rolled back because application impact was discovered after the upgrade. In this case, it's important for the app team to investigate the cause of the impact. Once the cause is understood, roll back so what was learned can be applied to avoid the issue for subsequent upgrades. + + Understanding the cause of application impacts is also an iterative process. App teams must take the time required to fully assess any application issues when upgrading their dev and test servers, rolling back as often as needed. Use the lower environments in this manner so full preparations can be made before moving to production. + +- After rolling back, the last pre-upgrade report generated before the upgrade will still be available. If no significant changes are made after rolling back, it is not necessary to generate a fresh pre-upgrade report before implementing any new/additional automation and trying another upgrade. + +## Conclusion + +In this exercise section, we reviewed the state of our three tier application servers after rolling back and we considered next steps for some different scenarios. + +In the next and final section of the exercise, we'll review what we learned and explore some additional things you may want to play with in the workshop lab environment. + +--- + +**Navigation** + +[Previous Exercise](../3.2-rollback/README.md) - [Next Exercise](../3.4-conclusion/README.md) + +[Home](../README.md) diff --git a/exercises/rhdp_auto_satellite/4-ripu/3.4-conclusion/README.md b/exercises/rhdp_auto_satellite/4-ripu/3.4-conclusion/README.md new file mode 100644 index 000000000..9ff7c2e5b --- /dev/null +++ b/exercises/rhdp_auto_satellite/4-ripu/3.4-conclusion/README.md @@ -0,0 +1,86 @@ +# Workshop Exercise - Rinse and Repeat + +## Table of Contents + +- [Workshop Exercise - Rinse and Repeat](#workshop-exercise---rinse-and-repeat) + - [Table of Contents](#table-of-contents) + - [Objectives](#objectives) + - [Guide](#guide) + - [Step 1 - What You Learned](#step-1---what-you-learned) + - [Step 2 - Activities for Extra Credit](#step-2---activities-for-extra-credit) + - [Step 3 - Look at the Code](#step-3---look-at-the-code) + - [redhat-cop/infra.leapp](#redhat-copinfraleapp) + - [oamg/leapp-supplements](#oamgleapp-supplements) + - [redhat-partner-tech/automated-satellite](#redhat-partner-techautomated-satellite) + - [redhat-cop/infra.lvm_snapshots](#redhat-copinfralvm_snapshots) + - [Thank You!](#thank-you) + +## Objectives + +* Review what we have learned in this workshop +* Consider ideas for further exploration +* Look at the code and get involved upstream + +## Guide + +Congratulations! You have reached the end of the RHEL In-place Upgrade Automation exercises. You are now armed with the knowledge needed to start developing an automation solution to help your organization manage RHEL upgrades at scale. + +Let's review what we learned and think about what's next. + +### Step 1 - What You Learned + +With these exercises, you gained hands-on experience while learning about a prescriptive approach to automating RHEL in-place upgrades. + +- You upgraded only a handful of RHEL cloud instances while progressing through the workshop exercises, but with the power of an enterprise deployment of AAP, this approach can be rolled out at scale across a large fleet of RHEL hosts. + +- You learned why automated snapshot/rollback is one of the most important capabilities required to successfully deliver RHEL in-place upgrade automation. Snapshots not only eliminate the risk and anxiety experienced by an app team facing a RHEL upgrade, but they also help accelerate the development of robust upgrade automation playbooks. + +- You also learned about the custom automation that must be developed to deal with the complex requirements of a large enterprise environment. We demonstrated a few examples of this including using Leapp custom actors for reporting special pre-upgrade checks as well as running Ansible playbooks to handle common remediations and third-party tools and agents. + +- But the most important lesson we learned is "You can do this!" + +### Step 2 - Activities for Extra Credit + +Hopefully, these exercises have opened your eyes to what is possible, but we have just scratched the surface. + +- Is it possible to upgrade from RHEL7 to RHEL9? While the Leapp framework doesn't support a "double upgrade" directly, it is possible to take a host that was upgraded from RHEL7 to RHEL8 and then upgrade it from there to RHEL9. You can try this with the three tier application instances in the workshop lab. + + There are a couple things to be aware of if you want to try it. You will first need to run the "LEAPP / 04 Commit" playbook job template. This job will delete the snapshot created for your RHEL7 to RHEL8 upgrade, so be sure you are happy with everything before you do this. While rolling back to RHEL7 will no longer be possible, you will be able to roll back to RHEL8 if needed after upgrading to RHEL9. + + Another consideration with going from RHEL7 to RHEL9 is the increased risk of application impacts. While RHEL system library forward binary compatibility is really solid between each RHEL major version, "N+2" compatibility is not guaranteed. Of course, the only way to know for sure is try it! + +- If you skipped over any of the optional exercises, it's not too late to go back and try them now: + +- The workshop lab environment is now yours to play with. Dream up your own ideas for additional learning and experimentation. Remember you can upgrade and roll back as often as you like. Rinse and repeat! + +### Step 3 - Look at the Code + +All of the Ansible roles and playbooks used in this workshop are maintained in upstream repositories that can be found on GitHub. Take some time to review the code and get engaged with the communities supporting these resources. + +#### [redhat-cop/infra.leapp](https://github.com/redhat-cop/infra.leapp) + +- The `infra.leapp` collection provides the Ansible role that generates the pre-upgrade reports and another that is used to perform the RHEL upgrades. This collection uses the Leapp framework for upgrades from RHEL7 and later, but also supports upgrading from RHEL6 using the older Red Hat Upgrade Tool. The collection is published on Ansible Galaxy [here](https://galaxy.ansible.com/infra/leapp) and also available from Ansible Automation Hub validated content [here](https://console.redhat.com/ansible/automation-hub/repo/validated/infra/leapp/). If you are planning to do RHEL in-place upgrades for your organization, these roles will help you quickly roll out proof-of-concept automation and start upgrading. + +#### [oamg/leapp-supplements](https://github.com/oamg/leapp-supplements) + +- Leapp Supplements is a repository of example Leapp custom actors. The CheckRebootHygiene actor that was demonstrated in the optional [Custom Pre-upgrade Checks](../1.5-custom-modules/README.md) exercise is maintained here. There is also a Makefile and RPM spec file that can be used to build packages for installing your Leapp custom actors. + +#### [redhat-partner-tech/automated-satellite](https://github.com/redhat-partner-tech/automated-satellite) + +- This is where you will find all of the AAP job templates and Ansible playbooks included in the workshop, specifically the `aap2-rhdp-prod` and `aap2-rhdp-dev` code branches. You can also explore the infrastructure/configuration as code (IaC/CaC) magic that is used to provision the workshop lab environment. + +#### [redhat-cop/infra.lvm_snapshots](https://github.com/redhat-cop/infra.lvm_snapshots) + +- Here you will find the upstream project used to build the Ansible collection for managing snapshot sets using LVM. If you are interested in automating LVM snapshots as explained in the [Let's Talk About Snapshots](../2.2-snapshots/README.md#lvm) exercise, review this collection project to get in on the action. + +## Thank You! + +If you enjoyed this workshop, please take a moment to give it a rating or write a review. If you have any ideas for improvements or new features, don't hesitate to raise an issue [here](https://github.com/redhat-cop/agnosticd/issues/new/choose), reference the workshop name `Ansible Workshop - Automated Satellite Workshop` and tagging/mentioning `@heatmiser` within the issue. All ideas and feedback are welcome! + +--- + +**Navigation** + +[Previous Exercise](../3.3-check-undo/README.md) + +[Home](../README.md) diff --git a/exercises/rhdp_auto_satellite/4-ripu/README.md b/exercises/rhdp_auto_satellite/4-ripu/README.md new file mode 100644 index 000000000..9d13ca5d1 --- /dev/null +++ b/exercises/rhdp_auto_satellite/4-ripu/README.md @@ -0,0 +1,77 @@ +# Automated Satellite Workshop: RHEL In-place Upgrade Automation exercise + +This exercise will introduce a comprehensive approach to automate in-place upgrades for Red Hat Enterprise Linux (RHEL). The solution uses Ansible Automation Platform (AAP) to execute upgrades at enterprise scale across a large estate of RHEL hosts. The exercise demonstrates how to use an example of this approach to perform upgrades from RHEL7 to RHEL8 and from RHEL8 to RHEL9. You will also learn about how this solution can be customized to meet the special requirements of your enterprise environment. + +There are four key features that the solution approach recommends to deliver success at scale: + +![Automate Everything, Snapshot/rollback, Custom Modules, Reporting Dashboard](images/ripu_key_features.svg) + +As you progress through this exercise, you will learn more about the importance of these features and the different options for how you might implement them in your enterprise. For this exercise, we assume you have at least some experience using Ansible Automation Platform and working with Ansible playbooks and roles. If you're new to Ansible, consider first completing the workshop [Ansible for Red Hat Enterprise Linux](https://aap2.demoredhat.com/exercises/ansible_rhel). + +## Table of Contents + +- [Automated Satellite Workshop: RHEL In-place Upgrade Automation exercise](#automated-satellite-workshop:-rhel-in---place-upgrade-automation-exercise) + - [Table of Contents](#table-of-contents) + - [Presentations](#presentations) + - [Time Planning](#time-planning) + - [Lab Diagram](#lab-diagram) + - [Exercises](#exercises) + - [Section 1 - Pre-upgrade Analysis](#section-1---pre-upgrade-analysis) + - [Section 2 - RHEL OS Upgrade](#section-2---rhel-os-upgrade) + - [Section 3 - Rolling Back](#section-3---rolling-back) + - [Supplemental Exercises](#supplemental-exercises) + - [Workshop Navigation](#workshop-navigation) + +## Presentations + +The exercises are self explanatory and guide the participants through all the phases of an automated RHEL in-place upgrade. All concepts are explained as they are introduced. + +There is an optional presentation deck available with additional information on the benefits of the approach demonstrated in this workshop: +[RHEL In-place Upgrades and Conversions Automation](../decks/ansible_ripu_conversion.pdf) + +## Time Planning + +The time required to complete the exercise depends on the number of participants and how familiar they are with Linux and Ansible. The exercises themselves should take a minimum of ~45 minutes. The introduction in the optional presentation adds 20 to 30 minutes. There are some optional exercises which can be skipped, but are recommended if time allows. Additionally, supplemental exercises at the end of the exercise provide for open-ended experimentation and exploring customizations that may apply to your specific environment and requirements. The lab environment provisioned could even be used for a multi-day deep dive workshop, but that is beyond the scope of this guide. + +## Lab Diagram + +The lab environment provisioned for the exercise includes an Ansible Automation Platform (AAP) controller, a Red Hat Satellite, and a number of RHEL and CentOS instances. The AAP instance is used to run playbook and workflow automation jobs. For this exercise, the jobs are executed against the RHEL 7 hosts which will be upgrade in place to RHEL 8. The automation uses LVM to manage the snapshot/rollback capability. + +![RHEL In-place Upgrade Automation Workshop lab diagram](images/auto_satellite_lab_diagram.png) + +## Exercises + +This exercise is composed of three sections each of which includes a number of steps. Each exercise builds upon the steps performed and concepts learned in the previous exercises, so it is important to do them in the prescribed order. + +### Section 1 - Pre-upgrade Analysis + +* [1.1 - Workshop Lab Environment](1.1-setup/README.md) +* [1.2 - (Optional) Deploy a Three Tier App](1.2-three-tier-app/README.md) +* [1.3 - Run Pre-upgrade Jobs](1.3-preupg/README.md) +* [1.4 - Review Pre-upgrade Reports](1.4-report/README.md) +* [1.5 - Perform Recommended Remediation](1.5-remediate/README.md) +* [1.6 - (Optional) Custom Pre-upgrade Checks](1.6-custom-modules/README.md) + +### Section 2 - RHEL OS Upgrade + +* [2.1 - Run OS Upgrade Jobs](2.1-upgrade/README.md) +* [2.2 - Let's Talk About Snapshots](2.2-snapshots/README.md) +* [2.3 - Check if the Upgrade Worked](2.3-check-upg/README.md) +* [2.4 - (Optional) How is the Three Tier App Doing?](2.4-check-three-tier-app/README.md) + +### Section 3 - Rolling Back + +* [3.1 - (Optional) Trash the Instance](3.1-error-condition/README.md) +* [3.2 - Run Rollback Job](3.2-rollback/README.md) +* [3.3 - Check if Upgrade Undone](3.3-check-undo/README.md) +* [3.4 - Rinse and Repeat](3.4-conclusion/README.md) + +## Workshop Navigation + +Your will find links to the previous and next exercises at the bottom of each exercise page. Click the link below to get started. + +--- + +**Navigation** + +[Next Exercise](1.1-setup/README.md) diff --git a/exercises/rhdp_auto_satellite/4-ripu/images/auto_satellite_lab_diagram.png b/exercises/rhdp_auto_satellite/4-ripu/images/auto_satellite_lab_diagram.png new file mode 100644 index 000000000..ea2bac126 Binary files /dev/null and b/exercises/rhdp_auto_satellite/4-ripu/images/auto_satellite_lab_diagram.png differ diff --git a/exercises/rhdp_auto_satellite/4-ripu/images/ripu_key_features.svg b/exercises/rhdp_auto_satellite/4-ripu/images/ripu_key_features.svg new file mode 100644 index 000000000..9c9dd58fd --- /dev/null +++ b/exercises/rhdp_auto_satellite/4-ripu/images/ripu_key_features.svg @@ -0,0 +1,312 @@ + +image/svg+xml diff --git a/exercises/rhdp_auto_satellite/5-setupinsights/README.md b/exercises/rhdp_auto_satellite/5-setupinsights/README.md new file mode 100644 index 000000000..cf1fb02ee --- /dev/null +++ b/exercises/rhdp_auto_satellite/5-setupinsights/README.md @@ -0,0 +1,125 @@ +Automated Satellite Workshop: Insights Environment Setup +---------------------------------------------------------------------- + +**Introduction**
+This use-case will focus on connecting an individual's Red Hat Portal Account to the Automated Satellite Workshop environment for the purposes of demonstrating Insights functionality at the end of the workshop. + +This exercise is primarily targeted for a Red Hat SA to deliver a demo of the Insights services, though any individual with a Red Hat Portal Account, the appropriate account permissions and other prerequiistes could run through this exercise. + +This exercise is perscriptive in its setup, yet open-ended in its implementation. + +**Environment** +- Satellite 6.x +- Ansible Automation Platform 4.x +- 3x RHEL 7 instances +- Red Hat Portal Account with 2 availble Red Hat RHEL Instanced-based Subscriptions + - Please note - that this lab will consume 2 subscriptions for the duration of this workshop + +**Exercise Scenario** +- Exercise: Setup Insights + + +Overview +----------------------------------------------------------------- + +**Summary**
+- Insights is a hosted service on console.redhat.com. In order to access this service you need a Red Hat Portal Account +- Since accounts are associated with subscriptions, sharing an account widely could cause a lost of control of the account and subscription consumption +- Therefore this exercise will require the use of a user portal account and will require 2 RHEL Subscriptions + + +Ok, let's get started... + +Prerequisites +-------------- +- Information required for executing this exercise + + - Manifest created in your portal account targeted to Satellite 6.14 with appropriate subscriptions including a minimum of 2 RHEL Instance-based subscriptions with Smart Management and 1 Satellite Infrastructure subscription + - Record the name ⇒ manifest_name + + - Offline Token for accessing the Subscription Manager API + - access.redhat.com -> Subscriptions -> Manage -> RHSM API Tokens - Generate Token ⇒ offline_token + + - Your Organization ID + - access.redhat.com -> Subscriptions -> Manage -> Activation Keys ⇒ rhsm_org_id OR + - console.redhat.com -> Settings -> Remote Host Configuration -> Activation Keys⇒ rhsm_org_id + + - Red Hat Account username and password + - username ⇒ insights_user + - password ⇒ insights_password + + +Exercise: +----------------------------------------------------------------- +**Login to your AAP UI's** +> **NOTE** The following are *example* URLs. Your student lab URLs will be different. +* Ansible Automation Platform URL
+ Example: https://ansible-1.{random}.sandbox{###}.opentlc.com* + +**Steps:**
+#### 1\. Logging into the Ansible Automation Platform (AAP) + +- Use a web browser on your computer to access the AAP GUI via the link found in the Environment above. And use the following username and password to login: *admin / * + +![login screen](images/4-setupinsights-aap2-login.png) + +- Upon successful login, you will be able to see the Ansible Automation Platform dashboard. + +#### 2\. Setup Insights Template + +- Use the side pane menu on the left to select **Templates**. + +- Scroll down to find **Z / SETUP / Insights**. + +> **NOTE** This template is a workflow template as indicated by the visualizer icon and type = Workflow Job Template + +![Setup Insight](images/4-setupinsights-workflow-template.png) + +- Click ![visualizer Icon](images/4-setupinsights-visualizer.png) and review the workflow that will configure the environment for Insights + +![Insights Workflow](images/4-setupinsights-insights-workflow.png) + +- This workflow job template executes the following job templates + + - Insights / Replace Satellite Manifest - Replaces the Satellite manifest in the workshop with one that attaches to your Red Hat Portal Account + - SERVER / RHEL7 - Register - Registers the hosts to Satellite + - Insights / Install and Register - Installs Insights and registers the 3 RHEL hosts to Insights. It also runs the Insights Compliance role which installs the openscap packages on the hosts + - Insights / Create Insights Credential - Creates the AAP Insights Credential using your portal account information + - Insights / Create Insights Project - Creates an Insights Project in AAP that provides a project for remediation playbooks created in Insights to be consumed by AAP + +> **NOTE** Prior to executing the workflow job template you **MUST** add variables to the template. To do that: + + +- Click ![pencil](images/4-setupinsights-pencil.png) to the right of **Z / SETUP / Insights**. This will open the edit details window as shown below: + +![setup-insights](images/4-setupinsights-variables.png) + +- Add the following variables captured during the prerequisites: + + - manifest_name + - offline_token + - rhsm_org_id + - insights_user + - insights_password + +- Once the variables are entered click Save + +- Then click Launch + +- Since we are registering hosts to Satellite during this workflow you will be presented with this screen + +![complete survey](images/4-setupinsights-survey.png) + +- Enter the information as follows: + - Server Name or Pattern - node + - Choose Environment - Dev + +- Click Next and then Launch and watch the workflow complete + +> **NOTE** You may click on each job template being executed to see the details of that job template run) + +- A successful workflow run will show the following: + +![workflow complete](images/4-setupinsights-workflow-complete.png) + +At this point in the exercise the Ansible Satellite Workshop is now connected to your Red Hat Portal Account and is configured to support demonstrating Insights. \ No newline at end of file diff --git a/exercises/rhdp_auto_satellite/5-setupinsights/images/4-setupinsights-aap2-login.png b/exercises/rhdp_auto_satellite/5-setupinsights/images/4-setupinsights-aap2-login.png new file mode 100644 index 000000000..24bc6f3bd Binary files /dev/null and b/exercises/rhdp_auto_satellite/5-setupinsights/images/4-setupinsights-aap2-login.png differ diff --git a/exercises/rhdp_auto_satellite/5-setupinsights/images/4-setupinsights-insights-workflow.png b/exercises/rhdp_auto_satellite/5-setupinsights/images/4-setupinsights-insights-workflow.png new file mode 100644 index 000000000..c2611c19a Binary files /dev/null and b/exercises/rhdp_auto_satellite/5-setupinsights/images/4-setupinsights-insights-workflow.png differ diff --git a/exercises/rhdp_auto_satellite/5-setupinsights/images/4-setupinsights-pencil.png b/exercises/rhdp_auto_satellite/5-setupinsights/images/4-setupinsights-pencil.png new file mode 100644 index 000000000..739e60aa4 Binary files /dev/null and b/exercises/rhdp_auto_satellite/5-setupinsights/images/4-setupinsights-pencil.png differ diff --git a/exercises/rhdp_auto_satellite/5-setupinsights/images/4-setupinsights-project-sync.png b/exercises/rhdp_auto_satellite/5-setupinsights/images/4-setupinsights-project-sync.png new file mode 100644 index 000000000..f5a0129f8 Binary files /dev/null and b/exercises/rhdp_auto_satellite/5-setupinsights/images/4-setupinsights-project-sync.png differ diff --git a/exercises/rhdp_auto_satellite/5-setupinsights/images/4-setupinsights-survey.png b/exercises/rhdp_auto_satellite/5-setupinsights/images/4-setupinsights-survey.png new file mode 100644 index 000000000..77574d57f Binary files /dev/null and b/exercises/rhdp_auto_satellite/5-setupinsights/images/4-setupinsights-survey.png differ diff --git a/exercises/rhdp_auto_satellite/5-setupinsights/images/4-setupinsights-variables.png b/exercises/rhdp_auto_satellite/5-setupinsights/images/4-setupinsights-variables.png new file mode 100644 index 000000000..2260652f4 Binary files /dev/null and b/exercises/rhdp_auto_satellite/5-setupinsights/images/4-setupinsights-variables.png differ diff --git a/exercises/rhdp_auto_satellite/5-setupinsights/images/4-setupinsights-visualizer.png b/exercises/rhdp_auto_satellite/5-setupinsights/images/4-setupinsights-visualizer.png new file mode 100644 index 000000000..351256311 Binary files /dev/null and b/exercises/rhdp_auto_satellite/5-setupinsights/images/4-setupinsights-visualizer.png differ diff --git a/exercises/rhdp_auto_satellite/5-setupinsights/images/4-setupinsights-workflow-complete.png b/exercises/rhdp_auto_satellite/5-setupinsights/images/4-setupinsights-workflow-complete.png new file mode 100644 index 000000000..cd203ec8d Binary files /dev/null and b/exercises/rhdp_auto_satellite/5-setupinsights/images/4-setupinsights-workflow-complete.png differ diff --git a/exercises/rhdp_auto_satellite/5-setupinsights/images/4-setupinsights-workflow-template.png b/exercises/rhdp_auto_satellite/5-setupinsights/images/4-setupinsights-workflow-template.png new file mode 100644 index 000000000..4f4cc0ac8 Binary files /dev/null and b/exercises/rhdp_auto_satellite/5-setupinsights/images/4-setupinsights-workflow-template.png differ diff --git a/exercises/rhdp_auto_satellite/6-exploreinsights/README.md b/exercises/rhdp_auto_satellite/6-exploreinsights/README.md new file mode 100644 index 000000000..c453a4c8d --- /dev/null +++ b/exercises/rhdp_auto_satellite/6-exploreinsights/README.md @@ -0,0 +1,49 @@ +Automated Satellite Workshop: Explore Insights +---------------------------------------------------------------------- + + +**Introduction**
+This use-case will focus on exploring some of the services available on Red Hat Insights at console.redhat.com. + +Prerequisites +----------------------------------------------------------------- + +- Exercise 5: Insights Setup + +Exercise +----------------------------------------------------------------- + +#### Explore Insights on console.redhat.com + +This exercise is much less prescriptive and is designed to provide the student with some general guidance to get started. Please feel free to explore all of the available Red Hat Insights Services + +- Login to console.redhat.com using portal account credentials - https://console.redhat.com + +- Select Red Hat Enterprise Linux -> Red Hat Insights + +- This will bring you to the Overview page which depicts a dashboard of the hosts that are registered to Insights + + - Explore this dashboard noting that each box addresses an Insights Service + +- Click on Inventory + + - Note that the hosts registered during the `Z / SETUP / Insights` workflow template job run are present at the top of the list + + - Click into each host to see the details of each host on the General Information tab. A representative sample is provided using node1.example.com. + +![inventory-general-information](images/5-exploreinsights-inventory-general.png) + +- Click on each of the other tabs to see the information that Insights has collected about each host. For example click on Vulnerability. This view will show all the vulnerabilities for that host. + +> **NOTE** The right most column labeled Remediation you will see Playbook listed on many of these vulnerabilities. This indicates that an Ansible Playbook has been created to correct this issue. In the next exercise we will demonstrate how to use AAP with this playbook to address the vulnerability. + + +![host-vulnerability-information](images/5-exploreinsights-host-vulnerabilities.png) + +- Let's now look at all hosts associated with a Service. In this example let's use Vulnerability service + + - On the left hand navigation pane click on Vulnerability -> CVEs. This view will show the vulnerabilities for all systems registered to Red Hat Insights + +![account-vulnerability-information](images/5-exploreinsights-account-vulnerabilities.png) + +- Navigate around the Insights services to gain more understanding of Red Hat Insights. \ No newline at end of file diff --git a/exercises/rhdp_auto_satellite/6-exploreinsights/images/5-exploreinsights-account-vulnerabilities.png b/exercises/rhdp_auto_satellite/6-exploreinsights/images/5-exploreinsights-account-vulnerabilities.png new file mode 100644 index 000000000..afc179d27 Binary files /dev/null and b/exercises/rhdp_auto_satellite/6-exploreinsights/images/5-exploreinsights-account-vulnerabilities.png differ diff --git a/exercises/rhdp_auto_satellite/6-exploreinsights/images/5-exploreinsights-host-vulnerabilities.png b/exercises/rhdp_auto_satellite/6-exploreinsights/images/5-exploreinsights-host-vulnerabilities.png new file mode 100644 index 000000000..09aa423ac Binary files /dev/null and b/exercises/rhdp_auto_satellite/6-exploreinsights/images/5-exploreinsights-host-vulnerabilities.png differ diff --git a/exercises/rhdp_auto_satellite/6-exploreinsights/images/5-exploreinsights-inventory-general.png b/exercises/rhdp_auto_satellite/6-exploreinsights/images/5-exploreinsights-inventory-general.png new file mode 100644 index 000000000..efd12e7bd Binary files /dev/null and b/exercises/rhdp_auto_satellite/6-exploreinsights/images/5-exploreinsights-inventory-general.png differ diff --git a/exercises/rhdp_auto_satellite/7-remediatevulnerability/README.md b/exercises/rhdp_auto_satellite/7-remediatevulnerability/README.md new file mode 100644 index 000000000..e98b66fd5 --- /dev/null +++ b/exercises/rhdp_auto_satellite/7-remediatevulnerability/README.md @@ -0,0 +1,188 @@ +Automated Satellite Workshop: Remediate Vulnerability +---------------------------------------------------------------------- + + +Overview +----------------------------------------------------------------- + +This use-case will demonstrate how to: + +- Identify potential vulnerabilities using Red Hat Insights + +- Create a Remediation Playbook to address the vulnerability + +- Use AAP to execute the playbook to resolve the vulnerability + +Prerequisites +----------------------------------------------------------------- + +- Exercise 5: Insights Setup + +- Exercise 6: Explore Insights + +Exercise +----------------------------------------------------------------- + +#### 1\. Prepare to Remediate a Vulnerability + +Now that you have some familiarity with the Insights Services let's go correct an issue. In this example, it will be a specific vulnerability. + +- Login to Red Hat Insights by going to https://console.redhat.com using your Red Hat Portal Account credentials. + +- Navigate to Red Hat Insights by going to Red Hat Enteprise Linux -> Red Hat Insights. + +- Navigatate to Inventory and click into node1.example.com + +- Click on the Vulnerability tab. + +- Select any Vulnerability listed that has a Playbook listed in the Remediation column. For this example we will choose "CVE-2023-22809". + +- Click on the box to the left of the CVE name and notice that the Remediate button becomes active. This indicates that a Remediation playbood can be created for this vulnerability. + +![remediate-button-active](images/6-remediatevulnerability-remediate-button.png) + +- Click on the Remediate button. This will take you into a wizard that will allow you to create a playbook to correct the identified vulnerability. + +- Select Create new playbook and give it a name. In this example we chose to name the playbook after the name of the vulnerability. + + +![select-playbook](images/6-remediatevulnerability-select-playbook.png) + + +- Click Next and you will be presented with the systems that will be included as hosts in this Ansible playbook. You have the option at this point to remove systems if you choose. + +![review-systems](images/6-remediatevulnerability-review-systems.png) + +- Select Next and you are presented with a Remediation Review screen. + +> **NOTE** In order to correct this vulnerability a reboot is required. If you desire to reboot later, select "turn off autoreboot". + +![remediation-review](images/6-remediatevulnerability-remediation-review.png) + +- Click Submit and a playbook will be created for you. + + +![playbook-created](images/6-remediatevulnerability-playbook-created.png) + + +At this point a playbook that has been created is available in the Remediations section of Insights. Let's go there next: + +- Click on Return to Application or close the window. + +- Select Toolkit -> Remediations. + +> **NOTE** That the playbook you created in the step above is available. + +- At this point you have several options available to you, including: + + 1. Download the playbook and execute it from an Ansible node in your environment. + + 2. Execute through Satellite or directly on the host if you have either the Cloud Connector configured on Satellite or Red Hat Connector configured. + + 3. Execute the playbook using the Ansible Project that we created during the setup of this lab. + +> **NOTE** In this example we will execute the Remediation through the Ansible Automation Platform. + + +#### 2\. Execute a Remediation Using AAP + +- Navigate back to the AAP GUI via the link found in the Environment above. And use the following username and password to login: *admin / * + +![login screen](images/6-remediatevulnerability-aap2-login.png) + +- Upon successful login, you will be able to see the Ansible Automation Platform dashboard. + +The Remediation playbooks from Insights are consumed by AAP through the use of a specific type of Project. We set this project up for you during the Setup / Insights job run. Let's sync this project with Insights to pull down the latest playbooks. + +Before doing the sync let's look at the Insights Credential that was also setup during the Setup / Insights job run. This credential is used to login to your account on the Red Hat Portal. For this use case it is specifically used to connect an AAP Project with the Insights Remediation Service. + +- Navigate to Resources -> Credentials and select the Insights Credential. + +![insights-credential](images/6-remediatevulnerability-credential.png) + +- Click Edit. + +![insights-credential-edit](images/6-remediatevulnerability-credential-edit.png) + +- Observe that the credential type is Insights and the user name is the Portal Account user name you entered as one of the prerequisites. + +- The Portal Account password you entered has been encrypted and cannot be retrieved. + +Next let's sync the Project and create the Job Template. + +- Navigate to Resources -> Projects and click on Insights Project. + +> **NOTE** That the last job status says "Successful" because the project was sync'd when we created the playbook during the Setup / Insights workflow template job run. + +- Click Sync and wait for the last job status return to "Successful". The Remediation Playbook we created in Red Hat Insights is now included in the Insights Project on AAP. + +Let's create a Job Template that uses this playbook. + +- Navigate to Resources -> Templates. + +- Click the BLUE 'Add' drop-down icon and select 'Add job template' from the drop-down selection menu. Fill out the details as follows: + + Name: Insights / Remediation - CVE-2023-22809 + + Job Type: Run + + Inventory: Workshop Inventory (Click the magnifying glass icon to select.) + + Project: Insights Project (Click the magnifying glass icon to select.) + + Execution Environment: insights execution environment (Click the + magnifying glass icon to select.) + + Playbook: cve-2023-22809-(uuid).yml (Click drop-down to select.) + + Credentials: Workshop Credential (Click drop-down to select.) + +> **NOTE** The diagram below depicts the job template that should be created. + + + +![insights-template](images/6-remediatevulnerability-insights-template.png) + +- Click Save. + +Now let's execute this job template to remediate the vulnerability + +- Click Launch and you will be taken to the Jobs Output screen for this template. + +- Wait for the Job Template to return a "Successful" status. + +![insights-template-complete](images/6-remediatevulnerability-template-complete.png) + +> **NOTE** In the screenshot above observe that the vulnerable package(s) was updated, system was rebooted and the insights-client was run again. + + +Let's go validate that the Remediation playbook eliminated the vulnerability. + +#### 3\. Verify Remediation on Red Hat Insights + +Login to https://console.redhat.com using portal account credentials + +- Select Red Hat Enterprise Linux -> Red Hat Insights. + +- This will bring you to the Overview page which depicts a dashboard of the hosts that are registered to Insights. + +First verify that the Remediation was run. + +- Navigate to Toolkit -> Remediations. + +- Verify that the remediation playbook created earlier shows a green checkmark under "Complete actions". + +![insights-playbook-complete](images/6-remediatevulnerability-remediation-playbook-complete.png) + + +Now let's go look at the CVE to verify that node1.example.com is no longer an impacted system. + +- Navigate to Vulnerability -> CVE's and search for the CVE you targeted in this remediation and click into it. In this example it is CVE-2023-22809. + + +![insights-remediation-complete](images/6-remediatevulnerability-cve-remediation-complete.png) + + +- Verify that node1 no longer shows up as a vulnerable system for this CVE. + +This completes this exercise. \ No newline at end of file diff --git a/exercises/rhdp_auto_satellite/7-remediatevulnerability/images/6-remediatevulnerability-aap2-login.png b/exercises/rhdp_auto_satellite/7-remediatevulnerability/images/6-remediatevulnerability-aap2-login.png new file mode 100644 index 000000000..24bc6f3bd Binary files /dev/null and b/exercises/rhdp_auto_satellite/7-remediatevulnerability/images/6-remediatevulnerability-aap2-login.png differ diff --git a/exercises/rhdp_auto_satellite/7-remediatevulnerability/images/6-remediatevulnerability-credential-edit.png b/exercises/rhdp_auto_satellite/7-remediatevulnerability/images/6-remediatevulnerability-credential-edit.png new file mode 100644 index 000000000..8f2ae2fd7 Binary files /dev/null and b/exercises/rhdp_auto_satellite/7-remediatevulnerability/images/6-remediatevulnerability-credential-edit.png differ diff --git a/exercises/rhdp_auto_satellite/7-remediatevulnerability/images/6-remediatevulnerability-credential.png b/exercises/rhdp_auto_satellite/7-remediatevulnerability/images/6-remediatevulnerability-credential.png new file mode 100644 index 000000000..251d77287 Binary files /dev/null and b/exercises/rhdp_auto_satellite/7-remediatevulnerability/images/6-remediatevulnerability-credential.png differ diff --git a/exercises/rhdp_auto_satellite/7-remediatevulnerability/images/6-remediatevulnerability-cve-remediation-complete.png b/exercises/rhdp_auto_satellite/7-remediatevulnerability/images/6-remediatevulnerability-cve-remediation-complete.png new file mode 100644 index 000000000..0b927f1fe Binary files /dev/null and b/exercises/rhdp_auto_satellite/7-remediatevulnerability/images/6-remediatevulnerability-cve-remediation-complete.png differ diff --git a/exercises/rhdp_auto_satellite/7-remediatevulnerability/images/6-remediatevulnerability-insights-template.png b/exercises/rhdp_auto_satellite/7-remediatevulnerability/images/6-remediatevulnerability-insights-template.png new file mode 100644 index 000000000..f834117ac Binary files /dev/null and b/exercises/rhdp_auto_satellite/7-remediatevulnerability/images/6-remediatevulnerability-insights-template.png differ diff --git a/exercises/rhdp_auto_satellite/7-remediatevulnerability/images/6-remediatevulnerability-playbook-created.png b/exercises/rhdp_auto_satellite/7-remediatevulnerability/images/6-remediatevulnerability-playbook-created.png new file mode 100644 index 000000000..d50bc1fc1 Binary files /dev/null and b/exercises/rhdp_auto_satellite/7-remediatevulnerability/images/6-remediatevulnerability-playbook-created.png differ diff --git a/exercises/rhdp_auto_satellite/7-remediatevulnerability/images/6-remediatevulnerability-remediate-button.png b/exercises/rhdp_auto_satellite/7-remediatevulnerability/images/6-remediatevulnerability-remediate-button.png new file mode 100644 index 000000000..10625eecd Binary files /dev/null and b/exercises/rhdp_auto_satellite/7-remediatevulnerability/images/6-remediatevulnerability-remediate-button.png differ diff --git a/exercises/rhdp_auto_satellite/7-remediatevulnerability/images/6-remediatevulnerability-remediation-playbook-complete.png b/exercises/rhdp_auto_satellite/7-remediatevulnerability/images/6-remediatevulnerability-remediation-playbook-complete.png new file mode 100644 index 000000000..e7f4092e2 Binary files /dev/null and b/exercises/rhdp_auto_satellite/7-remediatevulnerability/images/6-remediatevulnerability-remediation-playbook-complete.png differ diff --git a/exercises/rhdp_auto_satellite/7-remediatevulnerability/images/6-remediatevulnerability-remediation-review.png b/exercises/rhdp_auto_satellite/7-remediatevulnerability/images/6-remediatevulnerability-remediation-review.png new file mode 100644 index 000000000..77680268d Binary files /dev/null and b/exercises/rhdp_auto_satellite/7-remediatevulnerability/images/6-remediatevulnerability-remediation-review.png differ diff --git a/exercises/rhdp_auto_satellite/7-remediatevulnerability/images/6-remediatevulnerability-review-systems.png b/exercises/rhdp_auto_satellite/7-remediatevulnerability/images/6-remediatevulnerability-review-systems.png new file mode 100644 index 000000000..7e9a7cee4 Binary files /dev/null and b/exercises/rhdp_auto_satellite/7-remediatevulnerability/images/6-remediatevulnerability-review-systems.png differ diff --git a/exercises/rhdp_auto_satellite/7-remediatevulnerability/images/6-remediatevulnerability-select-playbook.png b/exercises/rhdp_auto_satellite/7-remediatevulnerability/images/6-remediatevulnerability-select-playbook.png new file mode 100644 index 000000000..b08ffbdc1 Binary files /dev/null and b/exercises/rhdp_auto_satellite/7-remediatevulnerability/images/6-remediatevulnerability-select-playbook.png differ diff --git a/exercises/rhdp_auto_satellite/7-remediatevulnerability/images/6-remediatevulnerability-template-complete.png b/exercises/rhdp_auto_satellite/7-remediatevulnerability/images/6-remediatevulnerability-template-complete.png new file mode 100644 index 000000000..195801c83 Binary files /dev/null and b/exercises/rhdp_auto_satellite/7-remediatevulnerability/images/6-remediatevulnerability-template-complete.png differ diff --git a/exercises/rhdp_auto_satellite/README.fr.md b/exercises/rhdp_auto_satellite/README.fr.md new file mode 100644 index 000000000..e75b94cb2 --- /dev/null +++ b/exercises/rhdp_auto_satellite/README.fr.md @@ -0,0 +1,62 @@ +# Atelier Automated Satellite + +**Lisez ceci dans d'autres langues**: +
![uk](../../images/uk.png) [English](README.md), ![france](../../images/fr.png) [Française](README.fr.md). +
+ +Dans cet atelier, vous apprendrez à tirer le meilleur parti de Red Hat Satellite en concert avec Red Hat Ansible Automation Platform. + +## Table des matières +- [Cas d'ulilisation](#cas-dutilisation) +- [Présentations](#présentations) +- [Planification du temps](#planification-du-temps) +- [Diagramme du laboratoire](#diagramme-du-laboratoire) +- [Exercices](#exercices) + +## Cas d'utilisation + +Cet atelier se concentre actuellement sur ces quatre points sensibles de gestion d'un parc linux : +- Conformité (OpenSCAP Scanning) et gestion de la vulnérabilité +- Gestion des Patches/Paquetages +- Conversion CentOS vers RHEL +- Gestion de la vulnérabilité avec Insights + +## Présentations + +Les exercices sont auto-explicatifs et guident les participants tout au long de l'atelier. Tous les concepts sont expliqués lorsqu'ils sont introduits. + +Il y a une présentation optionnelle disponible pour soutenir les ateliers et expliquer plus en détails l'automatisation, les bases d'Ansible et les sujets des exercices. La présentation de l'atelier est située ici, en anglais [Atelier automatisé de gestion intelligente](../../decks/ansible_smart_mgmt_fr.pdf). _[Red Hat Internal link](https://docs.google.com/presentation/d/1XpqjDbjEHel2FZLJdrKz67FA2RYKw3eZPY0oqzd8qiY)_ + +Jetez également un coup d'oeil à notre présentation sur les meilleurs pratiques avec Ansible: en anglais +[Pratiques exemplaires disponibles](../../decks/ansible_best_practices.pdf) + +## Planification du temps + +Le temps nécessaire pour faire les ateliers dépend fortement de plusieurs facteurs : le nombre de participants, la familiarité avec Linux en général et les discussions entre les ateliers. + +Cela dit, les exercices eux-mêmes devraient prendre environ 4 heures. Chaque laboratoire dure environ 30 à 45 minutes. La présentation qui accompagne elle-même ajoute ~1 heure. + +## Diagramme du laboratoire +![diagramme automatique de laboratoire de gestion intelligente](../../images/ansible_smart_mgmt_diagram.png#centreme) + +### Environnement + +| Rôle | Nom dans l'inventaire | +| ------------------------| ---------------| +| Automation controller | ansible-1 | +| Serveur Satellite | satellite | +| Host géré 1 - RHEL | node1 | +| Host géré 2 - RHEL | node2 | +| Host géré 3 - RHEL | node3 | +| Host géré 4 - CentOS | node4 | +| Host gété 5 - CentOS | node5 | +| Host gété 6 - CentOS | node6 | + + + +## Exercices + +* [Exercice 0: Configurer l'environnement du laboratoire](0-setup/README.fr.md) +* [Exercice 1: Conformité / Gestion de la vulnérabilité](1-compliance/README.fr.md) +* [Exercice 2: Gestion des correctifs / OS](2-patching/README.fr.md) +* [Exercice 3: CentOS à la conversion RHEL](3-convert2rhel/README.fr.md) diff --git a/exercises/rhdp_auto_satellite/README.md b/exercises/rhdp_auto_satellite/README.md new file mode 100644 index 000000000..2d24ca4ba --- /dev/null +++ b/exercises/rhdp_auto_satellite/README.md @@ -0,0 +1,66 @@ +# Automated Satellite Workshop + +**Read this in other languages**: +
![uk](./images/uk.png) [English](README.md), ![france](./images/fr.png) [Français](README.fr.md). +
+ +In this workshop, you will learn how to get the most from Red Hat Satellite in concert with Red Hat Ansible Automation Platform. + +## Table of Contents +- [Use Cases](#use-cases) +- [Presentations](#presentations) +- [Time planning](#time-planning) +- [Lab Diagram](#lab-diagram) +- [Workshop Exercises](#Workshop-Exercises) + +## Use Cases + +This workshop currently focuses on 5 main customer pain points: +- Compliance (OpenSCAP Scanning) and Vulnerability Management +- Patch/Package Management +- CentOS/OracleLinux to RHEL Conversion +- RHEL In-Place-Upgrades +- Vulnerability Management with Insights + +## Presentations + +The exercises are self explanatory and guide the participants through the entire lab. All concepts are explained when they are introduced. + +There is an optional presentation available to support the workshops and explain Automation, the basics of Ansible and the topics of the exercises in more detail. Workshop presentation is located at [Automated Satellite Workshop](https://aap2.demoredhat.com/decks/ansible_auto_satellite.pdf). + +Also have a look at our Ansible Best Practices Deck: +[Ansible Best Practices](https://aap2.demoredhat.com/decks/ansible_best_practices.pdf) + +## Time planning + +The time required to do the workshops strongly depends on multiple factors: the number of participants, how familiar those are with Linux in general and how much discussions are done in between. + +Having said that, the exercises themselves should take roughly 4 to 5 hours. Compliance, Patching and Insights exercises each take roughly 30-45 minutes. OS Conversion and RHEL In-Place-Upgrade each require about an hour to complete. The accompanying presentation itself adds 45 minutes to an hour if included in whole. + +## Lab Diagram +![automated Satellite lab diagram](../../images/ansible_smart_mgmt_diagram.png#centreme) + +### Environment + +| Role | Inventory name | +| ------------------------------------| ---------------| +| Automation controller | ansible-1 | +| Satellite Server | satellite | +| Managed Host 1 - RHEL | node1 | +| Managed Host 2 - RHEL | node2 | +| Managed Host 3 - RHEL | node3 | +| Managed Host 4 - CentOS/OracleLinux | node4 | +| Managed Host 5 - CentOS/OracleLinux | node5 | +| Managed Host 6 - CentOS/OracleLinux | node6 | + + + +## Workshop Exercises + +* [Exercise 1: Compliance / Vulnerability Management](1-compliance/README.md) +* [Exercise 2: Patch Management / OS](2-patching/README.md) +* [Exercise 3: CentOS to RHEL Conversion](3-convert2rhel/README.md) +* [Exercise 4: RHEL In-Place-Upgrade](4-ripu/README.md) +* [Exercise 5: Setup Insights](5-setupinsights/README.md) +* [Exercise 6: Explore Insights](6-exploreinsights/README.md) +* [Exercise 7: Remediate Vulnerability](7-remediatevulnerability/README.md) diff --git a/exercises/rhdp_auto_satellite/decks/ansible_ripu_conversion.pdf.pdf b/exercises/rhdp_auto_satellite/decks/ansible_ripu_conversion.pdf.pdf new file mode 100644 index 000000000..acfbc8f64 Binary files /dev/null and b/exercises/rhdp_auto_satellite/decks/ansible_ripu_conversion.pdf.pdf differ diff --git a/exercises/rhdp_auto_satellite/images/fr.png b/exercises/rhdp_auto_satellite/images/fr.png new file mode 100644 index 000000000..d6e3a3878 Binary files /dev/null and b/exercises/rhdp_auto_satellite/images/fr.png differ diff --git a/exercises/rhdp_auto_satellite/images/uk.png b/exercises/rhdp_auto_satellite/images/uk.png new file mode 100644 index 000000000..285e0a872 Binary files /dev/null and b/exercises/rhdp_auto_satellite/images/uk.png differ diff --git a/galaxy.yml b/galaxy.yml index 99c880db6..16f8fe538 100644 --- a/galaxy.yml +++ b/galaxy.yml @@ -1,7 +1,7 @@ --- namespace: ansible name: workshops -version: 1.0.17 +version: 2.0.0 readme: README.md authors: