【ハンズオン】GitLabおよびAnsibleによるインフラCI/CD ~Step1.導入目的~ -

1. はじめに

アプリケーション開発におけるCI/CDは広く一般的に活用されていますが、インフラレイヤにおけるCI/CDについては、まだ導入が進んでいない現場も多いのが実情です。本シリーズでは、GitLabとAnsibleを活用したインフラCI/CDの導入例を、ハンズオン形式でご紹介します。ぜひ参考にしていただければ幸いです。まずはStep1としてインフラCI/CDの導入目的を説明します。

2. インフラCI/CDが必要な背景

　従来のメインフレームやオンプレミス環境での業務経験を持つインフラエンジニアの中には、インフラCI/CDの必要性を十分に理解できず、導入に懐疑的な意見を持つ方も少なくありません。こうした状況の中でインフラCI/CDを推進していくには、今後のITシステムの変化を見据えた導入目的を明確に伝え、関係者の理解を得ることが重要です。ここでは、インフラCI/CDが求められる背景について解説します。

・インフラ構築・運用に人手を割けない
　今後もITシステムへの需要は拡大すると予測されており、それに伴ってサーバなどのインフラ機器の台数も増加していくと見込まれます。仮にインフラエンジニアの数も同様に増加すれば、従来の運用方法でも大きな支障はないかもしれませんが、実際にはそうはなっていません。
　その主な理由の一つが、インフラエンジニアの慢性的な人材不足です。特に日本では、海外人材の活用が進んでおらず、国内でインフラ構築・運用が可能な人材の確保が難しい状況にあります。今後、急速に人材が増えることも期待しにくいため、既存の人員でより効率的にインフラを運用する仕組みが求められています。
　また、ITエンジニアのリソースをよりビジネス寄りの領域へシフトさせたいという企業のニーズも高まっています。近年、ITシステムは単なる業務効率化のためのツールではなく、企業の売上向上に直結する戦略的な資産と位置付けられています。そのため、直接的なビジネス価値を生みにくいインフラ領域への投資を抑制しようとする傾向が強まっているのです。　
　こうした背景を踏まえると、今後は限られた人手で効率的にインフラの構築・運用を行う必要があり、その実現手段としてインフラCI/CDの導入が注目されているのです。

・市場の変化に柔軟に対応できるシステム構築・運用が求められる
　従来のシステム開発においては、「システムは構築したら終わり」とされ、その後は極力変更を加えず、安定運用を維持するという考え方が一般的でした。実際、特別な事情がない限りパッチの適用やバージョンアップを避ける運用を続けている現場も一定数存在しています。
　しかしながら、市場や顧客ニーズの変化が激しい現代においては、こうした従来の考え方は次第に通用しなくなってきています。サービスを迅速に市場へ提供し、ユーザーからのフィードバックを受けて柔軟にシステムを改修する動きが求められています。
　このような状況に対応するためには、インフラ構築についても従来のような長期間に及ぶ対応ではなく、短いサイクルで構築・試験・リリースを繰り返す対応が必要となっています。そこで効果的なのがインフラCI/CDとなります。

3. インフラCI/CDとは

　そもそも、インフラCI/CDとは何かについてご説明します。インフラ領域におけるCI/CDの解釈は人によって異なりますので、あくまで私の理解を説明させていただきます。
　まず、CIとは Continuous Integration（継続的インテグレーション）の略で、構成定義ファイル（自動化コードや設定ファイルなど）に対して変更を加えた後、それを既存の環境に反映・試験し、正常に動作するかを確認するプロセスを指します。
　次に、CDは Continuous Delivery（継続的デリバリー）の略で、動作確認が完了した構成定義ファイルを実際の環境に反映する工程を指します。
　アプリケーション開発におけるCI/CDと異なり、インフラ構成定義ファイルは実際にデバッグ環境へ反映して初めて試験が可能になるため、CIとCDの工程が明確に分かれていないケースが多くあります。そのため、CIの中にCDの要素も含まれているようなイメージで捉えています。

4. インフラCI/CDのプロセス

インフラCI/CDのプロセスをフロー図にしてみました。ただし、このプロセスは現場によって細かい点が異なる場合がありますので、あくまで一例としてご理解ください。ご自身の現場に適したプロセスをご検討いただければと思います。

それぞれのプロセスについてご説明します。

①トリガー
アプリ開発グループからの要件追加や、トラブルを契機とした不具合対応をトリガーとして、CI/CDプロセスが開始されます。GitHubのチケット機能を使って、明示的に管理しているプロジェクトもありますので、必要に応じて導入してみて下さい。

②設計
有識者間で修正方針を検討します。検討した内容を設計書やパラメータシートに落とし込み、レビューを実施します。

③環境定義の修正（デバッグ向け）
AnsibleでいうPlaybookのような自動化コードや、環境に反映する設定ファイルなどの「環境定義」を修正します。この際、Gitなどのバージョン管理システム（VCS）で管理されている原本をコピーして修正を行い、完了後は開発ブランチに反映します。

④環境定義の反映／試験（デバッグ向け）
開発ブランチに反映した環境定義をデバッグ環境に適用し、試験を実施します。変更箇所のアップグレード観点だけでなく、ディグレード観点でも試験を行います。

⑤レビュー（デバッグ向け）
環境定義および試験結果を有識者がレビューします。
GitHubなどのVCSツールを使用している場合は、変更点を視覚的に確認できるため、ぜひ活用してください。試験結果がOKであれば次のプロセスに進みますが、NGだった場合は原因に応じて前のプロセスに戻ってやり直します。

⑥環境定義マージ（デバッグ向け）
レビューがOKであれば、環境定義をVCSのメインブランチにマージします。責任者のみにマージ権限を付与することで、担当者が勝手に変更することを防止できます。

⑦環境定義の差分修正（本番向け）
デバッグ環境に適用した環境定義をそのまま本番環境に適用できるのが理想ですが、どうしても差分が出る場合があります。その際は、本番環境向けに環境定義を修正する必要があります。

⑧環境定義のレビュー（本番向け）
本番適用向けの定義については、有識者によるレビューをこの時点で実施してください。この定義はそのまま本番環境に適用されるため、デバッグ環境のように誤っていたらやり直すということは許されませんので。

⑨環境定義マージ（本番向け）
レビューがOKであれば、責任者が承認を行いメインブランチにマージします。

⑩環境定義反映/試験（本番向け）
本番環境に適用を行い、可能な範囲で試験も実施します。

⑪試験結果のレビュー（本番向け）
本番環境における試験結果を速やかに確認し、問題がなければ完了となります。

いかがでしたでしょうか。細かな違いはあるかもしれませんが、インフラCI/CDは概ねこのようなプロセスで運用していくものと思います。従来の環境反映プロセスよりも煩雑になるケースが多いため、プロジェクトメンバー全体の理解を深めるためにもこのような運用プロセスを文書化し、明確に定義しておくことを推奨します。

まとめ

インフラCI/CDに関する概要説明は以上となります。Step2以降で実際にGitlabやAnsibleによる具体的ンな手順や運用方法についてハンズオン形式で紹介していきますので、そちらもぜひ参照してもらえればと思います。
【ハンズオン】GitLabおよびAnsibleによるインフラCI/CD ~Step2.環境構築~
【ハンズオン】GitLabおよびAnsibleによるインフラCI/CD ~Step3.Playbook適用~