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

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

最近 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.



ツイッター(X)が API 制約を含めて色々と不便になってしばらく経過しました。ツイッターでリツイートボットとか作ってた個人のものはほぼ全滅状態ですが、さすがに「しばらく待てばまた使えるようになる、、」などと楽観的には考えない方が良さそうな感じですね。

世の中には使いにくくなったツイッターの後釜を狙う SNS も多く出てきましたが、今のところはまだツイッターを使っている人が圧倒的多数の印象です。まあ開発者的にはツイッターはもう見限ってる人も少なくないんでしょうけど、SNS はあくまで「発信の場」であって、使っているのは開発者ばかりじゃないですからね。メッセージを届ける先の規模含めると、使い勝手が現状維持ならまだしばらくツイッターが使われていくのでしょう。


一方で、とはいえ多くの SNS が新たに生まれてきてはいます。実は自分も「お絵描き SNS」という位置づけの MyDoodles なんていうものを密かにリリースしていたりもするのですが、、、そんな中でツイッターの共同創業者の一人だったジャック・ドーシーさんが新たに立ち上げた分散型 SNS である Bluesky Social (以下 "Bluesky")はツイッターに似たインターフェースを持ち、リリースからしばらくは招待制で運用されていましたが、先ごろ招待制が撤廃されて誰でもアカウントを作れるようになりました。比較的早い段階から API も公開されており、開発者視点では「次に来るのはこれかも」と期待しています。


そんな Bluesky の API を使って、ツイッターでは(個人では事実上)作れなくなってしまったボットを作ってみることにしました。自分が作ろうと思ったのは拙作マンホールマップが持つ機能の1つである「今日のマンホール」を午前零時に自動でつぶやくボットです。実はこれまでは私自身が人間ボットになって(笑)今日のマンホールを手動でつぶやいていたのですが、これを Bluesky 内で自動化する、というものです。ボットとしての基本的な考え方はツイッターの頃と大きく変わるものではないのですが、分散 SNS である Bluesky の、まだ充分に熟しているとは言えない API を使って実装することはチャレンジでもあり、色々面倒な考慮も必要にはなるのですが、とりあえず作れそうだったので、その中身の解説をするのが本ブログエントリの目的です。なお以下で紹介する内容は 2024-02-12 時点の情報であることをご了承ください。


【開発環境】
まず Bluesky API を紹介している本家ページがこちらです:
https://www.docs.bsky.app/docs/get-started

2024021201


SDK としては Node.js と Python 向けに提供されているようですが、Curl からも使える REST API があるようなので REST API でプログラミングするつもりであれば事実上プログラミング言語に制約はないことになります。今回以下で紹介するプログラミングの環境としては自分が普段使っている Node.js を使うことにします。

Node.js の場合、@atproto/api というライブラリを使うことで比較的簡単に Bluesky API を使ったアプリケーションの開発ができるようになります。こんな感じでインストールして使います:
$ npm install @atproto/api


【認証】
Bluesky API を使って試しに自分自身の情報でも取得・・・ するのもいいですが、まずは認証を行う必要があります。ツイッターなどでは開発者向けページからアプリケーションを登録して API キーを発行して OAuth 2.0 で・・・ といった手順で認証を行っていました。Bluesky もいずれはそのような形態になるものと思いますが、現時点では OAuth2.0 はサポートされておらず、ユーザー ID とパスワードを使って直接ログインする形になるようです。ちょうど Bluesky の招待制も終わったことなので、自分はこのボット用(というかマンホールマップ用)のアカウントを1つ新たに作成しました。そして Node.js の場合はこのような形で認証(ログイン)を行います:
var { BskyAgent } = require( '@atproto/api' );

var agent = new BskyAgent({
  service: "https://bsky.social"
});
agent.login({
  identifier: "myname@email.com",
  password: "mypassword",
}).then( async function(){
  // ログイン成功後の処理へ
    :
    :
});

"@atoproto/api" ライブラリから BskyAgent をインポートして、メールアドレス(上では "myname@email.com" の部分)とパスワード(同 "mypassword" 部分)を指定してログインします。このあたりはソースコード内に直接記載するのは危険なので、コードの管理方法には注意が必要です。


【ツイートする】
ボットを作るには「ツイートする」(書き込む)機能が必要です。ログイン後に単にテキストをツイートするだけなら簡単です。特に @atproto/api ライブラリを使っていれば post メソッドを使って以下のようにログイン後の処理を一行追加するだけです:
var { BskyAgent } = require( '@atproto/api' );

var agent = new BskyAgent({
  service: "https://bsky.social"
});
agent.login({
  identifier: "myname@email.com",
  password: "mypassword",
}).then( async function(){
  var res = await agent.post( { text: 'Hello, world.'} );
  console.log( {res} );
});

これでログインしたユーザーの権限で "Hello, world." とつぶやくことができます。簡単ですよね、ここまでは。


