6 ms·

Omnibus – Dependency Isolation Without Docker

30 points by duggan 11y ago

davexunit 11y ago
Omnibus does nothing to resolve the real issues behind dependency management, it just masks it by bundling everything in a single package. This approach is very bad because it burdens the developer with providing security fixes to bundled applications, and it burdens the user because they now depend on one or more third parties for security to updates to bundled software that could be duplicated in many such packages. The real solution is to use a package manager that doesn't install everything into a global /usr directory where only one version of any given piece of software can exist. I recommend exploring what GNU Guix and Nix do to solve the dependency isolation problem without introducing the harmful side-effects of bundling. They are general-purpose, fit for packaging any type of software, and offer additional features beyond dependency isolation such as atomic upgrades/rollbacks, unprivileged package management, and reproducible builds with a complete, precise dependency graph all the way down to the coreutils/gcc/etc. that bootstrapped it.
- FooBarWidget 11y ago
  As opposed to Docker which also bundles everything, or Go which basically statically links everything? And what if your goal is to distribute software to users that may be running any arbitrary OS? You can't tell them "install Guix, learn how to use it, then use Guix to install my app". You'll lose a lot of users that way. At the end of the day, users care most about getting stuff done. I am the author of a popular app that is written in C++ and uses Boost. Many users literally begged me to bundle Boost because installing Boost is so much of a pain for them.
  - davexunit 11y ago
    >As opposed to Docker which also bundles everything, or Go which basically statically links everything? Yes, you've identified a bad trend. I am trying to raise awareness to stop it. >And what if your goal is to distribute software to users that may be running any arbitrary OS? You can't tell them "install Guix, learn how to use it, then use Guix to install my app". You'll lose a lot of users that way. You can actually use Guix to export the closure of the build and distribute that, if that's your thing. We do this for Guix itself to greatly simplify the installation process for new users, though for your use-case there would be some adjustment needed. The resulting binary distribution would work on any GNU/Linux system. Nix additionally offers OS X support. But yes, not everyone's use-case can be covered by Guix right now, but I strongly feel it's the direction we should be moving in.
    - duggan 11y ago
      Sounds interesting, I'm familiar with Nix, but not Guix. The core tenets of Nix really resonate with me, and you're 100% right in your parent post: this does not solve dependency management. It is a hack which trades long term reliability for short term stability and ease of installation. It is not The Answer, it's just an answer until we (and I'm glad to see there are people like yourself on the case) can do better.
  - vezzy-fnord 11y ago
    Well, first of all, this isn't about user acquisition. It's about solving technical problems. Linking strategy is a totally orthogonal concern to package management, though I prefer static linking myself for not having to deal with the broader issues of the shared library namespace.
- GlennS 11y ago
  How well does Nix interact with inherently stateful things like databases? If I'm deploying a newer version of some project, which depends on a more recent version of a database which requires some schema migration (e.g. my PostGIS types are out of date and need upgrading), what happens to my data?
  - davexunit 11y ago
    >How well does Nix interact with inherently stateful things like databases? This is a frequently asked question. Nix/Guix do not interact with such files, and we make it a point to differentiate between stateful and stateless. Nix and Guix manage the stateless, deterministic stuff, and system services or other mechanisms manage the stateful stuff. For example, there's a postgresql package in Guix, but installing it doesn't create a db cluster in /var/lib, it just installs the binaries, docs, etc to the user's package profile. However, GuixSD, the distro built on Guix, comes with a postgresql system service that creates the system db cluster before launching the postgresql server. In other words, stateful things are handled at a different layer than the packaging layer. If a new version of an application requires a schema migration, then that would be something for a system service to perform with the updated binaries from the package manager. You still need to take care to back up your databases, home directories, etc.
