Outputs the equivalent argv of what you would get with a docker run
command.
This considers the given image's CMD
, ENTRYPOINT
, and docker run
's --entrypoint
flag.
$ run hello-world@sha256:96ebeec770e1af26469c98913277e1c3b40933202ca398cefc16177c3f26cc75
["cmd","/C","type C:\\hello.txt"]
$ run --entrypoint /crane hello-world@sha256:96ebeec770e1af26469c98913277e1c3b40933202ca398cefc16177c3f26cc75
["/crane"]
$ run hello-world@sha256:96ebeec770e1af26469c98913277e1c3b40933202ca398cefc16177c3f26cc75 crane
["crane"]
$ run gcr.io/go-containerregistry/crane version
["/ko-app/crane","version"]
$ run --entrypoint '["crane", "ls"]' gcr.io/go-containerregistry/crane ubuntu
["crane","ls","ubuntu"]
Yes! This is what kept tripping me up. As was explained to me, the CMD depends on the ENTRYPOINT, because we're just supplying args to the entrypoint binary. If we replace the entrypoint, those args should be invalidated.
Your summary is perfect -- I couldn't understand why you would use one approach over the other, but it comes down to whether you treat a container as a process or an environment in which to run processes.