2

I've got a Windows container that's running in Azure that I'm trying to attach persistent storage to, however, I'm not able to find any documentation on how to do so.

Dockerfile:

FROM mcr.microsoft.com/dotnet/framework/aspnet:4.8-20190910-windowsservercore-ltsc2016
SHELL ["powershell"]
EXPOSE 443
WORKDIR /CompanyAPP
COPY WebPackage.zip .
RUN Expand-Archive WebPackage.zip . ; `
    Rename-Item ./CustomerWebConfigurator ./WebConfigurator; `
    Rename-Item ./Customer ./WebRoot; `
    Rename-Item ./CustomerWebService ./WebService; `
    Rename-Item ./CustomerWCFService ./WCFService; `
    rm WebPackage.zip
ARG BUILD
RUN Add-WindowsFeature Net-WCF-HTTP-Activation45;`
    Install-PackageProvider -Name Nuget -Force;`
    Set-PSRepository -Name PSGallery -InstallationPolicy Trusted;`
    Install-Module -Name AWSPowerShell;`
    New-WebApplication -Site 'Default Web Site' -Name 'App' -PhysicalPath c:\CompanyAPP\WebRoot; `
    New-WebApplication -Site 'Default Web Site' -Name 'AppWebService' -PhysicalPath c:\CompanyAPP\WebService; `
    New-WebApplication -Site 'Default Web Site' -Name 'AppWCFService' -PhysicalPath c:\CompanyAPP\WCFService; `
    New-WebApplication -Site 'Default Web Site' -Name 'AppWebConfigurator' -PhysicalPath c:\CompanyAPP\WebConfigurator; `
    Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters' -Name ServerPriorityTimeLimit -Value 0 -Type DWord;`
    $cert = New-SelfSignedCertificate -Subject self; `
    New-WebBinding -Protocol https -port 443 -name 'Default Web Site' -SSLFlags 0; `
    $binding = Get-WebBinding -protocol https; `
    $binding.AddSslCertificate($cert.Thumbprint, 'my');
RUN Set-WebConfiguration -PSPath 'IIS:\Sites\Default Web Site\App' -Filter '/system.web/customErrors' -Value @{mode='Off'};`
    write-host 'got here!'

The storage is configured in an Azure Storage account, and using file storage, I'm attaching it in the configuration via path mappings, and am having no luck.

Hoping that someone can point me in a good direction to get this figured out.

devopsidiot
  • 25
  • 1
  • 4

2 Answers2

5

I may be quite late to the party, but I stumbled upon this issue only today (mounting Azure File Volumes in a Windows Container still is not supported even a year later), and I found quite an easy workaround. I will share this here, because this question is one of the top results when searching for the error message.

You can mount your Azure File Volume via SMB. All you need is the UNC, a username and a password, which you can get from the properties of your Azure File Volume

So I created a small startup.cmd

@echo off
net use z: %MNTUNC% %MNTPASS% /user:%MNTUSER%
"c:\program files\myapp\myapp.exe"

and defined that startup.cmd as the entrypoint in the dockerfile

....

COPY ["startup.cmd", "c:/startup.cmd"]
ENTRYPOINT ["c:/startup.cmd"]

Pitfall: Be aware, that a drive mapped with net use (or New-PSDrive if you prefer PowerShell) is only visible to the user account under which the command was executed, so be sure to mount the drive with the same user, which is used to execute the service.

You can set the values for the environment variables during deployment like described here:

https://learn.microsoft.com/en-us/azure/container-instances/container-instances-environment-variables

For instance, when using a YAML file for deployment, you can set the environment variables as follows. Using secureValue makes the value of the environment variable accessible only from within the container and the values won't be shown for instance in the properties of the container on the azure portal.

....
containers:
  - name: mycontainer
    properties:
      environmentVariables:
        - name: 'MNTUNC'
          secureValue: '\\myaccountname.file.core.windows.net\myvolume'
        - name: 'MNTPASS'
          secureValue: 'mysupersecretpassword'
        - name: 'MNTUSER'
          secureValue: 'Azure\myaccountname'
derpirscher
  • 14,418
  • 3
  • 18
  • 35
  • Tried this approach using **Azure Container Instances** on WinOS Server Core LTS 2019 - no luck => `401 Unauthorized` when trying to access Azure File Share Premium from within the container - may be something to do with how we are using it... we are [using self-hosted build agent in Docker](https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/docker?view=azure-devops), also tried using `New-PSDrive` and `New-SmbGlobalMapping` - no dice! – SliverNinja - MSFT Sep 21 '20 at 23:05
  • @SliverNinja-MSFT Are you able to mount your fileshare from (for instance) a local system using the same UNC + credentials? `Unauthorized` sounds more like some issue with the credentials. Could you try to echo the environment variables on startup and check the log of the container if they are correct? – derpirscher Sep 22 '20 at 13:15
  • great callout, `Unauthorized` was a bug - credentials were invalid - obvious using diagnostic output you suggested! I tested a direct read/write to the Azure Files SMB and it worked perfectly! The next hurdle seems to be limited access to the share using a [child process run from `powershell.exe` launching `Agent.Listener.exe`](https://github.com/microsoft/azure-pipelines-agent/blob/master/src/Misc/layoutroot/run.cmd#L26) which azure pipelines uses to fire up the build agent (via `run.cmd`). Any ideas how to make this share is visible to another worker process inside the container? – SliverNinja - MSFT Sep 23 '20 at 22:34
  • Sorry, don't really know anything about that particular use case. But as said above, mapped network drives are only visible to the user account which mapped them. Maybe that thing runs under a windows service account? Then this answer may help you https://serverfault.com/questions/4623/windows-can-i-map-a-network-drive-for-a-service-account – derpirscher Sep 24 '20 at 07:05
  • 1
    @SliverNinja-MSFT This might also help https://www.powershellmagazine.com/2015/04/08/user-account-control-and-admin-approval-mode-the-impact-on-powershell/ – derpirscher Sep 24 '20 at 07:18
1

If you use the Azure Container Instance to deploy for Windows container, then the Azure File storage does not support the persistent volume., it's currently restricted to Linux containers. You can get more details about the note here:

Mounting an Azure Files share is currently restricted to Linux containers.

Update:

With the message that the provided in the comment, you use the web app for the container with the Windows image. In this situation, it supports to mount the Azure File Share to the Windows Container. You can follow the steps in Configure Azure Files in a Windows Container on App Service.

Charles Xu
  • 29,862
  • 2
  • 22
  • 39
  • Hi Charles. I'm actually using Web Apps for containers to host said container to try to figure out a way around this issue - hoping that it's possible. – devopsidiot Sep 26 '19 at 12:08
  • @devopsidiot Wow, you need to add this message in the question at the beginning. I will update the answer. – Charles Xu Sep 27 '19 at 01:14
  • @devopsidiot Any more questions? Does it solve your problem? If it works for you please accept it as the answer. – Charles Xu Sep 30 '19 at 01:40