Add '--replace' option into container creation command

[devcoons]

closes #5023

- What I did

Implemented a --replace option within the container create command, allowing for the removal (if existing) of the container with the specified name without the need to separately execute the remove <container_name> command.

- How I did it

In the source file cli/command/container/create.go

• Line 73: Added the new option as boolean with default value false
• Line 255: If the option is true and the user has supplied a name we call the ContainerRemove(..)

- How to verify it

docker create --name=stitch hello-world
docker create --name=stitch hello-world (here we get an error)
docker create --replace --name=stitch hello-world (works)

- Description for the changelog

Added --replace option to create command for removing existing containers by name without prior remove <container_name> command.

[thaJeztah]

Thanks for contributing!

I'm still struggling to find the use-case for this though, and not sure if we should do this.

While there could be some use-cases that (e.g.) are used to update or replace a container, there may already be better ways to achieve that;

• docker compose allows updating your stack by updating the compose file, and running docker compose up (which performs steps needed to reconcile state with the state in the compose-file)
• with swarm enabled (which could be a single node), docker service update allows updating definition of services, which will create new tasks to replace the old one (but keeping a configurable number of previous instances)
• for some use-cases (not all options can be updated) docker container update can be used to update an existing container's configuration
• for other scenarios, and for sure it's not as "polished", chaining commands together (docker rm -fv <container> && docker run ...) or creating a shell alias for this could be used

The current approach in this PR means that any container with the given name would be forcefully killed and removed, which can be a very destructive operation.

I think this would warrant a more in-depth look into use-cases and a design based on that; without having given it a lot of thought, I'm considering (again, depending on use-cases);

• extending docker container update and/or introducing a docker container edit option; this is something that has come up in discussions, but combined with implementing reconciliation logic; some changes will require a new container to be created, which is something that could be added to that logic (which could be either an explicit option to be set, or use a similar logic as swarm where previous iterations are kept)
• a docker container replace command that explicitly replaces an existing container; possibly combined with the above

In either case, I think this requires some thinking before we implement this, and I'd rather not take this pull request (also because there's existing options that could allow this).

[devcoons]

Thanks for contributing!

I'm still struggling to find the use-case for this though, and not sure if we should do this.

While there could be some use-cases that (e.g.) are used to update or replace a container, there may already be better ways to achieve that;

• docker compose allows updating your stack by updating the compose file, and running docker compose up (which performs steps needed to reconcile state with the state in the compose-file)
• with swarm enabled (which could be a single node), docker service update allows updating definition of services, which will create new tasks to replace the old one (but keeping a configurable number of previous instances)
• for some use-cases (not all options can be updated) docker container update can be used to update an existing container's configuration
• for other scenarios, and for sure it's not as "polished", chaining commands together (docker rm -fv <container> && docker run ...) or creating a shell alias for this could be used

The current approach in this PR means that any container with the given name would be forcefully killed and removed, which can be a very destructive operation.

I think this would warrant a more in-depth look into use-cases and a design based on that; without having given it a lot of thought, I'm considering (again, depending on use-cases);

• extending docker container update and/or introducing a docker container edit option; this is something that has come up in discussions, but combined with implementing reconciliation logic; some changes will require a new container to be created, which is something that could be added to that logic (which could be either an explicit option to be set, or use a similar logic as swarm where previous iterations are kept)
• a docker container replace command that explicitly replaces an existing container; possibly combined with the above

In either case, I think this requires some thinking before we implement this, and I'd rather not take this pull request (also because there's existing options that could allow this).

Hello @thaJeztah,

Thank you for your feedback.
The aim is to achieve functionality similar to podman, which currently offers this capability. To align seamlessly, I've renamed the flag from --force to --replace (reflects better its purpose).