Testcontainers is a Python library that providing a friendly API to run Docker container. It is designed to create runtime environment to use during your automatic tests.
Hi! I'm have been working on a testcontainer for SaltStack, which is a OS configuration tool.
My motivation is that configuration tooling also needs to test its modules, and the normal system, salt-kitchen makes some assumptions that breaks with what i would call common structuring of the system :)
So I've made a workable solution extending the regular DockerImage with extra functionality to generate the correct configuration and mount of the roots we need, but what I'm a bit stuck at is what the running command should be. As this is a setup where the actual command (apply state) runs once and exits. From what i see/understand, by exiting the container I'm not able to start the next step of testing where i actually validate the state with help of for example testinfra
So right now I've opted for a two stage approach: Where the DockerFile stays alive with CMD [ "tail", "-f", "/dev/null" ] and the user invokes the state apply command after container.start()
How wrong of a pattern is this for a testcontainer? From what i see all others are mainly focusing on starting services to support, and not directly being used.
Would it make sense to run a init container that runs the apply, then a new instance that i can run the state inspection tests on afterwards? Or maybe run the apply as a part of the Image building?
PS: I know it does not make a lot of sense to use a Config management tool inside a container, the point here is simply to quickly test modules that will later be used on proper operating systems :)
Hi! I'm have been working on a testcontainer for SaltStack, which is a OS configuration tool. My motivation is that configuration tooling also needs to test its modules, and the normal system, salt-kitchen makes some assumptions that breaks with what i would call common structuring of the system :)
So I've made a workable solution extending the regular DockerImage with extra functionality to generate the correct configuration and mount of the roots we need, but what I'm a bit stuck at is what the running command should be. As this is a setup where the actual command (apply state) runs once and exits. From what i see/understand, by exiting the container I'm not able to start the next step of testing where i actually validate the state with help of for example testinfra
So right now I've opted for a two stage approach: Where the DockerFile stays alive with
CMD [ "tail", "-f", "/dev/null" ]
and the user invokes the state apply command aftercontainer.start()
How wrong of a pattern is this for a testcontainer? From what i see all others are mainly focusing on starting services to support, and not directly being used.
Would it make sense to run a init container that runs the apply, then a new instance that i can run the state inspection tests on afterwards? Or maybe run the apply as a part of the Image building?
PS: I know it does not make a lot of sense to use a Config management tool inside a container, the point here is simply to quickly test modules that will later be used on proper operating systems :)