by balou on 2/21/14, 9:43 AM with 12 comments
by grosskur on 2/21/14, 12:03 PM
There are some pitfalls, however:
* It can be time-consuming dealing with the arcane details of Debian package metadata or RPM spec files. If you're deploying your own application code, you're likely better off using fpm to generate a package from a directory tree:
https://github.com/jordansissel/fpm
* If you have a complex stack, e.g., a specific version of Ruby and a large number of gem dependencies, you should avoid trying to separate things into individual packages. Just create a single Omnibus-style package that installs everything into a directory in /opt:
https://github.com/opscode/omnibus-ruby
* Maintaining build machines and repository servers takes ongoing effort. Shameless plug: This is why I created Package Lab---a hosted service for building packages and managing repositories. Currently in private beta and would love feedback:
by onli on 2/21/14, 10:51 AM
For reference, it is not. Packages solve a different problem, and he even writes it: Well made packages with dependencies enable everyone to use the software, regardless of the involved system, given some constraints. They don't need to be fast and they don't need to be easy (as much as I would like them to), because they are used by specialists in a lengthy process.
But if one deploys code on a system, we know a bit more of the system than "it is a computer". Maybe it is a standardized production instance, maybe it is a vm - in any case, we have direct access. So it is possible to use easier and faster methods to deploy code directly, without having to resort to arcane voodoo.
If you really want to use debs for deployment, at least use checkinstall and handle the dependencies manually. Then you need at most 3 command (./configure, make, checkinstall).
by lamby on 2/21/14, 10:46 AM
You can also make your app quite modular - you can build multiple binary packages from one source which is perfect for different server roles that share a lot of code or configuration.
The only drawbacks are the fair amount of knowledge you need to share within your team, as well as quite a bit of machinery needed to get everything up and running once you move beyond a single "dpkg -i"-able .deb (some sort of APT repo, signing keys, blah blah).
by datr on 2/21/14, 10:45 AM
1) Clusters of application servers, where I will only want operations on shared resources to fire from one of the servers? E.g. database updates, shared file changes, etc.
2) When I want to deploy the code to a different location on the server so that I can have multiple versions of the application available? Do I have to spin up new servers for each version?
3) You mention roll back by just specifying an earlier package but I don't see how this would work with stuff like database changes either.
by ABS on 2/21/14, 11:02 AM
by olgeni on 2/21/14, 12:44 PM
(even more so after rewriting Erlang packages to get something that a) works and b) is not stale)
by balou on 2/21/14, 9:44 AM
by cauliturtle on 2/21/14, 10:45 AM