Drupal 8: deploy capistrano y gestión de la configuración
Descargar como PPTX, PDF1 recomendación650 vistas
Este documento describe cómo usar Capistrano para implementar despliegues automatizados de sitios Drupal 8. Capistrano es una herramienta de Ruby que permite implementar cambios de código de forma segura en servidores remotos. Explica los requisitos, las tareas que realiza Capistrano como implementar cambios y hacer rollback, y cómo configurar Capistrano y Drupal para admitir despliegues automatizados.
Drupal 8: deploy capistrano y gestión de la configuración
- 1. Drupal 8: Deploy con capistrano
- 2. ¿Qué es Capistrano? Capistrano (http://capistranorb.com/) es una herramienta escrita en ruby para la automatización de tareas en servidores remotos y realizar despliegues en estructuras complejas. Capistrano NO se instala en la(s) máquina(s) de destino, el único requisito en los entornos es ssh. Podemos centralizar los despliegues en una máquina con acceso ssh a todas las demás (maquina de deploy) y realizar las diferentes tareas (backups, tags de git, despliegues) con total seguridad y de una manera controlada.
- 3. Requisitos En la(s) máquina(s) de destino tenemos que tener acceso vía ssh, nada más! para todo lo demás capistrano se apaña. En la máquina de deploy tenemos que tener instalado… Capistrano, y por lo tanto ruby 2.0 o superior. Hemos preparado una plantilla para los entornos de deploy que simplifica la configuración: https://github.com/davidgallego/drupal8_capistrano
- 4. Qué hace Capistrano - Tareas básicas de deploy: - Sube tu código al/los servidor(es) en releases. - Tiene directorios y archivos compartidos entre releases. - Puedes hacer rollback en cualquier momento. - Custom Task. - Creación de copias de seguridad DB - Ejecución de comandos drush en Estructura: ├── current -> /var/www/my_app_name/releases/20150 120114500/ ├── releases │ ├── 20150080072500 │ ├── 20150090083000 │ ├── 20150100093500 │ ├── 20150110104000 │ └── 20150120114500 ├── repo │ └── <VCS related data> ├── revisions.log └── shared └── <linked_files and linked_dirs>
- 5. Desarrollo Instalamos drupal desde https://github.com/drupal-composer/drupal-project/, el core, los themes contribuidos y los módulos contribuidos se instalan desde composer, por lo tanto no están en el repositorio. Los módulos se instalan y actualizan con composer: composer require drupal/redirect ~8.1 composer update drupal/core La configuración va en /sites/default/settings.local.php fuera del repo.
- 6. Configuración de Capistrano Genérica (capistrano/config/deploy.rb) - Configuramos el repo: set :repo_url, '[email protected]:path/to/repo/reponame.git' - Configuramos la ruta de drupal (normalmente /web): set :app_path, "path/to/drupal/dir" Entornos (capistrano/config/deploy/{NOMBRE_ENTORNO}.rb) - Configuramos la rama que se tiene que desplegar: set :branch, 'dev' - Configuramos el directorio en el que se tiene que desplegar: set :deploy_to, 'path_in_the/server' - Configuramos el/los servidores: server 'ip_or_domain.es', port: 22, user: 'deploy_user', roles: %w{app db web}
- 7. Deploy Ya estamos preparados para hacer deploy: cap {entorno} deploy Listo! (bueno en realidad no….) la primera vez que hagamos el deploy será un FAIL, tenemos que crear el archivo shared/web/sites/default/settings.local.php con la configuración del servidor. cap {entorno} deploy y Ahora si!.. Listo! Para rollback (despues de hacer mas de dos deploys) cap {entorno} deploy:rollback (nos preguntará si queremos restaurar alguna copia de db)
- 8. Drupal 8: Gestión de la configuración
- 9. Configuration Management Initiative Por fin todo lo que sea configuración es exportable e importable a través de archivos yml, pero… ¿CÓMO GESTIONAMOS ESTO? Si sólo hay un desarrollador no hay ningún problema, haces los cambios que haya que hacer, los exportas en desarrollo y los importas en el entorno que toque, mola! Si el proyecto es multi-developer XD … puede que haya algún problema
- 10. Problemas Mike exporta su configuración y la sube al repositorio. Bob crea un nuevo tipo contenido... Bob recoge la configuración del repo y se la importa, (o dios!!!!, todos los cambios de configuración que había realizado, no están….) Bob, eres mu tonto
- 11. Problemas Mike exporta su configuración y la sube al repositorio. Bob actualiza su repo, exporta su configuración y la sube al repositorio. Mike actualiza su repo e importa la configuración O dios!!!!, todos los cambios de configuración que había realizado, no están…. Bob, eres mu tonto
- 12. Flow Bueno entonces cómo!!!! Una posible solución: http://nuvole.org/blog/2014/aug/20/git-workflow-managing- drupal-8-configuration Mike, si ha realizado cambios de configuración, antes de hacer un pull siempre hace una exportación de su configuración, luego hace el pull, si tiene conflictos los corrige y luego realiza un import de la configuración para incorporar los cambios de sus compañeros. En los entornos (dev|pre|pro) nunca se realizan cambios de configuración.
- 13. PROCESO drush config-export git add --all git commit -m “Cambios en config” git pull origin master (Arreglamos posibles conflictos si fuera necesario) drush config-import git push origin master
- 14. ¿¿¿CUAL ES TU SOLUCIÓN????