開発チームと運用チームの一貫したワークフローを構築する方法

GitHubとHashiCorpの連携により、企業は一貫したワークフローとアクションで、より速く、より安全に開発し、顧客に出荷することができるようになります。

GitHubが最近発表した「2022 State of the Octoverse」レポートにおいて、HashiCorp Configuration Language（HCL）がGitHubで最も成長したプログラミング言語となりました。HashiCorpは、クラウドコンピューティングのためのInfrastructure as Code (IaC) 自動化のリーディングプロバイダーです。HCLは、Terraformや Vaultなどのツールと共に使用されるHashiCorpの設定言語で、マルチクラウドやオンプレミス環境において、人間が読みやすい設定ファイルでIaC機能を提供することができます。

HCLの成長は、インフラ、運用、開発者の世界を一つにすることの重要性を示しています。これは常にDevOpsの目標でした。しかし、現実には、多くの企業でこれらの世界がサイロ化したままになっています。

この記事では、開発チームと運用チーム、そしてセキュリティ、ガバナンス、ネットワーク・チームを結びつけるビジネスと文化の影響について見ていきます。そして、GitHubとHashiCorpがCI/CDパイプライン全体を通して一貫したワークフローとガードレールをどのように実現できるかを探ります。

従来の運用（Ops）の世界

HashiCorpの共同創業者であるArmon Dadgar氏は、従来のOpsの世界を「木」に例えて説明しています。トランクには、物事を成し遂げるために企業で必要な、共有され一貫性のあるサービスがすべて含まれています。セキュリティ要件、Active Directory、ネットワーク構成などを考えてみてください。ブランチは、企業内のさまざまなビジネスラインを表し、社内または社外にサービスや製品を提供します。葉は、ソフトウェアやサービスが展開されるさまざまな環境と技術を表します。クラウド、オンプレミス、コンテナ環境などです。

多くの企業では、これらの異なるビジネス領域間のコミュニケーション・チャネルやプロセスが煩雑で、コストがかかる場合があります。インフラやアーキテクチャに大きな変更があった場合、通常、複数のチケットが複数のチームに提出され、企業内のさまざまな部署でレビューと承認が行われます。組織を保護するために、変更諮問委員会が一般的に使用されます。通常、文書化が完了しない限り、変更を進めることはできません。一般的に、将来の監査に必要な一連のガバナンスログと監査可能な成果物が存在します。

もし、チームが最適化された自動化されたワークフローを持ち、それを使って納期を早め、安全なガードレールのセットで仕事を終わらせることができるようになったら、企業にとってより有益ではないでしょうか？これは、時間とコストの大幅な節約につながり、ビジネス価値の向上につながる可能性があります。

最近のForresterのレポートでは、GitHubを使うことで3年間で433%のROIを達成したという結果が出ています。もちろん、時間の節約や効率の向上は言うまでもなく、一貫性と作業の合理化によってもたらされるその他の質的なメリットもあります。

あなたの製品やサービスは、遅々として進まない、手作業でエラーが起こりやすいプロセスではなく、セキュリティとガバナンスが組み込まれた最適化された経路でデプロイされることになるでしょう。これこそ、DevOps、GitOps、Cloud Nativeの夢ではないでしょうか？

IaCの導入

別の例えを使いましょう。IaCは、ソフトウェアやサービスをホストするリソース（サーバー、データベース、ネットワークコンポーネント、PaaSサービスなど）の設計図だと考えてください。

病院と学校を設計する場合、両シナリオで同じ全体的な設計図を使用することはないでしょう。なぜなら、両シナリオはまったく異なる目的を持ち、要件も大きく異なるからです。しかし、2つの設計にまたがって再利用できる構成要素や基礎があるはずです。

HCLのようなIaCソリューションでは、ソフトウェア開発でメソッド、モジュール、パッケージライブラリを再利用するのと同様に、これらのビルディングブロックを定義して再利用することができます。IaCであるため、アプリケーションでコラボレーションやデプロイを行う際に使用するのと同じ推奨プラクティスをインフラに採用することができます。

結局のところ、DevOpsの方法論を採用するチームは、生産性、クラウド対応のスケーラビリティ、コラボレーション、およびセキュリティが向上することが分かっているのです。

より良いデリバリー方法

このような背景から、インフラストラクチャをコード化することで得られる具体的なメリットと、それが従来の運用文化の変革にどのように役立つかを探ってみましょう。

リポジトリにコードを保存する

まずは、最も低いところにある果実から始めましょう。IaCであれば、GitHubなどのソースコード・リポジトリにインフラストラクチャやアーキテクチャ・パターンを保存することができます。これにより、完全なバージョン履歴を持つ単一のソース・オブ・トゥルースを手に入れることができる。これにより、必要に応じて変更をロールバックしたり、履歴から特定のバージョンの真実をデプロイしたりすることが容易にできるようになります。

