Maciej Pasternacki

Jetpack brings application containers to FreeBSD

Jetpack is an implementation of the App Container Spec from CoreOS that runs on FreeBSD, using jails for process isolation and ZFS for storage management. I will be speaking about the motivation behind starting a new implementation rather than porting an existing one, about Jetpack's goals, the technology it uses, its architecture and implementation challenges. A quick demo is not unlikely.

Vendor everything; stay sane.

Vendorificator is a tool that manages third-party (upstream) dependencies kept in project's Git repository. Using pristine orphan branches for each dependency, Git notes to store metadata, and tags for versions, it keeps track of origin, version, license, and other details of each of the dependencies.

Vendorificator allows you to specify all of your project's upstream dependencies in one file, and keep them in your repository along with your code. Each of dependencies is kept in its own pristine branch, and annotated with metadata, so you can easily review all the upstream dependencies with version, origin, and other needed data.

Keeping each dependency in its own pristine branch lets you introduce your own patches to the upstream dependencies, keep track of them, and update any dependency to a newer version as easily as you do a normal Git merge.

Vendorificator is language-independent. It can handle Ruby gems, Python modules, JavaScript files, CSS frameworks, Chef cookbooks - all the external dependencies are specified in one place and stored together with the project.

Vendor everything. Stay safe from third-party downtimes - keep your project running and deployable when Github/Rubygems/Pypi goes down, author pulls the old version you still need to use from the "downloads" page or moves the download URL around, or you just want the project runnable out-of-the-box right after git pull, without waiting for all the dependencies to download.

In my talk, I describe a pipeline for scripting the build process of custom system packages integrated with a continuous integration system – from Git repository through the CI build server to the Apt repository available to client systems

You know you can't rely on your OS distribution's packaging for critical dependencies of your project. The release cycles never align; you're either stuck with a hopelessly outdated version of the Web server, or forced to do incompatible upgrade of the database at the worst possible moment – or both. You need to have it under your control.

Of many ways to do it, from building full-system images to compiling stuff directly on the server, building system packages is known to be The Proper Way. It lets you leverage much of the knowledge and mechanics built into your OS. You integrate with the distribution, but you're not at the whim of its maintainers and release cycles.

At the same time, building and distributing packages is something of a black art. The Debian Policy Manual PDF has 103 pages without even starting to describe the tools. I just want to package and install Logstash for myself, not have it integrated into Debian!

In my talk, I describe a pipeline for scripting the build process of custom system packages integrated with a continuous integration system – from Git repository through the CI build server to the Apt repository available to client systems. I am showing how to sanely keep up with upstream projects and manage patches. I talk about sharing and reusing packaging scripts. I also briefly touch the topic of full stack packages.

The described toolchain is built on fpm, Rake, Metarake, Evoker, Vagrant, Git, and Vendorificator - a yet unfinished utility which I plan to release as usable beta in January. While I am using the pipeline with Debian and Ubuntu, the toolchain is flexible and easily adapted to other environments.