
Minideb – A small image based on Debian designed for use in containers - nikolay
https://github.com/bitnami/minideb
======
vmarquet
In addition to the "minimalist" aspect, this image seems to offer better
practices on a security level than official Debian images. From their README:
"The images are built daily and have the security release enabled, so will
contain any security updates released more than 24 hours ago."

A recent analysis showed that the debian:latest image is "updated roughly
every month" [https://anchore.com/blog/look-often-docker-images-
updated/](https://anchore.com/blog/look-often-docker-images-updated/)

~~~
zenlikethat
> In addition to the "minimalist" aspect, this image seems to offer better
> practices on a security level than official Debian images

I'm skeptical about this claim. Almost every image built from the Debian
official image begins with `apt-get update` before you can actually install
anything, which means you will almost always have the latest packages at the
time of building.

~~~
gramakri
apt update only updates the package list and not the packages themselves. So
unless the docker file contains apt upgrade it still uses old packages.

~~~
zenlikethat
There's nothing to upgrade. Pretty much nothing is installed already in most
base images. Even `ca-certificates` etc. have to be installed.

~~~
yebyen
are you saying that most base images don't have ssl?

because i'm a baseimage maintainer
([http://github.com/phusion/baseimage](http://github.com/phusion/baseimage))
and I don't think that's true...

[https://github.com/phusion/baseimage-
docker/blob/master/imag...](https://github.com/phusion/baseimage-
docker/blob/master/image/prepare.sh#L34)

~~~
nyrikki
No offence intended and these terms are not tightly defined but I would call
your imaged a 'baked' image.

My feeling is that I don't know how long a base-image will stick around. If
ca-certificates is installed in my base image it may end up trusting revoked
certificates.

IMHO it is better to know you need to install/bake in ca-certs from a trusted
source than to having a built in, potentially compromised CA cert installed.

Baked images, which I use to reduce instantiation time, or 'golden' images
that are immutable infrastructure tend to have shorter lifespans and the CA
package is carried in the application dependencies and more likely to be up to
date.

~~~
yebyen
No offense inferred!

It is not intended that users will download this baseimage (although it is a
supported configuration, you can use FROM phusion/baseimage) but, that this
will be an image definition that users can easily rebuild and build off of it.

Step one in Docker competency is "do you know exactly where your image comes
from, and can you rebuild it from scratch without trusting that some rando on
the internet didn't put bad stuff in there?"

Step two is "ok, do you really actually build them, though"

This image has traditionally been based on LTS ubuntu, and if you look at the
CentOS derived version that hasn't been updated since 2014 (pokle/centos-
baseimage), they chose not to include ca-certificates or hardly anything else.

(I'm assuming that tianon/centos:6.5 does not install ca-certificates by
default...)

I'm sure many people use FROM phusion/baseimage but personally, even as a
maintainer, I don't. I'd change the image source to whatever upstream of
Ubuntu I'm preferring today, and probably build that from scratch too. The
value in this image is not that it comes pre-built, it's that the build is
tested and supported. /side tangent

------
vietjtnguyen
I don't really work in this domain so maybe I'm missing something. If the goal
is to essentially get the bare minimum needed to run a program into a Docker
image why not develop your program in your desired environment and then use
something like CDE [1] to copy (or obtain a list of) all the files touched in
the desired invocation of the program. That copy or list can then be put into
a tarball and imported with "docker import". Philip Guo even writes about this
possible use [2].

Here's a silly example:

    
    
      cde python -c "import numpy as np; print(np.random.randn(3, 3).tolist())"
      pushd cde-package/cde-root/; tar cavf ../../cde-image.tar *; popd
      docker import cde-image.tar $USER:python-randn33
      docker run $USER:python-randn33 python -c "import numpy as np; print(np.random.randn(3, 3).tolist())"
      docker run -t -i $USER:python-randn33 python
    

If you look at the resulting "cde-image.tar" you'll find it to be quite bare.
Mines had only 387 entries (files and folders).

[1]: [http://www.pgbovine.net/cde.html](http://www.pgbovine.net/cde.html)

[2]: [http://pgbovine.net/automatically-create-docker-
images.htm](http://pgbovine.net/automatically-create-docker-images.htm)

~~~
monkmartinez
I imagine that if you created a product that could run my Python code without
building a full container or image, you might call it "serverless."

~~~
option_greek
[https://github.com/alexellis/faas](https://github.com/alexellis/faas)

------
zwerdlds
for anyone else interested in the actual stats, I grifted this from their pr
on the image:

The minideb image currently weighs in at around 50MB uncompressed. For
comparison the debian library image is 123MB, the alpine image is 5MB, and the
newly released amazonlinuximage is 328MB.

~~~
ridruejo
Once you do anything interesting (i.e. install Python) then Alpine and minideb
size are basically identical

~~~
pebers
I guess it's a bit more specific than you meant it, but our standard Python
image is ~20MB (alpine + python3, basically); that's still under half of
minideb.

Does look interesting for things that need glibc compatibility though. There
are some packages to help with that in Alpine but they only go so far.

~~~
ridruejo
Thanks, this is where I got the data from:

[https://dzone.com/articles/minideb-a-minimalist-debian-
based...](https://dzone.com/articles/minideb-a-minimalist-debian-based-docker-
image)

~~~
pebers
From looking at what I think is the Dockerfile for that image
([https://github.com/docker-
library/python/blob/b1512ead24c6b1...](https://github.com/docker-
library/python/blob/b1512ead24c6b111506a8d4229134a29da240597/2.7/alpine3.6/Dockerfile)),
that image is complex; it's downloading & building Python in it and adding &
removing a dev toolchain, in a few different layers.

I'm not surprised that I got something a lot smaller from just running `apk
add python3.6`, although as a result they are not comparing apples to apples;
their minideb example does pretty much exactly the equivalent (i.e.
downloading the distro-provided package, not compiling it within their image).

------
SwellJoe
This seems smarter than some of the container OS approaches that start from
distros that have weak or no package management, and rely entirely on the
"container" model to provide updates and some combination of spit and duct
tape to build them. There's a smallish Fedora for containers (exists in the
Docker registry) as well; it's about 70MB, which is still a little beefy.

Anybody know how big minideb is?

Edit: zwerdids posted that it's ~50MB so a wee bit smaller than the currently
commonly used Fedora container image. And an order of magnitude bigger than an
Alpine image.

------
CoreXtreme
It just saves top 5-6MB over Debian slim version of images. It's not worth my
time to use this instead of officially debian supplied images.

Edit: I would like to know where exactly this 5-6MB is saved.

~~~
kasabali
I guess removal of some essential packages

------
angrygoat
The `install_packages` command looks like a big win compared to the rather
spammy form most Dockerfiles use now to install packages, e.g:

    
    
        $ install_packages mime-support
    

vs:

    
    
        $ apt-get update && apt-get install -y --no-install-recommends mime-support && \
            apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
    

That's a great win in itself, this is excellent.

------
geofft
Neat. Some overlap with
[https://github.com/GoogleCloudPlatform/distroless](https://github.com/GoogleCloudPlatform/distroless)
; I think one big difference is that Google's approach uses bazel to download
and unpack .debs, and this one uses standard Debian tools (debootstrap). But
the end result sounds similar.

------
downrightmike
Picking up where Damn Small Linux left off.
[http://www.damnsmalllinux.org/download.html](http://www.damnsmalllinux.org/download.html)

~~~
ridruejo
There's a bunch of them, especially around networking use cases. Alpine itself
was a fork of another embedded Linux distro. One appeal of Minideb and a big
reason why we developed it is that at the end of the day, it is still Debian
and you have access to all the DEB packages out there, which tend to cover
more ground and be more actively maintained than more niche Linux distros

~~~
mst
wiremine's question upthread as to how this compares to debian:stable-slim
seems like it would benefit from an answer from you or another maintainer
(assuming I correctly read the "we" in your comment)

~~~
ridruejo
As some other comment pointed out, we update it daily. When we started debian-
slim was not an option for us, but it has caught in terms of size and
features, so we will definitely take another look

------
jayrwren
I love minideb. It is a great compromise when you need glibc but would have
otherwise used alpine.

~~~
viraptor
Curious: what are the scenarios in which you needed glibc?

~~~
davedunkin
Node.js packages with native code and .NET Core are a couple I’ve come across.
Basically any C-based code prebuilt for generic Linix.

~~~
nerdponx
But couldn't you rebuild them yourself?

------
simplehuman
Starred, thanks.

A little OT but how does bitnami make money? They don't seem to charge AMIs
atleast. So, I guess they charge AWS/GCE for providing 1-click images? Or are
they a consulting company (if so, why choose them over the original app
authors)? Or both?

~~~
ridruejo
Bitnami co-founder here. Most of what we produce is open source and we aim to
make money in ways that are useful to companies but not limit or handicap our
offering and alienate people. For example, we offer optional backup and
monitoring services through Bitnami Cloud Hosting
([https://bitnami.com/cloud/hosting](https://bitnami.com/cloud/hosting)) and
we also have commercial services for ISVs that want to package their
commercial apps through our platform. We also provide support for
infrastructure providers (i.e. cloud vendors) that want the applications
integrated with their platforms in specific ways

------
edsiper2
is there any big difference with the Debian image provided by Google ?

    
    
       launcher.gcr.io/google/debian8
    

(besides debian version)

------
amq
If I run dozens of containers based on the same Debian image, would Minideb or
even Alpine bring a big change, considering that Docker caches the layers?

~~~
devonkim
The point of smaller images to me isn't about disk savings as much as
minimizing dependencies and surface area of attacks such as for glibc, bash,
and OpenSSL in the past several years. Updating container images quickly is
absolutely essential given the myriad of possible problems if they were to
become stale.

I suppose it wouldn't hurt to have smaller image layers when updating these
containers more frequently to save on bandwidth at least.

~~~
peterwwillis
Reducing attack surface by only minimizing dependencies is a bit like putting
your house on stilts.

~~~
wvenable
You're arguing a straw man by putting the word _only_ in there.

~~~
peterwwillis
The author said 3 different things in their comment. I was answering this:

"The point [..] isn't about disk savings _as much as minimizing dependencies
and surface area of attacks_ such as for glibc, bash, and OpenSSL in the past
several years."

Technically they didn't say specifically _how_ they would minimize surface
area of attacks, so my assumption that they meant only by minimizing
dependencies (seeing as their comment was followed by a list of dependencies)
may have been faulty. Thanks for letting me know that in such a kind way.

------
luord
This is great, I created my own base images (for python and js, mostly) using
debian as base; this shall be the new base.

------
thinbeige
Slightly OT: Which distribution (for being a Docker host) has the best
unattended security updates incl. reboots?

Requirements:

\- Quick to setup, best would be a one-liner and not something I have to
google everytime

\- Update and reboot times can be slightly randomized, so the entire cluster
won't go down

~~~
Zhann__
You looking for CoreOS?

------
sintaxi
I use debian images for my infrastructure on VPS providers. Can anyone tell me
what makes this "container specific"?

~~~
jdwestby
One of the ways it reduces the size is by pulling out things that are very
unlikely to be required in a container, but are important for running on real
hardware. Things like udev, systemd, file system tools etc.

------
tokenizerrr
Off topic but what software is everyone using for their registry with ACLs and
pruning old images?

~~~
wolfgang42
GitLab Container Registry. It integrates beautifully with the rest of GitLab,
including the permissions and CI system. I believe it also has special support
for Kubernetes though I've not tried using that.

