OpenShift 4 には、インストール＆セットアップするためのアプローチが幾通りか用意されていますが、このことが原因で、時々混乱の種になっていたり、とっつきにくい状態になっている気がします。これはあまりよいことではないので、私なりに整理してみたいと思います。ここでは私が聞いたり読んだりしてきた情報から、よりわかりやすいと思う軸に則って整理してみようと思います。

OpenShift 4 クラスター構築バリエーションの整理軸
- マネージド vs セルフマネージド
- インストーラの使い方
- カスタマイズの範囲

なお、インストール＆セットアップの選択肢は、バージョンを重ねる毎に充実してきている側面ものでもあるので、この記事では2022年6月時点の最新版であるOpenShift 4.10　をベースにまとめていきます。

視点1:マネージド vs セルフマネージド

Amazon Web Services (AWS) や、Microsoft Azure , Google Cloud Platform ( GCP ) といった、主要なパブリッククラウドベンダーは、単純な仮想マシンを利用する意外にも、さまざまなマネージドサービスが用意されています。
マネージドサービスを選択する最大のメリットは、自身で機能を構築することに比べて、カスタマイズできる範囲は制限されるものの、利用する機能に対する管理はクラウド事業者側で行われるため、利用者は機能の利用に集中できるという点ではないでしょうか。
馴染みが薄いかも知れませんが、Red Hat OpenShift Container Platform にも、古くは、Version 3 の頃から、マネージドサービスが提供されています。

表：主要クラウドベンダー上で利用可能なマネージドOpenShiftサービス

サービス名	Platform	特徴	Link
ROSA	AWS	AWS と Red Hat が提供する. AWS のBilling に支払いが統合される	https://aws.amazon.com/jp/rosa/
ARO	MS Azure	MS Azure と Red Hat が提供する. MS Azure のBilling に支払いが統合される	https://azure.microsoft.com/ja-jp/services/openshift/#overview
ROKS	IBM Cloud	IBM と Red Hat が提供する. IBM のBilling に支払いが統合される	https://www.ibm.com/jp-ja/cloud/openshift?mhsrc=ibmsearch_a&mhq=openshift
OSD	AWS or GCP	Red Hat が提供する.　AWSまたはGCP を選択可能	https://www.redhat.com/ja/technologies/cloud-computing/openshift/dedicated

これらのマネージド型のOpenShiftを利用することで、一般的なマネージドサービスの利用と同様にOpenShiftクラスターの管理をクラウド事業者側へオフロードされます。つまり、利用者は、コンテナアプリケーションやサービスの開発、運用に集中することが可能となります。こと、環境のインストールやセットアップに関しては、それぞれのマネージドサービス毎に独自に簡略化された手段が提供されています。

こういった利用形態を総称すると、「マネージドサービスのOpenShift」とグルーピングできます。これとは異なる利用形態として、OpenShift Clusterの管理を環境の所有者が行うパターンがあります。ユーザ自身で管理するという意味で、セルフマネージドと呼ばれたりします。OpenShiftのインストールガイドで紹介されている環境構築手段を用いるものは、全てセルフマネージドに分類されます。

視点2:インストーラーの使い方

ここ以降の分類に関しては、基本的にセルフマネージドのOpenShift について分解することができます。
セルフマネージドの観点での、最初の大きな軸は、OpenShiftが提供するopenshift-installコマンドが、インストールタスクを完了するか否かで分類されます。

インストーラタスクの分類
- 全自動・半自動いずれかでopenshift-installコマンドがインストールタスクを完了
- インストールプロセスの一部としてopenshift-installコマンドを利用

openshift-install の使い方をどのように判断するのか？という観点になってきますが、明確な使い方のポイントがあります。

ポイント１：全自動・半自動は、OpenShift を構築する環境が製品としてサポートされている必要がある
- プラットフォーム例: AWS , Azure , GCP , IBM Cloud , vSphere, RHOSP , IBM Z
ポイント２：ポイント１に該当しないばあいは、一律、anyplatform installation とよばれるインストールプロセスとなり、openshift-installコマンドを部分的に使用しながら、環境を構築していくこととなる
- プラットフォーム例：Red Hat 意外のOpenStack , KVM , baremetal

詳細は、Red Hat ナレッジベースの関連記事、インストールマニュアルを参照してください。

視点3:カスタマイズの範囲

最後に、前述のopenshift-installコマンドの使い方による分類です。openshift-installコマンドはその名のとおり、OpenShiftクラスターをインストール＆セットアップします。ここでは、openshift-installコマンドがインストールタスクを完了させる全自動または半自動のプロセスの分類となります。

IPI : Installer Provisioned Infrastructure
UPI : User Provisioned Infrastructure

IPIは、openshift-install コマンドが、IaaSといったインフラのAPIをコールして、仮想ネットワーク等、OpenShift Cluster に付帯する全ての機能をセットアップします。対して、UPI の場合は、インフラ機能については、所有者であらかじめ用意したうえで、OpenShift Cluster を環境に合わせ込んでいくようなアプローチとなります。
IPIは、認定済みのIaaS環境であれば、OpenShift に必要な全てのリソースのセットアップも含めて、自動化されているので容易にOpenShiftを構築できる反面、構成で指定できるオプションはUPIに比べて制限されています。
これらの詳細についても、詳しくは製品ドキュメントを見てください。

まとめ？

結局、どの選び方がよいのか？というところについて、色々書き出して見ましたが結論は難しいなと思いました。

OpenShift クラスター環境に、細かくカスタマイズする必要がない。（要件がシビアではない）
- 候補：IPI インストール , マネージドサービス
OpenShift クラスターの管理（インストールや、バージョンアップ、障害対応...etc）を行えない。（行いたくない)
- 候補：マネージドサービス
非認定のプラットフォームに構築しなくてはならない
- 候補：anyplatform installation
環境を積極的にカスタマイズしていきたい
- 候補：UPI インストール , anyplatform installation

のような基準になるかと思います。
個人的には、OpenShift クラスターに関して、一般的なシステム要件を完全に網羅するのはなかなか難しい問題ですが、譲れる箇所が明確になれば、環境の用意のしやすさの観点で、ある程度柔軟に選択することが可能ではないかと思います。

この点については、時間経過とともにまた異なる視点もみえてくる点ではありますので、引き続きウォッチして適宜更新していきたいと思います。