Skip to content
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

Open
timbmg opened this issue Apr 18, 2020 · 14 comments
Open

Dockerfile support #83

timbmg opened this issue Apr 18, 2020 · 14 comments
Assignees

Comments

@timbmg
Copy link
Collaborator

timbmg commented Apr 18, 2020

Similar to allowing to run docker-compose files, would be great to just run a Dockerfile.

@tillahoffmann
Copy link
Collaborator

tillahoffmann commented Apr 29, 2020

@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 docker-compose if #78 is merged.

Is there any reason why running docker build prior to spinning up your tests isn't sufficient or desirable?

@callamd
Copy link
Contributor

callamd commented Apr 29, 2020

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.

@inikolaev
Copy link

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.

@HosseyNJF
Copy link

+1 :)

@bfotzo
Copy link

bfotzo commented Mar 7, 2024

@tillahoffmann
+1

I have a use case where I would like to use Dockerfile.

I'm ready to contribute and implement the feature if possible

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

@alexanderankin
Copy link
Member

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:

https://github.com/testcontainers/testcontainers-java/blob/d3b0df2d89ee349890c94b0ce220a167c82ddf51/core/src/test/java/org/testcontainers/junit/DockerfileTest.java#L54-L71

    @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);
    }

@bricefotzo
Copy link
Contributor

Hello!
Can I be assigned to this one please?
I woule like to implement it if it's okay for you.
Thanks!

@alexanderankin
Copy link
Member

alexanderankin commented Mar 9, 2024

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 Union type of DockerImage (or some other name) and str - where that other type would provide an os.PathLike and an indication that it should be build with the docker client.

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).

@bricefotzo
Copy link
Contributor

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.

@bricefotzo
Copy link
Contributor

Hello @alexanderankin!
Just to let you know that I updated the PR with my new proposal. I'm open to any feedback and of course changes requests if you have.
Thanks

@Tranquility2
Copy link
Contributor

@alexanderankin you asked for some feedback and alternative API design, I hope you will find #559 Interesting.
I think keeping it more like the original DockerContainer is the way to go, Context manager is more pythonic and this version helps to keep it more separated.

@alexanderankin
Copy link
Member

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.

@Tranquility2
Copy link
Contributor

The 1st part of the quadrilogy presented on #559 is ready.
I hope it will help to resolve this issues and provide the infra for:
feat(core): SrvContainer
feat(core): FastAPI module
feat(core): AWS Lambda module

alexanderankin pushed a commit that referenced this issue May 31, 2024
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)
alexanderankin added a commit that referenced this issue Jun 18, 2024
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]>
alexanderankin pushed a commit that referenced this issue Jun 28, 2024
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.
alexanderankin pushed a commit that referenced this issue Jul 31, 2024
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

10 participants