"Xless" is just a different way of saying "without X". "fearless" = "without fear"; "serverless" = "without a server" (yes, I know, not really); so "distroless" = "(comes) without a distribution"

So in my opinon the name correctly suggests that it's "just the package" and comes "without a distro", and not "was built without the help of a distribution".

No, they are not.

Debian packages are deployable packages, which are built around packages and services and conventions adopted and provided by the target distribution.

Not to mention, you still need runtimes if you are programming in Java, Python or many other languages. https://github.com/GoogleContainerTools/distroless project gives a way to have these runtimes + their lib dependencies while still maintaining a minimal attack surface.

https://aws.amazon.com/blogs/aws/new-tls-termination-for-net...

>Today we are simplifying the process of building secure web applications by giving you the ability to make use of TLS (Transport Layer Security) connections that terminate at a Network Load Balancer (you can think of TLS as providing the “S” in HTTPS). This will free your backend servers from the compute-intensive work of encrypting and decrypting all of your traffic, while also giving you a host of other features and benefits:

I think may main point is that kneejerk reactions to satisfy a security list checkbox are just as useless as a default "encrypt everything everywhere" stance must be better.

IMHO this should be viewed as a big, glaring anti-pattern, as it fundamentally puts security team goals at odds with product team goals.

we once saw this from some other company where they noticed we where talking to the competitors and wanted to talk.

I think the start of this thread was a plea not to terminate HTTPS at the edge, but instead to plumb it all the way to the serving container. That's unlikely to be mTLS in any case.

Which is a truly rare case as many backend APIs these days are mandatory secured by HTTPS (or LDAPS, SMTPS, IMAPS to name a couple other openssl-based secure protocols).

The downside of plumbing directly to the container is that you lose many of the routing features of a service mesh. If it can't inspect the traffic, it can't do layer 7 routing. It can only route and shape at layer 4.

The `static` image is very bare minimal and only contains things like nsswitch.conf and ca certificates. This is the recommended base image for statically linked languages.

There's also a `base` image that I usually use as the base image of C programs, e.g. stunnel/unbound DNS. In those cases, I usually use Debian Stretch as build environment (distroless uses binary from Debian stable, so ABI is compatible), build a dynamically linked binary, then copy the result binary along with all dynamic object files to a distroless base image.

So when I talk about openssl in the image, I was referring to the `base` flavor. If you are happy with the provided openssl version, the openssl in the base image is indeed useful.

or you can just build gdb into the container and run the process under gdb, then attach to the tty.

or you can debug from the host system where the container's pid namespace is a descendant of the root namespace and the other namespaces can be accessed via /proc or unshare.

https://github.com/clearlinux/dockerfiles/tree/master/python

Perhaps the point is not to enable program execution, but to make use of the benefits that may come with container orchestration.

Depends on your workload, of course. Some people want to run a huge number of containers and each isn’t compute intensive.

Or maybe you don’t use libc at all in your fast path?

Lots of cases it makes sense.

They see Alpine at 5Mb and Ubuntu at 80Mb. They mentally multiply, without realising that each of these will be pulled once for each image built on top of them.

For a large cluster it's a wash. You might as well use Ubuntu, Centos -- anything where there are people working fulltime to fix CVEs quickly.

I do agree that people prematurely optimise and mainly incorrectly consider disk space but I think there's a decent use case for tiny images.

There's a case for tiny images, but it's in severely-constrained environments. Otherwise folks are fetishising the wrong thing based on a misunderstanding of how container images and runtimes work.

I just downloaded Ubuntu 18.04 and 19.04 and they are not 40MB:

    $ docker image ls | grep ubuntu
    ubuntu  19.04  f723e3b6f1bd   76.4MB
    ubuntu  18.04  d131e0fa2585  102.0MB
    ubuntu  16.04  a51debf7e1eb  116.0MB

---

I followed @sofaofthedamned — https://blog.ubuntu.com/2018/07/09/minimal-ubuntu-released

