Azure 上的 GitHub Actions
使用带有 azure/webapps-deploy 操作的 GitHub Actions 复现 CI/CD 工作流,并了解何时应选择 GitHub Actions 而不是 Azure Pipelines。
Azure 上的 GitHub Actions 是 CoddyKit 上的免费 Azure Fundamentals 课时。 这是第 4 节课,共 4 节。 你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。 这是 Azure Fundamentals 学习路径的一部分,你的进度在网页和 CoddyKit 应用中同步。 Azure Fundamentals 课程共包含 4 节课。
什么是 GitHub Actions
GitHub Actions 是 GitHub 内置的持续集成、持续交付和自动化平台。工作流定义在存储库的 .github/workflows/ 目录中的 YAML 文件内,并由 GitHub 事件触发,例如推送、拉取请求、发布等。GitHub Actions 与 GitHub 生态系统(议题、PR、包和安全扫描)深度集成,并提供丰富的社区操作市场,可用于构建、测试和部署到 Azure 等任务。
GitHub Actions 工作流结构
GitHub Actions 工作流文件包含三个顶级部分。on 定义触发事件。env 设置全局环境变量。jobs 定义一个或多个作业,每个作业都在 runner(GitHub 托管或自托管)上运行。每个作业包含若干步骤,可以是 run(Shell 脚本)或 uses(预构建操作)。作业默认并行运行;使用 needs 创建顺序依赖关系。
# .github/workflows/ci.yml
name: CI
on:
push:
branches: [main]
pull_request:
branches: [main]
env:
NODE_VERSION: '18.x'
jobs:
build-and-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: ${{ env.NODE_VERSION }}
- run: npm ci
- run: npm test从 GitHub Actions 向 Azure 进行身份验证
让 GitHub Actions 向 Azure 进行身份验证的推荐方式是 OpenID Connect (OIDC)——它会颁发短期令牌,无需在 GitHub 中存储长期机密。请在 Azure App Registration 或托管标识上配置联合身份凭据,并授予其对 GitHub 存储库和分支的信任。使用 azure/login@v2 操作将 GitHub OIDC 令牌交换为 Azure 访问令牌——无需在 GitHub Secrets 中配置客户端机密。
# Configure OIDC federated credential in Azure
az ad app federated-credential create \
--id <AppRegistrationObjectId> \
--parameters '{
"name": "github-oidc",
"issuer": "https://token.actions.githubusercontent.com",
"subject": "repo:myorg/myrepo:ref:refs/heads/main",
"audiences": ["api://AzureADTokenExchange"]
}'
# In the workflow: login via OIDC
# permissions:
# id-token: write
# contents: read
# - uses: azure/login@v2
# with:
# client-id: ${{ vars.AZURE_CLIENT_ID }}
# tenant-id: ${{ vars.AZURE_TENANT_ID }}
# subscription-id: ${{ vars.AZURE_SUBSCRIPTION_ID }}部署到 Azure App Service
azure/webapps-deploy@v3 操作可将代码或容器映像部署到 Azure App Service。它支持槽部署、基于包的部署和 Docker 映像部署。将其与 azure/login@v2 配合使用即可完成身份验证。您可以先部署到暂存槽并运行冒烟测试,然后使用运行槽交换命令的 azure/CLI@v2 操作进行交换——从而完全在 GitHub Actions 中复现 Azure Pipelines 的蓝绿部署模式。
# .github/workflows/deploy.yml
jobs:
deploy:
runs-on: ubuntu-latest
permissions:
id-token: write
contents: read
steps:
- uses: actions/checkout@v4
- uses: azure/login@v2
with:
client-id: ${{ vars.AZURE_CLIENT_ID }}
tenant-id: ${{ vars.AZURE_TENANT_ID }}
subscription-id: ${{ vars.AZURE_SUBSCRIPTION_ID }}
- name: Build and zip app
run: npm ci && npm run build && zip -r app.zip dist/
- uses: azure/webapps-deploy@v3
with:
app-name: myUniqueWebApp
slot-name: staging
package: app.zip部署到 Azure Kubernetes Service
使用 azure/k8s-deploy@v5 操作从 GitHub Actions 部署到 AKS。此操作使用 kubectl apply 部署清单,执行映像替换(将映像标签替换为当前构建的标签),并监视发布运行状况。azure/aks-set-context@v4 操作通过使用已通过身份验证的 Azure 会话获取集群 kubeconfig,来配置 kubectl 凭据。
jobs:
deploy-aks:
runs-on: ubuntu-latest
permissions:
id-token: write
contents: read
steps:
- uses: actions/checkout@v4
- uses: azure/login@v2
with:
client-id: ${{ vars.AZURE_CLIENT_ID }}
tenant-id: ${{ vars.AZURE_TENANT_ID }}
subscription-id: ${{ vars.AZURE_SUBSCRIPTION_ID }}
- uses: azure/aks-set-context@v4
with:
resource-group: MyRG
cluster-name: myAKSCluster
- uses: azure/k8s-deploy@v5
with:
namespace: production
manifests: k8s/
images: 'mycontainerregistry.azurecr.io/myapp:${{ github.sha }}'GitHub Secrets 和变量
将敏感值存储在 GitHub Secrets 中——在工作流中可通过 ${{ secrets.SECRET_NAME }} 访问的加密值。非敏感配置放在 GitHub Variables 中——可通过 ${{ vars.VARIABLE_NAME }} 访问。两者都可以限定到存储库、环境或组织范围。使用 GitHub Actions 中的环境添加保护规则(必需的审阅者、部署分支),其作用类似于 Azure DevOps Environments。
# Reference secrets and variables in a workflow
steps:
- name: Configure app settings
uses: azure/CLI@v2
with:
inlineScript: |
az webapp config appsettings set \
--name myUniqueWebApp \
--resource-group MyRG \
--settings \
DATABASE_URL='${{ secrets.DATABASE_URL }}' \
API_VERSION='${{ vars.API_VERSION }}'环境保护规则
GitHub Actions 的 Environments(在存储库 Settings → Environments 中配置)提供类似于 Azure DevOps environments 的部署门禁。您可以要求必需的审阅者在面向该环境的作业运行前完成审批,限制部署到特定分支(只有 main 可以部署到 Production),还可以添加等待计时器来延迟部署。面向受保护环境的作业会暂停,直到满足所有保护规则。
# Workflow job targeting a protected GitHub environment
jobs:
deploy-production:
runs-on: ubuntu-latest
environment:
name: Production # Must have 2 approvers in GitHub settings
url: https://myapp.contoso.com
needs: deploy-staging
steps:
- uses: azure/login@v2
with:
client-id: ${{ vars.AZURE_CLIENT_ID }}
tenant-id: ${{ vars.AZURE_TENANT_ID }}
subscription-id: ${{ vars.AZURE_SUBSCRIPTION_ID }}
- uses: azure/webapps-deploy@v3
with:
app-name: myUniqueWebApp
package: app.zip可复用工作流和组合操作
使用 GitHub Actions 的两项功能,避免在多个存储库中重复 CI/CD 逻辑。可复用工作流允许您在一个存储库中定义工作流,并通过 uses: myorg/shared-workflows/.github/workflows/deploy.yml@main 在其他存储库的工作流中调用它。组合操作将多个步骤捆绑成一个存储在存储库中的操作,并可通过 uses: myorg/my-actions/deploy@v1 重复使用。两者都能在组织的 CI/CD 流水线中促进 DRY 原则。
# Call a reusable workflow from another workflow
jobs:
deploy:
uses: myorg/shared-workflows/.github/workflows/deploy-appservice.yml@main
with:
app-name: myUniqueWebApp
slot-name: staging
package-path: dist/
secrets:
AZURE_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID }}
AZURE_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
AZURE_SUBSCRIPTION_ID: ${{ secrets.AZURE_SUBSCRIPTION_ID }}GitHub Actions 与 Azure Pipelines:如何选择
在以下情况下选择 GitHub Actions:您的代码托管在 GitHub 上,团队偏好 GitHub 界面,需要与 GitHub PR 检查和代码扫描紧密集成,或者正在构建开源项目(提供充足的免费分钟数)。在以下情况下选择 Azure Pipelines:需要 Azure Boards 集成、借助 Azure Test Plans 进行高级测试、管理 Azure Artifacts 源、代码位于 Azure Repos 中,或者需要在众多环境中通过门禁进行复杂的多阶段发布管理。两者部署到 Azure 的能力同样出色。
GitHub Actions 市场
GitHub Actions Marketplace 提供数千个用于常见任务的社区和官方操作。Microsoft 发布了官方 Azure 操作:azure/login、azure/webapps-deploy、azure/aks-set-context、azure/k8s-deploy、azure/CLI、azure/arm-deploy 等。请始终将操作固定到特定版本标签(例如 @v3)或提交 SHA,以防止遭受供应链攻击,例如受攻击的操作被更新为包含恶意代码。
# Pin actions to specific version (recommended)
- uses: actions/checkout@v4 # Pinned to v4 tag
- uses: azure/login@v2 # Pinned to v2
- uses: azure/webapps-deploy@v3 # Pinned to v3
# Extra security: pin to commit SHA
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
# Avoid unpinned 'latest' or branch references
# - uses: some-action@main # UNSAFE - could change at any time私有网络的自托管运行程序
GitHub 托管的运行程序只能访问公共互联网——如果不将这些资源公开,它们无法访问私有 Azure 资源(SQL 数据库、内部 API)。对于私有资源的部署,请在 VNet 内的 Azure VM 上使用自托管运行程序。注册运行程序的方法是下载 GitHub Actions 运行程序代理,使用存储库 URL 和注册令牌进行配置,然后将其作为服务运行。使用 Azure Container Apps 扩展自托管运行程序,以构建弹性运行程序池。
# Register a self-hosted runner on an Azure VM
# 1. Download runner (run on the VM)
curl -O -L https://github.com/actions/runner/releases/download/v2.317.0/actions-runner-linux-x64-2.317.0.tar.gz
mkdir actions-runner && tar xzf ./actions-runner-linux-x64-2.317.0.tar.gz -C actions-runner
cd actions-runner
# 2. Configure (use token from GitHub Settings > Actions > Runners)
./config.sh --url https://github.com/myorg/myrepo --token <REGISTRATION_TOKEN>
# 3. Run as a service
sudo ./svc.sh install && sudo ./svc.sh start
# Use in workflow
# runs-on: self-hosted快速检查
测试您对本课 Microsoft Azure 基础知识(AZ-900)概念的理解。
课程回顾
本课您学习了:GitHub Actions 工作流是存储在 .github/workflows/ 中、由 GitHub 事件触发并在运行程序上执行的 YAML 文件;OIDC 联合凭据支持 GitHub Actions 无需机密即可向 Azure 进行身份验证;带保护规则的 GitHub Environments为生产部署增加审批门禁。至此 Azure DevOps 课程结束——接下来将学习 Azure Monitor 和日志分析。
常见问题解答
「Azure 上的 GitHub Actions」课时是免费的吗?
是的 — 「Azure 上的 GitHub Actions」的完整文本可在网页上免费阅读。要进行交互式练习(内置代码编辑器和全天候 AI 导师)并解锁 Azure Fundamentals 课程的其余内容,请升级到 CoddyKit PRO。 Azure Fundamentals 课程共包含 4 节课。
「Azure 上的 GitHub Actions」这节课中我会学到什么?
使用带有 azure/webapps-deploy 操作的 GitHub Actions 复现 CI/CD 工作流,并了解何时应选择 GitHub Actions 而不是 Azure Pipelines。 你通过在浏览器中直接运行的动手代码来练习 Azure Fundamentals,全天候 AI 导师会在你学习这节课的过程中回答你的问题。
学习 Azure Fundamentals 需要有经验吗?
无需任何先前经验。CoddyKit 上的 Azure Fundamentals 课程适合初学者到高级学习者,你可以从这里开始或从头开始,按照自己的节奏学习。 这是第 4 节课,共 4 节。
「Azure 上的 GitHub Actions」课时需要多长时间?
大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动,所以你能稳步进步,并在网页和应用中从离开的地方继续。
我能在这节 Azure Fundamentals 课中编写并运行代码吗?
能。每节 Azure Fundamentals 课都包含内置代码编辑器,你可以在浏览器中直接编写并运行真实代码,并获得即时 AI 反馈 — 无需本地设置。
此课程中的所有课时
- Azure DevOps Services 概览
- 使用 Azure Pipelines 构建 CI 管道
- 持续部署到 Azure
- Azure 上的 GitHub Actions