Control Plane Migration Assistant を試してみた

# CPMA の概要

Control Plane Migration Assistant (CPMA) は OpenShift の Master ノードのマイグレーションを手助けする cli ベースのツールです。OpenShift 3.7 もしくはそれ以降の OpenShift から OpenShift Container Platform 4.2 の違いをレポートとして出力してくれます。

ここでは、OpenShift3 と OpenShift4 の Control Plane 変更がサポートされているか、一部サポートなのか、まったく互換性がないかについてのレポートを試しに出力してみようと思います。

# インストールステップ

Red Hat Customer Portal の Downloads → Red Hat OpenShift Container Platform を選択し、以下の表示される画面のバージョンに "CPMA" と入力します。

<img width="1076" alt="Screen Shot 2019-11-20 at 23.03.49.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/155313/d79b947f-da96-3d55-96e4-66968bea3ab7.png">

CPMA ツールは Windows, Mac, Linux の 3 種類が用意されています。環境に合わせてダウンロードしてください。私の環境では Linux を使用します。

`/tmp/` ディレクトリへダウンロードし、`/usr/local/bin/` へ展開し、実行権限を付与します。

```shell
tar -xzvf /tmp/cpma-1.0.1-10-linux.tar.gz -C /usr/local/bin/
chmod +x cpma
```

# レポートの生成

## 実行方法の確認

CPMA の実行には cluster-admin の権限が必要なことと、OpenShift 3.7 以降である必要があります[^1]。
コマンドの実行は OpenShift 3 系のクラスタに対して API が実行できる必要があります。また `master-config.yaml` を解析対象とする場合は以下のいずれかを満たす必要があります。

+ Master ノードへ SSH ログインが可能
+ Master ノードの `/etc/origin`, `/etc/etcd`, `/etc/crio`, `/etc/containres` ディレクトリを `<Master ノード名>/etc/...` という形式でローカルホストの任意の場所に配置


## 今回の検証環境

+ OpenShift v3.11.59
+ CPMA v1.0.1

## 実行

OpenShift 3 に `cluster-admin` 権限のユーザーでログインしていること確認します。

```console
# oc whoami
system:admin
```

さっそく実行します。OpenShift 4 のクラスタに移行できる設定を反映するためのマニフェストを生成することも出来ますが、今回は省略します。

```console
# ./cpma --manifests=false
```
対話形式で、入力を求められますので1つ1つ入力していきます。特別難しいことは聞かれないため、素直に1つ1つ入力してください。コマンドの実行サーバは Master ノードへ SSH が可能な場所を利用しました。

```shell
? Do you wish to save configuration for future use? true
? What will be the source for OCP3 config files? Remote host
? Path to crio config file /etc/crio/crio.conf
? Path to etcd config file /etc/etcd/etcd.conf
? Path to master config file /etc/origin/master/master-config.yaml
? Path to node config file /etc/origin/node/node-config.yaml
? Path to registries config file /etc/containers/registries.conf
? Do wish to find source cluster using KUBECONFIG or prompt it? KUBECONFIG
? Select cluster obtained from KUBECONFIG contexts loadbalancer-713b-example-opentlc-com:443
? Select master node master1.713b.internal
? SSH login ec2-user
? SSH Port 22
? Path to private SSH key /root/.ssh/713bkey.pem
? Path to application data, skip to use current directory (.)
```

出力ログは次のとおりです。

```shell
INFO[30 Nov 19 01:29 UTC] Starting manifest and report generation
INFO[30 Nov 19 01:29 UTC] Transform:Starting for - API
INFO[30 Nov 19 01:29 UTC] APITransform::Extract
INFO[30 Nov 19 01:29 UTC] APITransform::Transform:Reports
INFO[30 Nov 19 01:29 UTC] Transform:Starting for - Cluster
INFO[30 Nov 19 01:29 UTC] ClusterTransform::Transform:Reports
INFO[30 Nov 19 01:29 UTC] ClusterReport::ReportQuotas
INFO[30 Nov 19 01:29 UTC] ClusterReport::ReportPVs
INFO[30 Nov 19 01:29 UTC] ClusterReport::ReportNamespaces
INFO[30 Nov 19 01:29 UTC] ClusterReport::ReportNodes
INFO[30 Nov 19 01:29 UTC] ClusterReport::ReportRBAC
INFO[30 Nov 19 01:29 UTC] ClusterReport::ReportStorageClasses
INFO[30 Nov 19 01:29 UTC] Transform:Starting for - Crio
INFO[30 Nov 19 01:29 UTC] CrioTransform::Extract
WARN[30 Nov 19 01:29 UTC] Skipping Crio: No configuration file available
INFO[30 Nov 19 01:29 UTC] Transform:Starting for - Docker
INFO[30 Nov 19 01:29 UTC] DockerTransform::Extract
INFO[30 Nov 19 01:29 UTC] DockerTransform::Transform:Reports
INFO[30 Nov 19 01:29 UTC] Transform:Starting for - ETCD
INFO[30 Nov 19 01:29 UTC] ETCDTransform::Extract
INFO[30 Nov 19 01:29 UTC] ETCDTransform::Transform:Reports
INFO[30 Nov 19 01:29 UTC] Transform:Starting for - OAuth
INFO[30 Nov 19 01:29 UTC] OAuthTransform::Extract
INFO[30 Nov 19 01:29 UTC] OAuthTransform::Transform:Reports
INFO[30 Nov 19 01:29 UTC] Transform:Starting for - SDN
INFO[30 Nov 19 01:29 UTC] SDNTransform::Extract
INFO[30 Nov 19 01:29 UTC] SDNTransform::Transform:Reports
INFO[30 Nov 19 01:29 UTC] Transform:Starting for - Image
INFO[30 Nov 19 01:29 UTC] ImageTransform::Extract
INFO[30 Nov 19 01:29 UTC] ImageTransform::Transform:Reports
INFO[30 Nov 19 01:29 UTC] Transform:Starting for - Project
INFO[30 Nov 19 01:29 UTC] ProjectTransform::Extract
INFO[30 Nov 19 01:29 UTC] ProjectTransform::Transform:Reports
INFO[30 Nov 19 01:29 UTC] Flushing reports to disk
INFO[30 Nov 19 01:29 UTC] Report:Added: report.json
INFO[30 Nov 19 01:29 UTC] Report:Added: report.html
INFO[30 Nov 19 01:29 UTC] Succesfully finished transformations
```

コマンドの実行時間は 20 秒位です。実行後、カレントのディレクトリに以下のようなファイルやディレクトリが作成されます。

```console
# ls -la
total 42872
drwxr-xr-x.  3 root root      101 Nov 30 01:29 .
dr-xr-x---. 15 root root     4096 Nov 30 01:29 ..
-rw-r--r--.  1 root root    31178 Nov 30 01:29 cpma.log
drwxr-x---.  3 root root       17 Nov 28 07:36 master1.713b.internal
-rw-r--r--.  1 root root  1107956 Nov 30 01:29 report.html
-rw-r-----.  1 root root   113290 Nov 30 01:29 report.json
```

**cpma.log** : コマンドの実行ログが JSON 形式で出力されます。
**master1.713b.internal** : Master ノードの設定ファイルが Master ノード名のディレクトリとして保存されます。
**report.hrml** : html 形式のレポート結果
**report.json** : JSON 形式のレポート結果

# レポートの内容確認

report.html をダウンロードし、ブラウザで表示します。`Cluster report` と `Component report` の 2 つのカテゴリが表示されます。

<img width="1006" alt="Screen Shot 2019-11-30 at 10.38.57.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/155313/3b10a7ec-791a-ceaf-a130-80fe13df8a01.png">

## Cluster Report の内容確認

`Cluster Report` の文字をクリックすると、以下のような項目が表示されます。

<img width="1003" alt="Screen Shot 2019-11-30 at 10.41.05.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/155313/2c47d52f-84b4-d102-647e-4bfd8ec4adad.png">

`Nodes` 項目をクリックすると、各ノードの情報が表示されます。

<img width="984" alt="Screen Shot 2019-11-30 at 10.41.48.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/155313/4be790b2-69eb-ce54-e719-2f3f74956bb0.png">

`Cluster report` には OpenShift 3 のクラスターのリソースの情報が収集されているようです。

## Component Report

<img width="1258" alt="Screen Shot 2019-12-01 at 0.14.04.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/155313/1d7fc693-2525-54f1-27d2-c1c9e40a37cc.png">

`Component Report` の項目は先程とは少し観点が異なります。各コンポーネントの設定項目が OpenShift 4 へ移行可能であるか、できないか等が記載されています。

いくつか項目を覗いてみましょう。一番上の API を開いてみます。

<img width="1253" alt="Screen Shot 2019-12-01 at 0.18.59.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/155313/1ae906bf-4d49-91a1-ac9d-b82fdb5af61f.png">

API の Port 番号と Certificate について記載されています。 項目の詳細については GitHub[^2] には記載されていないため説明は省きます。

コメントをには、Port に関しては OpenShift 4 では 6443 を利用していること、変更する手段が無いことが説明されています。

`Docker` はどうでしょうか。

<img width="1225" alt="Screen Shot 2019-12-01 at 0.31.16.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/155313/b67206f8-a9f6-96b8-f6db-33fc035d68f0.png">

OpenShift 4 から Container Runtime は CRI-O となってます[^3]。明らかではありますがちゃんと書かれているのは助かります.

# まとめ

OpenShift 3.11 のクラスターに対して CPMA (Control Plane Migration Assistant) ツールを試しに実行してみました。

レポートは HTML 形式で取得できるため非常に見やすい形式で確認でき、それぞれのコメントから設定変更が可能かどうかまで情報が得られ、バージョンが異なるクラスターの設定の違いを確認できるのは便利ですね。

もうすこし複雑な設定をしている環境で試すと面白かったかもしれません。

[^1]: https://docs.openshift.com/container-platform/4.2/migration/migrating-3-4/migrating-openshift-3-to-4.html#migration-using-cpma_ocp-3-to-4

[^2]: https://github.com/fusor/cpma

[^3]: https://docs.openshift.com/container-platform/4.2/architecture/understanding-development.html#container-build-tool-options