Cómo matar al CMDB

Cuándo salí de un curso de ITIL hace unos años tenía la firme convicción de que tener un CMDB era la solución a todos mis problemas como líder de un equipo de administradores de sistemas. Recuerdo haber hecho comparaciones entre software variado lo cual terminó en la instalación de OTRS, el cual seguramente en otras manos hubiera tenido más éxito.

El nuevo integrante del equipo de sysadmins iba a ser la pieza clave, no sólo iba a documentar nuestros procesos sino que también iba a llenar el CMDB con toda la información sobre los servidores y aplicaciones que utilizábamos. Fue una tarea entusiasta y fallida, al poco tiempo OTRS quedó abandonado y regresamos a colocar la información en nuestro wiki, en un ciclo sin fin: el wiki se actualizaba de tanto en tanto, pero justo cuándo necesitábamos la información ésta se encontraba desactualizada, así que alguien del equipo tenía que ponerse a actualizar el wiki … y así.

En tiempos en que los servidores en la nube nacen y mueren sin ni siquiera haber hecho login, en que se despliegan aplicaciones en containers que un día están y al otro ya no, el CMDB se ha convertido en una utopía, un algo en lo cual no conviene ya perder más tiempo pues nunca podrá ser lo que queremos. ¿Cuál es la alternativa entonces? ¿cómo podemos saciar nuestra ansiedad por saber qué es lo que sucede en nuestras plataformas?

La constante en la que se mueven las infraestructuras de TI modernas es el cambio. Hoy tenemos 5 instancias en AWS y un balanceador, dentro de 15 minutos agregaremos un bucket en Google Cloud Storage y mañana daremos de baja a una de las instancias para llevarla a Azure. No es útil tener a alguien llevando la cuenta de los cambios y actualizando el wiki, el otrs o la hoja de cálculo. En cada momento , nuestra infraestructura cambia y hay una nueva versión esperando a la vuelta de la esquina.

Cambios, versiones, control de versiones. Al otro lado de la oficina, los desarrolladores actualizan constantemente las aplicaciones con nuevas versiones que se van almacenando en los repositorios del sistema de control de versiones, que administramos para ellos. Probablemente ésa sea la única alternativa a la utopía creada por ITIL: versionar nuestra infraestructura.

Entendido, entonces ¿es hora de usar ansible, chef, puppet o salt ? y comenzar a escribir toda nuestra infraestructura como si fuera código. No. O sí, pero no ahora. Lo que necesitamos es conocer nuestra infraestructura actual, y sobre esa base registrar los cambios que se produzcan pero no de una manera manual sino automatizada.

¿Qué es lo que queremos llevar al control de versiones?

  • Los proveedores de IaaS ofrecen herramientas o APIs para poder obtener la información de los servidores, dimensiones y relaciones con otros componentes como balanceadores, servidores DNS, etc. Podemos guardar esa información en un formato legible: json, csv, texto. Add, Commit y Push.
  • Sabemos dónde están las configuraciones de nuestros servidores, en Linux podemos encontrar la mayoría de las cosas en /etc , con el comando rsync podemos copiar los archivos a un repositorio central. Add, Commit y Push
  • Si usamos docker podemos ejecutar comandos sencillos para obtener listas de containers activos o imágenes por ejemplo. Add. Commit y Push.
  • Y etc.

No vamos a poder tenerlo todo, siempre faltará algo, pero eso se va mejorando en el camino. Tengan en cuenta que más que querer tener toda la información almacenada, lo que me interesa es registrar los cambios para así poder relacionarlos con otros eventos. Si la performance de nuestros servidores mejoró en un 25% es porque hace unos días se añadieron parámetros en el sysctl. Si los costos subieron es porque la semana pasada se creó un servidor de pruebas que no está siendo usado. Si la aplicación falla, es porque se actualizó la versión del PHP.

No es tan difícil, partir de un script en bash que ejecute alguna de las tareas mencionadas anteriormente cada cierto tiempo y lo envié a un repo es sencillo. Si queremos hacerlo con estilo podemos usar herramientas como Ansible para programar la obtención de datos y Jenkins para interactuar con el control de versiones, que realice la tarea de manera programada.

Cuando mi obsesión por tener un CMDB puro y duro terminó sentí un gran alivio. Lo que antes era trabajo de una persona dedicada a actualizar información que nunca puede estar actualizada ahora es parte de un cron o un job de Jenkins. Ahora veo los commits de nuestra infraestructura y sé que estás conversaciones pasarán al olvido: “¿recuerdas qué cambio hicimos hace unos meses cuando el servidor de base de datos daba este error? . Creo que es hora de actualizar nuestro CMDB”

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.