Azure Fundamentals · レッスン

エンドツーエンドの開発者ワークフロー

GitHub Actions CI/CD、Azure Container Registry、Container Apps、Application Insights を接続し、コミットから可観測な本番環境までの開発者インナーループを完成させます。

「エンドツーエンドの開発者ワークフロー」はCoddyKit上の無料Azure Fundamentalsレッスンです。これはレッスン4/4です。下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。これはAzure Fundamentals学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Azure Fundamentalsコースには全4レッスンが含まれています。

ステップ1：ソース管理とブランチ戦略

GitHubリポジトリでコードを管理し、トランクベース開発またはGitFlowのブランチ戦略を使用します。ほとんどのマイクロサービスでは、トランクベース開発（短命のフィーチャーブランチを毎日mainにマージする方式）により、統合時の競合を減らし、パイプラインをシンプルに保てます。mainにはブランチ保護ルールを設定し、マージ前にプルリクエストのレビューとCIチェックの通過を必須にします。CODEOWNERSファイルを使用すると、重要なサービスへの変更について、該当チームのシニアエンジニアによる承認を必須にできます。

# Example .github/CODEOWNERS
# Require payments-team review for any changes under /src/payments/
/src/payments/ @payments-team
/infrastructure/   @platform-team

ステップ2：GitHub ActionsによるCI

CIパイプラインは、すべてのプルリクエストで実行されます。一般的なワークフローは、コードのチェックアウト → 依存関係の復元 → 単体テストの実行 → 統合テストの実行 → Dockerイメージのビルド → Azure Container Registryへのプッシュです。追跡可能性を確保するため、イメージにはgitコミットSHAでタグを付けます。GitHubにAzureサービスプリンシパルのシークレットを保存せずに済むよう、GitHub ActionsからAzureへのOIDCベースの認証（フェデレーションID経由）を使用します。これはCIパイプライン向けのマネージドIDに相当します。

# .github/workflows/ci.yml (abbreviated)
name: CI
on: [pull_request]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Login to ACR
        uses: azure/docker-login@v1
        with:
          login-server: myacr.azurecr.io
          username: ${{ secrets.AZURE_CLIENT_ID }}
          password: ${{ secrets.AZURE_CLIENT_SECRET }}
      - name: Build and push image
        run: |
          docker build -t myacr.azurecr.io/myapi:${{ github.sha }} .
          docker push myacr.azurecr.io/myapi:${{ github.sha }}

ステップ3：ステージング環境へのCD

mainへのマージ後にCIパイプラインが成功すると、CDパイプラインは自動的にステージング環境へデプロイします。パイプラインはContainer Appのイメージタグを新しくビルドしたSHAに更新し、新しいリビジョンが正常な状態になるまで待機してから、ステージングURLに対してスモークテストを実行します。スモークテストでは、重要なAPIエンドポイントが期待どおりのレスポンスを返すことを確認します。スモークテストに失敗した場合、パイプラインは手動操作なしでイングレスのトラフィックを以前のリビジョンに戻し、ロールバックします。

# CD stage: update Container App to new image
- name: Deploy to staging
  uses: azure/cli@v2
  with:
    azcliversion: latest
    inlineScript: |
      az containerapp update \
        --name myapi-staging \
        --resource-group myRG \
        --image myacr.azurecr.io/myapi:${{ github.sha }}

- name: Run smoke tests
  run: |
    STAGING_URL=$(az containerapp show --name myapi-staging \
      --resource-group myRG \
      --query 'properties.configuration.ingress.fqdn' -o tsv)
    curl -f https://$STAGING_URL/health || exit 1

ステップ4：本番環境の承認ゲート

ステージングの検証後、CDパイプラインは承認ゲートで一時停止します。GitHub ActionsのEnvironment protectionsを使用すると、production環境に必要なレビュアーを設定できます。パイプラインはオンコールエンジニアにSlack通知を送り、その担当者がステージングのテスト結果、差分、未解決のインシデントを確認してから承認します。承認された場合にのみ、パイプラインは同じイメージSHAを本番環境へデプロイします。この人間による確認を組み込んだステップは、高トラフィックのサービスや規制対象サービスにとって重要です。

# In GitHub: create 'production' environment with required reviewers
# .github/workflows/cd.yml (abbreviated)
jobs:
  deploy-production:
    environment:
      name: production
      url: https://myapi.contoso.com
    needs: deploy-staging
    steps:
      - name: Deploy to production
        uses: azure/cli@v2
        with:
          inlineScript: |
            az containerapp update \
              --name myapi \
              --resource-group myRG \
              --image myacr.azurecr.io/myapi:${{ github.sha }}

ステップ5：本番環境の可観測性

本番環境へのデプロイ後、Application Insightsによってリアルタイムの可視性が得られます。App Insights SDK（またはサポートされているランタイム向けの自動インストルメンテーション）は、リクエスト率、失敗率、遅延（3つのゴールデンシグナル）、依存関係の呼び出し（データベース、Service Bus、その他のAPIへの呼び出し）、そして完全なスタックトレース付きの例外を追跡します。Application Mapはサービス間の呼び出しを可視化し、障害や遅延に最も寄与している依存関係を強調表示します。

# Python: Add Application Insights SDK
from opencensus.ext.azure.log_exporter import AzureLogHandler
from opencensus.ext.azure.trace_exporter import AzureExporter
from opencensus.trace.samplers import ProbabilitySampler
from opencensus.trace.tracer import Tracer

