10 11 / 2011

Rails app with distributed deployment playground

While setting up Etxpress on the production box with system wide installed RVM and Resque for background processing, monitored via Upstart using Foreman export command, I had to run the following command to export the updated Procfile.production file with capistrano and custom cap deploy:foreman task.

rvmsudo foreman export upstart /etc/init -a etxpress -u deploy \ 
        -f ./Procfile.production -c worker=1 scheduler=1 redis=1 

Since the command rvmsudo is for sudoers, it asks for sudo password which capistrano cannot handle. Similarly, there are some other commands that need the sudo access as well. So, tweaking the settings directly in production and playing with cap deploy:foreman and other sudo related tasks, I’d to manually login and do service restarts.

This is not a best practice to test or play with deployment settings directly on the production box. So, to simulate the same environment and process, here the Vagrant and Chef come in.

The idea is to host a Gitlab as a Github repo in one VM, launch another VM to simulate the production box and setup the multistage capistrano recipe to test and experiment.

Local Deployment Diagram

It will be a long post. So, I’ll be blogging in the following series:

  1. Setup Gitlab as a Github repo hosting
  2. Setup a production box in another VM
  3. Setup capistrano multistage to test the deployment

To automate the process, we’ll be using vagrant to launch VM(s) and chef-solo for provisioning. I might do another post using chef-server to make it more automated.

Without further ado, here is the first part of the series: Setup Gitlab as a Github repo hosting using vagrant and chef-solo.