Pregunta ¿Cómo pueden los pequeños aprender y usar efectivamente Títere? [cerrado]


Hace seis meses, en nuestro proyecto sin fines de lucro, decidimos comenzar a migrar nuestra administración de sistemas a un ambiente controlado por Puppet porque esperamos que nuestro número de servidores crezca sustancialmente de aquí a un año.

Desde que se tomó la decisión, nuestros muchachos de TI se han vuelto un poco demasiado molestos con demasiada frecuencia. Sus mayores objeciones son:

  • "No somos programadores, somos administradores de sistemas";
  • Los módulos están disponibles en línea, pero muchos difieren entre sí; las ruedas se reinventan con demasiada frecuencia, ¿cómo decide cuál se ajusta a la factura?
  • El código en nuestro repositorio no es lo suficientemente transparente, para descubrir cómo funciona algo que tienen que responder a través de manifiestos y módulos que incluso podrían haber escrito hace un tiempo;
  • Un nuevo daemon requiere escribir un nuevo módulo, las convenciones deben ser similares a otros módulos, un proceso difícil;
  • "Vamos a ejecutarlo y ver cómo funciona"
  • Toneladas de 'extensiones' apenas conocidas en los módulos de la comunidad: 'trocla', 'augeas', 'hiera' ... ¿cómo pueden hacer un seguimiento nuestros administradores de sistemas?

Puedo ver por qué una gran organización enviaría a sus administradores de sistemas a los cursos de Títeres para convertirse en maestros de títeres. Pero, ¿cómo podrían los jugadores más pequeños aprender Puppet a un nivel profesional si no asisten a los cursos y básicamente lo aprenden a través de su navegador y editor?


106
2018-06-06 08:38


origen




Respuestas:


Comencé a usar Puppet antes de implementar una nueva infraestructura y simplemente compré un (bien considerado) libro sobre el tema. No creo que la mayoría de la gente realmente obtenga entrenamiento profesional de Títeres. Trabajé en ejemplos hasta que pude moldear el proceso a mi entorno. Esto fue en diciembre de 2011, así que en unas pocas semanas, pude entender los conceptos básicos y establecer un marco de producción. No era nuevo en la gestión de la configuración, teniendo un CFEngine antecedentes, 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 tus puntos ...

  • El rol tradicional de administración de sistemas está cambiando. Adaptar o quedarse atrás. He sido un exitoso ingeniero de sistemas, pero también tengo que cambiar la configuración (por ejemplo, aprendiendo Python). El enfoque en servidores individuales disminuye a medida que la abstracción del hardware a través de la virtualización y los servicios de nube públicos y privados ganan terreno. Esto significa la automatización de las tareas de los sistemas y el uso de la administración de la configuración para controlar el control de un gran número de servidores. Añadir Conceptos devOps a la mezcla, y verás que el expectativas del cliente / usuario final y los requisitos están cambiando.

  • Los módulos de Puppet 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 dio una pausa cuando me di cuenta de que Puppet parece apelar más a los tipos de desarrolladores que a los administradores que buscan un mejores prácticas o la manera correcta enfoque.

  • Documente en gran medida para tener una idea de cómo están conectadas las cosas. Dadas las definiciones inestables y la falta de un estándar De esta manera, su estructura de gestión de la configuración es realmente única para su entorno. Esa transparencia tendrá que ser desarrollada dentro.

  • Argumentaría que es razonablemente fácil duplicar un módulo para acomodar un daemon nuevo 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. La ejecución de puppetd a mano en un servidor representativo me permitió depurar los 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 Empieza a usar Augeas para un poco de 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 averiguar cómo organizar la estructura de directorios en mi Puppetmaster, entender cómo administrar la firma de certificados, obtener DNS inverso adecuado en todas partes, consiguiendo títeres para escalar adecuadamente para el medio ambiente y la comprensión de cuándo aprovechar los módulos de la comunidad en lugar de construir los míos. Es un cambio en la forma de pensar y veo cómo eso causaría pánico a un administrador de sistemas. Sin embargo, esta también fue una solución creada desde cero, por lo que tuve el lujo de evaluar herramientas. La decisión de ir por este camino se basó en la mentalidad y el impulso detrás de Puppet. Valió la pena el esfuerzo de aprender algo nuevo.

Recuerda, este sitio También es un buen recurso.


101
2018-06-06 09:02



Pasé de no tener experiencia en Puppet a tener mi entorno completo administrado en dos semanas planas. Soy responsable de ~ 40 máquinas virtuales, aunque todas ejecutan Ubuntu. Eso simplificó las cosas un poco. Soy un desarrollador de profesión. "Adaptar o quedarse atrás": ahora soy devops + sysadmin + architect. Excelente respuesta! - François Beausoleil
Los recomendaría para comenzar a implementar pequeños servicios, primero en forma independiente y luego comenzar a jugar con más servidores. No tengo que trabajar con Puppet, pero tengo un pequeño VPS y recientemente hice mis propios módulos Puppet. Si quieren mantenerse al día con el resto de administradores de sistemas en el siglo actual, es mejor que tengan una mentalidad abierta. Lo hago porque me gusta, y creo que no a todos les gusta aprender cosas nuevas, pero una cosa es segura, hoy en día los administradores de sistemas están más cerca que nunca de los desarrolladores. - Sergio Galvan
Trabajo en una pequeña empresa y también dirijo. puppetd -t para 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 principio. - jordanm
@ewwhite, he trabajado en el tutorial de Puppet en sus documentos, pero me preguntaba qué libro usaste cuando aprendías. Siento que el tutorial proporcionado en los documentos faltaba algo que impide que todo haga clic conmigo mientras trabajo con Puppet en los anfitriones de prueba para saber lo que estoy haciendo. EDITAR: O cualquier recurso adicional que pueda recomendar. Gracias. - Mike Keller
@MikeKeller me gustó en mi post ... Pero es disponible aquí. - ewwhite


En un trabajo anterior, me asignaron la tarea de hacer una implementación piloto de Puppet. Ahora, tengo experiencia en programación, aunque no en Ruby, así que no tengo tantos problemas como otros.

Sin embargo, es interesante observar que 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 administradores con Puppet, además de hacer presentaciones al respecto en dos eventos. Mi experiencia a partir de esa experiencia es que algunos administradores lo tomaron, y otros no. Estos eran todos los administradores tradicionales, sin conocimientos de programación y diferentes niveles de experiencia.

Una cosa en particular que noté es que Puppet requiere constante práctica. Las personas que fueron capacitadas, escribieron módulos y luego pasaron uno o dos meses haciendo otra cosa, volvieron a Títere con poca habilidad útil. Las personas que seguían haciendo pequeñas cosas cada semana nunca perdían la habilidad.

Sobre la base de estas dos observaciones, te recomiendo que te asegures de que todos sigan agregando alguna clase, definición o módulo de Puppet todas las semanas (preferiblemente al menos dos o tres veces). Aquellos que todavía no pueden acostumbrarse a esto pueden carecer de la habilidad para hacerlo.

Entonces, nuevamente, si se les impusiera Puppet desde lo alto, podrían estar reaccionando simplemente a lo que perciben como una administración intrusa en la forma en que hacen su trabajo, lo que de hecho sería lo suficientemente cierto. Podría ser el caso que les permita elegir. cual sistema de gestión de configuración para utilizar mejoraría las cosas. Aquí hay algunas alternativas:

  • ANSIBLE: Esto es nuevo, pero se basa en comandos de shell y ssh, lo que podría atraerlo a los administradores de sistemas tradicionales.
  • Cocinero: Tal vez su problema sea el estilo declarativo, en cuyo caso Chef sería mejor si tuvieran experiencia con Ruby.
  • SaltStack: Basado en Python, y de código abierto
  • CFEngine: viejo, rápido, tradicional - podría ganarles en esos terrenos.

29
2018-06-06 15:59



