OpenShift 4.14 Anyplatform Installation をやってみる。

## はじめに
はやいもので、2023年もあと1ヶ月。恒例のアドベントカレンダーの季節がやってきました！

今回は、セルフマネージド（マネージドサービスの対義語として）OpenShiftの環境構築において、もっとも汎用性の高いインストール方法である Anyplatform Install の実際の流れを最新リリースのOCP4.14を対象として追いかけてみたいと思います。

OpenShiftの環境構築に興味がある方は、詳しくは[製品ドキュメント](https://access.redhat.com/documentation/en-us/openshift_container_platform/4.14)を見ていただきたいのですが、OpenShiftのインストールには、大きく、フルオートメーション、セミオートメーション、手動に大別することができます。

### インストール方法の概要
| 名前 | 特徴 | 注意点など |
|:-:|:--|:--|
| IPI  | インストーラプログラムによってクラウド環境のマシン払出も含めて全自動で構築される  | インストーラーがパブリッククラウドや仮想化基盤といったプラットフォームに対応済である必要がある。<br> プラットフォームに対して比較的強い権限が必要  |
| UPI  | サーバの払出や、ネットワーク構築はユーザが手動で行い、インストール作業はインストーラが行う（＝セミオートメーション）。<br> IPIより柔軟な構成をとることが可能。 | 注意点は、IPIと同じ |
| Anyplatform | 必要なインフラリソースを全てユーザーが手動で用意する。<br> インストールプロセスにも度々、手動の操作が必要。IPI/UPIのように導入先となるプラットフォームの制限は無いため、最も汎用性が高い。<br> 必要な権限が利用できないオンプレ仮想環境や、ベアメタルマシンへ導入する場合は、ほぼこのパターンとなる。 | 最も汎用性が高い方法ではあるものの、導入できないケースはある。（eg.導入先のマシンスペックが弱い...etc) <br> マシンに対するOSインストールや電源ON/OFFといった操作は必要。 |

> 個人的には、インストレーションについては、ドキュメントの情報が充実しているため、詳しくはやはりそちらを参照してもらうのがベストですが、いずれのインストール方法も、オプションが多いため、最短パスでのインストールとなると、ドキュメントを読み解くのにある程度の知識が必要と感じます。
> 特に、オプション（というか、インストールに付帯する作業）が最も多いAnyplatformのインストール方法をまとめることによって、より取っ掛かりやすくできたらなという思いでこちらの記事を書きました！


## 環境
今回は、下図にある3 Master , 2 Worker 構成のOpenShift環境を構築します。
導入するOpenShiftのバージョンは、 4.14.4 (2023/12/1時点の最新)となります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/311140/3960bbe0-781f-d5e7-0821-d5b56a9d55e1.png)

Anyplatform インストールの場合、環境構成にはいくつかオプションがあります。今回は、もっとも補助系の機能が少ない構成としています。
補助系の機能に関しては、可用性や運用性の観点から、冗長化や、Network Bootの仕組みの導入などを適宜検討する必要があります。

### 各マシンの役割

