Talk “Automate to Innovate” at FLISoL CABA 2023

Hello, good afternoon to everyone, everyone, everyone or however you perceive yourself.

My name is OSiRiS, I work at gcoop ¹ and I am known as OSiUX ², in the community.

eee, and last night at 12hs I was in a dilemma… whether to do the slides for the talk (always the last night) or install Debian 12 ³

I chose to install Debian 12, because I felt like it, this eee and actually because the HDMI output didn’t work before so it was a good decision because now we can see, this…

…and partly also because I didn’t want to show only slides static but I wanted to show a little, something live.

…eee we are going to try to make the internet accompany us, this and more than nothing I wanted to comment briefly…

A little experience of using Ansible ⁴ that we have in gcoop.

And it has allowed us to innovate thanks to the fact that we automate a lot of tasks.

In that, the success story that we have been showing is the process of…

Wait for this to work… arrghh… I touched the zoom and it doesn’t work there nothing there, CTRL+F5 there, it is!

Well, Banco Credicoop ⁵, had all the Subsidiaries, it is say 300 Subsidiaries throughout the country, with 3000 jobs using obsolete technology, “Windows 2000” was what they used and Well, we had to move it to GNU/Linux and to do it, um…

Well, Bank came to gcoop, since we have been their suppliers since a while ago.

…and the idea was how to do that migration, that migration process, or That is, if one says Install SoftwareLibre, how can you do it here in InstallFest ⁶, it’s like…

Yes, under an ISO, I put it on a pendrive, I put it on a computer, ENTER, ENTER, ENTER and a while and that’s it!

Well; It’s a simplified version! Let’s say!

Then there are other conflicts, at the end user level, you have problems with the video driver, with the network driver, with the sound, with the performance…

With a lot of things. But in the relationship of 1 person with 1 machine, it will be more or less time, you solve it!

Now if you have many teams, as is the case with Bank, the migration was 6300 jobs, this is the Bank and it is all the teams that we manage from a single virtual one, which is called AWX ⁷ and that is walking around here in the center, it is this gray that It’s over here, that team, only that team controls 6300 hosts!

And what does it control? It’s good, what operating system is installed how that operating system is configured, what services are installed, how those services are configured, if a service needs to be restarted, if It is necessary to connect that service with another service, in short any An operation that was traditionally done by hand is now done by hand. automated, that is, no one puts their hands in the equipment, we cut off their hand to SysAdmins, this one, why? Not because of bad vibes!

If not, because when you have many teams, it is very difficult for everyone to they fit you the same, so that they all fit you the same, what you have to do is automate everything you can, so that they are reproducible, if If a piece of equipment breaks, I have to put one in the same conditions as was before, to put something that is in the same condition as It was before, how do I do it?

Do I have a very good memory or do I have versioned code?

Infrastructure as Code ⁸, that code will be able regenerate that equipment, this again and again, or correct it in case be necessary.

There is a more complete talk about this that I gave last year in nerdearla ⁹ and I invite you to watch it on the channel nerd it out!

…Or on my site osiux.com ¹⁰ is there, there is a transcription of everything I said ¹¹, so there is the technical detail of each portion, but good basically to make a summary of what I wanted to show, it’s like…

We use all free tools, we rely heavily on Ansible, we work with GitLab, AWX is the graphical orchestrator of Ansible that allows multiple people to operate and make, trigger executions of these automations, without knowing code, simply making some clicks.

We integrate with a AD (ActiveDirectory ¹²) the part of the users, works with FreeIPA ¹³ that we allows you to integrate users from “Windows” to users Free, we work with Debian and with a distribution based on Debian also…

And well, it took us 4 years to do this, it is working, obviously Every day something comes up, and you have to correct it, but good for synthesize…

This AWX that obtains the code, of what it has to do, each task that has to be done, that is connected, for example in the case of servers to the iDRAC ¹⁴ which is the server’s server, the computer’s computer, and it tells you, configure the disks of this way, create the RAID, partition it, whatever is needed, that then it restarts it and triggers the execution of a server PXE ¹⁵ which takes the image of a Debian NetInstall that installs itself, it is say there is no operator intervention, you set it and leave it pre-installed so that the operator then triggers a workflow that launches the execution and installation of a Proxmox ¹⁶, to to do the virtualization and then that triggers the execution of the creation of 10 virtual, different, with different services and for that is supported by other equipment that is within the network, which does is cache cache cache for this to work throughout and width of the entire country.

That is fully automated and in the Production instance when all the jobs had to be migrated, when they took those servers, all those positions had to be configured and in some Subsidiaries, I don’t know, you have 60 jobs and it has to go out working, it doesn’t matter if that job is, I don’t know, in a management, in a secretariat, or in a checkout line, is the same free operating system, and in fact if you had the urge you can Take it out of the receiving station and put it in a checkout line and you have You have to go out walking and if it breaks, you throw it away and put the same one, and you send deploy from CasaCentral to I don’t know, Salta or any place in the country.

How is this triggered? Well, let’s see if it works…, in the Bank I’m ogomez I’m not osiris, if I remember my password…

This would be the AWX of Development that we have, and basically what is see is a panel where the different options are, the executions that were being made, and here are the templates that were used recently, for example wst_bra was executed, which is what allows this do a scan of what positions are on in the network and a workflow from Proxmox that creates virtual machines, we can see, there it is Green is everything good, Red is everything bad, but it can be turned back to run until it hits Green, over and over again!

