Manejando los hilos de nuestra infraestructura IT
El viernes pasado tuve la oportunidad de participar como orador en las 6tas Conferencias Abiertas de Software Libre de Capital Federal, organizadas por CaFeLUG, y lo que me permitieron exponer en esta ocasión es una herramienta que vengo mirando de hace relativamente poco tiempo, pero que me interesa muchísimo: Puppet.
La administración de servidores involucra variadas tareas, desde la elección de hardware para un nuevo servidor, la instalación del sistema operativo, aplicaciones, su configuración, pruebas y puesta en producción, para luego terminar con el mantenimiento de dicho servidor, que puede incluir más tareas como por ejemplo: actualización periódica del software instalado, la corrección de mínimos errores que podamos haber tenido en la configuración inicial, el agregado de pequeñas herramientas que nos ayudan a mantener los servicios funcionando, copias de respaldo de datos, y quizás también del sistema base… la lista continúa pero creo que la idea está planteada: Administrar servidores no es una tarea simple.
A medida que sumamos servidores a nuestra carga administrativa, cada uno con sus peculiaridades, servicios diferentes, configuraciones personalizadas, etc. nos vemos más y más inmersos en un problema latente:
- Nuestra carga horaria necesaria para tener todo funcionando es cada vez mayor, ya que por cada servicio en cada servidor, los problemas que aparecen son únicos y muy pocas veces se repiten en otros casos. Esto significa que con casi cualquier problema que surge, el tiempo que tenemos que dedicarle a la investigación y resolución del mismo es tanto como el tiempo que le vamos a tener que dedicarle al siguiente, y así.
- Por más minuciosos que seamos, las soluciones que aplicamos en un servidor hace 1 año serán distintas a las que utilicemos en la implementación de servidores hoy en día, por más que la funcionalidad de ellos sea similar. Día a día pulimos métodos, mejoramos algoritmos, aprendemos nuevas formas de hacer lo mismo que nos ahorran tiempo, y todo eso lo aplicamos a los servicios que tenemos a cargo, pero actualizar esos métodos en servidores donde los tenemos funcionando en alguna manera hoy antigua, es o bien muy costoso o simplemente imposible. En consecuencia: los métodos que utilizamos a través de los años quedan dispersos en la línea temporal que forman los equipos generados por nosotros.
- ¿Y que me cuentan de la gestión de software? Habíamos visto que parte de nuestras tareas era la de mantener actualizado el software instalado en los equipos. Si bien hay administradores que tienen como política la frase “Si funciona, no lo toques”, yo creo que si la distribución te ofrece la estabilidad y confianza suficientes como para saber que las actualizaciones de seguridad no te van a romper nada, el actualizar es una necesidad, no sólo en los servidores expuestos a redes públicas como Internet. ¿Qué pasa cuando tenemos que actualizar 10 servidores? ¿Y cuando son 100? ¿Qué pasa cuando tenemos que instalar un nuevo software en 10, 50, o 100 servidores? Nos arremangamos, respiramos hondo, y o bien planeamos los siguientes 2 meses implementando el mismo software una y otra vez, o descartamos nuestros preciados fines de semana para acelerar el paso. De más está decir que si en vez de servidores hablamos de estaciones de trabajo…se complica un poquito más la cosa.
- A medida que la infraestructura aumenta de tamaño, vamos necesitando gente que nos ayude. Si las políticas administrativas no están estandarizadas de alguna manera, lo único que haremos es sumar un ancla más sobre nuestro pescuezo, ya que las nuevas personas tendrán sus propios criterios y formas de hacer las cosas, multiplicando la variedad en la que los problemas son solucionados y por lo tanto, haciendo cada vez más necesaria gente altamente capacitada para el mantenimiento. De más está decir que es difícil conseguir gente con mucha experiencia que esté interesada en mantener un verdadero caos, ¡ellos tienen mejores cosas que hacer de su vida, y vos también deberías!
En mi haber tengo casi 10 años de experiencia en la administración de servidores, y esto sólo lo digo para recalcar el hecho que las problemáticas arriba expresadas sólo se hicieron evidentes cuando ya era tarde, cuando tenía encima casi 40 servidores, todos configurados artesanalmente y cada uno con sus peculiaridades. Ni yo me acuerdo de todos los detalles que hay ocultos en cada servicio que todas esas máquinas dieron. Si alguien me hubiera advertido, es probable que haya empezado a planear una estandarización temprana que me hubieran permitido administrar 400 servidores sin mayores problemas.
Aquí es cuando entra Puppet al rescate, ésta es una herramienta que nos ayuda solucionar los problemas antes mencionados. Puppet tiene varios componentes, entre ellos se encuentra el servidor, que distribuye las recetas que los clientes deben aplicar en cada servidor. Y ya que hablamos de recetas, éstas están escritas en un lenguaje declarativo, es decir, un lenguaje que expresa el estado de cómo debería estar el servidor, sin caer en una receta paso a paso para llegar a ese estado. Una receta en Puppet se refiere entonces a recursos, y su estado en el equpo, como por ejemplo: el paquete vim debe estar instalado y debe ser el editor por defecto, entonces Puppet se encarga que esto sea aplicado, ya sea en un Debian, un Redhat, Ubuntu o SuSE, nosotros nos olvidamos de los detalles menores.
Este alto nivel de expresión nos permite escribir recetas que luego podemos compartir con otros colegas, tal cual el software libre! esto es algo que muy pocas veces se ha hecho ya que las herramientas que los administradores de sistemas realizamos son normalmente muy ad hoc, poco portables a otros entornos.
Entre los recursos que Puppet nos permite administrar, están los paquetes de software, archivos y directorios, usuarios, tareas de cron, etc. y además como la herramienta está escrita en el lenguaje Ruby, es fácilmente extensible para agregar nuevos recursos.
El caso ideal luego de haber aprendido esta herramienta, sería que con cada servidor nuevo, lo único que haya que instalar sea el sistema base, el cliente Puppet, y luego éste se encarga del resto, manteniendo el estado que se expresa en las recetas a rajatabla, chequeando que se cumplan cada tanto, y nosotros mientras tanto pudiendo regresar a casa temprano, olvidandonos que estamos de guardia y que de un momento a otro, el celular podría sonar por algún incendio.
Les dejo disponible los slides de mi charla por si les sirve de algo.
1 comment October 11th, 2007
