ページの先頭です

ページ内を移動するためのリンク
本文へ (c)

ここから本文です。

コンテナ技術によって実現する CI/CD パイプライン

ライター:千葉 豪
2009年ネットワンシステムズに入社し、IaaS(Infrastructure as a Service) を始めとしたクラウド基盤技術および管理製品を担当。現在はコンテナ技術を中心とした社内開発基盤・解析基盤の構築・運用や関連した自動化技術、監視製品などの技術検証を行っている。

目次

これまでコンテナ技術に関連する要素技術やオーケストレーションツールである Kubernetes を対象に「データ永続化」、「ネットワーク」といったトピックを取り上げて説明してきました。本記事ではこれらの技術・ツールがどのようなシーンで利用されるかその一例を紹介したいと思います。

コンテナ技術の特性

過去の関連するブログではコンテナの特性に関して触れられてきましたが改めてどのような特性があるのかを振り返ってみたいと思います。

  • 可搬性
    コンテナイメージのサイズが数百MBと軽量なためあらゆる環境下に展開しやすい
  • 俊敏性
    多くのコンテナイメージはライブラリ/ミドルウェアとアプリケーションのみで構成されるため、OSのブートプロセスなどのオーバーヘッドが無く高速に起動する
  • 再現性
    コンテナイメージに実際に動作するコードやミドルウェア、関連するライブラリ群をパッケージ化することでコード間の依存関係を含めて再現することが可能

このように従来のベアメタルサーバーやハイパーバイザー型仮想化技術と比べるとOS領域が含まれず可搬性に優れるためオンプレミス・クラウドを問わず様々な環境に高頻度で展開する際にコンテナのメリットを最大限に生かせると言えます。

Continues Integration / Continues Deployment, Delivery(CI/CD)

開発部門ではより早く市場にサービス・製品を提供するため従来のウォーターフォールモデルによる開発ではなくアジャイル・スクラムによる開発手法がよくとられています。そのため開発のサイクル(アジャイル開発ではスプリント)はウォーターフォールモデルが数カ月なのに対し1,2週間と短く、どれだけ早いタイミングでテストやビルドを実施し製品品質を維持するかが重要となります。その際基盤で必要となるのが Continues Integration/Continues Delivery, Deployment (継続的なインテグレーション/継続的なデリバリー,デプロイ)と呼ばれる手法になります。CI ではコードのビルドやユニットテストなどが行われその時点での成果物が正常に動作するかをチェックし必要に応じパッケージ化が実施されます。また、 CD プロセスではシステムとしての e2e(End-to-End)テストや外部システムとの連携テスト、必要に応じたステージング環境などへのデプロイを継続的にかつ自動で行うことを目的としています。

このようにCI/CDにより従来人手で行われてきたテストプロセスや環境へのデプロイメントプロセスを自動化させることでサービス・製品を常にリリース可能な状態に維持し開発者は本来のビジネスロジックの開発に集中することができ、結果として全体のコストを下げることにも繋がります。

CI/CDを実現するために、従来のハイパーバイザー型仮想化技術のVMを利用することもできますが、各CIプロセスにおけるコードの依存関係やビルド後のクリーンアップ処理などに注意が必要です。このように常に環境をクリーンに保ちつつテストを行いたい場合、コンテナを利用することで瞬時にクリーンなテスト環境の構築が可能となり、高速なCIプロセスに追従することができます。また、テスト完了後はコンテナ自体を破棄することでクリーンアップが不要となるといったメリットも享受できます。

GitOps

近年では、GitOps(バージョン管理ツールである Git を活用した運用手法) といった言葉が浸透してきており、従来開発部門において培われてきた文化・手法をインフラの管理に活用しようという流れがあります。GitOps という言葉自体はWeaveworks 社が 2017年に提唱した言葉であり彼らのブログでも語られています。

前述した CI/CD プロセスの多くは1つのコードリポジトリ内でソースコードと Kubernetes のマニフェストファイルなどを管理します。そのためちょっとしたマニフェストファイルの変更でデプロイ環境が動かなくなってしまった場合、複雑なパイプラインをトレースして何が原因だったか、ロールバックするべきバージョンはどれなのか調査が必要になるケースがあります。また、同時にいくつもの CI ジョブが走った場合、最終的にデプロイ環境に作られるシステムはどのバージョンなのか保証することは容易ではないでしょう。

そこでGitOps ではこれらのアプリケーションコードとインフラコードを個別にバージョン管理し、アプリケーションとインフラの CI/CDプロセスを明確に分離し互いの影響を受けないようにするとともに、Kubernetes のようなコンテナインフラをバージョン管理しようというコンセプトです。インフラ運用者であるオペレーターもインフラの構成をインフラコードとしてGitによりバージョン管理することで、オペレーターはkubectl CLIを利用してインタラクティブにインフラの構成変更を行うことはなくなります。

まとめ

本記事ではコンテナ技術の活用例として開発における CI/CD, GitOps といった手法・コンセプトを紹介させていただきました。コンテナの持つ可搬性・俊敏性・再現性といった特徴を開発環境に適用することで開発環境・ステージング環境といった異なる環境下に容易にシステムを展開することができる、コードの変更とインフラの変更を紐づけ問題点の早期発見につながる、軽量なコンテナイメージを利用することで常にクリーンな環境を用意できるといった様々なメリットを享受できます。また、組織としてこのような仕組みを検討することでこれまで人手で実施していた構築作業の標準化、ひいてはシステム化による作業時間の低減なども期待できるかもしれません。

※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。

RECOMMEND