For example, we have a workflow that starts and fires, a workflow that triggers other workflows, and is from the virtual machine Ansible, that of the Server FTP, that of the server PXE, that of the server of Log, the GIT server, the Print server, the CDN server, APT cache server and FileServer, and each of these workflows, if we look at them, we are going to look at a task completed, this one for example, we can enter, here it gave everything in Green and As you can see, they were all executed in parallel.

If we see here, this workflows node has, in turn, more tasks, and This one, the first one is, what it does is configure cloudinit, which is something which helps us configure the virtual machines, establishes the apt configuration.

The configuration of what the service of this particular VM is, and applies security criteria, so that is very important, Let’s say this is how you heard about DevOps ¹⁷, There is also DevSecOps

I can go into the detail of the execution of each of these nodes and see the log output.

This log output is exactly the same as if you run Ansible from the console line with a Playbook, is what you will return, the color criteria is: Green everything is fine, Red, error, everything is wrong, this.. Celestito is something that was ignored and can be an unexpected error that is possible to happen and one can ignore, Orange is something that changed, that is, the state changed, and Let’s see if we can see something here that is understood…

Ahhh… The machine is a little slow, well, or is it just me… Also…

This log, the result in this case is a JSON, but it can be a output standardoutput common and well here what I was doing is testing the cloudinit configuration, let’s look at something else in detail, for example here, we see something in Orange that changed and it is this file cloud.cfg

…tiene una expresión regular, acá lo que estaba buscando era esta línea que dice manage_resolv_conf que me tengo que asegurar que esto este en una configuración en un archivo en 3000 equipos, sino es de manera automatizada, no puedo garantizar que esto este en esas condiciones, es decir solo aplicando permisos no es suficiente, porque las personas nos equivocamos, cometemos errores, pero por sobre todo por más que tengamos buenas intenciones, a veces aplicamos una mejora y esa mejora no la versionamos, no es persistente dentro del equipo, entonces se reinicia el equipo y se pierde esa configuración, entonces caemos con el famoso que raro! Que no anda!

A veces te anda, a veces no!, proba con reiniciar, bue…

Para evitar todo eso tenemos esta herramienta que nos permite, publicar código y deployarlo, vamos a ver ahora otra cosa…

Esto es… Espera a ver si me anda…

Parte de la charla lo que quería mostrar también, es…

Hay una serie de scripts que fui construyendo con BASH que es lo que siempre tengo a mano.

Que básicamente son scripts bash que lo que utilizan es el cliente de consola de AWX, es decir AWX lo puedo usar de manera gráfica, que esta pensada más a nivel operador para que dispare ejecuciones…

O a nivel de consola y como hay muchas posibilidades y comandos, para automatizar el uso de la consola hice unos scripts que simplifican esa tarea porque son muchos comandos y asumen un montón de valores por defecto, pero digamos si yo quisiera lanzar un comando, en un equipo y no tengo ganas de ir a la interfaz gráfica, loguearse en AWX, ir la cantidad de saltos que son como 15 saltos para poder hacer algo efectivamente, bueno podés tirar un oneliner, que diga…

Bueno conectate, el awx-cli se conecta al servidor AWX y le dice bueno, ejecutá este trabajo, con estos comandos, con este límite, y devolveme la salida, la ejecución que disparo desde la consola, queda almacenada en AWX, entonces alguien puede estar monitoreando en AWX gráficamente y ver todo el detalle, esto que me garantiza, que tengo trazabilidad sobre todas las operaciones!

No hay problema con romper algo, cuando alguien rompe algo, lo que queremos es evidencia, para saber que sucedió y cómo corregirlo, porque si alguien entró, digamos por SSH, de modo oscuro que es, nadie esta viendo esa salida, no vamos a saber que sucedió, esto es lo interesante, no hay problema con romper, si lo rompemos, esta registrado en el log lo que pasó, y lo podemos arreglar, si no sabemos que pasó es muy difícil y perdemos tiempo en el diagnóstico.

Entonces para simplificar la operatoria, hicimos una serie de scripts, hay un montón, o sea son más de 200, que nos permitieron simplificar el Desarrollo para hacer esto.

A ver si me funciona…

Tengo un error acá, esto es… mmm…mmm..

Como tenemos varias instancias de AWX, tenemos una de Desarrollo, donde podemos jugar tranquilos, sin romper mucho, sin mucho daño… Tenemos una de Staging, y tenemos una Productiva, entonces a veces yo tengo que pasar de una instancia a otra, bueno entonces ya tenemos el primer comando que es awx-config, le digo el entorno y eso va a definir, una URL con ciertos túneles, el usuario, y me va a decir, che ya estas llegando a este servidor de Desarrollo y con estas versiones de AWX, del ansible-tower-cli ¹⁸, y de Ansible en si.

Yo podría decir, desde acá, eee…

Por ejemplo, awx-adhoc-shell ¹⁹ que voy a entrar a un equipo y que voy a tirarle un comando, el inventario le digo wst que son las WorkStations y le voy a poner un límite, que es el lugar donde podemos romper tranquilo, que es Desarrollo y después le puedo decir el comando, por ejemplo, voy a hacer algo leve que es el uptime, funciona? Vamos a ver, si tenemos suerte…

Los WARNINGS los ignoramos siempre :P no importa esta todo violetita, bueno…

Rojo esta todo mal, Rojo son los equipos que no llegamos, dice UNREACHEABLE…

No sé porqué no llegamos, puede ser que estén apagados simplemente, o puede ser problema de Firewall u otra cosa…

Pero si llegamos a un equipo acá, y nos contestó y nos dice, bueno esta arriba hace 32 días, esta operativo

Tiré un comando muy tonto, pero bueno, terminó la ejecución y el Job dice que falló porque la tarea la estoy tirando en todo el inventario con varios equipos, entonces yo podría, decir, che bueno…

Supongamos a que a mi no me interesa, ese equipo 662, no lo quiero ni ver, bueno le puedo decir host-disable

No queremos ver ese WARNING, así que lo deshabilitamos y ahora ese equipo esta deshabilitado, al estar deshabilitado, nadie puede operar sobre él…

Y vuelvo a tirar la misma tarea de antes, en el inventario wst tengo 3000 equipos, tengo un grupo que es Desarrollo donde ahí puedo romper tranquilo, vuelvo a tirar la misma tarea, así que ahora tengo la ejecución de 2 hosts, uno falló, el otro salió bien.

Esto que ejecuté desde la consola, digamos, modo Hacking oscuro, si voy al AWX, a Trabajos, tengo el registro de las tareas que se lanzaron, veamos la última, y ahí me dice, bueno, quién la inició, cuándo, con qué parámetros, o sea queda el registro completo de todo lo que se hace en un equipo.

Y esto es en función de la cantidad de espacio que tengan, puden almacenar, no sé 10 años de ejecuciones sobre un mismo equipo, sobre 3000 equipos, sobre 6000 equipos o todos los equipos que tengan y que necesiten.

Y acá bueno, es un poco más agradable la salida, pero es básicamente la misma, hago CTRL+F5 y obtengo más datos, se actualiza, esta un poco lenta la Internechi, vamos a mirar acá, esta salida, lo puedo ver como un JSON, como salida standard o si tengo un error, la salida de error.

Bueno, como funciona esto, simplemente tiré un comando aislado.

Ahora si yo quiero trabajar algo, más permanente, por ejemplo, vamos a ver, en una Workstation como se hace, cómo se actualiza una Workstation

Pregunta, el comando que tiraste anteriormente, es un comando que esta en la consola del AWX, es un comando local, dentro de AWX o…

No, es un cliente que esta instalado en mi máquina, que se conecta por un túnel ahora detrás de una VPN y llega al servidor, por medio de la API de AWX, entonces ya el cliente te maneja, vos le podés hablar directamente a la API desde otra cosa si quisieras, respetando la API, es una API REST, lo interesante es que te devuelve todo el resultado completo y te mantiene el registro, no es que lo tienen aislado.

La ejecución que hago, no es solo para mi, es en el servidor y todo el mundo la puede ver, digamos, especialmente, Auditoría!

Bueno, esto es un playbook, esto es un playbook de actualización de una Workstation, lo se hace es definir variables, de qué es el comportamiento que espera, hay tareas, pero antes de las tareas, hay pre-tasks, pre-tareas, hay algo que se llama roles te también se pueden usar y básicamente de esta manera uno va construyendo…

Todas las tareas que uno quiere que se realicen en un equipo, por ejemplo, acá tenemos un fix que es, que…

Usamos algo que se llama autofs ²⁰ que permite montar de manera automática un filesystem cuando se inicia el equipo y bueno, teníamos un bugcito y lo básico de ansible cada vez que hace una tarea es que más allá de la definición de tarea, lo importante es cuándo se va a ejecutar esa tarea, siempre conviene poner condicionales, es decir cuando está definido que haga esto y está en true, bueno hacelo, sino no

Si vemos esa tarea, básicamente lo que esta haciendo esa tarea, bueno se fija que existan los archivos de configuración, en caso de estar definido, restaura unos archivos de configuración que hacen falta y reinicia el servicio.

Entonces para reiniciar un servicio remotamente, la tarea es tan simple como, esto básicamente, un nombre que es un texto, el módulo servicio (service), en name le pones el nombre del servicio, que puede ser cups que puede ser cualquier otro, acá es autofs y el estado que querés, en este caso que este reiniciado (restarted), si el servicio no estaba corriendo, bueno lo va a iniciar, en este caso.

Entonces, de esta manera, vos podés decir que bueno todos los equipos, querés reiniciar el servidor de impresión y lo podés hacer a todos juntos.

Y cuando lo ejecutes vas a tener la salida de eso, en el AWX.

Ahora vamos a mirar una plantilla, por ej. vamos a mirar algo interesante, vamos a entrar a Producción un ratito, pero no vamos a romper nada, lo prometo, no soy osiris, y esto, acá, bueno acá casi DANGER metemos la pata.

Si voy a inventario, por ejemplo vamos a ver el wst que les comentaba…

Acá en servidores, vamos a ver, tengo muchos servidores…

Los equipos los tenemos identificados con el número de serie que esta dentro del mother, así sabemos que son esos equipos y no otros y por ej.

Elegí un equipo al azar, y ahí me dice, cual es su IP, cual es su MacAddress, cual es su hostname.

Lo que hicimos, es que los equipos todo el tiempo, que cambian su IP le avisan a AWX y actualizan los datos, entonces están siempre rastreados.

Un equipo puede pertenecer a uno o más grupos, en esos grupos, uno define las variables que quiere que lo afecten.

Y podemos ver el historial, por ej. de este equipo, en tareas completadas, qué se hizo, cuándo y quién lo hizo y tenés todo el historial de ejecuciones, de todas las tareas que se le hizo, entonces por ej. acá no tengo el detalle, vamos a expandirlo, ahí…

