3 ms·

Author here. I agree with the philosophy on #1, but what image would you rather see? You still need a big enough image that provides the dependencies for most

by amouat 12y ago

Author here. I agree with the philosophy on #1, but what image would you rather see? You still need a big enough image that provides the dependencies for most common processes.

akerl_ 12y ago
I'm a fan of statically compiled binaries for things like this. Given that I'm already treating containers as immutable once deployed, and containers (processes) aren't sharing libraries, the normal issues with static binaries are already issues: if I need to patch a library, I'm going to need to rebuild my containers and I'm going to need to replace old containers with new ones. That lets your container build be "add this binary, add some configs". If we really want to have shell access via docker exec or similar, we could base the image off of busybox or similar to get that. For dynamic things that resist compiling down (I'm looking at you, PAR::Packer), I can see more reason for building in a minimal distro userspace, but ideally there you're using something that's more minimal based on your use case. For example, if I run a fleet of rails apps, I might build out an image that had busybox + static ruby, with my codebase added alongside it. The minimal distro method has very powerful up-front value, which I suspect is why Docker is focusing on it: it allows users to dive in with a familiar environment and learn to do Docker things without having to discard a lot of their previous understanding. For that use case, it is magnificent. Users can use their existing understanding of packaging, of OS tools, and of service management and apply it when dockerizing their services. The methods I'm describing would be the next step, roughly akin to writing out a new codebase and then identifying where to optimize it. Once a user is comfortable with Docker and is using it to run their services, they can make a determination as to whether or not pushing around distro userspaces is helping or hurting them, and react appropriately. For example: a use case where each host is running service containers in a variety of languages or where the admin knows they're going to want to interact with userspace tools on the container. In that case, basing on Debian or such makes great sense. Another case: each host is running a collection of containers with golang binaries to crunch the last digit of pi or design the cutest protein or whatever. There's no reason to base on a full OS: build your protein builder statically, drop it in an image, and you have an extremely lightweight image to throw into your fleet.
- amouat 12y ago
  I think in the majority of cases it's just going to be simpler to use a minimal base image like debian. And the overhead is pretty minimal - once you've got the base image, you only need to download the changes for other child images. Admittedly, you do incur the image overhead at least once per Docker host. In short - horses for courses ;)

by amouat 12y ago

Author here. I agree with the philosophy on #1, but what image would you rather see? You still need a big enough image that provides the dependencies for most common processes.

akerl_ 12y ago

I'm a fan of statically compiled binaries for things like this. Given that I'm already treating containers as immutable once deployed, and containers (processes) aren't sharing libraries, the normal issues with static binaries are already issues: if I need to patch a library, I'm going to need to rebuild my containers and I'm going to need to replace old containers with new ones. That lets your container build be "add this binary, add some configs". If we really want to have shell access via docker exec or similar, we could base the image off of busybox or similar to get that. For dynamic things that resist compiling down (I'm looking at you, PAR::Packer), I can see more reason for building in a minimal distro userspace, but ideally there you're using something that's more minimal based on your use case. For example, if I run a fleet of rails apps, I might build out an image that had busybox + static ruby, with my codebase added alongside it. The minimal distro method has very powerful up-front value, which I suspect is why Docker is focusing on it: it allows users to dive in with a familiar environment and learn to do Docker things without having to discard a lot of their previous understanding. For that use case, it is magnificent. Users can use their existing understanding of packaging, of OS tools, and of service management and apply it when dockerizing their services. The methods I'm describing would be the next step, roughly akin to writing out a new codebase and then identifying where to optimize it. Once a user is comfortable with Docker and is using it to run their services, they can make a determination as to whether or not pushing around distro userspaces is helping or hurting them, and react appropriately. For example: a use case where each host is running service containers in a variety of languages or where the admin knows they're going to want to interact with userspace tools on the container. In that case, basing on Debian or such makes great sense. Another case: each host is running a collection of containers with golang binaries to crunch the last digit of pi or design the cutest protein or whatever. There's no reason to base on a full OS: build your protein builder statically, drop it in an image, and you have an extremely lightweight image to throw into your fleet.

amouat 12y ago
I think in the majority of cases it's just going to be simpler to use a minimal base image like debian. And the overhead is pretty minimal - once you've got the base image, you only need to download the changes for other child images. Admittedly, you do incur the image overhead at least once per Docker host. In short - horses for courses ;)