アルパカログ

Webエンジニア兼マネージャーがプログラミングやマネジメント、読んだ本のまとめを中心に書いてます。

GitHub ActionsでTerraform plan/apply自動化(setup-terraform)

f:id:otoyo0122:20200819202128p:plain:w300

GitHub Actionsのワークフロー設定ファイルは、以前はHCL形式でしたが今はYAML形式になっています。

このエントリでは、GitHub Actions(setup-terraform)でTerraform plan/applyを自動化する方法を紹介します。

手っ取り早くworkflowファイルのサンプルだけ欲しいという方は下記をご覧ください。

前提条件と注意点

クラウドリソースをすでにTerraformで管理している

まだという方は下記を参考にTerraform管理にしてください。

tfstateファイルをS3などリモートで管理している

ローカルにある人は下記を参考に移行してください。

GitHub Actionsからアクセスできる場所に置く必要があるためです。

注意点

Secretsが漏洩してしまう危険性があるので、パブリックリポジトリや信用できないユーザーがいるリポジトリで実行してはいけません。

ご利用は自己責任でお願いします。

サンプルとポイント

下記リポジトリにサンプルを置いたので参照してください。

ポイント1: ワークフローごとにファイルを分ける

ワークフローは、Terraform planとapplyの2つになります。

planは、PRがオープンされたりPRにコミットが追加されたりしたときに実行します。

applyは、PRがマージされるなどしてコミットがmasterに入ったときに実行します。

実行したいタイミングが異なるので、今回はterraform_plan.ymlterraform_apply.ymlをそれぞれ用意します。

ポイント2: pull_requestイベントをフィルタする

GitHub Actionsは「何が起こったか」を表すイベントによってワークフローを実行します。

PRを表すpull_requestイベントも用意されています。

前述のように、「PRがオープンされた場合」か「PRにコミットが追加された場合」にplanのワークフローを実行します。

しかし問題は、pull_requestイベントを起こすためのトリガー(アクティビティタイプと言う)に今回関係ないものが多いということです。

「アサインした」「アサインを外した」「ラベルを付けた」「ラベルを外した」「編集した」「レビュー準備した」など。

アクティビティタイプの詳細は下記を参照してください。

そこで、必要なアクティビティタイプをフィルタします。

アクティビティタイプでフィルタするには、on.event.typesにアクティビティタイプを指定します。

on:
  pull_request:
    types: [opened, reopened, synchronize, rerequested]

rerequestedは GitHub Actionsのワークフローが失敗したときに現れる再実行ボタンによる実行を表すアクティビティタイプです。

ポイント3: Secretsは環境変数で渡す

Secretsは環境変数で渡します。

AWS関連のキー2つはSecretsに登録しておき、"Configure AWA Credentials" Actionを使って一括でセットしておきます。

AWS credentialsはinit, plan, applyで必要です。

    - name: Configure AWS credentials
      uses: aws-actions/configure-aws-credentials@v1
      with:
        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        aws-region: ap-northeast-1

以上です。

このエントリでは、GitHub Actions(setup-terraform)でTerraform plan/applyを自動化する方法を紹介しました。

参考になった方は、ぜひ「はてブ」やSNSでシェアしていただけると嬉しいです。

履歴

  • 2020年8月19日 サンプルが動かなくなっていたので記事内容とサンプルを更新しました

参考情報