Repository navigation
create before start issue #997
Description
Activity
My main question is would we allow clients access to containers which are created, running & stopped? Currently the
Container._containerwill pretty much only be in the running state, b/c the currentstartmethod callsrun. While we certainly could make thestartmethod docreate+start, another option may be to expose a.createmethod, and thenstartcould check if_containerhas already been created for backwards compatibility. That'd afford the opportunity for callers to operate on the created container prior to starting, getting semantics much closer to the docker cli & api. Yet another option may be tocreatethe container in the initializer directly, so an instantiated class always corresponds to a created container.For reference (best of my knowledge, please correct me)
Things you can do prior to
starting a container:- Connect additional networks - what would the behavior of
with_networkbe on a created container. Currently it looks like we only support one network, but I believe you can connect to multiple in theory. One during creation - Copy files in/out. Would this be supported with
with_copy_into_containerorcopy_into_container?
Things you can't do prior to
starting a container:- Several places where we check
if self._containerwillraise ContainerStartExecption( here in get_logs for example). That may need to check something about the state of the container, or maybe blindly call the relevant docker_client commands and let those exceptions propagate. Could also potentially wrap those into something more user friendly.
Stopped container:
- We currently remove the container upon stopping. I've run into this before whereby I wanted to inspect stopped container logs and was unable to without overriding the
stopmethod. Should we afford users the ability to work with a stopped container?
Reacted by Andreas Motl- Connect additional networks - what would the behavior of
- So for stopped container I would recommend using a debugger but if there is a simple fix maybe we can explore, thinking about the others have look at the code for them…On Thu, Apr 2, 2026, 9:21 AM Ryan Hoban ***@***.***> wrote: *rhoban13* left a comment (testcontainers/testcontainers-python#997) <#997 (comment)> My main question is *would we allow clients access to containers which are created, running & stopped*? Currently the Container._container will pretty much only be in the running state, b/c the current start method calls run. While we certainly could make the start method do create + start, another option may be to expose a .create method, and then start could check if _container has already been created for backwards compatibility. That'd afford the opportunity for callers to operate on the created container prior to starting, getting semantics much closer to the docker cli & api. Yet another option may be to create the container in the initializer directly, so an instantiated class always corresponds to a created container. For reference (best of my knowledge, please correct me) Things you can do prior to starting a container: 1. Connect additional networks - what would the behavior of with_network be on a created container. Currently it looks like we only support one network, but I believe you can connect to multiple in theory. One during creation 2. Copy files in/out. Would this be supported with with_copy_into_container or copy_into_container? Things you can't do prior to starting a container: 1. Several places where we check if self._container will raise ContainerStartExecption ( here in get_logs <https://github.com/testcontainers/testcontainers-python/blob/87332c1332a30b673aac919b48e296e21f2c1baf/core/testcontainers/core/container.py#L310> for example. That may need to check something about the state of the container, or maybe blindly call the relevant docker_client commands and let those exceptions propagate. Could also potentially wrap those into something more user friendly. Stopped container: 1. We currently remove the container <https://github.com/testcontainers/testcontainers-python/blob/87332c1332a30b673aac919b48e296e21f2c1baf/core/testcontainers/core/container.py#L229> upon stopping. I've run into this before whereby I wanted to inspect stopped container logs and was unable to without overriding the stop method. Should we afford users the ability to work with a stopped container? — Reply to this email directly, view it on GitHub <#997?email_source=notifications&email_token=ACECGJAQOCIIOLG3RUUR5G34T2HRHA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMJXHA4TQOJVGIYKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4178989520>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACECGJDIVMT4DPBBWRHOYFD4T2HRHAVCNFSM6AAAAACXKW2AWOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DCNZYHE4DSNJSGA> . You are receiving this because you authored the thread.Message ID: ***@***.***>
I'm sorry but I need to ask the obvious, if one needs a file in the container prior to is start don't you usually do it as part of the Docker-file/Build process? we do support images and that's the main flow I imagine (other than some interesting debug cases).
What I'm trying to say is that the use case is not very clear to me (copying stuff to the container but not the image + doing it before anything even starts)
Going back to the original PR "This is often crucial like when you want to copy in a config file which is used by the entrypoint script or even more: if you copy in the actual entrypoint script the container should start with." This sounds exactly like something that I would personally do in the build stage (btw I used temp local images with testcontainers and its great)
Help me out, what am I missing?this is a feature of testcontainers in other languages and its very useful. building local images is kind of a lot of extra work imo
Reacted by Roy Moore, Günther Grill and Andreas MotlTo also give a practical use case for this: We use the https://github.com/cdelmonte-zg/nanoidp/pkgs/container/nanoidp image which supports comprehensive configuration via config yamls. Now, to test different scenarios, we have about 15 different configs for different tests. When the container is started, the configs must be in place to have them picked up.
- Pre-building the docker image would be very impractical as we change a log in the configs
- Mounting in the configs is also very annoying, as we have different environments including docker-in-docker, what makes mounting very hard.
Copying in files after creating but before starting the container is IMO the easiest option.
Reacted by Roy Moore and Andreas MotlThank you for excellently describing this use case, @guenhter 👍. It is similar with CrateDB, where we occasionally want to provide additional files into the container before invoking it, exercised here with a little Compose rig that configures CrateDB with SSL, also using a YAML file accompanied with Java keystore and truststore files. It would be sweet if we could exercise the same also with pure testcontainers. 🍀
Any update here? I'd really appreciate if this support would come in soon, as at the moment it is very annoying to workaround the problem...
- ok new rc release coming this week with whatever changes are available to be merged on this topic. if someone can link the latest state of things here, that would be helpful. ill merge/release it. also if you have any feedback about the other rc that went out https://pypi.org/project/testcontainers/4.15.0rc1/ that would be really great, so that i know that i dont have to roll anything back.…Message ID: <testcontainers/testcontainers-python/issues/997/4286027533@ github.com>
ok we are going to have to fix anything regarding #997 (comment) in follow up prs imo
this ticket discusses nuances about creating containers before starting them