How to set the dns option in Azure web app for containers

Question

This is what happens to run the container. I wonder if there is a way to start the web app for containers with a custom DNS.

I have 5 microservices in my ILB-ASE they need to be able to call each other using my custom DNS server in the VNet. When I check the resolv.conf i see 127.0.0.11. I need that to be set to my own custom dns server.

how can we inject my custom DNS value here?

Should we use the appsettings if so what are the values in the web app for containers?

So I can use the --dns option

The mystery part that Azure runs it. Some values are coming up from the appsettings.

2018-08-23 14:12:56.100 INFO - docker run -d -p 13940:5001 --name xxx -e DOCKER_CUSTOM_IMAGE_NAME=xxx.azurecr.io/xxx:558 -e WEBSITES_ENABLE_APP_SERVICE_STORAGE=false -e WEBSITES_PORT=5001 -e WEBSITE_SITE_NAME=xxx -e WEBSITE_AUTH_ENABLED=False -e WEBSITE_ROLE_INSTANCE_ID=0 -e WEBSITE_INSTANCE_ID=xxx -e HTTP_LOGGING_ENABLED=1 xxx.azurecr.io/xxx:558

=====DOCKER LOG=========

2018_08_23_RD0003FF2D0408_default_docker.log:

​

2018-08-23T14:12:49.755843301Z [40m[1m[33mwarn[39m[22m[49m: Microsoft.AspNetCore.DataProtection.KeyManagement.XmlKeyManager[35]

2018-08-23T14:12:49.755897801Z No XML encryptor configured. Key {xxx-xxx-xxx-xxx-xxx} may be persisted to storage in unencrypted form.

2018-08-23T14:12:54.761216323Z [40m[1m[33mwarn[39m[22m[49m: Microsoft.AspNetCore.Server.Kestrel[0]

2018-08-23T14:12:54.761251623Z Overriding address(es) 'http://+:80'. Binding to endpoints defined in UseKestrel() instead.

2018-08-23T14:12:54.908189021Z Hosting environment: Production

2018-08-23T14:12:54.908386123Z Content root path: /app

2018-08-23T14:12:54.908961927Z Now listening on: http://0.0.0.0:5001

2018-08-23T14:12:54.909256229Z Application started. Press Ctrl+C to shut down.

​

2018_08_23_RD0003FF2D0408_docker.log:

2018-08-23 14:12:44.125 INFO - Recycling container because of AppFrameworkVersionChange and appFrameworkVersion = xxx.xxx.io/xxx:558

2018-08-23 14:12:45.900 INFO - Starting container for site

2018-08-23 14:12:45.900 INFO - docker run -d -p 30464:5001 --name xxx -e DOCKER_CUSTOM_IMAGE_NAME=xxx.azurecr.io/xxx:549 -e WEBSITES_ENABLE_APP_SERVICE_STORAGE=false -e WEBSITES_PORT=5001 -e WEBSITE_SITE_NAME=xxx -e WEBSITE_AUTH_ENABLED=False -e WEBSITE_ROLE_INSTANCE_ID=0 -e WEBSITE_INSTANCE_ID=xxx -e HTTP_LOGGING_ENABLED=1 xxx.xxx.io/xxx:558

​

2018-08-23 14:12:55.972 INFO - Container xxx for site xxx initialized successfully.

2018-08-23 14:12:55.976 INFO - Recycling container because of AppSettingsChange and isMainSite = True

2018-08-23 14:12:56.099 INFO - Starting container for site

2018-08-23 14:12:56.100 INFO - docker run -d -p 13940:5001 --name xxx -e DOCKER_CUSTOM_IMAGE_NAME=xxx.azurecr.io/xxx:558 -e WEBSITES_ENABLE_APP_SERVICE_STORAGE=false -e WEBSITES_PORT=5001 -e WEBSITE_SITE_NAME=xxx -e WEBSITE_AUTH_ENABLED=False -e WEBSITE_ROLE_INSTANCE_ID=0 -e WEBSITE_INSTANCE_ID=xxx -e HTTP_LOGGING_ENABLED=1 xxx.azurecr.io/xxx:558

2018-08-23 14:13:05.385 INFO - Container xxx for site xxx initialized successfully.

​

Answer 1

we responded to your question on Github and Reddit. Re-posting our response here for visibility.

"Currently, there is a workaround for this: you should modify the default resolv.conf to the custom DNS IP and then add your custom resolv.conf on docker build by adding a COPY command in your entrypoint script and pointing a custom resolv.conf to /etc.

However, we are investigating a better solution for this, so that manually updating the resolv.conf wouldn’t be necessary, so stay tuned."

Answer 2

You shouldn't use DNS to communicate with microservices, instead, you should make use of service registry.

Check this Microsoft paper talking about this:

Each microservice has a unique name (URL) that is used to resolve its location. Your microservice needs to be addressable wherever it is running. If you have to think about which computer is running a particular microservice, things can go bad quickly. In the same way that DNS resolves a URL to a particular computer, your microservice needs to have a unique name so that its current location is discoverable. Microservices need addressable names that make them independent from the infrastructure that they are running on. This implies that there is an interaction between how your service is deployed and how it is discovered, because there needs to be a service registry. In the same vein, when a computer fails, the registry service must be able to indicate where the service is now running.

As you can see, the best solution will depend on your deployment model. Check this note about containers:

In some microservice deployment environments (called clusters, to be covered in a later section), service discovery is built-in. For example, within an Azure Container Service environment, Kubernetes and DC/OS with Marathon can handle service instance registration and deregistration. They also run a proxy on each cluster host that plays the role of server-side discovery router. Another example is Azure Service Fabric, which also provides a service registry through its out-of-the-box Naming Service.

Hope it helps!