5 ms·

Minimal docker images feel like the Right Choice for deployment artifacts. For a project I worked on recently that minimal image was a standalone go binary, not

Minimal docker images feel like the Right Choice for deployment artifacts. For a project I worked on recently that minimal image was a standalone go binary, nothing else in the image at all. But I was not sure how minimal was possible for a python project I was working on. Having standard base images for different languages will be great.

maslam 9y ago
Be oh so careful. We ran into issues with alpine node images that would only show up in minimal images like that. Switched to Debian and never looked back.
- jacobparker 9y ago
  Was it because of musl libc? These images use glibc.
  - mattomata 9y ago
    Yeah, that's exactly why we chose to start from debs.
yokaze 9y ago
Funnily enough, I found it rather paradoxical (if you are developing in-house). You choose a base, and that one is shared across your projects, so the size doesn't matter much within reason. Say, you go for Debian, then you count 50MB download and 100MB space over all your containers / apps, thanks to sharing. So, your stuff goes on top, potentially unshared (say multiple applications). Which comes to the next contradiction: You then go then for a go-binary, which weighs in by itself easily over a 100MB of binary code. Unshared. Any advantage of self-containment of a go-binary (being statically linked) becomes more a liability, as it is the functionality you gain from docker-images (self-containment), without the sharing of the layers. If you are focusing on delivering it to some random people, which would maybe care about having to install 100MB on top of whatever you are delivering, then I could see your point, but then you could just go for distributing the go-binaries themselves.
- pebers 9y ago
  Most Go binaries aren't over 100MB unless they have a bunch of data packed in them. 10-15MB seems more usual to me unless it's a particularly large project.
- BraveNewCurency 9y ago
  > You then go then for a go-binary, which weighs in by itself easily over a 100MB of binary code. Hah, I'd love something that small. Right now, we have dozens of Node.JS apps, each one needing over 500MBs of NPM libraries..
mattomata 9y ago
Right, "nothing else" = "FROM scratch". In the talk, I call this "FROM scratch -- for the rest of us." That a half-truth because this also tries to set up a minimal compatible environment for common cases, e.g. it sets up ca-certs, a /tmp directory, and an /etc/passwd file.
- deleted 9y ago
  [deleted]
- macrael 9y ago
  That makes a lot of sense. How did you decide where to draw the line on what to include and what to leave out?
marmaduke 9y ago
How is a single go bin in an image better than that bin by itself?
- macrael 9y ago
  Fundamentally it's not, but because Docker is a standard, you can throw that anywhere docker images can be consumed and run it. So, for instance, I was deploying to GKE which was easy to do. My docker deployment image was tiny (just the size of the binary) and I could run it anywhere.

maslam 9y ago

Be oh so careful. We ran into issues with alpine node images that would only show up in minimal images like that. Switched to Debian and never looked back.

jacobparker 9y ago
Was it because of musl libc? These images use glibc.
- mattomata 9y ago
  Yeah, that's exactly why we chose to start from debs.

yokaze 9y ago

Funnily enough, I found it rather paradoxical (if you are developing in-house). You choose a base, and that one is shared across your projects, so the size doesn't matter much within reason. Say, you go for Debian, then you count 50MB download and 100MB space over all your containers / apps, thanks to sharing. So, your stuff goes on top, potentially unshared (say multiple applications). Which comes to the next contradiction: You then go then for a go-binary, which weighs in by itself easily over a 100MB of binary code. Unshared. Any advantage of self-containment of a go-binary (being statically linked) becomes more a liability, as it is the functionality you gain from docker-images (self-containment), without the sharing of the layers. If you are focusing on delivering it to some random people, which would maybe care about having to install 100MB on top of whatever you are delivering, then I could see your point, but then you could just go for distributing the go-binaries themselves.

pebers 9y ago
Most Go binaries aren't over 100MB unless they have a bunch of data packed in them. 10-15MB seems more usual to me unless it's a particularly large project.
BraveNewCurency 9y ago
> You then go then for a go-binary, which weighs in by itself easily over a 100MB of binary code. Hah, I'd love something that small. Right now, we have dozens of Node.JS apps, each one needing over 500MBs of NPM libraries..

mattomata 9y ago

Right, "nothing else" = "FROM scratch". In the talk, I call this "FROM scratch -- for the rest of us." That a half-truth because this also tries to set up a minimal compatible environment for common cases, e.g. it sets up ca-certs, a /tmp directory, and an /etc/passwd file.

deleted 9y ago
[deleted]
macrael 9y ago
That makes a lot of sense. How did you decide where to draw the line on what to include and what to leave out?

marmaduke 9y ago

How is a single go bin in an image better than that bin by itself?

macrael 9y ago
Fundamentally it's not, but because Docker is a standard, you can throw that anywhere docker images can be consumed and run it. So, for instance, I was deploying to GKE which was easy to do. My docker deployment image was tiny (just the size of the binary) and I could run it anywhere.