Distribute Native Packages

date:Aug 28, 2014
author:Trevor Bramwell

As a system administrator I deploy a lot of code. As web developer I write a lot of code. Yet these two parts of me are always at odds.

When working on web applications the system administrator in me says “Just ship it!”

_images/shipit.gif

While the web developer screams “It’s not perfect yet!”

_images/perfect.gif

And when the code finally gets deployed, things inevitably fall over in the process.

_images/unmaintain.gif

My years of experience being both a developer and system administrator have taught me that the best way to distribute applications is by using native packages.

Turning unmanagable deployments...

_images/bad_package.gif

into well oiled machines.

_images/good_package.gif

Native packages provide three major benefits over other deployment strategies:

  1. Security
  2. Modularity
  3. Maintainability

1. Security

The first benefit native package provide is security. This is an optional benefit, as signing packages does not preclude them from being deployed.

Every time I have to install RVM, I die a little inside.

The RVM website provides a single method of installation:

$ \curl -sSL https://get.rvm.io | bash -s stable

This is horribly insecure, dangerous, and the definition of remote code execution.

Though RVM encourages installation over HTTPS, SSL is not enough security for software distribution, because does not verify the integrity of the content.

By using signed native packages instead, you can verify two things:

  1. The package contents haven’t changed since it was created.
  2. The package can only have come from the owner of the signing key.

This is because servers installing the package will already contain the author’s public key.

2. Modularity

Modularity is the second benefit native packages provide.

Native package create modularity by providing a clear distinction between the build and deployment steps of a web application. This leads to a highly scalable and continuously deployable application, which falls in line with The Twelve-Factor App definition.

Applications that don’t have a clear distinction between these processes tend to have deployments that organically grow into complex monstrosities.

This complexity can be seen clearly around the upgrade and rollback processes. Modularity comes from taking these processes and sectioning them into before/after install and remove scripts. Instead of being ran by an external process that requires elevated privileges to a production server, these scripts - which are packaged with the application - execute during upgrades (installing a new version) and rollbacks (downgrading versions).

3. Maintainability

The final benefit native packages provide, is maintainability.

Instead of maintaining complex execution definitions or a plethora of SCM resources in configuration management, system administrators have only to write a few simple resources: install application, upload configurations, restart services.

This leaves them with more time to fix important issues (like putting out fires), and keeps them from having to spend multiple hours deploying new versions.

Where it All Breaks Down

Even with all these benefits, native packages are not a silver bullet.

A new (but simple) piece of infrastructure will need to be setup to host package. If binaries are being signed, public keys will need to be shipped with server images, and signing will need to be integrated into the build processes. Migrating existing deployment architecture will take time, along with the creation of packaging scripts.

And finally, multiple packages may need to be created for any server that runs multiple versions of an application.

Concluding Remarks

If learning rpmbuild or debuild feel like it requires a robe and wizard hat (because it surely does), tools like fpm make building packages extremely simple.

Overall native package managers provide web application with greater security, modularity, and maintainability. They also reduce deployment times, and make system administrators lives easier. And even though they introduce a new set of problems, theses can be resolved with few extra resources and a little bit of time. The benefits of distributing native packages far outweigh the costs, and will eventually save large amounts time spent on development and administration.

Table Of Contents

Previous topic

Field - extract fields from a file

Next topic

Getting Started In Open Source

This Page