Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Inside Docker's “FROM scratch”

embano1.github.io

Post reply on HN
Print view View original

21–30 of 32 posts

Re: Inside Docker's “FROM scratch”

#21

Post by bpicolo »

throwaway2016a wrote: post #15
rem7 wrote: post #9

Unless building a base image... doesn’t this just take away from the benefits of using docker? If I understand one of the primary goals of containers it to: create an isolated environment with quotas and restrictions to the underlying OS by using Linux namespaces and cgroups. However one of the great things about docker is that I can do FROM ubuntu and then anywhere I run my container I now have my app running in an…

In today's Docker the biggest benefit I can see is Networking that container with other. Docker networking is quite powerful and having the container auto-join the network and have it routable from any other machine without having to even know what machine(s) it is actually running on is a nice thing. Being able to use consistent tooling with the rest of the containers is another plus. > But when we were faced with t…

The straightforward resource isolation is a big deal. CPU/Memory quotas are necessary for distributing containers among a machine pool.

Re: Inside Docker's “FROM scratch”

#22

Post by walterstucco »

cdancette wrote: post #3

Very interesting. Does someone have an example of a project where they used scratch? It seems to be only useful to build base distribution images

Yep

A minimal Cntlm Docker image

I am working for a big finance corporation and proxies are everywhere and configured in many different ways

First thing I do, I download my cntlm base image which is a bit less than 200K, take out my cntlm.conf from keybase and run it

From then on I can just set the proxy to localhost and keep working

Link, if anybody's interested https://hub.docker.com/r/massimo/cntlm/

Re: Inside Docker's “FROM scratch”

#23

Post by walterstucco »

embano1 wrote: post #12
cdancette wrote: post #3

Very interesting. Does someone have an example of a project where they used scratch? It seems to be only useful to build base distribution images

Thx! See me comment above on why you would want to put static binaries in "scratch", i.e. use "scratch" to deploy apps and not just for building base layers as you suggest.

You can however compose micro services with scratch

For example I created a cntlm base image (linked in another comment)

From there I can do

FROM my_base_image COPY whatever

and then add layers of services

first one is proxy

