Dans cet article, nous verrons comment publier facilement et gratuitement une application Rails sur Heroku, dans notre cas: la landing page. L’intérêt est de la rendre disponible à tout le monde sur une URL dédiée.
Cet article est la suite de notre tutoriel sur « La Landing Page: www.babasport.fr » que je vous recommande de lire en premier. Vous pouvez également commencer ici, le seul prérequis est d’avoir une application Ruby on Rails (dans notre exemple dans un dossier « baba »).
1. Introduction: Web hosting vs PaaS
Habituellement, pour déployer une application Web, on loue un serveur ou un bout de serveur à une entreprise (c’est l’hébergeur web par exemple: OVH, PlanetHoster, Bluehost, etc.). Le serveur, c’est un ordinateur auquel on se connecte à distance (via SSH, FTP ou autre), qui a déjà un système d’exploitation, et quelques préconfigurations de base pour pouvoir faire tourner un site web, mais une grosse partie de la configuration est à notre charge: installation des runtimes, configuration de la BDD, configuration du mail, configuration de la sécurité, du firewall … Souvent les hébergeurs web fournissent un interface d’administration de ces serveurs (comme cPanel), qui facilite un peu le travail, mais ne dispense pas de nombreux efforts. Enfin, une fois l’application déployée, se posent de nombreuses problèmes: comment redémarrer automatiquement l’application en cas de problème, comment faire une montée de version (c’est à dire une mise à jour du site), comment supporter une montée en charge (quand de plus en plus d’utilisateurs viennent sur le site et que le site devient de plus en plus lent). Encore une fois, tous ces problèmes sont à notre charge.
En résumé: l’hébergeur web nous loue un serveur, après c’est à nous de nous démerder.
Or c’est relativement bête de tous se démerder dans son coin, alors que quelqu’un pourrait automatiser ça pour nous non ? C’est l’idée derrière le PaaS : Platform-as-a-Service.
En plus de nous louer une infrastructure (virtualisée, et sur le cloud cette fois-ci), on nous prépare tout ce qu’il faut pour faire tourner notre application: le runtime pour Ruby on Rails, la base de données, des outils pour publier facilement et en sécurité des montées de version, des moyens pour augmenter les ressources pour supporter une montée en charge etc. Autrement dit c’est du pain béni pour notre cas d’utilisation: on veut juste publier une application, on veut pas se prendre la tête sur de la configuration.
Pour plus d’informations: hébergement web, cloud, IaaS, PaaS, SaaS.
2. Let’s get technical: Heroku
Heroku est une PaaS (Plateform-as-a-Service), qui a le mérite de fonctionner très bien avec Rails, et d’être gratuit jusqu’à ce que le trafic s’intensifie. En gros Heroku nous donne un serveur pour commencer (un *Dyno*) et on peut augmenter le nombre de Dynos en payant.
Pour plus d’informations sur les dynos: checker cette page dont vient l’image-titre !
> cd ~/baba
> git init
> heroku loginEnter your Heroku credentials.
Email: adam@example.com
Password (typing will be hidden):
Authentication successful.
> cd ~/baba
> heroku create
Creating stark-fog-398… done, stack is cedar-14
http://stark-fog-398.herokuapp.com/ | https://git.heroku.com/stark-fog-398.git
Git remote heroku added
> cd ~/baba> git add -A && git commit -m « C’est so baba »> git push heroku master
Là il se passe tout plein de trucs qui ont l’air trop cools ce qui est encourageant, mais ca finit par planter, ce qui est moins encourageant surtout qu’on a largement dépassé les 10 minutes déjà.
Quand on fait cette dernière commande, Heroku prend notre code, le met sur un serveur à eux (appelé « Dyno ») et tente d’installer tout ce qu’il faut pour faire tourner notre application. Ici tout baigne sauf pour sqlite3 qui n’est pas supporté sur Heroku. Il faut donc faire la seule modification à la configuration de base de Rails nécessaire au fonctionnement sur Heroku:
Dans le Gemfile, qui déclare les dépendances: on remplace sqlite3 par
>> Gemfile
gem ‘sqlite3’
par
>> Gemfile
group :development, :test do
gem ‘sqlite3’
end
group :production do
gem ‘pg’
end
Ce qui veut dire: en environnements de « developpement » et de « test », utilise ‘sqlite3’. Mais en environnement de « production », utilise ‘pg’, aka PostgreSQL.
Puis on lance
> bundle install
pour mettre à jour les dépendances.
On fait un nouveau commit git et un push sur heroku
> cd ~/baba> git add -A && git commit -m « Fix sqlite3 dependency on Heroku »> git push heroku master
« Et voilà » (prononcé à l’américaine). Les dernières lignes de log de Heroku dans la console devraient vous indiquer l’adresse de la nouvelle page:
Pour moi c’est : https://sleepy-lowlands-2671.herokuapp.com/
Bon, c’était long et dur mais j’espère que ça vous a plu. C’est le premier article technique, et peut-être pas le dernier, qui sait.
En attendant, n’oubliez pas de vous inscrire sur www.babasport.fr !
