Github Actionsを使ったNew Relic設定のCI/CD

記事タイトルとURLをコピーする

みなさんこんにちは。マネージドサービス部MSS課の塩野(正)です。 たまに出張をすると張り切って外を歩きすぎて、だいたい筋肉痛になるのですが、これって私だけですかね・・(困

さてさて、今回は前回の話の続きになります。Cloudwatch AlermやZabbixなどからNew Relicに移行した場合、このシステムは今まで通りあっちの監視システムで、新しいシステムはNew Relicでというのもあまり現実的ではありませんので、運用コストを考えると既存設定の移植をする必要があるのではないかと考えています。設定自体はTerraform などのコードを使用して実施するとして、毎回ローカルでコマンドを実行するよりはレポジトリ内のコードを更新したら、自動的にNew Relicに反映してくれると便利だよね~というのは皆さまの共通認識だと思います。前回の記事ではTerrafor Cloudを使った設定についてご紹介させていただきました。今回はもうひとつの選択肢となっていた Github Actionsについて記事にまとめてみました。

blog.serverworks.co.jp

blog.serverworks.co.jp

目次

Terraform CloudとGithub Actionsを使った場合の比較のおさらい

さらっとおさらいすると、お金をかけたくないし、そこまで大規模でもない環境の場合はGithub Actionsという選択肢もあるよという理解でいいかと思います。 詳しくは下記の記事に記載しておりますが、お金をかけたくない、大規模でないという条件はGithubのプランに依存しているのが大きな理由となります。

blog.serverworks.co.jp

公式サイトには下記のように記載があり、プライベートレポジトリに関しては「GitHub アカウントに付与」されている無料枠の範囲であれば無料で使えますが、この枠を超えてしまうと料金が発生してしまうため注意が必要です。

GitHub Actions の使用は、パブリック リポジトリの標準の GitHub ホステッド ランナーとセルフホステッド ランナーの場合は無料です。 プライベート リポジトリの場合、アカウントのプランに応じて、GitHub ホステッド ランナーでの使用を対象として、一定量の無料の使用時間 (分) とストレージが各 GitHub アカウントに付与されます。 含まれる量を超える使用は、使用制限によって制御されます。

docs.github.com

なお、無料枠を含めたプランの概要は下記の通りです。詳細は上記Githubのページをご参照ください。

Plan Storage Minutes (per month)
GitHub Free 500 MB 2,000
GitHub Pro 1 GB 3,000
GitHub Free for organizations 500 MB 2,000
GitHub Team 2 GB 3,000
GitHub Enterprise Cloud 50 GB 50,000

Github Actionsを使ったCI/CD

全体の構成

Github Actionsを使った場合、ざっくりと下記のような構成になると考えています。 Terraform Cloudがなくなった分、構成上はシンプルに見えますが、tfstateファイルを管理する場合はstateファイルの管理先がS3となりますので注意が必要になります。

  • Stateファイルを管理しない場合

  • Stateファイルを管理する場合

tfstateの管理って必要?不要?

これに関しては議論の余地があると認識しています。AWSやGoogle Cloud、Azureなどのクラウド環境を構築する場合、検証環境で試したものとまったく同じものを本番環境で使用したいニーズや障害などで環境が壊れてしまった場合にすばやく復旧する必要があるなど、「同じ環境をもう一度作り直す」可能性があることからIaCを使って状態管理をしておくのは必須でしょう。

その一方で監視設定などの場合は、「同じ環境をもう一度作り直す」可能性よりは、システムを運用していく中でちょっと閾値を変えてみようとか、うまく設定できていないかもしれないのでちょっと監視設定を変更してみようというニーズの方がはるかに高いのではないかと考えています。その「ちょっと設定を変更してみよう」といった場合に、コードを修正して、そのコードの内容確認・承認を通して設定反映するとなると、設定変更に対するスピード感が大きく損なわれる可能性が高いと考えられます。また、運用者の中にはコードが読み書きできない担当者がいるケースも少なからずあるでしょう。

もちろんどちらが正しい、どちらが間違っているというのはございませんが、システムを保守していく中で設定の正しさより、設定変更時のスピード感を求められるケースや、terraformのコードの保守ができない運用者に対してtfstateを強いることへの運用コスト負担を考慮すると、初期設定はterraformなどで実施したとしても、その後の変更などの際にはtfstateを管理せずにGUIでポチポチ設定変更する方が運用者の負担ははるかに小さいものになるのではないかと考えています。

そのあたりも踏まえてterraformで設定を実施する場合は、tfstateの管理をどのようにするかというのを運用を見据えた上でしっかり検討いただければと考えています。

Github Actionsを試してみた

それでは当記事の本題となっているGithub Actionsを使用した設定の話にすすめましょう。今回はStateファイルを管理しない想定で検証をしていますが、Github Actions環境でStateファイルを管理したい場合はS3バケットとアクセスするためのアクセスキーやシークレットアクセスキーを準備しておいて、下記の「backend "s3"」の設定を追加する必要があります。また、公式ドキュメントではバケットのバージョニングを有効にすることを強く推奨されていますので、tfstateを管理する場合は設定漏れのないようにご注意ください。

terraform {
 required_providers {
   <new relicのprovider情報を記載>
   }
  backend "s3" {
    bucket         = "<tfstateを保存するバケット名>"
    key               = "<保存先Path>"
    region         = "<S3バケットのリージョン>"
  }
}

developer.hashicorp.com

Github Actions自体は難しいものではなく、レポジトリのルートの 「.github/workflows」 フォルダを作成し、その中にコード更新時にどのような処理をしたいかをyamlファイルで定義していくことで、コードが更新された際に自動的に設定するような動作が実現できる機能になります。どのようなコードを記載すればよいかの詳細については、こちらの公式ドキュメントが参考になりますので合わせてご参照ください。

docs.github.com

環境変数の設定

今回はコード更新とともにNew Relicの設定を実施しますので、コードを保存しているレポジトリにある環境変数の設定が必要になります。 まず、Settingを開き、Secret and variablesの中のActionsをクリックします。次にActions secrets and variablesの中にある、Secrets または Variablesを選択し、New Repository SecretまたはNew Repository Variableをクリックして環境変数の登録を行います。APIキーを登録する場合は、必ず「New Repository Secret」として登録してください。

ファイルの設定

今回の検証で使用したファイルと構成は下記の通りです。

root
  +-----.github/workflows
  |                +------deploy.yml
  |
  +-----policy
           +------main.tf
           +------variables.tf
# /.github/workflows/deploy.yml

name: New Relic Policy Deployment

on:
  push:
    paths:
      - '/policy/*'

jobs:
  terraform:
    runs-on: ubuntu-latest
    defaults:
      run:
        working-directory: ./policy
    timeout-minutes: 2
    env:
      TF_VAR_new_relic_account_id: ${{ vars.NEW_RELIC_ACCOUNT_ID }}
      TF_VAR_new_relic_api_key: ${{ secrets.NEW_RELIC_API_KEY }}
    steps:
      - name: Checkout code
        uses: actions/checkout@v2

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v2

      - name: Terraform Init
        run: terraform init

      - name: Terraform plan
        run: terraform plan
        continue-on-error: true

      - name: Terraform Apply
        run: terraform apply -auto-approve
# /policy/main.tf

terraform {
  required_version = "~> 1.0"
  required_providers {
    newrelic = {
      source  = "newrelic/newrelic"
      version = "~> 3.12.0"
    }
  }
}


provider "newrelic" {
  account_id = var.account_id
  api_key    = var.api_key
  region     = "US"

}

resource "newrelic_alert_policy" "example" {
  name = "github_action_policy"
  incident_preference = "PER_POLICY"
  
}
# /policy/variables.tf

variable "api_key" {
  description = "New Relic API Key"
  type        = string
}

variable "account_id" {
  description = "New Relic Account ID"
  type        = string
  default = "1234567"
}

Actionの実行

コードをコミットすると、Actionsタブに新しいアクションが開始されて、ジョブが動作している状況が見えるようになります。

Github Actions実行中は、橙色のステータスがくるくる回っていますので、完了まで待ちます。

Github Actionsの動作が完了すると緑色のチェックマークが入りますので、チェックが入ったことを確認すればOKです。なお、設定ミスなどで本来なら設定が完了しているはずなのに完了していない状況が続くようなこともありますが、おかしいと思ったら一度Github ActionsをCancelで止めて再度コードの見直しを行ってください。個人的には止まっている原因は凡ミスのパターンが多いような気はしますが、デフォルトタイムアウトも長めの設定になっているため、Github Actionsを本格的に使っていきたい場合はタイムアウト値なども適宜見直しをすることをオススメいたします。

まとめ

食わず嫌いだったGithub Actionsを実際に触ってみた感じでは、うまく使いこなすととても便利な機能ということが理解できました。検証では最低限の動作確認しか行っていませんが、もっと色々な制御ができますので、機会があればぜひ使ってみてください。

この記事がどなたかのお役に立てれば幸いです。

宣伝

弊社では、お客様環境のオブザーバビリティを加速するための伴走型のNew Relic導入支援サービスなどもご提供しております。 もしご興味をお持ちの方は、こちらのサービスご紹介ページの一番下にあるお問合せフォームよりお問合せ頂けましたら幸いでございます。

◆ 塩野 正人
◆ マネージドサービス部 所属
◆ X(Twitter):@shioccii
◆ 過去記事はこちら

前職ではオンプレミスで仮想化基盤の構築や運用に従事。現在は運用部隊でNew Relicを使ってサービス改善に奮闘中。