インフラエンジニアの視点で見る、DevOpsを実現するためのツールとは

はじめに

DevOpsを実現し、開発サイクルを高速に回すためには作業の自動化が重要です。開発者はコードを書き、ビルドし、テストが通ればメインラインにマージする、この一連の流れを1日に何度も繰り返します。ビルドやテストなどを自動化することで開発者はコードを書くことに集中できるようになり、作業の効率化が見込まれます。

また、自動でテストが実行されることで、時間のかかるテストをスキップすることやテスト結果を無視することができなくなり、メインラインにバグが混入することを防ぐことができます。作業の自動化を取り入れ、品質を維持する開発手法を「CI」と言います。

CIとは「Continuous Integration」の略で、日本語では「継続的インテグレーション」と訳されます。「継続的」に変更の入ったソースコードをテストし、バグのないコードをメインラインに「マージ」することを意味し、これを行うためのツールを「CIツール」と呼びます。

CIツールの選択肢

CIツールは大きく分けて2種類があります。オープンソースソフトウェアを自分でサーバーにインストールして運用する「セルフホステッド型」と、ソフトウェアの開発元がサービスとして提供している「SaaS(Software as a Service)」です。

セルフホステッドはソフトウェアを動かす環境を自分で選択できるため、OSやマシンタイプ、ジョブの実行時間に制限がないというメリットがある一方で、CIツールをインストールしたマシンのメンテナンスを自分で行う必要があり、手間が増えるというデメリットがあります。セルフホステッド型のソフトウェアとしては「Jenkins」や「Drone」などが有名です。

SaaSは、サービスの提供元がソフトウェアやサーバーをメンテナンスするため、利用者はサービスを使うことに集中できます。OSやマシンタイプは、そのサービスで用意されているものしか利用できず、OSやマシンタイプ、ジョブの実行時間で利用料金が決まっています。最近では無料プランでも利用できるサービスが増えてきており、選択できるOSやマシンタイプで要件を満たすようならSaaSを選択するのが楽でしょう。SaaSのCIツールとしては「CircleCI」や「GitHub Actions」、クラウドベンダがサービスとして提供している「AWS CodeBuild」や「GCP Cloud Build」などが選択肢に上がってきます。

CIツール以外に必要なツール

CIで自動化したい作業は、開発者が手作業で行なっていた「ビルド」と「テスト」です。ビルドやテストの実行順は開発言語仕様やテストの内容によって前後するため、ここでは「どのようなテストを実行すると良いのか」について触れていきます。

テスト/静的解析

ソフトウェアの品質を保つために単体テスト(ユニットテスト)を実行し、コミットされたコードがメインラインにマージ可能か確認します。このテストが通らなかった場合はコードの修正が必要であると言えます。

セキュリティを担保するためにコードやコンテナにセキュリティ診断ツールを実行しても良いでしょう。開発言語別にセキュリティ診断ツールが開発されていますし、SaaSとして提供されている診断ツールも存在します。コンテナはビルド時にチェックするものやレジストリで設定できるものもあるため、お使いの環境に合わせて設定します。

また、コードの品質を保つために静的コード解析やコードフォーマッターを実行して、コミットされたコードがコーディング規約に則っているか、インデントが正しいかなどをチェックするのも良いでしょう。

ビルド

ビルドでは、バイナリファイルやコンテナイメージを生成します。ビルドするソフトウェアが環境の状態に左右されないようにするため、クリーンな環境でビルドを行うのが望ましいとされています。クリーンな環境を用意するにはビルド専用のコンテナイメージを使うのが一般的です。

ツール選定時に考慮すべきこと

CIツールを選定する際はセルフホステッドかSaaSかを考えます。例えば、使用できるサービスに制限があり、外部サービスを利用できない場合はセルフホステッドのCIツールを利用します。しかし、CIは開発の要となるツールであり停止できないため、必然的に高可用性が求められます。もし、外部サービスの利用に制限がなければSaaSを利用するのが楽でしょう。

CIツールから利用するツールの選定も重要です。CIツールから利用するツールには、プラグインとしてインストールできるものやコンテナでパッケージングして配布されているものなどがあります。これらのツールで配布元がはっきりしている場合は利用を推奨できますが、配布元が不明なツールは悪意のあるコードが混入しているかも知れませんし、悪意がなかったとしても公式に追従してメンテナンスしてくれるとは限りません。極力公式が配布しているプラグインやコンテナイメージを使いましょう。

CI/CD環境の構築

CI/CDを導入するには、周辺ツールやサービスなどのセットアップが必要になります。ここでは「何を考慮してセットアップしていくと良いのか」を解説します。

アカウントの作成

CI/CDを使用する場合、ソースコードリポジトリと連携するのが一般的です。ソースコードリポジトリにも選択肢は多々ありますが、迷ったらGitHubアカウントを作成するのが無難です。GitHub Actionsはもちろんのこと、CircleCIもGitHubアカウントでログインできます。

CDまで利用予定であれば、成果物を置く場所も必要になるでしょう。コンテナであれば「GitHub Container Registry」や「Docker Hub」、クラウドのコンテナレジストリなどが使えます。

また、ソフトウェアを動かすためのプラットフォームも必要になります。外部サービスで運用できないなどの事情がなければクラウドで稼働させるのが一般的なので、クラウドのアカウントを用意しましょう。

ツール間の連携

ツール間を連携するには、何らかの方法でCIからクラウドや対象のサービスを操作できる必要があります。一般的な方法としては、クレデンシャルを発行してCIツールから利用するかOIDCを使用します。

