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
service httpd start
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.
One year ago I started to use SaltStack. I have experience using Puppet for a long time, but a client was using Salt so I had to learn it. After a year using it, this is why it’s my preferred automation tool:
- Simple syntax, you define the state of your servers, files, pkgs, whatever using YAML files.
- You can apply your recipes on demand. You run a command and all the changes are applied at the moment. You don’t need to wait for polling.
- Integrated remote execution. It’s in the core, you need anything external.
- Cloud support. Salt cloud it’s part of the core right now. You set your credentials, you tell how many instances you want and salt-cloud will launch them, it will connect with the salt master automatically. Again, you don’t need anything from outside cloud.
- Flexibility, it’s really flexible. You can code custom modules in Python easily to customize everything according to your needs.
- Orchestration thanks to overstate. Overstate allows you to apply recipes in your server in a specific order. For example, database servers first, then app servers.
- The project is young, but it’s growing and growing. The number of bug reports, features requests and the fixes and enhancements on every version are impressive.
There are more reasons that I’m missing for sure.
You can see an example of something done using Salt here. It’s an example of a MongoDB cluster managed by Mongo. Let me know if you have questions about it.
A few months ago, I had spare time and I wanted to combine my experience in the last year with MongoDB and SaltStack. The result is Elastic MongoDB, an example of orchestration/automation to setup a MongoDB cluster with replication and sharding using Salt. The instructions to launch are in the README, it should be running in a few steps. There is only an issue, you have to run the salt \* state.highstate command three of four times to get everything working. That’s because there are some dependency between the boxes, so the setup should be in some order. By default, Salt applies all recipes at the same time, generating failures. To fix this I have to use a feature of Salt called overstate, but I haven’t had time to implement it.
I’ll fix when I have some time, but anyway you can try it. Have look here.
Fell free to ask any question!