bash - que - vagrant provision shell
Elegir un aprovisionador vagabundo (3)
Ah, con la libertad de elección viene la complicación de elegir lo que es correcto para usted.
Chef Solo : Chef solo es ideal si está comenzando con Chef o un chef chef es simplemente demasiado pesado para su situación. Chef solo le permite incrustar todos sus libros de cocina dentro de su proyecto, lo que es bueno para los proyectos que desean realizar un seguimiento de sus libros de cocina dentro del mismo repositorio. Chef solo funciona de manera independiente: no requiere de un servidor chef ni de ningún otro servidor con el que hablar; simplemente se ejecuta solo en la máquina virtual.
Chef Server : el servidor de Chef es útil para empresas o individuos que administran muchos proyectos, ya que le permite compartir libros de cocina en múltiples proyectos. Los libros de cocina se almacenan en el servidor y el cliente los descarga al ejecutarse.
Puppet : el aprovisionador de Puppet ejecuta manifiestos de Puppet independientes que se almacenan en el servidor y se descargan en la máquina virtual del cliente cuando se crea. El aprovisionador no requiere un servidor Puppet y se ejecuta en la propia VM.
Servidor Puppet: el aprovisionador del servidor Puppet se conecta a un servidor Puppet y configura la máquina virtual de su cliente utilizando la configuración de nodo en ese servidor.
Otras herramientas, scripts de shell, etc. - ¿Utiliza alguna otra cosa que no sea la que está incorporada en Vagrant? Los aprovisionadores son simplemente subclases de Vagrant :: Provisioners :: Base, lo que significa que usted puede construir su propio fácilmente, si es necesario.
También puede consultar la documentación, docs.vagrantup.com/v2
Pregunta
¿Alguien puede explicar por qué sería mejor elegir a los títeres o cocineros vagabundos aprovisionados en lugar de al armador?
Fondo
Estoy en el proceso de comenzar con Vagrant. Una de las cosas con las que estoy teniendo problemas es decidir qué aprovisionador usar. Hasta ahora, he tenido cierto éxito con el aprovisionador de shell, pero ha sido más trabajo del que esperaba que funcionara de forma confiable.
Por el momento, no estoy familiarizado con el rubí, el títere o el chef, pero estoy feliz de aprender cualquiera o todos ellos si tengo que hacerlo. Mi experiencia inicial al jugar con los títeres y el chef es que si alguien más tiene una receta que hace exactamente lo que usted quiere, funciona muy bien, pero hacer algo que no sea estándar significa volver a codificar la solución en ruby.
Soy consciente de los artículos que comparan títeres y chef , y me preocupa menos cuál de ellos usar, en lugar de saber cuándo y por qué debo usarlos.
Elegiría el aprovisionador de Shell y luego permitiría que el script de shell clonara el repositorio de títeres / chef desde github o bitbucket. El script puede configurar una clave ssh para permitir la clonación automática de git. Los beneficios son que la mayoría de los proveedores de la nube también lo admiten, por lo que puede usar el mismo script. Este blog explica bien git, puppet y vagrant, un hombre y el blog de la nube.
Revelación completa: soy un empleado de Puppet Labs. Pero elegí Puppet como producto durante 2 años antes de unirme a ellos.
Le recomendaría que utilice Puppet o Chef over shell si sus configuraciones van a a) tener algún grado de complejidad yb) cambiarán con el tiempo, o espera que su entorno de instalación cambie de una manera que pueda alterar la forma su despliegue realiza Sus scripts pueden ser muy buenos, pero en última instancia, a menos que esté siguiendo prácticas de programación fantásticas en torno a ellos, los pruebe y realice el control de calidad, etc. en algún momento fallarán.
Hay un cuerpo completo de personas instruidas en torno a DevOps que discuten esta noción, pero se trata del principio de "deuda técnica": ahora tendemos a hacer las cosas de manera fácil y, por lo tanto, las percibimos como más simples, a costa de aumentar la complejidad y la dificultad. luego.
Una de las fortalezas de Puppet es su naturaleza determinista: el manifiesto que usted escribe debe poder ser transformado programáticamente por Puppet en un modelo del servidor que está construyendo. Las personas perciben que esto es más "difícil", pero yo diría que la dificultad se reduce si se promedia a lo largo de la curva del ciclo de vida de su tecnología. En otras palabras, Puppet te obliga a pensar ahora, pero luego se implementa a escala con facilidad, en lugar de pensar más tarde y reingeniería a medida que avanzas. Pague en efectivo ahora, en lugar de a crédito, con intereses, más adelante.
Si está simplemente derribando los manifiestos de otras personas, en algún momento se encontrará con problemas, aunque nos gustaría que no fuera así. Trabajar con Puppet hoy en día, ciertamente es el caso, porque están escribiendo para abordar. El caso general, y no su sistema particular. Muchos manifiestos de propósito general se vuelven útiles solo cuando alcanzas una mejor comprensión de Títere.
Así que, en lugar de comenzar allí, trabajaría a través de la excelente guía de Aprendizaje de marionetas para comenzar a comprender los conceptos básicos. La curva de aprendizaje de Puppet es empinada, pero se nivela al cabo de poco tiempo.
Hay otras razones para usar otros aprovisionadores o herramientas, pero seguramente argumentaría que es mejor con Puppet o Chef que intentar asegurarse de que sus scripts de shell estén haciendo exactamente lo que cree que deben hacer, durante el tiempo que usted Necesidad de engendrar nuevos ambientes.