Bueno, tenemos en Verde y en Rojo, por ejemplo, este WoL es una plantilla que lo que hace es prenderlo remotamente, si el equipo esta apagado, venís acá y lo prendés, podés prender uno o podés prender todos los equipos al mismo tiempo o de a grupos.

Acá tuvo una actualización, a la versión 1.6 y de hecho falló y seguramente más adelante, después lo corrigieron, pero si querés ver porqué falló la actualización de ese equipo, tenes el historial, y vamos a ver acá, un poco más en detalle…

Bueno el equipo que falló acá, es ese que esta allá y esta en Rojo y pero esta en un ejecución donde el límite había sido toda una Filial, o sea, esta en un grupo de muchos más equipos que se estaban corriendo, así que a esta escala, uno trabaja los equipos no como mascota sino como ganado.

Bueno, hay un montón y ahí hay uno que, después vemos que le pasa, lo que importa que la mayoría funcionen, y fijense en ese resumen…

Dice la cantidad de tareas OK, en la mayoría que esta en Verde, dice 7 tareas que tenía que hacer y las completaron

La segunda columna dice las tareas que cambiaron

La tercera UNREACHEABLE, que es este equipo, que no llegó, no es que falló, ni siquiera llegó al equipo porque, no sé, estaba apagado, se aflojó el cable de red, no sabemos, no importa ahora eso, pero esta claro porqué no se actualizó.

Las tareas que fallaron, las tareas que se saltearon porque no era necesarias hacerlas…

Y si voy un poquito más arriba, ahí tengo cada una de las tareas que se fueron realizando, por ej. en este equipo, este que termina en MNC, la plantilla era actualizar, esperen a ver si me sale esto, esta plantilla era actualizar la versión 1.6 y en el caso de este equipo en particular, acá el mensaje es “ya está actualizado”, entonces, no hay que actualizarlo!

Esta bien, dio Verde, Verde es como tienen que estar, como se diseño que esté.

Porque cuál es el principio de Ansible, uno no puede controlar el estado de los equipos, uno lo que puede hacer es llevarlos a un estado conocido, a un estado que uno quiera.

En todo caso si todo eso falla al intentar llevarlo, uno lo que puede hacer es volver al estado anterior, y ese estado anterior puede ser volviendo a una imagen original o ejecutando la versión anterior de la plantilla que se definió para eso.

Ahora bien, para …, tenemos un montón de plantillas o job_templates que hacen un montón de cosas en diferente equipos, bueno, hay un montón de tareas, bueno voy a salir de acá, entonces hay que hacer plantillas.

Cómo se hace una plantilla, estamos en Desarrollo, voy a plantillas, digo Nueva, plantilla de trabajo, le ponemos nombre, una descripción, va a ser una plantilla de ejecución, le decimos, che esto va a ejecutar en este inventario, que va a ser el de las Workstations, le digo Seleccionar, OK, le digo que proyecto…

Entonces voy a elegir el proyecto, a ver voy a elegir uno que no haga mucho daño, este, ahí elijo el playbook que tiene ese proyecto.

Le tengo que definir las credenciales con que se va a conectar AWX a ese equipo o grupo de equipos.

Le puedo poner un límite, ahora le voy a poner un límite y además le puedo decir que pregunte, re-pregunte el límite en momento de ejecución.

El nivel de log, si quiero o permito en realidad que esta plantilla se puede ejecutar al mismo tiempo más de una vez, le tengo que decir que, habilito concurrentemente y acá abajo le podría poner variables adicionales, que quiero que las tome en el momento de ejecución, que esas variables adicionales lo que harían es, sobreescribir los valores originales de las variables, no es recomendable, pero bueno a veces falta hacerlo.

Luego digo Lanzamiento, para ejecutar, yo definí un límite, ahora me pregunta, vamos a decirle la 145 , le dijo ejecutá, digo Lanzamiento, ahí es la instancia de verificar “Está seguro lo que va a hacer”, yo le digo todo que sí, y ahí va a disparar la ejecución, esta ejecución no la esta disparando desde mi máquina, la esta disparando desde el servidor de AWX, al servidor de destino.

Y lo que hace AWX es se conecta vía SSH a ese equipo, para poder conectarse hay que definir las credenciales antes, y ejecuta las tareas que tenga este playbook.

En este caso lo que va a hacer es instalar un script que lo que va a hacer es ping a ciertas IPs, y va a guardar en el log ese monitoreo para saber si no hay pérdida de paquetes por ej. en este caso, lo define en el cron, lo reinicia, y lo deja operativo, o sea acá terminó dice correctamente (successfull), vamos a mirar alguna tarea, por ej. esta, que básicamente define una tarea en el cron y esto es importante…

Porque cuando uno tiene muchos equipos, si define una tarea en el cron de un equipo, después se olvida que lo hizo y después por algún motivo pasa algo en ese equipo y después de 3 días… Ah cierto que en el cron, habíamos puesto que se reinicie a las 2AM y nadie se acuerda de eso, bueno, es importante acá que lo podés hacer con un rol, podés definir las tareas versionadas y eso se aplica en el cron en todas las máquinas que hagan falta, porque a veces, te dicen al otro día, che hay una que no anda a veces, el a veces, porqué el a veces, no sabemos, pero bueno la apagaron y cambió algo.

Bueno acá queda registrado y es muy simple de definir.

Ahora para hacer toda esta cantidad de plantillas, era como mucho trabajo, no?

