Comencé a usar Puppet antes de implementar una nueva infraestructura y simplemente compré un libro ( bien considerado ) sobre el tema. No creo que la mayoría de las personas realmente obtengan entrenamiento profesional de marionetas. Trabajé en ejemplos hasta que pude moldear el proceso a mi entorno. Esto fue en diciembre de 2011, por lo que en unas pocas semanas pude comprender los conceptos básicos y establecer un marco de producción. No era nuevo en la gestión de la configuración, tenía experiencia en CFEngine , pero muchas de las preocupaciones de sus administradores de sistemas resuenan. Cometí errores y tuve que refactorizar varias veces, pero conseguí que las cosas funcionaran satisfactoriamente.
Algunas notas sobre sus puntos ...
El rol de administración de sistemas tradicionales está cambiando. Adaptarse o quedarse atrás. He sido un ingeniero de sistemas exitoso, pero también tengo que actualizar (aprendiendo Python, por ejemplo). El enfoque en servidores individuales disminuye a medida que la abstracción de hardware a través de la virtualización y los servicios en la nube públicos y privados ganan fuerza. Esto significa la automatización de las tareas del sistema y el uso de la gestión de la configuración para arrebatar el control de un mayor número de servidores. Agregue conceptos DevOps a la mezcla y verá que las expectativas y requisitos del cliente / usuario final están cambiando.
Los módulos de títeres disponibles en línea difieren en estilo y estructura y sí, vi mucha superposición, redundancia y esfuerzos duplicados. Un desarrollador con el que trabajé dijo: "¡podrías haber desarrollado tus propias herramientas en el tiempo que pasaste buscando en línea algo que funciona!" Eso me detuvo al darme cuenta de que Puppet parece atraer más a los tipos de desarrolladores que a los administradores que buscan las mejores prácticas o el enfoque correcto .
Documente mucho para tener una idea de cómo están conectadas las cosas. Dadas las definiciones inestables y la falta de una forma estándar de hacer las cosas, la estructura de administración de la configuración es realmente única para su entorno. Esa transparencia tendrá que desarrollarse dentro.
Yo diría que es razonablemente fácil duplicar un módulo para acomodar un nuevo demonio o agregar un servicio a un manifiesto existente, dependiendo de cómo haya organizado sus servidores y roles.
Pasé mucho tiempo probando en un solo objetivo antes de enviar cambios a grupos más grandes de servidores. Ejecutar puppetd a mano en un servidor representativo me permitió depurar cambios y evaluar su impacto. Tal vez eso sea un poco conservador, pero fue necesario.
No estoy seguro de cuánto dependería de los módulos de la comunidad. Tuve que comenzar a usar Augeas para algún trabajo , y lamenté el hecho de que era una funcionalidad que daba por sentado en CFEngine.
En general, siento que no hay un estándar bien definido cuando se trata de Puppet. Tuve problemas para descubrir cómo organizar la estructura de directorios en mi Puppetmaster, comprender cómo administrar la firma de certificados, obtener el DNS inverso adecuado en todas partes, hacer que Puppet se escale de manera adecuada para el entorno y comprender cuándo aprovechar los módulos de la comunidad en lugar de construir el mío. Es un cambio de pensamiento y veo cómo eso haría que un sysadmin entrara en pánico. Sin embargo, esta también fue una solución creada desde cero, así que tuve el lujo de evaluar las herramientas. La decisión de seguir este camino se basó en el intercambio mental y el impulso detrás de Puppet. Valió la pena el esfuerzo de aprender algo nuevo.
Recuerde, este sitio también es un buen recurso.
puppetd -tpara probar en un par de cajas antes de pasar a todos los servidores. Nunca falla que una pareja tenga algo único que haga que mis actualizaciones fallen. Puppet es mucho más fácil cuando tienes un entorno controlado y consistente para el comienzo.En un trabajo anterior, me asignaron la tarea de hacer una implementación piloto de Puppet. Ahora, tengo experiencia en programación, aunque no Ruby, así que no tengo tantos problemas como otros.
Sin embargo, es interesante notar que los programadores sin experiencia con paradigmas no tradicionales también tienen problemas con Puppet, porque Puppet es declarativo , no imperativo. En este sentido, Puppet funciona casi como cualquier archivo de configuración: usted dice cómo deberían ser las cosas y Puppet se encarga del resto.
Después del piloto, tuve la oportunidad de entrenar a una docena de otros administradores con Puppet, además de dar presentaciones al respecto en dos eventos. Mi opinión de esa experiencia es que algunos administradores lo tomaron, y otros no. Todos estos eran administradores tradicionales, sin habilidades de programación y con diferentes niveles de experiencia.
Una cosa particular que noté es que Puppet requiere práctica constante . Las personas que fueron entrenadas, escribieron módulos y luego pasaron un mes o dos haciendo algo más volvieron a Puppet con poca habilidad útil. Las personas que seguían haciendo cosas pequeñas todas las semanas nunca perdieron la habilidad.
Con base en estas dos observaciones, le recomiendo que se asegure de que todos sigan agregando alguna clase, definición o módulo de Puppet cada semana (preferiblemente al menos dos o tres veces). Aquellos que aún no pueden acostumbrarse a él realmente pueden carecer de la habilidad para hacerlo.
Por otra parte, si Puppet se les impuso desde más arriba, simplemente estarían reaccionando a lo que perciben como una administración intrusa en la forma en que hacen su trabajo, lo que sería bastante cierto, de hecho. Podría darse el caso de que permitirles elegir qué sistema de administración de configuración usar mejoraría las cosas. Aquí hay algunas alternativas:
fuente
He estado usando Puppet un poco más de dos años en pequeñas tiendas donde era el único administrador de sistemas. El mayor obstáculo que he tenido es aprender a desarrollar software correctamente. No había pasado una semana en la que no arruinara algo que les dije a los desarrolladores que no hicieran una docena de veces. Registré demasiado código, no separé los registros, no etiqueté, no ramifiqué, no ejecuté el verificador de sintaxis, no usé un estándar, etc. Si recién está comenzando recomendaría algunos de los siguientes.
En resumen, he encontrado todos estos problemas y también la mayoría de mis amigos administradores de sistemas. Tomará algún tiempo ser bueno en el uso de un sistema de administración de configuración. Una vez que lo hagas, te preguntarás cómo has vivido sin uno. "¿Iniciar sesión en un servidor y hacer cambios manualmente? Ick".
fuente
Parece una buena idea comenzar temprano: Puppet es más que una simple gestión de configuración, es una forma de documentación.
Necesitan un ajuste de actitud.
De nuevo, actitud. Usted puede hacer un archivo conf para un servidor, ¿verdad? Puede facilitar las tareas de creación de plantillas / 'programador' a medida que evolucionan sus necesidades y complejidad .
Difícil de responder: siempre prefiero los módulos de puppetlabs a la mayoría, y aun así, no uso tantos. Sentencia de seguro. En mi opinión, algunos módulos son "demasiado con volantes".
Esto no parece un problema de títeres, sino más bien un problema de organización o documentación.
Ese demonio podría ser una clase si es lo suficientemente simple de administrar. No estoy seguro de lo que quieres decir con convenciones, la marioneta impone convenciones sobre ti bastante bien, ¿no? ¿O estamos hablando de líneas de formato de código?
No es una mala idea si lo tomas con calma y seguridad. Todavía comenzaría con una VM para entender la esencia de las cosas.
postfix, exim, sendmail, mysql, postgresql, iftop, iptraf, perl, perl modules ... ¿Elige lo que quieres y úsalo? Supongo que esto suena más como una actitud de actitud otra vez ...
No he asistido a ningún curso, aunque soy un programador más que un administrador de sistemas, descubrí que no necesitaba mucha habilidad de programación para lograr algo.
La documentación de Puppet, cuando se sigue, es bastante completa. Solo preste atención a los tipos incorporados y pase un tiempo mirando cómo se combinan otros módulos. No diría que es -súper- fácil, pero tampoco es -duro-. Preparar su infraestructura para títeres requiere un poco de tiempo, pero se garantiza que el tiempo invertido se empleará bien cuando se expanda.
fuente
BESO (Mantenlo simple y estúpido): no utilices las nuevas tecnologías solo porque están allí, sino porque tienes un requisito para ellas, usa el mínimo necesario que requiere tu implementación, actualiza según sea necesario, no intentes mantenerte al día con el sangrado borde. Si comienza con una configuración básica y se basa en eso, es más fácil recogerlo a medida que avanza, y no deberían necesitar un curso (¿están incluso disponibles?).
La otra área que puede ver son sus administradores de sistemas. Si no pueden programar tan bien, ¿están lo suficientemente avanzados para una implementación grande, donde la mayor parte del trabajo necesita ser programada, independientemente de las herramientas que use?
fuente
También trabajo para una organización sin fines de lucro y fui responsable de llevar inicialmente las cajas de Linux a casa y poco después Puppet para administrarlas. Hemos hecho un par de cosas específicas que realmente han ayudado a poner las cosas en marcha.
En primer lugar, he tratado de mantenerme alejado de los módulos de terceros. Las herramientas incorporadas manejan el 90% de nuestra gestión. La mayor utilidad de terceros que uso es el módulo de firewall. Cualquier hecho personalizado, etc., se desarrolla con todo el equipo involucrado. Desarrollamos un módulo de plantilla y mantenemos la gestión de archivos, paquetes, servicios, etc., todo estandarizado fuera de esta plantilla.
En segundo lugar, después de estandarizar el uso de los módulos incorporados, comenzamos a usar Git y el Crucible de Atlassian, por cierto, sin fines de lucro, para realizar revisiones de todos los cambios de configuración. Esto proporciona la transparencia deseada.
En tercer lugar, automaticé la configuración de Puppet para que los nuevos hosts se puedan agregar automáticamente con un conjunto predeterminado de opciones. Hay varias formas de abordar esto. Como ya tenía un entorno Kickstart completo, opté por agregar un script allí.
fuente
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.
¿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 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.
... 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.
fuente