.NET Aspire 在 Azure Container Apps 中的 PostgreSQL 数据持久化问题解析

问题背景

在将 .NET Aspire 应用部署到 Azure Container Apps (ACA) 时，开发团队遇到了 PostgreSQL 容器数据持久化的严重问题。每次通过 azd deploy 重新部署应用时，PostgreSQL 容器中的数据都会被完全清除，即使已经配置了 WithDataVolume() 方法。这不仅导致数据库数据丢失，连表结构也会被重置。

问题根源分析

经过深入调查，发现这个问题源于多个技术层面的限制：

1. Azure Container Apps 的卷处理机制：ACA 在重新部署时对持久化卷的处理方式存在限制，特别是在使用 PostgreSQL 这类需要特定文件系统权限的数据库容器时。

2. PostgreSQL 容器的权限要求：PostgreSQL 容器在启动时会尝试修改数据目录的权限，这在 ACA 的存储卷环境中不被允许，导致容器启动失败并重新初始化数据库。

3. Azure 存储卷的限制：当前 Azure 存储卷不支持容器修改文件权限的操作，而 PostgreSQL 容器恰恰需要这种能力来确保数据安全。

解决方案探索

方案一：使用 Azure Flexible PostgreSQL 服务

经过验证，最可靠的解决方案是放弃容器化的 PostgreSQL，转而使用 Azure 原生的 Flexible PostgreSQL 服务：

var postgres = builder.AddAzurePostgresFlexibleServer("postgres");

这种方案的优势包括：

• 数据持久性有保障
• 无需担心部署时的数据丢失
• 可以获得 Azure 提供的托管服务优势

方案二：处理扩展依赖问题

在迁移到 Azure Flexible PostgreSQL 后，可能会遇到扩展依赖问题，特别是当应用使用了如 uuid-ossp 或 pgvector 等扩展时。可以通过以下方式解决：

postgres.ConfigureInfrastructure(infra => 
{
    var server = infra.GetProvisionableResources()
                    .OfType<PostgreSqlFlexibleServer>()
                    .Single();

    infra.Add(new PostgreSqlFlexibleServerConfiguration("extensions")
    {
        Parent = server,
        Name = "azure.extensions",
        Value = "vector,uuid-ossp",
        Source = "user-override"
    });
});

方案三：EF Core 迁移处理

对于 EF Core 迁移不自动执行的问题，需要确保：

1. 在应用启动时显式调用 DbContext.Database.Migrate()
2. 或者在部署流程中加入单独的迁移步骤
3. 检查数据库连接字符串是否正确配置

最佳实践建议

1. 生产环境数据库选择：对于生产环境，强烈建议使用 Azure Database for PostgreSQL 这类托管服务，而非容器化的数据库。

2. 开发环境配置：在开发环境中可以继续使用容器化 PostgreSQL，但要注意通过 WithDataVolume() 配置持久化卷。

3. 扩展管理：提前规划好需要的 PostgreSQL 扩展，并在基础设施代码中明确声明。

4. 迁移策略：建立完善的数据库迁移策略，可以考虑使用独立的迁移工具或在应用启动时执行迁移。

总结

在 .NET Aspire 应用部署到 Azure Container Apps 时，数据库持久化是需要特别注意的关键环节。通过采用 Azure 原生数据库服务而非容器化方案，可以避免大多数数据持久化问题。同时，合理配置数据库扩展和迁移策略，能够确保应用平稳运行和数据安全。

对于需要特定扩展的场景，务必提前在基础设施代码中声明，并了解 Azure PostgreSQL 服务的扩展支持策略。通过这些措施，开发者可以在享受 .NET Aspire 便利的同时，确保数据层的稳定性和可靠性。