はじめに
クラウドでWebアプリケーションを公開したいとき、インフラの構築やデプロイの仕組み作りは意外と手間がかかるものです。
今回は、そんな悩みを解決してくれるAzureのPaaS（Platform as a Service）である Azure App Service と、GitHubを連携させたCI/CDパイプラインの構築がいかに簡単かをご紹介します。
AzureのApp Serviceとは
App Serviceは、Webアプリケーションやモバイルバックエンドをホストするためのフルマネージドプラットフォームです。
インフラ（OS、ミドルウェア、サーバーなど）の管理をAzureに任せることができるため、開発者はアプリケーションのコードを書くことに集中できます。
- 多言語対応: .NET, Java, Node.js, Python, PHP, Rubyなど、多くの言語やフレームワークをサポート
- 自動スケール: トラフィックに応じて自動でスケールアウト／スケールインが可能
- CI/CD連携: GitHub, Azure DevOps, Bitbucketなどと簡単に連携し、継続的インテグレーションと継続的デプロイを実現
今回は、この中でも特に便利な GitHubとの連携機能 を使って、git pushするだけで自動でビルド＆デプロイが実行される環境を構築していきます。
筆者のひとりごと
コードをアップロードするだけで、すぐにWebアプリケーションとして公開できる手軽さは、まさに"神サービス"だと個人的に感じています。AWSなど他のクラウドサービスも経験してきましたが、このApp ServiceはAzureの中でも筆者が最も好きなサービスの一つです。
ここからは具体的手順
前提条件
- Azureアカウント（無料試用版でも可）
- GitHubアカウント
- デプロイしたいソースコードが格納されたGitHubリポジトリ
Step 1: App Serviceリソースの作成
まずはAzure Portalで、アプリケーションの土台となるApp Serviceを作成します。
１. Azure Portalにサインインし、[+ リソースの作成] をクリックします。
２. 検索バーに「Webアプリ」または「App Service」と入力し、表示された「Webアプリ」を選択して [作成] をクリックします。
３. 基本タブで以下の項目を入力・選択します。
- サブスクリプション: ご自身のサブスクリプション
- リソースグループ: 新規作成または既存のものを選択
-
名前: アプリケーションのURLになる一意の名前（例:
qiita-app-service-demo） -
公開:
コードを選択 -
ランタイムスタック: アプリケーションに合わせたものを選択（例:
Node 24 LTS） -
オペレーティングシステム:
LinuxまたはWindowsを選択 -
地域: アプリケーションをデプロイするリージョン（例:
東日本） - App Service プラン: サーバーのスペックを定義します。開発・テスト用途であれば、FreeプランやBasicプランで十分です。
４. [確認および作成] をクリックし、内容を確認したら [作成] をクリックします。デプロイが完了するまで数分待ちます。
Step 2: デプロイセンターでGitHubと連携
App Serviceのリソースが作成されたら、いよいよGitHubと連携します。
１. 作成したApp Serviceのリソース画面を開き、左側のメニューから [デプロイセンター] を選択します。
２. ソースとして GitHub を選択します。
３. GitHubアカウントの認証が求められるので、画面の指示に従って認証・認可します。
４. 連携するリポジトリとブランチを選択します。
- 組織: ご自身のGitHubアカウントまたは所属するOrganization
- リポジトリ: デプロイしたいソースコードが入っているリポジトリ
-
ブランチ: デプロイのトリガーとしたいブランチ（例:
mainやmaster） - 認証の種類: 今回は"基本認証"を選択
５. 基本認証を選択するために、WebAppのSCM認証を有効にします。
６. 設定内容を確認し、[保存] をクリックします。
補足：認証方法「基本認証」と「ユーザー割り当て」の違い
デプロイセンターでGitHubとの連携を設定する際、「認証の種類」として 「基本認証」 と 「ユーザー割り当て」 の選択肢が表示されます。これは、GitHub ActionsがAzureにデプロイを行う際の「身分証明」の方法を選ぶものです。
Azure Portalが推奨している通り、特別な理由がなければ ユーザー割り当て を選択する方が良さそうです。複雑に見える設定も、Portalが自動で行ってくれるため、私たちは安全な方法を簡単に利用できます。
1. 基本認証 (Basic Authentication)
これは、ユーザー名とパスワードのような 長期間有効な認証情報（発行プロファイル） を利用する方法です。
- 仕組み: 発行プロファイルという「合鍵」のようなものを生成し、それをGitHubリポジトリのSecretsに保存します。GitHub Actionsはデプロイのたびにこの合鍵を使ってAzureにログインします。
- 懸念点: 合鍵（認証情報）がもし外部に漏洩してしまった場合、第三者にAzureリソースへのアクセスを許してしまうリスクがあります。
一言でいうと、「家の合鍵を外部の金庫に預けておく」 ようなイメージです。
2. ユーザー割り当て (User-assigned identity)
こちらは、パスワードを使わないモダンで安全な認証方法です。Azure ADの 「ユーザー割り当てマネージドID」 という仕組みを利用します。
-
仕組み:
- まず、Azure上に「ID（身分証明書）」を作成します。
- そのIDに「このApp Serviceにデプロイする権限」を与えます。
- 最後に、GitHub Actionsのワークフローに対して「あなたはこのIDですよ」と関連付けます。
- メリット: パスワードのような固定の認証情報をどこにも保存する必要がありません。そのため、認証情報が漏洩するリスクが極めて低くなります。
一言でいうと、 「特定の担当者（ワークフロー）にだけ顔認証を許可する」 ようなイメージです。鍵を盗まれる心配がありません。
これだけで、GitHubリポジトリにCI/CDのワークフローファイルが自動で作成され、初回のビルド＆デプロイが実行されます。簡単すぎませんか？
Step 3: 自動ビルド＆デプロイ実行
１. mainブランチにあるコードが自動的にビルド・デプロイがスタートします。
２. Github Actionsの画面に遷移してみます。問題なければ成功します。
３．ドメイン（URL）にアクセスするとWebアプリケーションが起動します。
４．毎回この時間がエンジニアとして一番うれしい瞬間です。
今回はPoCで作成した簡易Webアプリです。
ナレッジ：ビルドエラー Error: Process completed with exit code 1.
エラーメッセージ
Github ActionsのBuildのログに、以下のようなエラーが表示された場合の対処法です。
************@1.0.0 test
echo Error: no test specified exit 1
Error: no test specified
Error: Process completed with exit code 1.
対処法
今回のビルドエラーは、GitHubリポジトリ内の .github/workflows/ ディレクトリにあるワークフローファイル、具体的には main_********.yml に記載されている npm run test --if-present の行を削除することで解決します。
なぜ npm run test を消すとビルドが成功したのか？
CI/CDのワークフローから npm run test --if-present の行を削除したことでビルドが成功したのは、エラーの原因となっていた「テストの実行」命令そのものを取り除いたからです。
もう少し詳しく解説すると、以下の流れになります。
-
エラーの原因: ビルドエラーは、
npm testというコマンドの実行が原因でした。 -
プロジェクトの初期設定: 多くのNode.jsプロジェクトでは、設計図である
package.jsonファイルに、テストが未設定の場合、わざと処理を失敗させるコマンド (exit 1) が初期設定として記述されています。 -
コマンドの実行:
npm run test --if-presentは、この「わざと失敗するコマンド」を実行してしまっていました。その結果、ビルドプロセス全体が「失敗」と判断され、停止していました。 -
解決: この行を削除したことで、問題のコマンドが実行されなくなり、エラーの原因自体が解消されました。そのため、ビルドプロセスは最後まで無事に完了できたのです。
#Azure #AppService #GitHub #GitHubActions #Webアプリケーション