Azure App Service と GitHub Actions を使って、CI(継続的インテグレーション)とCD(継続的デリバリー)を組むには
はじめに
この記事はAzure App Service Team BlogのZero to Heroシリーズの記事に感銘を受けて、和訳＆改変＆自分で新規執筆した記事です。 この記事を通してWeb Appsの基礎から実運用の方法まで、筆者自身が見直す機会としてシリーズ化して掲載する事にしました。 本家の「Zero to Hero」というフレーズの通り、Azure App Serviceを使ったことの無い方は一人前になれるように、すでに利用している方は知識のアップデートに役立てていただければと思います。
なお、連載の５回目からは筆者オリジナルのコンテンツを掲載しています。目次からまとめて読めますので、是非どうぞ。
【Azure初心者から上級者まで！】Azure App Service を使いこなしてゼロからヒーローになる
概要
この記事はApp Service でゼロからヒーローの2回目になります。そのためPart 1を終えた想定です。
前回の記事では App Service プランを作り、サンプルアプリケーションをForkしました。この記事では、GitHub Actions を使って CI/CD のパイプラインをセットアップします。
CI/CDとは
CI(継続的インテグレーション)とCD(継続的デリバリー) は、App Service や Azure において特別なものではありません。テストとデプロイを自動化することは、モダンなソフトウェア開発においてはベストプラクティスになります。App Service は GitHub Actions と Azure Pipelines を直接結びつけることができるので、App Service の CI/CD は容易に設定することができます。
継続的インテグレーション
継続的インテグレーションは、CI/CD パイプライン の最初の一歩です。このフェーズでは、パイプラインがアプリケーションのビルドとテストを担います。 masterブランチへの新しいプルリクエストでパイプラインが走ります。 このフェーズではコーディングのスタイルガイドを強制したり、lintを適用したりできます。
継続的デリバリー
アプリケーションがビルドされ、テストをパスすれば、新しいビルドは自動的にステージングかプロダクションのサーバーにデプロイされます。 より進化したデプロイチームはプロダクションに直接デプロイするかもしれませんが、思慮深いオペレーションと自動テストが要求されます。
ちょうどCI/CDを始めたチームは本番環境のミラーとなるステージング環境にデプロイし、動作確認した後に手動で新しいビルドをリリースできます。
次の記事では、本番へのトラフィックの一部をステージングにルーティングして、新しいビルドバージョンのアプリケーションにトラフィックを送る方法を紹介します。
ステージング環境の作成
App Service では、 スロットを使って、独立したステージング環境を作ったり消したりすることができます。コードやコンテナをスロットにデプロイして、新しいビルドを検証し、ステージングスロットをプロダクションスロットに スワップ することができます。
スワップは新しいビルドをユーザーに効果的にリリースします。
<name>のパラメータをWeb Appの名前で書き換えれば、下記に記載した CLI コマンドを使ってステージングスロットが作られます。
az webapp deployment slot create --slot staging -n <name> -g zero_to_hero
ポータルを利用する場合は以下の画像を参考にしてください。
ステージングスロットは固有のドメイン名を持ちます。ドメイン名はプロダクションスロットと似たパターンの名前を持ちます。
http://mycoolapp.azurewebsites.netにstagingというスロットを追加した場合はhttp://mycoolapp -staging .azurewebsites.netとなります。
CI/CD パイプラインを作成する
次に、CI/CDパイプラインを作り、GitHubリポジトリをステージングスロットに繋げます。 App Service には GitHub Actions と Azure Pipelinesを繋ぐ機能がビルトインされています。 サンプルアプリケーションがGitHubリポジトリにホストされているので、GitHub Actions を自分のパイプラインで利用できます。
GitHub Actions とは
GitHub Actions CI/CD をビルトインした自動化のフレームワークです。
リポジトリに新しいコミットや、プルリクエストへのコメント、プルリクエストがマージされたとき、CRONスケジュールがあるたびに、自動化タスクを実行することができます。自動化タスクは YAMLのファイルでリポジトリの .github/workflows/ ディレクトリにある ワークフローファイルにまとめられ、アプリケーションコードと共にソース配下としてトラックされます。
ワークフローファイルは自動化が実行される際の処理内容を定義します。ワークフローは１つか複数のjobsから構成され、ジョブは１つか複数のstepsから構成されます。ジョブは、ステップが実行されるOSを定義します。もし、ライブラリをパブリッシュして複数のOSでテストしたいなら、複数のジョブを使う必要があります。各ステップは個々の自動化のタスクで、自分に必要なものを書いたり、GitHubコミュニティで作られたアクションをインポートすることも出来ます。
“Hello World” ワークフローファイル例は以下になります。リポジトリにPUSHされると、いつでも、_“Hello Keanu Reeves”_と現時刻がプリントされます。YAMLを注意深く読めば、ドット記法を使用して、最後のステップが以前の「Helloworld」ステップからの出力をどのように参照しているかを確認できます。
name: Greet Everyone
on: [push] # This workflow is triggered on pushes to the repository.
jobs:
build:
name: Greeting # Job name is Greeting
runs-on: ubuntu-latest # This job runs on Linux
steps:
# This step uses GitHub's hello-world-javascript-action: https://github.com/actions/hello-world-javascript-action
- name: Hello world
uses: actions/hello-world-javascript-action@v1
with:
who-to-greet: 'Keanu Reeves'
id: hello
# This step prints an output (time) from the previous step's action.
- name: Echo the greeting's time
run: echo 'The time was ${{ steps.hello.outputs.time }}.'
GitHub Actions terms and conceptsについて、もっと知るにはこちら
パイプラインを作成する
Azure Portalで、前回作ったApp Service を開きます。 デプロイメントヘッダーの左側にある[デプロイ センター]を選択します。 App Service Deployment Centerが開きます。 Deployment Centerが CI/CD のセットアッププロセスをガイドします。
デプロイセンターを表示する
ビルドプロバイダーを選択する
次に、[GitHub] を選択して [続行]をクリックします。 次のページで、[GitHub Actions] を選択し、下部の[続行]をクリックします。
ビルド構成を設定する
次にドロップダウンからリポジトリを選択します。言語と言語バージョンのドロップダウンを編集する必要はありません。
最後のページで、リポジトリにコミットした GitHub Actions ワークフローファイルのプレビューを見つけることができます。 [完了]をクリックして、リポジトリにワークフローファイルをコミットします。このコミットはワークフローのトリガーになります。
App Service と連携させる GitHub Actions について学ぶには、こちら and Azure Pipelines について学ぶには、こちら。
パイプラインの進捗状況をチェックする
GitHubのリポジトリにあるマスターブランチで、.github/workflows/ という新しいファイルを見つけることができます。
GitHubリポジトリの[Actions]タブをクリックすると、GitHub Actions が実行された履歴を見ることができます。
ワークフローが完了すると、ステージングスロットへのデプロイが完了しているのが確認できます。
まとめ
これで継続的ビルドとステージングにデプロイするための CI/CD パイプラインを作ることができました。次の記事では、どのようにステージングスロットとプロダクションスロットを swap して、新しいビルドをプロダクションのユーザーにリリースします。 また、どのように少数のユーザーをステージングスロットにルーティングして、新しいビルドとプロダクションのトラフィックをA/Bテストするかについても説明します。
役に立つリンク
- Using GitHub Actions to deploy a Windows Container to App Service
- GitHub Workflows to create and delete a slot for Pull Requests
お問い合わせはこちらから
問い合わせる