Bueno a mi por lo menos no me gusta hacer clics, me gusta usar la consola, y entonces dije bue! Esto se tiene que hacer de otra manera!

Entonces, ahí es donde viene nuestro amigo GitLab a ayudarnos con la CI, vamos a buscar algo reciente, que sirva de ejemplo…

Pregunta: podés ver qué plantillas se ejecutaron sobre cada equipo?

Respuesta: Si, podés ir del lado tengo plantillas y quiero ver en dónde se ejecutaron o puedo ir al equipo y ver qué se le ejecutó.

Tenes las 2 visiones, pero cuando tenes muchos equipos, tenes a hacer un inventario dinámico y entonces puede ser que a veces pierdas, o sea esta la información pero esta como en 2 universos separados y eso es difícil de relacionar.

Acá yo tengo un rol, que lo que hace es instalar unas utilidades de un servidor que se llama FreeIPA

Y para instalar y configurar esto, nada mejor que usar el pipeline de GitLab para saber si nuestro rol cada vez que le agregamos un cambio, funciona y no esta rompiendo algo.

Para poder hacer eso, en GitLab podemos buscar acá un error, esto fue hace 1 mes y fui yo el que metí la pata, acá me dice, bueno mirá, acá el GitLab dice está roto directamente, cuando metí el commit ya hice macana!

Vamos a buscar algo más acá… Que tienen bastante en Verde, a ver algo anterior que sirva de ejemplo, bueno vamos a mirar igual una ejecución exitosa, es decir acá queda…

El GitLab dispara la ejecución, en este caso, para chequear que el rol que yo estoy publicando, de Ansible para que después lo lea AWX, esté en condiciones de ejecutarse.

O sea que no tenga ningún error, hace un chequeo básico, pero también, ahora lo voy a buscar, lo que hicimos es agarrar, que en lugar de ir a AWX y disparar la ejecución o desde mi consola disparar la ejecución.

GitLab se ocupa de ir a AWX y disparar la ejecución y mostrarme la salida, entonces de esa manera que tengo, que cada vez que meto un cambio, GitLab dispara las ejecuciones por mí y yo no tengo que estar mirando que es lo que hace, a lo sumo salió exitoso o salió fallida, me va a llegar una notificación y si están fallidas y esta en un branch yo no voy a poder hacer un merge de ese branch a algo productivo porque esta con errores y no me deja porque es una configuración de GitLab que se pone a propósito.

Y para automatizar un paso más esto, para que no solo lo haga GitLab, proveer estas plantillas dentro de AWX en lugar de ir haciéndolo a mano, lo que hicimos son unos scripts que lo que hacen es un deploy… Y vamos a buscar ahora…, hicimos un repositorio que se llama awx, que tiene esas plantillas en formato de JSON

Y los scripts que invocan a el cliente de AWX a su vez están versionados en un repositorio en GitLab.

Vamos a mirar un deploy reciente y va hacer el deploy, en este caso primero en un ambiente, primero lo hace en Desarrollo y si salió todo bien lo hace en Staging, Staging es más parecido a Producción, acá tenemos uno, otra vez fui yo…

En realidad fue GitLab, bue, acá… Y acá esta interesante este deploy..

Acá es: GitLab, tomó un repositorio que se llama awx, donde yo le envié el código que quiero que se publique en AWX y lo que hace es, revisa eso, se lo manda al AWX de Desarrollo que es el lugar donde podemos romper, manda la plantilla y cuando manda la plantilla, yo le puse…

A ver si se ve un poquito más arriba… Me falla el scroll… A ver…

No me deja ir más arriba, bueno… Acá lo que me dice es…

Algo que le pusimos al deploy es, che, fallá si no encontrás la documentación de esta plantilla, porque si no nosotros, hacemos plantillas y después cuando la quieren ejecutar dicen, qué hace esta plantilla? Y ahí decís, te mando un mail.

Bueno, entonces, ya en el Desarrollo, si yo no estoy haciendo la documentación de esta plantilla, ya esta fallando, esta diciendo, es un recordatorio, mirá que tenés que acordarte de hacer la documentación, y no me va a dejar pasar, hasta que yo haga la documentación…

La documentación después puede decir… Este título… Je je y nada más!

Pero bueno, es un chequeo y es un chequeo básico, pero que funciona.

Ahora vamos a ver, en ese caso no funcionó, más adelante, el primer circulito Verde es, Desarrollo, el segundo es Staging, vamos a mirar que hizo el deploy…

Y acá tenemos… Este… Vamos más arriba… Más arriba… Mucho… Ahí… Bueno…

Esta ejecución… Cuando uno hace un push de código, es..

Se baja las ansible_tools para tener la última versión disponible, se pasa al branch de Desarrollo, porque estamos constantemente en Desarrollo, genera las credenciales para configurar el acceso para GitLab pueda entrar a AWX Desarrollo, con el usuario de Desarrollo, que le permite disparar ejecuciones

Queda ahí el registro entonces que…

Y fíjense que queda ahí esta el MASKED, se ocultan las credenciales, no queda ningún secreto en el log visible

Dice exactamente con qué versiones se configuró, que branch esta queriendo correr, el pull que hizo para obtener la última versión, y acá lo que esta deployando, en este caso eran unos grupos, entonces se fija que este el grupo, que queremos…

Y en este caso, esta haciendo una actualización de variables, este…

Que esta cambiando unos textos, nada más, algo que podría cambiarlo algo a mano