Lo bueno de ANSIBLE es que funciona a través de distancias galácticas sin ninguna demora en la transmisión de datos. - Kalamane
Gracias por la mención ANIBLE No me había dado cuenta hasta ahora. - ewwhite
@ewwhite de nada. Yo mismo lo he descubierto recientemente, pero mucho me llamó la atención. Si ya no tuviéramos mucho en Puppet, definitivamente lo probaría. - Daniel C. Sobral


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 el software correctamente. No había pasado una semana en la que no haya arruinado algo que les he dicho a los desarrolladores que no hagan una docena de veces. Verifiqué demasiado código, no separé los registros, no etiqueté, no bifurqué, no ejecuté el verificador de sintaxis, no usé un estándar, etc. Si está empezando Fuera recomiendo algunos de los siguientes.

  1. Date cuenta de que estás desarrollando un software que, o bien no sabes hacer, o te está yendo mal. Esto se espera porque es nuevo.
  2. La infraestructura como código es la realidad y una vez que se supera la joroba es bastante poderosa. Invitaría a algunos desarrolladores, les mostraría tu proceso de desarrollo actual (o la falta de él), no te ofendas cuando te llamen la atención y tomen en serio sus sugerencias. Recomendaría usar cualquier sistema y proceso que usen sus desarrolladores a menos que sea completamente inapropiado.
  3. Los módulos de títeres de terceros chupan el 90% del tiempo. Los leia Les robaría ideas. No los incorporaría a mi sistema sin modificaciones importantes. Sin embargo, me gustaría tirar en el títere títere que agrega alguna funcionalidad agradable.
  4. augeas y hiera. Aprende esos dos. El primero permite la edición compleja de los archivos existentes en su lugar. El segundo es un almacén de datos externo.
  5. Código separado de los datos. Este es uno de los conceptos más difíciles de aprender. Los valores de codificación, como los hosts de monitorización en el código de su módulo, son malos. Ponerlos en un almacén de datos (db, yaml (Hiera usa esto por defecto), csv, lo que sea) que sus módulos puedan 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 hace que su proceso de desarrollo sea más simple.
  6. analizador de títeres validar y pelusa marioneta Como parte de su proceso de registro de código anterior o posterior. También las pruebas rspec pueden ser una buena idea una vez que esté al día.
  7. escribe una guía de estilo / código estándar y úsala. "dónde está el código que instala Apache" es un problema común. Si sus módulos son casi iguales, debería ser fácil.

En resumen, resolví todos estos problemas y también la mayoría de mis amigos de administrador de sistemas. Tomará algo de tiempo mejorar el uso de un sistema de administración de configuración. Una vez que lo hagas, te preguntarás cómo has vivido sin él. ¿"Iniciar sesión en un servidor y hacer cambios manualmente? Ick".


11
2018-06-06 18:04



Gracias por sus sugerencias, especialmente augeas y hiera son dos componentes que hemos comenzado a implementar y esto nos hizo mucho más conscientes, incluso confiados en las capacidades de Puppet. Así que gracias :-) - drumfire


Hace seis meses, en nuestro proyecto sin fines de lucro, decidimos comenzar   Migración de la gestión de nuestro sistema a un entorno controlado por Puppet.   porque esperamos que nuestro número de servidores crezca sustancialmente   entre ahora y un año a partir de ahora.

Suena como una buena idea para comenzar temprano: Puppet es más que solo la administración de configuraciones, es una forma de documentación.

Desde que se tomó la decisión, nuestros chicos de TI se han vuelto un poco demasiado   molesto un poco demasiado a menudo.

Necesitan un ajuste de actitud.

"We're not programmers, we're sysadmins";

De nuevo, la actitud. Usted puede hacer un archivo conf para un servidor, ¿verdad? Puede acomodar las cosas de creación de plantillas / 'programadores' según sus necesidades y complejidad evoluciona.

Los módulos están disponibles en línea, pero muchos difieren entre sí; ruedas   se reinventan con demasiada frecuencia, ¿cómo decidir cuál encaja en el   cuenta;

Una respuesta difícil, siempre prefiero los módulos de puppetlabs sobre la mayoría, e incluso así, no uso tantos. Llamada del juicio seguro. En mi opinión, algunos módulos son "demasiado caros".

El código en nuestro repositorio no es lo suficientemente transparente, para encontrar cómo funciona algo que tienen que responder a través de manifiestos y módulos que podrían   Incluso se han escrito hace un tiempo;

¿Esto no suena como un problema de títeres, pero más que un problema de organización o documentación?

Un nuevo daemon requiere escribir un nuevo módulo, las convenciones deben ser   Similar a otros módulos, un proceso difícil;

Ese daemon podría ser una clase si es lo suficientemente simple de manejar. No estoy seguro de lo que quieres decir con convenciones, títere aplica convenciones sobre ti bastante bien, ¿no es así? ¿O estamos hablando a lo largo de las líneas de formato de código?

"Let's just run it and see how it works"

No es una mala idea si lo tomas lento y seguro. Todavía comenzaría con una máquina virtual para obtener la esencia de las cosas.

