Hacker News Reader

Comment by sofaofthedamned | Hacker News Reader

I've no idea why you wouldn't use Ubuntu which is only around 40mb, has a sane package manager and a standard glibc.

> Ubuntu which is only around 40mb […]

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

How do you get a 40MB Ubuntu Docker image?

---

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

[1] http://cloud-images.ubuntu.com/minimal/releases/bionic/relea...

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

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

https://blog.ubuntu.com/2018/07/09/minimal-ubuntu-released

Apologies, it's actually 29mb.

i switched to ubuntu minimal for my cloud instances. it works great. highly recommended.

Don't feel bad. You've discovered the charming little fact that the registry API will report compressed size and the Docker daemon will report uncompressed size.

Ubuntu used to be much larger so I wouldn't be surprised if people switched to Alpine and never looked back.

40mb vs 5mb is like 5x difference.

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

You're only playing that 40mb once though. Multiple containers sharing the same parent layers will not require additional storage for the core OS layer.

Exactly. With copy on write and samepage merging it's more important to use the same base image for all your deployments.

Are you guys running everything on a single box?

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.

> single box

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.

As it happens, you're describing one of the motivations for Cloud Native Buildpacks[0]: consistent image layering leading to (very) efficient image updates.

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/

Technically it's closer to 8. Which is quite a bit. That said even. If it's relatively very different, absolutely speaking its 40mb which is very little even if you have to transfer it up.

It's sad to me that it wasn't obvious to you 5*5 is not 40, or 40/5 is not 5.

In particular since the base image is shared among all containers using it. It's 35 mb extra for n containers (n>>1).

Exactly. Amazed more people don't know this.

Ubuntu is 40MB but if you add a few packages with tons of dependencies it can quickly reach 800MB. Alpine has much more reasonable dependency trees.

--no-install-recommends is your friend

Many debian based images set this option by default.

And a shitty library at the heart that makes everything suck just a bit more.

The base image may be small, but all the packages and metadata are large, and the dependencies are many. Alpine always leans to conservative options and intentionally removes mostly-unnecessary things. So average image sizes are higher with an Ubuntu base compared to Alpine.

My inability to personally audit systemd would be at the top of the list.

Ubuntu Docker images do not run systemd by default or in most configurations. In many images it is removed entirely.

I wouldn't be too concerned about that in a container since you're probably not running systemd in that context.

given that containers usually do not include any init system at all that’s not a good reason to pick a side.

As far as I can tell, the recommended way to run several processes in an Ubuntu container is under supervisord. The default Ubuntu containers don't even include an init system.

Suoervisord is an awful thing to do under a container tbf. Any oom event and it will kill a random process. Not good in a container environment.

I've only ever done it when I needed to run exactly two processes- porting an older piece of software that was not originally designed to run inside containers, and orchestrating the separate processes to be able to communicate and run in separate containers didn't seem like worth the effort.

And supervisord will restart it.

Why would anyone run an init system inside a container?

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

Here is one reason: https://news.ycombinator.com/item?id=10852055 (TL;DR - default signal behaviour is different for PID 1).

[Edit - fix link]

Because sometimes it is easier to ship one thing to customers than 10 different images and several different run manifests.

There's plenty of other reasons.

I’ll try not to be opinionated, but starting an app inside Ubuntu typically has 50+ processes.

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.

I don't think your LXC experience applies to Docker. Most Ubuntu-based Docker containers are not running full init.

Their minimal images are well, minimal. Maybe not as minimal as Alpine, but not heavy either.

Reply on news.ycombinator.com