企業内のチームは、Git リポジトリ内の個別のブランチでコラボレーションを行うことができます。ブランチを使うことで、チームや個人は「自分のスペース」で生産的になり、「本番」の真実のソース（通常はメインブランチ）から離れて、他のチームの進行中の作業に悪影響を与えることを心配する必要がなくなります。

前節で述べた再利用可能なビルディングブロックであるTerraformモジュールも、Gitリポジトリに保存されバージョン管理されています。そこからTerraform Cloudのプライベートレジストリにインポートすることで、全チームが簡単にモジュールを発見できるようになります。GitHubで新しいリリースバージョンのタグが付けられると、レジストリにも自動的に更新されます。

早期かつ頻繁にコラボレーションする

上で説明したように、チームは現在の状態に影響を与えないように、別々のブランチで変更を加えることができます。しかし、その変更を本番環境のコードベースに反映させたい場合はどうすればいいのでしょうか。もしあなたが Git に慣れていないのなら、プルリクエストという言葉を聞いたことがないかもしれません。その名のとおり、あるブランチから別のブランチに変更を「引き込む」ことができます。

GitHub のプルリクエストは、チーム内の他のユーザーとコラボレーションするためのすばらしい方法です。ピアレビューを受けることで、フィードバックを自分の作業に反映させることができます。プルリクエストのプロセスは、チーム全体のコラボレーションを促進するために意図的に非常にソーシャルになっています。

GitHub では、ブランチ保護ルールを設定してメインブランチへの直接の変更を不可とすることもできます。そうすれば、すべてのユーザーがコードを実運用に移すにはプルリクエストを経由しなければならなくなります。ブランチ保護ルールには、最低限必要なレビュアーの人数を指定することもできます。

ヒント:GitHub のCODEOWNERS ファイルという特殊なファイルを使えば、編集中のファイルに基づいてプルリクエストにレビュアーを自動的に追加することができます。例えば、すべてのHCLファイルは、コアインフラストラクチャチームによるレビューが必要かもしれません。あるいは、勘定系システムのIaC設定には、コンプライアンスチームによるレビューが必要かもしれません。

通常、特定の周期で行われる変更諮問委員会とは異なり、プルリクエストはコードを本番環境に導入するためのプロセスの自然な一部となります。また、意思決定や議論の質も向上します。外部システムで推奨される「イエス/ノー」の決定ではなく、プルリクエストで直接コンテキストと推奨を確認することができます。

プロビジョニングプロセスではコラボレーションも重要です。GitHubとTerraform Cloudの統合により、これらのプロセスを複数のチーム間でスケールさせることができます。Terraform Cloud は Terraform の状態を安全に保存し、GitHub リポジトリと直接統合することで、プルリクエストとマージのライフサイクルをターンキーで体験できるようなワークフロー機能を提供します。

自動化された品質レビューをプロセスに取り入れる

前節の続きですが、プルリクエストでは、提案された変更の品質を自動的にチェックすることもできます。ソフトウェアでは、アプリケーションが正しくコンパイルされているか、ユニットテストは合格しているか、セキュリティの脆弱性はないかなどをチェックするのが一般的です。

IaCの観点からは、同様の自動チェックを我々のプロセスに取り入れることができます。GitHub のステータスチェックを使えば、特定の条件を満たしているかどうかを明確に把握することができます。

GitHub Actions は、GitHub のプルリクエストでこうした自動チェックを実行するためによく使われるものです。IaCの品質を判断するために、以下のようなチェックを入れることができます。

• コードが構文的に正しいかどうかを検証する（例えばTerraform validate）。
• コードが特定の標準に従っていることを確認するためのLinting（例えば、TFLintや Terraform format）。
• 静的コード解析により、「設計時」にインフラストラクチャの設定ミスを特定します (たとえば、tfsecやterrascan など)。
• 関連するユニットテストまたは統合テスト（Terratest などのツールを使用）。
• インフラストラクチャを「スモークテスト」環境にデプロイし、インフラストラクチャの構成が（既知のパラメータセットと共に）望ましい状態にデプロイされることを検証します。

Terraform on GitHubを使い始めるのは簡単です。TerraformのバージョンはLinuxベースのGitHubでホストされたランナーにインストールされていますし、HashiCorpには公式のGitHub Actionがあり、指定したTerraformバージョンを使ってランナーにTerraformをセットアップしてくれます。

自動チェックとしてのコンプライアンス

