none
Recent Windows Containers (1809 flavors) fail to resolve Azure Resource URLs RRS feed

  • Question

  • A fairly basic Java application that accesses Azure Key Vault and Table storage runs fine locally, either in NetBeans, as a stand-alone Java App (jar), or in a Docker container running locally (Docker run ….) on a Windows 10 Pro machine.

    When I attempted to run it in a Powershell/nanoserver container on Azure (specifically mcr.microsoft.com/powershell:6.2.1-nanoserver-1809_kb4480116_amd64) it crashed with "unknown host exception). The same issue occurred with powershell servercore 1809, and servercore ltsc2019 (and a couple of other images - all 64-bit windows).

    Investigation by jakaruna-MSFT on another forum determined that the solution was to use a significantly outdated base image (mcr.microsoft.com/windows/servercore:1607-KB4505052-amd64).

    It is disturbing, to say the least, that what seems to me to be a fundamental generic use case for containers (i.e., accessing other Azure resources from within a container) was (and is) broken in  image "updates" which followed the 1607 image. I wasted the better part of 3 calendar weeks trying to identify why the deployed container would not work, and had it not been for jakaruna-MSFT I would still be dead in the water.

    It appears to be some internal DNS issue, but in any case, MS please fix this. My container image is now almost 7GB, when it could be 1 if the nanoserver image worked as it should.

    Jack


    Sunday, May 26, 2019 7:44 PM

All replies

  • What exactly is crashing? Can you reproduce issue with no third party binaries to showcase the issue?
    Sunday, May 26, 2019 10:17 PM
  • As I stated, the (original) underlying exception was UnknownHostException, which in turn cause a StorageException at the first attempt to retrieve a row from a standard Azure table, using standard Azure storage libraries for Java (I tried 5.5, 8.0, and 8.3, though in retrospect the problem had nothing to do with Storage Libraaries).

    When I subsequently added Azure Key Vault access, the same underlying exception occurred, but of course earlier since the Key Vault contains credentials needed to access the table.

    Having spent way too much time already trying to get access to work (the beauty of containers is they run anywhere, right??), I am not inclined to write more throwaway code; however, I am confident that a HelloWorld app in any language that also attempted to retrieve information from a Key Vault would crash as soon as access to the Key Vault was attempted. In my Java code, credentials are provided through spring-boot dependency injection via named properties in the Key Vault, so the exception happens very early. Or, probably easier, just hard code credentials for accessing a table, then try to read a row from the table into a DynamicTableEntity.

    jakaruna-MSFT reproduced the issue by simply attempting to use nslookup from the command line in a running (Azure Container Instance) container (using the baseline 1809 nanoserver image I was originally using). When that failed, he then, through means unknown to me, determined that the borderline obsolete 1607 image would work as expected. And it does. But, in addition to being obsolete, it is 7.5GB versus ~1 GB for the nanoserver image, which in principle will do everything I need.

    Jack


    Monday, May 27, 2019 12:33 AM
  • Not sure what the point of posting here and not providing reproduction steps. Create dockerfile and show what the issue is with simple reproduction steps based only on Microsoft libraries. I just used nslookup with no problems with ltsc2019 image, so issue is not with nslookup functionality obviously and in general we can not possibly have issue with name resolution on ALL Microsoft images since 1607). So issue is either environmental or issue with third party libraries. Unless you provide clear reproduction steps based ONLY on Microsoft libraries not sure how this can be troubleshooted/verified here.

    `docker run -it --rm mcr.microsoft.com/windows/servercore:ltsc2019 nslookup contoso-vault2.vault.azure.net 8.8.8.8`

    Monday, May 27, 2019 1:00 AM
  • I appreciate your efforts, but in your "test" you provided the dns server IP. That works, and jakaruna-MSFT also demonstrated that nslookup works if you specify manually a DNS server IP to nslookup, even when you run nslookup from a shell inside a running ACI in Azure. But SETTING the server IP address inside a container, for the container, is not obvious (and with my admittedly limited research) and maybe not currently possible. For example, the Powershell cmdlets for dealing with DNS are not in the latest Powershell / nanosever or Powershell servercore images.

    Perhaps more to the point, as I noted, when running the container locally using Docker run (as in your example), everything works fine (and it is not necessary to add the dns server IP address). But my container does NOT work when running it as an Azure Container Instance in an Azure Container Group on Azure, unless I create it using the 1607 image.

    Jack

    Monday, May 27, 2019 1:29 AM
  • I can confirm ACI being broken. Is internal Microsoft case created? I created GitHub issue on troubleshooting section but not sure what has been already done on Microsoft side.

    https://github.com/MicrosoftDocs/azure-docs/issues/32209

    Monday, May 27, 2019 1:23 PM
  • @artisticcheese And then there were two. I raised the issue on the Azure container services issues page - where jakaruna-MSFT first responded. He has also responded to the issue you raised. With luck maybe now someone will take a serious look.
    Monday, May 27, 2019 2:37 PM