GitHub Actionsとは
クラウド上に展開されたアプリケーションを継続的に保守していくには、CI/CDの導入が不可欠である。CI/CDはContinuous Integration / Continuous Deliveryの略で、ソフトウェアに対する変更を常にテストし、自動で本番環境にリリース可能な状態までもっていく開発手法である。日本語では「継続的インティグレーション/継続的デリバリー」と呼ばれる。テストやパッケージビルドの手続きを人間の手を介さずに行うことができるため、バグの修正や機能追加などの変更を迅速に本番環境に反映させられるというメリットがある。
GitHub Actionsは、GitHub上にホストされたプロジェクトに対してさまざまなワークフローを定義し、自動で実行することができるサービスである。プロジェクトのビルドやテスト、デプロイ、コードレビュー、ブランチ管理など、ソフトウェア開発で必要となるさまざまなアクションを1つのワークフローとしてまとめ、それを自動で実行してくれる。ワークフローの起動のトリガーとなるのは、GitHubに対するリソースのPushやPull Request、Issueの追加などといった各種イベントだ。例えば、開発者の誰かがソースコードを修正してPushしたら、それをトリガーとして自動でワークフローが起動し、ビルドやテストを実行してくれるというわけだ。
ビルドやテストなどの各種アクションは、Linux/Windows/macOSのいずれかのVMまたはコンテナ内で直接実行される。アクションは、GitHubが提供するもの以外にサードパーティが作成することもでき、GitHub Marketplaceで公開されている。外部のサービスと連携したアクションにも対応しているため、Azureをはじめとする各種クラウドサービスへのデプロイも、ワークフローの一部として自動化できる。
Azure向けGitHub Actions
Microsoftからは、Azureと連携するためのさまざまなアクションが提供されている。主なアクションとしては次のようなものがあり、GitHub Marketplaceで見つけることができる。
アクション | 内容 |
---|---|
Azure Login | Azure環境にログインする |
Azure CLI Action | Azure環境上でAzure CLI Scriptを実行する |
Azure PowerShell Action | Azure環境上でAzure PowerShell Scriptを実行する |
Azure WebApp | Azure Wen AppsおよびAzure Web Apps for Containersへアプリケーションをデプロイする |
Azure App Service Settings | Azure App Serviceの設定を行う |
Azure App Configuration Sync | GitHubリポジトリをAzure App Configurationと同期する |
Azure Functions Action | Azure Functionsアプリをデプロイする |
Azure Functions Container Action | Azure Functionsのカスタムコンテナイメージをデプロイする |
Docker Login | Azure Container Registryにログインする |
Deploy to Azure Container Instances | Azure Container Instancesにコンテナをデプロイする |
Container image scan | コンテナイメージをデプロイする前に脆弱性の検証を行う |
Azure SQL Deploy | DACPACまたはSQLを使用してAzure SQL databaseをアップデートする |
Azure MYSQL Deploy | MySQL scriptを使用してAzure Database for MySQL server |
Azure Kubernetes Service set context | Azure Kubernetes Service (AKS)のクラスタ・コンテキストをセットアップする |
Deploy to Kubernetes cluster | Kubernetes clusterをデプロイする |
Kubernetes bake | Bakeマニフェストファイルをデプロイする |
Kubectl tool installer | kubectlをインストールする |
Create secret in Kubernetes cluster | AKSクラスタのシークレットを作成する |
Azure Machine Learning Workspace | Azure Machine Learning(AML)ワークスペースの作成やログインを行う |
Azure Machine Learning Run Action | AMLの機械学習モデルをトレーニングする |
Azure Machine Learning Deploy Action | AMLに機械学習モデルをデプロイする |
Azure Machine Learning Register Model Action | AMLに機械学習モデルを登録する |
Azure Pipelines Action | Azure PipelinesのCI/CDを開始する |
通常の開発で必要となる大半の作業がカバーされていることがわかる。上記のほかにも、GitHub Marketplaceには第三者が作成したアクションが多数公開されている。
実際にGitHub ActionsによるCI/CDを実現するには、これらのアクションを組み合わせてワークフローを定義しなければならない。ワークフローはYAML形式のファイルで定義する。Azure向けのプロジェクトの場合、MicrosoftのAzureチームによるこちらのGitHubリポジトリにさまざまな作業に対応したワークフローのテンプレートが公開されているので、これをベースとしてワークフローを作成すると良いだろう。
ちなみに、AzureにもAzure PipelinesというCI/CDのためのサービスがある。こちらは基本的にはAzure DevOpsのリポジトリを対象としたサービスになるが、上の表にもあるAzure Pipelines Actionというアクションを利用することでGitHubリポジトリと連携できるようになっている。
GitHub Actionsを使ったAzure Web Serviceへのデプロイ
それでは、実際にGitHub Actionsを使って、WebアプリケーションのビルドおよびAzure App Serviceへのデプロイを自動化してみよう。ここでは、サンプルのアプリケーションとして、前回までに作成した蔵書管理のSpring Bootアプリを利用する。アプリケーションのソースコード一式はこのGitHubリポジトリで公開しているので、これをForkすればビルド可能なサンプルとして利用できる。
GitHub ActionsからApp Serviceにアクセスするには、Azureサブスクリプションのサービスプリンシパルか、または対象のアプリケーションの発行プロファイルが必要となる。今回はサービスプリンシパルを使用する。サービスプリンシパルは、AzureのクラウドリソースにアクセスするためのセキュリティIDであり、ユーザ認証の証明書のような役割を持つ。
サービスプリンシパルは、Azure CLIでAzure環境にログインした上で、次のコマンドで作成できる。Azure CLIについては第3回の記事を参照のこと。
$ az ad sp create-for-rbac --role contributor --scopes /subscriptions/<サブスクリプションID> --sdk-auth
<サブスクリプションID>の部分は自身のアカウントのものに置き換えてほしい。サブスクシプションIDは、Azureポータルのメニューから[コスト]→[コスト管理]→[サブスクリプションに移動]と選択していくことで確認できる。
上のコマンドの場合、サブスクリプション全体に対するサービスプリンシパルを生成されるが、次のようにすることでサービスプリンシパルの範囲を特定のリソースグループやアプリケーションに制限することもできる。
$ az ad sp create-for-rbac --role contributor --scopes /subscriptions/<サブスクリプションID>/resourceGroups/<リソースグループ名>/providers/Microsoft.Web/sites/<アプリケーション名> --sdk-auth
サービスプリンシパルの作成に成功すると、次のような形式のJSONデータが返ってくるので、これをテキストファイルにメモしておこう。
{
"clientId": "<GUID>"
"clientSecret": "<GUID>"
"subscriptionId": "<GUID>"
"tenantId": "<GUID>"
"activeDirectoryEndpointUrl": "<URL>"
"resourceManagerEndpointUrl": "<URL>"
"activeDirectoryGraphResourceId": "<URL>"
"sqlManagementEndpointUrl": "<URL>"
"galleryEndpointUrl": "<URL>"
"managementEndpointUrl": "<URL>"
}
続いて、WebブラウザでGitHubリポジトリのページに行き、[Settings]→[Secrets]のメニューを開く。ここで、右上辺りにある[New secret]ボタンをクリックすると、新規シークレットの作成ができる。
次のように、Name(シークレット名)に「AZURE_CREDENTIALS」を、Valueに先ほどメモしたサービスプリンシパルを記入して、[Add secret]ボタンで登録する。
シークレットが登録できたら、ワークフローを作成しよう。[Actions]タブを開くと、最初は次のようなページが表示される。さまざま目的に応じたワークフローのテンプレートが用意されているので、これをベースにカスタマイズしてもいいが、今回は自前で作成するので[set up a workflow yourself]のリンクをクリックする。
下記のように、プロジェクトの/.github/workflows ディレクトリが作成されて、main.ymlという名前でYAML形式のファイルが開くので、ここにワークフローの定義を記述する。なお、このディレクトリに置かれたYAMLファイルは自動的にワークフローの定義ファイルとして扱われるので、Webブラウザ上で作業するのではなく、ローカルのリポジトリで作業してプッシュしてもよい。
今回は次のようなワークフローを定義した。記述内容の詳細は次回解説したい。
/.github/workflows/main.yml
# This is a basic workflow to help you get started with Actions
name: AzureWebApps
on:
push:
branches: [ master ]
jobs:
build-and-deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Set up JDK 11
uses: actions/setup-java@v1
with:
java-version: 11
# Build package using Maven
- name: maven build, clean
run: |
mvn clean package -D skipTests
# Maven plugin can cosume this authentication method automatically
- name: Azure Login
uses: azure/login@v1
with:
creds: ${{ secrets.AZURE_CREDENTIALS }}
# Maven deploy, make sure you have correct configurations in your pom.xml
- name: deploy to Azure App Service using Maven
run: |
mvn azure-webapp:deploy
記述できたら、右上の[Start commit]ボタンでコミット/プッシュしよう。定義ファイルがプッシュされると自動的にワークフローが有効になる。今回の例では、リポジトリのmasterブランチに新しいコミットがプッシュされたら、それをトリガーとしてワークフローが実行される。
ワークフローが実行されると、Actionsタブでは次のように実行結果が表示される。この例は、main.yml自体がプッシュされたことをトリガーとして実行された結果である。
詳細を見ると、次のように各アクションの実行結果を確認できる。再実行したい場合には右上の[Re-run jobs]ボタンをクリックする。
今回使用したワークフローでは、最後にAzure App Servieへのデプロイを行なっている。AzureポータルでいまビルドしたWebアプリが登録されていることを確認しよう。
以上が、GitHub Actionsを利用する一連の手順である。次回は、ワークフローの定義ファイルの中身についてもう少し詳しく解説したい。