Dockerfile support

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

@timbmg

@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?

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.

@tillahoffmann

@tillahoffmann This appears to be supported in Java.
Let's reconsider this feature.

+1 :)

@tillahoffmann

@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

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

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

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

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.

@alexanderankin

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

@alexanderankin

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

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

feat(core): Image build (Dockerfile support) (#585)

feat(core): Added ServerContainer (#595)

feat(core): Added Generic module (#612)

feat(new): Added AWS Lambda module (#655)

What is still open for this ticket?

@CarliJoy

Good point @CarliJoy, I think nothing, we have #585, I did spot a bug in the docs and will update soon.

docs: fix building images guide to use real DockerImage API (#1047)

Navigation Menu

Repository navigation

Dockerfile support #83

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Dockerfile support #83

Description

Activity

tillahoffmann commented on Apr 29, 2020

callamd commented on Apr 29, 2020

inikolaev commented on Dec 19, 2022

thedrow commented on Dec 20, 2022

HosseyNJF commented on Aug 20, 2023

bfotzo commented on Mar 7, 2024

alexanderankin commented on Mar 8, 2024

bricefotzo commented on Mar 9, 2024

alexanderankin commented on Mar 9, 2024

bricefotzo commented on Mar 9, 2024

bricefotzo commented on Mar 11, 2024

Tranquility2 commented on Apr 30, 2024

alexanderankin commented on Apr 30, 2024

Tranquility2 commented on May 27, 2024

CarliJoy commented on Jun 5, 2026

Tranquility2 commented on Jun 6, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions