Tag Archives | docker

Yak Coiffure: Towards a better CentOS 7 Docker RPM

And oh yeah, I started a Yum repo for CentOS 7 packages


Edit (2015/05/15): This article is now historical and should be considered out of date.

CentOS Extras has updated right past my repo, and now tracks Docker releases very closely. The details of this are available on the CentOS Wiki. As such, development of the Orange Fort Docker package is suspended as it is no longer relevant. This is a good thing! The package provided by Extras should simply upgrade an existing Orange Fort package with no conflicts or weirdness — if it doesn’t, that’s a bug and you should tell me!

Original post

Let me cut right to the point: The Docker RPM provided by CentOS ‘Extras‘ repository is old. How old? Version 0.11.1 old. While the code was only tagged 0.11.1 on May 7 2014, there have been 8 releases since then.

After seeing that a friend of mine had worked up a rough go at a FPM recipe for a current version of Docker, I said “we can do this better.”

Sidebar: I love FPM but…

I do. I really do. It’s a super handy way to take something, anything, and shove it into a distributable native package. But I’m captain of the local Pedant Squad and FPM is as easy to abuse as it is to use. So… one thing led to another, Bob’s your uncle, and oh hey, I packaged up Docker 1.2.0 as a nice, tidy RPM with a nice, tidy SRPM, and a corresponding nice, tidy Spec file.

Wait… what’s wrong with the Docker RPM in EPEL?

Simply put, it’s old. Docker 0.11.1 is lacking a lot of features that you’d expect Docker to have — like DockerHub. And the spec file builds Docker from source, which is exactly what every upstream or EPEL RPM does (and that’s generally OK).

But Docker is a little bit different because it’s written in Go, and typically distributed as a single static monolithic executable (one of the real strengths of Go binaries, I think). And because Go has all sorts of weird and wild dependency resolution quirks, there’s a real chance that the resultant binary you’re getting can be markedly different than the binary that the upstream authors intended. Also, ‘latest’ is probably the version of Docker that you’re going to want to use because if you’re using Docker then you probably like to live a little dangerously.

Putin is an animal lover

One More Thing

But! We don’t just shit unsigned packages into the void like wild animals. No! We create repositories! We make Yum repo configurations! We create new GPG keys!

So, I give you Orange Fort Packages for EL7. Installing the release package gets you the repo and the GPG key, but you can just import the key into rpm‘s GPG keyring if you’re so inclined:

<code>rpm --import https://secure.orangefort.com/packages/RPM-GPG-KEY-orangefort

Are you tracking this work anywhere?

Sure am! Here’s a GitHub repo for the Docker RPM work (note that it does not include the docker binary itself). All of my work is under the Apache License, version 2.0 and I encourage you to review & reuse it any way you see fit.


Software trends that puzzle me: today, it’s ‘one-line installations’

Maybe my UNIX neckbeard is showing, but the trend of one-line installations confuses me. I guess it’s not fundamentally different than installing whatever random packages you found from some no-name repository, and no admin should be installing things blindly (packaged or otherwise). But it just seems like such an invitation to disaster because if you follow these methods to the letter then you’re executing unread scripts live across the wire. It seems like the sort of thing a developer would whip up for convenience, but I see a ton of admins embracing them now that the trend is loose in the wild.

How about some examples? With pictures!


Here’s an example from Docker, which maybe I’m interested in using for a project at $DAYJOB:

curl get.docker.io | sh -x


OK, so that’s a thing… at least it’s going run that shell in debug mode so you will see what it’s doing.

Ruby Version Manager

Here’s how RVM suggests you install it:

\curl -L https://get.rvm.io | bash


Another instance of “Grab this straight across the wire, and dump it directly into a shell! Do not pass go! Do not bother running this through any sort of sanity check!” I do like that this at least uses the slash in front of curl to make sure you’re not inheriting any aliases when you run it. I guess that that’s considerate of the maintainers?


Over in OS X land, Homebrew also has a one-line installation:

ruby -e "$(curl -fsSL https://raw.github.com/mxcl/homebrew/go)"


I like this one! “Run this curl mess in a subshell, and then feed that into Ruby. Install away!”

What’s the big deal, guy? Just runs them scripts and shuts up.


Inner monologue, you’re a jerk. None of this is a big deal. But these things bug the hell out of me. For starters, I don’t know which irks me more about all of these methods: the use of UNIX-style non-descriptive short flags instead of GNU-style descriptive long flags1, or the fact that there’s no immediately visible validation in these pipelines.

The docs for these tools always say you’re welcome (encouraged!) to download the installation scripts and read them for yourself (which I do — they’re actually very well written and they usually accommodate a lot of the sanity checks and edge cases well) but I know that there’s many, many admins and developers who don’t.

And that’s horrifying.

And it seems like part of a broader trend towards super-dickery2. Along similar lines but without falling victim to the one-line installation trend,RBenv is just sort of dickish (in a short pants, school-boy kind of way) about wanting to know what your shell is doing3.

So what?

YOU GUYS, I can’t run this stuff as-is at $DAYJOB. For any one of these examples I’m going to have to fetch that installation script and save it locally. Then I’m going to have to inspect it and work out what remote resources that script is running. Then I have to figure out how to shove these tools into packages because we version EVERYTHING through packages at $DAYJOB. Science forbid these tools make naive assumptions about their target environment (Hey RVM, storing everything in my home directory is a problem if that home directory is a space-constrained network share; let’s not even talk about I/O if there’s network congestion or disk contention on the remote filer…).

And if there’s any releases/changes/improvements made to these one-line installation scripts between when I ran them in my development environments and when someone (WHO ~~DOESN’T LISTEN~~ IS ILLITERATE) runs them in my production environments then I’ll never see them until/unless I use the one-line method (which then silently introduces the dread environment drift). Put another way, one-line installations make installing the same version of a tool across multiple environments just a little bit trickier.

But I guess that the biggest concern I have is “why did someone think this would be OK?”

  1. GNU-style long flags & options are probably my favorite contribution from the whole of old man Stallman’s GNU project. They’re fantastic when editing/reviewing old shell scripts since they save me/you/everyone we know the hassle of looking up an array of arcane short flags. 
  2. I think of super-dickery as being the act of being an asshole without provocation, based solely on the assumption that the other party is not as smart as you think you are; I am guilty of this more often than not. Also, you know, Superman is a dick. 
  3. I like a good tongue-in-cheek README and I like a strong editorial voice, but this README actually comes across as slightly derisive if you’re trying to take admin-fu seriously. I think that the line “Skip this section unless you must know what every line in your shell profile is doing” is needlessly dismissive, and that’s pants. YMMV, caveat lector, etc.