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

    CI/CDを実現するGitHub Actions

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ポータルのメニューから[コスト]→[コスト管理]→[サブスクリプションに移動]と選択していくことで確認できる。

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

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

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

$ 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]ボタンをクリックすると、新規シークレットの作成ができる。

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

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

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

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

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

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

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

    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アプリがデプロイされた

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

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