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

fix(DinD): add feature flag to re-enable DinD #622

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

alexanderankin
Copy link
Collaborator

@alexanderankin alexanderankin commented Jun 28, 2024

Adds a feature flag to make DinD usable in a "backwards-compatible" way.

also fixes the ci/tests for it

@alexanderankin alexanderankin marked this pull request as draft June 28, 2024 09:21
@alexanderankin alexanderankin changed the title DinD: add feature flag to re-enable DinD fix(DinD): add feature flag to re-enable DinD Jun 30, 2024
alexanderankin referenced this pull request Sep 10, 2024
#388)

## What does this PR do?

Adds support for reading the `tc.host` property from the
`~/.testcontainers.properties` file. This config will have the highest
priority for configuring the Docker client.

## Why is it important

This brings [Testcontainers
Desktop](https://testcontainers.com/desktop/) support to
testcontainers-python and aligns this language with the
`TestcontainersHostStrategy` found it testcontainers-java.

## Misc

I wasn't able to get a working testcontainers-python development
environment set up on my M2 MacBook. This seems to be related to some
kind of Cython 3.0.0 issue, that I don't fully understand and trying to
fix it breaks the installation of further dependencies (like pymssql).
So I was only able to test it in an Ubuntu Codespaces environment (also
required some weird Cython workarounds).

##  Breaking Changes

- To prioritise `tc.host` this PR prioritised having that over true
`docker:dind` use cases
- This means we stopped trying to automatically infer the container host
IP when running inside a `docker:dind` container
- When using `-v /var/run/docker.sock:/var/run/docker.sock` you should
be unaffected since your containers run on the original host

---------

Co-authored-by: Bálint Bartha <[email protected]>
Co-authored-by: David Ankin <[email protected]>
alexanderankin pushed a commit that referenced this pull request Oct 23, 2024
closes #475 

One step closer to solve #517

Replaces #622 

According to the [data
collected](#475 (comment))
this should fix issues running testcontainers inside a container in
almost all cases.

There is still an issue when running it within docker desktop, that is
probably easily solved which checking for the existence of
`host.docker.internal`.

But I have to recollect the data to ensure this, so this will be added
at later point in time, as with with setting `-e
TESTCONTAINERS_HOST_OVERRIDE=host.docker.internal` an easy workaround
exists as well.
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 this pull request may close these issues.

1 participant