How to "connect" docker containers while using the "Launch Docker Image"-functionality?

[SnoppyFloppy]

Hi

I come from docker/docker-compose and I'm new to Kubernetes.

I want to deploy two containers using the "Launch Docker Image"-functionality. One container being an maria-db and the other being an app that relies on the db during deployment.

The app-image has an env. variable "DB_HOST" where, in docker, I would just specity the name of the db-container and if I put the the containers on the same custom bridge network, the app could reach the db using dockers internal DNS.

During the TrueNAS deployment I don't see an option to put the containers on the same internal network, and though I specified the env. var. DB_HOST=<DB app. name> the app is unable to contact the db and thus fails to deploy.

I found this within the truecharts documentation. but using <DB app. name>.ix-<DB app. name>.svc.cluster.local or <DB app. name>.ix-<DB app. name> doesn't resolve my problem.

Any advises?

 

[jsclayton]

I've had the same issues, even on 21.06 beta. I'm pretty sure that it's a configuration issue or two within k3s, but haven't been able to track it down.

The first issue seems to be that the host's DNS is being set in the containers launched via the "Launch Docker Image" button. If I shell in to a container and cat /etc/resolv.conf it shows the host's DNS server and no search domains. I also see DNS lookups to the svc domains in my pihole logs (which is the host DNS server).

However if I run the command from this post and check the DNS settings it looks like this, which is what I'd expect it to look like:

Code:

nameserver 172.17.0.10
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

From within that busybox instance I can resolve and ping <name>-ix-chart.ix-<name>, which does not work in the other containers.

The second issue seems to be with the charts that TrueNAS generates behind the scenes if you don't forward any ports. In this case, it does not generate a k8s Service, which is needed to internally communicate with it. If I remove the forwarded port I can no longer resolve <name>-ix-chart.ix-<name> from the busybox session. I'm not sure what the fix for this is, I'd consider the unnecessary forwarded port to be a workaround at best.

 

[morganL]

I've had the same issues, even on 21.06 beta. I'm pretty sure that it's a configuration issue or two within k3s, but haven't been able to track it down.

The first issue seems to be that the host's DNS is being set in the containers launched via the "Launch Docker Image" button. If I shell in to a container and cat /etc/resolv.conf it shows the host's DNS server and no search domains. I also see DNS lookups to the svc domains in my pihole logs (which is the host DNS server).

It would seem that this worth reporting as a bug... with some good guidance on how to reproduce.
Please send the bugID link when you have done so.

 

[SnoppyFloppy]

I've had the same issues, even on 21.06 beta. I'm pretty sure that it's a configuration issue or two within k3s, but haven't been able to track it down.

The first issue seems to be that the host's DNS is being set in the containers launched via the "Launch Docker Image" button. If I shell in to a container and cat /etc/resolv.conf it shows the host's DNS server and no search domains. I also see DNS lookups to the svc domains in my pihole logs (which is the host DNS server).

Thanks for your reply. This seems to be beyond my skill-level to resolve so I guess I just have to wait until gets solved.

I'm not sure what the fix for this is, I'd consider the unnecessary forwarded port to be a workaround at best.

I Agree. Ideally I would like to only expose for 80 and 443 for the traefik pod and nothing else.

 

[ksimm1]

It would seem that this worth reporting as a bug... with some good guidance on how to reproduce.
Please send the bugID link when you have done so.

@morganL since I'm also experience same thing, here's a ticket for this issue with some basic steps to reproduce and links to the two forum threads that discuss it:

https://jira.ixsystems.com/browse/NAS-111403

@SnoppyFloppy & @jsclayton please add any details in the comments for that ticket that I might've missed

 

[ksimm1]

Looks like this was fixed by @waqarahmed recently and will be available in the 21.08 release:

Allow specifying clusterfirst dns policy for ix-chart by sonicaj · Pull Request #80 · truenas/charts

This commit adds changes to allow specifying cluster first dns policy for ix-chart as it can be useful for cases where the workload running with ix-chart needs to consume internal kubernetes dns fo...

github.com

https://jira.ixsystems.com/browse/NAS-111103

Sidenote: now that SCALE is labeled BETA there really should be a way to apply bug fixes to the current release without forcing users to move to the unstable nightlies.

 

[morganL]

Sidenote: now that SCALE is labeled BETA there really should be a way to apply bug fixes to the current release without forcing users to move to the unstable nightlies.

It depends a lot on the specific fixes...
Many developers can do this using the open source, but it's difficult for users. It is extremely difficult for community to support users that have applied patches and so is not generally encouraged. Instead, the focus is on getting to quality and regular and frequent releases.

 

[ksimm1]

It depends a lot on the specific fixes...
Many developers can do this using the open source, but it's difficult for users. It is extremely difficult for community to support users that have applied patches and so is not generally encouraged. Instead, the focus is on getting to quality and regular and frequent releases.

No disagreement there. What I mean is that once you're labeling your product as beta you should push regular updates on that beta train to address critical fixes that users report, separate from the nightly unstable train.

 

[Flachzange]

This is quite an old thread but I came across the same issue here. How does the FQDN looks like for another docker container? How can I communicate between docker containers without exposing a port on the node itself?

I am also not sure if the mentioned Jira Ticket is actually fixed.

If I do a

cat /etc/resolv.conf

it still misses the cluster's dns server.

Where can I set the DNS Policy?

Thank you :)

 

[morganL]

This is quite an old thread but I came across the same issue here. How does the FQDN looks like for another docker container? How can I communicate between docker containers without exposing a port on the node itself?

I am also not sure if the mentioned Jira Ticket is actually fixed.

If I do a



it still misses the cluster's dns server.

Where can I set the DNS Policy?

Thank you :)

Suggest you start a new thread and detail what you are doing.... what works and what doesn't?

 

[Flachzange]

Thanks for your reply. However, I don't see why creating a new thread is actually benefical as my question is whether the problem stated in this thread is actually solved? And, if yes, how does the solution look like? That's usually something which the people originally involved can answer best.

Asking the same question twice in a new thread is somehow not helpful either imho. Hope that is undestandable.

 

[Flachzange]

Ok, the answer to the question is: Yes, it is solved and it order to use the internal DNS, this must be specified per docker app in the configuration as Option 2 below DNS policy:

Then, the correct host name needs to be figured out according to https://truecharts.org/docs/manual/SCALE Apps/Quick-Start Guides/linking-apps/

My challenge was to understand what $APP refers to. In my case it turned out to be "ix-chart".

Questions answered. Thanks!