まだプログラマーですが何か?

プログラマーネタ中心。たまに作成したウェブサービス関連の話も https://twitter.com/dotnsf

タグ:ocp

最近 OCP(Openshift Container Platform) について調べることが多かったので、何回かに分けてアウトプットしていこうと思います。

今回は「OCP のアップグレードパス」についてです。OCP のアップグレード(バージョンアップ)で特に頭の痛い問題の1つが「アップグレードパス」と呼ばれるバージョンアップ時に踏む段階のことです。

より具体的な例で考えてみましょう。例えば、現在 OCP 4.4.6 というバージョンを使っていると仮定します。なんらかの理由でこれを OCP 4.6.4 というバージョンにアップグレードしたい、という前提のもとで以下を記載していきます。


【アップグレードパス】
この辺りの事情にあまり詳しくない人だと「OCP 4.4.6 から OCP 4.6.4 へのアップグレードがそんなに不便なのか?」という疑問を持つかもしれません。わかりにくい所もあるのですが、最大の問題は「そもそも OCP 4.4.6 から OCP 4.6.4 へ直接アップグレードできるのか? 直接アップデートできない場合はどのような順で実行していけばアップデートできるのか?」という所から解決していく必要がある点にあります。この「どのような順で実行していく」のかという順序のことを「アップグレードパス」といいます。

例えばですが、仮に 4.4.6 から 4.6.4 への直接アップグレードが可能であった場合(実際はできないんですけど)、アップグレードパスは「 4.4.6 → 4.6.4 」ということになります。一方、もしも間に 4.5.0 をはさんで 4.4.6 から 4.5.0 にアップグレードし、4.5.0 から 4.6.4 にアップグレードするという2段階のアップグレードを行う必要がある場合(実際は更に複雑なんですが)、アップグレードパスは「 4.4.6 → 4.5.0 → 4.6.4 」ということになる、というわけです。


【アップグレードパスの調べ方】
さて、では実際に 4.4.6 から 4.6.4 へアップグレードする場合のアップグレードパスはどのように調べればよいのでしょうか? 実はこれが結構面倒だったりします。。

まず RedHat 提供のアップグレードパスを探すサービスがあります:
https://access.redhat.com/labs/ocpupgradegraph/update_path

ただこのサイト、比較的古いバージョンが対象だとやけに重くなってしまうのです。またアップグレード前後のバージョン差が大きいケースだと「アップグレードパスが見つからない」みたいな結果が表示されることもあり、なんかちょっとよくわからない(苦笑)感じだったりします。


というわけで、上記サービスに頼らないアップグレードパスの探し方を紹介します。具体的にはまずゴールとなるバージョン(今回だと 4.6.4)のリリースノートを調べる必要があります。OCP のバージョンごとのリリースノートはオンラインで参照することができ、その URL は以下の通りです:
https://mirror.openshift.com/pub/openshift-v4/clients/ocp/(バージョン)/release.txt

例えばバージョンが 4.6.4 であれば、以下の URL を参照します:
https://mirror.openshift.com/pub/openshift-v4/clients/ocp/4.6.4/release.txt

以下のような内容が表示されます:
2024030701


はじめの十数行だけを表示するとこのようになっています:
Client tools for OpenShift
--------------------------

