software

部署：场景：Azure App Service + Github + SQL Server

发布: (2026年1月9日 GMT+8 07:07)
9 分钟阅读
原文: Dev.to

I’m happy to translate the article for you, but I’ll need the text you’d like translated. Could you please paste the content (or the portions you want translated) here? I’ll keep the source link at the top and preserve all formatting, markdown, and code blocks as you requested.

我们将要搭建的场景组件

  • Azure App Service: 应用运行的地方
  • GitHub: 代码所在的地方
  • GitHub Actions（可选，但推荐）: 构建和部署的自动化
  • Azure SQL Database（SQL Server）: 数据存放的地方
GitHub (código)
↓
Pipeline (build / deploy)
↓
Azure App Service (API / App)
↓
Azure SQL Database (dados)

1. 什么是 Azure App Service？

正如我们在服务器类型中已经看到的，Azure App Service 是一个 托管服务。这意味着您：

  • 不需要创建服务器
  • 不需要安装 Windows/Linux
  • 不需要手动配置 IIS、Kestrel 或 Nginx

1.1 App Service

Azure 平台会为您处理所有这些事项。创建一个 App Service 时，您需要定义：

  • 运行时（例如：.NET 8）
  • 托管计划（CPU / 内存 / 成本）
  • 区域（服务器所在的位置）

这将生成一个公共 URL 并提供一个准备好运行您代码的环境：

https://minha-api.azurewebsites.net

重要提示： 此时 没有任何代码在运行。

1.2 代码如何上传到 Azure？（GitHub Actions）

在 Azure App Service 配置完成后，我们需要将代码从代码仓库推送到 Azure。此处我们将使用 GitHub Actions，并了解它解决了什么问题。

1.2.1 手动流程

在使用 GitHub Actions 之前，部署通常是这样进行的：

  1. 本地编译
  2. 手动发布
  3. 通过 FTP 覆盖文件

该流程会导致不一致、人工错误、缺少历史记录以及不可预测的部署等问题。

1.2.2 GitHub Actions

GitHub Actions 是一个 可配置的机器人，每当仓库中发生某些事件时就会在 GitHub 内部运行。这个“某些事件”可以是：

  • push
  • pull request
  • 创建标签
  • 定时调度

机器人可以编译代码、运行测试、生成构建、执行部署、发送通知等。所有这些都源于已配置的 workflow。

1.3 什么是 workflow，它与上述内容有什么关系？

workflow 是一个 .yml 文件，用来描述：“当 X 发生时，按顺序执行 Y 步骤”。例如：

# .github/workflows/deploy.yml
on:
  push:
    branches: [ main ]

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3
      - name: Build
        run: dotnet build --configuration Release
      - name: Test
        run: dotnet test --no-build --configuration Release
      - name: Publish
        run: dotnet publish -c Release -o ./publish
      - name: Deploy to Azure
        uses: azure/webapps-deploy@v2
        with:
          app-name: minha-api
          publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }}
          package: ./publish

好处： workflow 文件本身是代码，因此部署过程变得 可版本化、可审计且可重复。

Source: …

2. 在 Azure 上创建 SQL Server

在 Azure 上创建数据库时，您已经拥有自动备份、高可用性且无需安装任何东西。过程结束后，您会收到：

  • 服务器名称
  • 数据库名称
  • 用户名和密码

这些信息 绝不能 写入代码中。

2.1 逻辑服务器（SQL Server）

它不是虚拟机，而是用于身份验证和连接的托管端点。该服务器：

  • 可以托管多个数据库
  • 集中管理安全性
  • 控制防火墙

在 Azure 门户中：
Azure SQL → Create → 填写：

  • Server name → meu-servidor.database.windows.net
  • Admin login
  • 密码

2.2 数据库

在服务器内部，创建数据库 nomeDoBanco 并设置：

  • 层级（Basic / General Purpose / Business Critical）
  • DTU 或 vCore

2.3 SQL Server 防火墙

默认情况下，没人能够访问数据库。请在 Networking → Firewall rules 中进行配置：

  • ✔️ Allow Azure services
  • ✔️ 添加您的机器 IP（用于本地迁移）

如果不这样做：

  • 应用程序无法连接
  • 迁移会失败
  • 会出现超时错误