Toneladas de 'extensiones' apenas conocidas en los módulos de la comunidad: 'trocla',   'augeas', 'hiera' ... ¿cómo pueden nuestros administradores de sistemas realizar un seguimiento?

Postfix, exim, sendmail, mysql, postgresql, iftop, iptraf, perl, perl módulos .. Elige lo que quieres y úsalo? Supongo que esto suena más como una cosa de actitud otra vez ...

Puedo ver por qué una gran organización enviaría a sus administradores de sistemas a   Cursos de marionetas para convertirse en maestros de marionetas. Pero como lo harían los jugadores más pequeños.   aprender a Puppet a un nivel profesional si no van a   ¿Cursos y básicamente lo aprendes a través de su navegador y editor?

No he asistido a ningún curso, mientras que a.m un programador más que un administrador de sistemas, descubrí que no necesitaba mucha habilidad de programación para lograr nada.

La documentación de Títeres, cuando se sigue es bastante completa. Solo preste atención a los tipos incorporados y dedique un tiempo a observar cómo se combinan otros módulos. Yo no diría que es fácil, pero tampoco es difícil. Tomar un poco de tiempo para preparar su infraestructura para títere, pero se asegura que el tiempo invertido estará bien empleado cuando se expanda.


7
2018-06-06 14:04



Para su información, esto viene de alguien que acaba de preparar su infraestructura para comenzar. Así que tengo una experiencia nueva y no puedo decir que fue una pérdida de tiempo. - thinice
Como iniciador reciente, me reconozco por completo en tu comentario. - Martijn Heemels
En mi caso, un cambio de actitud era ciertamente necesario. A Ops le encanta la automatización y, a menudo, escribir cosas, por lo que se trata principalmente de usar diferentes herramientas. Es una sensación genial ver a su manifiesto de Puppet configurar una máquina completa o un nuevo servicio desde cero. El hecho de que un error pueda afectar a varias máquinas a la vez requiere acostumbrarse a pruebas más rigurosas, lo que puede ser molesto, pero obviamente es algo bueno. Experimente con Vagrant, rspec-puppet, puppet-lint, Geppetto, Git sucursales y otras herramientas gratuitas y pronto descubrirá su flujo de trabajo favorito. - Martijn Heemels
Trabajar con Puppet también me ayudó a aprender Ruby, que viene a reemplazar a Bash como mi lenguaje predeterminado de herramientas del sistema. - Martijn Heemels


KISS (Manténlo simple, estúpido): no uses las nuevas tecnologías solo porque están ahí, sino porque tienes un requisito para ellas, usa lo mínimo que requiere tu despliegue, actualiza según sea necesario, no trates de mantenerte al día con el sangrado borde. Si comienza con una configuración básica y se basa en que es más fácil de recoger a medida que avanza, y no deberían necesitar un curso (¿están incluso disponibles?).

La otra área que puedes ver son tus administradores de sistemas. Si no pueden programar también, ¿son lo suficientemente avanzados para una implementación grande, donde la mayoría del trabajo debe tener secuencias de comandos, independientemente de las herramientas que use?


5
2018-06-06 09:18



... porque esperamos que nuestro número de servidores crezca sustancialmente entre ahora y un año a partir de ahora. ¿Requisito? - Jeff Ferland
Realmente depende de qué tan cierta sea esa expectativa y si lo que usted implementa seguirá siendo adecuado para cuando surja la necesidad. - JamesRyan
+1 para "usar lo mínimo que requiere su despliegue": muchos de los problemas de títeres que encontré se derivan de intentar que el títere controle todo el sistema. - Sirex


También trabajo para una organización sin fines de lucro y fui responsable inicialmente de llevar las cajas de Linux en casa y poco después Puppet para administrarlas. Hay un par de cosas específicas que hemos hecho que tenemos De Verdad ayudó 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 utilizo es el módulo de firewall. Cualquier información personalizada, etc., se desarrolla con todo el equipo involucrado. Desarrollamos un módulo de plantilla y mantenemos la gestión de archivos, paquetes, servicios, etc. estandarizados fuera de esta plantilla.

En segundo lugar, después de estandarizar el uso de los módulos incorporados, comenzamos a usar Git y Atlassian's Crucible, por cierto, para realizar revisiones de todos los cambios de configuración. Esto proporciona la transparencia deseada.

