Azure App Serviceのデプロイ方法まとめ｜ポータル・CLI・zip・GitHub Actions・DevOps・コンテナ

Azure

「App Serviceにデプロイする方法、調べるとポータル・CLI・zip・GitHub Actions・コンテナ…と出てきすぎて、結局どれを使えばいいのか分からない」——これはApp Serviceを学び始めた人がほぼ全員ぶつかる壁です。

デプロイのやり方が多すぎる…。手動とCI/CDの違いも、正直あいまいなまま使ってる…

この記事では、App Serviceの「作成とデプロイ」を、手軽な方法から実務的な方法へと順番に整理します。読み終えたときに、次の7つを自分の言葉で説明・実践できるようになることをゴールにしています。

  • ポータルからWeb Appを作成できる
  • Azure CLI（az webapp）で作成できる
  • zip deployでデプロイできる
  • GitHub Actionsでデプロイできる
  • Azure DevOps Pipelinesでデプロイできる
  • コンテナ（ACRイメージ）からデプロイできる
  • デプロイスロット（staging）の概念を理解している

各セクションの最後に「これが説明できればOK」という自己チェックの目安を置いています。App Serviceそのものの概要（PaaSとは・Plan・価格レベル）は前回の記事で解説していますので、そちらも合わせてどうぞ。

全体像：デプロイ方法は「手動」と「自動（CI/CD）」に分かれる

個別の手順に入る前に、地図を持っておきましょう。App Serviceへのデプロイは、大きく「手動デプロイ」と「自動デプロイ（CI/CD）」の2系統に分けて捉えると、頭が整理されます。

【手動デプロイ】自分の手元から直接送り込む
   ├ ポータル … GUIでポチポチ作成（学習の最初）
   ├ Azure CLI（az webapp up / create）… コマンド一発
   └ zip deploy（az webapp deploy）… 成果物のzipを直接送る

【自動デプロイ / CI/CD】gitにpushしたら自動で反映
   ├ GitHub Actions … リポジトリがGitHubなら定番
   └ Azure DevOps Pipelines … Azure DevOps派の定番

【コンテナデプロイ】Dockerイメージから起動
   └ ACRのイメージ → Web App for Containers

ざっくり言えば、学習・検証は手動（ポータルやCLI）、実務の本番運用はCI/CD（GitHub Actions / DevOps）が基本です。まずは手動で「動く」を体験し、慣れたらCI/CDで「自動化」する——この順で進めていきます。

ポータルからWeb Appを作成する

一番手軽なのが、Azureポータル（GUI）からの作成です。学習の最初の一歩に最適で、App Serviceを構成する要素を目で見ながら理解できます。おおまかな流れは次のとおりです。

  1. ポータルで「App Service」→「作成」→「Webアプリ」を選ぶ
  2. リソースグループ・アプリ名（＝ <名前>.azurewebsites.net のURLになる）を入力
  3. 公開方法（コード or コンテナ）、ランタイムスタック（例: Python 3.x）、OS（Linux/Windows）、リージョンを選ぶ
  4. App Service Plan（新規作成 or 既存）と価格レベル（SKU）を選ぶ
  5. 「確認および作成」→「作成」。デプロイ完了後、既定URLにアクセスして初期画面が出ればOK

ここで前回学んだApp Service Plan・価格レベルを実際に選ぶことになります。概要記事の知識が、この画面で「腑に落ちる」瞬間です。

【ここが説明できればOK①】
ポータルのウィザードからWeb Appを作成し、既定の *.azurewebsites.net URLでアプリが応答することを確認できれば、このチェックはクリアです。

Azure CLI（az webapp）で作成する

GUIに慣れたら、次はコマンドでの作成です。CLIは再現性が高く、手順を残せる（＝自動化への第一歩）のが利点です。App Serviceの作成には、大きく2つのコマンドがあります。

① az webapp up：作成＋デプロイを一発で

