Foreman and SOA services

For the longest time I was fighting the problem of having the problem that ease
of development setup and composing my apps of different services seemed to fight
each other, but recently I discovered not only one but actually 2 solutions,
Foreman with
Subcontractor as well as
Vagrant.

First a little background: Imagine a very basic app, which relies on another
service to provide some functionality, my always happy to jump in example would
be a rails app which relies on websockets via faye. Of course to develop
locally, which I always prefer, I need to run both on my machine or else the app
will not be fully functional. So far I’ve been always starting the faye server
and the rails app separately, and of course forgetting to start the push server
from time to time and wonder about failing integration tests. So much for the
setting now the solution(s).

First vagrant: It provides a virtualized environment to run the apps, and relies
on Virtualbox to do so. It’s pretty simple to setup a machine which has both
services running at boot which solves the problem. The issue I have with that
is that I am not sure if I am ready to take the performance hit to run
everything virtualized. Also developing in either the VM, and migrating my
vimrc between every project is not really feasible, and mounting is slow.

Foreman to the rescue, foreman allows you to package the whole setup of what
needs to be running to make your app work in one nice file, the Procfile. The
problem has been for me that running a second rack app inside foreman is not
really possible, but this is what subcontractor is for, it lets you
specify which separate ruby apps need to be running with which environment

Procfile.development

push: subcontract --chdir $PUSH_PATH --signal INT 
      -- env BUNDLE_GEMFILE=$PUSH_PATH/Gemfile bundle exec 
      rackup config.ru -s thin -E $PUSH_RACK_ENV -p $PUSH_PORT

This means that all you need to do is specifying all service dependencies in a
Procfile and that run

foreman start -f Procfile.development

This allows even complex service setups to be run as needed.

Enjoy!

Fixing the restart for faye upstart foreman and thin

In a little test project of min I manage rails deployment by using a combination
of capistrano, upstart and foreman. This
means as soon as I run


$ cap deploy

foreman is exporting the current Procfile to upstart scripts and copies those
to the correct locations for deployment on my ubuntu server, to restart the app
after the deployment capistrano now runs


$ service APPNAME restart

This works perfectly fine as long as all services restart nicely, but I ran into
a problem while setting up faye to allow push in the
app. Now since there is a connection between thin (my appserver) and faye, thin
will not shutdown gracefully as soon as upstart tells it to, which in turn means
faye will not shut down as well… ok so my app server will take a lot of time
to restart which is not that nice. To get rid of this problem I created a small
rake task to shut down the thin servers before the restart phase, this fixes the
“deadlock” (not really a deadlock I know but oh well). So here it is

https://gist.github.com/3434628.js