Lo que sucede es, que este cambio que había que hacerlo a mano, hay que hacerlo en un montón de lugares, varias veces

No se, como… Era… eee…

9 cambios en 3 inventarios por 3 grupos cada inventario, es muy fácil, aunque hagas copiar y pegar, que en alguno te quede distinto!

Entonces la solución es hacer código y que este código, sea testeado por una herramienta automatizada, digamos que…

No tiene corazón, va a fallar ante el mínimo error, no te va a dejar pasar una!

Y en este caso que esta haciendo cambios de variables, de lo que vos versionaste, con lo que esta en el servidor de AWX, te va a mostrar un diff del cambio!

Entonces, si hay algo, que tenía que estar y está en AWX y esta bien que esté en AWX, pero lo editaron a mano y nosotros no llegamos a versionarlo como deberíamos, bueno al menos en el log esta, y vamos a poder ver ese cambio de ser necesario.

En este caso son este… eee… Cambios menores, pero bueno…

El ejercicio de hacerlo una y otra vez de manera automatizada, garantiza la calidad del código que finalmente llega a producción.

Y para que esto llegue a producción, o sea, esto mismo lo hicimos en Desarrollo, y si volvemos a la página anterior…

Ese mismo commit, en el “circulito” que sigue acá, lo hace en stage y stage es más parecido a Producción, porque nadie lo esta operando…

Este eee… Y es casi como deployar en Producción!

Si me da bien en Desarrollo, también me tiene que dar bien en Stage

Y para que pase a Producción, esta ejecución, actualmente lo que hacemos es… Le echamos la culpa a “les SysAdmines”

Si tienen un problema es problema de SysAdmins!

Bueno… Esto no fue Desarrollo, pero es la misma herramienta automatizada, son los mismos pasos!

A veces sucede que nos encontramos que hay diferencias de entorno, recuerden que es muy difícil, tenemos un entorno con 6300 equipos en Producción, es muy difícil de reproducir y simular!

Entonces, bueno, pasamos varias instancias y a veces llegan errores, normalmente, lo descubrimos eso y lo corregimos y lo volvimos a pasar por la interfaz de GitLab hasta que dé OK y ahí recién lanzamos la versión a producción.

Esto lo que yo veo como que, es una persona que trabaja por mí en testear, que es algo que es bastante aburrido, digamos…

Y si yo disparo la ejecución, ni siquiera disparo, ni siquiera entro al GitLab, o sea yo estoy en mi línea de comandos, hago git push y me voy a hacer un mate tranquilo, me voy, cuando estoy en la cocina, GitLab me va a avisar, me va a mandar un mensajito “no anda nada”, fijate que hacés, volvé!

Mientras vos disparas esa ejecución, no te tenés que quedar mirándola, te podés poner a hacer otra cosa, otra tarea al mismo tiempo!

Y después más tarde vas, revisas y vez si pasó, en un equipo de Desarrollo que somos varias personas, es decir, si alguien esta teniendo un inconveniente con una tarea…

Tener una reunión virtual para ver que estaba haciendo, que te cuente lo que pasó, durante los últimos 3 días, para tratar de entender lo que esta pasando, es una pérdida de tiempo!

Es mucho más simple ir, bueno a ver cuál fue el Job que ejecutaste, el último, bueno, vas mirás ahí y tenés todo el contexto necesario para saber que hizo, este… Yo…

Mi tarea y lo hago conmigo mismo, digamos no es que no tenga corazón, es…

Tengo mi compu llena de capturas donde digo “ahhh, esto acá esta mal!”

Y lo hago todo el tiempo porque, llega un momento que hay tantos valores que es muy difícil entender

Es muy difícil, ver dónde esta el error, es como todo el tiempo jugando a las 7 diferencias!

Entonces GitLab te va avisar y te va a tirar, “che acá hubo un error”, pero a veces hay que tratar de entender ese error, entonces señalarlo!

A veces, el error es, vos mismo pusiste un valor, que no debería haber ido, pero bueno, llegó, y eee…

Para simplificar esto… Salgo de acá…

Tengo por algún lado… A ver si lo encuentro por acá… Creo que acá… Acá…

Acá hay una simplificación de lo que estuve mostrando…

Tenemos a les DevOps, GitLab y AWX

Hacemos un git push de tu entorno local a GitLab

A partir de ahí todo lo que sucede, lo hace GitLab, GitLab habla con AWX, y bueno, primero se fija que los JSONs estén bien, que no tengan ningún error, genera la configuración de AWX, que este bien, que pueda llegar, envía el team, envía el project, actualiza el project, envía el inventory_source, envía el inventory, actualiza el inventory_source, envía el workflow y si este…

Otorga permisos, revoca permisos, y si todo eso salió bien, recién volvés a trabajar vos digamos en eso, no es que no estás haciendo nada, sino que estás trabajando en otra cosa!

Hay un montón de tareas que están automatizadas!

Vos no las tenés que hacer una por una, que es muy probable que te olvides algún paso!

Es decir, que de esto se ocupa GitLab y AWX.

Ahora esto no es magia, son herramientas que construimos nosotros, que nos equivocamos todo el tiempo, cada tanto hay que corregirlas e ir mejorándolas.

Ese código, este… Esta disponible, en GitLab, los que usan Ansible lo pueden obtener!

Si esto se digna a funcionar… Acá… eee… Para… pa..pa..pa… Dónde, acá…

ansible_tools esta en GitLab, en GitHub, en mis repos personales, en los repos de gcoop, en Codeberg y no sé dónde más…

