4 ms·

Happy to answer questions and brainstorm ideas here.

by jbeda 11y ago

cwp 11y ago
Just curious about this sentence: > There are package managers out there that are cleanly factored from the underlying OS (Homebrew, Nix) but they aren’t typically used in Docker images. I agree that Homebrew is probably not useful. It's cleanly factored from the OS, but it's still pretty Mac-centric. Nix, however, lots of Linux packages. Why didn't consider using it, rather than starting over?
- jbeda 11y ago
  I looked closely at Nix and there is a lot to like there. The thing that turned me off is that it is just too complex. Going from something like Dockerfiles to Nix is just a huge leap. Example: http://sandervanderburg.blogspot.com/2014/07/managing-private-nix-packages-outside.html http://sandervanderburg.blogspot.com/2014/07/managing-privat... A lesson from Docker is that we have to make this dead simple. It has to be something you can grok in 15-60m.
- willsher 11y ago
  There is also pkgsrc, which from memory can be build to be separate from the underlaying OS. FreeBSD's ports is similar. Slackware's packaging is based off simple tar files. It does seem that this software build/deploy is a key problem that needs solving and the decentralised, easy to grok nature of Docker is key to the software delivery system. Nix is a really clever bit of engineering and design, but is also hard to grasp. Could it be made more simple? I suspect it's 'functional' nature is the hard part. The nature of containers being essentially immutable, at least from a base software stance, with packages not being upgraded so much as newly installed avoids the problem of upgrading running services. Most (all?) software would run as its own user, so no root level daemons. Configuration files are built from service discovery (e.g. via Kelsey's confd in lieu of the apps themselves deriving config), so even config need not be preserved if a roll back to prior to the package layering is done. Just some thoughts, but I agree there is a need to better manage dependencies. Heck, why not build static linked binaries?
  - jbeda 11y ago
    Thanks for the pointers -- I'll dig in to those to get more ideas. Also agree that config-as-package is part of this too. As for statically linked binaries -- this solves some of it but not all. Still hard to figure out which version of openssl is actually running in production. Also falls down in the world of dynamic languages where you app is a bunch of rb/php/py files.
    - masom 11y ago
      > Still hard to figure out which version of openssl is actually running in production You could check the version of openssl in a specific image id and check if that image is used on the cluster. If one of your image has a package with known security updates it is just a matter of re-building it with the newer package and re-deploying.
      - jbeda 11y ago
        Agreed -- but how do you figure out which packages are in an image without cracking that image? Quick -- what version of OpenSSL is in the golang Docker images? (https://registry.hub.docker.com/_/golang/ https://registry.hub.docker.com/_/golang/). Short of downloading them and poking around the file system, I can't tell.
        willsher 11y ago
        That's a fair point, but the alternative of always compiling the packages at the point in time negates that, at the risk of regressions and other 'new version' bugs, but that may be endemic in this anyway - if the author of the golang container built it at a point in time against version X, then went away and left the container alone, upgrading versions may become risky in any case. Those kind of risks, and perhaps the larger container risks look like CI pipeline issues - how is the container tested a given new versions? As an adjunct, how do we so container component integration testing? Is that part of this packaging & building system?
    - willsher 11y ago

Happy to answer questions and brainstorm ideas here.

by jbeda 11y ago

Happy to answer questions and brainstorm ideas here.

cwp 11y ago

Just curious about this sentence: > There are package managers out there that are cleanly factored from the underlying OS (Homebrew, Nix) but they aren’t typically used in Docker images. I agree that Homebrew is probably not useful. It's cleanly factored from the OS, but it's still pretty Mac-centric. Nix, however, lots of Linux packages. Why didn't consider using it, rather than starting over?

jbeda 11y ago
I looked closely at Nix and there is a lot to like there. The thing that turned me off is that it is just too complex. Going from something like Dockerfiles to Nix is just a huge leap. Example: http://sandervanderburg.blogspot.com/2014/07/managing-private-nix-packages-outside.html http://sandervanderburg.blogspot.com/2014/07/managing-privat... A lesson from Docker is that we have to make this dead simple. It has to be something you can grok in 15-60m.
willsher 11y ago
There is also pkgsrc, which from memory can be build to be separate from the underlaying OS. FreeBSD's ports is similar. Slackware's packaging is based off simple tar files. It does seem that this software build/deploy is a key problem that needs solving and the decentralised, easy to grok nature of Docker is key to the software delivery system. Nix is a really clever bit of engineering and design, but is also hard to grasp. Could it be made more simple? I suspect it's 'functional' nature is the hard part. The nature of containers being essentially immutable, at least from a base software stance, with packages not being upgraded so much as newly installed avoids the problem of upgrading running services. Most (all?) software would run as its own user, so no root level daemons. Configuration files are built from service discovery (e.g. via Kelsey's confd in lieu of the apps themselves deriving config), so even config need not be preserved if a roll back to prior to the package layering is done. Just some thoughts, but I agree there is a need to better manage dependencies. Heck, why not build static linked binaries?
- jbeda 11y ago
  Thanks for the pointers -- I'll dig in to those to get more ideas. Also agree that config-as-package is part of this too. As for statically linked binaries -- this solves some of it but not all. Still hard to figure out which version of openssl is actually running in production. Also falls down in the world of dynamic languages where you app is a bunch of rb/php/py files.
  - masom 11y ago
    > Still hard to figure out which version of openssl is actually running in production You could check the version of openssl in a specific image id and check if that image is used on the cluster. If one of your image has a package with known security updates it is just a matter of re-building it with the newer package and re-deploying.
    - jbeda 11y ago
      Agreed -- but how do you figure out which packages are in an image without cracking that image? Quick -- what version of OpenSSL is in the golang Docker images? (https://registry.hub.docker.com/_/golang/ https://registry.hub.docker.com/_/golang/). Short of downloading them and poking around the file system, I can't tell.
      - willsher 11y ago
        That's a fair point, but the alternative of always compiling the packages at the point in time negates that, at the risk of regressions and other 'new version' bugs, but that may be endemic in this anyway - if the author of the golang container built it at a point in time against version X, then went away and left the container alone, upgrading versions may become risky in any case. Those kind of risks, and perhaps the larger container risks look like CI pipeline issues - how is the container tested a given new versions? As an adjunct, how do we so container component integration testing? Is that part of this packaging & building system?
  - willsher 11y ago