Remplacer Pow par Invoker

Invoker est un outil permettant de gérer les processus qui composent votre environnement de développement. Il permet de remplacer à la fois Pow et Foreman.

Pow est un très bon outil permettant de gérer vos applications Rack et Ruby on Rails. Il permet d’y accéder via un domaine en .dev en créant simplement un lien symbolique. Cependant, une application ne dépend pas uniquement du code applicatif. Postgres, Redis ou encore Sidekiq sont autant de dépendances qui doivent tourner pour que tout fonctionne.

Foreman répond à ce besoin en permettant de gérer tous ces processus de façon centralisé grâce à un fichier Procfile listant les commandes à utiliser :

pg: postgres -D vendor/postgresql
sidekiq: bundle exec sidekiq -C ./config/sidekiq.yml
redis: redis-server

Invoker propose une alternative permettant de fournir ces deux fonctionnalités et plus encore.

Invoker permet de visiter ses applications via un domaine .dev et de lancer les dépendances de votre application. Mais il ne s’arrête pas là et rend possible la gestion de plusieurs applications en même temps.

Installation

Distribué sous forme de gem Ruby, Invoker s’installe simplement via

gem install invoker

Une fois installé, vous pouvez simplement le lancer avec la commande

invoker start CONFIG_FILE

Configuration

Invoker, comme Foreman, a besoin d’un fichier de configuration pour fonctionner.

invoker.ini

Le principal format est .ini et ressemble à ceci :

[web]
command = bundle exec rails -s $PORT

[pg]
command = postgres -D vendor/postgresql

[sidekiq]
command = bundle exec sidekiq -C ./config/sidekiq.yml

[redis]
command = redis-server

Procfile

Si vous migrez depuis Foreman ou souhaitez utiliser le même Procfile en développement et sur Heroku, Invoker supporte également les fichiers Procfile.

web: bundle exec rails -s $PORT
pg: postgres -D vendor/postgresql
sidekiq: bundle exec sidekiq -C ./config/sidekiq.yml
redis: redis-server

Configuration extérieure à l’application

Invoker ne force pas la présence du fichier de configuration dans le dossier de l’application. Il est tout à fait possible de centraliser tous vos fichiers de configuration dans un même dossier.

Seule différence dans ce cas, vous devez indiquer dans quel dossier exécuter les commandes :

[web]
directory = /Users/simonc/work/my_application
command = bundle exec rails -s $PORT

[pg]
directory = /Users/simonc/work/my_application
command = postgres -D vendor/postgresql

[sidekiq]
directory = /Users/simonc/work/my_application
command = bundle exec sidekiq -C ./config/sidekiq.yml

[redis]
command = redis-server

Gestion de plusieurs applications

Il est parfois nécessaire de lancer plusieurs applications simultanément pour les besoins d’un projet. Si par exemple vous avez une API et une application utilisant cette API, lancer les deux peut se faire comme ceci :

[api-web]
directory = /Users/simonc/work/api
command = bundle exec rails -s $PORT

[api-pg]
directory = /Users/simonc/work/api
command = postgres -D vendor/postgresql

[api-sidekiq]
directory = /Users/simonc/work/api
command = bundle exec sidekiq -C ./config/sidekiq.yml

[my_app-web]
directory = /Users/simonc/work/my_app
command = bundle exec rails -s $PORT

[my_app-pg]
directory = /Users/simonc/work/my_app
command = postgres -D vendor/postgresql

[my_app-sidekiq]
directory = /Users/simonc/work/my_app
command = bundle exec sidekiq -C ./config/sidekiq.yml

[redis]
command = redis-server

Invoker ne peut être lancé qu’une fois et ne permet donc pas de faire tourner deux fichiers de configuration en même temps.

Deux choses à noter ici : Redis n’est lancé qu’une seule fois, ce qui est suffisant pour les deux applications, et chaque service porte un nom différent pour éviter tout conflit.

Accéder à votre application via un domaine .dev

La première étape est de désinstaller Pow qui est déjà à l’écoute des .dev.

curl get.pow.cx/uninstall.sh | sh

Tout comme Pow, Invoker nécessite un accès à votre système pour brancher la résolution des domaines .dev. Pour ce faire, lancez la commande

sudo invoker setup

Vous pourrez maintenant accéder à votre application en utilisant le nom donné à la commande rails -s. Si par exemple votre fichier invoker.ini ressemble à ceci :

[my_app]
command = bundle exec rails -s $PORT

l’application sera accessible sur http://my_app.dev.

Pours et Contres

La question est “Pourquoi faire le choix d’Invoker par rapport à Pow+Foreman ?”.

Une première réponse est la gestion du SSL : Invoker utilise un certificat self-signed et permet donc sans aucun réglage de tester votre application en HTTPS.

La deuxième est la limitation des ressources qui tournent sur une machine. Pow est un service prévu pour tourner en permanence tandis qu’Invoker est uniquement lancé à la demande (il est toutefois possible de le lancer en daemon).

Tout n’est cependant pas rose. Justement parce qu’il ne tourne pas en permanence, vous ne pouvez pas accéder à my_app.dev sur un coup de tête sans vous soucier de lancer quoi que ce soit. Vous ne pouvez pas non plus utiliser Xip.io (une pull-request corrigeant cela a cependant été fusionnée et sera donc dans la prochaine version).

La possibilité de lancer plusieurs applications en même temps reste une fonctionnalité appréciable de l’outil qui est en développement actif (contrairement à Pow) et nous réserve donc encore quelques surprises.

Aller plus loin

Pour en savoir plus, rendez-vous sur la documentation d’Invoker qui explique quelques fonctionnalités non abordées dans cet article comme l’ajout de services à chaud ou encore la “proxyfication” de services locaux.

Invoker ne se limite pas aux applications Ruby on Rails et peut vous permettre de travailler avec Middleman ou Jekyll par exemple.

Postgres

Pour ceux que la commande pg: postgres -D vendor/postgresql intrigue, nous n’utilisons pas postgresql sous forme de daemon et isolons nos bases de données par application grâce à la commande suivante :

cd my_app
pg_ctl init -D vendor/postgresql
Publié le 25 juillet 2014

Notre vision des choses vous correspond ? Vous avez envie de travailler avec nous ?