Inside Docker's “FROM scratch”
embano1.github.io
Inside Docker's “FROM scratch”
1–10 of 32 posts
Re: Inside Docker's “FROM scratch”
#2[deleted]
Re: Inside Docker's “FROM scratch”
#3Very interesting. Does someone have an example of a project where they used scratch?
It seems to be only useful to build base distribution images
Re: Inside Docker's “FROM scratch”
#4Very interesting. Does someone have an example of a project where they used scratch? It seems to be only useful to build base distribution images
Yes.
Works great with Haskell statically compiled binaries. Running the binary through UPX i've managed to get small HTTP microservices down to a 2MB docker image with just Scratch.
Re: Inside Docker's “FROM scratch”
#5Very interesting. Does someone have an example of a project where they used scratch? It seems to be only useful to build base distribution images
Yes. Works great with Haskell statically compiled binaries. Running the binary through UPX i've managed to get small HTTP microservices down to a 2MB docker image with just Scratch.
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.
Re: Inside Docker's “FROM scratch”
#6Earlier quoted context omitted.
Yes. Works great with Haskell statically compiled binaries. Running the binary through UPX i've managed to get small HTTP microservices down to a 2MB docker image with just Scratch.
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
Re: Inside Docker's “FROM scratch”
#7Earlier 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 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.
Re: Inside Docker's “FROM scratch”
#8Very interesting. Does someone have an example of a project where they used scratch? It seems to be only useful to build base distribution images
Static building, as mentioned by others, also works for Rust. Portier builds this way:
https://github.com/portier/portier-broker/blob/master/Docker...
This uses the awesome clux/muslrust Docker image as a build environment, then copies the result into a new ‘from scratch’ layer.
Re: Inside Docker's “FROM scratch”
#9Unless 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 OS that I’m comfortable with. So I can always run bash inside the container and apt-get whatever I need and debug it/experiment etc...
I understand the problem with docker image sizes. I worked at a company where we had a ~1GB image and our CI tool didn’t support caching of docker images so it would take a good 15 minutes to do a build every time. 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.
If you’re running a statically linked binary produced by go and that’s all you want on your pretty much empty image, why not just scp the file and run it manually under a cgroup? Or good ol choot/jails/zones?
Re: Inside Docker's “FROM scratch”
#10Unless 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 linked executables, to keep everything consistent.