Kubernetesを前提としたCI/CDパイプラインの具体例と、本番運用に必要なもの：コンテナベースのCI/CD本番事例大解剖（3）（2/2 ページ）

Kubernetes、コンテナ技術を活用したCI/CD基盤におけるサービス開発について、リクルートテクノロジーズの事例を基に解説する連載。今回は、インフラエンジニア視点からKubernetesを前提としたCI/CDの具体例について解説します。

[宮地克弥，リクルートテクノロジーズ]

パイプラインを組むときの注意点

• jobを適切なサイズに切り分ける

　Concourse CIのパイプラインにおける再実行の単位はジョブ単位です。1つのジョブ内で多くのことを実行させると、ジョブ間の移動時のオーバーヘッドは下がります。しかし、再実行が必要になったときに、また初めから実行されてしまいます。そのため、適切なサイズでジョブを切り分ける必要があります。

• マルチステージビルドを行う際は中間のイメージもプッシュする

　マルチステージで書かれたDockerfileでは、基本的に本番へのデプロイは最後のステージになることが多いと思います。デプロイすることだけを考慮すれば十分ですが、Concourse CIでは実行ごとにDockerをコンテナ内部で立ち上げる「docker-in-docker」の形式を採っているため、基本的に“状態”を持ちません。

　下記はマルチステージ化したDockerfileの例です。

FROM image as base
...
FROM image as app
...  

　また、Dockerfile全体で処理が重い部分は、前半のステージにくることが多いため、なるべく重い処理を行っているステージをプッシュし、実行時に読み込むようにすることでキャッシュを効かせることができます。

CIパイプラインの継続的改善

　連載第2回の「コンテナベースのCIパイプラインの課題」の項でも触れていますが、CI/CDツールは活用が進むにつれて、開発になくてはならないものになっていきます。それを象徴する言葉として、以前開発中に、筆者よりも経験豊富な開発者から「CI/CDツールは本番DBと同じくらいの安定性が必要」と言われたことがあります。

　CI/CDツールを安定稼働させていくために必要なものは、監視とモニタリングです。Concourse CIはメトリクスを提供しますが、それにより、外部からのプロセス監視では得られないような詳細な指標を入手できます。

Concourse CIで得られるメトリクスの例（公式サンプルから引用）

　メトリクスは「NewRelic」「Prometheus」「Datadog」など各種メジャーなモニタリングツール向けに提供されており、手軽に利用できるようになっています。

　「コンテナベースのCIパイプラインの課題」での教訓を元に、次の開発プロジェクトでConcourse CIを利用した際にはメトリクスを取得しました。結果、パイプラインの実行が遅くなったときは、「いつ時点から遅くなってきたのか」「起因はアプリケーションか、もしくはCI側の問題か」といった切り分けに大いに役立ちました。

　メトリクスの種類は多数あり、バージョンアップによって追加もされているので、運用しているCI/CDに合わせて選んだモニタリングをお勧めします。

Kubernetesを使う上で本番運用に必要なもの

　ここからは、本番運用に関して説明します。

　本番環境でKubernetesを運用するためには、準備しなければならないものが幾つか存在します。以下、準備すべきものを紹介します。

　ちなみに、Kubernetesにデプロイする上でのmanifestレベルの設定については、下記のスライドに詳しく書かれているのでご覧ください。

• 本番環境のKubernetesマニフェストに最低限必要な7のこと@Japan Container Days v18.12 / jkd1812-prd-manifests - Speaker Deck

ConfigMap、Secretを利用した環境設定

　「The Tweleve-Factor App」の「III. 設定」にも書かれている通り、環境間で異なるConfig設定は環境変数を通してアプリケーションに渡すよう推奨されています。そのためKubernetesでは、「ConfigMap」「Secret」という機能が提供されています。

　基本的には、機密情報ではないものをConfigMapで管理し、DBのパスワードやトークンなど外部に漏れるとセキュリティリスクのあるものをSecretとして管理することが推奨されています。

Secretは暗号化／復号する

　SecretではBase64でエンコードしているだけとなり、暗号化は行っていないので、「kubesec」「sops」を利用して暗号化し、CD上で復号する処理を加えてデプロイするのがお勧めです。

　またその際の方法としては、Git上でコード管理する以外にも、さまざまな方法があります。例えば「Vault」のようなクレデンシャル管理ツールや、Kubernetesに新たにcontrollerを追加し、Kubernetes内で暗号化済みデータを複合する「sealed-secrets」というツールを使うという選択肢もあります。

次回は、さまざまなプロジェクトにおける横断的な取り組みと今後について

　今回はインフラエンジニア視点でKubernetesを前提としたCI/CDの具体例を解説しました。

　これらの技術は実プロジェクトで運用され、大きな問題も生じることなく約1年が経過しています。しかし細かい課題はまだまだたくさんあるため、これからもさらなる発展を目指していきたいと考えています。

　今回紹介したツール群に関しては現在、過渡期であり、開発チームの規模やスキルによって向き不向きがあると思うので、いろいろなものに触れて最適なツールを探してみてください。

　最終回となる次回は、さまざまなプロジェクトにおいて横断で取り組み中、または今後取り組んでいこうとしている事柄を紹介します。

筆者紹介

宮地 克弥（みやざき かつや）

リクルートテクノロジーズ ITエンジニアリング本部 プロダクティビティエンジニアリング部 クラウドアーキテクトグループ所属

2017年、リクルートホールディングス（当時）に新卒入社。オンプレミスからクラウドまで、リクルートグループのさまざまな環境において新規プロダクトのインフラ開発およびエンハンス、インフラ運用に従事。