モダンなソフトウェア開発では、アプリケーションやサービス、環境の構成はプレーンテキストファイルの編集で行うことが一般的です。 Configuration as Code (CaC) はこの手法の進化版であり、システムにより構成ファイルを生成、保存、管理します。 開発に CaC を導入すれば、開発ライフサイクル全体の一貫性とトレーサビリティを確保しながら、アプリケーションと環境の構成管理を自動化できます。

DevOps の文脈では、CaC は、ソースリポジトリ内でコードやテストとあわせて構成ファイルも定義することを意味します。 つまり、新規デプロイのたびに手動でテキストファイルに変更を加えるのではなく、バージョン管理の一環としてプログラムで変更を加えて、ヒューマンエラーを防止するのです。 この手法なら、開発プロセスのセキュリティを強化し、自動化のレベルも高められます。

この記事では、CaC の概要、しくみ、DevOps チームにとっての価値について説明します。 また、CaC と GitOps との関係や CI/CD パイプラインへの適用方法、Infrastructure as Code との違いについても解説します。

目次

Configuration (構成) とは？

構成とは、システムの標準、属性、設定などの総称です。 開発者は構成ファイルを使用して、アプリケーションやインフラストラクチャ、継続的インテグレーションパイプラインの設定およびパラメーターを定義します。

アプリケーションの構成

アプリケーションの構成とは、アプリケーションの動作を定義する一連の設定のことです。 これらの設定によって、アプリケーションの動作や機能を変更できます。 モダンなプログラムにはクラウドでホストされた分散コンポーネントが数多く組み込まれており、複数のリージョンまたは仮想マシンにホストされたコンテナで実行されます。 コンポーネントごとの設定がばらばらだと、エラーの解決時やデプロイ中に事態が複雑になってしまうリスクがあります。 そのため、アプリケーションの構成として、すべてのアプリケーション設定を安全な場所で一元的に保存および管理するのです。

インフラストラクチャの構成

インフラストラクチャの構成とは、アプリケーションをサポートするために必要な物理リソースと論理リソースを定義および設定するプロセスのことです。 ハードウェアとソフトウェアの選定から設置やインストール、利用するアプリケーションに合わせた設定など、アプリケーションを使ううえで必要な作業がすべて含まれます。

インフラストラクチャの構成は、パフォーマンスから信頼性、スケーラビリティにいたるまで、アプリケーションの開発に不可欠なあらゆる要素を左右します。

パイプラインの構成

CI/CD パイプラインとは、コンテナ化、ソース管理、モニタリング、設定管理、ビルドなどを行う各種ツールを包括した概念です。 これらのツールにより、アプリケーションとインフラストラクチャのビルド、テスト、デプロイのプロセスを自動化します。 パイプラインの構成とは、自動化したプロセスの実行方法を示した一連の指示のことです。そのため、アプリケーションとインフラストラクチャの構成に影響を受けます。 これらの指示は、YAML、JSON、XML などの形式のパイプライン設定ファイルに入力します。

Configuration as Code とは？

通常の手法では、アプリケーションのコードはバージョン管理用のリポジトリにコミットします。 設定情報はこのリポジトリ外に保管し、開発者が手動で各デプロイの構成を作成、カスタマイズすることになります。

CaC はこれとは異なり、リソースのプロビジョニングや環境の設定など、構成にかかわる設定を実行可能なコードで定義します。 つまり、構成をコードと同じように扱い (バージョン管理での設定の保持を含む)、コードと構成ファイルを一緒に管理するということです。

CaC は CI/CD パイプラインと相性が良く、インフラストラクチャのメンテナンス、プロビジョニング、ソフトウェアの設定といったさまざまな側面やタスクを自動化できます。 開発者にとっては、こうした自動化により、エラーが発生しやすく時間のかかる手動タスクの数を減らせるというメリットがあります。

Infrastructure as Code と Configuration as Code

Infrastructure as Code (IaC) は、インフラストラクチャをソフトウェアのように扱う方法です。 インフラストラクチャをソフトウェアスタック内のアプリケーションのひとつとして扱うので、インフラストラクチャの構造をコードとして記述できます。 記述したファイルのテストが完了したら、そのファイルにもとづいてインフラストラクチャを自動的に作成または破棄します。

IaC と CaC は、ソフトウェアのプロビジョニングと構成を自動化する点は同じですが、その方法はそれぞれ異なります。

IaC では、インフラストラクチャをコードでモデル化して、マシンによりインフラストラクチャを管理します。 つまり、システムの設定や構成内容を記述したスクリプトを作成して、システムのデプロイを行います。 一般的な IaC のユースケースとしては、物理サーバーおよび仮想サーバーのデプロイと構成の自動化が挙げられます。

CaC では、アプリケーションの構成をモデル化してデプロイします。 新しいソフトウェア構成をプッシュすると、アプリケーションの構成全体が更新されます。手動で構成を変更する必要はありません。 CaC は、コンテナやマイクロサービスなど、あらゆる種類のアプリケーションに使用できます。

