I've been trying to understand why Docker's push command only takes a single argument. It feels like it would be much more intuitive to allow for two arguments: one for the local image and another for the remote target. With just one argument, it leads to some odd naming conventions where the entire path of an image ends up in the name itself. For instance, my image names are so long that they don't fit in the desktop app. On top of that, if a client wants their specific version of the image, I have to tag it according to their file path structure and push that. It's frustrating! Is there a valid reason behind this design choice?
3 Answers
Keep in mind that push is designed to send your local image to a remote registry. You need to specify where you're pushing it. If you want the image under a specific repository, you should tag it first. That’s just how the workflow operates.
The push command always means that you are sending your image to a remote location. It simplifies the process by focusing on the image that already has a proper tag instead of complicating things further with multiple arguments.
The push command actually refers to an already named image. Instead of creating multiple images, you can just use tags to differentiate between them. You just have to tag your image properly before pushing it.
That’s a fair point, but it still means I have to create a lot of tags for images that are essentially the same, which can get messy.
I see your point, but if I have to keep creating tags for every client and project, it becomes unmanageable.