How to deploy servers using Continuous Delivery | Three Drunken SysAds. OK, it’s May the fourth as I’ve started to write this and I couldn’t resist the title, but I hope that this first post in what I aim to deliver as a series of tutorials will help you move towards full testing, integration and deployment of your systems and turn what could be a five hour manual build and deploy routine into a single code commit. The Toolbox Whilst a bad workman may well always blame his tools, a good workman recognises the best tools out there and makes sure he’s using them.
This series will focus on the tools that I have found to be best for me, however (as always!) Your mileage may vary. Puppet Written in ruby and with a very strong community around it, puppet is a centralised way of distributing and maintaining system state in a secure manner. Git Git is a distributed Source Coded Management system. The Marionette Collective The Marionette Collective (or MCollective for short) is the brain-child of R.I. Jenkins Jenkins is a Continuous Integration (CI) Server. Capistrano. Blt/puppet-git. Hunner/wordpress. Debian Apache2 Recipe Patterns. This recipe helps you manage sites and modules for apache2 in a default Debian (Etch) installation. It might work on other systems too! Be sure to edit the wiki if it works for your non-Debian setup. Problem¶ When you run several loadbalanced webservers with a lot of websites, it can become quite difficult to maintain all the sites and modules that are needed. This recipe creates a few components that help you better maintain all this.
It should work even better if you incorporate this with templates for the actual site configs. Solution¶ Use these components in your webserver class: Add your own recipes for actually including the stuff you want included: NOTE: Don’t forget to add the config files! Another Solution¶ Another solution based on the code above — indeed, the one in production use at www.wesabe.com — can be found at: /! Discussion¶ I’ve replaced the check with /bin/readlink -e ${apache2_mods}-enabled/$name}.load.
Autosigning Client Certificates. Challenge You want to autosign any new client certificates that are sent to the puppet master. Be sure to understand the lack of security this presents. Solution $ cat /etc/puppet/autosign.conf * Explanation By adding a single * to the autosign.conf file you tell the puppet master to accept the first certificate it sees for each client host. To reiterate - having this option enabled may seem like a time saver but the risk is that any machine can connect without authorisation and request your manifests, which may contain privileged information such as passwords, certificates, shared keys etc.
See also Puppet SSL explained by Brice Figureau. Simple way to keep your Puppet master in sync with your Github repository. I keep the contents of /etc/puppet on my Puppet master server in a Github repository; whenever I push to the repository, the Puppet master server automatically gets all of the latest changes. To do this, I created a github-puppet.php file in my webroot, then set the URL of that file as a Post-Receive URL (under Admin - Service Hooks in Github's web interface). Here's my script - obviously this could be a CGI script or written in some other language, PHP just happened to be available for me: I also set the following in my /etc/sudoers file to allow the Apache user to run git - this could be improved, very insecure the way it is now! Apache puppet = (root) NOPASSWD: /usr/bin/git apache puppet = (root) NOPASSWD: /bin/touch.
Complete Configuration. To get a feeling what can be done with puppet, take a look at the git repository of David Schmitt. He develops webhosting automation and publishes his manifests and modules under the liberal BSD License. Get it¶ Either go to his gitweb or create a local clone. The “manifests” repo contains a complete configuration, to put in $confdir (generally /etc/puppet). $ git clone davids-manifests Modules are in the process of being split from the manifests repo into their own individual repositories. . # common prerequisite $ git clone /etc/puppet/modules/common # virtual machine support $ git clone /etc/puppet/modules/virtual Modules¶ Code Samples¶ Here some points of interest which might give starting points to explore the manifests and modules.
Configuring a simple Node¶ Configure the BackupPC Server: From manifests/site.pp: Hosting¶ From manifests/site_hosting/davids.pp: On the munin host: Patterns. Sts.ono.at/blog/2010/12/22/synchronize-puppet-with-git/ Project Source Puppet really shines at automating infrastructures. You will notice a sudden change of working methodology, once you manage the first systems with it. Instead of manually logging on to each single system for updating a certain part of configuration by issuing shell commands, you will stop to repeat yourself and just update a single piece of code, which describes the desired config state for all systems.
As recommended in the Puppet documentation you are well advised to keep your Puppet manifests under revision control. I wrote a small script which will come in handy, to ease your life with keeping your repository and the manifests on the master in sync and should fit to most of the environments out there. Once installed, you can store the manifests for each Puppet environment in its own GIT branch and every time you commit a new version to one of your branches, it will automatically sync the most recent version and inform the Puppet master process. ... Puppetlabs/mcollective-nettest-agent. Using Puppet to Manage Users, Passwords and SSH Keys - IT and ME.