Tag Archives: vagrant

Services that needs /vagrant to start

I have a set of recipes that I use to build the environments from the local developer desktop up to production. The background is provided in my last post.

One of the differences between the Vagrant environment and the other ones, is that HTTP apps have their web server DocumentRoot pointing to the /vagrant directory. This directory is available later at boot time, after the web server is started (at least with Apache in CentOS, I don’t remember in Ubuntu right now). The web server doesn’t start because the directory isn’t available.

To fix this, I use Upstart and its event system. Looks at this file (/etc/init/apache-vagrant.conf):

start on vagrant mounted

task

script
service httpd start
end

This script catches the event vagrant-mount, that is triggered when the /vagrant folder is ready to use. In this way, you execute the command to start Apache.

Let me know if you find a better way to do this.

Post to Twitter

Automation from the developer and up

Since last week’s discussion with colleagues and clients about automation, I’ve been talking about a process I commonly use and I think it should be part of DevOps’ processes. When we start to code our infrastructure for a new application, our starting point should be the environment used by the developer and then should finish in production. Let me explain further.

Vagrant has became very popular for managing local development environments via virtual machines. It has a functionality called “provisioning” that uses existing automation tools to install and configure all of the software inside the VM. You can use your preferred tool: Scripting, Chef, Puppet, Ansible, and SaltStack (my preferred tool these days). This gives us the opportunity to create an environment for the developer similar to test, qa, staging and production servers. There will be some differences obviously. The database in the developer desktop will be in the virtual machine itself, but it could be in different servers in the other environments. It’s possible that some security settings will be different too.

The most important part of this idea is that the developer will use the same software, the same versions, and the same configuration that we will use in all the stages up to production. I have a habit of starting to code the automation in Vagrant on my local machine, then giving the results to the developers as the first beta testers. If that works for them, then I start to create all of the servers that will run the application.

DevOps culture involves (among other things) two processes: communication and automation. The last one is clear – we are doing it using these tools – but the first one (the most important one) begins when the developers define the requirements, test their local environment, and provide feedback. We provide an environment with our infrastructure standards and, in exchange, we receive information about issues where the application is being created. If the developer changes something inside the virtual machine, the change should be reported to us so we can adjust our automation recipes. This would get the feedback loop working from the very beginning.

I forgot to mention the collaboration element of this process. It impossible to use this process successfully without it.

This process provides positive results in my experience, reaching production environments with a few issues. All of the issues are discovered within the first few stages of all this process. I hope it helps you as much as it has helped me.

Post to Twitter