This project manages around 3,000 Debian servers and 3,000 Debian-Based workstations across 300 branches.

This is a real-world case study of how to provision, install, configure and maintain thousands of Debian and Debian-based systems using Free Software.

The infrastructure combines Ansible, AWX, Proxmox, PXE, FreeIPA, GitLab CI/CD and several caching layers to automate the deployment and maintenance of approximately 6,300 systems across hundreds of branches.

The project started in 2018 and evolved continuously as the infrastructure, hardware, security requirements and software stack changed.

• Demo Site: https://filiales-gnu-linux.g.coop.ar
• Original Video: WebM (298 MB)
• Subtitle Video: WebM (298 MB)
• Spanish Subtitle: SRT (50 KB) VTT (44 KB)
• English Subtitle: SRT (48 KB) VTT (42 KB)
• English Slides: PDF (357 KB)
• Spanish Slides: PDF (357 KB)

Este post es una traducción al inglés, de la transcripción de la charla Cómo aprovisionar, instalar, configurar y mantener actualizados miles de sistemas Debian y basados en Debian

• Debian
• Ansible
• AWX
• Proxmox
• PXE
• FreeIPA
• GitLab CI/CD
• Infrastructure as Code
• GNU/Linux workstation management
• Automated deployment

This year, attending my first DebConf ¹, the DebConf26 ² in Santa Fe, I took the opportunity to give the talk "How to Provision, Install, Configure, and Keep Thousands of Debian and Debian-Based Systems Updated" as an update to the talk I presented at nerdearla ³ edition 2022 which was called "How to Migrate 6300 Machines to GNU/Linux Using Ansible and AWX" ⁴

My name is OSiRiS, and I am called OSiUX in the community. I work at gcoop ⁵, which is a Cooperative of Free Software, meaning we exclusively work with FreeSoftware ⁶ in a horizontal organization. We have no bosses, no employees.

Five members (partners) from gcoop attended the event; it is our first time at DebConf. We sponsored this event and give thanks to Debian ⁷ because we have 20 years of working with Free Software, and without Debian it would not have been possible.

I will show an update to a previous talk I gave in 2022, regarding the migration project of Branches /GNU/Linux of the Credicoop Bank Cooperative Limited ⁸, which is a cooperative bank.

And I will try to quickly review the migration process and then we will look at the differences in recent years. This project…

Basically, it is an Infrastructure as Code project using Ansible

Well, at the beginning of the project, even though it took 6 months, we had to try to discover which tools from the Free Libre Open Source Software ecosystem would allow us to carry out the entire infrastructure migration of a bank across the length and breadth of Argentina.

What we found was that the automation tool was Ansible because we were already using it. We would use GitLab ⁹. For ActiveDirectory authentication within Linux, we would use IPA. For AWX, obviously all servers would run on Proxmox ¹⁰. We had been working with Proxmox for years. The VMs inside the Proxmox servers would be Debian, obviously.

And for the Workstations, due to there being 3,000 of them and for Support reasons, we chose a distribution based on Debian. This… a little more updated.

What we have there, it doesn’t show very well there, but what is moving is that… underneath are all the components; it’s a timeline, all the dependency components we use, which are being updated worldwide, all the time. I mean, at that moment, in this month, a new versión of one component came out, and another, and another. And as you are figuring out how to do things, the whole ecosystem is updating. So it’s a problem to solve.

But well, what we reached was that in Development we managed to orchestrate a deploy idea, which is basically: we have an AWX, let me point it out like this, this is an AWX, and this AWX’s source of truth is a GitLab. So, AWX reads from GitLab everything that would be… I mean, playbooks, and the first step is to deploy the iDRAC.

The iDRAC ¹¹ is the computer inside the computer. Inside the Dell servers we use, before the server even has anything, there is a small computer called iDRAC. Using a protocol called Redfish, we made playbooks that AWX connects to the iDRAC and does partition the disk, configure the BIOS, and reboot into PXE ¹². So, a brand-new computer fresh out of the box.

And immediately that will end up generating from one Proxmox, it will end up generating another Proxmox. Inside that Proxmox we have several VMs. One of those VMs is a PXE Server, I don’t see anything here for it, but it must be this one.

We have a server, well we have a CDN, which is a processing server, an Nginx that has all the resources, which in turn acts as a Proxy for another, which is an Apache, and a server that replicates this data. Well, this is done automatically and unattended, without operator intervention. That means a server comes straight out of the factory, you open the box, install power, install network, and from AWX a script is launched. This is the AWX infrastructure, sorry, the Proxmox one, we were going to see, here it shows how it launches, and this is just for monitoring, let’s say, everything is done unattended and the operator doesn’t need to see anything running. The AWX deploys the Proxmox via PXE, actually there are several stages; first it deploys a Debian NetInstall completely unattended, meaning you don’t have to touch anything, directly in OEM mode, it configures everything necessary for that server to be operational. When it finishes, in a hook, at the end of the Debian NetInstaller, we made a script that does this: it takes the MAC address of that machine, which is unique, and registers it in the AWX Inventory.

So that machine, which just received a random IP, we already know what its IP will be, what its iDRAC is, it permanently stays, for all the years that Server will last, referenced to that MAC address and to a serial number that the server’s own iDRAC has. So, in that way, it is easy to identify it.

Over there on the left, the only thing there is the debug output of what is being seen on the PXE Server, and as you can see, the Server is at the PXE Server, the Server installs itself, there is no manual intervention and it finishes installed; it’s a Debian system.

The next playbook that is launched to AWX converts that Debian into a Proxmox, also in an unattended manner. That is, we do not install Proxmox; we install Debian and convert it into Proxmox. That is an advantage of Proxmox being a distribution based on Debian: the only thing that changes is adding a repo. And done, all necessary packages are configured.

And when it finishes configuring inside a Proxmox, we launch another playbook that creates the VMs, and yet another playbook that creates the services inside each VM. All the VMs we use are KVM. This is a Bank; it needs greater robustness in Security, so all machines are up-to-date. Over there on the left you can see the creation of all the different VMs. There are 10 VMs per Server and, rounding more or less, about 300 physical servers. That gives us a total of 3,000 Debian systems. Installed automatically across the entire country.

For workstations we made an image. There we are looking at a test virtual workstation from Development inside a Proxmox. And what we do is generate a base image, also a NetInstall in this case based on a distro based on Debian. And then we configure it, also in the same way, with a script. it takes the hostname of the machine, which can be configured later or reconfigured at the destination site. It is registered in the Inventory and remains available also with a manufacturer serial number. They are all HP Workstations. We can identify them uniquely, even if the MAC address changes at some point. It’s always the same device.

The graphical interface of AWX is basically a Web page written in Django. And there are lots of operators working by launching different playbooks we made, so that this stays operational. And the PXE server also takes workstation images. That is, you can take a workstation on-site; if it got misconfigured, something happened to it, doesn’t work, it doesn’t matter. The entire workstation image is rebuilt via PXE. No time is wasted waiting to see what’s wrong with it. You don’t access the machine manually. it is rebuilt from scratch. Why? Because there are no local data within the workstation. The data is on a Kerberized NFS Server within the same network as the branch where we are.

Well, and similar to the Proxmox, we have the workstations.

For the deploy at the branch, it’s a bit more complex because the deploy of the branch, as we said, we have 3,000 workstations. Of these 3,000 workstations there are no users on the workstations. That is, in those workstations, if you look at /etc/passwd, there are no local users, aside from the ones already in the system.

What we use is a FreeIPA client that connects to IPA and from IPA it connects to the 4 ADs we have. And they pull those domain users on the fly directly. And for this reason each workstation has to be enrolled in the domain as well. But what is done is that they enroll in the FreeIPA domain. And FreeIPA connects to the FreeIPA domain. And FreeIPA has a trust relationship with the ActiveDirectory domain. I mean, it’s like a subdomain. And what it allows is that for all those users, their password stays in the AD, which is the Bank’s infrastructure, without having changed anything for them. For them it is transparent. And from all GNU/Linux machines they use the same user directly. What is in the middle and enables this is called FreeIPA.

And to speed up the deployment process what we have new is multiple layers of caching. We have several proxies. Initially we had Debian’s apt-cacher. Now there are also some Debian mirrors. And then we have nginx for proxying and squid for caching. To make this work across the length and breadth of the entire country.

Here is a bit of the hardware IT started with. 3,000 HP ProDesk. 3,000 Dell servers. Sorry, 300 Dell servers. 3,000 virtual Debian. Afterwards IT changed a little bit. But also later we found 3,500 different peripherals. Strange things like a check scanner or a ticket printer.

This is what the infrastructure originally was with which the project started in 2018. It kept varying. We also changed some VMs.

And quickly what we encountered were problems. Scale problems. This is a graph of login attempts during the day. And what you will see is that there is a little problem here at 10 in the morning. That is, 3,000 people wanted to log in at 10 in the morning. It looks the same when they go down later starting from 4 PM. The logins start going back up. And well, here there is a delay/caching problem. And other problems which is, imagine with 3,000 users, with the robust security policies of a Bank, every day many passwords expire and they have to be changed and all that. And that change has to be done from our distro’s login screen. That is, directly from there. It tells them the password expired and at that moment it asks for the old one, twice for the new one. Someone in the early morning gets confused. That generates another password issue. But about this… Now I will tell you what was worked on to improve it.

And so, to do that too, well, part of the automation we achieved is, instead of going to AWX, which is a graphical interface, and clicking to create playbooks, to create workflows, to create inventories, and giving permissions and all that manually, what we did is a Git repo called AWX, a repo called Inventory, and they are all JSON or YAML files, which GitLab’s CI directly verifies and deploys into a Development AWX immediately as we do the Git push. So in this way we can have all stages verified and automatically deployed in a Development AWX for Testing. In the Production AWX, this deploy is triggered manually, let’s say, but it creates the same instances. That guarantees us versioned infrastructure as code.

And to give you an idea of the project’s scale, this is a view of what the Bank’s productive infrastructure is. I said, it’s about 300 Branches distributed across almost all provinces of the country. And now, if we look closely at this, we will understand a little more; these are all hosts. And all these hosts are controlled by one over here, which I am going to find right now, there. This one here is AWX, it’s a single VM, not even on physical hardware, that controls all the others and deploys to all of them. Obviously they don’t deploy them all together, they deploy them in stages.

And what we have is that each line, for example here, let’s see, this is the province of… the province of Santa Fe. And I will try to highlight a little. All of this are the machines from all the different Branches of the entire province of Santa Fe. And if we zoom in on one, here, for example, it is f0372. And well, within the concept of that branch, we have a local caché, which is a CDN, the PVE, which is the Proxmox Server, the REP, which is the file Server, a Kerberized NFS, a log machine, which receives the logs from all the others and forwards them. Initially we did this with rsyslog. There is a VPN node that we do not intervene on, but we made the automatic installation, which basically that is configured BY the Bank’s personnel. We have an Apt-Catcher, there, local, within the branch. What else do we have? Well, this Git one, in the end we ditched it. The print Server, which is a CUPS, where all the place’s printers are configured. And then, here is the representation of the different printers from that branch. And then we will have the different Workstations. And finally the rest of the equipment there. Ticket printers and so on.

And this infrastructure, this infrastructure repeats throughout the Bank. So that if you don’t do this automatically, it is impossible to maintain.

And what we achieved with this is that this AWX infrastructure allows us that we no longer need to log into a machine manually and see what happens. There is an AWX playbook, from the Headquarters, where there is already a template to solve each problem. And you run that template and it leaves a Record of everything that happens, a traceable log. Obviously there are different permission levels. Who can do that? Who cannot? Schedules, for example. I don’t know, if we want all machines to shut down at a certain time, well, there is a template that sets a poweroff at a certain schedule on each machine. For example, and you launch it. You can do things like SNMP sweeps to know if certain machines are alive or dead. That is, all of that ends up in one, finally a PostgreSQL database, managed from AWX.

And if we wanted to see a little of what it is, this is, like a view of all the playbooks that are in AWX. Here is our AWX. Here I tried to organize them a bit. Here we have iDRAC Redfish, rsyslog, CDN. Well, here we have the Inventory. I don’t know if you can see anything there. You can’t see it there. Neither do I see it here either. But, let’s see, let’s look here. Here, for example, we have a role that clones a KVM VM in Proxmox So there is just a role for that. Over here we will see more. This role creates a KVM VM from Proxmox directly from an ISO. And it is an ISO that is already unattended. That is, you don’t have to do anything. That is for the VPN. A Proxmox role to configure cloud-init for each of the VMs We use the OpenStack image Let’s say cloud, but without cloud, local, to do a qm restore That is, we can restore a VM from a backup and it comes up running. And so, there is a playbook for everything.

Well, this is more or less what the migration project was. I will try to summarize, and move forward with what’s new. A little difference from this of 2022 to 2026 in what has been worked on.

Well, there are over 200 Git repos to control all of this. Now what is being done, part of what was actually done, we worked a lot on cybersecurity. We changed from rsyslog to auditd. We integrated NUT for the UPS, to have UPS monitoring. We are working on updating the Debian from those VMs from 10 to 13. This, remember, started in 2018.

FreeIPA automation, now a new was done… that is, what we currently had in production was only one large FreeIPA VM. And since the Bank has OpenShift, we are doing a migration of FreeIPA to OpenShift. Also all with automated playbooks.

Here as a summary of everything done in Cybersecurity. It is a role that connects to each machine and says what is right, what is wrong. Some things it can correct and others simply say this cannot go to production like this.

We also worked on the topic of Kernel booting so that some Server models would appear and to identify the network cards and for everything to work automatically and disk repartitioning and so on, there are different Server levels. The regeneration of all these images. Everything that would be the lifecycle of the VMs that have to be registered. Several that were taken down. Others that changed that didn’t need a secondary disk somewhere. The order in which they start. A report of what the status of all this is. All those VMs and updates. Well, there’s a little of what I said about Server versions.

