Red Hatでソリューションアーキテクトをしている田中司恩( @tnk4on )です。 この連載はvSphere環境上にOpenShift Container Platform（以下、OpenShift）およびOpenShift Virtualizationの環境を構築する方法を解説するシリーズです。 第5回はMigration Toolkit for Virtualization（MTV）を使ったvSphere仮想マシンの移行方法について解説します。 第1回：OpenShiftのインストール 第2回：OpenShiftインストール後の作業 第3回：共有ストレージの作成（NFS CSIドライバーの構築） 第4回：OpenShift Virtualizationのインストールと実行 第5回：vSphere仮想マシンの移行 （←本記事） 【番外編】：共有ストレージの作成（NFSプロビジョナーの構築） （2024/10/2追記：移行後の仮想マシンの起動状態について記載内容を修正） -目次- vSphere仮想マシンの移行 前提条件 1. Migration Toolkit for Virtualizationについて 1-1 移行元プロバイダー 1-2 移行方式 （1）コールド移行 （2）ウォーム移行 2. Migration Toolkit for Virtualizationのインストール 2-1 インストールの概要 2-2 インストールの前提条件 2-3 Operatorのインストール 2-4 ForkliftControllerの作成 3. VDDKイメージの作成 3-1 VDDKイメージの作成手順 （1）VDDKイメージのビルド （2）VDDKイメージのプッシュ 4. プロバイダーの作成 ESXiホストがFQDNで登録されていない場合 5. 移行計画の作成 5-1 プロバイダーの選択 5-2 移行計画の作成 StatusにWarningが出る場合： 6. 移行計画の実行（コールド移行） 6-1 コールド移行の実行 6-2 移行の進捗確認 6-3 移行した仮想マシンの起動テスト 7. 移行計画の実行（ウォーム移行） 7-1 ウォーム移行の前提条件 7-2 ウォーム移行の設定 7-3 ウォーム移行の実行 7-4 移行の進捗確認 プレコピーの更新間隔の変更 7-3 カットオーバーの実行 まとめ vSphere仮想マシンの移行 本記事ではvSphere仮想マシンの移行について、下記の内容を紹介します。 Migration Toolkit for Virtualizationについて Migration Toolkit for Virtualizationのインストール VDDKイメージの作成 プロバイダーの作成 移行計画の作成 移行計画の実行（コールド移行） 移行計画の実行（ウォーム移行） 前提条件 連載 第4回 の作業を完了していることとします 全体の構成や各パラメーターなどは第1回を参照してください 作業用端末のプロンプトは % とします 踏み台サーバーのプロンプトは $ とします 踏み台サーバーの作業は明示的に記載がある場合を除いて、作業ディレクトリ ${HOME}/work で作業することとします 第4回の作業完了後の構成 1. Migration Toolkit for Virtualizationについて 1-1 移行元プロバイダー Migration Toolkit for Virtualization（以下、MTV）は、対応している移行元からOpenShift Virtualizationに仮想マシンを移行するツールです。 対応している移行元プロバイダーは下記の通りです。 VMware vSphere Red Hat Virtualization (RHV) OpenStack VMware vSphere によって作成された Open Virtual Appliances (OVA) リモートの OpenShift Virtualization クラスター MTVが対応しているプロバイダーはドキュメントに記載があります。 第1章 Migration Toolkit for Virtualization について | Red Hat Product Documentation 本記事では一番多いニーズのvSphere（ESXi）からの仮想マシンの移行を対象とし、以後の解説における移行元プロバイダーはVMware vSphereを前提とします。 1-2 移行方式 MTVはコールド移行とウォーム移行の2つの移行方式をサポートしています。 （1）コールド移行 デフォルトの移行方式で、移行元の仮想マシンを停止して移行を行います。 仮想マシンの停止中にデータのコピーを行うので、仮想マシンのサイズが大きい場合はコピーに時間がかかり移行に伴う停止時間が長くなる可能性があります。 （2）ウォーム移行 移行元の仮想マシンを起動した状態でデータのコピーを行います。最終的にカットオーバー処理を行うことで、仮想マシンが停止され残りのデータがコピーされます。 ウォーム移行は移行元がvSphereおよびRHVのみ対応しています。 OpenShift Virtualization v4.16.0-v4.16.2は ウォーム移行ができません 。 ウォーム移行を行う場合は、必ずOpenShift Virtualization v4.16.3以降にアップデート してご利用ください。 2. Migration Toolkit for Virtualizationのインストール 2-1 インストールの概要 MTVのインストールは、第4回で実施したOpenShift Virtualizationのインストールと同様に、 Operator を使って行います。 Operatorを使ったMTVのインストールの流れは下記の通りです。 MTVのインストールの流れ Operatorのインストール ForkliftControllerの作成 2-2 インストールの前提条件 MTVをインストールするには対応するOpenShiftおよびOpenShift Virtualizationがインストールされている必要があります。 第2章 前提条件 | Red Hat Product Documentation 2-3 Operatorのインストール MTVのインストール作業を行います。対象のドキュメントは下記を参照してください。 第3章 MTV Operator のインストールと設定 | Red Hat Product Documentation OpenShiftのWebコンソールから「Operator>Operator Hub」メニューを選択します。 Operator Hubの一覧画面 キーワードの入力欄に openshift virt と入力するとフィルタリングされて「OpenShift Virtualization」と「Migration Toolkit for Virtualization Operator」の2つが表示されます。 「Migration Toolkit for Virtualization Operator」を選択します。 キーワードでフィルタリングしてMigration Toolkit for Virtualization Operatorを選択 チャネルとバージョンはデフォルト表示のままで「インストール」を押します。 Migration Toolkit for Virtualization Operatorのインストール インストールの詳細入力画面が開きます。ここでもデフォルト表示のままインストールを押します。 なお、（FC）ForkliftControllerが必須となっていますが、これは後ほどインストールするのでそのまま無視します。 Operatorのインストール詳細入力画面 更新チャネル：release-v2.6（releaseバージョン以外にcandidateがある） バージョン：2.6.7（本記事執筆時点では「2.6.7」が最新） インストールモード：クラスターの特定のnamespace インストール済みのnamespace：Operator推奨のnamespace:openshift-mtv 更新の承認：自動 Migration Toolkit for Virtualization Operatorのインストールが開始します。環境にもよりますが、インストールの完了まで1分程度かかります。インストールの完了までそのままでお待ちください。なお、インストール自体はバックグラウンドで継続されるため、他の画面に遷移しても問題ありません。 Migration Toolkit for Virtualization Operatorのインストール中の画面 インストールが完了すると「ForkliftControllerの作成」ボタンが表示されます。これを押して次のステップに進みます。 Migration Toolkit for Virtualization Operatorのインストール後の画面 2-4 ForkliftControllerの作成 先のステップで「ForkliftControllerの作成」ボタンを押すと、「ForkliftControllerの作成画面」が表示されます。 そのまま「作成」ボタンを押します。 ForkliftControllerの作成画面 この「ForkliftControllerの作成画面」は、Webコンソールのメニューから「Operator>インストール済みのOperator>Migration Toolkit for Virtualization Operator」を選択して表示される画面上の、「ForkliftControllerの作成」ボタンを押した後に出る画面と同じものです。別の画面に遷移した場合はここから作業を継続してください。 インストール済みのOperatorの詳細画面 「作成」ボタンを押した後は自動で「インストール済みのOperator>Operatorの詳細画面」から、 ForkliftController のタブが選択された状態の画面に遷移します。 ForkliftControllerの作成中の画面 インストールが進むにつれステータスの表示が変わります。ここも環境によりますが、完了まで2-3分ほどかかりますのでまでそのまま待機します。 インストールの完了後、画面上部にポップアップ画面が表示されます（ステータス表示が変わる前に表示されることもあります）。ポップアップ画面内の「Webコンソールの更新」のリンクを押す、またはブラウザをリロードします。 ForkliftControllerの作成後、Webコンソールの更新のポップアップが表示される 画面の更新後、Webコンソールのメニュー内に「Migration」の項目が追加されています。 Webコンソール更新後の画面 Webコンソールのメニューから「Migration>Overview」を選択します。 Migration Toolkit for VirtualizationのOverview画面 以上でMigration Toolkit for Virtualizationのインストールは完了です。 続けてvSphere/ESXiの仮想マシンの移行に使用するVDDKイメージの作成を行います。 3. VDDKイメージの作成 VMware Virtual Disk Development Kit (以下、VDDK) はVMwareの仮想ディスクにアクセスしたり作成するためのSDKです。MTVはVDDKを使用しvSphere仮想マシンの転送を高速化します。 なお、VDDKの利用は任意ですが利用することは 強く推奨します （ほぼ必須）。 ここではVDDKを組み込んだコンテナイメージ（VDDKイメージ）を作成し、MTVから利用できるようにします。 VDDKの入手先はBroadcom社によるVMware社の買収後は、Broadcom社のサイトで配布が行われています。 VMware Virtual Disk Development Kit (VDDK) VDDKはWindowsおよびLinux向けのSDKが配布されており、「VMware Software Development Kit License Agreement」への合意に基づき利用が可能です。 なお、VDDKをダウンロードするにはBroadcomのアカウントでログインする必要があります。 事前にLinux版のVDDKを入手し、作業用端末に保存しておいてください。最新版はv8.0.3です（記事執筆時点）。 VDDKのダウンロード画面 3-1 VDDKイメージの作成手順 VDDKイメージの作成手順は下記のドキュメントを基に行います。 2.7. VMware の前提条件 | Red Hat Product Documentation VDDKイメージの注意点は「パブリックの領域に保存しない」ことです。ライセンスで再配布が禁止されているためです。 本記事では、OpenShiftの内部イメージレジストリにVDDKイメージを保存するようにします。 （1）VDDKイメージのビルド 踏み台サーバーでVDDKイメージの作成用の作業ディレクトリを作成し、そこへ移動します。 $ mkdir VDDK $ cd VDDK VDDKを作業用端末から、踏み台サーバー上の作業用ディレクトリにコピーします。 なお、入手したVDDKが作業用端末のカレントディレクトリにあることとします。 （作業用端末で実行） % scp VMware-vix-disklib-8.0.3-23950268.x86_64.tar.gz bastion:work/VDDK 踏み台サーバーでVDDKを解凍します。 $ ls -d VMware-vix-disklib-8.0.3-23950268.x86_64.tar.gz VMware-vix-disklib-8.0.3-23950268.x86_64.tar.gz $ tar xzf VMware-vix-disklib-8.0.3-23950268.x86_64.tar.gz $ ls -d vmware-vix-disklib-distrib vmware-vix-disklib-distrib VDDKイメージのDockerfileを作成します。 *1 $ cat > Dockerfile <<EOF FROM registry.access.redhat.com/ubi8/ubi-minimal USER 1001 COPY vmware-vix-disklib-distrib /vmware-vix-disklib-distrib RUN mkdir -p /opt ENTRYPOINT ["cp", "-r", "/vmware-vix-disklib-distrib", "/opt"] EOF ビルドするタグ名を取得するためにOpenShiftクラスタへログインします。 ocpadmin ユーザーでログインするために KUBECONFIG 環境変数を解除します。 詳細は連載 第2回 を参照。 $ unset KUBECONFIG $ oc login -u ocpadmin https://api.ocp.home.lab:6443 WARNING: Using insecure TLS client config. Setting this option is not supported! Console URL: https://api.ocp.home.lab:6443/console Authentication required for https://api.ocp.home.lab:6443 (openshift) Username: ocpadmin Password: パスワードを入力してOpenShiftにログインできたことを確認します。 Login successful. You have access to 74 projects, the list has been suppressed. You can list all projects with 'oc projects' Using project "ocp-virt". イメージレジストリのURLを取得し HOST 環境変数へセットします。 詳細は連載 第3回 を参照。 $ HOST=$(oc get route default-route -n openshift-image-registry --template='{{ .spec.host }}') $ echo ${HOST} default-route-openshift-image-registry.apps.ocp.home.lab 取得した HOST 環境変数をタグ名に使用し、VDDKイメージをビルドします。 実行コマンド $ podman build -t ${HOST}/openshift/vddk . 実行コマンドと結果 $ podman build -t ${HOST}/openshift/vddk . STEP 1/5: FROM registry.access.redhat.com/ubi8/ubi-minimal Trying to pull registry.access.redhat.com/ubi8/ubi-minimal:latest... Getting image source signatures Checking if image destination supports signatures Copying blob 76e9cdf18aba done | Copying config 7aaf580966 done | Writing manifest to image destination Storing signatures STEP 2/5: USER 1001 --> 9690c68eb273 STEP 3/5: COPY vmware-vix-disklib-distrib /vmware-vix-disklib-distrib --> e6bd091b0d6a STEP 4/5: RUN mkdir -p /opt --> cc8588d591eb STEP 5/5: ENTRYPOINT ["cp", "-r", "/vmware-vix-disklib-distrib", "/opt"] COMMIT default-route-openshift-image-registry.apps.ocp.home.lab/openshift/vddk --> 7da3e1ed5e31 Successfully tagged default-route-openshift-image-registry.apps.ocp.home.lab/openshift/vddk:latest 7da3e1ed5e3158a4a685609285f67ab18bf86721617e0305fd5e9fdee1eafbd0 （2）VDDKイメージのプッシュ OpenShiftのログイン情報と HOST 環境変数を利用して、 podman login コマンドでイメージレジストリへログインします。 $ podman login -u ocpadmin -p $(oc whoami -t) ${HOST} Login Succeeded! 続けて、VDDKイメージのプッシュを行います。 実行コマンド $ podman push ${HOST}/openshift/vddk 実行コマンドと結果 $ podman push ${HOST}/openshift/vddk Getting image source signatures Copying blob 67be5b5d64dc done | Copying blob 405af4f177b1 done | Copying blob bae4fda36bb4 done | Copying config 7da3e1ed5e done | Writing manifest to image destination 確認コマンド $ skopeo inspect docker://${HOST}/openshift/vddk Skopeoを使ってプッシュしたコンテナイメージがイメージレジストリーに登録されているか確認します。 確認コマンドと結果 出力結果を開く $ skopeo inspect docker://${HOST}/openshift/vddk { "Name": "default-route-openshift-image-registry.apps.ocp.home.lab/openshift/vddk", "Digest": "sha256:e37ebbedc80cb490fa7909cae202301fbe8e604a712354db5054a0a002ea58e1", "RepoTags": [ "latest" ], "Created": "2024-07-30T06:52:39.356472214Z", "DockerVersion": "", "Labels": { "architecture": "x86_64", "build-date": "2024-06-27T11:18:10", "com.redhat.component": "ubi8-minimal-container", "com.redhat.license_terms": "https://www.redhat.com/en/about/red-hat-end-user-license-agreements#UBI", "description": "The Universal Base Image Minimal is a stripped down image that uses microdnf as a package manager. This base image is freely redistributable, but Red Hat only supports Red Hat technologies through subscriptions for Red Hat products. This image is maintained by Red Hat and updated regularly.", "distribution-scope": "public", "io.buildah.version": "1.33.7", "io.k8s.description": "The Universal Base Image Minimal is a stripped down image that uses microdnf as a package manager. This base image is freely redistributable, but Red Hat only supports Red Hat technologies through subscriptions for Red Hat products. This image is maintained by Red Hat and updated regularly.", "io.k8s.display-name": "Red Hat Universal Base Image 8 Minimal", "io.openshift.expose-services": "", "io.openshift.tags": "minimal rhel8", "maintainer": "Red Hat, Inc.", "name": "ubi8-minimal", "release": "1018", "summary": "Provides the latest release of the minimal Red Hat Universal Base Image 8.", "url": "https://access.redhat.com/containers/#/registry.access.redhat.com/ubi8-minimal/images/8.10-1018", "vcs-ref": "4f8da2b64a13f2a264bd802d8909bf803211fb20", "vcs-type": "git", "vendor": "Red Hat, Inc.", "version": "8.10" }, "Architecture": "amd64", "Os": "linux", "Layers": [ "sha256:76e9cdf18aba09dd872666d609fbdc8cd5c6c418c119dc113872061ba434b70f", "sha256:f83fb1808400a57a0096f736d9b38e7e4f7ee405a2bb968702c3402d5286019d", "sha256:6c7b8478d4963d8b248ed45d3496c02cab837c540eafe989e6107454846c7571" ], "LayersData": [ { "MIMEType": "application/vnd.oci.image.layer.v1.tar+gzip", "Digest": "sha256:76e9cdf18aba09dd872666d609fbdc8cd5c6c418c119dc113872061ba434b70f", "Size": 39346374, "Annotations": null }, { "MIMEType": "application/vnd.oci.image.layer.v1.tar+gzip", "Digest": "sha256:f83fb1808400a57a0096f736d9b38e7e4f7ee405a2bb968702c3402d5286019d", "Size": 44400224, "Annotations": null }, { "MIMEType": "application/vnd.oci.image.layer.v1.tar+gzip", "Digest": "sha256:6c7b8478d4963d8b248ed45d3496c02cab837c540eafe989e6107454846c7571", "Size": 226, "Annotations": null } ], "Env": [ "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", "container=oci" ] } VDDKイメージの作成が完了しました。次は移行元プロバイダーの作成を行います。 4. プロバイダーの作成 MTVは移行元プロバイダーとしてVMware vSphereに対応していますが、実際にはvCenter ServerまたはESXiを指定して登録を行います。 本連載はでESXiを移行元プロバイダーとして指定します。 Webコンソールのメニューから「Migration>Providers for virtualization」を選択します。 プロジェクトを「すべてのプロジェクト」を選択すると、「host」プロバイダーが登録されているのが確認できます。 これはMTVのインストール時に自動で登録されたもので、Typeが「OpenShift」となっており、OpenShift Virutalizationそのものを指す設定とご理解ください。 新しくプロバイダーを追加するには「Create Provider」ボタンを押します。 デフォルトのプロバイダーの登録状態 「Provider details」では、登録可能なプロバイダーの一覧が表示されます。この中から「vSphere」を選択します。 プロバイダーの選択画面 選択したプロバイダーの詳細な設定入力画面に遷移します。ここでプロバイダー登録に必要な情報を入力します。 Provider details Select provider type: vSphere Provider resource name: esxi（任意の名前） Endpoint type：ESXi URL: https://esxi.home.lab/sdk VDDK init image: image-registry.openshift-image-registry.svc:5000/openshift/vddk:latest Provider credentials Username: root Password:（ESXiのrootのパスワード） Skip certificate validation: true パラメーターの入力後、「Create provider」ボタンを押します。 プロバイダーの登録画面（1/2） プロバイダーの登録画面（2/2） プロバイダーの登録後、登録したプロバイダーの詳細画面に遷移します。 登録したプロバイダーの詳細画面 Webコンソールのメニューから「Migration>Providers for virtualization」を再度選択すると、先ほど登録したプロバイダーが一覧に追加されたことが確認できます。 登録済みのプロバイダー一覧 次は登録したプロバイダーを使って、移行契約の作成を行います。 ESXiホストがFQDNで登録されていない場合 ESXiホスト自身にFQDNの設定が行われていない場合、MTVの移行時でエラーになる場合があります。 FQDNの設定が行われていない場合はESXi ShellまたはESXiホストへSSH接続を行い、下記の設定を行います。 実行コマンド （ESXiホスト上で実行） [root@esxi:~] hostname -f esxi [root@esxi:~] esxcli system hostname set --fqdn=esxi.home.lab [root@esxi:~] hostname -f esxi.home.lab FQDN設定後、再度プロバイダーを登録してます。「Providers>Provider Details」から「Hosts」タブを選択し、ESXiホストがFQDNで登録されていることを確認します。 FQDNでESXiホストが登録されている 5. 移行計画の作成 MTVは移行計画の作成を行なって仮想マシンの移行を行います。移行計画には1つ以上の仮想マシンを含めることができます。 5-1 プロバイダーの選択 Webコンソールのメニューから「Migration>Plans for virtualization」を選択します。 プロジェクトから「すべてのプロジェクト」を選択します。移行計画がまだ作成されていないことを確認し、「Create Plan」ボタンを押します。 移行計画の一覧画面 「Select source provider」から作成したプロバイダー：esxiを選択すると、ESXiホストマシン上の仮想マシンが一覧で表示されます。 選択可能なプロバイダー一覧 一覧から移行したい仮想マシンにチェックを入れ、「Next」ボタンを押します。 ここでは「rhel9-vmware」を選択します。 移行する仮想マシンを選択し、Nextボタンを押す 5-2 移行計画の作成 次の画面では移行計画の作成に必要な情報を入力します。 Create migration plan Plan name: migration-01 Source provider: 移行元のプロバイダー。「esxi」が選択済み。 Target provider: 移行先のプロバイダー。デフォルトの「host」が選択済み。 Target namespace: 移行先のNamespaceを指定可能。ここでは「ocp-virt」を選択。 Network map: VM Network（移行元のVMの仮想スイッチ）: Pod Networking（移行先のNAD） Storage map: NVMe（移行元のVMの保存ストレージ）: nfs-client（移行先のストレージクラス） 移行計画の詳細入力画面 すべての項目を入力後、「Create migration plan」ボタンを押します。 StatusがReadyになるまでそのまま待機します。初回は使用するコンテナイメージのダウンロードや展開に時間を要するため、3分ほどかかります。 作成した移行計画の詳細画面 Webコンソールのメニューから「Migration>Plans for virtualization」を再度選択し、作成した移行計画が一覧に登録されていることを確認します。 移行計画の一覧画面に作成した移行計画が登録されている StatusにWarningが出る場合： 移行元の仮想マシン名（インベントリに登録している名前）に大文字が含まれている場合、StatusがWarningになります。 Warning Target VM name does not comply with DNS1123 RFC, will be automatically changed. To troubleshoot, view the plan details page and check the Forklift controller pod logs. 例）RHEL、など そのまま移行を行うと、移行時に自動で小文字に変換されます。 なお、StatusがWarningであっても、「Start migration」ボタンが押せる状態であれば移行は可能です。 6. 移行計画の実行（コールド移行） 6-1 コールド移行の実行 作成した移行計画はデフォルトでは「コールド移行」となります。そのままコールド移行を行う場合は「Start migration」ボタンを押します。移行計画の一覧画面から実行する場合は「Start」ボタンを押します。 コールド移行の実行 どちらの場合も実行の確認画面が表示されるので、「Start」ボタンを押します。 移行開始の確認画面 StatusがRunningに変わり、移行が開始されます。なお、起動中の仮想マシンはこの時点で停止します。 移行開始後の詳細画面 6-2 移行の進捗確認 移行中の進捗確認は、移行計画の詳細画面から「Virtual Machines」タブを選択します。 さらに、「>」を展開し、 Pipeline で進捗状況を確認できます。 移行の進捗確認画面 Pipelineには下記の段階ごとに進捗状況が更新されます。 Initialize（Initialize migration） DiskAllocation（Allocate disks） ImageConversion（Convert image to kubevirt） DiskTransferV2v（Copy disks） VirtualMachineCreation（Create VM） Pipelineに進捗状況が表示される 仮想マシンが作成され、移行が完了する 最後の「VirtualMachineCreation」が完了すると、Webコンソールのメニュー「Virtualization>VirtualMachines」の仮想マシン一覧に移行した仮想マシンが登録されます。 移行が完了し、仮想マシン一覧に移行した仮想マシンが登録される 6-3 移行した仮想マシンの起動テスト 移行が完了すると、移行元で起動していた仮想マシンは自動で起動します。停止状態で移行した仮想マシンは移行後も停止状態になります。 移行後の仮想マシンはOpenShift Virtualizationで作成した仮想マシンと同様に操作できます（起動、停止、コンソール、スナップショット、ライブマイグレーション、など）。 移行した仮想マシンの起動を確認 7. 移行計画の実行（ウォーム移行） 7-1 ウォーム移行の前提条件 ウォーム移行を行う場合、対象の仮想マシンにChanged Block Tracking (以下、CBT)の設定を行う必要があります。 仮想マシンにCBTの設定を行う方法は、下記のドキュメントを参照ください。 Changed Block Tracking (CBT) on virtual machines govc コマンドを使用してCBTを有効化するには下記の手順を実行します。 なお、対象の仮想マシン（win2022-vmware）は事前にシャットダウンしていることとします。 実行コマンド $ govc vm.change -vm win2022-vmware -e="ctkEnabled=true" CBTの設定状況は下記のコマンドで確認します。 実行コマンド $ govc vm.info -e ctkEnabled=true win2022-vmware | grep ctkEnabled ctkEnabled: TRUE 7-2 ウォーム移行の設定 ウォーム移行を行う場合もコールド移行と同じ手順で移行計画を作成します。 ここでは「migration-02」として、「win2022-vmware」仮想マシンのウォーム移行を行います。 本記事「5. 移行計画の作成」の手順を参考に、移行計画を作成してください。 ウォーム移行を行う場合は、移行計画の作成後にコールド移行からウォーム移行へと設定を変更します。 移行計画の詳細画面から、「Settings>Warm migration」内の編集ボタンを押します。 移行計画の詳細画面から設定変更を行う 「Set warm migration」の設定画面がポップアップ表示されます。 ウォーム移行の設定を有効化し、「Save」ボタンを押します。 ウォーム移行を有効化する 移行計画詳細でウォーム移行の有効化を確認 7-3 ウォーム移行の実行 コールド移行と同様に、移行計画の詳細画面から「Start migration」ボタンを押してウォーム移行を実行します。 ウォーム移行の実行 コールド移行と同様に、実行の確認画面が表示されるので、「Start」ボタンを押します。 移行開始の確認画面 7-4 移行の進捗確認 移行中の進捗確認は、コールド移行と同様に移行計画の詳細画面から「Virtual Machines」タブを選択します。 移行の進捗確認画面 コールド移行と異なるのは、ウォーム移行では最初の移行の実行後に初期転送が行われ、カットオーバーが行われるまで進捗はその状態のままになることです。 進捗はDiskTransferが完了した状態で維持される ウォーム移行の開始後、移行元の仮想マシンに「forklift-migration-precopy」という名前のスナップショットが作成されます。 デフォルトでは「60分ごと」に差分の更新が行われ、その際に新しいスナップショットが作成されて、古いスナップショットは削除されます。 その後、カットオーバーを行うまで更新は自動で継続されます。 ウォーム移行ではプレコピー中、仮想マシンにスナップショットが作成される プレコピーの更新間隔の変更 プレコピーの更新間隔はMTVのOverview画面で変更が可能です。 Webコンソールのメニューから「Migration>Overview」を選択し、「Settings」内の「Precopy interval (minutes)」の値を変更します。 変更できる値は「5分、30分、60分、120分」から選択する方式です。 プレコピーの更新間隔の変更 更新間隔は事前に定義された4つの時間の中から選択する方式 ※注意：更新間隔を5分に設定しても、前後の処理時間が追加されるため、次回のスナップショットの作成時間は5分より超えて行われます 7-3 カットオーバーの実行 プレコピーの実行後、カットオーバーを実行することで最終のデータコピーが行われ、仮想マシンの移行が完了します。 移行計画の詳細画面から「Actions>Cutover」を選択することでカットオーバーを開始します。 または、移行計画の一覧画面から実行する場合は、対象の移行計画の「Cutover」ボタンを押します。 移行計画の詳細画面からカットオーバーを実行する 移行計画の一覧画面からカットオーバーを実行する カットオーバーのスケジュール設定画面がポップアップで表示されます。指定の時間にカットオーバーを行う場合は日時を選択して「Set cutover」を押します。 すぐにカットオーバーを行いたい場合は、そのまま「Set cutover」を押します。 カットオーバーの実行時間を指定する カットオーバーを実行すると、移行元の仮想マシンがシャットダウンされ、最終のデータコピー（ファイナライズ）が実行されます。 カットオーバーの実行後、最終のデータコピーが実行される その後、イメージ変換のプロセスを経て仮想マシンが作成されます。 仮想マシンが作成され、移行が完了する ※注意：初回のウォーム移行実行時は、イメージ変換に使用するコンテナイメージのダウンロード、解凍に時間を要する場合があります。 ウォーム移行の場合は、移行完了後の仮想マシンは自動で起動します。 移行した仮想マシンの起動を確認 まとめ MTVを使用したvSphere仮想マシンの移行方法について解説しました。 今回はシンプルな検証環境での実行を前提としたのでESXiを移行元プロバイダーとして使用しました。 実稼働環境ではvCenter Serverを使用することがほとんどですが、設定方法や移行の方法は同じですので、実稼働環境（およびその検証環境）でも同じ手順で移行の実行を行ってください。 本連載では対象の範囲外とした複雑なネットワークやストレージ環境においても、移行のマッピングを適切に行うことで移行は可能です。 是非さまざまな環境で移行の実行を行ってみてください。 本連載はこの記事をもって終了となりますが、書ききれなかった内容は多々あります。 それらについてはまた別の記事で補足することとします。 *1 : ドキュメントでDockerfileとなっているため、ここではContainerfileとせずそのまま記載

こんにちは。Red Hatのソリューションアーキテクトの瀬戸です。 気が付けば前回から3か月も空いてしまっていました。 今回は構築した環境を使用して実際にアプリケーションを開発していきたいと思います。 この記事では簡単なアプリケーションのデプロイまでを行います。 前回の記事はこちら。 rheb.hatenablog.com 前回の記事では、JBoss EAP/Mavenの設定をして簡単な動作確認まで終わりました。 IDEは前回の記事の中で予告していた通りPleiadesを使用します。 ダウンロードして、デフォルト状態でインストールされている状態から開始します。 ※この記事ではWindows x64用 Java Full Editionの2024-06.20240626を使用しています。 *1 Pleiadesのダウンロードは次のURLから行うことができます。インストールも含めて簡単なので、使ったことがない人はぜひ試してみてください。 willbrains.jp 今回使用する機能はJBoss EAP 8.0のマニュアル上非推奨とマークされている機能が含まれています。 しかし、これは即座に使用するなという意味ではなく、当面は使用し続けることができます。 また、以前はJBoss Developer Studioという製品が有償で提供されていましたが、現在は販売が終了しております。 現在は開発を行うためにはコミュニティによるツールやサードパーティー製品を使用する必要があります。ご注意ください。 プロジェクトの作成 Eclipse上からファイル->新規(N)->Mavenプロジェクトを選択します。 新規プロジェクトの作成 シンプルなプロジェクトの作成(s)(アーキタイプ選択のスキップ)にチェックを入れて 、次へ(N)を押します。 新規Mavenプロジェクト 成果物の欄で、グループIDに任意の文字列、アーティファクトIDとして保存先のフォルダの名前(ここではexampleにしています)、パッケージングとしてwarを指定します。入力したら完了を押します。 プロジェクトの構成 Note: ここではmavenにプロジェクトの設定を入力しています。後ほどmavenの設定ファイルを直接編集して直します。 指定したアーティファクトIDの名前の付いたプロジェクトが作成されます。 生成されたプロジェクト pom.xmlの編集 このプロジェクト用に生成されたpom.xmlを編集して、JBoss EAPに合うように変更します。 生成されたプロジェクトにpom.xmlがあることを確認してください。 mavenを使用したプロジェクトの作成方法は JBoss EAP にデプロイするアプリケーションの開発のスタートガイド に記載がありますが、細切れになっているため、JBoss EAP 8.0の設定をすべて行ったpom.xmlのテンプレートを準備しました。 以下の内容をpom.xmlに上書きしてください。 https://gist.github.com/ssetoredhat/5b1bcc2226380ba88131f21e60cffee5 ３つの項目を編集する必要があります。 6行目と7行目のgroupIdとartifactIdを編集します。 <groupId> com.redhat.sseto </groupId> <artifactId> example </artifactId> groupIdにはドメイン名を入れます。インターネット上に公開する予定がない場合は自由に入れて大丈夫です。 artifactIdにはこのプロジェクトの名前を入れます。 31行目のfinalNameを編集します。 <finalName> example </finalName> これはアプリケーションがJBoss EAP上にデプロイされた場合のコンテキスト名(アプリケーション名)になります。何のことかピンと来ない場合は、とりあえずartifactIdと同じ値を入れておきます。 さて、これでプロジェクトの設定が終わりました。このままサンプルアプリを作ることもできますが、軽くpom.xmlの書き方について説明します。 pom.xmlの内容について pom.xmlはxmlで記述するプロジェクトの設定ファイルです。アプリケーションのビルドに関わる設定を記述します。 最初の３行はヘッダーです。４行目のmodelVersionも含めて固定の記述となります。 <project xmlns = "http://maven.apache.org/POM/4.0.0" xmlns : xsi = "http://www.w3.org/2001/XMLSchema-instance" xsi : schemaLocation = "http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd" > <modelVersion> 4.0.0 </modelVersion> 11行目から19行目のpropertiesは変数の設定をしています。16行目のように変数として設定した値はその後に${}で呼び出すことができます。今回の設定ファイルではversion.bom.eeの値はversion.serverと同じになっています。 <properties> <project . build . sourceEncoding> UTF-8 </project . build . sourceEncoding> <maven . compiler . source> 11 </maven . compiler . source> <maven . compiler . target> 11 </maven . compiler . target> <version . server> 8.0.0.GA-redhat-00009 </version . server> <version . bom . ee> ${version.server} </version . bom . ee> <version . plugin . wildfly> 4.1.1.Final </version . plugin . wildfly> <version . plugin . war> 3.3.2 </version . plugin . war> </properties> 21行目から28行目のdependenciesタグには依存するライブラリを定義しています。今回はJBoss EAP 8.0が準拠しているjakartaee-api仕様のライブラリを入れています。これ以外にユーザー側で自由にライブラリを追加する事が可能です。 Mavenでは依存するライブラリはインターネット上から勝手に取得してきます。そのため、別途主導でローカルにダウンロードする必要はありません。 他の追加したいライブラリがある場合は Maven Central 等で検索することもできます。 <dependencies> <dependency> <groupId> jakarta.platform </groupId> <artifactId> jakarta.jakartaee-api </artifactId> <version> 10.0.0 </version> <scope> provided </scope> </dependency> </dependencies> 30行目から53行目のbuildタグではアプリケーションのビルド(コンパイル等)の設定を行っています。 今回は、sourceとtargetに11を入れています。これはOpenJDKの互換バージョンを指定しています。OpenJDK 11で動作できるようにコンパイルしています。2024年9月時点ではJBoss EAP 8.0では11と17で動作させることが可能です。今後のアップデートで21のサポートが追加される予定になっています。 <build> <finalName> example </finalName> <plugins> <plugin> <artifactId> maven-compiler-plugin </artifactId> <version> 3.13.0 </version> <configuration> <encoding> ${project.encoding} </encoding> <source> ${maven.compiler.source} </source> <target> ${maven.compiler.target} </target> </configuration> </plugin> <plugin> <groupId> org.apache.maven.plugins </groupId> <artifactId> maven-war-plugin </artifactId> <version> ${version.plugin.war} </version> </plugin> <plugin> <groupId> org.wildfly.plugins </groupId> <artifactId> wildfly-maven-plugin </artifactId> <version> ${version.plugin.wildfly} </version> </plugin> </plugins> </build> 55行目から120行目では依存ライブラリをどこから取得するのかを定義しています。先ほど言ったとおりにmavenはインターネットに接続して依存ライブラリを取得します。Red Hatでもmavenを通じてライブラリを配布する仕組みを持っており、今回はRed Hatのサーバーへの接続および、Red Hatの設定を使用するように設定しています。 特に細かい値を覚える必要はなく、JBoss EAPで開発をする場合にはこういう設定が必要程度で大丈夫です。 なお、Red Hatのmavenリポジトリを使用していない場合でも本番サポートを受けることは可能ですが、細かい不具合を避けるために使用する事が推奨されます。 <dependencyManagement> <dependencies> <dependency> <groupId> org.jboss.bom </groupId> <artifactId> jboss-eap-ee-with-tools </artifactId> <version> ${version.bom.ee} </version> <type> pom </type> <scope> import </scope> </dependency> </dependencies> </dependencyManagement> <repositories> <repository> <id> jboss-public-maven-repository </id> <name> JBoss Public Maven Repository </name> <url> https://repository.jboss.org/nexus/content/groups/public/ </url> <releases> <enabled> true </enabled> <updatePolicy> never </updatePolicy> </releases> <snapshots> <enabled> true </enabled> <updatePolicy> never </updatePolicy> </snapshots> <layout> default </layout> </repository> <repository> <id> redhat-ga-maven-repository </id> <name> Red Hat GA Maven Repository </name> <url> https://maven.repository.redhat.com/ga/ </url> <releases> <enabled> true </enabled> <updatePolicy> never </updatePolicy> </releases> <snapshots> <enabled> true </enabled> <updatePolicy> never </updatePolicy> </snapshots> <layout> default </layout> </repository> </repositories> <pluginRepositories> <pluginRepository> <id> jboss-public-maven-repository </id> <name> JBoss Public Maven Repository </name> <url> https://repository.jboss.org/nexus/content/groups/public/ </url> <releases> <enabled> true </enabled> </releases> <snapshots> <enabled> true </enabled> </snapshots> </pluginRepository> <pluginRepository> <id> redhat-ga-maven-repository </id> <name> Red Hat GA Maven Repository </name> <url> https://maven.repository.redhat.com/ga/ </url> <releases> <enabled> true </enabled> </releases> <snapshots> <enabled> true </enabled> </snapshots> </pluginRepository> </pluginRepositories> ここまでで今回使用するpom.xmlについてざっと説明しました。詳細を知りたい場合は、Mavenのドキュメントを参照してください。 maven.apache.org ソースコードを書く ここから実際にコーディングをしていきます。 HelloWorldServletクラスの作成 ServletというのはJakarta EEのウェブ仕様の名前です。Servletを使用する事でユーザーから受け取ったリクエストに対してレスポンスを返すことができます。 プロジェクトのsrc/mainを右クリックして、新規(W)からクラスを選択します。 新規クラスの作成 名前にHelloWorlsServlet、スーパークラスにjakarta.servlet.http.HttpServletを右側の参照から指定します。 指定したら完了ボタンを押します。 HelloWorldServletの作成 NOTE: 参照を押した場合に同じクラスが複数表示される場合があります。その場合はどれを選択しても大丈夫です。 HelloWorldServletの内容を次の内容に置き換えます。packageについては適切な値に変更してください。 package [元のファイルの値]; import java.io.IOException; import java.io.PrintWriter; import jakarta.servlet.ServletException; import jakarta.servlet.annotation.WebServlet; import jakarta.servlet.http.HttpServlet; import jakarta.servlet.http.HttpServletRequest; import jakarta.servlet.http.HttpServletResponse; @WebServlet ( "/HelloWorld" ) public class HelloWorldServlet extends HttpServlet { static String PAGE_HEADER = "<html><head><title>helloworld</title></head><body>" ; static String PAGE_FOOTER = "</body></html>" ; @Override protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { resp.setContentType( "text/html" ); PrintWriter writer = resp.getWriter(); writer.println(PAGE_HEADER); writer.println( "<h1> Hello World! </h1>" ); writer.println(PAGE_FOOTER); writer.close(); } } これはhtmlを生成してクライアントに返すプログラムです。Javaでプログラミングされているので内容を自由に変更することができます。@WebServlet("/HelloWorld")でこのプログラムが動作するURLを指定しています。 続いてjspファイルを作成します。上記のようにServletではJava言語の中にhtmlを埋め込みます。逆にjspではhtmlファイルの中にJava言語を埋め込むことができます。そのため、複雑なhtmlを返したい場合はServletよりもjspが多く使用されます。 *2 フォルダ階層からsrc/main/webappを右クリックして、新規(W)->その他(O)を選択します。 jspの新規作成 ウィザードからJSPファイルを選択してダブルクリックします。 jspの新規作成 ファイル名にindex.jspを入力して完了を押します。 index.jspの作成 index.jspを以下のように編集します。 <%@ page language = "java" contentType= "text/html; charset=UTF-8" pageEncoding= "UTF-8" %> <!DOCTYPE html> < html > < head > < meta charset = "UTF-8" > < title > こんにちは世界！ </ title > </ head > < body > < h1 > こんにちは世界！ </ h1 > < p ><% out.println(new java.util.Date()); //ここだけjava言語で記載 %></ p > </ body > これで、アプリケーションの作成は終わりです。 JBoss EAPへのデプロイとデバッグ ここまで終わったらアプリケーションをデプロイします。 Pleiades(Eclipse)ではJBoss Toolsを導入することでIDEからデバッグモードで起動することができます。 NOTE: JBoss Toolsの使い方自体はRed Hatではサポートしていません。 プロジェクトを右クリックして、デバッグ(D)->1.サーバーでデバッグを選択します。 サーバーでデバッグ 手動で新規サーバーを定義(M)からRed Hat JBoss Middlewareの下にあるJBoss AS, WildFly, & EAP Server Toolsを選択して次へを押します。 サーバータイプの選択 NOTE:複数出ている場合はどれを選択しても大丈夫です。現時点では依存ライブラリがローカルに存在しないため、仮のデータが表示されています。 依存ファイルのダウンロードが始まるので待ちます。※ダイアログが一番右にきてからもかなり時間がかかります。 サーバー設定のダウンロード 時間が経つとライセンス条項への同意画面が出るので、同意したうえで完了を押します。 フィーチャーライセンス エラーになるので、一度キャンセルします。 エラー Note: Red Hatではこの手順はサポートしていません。 裏側でインストールが続いているようなので、少し待ちます。右下に進捗が表示されています。 インストール中 時間が経つとオーソリティーの信頼画面が表示されるので、すべてのオーソリティーを信頼します。そしてインストールが進むのを待ちます。 オーソリティーの信頼 また、署名者の信頼画面が表示されるので信頼します。 アーティファクトの信頼 IDEの再起動を促されるので再起動します。 再起動 再起動したら先ほどの手順と同様に、プロジェクトを右クリックして、デバッグ(D)->1.サーバーでデバッグを選択すると開くがめんで、手動で新規サーバーを定義(M)を選択すると Red Hat JBoss Enterprise Application Platform 8.0が増えているのでそれを選択します。 このプロジェクトを実行するときは常にこのサーバーを使用(P)にもチェックを入れておきます。 サーバーでデバッグの選択 詳細な設定はデフォルトのまま次へを押します。 詳細な設定 ランタイムには前回インストールしたJBoss EAPのインストールフォルダを指定します。 ランタイムの設定 セキュリティの警告が表示された場合は許可を押します。 セキュリティの警告 ※セキュリティの警告が表示された場合、ブラウザが自動で立ち上がりません。その場合は、Pleiadesのコンソール上の右上に赤いボタンが表示されているので、それを使って一度サーバーを停止し、再度サーバーを起動してください。 サーバーの停止 実行に成功するとブラウザが立ち上がり、jspの画面が表示されます。 jsp URLにHelloWorldを付けることでServletの画面が表示されます。HelloWorldServletの@WebServletで指定したURLが使われています。 servlet デバッグ さて、デバッグしていきましょう。Servletもjspもホットデプロイができるようになっているので、修正するとそのまま反映されます。 HelloWorldServletの24行目を次のように修正して保存したうえで、画面にアクセスすると即座に変更されます。 writer.println( "<h1> Hello World! </h1>" ); ↓ writer.println( "<h1> Hello World!!!! </h1>" ); servletの変更 ※変更されない場合は、ソースルックアップの設定を修正する必要があります。 デバッグウインドウからソースルックアップの編集(K)を選択し、 ソースルックアップの編集 自分自身のプロジェクトが入っていることを確認してください。 ソースルックアップパスの編集 jspについても変更してみて更新されることを確認してみてください。 デバッグモードではブレークポイントを設定することもできます。 ソースコードの左側をダブルクリックすることでブレークポイントを設定できます。 ブレークポイントの指定 この状態で、ブラウザの画面をF5で更新するとブレークポイントで処理が止まります。メモリ上の値がどうなっているか等を確認することができて便利です。 処理を再開したい場合はデバッグウインドウから停止しているスレッドを選択して再開を押してください。 再開 その一つ下の終了を押すことでサーバーをシャットダウンすることができます。コンソールの左上にあるボタンと同じ機能です。ホットデプロイ機能は完全ではないため、開発中には適時再起動することになります。 *3 また、今回紹介する機能はIntelliJ IDEAやVSCodeでも似たような機能を使用する事ができます。お好きなエディタを使用する事が可能です。 Mavenを使用してのデプロイ 先ほどまではIDEからの操作について説明しました。次はコマンドライン(Maven)からの操作を説明します。 コマンドラインから操作をすることで自動化が行えるため、ある程度システム開発が進むと使用する事になります。 Note: Maven以外にもコマンドラインから操作する方法は多数あります。 MavenからデプロイするためにはEAPサーバーが立ち上がっている必要があります。 ひとつ前の記事の手順と同じように、binのフォルダの下にあるstandalone.batを起動します。 起動したら http://localhost:8080 にアクセスしてサーバーが立ち上がっていることを確認してください。 サーバー起動の確認 Eclipseから開いているプロジェクトのフォルダでコマンドプロンプトを開きます。場所がわからない場合はプロジェクトを右クリックしてプロパティを選択すると確認できます。 ロケーションの確認 mavenでコンパイルをする場合は以下のコマンドを実行します。 *4 mvn package ここからコンパイルしたものをJBoss EAPにデプロイしていきます。wildfly-maven-pluginを使用する事でデプロイできます。wildflyはJBoss EAPのアップストリーム製品(元になったOSS)で、互換性があるのでwildflyのツールをそのまま使用する事ができます。 先にサーバーにアクセスしてPleiades(Eclipse)からデプロイしたアプリケーションにアクセスできるか確認しましょう。 http://localhost:8080/example/ にアクセスしてみます。先ほどと同じ画面が表示されるはずです。 サーバーの画面 コマンドラインから以下のコマンドを実行します。このコマンドはサーバーにデプロイしたアプリケーションを削除します。 mvn wildfly:undeploy ブラウザを更新するとアクセスできなくなります。 404 Note: JBoss EAPのコンソールのログに削除された旨が出力されています。 コマンドラインから次のコマンドを実行します。 mvn wildfly:deploy また画面が表示されるようになります。 再デプロイ Note: JBoss EAPのコンソールのログにデプロイされた旨が出力されています。 Mavenには他のコマンドもあります。何ができるのかについてはMavenのドキュメントを参照してください。 maven.apache.org wildfly-maven-pluginの固有の機能についてはwildflyのページを参照してください。 https://docs.wildfly.org/wildfly-maven-plugin/releases/4.1/ docs.wildfly.org なお、wildfly-maven-pluginの新しいバージョンも公開されていますが、JBoss EAPはwildflyの少し前のバージョンをベースに安定版として製品化されていますので最新のプラグインを使用するのではなく、EAPのドキュメントのページに書かれているバージョンを使用する事がおすすめです。 また、OpenShift上で動作させたい場合はJBoss EAP Maven プラグインを使用する事で追加のタスクを行うことができます。詳細については以下を参照してください。 rheb.hatenablog.com まとめ これでPleiades(Eclipse)を使用してJBoss EAP上でのアプリケーションを開発する準備が整いました。 ただ、環境が整っただけで中身はどうしていけばいい？というのがあると思います。 JBoss EAPはJakarta EE仕様に乗っ取っているのでJakarta EEの参考資料をそのまま使用する事ができます。 例えば、Jakarta EE Tutorialのページを使用する事で一通り学ぶことができます。(英語ですが・・・) https://eclipse-ee4j.github.io/jakartaee-tutorial/ eclipse-ee4j.github.io 動くサンプルが欲しいという場合はjboss-eap-quickstartsを使用する事が可能です。 github.com 他にもJava EE時代の参考書もありますが、Java EEサーバーは長い間互換性が高く更新されてきたため、今でもパッケージ名の変更だけすれば、ほぼそのまま使用する事ができます。 この記事では簡単に初心者向けの概要という形でまとめました。 Jakarta EEは20年以上名前を変えながら使い続けられており、歴史も古くなり、新しい人がはじめるのにはなかなか敷居が高くなっています。初心者の人がなんとなく開発環境を構築できるようになってくれて開発ができるようになってくれると幸いです。 *1 : 一部他のバージョンを使用している場所もあります。 *2 : また、これ以外にも多くのテンプレートライブラリが存在します。 *3 : 開発中はメモリリークを起こしがちです。 *4 : コンパイルしていない場合はデプロイできません

Red Hatのエンジニアコミュニティが贈る恒例イベント「Red Hat Tech Night」が今年も開催されることが決定しました！ 日時: 2024年10月17日(木) 17:00〜18:30 17:00 - 18:00 : LTセッション 18:00 - 18:20 :パネルセッション 場所: 虎ノ門ヒルズフォーラム 5F Red Hat Tech Nightとは、Red Hatの有志ボランティアメンバーによるお祭りで、最新のオープンソース技術や文化、プロジェクトについて、視聴者置いてきぼりで語りたいことを熱く語る技術イベントです。 昨年は、コロナ禍による中断を経て、2年ぶりの開催となったRed Hat Tech Night。わずか60分という短い時間にもかかわらず、大盛況のうちに幕を閉じました。Podmanの最新情報や、Ansible Automation Platformの実行環境についてのセッションでは、登壇者の個性が光る発表が繰り広げられ、会場は大いに盛り上がりました。 また、エンジニアだけでなく営業や人事のメンバーも登壇したパネルディスカッションでは、Red Hatの企業文化やダイバーシティへの取り組みについて率直な意見が交わされ、普段は聞けないリアルな声に、参加者も耳を傾けていました。 そして今年は、時間を30分延長し、90分でお届けします。さらにパワーアップした内容にご期待ください！ もちろん、ライトニングトークも健在です。トピックを一部紹介！ 5分で完全理解！ゼロからはじめるOpenShift Virtualization アジャイルあるある2つの言語問題とその緩和に関する考察 Apache Camel 最新開発環境のご紹介 JBoss EAPによるクラウドネイティブのススメ ルールエンジンとLLMで嘘をつかないAIを作ろう MTPEもやもや&もくもく会の活動報告 Red Hat社員の「技術への情熱」と「ちょっと変わった個性」が炸裂する、目が離せないセッションになるでしょう。 パネルディスカッションでは、Red Hatで働くさまざまなバックグラウンドを持つメンバーが、それぞれの視点からRed Hatという企業の姿を浮き彫りにします。 Red Hat Tech Night 2024は、去年の盛り上がりをさらに超える、熱気あふれるイベントになること間違いなし。技術に興味があるすべての方に、ぜひご参加いただきたいと思います。 参加登録は以下のURLから。皆様のご来場を心よりお待ちしております！ http://red.ht/summit-connect-jp-technight

Red Hatの森若です。 去年の「 ChatGPTをRHELの運用に使えるか? いろいろためしてみた。 - 赤帽エンジニアブログ 」に引き続き、流行りもので遊んでみたシリーズです。 RHELのドキュメントはたくさんあります。今しらべるとRHEL8で73冊、RHEL9で76冊ありました。 単純なケースではGoogleで site: の指定をして検索するとそれらしい箇所が見つかり、そこから前後を拾い読みすればなんとかなることがよくあります。 httpd ssl certificate site:docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/ 一方で調査目的によっては複数のドキュメントから関連箇所を少しずつピックアップする必要があります。 具体的にはリリースノートで「RHEL8.x から8.10までのhogehugaについての変更をまとめたい」のような状況です。 このような時に表題のGoogle NotebookLMが役に立ちます。LLMの宿命で完璧ではないとはいえ、いい線までいってくれます。 PDFドキュメントのダウンロード まずはRed Hat ドキュメントのダウンロードです。残念ながら最近のデザイン変更でPDFのダウンロードは面倒になりました……のでダウンロードするスクリプトを作りました。 gist.github.com 製品バージョン毎にある、ドキュメントのインデックスページのURLをオプションで指定するとPDFをダウンロードします。 Google NotebookLM にとりこみ https://notebooklm.google.com/ を開いて 「新しいノートブック」を作成すると「アップロード元」というダイアログが表示されるのでダウンロードしたドキュメントを登録していきます。 ここではRHEL 8のリリースノート全部と、Consideration of adopting RHEL 8を登録します。NotebookLMは英語の資料を渡しても日本語でやりとりできるので、英語版のリリースノートを登録しました。 田 みたいなボタンを押すとソースを追加できます アップロード後しばらく待つと登録が完了します。これで準備が終わりです。これだけでいいの凄いですね……。 質問してみる 「ソース毎にまとめて」と言うと、リリースノートの場合バージョン毎にまとめてくれます。不要な内容の指定もできます。 たとえば以下のように聞いてみます「rsyslogの変更についてソース毎にまとめて。RHEL システムロールの情報は除外して。」 これが10秒で出るのは強い 前提として抜け漏れ間違いがあるにしても、10秒ほどでそれらしい回答を出してくるのは凄いです。灰色の数字は参考にしたソース箇所へのリンクです。 少なくとも「大量に内容があるので全リリースノートを確認する必要がありそう」「モジュール毎に記述があるから先に調査対象モジュールを整理した方がよさそう」「リベースを何回かしている」のようなことがすぐにわかります。 「systemdのリベースの記述はある?」と聞くと「見つかりませんでした」と回答してきます。無いって言えるの凄いですね。実際にRHEL 8ではsystemdのリベースは行われておらずずっと239なので正解です。ただししばらく遊んでみた印象では「有無の確認」のようなクエリは少し苦手なようです。 実際にも無いので当たり 「spaxがdeprecatedなソースを列挙」一見それらしい回答をしていますが 8.6〜8.9のリリースノートをみつけている一方で、なぜか8.10リリースノートでの記述は見逃しています。 8.10のリリースノートがソースから漏れている 「rsyslogの設定に影響を与える変更を列挙」"影響を与える" はかなりふんわりとした言葉なので意地悪問題です。「設定を変更する必要が発生するような」くらいの意図で使われることが多いかと思いますが設定項目が増えるようなあらゆる変更を列挙して……いたのですが途中で話が逸れてしまいました。 最初はそれらしい…… 関係ない話をしだした…… まとめ NotebookLM画面下部に「NotebookLM はまだ不正確な回答をすることがあるため、ご自身で事実確認されることをおすすめします。」と書いている通り、事実確認には使えません。 しかし確認以前の「多少はずしてもいいのでなんとなく雰囲気をつかみたい」「だいたいのボリュームを知りたい」のような用途ではかなり活躍してくれそうです。

はじめに こんにちは、Red Hat のコンサルタントの陳です。今回は、Red Hat Developer Sandbox を利用し、GitOps の開発を簡単に試せる手順をご紹介します。より実践的な内容で OpenShift の魅力を感じていただければと思います。 目次 Red Hat Developer Sandbox とは？ GitOps とは？ このブログで得られるもの リポジトリの紹介 仕組みの紹介 実施手順 おわりに 1. Red Hat Developer Sandboxとは？ Red Hat Developer Sandboxは、誰でも無料で手軽にOpenShiftを体験できるクラウドベースの環境です。これを利用することで、インフラの設定や管理に煩わされることなく、すぐにアプリケーションの開発やデプロイを始めることができます。 2. GitOpsとは？ GitOps は、Git リポジトリを信頼できる唯一の情報源として使用し、インフラストラクチャをコードとして提供します。登録されたコードは CI プロセスでチェックされ、CD プロセスではセキュリティやコードとしてのインフラストラクチャなど、アプリケーションフレームワークに設定された境界線に関する要件がチェックおよび適用されます。コードの変更はすべて追跡されるため、アップデートが容易になると同時に、ロールバックが必要な場合のバージョン管理も可能です。 3. この記事で得られるもの Red Hat Developer Sandboxの使い方 GitOpsの基本概念とその利点への理解 OpenShift上のパイプラインの構築方法 各種マニフェストの記述方法 StorybookやSonarqubeなどのツールの使い方 4. リポジトリの紹介 今回使用するリポジトリは以下の二つです： red-hat-developer-sandbox-apps こちらのリポジトリでは、以下のものが格納されています。 各種アプリケーションのソースコード ローカルでアプリケーションをデプロイするためのDockerファイル red-hat-developer-sandbox-manifest こちらのリポジトリでは、以下のものを格納します。 各種リソースのマニフェストファイル アプリケーションのコードとマニフェストを分離することで、運用や管理が容易になります。 分離の利点 変更の管理 アプリケーションのコードとマニフェストが別々のリポジトリに配置されているため、変更の影響範囲を明確に分けることができます。例えば、アプリケーションのアップデートとインフラの変更がそれぞれ独立して行えます。 チームの役割分担 開発チームと運用チームがそれぞれのリポジトリを担当することで、役割分担が明確になります。開発者はアプリケーションのコードに集中し、運用チームはインフラストラクチャの管理に集中できます。 5. 仕組みの紹介 アプリケーション sample-app: quarkus で開発したAPI、sonarqube 連携の設定が入っています sample-view: nextjs で開発した画面、sonarqube 連携の設定が入っています、storybook を起動できます test-reports: パイプラインで実施した各種テストのレポートをまとめて表示するもので、nodejs で書いた簡単な web サーバー e2e: Playwright で実現した End To End Test、sample-view の画面を開いて、ボタンクリックして、sample-app に api 呼び出し、取ってきたレスポンスを画面に正しく表示できるかチェック integration-test: API のプロセスにリクエストを投げるような結合テスト マニフェスト gitops-pipeline: こちらのマニフェストを最初に手動で openshift にデプロイします。本来は Openshift GitOps(ArgoCD) を使うべきですが、Sandboxの制限で使えませんでした。代わりに、マニフェストを適用するパイプラインを作成しました。 apps-pipeline: こちらのマニフェストは gitops-pipeline によってデプロイされます。その中で CI を行います。 build-and-push-sample-app-image で git commit の hash 値をアプリケーションのイメージタグにして registry に push した後、そのタグを update-sample-app-image-tag-in-repo-it で apps にある it 環境のマニフェストを更新して、git push することで、gitops-pipeline が実行され、it 環境に最新のイメージがデプロイされます。 ほかに、sonarqubeやtest-reportをデプロイするためのマニフェストも入っています。 apps: ここに、アプリケーションをデプロイするためにマニフェストが保存されています。 6. 実施手順 手順は こちら に纏めました。 7. おわりに これで、Red Hat Developer Sandbox を使った GitOps 開発パイプラインの設定が完了しました。この環境を活用することで、OpenShiftの強力な機能を体験し、すこしでも OpenShift に興味を持っていただければと思います。

Red Hatでソリューションアーキテクトをしている田中司恩( @tnk4on )です。 この連載はvSphere環境上にOpenShift Container Platform（以下、OpenShift）およびOpenShift Virtualizationの環境を構築する方法を解説するシリーズです。 第4回はOpenShift Virtualizationのインストールと実行方法について解説します。今後の連載予定は下記の通りです。 第1回：OpenShiftのインストール 第2回：OpenShiftインストール後の作業 第3回：共有ストレージの作成（NFS CSIドライバーの構築） 第4回：OpenShift Virtualizationのインストールと実行 （←本記事） 第5回：vSphere仮想マシンの移行 【番外編】：共有ストレージの作成（NFSプロビジョナーの構築） （2024/9/29追記：OpenShift Virtualization v4.16.3でNested環境のライブマイグレーションの不具合は修正されました） （2024/10/1追記：OpenShift Virtualization v4.16.2で、起動ボリュームからCentOS 7およびCentOS Stream 8は削除されました） -目次- OpenShift Virtualizationのインストールと実行方法 リファレンス実装ガイド サポート対象のゲストオペレーティングシステム 前提条件 1. OpenShift Virtualizationのインストール 1-1 インストールの概要 1-2 インストールの前提条件 1-3 OpenShift Virtualization Operatorのインストール 1-4 HyperConvergedの作成 1-5 インストール後の確認 （1）カタログ画面の確認 （2）コンテナーディスクの確認 2. 追加のOpenShiftの設定変更 2-1 クローンストラテジーの変更 2-2（OpenShift v4.16.0-v4.16.3限定）Console Operatorが再起動を繰り返すバグの修正 2-3 ライブマイグレーション用ワークアラウンドの実施（OpenShift Virtualization v4.16.0-v4.16.2限定） 3. CLIツール（virtctl）のインストール 3-1 virtctlのインストール 4. 仮想マシンの作成（インスタンスタイプから作成） 4-1 インスタンスタイプから作成する 4-2 定義済みのインスタンスタイプとは 4-3 仮想マシンの作成 4-4 仮想マシンへコンソールでアクセス 4-5 仮想マシンへvirtctlでリモートアクセス 5. 仮想マシンの作成（テンプレートから作成） 5-1 テンプレートから作成する 5-2 インストールの準備 5-3 仮想マシンの作成 6. 仮想マシンの起動と停止 6-1 仮想マシンの停止 6-2 仮想マシンの起動 6-3 OS内でシャットダウンした時の動作の変更 （1）OS内からのシャットダウンで仮想マシンの停止を有効化する （2）元の設定に戻す方法 7. 仮想マシンのライブマイグレーション 7-1 ライブマイグレーションについて 7-2 ライブマイグレーションの実行 まとめ OpenShift Virtualizationのインストールと実行方法 本記事では OpenShift Virtualizationのインストールと実行方法について、下記の内容を紹介します。 OpenShift Virtualizationのインストール 追加のOpenShiftの設定変更 CLIツール（virtctl）のインストール 仮想マシンの作成（インスタンスタイプから作成） 仮想マシンの作成（テンプレートから作成） 仮想マシンの起動と停止 仮想マシンのライブマイグレーション OpenShift Virtualizationでは インスタンスタイプから作成する方法 と テンプレートカタログから作成する方法 の2種類の仮想マシンの作成方法があります。 本記事において、インスタンスタイプから作成する方法ではRHEL 9の仮想マシンの作成方法を、テンプレートカタログから作成する方法ではWindows Server 2022の仮想マシンの作成方法を紹介します。 リファレンス実装ガイド OpenShift Virtualizationの構成のための参考情報として、リファレンス実装ガイド（英語）が公開されています。 最小構成の3ノード構成から大規模構成まで、ハードウェアの構成のための参考となる情報が記載されています。 実稼働環境でのサイジングの参考にしてください。 OpenShift Virtualization - リファレンス実装ガイド - Red Hat Customer Portal サポート対象のゲストオペレーティングシステム OpenShift VirtualizationがサポートするゲストOSのリストは下記のページに記載があります。 Certified Guest Operating Systems in Red Hat OpenStack Platform, Red Hat Virtualization, Red Hat OpenShift Virtualization and Red Hat Enterprise Linux with KVM - Red Hat Customer Portal RHELとWindows（クライアントOSおよびServer OS）について記載があり、それ以外のOSについては、 Red Hatのサードパーティのソフトウェアサポートポリシー *1 に従ってサポートされます。 Windows Server OSのサポートは Microsoft SVVP にて認定されています。 なお、Microsoft SVVPではクライアントOSの認定はないため、たとえばWindows 11はWindows Server 2022と同様にサポートされます。 SVVPにおけるOpenShift 4.16とWindows Server 2022の掲載の例 前提条件 連載 第3回 の作業を完了していることとします 全体の構成や各パラメーターなどは第1回を参照してください 作業用端末のプロンプトは % とします 踏み台サーバーのプロンプトは $ とします 踏み台サーバーの作業は明示的に記載がある場合を除いて、作業ディレクトリ ${HOME}/work で作業することとします 第3回の作業完了後の構成 1. OpenShift Virtualizationのインストール 1-1 インストールの概要 OpenShift Virtualizationのインストールは、 Operator を使用して行います。Operatorとは、Kubernetes上でアプリケーションやサービスのライフサイクル管理を自動化するためのカスタムリソースです。 Operatorを使ったインストールは、OpenShift上の Operator Hub メニューから実施します。Operator HubはOpenShiftに統合された機能のひとつで、リストされたOperatorの中から選択したものを簡単にOpenShift上に追加できるカタログ機能です。これにより、OpenShift自体の機能追加や、その他のミドルウェアアプリケーションの導入が容易になります。 Operatorを使ったOpenShift Virtualizationのインストールの流れは下記の通りです。 OpenShift Virtualizationのインストールの流れ OpenShift Virtualization Operatorのインストール HyperConvergedの作成 *2 OpenShift Virtualization OperatorおよびHyperConverged Operatorを構成する各コンポーネントの詳細は、下記のドキュメントを参照してください。 1.3. OpenShift Virtualization アーキテクチャー | Red Hat Product Documentation 1-2 インストールの前提条件 OpenShift Virtualizationを実行するためには、仮想マシンの実行元となるコンピュートノードには物理（ベアメタル）サーバーが必要です。 オンプレ以外のクラウド環境では、AWSまたはIBM Cloud（Tech Preview）がサポートプラットフォームです。 OpenShift Virtualizationのサポート対象のプラットフォームについては下記のドキュメントを参照してください。 第4章 インストール | Red Hat Product Documentation なお、本連載ではvSphere仮想環境を使った最小構成での検証環境構築を目的としています。 そのため本来必要な物理サーバーではなく、仮想マシン上のコンピュートノード（今回は3ノード構成のためコントロールプレーンと兼用）上で実行します。 物理サーバーを用意できる場合は、実稼働環境と同様に物理サーバー上に直接OpenShiftをインストールしてご利用ください。 1-3 OpenShift Virtualization Operatorのインストール ここからOpenShift Virtualizationの具体的なインストール作業を開始します。 対象のドキュメントは下記を参照してください。 4.2. OpenShift virtualization のインストール | Red Hat Product Documentation OpenShiftのWebコンソールから「Operator>Operator Hub」メニューを選択します。 Operator Hubの一覧画面が表示されます。ここではRed Hatの提供Operatorだけでなく、Red Hatパートナーやコミュニティ提供のOperatorも表示されます。 Operator Hubの一覧画面 キーワードの入力欄に openshift virt と入力するとフィルタリングされて「OpenShift Virtualization」と「Migration Toolkit for Virtualization Operator」の2つが表示されます。 ここでは「OpenShift Virtualization」を選択します。なお、Migration Toolkit for Virtualization Operatorは連載第5回でインストールを行います。 キーワードでフィルタリングしてOpenShift Virtualizationを選択 チャネルとバージョンはデフォルト表示のままで「インストール」を押します。 OpenShift Virtualization Operatorのインストール インストールの詳細入力画面が開きます。ここでもデフォルト表示のままインストールを押します。 なお、（HC）OpenShift Virtualization Deploymentが 必須 となっていますが、これは後ほどインストールするのでそのまま無視します。 Operatorのインストール詳細入力画面 更新チャネル：stable（stable以外にはdev-perviewがある） バージョン：4.16.0（本記事執筆時点では「4.16.0」が最新） インストールモード：クラスターの特定のnamespace インストール済みのnamespace：Operator推奨のnamespace:openshift-cnv *3 更新の承認：自動 OpenShift Virtualization Operatorのインストールが開始します。環境にもよりますが、インストールの完了まで3分半から4分程度かかります。インストールの完了までそのままでお待ちください。なお、インストール自体はバックグラウンドで継続されるため、他の画面に遷移しても問題ありません。 OpenShift Virtualization Operatorのインストール中の画面 インストールが完了すると「HyperConvergedの作成」ボタンが表示されます。これを押して次のステップに進みます。 OpenShift Virtualization Operatorのインストール後の画面 1-4 HyperConvergedの作成 先のステップで「HyperConvergedの作成」ボタンを押すと、「HyperConvergedの作成画面」が表示されます。 HyperConvergedの作成画面 この「HyperConvergedの作成画面」は、Webコンソールのメニューから「Operator>インストール済みのOperator>OpenShift Virtualization」を選択して表示される画面上の、「HyperConvergedの作成」ボタンを押した後に出る画面と同じものです。別の画面に遷移した場合はここから作業を継続してください。 インストール済みのOperatorの詳細画面 「HyperConvergedの作成画面」でフォームビューのまま一番下にスクロールし、すべてのパラメーターはデフォルトのままで「作成」を押します。 フォームビューを下までスクロールし、作成を押す 「作成」ボタンを押した後は自動で「インストール済みのOperator>Operatorの詳細画面」から、 OpenShift Virtualization Deployment のタブが選択された状態の画面に遷移します。 HyperConvergedの作成中の画面 インストールが進むにつれステータスの表示が変わります。ここも環境によりますが、完了まで4分ほどかかりますのでまでそのまま待機します。 インストールの完了後、画面上部にポップアップ画面が表示されます。ポップアップ画面内の「Webコンソールの更新」のリンクを押す、またはブラウザをリロードします。 HyperConvergedの作成後、Webコンソールの更新のポップアップが表示される 画面の更新後、Webコンソールのメニュー内に「Virtualization」の項目が追加されています。 Webコンソール更新後の画面 Webコンソールのメニューから「Virtualization>Overview」を選択します。初回アクセス時は「Welcome to OpenShift Virtualization」の画面が表示されます。「Do not show this again」のチェックボックスを選択すると次回からは表示されません。 初回アクセス時はWelcome to OpenShift Virtualizationの画面が表示される OpenShift VirtualizationのOverview画面 1-5 インストール後の確認 OpenShift Virtuzalizationのインストールの確認を行います。 （1）カタログ画面の確認 Webコンソールのメニューから「Virtualization>Catalog」を選択します。 OpenShift Virtualizationのカタログ画面 ここでは仮想マシンの作成時に使用する 起動ボリューム や テンプレートカタログ が選択できます。 カタログ画面のデフォルトは「InstanceTypes」のタブが選択されており、ここでは起動ボリュームからOSを作成できます。 初期状態では「CentOS Stream 8、CentOS Stream 9、CentOS 7、Fedora、RHEL 8、RHEL 9」が用意されています。 （追記：OpenShift Virtualization v4.16.2で、起動ボリュームからCentOS 7およびCentOS Stream 8は削除されました） なお、これらの起動ボリュームはHyperConvergedの作成直後は登録されておらず、バックグラウンドで追加の処理が自動で行われます。 HyperConvergedの作成直後は起動ボリュームは登録されていない この自動追加処理は起動ボリュームの元になる「コンテナーディスク」をインターネット上からダウンロードし、PVCおよびPVとして追加が行われます。 コンテナーディスクとは、OpenShift Virtualizationの仮想マシンの作成元となるOSのインストール済みのイメージのことです。コンテナーディスクは初期で登録されたもの以外に、ユーザーが任意でカスタムイメージを作成できます。作成手順は下記のドキュメントを参照ください。 7.2. カスタムイメージからの仮想マシンの作成 | Red Hat Product Documentation なお、このコンテナーディスクはコンテナイメージとして作成、配布を行いますが、「bootc（Image mode for RHELの基礎技術）」とは 異なるイメージ形式 です。混同しないようにご注意ください。 （2）コンテナーディスクの確認 Webコンソールのメニューから「ストレージ>PersistentVolumeClaims」を選択します。 プロジェクトの選択から「openshift-virtualization-os-images」を選択することで表示をフィルタリングできます。 カタログ画面で確認した起動ボリュームに対応するPVCおよびPVが登録されているのが確認できます。 自動で追加された起動ボリューム用のPVCとPVの一覧 踏み台サーバー上で下記のコマンドを実行すると、作成されたPVの実ディレクトリの中身を確認できます。 起動ボリュームのPVはディレクトリ配下に disk.img を持つ形式で保存されていることがわかります。 $ tree /mnt/nfs/ | grep -E 'disk.img|pvc-' ├── pvc-7843e9b5-03d2-41b2-a7b8-2fd95399dde3 │   └── disk.img ├── pvc-8899284c-25c4-4dd9-8a90-47875bbc9cf5 │   └── disk.img ├── pvc-b3c88568-404c-40c1-a4c8-d252b804a9fc ├── pvc-ba1e3638-e52b-45f9-aa10-3c89a34536b8 │   └── disk.img ├── pvc-e141698e-886e-4eee-a89c-40acf0813b4a │   └── disk.img ├── pvc-e21e08d2-9621-4d54-895b-07059f1a0942 │   └── disk.img └── pvc-f72ca6c3-39ec-46bf-9900-6f2e95ba5c74 └── disk.img OpenShift Virtualizationのインストールが確認できたので、次のステップ以降では仮想マシンのインストールを行います。 2. 追加のOpenShiftの設定変更 本連載で構築する環境では、追加でいくつかの設定変更を行います。 2-1 クローンストラテジーの変更 OpenShift Virtualizationのデフォルト設定では、仮想マシンの作成時にスナップショットを使った起動ボリュームのクローンを行います。 ストレージのCSIドライバーがスナップショットに対応している場合はその機能が使われます。 連載 第3回 で導入したNFS CSIドライバーはスナップショットに対応していますが、そのバックエンドはLinuxで構築した汎用的なNFSサーバーをしています。そのためデフォルトの設定のままでは仮想マシンの作成に非常に時間がかかり、また仮想マシンの作成に失敗することが分かりました。 クローンストラテジーの設定は下記のコマンドで確認できます。 spec の設定は空ですが、デフォルトでは cloneStrategy: snapshot が設定されていることが status の内容から分かります。 確認コマンド $ oc get storageprofiles nfs-csi -o yaml 確認コマンドと結果（一部省略） $ oc get storageprofiles nfs-csi -o yaml apiVersion: cdi.kubevirt.io/v1beta1 kind: StorageProfile ... spec: {} status: claimPropertySets: - accessModes: - ReadWriteMany volumeMode: Filesystem cloneStrategy: snapshot dataImportCronSourceFormat: pvc provisioner: nfs.csi.k8s.io snapshotClass: csi-nfs-snapclass storageClass: nfs-csi ... 本連載ではこの設定を snaphost から copy に変更します。これにより、仮想マシンの作成時に起動ボリュームを元に、単純なファイルコピーによるクローンが実行されます。 なお、この変更は本連載の環境で確実に動作させることを目的としており実稼働環境で必ずしも推奨するものではありません。実稼働環境におけるクローンストラテジーの設定は、お使いのストレージやストレージ用CSIドライバーで最適なものを採用ください。詳細は各ストレージベンダーにお問い合わせください。 クローンストラテジーの設定変更コマンドは下記です。 実行コマンド $ oc patch storageprofile nfs-csi --type=merge -p '{"spec": {"cloneStrategy": "copy"}}' 実行コマンドと結果 $ oc patch storageprofile nfs-csi --type=merge -p '{"spec": {"cloneStrategy": "copy"}}' storageprofile.cdi.kubevirt.io/nfs-csi patched コマンド実行後は下記のように設定内容が変更されます。 確認コマンド $ oc get storageprofiles nfs-csi -o yaml 確認コマンドと結果（一部省略） $ oc get storageprofiles nfs-csi -o yaml apiVersion: cdi.kubevirt.io/v1beta1 kind: StorageProfile ... spec: cloneStrategy: copy status: claimPropertySets: - accessModes: - ReadWriteMany volumeMode: Filesystem cloneStrategy: copy dataImportCronSourceFormat: pvc provisioner: nfs.csi.k8s.io snapshotClass: csi-nfs-snapclass storageClass: nfs-csi ... 2-2（OpenShift v4.16.0-v4.16.3限定）Console Operatorが再起動を繰り返すバグの修正 OpenShift v4.16.0からv4.16.3にはConsole OperatorのPodが頻繁に再起動を繰り返すバグがあります。 Console OperatorのPodが頻繁に起動を繰り返すことがある このバグのKCSは下記です。 Console keeps deploying frequently in OpenShift 4.16 - Red Hat Customer Portal このバグの影響により、OpenShift Virtualizationのコンソール画面が頻繁に切れるという現象が発生します。 すでにOpenShift v4.16.4で修正リリースが行われていますが、v4.16.0からv4.16.3のバージョンを使っている場合は下記のワークアラウンドのコマンドを実行してください。 なお、該当バージョン以外（たとえばv4.15.x）では実行は不要です。 実行コマンド $ oc create configmap cluster-monitoring-config -n openshift-monitoring --from-literal=config.yaml='telemeterClient: enabled: false' 実行コマンドと結果 $ oc create configmap cluster-monitoring-config -n openshift-monitoring --from-literal=config.yaml='telemeterClient: enabled: false' configmap/cluster-monitoring-config created 確認コマンド $ oc get configmap -n openshift-monitoring cluster-monitoring-config -o yaml apiVersion: v1 data: config.yaml: |- telemeterClient: enabled: false kind: ConfigMap metadata: creationTimestamp: "2024-07-25T18:49:01Z" name: cluster-monitoring-config namespace: openshift-monitoring resourceVersion: "3138283" uid: 1f475c16-42b0-4dfb-baa1-5040f8d9ab07 2-3 ライブマイグレーション用ワークアラウンドの実施（OpenShift Virtualization v4.16.0-v4.16.2限定） （追記：OpenShift Virtualization v4.16.3で下記の不具合は修正済みです） OpenShift v4.16でOpenShift Virtualizationをインストールする際、デフォルトではOpenShift Virtualization v4.16.0が選択されます（本記事執筆時点）。 OpenShift Virtualization v4.16.0で使用されるlibvirtに問題があり、特定の環境でライブマイグレーションに失敗します。 今回の検証環境ではNested環境でOpenShift Virtualizationの仮想マシンを実行しているためか、この問題が発生します。 [RHEL-30622] VM failed to save with error "Target CPU feature count 34 does not match source 105" - Red Hat Issue Tracker バグの特定とアップストリームでの修正は行われていますが、OpenShiftとしての修正リリースはまだです。 そこで、本記事ではCPUモデルに host-passthrough を指定することでワークアラウンドを実施しこの問題に対応します。 このワークアラウンドはRed Hatが公式に出しているものではありません。ご注意ください。 このワークアラウンドは同一ホスト上の仮想マシン同士であれば同じCPUを利用するので、 host-passthrough の設定でも問題なくライブマイグレーションできることを利用しています。 *4 この設定は kubevirt-hyperconverged カスタムリソースに設定するため、グローバル設定となります。 個別の仮想マシンごとに設定を行いたい場合は、 VirtualMachine カスタムリソースに個別に設定してください。 まず、既存の設定を確認します。デフォルトでは設定はないため null になります。 $ oc get -n openshift-cnv hco kubevirt-hyperconverged -o json | jq .spec.defaultCPUModel null ワークアラウンドの追加は下記のコマンドを実行します。 実行コマンド $ oc patch -n openshift-cnv hco kubevirt-hyperconverged --type=json -p '[{"op": "add", "path": "/spec/defaultCPUModel", "value": "host-passthrough"}]' 実行コマンドと結果 $ oc patch -n openshift-cnv hco kubevirt-hyperconverged --type=json -p '[{"op": "add", "path": "/spec/defaultCPUModel", "value": "host-passthrough"}]' hyperconverged.hco.kubevirt.io/kubevirt-hyperconverged patched 設定が反映されたか確認します。 実行コマンド $ oc get -n openshift-cnv hco kubevirt-hyperconverged -o json | jq .spec.defaultCPUModel 実行コマンドと結果 $ oc get -n openshift-cnv hco kubevirt-hyperconverged -o json | jq .spec.defaultCPUModel "host-passthrough" このグローバル設定は、各仮想マシンの起動時に読み込まれて仮想マシンに設定が反映されます。仮想マシンの起動時に設定変更した場合は、仮想マシンを再起動して反映してください。 仮想マシンの設定状況を確認するには、 VirtualMachineInstance カスタムリソースの設定を確認します。 仮想マシン名： rhel-9-salmon-parrotfish-27 の設定を確認するコマンドは下記になります。 実行コマンド $ oc get vmi -n ocp-virt rhel-9-salmon-parrotfish-27 -o json | jq .spec.domain.cpu.model デフォルトの設定値の場合（ host-model が設定されている） $ oc get vmi -n ocp-virt rhel-9-salmon-parrotfish-27 -o json | jq .spec.domain.cpu.model "host-model" ワークアラウンドの設定後（ host-passthrough が設定されている） $ oc get vmi -n ocp-virt rhel-9-salmon-parrotfish-27 -o json | jq .spec.domain.cpu.model "host-passthrough" 3. CLIツール（virtctl）のインストール 仮想マシンの作成の前に、作業で利用するCLIツール「virtctl」をインストールします。 virtctlを使うことでOpenShift Virtualizationの操作をCLIで行うことができます。 virtctlのインストール方法や対応しているコマンドは下記のドキュメントを参照してください。 3.2. CLI ツールの使用 | Red Hat Product Documentation 3-1 virtctlのインストール Webコンソールのメニューから「Virtualization>Overview」を選択します。 Overview画面の右上に「Download the virtctl command-line utility」のリンクがあります。 Overview画面からvirtctlのダウンロード先へのリンクを選択 リンクを選択すると各コマンドラインツールの入手先一覧が表示されます。 コマンドラインツールの一覧画面 virtctlの一覧から「Download virtctl for Linux for x86_64」のリンクをコピーします。 リンク先は下記のような形式になります。 https://hyperconverged-cluster-cli-download-openshift-cnv.apps.ocp.home.lab/amd64/linux/virtctl.tar.gz このリンクはOpenShiftクラスター上に作成されています。なお、virtctl以外のツールはインターネット上のリンク先からダウンロードすることになります。 踏み台サーバー上でコピーしたリンクをペーストし、下記のコマンドを実行します。 $ curl -L -o - https://hyperconverged-cluster-cli-download-openshift-cnv.apps.ocp.home.lab/amd64/linux/virtctl.tar.gz | sudo tar -C /usr/local/bin -xvzf - virtctl virtctl コマンドが実行できることを確認します。 $ virtctl Available Commands: addvolume add a volume to a running VM adm Administrate KubeVirt configuration. completion Generate the autocompletion script for the specified shell ... virtctl コマンドの自動補完を有効化します。 $ virtctl completion bash > virtctl_bash_completion $ sudo cp virtctl_bash_completion /etc/bash_completion.d/ $ exec bash $ virtctl (<--スペースに続けてTABキーを押す) addvolume (add a volume to a running VM) pause (Pause a virtual machine) adm (Administrate KubeVirt configuration.) permitted-devices (List the permitted devices for vmis.) completion (Generate the autocompletion script for the specified shell) port-forward (Forward local ports to a virtualmachine or virtualmachineinstance.) ... 4. 仮想マシンの作成（インスタンスタイプから作成） 起動ボリュームとインスタンスタイプを選択し、RHEL 9仮想マシンを作成する方法を紹介します。 インスタンスタイプからRHEL 9仮想マシンの作成 4-1 インスタンスタイプから作成する Webコンソールのメニューから「Virtualization>Catalog」を選択します。 カタログ画面のデフォルトでは「InstanceTypes」のタブが選択されます。 カタログ画面のデフォルトはInstanceTypesのタブが選択 インスタンスタイプから作成する方法では、3つのステップを経て仮想マシンを作成します。 インスタンスタイプから作成する作業フロー 起動ボリュームの選択（Select volume to boot from） インスタンスタイプの選択（Select InstanceType） 仮想マシンの詳細設定（VirtualMachine details） ステップ1「起動ボリュームの選択」は、本記事「1-5 インストール後の確認」で解説済みですのでここでは省略します。 ステップ2「インスタンスタイプの選択」では、作成する仮想マシンに適用するリソースと特性を事前に用意された 定義済みのインスタンスタイプ から選択します（詳細は後述）。 ステップ3「仮想マシンの詳細設定」では、仮想マシン名やストレージクラス、SSH公開鍵の事前設定などを行います。 4-2 定義済みのインスタンスタイプとは OpenShift Virualizationではデフォルトで5つのインスタンスタイプのシリーズ（N、CX、U、GN、M）が用意されています。 標準的なリソースのものから特定のワークロードに特化したもの（たとえばGPUを搭載したものなど）をここから選択できます。 各インスタンスタイプはさらに nano から 8xlarge のサイズまでの雛形が用意されています。 インスタンスタイプの各シリーズの上にマウスオーバーするとそのシリーズの詳細が表示されます。 各シリーズ上にマウスオーバーすると詳細が表示される また、インスタンスタイプの各シリーズ上で選択するとそのシリーズが対応しているサイズの一覧が表示されます。 仮想マシンを作成する時はここから任意のサイズを選択します。 各シリーズを選択すると対応するサイズ一覧が表示される インスタンスタイプの各サイズの内容がどのように定義されているかは oc get vmcf コマンドを使って表示できます。 たとえば、 u1.medium のサイズのスペックの定義は下記のコマンドで表示できます。 $ oc get vmcf u1.medium -o json | jq '.spec' { "cpu": { "guest": 1 }, "memory": { "guest": "4Gi" } } なお、本連載の環境では UシリーズまたはMシリーズのみ利用可能 です。他のシリーズを選択した場合は必要なリソースが提供できないため 仮想マシンの作成が失敗します 。ご注意ください。 参考に、各シリーズの最小サイズのスペックの定義を載せておきます。どのような内容が定義されているかご確認ください。 u1.microのspecの出力結果を開く $ oc get vmcf u1.micro -o json | jq '.spec' { "cpu": { "guest": 1 }, "memory": { "guest": "1Gi" } } gn1.xlargeのspecの出力結果を開く $ oc get vmcf gn1.xlarge -o json | jq '.spec' { "cpu": { "guest": 4 }, "gpus": [ { "deviceName": "nvidia.com/A400", "name": "gpu1" } ], "memory": { "guest": "16Gi" } } cx1.mediumのspecの出力結果を開く $ oc get vmcf cx1.medium -o json | jq '.spec' { "cpu": { "dedicatedCPUPlacement": true, "guest": 1, "isolateEmulatorThread": true, "numa": { "guestMappingPassthrough": {} } }, "ioThreadsPolicy": "auto", "memory": { "guest": "2Gi", "hugepages": { "pageSize": "2Mi" } } } m1.largeのspecの出力結果を開く $ oc get vmcf m1.large -o json | jq '.spec' { "cpu": { "guest": 2 }, "memory": { "guest": "16Gi", "hugepages": { "pageSize": "2Mi" } } } n1.mediumのspecの出力結果を開く $ oc get vmcf n1.medium -o json | jq '.spec' { "annotations": { "cpu-load-balancing.crio.io": "disable", "cpu-quota.crio.io": "disable", "irq-load-balancing.crio.io": "disable" }, "cpu": { "dedicatedCPUPlacement": true, "guest": 4, "isolateEmulatorThread": true }, "memory": { "guest": "4Gi", "hugepages": { "pageSize": "1Gi" } } } 定義済みのインスタンスタイプに関する詳細は下記ドキュメントを参照ください。 第7章 仮想マシン | Red Hat Product Documentation 4-3 仮想マシンの作成 Webコンソールから「Virtualization>Catalog」を選択します。 カタログ画面を開きプロジェクトを選択する 仮想マシンを実行するためのプロジェクトを新規作成します。「プロジェクトの作成」を選択します。 プロジェクトの作成を選択 プロジェクト名は任意の名前で構いませんが、ここでは「ocp-virt」とします。プロジェクト名の入力後、「作成」を押します。 プロジェクト名を入力し作成を押す 先ほど作成したプロジェクト名が選択されていることを確認し、起動ボリュームを選択します。「① Select volume to boot from」から「rhel9」を選択します Select volume to boot fromからrhel9を選択 次に、インスタンスタイプを選択します。「② Select InstanceType」からU seriesの「small: 1 CPUs, 2 GiB Memory」を選択します。 インスタンスタイプからサイズを選択 起動ボリュームの各OSには必要リソース要求が定義されています。たとえば、RHEL 9の場合はCPU 1 、メモリー 1536Mi が必要リソース要求として定義されています。 $ oc get vmcp rhel.9 -o json | jq .spec.requirements { "cpu": { "guest": 1 }, "memory": { "guest": "1536Mi" } } そのため、必要リソース要求を下回るサイズを選んだ場合はエラーになり、仮想マシンの作成ができません。 必要リソース要求を下回るサイズを選んだ場合は、仮想マシン作成時にエラーになる 最後に仮想マシンの詳細設定を行います。「③ VirtualMachine details」のNameは自動で作成されます。変更する場合は任意の名前を指定します。さらに、ここではSSH公開鍵の設定を行うため「Not contifured」のリンクを選択します。 仮想マシンの詳細設定画面 Public SSH Keyの設定画面内の「None」「Use existing」「Add new」から「Add new」を選択します。キーの入力欄にSSH公開鍵をペーストします。 「Secret name」に任意の名前を指定します。ここでは「my-sshkey」とします。 「Automatically apply this key to any new VirtualMachine you create in this project.」のチェックを入れると、今後同じプロジェクトで作成される仮想マシンに自動で同じSSHキーを使用します。 最後に「Save」を押します。 このSSHキーの設定はcloud-iniの機能を使用しており、cloud-initに対応したOSの場合は自動的にSSHキーが登録されます。 SSHキーの詳細設定画面 「Public SSH key」の欄に先ほど作成した「my-sshkey」が登録されています。また、RHEL 9の場合は「Dynamic SSH key injection」に対応していますのでチェックを有効にします（無効のままでも問題ありません）。 作成したSSHキーが登録されたことを確認 すべての設定の完了後、「Create VirtualMachine」を押して仮想マシンの作成を行います。その際に「Start this VirtualMachine after creation」にチェックが入っていると、仮想マシンの作成完了と同時に起動が行われます。 Create VirtualMachineを押して仮想マシンを作成する 作成したSSHキーは、仮想マシンの作成後「Virtualization>Overview>Settings>User>Manage SSH keys」で管理が行えます。 SSHキーの管理画面 仮想マシンの作成後、詳細画面に遷移します。Statusが「Provisioning」となり、起動ボリュームからクローンが行われます。 仮想マシンの作成中の画面 起動ボリュームのクローンが完了すると、Statusが「Running」に変わり、OSが起動します。 仮想マシンの起動、OSの起動中の画面 4-4 仮想マシンへコンソールでアクセス 仮想マシンの起動後、Consoleタブから仮想マシンのコンソール画面へアクセスできます。 Consoleタブから仮想マシンのコンソールにアクセスできる また、Overview画面から「Open web console」のリンクを選択すると別ウィンドウでコンソール画面を開くことができます。 Open web consoleのリンクを選択 コンソール画面には「Guest login credentials」のリンクがあり、選択するとその仮想マシンにログイン可能なユーザー名とパスワードが表示されます。 ユーザー名やパスワードをコピーし、「Paste」リンクを選択すると自動でコンソールの内部にコピーした内容がペーストされます。 コンソール画面上の操作 この初期ユーザーは sudo コマンドの実行が可能です。たとえば sudo -i コマンドを実行し、その後 passwd コマンドでルートユーザーのパスワードを変更できます。 4-5 仮想マシンへvirtctlでリモートアクセス 仮想マシンの詳細画面の右側にある「Actions」ドロップダウンメニューから「Copy SSH command」を選択します。 リモートアクセスのためのSSHコマンドをコピー 下記のようなコマンドがコピーされます。 virtctl -n ocp-virt ssh cloud-user@rhel-9-salmon-parrotfish-27 --identity-file=<path_to_sshkey> virtctl コマンドで仮想マシン内へSSHのリモートアクセスができます。 踏み台サーバーに秘密鍵をコピーしていない場合は連載 第1回 を参考に、SSHエージェント転送を利用してください。 （作業用端末で実行） % ssh -A bastion SSHエージェント転送を利用して踏み台サーバーにログイン後、OpenShiftにログインします。 ログイン方法は「kubeconfigを使ったログイン」または「oc login」のどちらでも構いません。 ログイン方法の詳細は連載 第2回 を参考にしてください。 $ export KUBECONFIG=${HOME}/work/auth/kubeconfig $ oc whoami system:admin OpenShiftにログイン後、先ほどコピーした virtctl コマンドから、秘密鍵の指定の部分を除いて実行します。 初回のフィンガープリントの確認の後、仮想マシンにリモートアクセスができます。 $ virtctl -n ocp-virt ssh cloud-user@rhel-9-salmon-parrotfish-27 The authenticity of host 'vmi/rhel-9-salmon-parrotfish-27.ocp-virt (<no hostip for proxy command>)' can't be established. ED25519 key fingerprint is SHA256:pIksu6TcU4ShB3tptNic3M25cU5Sx0gGJzmnHOj8DCc. This key is not known by any other names Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added 'vmi/rhel-9-salmon-parrotfish-27.ocp-virt' (ED25519) to the list of known hosts. Register this system with Red Hat Insights: insights-client --register Create an account or view all your systems at https://red.ht/insights-dashboard Last login: Thu Jul 25 15:23:10 2024 [cloud-user@rhel-9-salmon-parrotfish-27 ~]$ 5. 仮想マシンの作成（テンプレートから作成） テンプレートカタログから仮想マシンの元となるテンプレートを選択し、Windows Server 2022をインストールする方法を紹介します。 テンプレートからWindows Server 2022仮想マシンを作成 5-1 テンプレートから作成する テンプレートから作成する方法では、インストールの準備を除き2つのステップを経て仮想マシンを作成します。 テンプレートから作成する作業フロー テンプレートの選択 テンプレートの詳細設定 OpenShift Virtualizationのテンプレートとは、 起動ボリュームと事前に定義済みのリソースを組み合わせた雛形 のことです。 よく使う組み合わせを事前に定義しておくことで、繰り返し行う仮想マシンの作成作業を軽減できます。 また、OpenShift Virtualizationのインストール時に自動追加される起動ボリュームを使ったテンプレートが複数用意されているので、これを積極的に使うのも良いでしょう。 5-2 インストールの準備 MicrosoftのEvaluation CenterからWindows Server 2022の評価版をダウンロードします。 本記事ではダウンロード手順の詳細は割愛します。 Windows Server 2022 | Microsoft Evaluation Center Windows Server 2022 評価版のISOファイルをファイルを踏み台サーバーへコピーします。 作業用端末のカレントディレクトリにISOファイル（ SERVER_EVAL_x64FRE_ja-jp.iso ）が存在することとします。 % scp SERVER_EVAL_x64FRE_ja-jp.iso bastion:work ISOファイルを virtctl コマンドでOpenShiftへアップロード（PVCの作成）します。 virtctl コマンドによるファイルのアップロード方法は下記のドキュメントを参照してください。 7.2. カスタムイメージからの仮想マシンの作成 | Red Hat Product Documentation ocp-virt プロジェクトを選択し、 virtctl image-upload コマンドでISOファイルをアップロードします。 実行コマンド $ oc project ocp-virt $ virtctl image-upload dv win2022-ja-iso \ --size=10G \ --image-path=SERVER_EVAL_x64FRE_ja-jp.iso win2022-ja-iso ：PVCの名前。ここでは win2022-ja-iso とします。 --size=10G ：新規作成の場合はサイズの指定が必要です。ISOファイルが十分に収まるサイズを指定ください。 --image-path=SERVER_EVAL_x64FRE_ja-jp.iso ：アップロード元のファイルを指定します。 実行コマンドと結果 $ oc project ocp-virt Now using project "ocp-virt" on server "https://api.ocp.home.lab:6443". $ virtctl image-upload dv win2022-ja-iso \ --size=10G \ --image-path=SERVER_EVAL_x64FRE_ja-jp.iso PVC ocp-virt/win2022-ja-iso not found DataVolume ocp-virt/win2022-ja-iso created Waiting for PVC win2022-ja-iso upload pod to be ready... Pod now ready Uploading data to https://cdi-uploadproxy-openshift-cnv.apps.ocp.home.lab 4.85 GiB / 4.85 GiB [=============================================================================================================================================================================================================================================] 100.00% 54s Uploading data completed successfully, waiting for processing to complete, you can hit ctrl-c without interrupting the progress Processing completed successfully Uploading SERVER_EVAL_x64FRE_ja-jp.iso completed successfully Webコンソールのメニューから「ストレージ>PersistentVolumeClaims」を選択します。 ISOファイルアップロード時に作成したPVCと対応するPVが作成されています。 ファイルアップロードによる作成されたPVCとPVの確認 5-3 仮想マシンの作成 Webコンソールのメニューから「Virtualization>Overview」を開き、「Template catalog」タブを選択します。 テンプレートカタログの画面 テンプレートカタログはインスタンスタイプとは異なり、OSとリソース（CPU、メモリー）がセットになった状態のテンプレートとして選択ができるようになっています。 「Source available」の表示があるものは起動ボリュームが存在し、そのまま仮想マシンの作成が可能になっているものです。 「Source available」の表示がないものは起動ボリュームが存在せず、起動ボリュームを別途用意したりISOファイルからインストールを行う必要があります。 Windows Serverはどれも「Source available」の表示がなく、ISOファイルからインストールが必要です。 まず「Microsoft Windows Server 2022 VM」を選択します。 テンプレートカタログからWindows Server 2022VMを選択 仮想マシンの詳細設定画面が表示されたら、下記の通りに設定を行います。 仮想マシンインストールの詳細設定 Boot from CD ：有効化 CD source ：PVC（clone PVC） PVC project ：ocp-virt PVC name ：win2022-ja-iso Disk source ：Blank Disk size、VirtualMachine nameは任意で変更してください。 「Start this VirtualMachine after creation」のチェックはそのままで、仮想マシンの作成と同時に起動を行います。 すべてのパラメーターが設定できたら、「Quick create VirtualMachine」を選択します。 仮想マシンの作成後、詳細画面に遷移します。Statusが「Provisioning」となり、ISOのPVのクローンが行われます。 仮想マシンの作成中の画面 Statusが「Running」に変わり、ISOから起動が開始します。「Press any key to boot from CD or DVD・・・・ 」 の表示が出たらタイミングよくエンターを押します。 仮想マシンの起動、ISOから起動中の画面 あとは通常通りWindows Serverのインストールを続行します（本記事では詳細は割愛）。インストールの途中でドライバの追加なども不要です。 Windows Server 2022のインストール中の画面 OSのインストール完了後、「Send Key」のプルダウンメニューから「Ctrl + Alt +Delete」を選択してログインします。 Send KeyのプルダウンメニューからCtrl + Alt +Deleteを選択 OSのインストール中に適用されなかった不明なデバイスドライバは、Windows Updateの機能によりバックグラウンドで自動適用されます。環境によっては適用完了までに少し時間がかかりますので、しばらく待ってから確認ください。 インストール直後は不明なデバイスが存在する バックグラウンドでデバイスドライバが自動適用される 6. 仮想マシンの起動と停止 6-1 仮想マシンの停止 起動中の仮想マシンを停止するには、仮想マシンの詳細画面内の「Actions」メニューから Stop を選択します（またはStopのアイコンを押します）。 ActionsメニューからStopを選択、またはStopのアイコンを選択する この際、仮想マシン内のOSはシャットダウン操作が行われます（ハードオフではない）。 仮想マシンのOS内ではシャットダウンが実行される OSのシャットダウン完了後、自動的に仮想マシンが停止します。Statusは「Stopped」に変わります。 仮想マシンの停止が完了 6-2 仮想マシンの起動 仮想マシンを起動するには、仮想マシンの詳細画面内の「Actions」メニューから Start を選択します（またはStartのアイコンを押します）。 ActionsメニューからStopを選択、またはStopのアイコンを選択する 仮想マシンの起動後、Statusは「Running」に変わります。 仮想マシンが起動 6-3 OS内でシャットダウンした時の動作の変更 OpenShift Virtualizationのデフォルト設定では、仮想マシンのOS内でシャットダウンしても自動的に仮想マシンが再起動してしまいます。 この件に関しては ドキュメント に記載があります。 spec.running: true で設定された仮想マシンはすぐに再起動されます。spec.runStrategy キーを使用すると、特定の条件下で仮想マシンがどのように動作するかを決定するための柔軟性が高まります。 デフォルトの設定を確認するには下記のコマンドを実行します。 $ oc get vm win2k22-moccasin-elk-82 -n ocp-virt -o json | jq '.spec | {running: .running, runStrategy: .runStrategy}' { "running": true, "runStrategy": null } この spec.running キーの設定を無効化し、 spec.runStrategy キーの設定を行うことでデフォルトの動作を変更できます。なお、ドキュメントに下記の注意点が記載されています。 spec.runStrategy キーと spec.running キーは相互に排他的です。いずれか 1 つだけを 使用できます。両方のキーを含む仮想マシン設定は無効です。 これは spec.running キーと spec.runStrategy キーが相互に影響し合うため、別々に設定を変更できないことを意味します。そのため spec.running キーと spec.runStrategy キーを同時に変更する方法で設定を行います。 （1）OS内からのシャットダウンで仮想マシンの停止を有効化する OS内でのシャットダウンで仮想マシンを停止するには下記のコマンドで設定を変更します。 なお、 この設定は仮想マシンごとの設定になります 。 oc patch vm に続けて設定変更したい仮想マシン名を指定します。仮想マシンの作成時に設定を適用したい場合は また、この設定を反映するためには 仮想マシンの再起動が必要です 。仮想マシンを停止した後にコマンドを実行するか、仮想マシンを実行中に行った場合は仮想マシンの再起動を行なってください。 実行コマンド $ oc patch vm win2k22-moccasin-elk-82 -n ocp-virt --type json -p '[{"op": "remove", "path": "/spec/running"},{"op": "add", "path": "/spec/runStrategy", "value": "Manual"}]' 実行コマンドと結果 $ oc patch vm win2k22-moccasin-elk-82 -n ocp-virt --type json -p '[{"op": "remove", "path": "/spec/running"},{"op": "add", "path": "/spec/runStrategy", "value": "Manual"}]' virtualmachine.kubevirt.io/win2k22-moccasin-elk-82 patched 確認コマンド $ oc get vm win2k22-moccasin-elk-82 -n ocp-virt -o json | jq '.spec | {running: .running, runStrategy: .runStrategy}' 確認コマンドと結果 $ oc get vm win2k22-moccasin-elk-82 -n ocp-virt -o json | jq '.spec | {running: .running, runStrategy: .runStrategy}' { "running": null, "runStrategy": "Manual" } 設定変更後はOS内のシャットダウンで仮想マシンの停止ができるようになります。 設定変更後、OS内のシャットダウンから仮想マシンの停止が行える （2）元の設定に戻す方法 元の設定に戻す場合は下記のコマンドを実行します。 実行コマンド $ oc patch vm win2k22-moccasin-elk-82 -n ocp-virt --type json -p '[{"op": "remove", "path": "/spec/runStrategy"},{"op": "add", "path": "/spec/running", "value": true}]' 実行コマンドと結果 $ oc patch vm win2k22-moccasin-elk-82 -n ocp-virt --type json -p '[{"op": "remove", "path": "/spec/runStrategy"},{"op": "add", "path": "/spec/running", "value": true}]' virtualmachine.kubevirt.io/win2k22-moccasin-elk-82 patched 確認コマンド $ oc get vm win2k22-moccasin-elk-82 -n ocp-virt -o json | jq '.spec | {running: .running, runStrategy: .runStrategy}' 確認コマンドと結果 $ oc get vm win2k22-moccasin-elk-82 -n ocp-virt -o json | jq '.spec | {running: .running, runStrategy: .runStrategy}' { "running": true, "runStrategy": null } 7. 仮想マシンのライブマイグレーション 7-1 ライブマイグレーションについて ライブマイグレーションは、メンテナンスなどの目的で仮想マシンを停止せずに稼働中のホストから別のホストに仮想マシンを移行する機能です。 VMware vSphereのvMotionと同等の機能です。 vMotionは実行時に移行先のホストを明示的に指定しますが、OpenShift Virtualizationのライブマイグレーションではホストの指定はありません。 ライブマイグレーションの実行を指定するのみで、リソースの空きのある移行可能なホストに自動で移行が行われます。 この辺りの挙動はベース技術がコンテナオーケストレーションのKubernetesならではです。 なお、本連載における構成ではOpenShift Virtualization v4.16.0でライブマイグレーションできない不具合があるため、本記事「2-3 ライブマイグレーション用ワークアラウンドの実施」を行ってください。 該当バージョン以外や、不具合が発生しない場合はワークアラウンドの実施は不要です。 7-2 ライブマイグレーションの実行 ライブマイグレーションを実行するには、実行中の仮想マシンの詳細画面内の「Actions」メニューから Migrate を選択します。 操作はこれだけです。 ライブマイグレーションの実行 仮想マシンのライブマイグレーション中は、各仮想マシンのStatusが Running から Migrating に変わります。「Node」欄を確認すると、現在は node-01 上で実行していることが確認できます。 ライブマイグレーション実行中はStatusはMigrationgになる しばらく待って、ライブマイグレーションが完了すると Running に戻ります。「Node」欄を確認すると、完了後は node-02 上で実行していることが確認できます。 ライブマイグレーションの完了 ライブマイグレーションの進捗は、仮想マシンの詳細設定のMetricsタブを押し、画面を一番下にスクロールして「Migration>LiveMigration progress」を確認します。 ライブマイグレーションの進捗 まとめ OpenShift Virtualizationのインストールと実行方法について解説しました。 OpenShift Virtualizationのインストールは、OpenShiftクラスターとストレージの環境さえ整っていればWebコンソールのOperator Hubから選んでインストールするだけですのでとても簡単に行えます。 仮想マシンの作成や起動、停止、さらにはライブマイグレーションもGUIの操作で行うことができ、vSphereの操作に慣れた方であればそれほど違和感なく使い始められます。 仮想マシン作成のライフサイクルの中心になるのがPVCやPVといったストレージが重要なのは特徴かもしれません。 その代わりにインスタンスタイプやテンプレートを駆使することで、セルフサービスを前提とした仮想マシン運用に変化できるのは大きなメリットです。 （次回予告） 次回はMigration Toolkit for Virtualizationを使って、vSphere/ESXi上の仮想マシンを移行する方法を解説します。 *1 : サードパーティーコンポーネントを使用しているお客様に対して Red Hat はどのようなサポートを提供していますか? - Red Hat Customer Portal *2 : 実際には自動的にHyperConverged Operatorがインストールされます *3 : CNVはOpenShift Virtualizationの以前の名前「Container Native Virtualizationに由来 *4 : 同一ホスト上でなくても、同じハードウェア構成のノード間であれば同様に問題なくライブマイグレーションできる可能性があります

こんにちは、Red Hatでソリューションアーキテクトをしている石川です。 本日Meta社が新たなオープンLLMとして Llama 3.1 を発表し、LLM界隈では大きな盛り上がりを見せています。 これまでもMeta社は独自のLLMとしてLlamaシリーズを発表してきていましたが、性能面ではOpenAIのGPT-4oや、AnthropicのClaude 3.5 SonnetなどのクローズドLLMに一歩及んでいませんでした。しかし、新たなLlama 3.1ではこうしたLLMにも負けない、むしろいくつかのベンチマークでは上回る結果を出し、今非常に大きな注目を集めています。 これだけでもオープンLLMにとって大きな前進と言えますが、更にLlama 3.1で適用された新たなライセンスはLlama 3.1で生成したデータを他のLLMの学習に利用することを許可しています。これまで多くのクローズドLLMでは利用規約の中でこうした利用を禁止していましたが、今回Llama 3.1がこのような方針を示したことで、今後小中規模のLLMで生成された学習データを活用したファインチューニングが行われ、高性能なモデルがより増えてくることが期待できます。 対応する言語として日本語は含まれていませんが、今後派生するモデルで対応が行われていくと考えられます。 本ブログではそんなLlama 3.1をOpenShift AI上で動かしてみたいと思います。 なお本記事はあくまで個人的な検証であるため、内容についてサポートへのお問い合わせはご遠慮下さい。 環境の準備 OpenShift環境 今回はOpenShift環境としてROSA HCPを利用します。主題から外れるため構築方法は割愛とさせて頂きますが、弊社メンバーの ブログ記事 などを参照頂くと簡単に構築できると思います。 Worker NodeとしてAWSの下記のインスタンスタイプを準備し、検証を行いました。 ややオーバースペック気味なので、実際にはもう少し小さいインスタンスタイプでも十分だと思います。 ・m5.4xlarge(16vCPU,64GiB Memory) * 3 ・g5.4xlarge(16vCPU,64GiB Memory, A10G GPU 24GiB VRAM) LLMを実行する上で重要となるのがGPUのVRAMの大きさです。 本ブログではパラメータが8BのLlama 3.1を動かすため、およそ8 * 2 =16GiBほどのVRAM容量が要求されると予想できます。AWSのG5インスタンスに搭載されるA10G GPUであれば十分な容量が確保できます。 Operatorのインストール OpenShiftクラスタが構築できたら、必要なOperatorをOperatorHubからインストールしていきます。 今回必要となるOperatorは以下の通りです。 ・Node Feature Discovery(NFD) Operator ・NVIDIA GPU Operator ・OpenShift Serverless Operator ・OpenShift ServiceMesh Operator ・Authorino Operator ・OpenShift AI Operator 上2つのNFD OperatorとGPU OperatorはOpenShiftクラスタの中でGPUを利用するために必要となるOperatorです。 それぞれのOperatorをインストールした後に、NFDではNodeFeatureDiscovery、GPU OperatorではClusterPolicyというカスタムリソースを作成します。設定値について、今回の検証では両者ともデフォルト値のままで大丈夫です。 NFD OperatorがGPUデバイスを搭載したNodeにラベルを付与し、そのラベルを元にGPU Operatorが対象のNodeへGPUドライバ等のコンポーネントをロードします。 ClusterPolicy CRを作成後、 nvidia-gpu-operator NameSpaceでnvidia-driver Podが起動していればOKです。 oc get pod -n nvidia-gpu-operator | grep nvidia-driver --- nvidia-driver-daemonset-416.94.202407030122-0-skdd2 2/2 Running 0 3h34m 続いて残りのOperatorをインストールします。 OpenShift ServerlessとServiceMesh、Authorino OperatorはOpenShift AIでLLMを実行する際に用いるKServeというOSSの依存関係としてインストールが必要となります。 OpenShift AIのKServeでは2つのデプロイパターンが利用できます。今回のようにLLMなど比較的大きいモデルを実行する際は、1つのランタイムに1つのモデルをロードするSingle model servingと呼ばれる方法でデプロイを行います。 docs.redhat.com もう一つのデプロイパターンとしてMulti model serving(Model Mesh)という複数のモデルを1つのランタイムで実行する方法も存在しますが、こちらはより小さなモデルを対象としており、今回は使用しません。 OperatorHubからServerless、ServieMesh、Authorinoを検索しインストールしましょう。NFD/GPU Operatorと異なり自分でカスタムリソースを作成する必要はありません。 最後にOpenShift AIのインストールを行います。これまでと同様OperatorHubで検索し、インストールを実行します。Operatorのインストールが完了するとDataScienceClusterというカスタムリソースの作成が求められるため、デフォルト設定のまま作成します。 ステータスがReadyとなるとOpenShiftコンソールの右上のメニューからOpenShift AIコンソールへのリンクが追加されます。 リンクを開き、認証を行うとOpenShift AIコンソールにアクセスできます。 OpenShift AIにおける各種設定 ここからはOpenShift AIでLLMのサービングを行うにあたり必要な各種設定を行なっていきます。 OpenShift AIのKServeを利用しLLMを実行する場合、以下の図のようにLLMを一端オブジェクトストレージに格納し、そこからモデルの実行ランタイム(vLLM、等)にロード、実行します。 そのため、まず初めにモデルの保存先となるオブジェクトストレージの設定やランタイムの登録を行います。 Data Science Project と Data Connectionの設定 OpenShift AIでは、ユーザーが取り組むAIプロジェクトごとに、Data Science Projectという単位でリソースを管理します。OpenShift AIのコンソールから画面左のData Science Projectsを選択し、新たなProjectを作成しましょう。実態としてはこれらはラベルの付いたNameSpaceであり、その中でPod等の各種リソースが作成、実行されます。 上図のData Science Projectを作成すると、 llm-serving というNameSpaceがOpenShiftに新たに作成されます。 Projectが作成できたら、続いてData connectionを作成します。 Data connectionでは利用するオブジェクトストレージへのアクセス情報を設定します。 今回はAWS S3にて my-trial-llm というバケットをあらかじめ作成しており、そこへのアクセス情報を設定しました。 S3のエンドポイントについては以下のドキュメントを確認し、自分が利用するリージョンのエンドポイントを設定しましょう。 docs.aws.amazon.com Data ConnectionではS3互換のオブジェクトストレージであれば利用することができるため、例えばMinioやOpenShift Data Foundationなども同様に設定することができます。 ここで設定した内容はSecretとして管理されます。 便利ツール(ODH Tools)の追加 KServeによってLLMをホストするには、HuggingFaceで公開されているLLMのモデルファイルをオブジェクトストレージバケットに保存する必要があります。 必要なファイルを一端全て自身の端末にダウンロードしてからそれをまたアップロードする、という方法でも対応できますが、便利ツールとしてOpen Data Hub Tools & Extensions Companionというものがコミュニティで公開されています。 github.com こちらを使うことでHuggingFace上のモデルを直接バケットに保存することができます。 利用にはOpenShift AIのSettingsからODH ToolsのコンテナイメージをカスタムNotebook imageとして登録します。この設定はcluster-adminロールの権限が必要なので注意して下さい。（kubeadmin不可のため注意） Image locationとして quay.io/rh-aiservices-bu/odh-tec:latest を登録しましょう。 登録が完了するとデフォルトで準備されているNotebook imageと同様に利用することができるようになります。 カスタムServing Runtimeの追加 Llama 3.1をホストするにあたりモデルのランタイムとしてvLLMを利用します。OpenShift AIではvLLMのコンテナイメージがデフォルトでサポートされますが、vLLMプロジェクトの こちらのissue を確認すると、Llama 3.1をホストするには最新のvLLMバージョン(v0.5.3.post1)とtransformersライブラリ(4.43.1)が必要とのことです。現行のOpenShift AI（v2.11）ではこちらのバージョンに対応していないため、代替手段としてカスタムのランタイムイメージを登録します。OpenShift AIの次期バージョン（v2.12）以降ではサポートされるvLLMもバージョンアップされこの作業は不要となるでしょう。 SettingsメニューからServing runtimesを選択し、Pre-installedされたvLLMを複製（duplicate）します。 ここで2点変更を加えます。 apiVersion: serving.kserve.io/v1alpha1 kind: ServingRuntime metadata: annotations: opendatahub.io/recommended-accelerators: '["nvidia.com/gpu"]' openshift.io/display-name: Latest vLLM ServingRuntime for KServe labels: opendatahub.io/dashboard: "true" name: vllm-runtime-copy spec: annotations: prometheus.io/path: /metrics prometheus.io/port: "8080" containers: - args: - --port=8080 - --model=/mnt/models - --served-model-name={{.Name}} - --distributed-executor-backend=mp - --max-model-len=8192 #実行オプション追加 command: - python - -m - vllm.entrypoints.openai.api_server env: - name: HF_HOME value: /tmp/hf_home image: quay.io/jishikaw/vllm-openai-ubi9:0.5.3.post1 #イメージ変更 name: kserve-container ports: - containerPort: 8080 protocol: TCP multiModel: false supportedModelFormats: - autoSelect: true name: vLLM 一つは利用するコンテナイメージの変更です。 最新のライブラリを含むコンテナイメージをビルドし、Quayで公開しているのでこちらを利用します。 quay.io/jishikaw/vllm-openai-ubi9:0.5.3.post1 二つ目としてvLLMコンテナ実行時のオプションとして --max-model-len=8192 を追加します。 Llama 3.1はコンテクスト長として128kまでサポートしていますが、そのままでは利用するVRAMサイズに納まらないため、オプションにより制限をかけています。 カスタムServing Runtimeの登録を行うとPre-installedされたランタイムと同様にモデルサービング時に利用することができます。 モデルのダウンロード それでは先ほど登録したODH toolsを使ってHuggingFaceからLlama 3.1のモデルファイルをダウンロードしましょう。 今回利用するMeta-Llama-3.1-8B-InstructはHuggingFaceの以下のURLで公開されています。 https://huggingface.co/meta-llama/Meta-Llama-3.1-8B-Instruct こちらはGated modelとなっており、利用には以下が必要です。 ・HuggingFaceアカウントの作成 ・HF Tokenの払い出し ・Llama 3.1利用申請 既にHuggingFaceアカウントを持っておりアクセスTokenがある場合は、上２つはスキップして下さい。 3点目のLlama 3.1への利用申請は、先ほどのURLから行います。申請してから利用承認を得るまで若干時間がかかります。（10-20分程度） 承認が得られると以下のようなメールが送られてきます。 それではOpenShift AIのコンソールに戻り、先ほど作成したData Science Projectから新たなWorkbenchを起動します。 Workbenchの起動画面にて以下の設定を行います。 ・Notebook image / image selection: 先ほど登録したODH toolsを選択 ・Environment variables: Keyとして"HF_TOKEN"、Valueに取得したTokenを設定 ・Data connections: Use existing data connectionを選択し、作成済みのData Connectionを選択 他の項目はデフォルトのままでOKです。 Workbenchが起動すると以下のようなオブジェクトストレージのブラウジング画面が表示されます。 ここでImport HF modelを選択し、以下のようにLlama 3.1のリポジトリを選択します。アクセス承認済みであり、Tokenの設定が正しく行われていれば、ファイルのダウンロードが開始されます。 ダウンロードが完了するとLlama 3.1のsafetensorsファイル等がオブジェクトストレージに保存されたのを確認できるはずです。 モデルのサービング それではLlama 3.1を実行しましょう。再びData Sceince Projectに戻り、Modelsタブを開きます。Single model servingを選択し、デプロイのための設定を行います。 ・Model name: llama31 ・Serving runtime: 先ほど設定したカスタムランタイム ・Model framework (name - version): vLLM ・Model server replicas: 1 ・Compute resources per replica / Model server size: Custom ・CPU requests / limits: 1 - 8 ・Memory requests / limits: 4 - 28 ・Accelerator: NVIDIA GPU ・Number of accelerators: 1 ・Model location: Existing data connection ・Name: 作成済みのData connection ・Path: ダウンロードしたsafetensorsファイルが存在するオブジェクトストレージのパス 設定後Deployを押すとモデルのサービングが始まります。 オブジェクトストレージからのモデルファイルの取得や、容量の大きいランタイムコンテナイメージのpullを行うため、最初は特に時間がかかります。 デプロイが成功すると以下の画像のように推論のAPIエンドポイントが表示されます。 これで無事Llama 3.1のデプロイが完了しました。 推論の実行 最後に推論を実行してみましょう。 Llama 3.1は対応する言語として日本語は含まれていませんが、ここではあえて日本語で質問したいと思います。 以下のコマンドを実行します。 export LLM_ROUTE={表示された推論APIエンドポイント} curl ${LLM_ROUTE}/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "llama31", "messages": [ {"role": "system", "content": "あなたは丁寧なアシスタントです.ユーザーからの質問に回答して下さい"}, {"role": "user", "content": "Red Hatとはどんな会社ですか？"} ] }' | jq . 結果は以下の通りです。 { "id": "chat-ff392dae4bc24e6e803cb29325896953", "object": "chat.completion", "created": 1721818057, "model": "llama31", "choices": [ { "index": 0, "message": { "role": "assistant", "content": "Red Hatは、オープンソースソフトウェアの開発、販売、サポートを手掛ける米国の企業です。主にLinuxオペレーティングシステムとその周辺ソフトウェアの開発と販売を中心に事業を行っています。", "tool_calls": [] }, "logprobs": null, "finish_reason": "stop", "stop_reason": null } ], "usage": { "prompt_tokens": 47, "total_tokens": 106, "completion_tokens": 59 } } 無事回答を得られました。何度かやり取りをするとやはり日本語対応は不自然な点がありますが、そちらについては今後出てくるであろう日本語チューニングされたモデルの登場を待ちたいと思います。 OpenShift AIで実行するvLLMについては以下の通り関連するメトリクスをPrometheusにより取得し、表示することもできます。 まとめ 今回は今ホットなLLMであるLlama 3.1をOpenShift AIで実行しました。オンプレミスやエッジ環境など、実行環境を選ばず利用可能なオープンLLMは今後より発展が見込まれると考えられます。Red HatはAIでもOpen Hybrid Cloudを実現し、AI活用の更なる可能性を広げていきます。

Red Hatでソリューションアーキテクトをしている田中司恩( @tnk4on )です。 この連載はvSphere環境上にOpenShift Container Platform（以下、OpenShift）およびOpenShift Virtualizationの環境を構築する方法を解説するシリーズです。 第3回は共有ストレージの作成について解説します。今後の連載予定は下記の通りです。 第1回：OpenShiftのインストール 第2回：OpenShiftインストール後の作業 第3回：共有ストレージの作成（NFS CSIドライバーの構築） （←本記事） 第4回：OpenShift Virtualizationのインストールと実行 第5回：vSphere仮想マシンの移行 【番外編】：共有ストレージの作成（NFSプロビジョナーの構築） （2024/7/17追記：2つ目のディスクを/mnt/nfsにマウントする手順を追加しました） （2024/7/23追記：NFS CSIドライバーを使用する内容に変更しました。以前の内容は番外編として別記事にしました。） （2024/9/29追記：NFS CSIドライバーのアップデート方法を追加しました） （2024/10/2追記：踏み台サーバーに2つ目のディスクを追加するコマンドを修正しました） -目次- 共有ストレージの作成概要 前提条件 1. OpenShift Virtualizationに必要なストレージ 1-1 ストレージのアクセスモードについて 1-2 永続ストレージ 1-3 永続ボリュームの動的プロビジョニング 1-4 Container Storage Interface (CSI) 2. 踏み台サーバー上のNFSサーバー設定 2-1 NFSサーバーの設定 3. NFS CSIドライバーの設定 3-1 NFS CSIドライバーについて 3-2 NFS CSIドライバーの動作 3-3 NFS CSIドライバーのインストール （1）Helmのインストール （2）NFS CSIドライバーのインストール （追記）NFS CSIドライバーのアップデート （3）NFS CSIドライバーのインストールの確認 3-4 ストレージクラスとボリュームスナップショットクラスの作成 （1）ストレージクラスの作成 （2）ボリュームスナップショットクラスの作成 3-5 デフォルトストレージクラスの設定 3-6 動的プロビジョニングの動作テスト （1）サンプルファイルのダウンロード （2）PVCとPodの作成 （3）確認 （4）サンプルのPodとPVの削除 （5）NFS CSIドライバーの削除 4. イメージレジストリの設定 4-1 イメージレジストリーの構成 4-2 イメージレジストリーの設定 4-3 レジストリーの公開 4-4 レジストリーの操作 （1）ログイン （2）イメージのプッシュ （3）プッシュしたイメージの確認 （4）OpenShift上のイメージをプルする まとめ 共有ストレージの作成概要 本記事ではOpenShift Virtualizationに必要な共有ストレージの作成を目的として、下記の内容を紹介します。 OpenShift Virtualizationに必要なストレージ 踏み台サーバー上のNFSサーバー設定 NFS CSIドライバーの設定 イメージレジストリの設定 OpenShiftの標準サブスクリプションである OpenShift Container Platform （OCP）やその下位エディションの OpenShift Kubernetes Engine （OKE） *1 は複数ノードから書き込み可能な共有ストレージの機能は標準搭載していません。 通常はOpenShiftクラスター外部のストレージ製品を利用する形態でこれを構成します。 対して、OCPの上位エディションの OpenShift Platform Plus （OPP） *2 にはOpenShift Data Foundation（ODF） *3 が含まれます。このODFを使用することでOpenShiftをHCIで構成し共有ストレージを提供できるようになります（vSphereで言うところのvSANと同様のことができるとイメージください）。 ODFはOpenShiftに統合されたストレージであるため、実稼働環境における推奨されたストレージの選択です。 しかしながら、ODFはその構成上非常に多くのリソースを使用します。潤沢なリソースがない環境での利用は難しいため、今回の検証環境でODFは利用しません。 今回は1台のRHEL（または他のLinux等でも可）で構成できる NFSを利用したシンプルな共有ストレージ を作成することとします。 なお、このストレージはあくまで検証用途であり、実稼働環境での利用はできませんのでご注意ください。 *4 前提条件 連載 第1回 および 第2回 の作業を完了していることとします 全体の構成や各パラメーターなどは連載 第1回 を参照してください 作業用端末のプロンプトは % とします 踏み台サーバーのプロンプトは $ とします 踏み台サーバーの作業は明示的に記載がある場合を除いて、作業ディレクトリ ${HOME}/work で作業することとします 第2回の作業完了後の構成 1. OpenShift Virtualizationに必要なストレージ 1-1 ストレージのアクセスモードについて OpenShift Virtualizationに必要なストレージの要件についてはOpenShiftのインストールドキュメントに記載があります。 その一節にライブマイグレーションについての要件の記載があります。 ライブマイグレーションには共有ストレージが必要です。OpenShift Virtualizationのストレージは、ReadWriteMany(RWX)アクセスモードをサポートし、使用する必要があります。 第12章 ベアメタルへのインストール | Red Hat Product Documentation ReadWriteMany(RWX) モードとは、複数のノードからの読み書き（ReadWrite）に対応したアクセスモードのことです。 対して ReadWriteOnce (RWO) とは、1つのノードから読み書きに対応したアクセスモードです。 RWOとRWXのアクセスモードの違い アクセスモードは他にもReadOnlyMany（ROX）やReadWriteOncePod（RWOP）がありますが本記事では詳細な解説は省略します。 OpenShiftが対応しているアクセスモードの詳細については下記ドキュメントの「表3.1 アクセスモード」を参照ください。 3.3. 永続ボリューム | Red Hat Product Documentation OpenShiftではブロック、ファイル、オブジェクトの3種類のストレージタイプに対応しており、RWXモードで利用可能なのは ファイル か オブジェクト のタイプです。 OpenShiftで推奨されるストレージのタイプ 第7章 スケーラビリティとパフォーマンスの最適化 | Red Hat Product Documentation 今回は構築が簡単なNFSを使った ファイルストレージ を共有ストレージとして使用します。 1-2 永続ストレージ OpenShiftがサポートするストレージのタイプは大別して2つのカテゴリーに大別されます。 一時ストレージ ：Podとコンテナーが短期間のローカルストレージの操作に使用し、再起動や障害でデータが失われることを想定したストレージ 永続ストレージ ：Podとコンテナーがデータの永続性を保証し、再起動や障害後もデータが保持されるストレージ OpenShift Virtualizationでは仮想マシンのディスクが永続化されている必要があるため、使用するストレージのタイプは 永続ストレージ になります。 本記事では一時ストレージについては触れませんので、詳細は下記ドキュメントを参照ください。 1.2. ストレージタイプ | Red Hat Product Documentation 1-3 永続ボリュームの動的プロビジョニング OpenShiftでPodやコンテナで永続ストレージを利用する場合は 永続ボリューム（PV） を利用します。 PVはOpenShiftクラスタ内で永続的なストレージリソースを提供するためのオブジェクトです。 また、PVはクラスタ全体で利用可能なストレージを抽象化し、コンテナのライフサイクルとは独立してデータを保存できます。 PVの 動的プロビジョニング とは、必要なときに必要な量のストレージを自動的に割り当てる機能です。これにより、管理者は事前に大量のストレージを確保する必要がなくなり、効率的なリソース利用が可能となります。 [PVの動的プロビジョニングメリット] 自動化: 手動でのストレージ割り当ての手間が省ける。 効率化: 必要な分だけストレージを割り当てるため、無駄が少ない。 スケーラビリティ: 必要に応じてストレージを増減できるため、システムのスケールアップ・ダウンが容易。 手動プロビジョニングと動的プロビジョニングのPV作成のフローを図で表したものが下記になります。 手動プロビジョニングによるPV作成のフロー 動的プロビジョニングによるPV作成のフロー 1-4 Container Storage Interface (CSI) Container Storage Interface (CSI) は、異なるコンテナーオーケストレーションシステム間でコンテナーストレージを管理するためのAPI仕様です *5 。 ストレージベンダーはCSIに準拠したプラグイン（ドライバー）を開発することで、他のコンテナーオーケストレーションシステムでもプラグインに対応したストレージが機能するようにします。 CSIはストレージを共通化した仕様で抽象化することにより、接続に必要な手順を一律化し、コンテナーオーケストレーションシステムが多様なストレージに対応が可能となります。 OpenShiftはKubernetesを拡張したものであり、純粋なアップストリーム版のKubernetes（いわゆるVanilla Kubernetes）と同様にCSIドライバーを利用できます。 このCSIドライバーを利用することでPVの動的プロビジョニングを行うことができます。 2. 踏み台サーバー上のNFSサーバー設定 今回の検証環境の構成では永続ストレージの元となるNFSサーバーは踏み台サーバー上で実行します。 そのために、まずはLinuxでNFSサーバーを実行する基本機能として、NFSのエクスポートを行います。 踏み台サーバー上のNFSサーバー設定後の構成 2-1 NFSサーバーの設定 NFSをエクスポートする基点となるディレクトリを作成します。 このディレクトリはOSの起動ディスクとは別のディスク上に作成することとします。 第1回で踏み台サーバーの仮想マシンに2つ目のディスクを追加していない場合は追加してください。 govc コマンドで実行する場合は下記のコマンドを使用します。 踏み台サーバーに2つ目のディスクを追加します。 $ node=bastion $ govc vm.disk.create \ -vm ${node} \ -name "${node}/${node}_1.vmdk" \ -size 500G \ -thick=false \ -ds=NVMe ディスクデバイスを確認します。 下記のように2つ目のディスクが追加されました。 $ govc device.ls -vm ${node} | grep disk disk-1000-0 VirtualDisk 104,857,600 KB disk-1000-1 VirtualDisk 524,288,000 KB 2つ目のディスクをOS上で使用できるようにし、 /mnt/nfs にマウントします。 下記のコマンドを実行します。（2つ目のディスクが/dev/sdbにあることとします） $ sudo parted /dev/sdb --script mklabel gpt $ sudo parted /dev/sdb --script mkpart primary ext4 0% 100% $ sudo mkfs.ext4 /dev/sdb1 $ sudo mkdir -p /mnt/nfs $ echo '/dev/sdb1 /mnt/nfs ext4 defaults 0 0' | sudo tee -a /etc/fstab $ sudo systemctl daemon-reload $ sudo mount -a 正常にマウントされているか確認します。 $ df -h /mnt/nfs ファイルシス サイズ 使用 残り 使用% マウント位置 /dev/sdb1 492G 28K 467G 1% /mnt/nfs 次に /etc/exports ファイルにNFSエクスポート用の設定を追記します。 $ sudo vi /etc/exports /mnt/nfs 192.168.1.0/24(rw,async,no_subtree_check,no_root_squash) exportfs -r コマンドを使用して設定の検証を行います。設定に問題がなければ何も出力はされません。 $ sudo exportfs -r $ たとえば、エクスポートするディレクトリが見つからない場合は下記のエラーが出ます。 $ sudo exportfs -r exportfs: Failed to stat /mnt/nfs: No such file or directory NFSエクスポートの設定に問題がなければファイアーウォールの設定を行います。 NFSで使用するポートをファイアーウォール設定に追記します。 $ sudo firewall-cmd --add-service nfs --permanent $ sudo firewall-cmd --reload NFSサービスを自動起動サービスに登録し、同時に起動します。 $ sudo systemctl enable --now nfs-server これでNFSサーバーの設定が完了しました。 3. NFS CSIドライバーの設定 踏み台サーバー上に構築したNFSサーバーを利用してPVの動的プロビジョニングを行うため、OpenShiftに NFS CSI driver for Kubernetes （以下、NFS CSIドライバー）をインストールします。 NFS CSIドライバー導入後の構成 3-1 NFS CSIドライバーについて OpenShiftでPVの動的プロビジョニングを行うためにはストレージとそれに対応したCSIドライバーが必要です。 今回構築したストレージはRHELで立てた汎用的なNFSサーバーなので専用のCSIドライバーがありません。 そこで今回は、汎用的なNFSサーバーをバックエンドに使用しPVの動的プロビジョニングを行うことができるNFS CSIドライバーを利用します。 このNFS CSIドライバーはKubernetes CSIでホストされているリポジトリの1つです。OSSで開発されておりApache-2.0 licenseに従い無償で利用できます。 kubernetes-csi/csi-driver-nfs: This driver allows Kubernetes to access NFS server on Linux node. NFS CSIドライバーはfsGroupPolicy、Volume Snapshot、Volume Cloningに対応しています。 実稼働環境ではストレージベンダーなどの製品をご利用ください。 3-2 NFS CSIドライバーの動作 NFS CSIドライバーの動作の流れは下記の通りです NFS CSIドライバーの動作 3-3 NFS CSIドライバーのインストール NFS CSIドライバーをインストールする流れは下記のとおりです。 Helmのインストール NFS CSIドライバーのインストール 現時点ではコマンドの詳細を深く理解する必要はありません。まずはおまじない的にコマンドをコピペして実行してください。 （1）Helmのインストール NFS CSIドライバーのインストールでHelm *6 を使用します。 Helmはパッケージマネージャーの1つで、アプリケーションをパッケージ（Helmではチャートという）としてKuberenetes上に簡単にデプロイできる仕組みです。 今回の構成では踏み台サーバーにHelmをインストールします。Helmのインストールドキュメントは下記です（本記事ではRed Hatが提供しているHelmのバイナリを利用します）。 6.2. Helm のインストール | Red Hat Product Documentation x86_64の環境にHelmをインストールするコマンド例は下記のとおりです。 $ sudo curl -L https://mirror.openshift.com/pub/openshift-v4/clients/helm/latest/helm-linux-amd64 -o /usr/local/bin/helm $ sudo chmod +x /usr/local/bin/helm Helmのインストール後、 helm コマンドを実行して動作確認を行います。 $ helm version WARNING: Kubernetes configuration file is group-readable. This is insecure. Location: /home/user/work/auth/kubeconfig WARNING: Kubernetes configuration file is world-readable. This is insecure. Location: /home/user/work/auth/kubeconfig version.BuildInfo{Version:"v3.14.4+37.el9", GitCommit:"7163c12e65c8c0a40334c0a4b514b991ea37aa21", GitTreeState:"clean", GoVersion:"go1.21.9 (Red Hat 1.21.9-2.el9_4)"} KUBECONFIG 環境変数がセットされていて、かつ kubeconfig ファイルのパーミッションが所有者以外から読み込み可能になっているとコマンドの出力に警告が出ます。 気になる方は chmod コマンドでパーミッションを変更してください。 $ chmod 600 auth/kubeconfig （2）NFS CSIドライバーのインストール NFS CSIドライバーはOpenShiftにインストールします。初めにチャートリポジトリを追加し、その後にインストールを行います。 helm repo add コマンドでNFS CSIドライバーのチャートリポジトリを追加します。 実行コマンド $ helm repo add csi-driver-nfs https://raw.githubusercontent.com/kubernetes-csi/csi-driver-nfs/master/charts 実行コマンドと結果 $ helm repo add csi-driver-nfs https://raw.githubusercontent.com/kubernetes-csi/csi-driver-nfs/master/charts "csi-driver-nfs" has been added to your repositories ~/.config/helm ディレクトリが作成され、参照するリポジトリの情報が保存されます helm install コマンドでNFS CSIドライバーをインストールします。 --version オプションを使ってバージョンを指定します。（記事執筆時点での最新版はv4.8.0） 実行コマンド $ helm install csi-driver-nfs csi-driver-nfs/csi-driver-nfs --namespace kube-system --version v4.8.0 --namespace kube-system ：インストール先のネームスペースに kube-system を指定 --version v4.8.0 ：インストールするバージョンを指定。指定するバージョンはNFS CSIドライバーのリリースページ *7 を参照のこと helm install コマンドを実行すると下記のような応答が出力されます 実行コマンドと結果 $ helm install csi-driver-nfs csi-driver-nfs/csi-driver-nfs --namespace kube-system --version v4.8.0 NAME: csi-driver-nfs LAST DEPLOYED: Fri Jul 19 10:40:55 2024 NAMESPACE: kube-system STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: The CSI NFS Driver is getting deployed to your cluster. To check CSI NFS Driver pods status, please run: kubectl --namespace=kube-system get pods --selector="app.kubernetes.io/instance=csi-driver-nfs" --watch NFS CSIドライバーが正常にインストールできたかどうかは次の手順で確認します。 （追記）NFS CSIドライバーのアップデート NFS CSIドライバーのリリースページ *8 で新しいバージョンがリリースされた場合は、 helm repo update を行うことで新しいバージョンのインストールを行うことができます。 下記はチャートリポジトリのアップデートを行い、 v4.9.0 をインストールする手順です。 実行コマンド $ helm repo update $ helm install csi-driver-nfs csi-driver-nfs/csi-driver-nfs --namespace kube-system --version v4.9.0 実行コマンドと結果 $ helm repo update Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "csi-driver-nfs" chart repository Update Complete. ⎈Happy Helming!⎈ $ helm install csi-driver-nfs csi-driver-nfs/csi-driver-nfs --namespace kube-system --version v4.9.0 NAME: csi-driver-nfs LAST DEPLOYED: Thu Sep 26 23:18:01 2024 NAMESPACE: kube-system STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: The CSI NFS Driver is getting deployed to your cluster. To check CSI NFS Driver pods status, please run: kubectl --namespace=kube-system get pods --selector="app.kubernetes.io/instance=csi-driver-nfs" --watch （3）NFS CSIドライバーのインストールの確認 OpenShiftのWebコンソールから「管理者向け表示」のプルダウンを選択し「開発者」を選択します。 これにより開発者向け表示（Developerパースペクティブ）に切り替えることができます。 開発者向け表示（Developerパースペクティブ）に切り替える 左のメニューから「トポロジー」を選択します。プロジェクトのプルダウンメニューから「すべてのプロジェクト」を選択します。 「デフォルトプロジェクトの表示」スイッチをオンにします。 トポロジーメニューのプロジェクト表示 「デフォルトプロジェクトの表示」をオンにすることでOpenShift上の管理用のプロジェクトの選択が可能になります。 入力欄に kube-system と入力して表示のフィルタリングを行い、プロジェクト欄に表示された kube-system を選択します。 フィルタリングを行いkube-systemを選択 画面内に「D」のアイコンがついた csi-nfs-controller というオブジェクト（Deployment）と、「DS」のアイコンがついた csi-nfs-node というオブジェクト（DaemonSet）が表示されます。 csi-nfs-controller がNFS CSIドライバーの管理コンテナ、 csi-nfs-node が各ノード上で稼働する実行コンテナになります。 csi-nfs-controller と csi-nfs-node の2つを合わせたものが csi-driver-nfs という名前のHelmチャートとしてデプロイされています。 csi-nfs-controllerのDeploymentの詳細表示 csi-nfs-nodeのDaemonSetの詳細表示 左のメニューからHelmを選択すると、現在選択しているプロジェクトに登録済みのHelmリリース *9 の情報が表示されます。 デプロイされたHelmリリースの表示 「HR」アイコンが付いたHelmリリース名（ここでは csi-driver-nfs ）のリンクを選択します。 Helmリリースの詳細 リソースタブを選択すると、Helmでインストールされたリソースの名前やタイプが一覧で表示されます。 3-4 ストレージクラスとボリュームスナップショットクラスの作成 インストールしたNFS CSIドライバーを使ってPVの動的プロビジョニングを行うために ストレージクラス （StorageClass）を作成します。 ストレージクラスとはPVの動的プロビジョニングを定義するために使用されます。ユーザーは必要なストレージクラスを指定して永続ボリューム要求（PVC）を作成します。 ストレージクラスの詳細については下記のドキュメントを参照してください。 5.6. デフォルトストレージクラスの管理 | Red Hat Product Documentation また、合わせてOpenShift Virtualizationで仮想マシンのスナップショットを取得するための ボリュームスナップショットクラス （VolumeSnapshotClass）も作成します。 ボリュームスナップショットについては下記のドキュメントを参照してください。 5.4. CSI ボリュームスナップショット | Red Hat Product Documentation （1）ストレージクラスの作成 下記のコマンドでストレージクラスのカスタムリソースを storageclass-nfs.yaml という名前で作成します。 $ cat > storageclass-nfs.yaml <<EOF apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: nfs-csi provisioner: nfs.csi.k8s.io parameters: server: 192.168.1.206 share: /mnt/nfs reclaimPolicy: Delete volumeBindingMode: Immediate EOF server: 192.168.1.206 ：NFSサーバーのIPアドレス（またはホスト名）を指定します share: /mnt/nfs ：NFSサーバー上でエクスポートしているパス名を指定します reclaimPolicy: Delete ：PVを削除した時にNFSサーバー上のデータを保持するかどうかを指定します。 Delete はPVCの削除と同時にPVも削除され、NFSサーバー上の実データも削除されます。 PVCの削除後もPVとして残す場合は Retain 、PVは削除しつつもNFSサーバー上の実データを残す場合は Archive を指定します。 下記のコマンドでストレージクラスを作成します。 $ oc create -f storageclass-nfs.yaml （2）ボリュームスナップショットクラスの作成 下記のコマンドでボリュームスナップショットクラスのカスタムリソースを snapshotclass-nfs.yaml という名前で作成します。 $ cat > snapshotclass-nfs.yaml <<EOF apiVersion: snapshot.storage.k8s.io/v1 kind: VolumeSnapshotClass metadata: name: csi-nfs-snapclass driver: nfs.csi.k8s.io deletionPolicy: Delete EOF 下記のコマンドでボリュームスナップショットクラスを作成します。 $ oc create -f snapshotclass-nfs.yaml 3-5 デフォルトストレージクラスの設定 デフォルトストレージクラスとは2つ以上のストレージクラスが存在する場合に 標準的に使用されるストレージクラス のことです。 今回の構成ではストレージクラスは1つしか作成されていませんが、明示的に設定をしておくことで他のストレージクラスよりも優先的に利用するようにしておきます。 デフォルトストレージクラスを設定するには下記のコマンドを実行します。 今回はストレージクラス名： nfs-csi に対して通常のコンテナアプリケーションと仮想マシンの両方にデフォルト設定を行います。 $ oc patch storageclass nfs-csi -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}' $ oc patch storageclass nfs-csi -p '{"metadata": {"annotations":{"storageclass.kubevirt.io/is-default-virt-class":"true"}}}' 同様にデフォルトボリュームスナップショットクラスを設定するコマンドを実行します。 ボリュームスナップショットクラス名は csi-nfs-snapclass を指定します。 $ oc patch volumesnapshotclass csi-nfs-snapclass --type merge -p '{"metadata": {"annotations":{"snapshot.storage.kubernetes.io/is-default-class":"true"}}}' $ oc patch volumesnapshotclass csi-nfs-snapclass --type merge -p '{"metadata": {"annotations":{"snapshot.storage.kubevirt.io/is-default-virt-class":"true"}}}' 設定が反映されているか下記のコマンドを実行して確認を行います。 oc get コマンドで引数に storageclass と nfs-csi を指定し、さらに -o yaml オプションを追加して、ストレージクラスの設定内容をYAML形式で出力を行います。 $ oc get storageclass nfs-csi -o yaml 出力結果内の annotations: に先ほど設定した値が反映されているか確認できます。下記の出力結果を展開して内容を確認ください。 出力結果を開く $ oc get storageclass nfs-csi -o yaml apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: annotations: storageclass.kubernetes.io/is-default-class: "true" storageclass.kubevirt.io/is-default-virt-class: "true" creationTimestamp: "2024-07-23T05:35:49Z" name: nfs-csi resourceVersion: "596631" uid: 86a54044-89fa-4f49-8c35-6c5bc6cff696 parameters: server: 192.168.1.206 share: /mnt/nfs provisioner: nfs.csi.k8s.io reclaimPolicy: Delete volumeBindingMode: Immediate 同様にボリュームスナップショットクラスの設定内容を確認します。 oc get コマンドの引数は volumesnapshotclass を csi-nfs-snapclass 指定します。 $ oc get volumesnapshotclass csi-nfs-snapclass -o yaml 出力結果を開く $ oc get volumesnapshotclass csi-nfs-snapclass -o yaml apiVersion: snapshot.storage.k8s.io/v1 deletionPolicy: Delete driver: nfs.csi.k8s.io kind: VolumeSnapshotClass metadata: annotations: snapshot.storage.kubernetes.io/is-default-class: "true" snapshot.storage.kubevirt.io/is-default-virt-class: "true" creationTimestamp: "2024-07-23T05:37:13Z" generation: 1 name: csi-nfs-snapclass resourceVersion: "597248" uid: 774868f9-23f8-46c7-b02e-bf832d6c31ec 3-6 動的プロビジョニングの動作テスト NFS CSIドライバーの設定ができたので実際にサンプルのDeploymentを実行して動的プロビジョニングの動作テストを行います。 （1）サンプルファイルのダウンロード NFSプロビジョナーのリポジトリで公開されているサンプルのファイルをダウンロードします。 PVCとPodの実行が定義されたDeploymentのYAMLファイルをダウンロードします。 $ wget https://raw.githubusercontent.com/kubernetes-csi/csi-driver-nfs/master/deploy/example/deployment.yaml $ ls -d deployment.yaml deployment.yaml （2）PVCとPodの作成 oc create コマンドでYAMLファイルからリソースを作成します。 -f オプションで読み込むYAMLファイルを指定します。 最初にテスト実行用のプロジェクトを作成し、そのプロジェクト内にリソースを作成します。 下記のコマンドでプロジェクトを新規作成します。名前は test とします。 実行コマンド $ oc new-project test 実行コマンドと結果 $ oc new-project test Now using project "test" on server "https://api.ocp.home.lab:6443". You can add applications to this project with the 'new-app' command. For example, try: oc new-app rails-postgresql-example to build a new example application in Ruby. Or use kubectl to deploy a simple Kubernetes application: kubectl create deployment hello-node --image=registry.k8s.io/e2e-test-images/agnhost:2.43 -- /agnhost serve-hostname 続けてDeploymentリソースを作成します。 実行コマンド $ oc create -f deployment.yaml 実行コマンドと結果 $ oc create -f deployment.yaml persistentvolumeclaim/pvc-deployment-nfs created deployment.apps/deployment-nfs created PVCとPodの実行を定義したDeploymentが作成されました。 （3）確認 Webコンソールの管理者向け表示のメニューから「ストレージ＞PersistentVolumeClaims」を選択すると、作成されたPVCとバインドされたPVが一覧で表示されます。 「プロジェクト」選択プルダウンから test を選ぶと、先ほど作成した test プロジェクト上に作成されたPVCが表示されます。 サンプルのDeploymentから作成されたPVCとPV このサンプルでは下記の情報が確認できます。 PVC：pvc-deployment-nfs PV：pvc-43c68d68-95f2-4b2a-99cf-4eef0debba39 PVの容量：10 GiB 使用したストレージクラス：nfs-csi 踏み台サーバー上のNFSエクスポートディレクトリを確認すると、PV用のディレクトリが自動で作成されていることが分かります。 $ tree /mnt/nfs/ /mnt/nfs/ └── pvc-43c68d68-95f2-4b2a-99cf-4eef0debba39 └── outfile 1 directory, 1 file NFSサーバー上に作成されるディレクトリの命名規則は PV名 と同じものになります。 Webコンソールの管理者向け表示のメニューから「Workloads＞Pods」を選択すると、実行中のPodが一覧で表示されます。 サンプルのPod（ deployment-nfs-7579c47f6-r6zbq ）のステータスが Running になっており、このPodが正常に実行していることが分かります。 testプロジェクトで実行中のPod一覧 Pod名の deployment-nfs-7579c47f6-r6zbq のリンクを選択するとPodの詳細画面が表示されます。 このコンテナが mcr.microsoft.com/oss/nginx/nginx コンテナイメージから作成されていて状態が Running になっており、コンテナの実行が継続していることが確認できます。 また、このコンテナではPVは nfs という名前でボリュームとして扱われており、コンテナ内の /mnt/nfs ディレクトリに読み書き可能でマウントされています。 サンプルPodの詳細情報 このサンプルではコンテナの実行コマンドとしてホスト名と日時を1秒ごとにループで書き込み続けるようにプログラムされています *10 。 そのため、サンプルのPod起動後にNFSサーバー上のディレクトリを確認すると、コンテナの中で作成された outfile ファイルに継続的にデータが書き込み続けていることが分かります。 $ tail -f /mnt/nfs/pvc-43c68d68-95f2-4b2a-99cf-4eef0debba39/outfile deployment-nfs-7579c47f6-r6zbq Tue Jul 23 08:04:02 UTC 2024 deployment-nfs-7579c47f6-r6zbq Tue Jul 23 08:04:03 UTC 2024 deployment-nfs-7579c47f6-r6zbq Tue Jul 23 08:04:04 UTC 2024 deployment-nfs-7579c47f6-r6zbq Tue Jul 23 08:04:05 UTC 2024 deployment-nfs-7579c47f6-r6zbq Tue Jul 23 08:04:06 UTC 2024 deployment-nfs-7579c47f6-r6zbq Tue Jul 23 08:04:07 UTC 2024 deployment-nfs-7579c47f6-r6zbq Tue Jul 23 08:04:08 UTC 2024 deployment-nfs-7579c47f6-r6zbq Tue Jul 23 08:04:09 UTC 2024 deployment-nfs-7579c47f6-r6zbq Tue Jul 23 08:04:10 UTC 2024 deployment-nfs-7579c47f6-r6zbq Tue Jul 23 08:04:11 UTC 2024 deployment-nfs-7579c47f6-r6zbq Tue Jul 23 08:04:12 UTC 2024 deployment-nfs-7579c47f6-r6zbq Tue Jul 23 08:04:13 UTC 2024 ... （4）サンプルのPodとPVの削除 作成したサンプルのPodとPVを削除する場合は下記のコマンドを実行します。 oc delete project コマンドでプロジェクトごとOpenShift上のリソースを削除します。 実行コマンド $ oc delete project test 実行コマンドと結果 $ oc delete project test project.project.openshift.io "test" deleted 実行中のコンテナが強制的に停止し、すべてのリソースが削除するまで数十秒程度かかります。 PV削除後のNFSサーバー上の実体ディレクトリは下記のようになります。 $ tree /mnt/nfs/ /mnt/nfs/ 0 directories, 0 files PV削除と同時に実体のディレクトリも削除されます （5）NFS CSIドライバーの削除 NFS CSIドライバーの削除を行う場合は helm delete コマンドを実行します。 helm delete コマンドに引数として csi-driver-nfs とネームスペースに kube-system を指定して実行します。 $ helm uninstall csi-driver-nfs -n kube-system 4. イメージレジストリの設定 NFS CSIドライバーを設定したことで永続ボリュームを利用できるようになりました。 次は、OpenShiftのインストール後の作業の1つであるイメージレジストリの設定を行います。 この作業はストレージの設定が事前に必要なため、第2回のインストール後の作業では対象外としました 4-1 イメージレジストリーの構成 イメージレジストリはOpenShiftの内部で実行されるコンテナレジストリーです。 イメージレジストリーはパブリックなコンテナレジストリーと同様に、OpenShift上でビルドしたコンテナイメージを登録したり、登録したコンテナイメージからコンテナを実行できます。 また、OpenShiftの外部との接続口（ルート）を作成することでイメージレジストリーを外部へ公開できます。 イメージレジストリーの構成図 イメージレジストリーの設定方法はOpenShiftのインストールドキュメントに記載があります。下記のドキュメントを参照してください。 第24章 任意のプラットフォームへのインストール | Red Hat Product Documentation 実稼働環境におけるレジストリーの推奨ストレージは オブジェクトストレージ です（次点はブロックストレージ）。 本記事で紹介するファイルストレージを使った構成はあくまで検証用途での利用を前提としています。 ファイルストレージは、実稼働ワークロードを使用した OpenShift イメージレジストリークラスターのデプロイメントには推奨されません。 https://docs.redhat.com/ja/documentation/openshift_container_platform/4.16/html/scalability_and_performance/scalability-and-performance-optimization#specific-application-storage-recommendations 4-2 イメージレジストリーの設定 まず、現在のイメージレジストリーの設定を確認します。 下記のコマンドで configs.imageregistry.operator.openshift.io のリソースから storage と managementState の値を取得します。 実行コマンド $ oc get configs.imageregistry.operator.openshift.io -o json | jq '.items[] | {storage: .spec.storage, managementState: .spec.managementState}' 実行コマンドと結果 $ oc get configs.imageregistry.operator.openshift.io -o json | jq '.items[] | {storage: .spec.storage, managementState: .spec.managementState}' { "storage": {}, "managementState": "Removed" } storage は空の値、 managementState は Removed がセットされています。 次に、下記のコマンドを実行してレジストリーPodが 存在しないこと を確認します。 oc get pod コマンドで -l オプションを使用し、ラベルが docker-registry=default であるポッドをフィルタリングします。 実行コマンド $ oc get pod -n openshift-image-registry -l docker-registry=default 実行コマンドと結果 $ oc get pod -n openshift-image-registry -l docker-registry=default No resources found in openshift-image-registry namespace. イメージレジストリーがまだ設定されていないことが確認できました。下記のコマンドを実行し、イメージレジストリーを有効化します。 実行コマンド $ oc patch config.imageregistry.operator.openshift.io/cluster --type merge -p '{"spec":{"storage":{"pvc":{"claim":""}}}}' $ oc patch config.imageregistry.operator.openshift.io/cluster --type merge -p '{"spec":{"managementState":"Managed"}}' 実行コマンドと結果 $ oc patch config.imageregistry.operator.openshift.io/cluster --type merge -p '{"spec":{"storage":{"pvc":{"claim":""}}}}' config.imageregistry.operator.openshift.io/cluster patched $ oc patch config.imageregistry.operator.openshift.io/cluster --type merge -p '{"spec":{"managementState":"Managed"}}' config.imageregistry.operator.openshift.io/cluster patched コマンドの実行後、先ほどの設定を再度確認します。 claim に image-registry-storage の値が自動で追加されています。 実行コマンド $ oc get configs.imageregistry.operator.openshift.io -o json | jq '.items[] | {storage: .spec.storage, managementState: .spec.managementState}' 実行コマンドと結果 $ oc get configs.imageregistry.operator.openshift.io -o json | jq '.items[] | {storage: .spec.storage, managementState: .spec.managementState}' { "storage": { "managementState": "Managed", "pvc": { "claim": "image-registry-storage" } }, "managementState": "Managed" } しばらくしてからレジストリーPodを確認すると、下記のように先ほどは無かったレジストリーPodが起動していることが分かります。 $ oc get pod -n openshift-image-registry -l docker-registry=default NAME READY STATUS RESTARTS AGE image-registry-5cd6bf8ddf-mgkpm 1/1 Running 0 53s デフォルトではレジストリーPodのレプリカ数は1で実行されます。 PVのアクセスモードがRWXをサポートしている場合はレジストリーPodのレプリカ数を2にして高可用性構成が可能です。 下記のコマンドを実行して自動で作成されたPVCとPVの設定を確認します。 イメージレジストリーのPVはデフォルトで100GiBの容量を使用します。 $ oc get pvc -n openshift-image-registry NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE image-registry-storage Bound pvc-b3c88568-404c-40c1-a4c8-d252b804a9fc 100Gi RWX nfs-csi <unset> 2m4s $ oc get pv -n openshift-image-registry NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE pvc-b3c88568-404c-40c1-a4c8-d252b804a9fc 100Gi RWX Delete Bound openshift-image-registry/image-registry-storage nfs-csi <unset> 2m11s 4-3 レジストリーの公開 OpenShift上で起動したイメージレジストリーを外部から利用できるように公開設定を行います。 イメージレジストリーの公開方法のドキュメントは下記です。 第5章 レジストリーの公開 | Red Hat Product Documentation 下記のコマンドを実行してイメージレジストリーを公開します。 実行コマンド $ oc patch configs.imageregistry.operator.openshift.io/cluster --type=merge -p '{"spec":{"defaultRoute":true}}' 実行コマンドと結果 $ oc patch configs.imageregistry.operator.openshift.io/cluster --type=merge -p '{"spec":{"defaultRoute":true}}' config.imageregistry.operator.openshift.io/cluster patched イメージレジストリーの公開後、下記のコマンドで接続するためのURL（ HOST/PORT )を確認できます。 $ oc get route default-route -n openshift-image-registry NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD default-route default-route-openshift-image-registry.apps.ocp.home.lab image-registry <all> reencrypt None 4-4 レジストリーの操作 （1）ログイン 外部のコンテナツール（今回はPodmanを使用します）から公開したイメージレジストリーを利用するためにはコンテナレジストリーへのログインが必要です。 下記のコマンドを実行してコンテナレジストリーへのログインを行います。 イメージレジストリーのURLを取得し HOST 環境変数へセットします。 $ HOST=$(oc get route default-route -n openshift-image-registry --template='{{ .spec.host }}') $ echo ${HOST} default-route-openshift-image-registry.apps.ocp.home.lab Ingress Operatorの証明書を取得してシステムの信頼された証明書ストアに追加することで、イメージレジストリーへのHTTPSでのアクセスを行えるようにします。 oc get secret で証明書を取得し、踏み台サーバー上の証明書ストアに保存します。 $ oc get secret -n openshift-ingress router-certs-default -o go-template='{{index .data "tls.crt"}}' | base64 -d | sudo tee /etc/pki/ca-trust/source/anchors/${HOST}.crt > /dev/null 信頼されたルート証明書の一覧を更新します。 $ sudo update-ca-trust enable podman login コマンドを実行しイメージレジストリーへログインを行います。 ログインに使用するユーザーは ocpadmin を使用します。 ocpadmin でログインしていない場合は事前に oc login を実行します（連載第2回を参照）。 $ unset KUBECONFIG $ oc login -u ocpadmin https://api.ocp.home.lab:6443 $ podman login -u ocpadmin -p $(oc whoami -t) ${HOST} Login Succeeded! が表示されたらログイン成功です。 （2）イメージのプッシュ Podmanでサンプルのコンテナイメージを作成し、イメージレジストリーへプッシュします。 下記のコマンドを実行し、ベースイメージにUBI9を使用したContainerfileを作成します。 $ cat > Containerfile <<EOF FROM ubi9 RUN echo "hello" | tee hello.txt EOF podman build コマンドでコンテナイメージをビルドします。 $ podman build -t ${HOST}/openshift/push-test . 出力結果を開く $ podman build -t ${HOST}/openshift/push-test . STEP 1/2: FROM ubi9 Resolved "ubi9" as an alias (/etc/containers/registries.conf.d/001-rhel-shortnames.conf) Trying to pull registry.access.redhat.com/ubi9:latest... Getting image source signatures Checking if image destination supports signatures Copying blob f50ab65647ec done | Copying config e9beb314b7 done | Writing manifest to image destination Storing signatures STEP 2/2: RUN echo "hello" | tee hello.txt hello COMMIT default-route-openshift-image-registry.apps.ocp.home.lab/openshift/push-test --> 4d7c9eb63a75 Successfully tagged default-route-openshift-image-registry.apps.ocp.home.lab/openshift/push-test:latest 4d7c9eb63a75563e6c4deee82d472ddf5fd0770ca4850b0e2e379ee03fe280fc podman push コマンドでコンテナイメージをプッシュします。 $ podman push ${HOST}/openshift/push-test 出力結果を開く $ podman push ${HOST}/openshift/push-test Getting image source signatures Copying blob 09a48287d5f7 done | Copying blob f36b8ecab85c done | Copying config 4d7c9eb63a done | Writing manifest to image destination （3）プッシュしたイメージの確認 Skopeoを使ってプッシュしたコンテナイメージがイメージレジストリーに登録されているか確認します。 下記のコマンドを実行します。 すでに podamn login を実行しているため skopeo login の実行は不要です（SkopeoはPodmanのログイン情報を利用できます）。 $ skopeo inspect docker://${HOST}/openshift/push-test 下記を展開して出力結果を確認ください。 出力結果を開く $ skopeo inspect docker://${HOST}/openshift/push-test { "Name": "default-route-openshift-image-registry.apps.ocp.home.lab/openshift/push-test", "Digest": "sha256:4c537beccd99c1853f7e242dcfab054cbaf0bf5535233bcb2ac24335f2f8492f", "RepoTags": [ "latest" ], "Created": "2024-07-09T21:16:33.272504929Z", "DockerVersion": "", "Labels": { "architecture": "x86_64", "build-date": "2024-06-28T07:36:05", "com.redhat.component": "ubi9-container", "com.redhat.license_terms": "https://www.redhat.com/en/about/red-hat-end-user-license-agreements#UBI", "description": "The Universal Base Image is designed and engineered to be the base layer for all of your containerized applications, middleware and utilities. This base image is freely redistributable, but Red Hat only supports Red Hat technologies through subscriptions for Red Hat products. This image is maintained by Red Hat and updated regularly.", "distribution-scope": "public", "io.buildah.version": "1.33.7", "io.k8s.description": "The Universal Base Image is designed and engineered to be the base layer for all of your containerized applications, middleware and utilities. This base image is freely redistributable, but Red Hat only supports Red Hat technologies through subscriptions for Red Hat products. This image is maintained by Red Hat and updated regularly.", "io.k8s.display-name": "Red Hat Universal Base Image 9", "io.openshift.expose-services": "", "io.openshift.tags": "base rhel9", "maintainer": "Red Hat, Inc.", "name": "ubi9", "release": "1123.1719560047", "summary": "Provides the latest release of Red Hat Universal Base Image 9.", "url": "https://access.redhat.com/containers/#/registry.access.redhat.com/ubi9/images/9.4-1123.1719560047", "vcs-ref": "92a4a475241865d0d11bd861fb2b29fbd9b17df0", "vcs-type": "git", "vendor": "Red Hat, Inc.", "version": "9.4" }, "Architecture": "amd64", "Os": "linux", "Layers": [ "sha256:f50ab65647ec96ba313779f24c41e04bc6fde3e3ee79ee377ea8fd1901b896d5", "sha256:68513cceebd5b717b7e307a2c2ff646147e5a84b16657755c25da1be2732bf15" ], "LayersData": [ { "MIMEType": "application/vnd.oci.image.layer.v1.tar+gzip", "Digest": "sha256:f50ab65647ec96ba313779f24c41e04bc6fde3e3ee79ee377ea8fd1901b896d5", "Size": 79313334, "Annotations": null }, { "MIMEType": "application/vnd.oci.image.layer.v1.tar+gzip", "Digest": "sha256:68513cceebd5b717b7e307a2c2ff646147e5a84b16657755c25da1be2732bf15", "Size": 270, "Annotations": null } ], "Env": [ "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", "container=oci" ] } Webコンソール上で確認する場合は、メニューの「Builds＞ImageStreams」を選択します。 イメージレジストリーに登録されているイメージの一覧が表示されます。 名前で検索できますのでプッシュしたイメージ名： push-test を入力します。 OpenShiftの外部からプッシュしたイメージの表示 push-test のリンクを選択するとイメージの詳細画面が表示されます。 パブリックイメージリポジトリー に表示されているURLが、OpenShiftの外部からこのイメージをプルする時のURLになります。 イメージレジストリーの登録したイメージの詳細表示 （4）OpenShift上のイメージをプルする OpenShift上のイメージをローカルにプルするテストを行います。 ローカルにあるコンテナイメージを削除します。 $ podman images $ podman rmi push-test:latest 出力結果を開く $ podman images REPOSITORY TAG IMAGE ID CREATED SIZE default-route-openshift-image-registry.apps.ocp.home.lab/openshift/push-test latest 4d7c9eb63a75 19 minutes ago 220 MB registry.access.redhat.com/ubi9 latest e9beb314b7a2 11 days ago 220 MB $ podman rmi push-test:latest Untagged: default-route-openshift-image-registry.apps.ocp.home.lab/openshift/push-test:latest Deleted: 4d7c9eb63a75563e6c4deee82d472ddf5fd0770ca4850b0e2e379ee03fe280fc podman pull コマンドでイメージをプルします。 $ podman pull ${HOST}/openshift/push-test $ podman images 出力結果を開く $ podman pull ${HOST}/openshift/push-test Trying to pull default-route-openshift-image-registry.apps.ocp.home.lab/openshift/push-test:latest... Getting image source signatures Copying blob f50ab65647ec skipped: already exists Copying blob 68513cceebd5 done | Copying config 4d7c9eb63a done | Writing manifest to image destination 4d7c9eb63a75563e6c4deee82d472ddf5fd0770ca4850b0e2e379ee03fe280fc $ podman images REPOSITORY TAG IMAGE ID CREATED SIZE default-route-openshift-image-registry.apps.ocp.home.lab/openshift/push-test latest 4d7c9eb63a75 21 minutes ago 220 MB registry.access.redhat.com/ubi9 latest e9beb314b7a2 11 days ago 220 MB イメージレジストリー上のイメージをプルすることができました。 まとめ OpenShift Virtualizationで使用するための共有ストレージの作成を行いました。 汎用的なNFSサーバーをバックエンドに使用し、NFS CSIドライバーを使用することでPVの動的なプロビジョニングが行えます。 このストレージはOpenShift Virtualization以外でも使用できるため、イメージレジストリーのイメージ保存用のストレージの設定を行いました。 また、イメージレジストリーを公開設定を行うことにより、OpenShiftの外部からイメージをプッシュ、プルできるようになります。 第1回からここまでの作業でようやくOpenShift Virtualizationのインストールを行う準備が整いました。 次はいよいよOpenShift Virtualizationの設定になります。 （次回予告） 次回はOpenShift Virtualizationのインストールと仮想マシンの実行方法について解説します。 *1 : Red Hat OpenShift Kubernetes Engine | Red Hat *2 : Red Hat OpenShift Platform Plus とは？をわかりやすく解説 *3 : Red Hat OpenShift Data Foundation | Red Hat *4 : 7.1.2.1. 特定アプリケーションのストレージの推奨事項を参照 第7章 スケーラビリティとパフォーマンスの最適化 | Red Hat Product Documentation *5 : container-storage-interface/spec: Container Storage Interface (CSI) Specification. *6 : Helm *7 : Releases · kubernetes-csi/csi-driver-nfs *8 : Releases · kubernetes-csi/csi-driver-nfs *9 : OpenShift上にHelmでデプロイされたアプリケーションやサービスのインスタンスのこと *10 : 詳細を知りたい方はdeployment.yamlファイルの中身を参照ください

Red Hatの小島です。 RHEL7は2024年6月30日にメンテナンスサポートフェーズが終了し、延長ライフフェーズ(Extended life phase. ELP)に入りました。ELPではこれまでに提供されたソフトウェアなどを引き続き利用できますが、テクニカルサポートが限定的なものとなります。 ELPでは、テクニカルサポートがインストール済みの既存システムに限定され、バグ修正、脆弱性修正、ハードウェアへの対応、問題発生時の根本原因の分析などは行われません。 www.redhat.com そのため、バグ修正や脆弱性修正などのサポートを引き続きご希望であれば、新しいメジャーリリースのRHEL(RHEL9など)に適宜更新していただく必要があります。その際の更新猶予期間として延長サポート(Extended Life-cycle Support. ELS)もレッドハットでは提供しています。Azure Marketplaceで提供される従量課金制のRHELをご利用されている場合でも、従量課金制のRHEL7 ELSをご利用いただけます。本記事ではAzure Marketplaceでの従量課金制RHEL7 ELS利用時の注意点と、実際の利用方法の概要をご紹介します。 従量課金制のRHEL7 ELS利用時の注意点 準備するもの Red Hatへのお問い合わせ Azure MarketplaceのカタログからRHEL7 ELSを購入 従量課金制のRHEL7 ELS利用の参考手順 従量課金制のRHEL7 ELS使用量の確認 従量課金制のRHEL7 ELS利用時の注意点 従量課金制のRHEL7 ELSをご利用される場合、次の点に注意してください。ご利用の際に、後述する従量課金専用のRHEL ELSサブスクリプションを持っておく必要があります。 RHEL7 ELSのサポートポリシーは、 Red Hatが定義した内容 に準拠します。 上記サポートポリシーに従ったRHEL7 ELSのサポート対象については、Microsoftではなく Red Hatがサポートを提供 します。 最新マイナーリリースのRHEL7.9に限定されます。 RHEL7の古いマイナーリリース(RHEL7.5など)の場合は、サポートされません。 yum update コマンドなどでRHEL7.9に更新してください。 準備するもの 以下の2つのアカウントが必要になります。 Red Hatアカウント Azureアカウント RHEL7 ELSのインスタンスを実行するAzureサブスクリプションごとに、後述するRHEL7 ELSの購入手続きを実施します。例えば、↓の画像だと Azure private subscription という名前のAzureサブスクリプションがありますが、このサブスクリプションの中で稼働されたAzureリソースの利用料金が請求されますので、「 Azure pviate subscription に紐づいたRHEL7 ELSのインスタンスを1台または複数台実行する場合は、RHEL7 ELSの購入手続きを1回実施する」ことになります。 支払い方法を分けるなどして、複数個のAzureサブスクリプションがある場合は、RHEL7 ELSインスタンスを紐付けるAzureサブスクリプションの個数分だけ、RHEL7 ELSの購入手続きを実施します。 Azureサブスクリプションと、それに紐付いたAzureリソースの関係図については、下記のMicrosoftドキュメントをご参照ください。 learn.microsoft.com Azure MarketplaceでのRHEL7 ELSは、Microsoftのサードパーティ製品としてRed Hatが販売します。 下記がRHEL7 ELSのカタログです。作成元が「Red Hat Inc」となっていることをご確認ください。作成元が「Red Hat Limited」となっているカタログは、EMEA地域専用のカタログなので利用できません。 https://azuremarketplace.microsoft.com/ja-jp/marketplace/apps/redhat.rh-rhel-els-7 azuremarketplace.microsoft.com RHEL7 ELSに関するソフトウェアは、Microsoftではなく、Red Hatが運用しているリポジトリから提供します。このRed Hatのリポジトリにアクセスしていただく権限を、Red Hatがユーザーに割り当てるためにRed Hatアカウントを必要とする仕組みになっています。Red Hatアカウントの作成方法については、下記のRed HatのWebページをご参照ください。 access.redhat.com 「Red Hatアカウントの管理について不明点があるから確認したい」「(後述する)AzureアカウントとRed Hatアカウントの連携状況を確認したい、または連携を解除したい」などのリクエストがある場合は、Red Hatのカスタマーサービスまでお問い合わせください。 www.redhat.com Red Hatへのお問い合わせ 日本のユーザーは上記のAzure Marketplaceのカタログから直接購入することはできません。Azure MarketplaceでのRHEL7 ELSは、全てプライベートオファー経由での提供となります。「 購買専用のお問い合わせ 」のWebページからRHEL7 ELS購入希望をお問い合わせください。その際に、プライベートオファー発行に必要な情報をご案内します。 Azure MarketplaceのカタログからRHEL7 ELSを購入 プライベートオファーの場合は、Azure Marketplaceの「 プライベートオファーの管理 」からRHEL7 ELSカタログを辿ります。 RHEL7 ELSのカタログでは次のような画面が表示されますので「Subscribe」ボタンをクリックします。 その後、次のような画面が表示されますので、下記を選択・入力していきます。この時、日本リージョンのAzureアカウントでは価格が「vCPU Hours: $0.0088 per vcpu hour」と表示(注: この表示価格は税込み価格です。 日本円表示されている場合だと、2024年11月時点では「￥1.35062」となります)されていることを確認してください。選択や入力が完了したら「Review + subscribe」ボタンをクリックします。 RHEL7 ELSのインスタンスを実行するAzure Subscription IDを選択 RHEL7 ELSのインスタンスを実行するAzure Resource group Azure Marketplace上のサードパーティー製品としてRHEL7 ELSを利用するための、Azure SaaSの名前。この名前は任意に付けられます。 この購入手続きを複数回実施して、1つのAzureサブスクリプション内にRHEL7 ELS関連のAzure SaaSを複数個作ることはできますが、一番最初に作成したAzure SaaSにRHEL7 ELSサブスクリプションの利用料金が集約されて、Azure Portal上に表示されることになります。 確認画面が表示されますので、問題なければ「Subscribe」ボタンをクリックします。 その後、次のような画面が表示されますので、「Configure account now」ボタンをクリックします。 すると、Azure PortalのページからRed HatのWebページに遷移して、ログイン画面が表示されます。このログイン画面ではAzureアカウントではなく、前述した手順で作成したRed Hatアカウントでログインしてください。 Red Hatアカウントでのログインが完了すると、AzureアカウントとRed Hatアカウントの連携確認画面が表示されます。ここで表示される「terms and conditions」は Red HatのEnterprise Agreement (EA契約) です。問題なければ、チェックボックスにチェックを入れて「Connect accounts」ボタンをクリックします。 これでRed Hatアカウントに従量課金専用のRHEL ELSサブスクリプションが割り当てられます。下記のURLから、次の画面に表示されるRHEL ELSのPremium(24時間365日サポート)サブスクリプション(Red Hat Enterprise Linux Extended Life Cycle Support (On-Demand, Hourly Production Support). SKU: RH02985HR)が割り当てられていることを確認してください。確認できれば、RHEL7 ELS購入手続きは完了です。このRHEL ELSサブスクリプションを持って、ユーザーはRHEL ELSのソフトウェアを入手したり、Red Hatサポートチームへの問い合わせが可能になります。この画像では数量(Quantity)が2となっていますが、最低1つあればO.K.です。 購入手続きが完了しても、後述する従量課金制RHEL7 ELSの利用を有効化する手順を実施しない限り、RHEL7 ELSの利用料金は発生しません。 RHEL ELSサブスクリプション情報を確認するためのURL: https://console.redhat.com/subscriptions/inventory Azure Marketplaceから購入したRed Hatサブスクリプションは「Contract Number」が「Not Available」となっていますが、Red Hatからのサポートを問題なく受けることができます。 RHEL ELSサブスクリプションがRed Hatアカウントに割り当てられていないと、以降の手順には進めません。 RHEL ELSサブスクリプションが割り当てられていない場合、これまでの手順を正しく実施していたかどうかを見直してみてください。不明点がある場合は、Red Hatのカスタマーサービスまでお問い合わせ下さい。 www.redhat.com 従量課金制のRHEL7 ELS利用の参考手順 ここで記載しているRHEL7 ELSの利用手順は、次のURLの記載内容に従った参考手順です。 この手順を実施する場合、RHEL7のパッケージ更新に伴う再起動を除いて、既存のRHEL7インスタンスの再作成や再起動は必要ありません。 access.redhat.com この参考手順について不明な点がありましたら、上記で発行されたRHEL ELSサブスクリプションが割り当てられたRed Hatアカウントで、Red Hatサポートチームにお問い合わせください。 access.redhat.com 最初にAzure上でRHEL7 ELSの利用状況をレポートするためのhost-meteringサービスをインストールして起動します。このサービスがRed Hatに使用状況を定期的に送信し、この送信された情報をRed HatがMicrosoftに送信することで、Azure Marketplace上でRed Hatが販売するRHEL7 ELSの利用料金を、Microsoftがユーザーに請求するという仕組みになっています。ファイアーウォールやプロキシ経由でhost-meteringサービスによる使用状況送信を行う場合、下記URLへの経路を確保してください。 cert.console.redhat.com:443 subscription.rhn.redhat.com:443 subscription.rhsm.redhat.com:443 cdn.redhat.com:443 *.akamaiedge.net:443 *.akamaitechnologies.com:443 こうしたプロキシ設定の詳細については、下記をご参照ください。 access.redhat.com Azure上の従量課金制RHEL7インスタンスでは、デフォルトでRHEL7のソフトウェアリポジトリが利用できるようになっていますので、そのリポジトリ経由で次のコマンドを実行して、host-meteringパッケージをインストールします。このとき、最新版のsubscription-managerパッケージが必要となりますので、 yum update コマンドでsubscription-managerパッケージも更新します。 $ sudo yum -y update subscription-manager $ sudo yum -y install host-metering 次に以下のWebページからRHEL7 ELSの利用を有効化するための証明書をダウンロードします。 証明書ダウンロード先のURL: https://access.redhat.com/labs/rhpc/ 証明書をダウンロードするために、下記の画像のようにRHEL ELS 7.9 x86_64を選択するようにしてください。このとき、フィルターボックスに Red Hat Enterprise Linux Server - Extended Life Cycle Support とコピペするとスムーズに選択できます。「Action」の下にある矢印アイコンをクリックします。 すると、次の画面が表示されますので、Option1かOption2のいずれかの方法を用いて証明書をダウンロードしてRHEL7インスタンス内に保存します。このときOption1では自動で、Option2では手動で subscription-manager register コマンドによるRed HatへのRHELシステム登録が実施されますが、登録の際はRHEL ELSサブスクリプションが割り当てられたRed Hatアカウントのユーザー/パスワードを使ってください。Option2の手動登録の際は、登録情報を紐づけた Activation Keyを使う こともできます。 ファイアーウォールやプロキシ経由で、subscription-managerコマンドによるRHELシステム登録などを実行する場合、下記のWebページを参考にしてください。ここで必要となるURLへの経路の確保については、上記のhost-meteringサービスで必要となる経路の確保とほぼ同じものとなります。(subscription-managerの場合、 cert.console.redhat.com:443 へのアクセス確保が不要となります) access.redhat.com なお、/etc/rhsm/rhsm.confにプロキシサーバの設定をする場合、 proxy_hostname = myproxy.example.com proxy_scheme = http のように、 proxy_hostname にはホスト名だけを記載しくてください。 古いsubscription-managerでは proxy_hostname = http://myproxy.example.com という記載も可能でしたが、最新のsubscription-managerではこのフォーマットでは設定できませんので注意してください。 RHEL7インスタンスへの証明書ダウンロードが完了したら、次のコマンドを実行してhost-meteringサービスを有効化します。 $ sudo subscription-manager refresh $ sudo systemctl enable --now host-metering.service host-meteringサービスがすでに起動されている場合は、証明書の情報を反映するためにhost-meteringサービスを再起動します。 $ sudo systemctl restart host-metering.service ここまでの手順で、Red HatへRHEL7 ELSの使用状況を送信するhost-meteringサービスの設定が完了しました。 host-meteringサービスによって送信されるデータは、「vCPU数」や「ホスト名」などのホスト情報がまとめられた数KB程のテキストデータです。このデータが10分に1回の間隔で自動送信されます。 access.redhat.com (注): ロケールを ja_JP.utf8 に設定しているシステムではhost-meteringサービスが正常に起動しないという問題がありましたが、この問題は host-metering-1.4.0-5.el7_9 パッケージで修正されましたので、このバージョンまたはこれより新しいバージョンのhost-meteringパッケージをご利用ください。 なお host-metering-1.4.0-5.el7_9 はrhel-7-server-els-rpmsレポジトリにあります。この後でrhel-7-server-els-rpmsの設定を行いますので、設定後に $ sudo yum update host-metering を行うと最新版のhost-meteringにアップデートできます。 access.redhat.com この後に、Azure内でデフォルトで利用可能な内部Red Hat Update Infrastructure (RHUI)リポジトリーに加えて、Red HatのContent delivery network (CDN)から配信するELSのコンテンツを使用できるように設定するために、次のsubscription-managerコマンドを実行します。 subscription-manager register コマンドによるRHELシステム登録は、前述したOption1による証明書保存スクリプトを実施している、または、前述したOption2による手動でのRHELシステム登録を実行している場合は不要です。 $ sudo subscription-manager register $ sudo subscription-manager config --rhsm.manage_repos=1 $ sudo subscription-manager repos --enable rhel-7-server-els-rpms これでRHEL7 ELSの利用準備が完了です。 yum repolist コマンドでAzureのRHUIリポジトリに加えて、Red Hat CDNから配信するRHEL7 ELSリポジトリ(リポジトリーID: rhel-7-server-els-rpms/x86_64)も参照できるようになっていることが確認できます。この状態になると、yumコマンドなどでRHEL7 ELSリポジトリからのパッケージのダウンロードやインストールが出来るようになります。 $ sudo yum repolist 読み込んだプラグイン:langpacks, product-id, search-disabled-repos, subscription-manager, yum_rhui_plugin リポジトリー ID リポジトリー名 状態 rhel-7-server-ansible-2-rhui-rpms/x86_64 Red Hat Ansible Engine 2 RPMs for Red Hat Enterprise Linux 7 Server from RHUI 103 rhel-7-server-dotnet-rhui-rpms/7Server/x86_64 dotNET on RHEL RPMs for Red Hat Enterprise Linux 7 Server from RHUI 1,417 rhel-7-server-els-rpms/x86_64 Red Hat Enterprise Linux 7 Server - Extended Life Cycle Support (RPMs) 34,485 rhel-7-server-rhui-extras-rpms/x86_64 Red Hat Enterprise Linux 7 Server - Extras from RHUI (RPMs) 1,488 rhel-7-server-rhui-optional-rpms/7Server/x86_64 Red Hat Enterprise Linux 7 Server - Optional from RHUI (RPMs) 24,422 rhel-7-server-rhui-rh-common-rpms/7Server/x86_64 Red Hat Enterprise Linux 7 Server - RH Common from RHUI (RPMs) 243 rhel-7-server-rhui-rpms/7Server/x86_64 Red Hat Enterprise Linux 7 Server from RHUI (RPMs) 34,484 rhel-7-server-rhui-supplementary-rpms/7Server/x86_64 Red Hat Enterprise Linux 7 Server - Supplementary from RHUI (RPMs) 517 rhel-7-server-rpms/7Server/x86_64 Red Hat Enterprise Linux 7 Server (RPMs) 34,484 rhel-server-rhui-rhscl-7-rpms/7Server/x86_64 Red Hat Software Collections RPMs for Red Hat Enterprise Linux 7 Server from RHUI 14,708 rhui-microsoft-azure-rhel7 Microsoft Azure RPMs for Red Hat Enterprise Linux 7 (rhel7) 5 repolist: 146,356 従量課金制のRHEL7 ELS使用量の確認 Azure Portalのコスト分析 の画面から、他のAzureリソースと共にRHEL7 ELSの使用量を(およそ翌日以降に)確認できます。Azure PortalでAzure SaaSの情報を参照して利用料金を確認できます。Azureサブスクリプション内の複数のAzureリソースグループにRHEL7 ELSのAzure SaaSを複数個作成した場合でも、利用料金情報は1つに集約されて「SaaS」という名前で表示されます。RHEL7 ELSは実行されたRHEL7インスタンスのvCPU総数に応じて、Azure Subscription IDごとに時間単位(hourly)で課金されます。RHEL7 ELSの利用を有効化しているRHEL7インスタンスを停止または削除すれば、RHEL7 ELSサブスクリプションの課金は止まります。 また、 Red HatのHybrid Cloud Console からRHEL7 ELSの利用時間をインスタンスごとに確認できます。

こんにちは。ソリューションアーキテクトの橋本です。 今日は、レッドハットの製品を評価したい、という方に製品へのアクセス、利用開始をより簡単に始めていただくため、シンプルになったトライアルセンターをご紹介します。 www.redhat.com トライアル(評価版)サブスクリプションとは 評価版サブスクリプションは、Red Hatl製品の評価目的のためにRed Hat製品を使用する時に、無償で入手・利用することができるサブスクリプションです。通常版と比較して、機能制限、ソフトウェア、ドキュメントやナレッジへのアクセスの制限はありませんが、使用期限がだいたい60日間(一部異なるものもあります)と定められており、プロダクション環境での利用は、評価版の利用規約に反することになります。 評価版の利用条件は、トライアルセンターの ページ に記載されています。 トライアル対象製品や、サポートの有無、個別の申請が必要なトライアルについてなど、その他よくあるご質問(FAQ)については、こちらに記載されていますので、いちどご覧ください。 www.redhat.com トライアルセンターを見てみる トライアルセンター にアクセスすると、こんな感じの画面が表示されます。 注目の製品、Red Hat Enterirpse Linux, OpenShift, Ansible Automation Platform、そしてJBoss EAPを始めとしたミドルウェア製品がタブでわかれて表示されます。 ちなみにクラウドでOpenShiftのマネージドサービスを提供するROSAとAROについては、無償オプションとは別に、従量課金形式で気軽でクイックに試せますので、そのご案内もこのトライアルセンターにあります。 セルフサービスでトライアルを申請してみる 試しに、Red Hat Enterprise Linuxのトライアルを申請してみます。 "Red Hat Enterprise Linux" タブをクリックしたら表示される、 "Red Hat Enterprise Linux" の "試用する" ボタンを押してみます。 すると、以下のような画面が表示されます。トライアルの内容を確認し、問題がなければ、 "無料トライアルを利用する" をクリックします。 ログインを求められますので、Red Hat IDでログインします。まだRed Hat IDをお持ちでない場合は、ボックスの下にある "Register for a Red Hat Account" をクリックして作成してください。 ログインが成功したら、すぐプロセスは完了し、トライアル申請完了となります。と同時に、RHELの場合はRHEL 9.4(記事執筆現在)のインストールDVDのisoのダウンロードが開始されます。回線にはご注意ください。 自分が使っているトライアルを確認する My Trialsというページから、自分が現在申請、利用しているトライアルが一覧できるようになっています。 www.redhat.com 当然、Hybrid Cloud Consoleの Subscription Inventory のような、Red Hat IDに登録されているすべてのサブスクリプションの一覧にもTrialのサブスクリプションが表示されます。 ちなみに、RHELをRHSMおよびHybrid Cloud Consoleに登録する場合は、 Registration Assistant を使って登録コマンドを確認すると便利です。 ということで、トライアルセンターから、製品評価をサクっと始めていただけるようになっています。「Red Hat製品を試してみたいけど、どこから始めたらいいかわからないなぁ」という方は、ぜひチェックしてみてください。 なおRed Hatでは製品のトライアルサブスクリプションだけでなく、個人で使用できる無償のDeveloper Subscription for Individualsや、トレーニングを受け放題のラーニングサブスクリプションのトライアルなどを提供しています。そちらについては、当ブログにあるこちらのページをいちどご覧ください。 rheb.hatenablog.com

Red Hatでソリューションアーキテクトをしている田中司恩( @tnk4on )です。 この連載はvSphere環境上にOpenShift Container Platform（以下、OpenShift）およびOpenShift Virtualizationの環境を構築する方法を解説するシリーズです。 本記事は元々、連載「ゼロからはじめるOpenShift Virtualization」の第3回として投稿した内容の NFSプロビジョナーの構築部分のみ をピックアップした内容です。 このNFSプロビジョナーはボリュームのスナップショットに対応しておらず、OpenShift Virtuzalizationとして利用するには機能不足な点がありました。 そのため、本連載第3回の内容は NFS CSI driver for Kubernetes （以下、NFS CSIドライバー）を使った内容に変更しております。 本記事はあくまで参考情報として残しておくことを目的とします。 本連載の一覧は下記の通りです。 第1回：OpenShiftのインストール 第2回：OpenShiftインストール後の作業 第3回：共有ストレージの作成（NFS CSIドライバーの構築） 第4回：OpenShift Virtualizationのインストールと実行 第5回：vSphere仮想マシンの移行 【番外編】：共有ストレージの作成（NFSプロビジョナーの構築） （←本記事） -目次- 前提条件 1. NFSプロビジョナーの設定 1-1 NFSプロビジョナーについて 1-2 NFSプロビジョナーの動作 1-3 NFSプロビジョナーのインストール （１）NFSプロビジョナー用のプロジェクトを作成 （2）サービスアカウントの作成 （3）Helmのインストール （4）NFSプロビジョナーのインストール （5）NFSプロビジョナーのインストールの確認 1-4 デフォルトストレージクラスの設定 1-5 動的プロビジョニングの動作テスト （1）サンプルファイルのダウンロード （2）PVCの作成 （3）Podの作成 （4）サンプルのPodとPVの削除 （5）NFSプロビジョナーの削除 まとめ 前提条件 連載 第1回 、 第2回 および、 第3回 の「2. 踏み台サーバー上のNFSサーバー設定」作業が完了していることとします NFSプロビジョナー構築後の「イメージレジストリの設定」は 第3回 を参照ください 全体の構成や各パラメーターなどは連載 第1回 を参照してください 作業用端末のプロンプトは % とします 踏み台サーバーのプロンプトは $ とします 踏み台サーバーの作業は明示的に記載がある場合を除いて、作業ディレクトリ ${HOME}/work で作業することとします 踏み台サーバー上のNFSサーバー設定後の構成 1. NFSプロビジョナーの設定 踏み台サーバー上に構築したNFSサーバーを利用してPVの動的プロビジョニングを行うため、OpenShiftにNFSプロビジョナーをインストールします。 NFSプロビジョナー導入後の構成 1-1 NFSプロビジョナーについて OpenShiftでPVの動的プロビジョニングを行うためにはストレージとそれに対応したCSIドライバーが必要です。 今回構築したストレージはRHELで立てた汎用的なNFSサーバーなので専用のCSIドライバーがありません。 そこで今回は、汎用的なNFSサーバーをバックエンドに使用しPVの動的プロビジョニングを行うことができる「 NFS Subdir External Provisioner （以下、NFSプロビジョナー）」を利用します。 このNFSプロビジョナーはKuberentes SIGsでホストされているリポジトリの1つです。OSSで開発されておりApache-2.0 licenseに従い無償で利用できます。 kubernetes-sigs/nfs-subdir-external-provisioner: Dynamic sub-dir volume provisioner on a remote NFS server. なお、このNFSプロビジョナーは汎用的なNFSサーバーをバックエンドに利用できる反面、高度な機能には対応していません（ストレージの機能を使ったVolume CLoneなど）。 Support for "CSI Volume Cloning" · Issue #182 · kubernetes-sigs/nfs-subdir-external-provisioner 実稼働環境ではスナップショットやボリュームクローニングに対応したCSIドライバを提供しているストレージベンダーなどの製品をご利用ください。 1-2 NFSプロビジョナーの動作 NFSプロビジョナーの動作の流れは下記の通りです NFSプロビジョナーの動作 1-3 NFSプロビジョナーのインストール NFSプロビジョナーをインストールする流れは下記のとおりです。 NFSプロビジョナー用のプロジェクトを作成 サービスアカウントの作成 Helmのインストール NFSプロビジョナーのインストール 現時点ではコマンドの詳細を深く理解する必要はありません。まずはおまじない的にコマンドをコピペして実行してください。 （１）NFSプロビジョナー用のプロジェクトを作成 oc new-project コマンドでNFSプロビジョナー用のプロジェクトを作成します。 プロジェクト名は nfs-subdir-external-provisioner とします。 $ oc new-project nfs-subdir-external-provisioner （2）サービスアカウントの作成 NFSプロビジョナーのインストールの前にサービスアカウントを作成します。 サービスアカウントは、KubernetesやOpenShiftでシステムコンポーネントやアプリケーションがAPIサーバーと安全に通信するために使用される特殊なアカウントです。 手動で作成した nfs-subdir-external-provisioner サービスアカウントに権限、ラベル、アノテーションを追加します。 $ oc create sa nfs-subdir-external-provisioner $ oc adm policy add-scc-to-user hostmount-anyuid system:serviceaccount:nfs-subdir-external-provisioner:nfs-subdir-external-provisioner $ oc label sa nfs-subdir-external-provisioner app.kubernetes.io/managed-by=Helm $ oc annotate sa nfs-subdir-external-provisioner meta.helm.sh/release-name=nfs-subdir-external-provisioner meta.helm.sh/release-namespace=nfs-subdir-external-provisioner oc adm policy add-scc-to-user ：サービスアカウントに hostmount-anyuid というSCCを追加します oc label sa ：このサービスアカウントがHelmによって管理されていることを示すラベルを追加する oc annotate sa ：サービスアカウントにHelmリリースに関するメタデータをアノテーションとして追加する これでNFSプロビジョナーをインストールする準備が整いました。 （3）Helmのインストール NFSプロビジョナーのインストールでHelm *1 を使用します。 Helmはパッケージマネージャーの1つで、アプリケーションをパッケージ（Helmではチャートという）としてKuberenetes上に簡単にデプロイできる仕組みです。 今回の構成では踏み台サーバーにHelmをインストールします。Helmのインストールドキュメントは下記です（本記事ではRed Hatが提供しているHelmのバイナリを利用します）。 6.2. Helm のインストール | Red Hat Product Documentation x86_64の環境にHelmをインストールするコマンド例は下記のとおりです。 $ sudo curl -L https://mirror.openshift.com/pub/openshift-v4/clients/helm/latest/helm-linux-amd64 -o /usr/local/bin/helm $ sudo chmod +x /usr/local/bin/helm Helmのインストール後、 helm コマンドを実行して動作確認を行います。 $ helm version WARNING: Kubernetes configuration file is group-readable. This is insecure. Location: /home/user/work/auth/kubeconfig WARNING: Kubernetes configuration file is world-readable. This is insecure. Location: /home/user/work/auth/kubeconfig version.BuildInfo{Version:"v3.14.4+37.el9", GitCommit:"7163c12e65c8c0a40334c0a4b514b991ea37aa21", GitTreeState:"clean", GoVersion:"go1.21.9 (Red Hat 1.21.9-2.el9_4)"} KUBECONFIG 環境変数がセットされていて、かつ kubeconfig ファイルのパーミッションが所有者以外から読み込み可能になっているとコマンドの出力に警告が出ます。 気になる方は chmod コマンドでパーミッションを変更してください。 $ chmod 600 auth/kubeconfig （4）NFSプロビジョナーのインストール NFSプロビジョナーはOpenShiftにインストールします。初めにチャートリポジトリを追加し、その後にインストールを行います。 helm repo add コマンドでNFSプロビジョナーのチャートリポジトリを追加します。 $ helm repo add nfs-subdir-external-provisioner https://kubernetes-sigs.github.io/nfs-subdir-external-provisioner/ ~/.config/helm ディレクトリが作成され、参照するリポジトリの情報が保存されます helm install コマンドでNFSプロビジョナーをインストールします。 --set オプションを使って固有の情報を追加で指定します。 $ helm install nfs-subdir-external-provisioner nfs-subdir-external-provisioner/nfs-subdir-external-provisioner \ --set nfs.server=192.168.1.206 \ --set nfs.path=/mnt/nfs \ --set storageClass.accessMode=ReadWriteMany nfs.server ：NFSサーバーのIPアドレス/ホスト名を指定 nfs.path ：NFSエクスポートを行ったパスを指定 storageClass.accessMode ：RWXを使用するため ReadWriteMany を指定 helm install コマンドを実行すると下記のような応答が出力されます ... NAME: nfs-subdir-external-provisioner LAST DEPLOYED: Mon Jul 8 05:15:36 2024 NAMESPACE: nfs-subdir-external-provisioner STATUS: deployed REVISION: 1 TEST SUITE: None NFSプロビジョナーが正常にインストールできたかどうかは次の手順で確認します。 （5）NFSプロビジョナーのインストールの確認 OpenShiftのWebコンソールから「管理者向け表示」のプルダウンを選択し「開発者」を選択します。 これにより開発者向け表示（Developerパースペクティブ）に切り替えることができます。 開発者向け表示（Developerパースペクティブ）に切り替える 左のメニューから「トポロジー」を選択します。プロジェクトのプルダウンメニューから「 nfs-subdir-external-provisioner 」を選択します。 画面内に「D」のアイコンがついた nfs-subdir-external-provisioner というオブジェクト（Deployment）が表示されます。 このDeploymentはNFSプロビジョナーのアプリケーションPodの展開と管理を行うリソースです。 NFSプロビジョナーのプロジェクトのトポロジー表示 左のメニューからHelmを選択すると、現在選択しているプロジェクトに登録済みのHelmリリース *2 の情報が表示されます。 デプロイされたHelmリリースの表示 「HR」アイコンが付いたHelmリリース名（ここでは nfs-subdir-external-provisioner ）のリンクを選択します。 Helmリリースの詳細 Helmでインストールされたリソースの名前やタイプが一覧で表示されます。先ほど確認したDeploymentのステータス欄にはPodが1つ起動していることが確認できます。 このPodがNFSプロビジョナーを実行する実体（のコンテナ）となります。 1-4 デフォルトストレージクラスの設定 ストレージクラスとはPVの動的プロビジョニングを定義するために使用されます。ユーザーは必要なストレージクラスを指定して永続ボリューム要求（PVC）を作成します。 ストレージクラスの詳細については下記のドキュメントを参照してください。 5.6. デフォルトストレージクラスの管理 | Red Hat Product Documentation デフォルトストレージクラスとは2つ以上のストレージクラスが存在する場合に 標準的に使用されるストレージクラス のことです。 今回の構成ではストレージクラスは1つしか作成されていませんが、明示的に設定をしておくことで他のストレージクラスよりも優先的に利用するようにしておきます。 デフォルトストレージクラスを設定するには下記のコマンドを実行します。 今回はストレージクラス名： nfs-client に対して通常のコンテナアプリケーションと仮想マシンの両方にデフォルト設定を行います。 $ oc patch storageclass nfs-client -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}' $ oc patch storageclass nfs-client -p '{"metadata": {"annotations":{"storageclass.kubevirt.io/is-default-virt-class":"true"}}}' 設定が反映されているか下記のコマンドを実行して確認を行います。 oc get コマンドで引数に storageclass を指定し、さらに -o yaml オプションを追加して、ストレージクラスの設定内容をYAML形式で出力を行います。 $ oc get storageclass -o yaml 出力結果内の annotations: に先ほど設定した値が反映されているか確認できます。下記の出力結果を展開して内容を確認ください。 出力結果を開く $ oc get storageclass -o yaml apiVersion: v1 items: - allowVolumeExpansion: true apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: annotations: meta.helm.sh/release-name: nfs-subdir-external-provisioner meta.helm.sh/release-namespace: nfs-subdir-external-provisioner storageclass.kubernetes.io/is-default-class: "true" storageclass.kubevirt.io/is-default-virt-class: "true" creationTimestamp: "2024-06-28T07:10:00Z" labels: app: nfs-subdir-external-provisioner app.kubernetes.io/managed-by: Helm chart: nfs-subdir-external-provisioner-4.0.18 heritage: Helm release: nfs-subdir-external-provisioner name: nfs-client resourceVersion: "128018" uid: fd859079-dcb4-4b15-b1f2-747189033af2 parameters: archiveOnDelete: "true" provisioner: cluster.local/nfs-subdir-external-provisioner reclaimPolicy: Delete volumeBindingMode: Immediate kind: List metadata: resourceVersion: "" 1-5 動的プロビジョニングの動作テスト NFSプロビジョナーの設定ができたので実際にサンプルのPodを実行して動的プロビジョニングの動作テストを行います。 （1）サンプルファイルのダウンロード NFSプロビジョナーのリポジトリで公開されているサンプルのファイルをダウンロードします。 PVCとPodをそれぞれ実行するYAMLファイルをダウンロードします。 $ wget https://raw.githubusercontent.com/kubernetes-sigs/nfs-subdir-external-provisioner/master/deploy/test-claim.yaml $ wget https://raw.githubusercontent.com/kubernetes-sigs/nfs-subdir-external-provisioner/master/deploy/test-pod.yaml $ ls -d test-claim.yaml test-pod.yaml test-claim.yaml test-pod.yaml （2）PVCの作成 oc create コマンドでYAMLファイルからリソースを作成します。 -f オプションで読み込むYAMLファイルを指定します。 今回は前の作業からの流れのままプロジェクトは変更せずに行います。 $ oc create -f test-claim.yaml persistentvolumeclaim/test-claim created Webコンソールの管理者向け表示のメニューから「ストレージ＞PersistentVolumeClaims」を選択すると、作成されたPVCとバインドされたPVが一覧で表示されます。 サンプルのPVCから作成されたPV このサンプルでは下記の情報が確認できます。 PVC：test-claim PV：pvc-51702f11-4b99-451f-b2a1-109ab9e35557 PVの容量：1 MiB 使用したストレージクラス：nfs-client 踏み台サーバー上のNFSエクスポートディレクトリを確認すると、PV用のディレクトリが自動で作成されていることが分かります。 $ tree /mnt/nfs/ /mnt/nfs/ └── nfs-subdir-external-provisioner-test-claim-pvc-51702f11-4b99-451f-b2a1-109ab9e35557 1 directory, 0 files NFSサーバー上に作成されるディレクトリの命名規則は PVCのプロジェクト名（Namespace名） - PVC名 - PV名 になります。 （3）Podの作成 作成されたPVを使用するサンプルのPodを起動します。PVCの作成と同様に oc create コマンドを使用します。 $ oc create -f test-pod.yaml pod/test-pod created Webコンソールの管理者向け表示のメニューから「Workloads＞Pods」を選択すると、実行中のPodが一覧で表示されます。 サンプルのPod（ test-pod ）のステータスが Completed になっており、このPodの実行が正常に完了したことが分かります。 nfs-subdir-external-provisionerプロジェクトで実行中のPod一覧 Pod名の test-pod のリンクを選択するとPodの詳細画面が表示されます。 test-pod コンテナが busybox:stable コンテナイメージから作成されており、状態が Terminated になっており、すでに実行が終了していることが確認できます。 終了コードが 0 になっており、このコンテナの実行が正常に終了したことが示されています。 また、このコンテナではPVは nfs-pvc という名前でボリュームとして扱われており、コンテナ内の /mnt ディレクトリにマウントされています。 サンプルPodの詳細情報 このサンプルではコンテナの実行コマンドとして touch /mnt/SUCCESS が実行されて成功すれば exit 0 で終了するようにプログラムされています *3 。 そのため、サンプルのPod起動後にNFSサーバー上のディレクトリを確認すると、コンテナの中で作成された SUCCESS ファイルが生成されていることが確認できます。 $ tree /mnt/nfs/ /mnt/nfs/ └── nfs-subdir-external-provisioner-test-claim-pvc-51702f11-4b99-451f-b2a1-109ab9e35557 └── SUCCESS 1 directory, 1 file （4）サンプルのPodとPVの削除 作成したサンプルのPodとPVを削除する場合は下記のコマンドを実行します。 oc delete コマンドでOpenShift上のリソースを削除します。 -f オプションでYAMLファイルを指定し対象のリソースのみを削除できます。 -f オプションは複数指定可能で、今回はPodとPVを同時に削除します。 $ oc delete -f test-claim.yaml -f test-pod.yaml PV削除後のNFSサーバー上の実体ディレクトリは下記のようになります。 $ tree /mnt/nfs/ /mnt/nfs/ └── archived-nfs-subdir-external-provisioner-test-claim-pvc-51702f11-4b99-451f-b2a1-109ab9e35557 └── SUCCESS 1 directory, 1 file NFSプロビジョナーのデフォルト動作では、PV削除時のNFSサーバー上の実体ディレクトリは archived- が追加された名前にリネームされて保持されます。 これはストレージクラスの設定を出力することで確認できます。 OpenShift上のリソースから特定のセクションのパラメーターを取得する場合は、 oc get コマンドの出力を -o json オプションによりJSON形式で出力し、パイプで繋いで jq コマンドでパースします。 下記のコマンドでストレージクラスの parameters セクションの値のみを取り出すことができます。 $ oc get storageclasses -o json | jq '.items[].parameters' { "archiveOnDelete": "true" } parameters セクションに archiveOnDelete:true で設定されているため、PVを削除した場合でも実体ディレクトリがアーカイブされて保持されます。 この設定を archiveOnDelete:false に変更することで、PVの削除と同時に実体ディレクトリを削除できます。 なお、NFSプロビジョナーのインストール後にストレージクラスのパラメーターは変更できません。 次の項目を参照してNFSプロビジョナーを削除し、再度インストールする時に --set storageClass.archiveOnDelete=false オプションを追加してコマンドを実行してください。 （5）NFSプロビジョナーの削除 NFSプロビジョナーの削除を行う場合は helm delete コマンドを実行します。 helm delete コマンドに引数として nfs-subdir-external-provisioner を指定して実行します。 $ helm delete nfs-subdir-external-provisioner release "nfs-subdir-external-provisioner" uninstalled 合わせてOpenShiftのプロジェクトを削除する場合は下記のコマンドを実行します。 oc delete project コマンドに引数でプロジェクト名： nfs-subdir-external-provisioner を指定して実行します。 $ oc delete project nfs-subdir-external-provisioner project.project.openshift.io "nfs-subdir-external-provisioner" deleted プロジェクトを削除した場合、NFSプロビジョナーを再インストールする場合はサービスアカウントの作成から行う必要があります。 まとめ 汎用的なNFSサーバーをバックエンドとして、PVの動的プロビジョニングを行う方法としてNFSプロビジョナーの構築方法をご紹介しました。 PVの動的プロビジョニングを行うだけであればNFSプロビジョナーで十分ですが、OpenShift Virtualizationで仮想マシンのスナップショット機能には対応していません。 そのため、基本的にはNFSプロビジョナーと同様に構成して、Helmでインストールを行うことができる「NFS CSIドライバー」の利用を推奨します。 詳細は 第3回：共有ストレージの作成（NFS CSIドライバーの構築） を参照ください。 *1 : Helm *2 : OpenShift上にHelmでデプロイされたアプリケーションやサービスのインスタンスのこと *3 : 詳細を知りたい方はtest-pod.yamlファイルの中身を参照ください

Red Hatの小島です。 RHEL7は2024年6月30日にメンテナンスサポートフェーズが終了し、延長ライフフェーズ(Extended life phase. ELP)に入りました。ELPではこれまでに提供されたソフトウェアなどを引き続き利用できますが、テクニカルサポートが限定的なものとなります。 ELPでは、テクニカルサポートがインストール済みの既存システムに限定され、バグ修正、脆弱性修正、ハードウェアへの対応、問題発生時の根本原因の分析などは行われません。 www.redhat.com そのため、バグ修正や脆弱性修正などのサポートを引き続きご希望であれば、新しいメジャーリリースのRHEL(RHEL9など)に適宜更新していただく必要があります。その際の更新猶予期間として延長サポート(Extended Life-cycle Support. ELS)もレッドハットでは提供しています。AWS Marketplaceで提供される従量課金制のRHELをご利用されている場合でも、従量課金制のRHEL7 ELSをご利用いただけます。本記事ではAWS Marketplaceでの従量課金制RHEL7 ELS利用時の注意点と、実際の利用方法の概要をご紹介します。 従量課金制のRHEL7 ELS利用時の注意点 準備するもの Red Hatへのお問い合わせ AWS MarketplaceのカタログからRHEL7 ELSを購入 従量課金制のRHEL7 ELS利用の参考手順 従量課金制のRHEL7 ELS使用量の確認 従量課金制のRHEL7 ELS利用時の注意点 従量課金制のRHEL7 ELSをご利用される場合、次の点に注意してください。ご利用の際に、後述する従量課金専用のRHEL ELSサブスクリプションを持っておく必要があります。 RHEL7 ELSのサポートポリシーは、 Red Hatが定義した内容 に準拠します。 上記サポートポリシーに従ったRHEL7 ELSのサポート対象については、AWSではなく Red Hatがサポートを提供 します。 最新マイナーリリースのRHEL7.9に限定されます。 RHEL7の古いマイナーリリース(RHEL7.5など)の場合は、サポートされません。 yum update コマンドなどでRHEL7.9に更新してください。 準備するもの 以下の2つのアカウントが必要になります。 AWSアカウント ( AWSアカウントID を利用します) Red Hatアカウント AWS MarketplaceでのRHEL7 ELSは、AWSのサードパーティ製品としてRed Hatが販売します。RHEL7 ELSに関するソフトウェアは、AWSではなく、Red Hatが運用しているリポジトリから提供します。このRed Hatのリポジトリにアクセスしていただく権限を、Red Hatがユーザーに割り当てるためにRed Hatアカウントを必要とする仕組みになっています。Red Hatアカウントの作成方法については、下記のRed HatのWebページをご参照ください。 access.redhat.com 「Red Hatアカウントの管理について不明点があるから確認したい」「(後述する)AWSアカウントとRed Hatアカウントの連携状況を確認したい、または連携を解除したい」などのリクエストがある場合は、Red Hatのカスタマーサービスまでお問い合わせください。 www.redhat.com Red Hatへのお問い合わせ 2024年12月からプライベートオファー経由でなくても、日本のユーザーがRHEL7 ELSをAWS Marketplaceから直接購入して利用できるようになりました。そのため、プライベートオファー発行のためのRed Hatへのお問い合わせは不要になりました。 2024年7月時点では、日本のユーザーは上記のAWS Marketplaceのカタログから直接購入することはできません。AWS MarketplaceでのRHEL7 ELSは、全てプライベートオファー経由での提供となります。 AWS MarketplaceのカタログからRHEL7 ELSを購入 この購入手続きは、AWSアカウントIDごとに必要です。購入手続きを実施したAWSアカウントIDで、RHEL7 ELSの利用を有効化したRHELインスタンスを実行する必要があります。 下記のURLからAWSアカウントでログインして、AWS MarketplaceでのRHEL7 ELS購入手続きを実施します。販売元が「Red Hat」となっていることをご確認ください。販売元が「Red Hat Limited」となっているカタログは、EMEA地域専用のカタログなので利用できません。 aws.amazon.com すると、下記のような画面が表示されますので、画面右上にある「View purchase options」ボタンをクリックして、その次に表示される画面下部にある「Subscribe」ボタンをクリックします。 このカタログの「Pricing」で表示される「$0.008」は2025年3月31日まで消費税込みの価格でしたが、2025年4月1日からは消費税抜きの価格になりました。 AWS Marketplaceでの取引における日本の消費税に関する詳細情報は、下記のWebページをご参照ください。 aws.amazon.com その後、次のような画面が表示されますので「Set up your account」ボタンをクリックします。 すると、AWSのWebページからRed HatのWebページに遷移して、ログイン画面が表示されます。このログイン画面ではAWSアカウントではなく、前述した手順で作成したRed Hatアカウントでログインしてください。 Red Hatアカウントでのログインが完了すると、AWSアカウントとRed Hatアカウントの連携確認画面が表示されます。ここで表示される「terms and conditions」は Red HatのEnterprise Agreement (EA契約) です。問題なければ、チェックボックスにチェックを入れて「Connect accounts」ボタンをクリックします。 これでRed Hatアカウントに従量課金専用のRHEL ELSサブスクリプションが割り当てられます。下記のURLから、次の画面に表示されるRHEL ELSのPremium(24時間365日サポート)サブスクリプション(Red Hat Enterprise Linux Extended Life Cycle Support (On-Demand, Hourly Production Support). SKU: RH02985HR)が割り当てられていることを確認してください。確認できれば、RHEL7 ELS購入手続きは完了です。このRHEL ELSサブスクリプションを持って、ユーザーはRHEL ELSのソフトウェアを入手したり、Red Hatサポートチームへの問い合わせが可能になります。この画像では数量(Quantity)が2となっていますが、最低1つあればO.K.です。 購入手続きが完了しても、後述する従量課金制RHEL7 ELSの利用を有効化する手順を実施しない限り、RHEL7 ELSの利用料金は発生しません。 RHEL ELSサブスクリプション情報を確認するためのURL: https://console.redhat.com/subscriptions/inventory AWS Marketplaceから購入したRed Hatサブスクリプションは「Contract Number」が「Not Available」となっていますが、Red Hatからのサポートを問題なく受けることができます。 RHEL ELSサブスクリプションがRed Hatアカウントに割り当てられていないと、以降の手順には進めません。 RHEL ELSサブスクリプションが割り当てられていない場合、これまでの手順を正しく実施していたかどうかを見直してみてください。不明点がある場合は、Red Hatのカスタマーサービスまでお問い合わせ下さい。 www.redhat.com 従量課金制のRHEL7 ELS利用の参考手順 ここで記載しているRHEL7 ELSの利用手順は、次のURLの記載内容に従った参考手順です。 この手順を実施する場合、RHEL7のパッケージ更新に伴う再起動を除いて、既存のRHEL7インスタンスの再作成や再起動は必要ありません。 access.redhat.com この参考手順について不明な点がありましたら、上記で発行されたRHEL ELSサブスクリプションが割り当てられたRed Hatアカウントで、Red Hatサポートチームにお問い合わせください。 access.redhat.com 最初にAWS上でRHEL7 ELSの利用状況をレポートするためのhost-meteringサービスをインストールして起動します。このサービスがRed Hatに使用状況を定期的に送信し、この送信された情報をRed HatがAWSに送信することで、AWS Marketplace上でRed Hatが販売するRHEL7 ELSの利用料金を、AWSがユーザーに請求するという仕組みになっています。ファイアーウォールやプロキシ経由でhost-meteringサービスによる使用状況送信を行う場合、下記URLへの経路を確保してください。 cert.console.redhat.com:443 subscription.rhn.redhat.com:443 subscription.rhsm.redhat.com:443 cdn.redhat.com:443 *.akamaiedge.net:443 *.akamaitechnologies.com:443 こうしたプロキシ設定の詳細については、下記をご参照ください。 access.redhat.com AWS上の従量課金制RHEL7インスタンスでは、デフォルトでRHEL7のソフトウェアリポジトリが利用できるようになっていますので、そのリポジトリ経由で次のコマンドを実行して、host-meteringパッケージをインストールします。このとき、最新版のsubscription-managerパッケージが必要となりますので、 yum update コマンドでsubscription-managerパッケージも更新します。 $ sudo yum -y update subscription-manager $ sudo yum -y install host-metering 次に以下のWebページからRHEL7 ELSの利用を有効化するための証明書をダウンロードします。 証明書ダウンロード先のURL: https://access.redhat.com/labs/rhpc/ 証明書をダウンロードするために、下記の画像のようにRHEL ELS 7.9 x86_64を選択するようにしてください。このとき、フィルターボックスに Red Hat Enterprise Linux Server - Extended Life Cycle Support とコピペするとスムーズに選択できます。「Action」の下にある矢印アイコンをクリックします。 すると、次の画面が表示されますので、Option1かOption2のいずれかの方法を用いて証明書をダウンロードしてRHEL7インスタンス内に保存します。このときOption1では自動で、Option2では手動で subscription-manager register コマンドによるRed HatへのRHELシステム登録が実施されますが、登録の際はRHEL ELSサブスクリプションが割り当てられたRed Hatアカウントのユーザー/パスワードを使ってください。Option2の手動登録の際は、登録情報を紐づけた Activation Keyを使う こともできます。 ファイアーウォールやプロキシ経由で、subscription-managerコマンドによるRHELシステム登録などを実行する場合、下記のWebページを参考にしてください。ここで必要となるURLへの経路の確保については、上記のhost-meteringサービスで必要となる経路の確保とほぼ同じものとなります。(subscription-managerの場合、 cert.console.redhat.com:443 へのアクセス確保が不要となります) access.redhat.com RHEL7インスタンスへの証明書ダウンロードが完了したら、次のコマンドを実行してhost-meteringサービスを有効化します。 $ sudo subscription-manager refresh $ sudo systemctl enable --now host-metering.service host-meteringサービスがすでに起動されている場合は、証明書の情報を反映するためにhost-meteringサービスを再起動します。 $ sudo systemctl restart host-metering.service ここまでの手順で、Red HatへRHEL7 ELSの使用状況を送信するhost-meteringサービスの設定が完了しました。 host-meteringサービスによって送信されるデータは、「vCPU数」や「ホスト名」などのホスト情報がまとめられた数KB程のテキストデータです。このデータが10分に1回の間隔で自動送信されます。 access.redhat.com (注): ロケールを ja_JP.utf8 に設定しているシステムではhost-meteringサービスが正常に起動しないという問題がありましたが、この問題は host-metering-1.4.0-5.el7_9 パッケージで修正されましたので、このバージョンまたはこれより新しいバージョンのhost-meteringパッケージをご利用ください。 access.redhat.com この後に、AWS内でデフォルトで利用可能な内部Red Hat Update Infrastructure (RHUI)リポジトリーに加えて、Red HatのContent delivery network (CDN)から配信するELSのコンテンツを使用できるように設定するために、次のsubscription-managerコマンドを実行します。 subscription-manager register コマンドによるRHELシステム登録は、前述したOption1による証明書保存スクリプトを実施している、または、前述したOption2による手動でのRHELシステム登録を実行している場合は不要です。 $ sudo subscription-manager register $ sudo subscription-manager config --rhsm.manage_repos=1 $ sudo subscription-manager repos --enable rhel-7-server-els-rpms これでRHEL7 ELSの利用準備が完了です。 yum repolist コマンドでAWSのRHUIリポジトリに加えて、Red Hat CDNから配信するRHEL7 ELSリポジトリ(リポジトリーID: rhel-7-server-els-rpms/x86_64)も参照できるようになっていることが確認できます。この状態になると、yumコマンドなどでRHEL7 ELSリポジトリからのパッケージのダウンロードやインストールが出来るようになります。 $ sudo yum repolist 読み込んだプラグイン:amazon-id, product-id, search-disabled-repos, subscription-manager リポジトリー ID リポジトリー名 状態 rhel-7-server-els-rpms/x86_64 Red Hat Enterprise Linux 7 Server - Extended Life Cycle Support (RPMs) 34,484 rhel-7-server-rhui-rh-common-rpms/7Server/x86_64 Red Hat Enterprise Linux 7 Server - RH Common from RHUI (RPMs) 243 rhel-7-server-rhui-rpms/7Server/x86_64 Red Hat Enterprise Linux 7 Server from RHUI (RPMs) 34,484 rhel-7-server-rpms/7Server/x86_64 Red Hat Enterprise Linux 7 Server (RPMs) 34,484 rhui-client-config-server-7/x86_64 RHUI Client Configuration Server 7 10 repolist: 103,705 従量課金制のRHEL7 ELS使用量の確認 AWS Billing and Cost Management の画面から、他のAWSリソースと共にRHEL7 ELSの使用量を(およそ翌日以降に)確認できます。RHEL7 ELSは実行されたRHEL7インスタンスのvCPU総数に応じて、AWSアカウントIDごとに時間単位(hourly)で課金されます。RHEL7 ELSの利用を有効化しているRHEL7インスタンスを停止か削除すれば、RHEL7 ELSサブスクリプションの課金は止まります。 また、 Red HatのHybrid Cloud Console からRHEL7 ELSの利用時間をインスタンスごとに確認できます。

Red Hatでソリューションアーキテクトをしている田中司恩( @tnk4on )です。 この連載はvSphere環境上にOpenShift Container Platform（以下、OpenShift）およびOpenShift Virtualizationの環境を構築する方法を解説するシリーズです。 第2回はOpenShiftのインストール後の作業について解説します。今後の連載予定は下記の通りです。 第1回：OpenShiftのインストール 第2回：OpenShiftインストール後の作業 （←本記事） 第3回：共有ストレージの作成（NFS CSIドライバーの構築） 第4回：OpenShift Virtualizationのインストールと実行 第5回：vSphere仮想マシンの移行 【番外編】：共有ストレージの作成（NFSプロビジョナーの構築） （2024/7/24追記：第3回の内容を改訂し、元の内容を番外編に変更しました） -目次- インストール後の作業 前提条件 1. Webコンソールの表示設定 1-1 テーマの変更 1-2 言語設定 2. OpenShift CLI（oc）による操作 2-1 ocコマンドとは 2-2 インストール後に使用できる2つの管理者アカウント 2-3 kubeadminユーザーを使ったログイン方法 2-4 kubeconfigを使ったログイン方法 （1）kubeconfigについて （2）kubeconfigファイルの入手 （3）kubeconfigファイルを使ったログイン （4）oc loginとkubeconfig使用時の注意点 2-5 Cluster Operatorの出力確認 （1）Cluster Operatorの一覧を出力 （2）インストール途中でのCluster Operatorのモニタリング 3. 不要なPodの削除 4. アイデンティティープロバイダーの設定とkubeadminユーザーの削除 4-1 アイデンティティープロバイダーについて 4-2 htpasswd アイデンティティープロバイダーの設定 4-3 アイデンティティープロバイダーを使ったWebコンソールのログイン 4-4 アイデンティティープロバイダーを使ったocログイン 4-5 kubeadminユーザーの削除 まとめ インストール後の作業 本記事ではOpenShiftのインストール後の作業として、下記の内容を紹介します。 Webコンソールの表示設定 OpenShift CLI（oc）による操作 不要なPodの削除 アイデンティティープロバイダーの設定とkubeadminユーザーの削除 なお、OpenShiftのインストール後の作業は製品ドキュメントの「 インストール後の設定 」にまとまっています。 インストール後の設定 | Red Hat Product Documentation 今回の連載はOpenShift Virtualizationの検証目的なのでそれほど多くのDay2作業を行いません。 ストレージや関連するイメージレジストリーの設定は「第3回：共有ストレージの作成」で行います。 前提条件 連載第1回の作業を完了していることとします 全体の構成や各パラメーターなどは第1回を参照してください 作業用端末のプロンプトは % とします 踏み台サーバーのプロンプトは $ とします 踏み台サーバーの作業は明示的に記載がある場合を除いて、作業ディレクトリ ${HOME}/work で作業することとします OpenShiftインストール完了後の構成 1. Webコンソールの表示設定 前回のインストール作業が完了しWebコンソールにログインした状態からスタートします。 1-1 テーマの変更 Webコンソールのテーマはデフォルトではシステムのテーマにしたがって表示されます。 Webコンソールのライトとダークのテーマカラー OpenShiftのテーマを固定して変更したい場合は、ユーザー設定から変更を行います。 画面右上のユーザー名を選択し、プルダウンから ユーザー設定 を選択します。 Webコンソールのユーザー設定 デフォルトは「システムのデフォルト」が選択されていますので、変更する場合は「ライト」または「ダーク」を選択します。 ユーザー設定のテーマ 1-2 言語設定 デフォルトはブラウザの言語設定を使用します。別の言語に変更して固定したい場合は、チェックボックスを外して指定の言語を選択します。 ユーザー設定の言語設定 2. OpenShift CLI（oc）による操作 OpenShiftの操作の1つの OpenShift CLI（oc） を使ったCLIの操作について解説します。 2-1 ocコマンドとは oc コマンドを使用することでOpenShiftのクラスタ操作をCLIで行ったり、CLIでアプリケーションを作成できます。 oc コマンドのドキュメントは下記を参照してください。 第2章 OpenShift CLI (oc) | Red Hat Product Documentation 2-2 インストール後に使用できる2つの管理者アカウント oc コマンドによる操作をするためにはOpenShiftクラスターにログインする必要があります。 インストール直後に使用できる管理アカウントは2つあります。 kubeadmin system:admin kubeadmin はインストール後にWebコンソールへログインする時に使用したアカウントです。 system:admin はインストール後にダウンロードした kubeconfig ファイルを使ったログイン時に使用されるアカウントです。 OpenShiftにログインする複数の方法のまとめ どちらもクラスターの管理者アカウント（最上位の権限）ですが、 kubeadmin ユーザーの方はインストール後の一時利用を目的として用意されています。 そのため、Webコンソールにログインすると画面上部に「一時的な管理ユーザーとしてログインしています。他のユーザーがログインできるように、クラスターのOAuth設定を更新してください。」と警告が出続けます。 一時的な管理ユーザーでログインしている表示が掲載され続ける 本記事の後半では別の管理者アカウントの作成と kubeadmin ユーザーの削除について紹介します。 2-3 kubeadminユーザーを使ったログイン方法 kubeadmin ユーザーを使った oc コマンドによるログインは下記のように行います。 -u オプションでログインするユーザー名： kubeadmin を指定します。引数としてログイン先のOpenShiftのKubernetes APIをURLとして指定します。ポート番号は 6443 です。 $ oc login -u kubeadmin https://api.ocp.home.lab:6443 Webコンソールでアクセスした時と同様に、インストール後の状態では自己署名証明書を使っていますので接続の警告が出ます。 y を入力した後、パスワードの入力プロンプトが表示されますのでパスワードを入力します。 $ oc login -u kubeadmin https://api.ocp.home.lab:6443 The server uses a certificate signed by an unknown authority. You can bypass the certificate check, but any data you send to the server could be intercepted by others. Use insecure connections? (y/n): y WARNING: Using insecure TLS client config. Setting this option is not supported! Console URL: https://api.ocp.home.lab:6443/console Authentication required for https://api.ocp.home.lab:6443 (openshift) Username: kubeadmin Password: ログインが成功すると下記のような表示が出力されます。デフォルトでは default プロジェクトを開いた状態になります。 ... Login successful. You have access to 70 projects, the list has been suppressed. You can list all projects with 'oc projects' Using project "default". Welcome! See 'oc help' to get started. プロジェクトはKubernetesのnamespaceを拡張したものです。ここではOpenShift上の独立した論理的な分割単位でマルチテナントを実現するもの、くらいで覚えておけば良いでしょう。 ログインが成功すれば oc コマンドを使った各種操作が実行できます。 いくつかコマンドを実行してみましょう。 $ oc whoami kube:admin $ oc cluster-info Kubernetes control plane is running at https://api.ocp.home.lab:6443 To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. $ oc get nodes NAME STATUS ROLES AGE VERSION node-01.ocp.home.lab Ready control-plane,master,worker 37h v1.29.5+29c95f3 node-02.ocp.home.lab Ready control-plane,master,worker 37h v1.29.5+29c95f3 node-03.ocp.home.lab Ready control-plane,master,worker 37h v1.29.5+29c95f3 oc whoami ：現在ログインしているユーザー名を表示 oc cluster-info ：現在接続しているOpenShiftのクラスター情報を表示 oc get nodes ：OpenShiftクラスターを構成している各ノードを表示 ログアウトを行うには oc logout を実行します。 $ oc logout Logged "kube:admin" out on "https://api.ocp.home.lab:6443" oc login を行うとホームディレクトリ配下に .kube ディレクトリが作成されます。 .kube/config にはログインしたユーザーのトークン情報が記載され、デフォルトでは24時間の有効期限が設定されます。 トークンの有効期限が切れると下記のように oc コマンドが実行できなくなります。 $ oc whoami error: You must be logged in to the server (Unauthorized) トークンの有効期限が切れた場合は再度 oc コマンドでログインを行ってください。 デフォルトのトークンの期間を変更する場合は下記のドキュメントを参考にしてください。 3.4. 内部 OAuth サーバーのトークン期間の設定 | Red Hat Product Documentation 2-4 kubeconfigを使ったログイン方法 kubeconfig ファイルを使ったログイン方法はインストールのドキュメントに載っている方法でよく利用されます。 KUBECONFIG 環境変数に kubeconfig ファイルを指定することで、ユーザー名やパスワードを入力することなく固定のユーザー名： system:admin でログインができます。 なお、 system:admin を使ったログインは CLIのみ利用可能 で、Webコンソールでは使用できない点はご注意ください。 kubeconfig ファイルを使ったログイン方法のドキュメントは下記です。 3.12. インストールの完了 | Red Hat Product Documentation （1）kubeconfigについて kubeconfig ファイルは再利用ができません。たとえばOpenShiftを再インストールした場合は、新しいクラスター用の kubeconfig ファイルを入手して使用する必要があります。 kubeconfig ファイルは必ずバックアップを取っておくようにしましょう。 kubeconfigファイルを紛失したり損傷した場合は下記の手順で復旧できる場合があります Openshift 4 で system:admin ユーザーの kubeconfig を再作成する方法 - Red Hat Customer Portal About the OpenShift 4 kubeconfig file for system:admin - Red Hat Customer Portal （2）kubeconfigファイルの入手 前回 ダウンロードした kubeconfig ファイルを踏み台サーバーにコピーします。 kubeconfig ファイルは作業用端末のカレントディレクトリにあることとします。 踏み台サーバーに kubeconfig ファイルの配置先となる auth ディレクトリを作成します。 OpenShiftのドキュメントでは以前から慣用的に auth ディレクトリ配下に kubeconfig ファイルを配置するように示されてるのでそれに従います。 （作業用端末で実行） % ssh bastion mkdir work/auth 踏み台サーバーに kubeconfig ファイルをコピーします。 （作業用端末で実行） % scp kubeconfig bastion:work/auth/ 踏み台サーバーにログインします。 （作業用端末で実行） % ssh bastion （3）kubeconfigファイルを使ったログイン まず、 oc logout コマンドを実行してログアウトを行います。 $ oc logout Logged "kube:admin" out on "https://api.ocp.home.lab:6443" 現在のシェルセッションに KUBECONFIG 環境変数をセットします。 $ export KUBECONFIG=${HOME}/work/auth/kubeconfig フルパスで kubeconfig ファイルを指定することで別のディレクトリに移動した場合でも oc コマンドが実行できるようにします oc whoami コマンドを実行し現在ログインのユーザーを確認します。 $ oc whoami system:admin oc コマンドが実行できるか確認します。 $ oc cluster-info Kubernetes control plane is running at https://api.ocp.home.lab:6443 To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. $ oc get nodes NAME STATUS ROLES AGE VERSION node-01.ocp.home.lab Ready control-plane,master,worker 38h v1.29.5+29c95f3 node-02.ocp.home.lab Ready control-plane,master,worker 38h v1.29.5+29c95f3 node-03.ocp.home.lab Ready control-plane,master,worker 38h v1.29.5+29c95f3 oc login コマンドを使った場合と異なり、ログイン操作不要で oc コマンドを実行できるようになりました。 kubeconfig ファイルを使った操作をやめる場合、明示的なログアウトの処理はありません。 その代わりに KUBECONFIG 環境変数を解除して同等の処理とします。 $ echo $KUBECONFIG /home/user/work/auth/kubeconfig $ unset KUBECONFIG $ echo $KUBECONFIG $ oc whoami Error from server (Forbidden): users.user.openshift.io "~" is forbidden: User "system:anonymous" cannot get resource "users" in API group "user.openshift.io" at the cluster scope （4）oc loginとkubeconfig使用時の注意点 oc login と kubeconfig の併用は行わず、ログアウトまたは環境変数の解除を行って どちらか一方のみの操作 で行うようにしてください。 KCS にも下記の記載があります。 Important: Don't execute oc login when using the kubeconfig file, as it will switch them from using the special system:admin user (which uses client certificates) to token-based authentication using the credentials specified. （翻訳） 重要: kubeconfig ファイルを使用している場合、oc login を実行しないでください。実行すると、クライアント証明書を使用する特別な system:admin ユーザーから、指定された資格情報を使用するトークンベースの認証に切り替わってしまいます。 たとえば、 export KUBECONFIG を行った状態で、 oc login を行うと .kube ディレクトリが作成されず、 kubeconfig ファイルにユーザーのログイン情報が書き込まれます。 $ export KUBECONFIG=${HOME}/work/auth/kubeconfig $ oc whoami system:admin $ oc login -u kubeadmin https://api.ocp.home.lab:6443 Console URL: https://api.ocp.home.lab:6443/console Authentication required for https://api.ocp.home.lab:6443 (openshift) Username: kubeadmin Password: Login successful. You have access to 70 projects, the list has been suppressed. You can list all projects with 'oc projects' Using project "default". $ ls -d ~/.kube ls: '/home/user/.kube' にアクセスできません: そのようなファイルやディレクトリはありません それと同時に kubeconfig ファイルを使った system:admin ユーザーでのログインができなくなります。 $ export KUBECONFIG=${HOME}/work/auth/kubeconfig $ oc whoami Error from server (Forbidden): users.user.openshift.io "~" is forbidden: User "system:anonymous" cannot get resource "users" in API group "user.openshift.io" at the cluster scope こうなると元の kubeconfig ファイルから復旧するか、上記で紹介したKCSの方法で kubeconfig ファイルを復旧する必要があります。 ご注意ください。 2-5 Cluster Operatorの出力確認 oc コマンドを使った操作の1つである「Cluster Operatorの出力確認」について紹介します。 Cluster OperatorはOpenShiftクラスター全体のインフラストラクチャと管理を担当する重要なコンポーネントです。 Cluster Operatorがすべて正常に動作しているかどうかが、OpenShiftのクラスターの状態を確認する1つの手段になります。 （1）Cluster Operatorの一覧を出力 oc get clusteroperators コマンドを実行するとCluster Operatorの一覧を出力できます。 OpenShiftクラスターが正常にしている場合は、 AVAILABLE がすべて True 、 PROGRESSING と DEGRADED がすべて False になります。 oc get clusteroperators コマンドは oc get co と省略して入力できます。 $ oc get co NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE authentication 4.16.0 True False False 7m1s baremetal 4.16.0 True False False 30m cloud-controller-manager 4.16.0 True False False 43m cloud-credential 4.16.0 True False False 50m cluster-autoscaler 4.16.0 True False False 32m config-operator 4.16.0 True False False 33m console 4.16.0 True False False 14m control-plane-machine-set 4.16.0 True False False 30m csi-snapshot-controller 4.16.0 True False False 33m dns 4.16.0 True False False 33m etcd 4.16.0 True False False 31m image-registry 4.16.0 True False False 14m ingress 4.16.0 True False False 18m insights 4.16.0 True False False 28m kube-apiserver 4.16.0 True False False 23m kube-controller-manager 4.16.0 True False False 24m kube-scheduler 4.16.0 True False False 24m kube-storage-version-migrator 4.16.0 True False False 34m machine-api 4.16.0 True False False 21m machine-approver 4.16.0 True False False 34m machine-config 4.16.0 True False False 33m marketplace 4.16.0 True False False 32m monitoring 4.16.0 True False False 11m network 4.16.0 True False False 35m node-tuning 4.16.0 True False False 18m openshift-apiserver 4.16.0 True False False 22m openshift-controller-manager 4.16.0 True False False 27m openshift-samples 4.16.0 True False False 22m operator-lifecycle-manager 4.16.0 True False False 30m operator-lifecycle-manager-catalog 4.16.0 True False False 30m operator-lifecycle-manager-packageserver 4.16.0 True False False 22m service-ca 4.16.0 True False False 35m storage 4.16.0 True False False 34m （2）インストール途中でのCluster Operatorのモニタリング OpenShiftのインストールの途中に kubeconfig ファイルをダウンロードし、Cluster Operatorの一覧を出力することでインストールの経過状況をモニタリングできます。 watch コマンドを合わせて実行して進行状況を自動でモニタリングできます。 $ watch oc get co NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE authentication 4.16.0 False True True 13m OAuthServerDeploymentAvailable: no oauth-openshift.openshift-authentication pods available on any node.... baremetal 4.16.0 True False False 9m18s cloud-controller-manager 4.16.0 True False False 22m cloud-credential 4.16.0 True False False 29m cluster-autoscaler 4.16.0 True False False 11m config-operator 4.16.0 True False False 12m console control-plane-machine-set 4.16.0 True False False 9m32s csi-snapshot-controller 4.16.0 True False False 12m dns 4.16.0 True False False 12m etcd 4.16.0 True True False 10m NodeInstallerProgressing: 2 nodes are at revision 5; 0 nodes have achieved new revision 6 image-registry 4.16.0 True False False 47s ingress False True True 11m The "default" ingress controller reports Available=False: IngressControllerUnavailable: One or more status conditions indicate unavailable: DeploymentAvailable=False (DeploymentUnavailable: The deployment has Available status condition set to False (reason: MinimumReplicasUnavailable) with message: Deployment does not have minimum availability.) insights 4.16.0 True False False 7m14s kube-apiserver 4.16.0 True True False 2m38s NodeInstallerProgressing: 1 node is at revision 0; 1 node is at revision 3; 0 nodes have achieved new revision 6 kube-controller-manager 4.16.0 True True False 3m3s NodeInstallerProgressing: 1 node is at revision 3; 1 node is at revision 4 kube-scheduler 4.16.0 True True False 3m37s NodeInstallerProgressing: 1 node is at revision 3; 1 node is at revision 4 kube-storage-version-migrator 4.16.0 True False False 13m machine-api 4.16.0 True False False 48s machine-approver 4.16.0 True False False 12m machine-config 4.16.0 True False False 12m marketplace 4.16.0 True False False 11m monitoring Unknown True Unknown 11m Rolling out the stack. network 4.16.0 True False False 14m node-tuning 4.16.0 True False False 8m56s openshift-apiserver 4.16.0 True False False 65s openshift-controller-manager 4.16.0 True True False 6m12s Progressing: deployment/controller-manager: updated replicas is 1, desired replicas is 2... openshift-samples 4.16.0 True False False 55s operator-lifecycle-manager 4.16.0 True False False 9m25s operator-lifecycle-manager-catalog 4.16.0 True False False 9m27s operator-lifecycle-manager-packageserver 4.16.0 True False False 75s service-ca 4.16.0 True False False 14m storage 4.16.0 True False False 13m なお、すべてのOperatorの AVAILABLE が True にならずAssisted Installerの画面上でインストール完了になることがあります。 これは処理の進行上タイムラグが出ることはありますが問題はありません。 3. 不要なPodの削除 OpenShiftのインストール完了後、クラスターインベントリーの欄にエラーのPodが表示されることがあります。 インストール後、エラーになったPodが表示されることがある エラーの数字のリンクを押すと、エラーでフィルタリングされたPodの一覧が表示されます。 エラーになったPodの一覧表示 これはインストール時になんらかの理由でエラーになって残ったものですが、不要なので削除できます。GUI上でPodの一覧表示からPodを1つ1つを選んで削除することもできますが、数が多いと手間がかかります。 このような繰り返す作業はCLIで行う方が効率的です。先ほど使えるようにした oc コマンドでCLIを使って一括で削除してみましょう。 oc コマンドでエラーになったPodを確認する場合は下記のコマンドを実行します。 --field-selector= オプションでステータスが Failed になったPodをフィルタリングできます。 $ oc get pods --field-selector=status.phase=Failed -A NAMESPACE NAME READY STATUS RESTARTS AGE openshift-kube-apiserver installer-2-node-02.ocp.home.lab 0/1 Error 0 43m openshift-kube-apiserver installer-4-node-03.ocp.home.lab 0/1 Error 0 33m openshift-kube-controller-manager installer-2-node-02.ocp.home.lab 0/1 Error 0 44m openshift-operator-lifecycle-manager collect-profiles-28666305-hlq7g 0/1 Error 0 37m Podを削除する場合は oc delete pods コマンドを実行します。確認の場合と同じく --field-selector= オプションを使ってPodをフィルタリングします。 $ oc delete pods --field-selector=status.phase=Failed -A pod "installer-2-node-02.ocp.home.lab" deleted pod "installer-4-node-03.ocp.home.lab" deleted pod "installer-2-node-02.ocp.home.lab" deleted pod "collect-profiles-28666305-hlq7g" deleted Podの削除後、エラーになったPodが消えたことを確認します。 $ oc get pods --field-selector=status.phase=Failed -A No resources found エラーになったPodが削除された状態 4. アイデンティティープロバイダーの設定とkubeadminユーザーの削除 4-1 アイデンティティープロバイダーについて OpenShiftのインストール後から使用している kubeadmin ユーザーは一時的な管理ユーザーで、恒久的に使用できるユーザーではありません。 そのため kubeadmin ユーザーをそのまま使っていると、Webコンソールの上部に青い表示が出続けることになります。 一時的な管理ユーザーでログインしている表示が掲載され続ける 「クラスターのOauth設定」の文字のリンクを選択するとOpenShiftクラスターのOauthの画面が表示されます。 デフォルトではアイデンティティープロバイダーは何も登録されておらず、そのままでは管理ユーザーの変更ができません。 まずはアイデンティティープロバイダーの設定を行うところから開始します。 OpenShiftはさまざまなアイデンティティープロバイダーに対応しており、大規模なエンタープライズでの利用にも対応できます。 今回は小規模な検証用途ですので、一番シンプルに実装できる htpasswd を使って設定を行います。 アイデンティティープロバイダー設定については下記のドキュメントを参照してください。 第6章 アイデンティティープロバイダー設定について | Red Hat Product Documentation アイデンティティープロバイダーを使ったログインの構成は、本記事2-2の「図：OpenShiftにログインする複数の方法のまとめ」を参照ください。 4-2 htpasswd アイデンティティープロバイダーの設定 まず、htpasswdファイルの作成を行います。htpasswdファイルは、各ユーザーのユーザー名とハッシュ化されたパスワードを含むフラットファイルです。 htpasswdファイルは htpasswd コマンドを使ってファイルの作成とユーザーの追加を行います。 今回はファイル名： users.htpasswd 、ユーザー名： ocpadmin 、パスワード： password で作成を行います。 $ htpasswd -c -B -b users.htpasswd ocpadmin password 次に、htpasswdファイルが含まれる Secretオブジェクト を作成します。 $ oc create secret generic htpass-secret --from-file=htpasswd=users.htpasswd -n openshift-config secretの一覧を表示し、作成した htpass-secret が含まれているか確認します。 $ oc get secret -n openshift-config NAME TYPE DATA AGE builder-dockercfg-77z9v kubernetes.io/dockercfg 1 13h default-dockercfg-zjt6b kubernetes.io/dockercfg 1 13h deployer-dockercfg-5z9qv kubernetes.io/dockercfg 1 13h etcd-client kubernetes.io/tls 2 13h etcd-metric-signer kubernetes.io/tls 2 13h etcd-signer kubernetes.io/tls 2 13h htpass-secret Opaque 1 2m53s initial-service-account-private-key Opaque 1 13h pull-secret kubernetes.io/dockerconfigjson 1 13h webhook-authentication-integrated-oauth Opaque 1 13h htpasswdのカスタムリソース（CR）を作成します。これはhtpasswdアイデンティティープロバイダーのパラメーターと許可される値を定義したものです。 oauth_cr.yaml というファイル名で作成します。 $ cat > oauth_cr.yaml <<EOF apiVersion: config.openshift.io/v1 kind: OAuth metadata: name: cluster spec: identityProviders: - name: my_htpasswd_provider mappingMethod: claim type: HTPasswd htpasswd: fileData: name: htpass-secret EOF my_htpasswd_provider：このプロバイダー名は、プロバイダーのユーザー名に接頭辞として付加され、アイデンティティー名が作成されます。 mappingMethod：このプロバイダーのアイデンティティーとUserオブジェクト間にマッピングが確立される方法を指定します htpass-secret：htpasswdファイルが含まれる既存のシークレットです。 htpasswdのカスタムリソースをクラスターに適用します。 $ oc apply -f oauth_cr.yaml 作成したユーザー ocpadmin をクラスター管理者として定義します。OpenShiftでは cluster-admin というロールをユーザーに適用することでこれを行います。 11.2. RBAC の使用によるパーミッションの定義および適用 | Red Hat Product Documentation $ oc create clusterrolebinding admin --clusterrole=cluster-admin --user=ocpadmin これで ocpadmin ユーザーをクラスター管理者として作成することができました。 4-3 アイデンティティープロバイダーを使ったWebコンソールのログイン アイデンティティープロバイダーの設定が完了しましたので、Webコンソールから kubeadmin ユーザーをログアウトします。 画面右上のユーザー名を選択しプルダウンからログアウトを選択します。 Webコンソールからログアウトする ログイン画面に戻ると以前とは異なり、ユーザー名とパスワードの入力欄が消え、代わりに kube:admin と登録したhtpasswdアイデンティティープロバイダー名： my_htpasswd_provider が表示されます。 htpasswdのカスタムリソースの適用直後はCluster Operator: authentication の更新が完了しておらず、選択画面が出てこないことがあります。しばらく待ってからブラウザをリロードしてください。 ユーザー名とパスワードの代わりにアイデンティティープロバイダーの選択が表示 my_htpasswd_provider を選択し、続けて表示されるユーザー名とパスワードに先ほど作成した ocpadmin のユーザー情報を入力します。 新しい管理者ユーザーのユーザー名とパスワードを入力 ocpadmin で管理者としてWebコンソールにログインができました。 新しい管理者ユーザーでWebコンソールにログイン oc コマンドでユーザー情報を表示すると、ユーザー名と対応するアイデンティティープロバイダー名が確認できます。 $ oc get users NAME UID FULL NAME IDENTITIES ocpadmin 60272a66-73b6-42b9-aec6-8941340acdd7 my_htpasswd_provider:ocpadmin 4-4 アイデンティティープロバイダーを使ったocログイン 今度は oc login コマンドを使い、作成したユーザー： ocpadmin を指定してログインします。 「2-4 kubeconfigを使ったログイン方法」で書いたように、 oc login の前に KUBECONFIG 環境変数を解除してから実施します。 ログインの手順は「2-3 kubeadminユーザーを使ったログイン方法」と同じです。 $ unset KUBECONFIG $ oc login -u ocpadmin https://api.ocp.home.lab:6443 The server uses a certificate signed by an unknown authority. You can bypass the certificate check, but any data you send to the server could be intercepted by others. Use insecure connections? (y/n): y WARNING: Using insecure TLS client config. Setting this option is not supported! Console URL: https://api.ocp.home.lab:6443/console Authentication required for https://api.ocp.home.lab:6443 (openshift) Username: ocpadmin Password: Login successful. You have access to 70 projects, the list has been suppressed. You can list all projects with 'oc projects' Using project "default". Welcome! See 'oc help' to get started. 現在のセッションのユーザー名を確認します。 $ oc whoami ocpadmin 4-5 kubeadminユーザーの削除 新しい管理者ユーザーの作成が完了したので、kubeadminユーザーの削除を行います。 手順は下記のドキュメントに従います。 6.3. kubeadmin ユーザーの削除 | Red Hat Product Documentation kubeadminユーザーを削除する前提条件は下記の通りです。 1つ以上のアイデンティティープロバイダーを設定しておく必要があります。 cluster-adminロールをユーザーに追加しておく必要があります。 管理者としてログインしている必要があります。 ここでは「4-4 アイデンティティープロバイダーを使ったocログイン」の続きで、 ocpadmin ユーザーでログインしている状態で実行します。 kubeadmin ユーザーの削除は下記のコマンドを実行します。 $ oc delete secrets kubeadmin -n kube-system secret "kubeadmin" deleted kubeadmin ユーザーでログインできないことを確認します。 $ oc logout Logged "ocpadmin" out on "https://api.ocp.home.lab:6443" $ oc login -u kubeadmin https://api.ocp.home.lab:6443 WARNING: Using insecure TLS client config. Setting this option is not supported! Console URL: https://api.ocp.home.lab:6443/console Authentication required for https://api.ocp.home.lab:6443 (openshift) Username: kubeadmin Password: Login failed (401 Unauthorized) Verify you have provided the correct credentials. Webコンソールをログインし、再度ログインWebコンソールのトップ画面に戻ると元のユーザー名とパスワードを入力する表示に変わります。 これは登録されているアイデンティティープロバイダーが1種類しかないためです。 アイデンティティープロバイダーが1つの時のWebコンソールのログイン画面 まとめ OpenShiftのインストール後の作業についてご紹介しました。 OpenShiftはWebコンソールも利用できますが、まだまだ多くの作業は oc コマンドを使ったCLI操作が中心です。 またその設定方法はYAML形式のカスタムリソースを作成して適用するなどKuberentes特有の作業であり、新しい操作には慣れが必要です。 その反面パラメーターや設定変更後の状態をコードとして定義できる点は、手作業などの属人性の排除に繋がります。 本連載を通じて少しずつでもクラウドネイティブなインフラ管理の便利さを体感頂ければと思います。 （次回予告） 次回はOpenShift Virtualizationに必須の、共有ストレージの作成について解説します。

Red Hat で Java 関連を担当している伊藤ちひろです。 前回は、既存のJakarta EEアプリケーションをコンテナ化する方法を紹介しました。 既存のJakarta EE アプリケーション(WAR)を JBoss EAP でコンテナ化 - 赤帽エンジニアブログ また、Helm を使って OpenShift 上にコンテナ化する方法も紹介しました。 既存のJakarta EE アプリケーション(WAR)を JBoss EAP + OpenShift でコンテナ化 -Helm編- - 赤帽エンジニアブログ 今回も昔から運用されている Servlet/JSP で動作する Java EE アプリケーションをコンテナ化してOpenShiftへデプロイする方法を紹介します。 今回は、Source to Image を使用します。 必要な作業は以下の4つです。 Jakarta EE に対応 （今回は説明を省きます） Mavenの導入 Git対応 Source to Image Jakarta EEに対応 アプリケーションを Java EE から Jakarta EE に移行します。 JBoss EAP 8.0 は Jakarta EE 10 に対応しており、Java EE には対応していないためです。 本記事は、この移行が目的ではないため省略します。 この移行を支援するツールとして、Migration Toolkit があります。 Migration Toolkit は Red Hat が提供しているツールです。 Maven の導入 次に、アプリケーションのビルドのため Maven を導入します。 多くのアプリケーションはすでに導入しているでしょう。 しかしながら、一部のアプリケーションは Ant や独自の方法でビルドしているかもしれません。 今回は、最低限必要な Maven の設定を記載しています。 これから Maven を使う場合は、これをベースに依存関係を追加してください。 すでにMavenを使っている場合は、この設定を既存の設定に追加してください。 今回は、 Servlet/JSP を実行可能な、できるだけコンパクトな JBoss EAP をデプロイします。 JBoss EAP はアプリケーションが必要とする機能だけをもつコンパクトな JBoss EAP を作成できます。 この仕組みを Galleon と言います。 Galleon は各機能を Layer として定義しています。 Servlet/JSP を実行できる Layer は web-server です。 Layer は今回使用している web-server のほかにも、 ejb や jaxrs などさまざまあります。 他にどのような Layer があるのかは以下に記載されています。 第8章 JBoss EAP for OpenShift の機能のトリム | Red Hat Product Documentation また、Galleon 自体に興味のある方はこちらをごらん下さい。 Galleon Provisioning Guide 今回使用する pom.xml は以下のとおりです。 <project xmlns = "http://maven.apache.org/POM/4.0.0" xmlns : xsi = "http://www.w3.org/2001/XMLSchema-instance" xsi : schemaLocation = "http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd" > <modelVersion> 4.0.0 </modelVersion> <groupId> org.example </groupId> <artifactId> jee-traditional </artifactId> <packaging> war </packaging> <version> 1.0-SNAPSHOT </version> <profiles> <profile> <id> openshift </id> </profile> <profile> <id> develop </id> <activation> <activeByDefault> true </activeByDefault> </activation> </profile> </profiles> <dependencyManagement> <dependencies> <dependency> <groupId> org.jboss.bom </groupId> <artifactId> jboss-eap-ee </artifactId> <version> 8.0.0.GA-redhat-00009 </version> <type> pom </type> <scope> import </scope> </dependency> </dependencies> </dependencyManagement> <pluginRepositories> <pluginRepository> <id> jboss </id> <url> https://maven.repository.redhat.com/ga/ </url> <snapshots> <enabled> false </enabled> </snapshots> </pluginRepository> </pluginRepositories> <repositories> <repository> <id> jboss </id> <url> https://maven.repository.redhat.com/ga/ </url> <snapshots> <enabled> false </enabled> </snapshots> </repository> </repositories> <build> <finalName> ROOT.war </finalName> <plugins> <plugin> <groupId> org.apache.maven.plugins </groupId> <artifactId> maven-war-plugin </artifactId> <version> 3.4.0 </version> </plugin> <plugin> <groupId> org.jboss.eap.plugins </groupId> <artifactId> eap-maven-plugin </artifactId> <version> 1.0.0.Final-redhat-00014 </version> <configuration> <channels> <channel> <manifest> <groupId> org.jboss.eap.channels </groupId> <artifactId> eap-8.0 </artifactId> </manifest> </channel> </channels> <feature-packs> <feature-pack> <location> org.jboss.eap:wildfly-ee-galleon-pack </location> </feature-pack> <feature-pack> <location> org.jboss.eap.cloud:eap-cloud-galleon-pack </location> </feature-pack> </feature-packs> <layers> <layer> web-server </layer> </layers> <runtime-name> ROOT.war </runtime-name> </configuration> <executions> <execution> <goals> <goal> package </goal> </goals> </execution> </executions> </plugin> </plugins> </build> </project> Git 対応 アプリケーションは Git リポジトリで管理します。 OpenShift は後に指定する Git リポジトリからアプリケーションのソースコードを取得して、ビルドします。 Git リポジトリは OpenShift からアクセスできればどこでも大丈夫です。 今回は、GitHub 上のリポジトリを用います。 github.com Source to Image (S2I) 最後に、Source to Image (S2I) を使用して アプリケーションを含んだ JBoss EAP を作成します。 S2I は、CLI の oc コマンドを使います。 まずは、アプリケーションのビルドや JBoss EAP の構築に必要なビルダーを取得します。 > oc import-image jboss-eap-8/eap8-openjdk17-builder-openshift-rhel8:latest --from=registry.redhat.io/jboss-eap-8/eap8-openjdk17-builder-openshift-rhel8:latest --confirm 次に、アプリケーションをビルドします。 これには時間がかかります。 > oc new-build eap8-openjdk17-builder-openshift-rhel8:latest~https://github.com/chiroito/jee-traditional.git --name=myapp-build-artifacts 最後に、作成されたアプリケーションをデプロイし、外部からアクセスできるようにします。 > oc new-app --name=myapp myapp-build-artifacts > oc create route edge --service myappv これで完了です。 OpenShift で確認 アプリケーションが OpenShift にデプロイされたかを確認します。 開発者向けの表示の Builds をクリックします。 Buildsに my-app-build-artifacts というBuildConfigsができているはずです。 最終実行のステータス が Complete になっていればビルドは成功です。 Running はまだビルドしています。 他のステータスになったら、実行を確認しましょう。 最終実行 のカラムにある myapp-build-artifacts-1 をクリックします。 ログのタブをクリックするとログが出力されます。 出力されたログから失敗した原因を確認しましょう。 ビルドが成功したら、アプリケーションがデプロイされています。 左側のメニューの トポロジー をクリックします。 ここに myapp というアイコンができているはずです。 これをクリックすると、右側に詳細が表示されます。 その詳細で、青色の丸の中に 1 Pod と表示されていればアプリケーションが起動しています。 0 Pod の場合はアプリケーションの起動がまだ終わっていないか、起動に失敗しています。 青丸の上のリソースタブを開き、Podsのログを表示して、失敗の原因を確認しましょう。 確認の最後として、アプリケーションへアクセスしてみましょう。 下のアイコンをクリックすると、アプリケーションへアクセスできます。 サンプルアプリケーションを使用している場合は、 index.jsp の Hello World! が表示されれば成功です。 いかがでしたでしょうか。 今回は、設定をかなり省略しています。 本番ではもう少しちゃんと設定が必要になります。 とはいえ、既存のアプリケーションをOpenShift上にデプロイする流れをイメージできたのではないでしょうか。

Red Hat で Java 関連を担当している伊藤ちひろです。 前回は、既存のJakarta EEアプリケーションをコンテナ化する方法を紹介しました。 既存のJakarta EE アプリケーション(WAR)を JBoss EAP でコンテナ化 - 赤帽エンジニアブログ 今回は昔から運用されている Servlet/JSP で動作する Java EE アプリケーションをコンテナ化してOpenShiftへデプロイする方法を紹介します。 必要な作業は以下の4つです。 Jakarta EE に対応 （今回は説明を省きます） Mavenの導入 Git対応 Helmの作成 Jakarta EEに対応 アプリケーションを Java EE から Jakarta EE に移行します。 JBoss EAP 8.0 は Jakarta EE 10 に対応しており、Java EE には対応していないためです。 本記事は、この移行が目的ではないため省略します。 この移行を支援するツールとして、Migration Toolkit があります。 Migration Toolkit は Red Hat が提供しているツールです。 Maven の導入 次に、アプリケーションのビルドのため Maven を導入します。 多くのアプリケーションはすでに導入しているでしょう。 しかしながら、一部のアプリケーションは Ant や独自の方法でビルドしているかもしれません。 今回は、最低限必要な Maven の設定を記載しています。 これから Maven を使う場合は、これをベースに依存関係を追加してください。 すでにMavenを使っている場合は、この設定を既存の設定に追加してください。 今回は、 Servlet/JSP を実行可能な、できるだけコンパクトな JBoss EAP をデプロイします。 JBoss EAP はアプリケーションが必要とする機能だけをもつコンパクトな JBoss EAP を作成できます。 この仕組みを Galleon と言います。 Galleon は各機能を Layer として定義しています。 Servlet/JSP を実行できる Layer は web-server です。 Layer は今回使用している web-server のほかにも、 ejb や jaxrs などさまざまあります。 他にどのような Layer があるのかは以下に記載されています。 第8章 JBoss EAP for OpenShift の機能のトリム | Red Hat Product Documentation また、Galleon 自体に興味のある方はこちらをごらん下さい。 Galleon Provisioning Guide 今回使用する pom.xml は以下のとおりです。 <project xmlns = "http://maven.apache.org/POM/4.0.0" xmlns : xsi = "http://www.w3.org/2001/XMLSchema-instance" xsi : schemaLocation = "http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd" > <modelVersion> 4.0.0 </modelVersion> <groupId> org.example </groupId> <artifactId> jee-traditional </artifactId> <packaging> war </packaging> <version> 1.0-SNAPSHOT </version> <profiles> <profile> <id> openshift </id> </profile> <profile> <id> develop </id> <activation> <activeByDefault> true </activeByDefault> </activation> </profile> </profiles> <dependencyManagement> <dependencies> <dependency> <groupId> org.jboss.bom </groupId> <artifactId> jboss-eap-ee </artifactId> <version> 8.0.0.GA-redhat-00009 </version> <type> pom </type> <scope> import </scope> </dependency> </dependencies> </dependencyManagement> <pluginRepositories> <pluginRepository> <id> jboss </id> <url> https://maven.repository.redhat.com/ga/ </url> <snapshots> <enabled> false </enabled> </snapshots> </pluginRepository> </pluginRepositories> <repositories> <repository> <id> jboss </id> <url> https://maven.repository.redhat.com/ga/ </url> <snapshots> <enabled> false </enabled> </snapshots> </repository> </repositories> <build> <finalName> ROOT.war </finalName> <plugins> <plugin> <groupId> org.apache.maven.plugins </groupId> <artifactId> maven-war-plugin </artifactId> <version> 3.4.0 </version> </plugin> <plugin> <groupId> org.jboss.eap.plugins </groupId> <artifactId> eap-maven-plugin </artifactId> <version> 1.0.0.Final-redhat-00014 </version> <configuration> <channels> <channel> <manifest> <groupId> org.jboss.eap.channels </groupId> <artifactId> eap-8.0 </artifactId> </manifest> </channel> </channels> <feature-packs> <feature-pack> <location> org.jboss.eap:wildfly-ee-galleon-pack </location> </feature-pack> <feature-pack> <location> org.jboss.eap.cloud:eap-cloud-galleon-pack </location> </feature-pack> </feature-packs> <layers> <layer> web-server </layer> </layers> <runtime-name> ROOT.war </runtime-name> </configuration> <executions> <execution> <goals> <goal> package </goal> </goals> </execution> </executions> </plugin> </plugins> </build> </project> Git 対応 アプリケーションは Git リポジトリで管理します。 OpenShift は後に指定する Git リポジトリからアプリケーションのソースコードを取得して、ビルドします。 Git リポジトリは OpenShift からアクセスできればどこでも大丈夫です。 今回は、GitHub 上のリポジトリを用います。 github.com Helm 対応 最後に、Helmチャートを使用して アプリケーションを含んだ JBoss EAP を作成します。 Helm は、CLI の helm コマンドを使うか、OpenShift のコンソール上で使用します。 OpenShiftのコンソールはこの図の 作成 から進み、HelmチャートはJBoss EAP 8を選択してください。 今回は、CLI ツールを用います。 各OSが提供しているパッケージマネージャで helm をインストールしましょう。 まずはHelmリリースの定義をYAMLで作成します。 このYAMLは helm.yaml とします。 ファイルの中身は以下のようにします。 build.uri には先ほどの Git の URL を指定します。 build : uri : https://github.com/chiroito/jee-traditional.git deploy : replicas : 1 あとは、 helm コマンドでOpenShiftにインストールするだけです。 今回は myapp という名前でインストールします。 oc project コマンドで自分の望んでいるプロジェクトに移動してから、実行しましょう。 > oc project home > helm install myapp -f helm.yaml jboss-eap/eap8 ここまでで全て完了しました。 OpenShift で確認 アプリケーションが OpenShift にデプロイされたかを確認します。 開発者向けの表示の Builds をクリックします。 Buildsに my-app-build-artifacts というBuildConfigsができているはずです。 最終実行のステータス が Complete になっていればビルドは成功です。 Running はまだビルドしています。 他のステータスになったら、実行を確認しましょう。 最終実行 のカラムにある myapp-build-artifacts-1 をクリックします。 ログのタブをクリックするとログが出力されます。 出力されたログから失敗した原因を確認しましょう。 ビルドが成功したら、アプリケーションがデプロイされています。 左側のメニューの トポロジー をクリックします。 ここに myapp というアイコンができているはずです。 これをクリックすると、右側に詳細が表示されます。 その詳細で、青色の丸の中に 1 Pod と表示されていればアプリケーションが起動しています。 0 Pod の場合はアプリケーションの起動がまだ終わっていないか、起動に失敗しています。 青丸の上のリソースタブを開き、Podsのログを表示して、失敗の原因を確認しましょう。 確認の最後として、アプリケーションへアクセスしてみましょう。 下のアイコンをクリックすると、アプリケーションへアクセスできます。 サンプルアプリケーションを使用している場合は、 index.jsp の Hello World! が表示されれば成功です。 いかがでしたでしょうか。 今回は、設定をかなり省略しています。 本番ではもう少しちゃんと設定が必要になります。 とはいえ、既存のアプリケーションをOpenShift上にデプロイする流れをイメージできたのではないでしょうか。

こんにちは。ソリューションアーキテクトの橋本です。 2024/06/30をもって、Red Hat Enterprise Linux 7(RHEL7)のEnd of Maintenance(Extend Lifecycle Support 通称ELS提供中)、及びCentOS 7がEnd of Lifeを迎えました。 一方で、次のRHELのメジャーリリースであるRHEL10の開発が着々と進行しています。RHEL8以降、RHELは3年に1度メジャーリリースを行うようになりまして、RHEL8は2019年、現在最新のRHEL9は2022年のリリースです。 RHEL10はおそらく、その3年後、つまり来年2025年にリリースされると想定されます。 そうなんです。もう来年はRHEL10の年(予定)なんです。早いですよね。来年の話をするのが早すぎますかね... CentOS Stream 10 さて、RHELの開発プロセスをよりオープンにするために、CentOS Streamが存在します。RHEL10の開発の状況も、ずいぶん前からCentOS Stream10としてソースコードが公開されています。 例えば、CentOS Stream 10で採用されるべく開発中のkernelのソースコードおよびrpm sources(spec, config, patches)はこちらにあります。 gitlab.com gitlab.com で、今日の本題です。先月、CentOSプロジェクトの開発者メーリングリストで、CentOS Stream 10のComposingの公開が始まったというアナウンスがありました。 現時点で、採用される各ソフトウェアおよびそのバージョンが確定しているわけではなく、ここからまだ追加、削除、変更が行われます。つまり、 誰でもRHEL10の開発に参加できるチャンスです(キラキラ) lists.centos.org ちなみに、この compose というのは、リリースそのものではありません。単語としては"docker compose"なんかでよく目にするかもしれません。composeは「まとめる」といった意味で、FedoraやCentOS Stream,RHELの文脈ではたいてい「distroとして構成するものの実体を作成する」ことを指します。 狭義にはいわゆる(kernel+)システムの/以下の実体構成そのものを作成することを指すと言えますが、それを構成するrpmパッケージのビルド、リポジトリの配置、そしてその実体を使用したインストーラーiso, VMやコンテナイメージの作成なども含めて指すこともよくあります。 また、これらのrpmパッケージはまだCentOSプロジェクトとしてのすべてのgatingプロセスをすべて通過しているわけではないようです。これはどんな状態かを想像するために、こちらの資料にある絵を紹介します。 CentOS StreamとRHELのgating https://archive.fosdem.org/2022/schedule/event/centos_stream_stable_and_continuous/attachments/slides/5182/export/events/attachments/centos_stream_stable_and_continuous/slides/5182/centos_stream_slides.pdf このような、CentOS Stream自身が持っているプロセスをまだちゃんと通ってないということなのだと思います。まずはいったんdistroとして形を為すための仕組みを整えることが目的で、個々のパッケージの扱いについてはまだまだやわらかい状態だというのがイメージしていただけるんじゃないかと思います。 CentOS Stream 10をダウンロードしてみる CentOS Stream 10のrpmパッケージやインストーラーiso, VMイメージは以下で公開されています。 composes.stream.centos.org コンテナイメージはquay.ioで公開中です。(stream10-developmentタグ) quay.io たとえば「どんなパッケージが採用されているのかなぁ」とか見てみたければ、podmanなどを使ってコンテナイメージで気軽にサクっと見てみるとよいでしょう。ちなみに、上述のようなGitLabソースコードリポジトリの最新の状態と、実際にcomposeされた内容にはタイムラグ、先程のGatingプロセスなどがあるため、時間差が生じます。 [desktop] podman run --rm quay.io/centos/centos:stream10-development dnf info -q rust Available Packages Name : rust Version : 1.77.2 Release : 3.el10 Architecture : x86_64 Size : 24 M Source : rust-1.77.2-3.el10.src.rpm Repository : appstream Summary : The Rust Programming Language URL : https://www.rust-lang.org License : (Apache-2.0 OR MIT) AND (Artistic-2.0 AND BSD-3-Clause AND ISC AND MIT AND MPL-2.0 AND Unicode-DFS-2016) Description : Rust is a systems programming language that runs blazingly fast, prevents : segfaults, and guarantees thread safety. : : This package includes the Rust compiler and documentation generator. 動かしてみよう では折角なのでVMを動かしてみようということで、GenericCloudイメージ(qcow2)を使ってどこのおうちにもあるOpenStackでインスタンスを起動してみました...が、起動してきません。ログを見てみました。 [ 2.052368] usb 1-1: new full-speed USB device number 2 using uhci_hcd [ 2.068196] Running certificate verification selftests [ 2.069918] Loaded X.509 cert 'Certificate verification self-testing key: f58703bb33ce1b73ee02eccdee5b8817518fe3db' [ 2.076422] Unstable clock detected, switching default tracing clock to "global" [ 2.076422] If you want to keep using the local clock, then add: [ 2.076422] "trace_clock=local" [ 2.076422] on the kernel command line [ 2.080929] clk: Disabling unused clocks [ 2.083695] Freeing unused decrypted memory: 2028K [ 2.086081] Freeing unused kernel image (initmem) memory: 4212K [ 2.087079] Write protecting the kernel read-only data: 30720k [ 2.088553] Freeing unused kernel image (rodata/data gap) memory: 1432K [ 2.129492] x86/mm: Checked W+X mappings: passed, no W+X pages found. [ 2.130518] x86/mm: Checking user space page tables [ 2.168892] x86/mm: Checked W+X mappings: passed, no W+X pages found. [ 2.169912] Run /init as init process Fatal glibc error: CPU does not support x86-64-v3 [ 2.171799] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00 [ 2.172677] CPU: 0 PID: 1 Comm: init Not tainted 6.8.0-0.rc3.20240209git1f719a2f3fa6.31.el10.x86_64 #1 [ 2.172677] Hardware name: Red Hat OpenStack Compute/RHEL, BIOS 1.15.0-1.el9 04/01/2014 [ 2.172677] Call Trace: [ 2.172677] <TASK> [ 2.172677] dump_stack_lvl+0x3c/0x50 [ 2.172677] panic+0x329/0x350 [ 2.172677] do_exit+0x4de/0x500 [ 2.172677] do_group_exit+0x2d/0x80 [ 2.172677] __x64_sys_exit_group+0x18/0x20 [ 2.172677] do_syscall_64+0x84/0x160 [ 2.172677] ? do_syscall_64+0x90/0x160 [ 2.172677] ? exc_page_fault+0x6b/0x150 [ 2.172677] ? entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 2.172677] </TASK> [ 2.172677] Kernel Offset: 0x1c000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) [ 2.172677] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00 ]--- 原因はこれです。 Fatal glibc error: CPU does not support x86-64-v3 既視感のある方もいらっしゃるかもしれません。glibcで策定しているCPUマイクロアーキテクチャレベル(glibc-hwcaps)のお話です。なんじゃそりゃ？という方はこちらの記事をご覧ください。 rheb.hatenablog.com RHEL9ではx86_64-v2マイクロアーキテクチャが前提ですが、RHEL10ではそれをもう一段進めて、x86_64-v3マイクロアーキテクチャを前提とすることになりました。もちろん、CentOS Stream 10もx86_64-v3マイクロアーキテクチャを前提にビルドされています。詳しくはこちらをご覧ください。2013年ごろ以降発表(IntelならHaswell世代以降)のCPUを採用したマシンであれば、条件を満たします。 developers.redhat.com もしこのあたりの活動に興味があれば、CentOS ISA SIGを覗いてみてください。 sigs.centos.org ということで、おうちのOpenStackが動いているマシンがIvy Bridge EP世代で、x86_64-v2マイクロアーキテクチャまでしかサポートしていないため、起動しないのでした。 いやー仕方ないですねー。これはマシンを買いかえる必要がありますねー。仕方ないです。いやーそんなつもりはなかったんだけど仕方ないからなー(検索するキーボードの軽やかな音) ...はいすみません。話を戻します。CentOS Stream 10のイメージはAmazon EC2用も公開されていますので、こちらをAMIとしてインポートして、AWSで動かしてみましょう。 Amazon EC2でのイメージインポート手順は、RHEL8のドキュメントにジェネラルなイメージアップロード、スナップショットからのAMI登録の手順がありますので、参考になると思います。 docs.redhat.com ちなみに、RHEL9ではcomposer-cli(image-builder)でのイメージビルド/アップロード手順に統一されていますので、RHEL10がリリースされたら、Image Builderでよりシンプルなイメージアップロード手順がドキュメントで出てくるんじゃないかと思います。 docs.redhat.com イメージは、ここにある"CentOS-Stream-ec2-10-20240627.0.x86_64.raw.xz"を展開したrawイメージを使用しています。s3へのアップロード前にxzコマンドなどで展開していないと正しく処理できないのでご注意ください。 composes.stream.centos.org ほぼ上記のドキュメント通りなのでざっくり書くと イメージアップロード用のs3 bucketの準備 (aws s3 mb) 必要なAWS IAMロールとポリシーの追加 (aws iam create-role/aws iam put-role-policy) イメージのs3 bucketへの転送 (aws s3 cp) s3 bucketに保存したイメージからEC2スナップショットへのインポート(aws ec2 import-snapshot) スナップショットからAMIへの登録(aws ec2 register-image) 作成したAMIからEC2インスタンスの起動 という感じです。sshでのログインはRHELと同じく ec2-user で行います。 所感もろもろ もちろんログインして普通のLinuxとして操作できます。パッケージがもりもり新しめのバージョンなので、操作するだけなら普通に新しめのLinuxです。 個人的には、動作環境はkernel 6.8, rust 1.77ですが、ソースコードリポジトリ上はもっとバージョンの高いカーネルで開発が行われているので、kernelのrustサポートとかどうなっていくのかなー、みたいなことを思いました。RHELのカーネルドライバをRustで書きたい、みたいな方がいたら早めに需要をissueにあげてもいいのかも。 ちなみに、Fedora EPEL SIGによるEL10向けの作業はこれからです。興味のある方はこのあたりをウォッチしてみるとおもしろいんじゃないかなと思います。 hackmd.io 定番のシステム情報を出そうと思ったのですが、EPELはこれからだったので、 macchina をCentOS Stream 10で提供されているRust 1.77.2でビルドしてみました。こんな感じです。 また、ちょっと弄っていて、RHEL7の途中から今まで提供されている、私がよく使っているストレージの圧縮と重複排除技術であるVDO(Virtual Data Optimizer)に関係するパッケージが存在しないことに気づきました。VDOはずっとout-of-treeのカーネルドライバだったのですが、kernel 6.9でめでたくLinusのツリーに マージ されたので、このへんが変わるだろうなぁ、と気になっていたのです。この変更に伴ってFedoraからout-of-treeのドライバを提供していたパッケージが削除されたけど、CentOS Streamのカーネルモジュールのパッケージ側にはまだ入ってないのでcomposingで漏れる、みたいな、ちぐはぐな状況になっているようです。すでにRHELのVDOのパッケージメンテナは把握していたようなので、そのうち修正されそうです。 CentOS Stream 10/RHEL10の開発に参加してみよう!! 先述した通り、今のCentOS Stream 10の開発フェーズはかなりやわらかい状態です。こういう状態こそ、自分の使っている環境との差異を見つけ、修正するチャンスです。 特に今のうちに注目したほうがいいと個人的に思うのは、ソフトウェアの個々の品質そのものよりも、「RHEL8/9でこのパッケージ使ってたのになくなってる!!」とか「このパッケージの中に含まれてたこのファイルがなくなってる!？」みたいな、パッケージングそのものについてのチェックをして報告してあげたほうが有益かな、と思います。開発者はたくさんのユーザーがどのパッケージをよく使ってるのか、とか、実際の運用を知る術が限られますし、パッケージングの変更で誰も意識していなかったファイルがリストから落ちたりすることもありえます。もちろんソフトウェア自身の問題を早く見つけてパッチを送ってあげたり、よりupstreamで修正されていることを報告してあげると、積極的にrebaseもできるのでとてもナイスです。自分の環境での問題を報告して直せるオープンな場があることはとてもいいことですね!! あと、先述の通りx86_64-v3マイクロアーキテクチャ対応のマシンが前提になりますので、たとえばお使いの仮想環境が対応した仮想マシンモデルタイプを提供しているか、実際に動作するか、といったチェックも今のうちにできることとしてよいのではないかと思います。 CentOS Projectへのコントリビューションについてはこのドキュメントを見るところから始めましょう。まずはissueを立てるところから。 docs.centos.org ということで、CentOS Stream 10をガンガンチェックして、ぜひ一緒にRHEL10を作っていきましょう!!

こんにちは。Red Hat ソリューションアーキテクトの清水です。RHEL7のELSも開始となり、RHELのライフサイクル管理の重要性に改めて認識された方も多いのではないでしょうか？さて、本ブログ記事では、RHELのパッチ適用をAnsibleとSatelliteを使って自動化する方法についてご紹介していきたいと思います。 実は、RHELのパッチ適用を含むライフサイクル管理と言うと、幾つかの製品が登場してきて使い方も様々ですので、ちょっとわかりにくかったりします。代表的な製品としては、以下のようなものが挙げられます。 Red Hat Insights Red Hat Satellite Red Hat Ansible Automation Platform (AAP) これらの組み合わせパターンとしては、大きく以下の4パターンあり、いずれもInsightsやSatelliteといった中央のマネジメントプレーンからパッチ適用をトリガーする、言わば「プッシュモデル」となります。 Insgiths → RHEL Insights → Cloud Connector (Satellite) → RHEL Insights → AAP → RHEL Ansible in Satellite → RHEL これから紹介していく方法は、 上記の「プッシュモデル」とは異なり 、Satelliteをリポジトリセットとして使い、 RHELのパッチ適用を「プルモデル」で行い 、関連する一連の作業を、例えば、事前のバックアップやパッチ適用後のテストなども含めて、AAPのワークフローによって自動化する、という方法になります。具体的なイメージがあった方が理解がしやすいと思いますので、以下のAWS上の環境を一例として説明をしていきたいと思います。 想定環境 ここでは、管理対象のRHELサーバとして、Development環境の managed-dev 、そしてProduction環境の managed-prod の2台があります（通常の環境では、もっと多数のサーバがあると思いますが、話をシンプルにするためにそれぞれ1台という想定にしています）。それぞれRHEL9で稼働しており、アプリケーションとしてWordPressと、そのDBとしてMySQLが稼働しています。そして、これらのRHELサーバのパッチを管理する機能として satellite01 、さらにAAPのControllerが稼働する aac01 があります。 どのように動くのか？ Satellite Satelliteでは、 Organization（組織） という論理グループを作成することで、1つのSatelliteシステムで複数の組織を管理することができます。ここでは、 My_Organization という組織を1つ作成しています。さらに、Satelliteでは、アプリケーションのライフサイクルの各ステージに対応する ライフサイクル環境 というものを定義します。 Library というのはスタートポイントとして必須になりますが、ここでは Development や Production という２つのライフサイクルを定義しています。これは、ユーザー環境によって自由に定義することができ、例えば、Dev/Staging/Productionや、もっと複雑なものも定義可能です。 そして、Satelliteには、 コンテンツビュー というSatelliteが管理対象ホストに配信するもの全般を指す概念があります。具体的には、ソフトウェアパッケージ、RPMやDockerイメージが含まれます。 最初にこのコンテンツビューを Library に置くことを Publish と言います。まず、Ver1.0を Library に Publish するところから始まり、さらにこのVer1.0のコンテンツビューを Development 環境に置くことを Promote と言います。つまり、次のライフサイクルのステージにPromote(昇進)させるもの、と考えると良いでしょう。 Development 環境でテストされたコンテンツビューは、最終的に Production 環境に Promote されます。ここでは、Ver1.0のコンテンツビューには、2023/7/31以前にリリースされた、Bugfix、Security Updates、Enhancementsが全て含まれます。この条件は、 Content View Filters と呼ばれ、もっと複雑な条件を設定することも可能です。上記の例では、 Errata のタイプと公開日付でフィルターしていますが、 RPM 、 Package Group 、 Container image tag 、 Module Streaｍ などでフィルターすることが可能です。 例えばこのコンテンツビューを月次で更新することを想定してみましょう。翌月になったら、2023/8/31までのBugfix、Security Updates、Enhancementsを含むVer2.0を Publish して、 Development 環境に Promote します。同様に、その翌月になったら、9月末までのコンテンツビューとしてVer3.0を Publish するという流れになります。 ここでは、管理対象のRHELサーバは、このSatelliteのライフサイクルにマッピングされます。従って、 Development 環境の managed-dev サーバは、Ver2.0の8月末までのコンテンツビューしか参照できないようになっており、また Production 環境の managed-prod サーバも同様にVer1.0の7月末までのコンテンツビューしか参照できないようになっています。さらに言えば、このVer1.0のコンテンツビューは、 Development 環境でテスト済みということになります。このようにそれぞれの管理対象サーバは、紐づいているライフサイクルのコンテンツビューを参照することで、限られたスコープのコンテンツビューでRHELのアップデート、つまりパッチ適用を「プルモデル」で行うことができるわけです。 例えば、Ver2.0(2023/8/31まで)のコンテンツビューを適用したサーバの適用可能なErrataを、Satelliteのコンソールから確認してみると、全て2023/9月以降のものになっていることがわかります。当該サーバでは、8月末までのErrataは全て適用済みということになります。 そして、この全体の流れを制御し、自動化するのがAnsible Automation Platform(AAP)です。 Ansible Automation Platform (AAP) Ansible Automation Platform(AAP)では、Workflow Jobという形で自動化されたそれぞれのJobを、ワークフロー形式で実行することができます。 こちらは、Development環境におけるパッチ適用のワークフローの例です。 最初に、コンテンツビューを Publish して、 Development 環境に Promote 、さらに管理対象VMである managed-dev サーバのバックアップを行い、 Update Dev VM でパッチを適用します。その後、VMをリスタートして、インフラレベルのテストを行い、最後に稼働しているWordPressのアプリケーションレベルのテストを行って終了です。 Job やっていること Content View Publish 構成したコンテンツビューの新バージョンをPublish Promote To Dev コンテンツビューをDevelopmentライフサイクル環境にPromote Backup Dev VM managed-vmのディスクのSnapshotを取得 Update Dev VM 構成されたコンテンツビューに従い全てのパッケージをUpdate Restart Dev VM managed-vmをリスタート Test Dev VM 再起動したmanaged-vmのインフラレベルのテスト Test Dev App 再起動したmanaged-vmのアプリレベルのテスト ちなみに、 Content View Publish や Promote To Dev のJobでは、Satelliteの操作を行うため、Playbook内で redhat.satellite のAnsible collectionを使って連携させることができます。 そして次に示すのは、 Devlopement 環境のパッチ適用後に流す、 Production 環境用のワークフローの例です。 Development 環境との相違点は、最初のところでコンテンツビューの Publish がなく、 Development 環境のパッチ適用がうまくいった前提でコンテンツビューを Production に Promote するところから始まる点で、それ以外のJobは同様の流れになっています。 まとめ ここでは、RHELのパッチ適用に関する一連の作業を、AAPとSatelliteを使って自動化する方法を、AWS上のRHEL環境を例にしてご紹介しました。最初に挙げた通り、Satelliteを使ったRHELのパッチ適用については、他にも幾つかの方法があり、例えば、Satelliteから管理対象サーバの特定のErrataやパッケージを「プッシュモデル」でアップデートすることもできます。この「プッシュモデル」の方法は、「緊急パッチの適用」といった、どちらかと言うとセキュリティユースケースで使われる場合が多いようです。このあたりは、ユースケースに応じて適切な方法を見極めていく必要があります。いずれにせよ、RHELのパッチ適用の自動化については、やり方がわかってしまえば、実はそんなに難しいものでもありません。これを機に、RHELのライフサイクル管理を自動化することを考えてみてはいかがでしょうか。 ちなみに、ここで説明したサンプルは、以下のGithubリポジトリから取得して、簡単に再現することが可能です。興味を持たれた方は、ぜひCloneしてトライしてみてください。 https://github.com/yukshimizu/managing-rhel-lifecycle-setup https://github.com/yukshimizu/managing-rhel-lifecycle-demo

Red Hatでソリューションアーキテクトをしている田中司恩( @tnk4on )です。 この連載はvSphere環境上にOpenShift Container Platform（以下、OpenShift）およびOpenShift Virtualizationの環境を構築する方法を解説するシリーズです。 可能な限り最小構成での検証環境の構築を目指し、1台のESXi上にOpenShiftをインストールしてネスト仮想環境でOpenShift Virtualizationを実行する方法を解説します。 また環境の構築後はvSphere上の仮想マシンを移行ツール（Migration Toolkit for Virtualization）を使ってOpenShift Virtualization上へ移行することもできます。 初回の本記事では、OpenShiftのインストールについて解説します。 今後の連載予定は下記の通りです。 第1回：OpenShiftのインストール （←本記事） 第2回：OpenShiftインストール後の作業 第3回：共有ストレージの作成（NFS CSIドライバーの構築） 第4回：OpenShift Virtualizationのインストールと実行 第5回：vSphere仮想マシンの移行 【番外編】：共有ストレージの作成（NFSプロビジョナーの構築） （2024/7/8追記：踏み台サーバー自身のDNSサーバー設定変更に手順を追加しました） （2024/7/24追記：第3回の内容を改訂し、元の内容を番外編に変更しました） （2024/9/30追記：必要なDNSレコード表内の、ESXiホストのDNSレコードの表記を修正しました） （2024/10/2追記：VM作成時のgovcコマンドに、データストアを指定するオプションを追加しました） -目次- OpenShiftインストール作業の概要 前提条件 全体概要 構成図 OpenShiftインストール時の構成 OpenShiftインストール完了後の構成 OpenShiftの構成（3ノードクラスター） ネットワーク要件 基本要件 ネットワーク設計 パラメーターシート ネットワーク情報 ホスト情報 ドメイン、クラスター名 必要なDNSレコード ESXiホストの情報 1. 事前作業 1-1 Red Hatアカウントの作成 1-2 OpenShiftの評価版の申請 1-3 RHELインストールイメージのダウンロード 1-4 SSHキーペアの作成 2. 踏み台サーバーの構築 2-1 SSH公開鍵のコピー 2-2 作業ディレクトリの作成 2-3 パッケージのインストール 2-4 その他ツール類のインストール (1) OpenShift CLI（oc）のインストール (2) govcのインストール 2-5 dnsmasqの設定 (1) dnsmasq.confのバックアップ (2) dnsmasq.confの作成 (3) dnsmasqのサービスを自動起動に登録 (4) ファイアーウォールのポート解放 (5) 踏み台サーバー自身のDNSサーバー設定変更 (6) DNSのテスト 3. ISOファイルの作成 3-1 クラスターの新規作成 (1) Cluster details (2) Static network configurations (3) Operators (4) Host discovery 4. OpenShiftノード用仮想マシンの作成 4-1 ISOファイルのアップロード 4-2 仮想マシンの作成 4-3 仮想マシンの起動 5. OpenShiftインストールの実行 5-1 Storage 5-2 Networking 5-3 Review and create 5-4 インストールのモニタリング 5-5 インストールの完了 まとめ OpenShiftインストール作業の概要 全体の作業の流れは下記の通りです。 事前作業 踏み台サーバーの構築 ISOファイルの作成 OpenShiftノード用仮想マシンの作成 インストールの実行 本記事のゴールは下記の通りです。 OpenShiftのインストールが完了し、Webコンソールを使って管理画面にアクセスできること 本記事では Assisted Installer を使用してOpenShiftのインストールを行います。Assisted Installerのインストール部分は下記ドキュメントをベースとします。それ以外の事前作業や踏み台サーバーの構築は本記事のオリジナルです。 Assisted Installer を使用した OpenShift Container Platform のインストール | Red Hat Product Documentation 本記事は普段からvSphereやESXiの操作に慣れ親しんでいる方には抵抗感なくOpenShiftのインストール作業を行えるように、できるだけ詳細に作業内容を記述しています。また作業内容は繰り返す作業を除いて自動化は行わず、各作業をステップバイステップで進められるように記述しています。最初から最後まで手順通りに進めていただければインストールに失敗することはほとんどないはずです。 インストールの再現性を重視し、踏み台サーバーのOSにはRed Hat Enterprise Linux(以下、RHEL) を採用しています。他に使い慣れたOSなどがあればそちらで代用頂いても構いません。 インストールにかかる作業時間は、事前作業からインストールの完了まで2時間あれば十分でしょう（ISOファイルのダウンロード待ち時間を除く）。 前提条件 下記の環境をご準備ください。 vSphere環境 ESXi：ライセンス適用済みのものを推奨。vSphere Hypervisor（いわゆる無償版ESXi）ではgovcの実行ができなかったり、vSphereからOpenShift Virtualizationへ仮想マシンの移行が行えません。 vCenter Server：オプションです。ESXi単体でも問題ありません。 ESXiホストはESX 7.0以上、x86_64アーキテクチャーであること。物理8コア以上推奨（またはHT有効で合計8論理プロセッサー以上）。合計96GB RAMのOpenShiftノードの仮想マシンを実行できること（1台のESXiで構成する場合は128GB RAM以上推奨）。ストレージはPCIe Gen3以上のNVMe SSD相当の性能は必須です。 vSphere操作用アカウント ESXi単体の場合：rootユーザー vCenter Serverの場合：vCenter SSO管理者の権限で操作するのが構築時における余計なトラブルを防ぐのに有効ですが、vCenter SSO管理者を利用するのが難しい場合は下記のドキュメントを参照し、適切な権限を割り当てた作業ユーザーを作成してください。 23.2. installer-provisioned infrastructure | Red Hat Product Documentation 作業用端末 普段利用のmacOSやWindowsなど。Linuxでも可。 SSHコマンドが実行できること：踏み台サーバーへリモート接続に使用します ウェブブラウザが実行できること：OpenShiftのWebコンソールの接続に使用します。Firefox、MS Edge、Chrome、Safariがサポートされています。 *1 本連載は検証環境の構築を目的とし実稼働環境でサポートされない構成を含みます。 OpenShift Virtualizationのサポート対象はベアメタルサーバーです。ネスト仮想マシン上での実行はサポートされません。 *2 VMware ESXi上でサードパーティのハイパーバイザーの実行はサポートされていません *3 下記内容は本連載の対象外とします。 Multusを使ったマルチネットワークの構成 インターネット非接続環境でのOpenShiftのインストール構成 全体概要 構成図 OpenShiftインストール時の構成 Red HatがホストするクラウドサービスであるAssisted Installerを使用してOpenShiftのインストールを行います。 OpenShiftインストール時の構成 OpenShiftインストール完了後の構成 インストール完了後は作業用端末からWebコンソールを使用してOpenShiftに接続します。 OpenShiftインストール完了後の構成 OpenShiftの構成（3ノードクラスター） クラスタの可用性を持ちつつ最小のノード数で構成できる 3ノードクラスター を採用します。3ノードクラスターは1台のノードでコントロールプレーンとコンピュートの2つの役割を持ち、最小の3台のノードのみでOpenShiftを構成する方法です。3ノードクラスターはOpenShift v4.5からサポートされています。 1.2. 新機能および機能拡張 | Red Hat Product Documentation なお、OpenShift Virtualizationの仮想マシンをホスト間で移動する ライブマイグレーション を使用する場合は、インストール時点で3台以上のコンピュートノードで構成してインストールする必要があります （ドキュメントより抜粋）ライブマイグレーション機能を使用する場合は、クラスターのインストール時に 複数のワーカーノードが必要です。これは、ライブマイグレーションではクラスターレベルの高可用性 (HA) フラグを true に設定する必要があるためです。HA フラグは、クラスターのインストール時に設定され、後で変更することはできません。クラスターのインストール時に定義されたワーカーノードが 2 つ未満の場合、クラスターの存続期間中、HA フラグは false に設定されます。 *4 ネットワーク要件 ネットワーク構成図 API VIPとIngress VIPはVRRPを使用した仮想IPアドレスです。OpenShiftノード内部で実行する Keepalived によって構成されます。 基本要件 OpenShiftおよび、その他すべての機器からインターネット接続できることが推奨です。プロキシ経由での接続でも問題ありません。 インターネットの出口のファイアーウォールにポートを通す必要がある場合は、下記のドキュメントを参照してください。 25.2. ファイアウォールの設定 | Red Hat Product Documentation OpenShiftクラスターのコンポーネント間の通信も阻害することなく通信が行えるようにしてください。通信に使用されるポートの情報は下記のドキュメントを参照してください。 第25章 任意のプラットフォームへのインストール | Red Hat Product Documentation ネットワーク設計 下記の3つのネットワークを使用してOpenShiftの構成を行います。 マシンネットワーク：クラスタ内のノードが接続される物理または仮想のネットワーク サービスネットワーク：クラスタ内で動作するサービスが使用する仮想ネットワーク クラスターネットワーク：OpenShiftクラスタ内のすべてのポッドが通信するための仮想ネットワーク パラメーターシート ネットワーク情報 ネットワーク名 ネットワークアドレス サブネットマスク デフォルトゲートウェイ 備考 マシンネットワーク 192.168.1.0 24 192.168.1.1 ローカルのネットワーク クラスターネットワーク 10.128.0.0 14 192.168.1.1 OpenShiftがデフォルトで作成 サービスネットワーク 172.30.0.0 16 192.168.1.1 OpenShiftがデフォルトで作成 ホスト情報 項目 ホスト名 IPアドレス 備考 OpenShift ノード1 node-01 192.168.1.201 OpenShift ノード2 node-02 192.168.1.202 OpenShift ノード3 node-03 192.168.1.203 Kubernetes API Kubernetes API（内部クラスター通信） api api-int 192.168.1.204 API 通信に使用する VIP Ingress IP apps 192.168.1.205 外部からのアプリケーショントラフィック通信に使用するVIP 踏み台サーバー bastion 192.168.1.206 ESXiホスト esxi 192.168.1.100 ドメイン、クラスター名 項目 内容 設定値 ドメイン <base_domain> home.lab クラスター名 <cluster_name> ocp 必要なDNSレコード 項目 内容 設定値 Kubernetes API api.<cluster_name>. <base_domain> api.ocp.home.lab Kubernetes API（内部クラスター通信） api-int.<cluster_name>. <base_domain> api-int.ocp.home.lab アプリケーションIngressトラフィック *.apps.<cluster_name>. <base_domain> *.apps.ocp.home.lab OpenShift ノード1 <host_name>. <cluster_name>. <base_domain> node-01.ocp.home.lab OpenShift ノード2 <host_name>. <cluster_name>. <base_domain> node-02.ocp.home.lab OpenShift ノード3 <host_name>. <cluster_name>. <base_domain> node-03.ocp.home.lab ESXiホスト <host_name>. <base_domain> esxi.home.lab PTRレコードは、OpenShiftノード、Kubernetes API（内部クラスター通信も含む）に登録が必要です。 ESXiホストの情報 本記事執筆時に使用したESXiホストのスペック情報です。構成の参考にしてください。 項目 内容 備考 CPU Core i7-9700 RAM 128GB SSD Samsung 970 EVO Plus 1TB PCIe Gen3 NVMe接続 1. 事前作業 事前作業として下記の作業を行います。 Red Hatアカウントの作成 OpenShiftの評価版の申請 RHELインストールイメージのダウンロード SSHキーの作成 1-1 Red Hatアカウントの作成 OpenShiftの評価版の申請やRHELのインストールイメージをダウンロードするために Red Hatアカウント が必要です。Red Hatアカウントは Red Hatのカスタマーポータル から無料で作成可能です。 Red Hatカスタマーポータル 1-2 OpenShiftの評価版の申請 OpenShiftは60日間のセルフサポートの評価版が利用いただけます。下記の製品トライアルのサイトにアクセスし「無料トライアルを利用する」を押します。 Red Hatアカウントでログインし「製品トライアルを開始されました。」と表示されたら評価版の申請は完了です。 Red Hat OpenShift Container Platform | 製品トライアル OpenShift Container Platformの評価版申請 OpenShiftの評価版の申請サイトには下記の記載があります。 同製品の利用可能なすべてのバージョンの 32 コア (64 vCPU) のエンタイトルメント ここで記載されている32コアとはOpenShiftを実行するホスト上の 物理コア をカウントします *5 。 本記事では1台のESXiホスト（8コア）で実行しますのでこの制限には引っかかりません。たとえば複数のESXiホストで実行する場合や、物理サーバーでOpenShiftノードを実行する場合は合計で32コアの上限を超えないようにご注意ください。 1-3 RHELインストールイメージのダウンロード 踏み台サーバーのOSにRHEL 9を使用します。OpenShiftと同じくRHELも評価版はありますが、Red Hatアカウント1つに付きRHEL×1台が60日間の使用上の制限となります。個人での利用なら Red Hat Develper に登録すれば無償で16台までRHELが利用できます。この際に合わせてご登録のうえ無償版のRHELをご利用ください。 Red Hat Enterprise Linux Overview | Red Hat Developer なお、この無償でRHELを利用できる Red Hat Developer Subscription for Individuals についての詳細は下記FAQを参照ください。 No-cost Red Hat Enterprise Linux Individual Developer Subscription: FAQs | Red Hat Developer Red HatカスタマーポータルでRHELのインストールイメージのダウンロード 1-4 SSHキーペアの作成 下記を参考に作業用端末でSSHキーペアを作成します。OpenSSHがインストールされている最近のOS環境であればWindows、macOS、Linuxでコマンドは共通です。 ssh-keygen -t ed25519 保存先はデフォルトで ~/.ssh/id_ed25519 です パスフレーズは 無し で作成します 下記の2つの鍵ファイルが作成されていることを確認します。 id_ed25519：秘密鍵 id_ed25519.pub：公開鍵 （作業用端末で実行） % ls -d ~/.ssh/id_ed25519* /Users/your-username/.ssh/id_ed25519 /Users/your-username/.ssh/id_ed25519.pub 2. 踏み台サーバーの構築 踏み台サーバーはOpenShiftインストール時の各種作業を行ったり、DNSサーバーおよびNFSサーバーを実行するサーバーです。今回はOSにRHEL 9を使用しDNSサーバーにはdnsmasqを使用します。既存のDNSサーバーがある場合はそちらを流用いただいても問題ありません。またその他のコマンドとして下記を使用します。 OpenShift CLI（oc） govc Podman Skopeo wget（httpd-toolsに含む） dig（bind-utilsに含む） helm（連載第3回でインストールします） 踏み台サーバーはvSphere上の仮想マシンとして作成します。下記はサンプルの仮想マシン構成です。CPU、Memoryは使用環境に合わせて調整ください。 <踏み台サーバーの仮想マシン設定> 項目 内容 備考 Guest OS Linux Guest OS Version Red Hat Enterprise Linux 9 (64bit) RHEL 9.4 CPU 1 vCPU Memory 4GB Hard disk 1 100GB Thin provisioned 有効、OS領域 Hard disk 2 500GB Thin provisioned 有効、NFSエクスポート領域。連載第3回以降で使用します。 SCSI Controller 0 VMware Paravirtual Network Adapter Type VMXNET 3 仮想マシンの互換性 仮想HW v15以上 ゲストOSにRHEL 9を使用するため 事前作業で入手したRHELのインストールイメージを使用してOSのインストールを行います。RHELのインストールは最小構成で問題ありません。ただし、OSのインストール時に一般ユーザーを管理者として作成します（sudoを利用するため）。本記事ではユーザー名： user を使用します。 2-1 SSH公開鍵のコピー OSのインストール後、作業用端末からSSH公開鍵をコピーしてパスワードを入力すること無く作業用端末から踏み台サーバーにSSH接続できる設定を行います。 （作業用端末で実行） % ssh-copy-id user@192.168.1.206 フィンガープリントの登録を行い、パスワードを入力するとSSH公開鍵が踏み台サーバーに登録されます。 （踏み台サーバー上で実行。公開鍵がauthorized_keysとして登録される） [user@bastion ~]$ ls -d ~/.ssh/authorized_keys /home/user/.ssh/authorized_keys SSHコンフィグファイル（ ~/.ssh/config ）にホスト情報を登録し、簡単なコマンドで踏み台サーバーに接続できる設定を行います。 vi コマンドなどでファイルに下記の内容を追記してください。 （作業用端末で実行） % vi ~/.ssh/config Host bastion HostName 192.168.1.206 User user 踏み台サーバーにSSH接続する際は ssh bastion と入力するだけで接続できます。 （作業用端末で実行） % ssh bastion [user@bastion ~]$ 以後は踏み台サーバーのシェルプロンプトは $ のみで記載します。 踏み台サーバーからOpenShiftノードへSSH接続する場合は SSHエージェント転送 を利用します。 作業用端末で ssh-agent コマンドを実行しSSHエージェントにSSH秘密鍵を登録します。 （作業用端末で実行） % eval "$(ssh-agent -s)" % ssh-add ~/.ssh/id_ed25519 登録したSSH秘密鍵がリストに表示されることを確認します。 （作業用端末で実行） % ssh-add -l 作業用端末から踏み台サーバーへSSHエージェント転送を有効にして接続するには -A オプションを使用します。 （作業用端末で実行） % ssh -A bastion 2-2 作業ディレクトリの作成 作業用のディレクトリを作成し、そこへ移動します。 $ mkdir $HOME/work $ cd $HOME/work 以降の作業で作成したファイル類はこの作業ディレクトリに配置することとします。 2-3 パッケージのインストール サブスクリプションの登録がまだ行われていない場合は subscription-manager コマンドを使ってRHELシステムを登録します。なお、Simple Content Access（SCA）が無効の場合はサブスクリプションのアタッチが必要です。SCAが有効の場合はサブスクリプションのアタッチは不要です。 Simple Content Access - Red Hat Customer Portal SCA無効の場合の例 $ sudo subscription-manager register --auto-attach SCA有効の場合の例 $ sudo subscription-manager register SCA無効/有効、どちらの場合もユーザー名とパスワードを入力して登録を完了します。 RHELシステムのサブスクライブが完了すれば、パッケージマネージャーで追加するツール類をインストールします。 $ sudo dnf install bash-completion dnsmasq podman skopeo bind-utils httpd-tools nfs-utils wget -y インストールが完了したら、 bash-completion を有効化します $ exec bash コマンドに続けてTABキーを押し、コマンド補完が有効になっていることを確認します。 $ podman (<--スペースに続けてTABキーを押す) attach (Attach to a running container) mount (Mount a working container's root filesystem) auto-update (Auto update containers according to their auto-update policy) network (Manage networks) ... 2-4 その他ツール類のインストール パッケージマネージャーで追加できないツール類を手動でインストールします。 (1) OpenShift CLI（oc）のインストール OpenShift CLI（以下、ocコマンド）はOpenShiftの各種操作をCLIで行うツールです。 ocコマンドのGUIでの入手方法は製品ドキュメント *6 に記載があります。 Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。 Product Variant ドロップダウンリストからアーキテクチャーを選択します。 バージョン ドロップダウンリストから適切なバージョンを選択します。 OpenShift v4.XX Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。 GUIを使わず、CLIでocコマンドを直接インストールする場合は下記のコマンドを実行します。 （x86_64アーキテクチャーのLinuxサーバー上で実行する場合の例） $ curl -L -o - "https://mirror.openshift.com/pub/openshift-v4/$(uname -m)/clients/ocp/latest/openshift-client-linux.tar.gz" | sudo tar -C /usr/local/bin -xvzf - oc ocコマンドが実行できることを確認します。 $ oc version Client Version: 4.16.0 Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3 ocコマンドの自動補完を有効化します。 $ oc completion bash > oc_bash_completion $ sudo cp oc_bash_completion /etc/bash_completion.d/ $ exec bash $ oc (<--スペースに続けてTABキーを押す) adm (Tools for managing a cluster) login (Log in to a server) annotate (リソースのアノテーションを更新する) logout (End the current server session) ... (2) govcのインストール govcコマンドはGo言語で実装されたvSphere環境を管理するためのOSSのコマンドラインツールです。GUIのみで作業を行うのであれば導入は不要です（無償版のvSphere Hypervisorを使う場合など）。 なお、govcコマンドはRed Hatがサポートするツールではありません。 govmomi/govc/README.md at main · vmware/govmomi · GitHub GitHubの手順を参考にインストールします。 $ curl -L -o - "https://github.com/vmware/govmomi/releases/latest/download/govc_$(uname -s)_$(uname -m).tar.gz" | sudo tar -C /usr/local/bin -xvzf - govc 下記を実行し、govcコマンドのコマンド補完を有効化します $ sudo curl -L https://raw.githubusercontent.com/vmware/govmomi/master/scripts/govc_bash_completion -o /etc/bash_completion.d/govc $ exec bash $ govc (<--スペースに続けてTABキーを押す) Display all 414 possibilities? (y or n) govcコマンドを実行するにはGOVC環境変数を設定する必要があります。手動で毎回セットする代わりに下記のファイルを作成し source で読み込む方法を行います。慣れている方は.bashrcなどに設定する方法でも構いません。 GOVC環境変数をセットする govc_env を作成します。 $ cat > govc_env <<EOF export GOVC_URL=https://192.168.1.100 export GOVC_USERNAME=root export GOVC_PASSWORD=your-password export GOVC_INSECURE=true EOF GOVC_URL 、 GOVC_USERNAME はvCenter ServerまたはESXiに接続するものを指定します パスワードは平文でファイル上に保存されます。気になる方はgovc_envファイルから GOVC_PASSWORD の行を削除し、 export GOVC_PASSWORD を手動で実行するようにしてください。 GOVC_INSECURE=true は自己証明書を使っている環境でSSL 証明書の検証が無効化します source govc_env を実行し、現在のシェルセッションにGOVC環境変数を設定します。 $ source govc_env govc env コマンドでGOVC環境変数がセットされているか確認します。 $ govc env GOVC_USERNAME=root GOVC_PASSWORD=your-password GOVC_URL=192.168.1.100 GOVC_INSECURE=true govcコマンドの接続テストを行います。 govc find コマンドを実行しリソース情報が取得できることを確認します。 $ govc find / / /ha-datacenter /ha-datacenter/vm /ha-datacenter/host /ha-datacenter/datastore /ha-datacenter/network /ha-datacenter/network/VM Network /ha-datacenter/datastore/NVMe /ha-datacenter/host/esxi.home.lab /ha-datacenter/host/esxi.home.lab/Resources /ha-datacenter/host/esxi.home.lab/esxi.home.lab ... 2-5 dnsmasqの設定 (1) dnsmasq.confのバックアップ デフォルトのファイルをバックアップします。 $ sudo mv /etc/dnsmasq.conf /etc/dnsmasq.conf.bak (2) dnsmasq.confの作成 新規でdnsmasq.confを作成します $ sudo vi /etc/dnsmasq.conf 利用する環境に合わせてドメイン名、ホスト名、IPアドレスを修正します。 （dnsmasq.confの例） user=root port= 53 expand-hosts log-queries log-facility=- local=/home.lab/ domain=home.lab rev-server=192.168.1.0/24,127.0.0.1 server=192.168.1.253 server=192.168.1.1 address=/esxi.home.lab/192.168.1.100 address=/node-01.ocp.home.lab/192.168.1.201 ptr-record=201.1.168.192.in-addr.arpa,node-01.ocp.home.lab address=/node-02.ocp.home.lab/192.168.1.202 ptr-record=202.1.168.192.in-addr.arpa,node-02.ocp.home.lab address=/node-03.ocp.home.lab/192.168.1.203 ptr-record=203.1.168.192.in-addr.arpa,node-03.ocp.home.lab address=/api.ocp.home.lab/192.168.1.204 ptr-record=204.1.168.192.in-addr.arpa,api.ocp.home.lab address=/api-int.ocp.home.lab/192.168.1.204 ptr-record=204.1.168.192.in-addr.arpa,api-int.ocp.home.lab address=/apps.ocp.home.lab/192.168.1.205 log-queries と log-facility ：デバッグ目的でログファイル（デフォルトは /var/log/messages ）にクエリログを出力します。不要であれば削除可能です。 ptr-record ：OpenShiftノードには逆引き設定が必要です。これがないとインストールが正常に完了しません。 *7 rev-server ：逆引きを行うDNSサーバーは自分自身(127.0.0.1)を指定します。 server ：踏み台サーバーの上位のDNSサーバーを指定します。複数指定する場合は server を複数行記述します。 (3) dnsmasqのサービスを自動起動に登録 dnsmasqのサービスを自動起動サービスに登録し、同時に起動します。 $ sudo systemctl enable dnsmasq.service --now systemctl status コマンドを実行し、dnsmasqが正常に起動していることを確認します。 $ sudo systemctl status dnsmasq.service ● dnsmasq.service - DNS caching server. Loaded: loaded (/usr/lib/systemd/system/dnsmasq.service; enabled; preset: disabled) Active: active (running) since Mon 2024-07-01 02:08:14 JST; 28s ago ... (4) ファイアーウォールのポート解放 踏み台サーバー以外から接続を許可するためにファイアーウォールのポートを開放します。 $ sudo firewall-cmd --add-port=53/udp --permanent $ sudo firewall-cmd --reload 指定したポートが正常に登録されているか確認します。 $ sudo firewall-cmd --list-all | grep 53 ports: 53/udp (5) 踏み台サーバー自身のDNSサーバー設定変更 踏み台サーバー自身のDNSサーバーの設定を自分自身に変更します。合わせて検索ドメインリストに（ ocp.home.lab ）も追加します。 Network Managerを使用する場合とNetWork Managerを無効化して直接 /etc/resolv.conf を直接書き換える手順のどちらかを利用ください。 Network Managerを使用する場合 nmcli con show コマンドでネットワーク接続名を確認します。 $ nmcli -t -f NAME connection show ens34 lo DNSサーバーの変更と検索ドメインリストの追加を行います。 $ sudo nmcli con modify ens34 ipv4.dns 127.0.0.1 $ sudo nmcli con modify ens34 ipv4.dns-search home.lab,ocp.home.lab ネットワーク接続を再起動して設定を反映します。 $ sudo nmcli con down ens34; sudo nmcli con up ens34 NetWork Managerを無効化する場合 NetWork Managerを無効化して、 /etc/resolv.conf を直接書き換えます。 NetWork Managerの設定ファイルである NetworkManager.conf を編集し、mainセクションに dns=non を追加します。 $ sudo vi /etc/NetworkManager/NetworkManager.conf [main] dns=none NetWork Managerを再起動します。 $ sudo systemctl restart NetworkManager /etc/resolv.conf ファイルを編集します。 $ sudo vi /etc/resolv.conf nameserver 127.0.0.1 search home.lab ocp.home.lab (6) DNSのテスト 正引きと逆引きのテストを行います。登録したDNSレコードが踏み台サーバーおよび踏み台サーバー以外から正常に名前解決できるか確認します。 （正引きの例） % dig @192.168.1.206 +short api.ocp.home.lab 192.168.1.204 （逆引きの例） % dig @192.168.1.206 +short -x 192.168.1.201 node-01.ocp.home.lab. 3. ISOファイルの作成 ここからがインストール作業の本番開始です。作業用端末のブラウザを使ったGUIでの操作がメインです。 3-1 クラスターの新規作成 Red Hat Hybrid Cloud コンソール にログインし、下記のOpenShiftのクラスター作成画面に移動します。 Create an OpenShift cluster | Red Hat OpenShift Cluster Manager 「Datacenter」タブへ切り替え、「Create cluster」を押します。 新しいクラスターの作成 (1) Cluster details クラスターの詳細情報を入力します。下記のパラメーターを入力し「Next」を押します。 項目 設定 説明 Cluster name ocp Base domain home.lab OpenShift version OpenShift 4.16.0 2024/7/1現在のデフォルト CPU architecture x86_64 Install single node OpenShift(SNO) チェック無し Edit pull secret チェック無し Integrate with external partner platforms No platform integration Include custom manifests チェック無し Host's network configuration Static IP,bridges and bonds OpenShiftノードに固定IPアドレスをセットするため Encryption of installation disks 「Control plane nodes」「Workers」 無効 Cluster details (2) Static network configurations ネットワークの設定情報を入力します。 下記のパラメーターを入力後、「Next」を押します。 項目 設定値 説明 Configure via Form view Networking stack type IPv4 Use VLAN チェック無し DNS 192.168.1.206 2つ以上指定する場合はカンマ区切り Machine network 192.168.1.0/24 Default gateway 192.168.1.1 Static network configurations(1/2) 次の画面でOpenShiftノードのMACアドレスとIPアドレスを入力します。 1台目のホストを入力後、「Add another host configration」を押すと次のホストの入力ができるようになります。 下記のパラメーターを入力後、「Next」を押します。 ホスト MACアドレス IPアドレス Host1 00:50:56:00:00:01 192.168.1.201 Host2 00:50:56:00:00:02 192.168.1.202 Host3 00:50:56:00:00:03 192.168.1.203 指定された仮想マシンを利用する場合や物理サーバーを使用する場合は、事前にMACアドレスを確認のうえ入力してください Static network configurations(2/2) (3) Operators Operatorはクラスター導入後に追加できます。連載第4回でOpenShift Virtualizationのインストール時に実施します。 ここでは何も選択せず、「Next」を押します。 Operators (4) Host discovery ここではインストールに必要な設定が入力済みの Discovery ISO ファイルを作成し、ダウンロードします。 「Add host」を選択します。 Discovery ISO はドキュメントでは検出ISO、検出イメージなどど呼ばれますが、以降は単にISOファイルと呼びます。 このISOファイルを使ってOpenShiftノードの起動を行いますが、インストールに必要なファイルはインターネットからダウンロードを行います。 そのためこのISOファイルは一般的なインストーラーとは違い、インストールに必要最低限の情報が入った起動イメージになります。 Host discovery Add host 下記のパラメーターを入力後、「Generate Discovery ISO」を押します。 項目 設定値 説明 Provisioning type Full image file デフォルトはMinimalですが各ノードが個別にダウンロードを行う作業をスキップするためにFullを使用します SSH public key <YOUR KEY> 事前に作成済みのSSH公開鍵を入力します Configure cluster-wide proxy settings チェック無し Configure cluster-wide trusted certificates チェック無し Full image fileを選択し、ISOファイルを作成する Proxy導入済みの環境でインストールを行う場合は「Configure cluster-wide proxy settings」にチェックを入れ、ProxyのURLを設定してください ブラウザ用のダウンロードボタンが表示されますが、踏み台サーバーでダウンロードを行うのでCLIダウンロード用のコマンドをコピーします。 CLIダウンロード用のコマンドをコピーする 踏み台サーバーにコマンドをペーストしてISOファイルのダウンロードを実行します。 $ wget -O discovery_image_ocp.iso 'https://api.openshift.com/api/assisted-images/bytoken/..../full.iso' タイミングによってはダウンロードに30分以上かかる場合があるので、時間に余裕を持って作業を行いましょう ISOファイルのダウンロードが完了したら次の作業に移ります。 4. OpenShiftノード用仮想マシンの作成 ESXi上にOpenShiftノード用の仮想マシンを作成します。3ノード構成のためMACアドレスを除き、同じパラメーターで3台の仮想マシンを作成します。 <OpenShiftノード用仮想マシンの設定> 項目 内容 備考 Guest OS Linux Guest OS Version Red Hat Enterprise Linux 9 (64bit) 実際に稼働するOSはRed Hat Enterprise Linux CoreOS（RHCOS）です CPU 8 vCPU Memory 32GB Hard disk 1 100GB Thin provisioned 有効 SCSI Controller 0 VMware Paravirtual Network Adapter Type VMXNET 3 CD/DVD drive 1 discovery_image_ocp.iso 後ほどホストにアップロード Hardware virtualization Enable disk.enableUUID TRUE 仮想マシンの互換性 仮想HW v15以上 VMware Compatibility GuideのRHEL 9ゲストの情報を参照 *8 ホスト名 MACアドレス node-01 00:50:56:00:00:01 node-02 00:50:56:00:00:02 node-03 00:50:56:00:00:03 4-1 ISOファイルのアップロード GUIまたはCLIでESXi上へISOファイルをアップロードします。 govcコマンドを使う場合は下記のコマンドを実行してISOファイルをアップロードします。 （データストア名：NVMe、ISOファイル名：discovery_image_ocp.iso の例） $ govc datastore.upload \ -ds NVMe \ ./discovery_image_ocp.iso \ discovery_image_ocp.iso 4-2 仮想マシンの作成 GUIまたはCLIで仮想マシンの作成を行います。 govcコマンドを使う場合は下記のコマンドを実行して仮想マシンの作成を行います。 $ for node in node-01 node-02 node-03; do case $node in node-01) MAC="00:50:56:00:00:01" ;; node-02) MAC="00:50:56:00:00:02" ;; node-03) MAC="00:50:56:00:00:03" ;; *) echo "Unsupported node: $node" continue ;; esac govc vm.create \ -c=8 \ -m=32768 \ -disk=100GB \ -g=rhel9_64Guest \ -net.adapter=vmxnet3 \ -net.address=$MAC \ -disk.controller=pvscsi \ -iso-datastore=NVMe \ -iso=discovery_image_ocp.iso \ -ds=NVMe \ -on=false \ $node govc vm.change \ -e "disk.enableUUID=true" \ -nested-hv-enabled=true \ -vm=$node done ノード名でループを実行し、対応するMACアドレスを変数にセットします disk.enableUUID と nested-hv-enabled は vm.create 時に指定できないため、仮想マシンの作成後に vm.change でパラメーターを設定します。 ISOファイルが存在しないとコマンドの実行がエラーになります。必ず事前にデータストア上にISOファイルをアップロードしてください。 4-3 仮想マシンの起動 GUIまたはCLIで仮想マシンの起動を行います。 govcコマンドを使う場合は下記のコマンドを実行して仮想マシンの起動を行います。 $ for node in node-01 node-02 node-03; do govc vm.power -on $node done 5. OpenShiftインストールの実行 正常にVMの起動後、数分するとHost Inventory上に起動したOpenShiftノードが自動で表示されます。 起動したOpenShiftノードが表示される 事前にDNSの設定が適切に行われているとホスト名が自動で設定されます ホスト名の左側を展開すると、ホストの詳細が確認できます。CPUアーキテクチャーやハードウェアの情報が確認できます。 インストールに必要な条件を満たすと、Statusが Ready になり「Next」が選択できます。 詳細の確認後、「Next」を押します。 5-1 Storage ストレージの確認画面です。ISOの起動ディスクとは別にインストール先のディスクが登録されていることを確認します。 確認後「Next」を押します。 Storage インストール先ディスクの容量が実際の容量(100GB)よりも多いのはSwap領域も含めての数字となっていると思われます。正常な動作です。 5-2 Networking 最初に入力したネットワーク情報が正しく反映されているか確認します。 詳細の確認後、「Next」を押します。 項目 設定値 説明 Network Management Cluster-Managed Networking Networking stack type IPv4 Machine network 192.168.1.0/24(192.168.1.0-192.168.1.255) API IP 192.168.1.204 Ingress IP 192.168.1.205 Use advanced networking チェック無し Use the same host discovery SSH key チェック有り すべてのノードに同じ公開鍵を登録する Networking 5-3 Review and create ここまででインストールに必要な情報の入力、ノードのチェックは完了しています。 Preflight checksの各項目がグリーンマークになっていることを確認し「Install cluster」を押してインストールを開始します。 Review and create(1/3) Review and create(2/3) Review and create(3/3) 5-4 インストールのモニタリング インストールが開始すると自動で作業が進むのであとは放置で問題ありません。 環境によりますが、インストールの完了にはおおよそ1時間程度かかります。 インストールの進捗状況を確認 インストールの途中で「Download kubeconfig」を押し他場合は kubeconfig-ingress という名前のファイルがダウンロードされます。中身が異なりますのでインストール完了後に再度ダウンロードを実行してください。 インストール作業の概要(詳細は省略) ノードのうち1台がブートストラップマシンとして構成し、単一ノードのetcdクラスターと一時的なKubernetesコントロールプレーンを起動します。 残り2台はコントロールプレーンのインストールを実施します。 2台のコントロールプレーンのインストールが完了後、ブーストラップマシンは解除されコントロールプレーンのインストールを実施します。 コンピュートノードの設定、Cluster Operatorの起動が完了するとインストールが完了します。 5-5 インストールの完了 インストール完了後、「Launch OpenShift Console」を押すとWebコンソールに接続できます。 初期の管理者ユーザー名は「kubeadmin」です。パスワードはクリップボードへのコピーボタンを押すとコピーされます。 インストールの完了画面 「Download kubeconfig」を押しkubeconfigファイルは必ずローカルに保存してください。このkubeconfigファイルを使って system:admin としてクラスターにログインが可能です。このkubeconfigファイルのこの画面でのダウンロードは20日間のみ利用可能です。 OpenShift Webコンソールのログイン画面 デフォルトではOpenShiftの自己署名証明書を使用しているため、ブラウザでの接続時に警告がでます（合計2回）。 OpenShiftのWebコンソール画面 OpenShiftのインストールを行うと、自動で60日間のセルフサポートのトライアルが開始します。ライセンスの設定などの作業は不要です。そのまますべての機能が利用できます。 インストール直後はInsightsに警告が出ます。しばらくそのままにしていると自動的に警告は消えます。 まとめ vSphere（ESXi）上に3ノードクラスターのOpenShiftのインストールを行いました。 作業の大半は事前作業や踏み台サーバーの構築であり、OpenShiftのインストール自体は自動で行われるためほとんど何もすることなく簡単に実施が可能です。 Assisted Installerはこれまで難易度の高かったOpenShiftのインストールを簡略化するものです。 今回ご紹介した手順を何度か繰り返せば、実稼働環境向けの物理サーバーなどでもほぼ同じ手順でOpenShiftのインストールが可能です。 是非いろんな環境にOpenShiftをインストールすることにトライしてみてください。 （次回予告） 次回はOpenShiftのインストール後の作業について解説します。 *1 : OpenShift Container Platform 4.x Tested Integrations (for x86_x64) - Red Hat Customer Portal *2 : https://docs.redhat.com/ja/documentation/openshift_container_platform/4.15/html/virtualization/installing#preparing-cluster-for-virt *3 : https://knowledge.broadcom.com/external/article?legacyId=2009916 *4 : https://docs.redhat.com/ja/documentation/openshift_container_platform/4.15/html-single/installing/index#virt-planning-bare-metal-cluster-for-ocp-virt_preparing-to-install-on-bare-metal *5 : 64vCPUの方は、物理CPU上でHyper-Threading（HT）が有効の場合の換算値（1:2）です。本記事では詳細については割愛します。 *6 : 第2章 OpenShift CLI (oc) | Red Hat Product Documentation *7 : ハマりポイント。このPTRレコードがないとCluster Operatorの起動終盤で進まなくなります。 *8 : VMware Compatibility Guide - Guest/Host Search

Red Hat で Java 関連の製品を担当している伊藤ちひろです。 この記事では、すでにビルドされた WAR ファイルを用いて、JBoss EAP 8.0 のコンテナを作成する方法を紹介します。 みなさんのシステムには、WARファイルをビルドする手順がすでにあるでしょう。 そのような場合、その環境を生かしてJakarta EEアプリケーションをコンテナ化できます。 Jakrta EEアプリケーションのコンテナ化するに当たり以下のような不安があるかもしれません。 難しいツールを使わないといけないかもしれない CI/CD を構築しないといけない 実際はそのようなことはなく、Jakarta EEアプリケーションのコンテナ化は次の 3 ステップだけで完了します。 コンテナファイルを作成 コンテナイメージを作成 コンテナを起動 今回のアプリケーションは my-app.war を使用します。 1. コンテナファイルを作成 コンテナイメージを作成するにはコンテナファイル (Containerfile, Dockerfile) が必要です。 JBoss EAPのコンテナファイルは公式ドキュメントにサンプルがあります。 このサンプルには、アプリのデプロイ方法などがコメントとして記載されています。 以下は公式ドキュメントからコピーしたコンテナファイルに対して以下を実施しました。 コメントを削除 アプリケーションをデプロイするコードを1行追加 3.4. OpenShift へのサードパーティーアプリケーションのデプロイ | Red Hat Product Documentation FROM registry.redhat.io/jboss-eap-8/eap8-openjdk17-builder-openshift-rhel8:latest AS builder ENV GALLEON_PROVISION_FEATURE_PACKS org.jboss.eap:wildfly-ee-galleon-pack,org.jboss.eap.cloud:eap-cloud-galleon-pack ENV GALLEON_PROVISION_LAYERS cloud-default-config ENV GALLEON_PROVISION_CHANNELS org.jboss.eap.channels:eap-8.0 RUN /usr/local/s2i/assemble FROM registry.redhat.io/jboss-eap-8/eap8-openjdk17-runtime-openshift-rhel8:latest AS runtime COPY --from=builder --chown=jboss:root $JBOSS_HOME $JBOSS_HOME $JBOSS_HOME/standalone/configuration # my-app.warをデプロイ（サンプルに以下の1行だけを追加) COPY --chown=jboss:root my-app.war $JBOSS_HOME/standalone/deployments RUN chmod -R ug+rwX $JBOSS_HOME コンテナファイルの作成はこれで完了です。 Containerfile という名前で保存しましょう。 2. コンテナイメージを作成 WARファイルに加え、Containerfileも準備ができました。 それではコンテナイメージを作成します。 作業ディレクトリは以下のようになっています。 # ls -l total 8 -rwxrwxrwx 1 root root 1767 Jun 28 15:20 Containerfile -rwxrwxrwx 1 root root 2078 Jun 27 16:01 my-app.war コンテナイメージの作成は、コマンドを1つ実行するだけです。 この実行には registry.redhat.io へのログインが必要となります。まだログインされてない場合は、以下のリンクをごらん下さい。 Red Hat コンテナーレジストリーの認証 - Red Hat Customer Portal それでは、コンテナイメージを作成します。 > podman build -t my-app . しばらく時間がかかりますが、以下のようなログが出れば成功です。 Successfully tagged localhost/my-app:latest bec890e0bcf64d43b8193b6cc16a7469e03be81983923022ca5cf9c529a468c5 コンテナイメージが作成されたことを確認しましょう。今回作成したコンテナイメージは localhost/my-app として保存されます。 > podman images REPOSITORY TAG IMAGE ID CREATED SIZE localhost/my-app latest bec890e0bcf6 2 minutes ago 869 MB <none> <none> 6d564a55140f 2 minutes ago 910 MB registry.redhat.io/jboss-eap-8/eap8-openjdk17-builder-openshift-rhel8 latest d381ac3b8535 5 weeks ago 424 MB registry.redhat.io/jboss-eap-8/eap8-openjdk17-runtime-openshift-rhel8 latest 801b9cf38b51 5 weeks ago 409 MB ここまでで、コンテナイメージの作成は完了です。 3. コンテナを起動 最後に、コンテナを起動してみましょう。 コンテナの起動もコマンドを1つ実行するだけです。 > podman run -d -p 8080:8080 localhost/my-app bd33f23fc9181286ee52c929f8fb8badbe5ff670f3758babff4de14bb7eec039 コンテナが起動したことを確認してみましょう。 > podman ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES bd33f23fc918 localhost/my-app:latest sh -c ${JBOSS_CON... 25 seconds ago Up 26 seconds 0.0.0.0:8080->8080/tcp great_liskov アプリケーションにアクセスしてみましょう。 今回のアプリケーションは、WARの中でコンテキストパスは変更していないため my-app が使われます。 そのため、アクセスするURLは localhost:8080/my-app/<アプリ内のパス> です。 コンテキストパスを変更している場合は、 my-app の部分をそちらのパスへ変更してください。 アクセスするツールは Servlet/JSP であればブラウザ、JAX-RS であれば REST Client を用います。 今回のアプリケーションは JSP なため、ブラウザでアクセスしてみます。 無事に JSP が表示されました。 いかがでしたでしょうか。 既存アプリケーションのWARファイルがあれば簡単にコンテナイメージが作成できました。 Jakarta EEアプリケーションのコンテナ化は、難しそうなイメージがあるかもしれませんが、興味のある方はぜひ試してみてください。 参考 3.4. OpenShift へのサードパーティーアプリケーションのデプロイ | Red Hat Product Documentation

こんにちは。Red Hatのソリューションアーキテクトの瀬戸です。 今回は、Windows上でJBoss Enterprise Application Platform 8.0(以下EAP)を使用して開発を始めるまでを紹介したいと思います。 Windows上でJava言語を書いたことがあり、手元でJavaを実行することができ、コマンドプロンプトの概念を理解し、コマンドラインツールについては問題なく使用できることを前提としています。 この記事では開発ツールをインストールし、JBoss EAPサーバーを動かして、データソースの設定を行い、データソースの設定を行うところまでを行います。 実際にコードを書いてサーバーにデプロイするところは次回です。 JBoss Enterprise Application Platform とは何か JBoss Enterprise Application PlatformはRed Hatが出しているエンタープライズグレードのJakarta EE 10仕様に準拠したWebアプリケーションサーバーです。 Java言語でアプリケーションを記述することができ、水平分散、垂直分散、フェイルオーバー等、落ちにくいシステムを作りたいと考えたときに必要とする機能のほぼすべてを網羅しています。 Jakarta EE 10仕様は昔はJava EE仕様と呼ばれていました。 Java EE仕様はJavaのウェブサービスを実装するための仕様をまとめたもので、かつてはOracle社が管理していました。2017年にEclipse Foundationに移管したのですが、その時にOracle社がJavaの商標をEclipse Foudationに使わせることに難色を示したため、新しい名前が公募で決まり、Jakarta EEとなりました。 なお、Jakarta という名前はJava界隈では昔からなじみのある名前です。OSSを管理する団体として有名なApache Software Foudation内でJavaに関わるプロジェクトは Apache Jakarta Projectとして管理されていました。2011年にApache Jakarta Projectという単位は凍結されていたので、6年ぶりの復活でした。 EAP 8.0が準拠している Jakarta EE 10仕様は2022年に制定された仕様ですが、現時点でも最新の仕様です。 Jakarta EE仕様に準拠したサーバー(もしくはJava EE仕様に準拠したサーバー、以下EEサーバー)はJava EEの時代から通じて企業システムの根幹を維持するための製品として支持されてきました。そのため、EAPにおいても、長期間のサポートを行い、細心の注意を払ってテストをしています。 また、EEサーバーは複数社が提供していますが同じ仕様で実装されているため、互換性が高く、ベンダーロックインされにくいというのが特徴です。 複数の製品が同じEE仕様に準拠しているということもあり、EEに関する情報やツール類は流用できるという点も良いです。 実際に多くのライブラリはEE仕様 *1 に乗っ取って作成されており、EE仕様 *2 に則っていないアプリケーションサーバーが流行りにくい理由にもなっています。 EAP自体はOSSとして開発されており、upstreamはWildflyとして公開されています。 WildflyにはEAPに搭載される前の実験的な機能が含まれる場合もあるので、新しい機能を試してみたい場合はWildFlyを使ってみると良いでしょう。 www.wildfly.org Java EEからJakarta EEへの変更 Jakarta EEになってからよりもJava EEであった頃の期間が長いため、多くの情報はJava EEのままになっている場合もあります。Java EEとJakarta EEでは仕様の名前が変わったほかにjavaファイル上のパッケージ名が変更されています。 基本的にJavaでは下位互換性が非常に重要視されており、10年以上前に書かれたプログラムでも普通に動作することがほとんどなのですが、パッケージ名の変更だけは個別で対応する必要があります。 例) javax.http.servlet.HttpServletをjakarta.http.servlet.HttpServletに変更する必要がある Note: Java SEに含まれるパッケージについては置換が不要なのはご注意ください。(javax.sql等) また、Javaでアプリケーションを作る場合には多数のコミュニティや企業が作成したライブラリを使用する事ができます。古いライブラリには脆弱性が含まれている可能性があるので、 古い情報を参照してアプリケーションを構築する場合でも最新版のライブラリを使用してセキュリティ面を担保する必要があります。 その際に、Java EEの依存ライブラリで作られたままで、Jakarta EE版のライブラリが存在しない場合は使用ができないので注意が必要です。(2024年6月時点でVelocity等) 開発環境の準備 EAPを快適に開発するためには以下の準備が必要です。 Red Hat Developer Programへの登録 お好きなエディタもしくはIDEの準備 Java実行環境(OpenJDK)のインストール Mavenのインストール EAPのインストール (オプショナル)Podman/RDBMS(RDBMS)のインストール さて、一つずつ見ていきましょう。 Red Hat Developer Programへの登録 Red Hatでは個人の開発者向けにRed Hat Developer Programを提供しています。一定の利用条件を守ることで、ノンサポートですが、Red Hatの製品を無償で使用する事が出来るようになります。 EAPのダウンロードを行うためには、こちらに登録していただく等で、Red Hatのアカウントを作成していただく必要があります。 詳細については以下をご参照ください。 rheb.hatenablog.com お好きなエディタもしくはIDEの準備 EAP上で開発するのに特殊なツールは必要がなく、一般的なJava開発環境があれば開発することができます。Jakarta EE仕様にしたがっているため、IDEがJakarta EE対応の機能を持っていればそれを使用する事もできます。 以下のようなツールを使用する事ができます。 Eclipse もしくは Pleiades All in One Visual Studio Code に Language Support for Java(TM) by Red Hat を組み合わせたもの IntelliJ IDEA EclipseはデファクトスタンダードになっているJavaのIDE環境です。無料で使用する事ができます。Pleiades All in One は有志が提供しているEclipseに日本語化ツールや便利な機能を提供するプラグイン類を追加したものです。PCスペックに余裕があってIDEにこだわりがないのならお勧めです。 www.eclipse.org willbrains.jp Visual Studio CodeはMicrosoftが出しているエディタです。Language Support for Java(TM) by Red Hatを追加する事でEclipseのように使用する事ができますが、Eclipseに比べると機能が弱いことは否めません。軽い開発環境が欲しい場合は使用してください。 azure.microsoft.com IntelliJ IDEAは有償のIDEです。無償のCommunity Editionもありますが、Web開発向けの機能は有償機能のみで提供されています。 www.jetbrains.com これ以外にも多くのJava用の開発環境を使用する事ができます。普段から使用しているものがあればそのまま使用する事も可能です。 この次の記事ではPleiadesを使用しています。 Java実行環境(OpenJDK)のインストール Javaの実行環境をインストールします。Red HatはRed Hat build of OpenJDKというJavaの実行環境を提供しており、Windows上でも動作させることが可能です。 現時点(2024年6月)時点でEAPはOpenJDK17までをサポートしているため、そちらを使用します。 次のURLからダウンロードすることができます。Red Hatのアカウントが必要になります。登録していない人は先に登録してください。 developers.redhat.com 下の方からjdk-17.0.XX-x64 MSIを探してダウンロードします。 ※XXの部分は最新のものを使用するようにしてください。 ※慣れている方はZIP版や、他の互換OpenJDKディストリビューションを使用しても大丈夫です。 OpenJDKのダウンロード ダウンロードしたらmsiを実行することでインストールできます。 インストーラー起動 2つ目の画面でEnd-User License Agreementに同意します。 ライセンス 次はデフォルトのままNextを押します。 セットアップ Installを押すことでインストールが開始します。 インストールの開始 すぐにインストールが成功するでしょう。 インストールの終了 Note: インストーラーを使用する事で必要な環境変数を自動的に設定してくれます。ZIP版の場合は追加で環境変数の設定が必要になります。Java実行環境のいくつかのバージョンを共存させる必要がある場合などにZIP版を使用します。 Mavenのインストール MavenはJavaのビルドツールのデファクトスタンダードです。特にどこかの企業が製品として取り扱っているというわけではないのですが、Java開発時には一般的に使用されるツールの一つです。また、これ以外に有名なビルドツールとしてAntやGradleがあります。 Mavenのウェブサイトにアクセスします。 maven.apache.org Filesから最新のZipファイルをダウンロードします。MavenはすべてJavaで書かれているアプリケーションのため、OSに関係なく同じバイナリを使用する事ができます。 mavenのダウンロード ダウンロードしたらZIPファイルを適切な場所に解凍します。(例: C:\apps\maven\apache-maven-3.9.8) 解凍したフォルダの中のbinにPATHを通しますために次の操作を行います。 スタートメニューから「環境変数を編集」を選択します。 スタートメニュー 環境変数を選択します。 開いた先からもう一度選択する 環境変数にmavenの下のbinを追加します。 他の値がある場合は削除しないように気を付けてください。 環境変数へ追加 コマンドプロンプトを開いてmvn -vの結果が以下のようになったら正しくインストールされています。 >mvn -v Apache Maven 3.9.8 (36645f6c9b5079805ea5009217e36f2cffd34256) Maven home: C:\apps\maven\apache-maven-3.9.8 Java version: 17.0.11, vendor: Red Hat, Inc., runtime: C:\Program Files\RedHat\java-17-openjdk-17.0.11.0.9-1 Default locale: ja_JP, platform encoding: MS932 OS name: "windows 11", version: "10.0", arch: "amd64", family: "windows" mvnコマンドが見つからない場合はコマンドプロンプトを開きなおして試してください。それでも見つからないならPATHの設定方法が間違っている等が考えられるので確認してください。 Note: Windows のバージョンによってPATHの設定画面が大きく異なる可能性があります。また、PATHが壊れるとWindows自体が起動しなくなる可能性もあるので、不安がある場合は近くの詳しい人に相談してください。 mavenの設定ファイルへRed Hat Repositoryの追加 Red HatはRed Hatが管理するMaven Repositoryを提供しています。このリポジトリにはRed Hatが独自でビルドしているライブラリなどが提供されています。 次のドキュメントに従ってsetting.xmlを編集し、アクセスできるように設定します。 Mavenをインストールしたフォルダの配下の/conf/settings.xmlを修正するのが間違いにくいと思います。 ※Java製品で共通の設定方法です。 docs.redhat.com Note: Proxyサーバーが必要な場合等、追加で設定が必要になる場合があります。 EAPのインストール JBoss EAP 8.0をダウンロードします。 次のURLにアクセスしてください。 developers.redhat.com OpenJDKの時はWindowsインストーラーをダウンロードしましたが、今回は取り回しやすいZip版をダウンロードします。インストーラー版はサーバーとしてEAPを常駐させたい場合等に使用します。 Zipファイルのダウンロード Note: 本番環境で使用する場合はカスタマーポータルからダウンロードします。また、セキュリティパッチをあてることも忘れないようにしてください。 ダウンロードしたzipを任意の場所に解凍します。(例: C:\apps\jboss\jboss-eap-8.0) 起動できるか確認するため、binのフォルダの下にあるstandalone.batを起動します。 >standalone.bat Calling "C:\apps\jboss\jboss-eap-8.0\bin\standalone.conf.bat" Setting JAVA property to "C:\Program Files\RedHat\java-17-openjdk-17.0.11.0.9-1\\bin\java" =============================================================================== JBoss Bootstrap Environment JBOSS_HOME: "C:\apps\jboss\jboss-eap-8.0" JAVA: "C:\Program Files\RedHat\java-17-openjdk-17.0.11.0.9-1\\bin\java" JAVA_OPTS: "-Dprogram.name=standalone.bat -Xms1G -Xmx1G -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -Djdk.serialFilter="maxbytes=10485760;maxdepth=128;maxarray=100000;maxrefs=300000" -Xlog:gc*:file="\"C:\apps\jboss\jboss-eap-8.0\standalone\log\gc.log\"":time,uptimemillis:filecount=5,filesize=3M --add-exports=java.desktop/sun.awt=ALL-UNNAMED --add-exports=java.naming/com.sun.jndi.ldap=ALL-UNNAMED --add-exports=java.naming/com.sun.jndi.url.ldap=ALL-UNNAMED --add-exports=java.naming/com.sun.jndi.url.ldaps=ALL-UNNAMED --add-exports=jdk.naming.dns/com.sun.jndi.dns=ALL-UNNAMED --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.lang.invoke=ALL-UNNAMED --add-opens=java.base/java.lang.reflect=ALL-UNNAMED --add-opens=java.base/java.io=ALL-UNNAMED --add-opens=java.base/java.net=ALL-UNNAMED --add-opens=java.base/java.security=ALL-UNNAMED --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.util.concurrent=ALL-UNNAMED --add-opens=java.management/javax.management=ALL-UNNAMED --add-opens=java.naming/javax.naming=ALL-UNNAMED -Djava.security.manager=allow" (中略) 18:52:41,555 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: http://127.0.0.1:9990/management 上でリッスンす る HTTP 管理インターフェース 18:52:41,555 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: 管理コンソールは http://127.0.0.1:9990 をリッス ンしています。 18:52:41,561 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 8.0.0.GA (WildFly Core 21.0.5.Final-redhat-00001) は 2471 ミリ秒で開始しました - サービス 524 個のうち 282 個を開始しました (318 のサービスはレイジー、パッシブ、またはオンデマンドです) - 使用中のサーバー設定ファイル: standalone.xml 起動したら http://localhost:8080 にアクセスすることで、EAPの初期画面を表示することができます。 EAPの初期画面 別の画面が見えてしまった場合は他のサーバーがすでに起動しています。その場合は他のサーバーをシャットダウンするか、standalone.batを起動する際に standalone.bat -Djboss.http.port=8081 のように -Djboss.http.port= の後にポート番号を指定してあげることで別のポート番号で起動することができます。 この後の設定やアプリケーションのデプロイ時には起動している必要があるため、そのままにします。 *3 (オプショナル)Podman/RDBMS(RDBMS)のインストール この章の実行はオプショナルです。 EAPではデータベースの接続先の管理をEAPが担い、ユーザーアプリケーションはサーバーに管理されたデータベース接続設定を使用します。EAPが高可用性のための機能を持っており、そちらを使用するためです。高可用性のための機能を必要としない場合はEAPにデータベース接続設定を行う必要がありませんが、通常はEAPに任せます。一度設定を体験していれば簡単ですが、知らないとわかりにくい機能なので、ここで設定をします。 Podmanのインストール まず、接続先DBを起動するために、Podmanをインストールします。Podmanを使用しなくても直接使用できるDBがある場合はそちらを使用しても大丈夫です。 PodmanはRed Hatが提供しているDocker互換のコンテナ管理ソフトです。Dockerと同じように使用でき、Windowsでも無償で使用する事ができます。 PodmanをWindowsで使用する場合はPodman Desktopをインストールするのが簡単です。以前書いた Podman AI Labを使用してローカルでLLMを動かしてみる という記事でPodman Desktopのインストール方法を説明していますので、そちらを参照してください。 rheb.hatenablog.com Postgres(DB) の起動 Podman がインストールされていればPostgresの起動は簡単です。コマンドプロンプトを開いて次のコマンドを入力します。 podman image pull docker.io/postgres podman run --name postgres -e POSTGRES_PASSWORD=postgres -p 5432:5432 -d postgres これだけでPostgresが起動します。このPostgresはユーザー名:postgres、パスワード:postgres、接続先ポートとして5432を使用するように設定しています。他のカスタマイズ項目等に興味がある場合は次のURLからpostgresのコンテナイメージのドキュメントを参照してください。 https://hub.docker.com/_/postgres Note: ここで起動したPostgresはリソースを使用し続けるので不要になったら削除することをお勧めします。削除の仕方は最後に記載します。 データソースの設定 EAPではデータベースへの接続設定をEAPが管理します。高可用性を担保するための仕組みをEAPが持っており、そちらの機能を使用するためです。アプリケーション側にて直接データベースへの接続設定を行うこともできますが、その場合はEAPの持つ高可用性の機能を使用する事が出来ません。管理するためのCLIがありますので、そちらから設定していきます。 *4 JDBCドライバのダウンロード 最初に、DB接続用のJDBCドライバをダウンロードします。JavaではDB接続が仕様化されており、対応しているDBであればJDBCドライバを使用する事で同じように操作することができます。今回はPodman上でPostgresを起動していますので、以下のURLからドライバを取得します。 jdbc.postgresql.org PostgresのJDBCドライバ 今回はJava 17(OpenJDK 17)を使用していますが、Postgresで用意されているものはJava 8用のものまでのようなので、そちらをダウンロードします。左上のものを選択してダウンロードしてください。 Note: Javaは強力な後方互換性を維持しています。多くの場合どれだけ準拠するバージョンが古かろうとも準備されている最新のものを使用する事で正常に動作します。 ダウンロード時にはローカルの適切な場所に保存してください。EAPへの設定時にファイルへのアクセスが必要になります。また、設定後はEAP内にファイルがコピーされるのでダウンロードしたファイルは削除して大丈夫です。 Note: 使用するデータベースの種類、バージョンによって適切なJDBCドライバを準備してください。 EAPへのデータソースの登録 EAPが起動している状態でコマンドプロンプトからEAPをインストールしたフォルダのbinフォルダに移動します。その後、jboss-cli --connectを実行して管理コンソールに接続します。 > cd C:\apps\jboss\jboss-eap-8.0\bin >jboss-cli --connect [standalone@localhost:9990 /] 管理コンソール上で、以下のコマンドを入力します。 module add --name=org.postgres --resources=<PATH_TO_JDBC_DRIVER>\postgresql-XX.X.X.jar --dependencies=javax.api,javax.transaction.api /subsystem=datasources/jdbc-driver=postgres:add(driver-module-name=org.postgres, driver-name=postgres) data-source add --name=postgresDS --jndi-name=java:jboss/datasources/CoolstoreDS \ --driver-name=postgres \ --connection-url=jdbc:postgresql://localhost:5432/postgres \ --user-name=postgres --password=postgres ※<PATH_TO_JDBC_DRIVER>\postgresql-XX.X.X.jarは実際のファイルへのパスに置き換えてください。 次のコマンドでデータソースのテストを行えます。 /subsystem=datasources/data-source=postgresDS:test-connection-in-pool 以下は正常に設定が完了している場合の出力例です。 { "outcome" => "success", "result" => [true] } これでデータソースの設定は終わりです。 リソースの終了・削除 ここまでで開発を始める前の設定は一通り終わりました。長くなってきたので、ここで一度終わりにするためにリソースを終了・削除します。 EAPの終了 EAPが起動しているコマンドプロンプト上でCTRL-Cを押します。 jboss-cliはexitを入力することで終了することができます。 PostgreSQLの削除 コマンドプロンプト上で以下のコマンドを順に実行します。 podman stop postgres podman rm postgres podman rmi postgres Note: rmでPodman上からのコンテナの削除、rmiでローカルでのイメージのキャッシュを削除しています。今後もコンテナ上でPostgresを使用したい場合は削除しなくても大丈夫です。ただし、stopを実行しない場合は常にPostgresが起動し続けてしまうのでstopだけは忘れないようにしてください。 以上でリソースの終了・削除は終わりです。 おわりに ここまででJBoss EAPの開発環境を作ってみました。次回はこの開発環境を使って開発をしてきます。 続きはこちら rheb.hatenablog.com *1 : とくにServlet仕様 *2 : とくにServlet仕様 *3 : なお、コマンドプロンプト上でCTRL-Cを入力することでサーバーをシャットダウンすることができます。 *4 : 管理コンソールからGUIで設定することもできますが、今回は省略します。