test rails jamon deploy alternatives deployment capistrano release-management

deployment - jamon - capistrano rails



Cómo implementar en un solo servidor específico usando Capistrano (5)

Tengo un sistema en producción que tiene varios servidores en varios roles. Me gustaría probar un nuevo servidor de aplicaciones mediante la implementación en ese servidor específico, sin tener que volver a implementarlo en todos los servidores en producción. ¿Hay alguna manera de pedirle a Capistrano que se despliegue en un servidor específico? Idealmente, me gustaría poder ejecutar algo así como

cap SERVER=app2.example.com ROLE=app production deploy

si solo quisiera implementar en app2.example.com.

¡Gracias!

[actualización] Probé la solución sugerida por wulong al ejecutar:

cap HOSTS=app2.server.hostname ROLE=app qa deploy

pero Capistrano parecía tratar de ejecutar tareas para otros roles en ese servidor además de las tareas de la aplicación. Tal vez necesito actualizar mi versión de cap (estoy ejecutando v2.2.0)?


Debería poder hacer algo como esto en deploy.rb:

task :production do if ENV[''SERVER''] && ENV[''ROLE''] role ENV[''ROLE''], ENV[''SERVER''] else # your full config end end


Lo siguiente debería funcionar de la caja:

cap HOSTS=app2.example.com ROLE=app deploy

Si desea implementar en> 1 servidor con el mismo rol:

cap HOSTS=app2.example.com,app3.example.com,app4.example.com ROLE=app deploy


Tengo un problema similar e intenté lo siguiente. Funciona:

cap production ROLES=web HOSTS=machine1 stats


Terminé publicando una pregunta en la lista de usuarios de capistrano aquí , y obtuve la siguiente respuesta de Jamis (editada un poco por mí aquí para mayor claridad):

Pruebe la variable de entorno HOSTS:

cap HOSTS=app2.example.com production deploy

Tenga en cuenta que al hacer esto, se considerará que app2 está en todas las funciones, no solo en las funciones en las que se declare.

Si lo que desea es hacer un despliegue regular, pero solo actuar en la aplicación2, y solo cuando la aplicación2 se declara en su archivo de recetas, puede usar la variable HOSTFILTER en su lugar:

cap HOSTFILTER=app2.example.com production deploy

[...]

Considera este ejemplo concreto. Supongamos que su secuencia de comandos define tres servidores, A, B y C. Y define una tarea, "foo", que (de forma predeterminada) quiere ejecutar en A y B, pero no en C. Así:

role :app, "A", "B" role :web, "C" task :foo, :roles => :app do run "echo hello" end

Ahora, si cap foo , ejecutará el comando echo en A y B.

Si cap HOSTS=C foo , ejecutará el comando echo en C, independientemente del parámetro: roles para la tarea.

Si cap HOSTFILTER=C foo , no ejecutará el comando echo en absoluto, porque la intersección de (AB) y (C) es un conjunto vacío. (No hay hosts en la lista de hosts de Foo que coincidan con C.)

Si cap HOSTFILTER=A foo , ejecutará el comando echo únicamente en A, porque (AB) intersectado con (A) es (A).

Por último, si cap HOSTFILTER=A,B,C foo , ejecutará el comando echo en A y B (pero no en C), porque (AB) intersectado con (ABC) es (AB).

En resumen: HOSTS reemplaza por completo la declaración de hosts o roles de la tarea y obliga a que todo se ejecute contra el host especificado. HOSTFILTER, por otro lado, simplemente filtra los hosts existentes contra la lista dada, seleccionando solo aquellos servidores que ya están en la lista de servidores de tareas.


También puede especificar el parámetro de hosts de nivel de tarea de esta manera:

task :ship_artifacts, :hosts => ENV[''DEST_HOST''] do end