Martin Catty
02 07 2013

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

posté par dans les catégories rails

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.

AWS Console

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

Choix de l'AMI

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

Configuration de l'AMI

Notre instance va ensuite démarrer:

Liste des instances AWS

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.

Gestion des clés AWS

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.

Vulcanize de l'application Ruby on Rails

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).

Clés Amazon Web Services

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

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.

Articles connexes

Commentaires (5) Flux RSS des commentaires

  • Guillaume

    02/07/2013 à 17:21

    Bonjour

    Merci pour ce chouette article !


    Combien coûte ce genre d'hébergement pour une petite application?



    merci

  • Martin Catty

    02/07/2013 à 17:31

    Bonjour Guillaume,

    Pas de réponse précise là dessus puisqu'il s'agit de paiement à la consommation.
    On paye plusieurs choses selon leur type: l'instance, la bande passante… et d'autres options que l'on peut activer à la demande (cloudfront…).

    À noter qu'il existe une instance micro gratuite pour tester. Tout l'avantage est qu'on peut démarrer sur de petites instances sans option pour enrichir son panel de services quand l'application rencontre son public.

  • Domaine Chanzy

    04/07/2013 à 10:22

    Merci pour cet article, il est fort sympatique!
    Cela fait plusieurs fois déjà que je me renseigne sur votre blog, il n'y a que des bonnes informations!
    Merci encore!

  • PierreND

    04/07/2013 à 10:31

    Merci pour cet article très intéressant. J'ai une question sur la base de données. Je pensais utiliser Amazon RDS (Relational Database Service) mais en fait ça ne gère pas les bases PostgreSQL. Pouvez-vous partager avec vos lecteurs comment vous gérez votre base de données avec AWS si c'est le cas ?

  • Martin Catty

    13/07/2013 à 16:33

    Bonjour Pierre, c'est une bonne question je vais parler de RDS dans mon prochain article.

Ajouter un commentaire

Notre expérience vous intéresse ? Inscrivez-vous à nos articles !

×

Newsletter

Rejoignez-nous !

Poursuivons la conversation

N° Vert
0 805 69 35 35

Nos dernières nouvelles

Nos derniers tweets

RT @hackademy_io: Découvrez en vidéo comment installer #discourse la plateforme de discussion, mailing et chat https://t.co/pyu7qh2NgI #hac…

CORS, CloudFront et Firefox sont dans un bateau http://t.co/1CsOz2xIN9 #cdn

Découvrez comment créer votre propre police avec #sketch en vidéo http://t.co/7Wj60px54u #font