ans104 - gpulido-redhat/workshopclaro GitHub Wiki

Operaciones avanzadas con Ansible Tower

Meta:
- Entender los proceso avanzados con Ansible tower, como la integracion con GIT, formularios, worksflows, etc.

Objetivos:
- Realizar operaciones avanzadas con Red Hat Ansible Tower(Demostración)

Secciones:
- .(Teórico - Practico)
- GIT y worksflows.(Teórico)
- Instalación de Red Hat Ansible. (Demostración)

Laboratorios:
- Operaciones avanzadas con Ansible Tower

Integracion con GIT

Git es un sistema de control de versiones distribuido. Esto significa que un clon local del proyecto es un repositorio de control de versiones completo. Estos repositorios locales plenamente funcionales permiten trabajar sin conexión o de forma remota fácilmente. Los desarrolladores confirman su trabajo localmente y, a continuación, sincronizan su copia del repositorio con la copia en el servidor. Este paradigma es distinto del control de versiones centralizado, donde los clientes deben sincronizar el código con un servidor antes de crear nuevas versiones.

La flexibilidad y popularidad de Git lo convierten en una excelente opción para cualquier equipo. Muchos desarrolladores y egresados de la universidad ya saben cómo usar Git. La comunidad de usuarios de Git ha creado muchos recursos para entrenar a los desarrolladores y la popularidad de Git facilita la ayuda cuando es necesario. Casi todos los entornos de desarrollo tienen compatibilidad con Git y las herramientas de línea de comandos de Git se ejecutan en todos los sistemas operativos principales.


Ventajas de Git


Desarrollo simultáneo
Todos tienen su propia copia local de código y pueden trabajar simultáneamente en sus propias ramas. Git funciona sin conexión, ya que casi todas las operaciones son locales.


Versiones más rápidas
Las ramas permiten un desarrollo flexible y simultáneo. La rama principal contiene código estable y de alta calidad del que se libera. Las ramas de características contienen trabajo en curso, que se combinan en la rama principal tras la finalización. Al separar la rama de versión del desarrollo en curso, es más fácil administrar el código estable y enviar actualizaciones más rápidamente.


Integración integrada
Debido a su popularidad, Git se integra en la mayoría de las herramientas y productos. Cada IDE principal tiene compatibilidad integrada con Git y muchas herramientas admiten integración continua, implementación continua, pruebas automatizadas, seguimiento de elementos de trabajo, métricas e integración de características de informes con Git. Esta integración simplifica el flujo de trabajo diario.


Soporte técnico de la comunidad sólida
Git es de código abierto y se ha convertido en el estándar de facto para el control de versiones, por lo que no hay escasez de herramientas y recursos disponibles para que los equipos los aprovechen. El volumen de compatibilidad de la comunidad con Git en comparación con otros sistemas de control de versiones facilita la ayuda cuando es necesario.


Git funciona con cualquier equipo
El uso de Git con una herramienta de administración de código fuente puede aumentar la productividad de un equipo al fomentar la colaboración, aplicar directivas, automatizar procesos y mejorar la visibilidad y la rastreabilidad del trabajo. El equipo puede establecerse en herramientas individuales para el control de versiones, el seguimiento de elementos de trabajo y la integración e implementación continuas. O bien, pueden elegir una solución como GitHub o Azure DevOps que admita todas estas tareas en un solo lugar.


Solicitudes de incorporación de cambios
Use las solicitudes de extracción para analizar los cambios de código con el equipo antes de combinarlos en la rama principal. Los debates de las solicitudes de extracción son muy valiosos para garantizar la calidad del código y aumentar el conocimiento en todo el equipo. Plataformas como GitHub y Azure DevOps ofrecen una experiencia de solicitud de extracción completa en la que los desarrolladores pueden examinar los cambios de archivos, dejar comentarios, inspeccionar confirmaciones, ver compilaciones y votar para aprobar el código.


Directivas de rama
Los equipos pueden configurar GitHub y Azure DevOps para aplicar flujos de trabajo y procesos coherentes en todo el equipo. Pueden configurar directivas de rama para asegurarse de que las solicitudes de extracción cumplen los requisitos antes de su finalización. Las directivas de rama protegen ramas importantes al evitar inserciones directas, requerir revisores y garantizar compilaciones limpias.

