Par , le 5 mars 2015

Hébergement et déploiement d’une application RubyOnRails

Développement | 0

Développer un site web c’est bien mais encore faut-il pouvoir l’héberger.

Chez Silicon Salad, nous utilisons, la plupart du temps, Amazon Web Services (AWS) pour l’hébergement de nos sites ou applications web.

Je vais donc vous montrer, à travers un exemple, comment héberger un site web, développé avec le framework RubyOnRails, en utilisant les services d’Amazon. Dans un deuxième temps, j’expliquerai comment automatiser les déploiements avec Codeship.

Je ne vais pas revenir ici sur la partie applicative. Choisissez l’application Rails de votre choix. Il n’y a pas de configuration particulière côté application.

Voici les quelques pré-requis avant de commencer :

  • Avoir une application RubyOnRails fonctionnelle utilisant MySQL
  • Ajouter la gem unicorn dans votre application
  • L’application doit se trouver sur Github
  • Avoir un compte et être connecté sur l’interface web d’AWS

Dans cet article, je vais tout faire via l’interface en ligne d’AWS mais il est tout à fait possible de le faire via l’API.
Attention, il est recommandé d’avoir déjà utilisé AWS avant de vous lancer dans la configuration de votre stack grâce à cet article.

Mise en place de l’environnement de staging

Afin de tester la stack, l’application va être déployée dans un environnement de staging.

Base de données

Avant de créer une instance pour héberger l’application, il est nécessaire de créer une instance RDS pour la base de données. Pour cet article, MySQL a été choisi mais il est également possible d’utiliser PostgreSQL par exemple.

Afin de créer votre instance de base de données, rendez-vous dans la partie concernant RDS puis, dans la page listant les instances, vous allez pouvoir en lancer une nouvelle. Vous pouvez voir ci-dessous la configuration choisie pour l’exemple.

aws-rds-instance

aws-rds-instance2

Vous pouvez maintenant voir votre instance en cours de création dans la liste des instances RDS. Pour pouvoir passer à l’étape suivante, il faut attendre que l’instance soit créée et affichée comme disponible. Vous pouvez ensuite tester qu’elle est accessible en vous y connectant avec SequelPro ou tout autre outil similaire.

Ajout d’un Load Balancer

L’étape qui va suivre est optionnelle. Elle permet de créer un Load Balancer qui va, par la suite, regrouper nos différentes instances.

Il faut que vous vous rendiez dans la partie EC2 puis Load Balancer afin de pouvoir en créer un nouveau.

Il suffit dans un premier temps de donner un nom à ce dernier. Les listeners n’ont pas besoin d’être modifiés pour le moment.

aws-lb1

Ensuite, je modifie le Health Check pour tester l’accessibilité du serveur via TCP et non HTTP (à vous de voir suivant les cas).

aws-lb2

Les deux étapes qui suivent peuvent rester en l’état puisque l’on ajoutera les instances via OpsWorks.

Voici donc le récapitulatif de la configuration du Load Balancer.

aws-lb3

L’utilisation d’un Load Balancer va faciliter la suite de la mise en place de l’environnement de staging puisque nous allons pouvoir créer un enregistrement DNS qui pointera vers ce dernier et donc toutes les instances qui seront regroupées par ce Load Balancer seront accessibles via la même URL. De plus, le Load Balancer va répartir les requêtes équitablement vers chacun des serveurs.

Pour définir l’URL d’accès à votre staging, vous pouvez vous rendre dans la partie Route 53si vous gérer vos enregistrements DNS depuis AWS. Il faut ensuite créer un Record Set pour le domaine souhaité.

aws-route53

Cliquez dans le champ Alias Target, une liste contenant votre Load Balancer vous sera proposée.

Vous disposez maintenant d’une URL pour accèder à vos futures instances.

Installation du serveur

Pour avoir un serveur correctement configuré et disposant de tous les outils nécessaires nous allons utiliser OpsWorks. Cela permet, via des recipes Chef, de lancer des instances avec une configuration définie et directement disponibles dans le pool pour l’environnement donné.

Création de la stack OpsWorks

Dans la partie réservée à OpsWorks, vous devez ajouter une stack. Voici la configuration sélectionnée pour ce test :

aws-opsworks

J’ai donc choisi une instance sous Ubuntu 14.04. Je n’ai pas ajouté de clé SSH car vous verrez dans le recipe que j’ajoute ma propre clé SSH. Cette configuration est bien sûr modifiable, à chacun de voir ce qui est nécessaire en fonction des besoins.

Vous pouvez trouver le recipe Chef utilisé sur Github. Un JSON personnalisé peut être ajouté afin de déclarer un certains nombre de valeurs pour des variables qui seront utilisées dans le recipe.

Ajout des layers

Maintenant que la stack OpsWorks a été créée, les différents layers vont pouvoirs être ajoutés.

Base de données

Lorsque vous vous rendez dans la partie Layers vous pouvez en ajouter un premier. En cliquant sur l’onglet RDS, vous devez retrouver l’instance précédemment créée.

aws-layer-rds-1

Sélectionnez là et indiquez les identifiants de connexion.

Un premier layer a donc été ajouté à votre stack.

aws-layers

Application Rails

Maintenant que l’instance qui contiendra la base de données a été ajoutée, il faut créer le layer pour l’application RubyOnRails.

