2021/04/05
次世代基盤第二技術部　第一技術室

スピードと柔軟性！そのアプローチに必要なパーツをつなぐ技術

昨今、継続的インテグレーション/継続的デリバリ（以下 CI/CD）という言葉を聞く機会が増えた気がします。大手クラウドベンダーのCI/CDツールが整備され、国内の企業においても事例が少しずつ増えてきている状況です。CI/CD実践の中心となるコンテナ技術の普及も要因の一つに挙げられます 。

スピードを上げるための技術の中心はコンテナです。しかしその効果を最大化するには開発手法の取り込み、DevOps文化やマイクロサービス、テスト駆動など、様々なパーツを組み合わせる柔軟性が必要になります。そしてコンテナなどのITインフラ技術の適切な活用により、スピード感のあるこれからのアプリケーション運用が可能となります。最適な組み合わせには「技術」、「文化」どちらが欠けても成立しません。

本コラムではニューノーマル時代に必要となる「技術」と「文化」について2回に分けてお話します。今回は「技術」をテーマにCI/CDを取り上げます。CI/CDは必要なパーツをつなぎ開発から運用までのライフサイクルを自動化する、今まさに注目を集めている技術です。コンテナを中心にCI/CDをどう進めていくか？コラムを通じて一緒に考えていきたいと思います。

CI/CDとは

CI/CDとはContinuous Integration※1 /Continuous Delivery※2 の略です。従来、人が行ってきた作業プロセスをリリース可能な状態または、本番リリースまで全て自動化する手法です。”継続的”という言葉が示すとおり、初回もその後も同じプロセスを繰り返し、開発から運用までのサイクルを継続することが重要となります。アプリケーション開発を中心に拡がった技術ですが、ITインフラストラクチャのデリバリもCI/CDで実現することが出来ます。

パブリック・プライベート両クラウドで様々なツールが利用出来ます。三井情報ではパブリッククラウドはAzure DevOps、プライベートクラウドではGitLab Runnerを利用しています。元々はインフラ構築を自動化する構成管理ツールのコード品質の維持に利用していました。現在はKubernetes運用にも活用を拡げています。いずれもバージョン管理システムで管理しているコードの改変をトリガーに、自動化のパイプライン ※3が動き出します。端的に言うと「ある自動化の仕組みが、別の自動化をキックする」オーケストレータをイメージしていただけると分かりやすいかもしれません。
 

■CI/CDの概要イメージ

また、クラウドネイティブ化を実現するステップ案としてCNCF ※4ではトレイルマップが提唱されています。企業によって必要とする技術が異なるため、必ずしも順序通りに進める必要はありません。しかしステップの2番目に出てくるキーテクノロジーであり、活用の優先度が高い技術だと言えます。

※1 CIの主な目的は継続的なビルド、テストによりコードに潜むバグを早期に発見して対処すること。

※2 CDのDはDeliveryとDeploymentという意見もあり正式には定まっていない。一般的にDeliveryはリリース直前の状態。デプロイは本番リリースまでを自動化することを指す。

※3 継続的にソフトウェアを提供するために実行する必要のある一連のステップ。

※4 CNCFはCloudNativeComputingFoundationの略で、クラウドネイティブのエコシステムを推進する団体。
　　URL：https://github.com/cncf/trailmap

CI/CDを使うことのメリット

CI/CDには一定の基準を満たすプロセスを通過することで、バグの早期発見、継続的な改善を行えるなどの様々なメリットがあります。その中で私たちは特に以下の3つのメリットがあると考えています。

① 品質：

人為的ミスを無くしコードの規約やテストの実践など、常に一定品質のプロセスを図ることが出来ます。そして不具合の早期検知、改修を繰り返せる再現性。継続的に機能や性能を更新し続けることに役立てるメリットがあります。

② 時間：

ビルド、テストからデプロイまでの作業プロセスの時間を短縮します。そしてテスト異常や脆弱性を含む不具合の早期発見により、改修に掛かるコストを減少させる効果が期待できます。一貫性のあるプロセスを繰り返し実施でき、リリース作業のリードタイムを短縮するスピードは圧倒的なメリットとなります。

③ マインド：

CI/CDのサイクルを取り込むことを意識することで、自動化など人間が頑張らない方向への改善や技術の活用に関する視野がひろがります。また手動時には実践していなかったテストや、属人化していたテストを組み込むことを考える様になりました。「実はこの作業って自動化出来るよね」「この作業は並列で出来るよね」「この作業を承認のために止める必要あるの？一気通貫でよくない？」などチームのマインドが変わりつつあると感じています。

CI/CDの始め方とステップ

CI/CDはCNCFにあるContinous Integration & Delivery※5にある一覧のツールだけでなく、その他にも多くのツールが提供されています。GUIの有り/無し、使い勝手、コンセプト、完成度、親和性、検索にヒットする情報の過多など比較すべき点はあるかと思います。迷うと思います。しかし誤解を恐れず書くと、機能的に大きな差はあまり無いと考えています。ネット上には一般的なツールを比較してくれているサイトもあります。大半のツールはYAMLファイルに記載したルールで実行出来ます。比較に時間を費やすなら、トライアンドエラーで進め、CI/CD理解を深めることが重要です。情報量が多いツールから始めるのも一つの始め方だと思います。

