Last week (March 31st 2014), I launched the public beta of Packager, a service that generates debian packages for your apps using a Heroku-like workflow. It went well, and so it seems people are still interested in 'old-school' packaging.
There were good comments on the HN thread (including by docker co-founder @shykes), so I wanted to take a moment to explicit things about Packager, why it is an interesting way to distribute apps, and where it is headed. Please read on.
Where does Packager fit into the existing ways to install apps?
When it comes to the workflow for installing your apps, you're likely to fall into one of these camps:
- Install everything from source (or use RVM, ruby-build, etc.) - painful, slow, and you'd better keep track of security fixes for all the stuff you're building from source. But sometimes this is the easiest way to go.
- Package all your dependencies as separate debian packages (see fpm, gem2deb, etc.) - somewhat organizes things, but this is a painful process as well, and you probably need to setup and maintain an APT repository to host those packages.
- Vendor everything (Omnibus) - Well, now it looks like you've got a cloned OS to maintain yourself, but you're "in control".
- F*** it, I'm going to use Heroku instead. An entirely different discussion (vendor lock-in, price, privacy, etc.).
Packager fits between the 'package-all-my-dependencies' and the 'vendor-everything' approaches. It relies on the distro's packages for what could be deemed as "stable dependencies" (libc, libxml, libmysql, etc.), while the things that are most specific to your application are vendored.
For a Rails application for instance, the Ruby runtime (the specific version you asked for) and all of your gems (at the exact versions specified in your Gemfile.lock) will be embedded into the package. This is what Heroku is doing, and at Packager we're actually re-using their buildpacks (sometimes with slight variations) to generate the packages.
I think this strikes a good balance between OS packaging requirements (stable, reliable, but slow to include new stuff), and the requirements of Application packaging (fast delivery, with the best runtime available, and the latest and greatest libraries). To put it a bit differently: You don't necessarily need the latest libc available, but you certainly want to use the latest version of Rails.
Compared to Omnibus packages or installing everything from sources, this limits the security maintenance mainly to the runtime, which is definitely more manageable.
What about docker?
docker is fantastic, and it actually powers the build system of Packager. That being said:
- It does not solve the installation issue. You still have to make a decision as to how you're going to install things in your docker image. Actually, docker and Packager are not mutually exclusive, as you could easily install your app in your docker container by using a package generated by Packager.
- It requires additional steps to setup, and additional operational knowledge to maintain it.
- Not deployed (yet) on all of your end-user machines.
apt is still the easiest way to install stuff on debian-based machines.
docker is getting a lot of traction (deservedly so), but I'm convinced there is still a place for 'classic' packaging in a lot of cases.
Next steps for Packager
-
Reduce scope
Packager launched with many default buildpacks, most of which were not thoroughly tested to make sure they worked on all distributions. Since it is a lot of effort, for the time being I'm going to focus on the runtimes I know the best: Ruby and NodeJS. You'll still be able to specify another buildpack (see the doc), but it is most likely to fail. Additional buildpacks will be enabled once I'm sure they work reliably.
Another aspect is the target matrix, which up until now included the old stables of Ubuntu (10.04 - lucid) and Debian (6 - squeeze). Support for these distributions is dropped as of today, as I want to make sure the generated packages are working great on the current stables.
-
Add more apps to the showcase
I'm working on packaging well-known OpenSource Ruby and NodeJS apps, to be displayed in the showcase. Gitlab is well underway, but please contact me if you wish to get your app packaged (only Ruby and NodeJS apps for now).
-
Enable private projects
This is already supported by the service, for Github projects, albeit not enabled yet. However, I get the sensation that many private projects in need of Packager may not be hosted on Github. I would love to know more about your needs, so if you're interested to use Packager for packaging your private project(s), please take two minutes to answer this survey (4 questions). Thanks!
If you have further questions, please do not hesitate to say hi at support@packager.io, or @crohr on twitter. You should also follow @hellopkgr to get the latest news.
Update: happy to take any questions on the HN post at https://news.ycombinator.com/item?id=7546327.