az webapp up は、ソースコードのあるフォルダで実行するだけで、Plan作成・Web App作成・コードのデプロイまでをまとめてやってくれる、初心者にやさしいコマンドです。

# アプリのソースフォルダで実行
az webapp up \
  --name my-webapp-001 \
  --resource-group rg-appservice \
  --runtime "PYTHON:3.12" \
  --sku B1 \
  --location japaneast

② az webapp create：土台を細かく指定して作成

より細かく制御したい場合は、Plan作成→Web App作成を分けて行います。

# App Service Plan（土台）を作成
az appservice plan create \
  --name plan-appservice \
  --resource-group rg-appservice \
  --sku B1 --is-linux

# その土台の上にWeb App（アプリ）を作成
az webapp create \
  --name my-webapp-001 \
  --resource-group rg-appservice \
  --plan plan-appservice \
  --runtime "PYTHON:3.12"

この2コマンドの分離が、まさに概要記事で説明した「Plan（土台）とWeb App（アプリ）は別物」という関係をそのまま表しています。

「まず試すなら up、土台を作り込むなら plan create + webapp create」と覚えればOK！

【ここが説明できればOK②】
az webapp up または az webapp create でWeb Appを作成し、稼働状態を確認できれば、このチェックはクリアです。

zip deployでデプロイする

zip deploy は、アプリの成果物をzipファイルにまとめて直接送り込むデプロイ方法です。「すでにビルド済みの成果物を、手っ取り早く反映したい」ときに便利で、CI/CDの内部でもよく使われます。

# アプリのファイルをzipに固める
zip -r app.zip .

# zipをApp Serviceへデプロイ
az webapp deploy \
  --resource-group rg-appservice \
  --name my-webapp-001 \
  --src-path app.zip \
  --type zip

コマンドが成功したら、アプリのURLにアクセスして変更が反映されていることを確認します。旧来は az webapp deployment source config-zip というコマンドもありましたが、現在は az webapp deploy に統合されています。

【ここが説明できればOK③】
az webapp deploy --src-path app.zip でアプリをデプロイし、反映されたことを確認できれば、このチェックはクリアです。

GitHub Actionsでデプロイする（CI/CD）

ここからが実務の主役、CI/CD（継続的インテグレーション／継続的デリバリー）です。gitにpushしたら自動でビルド＆デプロイされる仕組みを作れば、毎回手動でzipを送る手間から解放されます。

リポジトリがGitHubにあるなら、GitHub Actions が定番です。ポータルの「デプロイセンター」でGitHubリポジトリを連携すると、ワークフローYAMLが自動生成されます。中身の要点はこうです。

name: Deploy to Azure Web App
on:
  push:
    branches: [ main ]   # mainにpushで発火

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      # （ここでビルド：npm build / pip install 等）
      - name: Deploy to Azure Web App
        uses: azure/webapps-deploy@v3
        with:
          app-name: my-webapp-001
          package: .           # 成果物を指定
          # 認証はOIDC（推奨）またはpublish profileで

認証には、OIDC（フェデレーション資格情報）による接続が推奨されます（シークレットを保存しないパスワードレス方式）。従来は「発行プロファイル（publish profile）」をSecretsに保存する方法も広く使われています。main へのpushでワークフローが走り、成功すればApp Serviceに新バージョンが反映されます。

【ここが説明できればOK④】
GitHub Actionsのワークフローで、pushをトリガーにApp Serviceへ自動デプロイされ成功することを確認できれば、このチェックはクリアです。

Azure DevOps Pipelinesでデプロイする（CI/CD）

Azure DevOpsを使っているチームなら、Azure Pipelines でのデプロイが定番です。考え方はGitHub Actionsと同じ「pushで自動」ですが、デプロイ処理は AzureWebApp タスク が担います。

trigger:
  - main

pool:
  vmImage: ubuntu-latest