【facets 処理(リッチテキスト処理)】
テキストをつぶやくのは簡単でした。ツイッターなどではこのテキスト内に他のユーザーへのメンション(@)が含まれていたり、ハッシュタグ(#)やリンクが含まれていると自動的に解釈してリッチテキスト化してくれて(リンクとかを付けてくれて)いましたが、Bluesky API はそうはいきません(そもそも Bluesky にはまだハッシュタグという概念がありません)。この辺りはプログラミング内でリッチテキスト化(Bluesky では「facets 検知」といいます)する必要があります。今回作ろうとしているボットも必ずあるページへのリンクを含む内容になっているので post 実行前の facets 検知が必須です。この辺から少し面倒になってきます。

具体的にはこのようなコードになります:
var { BskyAgent, RichText } = require( '@atproto/api' );

var agent = new BskyAgent({
  service: "https://bsky.social"
});
agent.login({
  identifier: "myname@email.com",
  password: "mypassword",
}).then( async function(){
  var text = "リンクを含むテキスト https://manholemap.juge.me/";

  var rt = new RichText({ text: text });
  await rt.detectFacets( agent );

  var res = await agent.post({
    $type: 'app.bsky.feed.post',
    text: rt.text,
    facets: rt.facets
  });

  console.log( {res} );
});

まずリッチテキスト化処理を行うために @atproto/api ライブラリから BskyAgent だけでなく RichText もインポートしておきます。そしてリンクなどのリッチテキスト化が必要なテキストを RichText で初期化した結果を変数 rt で受け取り、更に detectFacets() 処理を実行します。するとテキスト部分は rt.text に、facets 情報が rt.facets にそれぞれ格納されます。ツイッターではこの辺りの処理が自動化されていたので楽でしたが、Bluesky でもここまでライブラリが用意されているのでさほど大変ではないですね。

最後に facets 処理した結果を post します。先のプレーンテキストでは text 要素だけを post していましたが、リッチテキストの場合は少し情報を加えてあげる必要がありますが、これでテキスト内の URL 部分はリンクになってポストされます。


【オープングラフ処理(OGP対応)】
ツイッターなど多くの SNS ではリンクを含む情報をポストすると、そのリンク先の内容の一部(テキストや画像)が埋め込まれる形で表示されます。これは OGP と呼ばれる規格で、リンク先が OCP 規格に沿って作られたページであれば、その情報を使って実現できるものです。

Bluesky の場合もリンク先の情報を埋め込むことはできるのですが、API でつぶやく場合は(現状では)この部分を全て手作業で行う必要があります。具体的にはこんな感じです:
var { BskyAgent, RichText } = require( '@atproto/api' );
var { parse } = require( 'node-html-parser' );

var agent = new BskyAgent({
  service: "https://bsky.social"
});
agent.login({
  identifier: "myname@email.com",
  password: "mypassword",
}).then( async function(){
  var text = "リンクを含むテキスト https://manholemap.juge.me/";

  //. OGP
  var url = "https://manholemap.juge.me/";
  var resp = await fetch( url );
  var html = parse( await( resp.text() ) );
  var title = html.querySelector( "meta[property='og:description']" ).getAttribute( "content" );

  //. embed image
  var ogpImg = html.querySelector( "meta[property='og:image']" ).getAttribute( "content" );
  var blob = await fetch( ogpImg );
  var buffer = await blob.arrayBuffer();
  var response = await agent.uploadBlob( new Uint8Array( buffer ), { encoding: "image/jpeg" } );
  var embed_params = {
    $type: "app.bsky.embed.external",
    external: {
      uri: "https://manholemap.juge.me/",
      thumb: {
        $type: "blob",
        ref: {
          $link: response.data.blob.ref.toString()
        },
        mimeType: response.data.blob.mimeType,
        size: response.data.blob.size
      },
      title: title,
      description: title
    }
  };

  var rt = new RichText({ text: text });
  await rt.detectFacets( agent );

  var res = await agent.post({
    $type: 'app.bsky.feed.post',
    text: rt.text,
    facets: rt.facets,
    embed: embed_params
  });

  console.log( {res} );
});

まず URL のリンク先情報を解析するために node-html-parser ライブラリをインポートしておきます。そしてリンク先の URL(上では "https://manholemap.juge.me/")を fetch して HTML を取得します。OGP の規格に沿って作られたページであれば、その画像は HTML 内で <meta property="og:image" content="***" /> の *** 部分に指定されることになっているのでその値を取り出します。そして再度その画像 URL を fetch してバイナリデータを取り出し、agent 変数を使ってアップロードします。そのアップロード結果の情報等を使って OGP の埋め込みデータ(embed_params 変数)を作成します。埋め込みデータを作ることができたら、その値を embed パラメータに加えて post する、という流れになります。これで OGP に対応したポスト処理を Node.js で行うことができるようになりました。


【サンプルソースコード公開】
後はこの実行を自動化することになりますが、今回は自分が使っているサーバーの crontab を使って日本時間の午前零時ちょうどに実行するようにしました。具体的なコードは後述しますが、大まかには、
(1)日本時間午前零時になったら、マンホールマップの「今日のマンホール」取得 API を呼び出し、
(2)その結果からリンク先 URL やポストするテキストを生成し、
(3)リンク先 URL の OGP 情報を使って画像やタイトルなどを取り出して、埋め込み、
(4)facets 処理を加えた上でポストする

という流れを行っています。そしてそのサンプルソースコードを以下で公開しています:
https://github.com/dotnsf/bsky_manhotalk_bot/blob/main/motd.js


上では解説していない部分を1点だけ。上述のように現状の Bluesky API は認証情報を ID とパスワードを直接指定する形で実行する必要があります。上のリンク先を見るとわかるのですが、今回公開したサンプルソースコードには ID やパスワードは含まれておらず、このソースコードを実行する際の環境変数から取得するようにしています。したがってこのソースコードを実行する時に、
$ BSKY_ID=myname@email.com BSKY_PW=mypassword node motd.js

といった具合に BSKY_ID 環境変数と BSKY_PW 環境変数にそれぞれ Bluesky へのログイン ID とパスワードを指定して実行することで正しく動くようにしています。

そうして作ったマンホールマップ・ボットはこちらのアカウントで公開しています:
https://bsky.app/profile/manholemap.bsky.social

2024021200


↑ツイッターとちがって Bluesky のアカウントを持っていない人でも見ることはできますが、可能であればアカウントを作ってフォローしてください。「今日のマンホール」が登録されている日全てで午前零時になると教えてくれます(登録されていない日もあります)。

とりあえず現時点では「今日のマンホール」専用で動くボットですが、いずれハッシュタグが実装されたら #manhotalk ハッシュタグを検索して・・といった挙動や、ちょっとした会話にも挑戦するつもりでいます。

相当限られたケースになると思うのですが、とある目的で、、、
 ・あるサーバー(物理サーバー または 仮想サーバー)上に、
 ・RHEL (または互換 OS)をインストールすると仮定した場合の、
  ・NIC の MAC アドレス
  ・NIC が認識された時のデバイス名("eth0" など)
  ・ストレージディスクが認識された時のデバイス名("/dev/sda" など)
を事前に知っておきたい、ということがありました(知ってる人なら、どういう目的でこれらの情報が必要なのかわかると思う)。 

「実際にインストールすればわかるじゃん」ということでもあるんですが、対象サーバー数が多かったりして、特殊な方法でまとめてインストールするようなケースで、その特殊なインストール方法を利用する際に必要な情報だと思ってください。そういうわけでインストールそのものの手間は取りたくないけど、上の情報だけ事前に知っておきたいのだが、具体的にどうすればよいか? というのが本ブログエントリのテーマです。

で、以下がその答の1つだと思っています。もう少し簡単に調べる方法があれば教えてください。

まず普通に DVD/ISO を使い、初期インストール時と同じようにブートします:
rhel9_fdisk_001


RHEL の場合、最初に GUI のインストーラー画面が起動します。通常インストールだとまずインストール言語を指定して、、となるのですが、今回はインストールが目的ではないので、この画面に到達したことを確認するだけで OK です:
rhel9_fdisk_002


おもむろに Ctrl + Alt + F2(Ctrl キーと Alt キーを押して、押したまま更に F2 キーも押す)を実行します。すると GUI のインストール画面を実行したままいったん抜けて TTY2 という、root ユーザーで利用できる別画面に切り替わります:
rhel9_fdisk_003


この画面内で必要な情報を調べることができます(そのための最小限のコマンドも使えるようになっています)。まず NIC の MAC アドレスとデバイス名を調べるには "ip a" というコマンドを実行します:
rhel9_fdisk_004


"ip a" コマンドを実行すると、認識されているネットワークインターフェースと、その情報が一覧表示されます。上の例だと "lo" と "enp0s3" という2つのインターフェースが認識されていますが、"lo" はローカルホスト用なのでこちらではなく、もう一つの "enp0s3" が目的のデバイス名ということがわかります。またその中に MAC アドレスも "08:00:27:df:e7:b0" と記載されていますね。


次にストレージディスクのデバイス名も調べます。今度は "fdisk -l" コマンドを実行します:
rhel9_fdisk_005


するとストレージデバイスの一覧が表示されます。ここは結構多くて探すのが少し難しいのですが容量などを参考にしながら探してみてください。上の画面では一番上に "/dev/sda" というディスクを認識しているようです。容量もあっているので、おそらくこれ("/dev/sda")がストレージのデバイス名ということになりそうです。


これで目的は達成しました。OS をインストールしない場合はこのまま終了していいですし、インストールする場合は Ctrl + Alt + F6(Ctrl キーと Alt キーを押して、押したまま更に F6キーも押す)を実行すると元の GUI インストーラー画面に戻れるので、続きの作業を行ってください:
rhel9_fdisk_006


 

このページのトップヘ