Live data from Hacker News

Inside Docker's “FROM scratch”

embano1.github.io

31–32 of 32 posts

Re: Inside Docker's “FROM scratch”

#31
My current philosophy on this is use always start from scratch if I can. This would be the case where I'm using something that is statically compiled, or a standalone go binary.

If I need more facilities from an OS, then I try to use a micro-distribution like Alpine. This could be because I have a more complex go binary, or if I have a python script that I want to execute.

If Alpine isn't cutting it, then I go for something like Ubuntu. This is typically because Alpine doesn't have some library that I need, or because musl libc isn't behaving properly.

Re: Inside Docker's “FROM scratch”

#32
post #30
post #29

Earlier quoted context omitted.

Funny, I think using FROM ubuntu takes away the main benefits of Docker, namely the ability to have perfectly groomed execution environment, that is also fully reproducible and with minimal external dependencies. Basically having immutable infrastructure and infrastructure as code as the core pillars, enabling them to be so smooth that live mutation etc would be unnecessary.

Weird, if "fully reproducible" and "groomed/minimal" environments were the goal of docker, I'd expect image tags to not be mutable, the "FROM" line in a Dockerfile to only take immutable hash references, and for the default `docker build` environment to have no network access. At the very least, `docker build` should accept and produce a "lock" like file which specifies the source image it came from, and mark anythin…

But you can already do this.

FROM myregistry.example.com/foo:1.2.3@sha256:

You can call `docker build --network=none` to disable network access during the build step.

Why would you make a lock file from a Dockerfile? You can specify everything inside it already; from the version you pull with yum to explicitly COPY'ing RPMs/debs you keep locally.

Post reply on HN