先日、デリバリーパイプラインにコンプライアンス、セキュリティ、監査を組み込むことと、このアプローチの利点についてブログを書きました。既存の開発パイプラインやワークフローに IaC を追加すると、以前は手動だったコンプライアンステストや成果物を、HCL の設定ファイルに直接コードとして記述することができるようになります。

IaCの自然な拡張として、コードとしてのポリシーは、セキュリティとコンプライアンスチームが組織の要求の定義を一元化することを可能にします。Terraform CloudはHashiCorp SentinelとOpen Policy Agent (OPA)のフレームワークをサポートしており、GitHubリポジトリからポリシーセットを自動的に取り込み、すべてのプロビジョニング実行に一貫して適用することができます。これにより、設定ミスが本番環境に出る前に、ポリシーが適用されるようになります。

最近の別のブログで言及された追加ボーナスは、AIを搭載したコンプライアンスソリューションを活用して、配信をさらに最適化する能力です。AIが、開発およびインフラのデリバリー・パイプライン全体にわたって、手作業なしでコンプライアンスに焦点を当てたユニットテストを生成する未来を想像してみてください。

バックグラウンドでのセキュリティ

依存関係を最新の状態に保つための便利なツール、Dependabotをご存じかもしれません。しかし、Dependabot がTerraform をサポートしていることをご存知でしょうか？つまり、Terraformのプロバイダやモジュールのバージョンを最新に保つために、Dependabotを利用することができるのです。

チェック完了、デプロイの時間

チェックが完了したら、次は新しいインフラ構成をデプロイする番です！ブランチやデプロイ戦略は、この先も続きます。ブランチやデプロイの戦略については、この記事の範囲外なので、別の議論に譲りましょう。

しかし、GitHub Actions はデプロイの面でも役に立ちます。先ほど説明したように、GitHub上でTerraformを使い始めるのは簡単です。TerraformのバージョンはLinuxベースのGitHubでホストされているランナーにインストールされていますし、HashiCorpには公式のGitHub Actionがあり、指定したTerraformのバージョンを使ってランナー上にTerraformをセットアップしてくれます。

しかし、これをさらに進化させることができるのですTerraformでは、変更を本番環境に反映させる前に、terraform planというコマンドを使って変更の影響を把握するのが一般的です。

プルリクエストで環境の変更を確認する

HashiCorp は、GitHub Actions を使って Terraform を自動化する例を示しています。この例では、GitHub Actionsを使ってTerraform Cloudによるリリースをオーケストレーションしています。この例では、terraform planコマンドの出力をプルリクエストにコピーして承認します（これも、選択した開発フローに依存します）。

GitHub Actions の環境を使った環境変更のレビュー

HashiCorpの例をもとに、もうひとつの例を考えてみましょう。GitHub Actions には、environment (環境) という概念が組み込まれています。この環境は、目標とするデプロイ先への論理的なマッピングだと考えてください。保護ルールを環境と関連づけることで、デプロイ前に承認が得られるようになります。

では、GitHub Action のワークフローを作りましょう。2 つの環境 (計画用とデプロイ用の 2 つ) を用意します。

name: 'Review and Deploy to EnvironmentA'
on: [push]

jobs:
  review:
    name: 'Terraform Plan'
    environment: environment_a_plan
    runs-on: ubuntu-latest

    steps:
      - name: 'Checkout'
        uses: actions/checkout@v2

      - name: 'Terraform Setup'
        uses: hashicorp/setup-terraform@v2
        with:
          cli_config_credentials_token: ${{ secrets.TF_API_TOKEN }}

      - name: 'Terraform Init'
        run: terraform init


      - name: 'Terraform Format'
        run: terraform fmt -check

      - name: 'Terraform Plan'
        run: terraform plan -input=false

  deploy:
    name: 'Terraform'
    environment: environment_a_deploy
    runs-on: ubuntu-latest
    needs: [review]

    steps:
      - name: 'Checkout'
        uses: actions/checkout@v2

      - name: 'Terraform Setup'
        uses: hashicorp/setup-terraform@v2
        with:
          cli_config_credentials_token: ${{ secrets.TF_API_TOKEN }}

      - name: 'Terraform Init'
        run: terraform init

      - name: 'Terraform Plan'
        run: terraform apply -auto-approve -input=false

ワークフローを実行する前に、GitHubのリポジトリに環境を作成し、保護ルールをenvironment_a_deployに関連付けることができます。つまり、本番デプロイの前にレビューが必要です。

もっと詳しく

HashiCorpのTerraform CloudをGitHubで使うための実践的なガイドで、始めるにあたっての一般的な推奨事項を確認してください。また、GitHubがどのようにTerraformを利用してミッションクリティカルな機能をより早く、より低コストで提供しているかをご覧ください。