We’re doing a lot of services in containers which are one-shot applications, like building a project’s source code. Containerizing is handy because the build environment is controlled.
This is all scripted/automated, which is good.
Often we want to clean up the containers afterwards, and there isn’t a reliable error-free way to do that, which is bad.
Sometimes the container is required to hang around in case it needs to be restarted. So
docker run --rm is a non-starter.
docker run doesn’t report the container id or name that was assigned.
We could look up existing containers immediately after the fact, but, none of the
docker ps type commands are guaranteed to return the container from this script’s last
docker run invocation; there is always a window where other containers can be started and the lookup will return those instead. It’s a race condition.
Generally we resort to
--name <name> but that relies on every developer picking non-colliding names, or, sometimes the container won’t start properly. When someone copies an existing script and modifies it, the container name may not get updated properly, and a collision-on-start may not happen for quite some time when it’s more onerous to debug.
The ideal solution is for
docker run to report the container id and/or name that it was assigned. That means the just-started container can always be uniquely identified, and reliance on human developers not making errors is also removed, improving the system as a whole.
Unless, did I miss this information in the documentation?