I’ve been playing around with Capistrano over the past few weeks and I’ve recently created a way to use the power of Capistrano’s “deploy” and “rollback” features with Puppet and MCollective to enable me to have complete control over the deployment of my system configurations.We’ll start with Capistrano as it’s the key to all of this – you’ll need the following gems installed:
I’ve taken to having minimalist cap files so “cd” into your puppet manifests and type the following:
Now edit the Capfile so it looks as follows:
We’re also going to use the ‘multistage’ extension to make sure that we only deploy to our production environment deliberately, so update the config/deploy.rb file and make it look like this:
Note that the stages need to be set before you include the multistage extension otherwise they won’t get setup.
If you now run cap -vT then you should see the following amongst the other tasks:
cap production # Set the target stage to `production’.
cap staging # Set the target stage to `staging’.
This means that we can now run “cap staging deploy” or “cap production deploy” depending on what we want to do. Note also that we set the default stage to staging so that we have to explicitly state when we want to deploy to production – this will hopefully cut down on any accidental incidents of untested configs making it to the live servers!
Finally, note that we’ve disabled sudo – this makes things more secure (you can’t have your deploy user executing random code on the servers!) and also makes it easier to configure the server (no editing of /etc/sudoers).
The next step is to create the user account on the puppetmaster for deployment. For simplicity’s sake, we’ll create a user called “deploy”:
root@puppetmaster # useradd -m deploy
And assign it ownership of the puppet manifest directory (/usr/share/puppet/configuration in our case):
root@puppetmaster # chown -Rvf deploy: /usr/share/puppet/configuration
Puppet doesn’t care about write permissions to the manifests/modules directories as far as I can tell so as long as the “puppet” user can read the manifests/modules, we’re all good.
Now setup the access for the user. I have deliberately not set a password for this account as I use ssh-keys which are not as easily brute forced!
root@puppetmaster # su – deploy
deploy@puppetmaster > vim ~/.ssh/authorized_keys
Place the public SSH key of the user who will be running the “cap production deploy” command into the authorized_keys file listed above.
A quick gotcha: if you’re going to use a staging server with SSH keys, make sure that the key of the user account running “cap production deploy” is on both the gateway server and the puppetmaster, otherwise this will fail!
SSH to the puppetmaster as your deploy user from the account that will be running “cap production deploy” so that you don’t get any SSH-Key errors.
Now setup your config for the staging environment in config/deploy/staging.rb:
and do the same for config/deploy/production.rb:
This means that we can over-ride the “defaults” from deploy.rb for each environment.
You may have noticed the following line:
after ‘deploy:symlink’, ‘puppet:run’
This executes a custom task in a custom namespace once the “current” symlink has been updated to force a puppet run. The issue at the moment is that this task doesn’t exist yet!
Update config/deploy.rb to look like the following:
The important bits to pay attention to are the “require ‘mcollective’ ” (which loads the MCollective libraries) and the MCProxy class (thanks to @ripienaar for helping me with that!).
The MCProxy class enables us to create the puppet:run task and call the “puppetd” agent – note that you could call any agent with any argument you want here, we’re just calling the puppet one.
Now, I’ll leave the rest of the configuration to you (setting up SSH keys/users etc.) however when you now run “cap production deploy” you should see your puppet configs getting checked out of git and SCP’d via the gateway to your puppet master followed by MCollective executing a puppet run across your entire server estate.
The final task is to configure puppet to read the new configs. I’m assuming that you have all your manifests in one huge repo here, so just update your puppet config to point to the correct directory:
If you don’t know Capistrano, “current” is a symlink which gets updated everytime you successfully deploy/rollback. Puppet won’t let you set /etc/puppet as a symlink, so you have to adapt the configs to point to the “current” release of your configs.
Now do the inital setup:
cap production deploy:setup # creates the directories required
root@puppetmaster # service puppetmaster restart
and deploy the first version of your modules:
cap production deploy
Let me know how you get on…
Good article. I’ve spoken to quite a few people doing something similar although often not with mcollective and importantly not shared for everyone else to learn from. Thanks for posting. Few comments:
I’m setting paths in puppet.conf for modules and manifests like so:
modulepath = /usr/share/puppet/configuration/current/modules
manifestdir = /usr/share/puppet/configuration/current/manifests
I’m pretty familiar with capistrano, so knew what to override and add. But it’s might be worth being more explicit for anyone not using cap. For instance stating that you have to change puppetmaster to the domain of your puppetmaster here:
role :web, “puppetmaster”
Other cap things would include the need to run cap production deploy:setup (or creating the required files via puppet) before any of this will work. And needing to create the deploy user with the relevant permissions.
Hi. What is the version of puppet do you use in “deploy-and-roll-back-system-configs-with-capistrano-mcollective-and-puppet”?
This was all done with Puppet 0.26, I’ve not tried with later versions.