second one could be queue service (for example http://nsq.io)

then a message server, that just sends notifications

etc. etc. etc.

The same could be achieved downloading and configuring the static binaries, but Docker packaging, security and network separation makes evrything a little bit easier

Re: Inside Docker's “FROM scratch”

#24

Post by rkeene2 »

cdancette wrote: post #3

Very interesting. Does someone have an example of a project where they used scratch? It seems to be only useful to build base distribution images

I used FROM scratch to build a docker container for AppFS, which just has 2 files: init, and appfsd

http://appfs.rkeene.org/web/artifact/42acc0ed9e8f4327

init comes from: http://appfs.rkeene.org/web/artifact/ecb8eda1cfb32ecc

And just sets up some symlinks and starts appfsd, followed by running bash (which is cached and run transparently).

Re: Inside Docker's “FROM scratch”

#25

Post by kosinus »

stormbrew wrote: post #20
rtpg wrote: post #19

Earlier quoted context omitted.

If you're running multiple containers of images that are themselves derived from a same image, is it still a one-time cost? Is Docker smart enough to run "only one" instance of Ubuntu, for example?

What resources are you concerned about being consumed? - There will only ever be one running kernel with docker. - The base filesystem layer, if identically hashed, will be shared as an overlay filesystem. - The memory footprint of whatever each container runs (which will generally not be a full from runlevel0 system) will not be shared, except in the sense that binaries loaded into ram from the same overlay filesyst…

In practice, the base layers update often, and not all apps will be running from the same version.

Re: Inside Docker's “FROM scratch”

#26

Post by ealexhudson »

rtpg wrote: post #19
ealexhudson wrote: post #17

Earlier quoted context omitted.

The 'FROM scratch' with a single binary pattern is something I use a lot with stowage.org : basically, I can create series of containers that allow other developers to easily install and update dev-environment / build tool chain without having to do a bunch of packaging. That said, I definitely agree that you don't want to do 'FROM scratch' unless you're definitely not re-using the various upper layers. Having a fat…

If you're running multiple containers of images that are themselves derived from a same image, is it still a one-time cost? Is Docker smart enough to run "only one" instance of Ubuntu, for example?

What stormbrew said above. It's probably not an absolutely O(1) cost but in practice I haven't noticed the difference. I definitely have noticed a saving from pushing many different "slim" alpine images around (alpine is not at fault here, but the more differences your images have, the less you get to re-use existing layers).

Re: Inside Docker's “FROM scratch”

#27

Post by stormbrew »

kosinus wrote: post #25
stormbrew wrote: post #20

Earlier quoted context omitted.

What resources are you concerned about being consumed? - There will only ever be one running kernel with docker. - The base filesystem layer, if identically hashed, will be shared as an overlay filesystem. - The memory footprint of whatever each container runs (which will generally not be a full from runlevel0 system) will not be shared, except in the sense that binaries loaded into ram from the same overlay filesyst…

In practice, the base layers update often, and not all apps will be running from the same version.

That's true, but it is something that is potentially within your control as well.

Re: Inside Docker's “FROM scratch”

#28

Post by acdha »

lucaspiller wrote: post #10
rem7 wrote: post #9

Unless building a base image... doesn’t this just take away from the benefits of using docker? If I understand one of the primary goals of containers it to: create an isolated environment with quotas and restrictions to the underlying OS by using Linux namespaces and cgroups. However one of the great things about docker is that I can do FROM ubuntu and then anywhere I run my container I now have my app running in an…

> If you’re running a statically linked binary produced by go [...] In a way you are answering your own question. Sure you can give up Docker and use something else, but you are giving up benefits of using the Docker infrastructure and ecosystem. If you are just using Docker for one app, then yes I agree, but if you have other apps running through Docker then it’s certainly beneficial to do so even for statically lin…

This is especially important once an organization grows much. Once you start having ops or security teams, different development groups, etc. there's a significant benefit to having one way to manage everything.

A new sysadmin doesn't need to learn that custom way your hand-rolled deployment system handles dependencies, how to see what's supposed to be running on a box, etc. A security person who's wondering whether something is supposed to be listening on a port can at least see that it's something someone went to the trouble of exposing. That QA team or the person who inherited your maintenance coding can avoid learning a new way to ensure they have a clean CI build.

(That doesn't mean that Docker's always the right answer — maybe you've identified an area like networking where there's a reason not to use it — but in most cases the differences are below the threshold where it's worth caring)

Re: Inside Docker's “FROM scratch”

#29

Post by zokier »

rem7 wrote: post #9

Unless building a base image... doesn’t this just take away from the benefits of using docker? If I understand one of the primary goals of containers it to: create an isolated environment with quotas and restrictions to the underlying OS by using Linux namespaces and cgroups. However one of the great things about docker is that I can do FROM ubuntu and then anywhere I run my container I now have my app running in an…

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.

Re: Inside Docker's “FROM scratch”

#30

Post by TheDong »

zokier wrote: post #29
rem7 wrote: post #9

Unless building a base image... doesn’t this just take away from the benefits of using docker? If I understand one of the primary goals of containers it to: create an isolated environment with quotas and restrictions to the underlying OS by using Linux namespaces and cgroups. However one of the great things about docker is that I can do FROM ubuntu and then anywhere I run my container I now have my app running in an…

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 anything that does a network request (e.g. `apt-get update`) as tainted and unreproducible.

There are plenty of ways to create reproducible minimal images (such as using the nix package manager to create the rootfs), but the official docker images don't use those techniques and the docker tooling and ecosystem actively fight against it.

Docker is clearly focused on usability / first-user-experience at the expense of reproducibility and immutability. They encourage the use of the 'latest' tag, they encourage the use of procedural network-heavy build steps, and they have made not attempt to promote or create alternative tooling which tackles reproducibility correctly.

Post reply on HN