"No somos programadores, somos administradores de sistemas"
Mi cómo los tiempos han cambiado, para peor: se esperaba que una barba gris como yo fuera un mejor programador que los programadores profesionales, o de lo contrario nunca hubiera podido pasar por un administrador del sistema .
Ahora, tenemos "administradores de sistemas", que son básicamente usuarios de escritorio de Windows que en algún momento se convirtieron a Linux y no pueden programar, y no encuentran nada de malo en eso.
El elefante en la habitación es la razón por la cual la gerencia tolera una actitud tan destructiva. ¿Destructivo para quién o qué? Al negocio y a la infraestructura.
Volver al tema Puppet [, CFEngine, Chef]: tan pronto como uno establece una solución como esa, uno pierde. Todos pierden. ¿Por qué? Porque a quien se le ocurra la idea no es capaz de diseñar la gestión de la configuración encapsulada en forma de paquetes de sistema operativo Kickstart [, JumpStart, Instalador automatizado, AutoYaST, Ignite-UX, NIM] agradables y limpios. Cuando tiene que usar una herramienta de piratería automática como Puppet (o Chef, o CFEngine), significa que carece de los medios para diseñar e implementar un proceso que, por ese mismo diseño, impondría sistemas completamente impecables y apaga completamente automatizado y completamente no interactivo.
Otro punto importante es que, si tiene que tener Puppet o alguna solución similar para corregir a alguien que piratea la configuración del sistema o de la aplicación a mano, eso también se remonta a no tener la experiencia para diseñar un proceso, y en ese proceso un marco donde se empaqueta la configuración en componentes discretos. En efecto, quien implementa Puppet y similares, no tiene concepto de propietarios de componentes, lanzamientos, gestión de configuración, Modelo de madurez de capacidades. Esto se está convirtiendo rápidamente en un problema muy serio en la industria.
Trabajar con Puppet también me ayudó a aprender Ruby, que ha venido a reemplazar a Bash como mi lenguaje predeterminado de herramientas del sistema ".
¿Por qué se necesita Ruby, cuando se puede encapsular una gestión integral de la configuración de extremo a extremo en las secciones preinstalar, postinstall, preremove y postremove de los paquetes del sistema operativo, simplemente usando los programas de shell Bourne, AWK y sed? Que alguien llegue a aprender un lenguaje esotérico de Ruby, y un dialecto del mismo en el contexto de Puppet, es completamente innecesario. El problema de la gestión de la configuración se puede solucionar fácilmente (y, a saber, se ha resuelto) con programas de shell y AWK, y un poco de sed (1) aquí y allá como pegamento.
Es una sensación genial ver que su manifiesto de Puppet configura una máquina completa o un nuevo servicio desde cero.
Es aún más genial verlo hecho por Kickstart, AutoYaST o JumpStart, sin una sola línea de código , y poder consultar el sistema operativo utilizando herramientas integradas, sin necesidad de ningún software esotérico o extra , sin cliente-servidor requiere arquitectura (SSH está más que bien, mucho más que bien), y ver que su sistema operativo es consciente de todos y cada uno de los cambios que se le han hecho.
5. Código separado de los datos. Este es uno de los conceptos más difíciles de aprender. Los valores de codificación fija como Monitorear hosts en el código de su módulo son incorrectos. Ponerlos en un almacén de datos (db, yaml (Hiera usa esto por defecto), csv, lo que sea) que sus módulos pueden consumir es bueno. Un ejemplo es una aplicación web que usa Mysql. Lo que esto permite es la capacidad de insertar código y datos por separado. Esto simplifica su proceso de desarrollo.
... O bien, podría simplemente la plantilla de sus archivos de configuración con las variables de shell, incluso acentos graves (por ejemplo ls -1 ...) y escribir un script de shell que utiliza AWK para llamar a eval (1) y ampliar todas las variables en la plantilla, lo que incrementa exactamente el mismo alcance analizador que los depósitos tienen incorporado. ¿Por qué hacerlo complejo, cuando puede ser muy, muy simple? ¿Dónde guardará los valores de configuración? Por qué, en cualquier lugar que desee, como por ejemplo archivos pkginfo (4), o una base de datos como Oracle, o prácticamente en cualquier lugar . No necesita soluciones ultracomplejas. La biblioteca que menciono anteriormente simplemente podría obtenerse de las secciones previas a la instalación o posteriores a la instalación en los paquetes del sistema operativo, eliminando así la duplicación y aprovechando una pieza central de código ...
Pero, sobre todo, creo que la cita anterior es un ejemplo de la próxima generación de administradores de sistemas que necesitan tutoría no por parte de los administradores del sistema, sino por los ingenieros del sistema . Búscate una barba gris y regístrate como aprendiz.