Creando un usuario en GIT

Para completar el capitulo, los alumnos tendran a su disposicion un servidor de GOGS en la direccion url http://192.168.10.190:3000 o http://classroom.opennova.pe:3000. Para crear un nuevo usuario podra ingresar a la pagina y hacer click sobre el boton de registro

Ingresara los datos de su registro

Con el registro listo podra iniciar sesion en la plataforma

Podra crear un nuevo repositorio con el boton +

Nombramos el repositorio, para completar los laboratorios dejamos el repositorio como publico

Con el repositorio creado, copiamos el url del repositorio para administrarlo via comandos en los siguientes pasos

Inicializando el repositorio GIT

Para inicializar el repositorio creado en el paso anterior, usaremos la linea de comandos desde el serverX considerando el usuario alumnoX en el repositorio tower.

mkdir tower
cd tower
touch README.md
echo "Primer GIT del alumno" > README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin http://192.168.10.190:3000/alumno08/tower.git
git push -u origin master

Validamos la inicializacion del git

Actualizando el repositorio GIT

Para agregar nuevos archivos al repositorio, usamos el siguiente procedimiento, considerando que quisiera agregar los archivos /etc/hosts y /etc/fstab

cd tower
cp /etc/fstab .
cp /etc/hosts .
git add *
git commit -m "Actualizacion 01" *
git push -u origin master

Validamos la actualizacion del git

Para borrar archivos del git usamos

cd tower
git rm fstab
git commit -m "Actualizacion 02" fstab
git push -u origin master

Validamos la actualizacion del git

Si quisieramos obtener la informacion del git usamos los comandos

cd /tmp
git clone http://192.168.10.190:3000/alumno08/tower.git
cd tower
ls -l

Laboratorio 01


Cree un usuario alumnoX en el git server http://192.168.10.190:3000 donde X es su nuemro de alumno
Cre un repositorio llamado tower con acceso publico
Agregue los archivos /etc/fstab /etc/hosts /etc/redhat-release en su repositorio
Cree una copia de su repositorio publico en /tmp
Cree un repositorio privado llamado ansible
Agregue algunos playbooks en su repositorio privado(instalacion e desinstalacion de apache)
Cree una copia de su repositorio privado en /tmp

Creando proyectos con contenido de GIT

En lugar de crear espacio de trabajo en la ruta /var/lib/awx/projects podemos importar los playbooks desde un GIT que sea gestionado por un area de desarrollo con experiencia en el formato yaml a fin de facilitar el ciclo de pruebas y certificacion de los playbooks. Ansible Tower permite crear proyectos del tipo GIT para ellos necesatamos un git de preferencia privado. El primer paso es crear una credencial que permita el acceso seguro al GIT. En la seccion credenciales agregamos uno nuevo con el boton +

Creamos la nueva credencial con el tipo FUENTE DE CONTROL y las credenciales de acceso del git

Luego agregamos un nuevo proyecto

Ingresamos los datos del proyecto considerando las credenciales creadas anterioremente y otros datos propios del repositorio GIT

Con el proyecto git listo, creamos una nueva plantilla de trabajo

Al crear la nueva plantilla de trabajo, seleccionamos el proyecto de git y vemos que los playbooks en el ya estan disponibles

Con estos procedimientos ya puede usar el GIT para cargar sus playbooks al proyecto de ansible tower, en caso algun playbooks se actulice pero no aparesca en la plataforma, puede actualizar de forma inmediata con el boton refrescar en el proyecto

Laboratorio 02


Desinstale el apache en el grupo de servidor PROD(node81 y node82) con el comando yum remove httpd
Agregue a su repositorio GIT privado llamado ansible los playboks de instalar y desinstalar apache
Cree una credencial de acceso a su git privado llamado GitUserX con los accesos a su git privado
Cree un proyecto llamado GitAnsibleX que incluya los datos de su repositorio privado
Cree las plantillas de trabajo "Git Install Apache X" y "Git Uninstall Apache X" que puedan ejecutar las tareas desde los playbooks de su git personal
Logueese como un usuario no admin y ejecute las tareas definidas en las plantillas de trabajo

Uso de formularios

Creando un formulario con variables

