-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow for graceful container stop #1000
Comments
Yes, you are right in this regard. |
Well, I think it is not very common one... I use testcontainers as a very convenient library to start/stop docker containers from my Java application. It is kinda "orchestrator", which starts and stops several containers in a sequence to achieve some result. So on one of the steps I have to start a container, wait for some externally observable effect and then stop this container. But I need to ensure that all shutdown hooks of that application (Spring's @PreDestroy annotations) complete successfully. Currently it is not possible, container is killed too soon. |
Okay I see. We can probably also add this to the current version as a manually callable method on |
Yes, that was what I thinking about. IMO ideally we should introduce new method |
Yes, while I'd also like to align our API more closely to the domain language used by Docker (start/stop/pause/kill), I don't think the breaking change is worth it at the moment. So adding a more explicit method makes sense IMO. |
Hei, guys. What do you think about marking this for 2.0 milestone? :) |
I have taken a look how easy it would be for me to propose a PR. I was unable to find a suitable place for my new proposed methods. Currently On the other hand, in our particular case we have found a satisfying workaround (shutting applications down via Spring Boot's actuator), so this issue does not bother us any more at all. As a result, I suggest just closing this issue as not relevant. |
This proposal is still useful for test cases that involve microservice disconnections/reconnections due to docker containers stopping. |
Also it is strange, that stop stops and removes a container from the point of a Docker user (sooner or later you have to deal with the Docker). |
I think a good first step would be to keep everything as-is but use a stop command instead of a kill one. The default timeout of 10s should be fine in most cases. If necessary, it could be made configurable or an overloaded |
There is
Also note that stopping and then starting a container won't work properly (one of the use cases for not killing the container from Given this, I suggest we close this issue. @rnorth @kiview WDYT? |
Thanks, that's slightly better than overriding |
uh? Why?
Yes, there is an overall confusion of
We're very usecase-driven, plus we don't want to send a wrong message that, in general, containers should be gracefully terminated, given the domain of testing. If it is really needed, I suggest doing it manually and explicitly is the best approach. Not to mention that as soon as we introduce any concept of graceful termination, people will start asking for configurable timeouts, retries, custom termination signals, etc etc. And, even if we add it to the JVM termination process, it would be hard to add it to Ryuk, and this would break the expectations. |
TBH I was just cargo-culting what
In my case, I want to test that a container does handle SIGTERM properly which is arguably not the main use case of Testcontainers.
I can certainly relate to the trade-offs of adding such a feature being an open-source maintainer myself. 😉 |
In this case, I would highly recommend to do it explicitly, as part of the test's scenario 👍
:D I knew you would understand it :) |
Thanks for the tip! |
Hey people, Another use-case for a graceful stop if when capturing code coverage of the process running in the container with the Jacoco agent. The most reliable way to capture coverage is to have it dump coverage on exit, but that requires a graceful shutdown... |
Hi everyone, here's a use-case we have for this issue and it also involves a JVM agent. We're building our production system as a docker container and then running tests against it, so that system-under-test itself and all the dependencies are running as docker containers using testcontainers with a common network. Currently we're checking out possible transition to spring-native with GraalVM. It provides a special agent that needs to run in JVM while tests are running. So that would be pretty easy for us to do we thought originally, but... the agent only writes out the results when JVM is terminated gracefully. So graceful stop of the container would be very helpful to avoid ugly workarounds. |
I'll add my pain from ticket #2608 |
Now @shaburov, I'm all up for encouraging them to fix this by highlighting more use cases where this is an issue. But, personally, I'd say comments like Maybe a more productive approach would be to raise a PR or to offer up some sponsorship money to prioritising this bug, if it's causing you or your company enough pain to be worth it. Of course, the same can be said to me too! |
@big-andy-coates Thank you for taking on the task. |
Hey everyone! I thought about executing a command in an After reading this thread, if I understand correctly, the container is being "killed" after all the tests are running, so there isn't a possibility to execute a command on stop. Is there a workaround for this issue that I missed? |
Currently I see only 1 method to stop a running testcontainer:
org.testcontainers.containers.GenericContainer#stop
. But to my great surprise and dismay that method ends up callingdockerClient.killContainerCmd
. So there is no way for graceful shutdown of running container which would allow for the application running inside it to perform any expected cleanup.Please, provide a graceful stop.
The text was updated successfully, but these errors were encountered: