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

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

タグ:redhat

RHEL(RedHat Enterprise Linux) を使っている人は珍しくないと思いますが、RHCOS(RedHat CoreOS、以下 "RHCOS") は名前を聞いたことはあっても使っている人はあまり多くないのではないかと思っています。 そんな RedHat CoreOS 4.15.0 を手元の VirtualBox 仮想環境にインストールし、かつ使いやすいように少しカスタマイズしてみました。その手順を紹介します(VirtualBox に依存した部分はないつもりなので、他の仮想環境や物理環境でも同様に実施できると思っています)。


【RHCOS とは?】
RedHat が提供する Linux カーネルを中心とした軽量な Linux 環境であり、自動化やリモートアップデートの機能があります。現在は RedHat OCP(OpenShift Container Platform) のコンポーネントとしてのみサポートされています。
2024050400



【RHCOS のインストールに必要なもの】
他の Linux にない、CoreOS の特徴の1つでもあるのが「インストーラーがない」です。インストーラーはコア機能の一部ではない(言われてみればまあその通りかも・・)ということなんでしょうかね。 他の Linux の多くはインストール DVD(ISO) が用意されていて、その DVD で起動するとインストーラーが立ち上がって・・・という方法でインストールするものばかりですが、CoreOS ではこの方法は提供されていません。つまりインストーラー無しでインストールする必要があります。

ただこの辺りが全く考慮されていないわけでもありません。インストール用の ISO はダウンロード可能な形で提供されています。ただインストール時に指定する必要のあるホスト名やユーザー名、そのユーザーの公開鍵情報を入力する UI は用意されていません。ではこれらの情報をどのように指定するかというと「HTTP でアクセス可能な外部ファイル(Ignition ファイルといいます)として用意し、インストール時にその URL を指定して取得する」ことになります。したがってインストール時にはインストール先となるサーバー以外に HTTP サーバーが必要になります。

更にはこの「HTTP でアクセス可能な外部ファイル」も用意する必要があるのですが、その作業自体は同 HTTP サーバー上で実行できます。したがって「インストール前の準備作業を行い、インストール時の HTTP サーバーとして稼働するサーバーが同一ネットワーク上に1台必要」ということになります。

今回、このサーバーを CentOS 7(Minimal) で用意しました。他のディストリビューションでも同様に可能だと思いますが、適宜読み替えてください。


【HTTP サーバーと Ignition ファイルの準備】
まず HTTP サーバーとなる CentOS に root 権限でログインし、後述の作業を実行する上で必要になるツールをあらかじめインストールしておきます(HTTP サーバーとして Apache HTTPD を使う前提で以下を説明しています):
# yum install -y httpd wget

この後外部からこの HTTP サーバーへのアクセスがあるので、ファイアウォールを無効にするか、80 番ポートを解放します(以下では CentOS7 のファイアウォールを無効にしています):
# systemctl stop firewalld



また Ignition ファイルは JSON 形式なのですが、編集時には YAML で編集します。編集後に YAML -> JSON の変換を行うのですが、Ignition ファイルとしての変換を実行してくれる butane(以前の名称は fcct)というツールもインストールしておきます:
# cd
# wget https://github.com/coreos/butane/releases/download/v0.20.0/butane-x86_64-unknown-linux-gnu
# mv butane-x86_64-unknown-linux-gnu butane
# chmod +x butane

また RHCOS は、インストール直後はコンソールからのログインができず、外部サーバーからの SSH 接続のみが可能です。その際に利用する鍵ファイルを用意します(既にある鍵ペアを使うことも可能ですが、ここでは新規に作成する前提で紹介します):
# ssh-keygen

"ssh-keygen" というコマンドを入力すると色々パラメータの入力を求められますが、全てそのまま Enter でも構いません(その場合は秘密鍵が ~/.ssh/id_rsa に、公開鍵が ~/.ssh/id_rsa.pub にそれぞれ作成されます):
2024050401


鍵ペアが用意できたら Ignition ファイルを作ります。まずは ignition.yaml というファイル名で以下のような YAML フォーマットのテキストファイルを作ります(赤字はコメントなので、実際には不要です):
variant: fcos
version: 1.0.0
storage:
  files:
    - path: /etc/hostname
      mode: 0644
      contents:
        inline: rhcos (ホスト名)
passwd:
  users:
    - name: core (ログインユーザー名)
      groups:
        - sudo (sudo 権限を与える)
      ssh_authorized_keys:
        - ssh-rsa XXXXXXXXXXXXX(公開鍵ファイル ~/.ssh/id_rsa.pub の内容)XXXXXXXXXXXXXXXX...

RHCOS の特徴でもあるのですが、この Ignition ファイルの中で /etc/hostname の内容を直接書き込む形でホスト名を指定します。またログインユーザー名やその権限(所属グループ)もこの Ignition ファイルの中で指定します。 ssh_authorized_keys の値は(先ほど作成した)鍵ペアの公開鍵ファイルの中身をそのまま1行で記載します。

ignition.yaml ファイルが完成するとこんな↓感じになります:
2024050402


そして butane を使ってこの ignition.yaml ファイルを JSON 形式に変更します:
# ./butane ignition.yaml --pretty --output ignition.json

2024050404


できあがった ignition.json は以下のような内容でした:
2024050405


この ignition.json を HTTP アクセス可能なファイルとしてコピーします:
# cp ignition.json /var/www/html/
# systemctl restart httpd

これで Ignition ファイルは "http://(このサーバーの IP アドレス)/ignition.json" という URL で外部からアクセスできるようになり、RHCOS のインストール時に指定可能なファイルとしての準備が整いました。

なおこのサーバーの IP アドレスは "ip a" というコマンドで調べることができます(下図の例だと "192.168.0.102" であることがわかります):
2024050412


【RHCOS のインストール】
RHCOS をインストールするための ISO ファイルを取得します。RedHat Developer Subscription に(個人または企業アカウントで)登録した上で、RedHat CoreOS のダウンロードサイトから最新版の ISO ファイルをダウンロードします(2024-05-04 時点では 4.15.0 というバージョンが最新で、ファイル名は rhcos-4.15.0-x86_64-live.x86_64.iso でした)。物理サーバーにインストールする場合は DVD などブート可能なメディアに変換しておきます:
2024050406


RHCOS をインストールしたいサーバーにダウンロードした ISO(または DVD)をセットします(図は VirtualBox で ISO を DVD にセットした時の様子):
2024050407


そしてサーバーの電源を ON にします。ISO(DVD) から起動します:
2024050409


起動すると以下のような一般ユーザー(core)のプロンプトが表示される画面になります。これは ISO の Live 環境が起動している状態です:
2024050410


ここでプロンプトに以下のように入力します。"/dev/sda" はインストール先ディスクのデバイス名です(US キーボードレイアウトになっているので注意):
$ sudo coreos-installer install /dev/sda --ignition-url (ignition.json のURL) --insecure-ignition
※最後の "--insecure-ignition" は ignition.json の URL が https ではなく http の場合に必要です。

2024050413


Ignition ファイルへのアクセスができていればインストールが開始されます:
2024050414


インストールはすぐに完了してプロンプトに戻ります:
2024050415


"sudo shutdown -h now" でシャットダウンし、ISO(DVD) を取り除いてから再度起動します:

すると今度はこのような画面で起動します。これは Live DVD で起動した画面ではなく、ディスクにインストールされた RHCOS が起動していることを意味しています(画面内に IP アドレスが表示されていることも確認してください)。RHCOS のインストール自体はこれで完了です:
2024050416


ただし、この時点ではこの画面からログインすることはできません。Ignition ファイル内で作成するユーザー名は指定(上の例では "core")していましたが、パスワードは指定していません。この作成方法だと RHCOS にログインするには鍵ファイルを持つ他のサーバーから SSH 経由でのみログインできます。

試しに CentOS サーバーからログインしてみます。ユーザー名(core)と IP アドレスを指定して ssh でログインしてみます:
# ssh core@(RHCOS の IP アドレス)

2024050417


上図のようになると RHCOS に SSH で接続できています。core ユーザーには sudo 権限があるので、事実上の管理者権限を持って作業することはできます。シャットダウンもこの状態からであれば行うことができます。


というわけで、一応 RHCOS のインストールは完了し、SSH ログインによって OS を操作することも可能になりました。慣れていないと不思議に感じるかもしれませんが、一般的な RHCOS は(あくまでコンテナクラスタの OS としてしか使わないので)このように使います。

ただコンソールからログインできない(秘密鍵を持つサーバーからの SSH でないとログインできない)のはちょっと不便なので、最後にコンソールログインもできるように設定を変更します。


【RHCOS インストール後の設定変更】
RHCOS に直接ログインできるようにするにはパスワードを設定してあげるだけです。上の続きで SSH ログイン後に以下のコマンドを実行してパスワードを設定します:
$ sudo -i
# passwd core

パスワード設定後に exit して SSH 接続も切断します。ここまでの手順が成功していれば、CentOS 環境はもう不要なのでシャットダウンしてしまっても構いません。

最後に RHCOS のコンソールからパスワードでログインできるようになったことを確認します:
2024050418


これで CentOS に依存しない、単体で動作可能な RHCOS 環境ができあがりました。


まあ「どんな時に単体の RHCOS が必要か?」と聞かれると、(あまりオススメしませんが)アンチウィルスソフトの動作確認をしたいとか、コンテナに特殊なストレージデバイスを接続して使うような場合の手順や動作の確認時とか、かなり偏った用途くらいしか思いつかないのですが、レアな環境を手に入れることに興味を持つエンジニアにはウケるんじゃないかと思っています。



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



ちょっとした UI 系トラブルに巻き込まれた結果とある機会に CLI 操作だけで IBM Cloud 上に Openshift クラスタ(いわゆる "ROKS")を作る必要が生じて、実際に試してみました。以下、その時に実行したコマンド群を順に紹介します。


【前提条件】
やりたかったことは単純に「VPC(Virtual Private Cloud)環境内に OpenShift クラスタを1つ作る」ことでした。既に VPC 自体はサブネット含めて作成済みで、バックアップストレージの Cloud Object Storage インスタンスも作成済みです。 後はこの VPC 内に OpenShift クラスタをスペックやワーカーノード数を指定して作るだけ、という状況です。


【CLI コマンド】
以下 CLI コマンドを記載します。ここまでに "ibmcloud login" は実行済みであるとします。

詳しくは下記参考ページを参照いただきたいのですが、VPC 内に OpenShift クラスタを作るための CLI コマンドは以下のようになります:
$ ibmcloud oc cluster create vpc-gen2 --name (クラスタ名) --zone (作成先ゾーン名) --vpc-id (作成先 VPC ID) --subnet-id (作成先サブネット ID)  --flavor (ワーカーノードのフレーバー) --version (OpenShift バージョン) --cos-instance (Cloud Object Storage の CRN) --workers (1ゾーンあたりのワーカーノード数)

で、このコマンドを実行するためには(上記コマンド内にも括弧がたくさんあるように)指定する必要がある多くのパラメータ情報を事前に集めておく必要があります。というわけでまずはパラメータ情報を収集するための CLI コマンドから説明します。

まず "--name" パラメータで指定する「クラスタ名」は自分で自由に指定することができるので説明は不要だと思います。次に "--zone" パラメータで指定する「作成先ゾーン名」ですが、これは目的のゾーンが例えば「大阪3」であったとして、この「大阪3」を指定するための文字列です。これを調べるには次のコマンドでゾーン一覧を取得して、そこから目的のゾーンの ID を取り出します(青字が入力コマンドです):
$ ibmcloud oc zone ls --provider vpc-gen2
OK
ID           Name         Metro             Flavors
au-syd-1     au-syd-1     Sydney            -
au-syd-2     au-syd-2     Sydney            -
au-syd-3     au-syd-3     Sydney            -
br-sao-1     br-sao-1     Sao Paulo         -
  :
eu-gb-3      eu-gb-3      London            -
jp-osa-1     jp-osa-1     Osaka             -
jp-osa-2     jp-osa-2     Osaka             -
jp-osa-3     jp-osa-3     Osaka             -
jp-tok-1     jp-tok-1     Tokyo             -
jp-tok-2     jp-tok-2     Tokyo             -
jp-tok-3     jp-tok-3     Tokyo             -
us-east-1    us-east-1    Washington D.C.   -
  :

この結果から「大阪3」を使う場合に指定するゾーン名が "jp-osa-3" であることが分かります。

次に作成先の「VPC ID」です。VPC が決まっていても、その ID を取り出して指定する必要があります。これは以下のコマンドを実行することで取り出せます:
$ ibmcloud oc vpcs --provider vpc-gen2
OK
Name              ID                                          Provider
xxxxxxx-vpc-osa   ****-********-****-****-****-************   vpc-gen2
  :

目的の VPC 名と照らし合わせることで ID を確認することができます("****-********-****-****-****-************" という値であったと仮定します)。

作成先の「サブネットID」も調べる必要があります。普段は名称で扱っていて、ID を意識することがあまりないのですが CLI 操作時には必要な情報です。これは以下のコマンドで "xxxx-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" であることが確認できます:

$ ibmcloud oc subnets --provider vpc-gen2 --vpc-id (VPC ID) --zone (ゾーン名)
OK
Name                ID                                          Public Gateway Name                        Public Gateway ID                           IPv4 CIDR Block   Available IPv4 Addresses
sn-xxxxxxxxxxx-03   xxxx-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx   pgw-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx   xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx   10.xxx.xxx.0/24   244

ワーカーノードのフレーバー(スペック)も実行時に指定する必要のある情報です。これは以下のコマンドでフレーバーの一覧を取得し、目的のフレーバーの ID を取り出します。今回は "bx2.16x64" というスペックのフレーバーを使うことにします:
$ ibmcloud oc flavors --zone (ゾーン名) --provider vpc-gen2
OK
For more information about these flavors, see 'https://ibm.biz/flavors'
Name           Cores   Memory   Network Speed   OS             Server Type   Storage
  Secondary Storage   Flavor Class   Provider
bx2.16x64      16      64GB     24Gbps          UBUNTU_20_64   virtual       100GB     0B, *               bx2            vpc-gen2
bx2.2x8†       2       8GB      4Gbps           UBUNTU_20_64   virtual       100GB     0B                  bx2            vpc-gen2
bx2.32x128     32      128GB    25Gbps          UBUNTU_20_64   virtual       100GB     0B, *               bx2            vpc-gen2
b
  :
  :

OpenShift のバージョンも指定する必要がある項目ですが、これは普通に "4.11_openshift" などと指定できます。またゾーンあたりのワーカーノード数も普通に "2" などと数字で指定可能です。

最後に Cloud Object Storage の CRN を取得します。これは取得が面倒なのですが、作成済みリソースの一覧を取得し、そこから目的の Cloud Object Storage サービスを探して、その ID を見つける、という方法で取得します:
$ ibmcloud resource service-instances --long
OK
   :
   :
ID:                 crn:v1:bluemix:public:cloud-object-storage:global:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx::

GUID:               xxxxxxxxxxxxxx


Name                Cloud Object Storage for me


Location            global
   :
   :

これで OpenShift クラスタを作成するために必要な最低限の情報が揃いました:
情報
ゾーン名jp-osa-3
VPC ID****-********-****-****-****-************
サブネット IDxxxx-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
ワーカーノードのフレーバーbx2.16x64
OpenShift バージョン4.11_openshift
1ゾーンあたりのワーカーノード数2
Cloud Object Storage の CRNcrn:v1:bluemix:public:cloud-object-storage:global:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx::



これらの情報を使って以下のコマンドを実行します:
$ ibmcloud oc cluster create vpc-gen2 --name (クラスタ名) --zone jp-osa-3 --vpc-id ****-********-****-****-****-************ --subnet-id xxxx-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx  --flavor bx2.16x64 --version 4.11_openshift --cos-instance crn:v1:bluemix:public:cloud-object-storage:global:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:: --workers 2
Creating cluster...
OK
Cluster created with ID ***************************

成功すると上述のようにクラスタ ID("***************************")が表示され、「デプロイ中」のステータスとなります。


なお、マルチゾーンで作成する場合は上記の作業を行ってシングルゾーンでクラスタを作成した上で、追加するゾーンのゾーン名とサブネット ID を取得してから以下のコマンドを実行してワーカープールにワーカーノードを追加します:
$ ibmcloud oc zone add vpc-gen2 --zone (追加するゾーン名) -c (クラスタ名) --worker-pool (追加先のワーカープール名) --subnet-id (サブネットID)
OK

これで IBM Cloud のダッシュボード画面にアクセスできなくてもしなくても、CLI だけで Openshift クラスタを作ることができそうです。


【参考】
https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-create-vpc-gen2&interface=cli


 

ウェブアプリケーションの開発ハンズオン(オンライン含めて)を行う場合、その開発環境の準備が面倒です。参加者の PC を使おうとすると言語ランタイムやエディタのインストールやバージョン管理を含めて事前に準備してもらう項目が多く、また特にオンライン環境だとネットワークの設定が問題になったりするので、色んな環境のケースを想定した準備が必要になります。

そんな「開発環境構築」を比較的容易にする RedHat CodeReady Workspaces を使う機会があったので、使い方やこれを使って構築する開発環境がどんなものかまとめてみました:
2023011700


【事前準備】
今回は RedHat OpenShift クラスタ環境を使って CodeReady Workspaces を準備します。というわけで OpenShift クラスタ環境が必要です。以下では IBM Cloud 上に作った OpenShift クラスタ環境を使って紹介しますが、他のクラウドやオンプレミス版などを使っていても構いません。


【OpenShift に RedHat CodeReady Workspaces を導入】
まずは OpenShift クラスタに RedHat CodeReady Workspaces を導入します。RedHat CodeReady Workspaces は OpenShift 上のオペレータとして提供されているのでこれを使って環境を作ります。最初に OpenShift のウェブコンソールを開いて、Administrator パースペクティブで左メニューから Operator - OperatorHub を選択します。そこでプロジェクト(例えば "default")を1つ選び、検索フィールドに "codeready" などと入力して "Red Hat CodeReady Workspaces" を見つけてクリックします:
2023011701


Red Hat CodeReady Workspaces の説明画面が表示されたら「インストール」ボタンをクリックします:
2023011702


次の画面を下までスクロールしてもう一度「インストール」ボタンをクリックします:
2023011703


ここでしばらく待つと RedHat CodeReady Workspaces オペレータがインストールされます:
2023011704


インストールが完了すると以下のような画面になるので、「Operator の表示」ボタンをクリックします:
2023011705


インストールされた RedHat CodeReady Workspaces オペレータが表示されます。実際に CodeReady Workspaces インスタンスを動かすために「提供される API」欄の "CodeReady Workspaces Instance Specification" の下の「インスタンスの作成」をクリックします:
2023011706


もう一度下までスクロールして「作成」ボタンをクリックするとインスタンスの作成が始まります:
2023011707


インスタンスが作成されると以下のような画面になるので、"codeready-workspaces" と書かれた箇所をクリックします:
2023011708


下のような画面になります。この画面ではまだインスタンスは準備中ですが、用意ができると "CodeReady Workspaces URL" の下にリンク URL 文字列が表示されます:
2023011709


このような表示になるとインスタンスの作成も完了しています。早速 CodeReady Workspaces URL 下のリンクをクリックします:
2023011710


最初の1回だけアクセス権の設定を行う必要があります。"user-full" にチェックが入っていることを確認して "Allow selected permissions" ボタンをクリックします:
2023011711


するとアカウント情報の画面が表示されます:
2023011712


この画面内でユーザー名、メールアドレス、ファースト/ラストネームを入力して、最後に Submit ボタンをクリックします。これでアカウント情報の登録も行われます:
2023011713


CodeReady Workspaces の起動が開始します。ここまで行うことができれば RedHat CodeReady Workspaces の環境構築手順は無事に成功しました:
2023011714



【RedHat CodeReady Workspaces を使ってアプリケーション開発を行う】

RedHat CodeReady Workspaces の起動が完了すると最初のワークスペースを作るようナビゲートされます:
2023011715


Git リポジトリを指定してソースコード一式をインポートすることもできますが、今回はテンプレートからワークスペースを作ってみます。(なんでもいいのですが)画面下の "NodeJS Express" と書かれた Node.js のシンプルなソースコードをベースに選択して、ここからワークスペースを作ることにしてみましょう:
2023011716


すると指定されたテンプレートを元にしたソースコード一式が作成されるので、完了するまで少し待ちます:
2023011717


ワークスペースの生成が完了するとこのような画面が表示されます。ウェブ版の VSCode が起動し、(今回の例であれば)シンプルな Node.js + Express のウェブアプリケーションの雛形となるソースコードが読み込まれています。指定したファイルを開いたり、その内容を変更することもできます(最初は README.md がプレビューモードで開かれています):
2023011718


依存関係や起動コマンドを確認するため、package.json を開いてみました。ここから最初に起動するべきファイルは app/app.js であることがわかります:
2023011719


実際に app/app.js も開いて内容を確認してみました。いわゆる「ハローワールド」のウェブ版のアプリケーションのようです:
2023011720


このアプリを起動するには VSCode 内でターミナルを起動します。メニューの Terminal - Open Terminal in specific container を選択し、"vscode-nodeajs" を選択します:
2023011721


すると画面右下にターミナルが現れ、CLI コマンドを実行できるようになります:
2023011722


実際にアプリケーションを起動してみましょう。まずはターミナルで "npm install" と入力してライブラリをインストールします:
2023011723


そして "node app/app.js" と入力してウェブアプリケーションを起動します。すると画面右下に「起動したウェブアプリケーションをブラウザで表示するか?」と聞かれるので、「新しいタブで起動(Open In New Tab)」を選択します:
2023011724


新しいブラウザタブが開いて、そこで起動したアプリケーションが実行されます。期待通り、"Hello World!" が表示できました。CodeReady Workspaces で作ったオンライン開発環境を使ってアプリケーションを開発/実行/動作確認までできることが確認できました:
2023011725


CodeReady Workspaces のエディタ画面で編集したアプリケーションをウェブブラウザで実行(表示)することができました:
2023011700


【まとめ】
OpenShift コンテナクラスタ環境を使うことで、開発環境も実行環境もコンテナ上で簡単に構築・実現することができました。個人の PC にはランタイムや CLI などを導入する必要がなく、ネットワークも(HTTP/HTTPS さえインターネットに通っていればいいので)環境による試行錯誤はほぼ不要だと思います。簡易的なアプリケーション開発環境の構築程度であれば非常に用意に作れると感じました。


Ubuntu の標準形式でありながら、CentOS や RHEL(RedHat Enterprise Linux) ではそのままでは扱えない deb パッケージを rpm パッケージに変換する方法があります。

具体的には alien コマンドを利用します。 まずこの alien コマンドを CentOS や RHEL 環境上でビルドします:
# yum install rpm-build
# cd /tmp
# wget http://ftp.debian.org/debian/pool/main/a/alien/alien_8.92.tar.gz
# rpmbuild -ta alien_8.92.tar.gz
  :
  :
書き込み完了: /root/rpmbuild/RPMS/noarch/alien-8.92-1.noarch.rpm
  :
  :
# rpm -ivh /root/rpmbuild/RPMS/noarch/alien-8.92-1.noarch.rpm

ここまでの作業で alien コマンドがインストールできているので、このコマンドを使って deb パッケージを rpm パッケージへ変換します:
# alien --to-rpm --scripts xxx.deb
xxx.rpm generated

こうして出来上がった rpm ファイルは rpm コマンドや yum コマンドで導入可能です。
 

このページのトップヘ