Por qué aprender aprender Chef o Puppet

Primero, es obvio que en el futuro cercano la administración de sistemas va a pasar por el manejo de herramientas de configuration management, bah, el presente se basa en este tipo de herramientas.

La administración wintel, fue pionera en realidad, y hay productos comerciales maduros para configuration management, Microsoft SCCM (System Center Configuration Manager), HP Server Automation, etc. Estos productos tienen un costo obviamente, aunque hacen un par de cosas que no hacen ni Chef ni Puppet, pero eso es para otro artículo.

Volviendo a Chef y Puppet (este último tiene una versión comercial que soporta Wintel configuration management), es obvio que el grueso de las plataformas Linux va a migrar en poco tiempo por completo al uso de herramientas de configuration management, muy probablemente Chef y/o Puppet, por ejemplo, ahora mismo se pueden bajar el detalle - menos passwords y certificados SSL - completo de cómo está configurado el stack de server de Wikipedia:

http://blog.wikimedia.org/2011/09/19/ever-wondered-how-the-wikimedia-servers-are-configured/

y pueden bajarse la configuración así:

git clone https://gerrit.wikimedia.org/r/p/operations/puppet

También pueden leer la configuración aquí https://gerrit.wikimedia.org/r/gitweb?p=operations%2Fpuppet.gitweb

Recapitulemos, aparte de aprender a configurar masivamente servers (un largo etcétera de skills laterales asociadas)

¿Para qué puede servir aprender a manejar Chef y Puppet?

Para aprender a configurar rápidamente cualquier tipo de servicios y software en Linux. Es muy simple, los cookbooks de Chef y los manifiestos de Puppet son simplemente la descripción hecha código fuente de cómo se configura un servicio o software. Si podemos leer ese código, vamos a aprender a configurar cosas mucho más rápido que de costumbre.

Los cookbooks de Chef y los manifiestos de Puppet carecen de muchas limitaciones que tienen (y siempre tuvieron) los howtos típicos que se encuentra en la red:
- No tener los nombres exactos de los paquetes o archivos
- No tener las versiones exactas del software y sistemas operativos en los que el procedimiento funciona
- Al variar versiones, locaciones y nombres, la secuencia exacta para realizar los procedimientos puede no ser clara.

En cambio, los cookbooks y manifiestos son un código fuente claro, ordenado y secuencialmente claro de cómo se configura mucho del software que existe en Linux. Hay excepciones claro, ya que en Chef y Puppet se puede manejar "dependencias/herencia" para las configuraciones, ni hablar de cuando se usa expresiones regulares en el código.

Acá tienen un ejemplo de un manifiesto en Puppet para configurar memcached (sacado del pack de manifiestos que configuran los servers de Wikipedia):

# Virtual resource for monitoring server
@monitor_group { "memcached": description => "all memcached servers" }
@monitor_group { "mc_pmtpa": description => "pmtpa memcached" }


class memcached ($memcached_size = '2000', $memcached_port = '11000', $memcached_ip = '0.0.0.0') {


        class { "memcached::config": memcached_size => "$memcached_size", memcached_port => "$memcached_port", memcached_ip => "$memcac
hed_ip" }


        package { memcached:
                ensure => latest;
        }


        service { memcached:
                require => Package[memcached],
                enable     => true,
                ensure => running;
...


Acá hay otro ejemplo para configurar Mysql:

  #######################################################################
        ### LVM snapshot hosts - currently only puppet managed in eqiad
        #######################################################################
        if $hostname =~ /^db(24|25|26|32|33|44|46|1005|1007|1018|1020|1022|1033|1035)$/ {
                $snapshot_host = true
        }


        #######################################################################
        ### Cluster Definitions - update if changing / building new dbs
        #######################################################################
        if $hostname =~ /^db(12|32|36|38|42|52|53|59|60|1001|1017|1033|1043|1047)$/ {
                $db_cluster = "s1"
        }
        elsif $hostname =~ /^db(13|24|30|54|57|1002|1018|1034)$/ {
                $db_cluster = "s2"
        }
        elsif $hostname =~ /^db(11|25|34|39|1003|1019|1035)$/ {
                $db_cluster = "s3"


...

Así que, si entendés el código, entendés como se configura, tenés las versiones donde funciona el procedimiento, los nombres de todo, paquetes, files, parámetros a configurar, indispensables y opcionales, vas viendo buenas prácticas de configuración (los sysadmin que van armando y publicado cookbooks y manifiestos los van depurando).

Y todo lo anterior es solamente un beneficio particular (..mente bueno), de implementar infraestructura como código.