And we will advance because we are short on time.

For Workstation is what has been worked on the most because it had originally been worked on with a Workstation 18.04 and now we moved to 24.04 if I’m not mistaken. And then besides there are some problems they had. Remember this original infrastructure was not GNU and worked with Firefox v9. We took it to v68 and now we took it to v120 and tests are being done with v140. The problem is not so much the environment, but the problem is the ecosystem of all the internal applications that are not updated and don’t work. Basically it’s not an easy task. So for a moment more than one versión of browser coexisted. Uh… And that was another challenge.

And well, also issues of updating the Kernel version. We had to patch some difficult CVEs that came out recently. Well, at some point Chrome was also tried as an alternative for some sites.

We do with a playbook all the configuration policies of Firefox. The user basically cannot do anything. That is like… They can’t even change the wallpaper. Well it’s the way to keep 3,000 users. Well then… No one goes into a machine to configure it. From AWX a playbook is launched directly.

And, uh… Well the topic of WakeOnLAN, integration, updating the Kernel, sftp fixes. That is well everything that would lead to the new versión of IPA. We worked quite a bit with AppArmor to restrict… Uh… Some important things. The handling of login. Also handling being able to change the password. Uh… Well Backup and all that.

And, uh… Let’s see… A little of AWX here. Uh… Well there are 198 releases since we finished migrating it. Because as with any large infrastructure when you finish migrating it you have to start migrating again. Basically. It is in constant change. And well all the time after that new needs also come out…

Uh… Well we have CloneZilla for this I said of booting a machine with an already built image. Uh… And solving problems. Uh… Here uh isolated profiles. Isolated from each other due to configuration issues.

A part of CCTV was added. Machines that are integrated into the security cameras’ DVRs. Uh… So well that is like a new inventory being added.

Uh… HP Linux Tools, for example that… A detail is at one point uh a machine froze and froze in strange situations. We took long to investigate what happened. It had to do with a power saving configuration of the BIOS. And so the solution was simple. It was to go into 3,000 machines, change the BIOS configuration and reboot them. It’s done. It’s very simple. Do you need 3,000 technicians or uh as many as Branches in the entire country? It is impossible. And well there uh I set out to investigate /HP’s FTP. And found a crazy guy on Linux who had a tool that allows writing a file in the UEFI. With the BIOS configuration that it will take the next reboot. This requires compiling a Kernel module and so on. Uh… we told them to ask permission to HP and guarantee they weren’t going to turn into a BIOS that turns 3,000 bricks. They said Yes! And well we did several tests. Never happened to us. So they worked out fine. Uh… And that allows well again centralized administration you could even change the password of the BIOS of all machines centrally and remotely. So it’s super useful.

Uh… Well here for example this modification of the Git tokens and… There are a lot of things.

This… At the URL down below, https://filiales-gnu-linux.g.coop.ar all of this will be available. So if you want to see it in detail.

Uh… And since there are five minutes left uh if it’s okay I’ll close here and ask anything you want… Because we won’t manage to see everything.

Audience: Hi. Uh… Are the ActiveDirectory you use Windows or do you also use Windows Server?

OSiUX: Yes it’s Bank infrastructure. Uh… That already existed and they weren’t going to change it. The challenge was that all those users work on the new workstations. Uh… And it works.

Audience: First of all impressive.

OSiUX: Thanks to the Free Software community! Uh… We put the pieces together.

Audience: You really squeezed every bit out of Ansible, but I didn’t think that much could really be done. I had a particular small doubt about something I saw. You said you changed from rsyslog to auditd

OSiUX: Yes. It was a cybersecurity request.

Audience: But the intention. Let’s say rsyslog logs a level we call application maybe a system level. And auditd points a bit more to the syscalls of the system itself.

OSiUX: Yes, but it allows more detail. You can specify exactly what parts you want.

Audience: No no no. I understand. My doubt is, are you logging the syscalls of 3,000 clients?

OSiUX: That is… Not from all workstations. Actually it’s uh… Generally from the VMs mostly and some things. It is selective, not everything.

Audience: Ah ah.

OSiUX: No, because otherwise there’s no way.

Audience: No no it’s fine. That was it.

OSiUX: Exactly, it’s to not send all the logs. That is, to send selectively. All this information goes to a SIEM that is at Headquarters.

Audience: Just one?

OSiUX: Yes, well it could be more than one node.

Audience: Ah no.

OSiUX: But let’s say conceptually it goes to a SIEM where everything that happens is visualized there. And also to the SIEM goes all… the log of the AWX deploy. So also…

Audience: Like SIEM?

OSiUX: No, another I don’t remember now but it is known. Now if I tell you I’d lie. (it was Splunk that was the SIEM)

Audience: Thank you very much.

Audience: I agree with the colleague, hard work, a tough Job. And moreover done with Free Software. My question is basically based on the experience of the whole project. What went really well? What are you going to start doing apart from what you mentioned? And what things went one way and you said no this doesn’t go this way we pivot?

OSiUX: The biggest challenge in general is not technical itself, but it’s dealing with the priorities of everything that needs to be done. And with things at user level for many free applications are not designed for such a large scale. And a problem where you want users to not be able to touch anything. For example, there are PDFs that are like smartforms you can fill out. And then you have to print them. And that was really complex to solve. At the beginning we had to install Adobe Acrobat with I don’t know wine or some horrible thing because it was the only one that supported it. evince showed them but didn’t allow us to complete. After we had an option I don’t remember which allowed us to complete. But it didn’t let you hide the comment in each form, in each textbox. And that came out printed and didn’t work. Now we worked on okular which has all that. But doesn’t have any file-by-file configuration option to disable everything. That is, the user can deactivate it in the moment. Well then we worked. We are touching Okular’s code so that works. The same happened with some binaries that don’t have translation and don’t have translation Support. And well what we could we edited with a hex editor and deployed our binary. Things like that, let’s say with apologies to Asians we call them Chinese. (“Sorry, I will avoid this type of comment in the future”). That is, there are things sometimes you have to get hands-on and solve it. Or complex Bugs where I don’t know you enter a screen and for X reasons if you move the mouse a little further down to the right gnome freezes. And then you have to put a script that prevents you from going down. And also things that a user owner of their environment doesn’t have a problem with because they can customize. And an end user cannot touch anything. And you as Admin of this infrastructure also don’t want them to touch but you have to give them a solution. Like thousands of things. What we didn’t get involved in and delegated was the check scanner integration part. I tried for a while and couldn’t get it. That was outsourced. But it works. We did manage to get the ticket printer to work well. And that implied a challenge that the banking core at that time used some Java applets. And that nothing was impossible. We had to PUT a chroot in the middle with something old for that to work. Well in the end we could avoid all that. Because now that core already detects when it’s GNU/Linux and done, it throws code and we PUT a local Backend that does everything missing and it works out. But yes it’s a challenge of many people. I am currently not on the project. I was in the initial development and migration Stage. There are three people now who are full time on this. And every day something new appears.

Audience: Well excellent.

OSiUX: I can stay here and chat.

Audience: Well. OSiRiS, first thank you. For those of us who came here to learn. The admiration you generate with everything you tell. My question doesn’t go by…

OSiUX: It’s gcoop work too, not mine… I’m just selling it.

Audience: Of everyone. My question goes more. Goes more that way. Not the technical side. But by the team or human group. That exists in Branches GNU/Linux which if I understand is the organization behind this whole project. How many people are needed to do this? And how do you manage it?

OSiUX: Well initially it was a six month project. Of two people. A functional analyst and me. To see if the project was viable. Afterwards started. I think we started three people. At the peak we reached three people? Five?

gcoop: Three plus one.

OSiUX: Yes sure. Always with a PM. But at the peak five no. I mean I think there… I don’t count the PM poor. Because he always talks about we are not people. That we are developers. That we are weird things. So well it’s revenge. No at the peak five people. Today there are three. Of DevOps, let’s say. But that have to. Let’s say is the FullStack. So to speak. But then you have to touch or redesign an application. I mean we had to design applications to fix existing things. I mean it’s the fun and complex at the same time.

Audience: I thought you were going to say three hundred, I don’t know. Thank you very much.

OSiUX: No no, sorry. We designed the automation of all this. The Bank has its own arsenal. An army of people who use all this daily. They did the migration in full pandemic 2020. In less than a year! But it was a physical army of people that solved all that. AWX operators I think they are more or less like sixty. That is like… Well there’s so much people. The Bank’s Infra is very big. And it’s all On-premise. It’s all local. That is and all with Free Software.

Audience: Thank you very much.

Organization: There, Alejandro. I’ll put a question in the chat here. If later you can answer it there itself.

OSiUX: Yes. And later I have here colleagues who know how to speak English. And that if there is someone who doesn’t speak Spanish.

Organization: Sure. And Alejandro will be around today. So you can keep asking him. Thank you very much.

OSiUX: OSiUX too!

• How to Migrate 6300 Machines to GNU/Linux Using Ansible and AWX
• Automating BIOS Configuration Using ansible and HP Linux Tools
• GNU/Linux Branches FLISoL CABA
• Ansible Tools v0.3.0
• Automating the Deployment of AWX Resources with GitLab CI/CD and Ansible Tools
• Using Graphviz to Generate Slides
• How to Make a Timeline with GraphViz
• Administrador de Sistemas GNU/Linux

Este proyecto gestiona alrededor de 3,000 servidores Debian y 3,000 estaciones de trabajo basadas en Debian a lo largo de 300 sucursales.

Se trata de un estudio de caso real sobre cómo aprovisionar, instalar, configurar y mantener miles de sistemas Debian y basados en Debian mediante Software Libre.

La infraestructura combina Ansible, AWX, Proxmox, PXE, FreeIPA, GitLab CI/CD y varias capas de caché para automatizar el despliegue y mantenimiento de aproximadamente 6,300 sistemas a lo largo de cientos de sucursales.

El proyecto comenzó en 2018 y ha evolucionado continuamente conforme cambiaron la infraestructura, el hardware, los requisitos de seguridad y el Stack de Software.

• Demo Site: https://filiales-gnu-linux.g.coop.ar
• Original Video: WebM (298 MB)
• Subtitle Video: WebM (298 MB)
• Spanish Subtitle: SRT (50 KB) VTT (44 KB)
• English Subtitle: SRT (48 KB) VTT (42 KB)
• English Slides: PDF (357 KB)
• Spanish Slides: PDF (357 KB)

This post has an English translation at How to Provision, Install, Configure, and Keep Thousands of Debian and Debian-Based Systems Updated

• Debian
• Ansible
• AWX
• Proxmox
• PXE
• FreeIPA
• GitLab CI/CD
• Infrastructura como Código
• Administración GNU/Linux de puestos de trabajo
• Deploy Automatizado

Este año al asistir a mi primera DebConf ¹, la DebConf26 ² en Santa Fe, aproveché a dar la charla "Cómo aprovisionar, instalar, configurar y mantener actualizados miles de sistemas Debian y basados en Debian" como actualización de la charla que presenté en nerdearla ³ edición 2022 que se llamaba "Cómo migrar 6300 equipos a GNU/Linux usando Ansible y AWX" ⁴

Me llamo OSiRiS, me dicen OSiUX en la comunidad, trabajo en gcoop ⁵ que es una Cooperativa de Software Libre, es decir, que trabajamos exclusivamente con SoftwareLibre ⁶ y de manera horizontal, la organización. No tenemos jefes, no tenemos empleados.

Vinimos cinco socios y socias de gcoop, al evento, es nuestra primera vez en DebConf. Esponsoreamos este evento y le damos gracias a Debian ⁷ porque tenemos 20 años trabajando con Software Libre y sin Debian no hubiera sido posible.

Voy a mostrar una actualización de una charla previa que ya di en el 2022, que se trata del proyecto de migración de Filiales GNU//Linux del Banco Credicoop Cooperativo Limitado ⁸, es un /Banco cooperativo.

Y voy a tratar de hacer una review del proceso de migración rápidamente y después vamos a ver las diferencias en los últimos años. Este proyecto…

Básicamente es un proyecto de Infraestructura como Código utilizando Ansible ⁹ y AWX ¹⁰.

AWX es una plataforma Web, que es una interfaz gráfica por un lado de Ansible, pero por otro lado permite orquestar y administrar y gestionar todos los playbooks de Ansible.

Y esto se hizo para Banco Credicoop. Desde gcoop.

Bueno, al principio del proyecto, lo que teníamos que era, aunque fueron 6 meses, fue tratar de descubrir qué herramientas del ecosistema de Software Libre nos permitían llevar adelante toda la migración de la infraestructura de un Banco a lo largo y a lo ancho de todo el país de Argentina.

Y lo que fuimos encontrando, bueno, es que la herramienta de automatización era Ansible porque ya la veníamos utilizando. Que íbamos a usar GitLab ¹¹. Que para la autenticación de ActiveDirectory dentro, en los Linux, íbamos a usar IPA. AWX, obviamente todos los servidores iban a usar Proxmox ¹². Nosotros ya veníamos hace años trabajando con Proxmox. Las VMs dentro de los Proxmox iban a ser Debian, obviamente.

Y bueno, los puestos de trabajo, por una cuestión de que eran 3.000 puestos de trabajo y por una cuestión de soporte, elegimos una distribución basada en Debian. Este… Un poquito más actualizada.

Y lo que teníamos ahí, no se ve muy bien ahí, pero lo que se está moviendo es que …por debajo son todos los componentes, es una línea de tiempo, todos los componentes de dependencia que utilizamos nosotros, que se están actualizando en todo el mundo, todo el tiempo. O sea, en ese momento, en tal mes, salió una nueva versión de un componente y de otro componente y de otro componente. Y esto es a medida que vos estás pensando cómo vas a hacer la cosa, se va actualizando todo el ecosistema. Entonces es una problemática a resolver.