• https://github.com/gcoop-libre/ansible_tools
• https://github.com/osiris/ansible_tools
• https://gitlab.com/gcoop-libre/ansible_tools
• https://gitlab.com/osiux/ansible_tools
• https://codeberg.org/osiux/ansible_tools

O sea, está en todos lados, está público todo, y son un montón de scripts que hacen las cosas por uno!

De hecho cuando tenemos que hacer las diferencias, las configuraciones, un montón más de, llamemos burocracia…

Hay documentación automatizada que se autogenera y la hacen los scripts para no cometer errores!

Por ejemplo, yo estoy… eee… Este por ejemplo, este bonito README y bueno, que tengo esta versión, se hizo tal día, en este archivo, esto lo hace un script que esta dentro de las ansible_tools.

No hay que estar haciéndolo a mano, si quiero ver, qué incluyó una versión, y qué es lo que tenía… Si vamos a esta por ejemplo…

Entonces, esta documentación también se generó, dice el commit, quién lo hizo, cuándo, qué es lo que trae, qué es lo que cambia, qué permisos otorga, también se hizo, todo de manera automatizada…

La idea es, que todo lo que se tenga que hacer más de una vez, lo automatizemos, no suframos, esteee…

Y lo interesante por ahí es comentar es, que para…

La única manera que creemos posible de llevar adelante este tipo de proyectos, con esta escala, es automatizando, la única manera digamos, o perdemos menos tiempo, digamos…

Después como todo, no es magia, estamos todos los días peleando con algo nuevo, “huy porqué falló esto acá si antes no falló”, bueno es ir corrigiendo y mejorando la herramienta.

Pero hay un montón de tiempos que ya no le dedicás más, sobre todo lo mejor es que vos mismo que lo hiciste, al otro día lo podés revisar en el log y no sé qué estaba haciendo acá…

“Son más veces las que falla, seguro, hasta que sale, pero tenés alguien que revisa por vos, cada punto!

Es decir, por ejemplo, esto, revisa que este la documentación, revisa que el nombre del branch coincida con el nombre de la plantilla y la plantilla apunte a ese branch, que es una pavada, pero que cuando estas escribiéndolo a mano, ponés un punto, una coma, algo ponés mal siempre, das vuelta los números, yo doy vuelta los números siempre.

Y después tenés los errores de producción, que son más graves, tenés una tasa muy alta de errores en Desarrollo, pero una vez que liberás esto, si se hizo de la manera reproducible y repetible y te quedó el log.

Pasó todos los controles en Desarrollo, pasó todos los controles en staging, a producción es raro que falle, puede ser, pero son menos!

Y en mi caso… Tengo el placer acá que tengo varios SysAdmines que están del otro lado y que yo les digo /“por favor deployen esto!”, y yo les digo, /”deployen la versión tal”_, la 34.5, no sé

Y estas personas se ocupan de hacer eso y me dicen “ya está”!

En el medio hay un log que quedó registrado, que siempre hay que revisarlo, porque puede ser que algún error se escape, pero como que se simplifica la tarea, siempre el mismo proceso, de la misma manera.

Y lo mejor es que con una herramienta libre que la podemos modificar y esta disponible para ustedes si quieren colaborar lo puedan hacer o se puedan inspirar en todo lo que no hay que hacer…!

Bueno, eso creo que esto, no quiero marear más, si tienen algunas preguntas, yo estoy acá!

Si, en el caso de los servidores…

Quiero ver si lo tengo acá, me parece que no…

La iDRAC de los servidores, crea el RAID y configura la BIOS para que el próximo reinicio sea por PXE en esta interfaz de red y después le dice “reiniciate”, cuando se reinicia ese servidor, se reinicia en modo PXE y hay una virtual que tenemos que es un servidor PXE que dice, “bueno, si aparece un servidor que matchea y dice DELL yo le mando un Debian”, así!

Y es un Debian que lo que hicimos es un preseed que no tiene interacción humana, osea que es un preseed que automatiza y rompe todo digamos, reinstala, y busca, de hecho ahora tenemos un inconveniente, cambiaron el modelo de servidor y lo que antes era sda ahora es sdb y tuvimos que meter…

Claro, cambió algo ahí y bueno tuvimos que meter mano en ese preseed, pero bueno, ya lo solucionamos y entonces se reinstala el Debian desde cero, o sea, si ya tenía, lola, o sea, como agarra la primer partición, instala todo de cero, un Debian pelado, una vez que termina ese Debian pelado, te queda…

Cuando se instala ese preseed se dispara la ejecución y se da de alta ese servidor en AWX y le dice yo soy tal IP y tengo tal MAC y estoy disponible para deployar!

Después hay un operador que dispara otra ejecución o se se podría automatizar por tiempo, bueno lo esperamos x tiempo y ahí la lanzamos, pero generalmente como son servidores, son equipos caros, hay una intervención, bueno mirar a ver que pasó?

Si salió todo bien dispara la ejecución del workflow, y ese workflow, instala el Proxmox, se baja unas plantillas de unos Backups de VMs, usamos KVM.

Instala un Debian Base de KVM que es el Debian Cloud image, que es bastante standard, el mismo que usan Amazon u OpenStack

Y ahí se le dispara la ejecución de un tercer workflow que instala y configura los servicios de cada virtual, son 10 virtuales, cuando termina todo eso, hay un intervención manual porque, ahí nosotros no tenemos acceso, hay una de esas virtuales que es la VPN, entonces ahí hay una configuración manual de la VPN, por una cuestión de credenciales y también por una cuestión de conectividad que en remoto es difícil de emular.

