I've used staged builds before, but never used scratch for the last stage, only alpine. I wonder if there are tradeoffs to not using a Linux environment?
I'm curious to see if it holds me up when I inevitably do have other assets to include. When the only thing in the container is a single binary it's straightforward enough, at least.
All other concerns should be handled by the host server, though, I think - right?
Yeah, I never thought about it much, but the OS in the docker image is really only needed for runtime environment purposes. If all you have is a binary, you shouldn't need an environment aside from the host.
This image is most useful in the context of building base images (such as debian and busybox) or super minimal images (that contain only a single binary and whatever it requires, such as hello-world).
Appreciate this article so much. So many concepts being added to my knowledge-base for future use.
One thing I find is that I'm managing container-container communications a lot. Not a problem normally. How is that with scratch? Does Docker handle it all, or does the OS provide some abstraction that would need to be substituted within the binary?
EDIT: To be clear, I'm thinking of putting a binary at the end of an API call. If I could do that with a minimal image I would be so much happier. Just want to get the plumbing right 😉
I haven't tried yet, but my instinct tells me this is something Docker manages, not your containers. Like Moshe said, the Linux userland inside a container is explicitly for runtime needs of the container's internal commands, everything outside of that is handled by Docker itself.
I've used staged builds before, but never used scratch for the last stage, only alpine. I wonder if there are tradeoffs to not using a Linux environment?
I'm curious to see if it holds me up when I inevitably do have other assets to include. When the only thing in the container is a single binary it's straightforward enough, at least.
All other concerns should be handled by the host server, though, I think - right?
Yeah, I never thought about it much, but the OS in the docker image is really only needed for runtime environment purposes. If all you have is a binary, you shouldn't need an environment aside from the host.
The scratch image description actually says the following:
Appreciate this article so much. So many concepts being added to my knowledge-base for future use.
One thing I find is that I'm managing container-container communications a lot. Not a problem normally. How is that with
scratch? Does Docker handle it all, or does the OS provide some abstraction that would need to be substituted within the binary?EDIT: To be clear, I'm thinking of putting a binary at the end of an API call. If I could do that with a minimal image I would be so much happier. Just want to get the plumbing right 😉
I haven't tried yet, but my instinct tells me this is something Docker manages, not your containers. Like Moshe said, the Linux userland inside a container is explicitly for runtime needs of the container's internal commands, everything outside of that is handled by Docker itself.
Thanks.
scratchfeels like taking the training wheels off, but you have to do it at some point!Afaik,
scratchisn't "nothing", it just downloads nothing.There's still stuff from the runtime when it's alive.