Just one word of caution for those wanting to use the "scratch" container in production: if your binary you are packaging with the scratch container has some dependencies on a specific version of some very specific libraries, e.g. glibc, your app may not run when the container is being started on a host with a different OS than the one you used to package the container.
For example, you package your container on CentOS 7 but then your container gets to run on an older CentOS 6. In this case, binaries depending on glibc may fail to run since the glibc that comes with CentOS 7 is not backwards compatible with the older glibc coming with CentOS 6.
So, while it is really desirable to keep the container size as minimal as possible, one of the benefits of containers is to shield the app from the specifics of the underlying host OS providing it the same runtime no matter where the container will be run. And, the only way to really do that is to package a minimal OS with the container for your application.
Thanks for the update. I am aware of issues with mismatching glibc versions but was under an impression that an application wouldn't even start with a library missing from the image. That's why the Dockerfile contains library collection script. Here's a dive printout of a sample image contents for a dynamically linked application.
However, I'll certainly have a look at how this behaves on an ancient system. Your mention of CentOS 6 is a good example of one still fairly used (unfortunately).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Just one word of caution for those wanting to use the "scratch" container in production: if your binary you are packaging with the scratch container has some dependencies on a specific version of some very specific libraries, e.g. glibc, your app may not run when the container is being started on a host with a different OS than the one you used to package the container.
For example, you package your container on CentOS 7 but then your container gets to run on an older CentOS 6. In this case, binaries depending on glibc may fail to run since the glibc that comes with CentOS 7 is not backwards compatible with the older glibc coming with CentOS 6.
So, while it is really desirable to keep the container size as minimal as possible, one of the benefits of containers is to shield the app from the specifics of the underlying host OS providing it the same runtime no matter where the container will be run. And, the only way to really do that is to package a minimal OS with the container for your application.
Just my 2 cents.
Thanks for the update. I am aware of issues with mismatching glibc versions but was under an impression that an application wouldn't even start with a library missing from the image. That's why the Dockerfile contains library collection script. Here's a
diveprintout of a sample image contents for a dynamically linked application.However, I'll certainly have a look at how this behaves on an ancient system. Your mention of CentOS 6 is a good example of one still fairly used (unfortunately).