[Devops] May meeting

Maciej Pasternacki maciej at pasternacki.net
Wed May 30 01:35:26 CEST 2012


Hi,

Materials & links from today's meetup:

 - Code snippets with comments for the build system: https://gist.github.com/2823575
 - Vagrant, a convenient command-line tool for running VirtualBox virtual machines (VMs): http://vagrantup.com/
 - FPM (Effing Package Management), the main actor: https://github.com/jordansissel/fpm/
 - Buildbot, the continuous integration server: http://trac.buildbot.net/ (alternative for open source, Travis CI: http://travis-ci.org/)
 - Articles about setting up Buildbot by Jacob Kaplan-Moss, creator of Django:
   - Part 1, http://jacobian.org/writing/buildbot/ci-is-hard/
   - Part 2, http://jacobian.org/writing/buildbot/configuration-and-architecture/
 - Runit, a sane reimplementation of Dan J. Bernstein's daemontools under BSD-like license. A tool for managing long-running services (I'd say "daemons", but they don't daemonize – they are managed by runit when running in the foreground): http://smarden.org/runit/
 - LXC - Linux Containers, a lightweight userspace virtualization for Linux (may be used for real clean builds or for testing the packages): http://lxc.sourceforge.net/
 - The Debian Policy Manual: http://www.debian.org/doc/debian-policy/index.html#contents

FPM is a command-line tool that converts between different package formats (from: local directory, ruby gem, php pear, python module, node.js npm package, deb, rpm; to: local directory, deb, rpm, solaris, tar). The "local directory" pseudo-format allows for easy creation of quick-and-dirty packages that Just Work, short-circuiting all the layers from the Debian Policy Manual all the way up to dh_make with one quick script call. FPM doesn't care about actually building your stuff (as in: unpacking, configuring, compiling, etc). It just takes directory you put it into, and turns it into a package. To prepare the compiled files and put them in the right place first is your job. So is specifying the dependencies - there are no automatic dependencies on dynamically linked libraries.

Workflow for the continuous integration using bits & pieces from the gist:
 - On developer's workstation, "vagrant up" command brings up new VirtualBox VM with clean Debian and sets up a clone of the "packages" repository with a local branch
 - "vagrant ssh" to the VM, go to the packages repo, prepare or modify new package, test it
 - "git push" from the VM to the "develop" branch on the host server
 - "git pull . develop" on the host server's master branch to merge
 - "git push" to central git repo
 - buildbot (continuous integration server) picks up the commit
 - buildbot builds changed package and adds it to the apt repo
 - new package is available to clients via apt-get within minutes from the push.

Misc links:
Check_MK for Nagios: http://mathias-kettner.de/check_mk.html

Next meetup is on June 19th - no topic yet. If anyone has something to show / say, it's a good time for that!
See you next month!
-- M

On May 29, 2012, at 18:42 , Maciej Pasternacki wrote:

> Hey,
> 
> I'm running late and just got into a monster queue. Will be at the Lab 20-30 minutes after 7. Sorry about that. 
> 
> --M
> 
> On 21 May 2012, at 18:21, Michael Prokop <mika at grml.org> wrote:
> 
>> * Maciej Pasternacki [Mon May 21, 2012 at 05:19:04PM +0200]:
>>> There will be slides / code snippets :)
>> 
>> Great, looking forward :)
>> 
>> I'm doing lots of Debian packaging continuous integration work
>> (mostly based on https://github.com/mika/jenkins-debian-glue) and
>> also did some work with fpm, would love to chat with you about this
>> topic, so feel free to drop me a note via irc, jabber, mail,... :)
>> 
>> regards,
>> -mika-
>> _______________________________________________
>> Devops mailing list
>> Devops at lists.metalab.at
>> https://lists.metalab.at/mailman/listinfo/devops




More information about the Devops mailing list