duggan 11y ago
Someone also pointed me to HashDist (https://hashdist.github.io/ https://hashdist.github.io/) which looks like another isolation framework, but written in Python.
atom_enger 11y ago
I've been using Omnibus extensively since they introduced it at ChefConf'13...and I just spent the last two weeks cleansing my infrastructure of anything Omnibus related in favor of using Packer + Amazon AMI's. Some projects may benefit from using Omnibus; being able to produce deliverables which are just installed by the package manager. However, there is a significant learning curve and investment of time required for the debugging process in order to get your package building with Omnibus. I finally said screw all that and I've resorted to shell scripts + packer building my images on amazon. Now my builds don't require a complicated omnibus builder host to be configured, or even ruby to be installed and god damnit, I don't have to worry about doing a bundle update to get the latest chef-sugar or omnibus gem to get it to work. I'm tired of these complicated systems. Every new piece of tech in your stack should be considered carefully. I could barely explain Omnibus to my dev team, even though I knew exactly how it worked and how all the packages were built on every build. Omnibus is a great project with a lot of contributors, but users beware - it comes at a price of time and complexity.
- duggan 11y ago
  Agree on all points, particular about weighing up the pros and cons. If you have full control of your stack, I would say Omnibus is a waste of time. It is without a doubt most useful when you do not control the environment where your code is going to be deployed.
  - atom_enger 11y ago
    Yeah, that's precisely where it became useful. Deploying our code into a datacenter with extremely strict security requirements(meaning no bundle install to get deps on the host, everything had to come with).

30 points by duggan 11y ago

Omnibus does nothing to resolve the real issues behind dependency management, it just masks it by bundling everything in a single package. This approach is very bad because it burdens the developer with providing security fixes to bundled applications, and it burdens the user because they now depend on one or more third parties for security to updates to bundled software that could be duplicated in many such packages. The real solution is to use a package manager that doesn't install everything into a global /usr directory where only one version of any given piece of software can exist. I recommend exploring what GNU Guix and Nix do to solve the dependency isolation problem without introducing the harmful side-effects of bundling. They are general-purpose, fit for packaging any type of software, and offer additional features beyond dependency isolation such as atomic upgrades/rollbacks, unprivileged package management, and reproducible builds with a complete, precise dependency graph all the way down to the coreutils/gcc/etc. that bootstrapped it.

FooBarWidget 11y ago
As opposed to Docker which also bundles everything, or Go which basically statically links everything? And what if your goal is to distribute software to users that may be running any arbitrary OS? You can't tell them "install Guix, learn how to use it, then use Guix to install my app". You'll lose a lot of users that way. At the end of the day, users care most about getting stuff done. I am the author of a popular app that is written in C++ and uses Boost. Many users literally begged me to bundle Boost because installing Boost is so much of a pain for them.
- davexunit 11y ago
  >As opposed to Docker which also bundles everything, or Go which basically statically links everything? Yes, you've identified a bad trend. I am trying to raise awareness to stop it. >And what if your goal is to distribute software to users that may be running any arbitrary OS? You can't tell them "install Guix, learn how to use it, then use Guix to install my app". You'll lose a lot of users that way. You can actually use Guix to export the closure of the build and distribute that, if that's your thing. We do this for Guix itself to greatly simplify the installation process for new users, though for your use-case there would be some adjustment needed. The resulting binary distribution would work on any GNU/Linux system. Nix additionally offers OS X support. But yes, not everyone's use-case can be covered by Guix right now, but I strongly feel it's the direction we should be moving in.
  - duggan 11y ago
    Sounds interesting, I'm familiar with Nix, but not Guix. The core tenets of Nix really resonate with me, and you're 100% right in your parent post: this does not solve dependency management. It is a hack which trades long term reliability for short term stability and ease of installation. It is not The Answer, it's just an answer until we (and I'm glad to see there are people like yourself on the case) can do better.
- vezzy-fnord 11y ago
  Well, first of all, this isn't about user acquisition. It's about solving technical problems. Linking strategy is a totally orthogonal concern to package management, though I prefer static linking myself for not having to deal with the broader issues of the shared library namespace.
GlennS 11y ago
How well does Nix interact with inherently stateful things like databases? If I'm deploying a newer version of some project, which depends on a more recent version of a database which requires some schema migration (e.g. my PostGIS types are out of date and need upgrading), what happens to my data?
- davexunit 11y ago
  >How well does Nix interact with inherently stateful things like databases? This is a frequently asked question. Nix/Guix do not interact with such files, and we make it a point to differentiate between stateful and stateless. Nix and Guix manage the stateless, deterministic stuff, and system services or other mechanisms manage the stateful stuff. For example, there's a postgresql package in Guix, but installing it doesn't create a db cluster in /var/lib, it just installs the binaries, docs, etc to the user's package profile. However, GuixSD, the distro built on Guix, comes with a postgresql system service that creates the system db cluster before launching the postgresql server. In other words, stateful things are handled at a different layer than the packaging layer. If a new version of an application requires a schema migration, then that would be something for a system service to perform with the updated binaries from the package manager. You still need to take care to back up your databases, home directories, etc.

duggan 11y ago

Someone also pointed me to HashDist (https://hashdist.github.io/ https://hashdist.github.io/) which looks like another isolation framework, but written in Python.

atom_enger 11y ago

I've been using Omnibus extensively since they introduced it at ChefConf'13...and I just spent the last two weeks cleansing my infrastructure of anything Omnibus related in favor of using Packer + Amazon AMI's. Some projects may benefit from using Omnibus; being able to produce deliverables which are just installed by the package manager. However, there is a significant learning curve and investment of time required for the debugging process in order to get your package building with Omnibus. I finally said screw all that and I've resorted to shell scripts + packer building my images on amazon. Now my builds don't require a complicated omnibus builder host to be configured, or even ruby to be installed and god damnit, I don't have to worry about doing a bundle update to get the latest chef-sugar or omnibus gem to get it to work. I'm tired of these complicated systems. Every new piece of tech in your stack should be considered carefully. I could barely explain Omnibus to my dev team, even though I knew exactly how it worked and how all the packages were built on every build. Omnibus is a great project with a lot of contributors, but users beware - it comes at a price of time and complexity.

duggan 11y ago
Agree on all points, particular about weighing up the pros and cons. If you have full control of your stack, I would say Omnibus is a waste of time. It is without a doubt most useful when you do not control the environment where your code is going to be deployed.
- atom_enger 11y ago
  Yeah, that's precisely where it became useful. Deploying our code into a datacenter with extremely strict security requirements(meaning no bundle install to get deps on the host, everything had to come with).