IaC、CI/CD、マージリクエストは、GitOps の中核をなす手法です。 GitOps とは、信頼できる唯一の情報源として Git を使用して宣言型のインフラストラクチャを管理する方法です。 GitOps では、インフラストラクチャの変更をソフトウェアのインテグレーションおよびデリバリープロセスのコアコンポーネントとして扱います。そのため、これらを同じ CI/CD パイプラインに統合できます。 この統合によって、構成を変更する手間を削減できます。 開発者がやるべきことは、構成の変更をコードで作成し、ソース管理リポジトリにプッシュすることだけです。 CI/CD ツールによってリポジトリ内でコードがテストされた後、基盤インフラストラクチャに変更が適用されます。

DevOps に Configuration as Code を取り入れるメリットは？

Configuration as Code には、開発チームにとってさまざまなメリットがあります。

  • 構成ミスのリスクの軽減
  • 開発プロセスの標準化
  • アプリとインフラストラクチャの変更に対する可視性と制御の向上

構成ミスによる脆弱性の発生を回避できる

オープンソースソフトウェアのセキュリティインシデントの原因は、往々にして構成ミスです。 この問題は、数千から数百万ものインスタンスをきわめて正確に構成する必要がある大規模なクラウド環境で特に顕著です。 CaC で自動化を実現し、一貫性とシンプルさを促進することで、構成ミスを抑えられます。

日常業務のプロセスを自動化することで、ヒューマンエラーを減らせるだけでなく、開発チームがより価値のあるタスクに時間をかけられるようになります。 また、開発、テスト、本番の各環境で全体の構成を簡単に変更できるようになります。 CaC によって、環境を問わず同じやり方でアプリケーションをデプロイできるという安心感が生まれるのです。

構成を一元的に保管するので、変更がインフラストラクチャ環境やアプリケーション環境の他の領域にもたらす影響を簡単に確認できます。 これにより、変更によって他のサーバーやネットワーク上で問題が発生する事態を防ぎやすくなります。 すべてをコードとして記述し自動化するので、明示的な指示ですべてを制御できます。これにより、変更をデプロイする際にエラーが発生するリスクを大幅に抑えられます。

パイプラインの標準化を促進できる

CaC では、あらゆる環境で同じスクリプトを実行するパイプラインを作成できます。 これにより、どの環境でも同じバージョンのアプリケーションを確実に実行することができます。 また、構成をソースコードとして記述するので、開発のベストプラクティスを実践しやすくなります。 セキュリティスキャン、コード品質分析、パラメーター化など、さまざまなベストプラクティスに合わせて構成を最適化できるのです。

マイクロサービスを採用しているのであれば、CaC により似通ったビルドプランがないか検証できます。 プロセスの標準化は、マイクロサービスの連携の確保にもつながります。 さらに、メインブランチへのコミットの前に、構成ファイルが規定の標準に従っているかどうかを確認およびテストすることもできます。

コンプライアンスと変更管理を強化できる

CaC により、構成アイテムと関連ポリシーの間のトレーサビリティを確保できます。 本番環境にデプロイする構成アイテムが規制に準拠していなければならない場合、開発者にそのプロセスを文書化し、状況を証明するよう義務付けられるからです。 DevOps の現場で CaC のトレーサビリティを活用することで、システムのセキュリティと安定性を確保するためのポリシーを作成し、コンプライアンスと変更管理を強化できます。

CaC が持つ監視とコンプライアンスを強化できるという特徴は、ユーザーにとって大きなメリットがあります。 構成のアーティファクトを保存するリポジトリが一元化されるので、変更点ごとに監査証跡が得られます。 そのため、変更の実行者、内容、変更対象、実施時期を特定しやすくなります。 バージョン管理システムなどの追跡メカニズムによって変更を追跡、監査できるため、問題の発生時には、(偶発的か故意かを問わず) 問題を発生させた当事者まで辿ることが可能になります。

また、コンプライアンスの標準を構成ファイル内で定義することで、それらの遵守を徹底できます。 構成ファイルの変更は、ユーザーまたは管理者が明示的にオーバーライドする場合を除き、すべての環境に適用されます。 そのため、アプリケーションに随時加えられる変更も、次の方法で簡単に管理できます。

  • 構成コードにインフラストラクチャの状態を厳密に定義する
  • 変更対象のアプリケーションの構成ファイルに加えられたすべての変更を監査する

これら 2 つのプロセスにより、アプリケーションに加えられたすべての変更をまとめた監査可能なレコードを作成できます。 アプリケーションの構成ファイルのミスや問題を継続的に特定することで、セキュリティ標準への適合を維持し、アプリケーションを適切に機能させ続けることができます。

まとめ

Configuration as Code を開発プロセスに導入することで、大きなメリットが得られます。 環境全体に構成を適用するプロセスが自動化されるため、更新の適用が容易になり、あらゆる要素の連携も確保できます。 また、リポジトリが一元化されるので、変更を管理、追跡しやすくなります。 さらに Configuration as Code は、コードの開発とデプロイを効率化すると同時に、複雑なインフラストラクチャやパイプラインも管理できる強力なツールです。 このツールを利用することで、デプロイの信頼性を落とさずに開発を高速化するうえで不可欠な、可視性と管理性を手に入れられます。

なお、CircleCI なら、パイプライン、アプリケーション、インフラストラクチャを管理する CaC アプローチの実装を簡単に行えます。 ぜひ、CircleCI の無料プランに登録して CaC を始めましょう。開発プロセスの安定性を高め、セキュリティとコンプライアンスも強化できます。