用 Azure Files 承载现代 Linux 工作负载：共享文件不再只是挂载点

预计阅读时间：10 分钟

Linux 工作负载里，文件共享一直是一个朴素但关键的需求：多个节点读写同一批文件、应用迁移时保留 POSIX 风格路径、批处理和服务之间交换数据。Azure Files 的价值在于把这种熟悉的文件访问模型，和云上的性能能力、数据保护、安全控制以及 Azure 服务集成放到一起，减少团队自己维护文件服务器的负担。

为什么 Linux 应用仍然需要托管文件共享

不是所有状态都适合塞进对象存储或数据库。很多 Linux 应用依赖目录、文件名、挂载路径和传统文件 API：

内容管理系统需要多个实例访问同一个上传目录。
数据处理任务需要把中间文件交给后续任务。
旧系统迁移到云上时，代码里已经写死了 /mnt/share、/data 这类路径。
容器化之后，多个 Pod 仍然需要共享配置、模型文件、导出报表或用户生成内容。

Azure Files 适合这类场景的原因，是它保留了文件访问的直觉：应用看到的是一个文件系统路径，而不是一个 SDK。与此同时，平台侧提供性能、保护、安全和 Azure 服务集成能力。对工程团队来说，这意味着可以把更多精力放在应用行为和容量规划上，而不是文件服务器补丁、磁盘扩容和高可用切换。

现代 Linux 工作负载关心的不只是“能挂载”

把共享盘挂上去只是第一步。真正上线时，团队通常会问几个更硬的问题。

性能方面，要看 workload 是大量小文件、顺序读写，还是并发读写。Azure Files 提供内建性能能力，但应用仍然需要用真实访问模式压测，而不是只看峰值数字。比如模型加载、图片缩略图生成、日志归档、批量导入，它们的 IO 形态很不一样。

数据保护方面，文件共享通常保存了业务可恢复性所依赖的数据。使用托管服务的一个好处，是可以把备份、快照、保留策略这类能力纳入平台治理，而不是靠某台 VM 上的 cron 脚本。

安全方面，文件共享不应该只是“拿到连接串就能访问”。生产环境要关注网络边界、身份与访问控制、密钥轮换、最小权限和审计。Azure Files 与 Azure 安全体系集成，这使它更容易进入企业现有的合规和运维流程。

服务集成方面，文件共享可以成为 Linux VM、容器平台、批处理任务和其他 Azure 服务之间的稳定数据接口。它不是替代所有存储形态，而是在“需要文件语义”的位置发挥作用。

可以这样实践：在 Linux 上挂载 Azure Files

下面示例演示一个可改造的 Linux 挂载流程。你需要替换资源组、存储账号、文件共享名称和区域。命令依赖 Azure CLI，并假设你已经 az login。

#!/usr/bin/env bash
set -euo pipefail

RESOURCE_GROUP="rg-linux-files-demo"
LOCATION="eastus"
STORAGE_ACCOUNT="stlinuxfiles$RANDOM"
SHARE_NAME="appshare"
MOUNT_POINT="/mnt/azfiles"

az group create \
  --name "$RESOURCE_GROUP" \
  --location "$LOCATION"

az storage account create \
  --resource-group "$RESOURCE_GROUP" \
  --name "$STORAGE_ACCOUNT" \
  --location "$LOCATION" \
  --sku Standard_LRS

STORAGE_KEY=$(az storage account keys list \
  --resource-group "$RESOURCE_GROUP" \
  --account-name "$STORAGE_ACCOUNT" \
  --query '[0].value' \
  --output tsv)

az storage share create \
  --account-name "$STORAGE_ACCOUNT" \
  --account-key "$STORAGE_KEY" \
  --name "$SHARE_NAME"

sudo mkdir -p "$MOUNT_POINT"
sudo mount -t cifs "//$STORAGE_ACCOUNT.file.core.windows.net/$SHARE_NAME" "$MOUNT_POINT" \
  -o "vers=3.0,username=$STORAGE_ACCOUNT,password=$STORAGE_KEY,serverino,nosharesock,actimeo=30"

echo "hello from $(hostname)" | sudo tee "$MOUNT_POINT/hello.txt"
ls -l "$MOUNT_POINT"

运行前要改什么：

LOCATION 改成你的 Azure 区域。
STORAGE_ACCOUNT 必须全局唯一，只能使用小写字母和数字。
--sku Standard_LRS 是演示配置；生产环境应根据性能、冗余和成本需求选择合适 SKU。
如果要长期使用，不要只依赖手工 mount；应使用安全的凭据管理方式，并把挂载写入系统启动流程或自动化配置。

如果要让挂载在重启后保留，可以把凭据放进 root 只读文件，再写入 /etc/fstab。下面是可改造示例：

STORAGE_ACCOUNT="yourstorageaccount"
SHARE_NAME="appshare"
MOUNT_POINT="/mnt/azfiles"
STORAGE_KEY="replace-with-storage-key"

sudo mkdir -p /etc/smbcredentials "$MOUNT_POINT"
sudo bash -c "cat > /etc/smbcredentials/${STORAGE_ACCOUNT}.cred" <<EOF
username=${STORAGE_ACCOUNT}
password=${STORAGE_KEY}
EOF
sudo chmod 600 "/etc/smbcredentials/${STORAGE_ACCOUNT}.cred"

sudo bash -c "cat >> /etc/fstab" <<EOF
//${STORAGE_ACCOUNT}.file.core.windows.net/${SHARE_NAME} ${MOUNT_POINT} cifs nofail,vers=3.0,credentials=/etc/smbcredentials/${STORAGE_ACCOUNT}.cred,serverino,nosharesock,actimeo=30 0 0
EOF

sudo mount -a
df -h "$MOUNT_POINT"

生产中更推荐把这段逻辑交给 cloud-init、Ansible、Terraform 或镜像构建流水线，而不是让工程师 SSH 到机器上手动敲。

可以这样实践：给 Kubernetes 工作负载挂共享目录

如果你的 Linux 工作负载运行在 Kubernetes 上，可以把 Azure Files 作为持久卷使用。下面是一个最小化示例，用于说明 Pod 如何把共享文件系统挂到容器内。具体 StorageClass 名称需要按集群实际配置调整。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-files-pvc
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: azurefile-csi
  resources:
    requests:
      storage: 100Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: file-writer
spec:
  replicas: 2
  selector:
    matchLabels:
      app: file-writer
  template:
    metadata:
      labels:
        app: file-writer
    spec:
      containers:
        - name: app
          image: busybox:1.36
          command:
            - sh
            - -c
            - |
              while true; do
                date >> /data/heartbeat.txt
                hostname >> /data/heartbeat.txt
                sleep 10
              done
          volumeMounts:
            - name: app-files
              mountPath: /data
      volumes:
        - name: app-files
          persistentVolumeClaim:
            claimName: app-files-pvc

应用到集群：

kubectl apply -f azure-files-demo.yaml
kubectl get pvc app-files-pvc
kubectl exec deploy/file-writer -- tail -n 20 /data/heartbeat.txt

这个例子适合验证 ReadWriteMany 共享访问路径，但不代表所有应用都可以无脑横向扩容。多个副本同时写同一个文件时，应用层仍然要处理锁、幂等、追加写顺序和失败重试。

落地时的取舍清单

采用 Azure Files 前，建议把问题拆得具体一点：

访问模式：是单机挂载、多 VM 共享，还是 Kubernetes 多副本共享？
协议和语义：应用依赖哪些 Linux 文件系统行为？是否有锁、权限、软链接或大量小文件场景？
性能目标：需要关注吞吐、IOPS、延迟，还是并发连接数？压测要使用真实文件大小和并发度。
数据保护：快照、备份、恢复演练和保留周期是否已经写进运维流程？
安全边界：谁能创建共享、谁能挂载、凭据如何轮换、网络如何限制？
成本模型：容量、事务、性能层级和冗余策略都可能影响账单。

Azure Files 的核心吸引力不是“云上有个共享盘”这么简单，而是把 Linux 应用熟悉的文件访问方式，接到 Azure 的托管能力上。适合它的地方，要大胆用；不适合的地方，比如强事务数据库、海量对象分发或高度定制的本地文件系统行为，也要及时换成更匹配的存储服务。