.
本稿ではIBMがIBM Cloud上にホスティングしているエンタープライズ向けOpenShiftのマネージドサービスである「RedHat OpenShift on IBM Cloud」（以下、OpenShift on IBM Cloud）を使って、長期利用を想定して「本気の開発テスト環境」を構成する際に直面する悩みや疑問、その対応方法をお伝えする。
後編は中上級者向けに、「運用時の悩み：着実なデプロイ運用」について解説する。
.
KubernetesやOpenShiftのコンテナ環境を無事構築し、アプリケーションを運用する段階で直面するのが、アプリケーションのデプロイに関する悩みである。
コンテナのデプロイに関して注意すべきは、Kubernetesが従来の環境の「命令型」のコンセプトではなく、「宣言型」のコンセプトを備えている点である。
たとえば、Kubernetesに新しい構成の適用やアプリケーションのコンテナイメージのデプロイを行う場合、「kubernetes apply」コマンドを使用できる。
-fオプションで構成を定義したマニフェスト・ファイルを指定する（kubernetes apply -f deployment.yaml）。
従来型の開発に慣れている場合は、このようなコマンドを実行すればオプションで指定したファイルに含まれる構成が反映されると考えるかもしれない。
.
トラブル1
デプロイ後にアプリケーションが最新にならない
あるシステムで最新のコードをビルドし、「kubernetes apply」コマンドでデプロイを実行したが、起動アプリケーションの挙動が最新版に見えない問題が発生した。
確認したところ、最新のコンテナイメージをデプロイするために上記のコマンドを実行していたが、実際に最新のコードを含むコンテナイメージはデプロイされていなかった。なぜそのような問題が発生したのだろうか。
その原因は、Kubernetesの「宣言型」コンセプトによるものだった。
デプロイメントの構成を定義したマニフェスト・ファイル内では、コンテナイメージのバージョンを「image: bar/foo: latest」（イメージbar/fooのlatestタグの意）と指定しており、アプリケーションをビルドするたびに、新しいイメージを同じタグ名で上書きしてコンテナレジストリに格納していた。
その結果、コンテナイメージが上書きされても、マニフェスト・ファイル自体の更新は必要なかった。ところが宣言型のコンセプトをもつKubernetesは、マニフェストそのものに差分がないと、「現状」と「あるべき姿」の間にギャップはないと見なし、イメージのデプロイを行わない。
その結果、kubectl applyコマンドを実行したにも関わらず、デプロイが行われず、最新版のアプリケーションが起動されなかったのだ。
.
トラブル2
リソースを再作成してもアプリケーションが最新にならない
前述した問題の対応として、kubectl applyコマンドで最新の構成を適用するのではなく、リソースをいったん削除するkubectl deleteと、再度作成するkubectl createコマンドを使用するように変更した。
これでいったん問題は解決したように見えた。しかし、再びアプリケーションの最新版がデプロイされない問題が発生した。
今度の原因は、マニフェスト内でのイメージ名の指定を「image: bar/foo: dev」イメージbar/fooのdevタグの意）へ変えていたことが原因だった。
Kubernetesがコンテナイメージを取得して配置する設定は、デフォルトではlatestタグとそれ以外のタグで挙動が異なる。
イメージのタグ名が「latest」である場合、デフォルトでは、マニフェストの変更があれば、アプリケーションを稼働させるポッドの起動時に毎回新しいイメージが取得される（imagePullPolicyパラメータがAlways）。
しかし「latest」以外のタグの場合は、指定されたタグ名のイメージがKubernetesノード上に存在してない場合のみ、イメージを取得する挙動（imagePullPolicyパラメータがIfNotPresent）となる。
つまりノードの状態によっては、最新版のアプリケーションが起動するとは限らない。マニフェストの適用からアプリケーションの更新までの流れをまとめたのが、図表1となる。
.
.
この問題には、CI／CDパイプラインツールであるJenkinsに2つの処理を実装することで対応した。
コンテナイメージのビルド時に毎回異なる連番タグを生成し、コンテナイメージに付与する処理と、タグが付与されたイメージを使用するようにKubernetesのデプロイメント用マニフェストを書き換える処理である。
しかしこの方法には、イメージタグの生成ルールを決める必要があることや、Jenkinsジョブの複雑な作り込みが必要になること、バージョン管理に格納しているマニフェストとデプロイ時に使用したマニフェストの乖離が生じるといった課題がある。
.
デプロイの課題を
OpenShiftの独自機能で解決する
この課題に対しては、OpenShiftの機能が有効である。
OpenShiftはKubernetesに独自の機能を強化しており、ビルドやデプロイに関しても独自の機能を備える。ここで取り上げたいのが、「ImageStream」と「DeploymentConfig」という機能である。
ImageStreamはコンテナイメージへの参照情報を保持し、コンテナイメージのバージョン履歴の管理や更新検知機能を搭載する。
DeploymentConfigはKubernetesにおけるDeploymentリソースに機能拡張を実施しており、ImageStreamによる更新検知をトリガーに、アプリケーションの起動単位であるポッドをデプロイできる。
ImageStreamを利用すると、コンテナレジストリ上のイメージ更新がOpenShiftによって検知され、それをトリガーとして、DeploymentConfigでアプリケーションの最新版をデプロイできる。
つまりこれらの機能を利用することで、CI／CDパイプラインでコンテナイメージの更新を検知する処理を実装する必要はなくなる。図表2は、連携のイメージである。
.
.
なお、ImageStreamがイメージ更新を検知するための確認間隔（ポーリング間隔）は、OpenShift on IBM Cloudのようなマネージドサービスでは利用者を指定できない点に注意したい。
任意のタイミングで確認したい場合には、「oc import-image」コマンドを明示的に実行するとよい。
デプロイに関する悩みは、命令型から宣言型へのマインドセットを変換すること、必要値によって挙動が変わるKubernetesのリソースに注意すること、OpenShiftのImageStreamの活用によって作り込みを回避できることがポイントとなる。
本稿では、筆者や同じシステム構築に携わったメンバーがOpenShift on IBM Cloudに本気の開発テスト環境を構築する際に経験した悩み、疑問、そしてその対応方法を紹介した。
これからコンテナを活用する案件が増えることで、同じような悩みを抱く人が出てくるかもしれない。その際には、本稿の内容を思い出して、参考にしていただければ何より嬉しい。
著者｜
福島 清果氏
日本アイ・ビー・エム システムズ・エンジニアリング株式会社
クラウド・アプリケーション
アドバイザリーITスペシャリスト
入社以来、さまざまな業種やシステムにおいてテスト自動化ソリューションの技術支援に携わり、近年はコンテナ環境での開発テストツールチェーンの提案からシステム構築までを担当している。
［i Magazine 2020 Summer掲載］
････････
特集｜OpenShift
Part1 基礎から始めよう、OpenShiftネットワークの概要と活用例
Part2 OpenShift on IBM Cloudを活用した本気の開発環境デザイン
＿前編 提案時の悩み：コンテナ環境向け開発ツールの選定
＿中編 設計時の悩み：開発テスト環境のプライベートネットワーク構成
＿後編 運用時の悩み：OpenShift機能を活用して開発テスト環境へのデプロイを効率的に
Part3 OpenShiftでの最適なバックアップ手法
