testcontainers / testcontainers/testcontainers-python
Can't connect to PostgreSQL container from another container when running on Mac as host
Personne n'a encore pris cette issue.
- Langage dominant
- Python
- Étoiles
- 2.3k
- Forks
- 386
- Merge moyen
- 4 h 40 min
- PR mergées (30 j)
- 1
Description
In our current setup we have some Python code running on a docker container which uses testcontainers to create a PostgreSQL database container we can test with. All necessary requirements to start a new container from a docker image are met, and the host machine's docker client is used to start the new container. When looking at the DB container, it starts up successfully, we can access it from localhost with the port assigned to it when exposing and with the container's IP with the port we wanted to expose (5432). The problem comes if we try to access it with the Gateway IP of the network the 2 containers are in, and the port assigned to it when exposing (which is what testcontainers is doing as per my understanding).
This last part only fails when the host the 2 containers are started on is a MacOS machine, it works fine on Linux. To replicate the issue the following script can be run on a docker container that is started on a MacOS machine (with the host's docker client mounted up as per the requirements in this repo's README):
from testcontainers.postgres import PostgresContainer
import sqlalchemy
with PostgresContainer("postgres:9.6") as postgres:
e = sqlalchemy.create_engine(postgres.get_connection_url())
print(e.execute("select version()"))
We ran with Python 3.6 and newest versions of testcontainers, sqlalchemy and psycopg2. The above script should fail in a container started on Mac and work in a container started on Linux.
This is because the networking implementation is different between Linux and Mac. When exposing ports on Mac without providing a binding port (so docker finds a port for itself), the HostConfig/PortBindings for the newly started container gets set to "0". In contrast, it is left as an empty String on Linux. The "0" value causes the issue. We've opened a ticket about this on the docker for mac repo which has more info about this particular issue: https://github.com/docker/for-mac/issues/5588
Currently the work around we use in our code is to explicitly bind ports instead of just exposing them like so:
from testcontainers.postgres import PostgresContainer
import sqlalchemy
with PostgresContainer("postgres:9.6").with_bind_ports(5432, 47000) as postgres:
e = sqlalchemy.create_engine(postgres.get_connection_url())
print(e.execute("select version()"))
This version works on both Mac and Linux as the host because HostConfig/PortBindings gets updated with the port we've provided on containers started on both Mac and Linux. The downside is we always have to manually bind and find a port that is available.
The suggestion in the issue that I linked above is that for portability, the internal DNS and IP of containers should be used for communicating between containers rather than the Gateway IP. Would it make sense to make the change in testcontainers so it would use those to access the DB container rather than the Gateway IP? What was the specific reason for which Gateway IP was chosen as the preferred method of communication between containers?
I am happy to have a go at making the change in this repo if you accept contributions.
Guide de contribution
Ouvrir le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Piste de recherche
Commencez par les points d’entrée de PostgresContainer get_connection_url et with_bind_ports, puis exécutez la reproduction SQLAlchemy fournie dans des conteneurs sur Mac et Linux. Suivez la manière dont l’adresse du conteneur de base de données et le port exposé sont sélectionnés ; le travail est terminé lorsque la requête se connecte sans choisir manuellement un port hôte et se comporte de manière cohérente sur les deux hôtes.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- docker, postgresql, python, sqlalchemy
- Domaine
- databases, devops, networking
- Type d'issue
- Bug
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Activité
- À l'abandon
- Clarté
- Plutôt claire
- Accessibilité débutants
- 42/100