| 分類 | マシン名称 | 台数 | 役割 |
|:-:|:-:|:-:|:--|
| OpenShift  | bootstrap  | 1 | 初期インストール時のみ必要となるノード |
|   | master  |  3 | OpenShiftのコントロールプレーン  |
|   | worker  |  2 | アプリケーションPODが可動するノード  |
| 補助  | bastion  | 1  | 管理者がコマンドライン操作を行ういわゆる踏み台マシン。openshift-install , oc といったバイナリファイルを配置する。 |
|  | utility(*) | 1 | Loadbalanser , DNS , httpd(ignitionファイルの配布用）といったOpenShift に必要な外部機能を混載する。 |

(*) 各種機能は、アプライアンス製品や他サービスで代替できます。また、実践的な利用にむけては、冗長化など可用性を考慮した構成とすることを推奨します。

### マシンスペック

| マシン名称 | CPU | RAM | System Disk | 使用したOS(*) |
|:-:|:-:|:-:|:-:|:-:|
| bootstrap  | 4 VCPU | 16 GB  | 120 GB  | RHCOS |
| master  | 4 VCPU  | 16 GB  | 120 GB | RHCOS |
| worker  |  4 VCPU | 16 GB  |  120 GB | RHCOS |
| bastion  | 1 VCPU  | 4 GB  | 40 GB  | RHEL 9 |
| utility  | 2 VCPU  | 8 GB  | 100 GB  | RHEL 9 |

(*) RHCOS = Red Hat Core OS , RHEL 9 = Red Hat Enterprise Linux 9

## 用意するもの

* マシン (物理マシン / VMゲストを問わない）
* インターネットアクセスが可能なネットワーク環境（１セグメント）
* Red Hat ID ※アカウントの状態によって評価版を申し込む必要あり。
    * [カスタマーポータルより入手](https://access.redhat.com/)
        * RHEL ISO　ファイル
        * RHCOS ISO　ファイル
    * [Red Hat Hybrid Console](https://console.redhat.com/)より入手
        * openshift-installer
        * oc コマンド
        * pull-secret

## インストール

### 大まかな作業の流れ
#### 事前：補助系マシンの整備
1. bastionマシンのOSインストール
1. utilityマシンのOSインストール
    1. セットアップ
        1. dnsmasq
        1. haproxy
        1. httpd
1. RHCOS ISOイメージのマウント用意

#### OpenShiftインストール
1. openshift-install , oc コマンドの配置
1. ノードへのアクセス時に使用するSSHキーの生成
1. install-config.yamlの作成
1. クラスターの Kubernetes マニフェストの生成
1. ignitionファイルの生成
1. ignitionファイル配布の準備
1. bootstrap ノードのブート
1. master ノードのブート
1. bootstrapプロセス完了の待機
1. worker ノードのブート
1. CSRの承認
1. インストールプロセス完了の待機
1. 確認

### bastion & utility マシンのOSインストール
この点はさらっと記載します。
* RHELのISOメディア（または、仮想イメージ）を使用
* ソフトウェアの選択：『最小限のインストール』
* ネットワークへの接続 ( IPアドレス, Gateway , DNS )
    * DNSについては、暫定のものを指定します。subscription-managerやdnfコマンドを実行するのに必要です。内部のdnsサーバがセットアップできた後、参照先を変更します。
* タイムゾーンの選択と時刻同期ON
* ホスト名の設定 ( bastion , utility )
* ディスク構成は任意。
    * カスタマイズ時に "/home" を提案される場合は、"/" へ振りなおす
* rootアカウントのパスワード設定
* OSログイン用のユーザアカウントの追加 ( このユーザーを管理者アカウントにするをチェック）
* インストール後、subscription-manager コマンドを使用して、register と、attach を行う。
* OSの最新化 ( $ sudo dnf update -y )

### utilityマシン ( dns , loadbalancer , httpd の設定）
#### dnsmasq 
OpenShiftクラスターに関連する名前解決をできる必要があります。この手順では、dnsmasq を使用しました。
このDNSレコードは、OpenShiftを構成するマシン群および、OpenShiftのコンソールアクセス、OpenShift上で可動するアプリケーションへアクセスに使用するクライアントマシンが参照します。
尚、要件を満たす限りは異なるソフトウェアやアプライアンス、サービスで代替することが可能です。

##### パッケージのインストール
```
$ sudo dnf install -y dnsmasq
```
##### レコードの設定
ドキュメントにある要件を参考に、DNSレコードを追加します。
今回は、クラスター名を"cluser-ocp" ,base domain を、"myhome.lab" としました。
このため、主要なレコードは下記の様になります。

| 名前 | IPアドレス |
|:-:|:-:|
| api.cluster-ocp.myhome.lab | 192.168.3.129 |
| api-int.cluster-ocp.myhome.lab  | 192.168.3.129 |
| *.apps.cluster-ocp.myhome.lab  | 192.168.3.129 |
| bootstrap.cluster-ocp.myhome.lab  | 192.168.3.191 |
| master01.cluster-ocp.myhome.lab  | 192.168.3.193 |
| master02.cluster-ocp.myhome.lab  | 192.168.3.194 |
| master03.cluster-ocp.myhome.lab  | 192.168.3.195 |
| worker01.cluster-ocp.myhome.lab  | 192.168.3.196 |
| worker02.cluster-ocp.myhome.lab  | 192.168.3.197 |

###### 参考"/etc/hosts"ファイル
```
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

192.168.3.128 bastion bastion.cluster-ocp.myhome.lab
192.168.3.129 api.cluster-ocp.myhome.lab api-int.cluster-ocp.myhome.lab lb01.myhome.lab lb01

192.168.3.191 bootstrap bootstrap.cluster-ocp.myhome.lab
192.168.3.193 master01 master01.cluster-ocp.myhome.lab
192.168.3.194 master02 master02.cluster-ocp.myhome.lab
192.168.3.195 master03 master03.cluster-ocp.myhome.lab
192.168.3.196 worker01 worker01.cluster-ocp.myhome.lab
192.168.3.197 worker02 worker02.cluster-ocp.myhome.lab
```

###### 抜粋 "/etc/dnsmasq.conf"ファイル
ワイルドカードレコードの登録
```
...抜粋
# Add domains which you want to force to an IP address here.
# The example below send any host in double-click.net to a local
# web-server.
#address=/double-click.net/127.0.0.1
address=/apps.cluster-ocp.myhome.lab/192.168.3.129
...抜粋ここまで
```

##### デーモンの起動と自動起動設定
```
$ sudo systemctl enable dnsmasq
$ sudo systemctl start dnsmasq
```

##### firewalld のポート開け
dns のポートを開ける

```
$ sudo firewall-cmd --add-service dns --zone public --permanent
$ sudo firewall-cmd --reload
```
##### テスト
下記のように応答が返ってくることを確認する。

```
# 順引き
$ dig hoge.apps.cluster-ocp.myhome.lab

; <<>> DiG 9.11.36-RedHat-9.11.36-8.el8 <<>> hoge.apps.cluster-ocp.myhome.lab
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6996
;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;hoge.apps.cluster-ocp.myhome.lab. IN   A

;; ANSWER SECTION:
hoge.apps.cluster-ocp.myhome.lab. 0 IN  A       192.168.3.129

;; Query time: 0 msec
;; SERVER: 192.168.3.130#53(192.168.3.130)
;; WHEN: Thu Nov 30 19:06:04 JST 2023
;; MSG SIZE  rcvd: 66

$ 
# 逆引き
$ dig -x 192.168.3.129

; <<>> DiG 9.11.36-RedHat-9.11.36-8.el8 <<>> -x 192.168.3.129
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24418
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;129.3.168.192.in-addr.arpa.    IN      PTR

;; ANSWER SECTION:
129.3.168.192.in-addr.arpa. 0   IN      PTR     api.cluster-ocp.myhome.lab.

;; Query time: 0 msec
;; SERVER: 192.168.3.130#53(192.168.3.130)
;; WHEN: Thu Nov 30 19:08:11 JST 2023
;; MSG SIZE  rcvd: 95

$ 
```

#### haproxy 
3 master , n worker 構成のOpenShiftは、API や、ingressを経由したアプリケーションへのアクセスをロードバランサーでマスカレードする必要があります。
今回は、haproxy を使用して、外部ロードバランサー機能を実現しました。
尚、Layer 4 の負荷分散が可能であれば、ことなるアプライアンスやサービスで代替することが可能です。

##### パッケージのインストール
```
$ sudo dnf install -y haproxy
```
##### Pool の設定
ドキュメントの要件を参考に、負荷分散のグループを設定します。

| 名前 | ポート | プールメンバー |
|:-:|:-:|:-:|
| api-server | 6443  | bootstrap & master  |
|  machine-config-server | 22623 |  bootstrap & master   |
| ingress-router | 443  | worker  |
| ingress-router | 80	  | worker  |

###### 参考："/etc/haproxy/haproxy.cfg"
```
global
  log         127.0.0.1 local2
  pidfile     /var/run/haproxy.pid
  maxconn     4000
  daemon
defaults
  mode                    http
  log                     global
  option                  dontlognull
  option http-server-close
  option                  redispatch
  retries                 3
  timeout http-request    10s
  timeout queue           1m
  timeout connect         10s
  timeout client          1m
  timeout server          1m
  timeout http-keep-alive 10s
  timeout check           10s
  maxconn                 3000
frontend stats
  bind *:9000
  mode            http
  log             global
  maxconn 10
  stats enable
  stats hide-version
  stats refresh 30s
  stats show-node
  stats show-desc Stats for ocp4 cluster 
  #stats auth admin:ocp4
  stats uri /stats
listen api-server-6443 
  bind *:6443
  mode tcp
  server bootstrap bootstrap.cluster-ocp.myhome.lab:6443 check inter 1s backup 
  server master01 master01.cluster-ocp.myhome.lab:6443 check inter 1s
  server master02 master02.cluster-ocp.myhome.lab:6443 check inter 1s
  server master03 master03.cluster-ocp.myhome.lab:6443 check inter 1s
listen machine-config-server-22623 
  bind *:22623
  mode tcp
  server bootstrap bootstrap.cluster-ocp.myhome.lab:22623 check inter 1s backup 
  server master01 master01.cluster-ocp.myhome.lab:22623 check inter 1s
  server master02 master02.cluster-ocp.myhome.lab:22623 check inter 1s
  server master03 master03.cluster-ocp.myhome.lab:22623 check inter 1s
listen ingress-router-443 
  bind *:443
  mode tcp
  balance source
  server worker01 worker01.cluster-ocp.myhome.lab:443 check inter 1s
  server worker02 worker02.cluster-ocp.myhome.lab:443 check inter 1s
listen ingress-router-80 
  bind *:80
  mode tcp
  balance source
  server worker01 worker01.cluster-ocp.myhome.lab:80 check inter 1s
  server worker02 worker02.cluster-ocp.myhome.lab:80 check inter 1s
```

##### デーモンの起動と自動起動設定
```
$ sudo systemctl enable haproxy
$ sudo systemctl start haproxy
```

##### firewalld のポート開け
80,443,6443,22623 のポートを開放する
```
$ sudo firewall-cmd --add-service https --zone public --permanent
$ sudo firewall-cmd --add-service https --zone public --permanent
$ sudo firewall-cmd --add-service=kube-apiserver --zone=public  --permanent
$ sudo firewall-cmd --permanent --new-service machine-config
$ sudo firewall-cmd --permanent --service=machine-config --set-description="OpenShift machine config access"
$ sudo firewall-cmd --service=machine-config --add-port=22623/tcp --permanent 
$ sudo firewall-cmd --add-service=machine-config --zone=public  --permanent
$ sudo firewall-cmd --add-port 9000/tcp --zone public --permanent
$ sudo firewall-cmd --reload
```

##### テスト
lbマシンの9090ポートにWebブラウザでアクセスし、ステータスページが表示されることを確認する。(この段階だと、全てのプールメンバーは起動していない為、全てがダウンステータスで表示されます。）
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/311140/4e851cb3-c6bc-4c68-1733-44e706d5cd8a.png)


#### httpd
OpenShift のインストール時に、各coreos に設定ファイルとしてignitionを配布します。その配布用のサーバとして、httpd を構築しました。
今回は、utilityマシンにhaproxy ( 80　ポートをマスカレード）と混載しているため、ポートをデフォルトの80から8003 へ変更しています。haproxy と、ignition配布用のhttpd は、アクセスする用途が大きく異なる為、セキュリティや管理性を考慮し、マシンを異なるものとすべきかを検討する必要があります。
尚、OpenShiftを構成するマシン群からhttpにてアクセス可能であれば、異なるソフトウェアやアプライアンス、サービスに代替することが可能です。

##### パッケージのインストール
```
$ sudo dnf install -y httpd
```
##### httpd の設定

前述のとおり、リッスンポートを80から8003 へ変更する必要があるため、httpd.conf を変更します。

###### 参考："/etc/httpd/conf/httpd.conf"

```
...抜粋
#
# Listen: Allows you to bind Apache to specific IP addresses and/or
# ports, instead of the default. See also the <VirtualHost>
# directive.
#
# Change this to Listen on specific IP addresses as shown below to
# prevent Apache from glomming onto all bound IP addresses.
#
#Listen 12.34.56.78:80
Listen 8003

...抜粋ここまで
```

##### デーモンの起動と自動起動設定
```
$ sudo systemctl enable httpd
$ sudo systemctl start httpd
```

##### firewalld のポート開け
8003 ポートを開ける

```
$ sudo firewall-cmd --add-port 8003/tcp --zone public --permanent
$ sudo firewall-cmd --reload
```

##### テスト
curlコマンドやWebブラウザーで http://lb01:8003 へアクセスし、レスポンスがあることを確認する。

```
$ curl http://lb01:8003                                                                                                                     
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">                                                        
                                                                                                                                                         
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">                                                                                                
        <head>                                                                                                                                           
                <title>Test Page for the HTTP Server on Red Hat Enterprise Linux</title> 
 ... 省略
 </div>
        </body>
</html>
$ 
```

### RHCOS ISOイメージのマウント用意
RHCOS のISOイメージを、カスタマーポータルから入手します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/311140/2fb5ff8e-ab01-71b2-478d-73ce9d2d6399.png)

入手したISOイメージを環境に合わせて、使用できるようにします。今回の環境は、KVM上に構築していますので、KVMホストのイメージストアにアップロートし、ゲストVMへアタッチしました。（下図は、virt-managerで表示したbootstrapノードの設定です。）
* ISOイメージのアタッチ
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/311140/6682abd4-11dd-22af-7451-f4f7c853f3bb.png)

* bootデバイスの設定
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/311140/c8d89a73-2436-682b-ddc2-a534f7f3f264.png)

OSのインストールメディアをアタッチするのと同じ操作となるので、仮想化環境が異なる場合は、環境にあわせて、同様の操作を行ってください。また、ベアメタルマシンの場合は、入手したISOイメージファイルをbootメディアとして用意します。（手順の上では、bootメディアは一つで大丈夫です。）


事前準備は完了となります。

### OpenShift インストール
#### openshift-install , oc コマンドの入手と、bastionマシンへの配置
[console.redhat.com](https://console.redhat.com/)(*)から、openshift-install およびoc コマンドを入手します。こちらのサイトから入手できるバイナリーは、公開済みの最新バージョンとなります。
(*) ログインするには、Red Hat ID が必要です。

尚、インストール方法を問わず、構築を行う際に使用するopenshift-install コマンドのバージョンが、その時点で選択できる最新のバージョンとなります。ターゲットとするOpenShiftバージョンより新しいopenshift-installを入手して使用するようにしてください。

console.redhat.comでの画面操作順を以下に示します。

* console.redhat.comログイン後のトップページ
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/311140/3387469c-d50d-dae8-d628-5aa76747c7cd.png)

<br>

* OpenShiftオーバービューの画面
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/311140/c59f086e-7706-1e39-01bb-12a4aa12de4b.png)

<br>

* Cluster Typeの選択画面
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/311140/5c412fb8-e798-0dbd-78c5-b00e6a7b9d37.png)

<br>

* Cluster Type @ Datacenter の画面
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/311140/22151e6f-c998-6c68-5be4-e2910a4abecf.png)

<br>

* Cluster Type @ Datacenter = Platform agnostic
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/311140/5b35f5e8-a4c5-9421-a265-4f9cc39c5c1b.png)

<br>

* 各種ファイルのダウンロード
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/311140/6b213b01-c525-bded-2e6a-6d0159f3e1c7.png)
※このページは、後の手順で、"pull secret"の取得時にもアクセスします。

入手したファイルは、適宜bastionマシンのOSログインユーザのディレクトリに配置します。また、各ダウンロードボタンからリンク先のURLを取得して、bastionマシンからcurl コマンドで入手することも可能です。

```
# ファイルの取得
$ curl -O https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/ocp/stable/openshift-install-linux.tar.gz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  410M  100  410M    0     0  7385k      0  0:00:56  0:00:56 --:--:-- 4294k
$ curl -O https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/ocp/stable/openshift-client-linux.tar.gz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 60.9M  100 60.9M    0     0  7418k      0  0:00:08  0:00:08 --:--:-- 9004k
$ ls -l
total 483136
-rw-rw-r--. 1 toaraki toaraki  63934993 Dec  1 14:45 openshift-client-linux.tar.gz
-rw-rw-r--. 1 toaraki toaraki 430791889 Dec  1 14:44 openshift-install-linux.tar.gz

# tar.gz ファイルの展開と、/usr/local/binへの配置
$ sudo tar xzf openshift-client-linux.tar.gz -C /usr/local/bin
$ sudo tar xzf openshift-install-linux.tar.gz -C /usr/local/bin

# Pathとバージョンの確認
$ which oc
/usr/local/bin/oc
$ which openshift-install
/usr/local/bin/openshift-install
$ openshift-install version
openshift-install 4.14.3
built from commit cebc8ab0fd6f8b66197f5a4e058ea4913dbb587c
release image quay.io/openshift-release-dev/ocp-release@sha256:e73ab4b33a9c3ff00c9f800a38d69853ca0c4dfa5a88e3df331f66df8f18ec55
release architecture amd64
$ oc version
Client Version: 4.14.3
Kustomize Version: v5.0.1
$ 

```

#### ノードへのアクセス時に使用するSSHキーの生成
インストール時に各ノードへインジェクションされるSSHキーを生成します。

```
$ ssh-keygen -t ed25519 -N '' -f ~/.ssh/cluster-ocp
Generating public/private ed25519 key pair.
Your identification has been saved in 
... << ommited >>
|  o .  ...E ..   |
|   .    .o.      |
|         .       |
|                 |
+----[SHA256]-----+
$ 
```

#### install-config.yamlの作成
openshift-installコマンドに渡すパラメータを、install-config.yaml ファイルに記述します。
今回作成したinstall-config.yaml を以下に示します。

``` install-config.yaml
apiVersion: v1
# base domainの指定
baseDomain: myhome.lab
compute:
- hyperthreading: Enabled
  name: worker
  # replicas は、台数を指定するが、Anyplatformインストールの場合は、"0" 一択
  replicas: 0
controlPlane:                   
  hyperthreading: Enabled
  name: master
  replicas: 3 
metadata:
  # クラスターの名称を指定する。
  name: cluster-ocp
networking:
  # -- マニュアルより引用 --
  # Pod IP アドレスの割り当てに使用する IP アドレスのブロック。このブロックは既存の
  # 物理ネットワークと重複できません。これらの IP アドレスは Pod ネットワークに使用
  # されます。外部ネットワークから Pod にアクセスする必要がある場合、ロードバランサー
  # およびルーターを、トラフィックを管理するように設定する必要があります。
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23 
  networkType: OVNKubernetes 
  # -- マニュアルより引用 --
  # サービス IP アドレスに使用する IP アドレスプール。1 つの IP アドレスプールのみ
  # を入力できます。このブロックは既存の物理ネットワークと重複できません。外部ネット
  # ワークからサービスにアクセスする必要がある場合、ロードバランサーおよびルーターを、
  # トラフィックを管理するように設定します。
  serviceNetwork: 
  - 172.30.0.0/16
platform:
  none: {} 
fips: false 
pullSecret: '{"auths": ...}'
# 後述するconsole.openshift.com で取得する、'pull secret'の値を "..." 箇所に記入する。
sshKey: 'ssh-ed25519 AAAA...'
# 前手順で生成した SSH鍵を指定する。
```

* 'pull secret'の取得方法
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/311140/74c2ea1a-d119-b255-62fc-dba7aee00469.png)



インストール構成を管理するディレクトリ(通例では、クラスター名を指定）作成し、作成したinstall-config.yaml を配置します。尚、install-config.yamlは、以降の操作でファイルが消失してしまう仕様のため、再インストール時に備えてコピーを取得しておくことをおすすめします。


``` 
$ mkdir cluster-ocp
$ mv install-config.yaml cluster-ocp/.
$ mkdir cluster-ocp-config-bk
$ cp cluster-ocp/install-config.yaml cluster-ocp-config-bk/.
$
```

#### クラスターの Kubernetes マニフェストの生成
openshift-installコマンドを使用して、kubernetesマニフェスト（インストールの構成ファイル）を生成します。

```
$ openshift-install create manifests --dir ~/cluster-ocp
INFO Consuming Install Config from target directory 
WARNING Making control-plane schedulable by setting MastersSchedulable to true for Scheduler cluster settings 
INFO Manifests created in: /home/toaraki/cluster-ocp/manifests and /home/toaraki/cluster-ocp/openshift 
$ 
```

生成されたマニフェストファイルから、コントロールプレーンへのPODスケジューリングに関するパラメータを確認します。(下記、マニュアルから引用）
```
<installation_directory>/manifests/cluster-scheduler-02-config.yml Kubernetes マニフェスト
ファイルの mastersSchedulable パラメーターが false に設定されていることを確認します。
この設定により、Pod がコントロールプレーンマシンにスケジュールされなくなります。

i. <installation_directory>/manifests/cluster-scheduler-02-config.yml ファイルを開きます。

ii. mastersSchedulable パラメーターを見つけ、これが false に設定されていることを確認します。

iii .ファイルを保存し、終了します。
```
実際に生成されたままのファイルはこちら。
``` cluster-scheduler-02-config.yml 
apiVersion: config.openshift.io/v1
kind: Scheduler
metadata:
  creationTimestamp: null
  name: cluster
spec:
  mastersSchedulable: true
  policy:
    name: ""
status: {}
```
7行目の'mastersSchedulable'が、'true' になっているので、これをfalse に変更します。（今回の構成では、master ノードにユーザアプリケーションをデプロイさせないようにしたいため。）

編集後のファイルはこちら
``` cluster-scheduler-02-config.yml 
apiVersion: config.openshift.io/v1
kind: Scheduler
metadata:
  creationTimestamp: null
  name: cluster
spec:
  mastersSchedulable: false
  policy:
    name: ""
status: {}
```

#### ignitionファイルの生成
インストール処理においてRHCOSに設定を行うinigitionファイルを生成＆変更済みのクラスターkubernetesマニフェストファイルから生成します。
```
$ openshift-install create ignition-configs --dir ~/cluster-ocp
INFO Consuming Openshift Manifests from target directory 
INFO Consuming Worker Machines from target directory 
INFO Consuming Master Machines from target directory 
INFO Consuming Common Manifests from target directory 
INFO Consuming OpenShift Install (Manifests) from target directory 
INFO Ignition-Configs created in: /home/toaraki/cluster-ocp and /home/toaraki/cluster-ocp/auth 

$ ls -l ~/cluster-ocp
total 288
drwxr-x---. 2 toaraki toaraki     50 Dec  1 17:22 auth
-rw-r-----. 1 toaraki toaraki 282434 Dec  1 17:22 bootstrap.ign
-rw-r-----. 1 toaraki toaraki   1724 Dec  1 17:22 master.ign
-rw-r-----. 1 toaraki toaraki    110 Dec  1 17:22 metadata.json
-rw-r-----. 1 toaraki toaraki   1724 Dec  1 17:22 worker.ign
$ 
```

#### ignitionファイル配布の準備

各ノードをセットアップする際は、前段で生成したignitionファイルを使用します。これを、準備のステップで構築したhttpd経由で取得できるように、ignitionファイルをwebサーバへ配置します。

##### SHA512ダイジェストの確認と記録

RHCOSのインストールセットアッププロセスの途中で、取得したignitionファイルが、適切なものであることのチェックがあるため、SHA512ダイジェストを取得して、メモを記録します。

今回使用する手順では、RHCOS上でコマンドライン入力で操作をおこいますが、この時にダイジェストの値を手で入力するには、あまりに大変なので、ここで収集した情報を元に、RHCOS上で実行するコマンドをワンショットのシェルスクリプトに書き起こしておくと、楽になります。

```
## SHA512ダイジェストの確認
$ sha512sum ~/cluster-ocp/*.ign 
d431589e4f7f57f2451ee945f497b5fa8ecdb09962b24490274dc766694b0e692a99ac78f3e85612740a258fd7935ab2c8a926cabb84fb9506370f879e2edb3c  /home/toaraki/cluster-ocp/bootstrap.ign
3f5c52f46cb918289bbbf594cb574061388d4168246cea504d957032a7ac23ebcf5c53dd7cec7dce9f16b6a0d895608adaff4f8552575eac4546cf7c4390dda5  /home/toaraki/cluster-ocp/master.ign
1231669a24a03bc4e390d457aac22f04436fbc1ecd7be73dffdc5f5512c82077bb3c72df0f5e16996ab968eddebfe0f4d859e51bf006f6f3c3121b10652eb9b5  /home/toaraki/cluster-ocp/worker.ign
$ 
```

bootstrap , master , worker のRHCOSインストールコマンドシェルスクリプトの準備

* (参考)作成したbootstrapノード用のシェルスクリプト

``` coreos_setup_bootstrap.sh
#/bin/sh

## ignitionファイル配布元のWebサーバアドレス（とポート）
WebServerAddress=192.168.3.129:8003
## ignitionファイルのファイル名 ( bootstrap || master || worker )
IGNITIONFILE=bootstrap.ign
## RHCOS をインストールする先のハードディスクドライブの名称
DstHDD=/dev/vda
## SHA512ダイジェストの値
SHA512DIGEST=d431589e4f7f57f2451ee945f497b5fa8ecdb09962b24490274dc766694b0e692a99ac78f3e85612740a258fd7935ab2c8a926cabb84fb9506370f879e2edb3c

## coreos-installerコマンドの実行
## スタティックIPアドレス指定を想定している為、'--copy-network' オプションを指定している。これによって
## インストール時にノードの設定されているネットワーク設定が、RHCOSの設定値として引き継がれる。
sudo coreos-installer install --ignition-url=http://${WebServerAddress}/${IGNITIONFILE} ${DstHDD} --ignition-hash=sha512-${SHA512DIGEST} --copy-network

```

* (参考)作成したmasterノード用のシェルスクリプト

``` coreos_setup_master.sh
#!/bin/sh

## ignitionファイル配布元のWebサーバアドレス（とポート）
WebServerAddress=192.168.3.129:8003
## ignitionファイルのファイル名 ( bootstrap || master || worker )
IGNITIONFILE=master.ign
## RHCOS をインストールする先のハードディスクドライブの名称
DstHDD=/dev/vda
## SHA512ダイジェストの値
SHA512DIGEST=3f5c52f46cb918289bbbf594cb574061388d4168246cea504d957032a7ac23ebcf5c53dd7cec7dce9f16b6a0d895608adaff4f8552575eac4546cf7c4390dda5

## coreos-installerコマンドの実行
## スタティックIPアドレス指定を想定している為、'--copy-network' オプションを指定している。これによって
## インストール時にノードの設定されているネットワーク設定が、RHCOSの設定値として引き継がれる。
sudo coreos-installer install --ignition-url=http://${WebServerAddress}/${IGNITIONFILE} ${DstHDD} --ignition-hash=sha512-${SHA512DIGEST} --copy-network
```

* (参考)作成したworkerノード用のシェルスクリプト

``` coreos_setup_worker.sh
#!/bin/sh

## ignitionファイル配布元のWebサーバアドレス（とポート）
WebServerAddress=192.168.3.129:8003
## ignitionファイルのファイル名 ( bootstrap || master || worker )
IGNITIONFILE=worker.ign
## RHCOS をインストールする先のハードディスクドライブの名称
DstHDD=/dev/vda
## SHA512ダイジェストの値
SHA512DIGEST=1231669a24a03bc4e390d457aac22f04436fbc1ecd7be73dffdc5f5512c82077bb3c72df0f5e16996ab968eddebfe0f4d859e51bf006f6f3c3121b10652eb9b5

## coreos-installerコマンドの実行
## スタティックIPアドレス指定を想定している為、'--copy-network' オプションを指定している。これによって
## インストール時にノードの設定されているネットワーク設定が、RHCOSの設定値として引き継がれる。
sudo coreos-installer install --ignition-url=http://${WebServerAddress}/${IGNITIONFILE} ${DstHDD} --ignition-hash=sha512-${SHA512DIGEST} --copy-network
```

##### ignitionファイルをWebサーバへ配置

```
$ cd ~/cluster-ocp
$ ls
auth  bootstrap.ign  master.ign  metadata.json  worker.ign
$ scp *.ign root@lb01:/var/www/html/.
root@lb01's password: 
bootstrap.ign                                                                         100%  276KB  49.8MB/s   00:00    
master.ign                                                                            100% 1724   723.7KB/s   00:00    
worker.ign                                                                            100% 1724   640.0KB/s   00:00    

## @springred 様より必要の旨コメントあり（実機確認中）
## lb01へ、*.ign ファイルをアップロードした後で、lb01上で
## "chmod 755 -R /var/www/html"　を行わないと、403エラー
## となる。
## （ここまで）

$ curl -I lb01:8003/bootstrap.ign
HTTP/1.1 200 OK
Date: Sat, 02 Dec 2023 08:42:24 GMT
Server: Apache/2.4.37 (Red Hat Enterprise Linux)
Last-Modified: Sat, 02 Dec 2023 08:37:08 GMT
ETag: "44f42-60b82ca50c67d"
Accept-Ranges: bytes
Content-Length: 282434
Content-Type: application/vnd.coreos.ignition+json

$
```
Webサーバへinigitionファイルをアップロードしたら、いよいよノードのセットアップとなります。

#### bootstrapノードのブート
準備のセクションで設定したとおり、RHCOSのISOメディアからブートする設定としたうえで、boostrap用のノードの電源をONにします。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/311140/f9f8ceeb-cf96-c0fb-10cb-d7c4c4ad8293.png)

起動が完了すると、コマンドプロンプトが表示されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/311140/fbb08749-5e00-eb35-a210-72ff83177f19.png)

今回の方法だと、起動したRHCOSにはIPアドレス等が一切付与されない状態で起動してきますのでネットワークの設定を手動で投入します。

このスクリーンショットでは、nmcliコマンドでOS起動時に作成される'Wired connection 1'を削除（名前が扱いにくいため）たうえで、新しいコネクションプロファイルを作成し、IPアドレス・ネットマスクを付与します（他マシンと通信するための最低限の設定）。
その後、手元にあったシェルスクリプト(niccnf.sh ...コマンドを羅列しただけの物なので説明しません)をscp し、ネットワークの設定を流し込みました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/311140/168192d2-d2d8-1c17-103e-99602f924c52.png)

シェルスクリプトで設定しているリストは以下のとおりです。
* ipv4.address　... IPアドレスとネットマスク
* ipv4.method ... Auto(DHCP)/Manual/無視/無効の切り替え
* connection.autoconnect ... OS起動時に自動活性するかどうか
* ipv4.dns ... 参照先DNSサーバ（=このシナリオでは、utiltyマシンのIPアドレスを指定しています）※画像との整合性を要修正
* ipv4.gateway ... デフォルトゲートウェイ
* ipv6.method ... ipv6 のAuto/Manual/無視/無効の切り替え

続いて、前の手順で作成したcoreos_setup_bootstrap.sh を入手し、実行します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/311140/8535476e-c415-1077-a15a-326c6e9edfab.png)

RHCOSのイメージコピーおよびネットワーク設定の引き継ぎが行われるので、完了したらOSをリブートします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/311140/2d70018b-77fc-4da0-85f1-6da0e20553be.png)

再起動後、boostrapノードのOpenShiftに関連するセットアップが自動的に実行されます。

画面は再起動が完了し、裏で自動的にセットアップが行われている様子となります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/311140/1f7ba99e-fe7a-d657-4952-e05d6c60a166.png)

#### masterノードのブート
bootstrapノードとほぼ同じ内容で、masterノードもブートしていきます。
操作内容の相違点は、
* 各ノードに割り当てるIPアドレス
* masterノードの用のcoreos-installer コマンドのシェルスクリプトを使用する
* リブートのタイミングは3台はなるべく同じタイミングで実施
    * 根拠はないですが、内部で処理させるetcdクラスタリングの処理等を想像すると、あまり離れたタイミングではない方がいいのではないかと思っています。。。

#### boostrapプロセス完了の待機
masterノード3台のリブートが完了したら、bootstrapプロセスが完了するまで待機します。
待機には、openshift-installコマンドのwait-for オプションを使用します。
以下に実際に実行した時の出力を示します。
```
$ openshift-install --dir cluster-ocp wait-for bootstrap-complete --log-level=debug                  
DEBUG OpenShift Installer 4.14.3           
DEBUG Built from commit cebc8ab0fd6f8b66197f5a4e058ea4913dbb587c
INFO Waiting up to 20m0s (until 9:23PM JST) for the Kubernetes API at https://api.cluster-ocp.myhome.lab:6443... 
DEBUG Loading Agent Config...
INFO API v1.27.6+b49f9d1 up                                                  DEBUG Loading Install Config...                                              DEBUG   Loading SSH Key...                
DEBUG   Loading Base Domain...             
DEBUG     Loading Platform...              
DEBUG   Loading Cluster Name...            
DEBUG     Loading Base Domain...           
DEBUG     Loading Platform...              
DEBUG   Loading Networking...              
DEBUG     Loading Platform...              
DEBUG   Loading Pull Secret...             
DEBUG   Loading Platform...                
DEBUG Using Install Config loaded from state file
INFO Waiting up to 30m0s (until 9:33PM JST) for bootstrapping to complete... 
DEBUG Bootstrap status: complete                      
INFO It is now safe to remove the bootstrap resources 
DEBUG Time elapsed per stage:
DEBUG Bootstrap Complete: 31s                      
INFO Time elapsed: 31s  
$
```

#### workerノードのブート
bootstrapノード , masterノードと同様の内容で、workerノードをブートしていきます。
操作内容の相違点は、
* 各ノードに割り当てるIPアドレス
* masterノードの用のcoreos-installer コマンドのシェルスクリプトを使用する
* coreos-installer コマンドの後、OSをリブート

#### CSR(Certificate Signing Requests)の承認
workerノードのセットアッププロセス中に、クラスターへジョインするタイミングで、CSRが発行されます。この要求が特に問題がない（今回は、インストールを意図しているため問題はない。）場合、CSRを承認します。

```
$ oc get csr | grep -i pending
csr-8kjrg                                        103s    kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper         <none>              Pending
csr-b8gbf                                        114s    kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper         <none>              Pending
csr-jwnzb                                        2m20s   kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper         <none>              Pending
csr-xdjp6                                        2m10s   kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper         <none>              Pending
[toaraki@bastion ~]$ 
```
※oc コマンドを実行する際に、認証が必要な旨のメッセージが表示される場合は、KUBECONFIG環境変数を設定します。

```
oc get csr
error: Missing or incomplete configuration info.  Please point to an existing, complete config file:


  1. Via the command-line flag --kubeconfig
  2. Via the KUBECONFIG environment variable
  3. In your home directory as ~/.kube/config

To view or setup config directly use the 'config' command.
$ export KUBECONFIG=~/cluster-ocp/auth/kubeconfig
$ oc whoami
system:admin
$
```

次のワンライナーコマンドで、Pending 状態のCSRを一括で承認できます。
```
$ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve
certificatesigningrequest.certificates.k8s.io/csr-8kjrg approved
certificatesigningrequest.certificates.k8s.io/csr-b8gbf approved
certificatesigningrequest.certificates.k8s.io/csr-jwnzb approved
certificatesigningrequest.certificates.k8s.io/csr-xdjp6 approved
[toaraki@bastion ~]$ 
```

続けて、'kubernetes.io/kubelet-serving' が要求されますので、同様に承認します。

```
$ oc get csr | grep -i pending
csr-qzf8l                                        77s     kubernetes.io/kubelet-serving                 system:node:worker02.cluster-myhome.lab                                           <none>              Pending
csr-xh4vk                                        75s     kubernetes.io/kubelet-serving                 system:node:worker01.cluster-myhome.lab                                           <none>              Pending
$ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve
certificatesigningrequest.certificates.k8s.io/csr-qzf8l approved
certificatesigningrequest.certificates.k8s.io/csr-xh4vk approved
$ 

```

この操作が完了すると、worker ノードのクラスターへの参加が完了し、後続の処理が継続されます。