Pero bueno, a lo que llegamos es que en Desarrollo logramos orquestar una idea de deploy, que básicamente es, tenemos un AWX, a ver si lo puedo señalar así, esto es un AWX, y este AWX, su fuente de verdad es un GitLab, entonces es decir, AWX lee desde GitLab todo lo que sería… O sea, playbooks, y el primer paso es deployar la iDRAC.

La iDRAC ¹³ es la computadora, de la computadora, dentro de los servidores Dell que utilizamos antes de que tenga nada el servidor, hay una compu que se llama iDRAC, por un protocolo que se llama Redfish, hicimos unos playbooks que AWX se conecta a la iDRAC y lo que hace es particionar el disco, configurar la BIOS y reiniciar en PXE ¹⁴. O sea, una compu nueva, recién salida de la caja.

E inmediatamente eso va a terminar generando desde un Proxmox, va a terminar generando otro Proxmox. Dentro de ese Proxmox nosotros tenemos varias VMs. Una de esas VMs es un servidor PXE, que no veo nada acá, pero debe ser este.

Tenemos un servidor, bueno tenemos una CDN, que es un Server de procesamiento, un Nginx que tiene todos los recursos, que a su vez es Proxy de otro, que es un Apache, y un servidor que Replica estos Datos. Bueno, esto se hace de manera automatizada y desatendida, sin intervención del operador, es decir que viene un servidor recién salido de fábrica, se abre la caja, se instala power, se instala Red, y desde AWX se lanza un script, esta es la infraestructura de AWX, perdón, la de Proxmox, íbamos a ver, acá se ve, cómo se lanza, y esto es solo para monitoreo, digamos, se hace todo de manera desatendida y el operador no necesita ver nada funcionando, el AWX deploya el Proxmox vía PXE, en realidad son varias etapas, primero deploya un Debian NetInstall totalmente desatendido, o sea, no hay que tocar nada, directamente en modo, sería OEM, configura todo lo necesario para que ese servidor esté operativo, y cuando termina, en un hook, al final del Debian NetInstaller, hicimos un script que lo que hace es, toma la MAC de ese equipo, que es única, y la de alta en el inventario de AWX.

Entonces esa máquina, que acaba de recibir una IP random, ya sabemos cuál va a ser su IP, cuál es su iDRAC, queda permanentemente, en todos los años que va a tener ese servidor, referenciado a esa MAC y a un número de serie que tiene el servidor propio del iDRAC. Entonces, de esa manera es fácil identificarlo.

Ahí a la izquierda, lo único que hay es el debug de lo que se va viendo en el servidor PXE, y como ven, el servidor está en el servidor PXE, el servidor se instala solo, no hay intervención manual y termina instalado, es un Debian.

El siguiente playbook que se lanza a AWX, convierte a ese Debian en un Proxmox, también de manera desatendida. Es decir, nosotros no instalamos Proxmox, nosotros instalamos Debian y lo convertimos en Proxmox. Esa es una ventaja de que Proxmox es una distribución basada en Debian, que lo único que cambia es agregar un repo. Y listo, se configuran todos los paquetes necesarios.

Y cuando termina de configurarse, en un Proxmox, lanzamos otro playbook que lo que hace es crear las VMs, y otro playbook más que lo que hace es crear los servicios dentro de cada VM.

Todas las VMs que usamos son KVM. Esto es un Banco, necesita mayor robustez en la seguridad, entonces todos los equipos están actualizados. Ahí a la izquierda se ven la creación de todas las distintas VMs. Hay 10 VMs por servidor y hay, más o menos redondeando, unos 300 servidores físicos. Eso nos da un total de 3.000 Debian. Instalados de manera automatizada por todo el país.

Workstations hicimos una imagen. Ahí estamos viendo una Workstation virtual de prueba, de Desarrollo, dentro de un Proxmox. Y lo que hacemos es generar una imagen base, también una NetInstall, en este caso basada en una distro basada en Debian. Y después configuramos, también de la misma manera, con un script. Toma el hostname del equipo, que se puede configurar después o reconfigurar en el lugar de destino. Se da de alta en el inventario y queda disponible también con un número de serie del fabricante. Son todas HP Workstations. Las podemos identificar unívocamente, aunque cambie la MAC address en algún momento. Siempre es el mismo dispositivo.

La interfaz gráfica del AWX es básicamente una página Web que está hecha en Django. Y hay un montón de operadores que trabajan lanzando distintos playbooks que hacemos, para que esto quede operativo. Y también el servidor PXE lo que hace es tomar imágenes de Workstations. O sea, vos podés agarrar una Workstation en el lugar, si se desconfiguró, le pasó algo, no anda, no importa. Se reconstruye vía PXE la imagen completa de la Workstation. No se pierde tiempo. Tiene tiempo viendo qué le pasa. No se entra manualmente al equipo. Se reconstruye desde cero. ¿Por qué? Porque no hay Datos locales dentro de la Workstation. Los Datos están en un servidor NFS kerberizado dentro de la misma red de la Filial donde estamos.

Bueno, y similar a los Proxmox, tenemos las Workstations. Las

Para el deploy en la Filial, es un poco más complejo porque el deploy de la Filial, dijimos, tenemos 3.000 puestos de trabajo. De estos 3.000 puestos de trabajo no hay usuarios en las Workstations. Es decir, en esas Workstations, si miran el /etc/passwd, no hay ningún usuario local, fuera de los que ya vienen en el sistema.

Lo que utilizamos es un cliente de FreeIPA que se conecta al IPA y del IPA se conecta a los 4 ADs que tenemos. Y toman al vuelo esos usuarios del dominio directamente. Y por este motivo cada Workstation tiene que estar enrolada también al dominio. Pero lo que se hacen es que se enrolan al dominio de FreeIPA. Y el FreeIPA se conecta al dominio de FreeIPA. Y el FreeIPA tiene una relación de confianza con el dominio de ActiveDirectory. O sea, es como un subdominio. Y lo que permite es que todos esos usuarios, su password esté en el AD, que es la infraestructura del Banco, sin haberles cambiado nada. Para ellos es transparente. Y desde todos los equipos GNU//Linux usan el mismo usuario directamente. Lo que está en el medio y que permite esto se llama /FreeIPA.

Y para acelerar el proceso de despliegue lo que tenemos de nuevo, es una caché de caché de caché. Tenemos varios Proxys. Inicialmente teníamos Apt-Cacher de Debian. Ahora ya hay unos mirrors de Debian también. Y después tenemos Nginx de Nginx y Squid de Squid de Squid. Para que esto funcione a lo largo y a lo ancho de todo el país.

Acá un poquito el hardware con que se comenzó. 3.000 HP ProDesk. 3.000 servidores Dell. Perdón, 300 servidores Dell. 3.000 Debian virtuales. Después se fue cambiando un poquito. Pero además después nos encontramos con 3.500 periféricos distintos. Cosas raras como un escáner de cheque o una impresora de tickets.

Esto es lo que fue originalmente la infraestructura con la que comenzó el proyecto en el 2018. Esto fue variando. Algunas VMs fuimos cambiando también.

Y rápidamente los que nos encontramos con problemas. Problemas de escala. Esto es un gráfico de los intentos de login durante el día. Y lo que van a ver es que hay un problemita acá a las 10 de la mañana. Es decir, 3.000 personas se quieren loguear a las 10 de la mañana. Se ven igual cuando bajan después a partir de las 4 de la tarde. Ya empiezan a ir los logins. Y bueno, acá hay un problema de delay, de caché. Y de otros problemas que es, imagínense con 3.000 usuarios, con las políticas robustas de seguridad de un Banco, todos los días vencen muchas contraseñas y las tienen que recambiar y todo eso. Y ese recambio lo tienen que hacer desde la pantalla de login de la distro nuestra. Es decir, directamente desde ahí. Se le dice que la contraseña venció y en ese momento le pide la vieja, dos veces la nueva. Uno a la mañana temprano se confunde. Eso genera otra contraseña más. Pero en esto… Ahora les voy a contar que se trabajó para mejorarlo.

Y entonces, para hacerlo también, bueno, parte de la automatización que logramos es, en lugar de ir a AWX, que es una interfaz gráfica, y hacer clics para crear playbooks, para crear workflows, para crear inventarios, y dar permisos y todo eso manualmente, lo que hicimos es un repo Git que se llama AWX, un repo que se llama Inventory, y son todos archivos JSON o YAML, que la CI de GitLab directamente las verifica y las deploya en un AWX de Desarrollo de manera inmediata a medida que hacemos el Git push. Entonces podemos de esa manera tener todas las etapas verificadas y deployadas automáticamente en un AWX de Desarrollo para pruebas. En el AWX de Producción, este deploy se dispara manualmente, digamos, pero hace las mismas instancias. Eso nos garantiza tener toda la infraestructura como código versionada.

Y para darnos una idea de la escala del proyecto, esto es una visión de lo que es la infraestructura del Banco productiva. Dije, son más o menos unas 300 Filiales, distribuidas por casi todas las provincias del país. Y ahora, si vemos de cerca esto, vamos a entender un poquito más, todos estos son hosts. Y todos estos hosts están controlados por uno que está por acá, que ya lo voy a encontrar, ahí. Este que está acá es la AWX, es una sola virtual, ni siquiera es de un equipo físico, que controla a todas las demás y deploya a todas las demás. Obviamente no las deployan todas juntas, las van deployando por etapas.

Y lo que tenemos es que cada línea, por ejemplo acá, vamos a ver, esto es la provincia de… la provincia de Santa Fe. Y voy a tratar de iluminar un poquito. Todo esto son los equipos de todas las distintas Filiales de toda la provincia de Santa Fe. Y si nos acercamos a uno, acá, por ejemplo, es la f0372. Y bueno, dentro de lo que es el concepto de esa Filial, tenemos una caché local, que es una CDN, el PVE, que es el servidor Proxmox, el REP, que es el file Server, un NFS kerberizado, una máquina de log, que es la que recibe los logs de todas las demás y los reenvía. Inicialmente esto lo hacíamos con rsyslog. Hay un nodo de VPN que nosotros no intervenimos, pero hicimos la instalación automática, que básicamente eso lo configura el personal del Banco. Tenemos un Apt-Catcher, ahí, local, dentro de la Filial. ¿Qué más tenemos? Bueno, esta de Git, al final la volamos. El servidor de impresión, que es un CUPS, donde están configuradas todas las impresoras del lugar. Y después, acá está la representación de las distintas impresoras de esa Filial. Y después vamos a tener los distintos puestos de trabajo. Y finalmente el resto de equipamiento que hay ahí. Impresoras de ticket y demás.

Y esta infraestructura, esta infraestructura se repite por todo el Banco. O sea que esto, si no lo haces de manera automatizada, es imposible de mantener.

Y lo que logramos con esto, que es que esta infraestructura de AWX nos permita que ya no hace falta loguearse un equipo manualmente y ver lo que pasa. Hay un playbook de AWX, de la CasaCentral, donde ya hay una plantilla para solucionar cada problema. Y se corre esa plantilla y queda un registro de todo lo que sucede, un log traceable. Obviamente hay distintos niveles de permiso. ¿Quién puede hacer eso? ¿Quién no lo puede hacer? Horarios, por ejemplo. No sé, si queremos que todos los equipos se apaguen a cierta hora, bueno, hay una plantilla que establece un poweroff a cierto horario en cada equipo. Por ejemplo, y lo lanzás. Puedes hacer cosas como barridos de SNMP para saber si ciertos equipos están vivos o muertos. Es decir, todo eso queda todo en una, finalmente una base de Datos PostgreSQL, manejada desde AWX.

Y si quisiéramos ver un poquito lo que es, esta es, como una visión de todos los playbooks que hay en AWX. Acá está nuestro AWX. Acá yo intenté organizarlos un poquito. Acá tenemos el iDRAC///Redfish. rsyslog, CDN. Bueno, acá tenemos el inventario. No sé si se llega a ver algo. Ahí no se llega a ver. Ni yo lo veo acá tampoco. Pero, a ver, vamos a ver por acá. Acá, por ejemplo, tenemos un rol que clona un VM de KVM en Proxmox. Entonces hay un role para eso nada más. Por acá vamos a ver más. Este rol lo que hace es crear una VM KVM de Proxmox desde una ISO directamente. Y es una ISO que ya es desatendida. O sea, no hay que hacer nada. Eso es para la VPN. Un role de Proxmox para configurar el cloud-init de cada una de las VMs. Usamos la imagen OpenStack. Digamos cloud, pero sin cloud. Local. Para hacer un qm Restore. O sea, podemos restaurar una VM desde un Backup y sale andando. Y así, hay playbook para todo.

Bueno, esto es más o menos lo que fue el proyecto de migración. Voy a tratar de resumir, y avanzar con lo nuevo. Un poco la diferencia de esto del 2022 al 2026 en que se estuvo trabajando.

Bueno, hay más de 200 repositorios de Git para controlar todo esto. Ahora lo que se está haciendo, parte de lo que se hizo en realidad, se trabajó mucho en seguridad informática. Se cambió de rsyslog a auditd. Se integró NUT para las UPS, para tener monitoreo de UPS. Se está trabajando en actualizar los Debian de esas virtuales de 10 a 13. Esto, recuerden, empezó en 2018.

La automatización de FreeIPA, ahora se hizo un nuevo… …o sea, lo que teníamos actualmente en producción era solo una VM grande de FreeIPA. Y como el Banco tiene OpenShift, estamos haciendo una migración del FreeIPA a OpenShift. También todo con playbook automatizado.

Acá como un resumen de todo lo que se hizo de Seguridad Informática. Es un rol que se conecta en equipo y dice qué está bien, qué está mal. Algunas cosas las puede corregir y otras simplemente dice esto no puede salir a producción así.

