Closed LrsK closed 7 years ago
Your username looks disturbingly like mine :).
I'm a little concerned about the possibility for conflicts when using an existing base image, rather than scratch
, since dockerize
will probably end up replacing several of the shared libraries in the image, including libc
. For example:
$ dockerize -b ubuntu:12.04 /bin/ls
Step 1/3 : FROM ubuntu:12.04
---> aefa163f7a7e
Step 2/3 : COPY . /
---> e74687dfa140
Removing intermediate container 3ab03304466f
Step 3/3 : ENTRYPOINT /bin/ls
---> Running in 46a59501be86
---> 0976e1dd69e5
Removing intermediate container 46a59501be86
Successfully built 0976e1dd69e5
$ docker run --rm 0976e1dd69e5
/bin/ls: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.17' not found (required by /bin/ls)
That's a pretty rotten user experience, and I'm not sure there's a good way to avoid it.
That is a very good point.
I use dockerize a lot, but sometimes need to check the result more closely, which usually means exchanging scratch with busybox using sed in my deploy scripts. To be honest I've never tried Ubuntu or any larger distribution as a replacement base, the largest probably being Alpine. So far I've never had a problem, but that is probably because both busybox and Alpine don't interfere with the imported libs.
An alternative is just to:
dockerize -o myimage -n /path/to/bin
This will create the Dockerfile in the myimage
directory, along with the binary and shared libarries and anything else installed by dockerize
, but won't build the image. You can inspect, modify the Dockerfile
, etc.
That is in face what I do, but is really more a debugging thing. It is probably better to close this PR.
Thank you for the discussion, your username also made me do double takes!
Sometimes it is handy to use other base images than scratch. I've added a flag to set a custom base image. I also added some minor cleanup of the Jina-template with respect to newlines.