But I’m still confused, where are they getting 29MB from? Even the compressed files are big:

    Ubuntu Bionic [1]
    - ubuntu-18.04-minimal-cloudimg-amd64-root.tar.xz |  77M
    - ubuntu-18.04-minimal-cloudimg-amd64.img         | 163M
    - ubuntu-18.04-minimal-cloudimg-amd64.squashfs    |  96M
    
    Ubuntu Cosmic [2]
    - ubuntu-18.10-minimal-cloudimg-amd64-root.tar.xz | 210M
    - ubuntu-18.10-minimal-cloudimg-amd64.img         | 295M
    - ubuntu-18.10-minimal-cloudimg-amd64.squashfs    | 229M
    
    Ubuntu Disco [3]
    - ubuntu-19.04-minimal-cloudimg-amd64-root.tar.xz |  69M
    - ubuntu-19.04-minimal-cloudimg-amd64.img         | 155M
    - ubuntu-19.04-minimal-cloudimg-amd64.squashfs    |  89M

[2] http://cloud-images.ubuntu.com/minimal/releases/cosmic/relea...

[3] http://cloud-images.ubuntu.com/minimal/releases/disco/releas...

Apologies, it's actually 29mb.

There are also slimmed down images based on Debian or Ubuntu. A number of packages is a bit older versions, though.

Do you get all developers to agree on which base image to build all their services from?

I heard about this "oh, it's shared, don't worry" thing before. It started with 40MB. Now that supposedly shared image is half a gig. "Don't worry, it's shared anyway". Expect when it isn't. And when it is, it still slow us down in bringing up new nodes. And guess what, turns out that not everyone is starting from the same point, so there is a multitude of 'shared' images now.

Storage is cheap, but bandwidth may not be. And it still takes time to download. Try to keep your containers as small as possible for as long as possible. Your tech debt may grow slower that way.

Images built from dockerfiles can do this too, but it requires some degree of centralisation and control. Recently folks have done this with One Multibuild To Rule Them All.

By the time you're going to the trouble of reinventing buildpacks ... why not just use buildpacks? Let someone else worry about watching all the upstream dependencies, let someone else find and fix all the weird things that build systems can barf up, let someone else do all the heavy testing so you don't have to.

Disclosure: I worked on Cloud Native Buildpacks for a little while.

[0] https://buildpacks.io/

In production, the smallest box has half a gig of RAM.

In development, it's indeed a single box, usually a laptop.

> all developers to agree on which base image to build all their services from

Yes. In a small org it's easy. In a large org devops people will quickly explain the benefits of standardizing on one, at most two, base images. Special services that are run from a third-party image is a different beast.

> Storage is cheap, but bandwidth may not be.

Verily! Bandwidth, build time, etc.

Just run the process. Let whatever is managing your container restart it if the process quits, be it docker or K8s.

There's plenty of other reasons.

[Edit - fix link]

In most cases with Alpine-based containers, the only process is the one that you actually want to run.

Add to that that modern Ubuntu uses systemd which greatly exhausts the system’s inotify limits, so running 3-4 Ubuntu-containers can easily kill a systems ability to use inotify at all, across containers and the host system. Causing all kind of fun issues, I assure you.

So the cost is not just about disk-space.

Disclaimer: more experience with LXC than Docker.

For Python in particular, significantly slower.

[0] https://github.com/docker-library/python/issues/160 [1] https://gist.github.com/blopker/9fff37e67f14143d2757f9f2172c...

If your software is I/O-bound, and is written in a language like Python or Ruby, and sits idle waiting for requests for significant time anyway, CPU performance is likely not key for you. This also represents the majority case, AFAICT.

then you look at: https://sourceware.org/git/?p=glibc.git;a=blob;f=string/strl...

and your mind will sort of explode for a bit. The difference is the GLIBC version is dramatically faster; take the comments away and most of us wouldn't even know that's strlen. It's more complex, no question, but it's much faster. GLIBC is full of stuff like that. qsort and memcpy are non-obvious to many folks. It's not complexity for no reason, you'd be challenged to build a better qsort than the one in glibc, it's not easy.

[1]: https://github.com/bminor/glibc/blob/master/sysdeps/x86_64/s...

    http://ridiculousfish.com/blog/posts/old-age-and-treachery.html

For me it's mostly a non-issue. But things like redis or nginx work nicely with alpine as a base. And more than likely, whatever I want to containerize has already been containerized for Alpine. If not, getting something to work on Alpine may just not be worth it...

Might you have any citation(s) for this? I have not heard this before. Could you elaborate on what some the "wide variety of software" is? Thanks.

Worst case for slower processes, things take longer. Worst case for more disk use, things start crashing. For general cases, the former is preferable.