Home > Uncategorized > APT Packaging

APT Packaging

At Sentry we originally built a lot of our servers by hand, manually installing each OS and dependency we needed to support our various software products/services. This was a very tedious task for our sysadmins and one that was very error prone. We could never quite guarantee that a new server was exactly the same as the old server it was replacing (in terms of version dependencies). Many times we would run into issues because an admin forgot a configuration step or installed the wrong version of a dependency, causing us to scramble and fix things.

We finally wised up (a demand from our CIO) to package everything and use apt for installation.  This would allow us to specify all of our dependencies in writing and have an automated way of installing them on any server we wanted. This (obviously) has proved to be a huge success.

After a year of our sysadmins managing packages, I got pulled in to help build/support our software packages. I was pretty impressed by the setup our admins put together  and thought I’d share about that here.

Anatomy of a Package

A minimal apt package contains the following files. The control file is the heart of the package. It’s common to have the post/pre files for completeness even if they aren’t used.

rvm-sentry
   DEBIAN
      control
      postinst
      postrm
      preinst
      prerm

The control file specifies the package name, version, dependencies, author, and a description.

Package: rvm-sentry
Version: 0.12
Architecture: amd64
Priority: extra
Maintainer: jheth <jheth@sentryds.com>
Depends: debian-sentry, bash, curl, git-core, build-essential, bison, openssl, libreadline6, libreadline6-dev, zlib1g, zlib1g-dev, libssl-dev, libyaml-dev, libsqlite3-0, libsqlite3-dev, sqlite3, libxml2-dev, libxslt-dev, autoconf, libc6-dev
Description: Installs RVM as Sentry expects it

The other files (marked as executable) are often just shell scripts that get run according to their names.
– preinst is run prior to the installation of the package
– postinst is run after the installation of the package dependencies
– prerm is run prior to package removal
– postrm is run after the package dependencies have been removed

Our sysadmins created a few shell scripts to automate the creation and building of these packages.  Whenever a change is committed to one of our packages (currently SVN), a server side process picks up the change, rebuilds the package, and makes it available on our internal package server.

The only thing left to do is to tell our servers where to find the Sentry specific packages.  This is done by adding a .list file to /etc/apt/sources.list.d, which gets searched during apt-get install.

echo deb http://package-server/debian stable main > /etc/apt/sources.list.d/sentry-infra.list && apt-get update

All of this has taken the guess work out of building servers and gives us confidence that a server has what it needs to run our software on top of it. These package in conjunction with our GRID infrastructure has made building and deploying our products a breeze.

Advertisements
Categories: Uncategorized
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: