Assisted installer と Agent-based installer について

## はじめに

こんにちは。
パートナー企業でOpenShiftの技術支援をしている @ynicotama です。
今回は[OpenShift Advent Calendar 2023](https://qiita.com/advent-calendar/2023/openshift) 10日目ということで、
Assisted installer と Agent-based installer について、概要、両インストーラの違いを追っていきたいと思います。

## 注意事項
- 本記事は、公開時点(2024/12/10)での情報をもとに執筆しています。
- 今後も情報が更新される可能性があるため、参考にされる場合は最新の情報を参照してください。
- 本記事ではそれぞれのインストール方法について、以下の略語を使用します。
    - AI: Assisted installer
    - ABI: Agent-based installer

## 現在のOpenShiftのインストール方法
本記事の執筆時点で、OpenShiftのインストールは以下4つの方法に大別されます。
- UPI(User-provisioned installation)
- IPI(Installer-provisioned installation)
- AI(Assisted Installer)
- ABI(Agent-based Installer)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/867585/c3e5e4ae-ba53-9220-b46d-2ee93933920e.png)

混同しがちですが、UPI・IPIとは異なるインストール方法として、AI・ABIが存在します。

## AI(Assisted Installer)
AI は、RHOCP4.10でGAとなった機能です。
特徴は、Webベースで視覚的な操作、インストール前の種々のバリデーションをすることにより、初心者にも比較的簡単にOpenShiftをインストールすることが可能な点にあります。
AI では、UPI、IPIとは異なり、discoveryISOと呼ばれるカスタムRHCOSのbootISOをホスト上で起動することにより、インストールを実施します。
また、もう一つの大きな違いとして、インストール時にbootstrapノードの配備が不要になります。

## ABI(Agent-based Installer)
ABI は、RHOCP4.12でGAとなった機能です。
特徴は、 AI のインタラクティブな操作、インストール前のバリデーション、bootstrapノードの配備不要等の利点を引き継ぎつつ、disconnected環境へのインストールにも対応している点です。(なお、connected環境へのインストールも可能です。)
on-premise環境におけるIPI、UPIで種々の設定管理に課題を感じている場合、disconnected環境のためAIが使えない場合にも対応したインストール方法です。

## AI と ABI の違い
ここまでで、 AI と ABI の概要について追ってきましたが、 AI と ABI の何が違うの？と思うかもしれません。
両者の違いはどこにあるのでしょうか？
以下の表で両者の比較をしてみましょう。

|                                     | Assisted installer                      | Agent-based installer                        |
|-------------------------------------|-----------------------------------------|----------------------------------------------|
| 対応platform<br>(platform integration)   | none, baremetal, vsphere, nutanix   | none, baremetal, vsphere                     |
| UI                                  | Webページ, CLI(API利用)                   | TUI, CLI                                     |
| インストール媒体                       | ISO(discoveryISO)                       | ISO(agentISO)                               |
| Assisted-serviceのホスト             | Red Hat社が管理するリモートホスト            | ローカルのノードホスト(最初に起動したノード)   |
| ネットワーク構成                       | connected環境のみ                         | connected環境, disconnected環境               |

AIとABIで対応プラットフォームが異なる、UIが異なる等の違いはありますが、インストール時にISOを利用する点、インストール時にAssisted-serviceが利用される点は同様です。

キモは、以下の概略図に示すように、インストールをサポートするAgentの接続先となる、Assisted-serviceがホストされている場所です。
- AI では、Red Hat社がホストしているmanagedなAssisted-serviceへ接続し、インストールを実施されるのに対し、
- ABI では、ローカルで最初に起動したコントロールプレーン上で、Assisted-serviceが起動し、インストールが実施されます。

インターネット越しの接続が前提だったAssisted-serviceを、ローカルでホストすることにより、disconnected環境のインストールにも対応したということですね。

![無題のプレゼンテーション.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/867585/8977e694-d29a-6961-379c-f85f42804e71.png)

## 独立したbootstrapノードの準備が不要できる理由
さて、両インストールの違いについては大枠はイメージできたかと思います。
最後に、AI、ABIを触った方なら気になる、インストール時にbootstrapノードの配備が不要となるワケについて掘り下げていきたいと思います。

仕組みは、以下のとおりです。
- AI・ABIで、ISOから起動したノードのうちの一台が、bootstrapの役割を果たすノードとして動作します。
  (UPI/IPIで実施していたbootstrapがなくなったわけではない。)
- 加えて、インストール中にetcdのreplica数が2であることが許容されており、masterノードが2台起動した時点でbootstrapが完了します。
- bootstrap完了後に、そのノードがmasterノードとして再度クラスタへ組み込まれることにより、3master構成が完成します。

## まとめ
以上、Assisted installer、Agent-based installerについて追ってきました。
本記事が、それぞれのAI・ABIの理解の助けとなれば幸いです。