Closed Tranquility2 closed 1 month ago
Image creation is now based on id as advised by @alexanderankin (tag is optional and not critical to the build flow)
Image cleanup is now optional (defaults to True
to facilitate the use-cases known to me)
Please note that test_core.py
now take double the time (~15sec on my machine)
for fast api, i can imagine the plan is to create a Testcontainer for an intree service to test against from other intree services' test suites. what is the plan for aws lambda exactly?
I think its basically extending the paradigm for testcontainers-python
.
Instead of only providing the supporting services for testing something, one can now test a service ("dockerized" one).
I updated the doctest for SrvContainer (and code ofc) to better reflect this, so I hope it will be more clear, any python web service could benefit from testing it like this + we can provide supported services as neeed, for example:
with RedisContainer() as redis_container:
redis_params = redis_container.get_client_params()
with FastAPIContainer() as server: # this is very close to SrvContainer
# do some calls to the server and utilize the fact that its connected to redis
*at this point I'm not as sure we will need a module for FastAPI but still needs to think about it
Now regarding aws lambda
its very similar to the localstack
module already available, and very ironically will probably also be used with it quite a lot. if we look at an example:
with LocalStackContainer() as localstack:
dynamo_client = localstack.get_client("dynamodb")
# prepare something in dynamo
with AwsLambdaContainer() as lambda:
# run some requests to http://localhost:9000/2015-03-31/functions/function/invocations
# this way we can be validating flow with dynamo
# and maybe even checking the changes on dynamo itself
this is static URL in all AWS lambdas
AwsLambdaContainer
will be a new module
similar=have all the same env vars, as its all AWS eco system
Decided to implement a module for FastAPI, I think it will be good even on a didactic level for anyone who needs to use it, as it include a working example and all the sources.
feat(core): Added AWS Lambda module
feat(core): Added FastAPI module
feat(core): Added SrvContainer
feat(core): Image build support (using Dockerfile)
They now reflect better the improvements and the work that was done.
I think I should split this PR to the 4 commit (PR for each)
So it will be easier to review and keep track Any advice on how to proceed will be welcomed
@Tranquility2 Thank you for your work here and joining efforts with the project, much appreciated š. I agree with your last proposal, splitting these changes into 4 dedicated PR would be much better.
Fun fact: That is also how I originally joined the Testcontainers project as a maintainer, since I authored a very similar project in Java back in the day š
1st part is up: https://github.com/testcontainers/testcontainers-python/pull/585
2nd part is up: #595
4th part is up: https://github.com/testcontainers/testcontainers-python/pull/655
Overview
So basically as you can see from the title this adds a functionally that I think is super useful, supporting working with Dockerfile for achieving even more compatibility with custom images.
The created image is cleaned and any any intermediate containers are removed.
Background
I'm a bit biased as I originally started from working on my own project: https://github.com/Tranquility2/dockerr that has some very clear similarities with
testcontainers
. I noticedtestcontainers
in Go and Java (for example) indeed support Dockerfile (and even some extra compatibility modes like Dockerfile DSL) so decided to take the time and add this totestcontainers-python
as well.Goal
The end goal will be supporting custom images that can be tested, in my use case:
Work Plan
This is what I'm planning to do
with CustomContainer(tag="my-custom-image:latest", path="/path/to/Dockerfile") as server: # tag is optional server_url = custom_container.get_url()