4 ms·
Most people would benefit from the distroless base image: https://github.com/GoogleContainerTools/distroless https://github.com/GoogleContainerTools/distroless
by yegle 7y ago
Most people would benefit from the distroless base image: https://github.com/GoogleContainerTools/distroless https://github.com/GoogleContainerTools/distroless
It's a base image with binaries from Debian deb package, and with necessary stuff like ca-certificates, and absolutely nothing else, while still glibc-based (unlike Alpine base images).
Example images I built with the base image
- C binary, <10MB https://hub.docker.com/r/yegle/stubby-dns https://hub.docker.com/r/yegle/stubby-dns
- Python binary, <50MB https://hub.docker.com/r/yegle/fava https://hub.docker.com/r/yegle/fava
- Go binary, 5MB https://hub.docker.com/r/yegle/dns-over-https https://hub.docker.com/r/yegle/dns-over-https
Another trick I use is to use https://github.com/wagoodman/dive https://github.com/wagoodman/dive to find the deltas between layers and manually remove it in my Dockerfile.
- dfsegoat 7y agoI just became familiar with the Alpine base images. Curious to know what the benefit conferred by it being 'glibc-based' is exactly?
- CraftThatBlock 7y agoMostly compatibility. GNU's libc and Alpine's libc implementation should match the same ABI but might not be 100% the same
- devy 7y agoYeah, because of that, it's really hard to get Alpine-based Docker images to work in some situations, for instance: this: https://github.com/grpc/grpc/issues/18150#issuecomment-479994767 https://github.com/grpc/grpc/issues/18150#issuecomment-47999... And this: https://github.com/pypa/manylinux/issues/37 https://github.com/pypa/manylinux/issues/37 I use Python. Anytime you need to compile the source to build a pip package and that the upstream package developer decided that they don't support Alpine's libc implementation (aka musl) then you will have a big problem, unless you can control your dependencies and include as few pip packages that requires compilation or find binary builds.
- tyingq 7y agoAlpine uses musl instead of glibc. That works well for most things, but not all things. For example, there are some JVM implementations that don't like musl unless you do quite a lot of work.
- iagooar 7y ago> Alpine uses musl instead of glibc. That works well for most things, but not all things. It works well until it doesn't. And screws up your whole deployment pipeline.
- techntoke 7y agoHow so? If you have a deployment pipeline, wouldn't you just detect failures?
- ptsneves 7y agoNever understood the whole alpine thing. I would say most sysadmins doing docker stuff do not understand the concept of what is a libc and its variants to understand the consequences of their choices. Hell I work in embedded and have worked with ulibc or musl and have been bitten quite hard. Some calls not working as expected are loads of fun. All for a few MB, when it could be done just using a proper small base image like has been suggested above.
- avip 7y agoThe standard benefits of using something mainstream vs. something niche - x100 more scenarii tested in the wild. In my limited experience, some things don't compile targetting musl. If everything works alpine is sup. Else, it may be fairly difficult (and mostly unjustified) to fix.
- yegle 7y agoFor one: with musl you can't reuse anylinux Python packages on PyPI (e.g. lxml) and you'll have to have GCC to build and install those packages.
- gauravphoenix 7y agoAlso, I beg you to not use Alpine. It is horrible from the security perspective. The Alpine team doesn't have sufficiently staffed security folks to upgrade packages when vulnerabilities are found. Most popular Linux distro vendors publish OVAL data[1] which can be used to find and fix vulnerable packages. But not with Alpine [2] [1] Example- https://www.redhat.com/security/data/oval/ https://www.redhat.com/security/data/oval/ [2] This is the closest you can get- https://github.com/alpinelinux/alpine-secdb https://github.com/alpinelinux/alpine-secdb
- andrewdb 7y agoSome of the examples in the repo include compressing distroless-based images. For example: from python2.7:distroless - 60.7MB => 18.3MB (minified by 3.32X)
- ggregoire 7y agoDoes it go there in term of size? scratch < distroless ~= alpine < debian-slim
- andoriyu 7y agoWell, distroless base is 3x alpine. Which is a clickbaity way of saying its 10mb bigger. Distroless nodejs images is...10mb bigger than the same on alpine. Main purpose of distroless is less attack surface rather than size. Without package manager mutating container is PITA. Not having `ps` or `cat` makes it hard to read secrets that you injected into container one way or another.
- baroffoos 7y agoWhat do you do when you need to debug an issue and the container contains no utils? I expect someone will leave a comment saying "But you shouldn't be entering containers, you should be using Ansible/Kubernetes". Yes, that is how I manage changes but sometimes you just have to log in and see what is going on with htop/etc
- londons_explore 7y agoMy dream solution to this issue is a one liner command like: docker exec -it --augment=ubuntu my_container bash Would start bash in the container, but also layer into the filesystem all the rest of a standard ubuntu image only for my tools, but not affecting the application in the running container. I'm pretty sure that's possible with current linux kernel mount namespace/overlayfs infrastructure used by docker - all that's needed is the command line tool to support it.
- zapita 7y agoWhich version of bash would you expect to run in this example? (1) If it's the bash version from the standard ubuntu image, you will need to specify where to mount your application's filesystem inside the ubuntu filesystem. (2) If it's the bash version from your application, then it's the other way around: you will need to specify where to mount the ubuntu filesystem inside your container. Option (1) seems more practical. My point is that you will need to specify a mountpoint either way, and your commands will need to take this mountpoint into account.
- londons_explore 7y agoMount both filesystems at the same place as an overlay - if a file exists in both, I don't care which I see.
- zapita 7y agoI see. That will work as long as your app is built on the same distro as your tools image (in your case, ubuntu).
- kylequest 7y agospeaking of dive... there's a bit of overlap between docker-slim and dive. docker-slim produces similar container image reports (with more details about the layers, but no diffs, for now... the layer diff support is coming)
- tuananh 7y agoi wish they would add more node version to the node distroless image.
- sandGorgon 7y agoHave you had a better experience using this versus Alpine ?
- yegle 7y agoBeing able to use anylinux PyPI package is a huge benefit.
- nikolay 7y agoNothing beats FROM scratch
- yegle 7y agoThis is misleading. For very basic things, you'll need timezone files, ca-certificate, for many Linux tool/libraries to work properly.
- nikolay 7y agoYeah, and all these could be copied from another container. I've slimmed down and lots of sidecar containers and, on top, I used UPX [0] on the binaries as well. Premature optimization is the root of all evils, true, but sometimes, for example, for Prometheus exporters you need to run on a bunch of nodes as sidecars, it totally makes sense to go the extra mile. [0]: https://upx.github.io/ https://upx.github.io/