Archivo
Configuration Management: Puppet
De entre las tareas más tediosas de la puesta en servicio se encuentran la actualización y configuración de los diferentes entornos. Estas tareas requieren la preparación de equipos con mucha experiencia y conocimiento tanto de los entornos técnicos como de lo entornos organizativos en que nos movemos. Pero una vez materializado ese conocimiento son tareas repetitivas y largas, y por lo tanto, muy propensas a error. Además de documentar y actualizar muy bien la situación de los entornos, es imprescindible automatizar estas tareas. No ya solo para evitar errores, sino también para escalar e igualar cuando el conjunto de entornos sea muy numeroso.
Para esta finalidad existen muchas soluciones. De las más conocidas en el mundo Open Source:
Todas son soluciones y basadas en código abierto (licencias Apache y GPL según cada caso), pero con una versión o servicio más completo de pago (modelo Freemium). Las más extendidas son las dos primeras, en especial Puppet que es la que tiene una comunidad más extensa, y por lo tanto una cobertura con módulos de sistemas y entornos mayor.
Puppet tiene un lenguaje de configuración propio basado en Ruby (aunque también permite el uso de Ruby directamente). La primera particularidad es que Puppet recibe una configuración de entorno final o definitiva y se encarga de decidir qué pasos tomar para llegar a ella; nosotros no definimos los pasos, sino el objetivo. Esto nos permite aplicar la misma configuración a entornos con configuraciones distintas, Puppet se encargará de igualar los diferentes entornos. Estas configuraciones son lo que Puppet llama Manifiest y se materializan en ficheros .pp.
Los ficheros .pp contienen descripciones de recursos. Cada recurso es una estructura con tipo, título y atributos que describe el estado final de un cierto elemento de configuración del entorno donde se aplica el manifiesto. Los recursos tienen una tipología propia y una estructura en clases para abarcar el conjunto de elementos o aspectos configurables en un entorno (servicios, ficheros, parametrizaciones del sistema…). Estas tipologías pueden extenderse con módulos específicos para cada elemento de software configurable (la lista se encuentra aquí). Los atributos son los valores que describen la configuración de dicho recurso. El título es el atributo que identifica al recurso de entre los de su clase (en el ejemplo: el path del fichero o el nombre del servicio). El siguientes es un ejemplo de manifiesto para la configuración de un Apache:
class apache {
package {
apache:
ensure => installed
}
file {
"httpd.conf":
mode => 644,
owner => root,
group => root,
path => "/etc/apache2/httpd.conf",
source => "puppet://modules/files/httpd.conf",
}
service {
apache2:
ensure => true,
enable => true,
subscribe => [File["httpd.conf"], Package[apache]],
}
}
En el manifiesto anterior el estado final de configuración es aquél en el que se ha instalado el paquete de Apache, se ha copiado el fichero de configuración del repositorio de Puppet (se puede utilizar cualquier otra localización) y se ha habilitado el servicio. Nótese que el atributo, en este caso metaatributo, subscribe indica que el recurso servicio va a ser informado de los cambios que se produzcan en los otros dos recursos; de esta manera se puede establecer orden o dependencia entre ellos. Los manifiestos pueden gestionar variables, variables de entorno, así como hacer uso de estructuras de control o de dependencia u orden.
Puppet puede instalarse con una estructura de agente y maestro, donde el maestro o maestros gestionan la configuración de los agentes, que están en los entornos configurables y que toman (pull) los cambios de los maestros. O bien, como un maestro independiente, que gestiona de manera autónoma el entorno en que se encuentra. Las consultas y aplicaciones de configuraciones se hacen mediante el comando puppet del símbolo del sistema, aunque la versión Enterprise tiene una UI que facilita estas operaciones.
En las referencias incluyo el enlace a la documentación de Puppet (bastante completa en mi opinión), por si quieres conocer más acerca de él.
Referencias
Comparativa en Wikipedia
Review en InfoWorld
Introducción a Puppet en Puppet Labs
La foto ha sido tomada de aquí, bajo licencia CC
Esta entrada de Juan Francisco Adame Lorite está publicada bajo una licencia Creative Commons Atribución-CompartirIgual 3.0 Unported.
Tiempo y zonas horarias en aplicaciones
Siempre me he encontrado con la duda de qué estándar de tiempo utilizar en mis aplicaciones o si debo hacer uso de manera explícita del uso horario o no. Así que he decidido analizar el asunto.
Empecemos distinguiendo los estándar de tiempo de las zonas horarias:
- Los estándar de tiempos son los convenios establecidos para la medición de duración de tiempos o el establecimiento puntual de eventos en el tiempo. Es muy importante saber para qué vamos a utilizar o para qué necesitamos la medición de tiempos en cuestión. No es lo mismo que queramos definir momentos concretos en el tiempo, bien pasado o futuro; o medir duración de tiempo entre momentos específicos. Para cada caso nos convendrá un estándar u otro.
- Los husos o zonas horarias o tiempos civiles son los tiempos definidos de manera legal en un territorio. Toman como referencia un estándar de tiempo (hoy en día UTC) y difieren de este un tiempo definido según el meridiano de la región. Pueden adoptar o no, cambios por horario de verano.
A continuación veamos los tipos de estándar de tiempo:
- Estándares de tiempo basados en la rotación de la Tierra. Son aquellos en los que la posición astronómica de la Tierra y su medición indican cada momento puntual de tiempo o la duración del mismo.
- GMT (Greenwich Mean Team). Fue el primero en establecerse. Se sincroniza con la hora medida en el Real Observatorio de Greenwich (a las afueras de Londres) que coincide con el meridiano 0 o de Greenwich. Se calcula mediante la duración media del día medida entre dos pasos del Sol por el meridiano. Fue sustituido por UTC desde 1972. Por cierto, las Islas Británicas solo coinciden con GMT durante el invierno.
- UT (Universal Time). Definido con posterioridad a GMT, pero con su misma filosofía. Su medición, sin embargo, se basa en el posicionamiento diurno de las estrellas y no del Sol, lo que lo hace más exacto. Existen varios UT: UT0, UT1, UT1R y UT2. UT0 es la versión que más se ciñe a la definición de UT. UT1, es el más usado y en el que se basa UTC, incluye sobre UT0 las variaciones debidas al movimiento del eje de rotación de la Tierra. UT1R incluye las variaciones debidas a las mareas. UT2 es un suavizado periódico de UT1.
- Estándares de tiempo construidos. Son aquellos que se sincronizan mediante eventos de duración definida:
- TAI (International Atomic Time). Estándar de tiempo desde 1972 para la definición del segundo. Se creó para evitar las derivas de tiempos y las irregularidades propias de la rotación y traslación de la Tierra. El tiempo TAI se calcula mediante la sincronización de cerca de relojes atómicos en todo el mundo. Difiere de UTC en un número definido de segundos (los segundos intercalares añadidos o restados hasta la fecha desde su establecimiento).
- UTC (Coordinated Universal Time). Es el estándar de tiempo más utilizado. Está basado en el TAI pero con una diferencia de segundos definida y conocida. Estos segundos son los segundos intercalares añadidos o restados (hasta la fecha siempre se han añadido) para evitar que la hora UTC no difiera de la hora UT1 de Greenwich más de 0,9 segundos.
- GPST (GPS Time). Utilizado por el sistema de posicionamiento GPS. Está retrasado sobre TAI de manera constante 19 segundos. El mensaje de posicionamiento GPS incluye el número de segundos intercalares con UTC, para que las unidades GPS puedan calcular la hora UTC.
- Estándares de tiempo basados en el movimiento de planetas. Son aquellos en los que la posición y el movimiento de los plantas indican cada momento puntual de tiempo o la duración del mismo. El más utilizado era el Tiempo de Efemérides, calculado a partir de la traslación de la Tierra alrededor del Sol, ya en desuso debido a que no tenía en cuenta las tesis relativistas del tiempo. Hoy en día existen otros que sí tienen en cuenta estos factores, como el Terrestrial Time que sustituyó al Tiempo de Efemérides.
Conclusiones
De manera general, podemos decir que el estándar de tiempo más apropiado a utilizar es UTC para el almacenamiento de información temporal. Formateando o capturando la información para adaptarla a la zona horaria del usuario en el momento de su procesado. Todos las zonas horarias están referenciadas a este estándar y la conversión hacia o desde estas es inmediata.
Sin embargo cuando queramos calcular duraciones de tiempo a futuro con precisión, no podremos utilizar UTC, ni cualquier otro sistema basado o sincronizado en cálculos astronómicos; puesto que no podemos conocer las variaciones de tiempo o segundos intercalares que se aplicarán a futuro a un estándar de tiempo. En ese caso es preferible utilizar TAI. Esta observación no aplica para el procesado de fechas: el evento en cuestión seguirá ocurriendo en dicho momento con independencia de las variaciones.
El almacenamiento y cálculo de tiempos y fechas con zonas horarias aplicadas no puede considerarse una buena práctica. En primer lugar, las zonas horarias con cambio de horario en verano no son causales (un evento posterior a otro puede aparecer como anterior si entre medias se produce el cambio de horario de otoño, el retraso de una hora), lo que dificulta el cálculo de duraciones de tiempo.En segundo lugar, dificulta la internacionalización de soluciones o la compartición de diferentes ámbitos regionales en una solución (aplicación usada en países con diferentes zonas horarias o usuarios que viajan entre zonas horarias); sobre todo si no se ha tenido en cuenta en el diseño inicial de la solución. El argumento de la mejora de rendimiento no suele ser válido para defender esta posibilidad tampoco, puesto que los cálculos para el cambio de zonas horarias de tiempos son inmediatos (por lo general, suma de un número entero de horas).
Hasta Windows 2000 los sistemas Windows almacenaban la hora local referenciada a la zona horaria establecida en el equipo o usuario. Desde Windows 2000 y en los sistemas UNIX-like, se almacena UTC (aunque se formatee a la zona horaria del usuario cuando se muestra).
Referencias
La foto está sacada de aquí.
Time Standard en Wikipedia
GMT vs UTC
Esta entrada de Juan Francisco Adame Lorite está publicada bajo una licencia Creative Commons Atribución-CompartirIgual 3.0 Unported.
Bytes & Chips 