Browse Source

chapitre sur Capistrano (1er jet)

master
Jérémy Lecour 2 years ago
committed by Jérémy Lecour
parent
commit
04b324e073
1 changed files with 34 additions and 4 deletions
  1. +34
    -4
      HowtoRails.md

+ 34
- 4
HowtoRails.md View File

@@ -204,10 +204,42 @@ En général, on inclut les fichiers `Gemfile` et `Gemfile.lock` dans le reposit

### Capistrano

[Capistrano](https://capistranorb.com/) est un outil de déploiement populaire, notamment pour les applications Rails.
[Capistrano](https://capistranorb.com/) est un outil de déploiement particulièrement adapté aux développements en Ruby (dont Rails) mais parfaitement compatible avec d'autres langages ou frameworks (PHP, Java…).

TODO
Il est généralement exécuté depuis un poste de développement ou d'intégration. Il se connecte alors en SSH à un ou plusieurs serveurs (via SSH) pour y exécuter des tâches selon les rôles du serveur (application, base de données…).

Il est recommandé d'installer Capistrano via Bundler (dans le cadre d'un projet), mais il est évidemment possible de l'utiliser indépendamment (`# gem install capistrano`). Sa commande principale est `cap`.

À l'initialisation, Capistrano créé plusieurs fichiers, dont ceux nécessaires à gérer plusieurs envvironnements (production, staging…) :

~~~
├── Capfile
├── config
│ ├── deploy
│ │ ├── production.rb
│ │ └── staging.rb
│ └── deploy.rb
└── lib
└── capistrano
└── tasks
~~~

* `Capfile` est lu par l'exécutable au chargement pour déterminer les modules à charger ;
* `config/deploy.rb` contient la configuration générale ;
* `config/deploy/*.rb` contiennent les particularités de chaque environnement ;
* `lib/capistrano/tasks/*` permet de créer ses propres tâches à exécuter lors du déploiement.

Il existe de nombreux modules additionnels pour Capistrano afin d'apporter le support de frameworks ou bibliothèques : rails, rbenv, sidekiq, whenever… Il s'agit de gems à installer manuellement ou via Bundler.

Capistrano s'appuie massivement sur Rake, qui est une implémentation en Ruby du principe de Make (et des Makefile). Tout se passe donc sous forme de taches exécutées dans un ordre défini par un arbre de dépendance. De fait toutes les tâches peuvent être surchargées pour en personnaliser l'exécution.

Dans la plupart des cas (surtout avec Rails ou d'autres frameworks supportés) le déploiement en production se fait via la commande `[bundle exec] cap production deploy`. Un déploiement classique d'application Rails va faire :
* mise à jour du code source (via Git)
* création d'une "release" avec copie du code, liaison de fichiers/dossiers clés…
* pré-compilation des assets (images, JS, CSS…)
* migration de la base de données
* activation de la release
* relance du serveur d'application

## Serveur web

@@ -405,5 +437,3 @@ rails_env = `head -1 $(HOME}/www/current/config/database.yml | tr ':' ' '`
### Rails 2.3.2->2.3.5 & Passenger & les logs

Une petite erreur en environnement de production affecte les versions 2.3.2 à 2.3.5 (incluse) de Rails. Les logs de l'application ne sont pas écrits dans le fichier `log/production.log`. Pour pallier cette erreur, il faut appliquer le patch qu'on trouve [ici](https://rails.lighthouseapp.com/projects/8994/tickets/3577-failsafe-middleware-should-flush-the-logger) (deuxième fichier).



Loading…
Cancel
Save