```
[toaraki@bastion ~]$ oc get node
NAME                          STATUS     ROLES                  AGE     VERSION
master01.cluster-myhome.lab   Ready      control-plane,master   58m     v1.27.6+b49f9d1
master02.cluster-myhome.lab   Ready      control-plane,master   57m     v1.27.6+b49f9d1
master03.cluster-myhome.lab   Ready      control-plane,master   58m     v1.27.6+b49f9d1
worker01.cluster-myhome.lab   NotReady   worker                 3m32s   v1.27.6+b49f9d1
worker02.cluster-myhome.lab   NotReady   worker                 3m34s   v1.27.6+b49f9d1
[toaraki@bastion ~]$ 
```



#### インストールプロセス完了の待機

再び、openshift-install のwait-for オプションを指定して、インストールプロセスが完了するのを待ちます。
```
$ openshift-install --dir cluster-ocp wait-for install-complete --log-level=debug
DEBUG OpenShift Installer 4.14.3                  
DEBUG Built from commit cebc8ab0fd6f8b66197f5a4e058ea4913dbb587c
DEBUG Loading Install Config...                   
DEBUG   Loading SSH Key...                          
DEBUG   Loading Base Domain...                      
DEBUG     Loading Platform...                       
DEBUG   Loading Cluster Name...                     
DEBUG     Loading Base Domain...                   
DEBUG     Loading Platform...                       
DEBUG   Loading Networking...                       
DEBUG     Loading Platform...                       
DEBUG   Loading Pull Secret...                      
DEBUG   Loading Platform...                         
DEBUG Using Install Config loaded from state file  
DEBUG Loading Agent Config...                       
INFO Waiting up to 40m0s (until 10:18PM JST) for the cluster at https://api.cluster-ocp.myhome.lab:6443 to initialize... 
DEBUG Still waiting for the cluster to initialize: Cluster operators authentication, console, ingress, monitoring are not available 
DEBUG Still waiting for the cluster to initialize: Cluster operators authentication, console, monitoring are not available 
...ommited
DEBUG Cluster is initialized                        
INFO Checking to see if there is a route at openshift-console/console... 
DEBUG Route found in openshift-console namespace: console 
DEBUG OpenShift console route is admitted          
INFO Install complete!                             
INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/home/toaraki/cluster-ocp/auth/kube
config' 
INFO Access the OpenShift web-console here: https://console-openshift-console.apps.cluster-ocp.myhome.lab 
INFO Login to the console with user: "kubeadmin", and password: "xxxxxxxxxxxxxx" 
DEBUG Time elapsed per stage:                       
DEBUG Cluster Operators: 10m41s                     
INFO Time elapsed: 10m41s                          
$ 
```

コマンドが完了するとk、下記の様にクラスターの認証情報が表示されます。

```
INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/home/toaraki/cluster-ocp/auth/kube
config' 
INFO Access the OpenShift web-console here: https://console-openshift-console.apps.cluster-ocp.myhome.lab 
INFO Login to the console with user: "kubeadmin", and password: "xxxxxxxxxxxxxx" 
```

#### 確認

実際に環境へアクセスして、OpenShiftが稼働していることを確認します。


cluster-operator の確認

```
$ export KUBECONFIG=~/cluster-ocp/auth/kubeconfig 
$ oc get co
NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
authentication                             4.14.3    True        False         False      12m     
baremetal                                  4.14.3    True        False         False      64m     
cloud-controller-manager                   4.14.3    True        False         False      78m     
cloud-credential                           4.14.3    True        False         False      86m     
cluster-autoscaler                         4.14.3    True        False         False      63m     
config-operator                            4.14.3    True        False         False      68m     
console                                    4.14.3    True        False         False      17m     
control-plane-machine-set                  4.14.3    True        False         False      63m     
csi-snapshot-controller                    4.14.3    True        False         False      66m     
dns                                        4.14.3    True        False         False      63m     
etcd                                       4.14.3    True        False         False      65m     
image-registry                             4.14.3    True        False         False      52m     
ingress                                    4.14.3    True        False         False      20m     
insights                                   4.14.3    True        False         False      61m     
kube-apiserver                             4.14.3    True        False         False      51m     
kube-controller-manager                    4.14.3    True        False         False      58m     
kube-scheduler                             4.14.3    True        False         False      60m     
kube-storage-version-migrator              4.14.3    True        False         False      54m     
machine-api                                4.14.3    True        False         False      59m     
machine-approver                           4.14.3    True        False         False      66m     
machine-config                             4.14.3    True        False         False      64m     
marketplace                                4.14.3    True        False         False      63m     
monitoring                                 4.14.3    True        False         False      18m     
network                                    4.14.3    True        False         False      68m     
node-tuning                                4.14.3    True        False         False      66m     
openshift-apiserver                        4.14.3    True        False         False      54m     
openshift-controller-manager               4.14.3    True        False         False      54m     
openshift-samples                          4.14.3    True        False         False      53m     
operator-lifecycle-manager                 4.14.3    True        False         False      65m     
operator-lifecycle-manager-catalog         4.14.3    True        False         False      65m     
operator-lifecycle-manager-packageserver   4.14.3    True        False         False      54m     
service-ca                                 4.14.3    True        False         False      68m     
storage                                    4.14.3    True        False         False      68m     
$ 
$ oc get clusterversion
NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.14.3    True        False         13m     Cluster version is 4.14.3
$ 
```

Webブラウザーでのアクセス
`openshift-install --dir cluster-ocp wait-for install-complete`の最終段階で出力された認証情報を使用してログインします。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/311140/ef69f469-5ecd-cf8c-c304-58bcdf00e167.png)

ログインに成功すると、ダッシュボードが表示されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/311140/4c8abf2a-5da0-2143-be46-3a1e1646a16f.png)


以上

ここまでで、Anyplatform InstallationによるOpenShiftクラスター master 3 , worker 2 構成のインストールが完了となります！

おつかれさまでした〜