Tercero, automaticé la configuración de Puppet para que los nuevos hosts puedan agregarse automáticamente con un conjunto predeterminado de opciones. Hay varias maneras de abordar esto. Como ya tenía un entorno Kickstart completo, opté por agregar un script allí.


5
2018-06-06 13:50





"No somos programadores, somos administradores de sistemas"

Mi cómo los tiempos han cambiado, para peor: un greybeard como yo era esperado para ser un mejor programador que los programadores profesionales, o de lo contrario nunca habría podido pasar por un administrador de sistema.

Ahora, tenemos "administradores de sistemas", que son básicamente usuarios de escritorio de Windows que en algún momento se han convertido 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.

De vuelta al tema Títere [, CFEngine, Chef]: tan pronto como uno establece una solución como esa, uno pierde. Todos pierden. ¿Por qué? Porque quienquiera que se le ocurra la idea no es capaz de diseñar la administración de configuración encapsulada en forma de paquetes de sistemas operativos agradables, limpios, Kickstart [, JumpStart, Automated Installer, AutoYaST, Ignite-UX, NIM]. Cuando tiene que usar una herramienta de pirateo automatizada como Puppet (o Chef, o CFEngine), significa que carece de los medios para hacerlo. diseño y para implementar un proceso que, con ese mismo diseño, impondría sistemas completamente prístinos e iluminados, completamente automatizados y no interactivos.

Otro punto importante es, si tiene que tener Puppet o alguna solución similar para correcto alguien seco configuración manual del sistema o de la aplicación, que también se remonta a no tener la experiencia para diseñar un proceso, y en ese proceso un marco donde la configuración se empaqueta en componentes discretos. En efecto, quienquiera que implemente Puppet y similares, no tiene un concepto de propietarios de componentes, versiones, administración de configuración, modelo de madurez de capacidad. 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 viene a reemplazar a Bash como mi lenguaje de herramientas predeterminado del sistema ".

¿Por qué se necesita Ruby, cuando se puede encapsular una gestión de configuración integral de extremo a extremo en las secciones de preinstalación, postinstalación, prearemove y postremover de los paquetes del sistema operativo, simplemente utilizando los programas de shell Bourne, AWK y sed? El hecho de que alguien llegue a aprender un lenguaje esotérico de Ruby y su dialecto en el contexto de Puppet es completamente innecesario. El problema de la gestión de la configuración es fácilmente solucionable (y, en definitiva, se ha solucionado) con programas shell y AWK, y un poco de sed (1) aquí y allá como un pegamento.

Es una sensación genial ver a su manifiesto de Puppet configurar una máquina completa o un nuevo servicio desde cero.

Es una cosa aún mejor 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 software esotérico o extra., no requiere arquitectura cliente-servidor (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 realizados en él.

5.Separate el código de los datos. Este es uno de los conceptos más difíciles de aprender. Los valores de codificación, como los hosts de monitorización en el código de su módulo, son malos. Ponerlos en un almacén de datos (db, yaml (Hiera usa esto por defecto), csv, lo que sea) que sus módulos puedan 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 hace que su proceso de desarrollo sea más simple.

... O simplemente podrías modelo sus archivos de configuración con variables de shell, incluso backquotes (por ejemplo, ls -1 ...) y escriba un script de shell que use AWK para llamar a eval (1) y expanda todas las variables en la plantilla, aprovechando así el mismo analizador potente que los shells han incorporado. ¿Por qué hacerlo complejo, cuando puede ser realmente simple? ¿Dónde almacenará 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 más o menos en cualquier sitio. No hay necesidad de soluciones ultracomplejas. La biblioteca que menciono arriba podría ser simplemente de origen desde las secciones de preinstalación o postinstalación en los paquetes del sistema operativo, eliminando así la duplicación y aprovechando un código central ...

Pero sobre todo, encuentro que la cita anterior es un ejemplo de la próxima generación de administradores de sistemas que necesitan tutoría no por administradores de sistemas, sino por ingenieros de sistemas. Encuentra un greybeard e inicia sesión como aprendiz.


4
2018-02-11 12:28



Parece que has olvidado tu respuesta a la pregunta de los autores. - M. Glatki
Esta respuesta parece ser principalmente una discusión sobre opiniones, actitudes y herramientas, y realmente no aborda la pregunta que se hace. - JonathanDavidArndt