steps:
  # （ここでビルドステップ）
  - task: AzureWebApp@1
    inputs:
      azureSubscription: 'my-service-connection'  # サービス接続
      appName: 'my-webapp-001'
      package: '$(System.DefaultWorkingDirectory)/**/*.zip'

ポイントは 「サービス接続（Service Connection）」 でAzureへの認証を設定しておくこと。あとは AzureWebApp@1 タスクにアプリ名と成果物（package）を渡せば、Pipelineの実行でApp Serviceへデプロイされます。GitHub ActionsとAzure Pipelinesは「どちらのプラットフォームを使うか」の違いで、やっていること（push→ビルド→デプロイ）は同じです。

【ここが説明できればOK⑤】
Azure Pipelinesの AzureWebApp タスクでApp Serviceへデプロイが成功することを確認できれば、このチェックはクリアです。

コンテナ（ACRイメージ）からデプロイする

組み込みランタイムでは要件が満たせない場合、自分でビルドしたDockerイメージを動かす Web App for Containers の出番です。イメージの置き場所として、Azure純正の ACR（Azure Container Registry） がよく使われます。

# ACRのイメージを指定してコンテナ用Web Appを設定
az webapp config container set \
  --name my-container-app \
  --resource-group rg-appservice \
  --container-image-name myacr.azurecr.io/myapp:latest \
  --container-registry-url https://myacr.azurecr.io

ACRからイメージをpullする権限には、マネージドIDを使うのが安全な構成です（この認証・ID周りは本シリーズの第5回で詳しく扱います）。イメージを更新したら、App Serviceを再起動 or 継続的デプロイ設定で新イメージに切り替わります。「独自の言語バージョンや依存を丸ごとイメージに固める」ことで、環境差異のないデプロイが実現できます。

【ここが説明できればOK⑥】
ACRのコンテナイメージを指定してWeb App for Containersを起動し、動作を確認できれば、このチェックはクリアです。

デプロイスロット（staging）の概念

最後に、実務で必ず役立つデプロイスロットの考え方を押さえましょう（Standard以上の価格レベルで利用可能）。

デプロイスロットとは、本番（production）とは別に用意できる「もう一つの稼働環境」です。stagingスロットで新バージョンを検証してから、本番と入れ替える（スワップ）ことで、ダウンタイムなしのデプロイを実現します。

【スロットの考え方】

  ┌─ production スロット（本番・今公開中）
  │
  └─ staging スロット（検証用・新バージョンをデプロイ）
             │
             │ ① stagingで動作確認OK
             ▼
        ★ スワップ（swap）
             │
             ▼
   staging ⇄ production を入れ替え
   → ユーザーは瞬時に新バージョンへ（無停止）

いきなり本番に新バージョンを上書きすると、不具合があったときにサービスが止まってしまいます。stagingスロットに先にデプロイして「温めて」おき、動作確認できたらスワップで一気に切り替える——これが安全なデプロイの基本形です。スワップの実際の手順（無停止デプロイ）は、本シリーズ第6回「スケール・運用」で詳しく解説します。

【ここが説明できればOK⑦】
「stagingスロットで検証後に本番へスワップする無停止デプロイの考え方」を説明できれば、このチェックはクリアです。

まとめ

今回はApp Serviceへの「作成とデプロイ」を、手軽な方法から実務的な方法まで整理しました。

  • 手動：ポータル（GUI）→ CLI（az webapp up/create）→ zip deploy（az webapp deploy）
  • 自動（CI/CD）：GitHub Actions / Azure DevOps Pipelines。pushで自動ビルド＆デプロイ
  • コンテナ：ACRイメージ → Web App for Containersで柔軟に
  • デプロイスロット：stagingで検証→スワップで無停止デプロイ

デプロイができたら、次はアプリの「設定（構成）」——環境変数・接続文字列・ログ・カスタムドメインなど——を整えていきましょう。次回の記事で解説します。

あわせて読みたい

タイトルとURLをコピーしました