-
Notifications
You must be signed in to change notification settings - Fork 297
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
Dockerfile support #83
Comments
@timbmg, thank you for the suggestion. My hunch is that the scope of the library would start ballooning a bit if we start introducing build steps. Having said that, you raise a good point that it's available for Is there any reason why running |
I can't really imagine a workflow where this could be useful. Surely the other dependencies will be built beforehand, and if they're not then docker-compose will build them. |
Was just looking for exactly this feature - I would like to be able to start a database container, but I need it to have some additional extensions to be installed first. The beauty of test containers is that I don't need to build anything else prior to starting my tests - I start them and it just works. But if this is not supported then I have to come up with some fixture that does that for me, perhaps using the provided docker client. |
+1 :) |
I have a use case where I would like to use Dockerfile.
I han API designed with FastAPI and I would like to leverage the power of testcontainers to test the build and readiness of my API My tests would look like : def test_docker_run_with_dockerfile():
fastapi_container = FastAPIContainer("fastapi:local", dockerfile="/workspace/my-api/", port=8000)
with fastapi_container as fastapi:
url = f"http://{fastapi.get_container_host_ip()}:{fastapi.get_exposed_port(fastapi.port)}/"
r = requests.get(url)
logging.info(r.text)
assert r.status_code == 200
assert "Welcome to fastapi with dockerfile!" in r.text |
i dont know where it would fall on our list of priorities but i think it would be acceptable for this library to have something like: @Test
public void dockerfileBuilderWorks() {
ImageFromDockerfile image = new ImageFromDockerfile()
.withFileFromClasspath("test.txt", "mappable-resource/test-resource.txt")
.withFileFromString("folder/someFile.txt", "hello")
.withDockerfileFromBuilder(builder -> {
builder
.from("alpine:3.16")
.workDir("/app")
.add("test.txt", "test file.txt")
.run("ls", "-la", "/app/test file.txt")
.copy("folder/someFile.txt", "/someFile.txt")
.expose(80, 8080)
.cmd("while true; do cat /someFile.txt | nc -l -p 80; done");
});
verifyImage(image);
} |
Hello! |
the potential implementation in #455 is very interesting but id like to figure out how we can do this without passing image and dockerfile separately. whereas the reference implementation from java uses a DockerImage class, we can have a ill assign the issue to you for now but I think we are generally looking for feedback from any potential users or contributors about a better API design (or testing ideas). |
I totally agree with you. I also had a thought about another way to implement it using a specific class for image building without changing the docker client class. I'm even more confortable with it! I'll propose you changes with another way of doing that. |
Hello @alexanderankin! |
@alexanderankin you asked for some feedback and alternative API design, I hope you will find #559 Interesting. |
I was in the middle of job switching when i was added as contributor, the new job has really kicked up a notch and I haven't had time to spend on testcontainers all that much. to be clear, this issue is not a priority for the project. It is at least below fixing DinD, MacOS/Windows, and ipv6/ipv4 stuff, things that prevent people using the library. i re-opened this as a nice to have, not a core requirement. hope to be able to revisit soon. |
The 1st part of the quadrilogy presented on #559 is ready. |
As part of the effort described, detailed and presented on #559 (Providing the implementation for #83 - Docker file support and more) This is the first PR (out of 4) that should provide all the groundwork to support image build. This would allow users to use custom images: ```python with DockerImage(path=".") as image: with DockerContainer(str(image)) as container: # Test something with/on custom image ``` Next in line is: `feat(core): Added SrvContainer` And later on: `feat(core): Added FastAPI module` `feat(core): Added AWS Lambda module` (all of the above can be overviewed on #559)
As part of the effort described, detailed and presented on #559 This is the seconds PR (out of 4) that should provide all the groundwork to support containers running a server. This would allow users to use custom images: ```python with DockerImage(path=".", tag="test:latest") as image: with ServerContainer(port=9000, image=image) as srv: # Test something with/on the server using port 9000 ``` Next in line are: `feat(core): Added FastAPI module` `feat(core): Added AWS Lambda module` --- Based on the work done on #585 Expended from issue #83 --------- Co-authored-by: David Ankin <[email protected]>
As part of the effort described, detailed and presented on #559 This is the third PR (out of 4) that should provide all the groundwork to support containers running a server. As discussed on #595 this PR aims to refactor the `ServerContainer` under a new dedicated module called "generic". ![image](https://github.com/testcontainers/testcontainers-python/assets/7189138/b7a3395b-ce3c-40ef-8baa-dfa3eff1b056) The idea is that this module could include multiple generic implementations such as ```server.py``` with the proper documentation and examples to allow users simpler usage and QOL. This PR adds the original FastAPI implementation as a simple doc example, I think this aligns better following #595 Next in line is ```feat(core): Added AWS Lambda module``` Based on the work done on #585 and #595 Expended from issue #83 --- Please note an extra commit is included to simulate the relations when importing between and with other modules.
As part of the effort described, detailed and presented on #559 This is the 4th (and final in this track) PR that should provide support for AWS Lambda containers. This module will add the ability to test and run Amazon Lambdas (using the built-in runtime interface emulator) For example: ```python from testcontainers.aws import AWSLambdaContainer from testcontainers.core.waiting_utils import wait_for_logs from testcontainers.core.image import DockerImage with DockerImage(path="./modules/aws/tests/lambda_sample", tag="test-lambda:latest") as image: with AWSLambdaContainer(image=image, port=8080) as func: response = func.send_request(data={'payload': 'some data'}) assert response.status_code == 200 assert "Hello from AWS Lambda using Python" in response.json() delay = wait_for_logs(func, "START RequestId:") ``` This can (and probably will) be used with the provided [LocalStackContainer](https://testcontainers-python.readthedocs.io/en/latest/modules/localstack/README.html) to help simulate more advance AWS cases. --- Based on the work done on: - #585 - #595 - #612 Expended from issue #83
Similar to allowing to run docker-compose files, would be great to just run a Dockerfile.
The text was updated successfully, but these errors were encountered: