https://launchpad.net/ does this too (though just for Ubuntu distros). It's quite nice and a pretty impressive service, considering it's provided for free.
One edge-case, where fpm cannot help by itself, occurs in the python (w/ C-bindings) world, when your dev and prod environments use different libc versions. I got around that issue by running fpm inside a VM, which matches the libc version of the target system.
But it's still not as easy as it can be - so pkgr.io looks promising.
OP here, thanks for the comment. fpm is a great tool: PKGR is based on https://github.com/crohr/pkgr, which itself uses fpm. That being said, you indeed need to make sure your build system is close to your target system, and it is not that easy to package complex apps with specific dependencies. Generally, (Web) Application packaging does not have the same needs as OS packaging.
As a Rails developer, I've become tired of messing with
ruby versions, gem dependencies, bundle installations,
deploy-time asset precompilation on my servers,
etc. ... Basically, what I wanted was a Heroku-like
workflow that generates and hosts debian packages,
which is what exactly what PKGR provides.
As a customer of Heroku's excellent but rather expensive services, and a fan of deployment via package management, I'm certainly intrigued.
Unfortunately checkinstall has an inconvenient bug on (at least) Debian Wheezy which makes sudo required for package building under some circumstances.
My first thought was that there was no way I'd want to make my deploys dependent on yet another random webservice. But it looks like there's a standalone version, too. https://github.com/crohr/pkgr
"Uses Heroku buildpacks to embed all your dependencies within the debian package. That way, no need to mess with stale system dependencies"
That does mean, however, that it's now your job to rebuild your package whenever a library gets a security fix. Possibly worth the sacrifice, but an important one I think people need to understand.
OP here. Totally right, the final goal being that a new version of the package gets automatically rebuilt whenever a buildpack gets updated with a security fix.
Not sure whenever this is a good service or not (proper Debian packaging is 10% writing scripts 90% reading and conforming to policies), but I believe it would be really better if it'd be able to produce and maintain "debian" branch and tags for pbuilder/git-buildpackage, so standard package building practices would apply.
Pkgr (and fpm, the program it uses) is not for shipping a package that people can install and depend upon as part of their own OS distribution. It's for using apt-get as your orchestration system, instead of puppet/chef/etc.
You package your application and its dependencies as .debs, create an apt-mirror containing those debs, add that apt repo to your deploy-targets' sources.list.d's, "apt-get install yourcorp-system-release", and relax.
You have the possibility to add custom before/after hooks, and thus upload freshly precompiled assets from them, however there is currently no secure way to encrypt secrets (in your case, S3 credentials). This may come later on (a la Travis-CI, http://docs.travis-ci.com/user/encryption-keys/), but is not a priority right now.
Missing the neat config interface of pkgr (and the build service obviously!) but it's fully supported by Debian/Ubuntu now (used to build almost all of their ruby app and library packages).
At launch, only Ruby and Node.js projects are officially supported. But you can always specify another buildpack in your app's configuration to test with other runtimes (https://pkgr.io/doc#buildpack).
Installing dependencies for web apps at the system level is usually the wrong thing. You may have a deb but now you are prone to conflicts between that deb and the distro's debs.
OP here. For all the goodness offered by Docker to deploy apps, sometimes a good old debian package is all that's needed. The format is widely supported and battle-tested, while Docker requires specificities under the form of kernel version, additional software to install, and additional operational knowledge.
In short, if you already have a working Docker installation, you probably don't need PKGR, though nothing prevents you from building your containers by simply apt-get install'ing the app instead of having 10's of RUN commands to install the dependencies.
[+] [-] blinry|12 years ago|reply
It builds the packages on virtual machines for many different distributions and 32+64 bit CPUs.
[+] [-] baldfat|12 years ago|reply
Hope people will just "get it" soon!
[+] [-] comice|12 years ago|reply
[+] [-] mtrn|12 years ago|reply
One edge-case, where fpm cannot help by itself, occurs in the python (w/ C-bindings) world, when your dev and prod environments use different libc versions. I got around that issue by running fpm inside a VM, which matches the libc version of the target system.
But it's still not as easy as it can be - so pkgr.io looks promising.
[+] [-] crohr|12 years ago|reply
[+] [-] bguthrie|12 years ago|reply
[+] [-] wting|12 years ago|reply
https://github.com/progrium/dokku
[+] [-] takeoutweight|12 years ago|reply
http://manpages.ubuntu.com/manpages/trusty/man8/checkinstall...
[+] [-] regularfry|12 years ago|reply
[+] [-] jamesgeck0|12 years ago|reply
[+] [-] comice|12 years ago|reply
That does mean, however, that it's now your job to rebuild your package whenever a library gets a security fix. Possibly worth the sacrifice, but an important one I think people need to understand.
[+] [-] crohr|12 years ago|reply
[+] [-] drdaeman|12 years ago|reply
[+] [-] derefr|12 years ago|reply
You package your application and its dependencies as .debs, create an apt-mirror containing those debs, add that apt repo to your deploy-targets' sources.list.d's, "apt-get install yourcorp-system-release", and relax.
[+] [-] jlafon|12 years ago|reply
[+] [-] crymer11|12 years ago|reply
[+] [-] crohr|12 years ago|reply
[+] [-] jjgreen|12 years ago|reply
[+] [-] phaer|12 years ago|reply
[+] [-] YokoZar|12 years ago|reply
[+] [-] comice|12 years ago|reply
Missing the neat config interface of pkgr (and the build service obviously!) but it's fully supported by Debian/Ubuntu now (used to build almost all of their ruby app and library packages).
[+] [-] otterley|12 years ago|reply
[+] [-] krupan|12 years ago|reply
[+] [-] crohr|12 years ago|reply
[+] [-] pekk|12 years ago|reply
[+] [-] mwcampbell|12 years ago|reply
[+] [-] qbonnard|12 years ago|reply
[+] [-] crohr|12 years ago|reply
In short, if you already have a working Docker installation, you probably don't need PKGR, though nothing prevents you from building your containers by simply apt-get install'ing the app instead of having 10's of RUN commands to install the dependencies.
[+] [-] pandemicsyn|12 years ago|reply
"The easiest way to get a debian package out of any app"
Basically you push up to the service and it takes care of building a debian package for you and provides an apt repo to pull from.
Usually you end up having to do some permutation of https://wiki.debian.org/HowToPackageForDebian
[+] [-] jafaku|12 years ago|reply
[+] [-] maslam|12 years ago|reply
[+] [-] brokenparser|12 years ago|reply
[+] [-] tomswartz07|12 years ago|reply
Does anyone have any suggestions for other platforms? Perhaps Windows, OSX, etc?
[+] [-] baldfat|12 years ago|reply