.
クラウド上のアプリケーションの稼働環境として、コンテナ技術が徐々に浸透しつつある。開発したアプリケーションを迅速に稼働させ、動作検証できるコンテナ環境はアプリケーションの開発テスト環境に適している。
コンテナ技術としてはDockerや、その管理機能を強化したコンテナ管理ソフトウェアであるKubernetesを利用する事例も増えている。さらにKubernetesを拡張し、企業向けに使いやすくしたソフトウェアとしてRedHat OpenShiftがある。
コンテナ環境を構築するには、サーバーや仮想サーバーを用意してソフトウェアを導入する方法以外に、「マネージドサービス」として提供される環境を利用する方法もある。
マネージドサービスはサービスの提供側が構築や管理を実施するため、利用側はすぐに利用できる大きなメリットがある。ただし自由にすべてをカスタマイズできるわけではなく、制約もある点に注意が必要となる。
本稿ではIBMがIBM Cloud上にホスティングしているエンタープライズ向けOpenShiftのマネージドサービスである「RedHat OpenShift on IBM Cloud」（以下、OpenShift on IBM Cloud）を使って、長期利用を想定して「本気の開発テスト環境」を構成する際に筆者が経験した悩みや疑問、その対応方法をお伝えする。
3つのパートに分け、前編はコンテナ初心者向けに「提案時の悩み：コンテナ環境向けツール選定」、中編は中上級者向けに「設計時の悩み：プライベートネットワーク構成」、後編は同様に「運用時の悩み：着実なデプロイ運用」について解説する。
.
コンテナ環境で必要なラインアップとは
これまでオンライン系のアプリケーション開発に携わってきた経験があれば、開発に必要な環境や開発の流れをある程度イメージできるだろう。
しかしコンテナ環境向けとなると、どのような開発環境を用意すればよいか、イメージが湧かないかもしれない。筆者も最初は、多くの断片的な情報に翻弄された。コンテナ環境で開発テスト環境を構築する際に最初に悩む課題だと思うので、まずはコンテナ環境に共通するツール選定のポイントを紹介したい。
コンテナ開発向け開発ツールは、「開発ツールの範囲→構築パターン→サービスツール」で段階的に選定する
筆者がコンテナ開発向け開発ツールの選定に際して実践したのは、開発ツールの範囲、構築のパターンを検討したあとに、具体的なツールを考えるという進め方である。
初めにツール名から考えると思わぬ要素が抜けてしまうことがあるので、コンテナ環境での開発に必要な要素の全体像を理解してから、詳細を考えるほうが漏れがない。
また開発テスト環境には多くの範囲があるが、すべてを初めから揃える必要はなく、最低限必要なものを押さえたうえで、プロジェクトやチームに合わせて必要なものを追加していくのがよいだろう。
必要な要素を押さえるために、図表1のコンテナ環境の基本的な開発の流れを理解しよう。
.
.
①開発したソースコードはバージョン管理に格納する。
②バージョン管理に格納されたソースコードをビルド（コンパイルとパッケージング）し、さらにコンテナイメージ（Dockerイメージとも呼ばれる）にビルドする。そしてコンテナイメージをコンテナ環境へデプロイする。このビルドとデプロイを自動化するのが、CI／CDパイプラインである（CIは継続的インテグレーション、CDは継続的デリバリーの略）。
③アプリケーションのビルドの際には、必要なライブラリを成果物管理のMavenリポジトリから取得する。
④コンテナイメージのビルドの際には、コンテナレジストリからベースのイメージを取得し、ビルド後のDockerイメージをコンテナレジストリに格納する。
⑤コンテナイメージをコンテナ稼働環境へデプロイすると、アプリケーションが起動する。
このコンテナ環境での開発で従来と異なる点は、主に2つある。
1つ目は、ビルドとデプロイの流れを自動化する「CI/CDパイプライン」が必須となることである。
コンテナには新しい機能を迅速に稼働できるという特徴がある。人手によるビルドやリリースでそのよさを損なわないようにするには、CI/CDパイプラインによるビルドやデプロイの自動化が必須となる。
2つ目は、コンテナイメージを格納するコンテナレジストリが新たに追加になることである。
コンテナ環境での開発の流れを見ると、バージョン管理、ビルド、成果物管理、CI／CDパイプラインが主な開発ツールの範囲となる。
そのほかにも稼働後のアプリケーションのテストを自動化する結合テスト自動化ツール、コードのチェックを実行する静的解析ツール、きめ細かく作業を管理するチケット管理ツール、コンテナやアプリケーションのセキュリティ検査ツール、各種ツールからの情報をユーザーへ通知するコミュニケーションツールなどもオプションで追加することがある。
プロジェクトやチームの目的や必要なコスト（準備や利用のコスト）を踏まえて、利用するツールの範囲を選定しよう。範囲を選んだら、次にその要素の構築・運用パターンを考える。従来の開発環境であれば自前で開発ツール環境を構築することが多かった。しかし最近では、パブリックサービスとして提供されるツールを利用する方法もある。
セキュリティやコストなどのメリット・デメリットを踏まえて、プロジェクトやチームに適したものを選択する。たとえばコストに関しては、パブリックサービスを利用すると初期構築やバージョンアップなどのメンテナンスのコストは不要となるが、継続的な利用時にはコストが発生する。
またセキュリティに関しては、プライベート構築では外部から分離した環境を構築することもできるが、パブリックサービスの場合には共同利用する要素があるため、セキュリティを確保する方法の検討が重要となる。
構築パターンを決めたら、ツール選定の最後のステップとしてツールやサービスを選定する。非常に多くのツールやサービスがあるが、選定基準として、まずはアプリケーションの稼働環境と親和性の高いものから検討し、さらに一般的によく使用されるツール、企業内で利用を推奨されるツールを確認するのがよいだろう。
サーバー型のツールには、前述したプライベート構築とパブリックサービスの利用という選択肢がある。
インターネットで検索すると、パブリックサービスとして提供されるツール（バージョン管理のGitHubやCIツールのTravisCIなど）がよくヒットするが、プライベート構築の場合、それらは利用できないので注意したい。プライベート構築で利用できるツールを選択する必要がある。
また最近では、JenkinsXなどあらかじめセットになっているツール群をまとめた「ツールセット」を利用する選択肢もある。
ツールセットには必要なツールが揃った環境を構築できる利点がある。ただ、ツールが想定する開発方法に合わせる必要があるので、どのような開発方法を想定しているか事前に確認しておこう。
ツールやサービス、ツールセットの候補は刻一刻と変わるので、必須の機能を見極め、ある程度は割り切って選択する。できれば、必要に応じて段階的に追加して行くのが望ましい。そのためには、連携の追加が可能な拡張性のあるツールを選ぶのがよいだろう。
著者｜
福島 清果氏
日本アイ・ビー・エム システムズ・エンジニアリング株式会社
クラウド・アプリケーション
アドバイザリーITスペシャリスト
入社以来、さまざまな業種やシステムにおいてテスト自動化ソリューションの技術支援に携わり、近年はコンテナ環境での開発テストツールチェーンの提案からシステム構築までを担当している。
［i Magazine 2020 Summer掲載］
････････
特集｜OpenShift
Part1 基礎から始めよう、OpenShiftネットワークの概要と活用例
Part2 OpenShift on IBM Cloudを活用した本気の開発環境デザイン
＿前編 提案時の悩み：コンテナ環境向け開発ツールの選定
＿中編 設計時の悩み：開発テスト環境のプライベートネットワーク構成
＿後編 運用時の悩み：OpenShift機能を活用して開発テスト環境へのデプロイを効率的に
Part3 OpenShiftでの最適なバックアップ手法
