今さら聞けない!? OpenShift4の多すぎるインストール方式をおさらいする

目次

はじめに

はじめまして、Red HatでOpenShift Container Platformのテクニカルサポートの野間です。Red Hat Advent Calendar 2023 の12/7の記事になります。別でOpenShift Advent Calendar 2023 もありますね、どちらも楽しんでください。

OCP4.1がGAされた2019年に入社し、この製品と4年をともに過ごしました。現在ではマイナーバージョンも4.14まで更新され、あわせてインストール可能なプラットフォームやインストール方式も増えました。製品も成長したなあ、とふと公式ドキュメントのinstallingの項目を確認すると、、、ぶっちゃけ多すぎて読む気なくしません？同じ内容で日本語訳も読めるこちらのドキュメントページではsingle-pageでの表示もできるのですが、インストールのページをsingle-pageで開くと、量が多すぎて私のPCのブラウザが固まります。試してみる場合は注意してください。

ソフトウェア利用の最初の一歩であるインストールがこんなに複雑ではやる気がなくなってしまいます。とうわけでユーザーが少しでも回れ右をしないように、必要な前提知識を整理してみます。

プラットフォーム

まずはインストールするプラットフォームを選択する

プラットフォームを決定しないことには始まらないので、まずプラットフォームを選択しましょう。4.14時点でOpenShiftはAWS、Azure、vShereなど10のプラットフォームをサポートしています。

インストールドキュメントが肥大化している一番の理由は、実はプラットフォーム毎に手順が存在しているためです。よく読むと、それぞれのプラットフォーム独自の手順以外は、同じ内容が記載されています。ひとつのプラットフォームを選択したら、ほかの手順は読む必要はありませんので、ドキュメントボリュームに気後れする必要はありません。

any platformとbaremetalの意味とちょっとした歴史的経緯

プラットフォームのany platformとbaremetalについて補足します。any platform(日本語ドキュメントでは「任意のプラットフォーム」)はその名前の通りプラットフォームを選ばないインストール方法です。たとえばvSphereのVMをany platform方式でインストールしたり、もしくはドキュメントに記載のないプラットフォームに使うことができます。昔はbaremetalとして記載されていたのですが、仮想環境でも使用できることから正確性のために、4.6からany platformに変更されました。以降のbaremetalは、名称のとおり物理サーバーを想定した方法になっています。そのような経緯から今も混同されていることがありますので、注意してください。

インストール方式

IPIとUPIは何が違うのか

もっともスタンダードなインストール方式はIPI(Installer Provisioned Infrastructure)とUPI(User Provisioned Infrastructure)の2種類です。凄くザツに説明すると、「自動でおまかせ」モードと「イチからDIY」モードです。

IPIでは、インストーラーにinstall-config.yamlファイルを読み込ませるだけで済みます。この方法では、必要なインフラをプラットフォームの機能と連携して自動的に構成します。例えばAWSでIPIを使用すると、ノード(EC2)はもちろん、Route 53のレコード登録やネットワークも作成してくれます。インストール後も引き続きプラットフォームと連携するため、OpenShiftの機能をフル利用できる構成です。

UPIは基本的にインフラをユーザー側で用意して構成します。そのため当然ですがIPIと比べて手間や知識が必要となります。利点は、IPIでは構成できない細かいカスタマイズが可能になるという点です。そのため、基本的にはIPIで構成し、譲歩できないカスタマイズ要件が存在するユースケースではUPIを使う選択が一般的かと思います。インストールの簡単さとカスタマイズ性はトレードオフになると考えています。

その他のインストール方式

IPIとUPI以外の以下のインストール手順はドキュメントは、プラットフォームに関わらず独立した項目になっています。下記の説明とともにリンクをご覧ください。

SNO(Single Node OpenShift)

基本的には複数のノードで構成することが通常のOpenShiftですが、なんと一台でも作れてしまいます。想定されるユースケースは通信事業系のエッジコンピューティングや、導入として小さいリソースで検証するような場合です。当然ですが一台なのでHA(高可用性)機能は切り捨てられています。サポートされるプラットフォームなどに制限があるため、条件についてはドキュメントのRequirementsをご覧ください。

Assisted Installer

オンプレミス環境限定となりますが、Web上で対話式で設定できる支援サービスによりインストールできます。もう一つの利点ですが、bootstrap nodeが必要ありません。そのため、オンプレミス環境で課題となりがちなbootstrap用のリソース確保が不要となります。また、前述のSNOも構成できます。

Agent-based installer

Assisted Installerは素晴らしい、しかし僕らが求めているオンプレ環境はインターネットに接続しないクローズド環境なんだ、というあなたにはAgent-based installerがあります。bootstrap不要、 SNOにも対応というAssitsted Installerの利点をいかしつつも、CLIで完全ローカルに構成することができます。比較的新しいインストール方式で4.12からGAとなっており、まだまだ機能強化が予定されています。

インターネット非接続環境

Agent-basedでも少し触れましたが、インターネットに接続しない閉じられたネットワーク環境での構成、つまり「インターネット非接続環境」が求められるケースがあります。英文ドキュメントやナレッジではdisconnected network、 restricted network もしくはair-gapped networkと呼ばれることもあります。

IPIやUPIでも可能であり、各プラットフォームの項目に restricted network として別項で手順が記載されています。ただ、これだけでは手順は不足しており、事前にミラーレジストリホストを準備しておく必要があります。通常はクラスタがイメージなどのコンテンツをインターネットから取得するため、その代替をネットワーク内に構築する必要があるということです。ミラーの作成方法は幾通りかあるためドキュメントのDisconnected installation mirroringの項目を確認し作成してください。

インストールパターンと難易度について

インストールについての一通りを説明しましたが、組み合わせることでパターンは無数に存在します。選択肢が多いことはよいことですが、インストールの難易度(手間や事前知識)に差があることも留意してください。

例えばAWSのようなクラウドプロバイダープラットフォームのIPIであればinstallerをダウンロードし、install-config.yamlを作成し実行するだけです。作業自体は慣れれば10分もかかりません。しかし、any platform方式のインターネット非接続環境となると、ユーザーがノードやネットワークおよびミラーレジストリホストを構築する必要があり、事前知識や手間が大きく異なります。あまり事例の無い組み合わせのレアなユースケースの場合は、蓄積されたナレッジも少ないため思わぬ落とし穴にはまるかもしれません。もちろん構成の選定はシステムの要件が基になるべきですが、まずは簡素な構成/方式からステップアップしていくことをおすすめいたします。

まとめ

• まずはサポートされているプラットフォームを選ぼう

• 次にインストール方式を選ぼう。簡単なのはIPI、カスタマイズしたいならUPI。その他の方式も選べるよ

• インストール方式で手間や事前知識は大きく異なるので、例えばインターネット非接続環境のような条件付き構成は難易度が高くなることに注意しよう