Support pausing and resuming a container

[lcmgh]

Hi!

In my integration test I like to test my apps behavior in case the database becomes unavailable. Currently I am stopping the db but of course I also want to test the recover of the database with its former state. Even if don't mind loosing the former db state I still have to create a new db pool because port changes on every container spawn and the already injected one can never recover.

Two options come to my mind to solve the issue: 1) Allow defining an explicit mapped host port 2) Allow to pause and continue container without changing the mapped host port (my preferred option)

Thanks

[DDtKey]

Are you (probably) looking for adding docker's pause/unpause to testcontainers api?

[thomaseizinger]

I have never heard of docker pause but it seems like a reasonable thing to implement so I am gonna accept a PR that adds a pause and unpause API to Container and ContainerAsync.

[FibreFoX]

Stupid question: wouldn't it make more sense to just use stop and start instead of introducing a new pause/unpause, to have it more "in line" with the Java implementation like documented on the website https://www.testcontainers.org/test_framework_integration/manual_lifecycle_control/?

I think it feels "more natural" when having both ecosystems (Rust + Java) using the same method language.

[DDtKey]

Hi @FibreFoX, I'll try to answer

stop + start recreates container (with graceful shutdown logic by sigterm signal or sigkill in case of hanging), so the state of such container will be dropped. For in-memory databases it's critical.

While pause/unpause doesn't. One more case is introducing some controlled delays.

Just a different behavior and could be useful for testing purposes.

Anyway, it's official docker API for suspending processes. And I don't think we should avoid this for aligning APIs.

[FibreFoX]

@DDtKey Thanks for clarification, I wasn't aware that stop + start actually recreate the containers instead just stopping and re-starting the container. And sure, this is a very special scenario.

If I understand correct, the testcontainers-java should have an open issue to feature-request this too, right?

[mervyn-mccreight]

One more case is introducing some controlled delays.

You could also use toxiproxy for this. I used this in some JVM project a while ago for testing (I used the java module there) and IMO it was pretty neat.

[anatolikarman]

I think you can call a dockerClient instance from your container instance so if you want to pause, it will look like this: myContainer.dockerClient.stopContainerCmd(myContainer.getContainerId()).exec(); and unpause: myContainer.dockerClient.startContainerCmd(myContainer.getContainerId()).exec()

[paulkeogh]

I think you can call a dockerClient instance from your container instance so if you want to pause, it will look like this: myContainer.dockerClient.stopContainerCmd(myContainer.getContainerId()).exec(); and unpause: myContainer.dockerClient.startContainerCmd(myContainer.getContainerId()).exec()

That doesn't work for me. The container is stopped and started.

[qrilka]

On a related note: ATM stop in both runners have the following in their rustdocs

Stops the container (not the same with pause).

Which is quite confusing without pause available anywhere.