在真实生产环境中： 理想做法是使用 Private Endpoint。对于入门阶段，简单的防火墙设置已经足够。

3. Connection String – 应用与数据库之间的桥梁

这是所有部署中最重要的部分之一。没有 connection string，应用程序无法与数据库通信。

  • 应用启动: ✔️
  • 数据库已存在: ✔️
  • 但没有任何通信: ❌

3.1 你在 Azure SQL Database 中已经创建的内容

  • 服务器名称
  • 数据库名称
  • 管理员登录名
  • 密码
  • 认证类型（SQL Authentication）

这些信息构成了你的 connection string 的基础。

3.2 实际上 Connection String 是什么？

它是一段文本，告诉应用程序：

  • 数据库所在位置
  • 要访问的数据库
  • 如何进行身份验证
  • 连接期间的行为

通用示例：

Server=...
Database=...
User Id=...
Password=...

3.3 Connection String 的值从哪里来？

在 Azure SQL Database 中：

SQL Database → Settings → Connection strings

通常你会看到类似如下的内容：

Server=tcp:meuservidor.database.windows.net,1433;
Initial Catalog=MinhaBase;
PersistSecurityInfo=False;
User ID=adminuser;
Password=********;
MultipleActiveResultSets=False;
Encrypt=True;
TrustServerCertificate=False;
Connection Timeout=30;

提示: 复制完整的字符串并将其存储在 Secret 中（例如 Azure Key Vault 或 GitHub Secrets），以确保它永远不会出现在代码中。

3.4 现在我们把 App → 数据库 连接起来

此配置直接在 Azure App Service 中完成，无需修改代码。

3.4.1 Azure Portal 中的路径

App Service
 → Settings
 → Configuration
 → Connection strings

此区域相当于应用程序的 机密库。

  • ✅ 更安全
  • ✅ 与代码分离
  • ✅ 适用于不同环境（开发 / 测试 / 生产）

3.4.2 Connection String 的名称（非常重要）

如果你使用 Entity Framework Core，最常见（也是推荐）的名称是：

DefaultConnection

该名称必须 完全匹配 你在 Program.cs 或 appsettings.json 中使用的名称。

代码中的常见示例：

builder.Services.AddDbContext(options =>
    options.UseSqlServer(
        builder.Configuration.GetConnectionString("DefaultConnection")));

如果 Azure 中的名称不一致：

  • ❌ 应用能够启动
  • ❌ 但找不到数据库
  • ❌ 经典错误：The ConnectionString property has not been initialized

4. 迁移

现在是 数据库部署中最重要的部分。我们将其分为三条实用路径：

  • 手动迁移 本地 → Azure SQL
  • 通过 GitHub Actions 迁移 → Azure SQL（流水线）
  • 使用 SQL 脚本迁移（企业常用做法）

4.1 手动迁移（本地 → Azure SQL）

前置条件

  • 使用 EF Core 的项目
  • 已创建迁移

这一步不会修改数据库，只会生成 C# 文件。

4.2 在 Azure 上开放数据库访问

默认情况下，Azure SQL 会阻止所有连接，需要授权本地机器；否则系统会出现 Login failed / Timeout expired 错误。

在 Azure 门户

  1. Azure SQL Server
  2. Networking
  3. Firewall rules
  4. Add your client IPv4 address
  5. Save

4.3 确保应用指向 Azure

确保 appsettings.Development.json 文件指向 Azure 上的 SQL Server：

{
  "ConnectionStrings": {
    "DefaultConnection": "Server=tcp:meuservidor.database.windows.net;..."
  }
}

4.4 执行迁移

dotnet ef database update

背后发生的事情

  • EF 与 Azure SQL 建立连接
  • 检查是否存在表 __EFMigrationsHistory
    • 若 不存在 → 创建
    • 若存在 → 读取已执行的迁移记录
  • 对比：
    • 代码中的迁移
    • 数据库中的迁移
  • 只执行 未完成的迁移
  • 记录已应用的版本
Back to Blog

相关文章

阅读更多 »

你好，我是新人。

嗨！我又回到 STEM 的领域了。我也喜欢学习能源系统、科学、技术、工程和数学。其中一个项目是…