Configuration Management
1. Introducció a l'Automatització d'Infraestructures
El Problema que Resolem
Imagina que ets l'administrador de sistemes d'una empresa que té 50 servidors. Un dia, et demanen que instal·lis una actualització de seguretat crítica a tots els servidors. Si haguessis de fer-ho manualment, hauries de connectar-te a cada servidor, executar les mateixes comandes, verificar que tot funcioni correctament, i repetir aquest procés 50 vegades. A més de ser extremadament tediós, aquest procés és propens a errors humans: potser t'oblides d'un servidor, o executes una comanda diferent en alguns servidors per error.
Ara imagina que la teva empresa creix i passa a tenir 500 servidors, o 5.000. La gestió manual es fa completament inviable. És aquí on entra en joc l'automatització d'infraestructures.
L'automatització d'infraestructures és la pràctica de gestionar i configurar servidors, xarxes i altres components d'infraestructura utilitzant codi en lloc de processos manual. Això no només estalvia temps, sinó que també garanteix la consistència, redueix errors i permet tractar la infraestructura com a codi que es pot versionar, revisar i provar igual que el codi de les aplicacions.
De Pets a Cattle: Un Canvi de Paradigma
Tradicionalment, els servidors s'han tractat com a "pets" (mascotes). Cada servidor té un nom, el coneixes personalment, quan s'emalalteix li dediques atenció especial per curar-lo, i si mor, és un drama perquè era únic i insustituïble. Amb l'automatització, els servidors passen a ser "cattle" (bestiar). Tenen números en lloc de noms, són fungibles (intercanviables), quan un s'emalalteix simplement el substitueixes per un de nou, i si mor, en crees un altre idèntic automàticament.
Aquest canvi de mentalitat és fonamental en l'era del cloud computing i l'escalabilitat. Quan pots crear o destruir servidors en segons, i quan tens centenars o milers d'ells, necessites eines que et permetin gestionar-los com a conjunt més que com a individus.
Infrastructure as Code (IaC)
Infrastructure as Code és el principi de gestionar la infraestructura utilitzant fitxers de codi que es poden versionar en un sistema de control de versions com Git. Això significa que la configuració dels teus servidors es guarda en fitxers de text que descriuen l'estat desitjat de la infraestructura. Aquests fitxers es poden compartir entre l'equip, revisar en pull requests, revertir si alguna cosa va malament, i desplegar automàticament.
Els beneficis d'IaC són nombrosos. Primer, tens un registre històric de tots els canvis en la infraestructura, sabent exactament qui va fer què i quan. Segon, pots reproduir la mateixa infraestructura en diferents entorns (desenvolupament, staging, producció) de manera consistent. Tercer, pots tractar els canvis d'infraestructura amb les mateixes bones pràctiques que el codi d'aplicació: revisió de codi, testing, integració contínua.
El Rol de Configuration Management
Configuration Management (gestió de configuració) és una categoria específica dins d'Infrastructure as Code que se centra en assegurar que els servidors mantenen un estat consistent i desitjat al llarg del temps. Les eines de configuration management et permeten definir com hauria de ser un servidor, i després asseguren que el servidor es manté en aquest estat, detectant i corregint desviacions automàticament.
Això és diferent d'eines d'aprovisionament com Terraform, que se centren en crear i destruir recursos d'infraestructura, o d'eines d'orquestració com Kubernetes, que gestionen la execució de contenidors. Configuration management se centra en la configuració i l'estat dels sistemes operatius i les aplicacions que s'executen en ells.
2. El Món de la Configuration Management
Història i Evolució
La necessitat de gestionar configuracions de servidors a escala no és nova. Abans de les eines modernes, els administradors de sistemes utilitzaven scripts de shell personalitzats, que sovint eren fràgils, difícils de mantenir i poc portables entre diferents sistemes operatius. Als anys 90 i principis dels 2000, van començar a aparèixer les primeres eines especialitzades.
CFEngine, creat el 1993, va ser un dels primers sistemes de configuration management. Més tard, al 2005, va aparèixer Puppet, que va introduir un llenguatge declaratiu més accessible. Chef va seguir el 2009, portant una aproximació basada en Ruby. Finalment, Ansible va arribar el 2012 amb una proposta radicalment més simple: sense agents, utilitzant SSH, i amb una sintaxi YAML fàcil d'aprendre.
Cada una d'aquestes eines va aportar innovacions, però totes comparteixen el mateix objectiu fonamental: permetre als administradors definir l'estat desitjat dels seus sistemes i assegurar que aquest estat es manté.
Conceptes Fonamentals Compartits
Abans d'endinsar-nos en Ansible i Puppet específicament, és important entendre alguns conceptes que són comuns a totes les eines de configuration management.
Idempotència és potser el concepte més important. Una operació és idempotent quan pot ser executada múltiples vegades sense canviar el resultat després de la primera aplicació. Per exemple, si el teu codi diu "assegura't que el paquet nginx està instal·lat", executar aquest codi una vegada instal·larà nginx, però executar-lo 100 vegades més no farà res perquè nginx ja està instal·lat. Això és fonamental perquè significa que pots executar el teu codi de configuració repetidament sense por de trencar res.
Declarativitat versus imperativitat és una altra distinció clau. En programació imperativa, describes els passos exactes per aconseguir un resultat: "executa aquesta comanda, després aquesta altra, després aquesta tercera". En programació declarativa, simplement describes el resultat desitjat: "vull que nginx estigui instal·lat i executant-se". L'eina s'encarrega de determinar quins passos són necessaris per aconseguir aquest estat. La majoria d'eines de configuration management modernes són declaratives, encara que sovint permeten elements imperatius quan és necessari.
Convergència és el procés pel qual un sistema passa de l'estat actual a l'estat desitjat. Quan executem el nostre codi de configuration management, l'eina compara l'estat actual del sistema amb l'estat desitjat que hem definit, i realitza només els canvis necessaris per convergir cap a l'estat desitjat.
Inventari és la llista de servidors (o nodes) que volem gestionar. L'inventari pot ser estàtic (un fitxer que llista els servidors) o dinàmic (generant la llista automàticament des d'una API del cloud provider, per exemple).
Agent vs Agentless
Una de les diferències més significatives entre diferents eines de configuration management és si requereixen un agent o no. Un agent és un programa que ha d'estar instal·lat i executant-se en cada servidor gestionat. Aquest agent es comunica amb un servidor central (master) per rebre instruccions sobre com configurar-se.
L'aproximació amb agents té avantatges: els agents poden informar proactivament sobre l'estat del servidor, poden executar canvis de manera regular sense intervenció externa, i poden mantenir un registre detallat de tots els canvis. Però també té desavantatges: cal instal·lar i mantenir l'agent en cada servidor, hi ha un punt addicional de fallada possible, i pot haver-hi problemes de seguretat si l'agent es veu compromès.
L'aproximació agentless, per contra, no requereix instal·lar res especial en els servidors gestionats. Normalment utilitza protocols estàndard com SSH per Linux o WinRM per Windows. Això fa la configuració inicial molt més simple, però pot ser menys eficient a gran escala i requereix que el servidor de gestió pugui connectar-se directament als servidors gestionats.