These archives contain the client tooling for [OpenShift](https://docs.openshift.com).

To verify the contents of this directory, use the 'gpg' and 'shasum' tools to
ensure the archives you have downloaded match those published from this location.

The openshift-install binary has been preconfigured to install the following release:

---

Name:      4.6.4
Digest:    sha256:6681fc3f83dda0856b43cecd25f2d226c3f90e8a42c7144dbc499f6ee0a086fc
Created:   2020-11-11T15:13:14Z
OS/Arch:   linux/amd64
Manifests: 444

Pull From: quay.io/openshift-release-dev/ocp-release@sha256:6681fc3f83dda0856b43cecd25f2d226c3f90e8a42c7144dbc499f6ee0a086fc

Release Metadata:
  Version:  4.6.4
  Upgrades: 4.5.16, 4.5.17, 4.5.18, 4.5.19, 4.6.1, 4.6.2, 4.6.3
  Metadata:
    description: 
  Metadata:
    url: https://access.redhat.com/errata/RHBA-2020:4987
  :
  :

↑の赤字部分に着目します。"Release Metadata:" と書かれた部分の下にバージョンに関する情報が表示されています。まず "Version:" はこのリリースノートが対象としているバージョン(4.6.4)が表示されています。 そしてその下の行の "Upgrades:" に着目してください。この例だと "4.5.16, 4.5.17, 4.5.18, 4.5.19, 4.6.1, 4.6.2, 4.6.3" と書かれていますね。

これはつまり「バージョン 4.6.4 に直接アップグレードできるバージョンは 4.5.16, 4.5.17, 4.5.18, 4.5.19, 4.6.1, 4.6.2, 4.6.3 のいずれかのみ」であることを示しています。残念ながら元のバージョンである 4.4.6 が含まれていないので、少なくとも1回のアップグレードで 4.4.6 から 4.6.4 へはアップグレードできないことも分かります。

では最終ゴールである 4.6.4 へは(上のバージョンの中のどれでもいいんですが、なるべく回数を減らしたいので最も遠い) 4.5.16 からアップグレードするとしましょう。次に調べる必要があるのは「4.4.6 から 4.5.16 へ直接アップグレードできるのか?」です。

これも同様にして 4.5.16 のリリースノート(https://mirror.openshift.com/pub/openshift-v4/clients/ocp/4.5.16/release.txt)を開き、4.5.16 にアップグレード可能なバージョンを調べると、"4.4.13, 4.4.14, 4.4.15, 4.4.16, 4.4.17, 4.4.18, 4.4.19, 4.4.20, 4.4.21, 4.4.23, 4.4.26, 4.4.27, 4.4.28, 4.4.29, 4.4.30, 4.5.2, 4.5.3, 4.5.4, 4.5.5, 4.5.6, 4.5.7, 4.5.8, 4.5.9, 4.5.11, 4.5.13, 4.5.14, 4.5.15" という結果になることが分かります。残念ながら 4.4.6 は含まれていないので、更に段階を経たアップグレードが必要になることが分かります:
2024030702


同様にして、ここでの中継バージョンを 4.4.13 とみなし、4.4.13 のリリースノート(https://mirror.openshift.com/pub/openshift-v4/clients/ocp/4.4.13/release.txt)を調べると、、今度は "4.4.6" が含まれていることがわかります。4.4.6 から 4.4.13 へのアップグレードは可能でした:
2024030703


ここまでの結果を総合すると、4.4.6 から 4.6.4 へのアップグレードパスの1つとして
4.4.5 → 4.4.13 → 4.5.16 → 4.6.4

があることが確認できました。つまり 4.4.6 から 4.6.4 へは少なくとも3回に分けてアップグレードを実施する必要がある、ということになります。

今回の例では 4.4.6 から 4.6.4 という固定バージョンでのアップグレードパスと、その調べ方を紹介しましたが、アップグレードパスの調べ方はどのバージョンからどのバージョンへ向かう場合も同様です。上で紹介した方法を使って、目的バージョンから「このバージョンにアップグレードできる最も古いバージョンは?」を繰り返し調べていくことで、最短回数でのアップグレードパスを見つけることができるようになります。

・・・でも、ちょっと面倒ですよね。そこでこの処理をツール化してみました。


【アップグレードパスを調べるツール】
上で紹介した処理を自動的に調べるツールを Node.js で作ってみました。MIT ライセンスで公開しているので商用含めて利用・改変もご自由に:
https://github.com/dotnsf/ocp-upgrade-path


Node.js がインストールされた PC 上で、上記 URL からソースコードを clone またはダウンロードして展開します。最初の実行前に一回だけ "npm install" で外部ライブラリをインストールしておく必要があります。

実行時はコマンドラインから以下のように指定して実行します:
$ node app (現在のバージョン) (アップグレード後のバージョン)

上のように現在のバージョンが 4.4.6 、アップグレード後のバージョンが 4.6.4 であったとすると、以下のように指定して実行することになります:
$ node app 4.4.6 4.6.4

実行結果は以下のように出力されます:
$ node app 4.4.6 4.6.4
currentversion = 4.4.6
targetversion = 4.6.4

4.4.6 -> 4.4.13 -> 4.5.16 -> 4.6.4

不可能なパターンを指定するとアップグレードパスに impossible と表示されます(新しいバージョンから古いバージョンへのアップグレードを指定した例です):
$ node app 4.6.4 4.4.6
currentversion = 4.6.4
targetversion = 4.4.6

4.6.4 -> (impossible) -> 4.4.6

またバージョンで指定できるパターンは正式リリース対象の (数字).(数字).(数字) だけです。バージョン文字列内に "nightly" などの文字を含む正式リリースではないバージョンも存在していますが、このツールでは対象外としています。

ちゃんとテストしたわけではない(というかテストできない)のですが、現時点でリリースされていない未来のバージョンについても、その未来バージョンがリリースされて、リリースノートも同様に提供されていれば、その未来バージョンへのアップグレードパスも表示できるようになるはずです。

ウェブ化してもっと気軽に(Node.js がインストールされていなくても)使えるようにすることも考えたのですが、「OCP をバージョンアップする」作業が必要になるようなプロジェクトでは、それなりのエンジニアがプロジェクトに携わっていることが大半だと思ってサボっちゃいました。


「OCP アップグレード版の乗換案内」的なツールができたと思っています。役立つことがあれば嬉しいです。


【参考】
Successfully upgrade OpenShift cluster on a disconnected environment with troubleshooting guide.



RHEL(RedHat Enterprise Linux) を「インターネットから隔離された状態で」使う、というのが本ブログエントリのテーマです。セキュリティ要件など何らかの事情があってインターネットに接続することが許されていない環境下で RHEL を使う、という場合の設定手順を紹介します。

これ、CentOS だと特に意識することもなく、インストール用の DVD などを用意して普通にインストールできるし、(インターネットに接続できない不便さはあっても)そのまま使い続けることもできます。ただ同じことを RHEL でやろうとするとうまくいかないことがあって、それを回避するにはどうすればよいか、を自分なりに調べた内容のアウトプットです。


【RHEL と CentOS との違い】
まず RHEL は CentOS と同じように使えないのでしょうか? その違いは何で、どのような影響があるのでしょうか?

今回のテーマとしてとりあげる問題はサブスクリプションマネージャー(subscription-manager)にあります。RHEL は CentOS とは異なり、サブスクリプションがないと使えません。サブスクリプションは有償のものであったり、開発者向けに無償で提供されているものもありますが、なんらかの登録を行い、その登録情報をインストール中に入力することで使えるようになります(下画面ではインストール中に表示される「Red Hat に接続」という部分で正しいサブスクリプション情報を入力しないと先に進めません。つまりこの時点ではインターネット接続が必要です):
2024010701

2024010702


なお一部のクラウドベンダーでは初めから RHEL がインストールされたイメージを使うことができますが、この場合もサブスクプションを無視して使えているわけではなく、特殊なサブスクリプションが適用された状態になっています(RHEL のサブスクリプション料金がクラウドの料金に含まれているはずです)。サブスクリプションマネージャーはこのサブスクリプション情報を管理するシステムを提供しています。


【サブスクリプションマネージャーが管理しているもの】
このサブスクリプションマネージャーが管理しているものの1つが「yum(dnf) のリポジトリ」です。例えば RHEL の場合、RedHat が提供しているツール類に加えて ansible など RHEL のサブスクリプションを所有している前提で使うことのできるツールが提供されていて、その利用のためのリポジトリ情報(yum などでインストールするためにサーバー情報や鍵情報)がサブスクリプションマネージャーによって管理されています。サブスクリプションマネージャーが yum リポジトリを管理していることで(インターネットに繋がっている RHEL や、特定のクラウド環境内で使っている RHEL は)RHEL 向けに提供されているツールを使うことができる、という仕組みになっています。そしてその仕組みを管理しているのがサブスクリプションマネージャーということになります。


【サブスクリプションマネージャーが有効な場合に不都合となるケース】
そしてこの適用されているサブスクリプション情報は、インストール後の利用時にも影響を与え続けることになります。たとえネットワークインターフェースを無効にするなどしてインターネットに(物理的/論理的に)繋がっていない状況を作り出したとしても、サブスクリプション情報はシステムに残り続けます。

これが「インターネットに接続していない環境」だと不都合な問題が発生します。以下、具体的な画面(VirtualBox 内にインストールした RHEL 9.3 の画面)を交えて紹介します。

まず RHEL 9.3 をインストールします。上述のようにサブスクリプション情報を入力/認証する必要があるため、初期セットアップ時にはインターネット接続が必要です。この時点では VirtualBox 側のネットワーク設定でアダプター割り当てを「NAT」にしていました:
2024010801


この状態で(インターネット接続がある状態で) "yum repolist" を実行して現在有効な yum のリポジトリを確認すると2つのリポジトリが有効に登録されていました。そして "yum install tmux"(tmux というツールをインストールする際のコマンド)を実行すると登録されているリポジトリから必要なモジュールを探し、「インストールしますか?」と聞かれるところまで実行できました("n" を押してインストールをキャンセルします)。期待通りの挙動になっています:
2024010802


この状態からネットワークを無効にします。今回は VirtualBox 側の割り当て設定を「未割当」にしました。RHEL 側からはネットワークアダプターそのものは認識できるが、DHCP などで IP アドレスが割り当てられることもなく、実質的に使えない状態になるはずです。こうすることで物理的なサーバーをインターネットが使えない環境に移動させた時と近い状況が作り出せているはずです:
2024010803


この状態で先ほどと同じコマンドを実行してみます。"yum repolist" を実行すると先ほどと同じ結果になり、リポジトリそのものは2つ登録されたままになっていることがわかります。しかし "yum install tmux" を実行して tmux をインストールしようとすると、今度は(ネットワークが使えず)リポジトリ先にアクセスすることができないため失敗してしまいます。これもここまでは期待通りの挙動と言えます:
2024010804


ただ問題は「使えないリポジトリが登録されたままになっている」点です。この状態から tmux などのツールを追加インストールするにはローカルリポジトリを作成するなどすることで可能ではあるのですが、この使えないリポジトリは邪魔なので消す必要があります。

リポジトリの情報は /etc/yum.repos.d/ フォルダ以下に .repo という拡張子を持ったファイルを用意しておくことでシステムに認識させることができます。RHEL の場合も /etc/yum.repos.d/redhat.repo というファイルが用意されており、ここでサブスクリプション情報に合わせたリポジトリが使えるようになっています。 というわけでいったんこのファイルを(redhat_repo などに)リネームして、RHEL のリポジトリが無効になるよう更新してみます。 本来ならばこれで登録リポジトリは空になるはずだと期待していたのですが、実際にやっていると登録リポジトリは変わらず2つ存在したままで、しかもリネームしたはずの /etc/yum.repos.d/redhat.repo ファイルがいつの間にか復活(!?)していました:
2024010805


これがサブスクリプションマネージャーの挙動です。ansible など RHEL のサブスクリプションがないと使えないリポジトリも含めて管理されており、何かの手違いでサブスクリプション情報が消えてしまわないよう(ansible などがインストールできなくなってしまわないよう)リポジトリ情報はリポジトリファイル以外でも管理されていて、変更が加わってもリポジトリの更新時に再度自動で復活させるような挙動を見せます。

この挙動により RHEL をインターネット接続がない環境で使おうとした際の、上述の「使えないリポジトリが登録されたままになっている」点を解決しようとしてもすぐに元に戻ってしまう、という問題が残ってしまうのでした。


(↓以下補足)
自分だけのケースかもしれませんが少し補足します。上述のようなインターネット接続が使えない環境下で RedHat OCP(OpenShift Container Platform) をローカルインストールしようと試みた際に RedHat が提供している ocp4-helpernode というツールを使おうとしました。 その時も上述のように RedHat のリポジトリが自動で復活する問題を抱えていたのですが、「ローカルリポジトリを作って、自動復活する前に各種ツールをインストールして準備」したつもりでした。 が、それだと最終的に ocp4-helpernode を使おうとした段階になって RedHat のリポジトリが復活してしまい、「準備ツールをインストールした時と環境が異なっている」ことが検知されたようなエラーメッセージ(↓)が表示されて止まってしまいました:

  :
  :
TASK [set_fact] ****************************************************************
ok: [localhost]

TASK [Install needed packages] *************************************************
fatal: [localhost]: FAILED! => {"changed": false, "failures": [], "msg": "Unknown Error occurred: Some packages from local repository have incorrect checksum", "rc": 1, "results": []}

自分の場合はもともとこの環境を作りたくて調べていたのですが、CentOS とは異なり、RHEL だとこのリポジトリを管理するサブスクリプションマネージャーをどうにかしないといけない、ということがわかったのでした。

なお、同じこと(OCP をネットワーク接続のない環境で物理サーバーにインストール)を RHEL ではなく CentOS を使って行うことも検討したのですが、こちらの場合は RHEL のサブスクリプションには含まれている ansible や ansible の関連ツールのインストールが別途必要になったり、上で紹介した ocp4-helpernode 自体が RHEL 向けだけに提供されていたりして、別の部分で余計にややこしそうだったのであきらめました。
(↑以上補足)


というわけで、RHEL のサブスクリプションマネージャーは便利な反面、利用形態によっては邪魔になってしまうケースもあることがわかったのでした。


【サブスクリプションマネージャーを無効にする方法】
前置きの長いブログになってしまいましたが、このような背景からサブスクリプションマネージャーを無効にしたい、という需要も少なからずあるように感じています。もちろん無効にすることで RHEL が管理している最新のリポジトリは使えなくなってしまうし、ansible など RHEL のサブスクリプションと合わせて提供されるツールもインストールできなくなってしまうというリスクがあります。そのリスクを理解した上で「それでも無効にしたい」場合だけ実施するようにしてください(私は責任取れません)

RHEL のサブスクリプションマネージャーは以下のコマンドで無効にできます:
# subscription-manager config --rhsm.manage_repos=0

上述のような「インターネット接続がない環境下でいろいろなツールをセットアップ」しないといけないようなケースでは、まず上のコマンドを実行してサブスクリプションマネージャーを無効化した上で、DVD などから必要なモジュールを取り出し、あるいはファイルのみダウンロードしたりした上で、必要に応じてローカルリポジトリを用意してインストール/セットアップを行う、という手順が必要になると思います。

自分のように OCP をネットワーク接続のない環境でセットアップ、、なんて無茶なことをやろうとする場合に自分が調べてこのブログにまとめた関連情報(躓きそうな箇所に関する情報)を以下に記載しておくので参考にしていただけると嬉しいです:




(参照)
ネットワークが制限された環境でのクラスターのベアメタルへのインストール
OpenShift on Power 完全オフライン環境でのインストール

 

このページのトップヘ