Se trabajó también con el tema del Booteo del Kernel para que aparecieran unos modelos de servidores y para identificar las placas de red y que funcione todo solo y el reparticionado de discos y en fin, hay distintos niveles de servidores. La regeneración de todas estas imágenes. Todo lo que sería el ciclo de vida de las VMs que hay que ir de alta. Varias que se bajaron. Otras que cambiaron que no necesitaban por ahí un disco secundario. El orden en que se inician. Un reporte de cuál es el estado de todo esto. Todas esas VMs y actualizaciones. Bueno, ahí un poquito de lo que decía de versiones de servidores.

Y vamos a avanzar que estamos corto de tiempo.

En Workstation es lo que más se viene trabajando porque se había originalmente trabajado con una Workstation 18.04 y ahora se pasó a 24.04 si no me equivoco. Y entonces además hay unos problemas que tenían. Recuerden esta infraestructura original no era GNU y trabajaba con Firefox 9. Nosotros lo llevamos a v68 y ahora lo llevamos a v120 y se están haciendo pruebas con v140. El problema no es tanto el entorno, sino que el problema es el ecosistema de todas las aplicaciones internas que no están actualizadas y no funcionan. Básicamente no es tarea fácil. Entonces por un momento convivieron más de una versión de browser. Eh… Y eso era otro desafío.

Y bueno, también cuestiones de actualizar la versión de Kernel. Hubo que hacer el parcheo de algunos CVEs difíciles que estuvieron saliendo hace poco. Bueno, en algún momento también se probó Chrome como alternativa para algunos sitios.

Hacemos con un playbook toda la configuración de policies de configuración de Firefox. El usuario básicamente no puede hacer nada. O sea, como… No puede ni cambiarle el fondo de pantalla. Este… Pero bueno, es la manera de mantener 3.000 usuarios. Bueno, entonces… Nadie entra a un equipo a configurarlo! Desde AWX se lanza un playbook directamente.

Y, eh… Bueno, el tema de WakeOnLAN, integración, actualización del Kernel, correcciones de sftp. Es decir, bueno, todo lo que llevara a la nueva versión de IPA. Trabajamos bastante con AppArmor para restringir… Este… Algunas cosas que son importantes. El manejo del login. Manejo también de poder cambiar la contraseña. Este… Bueno, Backup y todo eso.

Y, eh… Vamos a ver… Un poquito de AWX acá. Eh… Bueno, hay 198 releases desde que terminamos de migrarlo. Porque como toda infraestructura grande, cuando terminás de migrarlo tenés que empezar a migrar de nuevo. Básicamente. Está en constante cambio. Y, bueno, todo el tiempo después además van saliendo nuevas necesidades…

Eh… Bueno, tenemos CloneZilla para esto que decía de arrancar un equipo con una imagen ya armada. Este… Y solucionar los problemas. Este… Acá, eh… Perfiles isolados. Este… Aislados unos de otros por tema de configuraciones.

Se agregó una parte de CCTV. Equipos que están integrados a los DVR de las cámaras de seguridad. Este… Entonces, bueno, eso es como un nuevo inventario que se agrega.

Eh… HP Linux Tools, por ejemplo, eso… Un detalle es en un momento, eh… Un equipo se colgaba y se colgaba en situaciones extrañas. Tardamos en investigar qué sucedía. Tenía que ver con una configuración de ahorro de energía de la BIOS. Y entonces la solución era simple. Era entrar a 3.000 equipos, cambiar la configuración de la BIOS y reiniciarlos. Ya está. Es muy simple. ¿Necesitás 3.000 técnicos? o Este… Tantos como Filiales en todo el país. Es imposible. Y, bueno, ahí, este… Yo me puse a investigar el FTP de HP. Y encontré un loco en Linux que tenía una herramienta que lo que permite es escribir un archivo en la UEFI. Este… Con la configuración de la BIOS que la va a tomar el próximo reboot. Esto hay que compilar un módulo del Kernel y demás. Y… Eh… Le dijimos que pidan permiso a HP y que garanticen que no se iban a convertir en una BIOS. Que se convertir en 3.000 ladrillos. Este… Dijeron… ¡Sí! Y, bueno, nosotros hicimos varias pruebas. Nunca nos pasó. Así que salieron andando todo bien. Eh… Y eso permite que, bueno, de nuevo, de administración centralizada, inclusive podrías cambiar la password de la BIOS de todos los equipos de manera centralizada y remota. Así que es súper útil.

Eh… Bueno. Acá, por ejemplo, este… Modificación de los tokens, de Git y… Hay un montón de cosas.

Esto… En la URL que está ahí abajo, https://filiales-gnu-linux.g.coop.ar van a estar todo esto disponible. Así que si lo quieren ver en detalle.

Eh… Y como quedan cinco minutos, este… Si les parece, cierro acá y pregunten lo que sea… Porque no vamos a llegar a ver todo.

Público: Hola. Eh… ¿Los ActiveDirectory que usan son Windows o usan también Windows Server?

OSiUX: Sí, es infra del Banco. Este… Que ya tenía preexistente. Y que no la iban a cambiar. El desafío fue que todos esos usuarios funcionen en los nuevos puestos de trabajo. Este… Y funciona.

Público: Primero que nada, impresionante.

OSiUX: Gracias a la comunidad del Software Libre! Eh… Nosotros juntamos las piezas.

Público: Le sacaron todo el jugo a Ansible, pero no pensé que se pudiera hacer tanto realmente. Tenía una pequeña duda en particular con algo que vi. Dijiste que cambiaron de rsyslog a auditd

OSiUX: Sí. Fue solicitud de seguridad informática.

Público: Pero la intención… Digamos, rsyslog loguea un nivel, llamamos aplicación, tal vez un nivel de sistema. Y auditd apunta un poco más a las syscalls del mismo sistema.

OSiUX: Sí, pero permite más detalle. Podés especificar exactamente qué partes querés.

Público: No, no, no. Entiendo. Mi duda es, ¿ustedes están logueando las syscalls de 3.000 clientes?

OSiUX: Eso es… No de todos los puestos. En realidad es… Eh… En general de las VMs mayormente, y algunas cosas. Es selectivo, no es de todo.

Público: Ah, ah.

OSiUX: No, porque si no, no hay manera.

Público: No, no, está bien. Era eso nomás.

OSiUX: Justamente es para no enviar todos los logs. Es decir, enviar de manera selectiva. Toda esta información va a un SIEM que está en CasaCentral.

Público: ¿Uno solo?

OSiUX: Sí, bueno, puede ser que sea más de un nodo.

Público: Ah, no.

OSiUX: Pero, digamos, conceptualmente va a un SIEM que ahí se visualiza después todo lo que sucede. Y también al SIEM va todo… el log del deploy de AWX. Entonces también…

Público: ¿Como SIEM?

OSiUX: No, otro que no me acuerdo ahora, pero que es conocido. Ahora, si te digo, te miento. (era Splunk el SIEM)

Público: Muchísimas gracias.

Público: Coincido con el colega un arduo laburo, un arduo trabajo. Y además hecho con Software Libre. Mi pregunta es básicamente en función a la experiencia de todo el proyecto. ¿Qué salió re bien? ¿Qué van a empezar a hacer, aparte de lo que has mencionado? ¿Y qué cosas fueron por un lado y dijeron, no, esto no va por este lado, mudamos?

OSiUX: El mayor desafío en general no es técnico en sí, sino es lidiar con las prioridades de todo lo que hay que hacer. Y con cosas que a nivel usuario, de muchas aplicaciones libres, no están pensadas para una escala tan grande. Y una problemática de donde vos querés que los usuarios no puedan tocar nada. Por ejemplo, hay unos PDFs que son unos formularios como inteligentes que podés completar. Y después lo tenés que imprimir. Y eso fue re complejo de solucionarlo. Y al principio tuvimos que instalar Adobe Acrobat con, no sé, Wine o alguna cosa así horrible. Porque era lo único que lo soportaba. Evince los mostraba, pero no nos permitía completar. Después teníamos una opción que no me acuerdo cuál era, pero que los permitía completar. Pero no te permitía ocultar el comentario que está en cada formulario, en cada textbox. Y eso salía impreso y no servía. Ahora se estuvo trabajando en Okular, que es el que tiene todo eso. Pero no tiene ninguna opción de configuración por archivo para deshabilitar todo eso. O sea, el usuario lo puede desactivar en el momento. Bueno, entonces trabajamos. Estamos tocando el código de Okular para que eso ande. Lo mismo pasó con algunos binarios que no hay traducción y no tienen soporte de traducción. Y bueno, lo que pudimos lo editamos con un editor hexadecimal. Y plantamos nuestro binario. Cosas así, digamos, con el perdón de los asiáticos, le decimos chinos. («Perdón, voy a evitar este tipo de comentarios en el futuro»). O sea, es un chino que hay veces que hay que meter mano y resolverlo. O Bugs complejos de que, no sé, entrás en una pantalla y por X motivos, si moves el mouse un poquito más abajo a la derecha, se cuelga a gnome. Y entonces hay que poner un script que evite que vos vayas para abajo. Y además cosas que un usuario dueño de su entorno no tiene problema porque puede customizar. Y un usuario final no puede tocar nada. Y vos, como administración de esta infraestructura, tampoco querés que toquen. Pero tenés que darle una solución. Así, mil cosas. Lo que no nos metimos y lo delegamos fue la parte de integración con el escáner de cheques. Yo estuve intentando un tiempo y no lo conseguí. Eso fue tercerizado. Pero anda. Sí logramos que ande bien la impresora de tickets. Y eso implicó un desafío de que el core bancario en ese momento utilizaba unos applets Java. Y eso, nada, era imposible. Tuvimos que meter un chroot en el medio con algo viejo para que eso ande. Bueno, al final pudimos evitar todo eso. Porque ahora el core ese ya detecta cuando es un GNU///Linux. Y listo, tira un código y metimos un Backend local que hace todo lo que falta y sale andando. Pero sí, es un desafío de muchas personas. Yo actualmente no estoy en el proyecto. Estuve en la etapa de desarrollo inicial y de migración. Hay tres personas ahora… Que están a full con esto. Y todos los días aparece algo nuevo.

Público: Bueno, Buenísimo.

OSiUX: Yo me puedo quedar acá y charlamos.

Público: Bueno. OSiRiS, primero agradecerte. Para los que vinimos acá a aprender. La admiración que generás con todo lo que contás. Mi pregunta no va por…

OSiUX: Es trabajo de gcoop igual, no mío… Yo lo estoy vendiendo.

Público: De todos. Mi pregunta va más… Va más por ese lado. No por el lado técnico. Sino por el equipo o grupo humano. Que hay en Filiales. GNU///Linux, que si no entiendo es la organización que está detrás de todo este proyecto. ¿Cuántas personas se necesitan para hacer esto? ¿Y cómo lo gestionan?

OSiUX: Bueno, inicialmente fue un proyecto de seis meses. De dos personas. Un analista funcional y yo. Para ver si era viable el proyecto. Después empezó… Creo que empezamos tres personas. En el tope llegamos a tres personas. ¿A cinco?

gcoop: Tres más uno.

OSiUX: Claro, sí. Siempre con un PM. No, pero en el tope cinco no. O sea, creo que ahí… No lo cuento al PM, pobre. Porque él siempre habla de… El PM siempre habla de que no somos personas. Que somos developers. Que somos cosas raras. Entonces, bueno. Es la venganza. No, en el tope cinco personas. Hoy hay tres. De DevOps, digamos. Pero que hay que… Digamos, es el FullStack. Por así decirlo. Pero después hay que tocar o rediseñar una aplicación. O sea, tuvimos que diseñar aplicaciones para solventar cosas existentes. O sea, está lo divertido y lo complejo al mismo tiempo.

Público: Pensé que ibas a decir trescientas, no sé. Muchas gracias.

OSiUX: No, no, perdón. Nosotros diseñamos la automatización de todo esto. El Banco tiene su propio arsenal. Un ejército de personas que utilizan diariamente todo esto. Hicieron la migración en plena pandemia 2020. En menos de un año! Pero fue un ejército físico de personas que resolvió todo eso. Operadores de AWX creo que son más o menos como sesenta. O sea, como… Bueno, hay muchísima gente. La Infra del Banco es muy grande. Y es todo on-premise. Es todo local. O sea, y todo con Software Libre.

Público: Muchas gracias.

Organización: Ahí, Alejandro. Ahí te pongo una pregunta en el chat. Si después podés respondérsela ahí mismo.

OSiUX: Sí. Y después tengo acá compañeros que saben hablar inglés. Y que si hay alguien que no habla español.

Organización: Dale. Y Alejandro hoy va a estar por acá. Así que le pueden seguir preguntando. Muchas gracias.

OSiUX: OSiUX también!

• 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

Desde que tengo a tequila, que es una ThinkPad T14 Gen 1 fui pasando por Debian Buster y luego Debian Bullseye para ahora disfrutar de Debian Trixie ¹.

       _,met$$$$$gg.          osiris@tequila
    ,g$$$$$$$$$$$$$$$P.       --------------
  ,g$$P"        """Y$$.".     OS: Debian GNU/Linux 12 (Trixie) x86_64
 ,$$P'              `$$$.     Kernel: 6.1.0-9-amd64