Podemos inyectar variables a los playbooks desde ansible tower, para ello tenemos la facilidad del uso de formularios, asi la ejecucion se hace mas dinamica, para ello primero creamos un playbook que cree un archivo de configuracion en el servidor ansible

[root@server08 ~]# cd /var/lib/awx/projects/test08/
[root@server08 test08]# vi apache_content.yaml
---
- name: Index content
  hosts: all
  tasks:
    - copy:
        content: |
                 WebServer estatico
        dest: /var/www/html/index.html

Ahora creamos una nueva plantilla de trabajo llamada Apache Content el cual apuntara a nuestro playbook

Ejecutamos la tarea y vemos que el index del servidor web se actualizo

En este punto podemos modificar el playbook para que su contenido sea dinamico a traves de variable, en este ejemplo vamos preparar el playbook para recibir las variables nombre y apellido

[root@server08 test08]# vi apache_content.yaml
---
- name: Index content
  hosts: all
  tasks:
    - copy:
        content: |
                 WebServer dinamico preparado por {{ nombre }} {{ apellido }}
        dest: /var/www/html/index.html

Luego regresamos a la plantilla de trabajo y añadimos un formulario

Agregamos la variable nombre

Agregamos la variable apellido

Ejecutamos la plantilla y esperemos que nos pregunte las variables a traves del formulario

Verificamos el webserver

Podemos modificar el playbook para que cuente con mas variables que seran enviadas por el formulario pero con variables predefinidas con lista de opciones

[root@server08 test08]# vi apache_content.yaml
---
- name: Index content
  hosts: all
  tasks:
    - copy:
        content: |
                 WebServer dinamico preparado por {{ nombre }} {{ apellido }} para el ambiente de {{ ambiente }}
        dest: /var/www/html/index.html

Modificamos el formulario para incluir la variable ambiente

Ejecutamos de nuevo ingresando los datos

Verificamos el servidor web

Laboratorio 03


Cree una nueva plantilla de trabajo que modifique un web server, debera modificar la pagina index.html con el contenido
La plantilla debera tener el check de "Preguntar al ejecutar" en el campo INVENTARIO donde debera escoger entre los inventarios PROD, DESA y QA de ejercicios anteriores
EL webserver debera ser identificado por navegador si el servidor fue entregado para los ambientes de PROD, DESA o QA a traves de variables ingresadas por formulario y el nombre del alumno, se recomienda que el nombre sea una variable de texto y el ambiente de una lista de opciones
Desplegar el contenido a los 4 nodos gestionados disponibles
Validar la correcta ejecucion de su trabajo a traves de la consulta web a sus servidores clientes

Laboratorio 04


Cree una plantilla de trabajo que permita crear el grupo testers, devops y cualquie otro grupo en los servidores de QA a traves de un formulario donde la variable de entrada sea el grupo deseado.

Utilice el siguiente playbook create_group.yaml

---
- name: Create Group
  hosts: all
  tasks:
  - name: Ensure group exists
    group:
      name: "{{ grupo }}"
      state: present


Cree usuarios a traves de un formulario el cual pida el ingreso del nombre y la contraseña del usuario, apoyese en el siguiente playbook create_user.yaml

---
- name: Create User
  hosts: all
  tasks:
  - name: Creating user
    user:
      name: "{{ user }}"
      password: "{{ password | password_hash('sha512') }}"

Finalmente agregue un usuario en un grupo a traves de un formulario donde se deba ingresar el usuario y el grupo, apoyse en el siguiente playbook add_user_to_group.yaml

---
- name: add user to group
  hosts: all
  tasks:
  - name: adding existing user to group sudo
    user:
      name: "{{ user }}"
      groups: "{{ grupo }}"
      append: yes

Con los 3 playboos creados, proceda a crear 3 plantilla de trabajo con formularios que permitan:
Crear usuarios a traves de un formulario, definiendo las variables user y password
Crear un grupo a traves de un formulario, definiendo la variable grupo
Asignar un grupo a un usuario a traves de un formulario, definiendo las variables user y grupo

WorkFlows

Que es un workflow

Los flujos de trabajo le permiten configurar una secuencia de plantillas de trabajo dispares (o plantillas de flujo de trabajo) que pueden o no compartir inventario, guías o permisos. Sin embargo, los flujos de trabajo tienen permisos de "administración" y "ejecución", similares a las plantillas de trabajo. Un flujo de trabajo cumple la tarea de rastrear el conjunto completo de trabajos que fueron parte del proceso de liberación como una sola unidad.

