6 ms·

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

peterwwillis 7y ago
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.
nine_k 7y ago
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.
- koolba 7y ago
  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.
  - sofaofthedamned 7y ago
    Exactly. With copy on write and samepage merging it's more important to use the same base image for all your deployments.
  - outworlder 7y ago
    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.
    - nine_k 7y ago
      > 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.
    - jacques_chester 7y ago
      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/ https://buildpacks.io/
- makapuf 7y ago
  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.
- stephenr 7y ago
  It's sad to me that it wasn't obvious to you 5*5 is not 40, or 40/5 is not 5.
josteink 7y ago
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.
- wmf 7y ago
  I don't think your LXC experience applies to Docker. Most Ubuntu-based Docker containers are not running full init.
- mixmastamyk 7y ago
  Their minimal images are well, minimal. Maybe not as minimal as Alpine, but not heavy either.
lixtra 7y ago
In particular since the base image is shared among all containers using it. It's 35 mb extra for n containers (n>>1).
- sofaofthedamned 7y ago
  Exactly. Amazed more people don't know this.
wmf 7y ago
Ubuntu used to be much larger so I wouldn't be surprised if people switched to Alpine and never looked back.
acct1771 7y ago
My inability to personally audit systemd would be at the top of the list.
- zbentley 7y ago
  Ubuntu Docker images do not run systemd by default or in most configurations. In many images it is removed entirely.
- silluk 7y ago
  I wouldn't be too concerned about that in a container since you're probably not running systemd in that context.
- Xylakant 7y ago
  given that containers usually do not include any init system at all that’s not a good reason to pick a side.
- roywiggins 7y ago
  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.
  - sofaofthedamned 7y ago
    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.
    - roywiggins 7y ago
      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.
    - 7y ago
guessmyname 7y ago
> 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 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/release-20190425.1/ http://cloud-images.ubuntu.com/minimal/releases/bionic/relea... [2] http://cloud-images.ubuntu.com/minimal/releases/cosmic/release-20190419/ http://cloud-images.ubuntu.com/minimal/releases/cosmic/relea... [3] http://cloud-images.ubuntu.com/minimal/releases/disco/release-20190417/ http://cloud-images.ubuntu.com/minimal/releases/disco/releas...
- sofaofthedamned 7y ago
  https://blog.ubuntu.com/2018/07/09/minimal-ubuntu-released https://blog.ubuntu.com/2018/07/09/minimal-ubuntu-released Apologies, it's actually 29mb.
  - novaleaf 7y ago
    i switched to ubuntu minimal for my cloud instances. it works great. highly recommended.
  - jacques_chester 7y ago
    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.
akvadrako 7y ago
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.
- meddlepal 7y ago
  --no-install-recommends is your friend
  - CameronNemo 7y ago
    Many debian based images set this option by default.
- sleepybrett 7y ago
  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.

nine_k 7y ago

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.

koolba 7y ago
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.
- sofaofthedamned 7y ago
  Exactly. With copy on write and samepage merging it's more important to use the same base image for all your deployments.
- outworlder 7y ago
  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.
  - nine_k 7y ago
    > 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.
  - jacques_chester 7y ago
    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/ https://buildpacks.io/
makapuf 7y ago
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.
stephenr 7y ago
It's sad to me that it wasn't obvious to you 5*5 is not 40, or 40/5 is not 5.

josteink 7y ago

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.

wmf 7y ago
I don't think your LXC experience applies to Docker. Most Ubuntu-based Docker containers are not running full init.
mixmastamyk 7y ago
Their minimal images are well, minimal. Maybe not as minimal as Alpine, but not heavy either.

lixtra 7y ago

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

sofaofthedamned 7y ago
Exactly. Amazed more people don't know this.

wmf 7y ago

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

acct1771 7y ago

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

zbentley 7y ago
Ubuntu Docker images do not run systemd by default or in most configurations. In many images it is removed entirely.
silluk 7y ago
I wouldn't be too concerned about that in a container since you're probably not running systemd in that context.
Xylakant 7y ago
given that containers usually do not include any init system at all that’s not a good reason to pick a side.
roywiggins 7y ago
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.
- sofaofthedamned 7y ago
  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.
  - roywiggins 7y ago
    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.
  - 7y ago

guessmyname 7y ago

> 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 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/release-20190425.1/ http://cloud-images.ubuntu.com/minimal/releases/bionic/relea... [2] http://cloud-images.ubuntu.com/minimal/releases/cosmic/release-20190419/ http://cloud-images.ubuntu.com/minimal/releases/cosmic/relea... [3] http://cloud-images.ubuntu.com/minimal/releases/disco/release-20190417/ http://cloud-images.ubuntu.com/minimal/releases/disco/releas...

sofaofthedamned 7y ago
https://blog.ubuntu.com/2018/07/09/minimal-ubuntu-released https://blog.ubuntu.com/2018/07/09/minimal-ubuntu-released Apologies, it's actually 29mb.
- novaleaf 7y ago
  i switched to ubuntu minimal for my cloud instances. it works great. highly recommended.
- jacques_chester 7y ago
  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.

akvadrako 7y ago

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.

meddlepal 7y ago
--no-install-recommends is your friend
- CameronNemo 7y ago
  Many debian based images set this option by default.
sleepybrett 7y ago
And a shitty library at the heart that makes everything suck just a bit more.