'Networking between container groups in a virtual network without ip addresses
Imagine the following scenario: I have a virtual network. In it are multiple container groups/instances which needs to communicate among themselves. Each group is in a separate subnet. There is also a application gateway which needs to know the container groups as it routes some traffic to them. Currently the communication works over ip addresses. During deployment I tell the gateway and some container groups which ip addresses they needs to know.
My problem is now that whenever a container groups restarts (whether intentionally or unintentionally) it may gets a new ip address. But everything is still using the old ip address (since how should they know that it changed).
I found no way to specify a static private ip address or hostname or some kind of fqdn which I could safely use. Also a private dns won't work here, since I can't update it. So the name would still resolve to the old ip address.
Does anyone have an idea how network between container groups in a virtual network should be done and which is fine when some container groups restarts or get a new ip address?
The only possible solution I can currently think of is that whenever a image inside of that groups (re)starts it also updates the private dns in azure. But this is something I don't really see as a (good) solution. An image should not have a dependency to a specific host(er). Also I would need to deploy some sort of credentials which is also bad.
Solution 1:[1]
Currently, I don't think there is a solution for you. You know, the DNS is not supported when the container group created in a VNet, and you also cannot decide what IP address the group will use when you restart the group. That is how it is designed. Maybe it will be better in the future.
If the container instance is your only choice, I recommend you create all the container inside a container group so that containers can communicate with their ports, not the private IP address. If you do not mind using other services, the AKS may be a better choice for you.
Solution 2:[2]
I personally would not use this (so don't mark as an answer).
Gary Jackson has the following post about how he solve this. So far this is the best solution I can find.
https://www.garyjackson.dev/posts/azure-container-instance-dns-private-ip/
Another option would be to use Dapr with a Web Service proxy so calls to the Web Service would be handled by the ACI (sick in mouth). Dapr is cool, but my idea is not :)
https://docs.dapr.io/getting-started/quickstarts/serviceinvocation-quickstart/
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
| Solution | Source |
|---|---|
| Solution 1 | Charles Xu |
| Solution 2 | Garry Taylor |