Héberger une application Ruby on Rails avec Amazon Web Services

Rubber est un plugin capistrano dont le but est de faciliter le déploiement d’applications Ruby on Rails sur Amazon Web Services (AWS).

Partons de 0 pour déployer la pré-production d’une application sur AWS.

L’application Ruby on Rails

Commencons par créer une application Rails basique:

rails new todo -d postgresql
bin/rails g scaffold task description:text
bin/rake db:migrate
rm public/index.html
root :to => 'tasks#index'

Configuration d’une instance Amazon EC2

La première chose à faire est de se créer un compte sur Amazon AWS.

Une fois que tout est en ordre nous allons aller dans notre console, qui reprend tous les services auxquels nous avons accès.

Dans la section EC2, nous allon créer une instance, en nous basant sur une Ubuntu 12.04 LTS.

Nous pouvons choisir le type d’instance, selon les besoins en ressources:

Notre instance va ensuite démarrer:

Nous pouvons la couper car rubber va reconfigurer sa propre instance. Pour cela un clic droit sur la ligne avec terminate suffit.

Vérifier que notre instance Amazon EC2 fonctionne

Afin de pouvoir accèder en SSH à notre instance nous allons générer un jeu de clés par le biais du menu key pairs.

Il est possible d’utiliser le nom par défaut (gsg-keypair) ou pas. Attention le jeu de clé doit correspondre à la zone où sera déployée l’application, c’est à dire ne pas avoir un jeu de clé Ouest pour une application web sur la zone Est.

Une fois réalisé nous allons placer cette clé privée dans le dossier ec2 et générer la clé publique associée.

mkdir ~/.ec2
mv ~/Downloads/gsg-keypair.pem ~/.ec2/gsg-keypair
chmod 600 ~/.ec2/gsg-keypair
ssh-keygen -y -f gsg-keypair > gsg-keypair.pub

Vous devez maintenant pouvoir vous connecter à l’instance via:

ssh -i ~/.ec2/gsg-keypair ubuntu@ec2-54-218-17-153.us-west-2.compute.amazonaws.com

La valeur du host est le public DNS disponible quand vous cliquez sur l’instance dans la console Amazon AWS.

Configuration de notre application Rails avec Amazon

C’est maintenant que Rubber entre en jeu. La première chose à faire est de l’installer au niveau global.

gem install rubber && rbenv rehash

À l’image d’un capify pour capistrano, nous allons «vulcaniser» l’application.

Pour cela nous allons choisir un template. Les templates sont des jeux de configuration prêts à l’emploi.

Il en existe un grand nombre dans le dépôt Github Rubber.

Nous allons utiliser nginx, unicorn avec postgresql par le biais du template complete\_unicorn\_nginx\_postgresql.

Tous les fichiers de configuration sont ajoutés directement dans l’application. Ils possèdent tous des réglages par défaut qui sont bien sûr éditables, mais qui fonctionnent en l’état.

La commande ajoute également les gem rubber et open4 dans notre Gemfile.

Il est important de décommenter therubyracer dans le Gemfile, autrement aucun moteur ne sera disponible pour compiler les assets.

Le seul fichier à configurer est le fichier config/rubber/rubber.yml

Les paramètres à changer sont:

• Le nom de l’application
• L’app_user, si vous avez pris l’AMI Ubuntu c’est «ubuntu» l’utilisateur par défaut
• La timezone utilisée, par exemple US/Western
• Le domaine de l’application
• La région du serveur dans la section aws, par exemple us-west-2

Configuration des clés

Il faut ensuite configurer les clés d’accès Amazon AWS.

Le numéro de compte (account) se trouve dans Account Identifiers: aws_security_credentials

Il faut ensuite aller dans la section Security Credentials, puis Access Keys et créer une clé.

Vous pouvez recopier Access Key ID dans la section access_key de la configuration. Pour le secret il faut se rendre dans la section sécurité et l’afficher.

Pour la partie keyname il faut faudra la changer si vous n’avez pas gardé gsg-keypair. Enfin il faudra configurer les informations de l’image. Le type (ex: m1.medium) et l’id (ex: ami-70f96e40).

Création d’un staging

À partir de là vous avez normalement tous les réglages suffisants pour créer un staging.

J’ai toutefois dû modifier les règles de sécurité suivantes:

• auto_security_groups, chaque rôle a son propre groupe de sécurité.
• isolate_security_groups, isôle également les rôles au niveau environnement (web_production et staging_production sont des groupes différents).

J’ai du mettre ces 2 valeurs à false pour éviter l’erreur You have exceeded the number of VPC security groups allowed per instance. (Fog::Compute::AWS::Error).

Si vous avez des retours là dessus je suis preneur. J’ai aussi mis prompt_for_security_group_sync à false. Autrement dès lors que les groupes de sécurité remote ne correspondent plus, il demande explicitement s’il faut bien les supprimer.

Il nous reste donc à lancer:

cap rubber:create_staging

Ajouter une dépendance

Imaginons que par la suite votre application ait besoin d’une dépendance supplémentaire, par exemple memcached.

Dans ce cas vous allez re-vulcanizer avec le template en question:

be cap rubber vulcanize memcached

Cela aura pour effet de créer les fichiers de configuration de memcached.

Dans le fichier config/rubber/rubber-memcached.yml on voit que le memcached utilise le role memcached.

Notre instance de production ne possède pas encore ce rôle nous allons l’ajouter:

RUBBER_ENV=production ROLES=memcached be cap rubber:roles:add

Une fois réalisé vous pouvez relancer un bootstrap pour installer les paquets manquants sur l’instance voulue:

RUBBER_ENV=production be cap rubber:bootstrap

Conclusion

Il est à noter qu’avant de recréer un staging après l’avoir supprimé (cap rubber:destroy_staging), j’ai dû manuellement retirer les règles restantes dans la console AWS afin d’éviter les erreurs type: InvalidPermission.Duplicate => the specified rule \"peer: sg-f74dac98, TCP, from port: 1, to port: 65535, ALLOW\" already exists (Fog::Compute::AWS::Error)

Autrement tout c’est déroulé correctement. Vous voilà donc avec une pré-production prêt à l’emploi en quelques commandes.

Dans le prochain article nous verrons comment gérer finement plusieurs instances pour monter en charge.

L’équipe Synbioz.

Libres d’être ensemble.