3 ms·
This seems like a roadblock that is rather inherent to the app container model of making images of host OS subsystems partitioned into their own namespaces. I
by vezzy-fnord 11y ago
This seems like a roadblock that is rather inherent to the app container model of making images of host OS subsystems partitioned into their own namespaces.
I thought that the idiomatic usage was not to treat them as distros, but as immutable images that you simply tear down and provision when a major system state change transaction needs to be performed?
Package introspection and sharing seems like something people would run a CM or task runner on the containers for. Hence the whole move to build large orchestration suites for them.
Not sure what is exactly meant by "order dependence" in this context.
Package manager cruft is just bad resource management, or sometimes even deficiencies in the PM itself.
- jbeda 11y agoImmutable images are the name of the game. Any sort of surgical update to image A would result in image A-prime. Any sort of orchestration system will help to run containers and will know what images you are running but not which packages you are running inside those images. With something like this a cluster admin could find all the containers across a 10k node cluster are running an unpatched version of openssl. Or could block running containers that are using unapproved packages. "Order dependence" is the fact that Dockerfile is stictly linnear -- even when 2 steps won't interact in any way. It makes caching and reuse more difficult.
- yo-code-sucks 11y agoI like that, a snapshot of all versions of all dependencies and apps within the container. So the final build step I could use Blueprint to capture that info, then ship the metadata and ship the container. Perhaps this could be achieved using the ONBUILD step.