では、CI/CDツールを決め環境を準備したとして、その後のステップは

1. ステージとジョブの概念を把握する
2. パイプライン構成を組み立てる
3. 実行条件を決める
4. YAMLでパイプラインを記述して動かす

の流れで感覚的に理解していきます。ツールによって呼び名や階層が異なるかもしれませので、GitLabの用語を用いて説明します。


①ステージとジョブの概念を把握する

最小単位となるジョブは、ステージに所属する構造で管理されます。そしてステージ内の各ジョブは独立した環境で、つまり、並列で実行されます。これらのジョブ、ステージを連結した、提供に必要な一連の処理ステップをパイプラインとして表現します。先行・後続の順序性を持たせたい、または同時に実行し早く終わらせたいなどのリクエストに対応することが可能です。またジョブは、GITで管理するソースコードを常にダウンロードする仕組みとなっています。
 

■CI/CDパイプラインイメージ

②パイプライン構成を組み立てる

開発やインストール、設定を実施するために利用するコンテナイメージ。それと連携して外部テストを実行するコンテナイメージなど、関係性を把握して構成を組み立てる必要があります。これらの関係性はステージやジョブごとに組み立てることが出来ます。構成を理解すれば、このジョブやステージではどのコンテナイメージを利用してどういった処理を行っているか、迷うことは無くなります。

③実行条件を決める

パイプライン全体、ジョブやステージをどんな条件で動かすかを検討します。例えば特定のブランチ ※6 でコードが改修された場合にパイプラインを動かすとか、ディレクトリ配下の特定ファイルが更新されたら動かす、CIは動かすがCDは動かさないなどです。当然テストを通過していないものをデリバリやデプロイすることを避ける実行条件は重要となります。

④YAMLでパイプラインを記述して動かす

ここまで把握出来れば後はYAMLでパイプラインを記述するだけです。各ツールのリファレンスマニュアルに従ってYAMLファイルを記述します。一例ですがAzure DevOpsそしてGitLab Runnerの記述例で、一般的に使いそうなパラメータを比較してみます。

■Azure DevOpsとGitLab Runnerのパラメータの比較イメージ

いかがでしょう。指定方法は異なりますが、大きな違いは無いことが読み取れるかと思います。あとは皆さんのコードをバージョン管理のGITへアップロードするだけです。

※5 CNCF Cloud Native Interactive Landscape （CMCFウェブサイト）CNCFのContinuous Integration & Delivery：https://landscape.cncf.io/category=continuous-integration-delivery&format=card-mode&grouping=category

※6 ブランチとはプログラムの修正や機能の追加を行う際にソースコード本体に影響を与えないGITの仕組み

私たち三井情報の使い方

私たちはコンテナを含むサーバプラットフォームを提供しています。インフラ領域にもCI/CD利用を拡げ、ハードウェアにまつわる構築の品質維持、効率化にも活用しています。ここではその例をご紹介します。Infrastructure as Code（以下、IaC）の概念のもと、ハイパーコンバージドインフラであるデルテクノロジーズ社製のVxRailの初期構築を効率化しています。プロセスとしては以下となります。

1． パラメータシートの読み取りとプログラムへのコード変換
2． 疑似の顧客環境の構築
3． 構築および試験
4． 試験結果の生成

これらのプロセスを自動化するため、構築に必要となる疑似環境ネットワークの準備、自動化管理のWebアプリケーション、正常性とエビデンスを取るためのテスト環境をコンテナ化しています。そのため、いつでも・誰でも・何度でも簡単に構築作業を実践出来るようにしています。
 
■利用概略とCI/CDインフライメージ

そして、この環境群をいつでも正常な状態で利用するためにCI/CDを利用しています。自動化コードが正しく動作することを常に確認します。そのために疑似環境ネットワークやテスト環境のコンテナ構築をCI/CDで、プログラム品質テストをCIで回しています。
 

■IaCのCI/CDステージと実践するプロジェクトイメージ

さいごに

今回、「技術」のお話としてコンテナ運用で必要となるCI/CDの概要について説明しました。市場への新規投入や課題解決のスピードが必要な方には、有用な技術かと思います。また、コロナ禍によって在宅からの開発や運用を強いられた経験から、リモートでも開発・運用のサイクルをまわすDevOpsそしてCI/CDの需要は今後益々高まっていくと考えられます。皆さまの“ニューノーマル”時代のインフラ運用検討の一助になれば幸いです。

次回は「文化」について取り上げてお話したいと思います。

関連ページ

おすすめコラム：

次世代ストレージのあるべき姿とは!?

関連ソリューション：

VMware TKGI on VxRailパッケージ