Las plantillas de trabajo o flujo de trabajo se vinculan entre sí mediante una estructura en forma de gráfico denominada nodos. Estos nodos pueden ser trabajos, sincronizaciones de proyectos o sincronizaciones de inventario. Una plantilla puede formar parte de diferentes flujos de trabajo o usarse varias veces en el mismo flujo de trabajo. Se guarda una copia de la estructura del gráfico en un trabajo de flujo de trabajo cuando inicia el flujo de trabajo.

El siguiente ejemplo muestra un flujo de trabajo que contiene los tres, así como una plantilla de trabajo de flujo de trabajo:

A medida que se ejecuta el flujo de trabajo, los trabajos se generan a partir de la plantilla vinculada del nodo. Los nodos que unen a una plantilla de trabajo que tiene campos-prontas conducido ( job_type, job_tags, skip_tags, limit) pueden contener esos campos, y no se le pedirá en el lanzamiento. Las plantillas de trabajo con credenciales y / o inventario solicitables, SIN valores predeterminados, no estarán disponibles para su inclusión en un flujo de trabajo.

Cree el nuevo flujo de trabajo

Ingrese los datos de la plantilla

Al momento de guardar la plantilla, se abrira un asistente grafico, mire como el instructor crea la plantilla con el editor grafico, donde podra ver que hay trabajos secuenciales como crear usuario y crear grupo

Tambien hay trabajos paralelos como la instalacion del webserver y el ftpserver

Solo cuando ambas tareas finalicen se continua con el flujo principal

Cada una de las tareas independientes del flujo de trabajo tienen variables, estan deben consolidarse en un gran formulario con todas las variables

Antes de ejecutar el workslow, validemos que no se encuentre instalado el apache, ftp ni existen los usuarios y grupos en el inventorio seleccionado y que todos las tareas individuales del worksflow apunten al mismo inventario

Podra observar que el flujo de trabajo se completa de forma exitosa, haciendo mas facil la concentenacion de tareas

Laboratorio 05


Al igual que su instructor, cree un plantilla de flujo de trabajo compleja, se recomienda clonar sus plantillas individuales y modificar el inventario a servidores de produccion.
Realice el siguiente flujo de tareas: inicie con la creacion de un usuario, luego de un grupo, luego en paralelo la instalacion de apache con su webcontent custonizado y la instalacion del ftp, cuando terminen el ftp y el web recien asigne el usuario al grupo
Realice todas las operacion con variables ingresadas con formularios y en los servidores de PROD
Antes de iniciar el workslow desintale el servicio httpd y vsftp e intente con usuarios y grupos que no existan en los servidores de PROD

Respaldo y recuperacion de la plataforma

Como parte de las operaciones avanzadas en la plataforma Ansible Tower, es importante respaldar la plataforma de forma programada, para ello usamos el siguiente procedimiento

mkdir /var/backup
cd /root/ansible-automation-platform-setup-bundle-1.2.5-1/
./setup.sh -e 'backup_dest=/var/backup/' -b

Luego borramos una plantilla de workflow en la plataforma y procedemos a restaurar desde el respaldo anterior pero ahora apuntanto no solo a la carpeta de backup sino hasta el archivo tar.gz

cd /root/ansible-automation-platform-setup-bundle-1.2.5-1/
./setup.sh -e 'restore_backup_file=/var/backup/tower-backup-latest.tar.gz' -r

Laboratorio 06


Respalde su plataforma de ansible tower
Borre algunos plantillas de trabajo de su infraestructura(sin borrar los archivos .yaml o del git)
Restaure su plataforma desde un respaldo anterior

Laboratorio Propuesto


Poblar su GIT privado con todos los playbooks usados en clase
Crear un workflow nuevo, similar al realizado en el Laboratorio 5 pero con todos los playbooks usados desde su GIT personal, no use los playbooks desde el proyecto TestX
Ejecute su workflow pero asegurandose que el servicio apache y ftp no esten instalados, en caso de estar instalado puede removerlos con yum remove httpd vsftpd y cree usuarios y grupos nuevos

⚠️ **GitHub.com Fallback** ⚠️