2

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.

Mik4sa
  • 33
  • 1
  • 6
  • 1
    I recently opened an github issue on the Azure Docs for pretty much your scenario. still waiting for feedback though https://github.com/MicrosoftDocs/azure-docs/issues/61627 – silent Sep 07 '20 at 15:40

2 Answers2

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.

Charles Xu
  • 29,862
  • 2
  • 22
  • 39
  • I guessed so. I can't put all instances into a container group. Sooner or later I'll reach the limits enforced by azure. I will have a look at AKS though. Thx – Mik4sa Sep 08 '20 at 08:48
  • @Mik4sa OK, I will wait for your news. Feel free if you need more help. And if it solves your issue please accept it. – Charles Xu Sep 10 '20 at 02:59
  • @chareles-xu Sadly I don't get time for this by now. We are trying the approach I already mentioned above (updating the dns on container start with a separate image). – Mik4sa Sep 11 '20 at 07:53
  • @Mik4sa Update the DNS name and image is not a good approach. Multiple update actions are too complex. – Charles Xu Sep 11 '20 at 07:59
  • @chareles-xu Not really. I currently don't have much time for this. I'll look at this in the next days again. But I'll stay with the approach mentioned above. I know that this isn't a really good solution, but I can't decide that on my own and time is running ;) – Mik4sa Sep 15 '20 at 07:46
  • This has me scratching my head. How can anyone use this in production? Every service in Azure has something that makes it painful to use. If you want a Microservice arch, your gonna have to use Kubernetes... – Garry Taylor May 03 '22 at 11:34
0

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/

Garry Taylor
  • 940
  • 8
  • 19