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をはじめとする各種クラウドサービスへのデプロイも、ワークフローの一部として自動化できる。

CI/CDを実現するGitHub Actions

Azure向けGitHub Actions

Microsoftからは、Azureと連携するためのさまざまなアクションが提供されている。主なアクションとしては次のようなものがあり、GitHub Marketplaceで見つけることができる。

通常の開発で必要となる大半の作業がカバーされていることがわかる。上記のほかにも、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/ --sdk-auth

の部分は自身のアカウントのものに置き換えてほしい。サブスクシプションIDは、Azureポータルのメニューから[コスト]→[コスト管理]→[サブスクリプションに移動]と選択していくことで確認できる。

サブスクリプションIDの確認

上のコマンドの場合、サブスクリプション全体に対するサービスプリンシパルを生成されるが、次のようにすることでサービスプリンシパルの範囲を特定のリソースグループやアプリケーションに制限することもできる。

$ az ad sp create-for-rbac --role contributor --scopes /subscriptions//resourceGroups//providers/Microsoft.Web/sites/ --sdk-auth

サービスプリンシパルの作成に成功すると、次のような形式のJSONデータが返ってくるので、これをテキストファイルにメモしておこう。

{

"clientId": ""

"clientSecret": ""

"subscriptionId": ""

"tenantId": ""

"activeDirectoryEndpointUrl": ""

"resourceManagerEndpointUrl": ""

"activeDirectoryGraphResourceId": ""

"sqlManagementEndpointUrl": ""

"galleryEndpointUrl": ""

"managementEndpointUrl": ""

}

続いて、WebブラウザでGitHubリポジトリのページに行き、[Settings]→[Secrets]のメニューを開く。ここで、右上辺りにある[New secret]ボタンをクリックすると、新規シークレットの作成ができる。

GitHubリポジトリでシークレットを作成する

次のように、Name(シークレット名)に「AZURE_CREDENTIALS」を、Valueに先ほどメモしたサービスプリンシパルを記入して、[Add secret]ボタンで登録する。

Azureのサービスプリンシパルを登録

シークレットが登録できたら、ワークフローを作成しよう。[Actions]タブを開くと、最初は次のようなページが表示される。さまざま目的に応じたワークフローのテンプレートが用意されているので、これをベースにカスタマイズしてもいいが、今回は自前で作成するので[set up a workflow yourself]のリンクをクリックする。

Actionsタブでワークフローを作成する

下記のように、プロジェクトの/.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アプリが登録されていることを確認しよう。

Azure App ServiceにWebアプリがデプロイされた

以上が、GitHub Actionsを利用する一連の手順である。次回は、ワークフローの定義ファイルの中身についてもう少し詳しく解説したい。