OIDCはOpenID Connectの略で、一時的なアクセストークンを発行して外部のサービスと連携できます。クレデンシャルのような永続的な認証情報ではないため、例えアクセストークンが漏洩しても悪用を最小限に抑えられます。主要なパブリッククラウドやSaaSのCIツールはOIDCをサポートしているため、こちらを選択すると良いでしょう。

通知設定

自動化されたジョブの結果は、ステークホルダーに通知する必要があります。メールやチャットのほか、GitHubと連携していればプルリクエストの画面で通知できますが、全ての人にジョブの結果を通知する必要はありません。例えば、プロダクトオーナーにテスト結果を通知してもあまり意味はないですが、CDの結果を通知すると新しい機能が入ったことや、どのバージョンがデプロイされたのかを確認できます。必要な人に必要な通知を届けることが重要です。

実行インフラの構築

実行インフラとは、ソフトウェアを動作させる環境を意味します。ここでは、環境構築に使用するIaCや環境、デプロイ方法などを解説します。

IaCで構築を自動化する

IaCはInfrastructure as Codeの略で、インフラ構成をコードで管理し、構成管理ツールで構築を自動化します。

従来の手作業で構築を行なっていく際、作業者は手順書に従ってコマンドやWebコンソールから操作します。規模が大きくなるにつれ操作対象のサーバーやリソースが増えれば、その分手間やコスト、工数が増えていきます。手作業を繰り返していれば人的ミスの可能性も増えていくことでしょう。また、これらの操作をミスなく構築できるような手順書を管理・保守していくのも大変です。

このような問題を解決するのがIaCです。コードは何度実行しても同じ結果が得られ、冪等性が担保されます。操作対象が増えたとしても構築は構成管理ツールが自動で行うため人的ミスを削減できます。手順書には、構築の手順ではなくツールの実行方法や構成などを記載すると良いでしょう。ツールの実行方法はそうそう変わるものでもないため、手順書の保守コストも下げられます。

テスト環境と本番環境

サービスを運用していくには、開発中のソフトウェアを確認するためのテスト環境とソフトウェアを公開する本番環境が必要です。テスト環境は開発体制によって複数あるかもしれません。IaCを利用すれば環境を増やすことも簡単なので、1環境で窮屈な思いをするくらいなら必要な数を構築してしまうのが良いでしょう。

テスト環境と本番環境には必ず差分が生じます。例えば、インスタンスタイプやサーバー台数などを変更するためにIaCのコードを分けてしまうとコードの管理が大変になってしまうため、これらの情報は構成管理ツールの実行時に外部から渡せるようにしておくのが無難です。

また、テスト環境と本番環境ではリリースサイクルも違います。テスト環境ではソースコードがメインラインにマージされると即時に反映し、確認に移れると手間が少ないでしょう。デプロイまで自動化するContinuous Deploymentを採用するのも1つの手です。

一方、本番へのデプロイはプロダクトオーナーの確認が必要になるかもしれません。その場合はContinuous Deliveryを採用し、リリース準備までを自動化すると良いでしょう。

デプロイ方法

ソフトウェアのデプロイは「どこから」実行し「どのような手法」で実行されるかが重要です。どこからデプロイするかという点で、CI上からデプロイコマンドを実行する「CIOps」や、デプロイ後の構成を宣言的なコードで管理し、コードの変更をトリガーにKubernetes上からデプロイを実行する「GitOps」などが一般的になってきました。

CIOpsはCI上からそれぞれの環境にソフトウェアをデプロイするため、処理の流れがシンプルで分かりやすい点がメリットですが、一方でCI に強力な権限を持たせる必要がある点がデメリットになります。また、一般的にCIOpsはデプロイ後のアプリケーションについてはフォローしない場合が多く、デプロイの失敗に気付けない恐れもあります。

GitOpsは主にKubernetes環境で使用します。Kubernetes上にデプロイしたGitOpsツールがリポジトリの変更を検知し、対象のKubernetesにコンテナをデプロイします。外部サービスに強い権限を持たせる必要がなく、Gitリポジトリとデプロイ先の環境が一致するため、変更の追跡や監査が可能です。

次に、デプロイの手法について考えます。稼働しているサーバーのソフトウェアを直接置き換える「インプレースデプロイ」、稼働中の一部のサーバーを切り離してデプロイし、再びオンラインに戻す「ローリングデプロイ」、稼働中の一部のサーバーにのみ新しいソフトウェアをデプロイし、特定のユーザーにだけ利用してもらう「カナリアデプロイ」、稼働中のサーバー「Blue」と新しくソフトウェアをデプロイしたテスト環境の「Green」をLBのリクエスト転送先を切り替えて一気に公開する「ブルーグリーンデプロイ」などがあります。インプレースデプロイやローリングデプロイはデプロイ先のサーバーを選ぶだけなので仕組みは比較的単純ですが、一方でカナリアデプロイやブルーグリーンデプロイはLBの機能を使って実現しているため、ツールや仕組みが必要になってきます。

Kubernetesや、それに類似するコンテナオーケストレーションツールは、ツールが自動でデプロイするためデプロイの手法について考える必要がなくなってきました。しかし、サーバーに直接インストールして動かすソフトウェアは、まだ世の中に数多く存在しているのも事実です。規模やテスト方法などを考慮したデプロイ手法を選択しましょう。

おわりに

今回は、インフラエンジニアの視点から、DevOpsを実現するためのツールについて解説しました。DevOpsやCI/CDは開発効率を向上してくれるとても良いツールですが、品質を保証するためにはテストの内容が最も重要です。開発者はテストカバレッジを意識して、十分なテストを用意する必要があります。

次回は、開発者の立場からDevOpsで使うツールや考慮する点などを紹介します。