Choisissez un nouveau layer de type Rails App Server, puis, la version de Ruby ainsi que celles de RubyGems et de Bundler.

Si vous avez créé un Load Balancer précédemment, ajoutez le à ce layer.

aws-layer-rails

Vous trouvez donc maintenant vos deux layers et le Load Balancer dans OpsWorks.

aws-layers2

Lorsque vous cliquez sur le layer Rails, vous pouvez modifier les recipes appelés. Il faut ajouter l’appel à notre recipe personnalisé pour ajouter la clé SSH.
Le deuxième recipe à ajouter, opsworks_nodejs, sera utile pour Rails.

aws-recipes

Ajout de l’application

Maintenant que les layers sont créés et avant d’ajouter des instances, il faut créer l’application dans OpsWorks.

Pour cela, rendez-vous dans la partie Apps. Vous devez donner un nom, spécifier l’environnement ainsi que l’adresse du repository Github sur lequel se trouve votre application Rails. Il est également nécessaire d’indiquer sur quelle instance RDS vous souhaitez créer la base de données de l’application.

aws-app

Ajout des instances

Tout est maintenant prêt pour que l’on déploie notre application sur une première instance.

Afin de tester que la configuration est correcte j’ai choisi d’utiliser une instance m3.2xlarge. C’est beaucoup trop performant pour le test mais l’instance étant plus puissante, elle met moins de temps à se lancer et se configurer. Vous pourrez, de toute façon, lancer des instances plus petites par la suite.

aws-instances-setup

aws-instances

Une fois l’instance disponible, si vous avez bien ajouté votre clé, vous devriez pouvoir vous y connecter en SSH. Vous trouverez votre application dans le répertoire /srv/www/myappname/current/.

Afin que l’instance de l’application puisse communiquer avec la base de données, vous allez devoir ajouter l’adresse IP de cette instance dans le security group de l’instance RDS. Pour cela, dans le listings de vos instances RDS, cliquez sur le security group de celle concernée. Là, vous pourrez modifier les règles dans la partie Inbound :

aws-sg-1

Maintenant que tout est configuré, vous devriez pouvoir lancer un déploiement depuis l’interface OpsWorks pour votre application (avec les migrations). Attention, il m’est arrivé que la base de données de l’application ne soit pas créée. N’hésitez pas, dans ce cas, à lancer la commande Rails permettant la création depuis l’instance hébergeant votre application.

Voilà, vous avez donc une application hébergée sur AWS, qui est accessible à une URL choisie et avec une base de données stockée sur une autre instance (RDS).

Déploiements automatisés avec Codeship

Codeship est un outil permettant d’automatiser les déploiements comme nous vous l’expliquions dans un précédent article. Il s’intègre très facilement avec OpsWorks, je vais vous montrer comment.

Avant tout, il vous faudra créer un utilisateur IAM dans AWS pour que Codeship puisse accéder aux différentes instances de votre stack OpsWorks.

Dans votre interface d’administration Codeship, vous devez créer le projet correspondant à votre application (choisissez le repository Github concerné). Ensuite, dans les paramètres de ce projet, rendez-vous dans la gestion des déploiements. Là, choisissez la branche souhaitée et sélectionnez le mode Custom script afin d’ajouter votre script de déploiement OpsWorks. Vous retrouverez plus d’informations sur le site de Codeship.

Voici un exemple de script :

aws-1

Comme vous pouvez le constater, les migrations seront lancées à chaque déploiement.

Voilà, un simple push sur votre branche va maintenant, automatiquement, déclencher un déploiement. Codeship a vraiment un intérêt si vous avez écrit des tests pour votre application car il va vous permettre de déployer en staging uniquement si les tests passent. Vous pouvez néanmoins l’utiliser sans tests.

Conclusion

Vous avez pu voir, au travers de cet article, comment utiliser AWS pour héberger votre site développé avec RubyOnRails et faciliter les déploiements. Le but de cet article est de vous montrer comment rapidement mettre en place une stack de staging. À vous ensuite de l’adapter légérement si vous souhaitez l’utiliser pour un environnement de production.

OpsWorks possède de nombreux avantages, le principal étant que vous allez maintenant pouvoir ajouter autant de serveurs que vous le souhaitez pour votre stack sans avoir à tout re-configurer. Il vous suffit d’ajouter une instance (du type souhaité) et le tour est joué (il faut tout de même attendre quelques minutes pour qu’elle boot et qu’elle soit configurée par OpsWorks mais aucune configuration supplémentaire ne sera nécessaire). Vous pouvez donc faire croitre ou décroitre le nombre d’instances suivant les besoins et sans efforts.

Je n’ai montré ici qu’un exemple d’utilisation. Il est bien sûr possible d’aller plus loin dans de nombreux domaines : sécurité, base de données… N’hésitez pas à me faire des retours sur vos cas d’utilisation.

Partager l'article :

Vous souhaitez réagir ?

En soumettant ce commentaire vous donnez à Silicon Salad le droit de citer vos propos ainsi que votre nom/site. Tous commentaires dégradants ou hors-sujet peuvent-être supprimés par décision de l’auteur. Votre e-mail, ne sert qu’à des fins d’authentification, il ne peut-être ni partagé ni diffusé.
Vous pouvez commenter avec la syntaxe Markdown. En savoir plus

Article précédent
Ruby On Rails et Silicon Salad : love story mais pas que...