Capistrano, Rails 3.2, recetas estándar?

Question

He estado desarrollando Rails por un tiempo, pero de alguna manera evité usar capistrano hasta ahora.

Al tratar de descubrir cómo comenzar, me confundí acerca de la mejor receta de Capistrano para una versión 3.x de los rieles "estándar" con implementación de inventario de activos. Tal vez porque mirando a su alrededor en Google, uno encuentra 'respuestas' de varias partes de la historia, con diferentes períodos históricos cuando se construyeron cosas diferentes en el límite.

Tengo una aplicación que guardo en git, rails 3.2, con canalización de activos, desplegada en solo un host con pasajero.

Pensando en ello, básicamente necesito tapa para:

• despliegue de git?
• hacer una etiqueta en git para el despliegue (y/o utilizar una rama implementar Todo lo que es más habitual en la tapa, si existe tal cosa?)
• bundle install --deployment db
• rastrillo: migrar
• activos rastrillo: precompilación
• toque tmp/restart.txt

Oh mierda, una cosa más extraña posiblemente:

• creo que voy a usar una instalación de rbenv en todo el sistema en el servidor de implementación. No estoy seguro de lo que eso implica.

¿Cuál es la forma más estándar, fácil, simple y fácil de mantener para que la tapa haga todas estas cosas? ¿Hay algo que me estoy perdiendo? Si algo de lo que he especificado no es estándar, me complace usar las mejores prácticas estándar en su lugar (con quizás una excepción o dos, realmente quiero una etiqueta de git para cada implementación, incluso si esa no es una mejor práctica estándar, aunque creo que lo sería, me confundí al mirar a los documentos cómo funciona)

¿Hay una respuesta fácil aquí?

EDIT: Sí, he consultado el wiki de Cap. Puede ser porque soy lento, pero he encontrado respuestas a NINGUNO de mis preguntas allí. Ni siquiera hay un documento de 'inicio'. No hay documentación de lo que hace una receta predeterminada de tapa de caja. etc.

actualización: escribí mi propia guía después de averiguarlo. https://gist.github.com/2161449

Answer 1

Bueno, no tener que usar capistrano es una bendición :-). Empecé a desagradarlo, pero para ser justo, obtuvo un lote mejor, y el documento aquí https://github.com/capistrano/capistrano/wiki/ aborda la mayoría de sus problemas; la sección sobre RVM podría ser suficiente como una alternativa a rbenv. Su configuración debería funcionar con un archivo de captación listo para usar.

EDITAR: sí, tendrá que hacer el etiquetado usted mismo, pero la clave es pensar en los métodos que escribe en el capfile como simples comandos del sistema (recordando que probablemente no tenga su ruta normal de shell y otra ambiente). Sigue los ejemplos de otros comandos de git y estarás bien.

EDIT: Mejor respuesta (tal vez :-)

• entra aquí: https://github.com/capistrano/capistrano/wiki/2.x-From-The-Beginning
• gem install capistrano (nota, por lo general esto no pertenece en su Gemfile)
• cd
• capify . Crea app/Capfile y app/config/deploy.rb
• Está utilizando la canalización de activos, por lo que en el comentario de Capfile load 'deploy/assets'
• Ahora, mira el deploy.rb
  • nombre de la aplicación es un nombre como "my_application"
  • repositorio es la URL a tu repositorio de control de origen, por ejemplo, myusername@github.com:yourrepo/yourproj.git
  • scm: git (derecha Si no es así, misma idea:? URL anterior y esto por SVN, o lo que sea)
  • role :web "www.example.com" y desde el: db y: aplicación están en una sola caja, esos son los mismos
  • se está usando Passenger, entonces descomenta las líneas como se indica.
  • no estoy seguro, pero puede que tenga que require "bundler/capistrano" en la parte superior
  • se necesita un set :deploy_to, <remote installation path> quizá "/var/www"
  • seguir los otros pasos en la guía
  • hipotéticamente después de estos y los pasos que echaba de menos, comprobar todos en este, y asegúrese de que su aplicación está marcada en (y empujó si GIT), y hacer el cap deploy:setup

Hipotéticamente, la instalación configurar el servidor en consecuencia. Lo más probable es que el error aquí sea que su máquina actual necesita permisos para ssh en la máquina remota, y la máquina remota necesita acceso al repositorio de control de origen. Las claves públicas son tu amigo.

Después de esto, el flujo de trabajo es:

• hacer cambios prueba
• localmente
• confirmación, y empujar a git
• cap deploy migrations (la parte migraciones sólo es necesario si usted ha hecho alguna)

La mayoría de las organizaciones tienen algún tipo de servidor de prueba o de prueba. Busque "de varias etapas" para conseguir que lo que puede hacer cap test deploy y cap staging deploy etc.

Para implementar una rama (y creo que una etiqueta) en Git es cap -S <branch/tagname> deploy (asegúrese de que sea el capital S, podría estar en minúsculas).

Una vez que lo hace, es probable que haya cosas que desee hacer antes o después de la implementación, por ejemplo, enviar correo electrónico, regenerar un mapa del sitio, hacer una copia de seguridad de la base de datos, etc. Use los ganchos antes o después para escribir sus propias tareas.

Así que la peor parte de capistrano es que todos los doctores asumen que sabes qué diablos hace. En pocas palabras, usa ssh (ruby's net-ssh) para ejecutar comandos en un servidor remoto desde cualquier estación de trabajo local desde la que implemente. Mira el encabezado de su árbol fuente (o etiqueta o rama, si está especificado), lo lleva a una nueva ubicación en su servidor, hace cualquier otra cosa (migraciones, precompilación de activos) y prepara la aplicación; una vez que se ve bien, se cambia un enlace simbólico (por ejemplo /var/www/current para que apunte a la nueva ubicación y luego (en el caso de pasajeros) llama touch app/tmp/restart.txt para hacer que el servidor se reinicie.

mejor?

Answer 2

Ésta es la receta de la tapa que utilizo para la mayoría de mis proyectos ...

https://gist.github.com/2118882

No sirve de etiquetado, pero se puede hacer de una tarea personalizada, que se escriben como tareas de rake Por defecto, realizará la precompilación y la instalación del paquete. En la parte inferior se encuentra la tarea de volver a cargar tocando tmp/restart.txt en lugar de reiniciar. También limpiará sus lanzamientos para que solo tenga los últimos 3 en el servidor (en lugar de mantenerlos para siempre).

No tengo conocimiento de RBEnv en ningún entorno, utilizo RVM para desarrollo y he usado RVM en producción una vez, pero es tan complicado administrar varios rubies en un entorno de producción (y muy mala práctica) que gané ' t hacerlo de nuevo. Agregó mucha complejidad al proceso de actualización para los paquetes del lado del servidor.

Answer 3

Ha visto la Railscast: Deploying to a VPS a pesar de que se basa en nginx & unicornio, hay una receta alternativa de pasajeros