The Theo Spears Blog

When you come to read this, it is probably Friday. That means it's activity day for you. Once a week I'm going to give everyone reading a small activity to do, as a break from the daily grind. I have stats on how many people read this (including via RSS) so I'll be reporting each week on what percentage of people actually do their homework.

This week: I would like you to introduce me to someone you think it would be mutually beneficial for me to be in touch with. If you really cannot think of anyone, then reintroduce me to yourself, and tell me something I didn't already know about you. Contact me via email using my address theo@smallparachute.com.

Please make sure you've done this before you continue reading.

Today was a day of choosing a task, and focusing on it to the exclusion of all else. The task in this case was building the scaffolding that will allow me to quickly deploy new instances of the open source projects I am offering hosting for. I went through a few iterations of the plan for this: (Warning, here comes geek only content)

1. Git and ruby scripting Git is a great tool for storing configuration information and copying it between machines. I'll keep all my configuration files in git, and write some scripts to generate a new set of configurations when I want to deploy a new site. Then I can run one command to update to the latest version from git, and make the required configuration changes on the server. When I want to add a new service, I'll generate the configuration files using a template, and then commit them.
   Problems This feels like reinventing the wheel, and is probably going to be more work than I think to write the scripts.
2. Git and Puppet Puppet is designed for setting up and configuring systems. (Chef is an alternative, but Puppet takes a more declarative approach, which I prefer). Puppet has a client/server setup, but I don't really want to worry about the access control and multiple servers that this requires, so I'll just store the configuration in git, and use git to push it to servers.
   Problems For convenience the git repo I am storing my config in also has the private keys to the servers and some other private information I really don't want to be available on all the servers. I can't selectively push part of a repo easily with git.
3. Rsync and Puppet Of course I don't need complete history of configuration to be actually stored on the servers, all I need there is the latest version. To just update the server with the latest version of the configuration from my local machine, rsync is the correct tool. I can just point rsync at a subdirectory, so no issues with sending files I want to keep private. I now have a nice script that rsyncs the configuration to the server, and then uses puppet to apply it. Everything locally is still versionned in git.
   Problems I still have to learn puppet.

Puppet by and large seems pretty nice, it's clearly designed by people who have run into the issues involved in administering servers, and gone about building a tool to solve them. The getting started guide, although not yet complete, is exceptionally good. Today I got as far as deploying common server packages, and setting up a per-account apache instance. (I'm going for a separate copy of apache per user to make sure changes for one user can't affect other users, and to make it easy to move installed sites between machines). Tomorrow I need to sort out installing the relevant site into apache for the user, and getting it tied into the varnish load balancer.

In other news, I now have access to office space! I went to visit Stew and Alyson at IdeaSpace today and agreed to take a hotdesking membership there. It will be interesting to see the impact that working in office space with some other people instead of alone in my room has on my mood and productivity.

If you found this interesting you should follow me on twitter