',$$P       ,ggs.     `$$b:   Uptime: 2 days, 7 hours, 53 mins
`d$$'     ,$P"'   .    $$$    Shell: bash 5.2.15
 $$P      d$'     ,    $$P    WM: awesome
 $$:      $$.   -    ,d$$'    Terminal: terminator
 $$;      Y$b._   _,d$P'      CPU: Intel i7-10510U (8) @ 4.900GHz
 Y$$.    `.`"Y$$$$P"'         GPU: Intel CometLake-U GT2 [UHD Graphics]
 `$$b      "-.__              GPU: NVIDIA GeForce MX330
  `Y$$                        Memory: 5433MiB / 15651MiB
   `Y$$.
     `$$b.
       `Y$$b.
          `"Y$b._
              `"""

Como siempre el esquema es 1 partición /boot, 2 particiones idénticas para Sistema Operativo, una para la / de ahora y una disponibles para cuando falle, el resto de la unidad para datos, pero como estamos en un sistema moderno además es necesaria 1 partición para EFI, en fin, quedó asi:

Model: SAMSUNG MZVLB512HBJQ-000L7 (nvme)
Disk /dev/nvme0n1: 512GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name          Flags
 1      1049kB  1000MB  999MB   fat32        EFI           boot, esp
 2      1000MB  2001MB  1000MB  ext4         BOOT
 3      2001MB  52,0GB  50,0GB               LUKSDEBIAN12
 4      52,0GB  102GB   50,0GB               LUKSDEBIAN11
 5      102GB   512GB   410GB                LUKSDATA

Esta tarea esta super des-atendida gracias a DiRePlOs ², aunque aproveché a hacer algunas correcciones, que ya publicaré.

Basta ejecutar:

./deb.sh -utx

A diferencia de Debian Bullseye que necesité un kernel de Debian Backports, esta vez no tuve inconvenientes para que funcione Xorg con la placa Intel pero esta pendiente hacer funcionar la NVIDIA.

De la misma manera, no necesité extras para usar WiFi, también intel iwlwifi

dpkg -l | grep iwlwifi

  ii  firmware-iwlwifi  20230210-5          all  Binary firmware for Intel Wireless cards

El sonido, también salió andando de una, usando firmware-sof-signed:

dpkg -l | grep sof-signed

  ii  firmware-sof-signed  2.2.4-1  all  Intel SOF firmware - signed

Tengo mucho por documentar sobre la instalación y configuración, la idea es ahorrarle un poco de tiempo a quienes quieran instalar Debian Trixie en una ThinkPad T14 Gen 1.

• Thinkpad HackToon FLOSS Vinyl by OSiUX
• Install Debian Bullseye on ThinkPad T14 Gen 1
• Install Debian Buster on ThinkPad T14 Gen 1
• DIsaster REcovery PLan OSiux

• 2023-06-10 18:10 agregar Install Debian Trixie on ThinkPad T14 Gen 1

Hola Buenas Tardes a todos, todes, todis o como se autoperciban.

Me llamo OSiRiS, trabajo en gcoop ¹ y me conocen como OSiUX ², en la comunidad.

eee, y anoche a las 12hs estaba en la disyuntiva… si hacer los slides para la charla (siempre la última noche) o instalar Debian 12 ³

Elegí instalar Debian 12, porque tenía ganas, este eee y en realidad porque no me andaba antes la salida HDMI así que fue una buena decisión porque ahora podemos ver, esto…

…y en parte también porque no quería mostrar solamente slides estáticos sino que quería mostrar un poco, algo en vivo.

…eee vamos a intentar de que la internet nos acompañe, este y más que nada lo que quería comentar brevemente…

Un poco la experiencia de uso de Ansible ⁴ que tenemos en gcoop.

Y que nos ha permitido innovar gracias a que automatizamos un montón de tareas.

En eso, el caso de éxito que venimos mostrando, es el proceso de …

Esperen que me ande esto… arrghh… Toqué el zoom y ahí no me anda nada ahí, CTRL+F5 ahí, está!

Bueno, el Banco Credicoop ⁵, tenía todas las Filiales, es decir 300 Filiales en todo el país, con 3000 puestos de trabajo usando tecnología obsoleta, «Ventanas 2000» se llamaba lo que usaban y bueno, había que pasarlo a GNU/Linux y para hacerlo, esteee…

Bueno el Banco vino a gcoop, que ya somos proveedores de ellos desde hace rato.

…y la idea era cómo hacer esa migración, ese proceso de migración, o sea, si uno dice Instalar SoftwareLibre, como lo pueden hacer acá en el InstallFest ⁶, es como…

Si, bajo una ISO, lo pongo en un pendrive, lo pongo en una compu, ENTER, ENTER, ENTER y un rato y ya está!

Bueno; es una versión simplificada! Digamos!

Después hay otros conflictos, a nivel usuario final, tenes problemas con el driver de video, con el driver de la red, con el driver de sonido, con la performance…

Con un montón de cosas. Pero en la relación de 1 persona con 1 máquina, será más o menos tiempo, lo solucionas!

Ahora si vos tenes muchos equipos, como es en el caso del Banco, la migración fue de 6300 puestos de trabajo, esto es el Banco y es todos los equipos que administramos desde una sola virtual, que se llama AWX ⁷ y que anda por acá en el centro, es esta griscecita que esta por acá, ese equipo, solo ese equipo controla 6300 equipos!

Y qué es lo que controla? Es bueno, qué sistema operativo se instala cómo se configura ese sistema operativo, qué servicios se instalan, cómo se configuran esos servicios, si es necesario reiniciar un servicio, si es necesario conectar ese servicio con otro servicio, en fin cualquier operación que tradicionalmente se hacía a mano ahora se hace de manera automatizada, es decir, nadie mete mano en los equipos, les cortamos la mano a les SysAdmines, este, porqué? No por mala onda!

Si no porque cuando vos tenés muchos equipos, es muy difícil que todos te queden iguales, para que te queden todos iguales, lo que tenés que hacer es automatizar todo lo que puedas, para que sean reproducibles, si se rompe un equipo yo tengo que poner uno en las mismas condiciones que estaba antes, para poner algo que está en las mismas condiciones que estaba antes, como hago?

Tengo muy buena memoria o tengo código versionado?

Infraestructura como Código ⁸, que ese código va a poder regenerar ese equipo, este una y otra vez, o corregirlo en caso de que sea necesario.

Hay una charla más completa sobre esto que la di el año pasado en nerdearla ⁹ y que los invito a verla en el canal de nerdearla!

…O en mi sitio osiux.com

Utilizamos todas herramientas libres, nos apoyamos fuertemente en Ansible, trabajamos con GitLab, AWX es el orquestador gráfico de Ansible que permite que varias personas operen y hagan, disparen las ejecuciones de estas automatizaciones, sin saber de código, simplemente haciendo unos /clics/.

Integramos con un AD (ActiveDirectory ¹⁰) la parte de los usuarios, trabajos con FreeIPA ¹¹ que nos permite hacer esa integración de usuarios de «Ventanas» a usuarios Libres, trabajamos con Debian y con una distribución basada en Debian también, este…,

Y bueno, esto tardamos 4 años en hacerlo, esta funcionando, obviamente todos los días surge algo, y hay que ir corrigiéndolo, pero bueno para sintetizar…

Esta AWX que obtiene el código, de lo que tiene que hacer, cada tarea que tiene que realizar, eso se conecta, por ejemplo en el caso de los servidores a la iDRAC ¹² que es el servidor del servidor, la computadora de la computadora, y le dice, configurá los discos de esta manera, creá el RAID, particionalo, todo lo que haga falta, eso después lo reinicia y dispara la ejecución de un servidor PXE ¹³ que toma la imagen de un Debian NetInstall que se autoinstala, es decir que no hay intervención del operador, se configura y lo deja preinstalado para que después el operador dispare un workflow que lanza la ejecución y la instalación de un Proxmox ¹⁴, para que haga la virtualización y después eso dispara la ejecución de la creación de 10 virtuales, diferentes, con distintos servicios y para eso se apoya en otros equipos que están dentro de la red, que lo que hace es caché de caché de caché para que esto funcione a lo largo y ancho de todo el país.

Eso esta totalmente automatizado y en la instancia de Producción cuando hubo que migrar todos los puestos de trabajo, cuando se llevaron esos servidores, hubo que configurar todos esos puestos y en algunas Filiales, no sé, tenés 60 puestos de trabajo y tiene que salir funcionando, no importa si ese puesto de trabajo esta, no sé, en un gerencia, en una secretaría, o en una línea de cajas, es el mismo sistema operativo libre, y de hecho si tuvieras la urgencia podés sacarlo, del puesto de recepción y ponerlo en una línea de cajas y tiene que salir andando y si se rompe, lo tirás y ponés uno igual, y mandás a deployar desde CasaCentral a no sé, Salta o cualquier lugar del país.

Cómo se dispara esto? Bueno, vamos a ver si me anda…, en el Banco soy ogomez no soy osiris, si me acuerdo mi contraseña…

Este sería el AWX de Desarrollo que tenemos, y básicamente lo que se ve es un panel donde están las distintas opciones, las ejecuciones que se estuvieron realizando, y acá las plantillas que se usaron recientemente, por ejemplo se ejecutó wst_bra que es lo que permite es hacer un escaneo de qué puestos están encendidos en la red y un workflow de Proxmox que crea máquinas virtuales, podemos ver, ahí lo Verde es esta todo bien, lo Rojo esta todo mal, pero se puede volver a ejecutar hasta que dé Verde, una y otra vez!

Por ejemplo, tenemos un workflow que se inicia y dispara, un workflow que dispara otros workflows, y es de la máquina virtual de Ansible, la del Servidor FTP, la del servidor PXE, la del servidor de Log, la del servidor de GIT, del servidor de Impresión, el servidor de CDN, el servidor de la caché de APT y el FileServer, y cada uno de estos workflows, si los miramos, vamos a mirar una tarea completada, esta por ejemplo, podemos entrar, acá dio todo en Verde y como ven se ejecutaron todas en paralelo.

Si vemos aquí, este nodo de workflows tiene a su vez, más tareas, y esta, la primera es, lo que hace es configurar cloudinit, que es algo que nos ayuda a configurar las maquina virtuales, establece la configuración de apt.

La configuración de lo que es el servicio de esta VM en particular, y le aplica criterios de seguridad, entonces eso es muy importante, digamos así como escucharon por ahí hablar de DevOps ¹⁵, también esta DevSecOps ¹⁶, que es cómo garantizo la seguridad de un equipo, bueno todas las políticas tienen que estar versionadas en código, y se tienen que volver aplicar una y otra vez para asegurarse de que este todo bien.

Puedo entrar en el detalle, de la ejecución, de cada uno de estos nodos y ver el log de salida.

Este log salida es exactamente lo mismo, que si vos ejecutás Ansible desde la línea de la consola con un Playbook, es lo que te va a devolver, el criterio de color es: Verde esta todo bien, Rojo, error, esta todo mal, este.. Celestito es algo que se ignoró y puede ser un error inesperado que es posible que suceda y uno lo puede ignorar, Naranja es algo que cambió, es decir cambió el estado, y a ver si podemos ver algo acá, que se entienda…

Ahhh… Un poco lenta la máquina, bue, o soy yo… También…

Este log, el resultado en este caso es un JSON, pero puede ser una salida standaroutput común y bueno acá lo que estaba haciendo es testeando la configuración de cloudinit, vamos a mirar algo más en detalle, por ejemplo acá, vemos algo en Naranja que cambió y es este archivo 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

• 2024-02-27 09:02 corregir tamaño video Charla «Automatizar para Innovar» en FLISoL CABA 2023
• 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

Taking advantage of the face-to-face return of nerdearla ¹ edition 2022 at Konex ², I presented talk "How to migrate 6300 hosts to GNU/Linux using Ansible and AWX" ³

Summarizing 4 years of work in 25 minutes is not an easy task, but due to the large number of simultaneous talks there was no other way to summarize, so I divided the talk into 7 stages, coinciding with the 7 colors of cooperativism 🌈

To detail and extend the talk a little more, I unrecorded the audio and I will be adding references to each topic and/or technology mentioned, for those who want to go a little deeper.

Instead of making Slides I created a website ⁴ with the help of Hugo Ruscitti ⁵ who built the multiple video viewer ⁶, which I used to display several videos at the same time.

Since several people asked about the tool I used to make the graphs, I put together a post ⁷ detailing how I generated the graphs and the timeline ⁸ using GraphViz

Well, welcome back to the Infra track on Nerdearla!

All good? How are they doing? Hey there goes that audience still!

Well very well, thank you very much for being here!

I have already said several times, I will say it again the ninth edition of Nerdearla 2022, the 10 years of SysArmy ⁹ and here we are, here Trac Infra, we have a Trac Dev Online and a Trac Sec Online and the DataScience Trac there in the other auditorium, here in the Konex Cultural City from October 19 to 22, nothing come, you still have time to come, this afternoon, Friday and Saturday if you are watching us online but if you are here, you are already enjoying all the activities that we have in the stands, in the auditoriums, in places to do coworking, games, etc. there is everything thanks! Thank you for being here and joining us!

And now the last round of talks is coming, it’s not the last talk, the last round, there are several talks ahead of us.

Well, now we are going to talk about something that I really like, which is Free Software. Who likes Free Software here?

Let’s go still! Look, you have FANs ! Jewel

Well then, we are going to welcome OSiRiS GóMeZ, which is a partner of gcoop ¹⁰, which is a Free Software Cooperative …

Heroes without capes, as we usually say...

He is a GNU/Linux programmer and Administrator (you saw that I said GNU and not G-N-U, but Richard Stallman ¹¹ gets angry) he is self-taught and a fan of automating everything from a terminal (from tty actually says here) and is very interested in disseminating the use of the Free Software, so…

I leave you with OSiRiS a round of applause please!

Wow, I’m so tall! Can you hear it? Yes? Perfect!

(well, it seems to me that it sounds better there)

First I apologize if I cough out there because I have a bad throat.

And what I’m going to try to do in 25 minutes, if I can do it, is tell you the story of gcoop and Banco Credicoop ¹² in the last 4 years.

Basically it is a migration project of the entire Infrastructure of the Subsidiaries, there are many, throughout the country and well, it was quite a challenge, we did it!

But we are going to see it step by step a little as we were living it.

Initially we had a laboratory stage, in this laboratory stage we had to analyze if it was possible to do this migration project and with what free tools was it possible to do it?

Basically what we detected is that first we were going to use Ansible because we had already been using it in gcoop and we were very happy with the use of Ansible, eh, basically it was to make roles and playbooks, this code that we wrote was going to be in a GitLab repository and this GitLab repository was going to be obtained as Infrastructure as Code from the AWX tool to make the deployment or the deploy in all the necessary computers and something…

(let’s see if this works for me…, yes, no, there)

The little bar below (let’s try to make it stand still for a minute) is a timeline of all the projects that we ended up using eventually at some point in the project, I’m talking almost 4 years and the interesting thing is that the first The day we started this, which was in 2018, we had no idea that we were going to be using that bar, that is to say, that there are a lot of projects from different Free Software development communities around the world that were doing projects that later we We were going to end up using them and this is the important thing about Free Software, that is, we empower each and every one of us, this… Building and finally giving back something else!

Having Ansible and having AWX with GitLab we could already start to do a massive deployment, but the first obstacle we found was that we had to replace a workstation, the workstation that the Bank had at that time was an Operating System that had 2000 on his behalf and it was 2018 so he was a couple of years out of date!

(can’t hear? ah well that’s ok sorry, I thought you couldn’t hear)

And one requirement we had was that these workstations needed to connect to users that were in an AD (Active Directory), so that AD was in Headquarters and the workstations were scattered…

(can you hear? There?)

… In different cities, throughout the country…

(I don’t know if I’m coming, is it very loud? Is it okay? Well, yes…yes, no…no, yes…yes, no…no)

Well finally we were like this, we had a workstation based on Debian, it was clear that we were going to use that and we had the AD, so we had to find something that, a piece that joins this in the middle and this is called IPA, it is a free development that can be used to integrate.

(Me? I grab… Sorry… I have 2 hands, I hadn’t realized!)

Well… So we managed to get users to talk to the AD, this, through IPA and finally the other leg that we needed was the server part, in each branch of the Bank there was a server, instead of ending with a 2000, it ended with a 4 (the Software) and also in 2018 imagine!

And via a VPN we were going to get to the server, the server was going to be based on Debian, a distribution called Proxmox, it was going to virtualize and it was going to have a lot of virtual machines with Debian again to complete the scheme that was the stage of Laboratory, it took us six months to realize that!

And we went to a stage of Development!

(Let’s see if this works? A little there, we’re better)

In the development stage we already figured out how to deploy these services and this service deployment is basically the AWX connects to GitLab, obtains the code, with that code it communicates with the iDRAC which is the administration interface of a DELL server and It deals with creating the storage, this, configuring the BIOS and restarting the computer.

As soon as you restart the computer, Proxmox starts running:

• talk to the NodeVPN, get an IP
• talk to a PXE server, get an image with a Kernel
• boot, get a base image
• goes to a local CDN, looks for local resources,
• what it does not have locally goes to Headquarters (when I say Headquarters is because we can be in any Subsidiary, anywhere in the country)
• and finally if Debian packages are to be installed, we need a APT repository and we have a local cache, but if the package we need is not in the local cache, it will Headquarters accesses another cache repository and finally all the packages are installed
• and in this way we have a server, this… from scratch, recently installed!

Now, thinking of… More… To see him…

(let’s see if it’s possible, here we have…)

There is the start of the iDRAC interface, in the background what you see in green and black is me playing to get debug, but the process is automated, that is:

• from AWX the connection was triggered
• the server is brought up the server takes an interface by PXE
• you’re going to get a Debian image that’s going to be self-installing, it’s a process that lasts a series of minutes
• and the operator that triggers execution from the interface AWX administration, you don’t have to do anything but wait!

And in fact at the time of generation of servers, imagine there are 300 subsidiaries, they had to generate 300 servers, they generated 3 servers at the same time, in this way they generated it in parallel at Headquarters, this simply by opening the box connecting 2 network cables and from AWX triggering the execution and waiting, I don’t know, I think maximum 1 hour and you had 3 servers installed and configured from scratch, with all the components they had inside, that is:

First a Debian Net Install is done which is what we are seeing there in an accelerated way

• Then the computer restarts
• The equipment is registered only to the AWX, in the inventory, it says… I am such MAC, I am such IP, I am such equipment
• and from there the operator can fire the second execution that is… Well now you stop being a base Debian and become a Proxmox
• and after you have already become a Proxmox, it goes on to… A circuit that what it does is create the 10 virtual ones that are needed and
• and then a third circuit that what it does is create the services that is inside each virtual and the whole process is automated
• and finally… Nothing, a server is running that will have all the virtual ones you need!

But it will also have the ability to generate another server exactly the same, this one with the same steps, that is:

• to generate a server we use a server
• to generate another server we use that same generated server
• recursion they say…

Workstation… Well with workstations it happens to us that as there were many, there were no longer 300, they were 3000, what we did is a base image, that base image was sent to the workstation manufacturer to clone

And what you had to do afterwards was select that workstation and apply the changes to it, whatever is new and basically enroll it in the network.

(here what we are going to see, I am going to see if I can pause a bit…)

Eh… On the right… yes… I’m on a Proxmox server with a virtual one, to play in Development.

And on the left I have the AWX interface and basically what I have is identified in the inventory the IP of the host, the MAC, the hostname since the Subsidiary it belongs to, in this case it is 661.

And on the right, what I am going to see is that what AWX is going to execute on the left, on the right, it is going to materialize in some way. In this case, it is a fairly simple example, which is to change the wallpaper, but what is interesting is that it is done from Headquarters, the workstation can be anywhere in the country.

And the operator only sees the AWX interface, he never sees the workstation screen, he simply chooses a series of templates and within the template what he chooses is the limit.

The limit is basically one or more teams together that will deploy, they are always deployed in parallel,

This… All that’s needed is the limit on that and once it’s run in the control panel what you’re going to see is a bunch of messages.

(there you can see half a boy but… Let’s see if I can zoom in… yes… eh)

What is green is fine, what is red is a serious error, this little orange is when something of value changes and cyan when it could be skipped because it was not necessary to do so.

The scheme is quite simple, it is a web page, values are chosen, those values…

(let’s pause there, let’s see…)

There for example we see, we are in a workstation and we see the variables that are loaded inside the AWX and it says for example the default_background and the name of the image and basically that value comes from GitLab and is versioned, but from the Administration panel of AWX, if you have enough permissions, you can change it and if you change it, as it is in this case here, eh… It’s trying to change the background of the screen, let’s see if it succeeds in this execution, I think there was an error there .

(I don’t even remember what I did…)

Yes, indeed there it says gcoop.jpg and it says failed and if we look in the log … There it will be going down… Where it is in red is because it is trying to find an image that does not exist, so now what it is going to do is… There is no no problem, the operator can change the file name to the corresponding file name, there he put the correct name, it tells him to save.

Execute again and it is executed on the failed equipment, which can be 1 or many and once it turns green, that is, the operator only waits for it to turn green, if it turns green everything is fine and continues with another template or with another team and if it turns red, something happened…

And so it immediately changes on the right side, in the job to the user while he was “logged in”, that is, the example is quite simple but it also serves to comment that any task, no matter how small, can be automated and In fact, there are 3,000 workstations, users do not have permission for anything, that is, everything is done from Headquarters in an automated, centralized manner, all changes are versioned, because It’s the only way to keep control over so many computers…

Well, then we were ready to deploy…

To do the deployment is to do the same thing but with many workstations at the same time, then basically it begins to become more complex, it is similar to the above, that is:

• AWX communicates with GitLab, gets the code and it will run a team, in this case 3 jobs these 3 jobs get the changes, but need local resources
• some local resources are the local APT cache a local CDN which is one nginxthat we have there in a VM in a server, but then it needs resources against the FileServer that is inside of the subsidiary
• and finally to be able to have a centralized login you need to talk to the IPA that is in Headquarters and also with the Cluster of the 4 ADs that are in Headquarters then there begins to be a lot of traffic from one side to the other, which is a little… colorinche, but hey, it works,

In real life, hardly anyone sees that all this is happening behind the scenes, inside AWX or they see green or they see red and everything went well or they call us.

Well, next stage, we’re ready for staging !

Staging, basically… That is to say, go out to production in this case but with a single Subsidiary, instead of 300 to see if the solution works

And there we find things, right?

Well there are not only 3000 workstations, there are thousands of different peripherals!

(let’s see if I can pause, there)

In these peripherals we had to make the workstations that are all the same for a cashier position, also be for the manager or for the receptionist or for whoever is inside the Bank and has to work that same workstation with a Cash Scanner checks, with a ticket printer or whatever it takes…

The technology we use in summary is this:

• Ansible, Python, AWX
• On the IPA side, IPA goes with CentOS, CentOS 7, when we started the project there was CentOS 7, not now, we are going to migrate it
• on the Debian 10 server side, when we started it was stable, Proxmox 6.3
• and the same on the side of jobs, we are already a little old…

Like any big migration project, when you finish migrating it, you have to start over!

The advantage is that it would only be to update some playbooks and roles, in short, we already have the deployment tool!

Well, we have 10 virtual machines, to recap, with different uses this… PrintServer, FileServer …

Within GitLab we have more than 200 repositories!

Here and there I pause, this was an important change of work, normally in a project no matter how big it is with 1, 2, 5 repositories…

And going to work with 200 repositories… it’s chaos!

It’s chaos and on top of that everything is versioned and many repos are nested that some depend on the others and well it’s possible! GitFlow helped a lot there.

And the important thing there is that there is 1 repository called inventory which is the entire inventory of all the equipment that is turning around, are versioned in one place and there is a repository called awx, that is, all the information to run the /AWX/ deployment , which could be done manually from the administration interface we did it via code and then that code is shipped and deployed and versioned.

(well… And that’s where everything was hung… right? That’s the end of it!)

Well there AWX, the number of projects we have, more than 200 projects, 300 inventories, nothing, many templates, each one does something different

(Let’s see if… Pause)

Well, this is a summary of how we have come so far, that is, we had 6 months of laboratory, 1 year of development, 1 year of deployment of the solution, 87 days in staging, that is, we had a subsidiary for almost 3 months in operation running, fully migrated, server and new.

And from there began the arduous task that we got to here, let’s say we got there, we designed the solution, but the implementation was done by the Bank’s Implementations team, the truth is that they managed to do it in less than 1 year!, they came to migrate 3 per night! In 347 days, 300 subsidiaries migrated

And that is something important to understand, we are talking about a Bank and in a Bank that is how it closes at 06:00, opens at 09:00. Well, that was the window that the Implementations team had to change the server, change the rack, change the switches, rewire everything, install a new Operating System, deploy from Headquarters and in the morning everything continues to operate, like people go and do I don’t know their fixed term and everything works!

And it was obviously done in 2 stages, a first stage of servers and a second stage of workstations, but initially, that is all the Subsidiaries, went from one day to the next to throw away the infrastructure they had and start up with a new one.

And something important is that, one difference that this project had, is that before the VPN was outside and in this case the server that replaced the infrastructure of the Subsidiary had the VPN inside the virtualized server, so it was quite a challenge that’s good and we finished in 2021, on September 9, the deployment of all the Subsidiaries was finished.

We entered there what would be support, which is really good as you know, support for something recently migrated is like finishing a little what we had been doing and from there well… Evolutionary maintenance so to speak, this there are improvements every day and new challenges and developments to fix.

(wait… nothing works for me)

Well let’s jump to Production We are in Production!

This is a way to see production!

(let’s see if we can increase)

This is an interpretation of what the migrated Bank is for us!

In the center of all that, this AWX, each balloon is a team that we can manage…

(let’s get closer!)

Come here in the center, this AWX which is a single team that is virtualized in Headquarters, which is going to connect for example here in red/orange Branch 105 and that Branch 105 well has its 10 virtual machines, its Proxmox server, its PrintServer and its 10 or 15 workstations there and the same is going to happen to 252 next to it, to 85 and to all the others!

It’s chaos!

I don’t know how they did this before! That we used AWX and had everything and Ansible versioned .

But the truth is that…

The only way to be able to manage so many computers on such a large scale and know what is happening to each one and to see why it doesn’t work, I don’t know, the printer of Subsidiary 24 , it’s like…

No hay otra manera, tiene que ser centralizado y tiene que estar automatizado!

(I don’t know how we got here on time? I have 3 minutes left!)

One of the little problems we had when we started Production was this!

That we did all the tests that we did of user login, although we simulated a certain load, we were never going to have the load that was production, which is basically around 10:00 in the morning, you have 2000 people who “log in” at the same time!

And then that good generated, a few seconds of delay for example there we are seeing that there is… More than 20 seconds of delay in the login is like a problem!.

So well, this is something that we mitigate in some way by generating a login cache synchronization and an API in the middle to just in time try to synchronize those users and well the definitive solution is going to come soon with a Cluster of IPAs in Instead of just one, we believe that it will be the solution, but well, it is one of the problems with the concurrence of many users at the same time.

(and I lost everything, wait, F5)

Well, what’s next?

We are working with many things in parallel but well here, this is a brief graphic that basically what we do is the AWX update solution , that is, at the beginning, what did we do?

We made a template in AWX, trial and error, trial and error until it worked for us and we said, well, this is it!

And now we have to pass it to production and pass it to Production, well, we exported a .jsonand that JSON we put it in production by hand, let’s say with commands from a CLI but basically manually and we said “that’s it!”

But hey, that’s not cool, that Development touches Production, so what we did is a script that what it does is, as soon as you start developing in a branch of your role or your playbook, as soon as you do push, GitLab deals with the CI to do whatever it takes to get that template deployed .

• it is first deployed in Development
• if it went well, the deploy in Development is deployed in Staging and if it turned out well in Staging, let’s say, it fulfilled the two steps and passed the entire test circuit, we generate a release

And we say to the Bank’s Technology team, “hey, you can deploy such a release” and the pass to Production uses the same script used by GitLab CI but triggered by a SysAdmin who says everything is going… (and who mistrusts us…! )

Well, that’s basically an idea and a summary of the migration project that we had to do from gcoop, I didn’t say it before but:

gcoop is a Free Software Cooperative, we work exclusively with Free Software, we don't have bosses, we don't have employees, we are all partners and it is another way of working and it is possible that we do things like this, like these and that they work!

So as of now, I got right to 20 seconds! I answer questions, we have a few minutes, if you dare? I am still standing!

Thank you so much OSiRiS ! Well thank you very much!

Excellent talk! Great gcoop support Free Software and the development of that style, much more is needed!

I ask you to stay here while we close the next presentation that will be in English, so those who need it, behind us we have headsets for the real-time translation of our stars of the night, there in the booth, so good, many thanks again OSiRiS, a new round of applause, see you in a few minutes…

The event used the swapcard platform and after the talk I could see that they asked several questions, some were answered at the time, but others were pending, so I answer each question here.

• Cómo aprovisionar, instalar, configurar y mantener actualizados miles de sistemas Debian y basados en Debian
• How to provision, install, configure and keep thousands of Debian and Debian-based systems updated
• Automate BIOS setup using ansible and HP Linux Tools
• Filiales GNU/Linux FLISoL CABA
• Ansible Tools v0.3.0
• Automate deployment of AWX resources with GitLab CI/CD and Ansible Tools
• Use Graphviz to generate Slides
• Cómo hacer una línea de tiempo con GraphViz

• 2022-11-13 20:39 agregar y actualizar tags OpenGraph
• 2022-10-28 14:13 add links to in titles to Draft "How to migrate 6300 hosts to GNU/Linux using Ansible and AWX"
• 2022-10-28 14:26 use thumbnails form images in Draft "How to migrate 6300 hosts to GNU/Linux using Ansible and AWX"
• 2022-10-28 14:18 fix typo in footnote reference in Draft "How to migrate 6300 hosts to GNU/Linux using Ansible and AWX"
• 2022-10-28 13:37 add Draft "How to migrate 6300 hosts to GNU/Linux using Ansible and AWX"
• 2022-10-28 13:26 renombrar 2022-10-20-howto-migrate-6300-hosts-to-gnu-linux-using-ansible-and-awx.org a 2022-10-20-como-migrar-6300-equipos-a-gnu-linux-usando-ansible-y-awx
• 2022-10-26 17:48 agregar Cómo migrar 6300 equipos a GNU/Linux usando Ansible y AWX

Aprovechando la vuelta presencial de nerdearla ¹ edición 2022 en el Konex ², presenté la charla "Cómo migrar 6300 equipos a GNU/Linux usando Ansible y AWX" ³

Resumir 4 años de trabajo en 25 minutos no es tarea fácil, pero debido a la gran cantidad de charlas en simultáneo no quedaba otra que resumir, asi que dividí el charla en 7 etapas, coincidiendo con los 7 colores del cooperativismo 🌈

Para detallar y extender un poco más la charla, desgrabé el audio y voy a estar agregando referencias a cada tema y/o tecnología mencionada, para quienes quieran profundizar un poco más.

En lugar de hacer Slides generé un sitio web ⁴ con la ayuda de Hugo Ruscitti ⁵ quien armó el visor de videos multiples ⁶, el cual utilicé para mostrar varios videos al mismo tiempo.

Como varias personas preguntaron sobre la herramienta que utilicé para hacer los gráficos, armé un post ⁷ detallando cómo generé los gráficos y la línea de tiempo ⁸ usando GraphViz ⁹

Al final agregué las preguntas y respuestas que surgieron en swapcard

Bueno, bienvenidos nuevamente al track Infra en Nerdearla!

Todo bien? Cómo la están pasando? Eh ahí va ese público todavía!

Bueno muy bien, muchas gracias por estar acá!

Dije ya varias veces, lo vuelvo a decir la novena edición de Nerdearla 2022, los 10 años de Sysarmy ¹⁰ y aquí estamos, acá Trac Infra, tenemos un Trac Dev Online y un Trac Sec Online y el Trac de DataScience allá en el otro auditorio, acá en la Ciudad Cultural Konex del 19 al 22 de Octubre, nada venite, todavía estas a tiempo de venirte, esta tarde, Viernes y Sábado si nos estas viendo por Internet pero si estás acá, ya estás disfrutando de todas las actividades que tenemos en los Stands, de los auditorios, de lugares para hacer coworking, juegos, etc hay de todo gracias! Gracias por estar acá y acompañarnos!

Y ahora se viene viene la última tanda de charlas, no es la última charla, la última tanda, son varias las charlas que tenemos por delante.

Bueno y ahora vamos a hablar de algo que a mi me gusta mucho, que es el Software Libre. A quién le gusta el Software Libre acá?

Vamos todavía! Mirá, tenes FANs! Joya

Bueno entonces, vamos a recibir a OSiRiS GóMeZ, que es socio de gcoop ¹¹, que es una Cooperativa de Software Libre…

Héroes sin capa, como solemos decir...

Es programador y Administrador de GNU/Linux (viste que dije GNU y no G-N-U, sino Richard Stallman ¹² se enoja) es autodidacta y fanático de automatizar todo desde una terminal (una tty en realidad dice acá) y esta muy interesado en divulgar el uso del Software Libre, así que…

Los dejo con OSiRiS un aplauso por favor!

Huy que alto que estoy!, se escucha?, si?, perfecto!

(bueno, ahí me parece que se escucha mejor

Primero pido disculpas si por ahí toso porque vengo mal de la garganta.

Y lo que voy a intentar hacer en 25 minutos, si es que lo logro es contarle la historia de gcoop y Banco Credicoop ¹³ en estos últimos 4 años.

Básicamente es un proyecto de migración de toda la Infraestructura de las Filiales, son muchas, en todo el país y bueno, fue todo un desafío, lo logramos!

Pero vamos a ir viéndolo paso a paso un poco como lo fuimos viviendo.

Inicialmente tuvimos una etapa de laboratorio, en esta etapa de laboratorio teníamos que analizar si era posible hacer este proyecto de migración y con qué herramientas libres era posible hacerlo?

Básicamente lo que detectamos es que primero íbamos a usar Ansible porque nosotros ya lo veníamos usando en gcoop y estábamos muy contentos con el uso de Ansible, eh, básicamente era hacer roles y playbooks, este código que lo escribíamos iba a estar en un repositorio GitLab y este repositorio GitLab iba a ser obtenido como Infraestructura como Código desde la herramienta AWX para hacer el despliegue o el deploy en todos los equipos que hiciera falta y algo…

(a ver si me funciona esto…, si, no, ahí)

La barrita que se ve abajo (vamos a intentar que se quede quieta por un minuto) es una línea de tiempo de todos los proyectos que terminamos utilizando finalmente en algún momento del proyecto, estoy hablando de casi 4 años y lo interesante es que el primer día que empezamos esto, que fue en el 2018 no teníamos ni idea que esa barrita la íbamos a estar usando es decir, que hay un montón de proyectos de distintas comunidades de desarrollo de Software Libre, alrededor del mundo que estaban haciendo proyectos que luego nosotros los íbamos a terminar usando y esto es lo importante del Software Libre o sea que nos potenciamos todos y todas, este… Construyendo y devolviendo finalmente algo más!

Teniendo Ansible y teniendo AWX con GitLab ya podíamos empezar a hacer un despliegue masivo, pero el primer impedimento que encontramos es que teníamos que reemplazar un puesto de trabajo, el puesto de trabajo que tenía el Banco en ese momento era un Sistema Operativo que tenía 2000 en su nombre y estábamos en el 2018, así que tenía un par de años desactualizado!

(no se escucha? ah bueno esta bien perdón, pensé que no se escuchaba)

Y un requerimiento que teníamos era que estos puestos de trabajo necesitaban que se conectaran a los usuarios que estaban en un AD (Active Directory), entonces ese AD estaba en CasaCentral y los puestos de trabajo estaban desparramados…

(se escucha? Ahí?)

… Por distintas ciudades, en todo el país…

(yo no sé si me corro, se escucha muy fuerte? Esta bien? Bueno, si..si, no..no, si..si, no..no)

Bueno finalmente estábamos así, teníamos un puesto de trabajo basado en Debian, era claro que íbamos a usar eso y teníamos el AD, así que teníamos que encontrar algo que, una pieza que una esto en el medio y esto se llama IPA, es un desarrollo libre que lo pueden utilizar para integrar.

(yo? Agarro… Perdón… Tengo 2 manos no me había dado cuenta!)

Bueno… Conseguimos entonces, usuarios que hablen con el AD, este, mediante IPA y finalmente la otra pata que nos faltaba era la parte de servidores, en cada sucursal del Banco había un servidor, éste en lugar de terminar con un 2000, terminaba con un 4 (el Software) y también en el 2018 imagínense!

Y vía una VPN íbamos a llegar al servidor, el servidor iba a estar basado en Debian, una distribución que se llama Proxmox, iba a virtualizar e iba a tener un montón de máquinas virtuales con Debian nuevamente para completar el esquema esa fue la etapa de Laboratorio, seis meses tardamos para darnos cuenta de eso!

Y pasamos a una etapa de Desarrollo!

(a ver si funciona esto? Poquito ahí, estamos mejor)

En la etapa de desarrollo ya imaginamos cómo hacer el despliegue de estos servicios y este despliegue de servicios básicamente es el AWX se conecta al GitLab, obtiene el código, con ese código se comunica al iDRAC que es la interfaz de administración de un servidor DELL y se ocupa de crear el storage, este, configurar la BIOS y reiniciar el equipo.

Ni bien reinicia el equipo, el Proxmox empieza a correr:

• habla con el NodoVPN, obtiene una IP
• habla con un servidor PXE, obtiene una imagen con un Kernel
• bootea, obtiene una imagen base
• va a un CDN local, busca los recursos locales,
• lo que no tiene localmente va a buscar a CasaCentral (cuando digo

CasaCentral es porque podemos estar en cualquier Filial, en cualquier punto del país)

• y finalmente si hay que instalar paquetes de Debian, necesitamos un

repositorio APT y tenemos una cache local

• pero si en la cache local no esta el paquete que necesitamos, se

accede a CasaCentral a otro repositorio de cache de cache y finalmente se instalan todos los paquetes

• y de esta manera tenemos un servidor, este.. desde cero, recién

instalado!

Ahora, pensando en… Mas… En verlo…

(a ver si es posible, acá tenemos…)

Ahí esta el inicio de la interfaz de iDRAC, de fondo lo que ven en verde y negro soy yo jugando para obtener debug, pero el proceso es automatizado es decir:

• desde AWX se disparó la conexión
• se levanta el servidor el servidor toma una interfaz por PXE
• va a obtener una imagen de Debian que va a ser autoinstalable, es un

proceso que dura una serie de minutos

• y el operador que dispara ejecución desde la interfaz de

administración de AWX, no tiene que hacer nada, mas que esperar!

Y de hecho en el momento de generación de servidores, imaginen son 300 filiales, había que generar 300 servidores llegaron a generar 3 servidores al mismo tiempo, de esta manera en paralelo lo generaban en CasaCentral, este simplemente abriendo la caja conectando 2 cables de red y desde AWX disparando la ejecución y esperar, no sé, creo que máximo 1 hora y tenías 3 servidores instalados y configurados desde cero, con todos los componentes que tenían dentro, es decir:

• Primero se hace un Debian Net Install que es lo que estamos viendo ahí

de manera acelerada

• Luego se reinicia el equipo
• Se dá de alta el equipo solo al AWX, en el inventario, le dice… Soy

tal MAC, soy tal IP, soy tal equipo

• y a partir de ahí el operador puede disparar la segunda ejecución que

es.. Bueno ahora dejas de ser un Debian base y pasas a ser un Proxmox

• y luego de que ya te convertiste en un Proxmox, este pasa a … Un

circuito que lo que hace es crear las 10 virtuales que hacen falta y

• y después un tercer circuito que lo que hace es crear los servicios

que hay dentro de cada virtual y todo el proceso es de manera automatizada

• y finalmente… Nada, queda funcionando un servidor que va a tener

todas las virtuales que necesita!

Pero además va a tener la capacidad de generar otro servidor exactamente igual, este con los mismos pasos es decir:

• para generar un servidor usamos un servidor
• para generar otro servidor usamos ese mismo servidor generado
• recursividad le dicen…

Workstation… Bueno con workstation nos pasa que como eran muchas, ya no eran 300, eran 3000, lo que hicimos es una imagen base, esa imagen base se envió a clonar con el fabricante de las workstations

Y lo que había que hacer después era, seleccionar esa workstation y aplicarle los cambios, lo que haya de nuevo y básicamente enrolarla a la red

(acá lo que vamos a ver, voy a ver si puedo pausar un poco…)

Eh… A la derecha…si.. Estoy en un servidor Proxmox con una virtual, para jugar en Desarrollo.

Y a la izquierda tengo la interfaz de AWX y básicamente lo que tengo es identificado en el inventario la IP del host, la MAC, el hostname y a que Filial pertenece, en este caso es la 661.

Y a la derecha lo que voy a ir viendo es que lo que va a ejecutar a la izquierda AWX a la derecha se va a materializar de alguna manera en este caso es un ejemplo bastante simple, que es cambiar el fondo de pantalla pero lo interesante es que se hace desde CasaCentral, la workstation puede estar en cualquier lugar del país.

Y el operador solo ve la interfaz de AWX, nunca ve la pantalla de la workstation, simplemente elige una serie de plantillas y dentro de la plantilla lo que elije es el límite.

El límite es básicamente uno o mas equipos en conjunto que va deployar siempre se deployan en paralelo,

Este.. Todos lo que hagan falta es importante el límite en eso y una vez que se ejecuta en el panel de control lo que van a ver es un montón de mensajes.

(ahí se ve medio chico pero… A ver si hago zoom…si..eh)

Lo que esta verde esta bien, lo que esta rojo es error grave, este naranjita es cuando cambia algo de valor y celestito cuando se lo pudo saltear porque no era hecesario hacerlo.

El esquema es bastante simple es una página web, se eligen valores, esos valores…

(vamos a hacer una pausa ahí, a ver…)

Ahí por ejemplo vemos, estamos en una workstation y vemos las variables que están cargadas dentro del AWX y dice por ejemplo el default_background y el nombre de la imagen y básicamente ese valor proviene desde el GitLab y esta versionado, pero desde el panel de Administración de AWX, si tenés permisos suficientes, lo podés cambiar y si lo cambias, como es en este caso acá, eh.. Esta tratando de cambiar el fondo de la pantalla vamos a ver si lo logra en esta ejecución, creo que hubo un error ahí.

(ya ni me acuerdo lo que hice…)

Si, efectivamente ahí dice gcoop.jpg y dice fallido y si miramos en el log… Ahí va a estar bajando… Ahí donde esta en rojo es porque esta tratando de buscar una imagen que no existe, entonces ahora lo que va a ir haciendo es… No hay ningún problema, el operador puede cambiar el nombre de archivo por el nombre de archivo que corresponde, ahí puso el nombre correcto, le dice guardar.

Volver a ejecutar y se ejecuta sobre el equipo fallido, que puede ser 1 o muchos y una vez que le dé verde, o sea el operador solo espera que le de verde, si le da verde esta todo bien y sigue con otra plantilla o con otro equipo y si le da rojo, algo pasó…

Y así que cambia inmediatamente en el lado derecho, en el puesto de trabajo al usuario mientras estaba «logueado», es decir, es bastante simple el ejemplo pero también sirve para comentar de que cualquier tarea por mas pequeña que sea, se puede automatizar y de hecho los puestos de trabajo, como son 3000, los usuarios no tienen permiso para nada, es decir todo se hace desde CasaCentral de manera automatizada, centralizada, están todos versionados los cambios, porque es la única manera de mantener el control sobre tantos equipos…

Bueno, entonces ahí ya estábamos listos para hacer el despliegue…

Para hacer el despliegue es hacer esto mismo pero con muchas workstations al mismo tiempo entonces básicamente se empieza a complejizar, es similar a lo anterior es decir:

• AWX se comunica con GitLab, obtiene el código
• y va a ejecutar a un equipo, en este caso 3 puestos de trabajo
• éstos 3 puestos de trabajo obtienen los cambios, pero necesitan

recursos locales

• algunos recursos locales son la cache de APT local
• un CDN local que es un nginx que tenemos ahí en una /VM /en un

servidor,

• pero después necesita recursos contra el FileServer que esta dentro

de la Filial

• y finalmente para poder tener login centralizado necesita hablar con

el IPA que esta en CasaCentral

• y además con el Cluster de los 4 ADs que están en CasaCentral
• entonces empieza a haber mucho tráfico de una lado para el otro que es

un poco … colorinche, pero bueno, funciona,

En la vida real casi nadie ve que esta pasando todo esto por detrás, dentro de AWX o se ve verde o se ve rojo y salió todo bien o nos llaman.

Bueno, siguiente etapa, ya estamos para staging!

Staging, básicamente… Es decir salir a producción en este caso pero con una sola Filial, en lugar de con 300 para ver si efectivamente la solución anda

Y ahí nos encontramos con cosas, no?

Bueno no solo hay 3000 workstations, hay miles de periféricos distintos!

(a ver si puedo poner pausa, ahí)

En estos periféricos tuvimos que hacer que la workstations que son todas iguales para un puesto de caja, también sean para el gerente o para la recepcionista o para quien sea que este dentro del Banco y tiene que andar ese mismo puesto de trabajo con un Scanner de cheques, con una impresora de tickets o lo que sea que haga falta…

La tecnología que utilizamos en resumen es esto:

• Ansible, Python, AWX
• del lado de IPA, IPA va con CentOS, CentOS 7, cuando empezamos el proyecto existía CentOS 7, ahora no, ya lo vamos a migrar
• del lado de los servidores Debian 10, cuando empezamos era stable, Proxmox 6.3
• y lo mismo del lado de los puestos de trabajo, ya nos quedó un poquito viejo…

Como todo proyecto de migración grande, cuando terminas de migrarlo, tenes que volver a empezar!

La ventaja es que sería solo actualizar algunos playbooks y roles, total, la herramienta de despliegue ya la tenemos!

Bueno, tenemos 10 máquinas virtuales, para recapitular, con distintos usos este.. PrintServer, FileServer…

Dentro de GitLab tenemos mas de 200 repositorios!

Acá por ahí hago una pausa, este fue un cambio importante de trabajar, normalmente en un proyecto por mas grande que sea con 1, 2, 5 repositorios…

Y pasar a trabajar con 200 repositorios… es un caos!

Es un caos y encima esta todo versionado y muchos repos están anidados que unos dependen de los otros y bueno es posible!. GitFlow ayudó bastante ahí.

Y lo importante ahí es que hay 1 repositorio que se llama inventory que es todo el inventario de todos los equipos que estén dando vuelta, están versionados en un único lugar y hay un repositorio que se llama awx, es decir, toda la información para que se corra el despliegue de /AWX, que se podría realizar manualmente desde la interfaz de administración la hicimos vía código y entonces, ese código se envía y se deploya y queda versionado.

(bue… Y ahí se colgó todo…no? Hasta acá llegamos!)

Bueno ahí AWX, la cantidad de proyectos que tenemos, mas de 200 proyectos, 300 inventarios, nada, muchas plantillas, cada una hace algo distinto

(y a ver si… Pausa)

Bue, esto es un resumen de tiempos de cómo venimos hasta el momento es decir, tuvimos 6 meses de laboratorio, 1 año de desarrollo, 1 año de despliegue de la solución, 87 días en staging, es decir tuvimos una Filial casi 3 meses operativa funcionando, totalmente migrada, servidor y nuevo.

Y a partir de ahí empezó la tarea ardua que nosotros hasta acá, digamos hasta ahí llegamos, nosotros diseñamos la solución, pero la implementación la hacía el equipo de Implementaciones del Banco la verdad que lograron hacerlo en menos de 1 año! En 347 días migraron 300 /Filiales, llegaron a migrar 3 por noche!

Y eso es algo importante de entender, estamos hablando de un Banco y en un Banco o sea como cierra a las 06:00, abre a las 09:00. Bueno, esa era la ventana que tenía el equipo de Implementaciones para cambiar el servidor, cambiar el rack, cambiar los switchs, recablear todo, instalar un Sistema Operativo nuevo, hacer el deploy desde CasaCentral y que a la mañana todo siga operando, como que la gente vaya y haga no sé su plazo fijo y funcione todo!

Y se hizo obviamente en 2 etapas, se hizo una primer etapa de servidores y una segunda etapa de workstations, pero inicialmente, es decir todas las Filiales, pasaban de un día al otro a tirar la infraestructura que tenían y a arrancar con una nueva.

Y algo importante es que, una diferencia que tuvo este proyecto, es que antes la VPN estaba por fuera y en este caso el servidor que reemplazaba la infraestructura de la Filial tenía la VPN dentro del servidor virtualizado, así que fue todo un desafío eso bueno y terminamos en 2021, el 9 de Septiembre, se terminó el despliegue de todas las Filiales.

Entramos ahí lo que sería soporte, que en realidad bueno como saben, soporte de algo recién migrado es como terminar un poco lo que veníamos haciendo y a partir de ahí bueno… Mantenimiento evolutivo por así decirlo, este hay mejoras todos los días y nuevos desafíos y desarrollos que solucionar.

(esperen…que no me anda nada)

Bueno vamos a saltar a Producción Estamos en Producción!

Esto es una manera de ver producción!

(vamos a ver si podemos aumentar)

Esta es una interpretación de lo que es el Banco migrado para nosotros!

En el centro de todo eso, esta AWX, cada globito es un equipo que podemos administrar…

(vamos a acercarnos!)

Ven aquí en el centro, esta AWX que es un solo equipo que esta virtualizado en CasaCentral, que se va a conectar por ejemplo acá en rojo/naranja la Filial 105 y esa Filial 105 bueno tiene sus 10 máquinas virtuales, su servidor Proxmox, su PrintServer y sus 10 o 15 workstations ahí y lo mismo le va a pasar a la 252 que esta ahí al lado, a la 85 y a todas las demás!

Es un caos!

Yo no sé como hacían esto antes! De que usáramos AWX y tuviéramos versionado todo y Ansible.

Pero la verdad es que… La única manera de poder administrar tantos equipos a tan gran escala y saber que es lo que le pasa a cada uno y ver porqué no anda, no se, la impresora de la Filial 24, es como…

No hay otra manera, tiene que ser centralizado y tiene que estar automatizado!

(no sé como venimos de tiempo?, me quedan 3 minutos!)

Uno de los problemitas que tuvimos cuando empezamos Producción fue esto!

Que nosotros todas las pruebas que hicimos de login de usuarios, lo hacíamos, si bien simular cierta carga, nunca íbamos a tener la carga que era producción que es básicamente cerca de las 10:00 de la mañana tenés 2000 personas que se «loguean» al mismo tiempo!

Y entonces eso bueno generó, algunos segundos de demora por ejemplo ahí estamos viendo que hay… Mas de 20 segundos de demora en el login es como todo un problema!.

Entonces bueno, esto es algo que mitigamos de alguna manera generando una sincronización de cache de login y una API en el medio para justo a tiempo tratar de sincronizar esos usuarios y bueno la solución definitiva va a venir dentro de pronto con un Cluster de IPAs en lugar de uno solo, creemos que va a ser la solución pero bueno es uno de los problemas que hay con la concurrencia de muchos usuarios al mismo tiempo

(y se me perdió todo, esperen, F5)

Bueno, que sigue?

Estamos trabajando con muchas cosas en paralelo pero bueno acá, este es un breve gráfico que básicamente lo que hacemos es la solución de actualización de AWX, es decir, en el inicio nosotros que hacíamos?

Hacíamos una plantilla en AWX, prueba y error, prueba y error hasta que nos andaba y decíamos bueno ya esta!

Y ahora hay que pasarla a producción y a pasarla a Producción bueno exportábamos un .json y ese JSON lo poníamos en producción a mano digamos con comandos de un CLI pero básicamente manual y decíamos «ya esta!»

Pero bueno, eso no esta piola, que Desarrollo toque Producción, entonces lo que hicimos es un script que lo que hace es, ni bien empezás a desarrollar en un branch de tu rol o de tu playbook, ni bien hacés push, GitLab se ocupa con la CI de hacer todo lo que haga falta para que esa plantilla se deploye.

• primero se deploya en Desarrollo
• si salió bien, el deploy en Desarrollo, se deploya en Staging
• y si en Staging ya quedó bien digamos, cumplió los dos pasos y pasó

todo el circuito de pruebas, generamos un release

Y le decimos al equipo de Tecnología del Banco, «che, pueden deployar tal release» y el pase a Producción se usa el mismo script que utiliza GitLab CI pero disparado por un SysAdmin que dice todo anda … (y que desconfía de nosotros…!)

Bueno, eso es básicamente una idea y un resumen del proyecto de migración que nos tocó hacer desde gcoop, no lo dije antes pero:

gcoop/ es una /Cooperativa de Software Libre/, trabajamos exclusivamente con /Software Libre/, no tenemos jefes, no tenemos empleados, todos somos socios y socias y es otra manera de trabajar y es posible que hagamos cosas asi, como éstas y que funcionen!

Así que a partir de ahora, llegué justo con los 20 segundos! Respondo preguntas, tenemos unos minutos, si se animan? Yo todavía estoy en pie!

Muchas Gracias OSiRiS! Bueno Muchas Gracias!

Excelente charla! Grande gcoop aguante el Software Libre y el desarrollo de ese estilo, hace tanto falta mas!

Les pido que se queden acá mientras cerramos la siguiente presentación que aviso va a ser en Inglés, así que quienes necesiten, detrás tenemos Headsets para la traducción en tiempo real de nuestras estrella de la noche, ahí en la cabina, así que bueno, muchas gracias nuevamente OSiRiS, un nuevo aplauso, nos vemos en unos minutos…

El evento utilizaba la plataforma swapcard y luego de la charla pude ver que hicieron varias preguntas, algunas fueron contestadas en el momento, pero otras quedaron pendientes, asi que respondo cada pregunta por acá.

• Cómo aprovisionar, instalar, configurar y mantener actualizados miles de sistemas Debian y basados en Debian
• How to provision, install, configure and keep thousands of Debian and Debian-based systems updated
• 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

• 2022-11-13 20:39 agregar y actualizar tags OpenGraph
• 2022-11-13 12:56 agregar tags OpenGraph article y corregir type en Cómo migrar 6300 equipos a GNU/Linux usando Ansible y AWX
• 2022-11-13 10:40 agregar tags OpenGraph en Cómo migrar 6300 equipos a GNU/Linux usando Ansible y AWX
• 2022-10-28 15:29 corregir link a traducción al Inglés de Cómo migrar 6300 equipos a GNU/Linux usando Ansible y AWX
• 2022-10-28 14:35 agregar link a traducción al Inglés de Cómo migrar 6300 equipos a GNU/Linux usando Ansible y AWX
• 2022-10-28 13:26 renombrar 2022-10-20-howto-migrate-6300-hosts-to-gnu-linux-using-ansible-and-awx.org a 2022-10-20-como-migrar-6300-equipos-a-gnu-linux-usando-ansible-y-awx