You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am struggling a bit trying to understand how best to access containers that kubedock has created.
I have created a simple integration test that depends on a mysql container. If I use kubedock in --reverse-proxy mode, I can see that when my test asks testcontainers for the mysql container db url, it is given the fully qualified kubedock hostname with the random port that has been assigned to the mysql instance:
Waiting for database connection to become available at jdbc:mysql://kubedock.xxx.svc.cluster.local:57636/yyy using query 'SELECT 1'
Unfortunately, because I have not exposed this port explicitly in the kubedock service config, it times out while trying to obtain a connection.
If I remove the --reverse-proxy flag and instead try to use --inspector, I can see that a k8s service has been created for my mysql container with the random port exposed, however when my test asks testcontainers for the mysql db url, it is still given the kubedock hostname rather than that of the mysql service.
So I guess my question is, what is the expected use case for the --inspector flag? Is there some way I can get testcontainers to provide me with the container's service name rather than the kubedock service name?
The text was updated successfully, but these errors were encountered:
So I guess my question is, what is the expected use case for the --inspector flag? Is there some way I can get testcontainers to provide me with the container's service name rather than the kubedock service name?
In some cases there is no port exposed when starting the container. In that case kubedock doesn't expose ports either. The --inspector flag will query the registry for that specific image to see if there were any default ports exposed via the image itself. If so, it will reverse-proxy/port-forward these ports as well. This will increase compatibility, but note that the occasions where this is required are rare (and can be worked around by exposing them in the test itself).
I am struggling a bit trying to understand how best to access containers that kubedock has created.
I have created a simple integration test that depends on a mysql container. If I use kubedock in
--reverse-proxy
mode, I can see that when my test asks testcontainers for the mysql container db url, it is given the fully qualified kubedock hostname with the random port that has been assigned to the mysql instance:Unfortunately, because I have not exposed this port explicitly in the kubedock service config, it times out while trying to obtain a connection.
If I remove the
--reverse-proxy
flag and instead try to use--inspector
, I can see that a k8s service has been created for my mysql container with the random port exposed, however when my test asks testcontainers for the mysql db url, it is still given the kubedock hostname rather than that of the mysql service.So I guess my question is, what is the expected use case for the
--inspector
flag? Is there some way I can get testcontainers to provide me with the container's service name rather than the kubedock service name?The text was updated successfully, but these errors were encountered: