使用Bicep部署Azure Container Apps时SMB卷挂载失败，手动修复后恢复

现象与错误日志 #

使用Bicep部署Azure Container Apps资源后，部署流程无报错但容器无法正常启动。

应用日志流错误 #

Connecting to stream...
2025-07-24T04:55:01.48767  Connecting to the container 'hello-template'...
2025-07-24T04:55:01.53411  Kubernetes error happened. Closing the connection.

系统日志流存储挂载错误 #

Connecting to stream...
{"TimeStamp":"2025-07-24T04:55:49Z","Type":"Normal","ContainerAppName":null,"RevisionName":null,"ReplicaName":null,"Msg":"Connecting to the events collector...","Reason":"StartingGettingEvents","EventSource":"ContainerAppController","Count":1}
{"TimeStamp":"2025-07-24T04:55:50Z","Type":"Normal","ContainerAppName":null,"RevisionName":null,"ReplicaName":null,"Msg":"Successfully connected to events server","Reason":"ConnectedToEventsServer","EventSource":"ContainerAppController","Count":1}
{"TimeStamp":"2025-07-24 04:52:43 +0000 UTC","Type":"Warning","ContainerAppName":"internship-test","RevisionName":"internship-test--s2vnoix","ReplicaName":"internship-test--s2vnoix-66dd654575-5h772","Msg":"MountVolume.SetUp failed for volume \"internship-test-volume\" : rpc error: code = Internal desc = volume(csi-d341431304f74d865c98297c5c72c264d7f5b446662947e1f7be4105b5812254) mount //internshipteststacc.file.core.windows.net/internship-test-fileshare on /var/lib/kubelet/pods/fe37caf9-3817-42dd-a811-262d6a8455e2/volumes/kubernetes.io~csi/internship-test-volume/mount failed with mount failed: exit status 32\nMounting command: mount\nMounting arguments: -t cifs -o ,actimeo=30,mfsymlinks,nosharesock,file_mode=0777,dir_mode=0777,\u003Cmasked\u003E //internshipteststacc.file.core.windows.net/internship-test-fileshare /var/lib/kubelet/pods/fe37caf9-3817-42dd-a811-262d6a8455e2/volumes/kubernetes.io~csi/internship-test-volume/mount\nOutput: mount error(2): No such file or directory\nRefer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)\n\nPlease refer to http://aka.ms/filemounterror for possible causes and solutions for mount errors.","Reason":"FailedMount","EventSource":"ContainerAppController","Count":3}

手动调整后的错误与恢复 #

删除Bicep创建的卷并手动重建后，系统日志出现端口不匹配提示：

{"TimeStamp":"2025-07-24 05:02:25 +0000 UTC","Type":"Normal","ContainerAppName":"internship-test","RevisionName":"internship-test--0000001","ReplicaName":"internship-test--0000001-5d64cc5cdc-4nmr6","Msg":"The TargetPort 8080 does not match the listening port 80.","Reason":"Pending:PortMismatch","EventSource":"ContainerAppController","Count":4}

将Ingress目标端口改为80再改回8080后，容器恢复正常。临时解决步骤：

• 使用相同SMB文件共享手动重建Container App中的卷
• 将Ingress目标端口改为80后改回8080（必须按此顺序）

问题根源分析 #

1. 文件共享名称不匹配：
   storage模块中创建的文件共享名称为${appName}-share，但container模块的Azure Files存储配置中指定的shareName是${appName}-fileshare，两者不一致导致挂载时找不到目标共享，触发No such file or directory错误。

2. 部署时序与缓存问题：
   手动调整端口的操作触发了Container App的重新部署，刷新了之前因挂载失败产生的资源缓存，让正确配置的卷生效。

优化解决方案 #

修正Bicep配置中的文件共享名称不一致问题，添加资源依赖确保部署时序正确，无需手动操作即可完成正常部署。

修正后的storage模块 #

param appName string
param location string

resource storageAccount 'Microsoft.Storage/storageAccounts@2021-02-01' = {
  name: '${replace(appName, '-', '')}stacc'
  location: location
  kind: 'Storage'
  sku: {
    name: 'Standard_LRS'
  }
}

resource fileService 'Microsoft.Storage/storageAccounts/fileServices@2021-09-01' = {
  parent: storageAccount
  name: 'default'
}

// 统一共享名称为${appName}-fileshare，与容器模块配置对齐
resource fileShare 'Microsoft.Storage/storageAccounts/fileServices/shares@2021-09-01' = {
  parent: fileService
  name: '${appName}-fileshare'
  properties: {
    shareQuota: 100
  }
}

output storageAccountName string = storageAccount.name
output storageAccountKey string = storageAccount.listKeys().keys[0].value

修正后的container模块 #

param appName string
param location string
param loganalysisId string
param loganalysiskey string
param storageAccountName string
param storageAccountKey string

resource containerRegistry 'Microsoft.ContainerRegistry/registries@2021-06-01-preview' = {
  name: '${replace(appName, '-', '')}cr'
  location: location
  sku: {
    name: 'Basic'
  }
  properties: {
    adminUserEnabled: true
  }
}

resource containerAppEnvironment 'Microsoft.App/managedEnvironments@2023-05-01' = {
  name: '${appName}-cae'
  location: 'australiaeast'
  properties: {
    appLogsConfiguration: {
      destination: 'log-analytics'
      logAnalyticsConfiguration: {
        customerId: loganalysisId
        sharedKey: loganalysiskey
      }
    }
  }
}

resource azureFilesStorage 'Microsoft.App/managedEnvironments/storages@2023-05-01' = {
  parent: containerAppEnvironment
  name: '${appName}-smb'
  properties: {
    azureFile: {
      accountName: storageAccountName
      accountKey: storageAccountKey
      shareName: '${appName}-fileshare' // 与storage模块的共享名称保持一致
      accessMode: 'ReadWrite'
    }
  }
}

resource containerApp 'Microsoft.App/containerApps@2023-05-01' = {
  name: appName
  location: 'australiaeast'
  dependsOn: [
    azureFilesStorage
    // 新增文件共享资源依赖，确保共享创建完成后再部署容器应用
    resourceId('Microsoft.Storage/storageAccounts/fileServices/shares', storageAccountName, 'default', '${appName}-fileshare')
  ]
  properties: {
    managedEnvironmentId: containerAppEnvironment.id
    configuration: {
      ingress: {
        external: true
        targetPort: 8080
      }
      registries: [
        {
          server: containerRegistry.properties.loginServer
          username: containerRegistry.listCredentials().username
          passwordSecretRef: 'acr-password'
        }
      ]
      secrets: [
        {
          name: 'acr-password'
          value: containerRegistry.listCredentials().passwords[0].value
        }
      ]
    }
    template: {
      containers: [
        {
          name: 'hello-template'
          image: 'mcr.microsoft.com/azuredocs/containerapps-helloworld:latest'
          resources: {
            cpu: '0.5'
            memory: '1Gi'
          }
          volumeMounts: [
            {
              volumeName: '${appName}-volume'
              mountPath: '/app/data'
            }
          ]
        }
      ]
      volumes: [
        {
          name: '${appName}-volume'
          storageType: 'AzureFile'
          storageName: azureFilesStorage.name
        }
      ]
      scale: {
        minReplicas: 0
        maxReplicas: 10
      }
    }
  }
}

额外优化说明 #

• 在container模块的dependsOn中新增文件共享资源依赖，确保文件共享完全创建后再部署Container App，避免因资源未就绪导致的挂载失败。
• 统一文件共享名称后，部署完成后容器即可正常启动，无需手动重建卷或调整端口。

内容的提问来源于stack exchange，提问作者Sorawit Tonpitak