みなさんこんにちは。マネージドサービス部MSS課の塩野(正)です。 たまに出張をすると張り切って外を歩きすぎて、だいたい筋肉痛になるのですが、これって私だけですかね・・(困
さてさて、今回は前回の話の続きになります。Cloudwatch AlermやZabbixなどからNew Relicに移行した場合、このシステムは今まで通りあっちの監視システムで、新しいシステムはNew Relicでというのもあまり現実的ではありませんので、運用コストを考えると既存設定の移植をする必要があるのではないかと考えています。設定自体はTerraform などのコードを使用して実施するとして、毎回ローカルでコマンドを実行するよりはレポジトリ内のコードを更新したら、自動的にNew Relicに反映してくれると便利だよね~というのは皆さまの共通認識だと思います。前回の記事ではTerrafor Cloudを使った設定についてご紹介させていただきました。今回はもうひとつの選択肢となっていた Github Actionsについて記事にまとめてみました。
目次
Terraform CloudとGithub Actionsを使った場合の比較のおさらい
さらっとおさらいすると、お金をかけたくないし、そこまで大規模でもない環境の場合はGithub Actionsという選択肢もあるよという理解でいいかと思います。 詳しくは下記の記事に記載しておりますが、お金をかけたくない、大規模でないという条件はGithubのプランに依存しているのが大きな理由となります。
公式サイトには下記のように記載があり、プライベートレポジトリに関しては「GitHub アカウントに付与」されている無料枠の範囲であれば無料で使えますが、この枠を超えてしまうと料金が発生してしまうため注意が必要です。
GitHub Actions の使用は、パブリック リポジトリの標準の GitHub ホステッド ランナーとセルフホステッド ランナーの場合は無料です。 プライベート リポジトリの場合、アカウントのプランに応じて、GitHub ホステッド ランナーでの使用を対象として、一定量の無料の使用時間 (分) とストレージが各 GitHub アカウントに付与されます。 含まれる量を超える使用は、使用制限によって制御されます。
なお、無料枠を含めたプランの概要は下記の通りです。詳細は上記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バケットのリージョン>" } }
Github Actions自体は難しいものではなく、レポジトリのルートの 「.github/workflows」 フォルダを作成し、その中にコード更新時にどのような処理をしたいかをyamlファイルで定義していくことで、コードが更新された際に自動的に設定するような動作が実現できる機能になります。どのようなコードを記載すればよいかの詳細については、こちらの公式ドキュメントが参考になりますので合わせてご参照ください。
環境変数の設定
今回はコード更新とともに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導入支援サービスなどもご提供しております。 もしご興味をお持ちの方は、こちらのサービスご紹介ページの一番下にあるお問合せフォームよりお問合せ頂けましたら幸いでございます。