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

11–20 of 32 posts

Re: Inside Docker's “FROM scratch”

#11

Post by embano1 »

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…

Agreed, just for one app no need to create unneeded overhead. But PROD usually looks different. See paragraph "Application Environment" here http://queue.acm.org/detail.cfm?id=2898444 why you would still want to put static binaries in Docker containers.

Re: Inside Docker's “FROM scratch”

#12

Post by embano1 »

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.

Re: Inside Docker's “FROM scratch”

#13

Post by embano1 »

Intermernet wrote: post #7
rmoriz wrote: post #6

Earlier quoted context omitted.

Massive downside: You run your app as root or you have to do nasty mounts of /etc/passwd and /etc/group from your host

You can run a Docker container as a particular user. https://docs.docker.com/engine/reference/builder/#user You can use `setcap` to grant capabilities to the binary or the `pam_cap` module if you need to do capabilities per user. I haven't run across the need to run most containers as root for a while now.

Yup, in the end it´s an OS process and all rules apply. I did not care too much about Dockerfile best practices in my article. Good point, should at least have used "user ".

Re: Inside Docker's “FROM scratch”

#15

Post by throwaway2016a »

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 the option of using another smaller OS, like alpine, we decided not do it because we would give up a lot of flexibility that the OS was providing us.

Alpine is getting easier to work with. It's been a while since I haven't been able to find a pre-built package for something I needed for instance.

Re: Inside Docker's “FROM scratch”

#16

Post by lizxrice »

rmoriz wrote: post #6
Intermernet wrote: post #5

Earlier quoted context omitted.

Works just as well for Go binaries. It's pretty much the recommended base image for distribution of Go apps on Docker. I assume that it would be just as effective for any statically compiled binary. Edit: I really should have read the article first. It uses Go binaries as the example. Good to know Haskell folks are also using it.

Massive downside: You run your app as root or you have to do nasty mounts of /etc/passwd and /etc/group from your host

You don't have to mount the host versions - you can create container-specific ones.

See https://medium.com/@lizrice/non-privileged-containers-based-...

Re: Inside Docker's “FROM scratch”

#17

Post by ealexhudson »

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…

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 base image is a one-time cost that potentially pays itself back many times over.

Re: Inside Docker's “FROM scratch”

#19

Post by rtpg »

ealexhudson wrote: post #17
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…

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?

Re: Inside Docker's “FROM scratch”

#20

Post by stormbrew »

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 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 filesystem will have some of their disk pages shared.

Post reply on HN