Archive for the ‘puppet’ Category
I’ve been playing with juju for a few months now in different contexts and I’ve really enjoyed the ease with which it allows me to think about services rather than resources.
More recently I’ve started thinking about best-practices for deploying services using juju, while still using puppet to setup individual units. As a simple experiment, I wrote a juju charm to deploy an irssi service  to dig around. Here’s what I’ve found so far . The first is kind of obvious, but worth mentioning:
Install hooks can be trivial:
#!/bin/bash sudo apt-get -y install puppet juju-log "Initialising machine state." puppet apply $PWD/hooks/initial_state.pp
Normally the corresponding manifest (see initial_state.pp) would be a little more complicated, but in this example it’s hardly worth mentioning.
Juju config changes can utilise Puppet’s Facter infrastructure:
This enables juju config options to be passed through to puppet, so that config-changed hooks can be equally simple:
#!/bin/bash juju-log "Getting config options" username=`config-get username` public_key=`config-get public_key` juju-log "Configuring irssi for user" # We specify custom facts so that they're accessible in the manifest. FACTER_username=$username FACTER_public_key=$public_key puppet apply $PWD/hooks/configured_state.pp
In this example, it is the configured state manifest that is more interesting (see configured_state.pp). It adds the user to the system, sets up byobu with an irssi window ready to go, and adds the given public ssh key enabling the user to login.
The same would go for other juju hooks (db-relation-changed etc.), which is quite neat – getting the best of both worlds: the charm user can still think in terms of deploying services, while the charm author can use puppets declarative syntax to define the machine states.
Next up: I hope to experiment with an optional puppet master for a real project (something simple like the Ubuntu App directory), so that
- a project can be deployed without the (probably private) puppet-master to create a close-to-production environment, while
- configuring a puppet-master in the juju config would enable production deploys (or deploys of exact replicas of production to a separate environment for testing).
If you’re interested in seeing the simple irssi charm, the following 2min video demos:
# Deploy an irssi service $ juju deploy --repository=/home/ubuntu/mycharms local:oneiric/irssi # Configure it so a user can login $ juju set irssi username=michael public_key=AAAA... # Login to find irssi already up and running in a byobu window $ ssh email@example.com
and the code is on Launchpad.
 Yes, irssi is not particularly useful as a juju service (as I don’t want multiple units, or relating it to other services etc.), but it suited my purposes for a simple experiment that also automates something I can use for working in the cloud.
 I’m not a puppet or juju expert, so if you’ve got any comments or improvements, don’t hesitate.