tracer = Tracer(
  exporter=AzureExporter(connection_string='InstrumentationKey=<key>'),
  sampler=ProbabilitySampler(1.0)
)

デプロイとトレースの関連付け

Application Insights Annotationsを使用して、メトリックチャートにデプロイイベントを記録します。リリースのアノテーションを作成すると（GitHub Actionsのazure/appinsights-annotationアクション経由）、すべてのApp Insightsメトリックチャートに垂直線として表示されます。これにより、遅延の急増やエラー率の上昇が直近のデプロイと相関しているかどうかがすぐに分かり、インシデント発生時の平均診断時間（MTTD）を大幅に短縮できます。

# Create a release annotation in Application Insights
- name: Annotate release in App Insights
  uses: azure/appinsights-annotation@v1
  with:
    appInsightsResourceName: myAppInsights
    resourceGroupName: myRG
    releaseName: '${{ github.run_id }}-${{ github.sha }}'

エラー率急増時の自動ロールバック

最も高い回復性を備えたパイプラインでは、自動ロールバックを実装します。本番環境へのデプロイ後、パイプラインは10分間待機してからApplication Insightsにエラー率を問い合わせます。エラー率が設定可能なしきい値（例：5%超）を上回った場合、パイプラインはContainer Appのイングレストラフィックを100%以前のリビジョンに向けることで自動的にロールバックします。このプログレッシブデリバリーパターンにより、問題のあるデプロイの影響範囲を縮小し、複雑な変更や慎重な対応が必要な変更でも、チームは自信を持ってデプロイできます。

# Query App Insights error rate via REST (abbreviated)
QUERY='requests | where timestamp > ago(10m) | summarize failed = countif(success == false), total = count() | extend errorRate = round(100.0 * failed / total, 2)'
RESULT=$(az monitor app-insights query \
  --apps myAppInsights \
  --resource-group myRG \
  --analytics-query "$QUERY" \
  --query 'tables[0].rows[0][2]' -o tsv)
if [ $(echo '$RESULT > 5' | bc -l) -eq 1 ]; then
  echo 'Error rate $RESULT% - rolling back!'
  az containerapp ingress traffic set --name myapi --resource-group myRG --revision-weight stable=100
fi

開発者の生産性：エミュレーターを使用したローカル開発

開発者は、本番のAzureリソースに接続せずに、完全なスタックをローカルで実行およびテストできる必要があります。ローカルのBlobおよびキューストレージにはAzure Storage Emulator（Azurite）、ローカルのデータベーステストにはCosmos DB Emulator、ローカルのメッセージングにはService Bus Emulatorを使用します。AZURE_ENVIRONMENT=local環境変数を使うと、DefaultAzureCredentialをエミュレーターを指す接続文字列の使用に切り替えられます。一方、同じコードがAzureではマネージドIDを使用します。Docker Composeを使えば、すべてのローカル依存関係を1つのdocker compose upでオーケストレーションできます。

# docker-compose.yml for local development
services:
  azurite:
    image: mcr.microsoft.com/azure-storage/azurite
    ports:
      - '10000:10000'
      - '10001:10001'
  cosmos-emulator:
    image: mcr.microsoft.com/cosmosdb/linux/azure-cosmos-emulator
    ports:
      - '8081:8081'

開発者ワークフローにおけるセキュリティ

開発者ワークフローのすべての段階にセキュリティを組み込みます。Dependabotはプルリクエスト内の脆弱な依存関係をスキャンします。GitHub Advanced Security（CodeQLによるコードスキャン）は、SQLインジェクションやハードコードされたシークレットなどの脆弱性を検出します。Microsoft Defender for DevOpsはGitHubと統合し、コードの変更と併せてAzureのセキュリティに関する推奨事項を提示します。ACR Defenderの脆弱性スキャンは、プッシュのたびにコンテナーイメージのOSおよびアプリケーション層のCVEをチェックします。セキュリティ上の指摘はプルリクエストのコメントとして表示されるため、マージ前に対処できます。

すべてをまとめる

完全な開発者ワークフローは継続的なフィードバックループです。開発者がコードをコミットし、CIがコンテナーイメージをビルドしてテストし、イメージがコミットSHAをタグとしてACRにプッシュされ、CDがステージング環境へデプロイしてスモークテストを実行し、人間が本番環境へのデプロイを承認します。その後、パイプラインが本番環境へデプロイしてリリースアノテーションを作成し、Application Insightsがエラー率を監視します。しきい値を超えた場合は自動的にロールバックします。同じリポジトリにInfrastructure as Code（BicepまたはTerraform）を置くことで、パイプライン、Container App、監視構成もアプリケーションコードとともにすべてバージョン管理できます。

クイックチェック

このレッスンで扱った Microsoft Azure Fundamentals（AZ-900）の概念について、理解度を確認しましょう。

レッスンのまとめ

このレッスンでは、エンドツーエンドの開発者ワークフローがGitHubのソース管理、GitHub ActionsのCI/CD、Azure Container Registry、Container Apps、Application Insightsを結び付けること、リリースアノテーションによってデプロイとメトリックの変化を関連付け、インシデントをより迅速に診断できること、そしてエラー率のクエリに基づく自動ロールバックによって問題のあるデプロイの影響範囲を縮小できることを学びました。次は、クラウドの概念とAzureアーキテクチャを包括的に復習し、試験対策に移ります。

よくある質問