.
本稿ではIBMがIBM Cloud上にホスティングしているエンタープライズ向けOpenShiftのマネージドサービスである「RedHat OpenShift on IBM Cloud」（以下、OpenShift on IBM Cloud）を使って、長期利用を想定して「本気の開発テスト環境」を構成する際に直面する悩みや疑問、その対応方法をお伝えする。
中編は中上級者向けに、「設計時の悩み：プライベートネットワーク構成」について解説する。
.
パブリックなクラスタを
仮想プライベートネットワーク内の開発テスト環境として使用
コンテナ環境向けの開発ツールを選定し、いざ開発テスト環境の設計に着手する際に戸惑うのが、プライベートな開発テスト環境のネットワーク構成である。ある程度コンテナ環境に関する知識がある中上級者でも、OpenShift on IBM Cloud特有の要素は押さえておきたい。
企業のシステム構築では、開発環境を企業のプライベートネットワーク内に構築したいケースが多々ある。
その理由として、データセンターや企業内サーバーなどプライベートネットワーク内に関連システムやその開発テスト環境があり、クラウド上に構築するアプリケーションもそれらのシステムと連携する必要があること、開発中やテスト中のアプリケーションプログラムやテストデータなどにアクセスされるリスクを極力減らしたいことが挙げられる。
利用するIBM Cloudのパブリックサービスについても、プライベート環境からのみアクセスしたい場合もある。
経験のあるアーキテクトであれば、そのような前提でのネットワーク構成を何となくイメージできるだろう。
①IPアドレスはプライベートにする、②クラスタ内の環境（開発、テスト、ステージング）はネームスペースで分離する、③クラスタから企業内のネットワークへはVPN経由でプライベート接続する、④コンテナからIBMのパブリックサービス （Db2 WarehouseやWatson APIなど）はプライベートIPアドレスからのみアクセスできるように構成する、⑤パブリックIPアドレスのみのサードパーティサービスはhttpsなどのセキュアなプロトコルで接続する、といったあたりは想像できるかもしれない。
ところが実際に設計しようとすると、パブリッククラウドで提供されているマネージドサービスについてはパブリックアクセスに関する情報が主で、プライベート構成の情報が非常に限定的であることに気づくだろう。
ここからOpenShift on IBM Cloudにおける開発テスト環境のプライベートネットワーク構成について、よくある以下の3つの疑問について解説する。
疑問1 パブリッククラウドにあるクラスタにプライベートIPでのみ接続するには
疑問2 どうやればコンテナをプライベートIPに公開できるか
疑問3 ネームスペースで環境を分けたら、開発端末からどのようにアクセスするか
.
疑問1 パブリッククラウドにあるクラスタに
プライベートIPでのみ接続するには
開発テスト環境のプライベートネットワーク構成でまず悩むのは、「パブリッククラウドにあるクラスタなのに、プライベートIPでのみ接続できるのか」ということだ。
その答えは、「パブリッククラウドでのプライベートアクセスが可能かどうかは、マネージドサービスの提供ベンダーやサービスによって異なる」である。
まずは利用するサービスについて、プライベートIPのみの接続が可能かを確認しよう。
IBM Cloud の場合はプライベートネットワーク構成をサポートしているが、サービスによってはパブリックネットワーク・アクセスしかサポートされないものもある。
また一般的に、クラウドのサービスは随時サポートされる構成が変わるため、最新の情報を確認する必要がある。
IBM Cloudについては、2種類のプライベートネットワーク構成がある。
1つ目は旧SoftLayer時代から存在する「クラシック・インフラストラクチャ」、2つ目は新しいアーキテクチャである「仮想プライベート・クラウド（VPC）インフラストラクチャ」である。
名前を聞くと後者を利用するのがよさそうだが、残念ながら執筆時点（2020年6月）では、OpenShift on IBM Cloudの最新バージョンであるバージョン4.3と、1つ前のバージョンであるバージョン3.11では「仮想プライベート・クラウド（VPC）インフラストラクチャ」はサポートされていない（Red Hat OpenShift on IBM Cloud サービスの制限-バージョン 4.3 クラスタの制限）。
そのため、利用するのは「クラシック・インフラストラクチャ」になる。
またOpenShift on IBM Cloudバージョン4.3では、クラスタを管理する「マスターノード」へはプライベートアクセス（「プライベート サービス・エンドポイント」と呼ばれる）がサポートされない点も注意したい。
クラシック・インフラストラクチャを利用したOpenShift on IBM Cloudのプライベートネットワーク構成の要点を図表1で説明する。
.
.
① アプリケーションを稼働させるワーカーノードは任意の仮想LAN（以下、VLAN）に接続できるため、ワーカーノードはパブリックVLANとプライベートVLANをそれぞれ１つずつ指定する必要がある。
② インターネットからの各ユーザーアカウント専用のパブリックVLANへの入り口となるルータが、「FCR （Front-end Customer Router）」である。
③ IBM Cloud プライベートネットワークから各ユーザー専用のプライベートVLANへの入り口となるルータが、「BCR （Back-end Customer Router）」である。
④ プライベートVLANとパブリックVLANをつなぎ、ファイアウォール、トラフィック・シェーピング、ポリシーベースの経路指定やVPNの機能を提供するのが、「VRA （Virtual Router Appliance）」である。FCR、BCR、VRAはIBM Cloud特有の用語であるが、クラシック・インフラストラクチャによるIBM Cloudのネットワーク構成で欠かせないため覚えておきたい。
⑤ OpenShift on IBM Cloudはマネージドサービスであるため、クラスタを管理するマスターノード（サービス・エンドポイントとも呼ばれる）はIBM管理となっており、これについてはパブリックネットワーク側でアクセスする必要がある。
⑥ OpenShiftクラスタへのアクセス権を管理するIBM Cloud Identity and Access Management（IAM）や、追加のコンテナを配置する際に必要なコンテナレジストリのIBM Cloud Container Registry など、最低限必要なプライベートネットワーク外へのアクセスを確保する必要がある。これらはIBM Cloud内部に配置されているが、ユーザーではなくIBM管理のIPアドレス空間となる。
ここまでで基本的な構造は抑えられたと思う。ネットワーク構成のためにはこれらに加えて、OpenShiftやKubernetesのコンテナでのネットワーク構成の理解も必要となる。
.
疑問2 どうやればコンテナを
プライベートIPに公開できるか
開発環境のプライベートネットワーク構成に関する2つ目の疑問は、「アプリケーションをプライベートIPに公開するにはどうすればよいか」である。
コンテナを公開する際に基本のマニュアルやチュートリアルどおりに実施すると、パブリックIPに公開されてしまうし、プライベートIPへの公開に関する情報は少ない。一例として筆者が理解した内容を紹介したい。
OpenShiftクラスタ上のアプリケーションへのアクセスは、http(s) のトラフィックについては一般的にOpenShift独自のRouter、もしくは Kubernetesの汎用的なIngressを使用し、OpenShiftクラスタではRouterが振分け処理を実行する。
デフォルトのクラスタ構成では、Router も Ingress もパブリックIPアドレスに公開されているので、まずはRouterをプライベートIPアドレスに公開するように追加のセットアップが必要となる。
OpenShift on IBM Cloud バージョン4.3で行った追加セットアップの大まかな流れを解説しよう。詳細な手順はSetting up basic load balancing with an NLB 1.0を参照してほしい。
まずはIngressControllerリソースを作成して、新しいRouterを作成する。
次に新しいRouterに対してServiceリソースを作成して RouterをプライベートIPの Load Balancerに公開する。
オプションとして、パブリックIPに公開されているデフォルトRouterのIngressController定義を編集して、プライベートのRoute定義がデフォルトRouterに公開されないように構成する。
ここまででプライベートなRouterが構成できるが、そこにアプリケーションを公開するには、まずRouteの設定で指定したlabelによるセレクターのルールに合わせて、OpenShiftプロジェクト（Kubernetesのネームスペース）に、Route定義のlabelを設定する方法がある。
さらにRouteを作成する際に、hostnameオプションを使用して、プライベートIPアドレスに解決されるホスト名を指定すればよい。
プライベート構成に関してはまとまった情報が少ないので、1つの例として、この流れで実際にプライベートネットワーク構成を実現できたことを伝えたい。
.
疑問3 ネームスペースで環境を分けたら
開発端末からどのようにアクセスするのか
開発テスト環境のプライベートネットワーク構成を行ったあと、その環境に配置したアプリケーションへ開発端末からアクセスするには、どうすればよいだろうか。
まずOpenShiftクラスタ上のアプリケーションへのアクセスは、大きく2つに分けられる。
1つ目は、前述したようなRouter（もしくはIngress）を使用して、アクセス時に使用するホスト名（仮想ホスト名）やコンテキスト・ルートをもとに振り分ける方法で、これは基本的にhttp/httpsのみが対象となる。
2つ目はKubernetesのServiceを、ネットワーク・ロードバランサー・サービス （NLB） を使用するように構成し、IPアドレスを割り振る方法で、任意のTCP/IP サービスが対象となる。クラスタ上のコンテナで稼働しているデータベースに、クラスタ外から直接アクセスする場合などにも使用できる。
ここでは、1つ目のRouterもしくはIngressを使用して仮想ホスト名で割り振る方法について説明する。
例として統合テスト環境とステージング環境のそれぞれのネームスペースに、WebとAPIの2つのアプリケーションのコンテナを稼働させる場合を考えてみよう。
統合テスト環境のコンテナは、共通の仮想ホスト名（例としてapp1-it.mydomain.internal）とし、各アプリケーションはホスト名以降のパスを分けてアクセスさせる。
たとえばWebのコンテナは/web/、APIのコンテナは「https://app1-it.mydomain.internal/api/」でアクセスする。
ステージング環境の仮想ホスト名を「app1-staging.mydomain.internal」とし、同様に各アプリケーションはホスト名以降のパスで分け、統合テスト環境のWebのコンテナはhttps://app1-it.mydomain.internal/api、ステージング環境のAPIのコンテナはhttps://app1-staging.mydomain..internal/api/でアクセスしたいとする。
これを実現するには図表2のように、開発端末からはIT環境の仮想ホスト名とステージング環境の仮想ホスト名のいずれも同じRouterのIPアドレスに名前解決させること、そしてアクセス先のRouterは端末がアクセスする仮想ホスト名とパスによってアクセス先のサービス（コンテナ）を振り分けることが必要となる。
.
.
この際、開発端末からRouterへの名前解決の考慮が必要になる。
名前解決については、企業内や公開用のDNSサーバーがあれば、それに開発環境用のドメインを登録する方法や、開発端末にDNSプロキシーソフトウェアを導入構成する方法、IPアドレスに解決するダイナミックDNSサービス （nip.io など）を利用する方法などがある。
Routeでのホスト名とパスによる振り分けについては、oc expose コマンドの –hostname オプションで明示的に指定する方法と、Route リソース定義で hostname を指定する方法がある。
具体的な設定は、製品のマニュアルを参照してほしい（RedHat OpenShift Container Platform 4.3-Secured routes）。
ここまで、OpenShift on IBM Cloudを利用してプライベートネットワーク内に開発テスト環境を構築する場合によくある疑問を3つ紹介した。実は開発環境のプライベートネットワーク構成はこのほかにも追加のニーズや罠があるので、別の機会があれば紹介したい。
著者｜
福島 清果氏
日本アイ・ビー・エム システムズ・エンジニアリング株式会社
クラウド・アプリケーション
アドバイザリーITスペシャリスト
入社以来、さまざまな業種やシステムにおいてテスト自動化ソリューションの技術支援に携わり、近年はコンテナ環境での開発テストツールチェーンの提案からシステム構築までを担当している。
［i Magazine 2020 Summer掲載］
････････
特集｜OpenShift
Part1 基礎から始めよう、OpenShiftネットワークの概要と活用例
Part2 OpenShift on IBM Cloudを活用した本気の開発環境デザイン
＿前編 提案時の悩み：コンテナ環境向け開発ツールの選定
＿中編 設計時の悩み：開発テスト環境のプライベートネットワーク構成
＿後編 運用時の悩み：OpenShift機能を活用して開発テスト環境へのデプロイを効率的に
Part3 OpenShiftでの最適なバックアップ手法