Y una vez que eso esta y dijeron el servidor está, disparan la ejecución del último workflow que se llama de cierre, y lo que hace es dejar el equipo en condiciones para que cuando se inicie la próxima vez, esté en el lugar remoto, o sea, en Salta, por ejemplo.

Y entonces, toda la operatoria, de sacar un servidor nuevo, de una caja, enchufarle dos cables de red, un cable power, en una hora de tirar cuatro clics, digamos, de ejecuciones, anda!

Hay algunas confinaciones por ahí que hay que hacer, listo tenés un servidor ya vuelto para poner en la caja y mandarlo por el flete!

Así ese proceso, se hicieron 300 veces, entonces se llegaron a hacer 3 servidores al mismo tiempo en paralelo, digamos…

Esto además la migración la hicimos en medio de la cuarentena, así que tenía otras complicaciones!

Y bueno, llevó… La migración en sí, llevó 1 año!

…eee, esperen que tengo por acá, no se dónde… Acá…

Acá hay un poco los datos técnicos, de lo que son los equipos…

Aparecieron 3580 periféricos, pensábamos solo que eran monitores y computadoras y no, aparenten impresoras, scanners de cheques, impresoras de tickets, como todas las complejidades y además cada uno de esos equipos tiene que hablar con un montón de otros equipos que ya están digamos…

Actualmente para que tengan una idea, es como…

El proceso de por ejemplo de cheques, hay un scanner de cheques, que los scannea y lo manda de la Workstation a un VM que se ocupa de procesar esos archivos y mandarlos a CasaCentral para que en CasaCentral lo puedan verificar con otros procesos, pero automatizados también, y todo eso para que tu cheque se pre-acredite!

Si esa VM de golpe, tipo cae, lo que tienen que hacer es agarrar y mandar los cheques en una camioneta y hasta que no lleguen a CasaCentral, vos no cobras!

O sea, entonces, es crítico que todo este funcionando y además esto se envía a un servidor en CasaCentral, 300 Filiales lo envían a 1 servidor en CasaCentral que revise esos archivos y que después coincidan, no, los números!

Por esto mismo, digamos, por esta infraestructura, pasan los cajeros, digamos…

Y hay algunos cajeros que no tienen, son cajeros viejos, que no tienen vínculo directo, entonces el tesorero o alguien responsable dentro de la Filial, va con un pendrive al cajero, hace unas operaciones dentro del cajero y ese pendrive lo lleva a un puesto, que el usuario en ese momento tiene el rol de Tesorero y tiene permiso, le dispara un proceso que procesa esos archivos para que después se envíen a CasaCentral

Una manera Offline, pero porque esos cajeros son muy viejos y bueno quedaron y hasta que pongan uno nuevo o lugares muy remotos que no hay mucha conectividad también eso sucede, digamos, pensa que en todo el país, hay más angosto de banda que ancho de banda, igual toda la infraestructura tiene redundancia, de mínimo 2 enlaces siempre.

Bueno g.coop.ar nuestro sitio web y bueno acá estan algunos de los repos que estan libres, no liberamos todo porque no llegamos a tiempo, pero hay más de 200 repos!

Primero tenés que instalarte Ansible, es otro curso!

Son equipos completos, estan basados en Debian, medio lo que estan haciendo acá, nosotros en muchos equipos lo que hicimos es, construimos el modelo un equipo con Ansible y una vez que se hicieron un montón de pruebas y se dijo ya está bien!

Se hizo una imagen, una ISO del equipo, y se le mandó al proveedor de los equipos, y se le dijo “bueno, copialo vos de alguna manera en 3000 equipos!”

Entonces ya tienen una imagen base, cuando llegan a la Filial, las diferencias de versión o algunas cuestiones que son propias de esa instancia se hacen remotamente y cada tanto se genera una actualización, que es una plantilla que se ocupa de actualizar de la v1.4 a la v1.5, pero que eso puede tardar mucho tiempo a veces, por esto que decíamos del ancho de banda y porque son muchas tareas en un equipo.

Entonces a veces lo que se hace es, si el salto es muy grande, de cambios que hubo, se hace una nueva imagen base y se manda la imagen base y van con un equipo nuevo directamente y reemplazan uno por otro.

Estamos? 2 preguntas más? Si alguien se anima?

Que este chequeando todo el tiempo si hubo un cambio y si hubo un cambio haga un Update, entonces siempre lo tenes actualizado y lo podemos poner a la noche….

Soy yo, te ganaste una careta! Otra pregunta?

Alguien tiene otra pregunta?

• Cómo migrar 6300 equipos a GNU/Linux usando Ansible y AWX
• Automatizar la configuración de la BIOS usando ansible y HP Linux Tools
• Filiales GNU/Linux FLISoL CABA
• Ansible Tools v0.3.0
• Automatizar la implementación de los recursos de AWX con GitLab CI/CD y Ansible Tools
• Usar Graphviz para generar Slides
• Cómo hacer una línea de tiempo con GraphViz

• 2023-12-19 15:45 actualizar KEYWORDS, agregar poster link de descarga de video y agregar link a charla nerdearla en Charla “Automatizar para Innovar” en FLISoL CABA 2023
• 2023-12-19 14:05 agregar Charla “Automatizar para Innovar” en FLISoL CABA 2023