Think!

One day, out of the blue, I get a mail from one of my B'lore team members that a conference by the name of RootConf is being held for system admins. Considering the time and effort we have spent on setting up our own cloud and its monitoring, from scratch, we were expected to submit proposals. Now I'm thinking "Why will anyone want to hear me speak?? After all, there will be seasoned speakers and experienced admins attending the conference". After some thought I decided "There ain't anything wrong in submitting a proposal. Who knows, it may not even get as many votes to be featured as a talk". So, fearlessly, I typed down my proposal topic - "Infrastructure Monitoring using Chef and Nagios". Sounds deep doesn't it! Well when my mentor saw it he had no reaction. According to him, the topic din't catch his eye.. Of course it din't! For him its a day's work but for me it took weeks to achieve it! A seasoned speaker hi

There came a time in our team where we started churning out cookbooks by the hour. Now the question that needed to be answered was - How does one QA a chef cookbook. We could either have had one team member solely responsible for writing out rspecs and testing the cookbooks on a virtual environment, but what happens when the only team members who can be used to perform the above task as busy creating the cookbooks themselves. We needed a faster and smoother answer. In came Vagrant. Well Vagrant does everything that one would need to do to set up a virtual environment without wasting time in installations, snapshots, teardowns etc. Vagrant gives us one file "Vagrantfile" that needs to be configured with the environment that needs to be set and voila! everything works like you want it to. The standard (read easiest) way to use vagrant is as below. Create a directory where you want to store all your vagrant data, I call it vagrant. Then download the boxes that you need in y

After creating the Ruby on Rails application mentioned in my blog , the next task was to deploy the application to a hosted web server. The traditional way would be to write rake tasks and trigger them manually or using a CI build/deploy. Well chef provides another easy solution to deploy an application. The recipe below performs all the tasks of deploying an application. The before_migrate script contains the tasks that need to be performed before the application kicks in. The migration_command is the final command that is run to mark deployment successful. deploy_revision is used to make sure that the recipe would only be executed once the git head changes in the repository from the last deployed version. symlink_before_migrate can be used to create symlinks to the yml files used in the configuring the application. The deploy cookbook for a basic app looks like below app_user="user" deploy_dir="/opt/application_deploy" user app_user directory "/home