Caja de vagabundos compartida y automatizada

Question

Estoy pensando en utilizar Vagrant para desarrollar aplicaciones de Django, pero estoy un poco confundido y no estoy seguro de si lo que me gustaría hacer es incluso posible.

Instalé la caja lucid32 con éxito y creé una nueva "instancia" de vagabundo, con un Vagrantfile, algunos directorios compartidos y puertos reenviados.

• El primer problema es que esto no me parece la mejor opción cuando se trabaja en equipo. ¿Cómo podemos nosotros (yo y otros 10 desarrolladores, por ejemplo) compartir el cuadro para que cada cambio que se comparte? Por ejemplo, si en 6 meses necesitamos postgresql, necesito que funcione sin tener que instalar postgresql 11 veces.

• Además, ¿cómo puedo hacer cosas (como: postgresql, django, this-service, etc.) para comenzar cuando la caja se ha iniciado? No creo que deba grabarlo y comenzar manualmente n veces todos los n elementos que necesito todo el tiempo.

• Y finalmente: no entiendo bien si cosas como marionetas y chef están destinadas a sustituir por completo la instalación manual (a través de pip o apt-get, por ejemplo). ¿Es eso así?

Gracias.
_{Y lo siento por el mal inglés. :-)}

Answer 1

Yo diría que su elección de Vagrant ya fue un buen comienzo para lo que está buscando, pero ahora necesita profundizar un poco más en Chef o Títere, para automatizar aún más su proceso de aprovisionamiento.

Supongo que una buena opción en su sceneraio sería poner primero ambos, el Vagrantfile y el manifiesto Puppet correspondiente bajo control de versión como parte de su proyecto. Además, todas las configuraciones relacionadas con esta máquina también deben ponerse en control de versiones y/o estar disponibles a través de algún tipo de repositorio de artefactos.

En segundo lugar, establezca la regla en el equipo que los cambios (al menos estos que deberían durar más tiempo) al medio ambiente deben registrarse si se consideran listos para los otros miembros del equipo.

En relación con su segunda pregunta y volviendo a mi apertura: Puppet (que me gusta) o Chef son sus herramientas de elección y pueden ahorrarle a usted y a sus colegas mucho trabajo en el futuro. Me quedaré con Puppet aquí, ya que no sé Chef demasiado bueno.

Con puppet, puede administrar todo lo que desee, instalar paquetes, cambiar configuraciones y asegurarse de que se ejecuten determinados servicios, o en general que el sistema tenga el estado que desea que sea. Aún mejor, si usted u otro miembro del equipo hecho algunos chages maliciosos a su/su caja, sólo puede deshacer los cambios en su manifiesto Vagrantfile/Títeres, el tipo de

vagrant destroy && vagrant up 

y la caja es fácilmente llevado de vuelta a el último estado versionado.

Por ejemplo, tomemos el siguiente archivo de manifiesto:

package { "mysql-server-5.1": 
    ensure => present 
} 

file { "/etc/mysql/my.cnf": 
    owner => "root", 
    content => "http://myrepository.local/myProject/configurations/mysql/my.cnf", 
    require => Package["mysql-server-5.1"] 
} 

service { "mysql": 
    ensure => running, 
    subscribe => File["/etc/mysql/my.cnf"], 
    require => File["/etc/mysql/my.cnf"] 
} 

Lo que esto hace es, en primer lugar, de todos los cheques el mecanismo paquete del sistema operativo en su caja (los nombres en el ejemplo asume una reciente Ubuntu) si el paquete "mysql-server-5.1 "está instalado, y si no, lo instalará. A través del atributo 'requerir', la segunda directiva se ejecutará después de la primera (y solo si funcionó), cambiando la configuración de MySQL a la que también ha marcado y/o publicado en algún lugar al que pueda acceder (que también podría colocarse en la misma carpeta que el Vagrantfile, y luego estará disponible en el recuadro debajo de/vagabundo). El último paso, que nuevamente solo se ejecutará si la alteración de la configuración trabajó, se asegurará de que el servicio "MySQL" está en marcha o se está reiniciará si ya estaba funcionando cuando la configuración se cambió

Ahora usted puede conectar este manifiesto en su Vagrantfile:.

Vagrant::Config.run do |config| 

    config.vm.box = "lucid32" 
    config.vm.box_url = "http://files.vagrantup.com/lucid32.box" 

    config.vm.define "node1" do |cfg| 
    cfg.vm.network "10.23.5.11" 
    cfg.vm.provision :puppet do |puppet| 
     puppet.manifests_path = "manifests" 
     puppet.manifest_file = "node1.pp" 
    end 
    end 
end 

Con todos los cambios además de los productos de prueba que se realizan en el entorno de esta manera, todos los miembros del equipo están garantizados para tener la misma configuración fácil y reproducible al alcance de la mano.

Personalmente, me gusta probar cosas en la caja a mano, y cuando encontré la configuración y configuración correctas, tradúzcalas en un manifiesto de Puppet para tenerlas listas para su uso posterior y compartirlas con los miembros del equipo.

Como Puppet (y Chef también) puede administrar casi todo lo que necesita (usuarios, trabajos cron, paquetes, servicios, archivos, ...) es una buena opción para esos problemas, y usted tiene el beneficio de incluso podrá usar las configuraciones para aprovisionar escenarios o probar entornos más adelante si así lo desea. Hay muchas más opciones con Puppet, y una lectura a través de the language guide debería darte una buena idea de qué más puedes hacer con ella.

Espero que pueda ayudar :)