Red Hat のソリューションアーキテクトの瀬戸です。 概要 前回 はjpackageの基本的な使い方を説明しました。 今回はもうちょっと踏み込んだ使い方を説明します。 前回の記事を読んでいない方は、先にそちらをお読みください。 rheb.hatenablog.com よく使うパラメーターをまとめる @[filename] を使用することでそのファイルの内容をパラメーターとして解釈させることができます。よく使用するパラメーターをファイルにすることでオプションを毎回入力しなくて済むようになります。 必要なパラメーターを追加で付けることもできます。同じパラメーターがファイルと引数の両方にあった場合は引数が優先されるようです。 > jpackage @option.txt --app-version 2.1 アプリケーションのアイコンとベンダーを指定する Windowsインストーラーにはいくつかのメタデータが含まれていて、プログラムの追加と削除から表示することができます。 次のように引数を指定することでアイコンとベンダー名を指定することができます。 > jpackage @option.txt --icon shadowman.ico --vendor "red hat" これでだれが作ったアプリケーションか一目瞭然になるのではないでしょうか。 ちなみに、icoファイルはinputフォルダの下に置く必要はありません。 ベンダー名指定 Java ランタイムの軽量化 JDK 9以降はランタイムのモジュール化が図られており、必要なモジュールのみ配るように制限することでインストーラーのサイズを小さくすることができます。 jdepsを使用すると、必要としているモジュールが何かを判別することができます。 > jdeps --print-module-deps clientexample.jar java.base,java.desktop >jpackage @option.txt --add-modules java.base,java.desktop jdepsの出力結果を --add-modules で指定しています。 今回のサンプルアプリケーションは依存しているものも少ないので、実際に半分のサイズになってしまいます。 moduleを指定した場合はインストーラーのサイズが半分に アプリケーションのアップデートへの対応 Windowsインストーラーは同じ製品のバージョン違いかどうかをUUID(もしくはGUID)を使って管理をしています。 インストーラーの作成時に、UUIDと製品バージョンを指定することで同じアプリケーションとして認識され、アップデート時に古いアプリケーションを同時に削除することが出来るようになります。 次のように指定します。 > jdeps --print-module-deps clientexample.jar java.base,java.desktop > jpackage @option.txt --app-version 2.0 --win-upgrade-uuid d5f22f98-52b1-4daa-b501-ad12535a5553 versionには細かい規定があります。詳しくはWiXのドキュメントを参照してください。 WiX チュートリアル 日本語訳 Lesson 4 アップグレードとモジュラー化 UUID(GUID)は世界中でユニークである必要のある値です。 Windowsの場合はPowerShellから生成できます。 > [Guid]::NewGuid() Guid ---- d5f22f98-52b1-4daa-b501-ad12535a5553 ライセンスの追加 いわゆる使用許諾契約書を追加することができます。 > jpackage @option.txt --license-file .\licencefile.txt Apache License 2.0をそのまま取り込んだ例が次の画像です。 https://www.apache.org/licenses/LICENSE-2.0.txt 残念なことに現時点では改行が崩れてしまっています。 また、日本語には対応していないようです。 きれいに見せるためにはなかなか骨が折れそうです。 Apache License 2.0を取り込んだところ さらなるカスタマイズ いままではjpackageの標準的なオプションの中でできることを見てきました。しかし、内部で使っているWiXを直接扱うことでさらなるカスタマイズができます。 --temp と --verbose のオプションを付けることで、WiX用の設定ファイルの保存と、WiXの実行時に指定されるコマンドを出力することができます。 --tempと--verboseを指定した場合 インストーラーの見た目をカスタマイズしたい場合はこれらを使用することでお好きなインストーラーを作成することができます。 その場合はWiXのマニュアルを参照しながらカスタマイズをしてください。また、Windowsインストーラーには署名もできますが、jpackageでは対応していないようです。 必要に応じてWindowsインストーラーのドキュメントを参照して署名を行ってください。 WiX チュートリアル 日本語訳 Lesson 4 アップグレードとモジュラー化 Windows インストーラー - Win32 apps | Microsoft Learn まとめ 駆け足でしたがjpackageの踏み込んだ使い方を説明してきました。説明できていないオプション類もたくさんありますので、ぜひ興味がある人は試してみてください。

Red Hat のソリューションアーキテクトの瀬戸です。 概要 OpenJDK 14からjpackageというインストーラーを作るためのツールが同梱されるようになりました。 もともとはJavaFXにあったjavapackagerがベースとなっているツールです。 Windows/Linux/Mac用のインストーラーを作成することができます。 もともとJava 8まではJava Web Start等でアプリケーションの配布を行っていましたが、セキュリティ上の理由によりオミットされてしまったのでそちらの代替となるアプリケーションの配布方法になります。 こちらを使用するとJavaで作られたアプリケーションだけでなく、OpenJDK(Javaの実行環境)も同時に配布できるパッケージを作成できます。 これだけでOpenJDKのインストールができ、アプリケーションが実行されるOpenJDKのバージョンも固定できるので、クライアントアプリケーションを作りたい場合は便利なツールです。 今回はこちらを使用して、Windows向けの配布パッケージ(msi)を作っていきます。 ちなみに、JEP 343: Packaging Tool で提案されて実装されました。 openjdk.org ツールのインストール OpenJDK jpackageはOpenJDKに含まれるツールなのでOpenJDKをインストールします。 今回はRed HatもサポートしているEclipse Temurinを使用します。 adoptium.net Eclipse Temurinの以下のリリースを使用しました。 openjdk 21 2023-09-19 LTS OpenJDK Runtime Environment Temurin-21+35 (build 21+35-LTS) OpenJDK 64-Bit Server VM Temurin-21+35 (build 21+35-LTS, mixed mode, sharing) jpackageはインストール先のbinの中に入っています。binの下にPATHが通っていることを確認してください。 WiX Toolset WiX Toolset v3をインストールする必要があります。v4系もリリースされていますが、そちらでは動作しません。 wixtoolset.org WiX Toolset v3のダウンロードはgithubから行うことができます。 wix311-binaries.zipをダウンロードしてPATHの通っている場所に解凍して置いておくのが簡単です。 github.com WiXのインストールに失敗している場合はjpackageの実行時に次のようなメッセージが表示されます。 [14:24:55.174] WiXツール(light.exe、candle.exe)が見つかりません [14:24:55.174] WiX 3.0以降をhttps://wixtoolset.orgからダウンロードし、PATHに追加します。 エラー: 無効またはサポートされていないタイプ: [msi] 今回使用するサンプル 今回使用するアプリケーションのサンプルは以下に保存してあります。入力しているパラメーターと実際のソースコードを比べたい場合は見てみてください。 github.com 実際に使用してみる Javaアプリケーションはmaven等でビルドをして、jarファイルを作成しておきます。複数のjarを含めることもできます。 今回のサンプルの場合は、mvn packageでビルドをすることでjarファイルを作成できます。 jarの中には起動させるためのmainメソッドが含まれている必要があります。 jpackage -hで使用できるオプションの一覧が表示されます。日本語化もされているので、使う前に一度見てみるとよいでしょう。 jpackage -hの結果 今回はmsi形式を作ります。 msi形式を作る場合、デフォルト設定でprogram files配下にサイレントインストールされるパッケージが作成されます。それだと使いにくいのでいくつかのインストール時の設定を加えて実行します。 C:\>jpackage --type msi --win-menu --win-dir-chooser --win-shortcut --win-shortcut-prompt --input .\clientexample\target --name clientexample --main-class com.redhat.clientexample.App --main-jar clientexample.jar それぞれのオプションの意味は次の通りです。 オプション 説明 type 作成する形式(今回はmsi) win-menu Windowsメニューに登録する win-dir-chooser インストール先を選択できるようにする win-shortcut ショートカットを作成する win-shortcut-prompt ショートカットを作成するかどうかプロンプトを表示する input アプリケーションに含めるフォルダ name アプリケーションの名前 main-class 起動するmainメソッドの含まれているクラス main-jar 起動するjar inputでパッケージ化するフォルダを指定している(=jar以外も含めることができる)というのがポイントでしょうか。 詳細についてはjpackage -hを参照してください。 実行すると、何事もなかったように終了し、msiパッケージが作成されます。 生成されたmsiファイル msiを起動するとセットアップウィザードが起動します。普通のWindowsインストーラーですね。 インストーラー起動 インストール先を変更することができます。 インストール先の変更 ショートカットの作成を選択することができます。 ショートカットの作成 指定するとインストールを開始できます。 インストールの開始 スタートメニューにショートカットを追加するを選択しているので、ショートカットが作成されています。一般的なWindowsアプリケーションのインストールと変わりありません。 スタートメニュー デスクトップにショートカットを作成することを選択しているので、デスクトップにショートカットが作成されています。こちらも一般的なWindowsアプリケーションのインストールと変わりありません。 リンク先はWindowsの実行ファイル(exe)になっています。jarへリンクが張られているわけではありません。 デスクトップ 実行すると普通に起動します。普通にとしか言えません。 アプリケーションの起動 インストールしたアプリケーションのフォルダを見ると、exeファイルが一つと、appとruntimeというフォルダを見つけることができます。 ショートカットからはこちらのexeにリンクが張られています。 インストール先のフォルダ appの下にはinputで指定したフォルダの配下のファイルと、いくつかのメタデータが生成されて入っています。今回はmavenビルドの成果物をそのまま使用しているため余分なファイルが含まれています。 実際に配布する場合は配布用のフォルダ構成を別途用意してからインストーラーを作成することで配布物のサイズを抑えることができます。 app配下にはinputで指定したファイルが置かれている runtimeの下にはOpenJDKから必要なもののみが配置されています。デフォルトでは開発ツール類は入ってきません。 OpenJDK由来のファイルについてはjlinkを使用して準備されます。配布ファイルのサイズを小さくしたい場合はjlinkにオプションを渡すことで実現できます。 runtimeの下にはOpenJDK由来のランタイムが置かれている まとめ かつてのJavaアプリケーションはランタイムとユーザーアプリケーションの配布タイミングが異なっていたため、複数のJavaバージョンを混在させることが難しく、ランタイムのバージョンアップ時に考慮する必要がありました。 現在ではアプリケーションと同時にランタイムを配布する方式もサポートされているため、管理がしやすくなっています。 Windows/Mac/Linuxで同じように動作するデスクトップアプリケーションが必要な場合は現在でも有効な選択肢の一つですので、ぜひお試しください。 追記: 前にjpackageのバグを直したとき「自分のデスクトップ汚したくないけどどうやってインストーラー試そう？」と悩んだけどWindows Sandboxに助けられた。jpackageのインストーラーのテストしたい方、ぜひSandboxの存在を思い出してほしい。 https://t.co/xEhOddQuvY — Yasumasa Suenaga (@YaSuenag) 2023年10月25日 知らなかった・・・・ learn.microsoft.com 続きを書きました。 rheb.hatenablog.com

Red Hatでソリューションアーキテクトをしている田中司恩( @tnk4on )です。 この記事は Red Hat Developer の Containerize a Spring Boot application with Podman Desktop を、許可をうけて翻訳したものです。 本記事で紹介する Podman や Podman Desktop に関する情報を日本語で紹介するX アカウントがあります。こちらもフォローして情報収集に活用ください。(ハッシュタグ #podmanjp ) Podman( https://t.co/ipoaatoD4a )の非公式Twitterアカウント。 #Podman に関する情報を日本語で配信中。ツイートは個人のものであり特定の組織や企業を代表するものではありません。The unofficial Twitter account for Podman. Tweets are my own. #podmanjp — podmanjp (@podman_jp) July 9, 2023 前提条件 Spring Bootアプリケーションのコンテナ化 Podman Desktopでコンテナイメージを構築する コンテナ化したアプリケーションを実行する まとめ 関連の記事 関連のコンテンツ Spring と Spring Boot は、クラウドで動作する Java アプリケーションを構築するために開発者に愛用されています。Springは、本番環境に対応していることで知られており、 コンテナ化 を非常にうまく補完してくれます。。 State of Spring 2022 レポートによると、 Kubernetes はSpringアプリを実行するための主要なプラットフォームになっています。では、Springアプリケーションをコンテナ化してローカルで実行するにはどうすればいいのでしょうか？ローカル環境からコンテナやKubernetesをシームレスに扱うためのオープンソースツールであるPodman Desktopを使って、これを調べてみましょう。 前提条件 Spring Bootアプリケーション：この記事では、GitHubで人気のある Spring PetClinic サンプルアプリケーションを使用します(図1)。自分のプロジェクトを使うか、 Spring Initializr から始めるのも自由です。 図1：Github上のSpring PetClinicリポジトリ Podman Desktop： コンテナエンジンのPodman を使ってコンテナをデプロイ、管理するためのGUIベースの強力なツール、 Podman Desktop を使ってみましょう。インストールが完了したら、Springアプリケーションのコンテナ化を開始できるようになります。（図2）。 図2：Podman Desktopのダッシュボード Spring Bootアプリケーションのコンテナ化 PetClinicリポジトリを使う場合は、アプリケーションのソースコードをクローンすることから始めましょう。 git clone https://github.com/spring-projects/spring-petclinic.git cd spring-petclinic Maven を使ってjarファイルをビルドして実行することもできますが、ここではプロジェクトのルートディレクトリにContainerfileを作成することにしましょう。このファイルは touch Containerfile コマンドで作成することもできますし、IDEから作成することもできます。このサンプルのSpring BootアプリケーションでContainerfileがどのようになるか見てみましょう。 # Start with a base image that has Java 17 installed. FROM eclipse-temurin:17-jdk-jammy # Set a default directory inside the container to work from. WORKDIR /app # Copy the special Maven files that help us download dependencies. COPY .mvn/ .mvn # Copy only essential Maven files required to download dependencies. COPY mvnw pom.xml ./ # Download all the required project dependencies. RUN ./mvnw dependency:resolve # Copy our actual project files (code, resources, etc.) into the container. COPY src ./src # When the container starts, run the Spring Boot app using Maven. CMD ["./mvnw", "spring-boot:run"] このContainerfileを構成するコンポーネントを詳しく見てみましょう。 FROM eclipse-temurin:17-jdk-jammy 目的：この行は、コンテナの基礎を設定する。 深く掘り下げる：この行は、Java 17がすでにインストールされている既存のイメージを使うようにPodmanに指示します。材料を追加する前に、ケーキのベースとなる味を選ぶようなものだと考えてください。私たちは eclipse-temurin イメージを使いますが、それはJavaインストールの信頼できるソースだからです。 WORKDIR /app 目的: コンテナ内の作業スペースを指定します。 深く掘り下げる：コンテナには独自のファイルシステムがあります。ここでは、Podmanに「app」という名前のフォルダをセットアップし、その後の操作のデフォルトの場所にするよう指示しています。 COPY commands 目的：ローカルシステムからコンテナにファイルを転送する。 深く掘り下げる：最初のCOPYは、Java開発者がアプリの依存関係を管理するために使用するツールである Maven の設定を取得します。2つ目のCOPYは、アプリの主要ファイルであるMavenラッパー（ mvnw ）とプロジェクトの詳細（ pom.xml ）をコピーします。 RUN ./mvnw dependency:resolve 目的: アプリに必要なライブラリとツールをダウンロードします。 深く掘り下げる：このコマンドは、アプリの実行に必要なものすべてをフェッチするためにMavenをアクティブにする。Containerfileでこれを行うことで、コンテナにすべてがきちんとパッケージ化されていることを確認します。 COPY src ./src 目的：実際のアプリケーションコードを追加する。 深く掘り下げる：アプリのロジック、機能、リソースはsrcディレクトリにあります。これをコンテナに移動することで、コンテナの実行時に完全なアプリが表示されるようにします。 CMD ["./mvnw", "spring-boot:run"] 目的: アプリケーションを起動します！ 深く掘り下げる：このコマンドは最後のステップです。この行は、コンテナの起動時にMavenを使ってSpring Bootアプリケーションを実行するようPodmanに指示します。 このContainerfileをPodman Desktopで使用して、Spring Bootアプリケーションのコンテナイメージを作成する準備が整いました（図3）。このアプリケーションのイメージをビルドする前に、選択したIDEでディレクトリ構造とContainerfileを再チェックしましょう。 図3：VSCodeのContainerfile。 Podman Desktopでコンテナイメージを構築する まずPodman Desktopの Images セクションに行き、右上の Build an Image ボタンを選択します（図4）。 図4：Podmanデスクトップビルドイメージがハイライトされています これでメニューが開き、 spring-petclinic フォルダのルートディレクトリにある、以前に作成したContainerfileへのパスを選択できます。Containerfileを選択すると、コンテナイメージに名前を付けることができます（ここでは petclinic ）。次に、 Build をクリックすると、イメージの各レイヤーが作成されるのがわかります。これはローカルのイメージレジストリ（図5の Image セクション）で確認できます。 図5：PodmanデスクトップのBuild an Imageメニュー コンテナ化したアプリケーションを実行する 素晴らしい！ Images セクションに戻り、ビルドされイメージとしてタグ付けされたコンテナ化されたSpring Bootアプリケーションと、petclinicイメージをビルドするためにダウンロードされたeclipse-temurinベースイメージを確認しましょう。コンテナイメージの右側にある Run アイコンを使用して、このイメージをシステム上でコンテナとして簡単に実行できます（図6）。 図6：コンテナを実行する場所を示すPodman Desktop PortMapping で、コンテナのポート8080をホストのポート8080に割り当てていることを確認します。その他の設定はデフォルトのままにしておいてください。 Start Container をクリックして、Spring Bootアプリケーションのコンテナ化インスタンスを起動します（図7）。 図7：Podman Desktop メニューのコンテナ開始ボタンをクリックする さて、コンテナを起動して実行した状態で、Podman Desktopのユーザーインターフェイスにある便利な「ブラウザを開く」ボタンを使って、コンテナのURLをブラウザで開いてみましょう（図8）。 図8：ブラウザを開くボタンを強調表示したPodman Desktop 完璧です！ContainerfileのstartupコマンドとPodman Desktopで設定したポートマッピングのおかげで、Spring Bootアプリケーションが実行されているように見えます（図9）。 図9: Spring BootアプリケーションがChromeで実行されている これでPetClinicアプリケーションがブラウザで実行されていることが確認できましたが、それだけではありません。ターミナルを呼び出す必要があるその他の機能については、代わりにPodman Desktopを使うことができます（図10）。これには、デバッグや設定変更のためにコンテナにSSH接続したり、コンテナのログを見たり、環境変数を調べたりすることが含まれます。これはすべて、コンテナの起動後に自動的に開く Container Details セクションで実行できます。 図10：Podman Desktopのターミナル まとめ ローカルのSpring Bootコードからアプリケーションをコンテナ化し、 Podman Desktop で実行するようになりました！今では、コンテナとして、 Quay.io や Docker Hub のようなレジストリを使用して、環境間でこのアプリケーションを共有し、 Kubernetes や OpenShift を使用して、様々な異なるクラウドプロバイダにデプロイすることができます。 関連の記事 Containerize a Spring Boot application with Podman Desktop Knative versus AWS Lambda and Azure Functions eBPF application development: Beyond the basics How to connect Kubernetes clusters with Service Interconnect Learning Go: Stale slices explained 関連のコンテンツ Deploying a Spring Boot App with MySQL on OpenShift Configuring Spring Boot Application on Kubernetes Deploy and test Kubernetes containers using Podman Desktop What is Podman Desktop? A developer's introduction

こんにちは、レッドハットサポートの クリス です。 大体、コンピュータの稼動に使われる電気エネルギーのほとんどは化石燃料によって生成されているので、気候変動に影響を与えます。電気も高いので、ITのエネルギー消費を把握するのは大切です。エネルギーを節約するための活動も増えています。2031 年までに消費電力を 40%削減するために 協力している企業もあります 。 Red Hat Enterprise Linux (RHEL) の Performance Co-Pilot (PCP) スイートは、パフォーマンス、デバッグ、可視化が出来ます。PCP には pmda-denki (日本語の電気という言葉で名付けた) が含まれています。pmda-denkiツールを使うと、電力消費量を測定できます。 powertopではリアルタイムでエネルギー消費量を測定できますが、長期的な測定はできません。PCPのメトリクスでは、メトリクスの保存、可視化、急激な増加への対応など利用できます。ワークロードの消費電力を比較するのは面白いと思いませんか？すでに多くの企業が、コミットしたばかりのソースコードの性能ベンチマークを行っている。コミットの消費電力を測定することで、新しいコードが効率的にはよくなったか、悪くなったか、分かります。 pmda-denkiは何ができるのか？ 現在のシステムには、消費電力を測定するための専用センサーはほとんどありません。この記事では、3つのデータソースを使用して、コンピュータのワークロードの電力消費が分かります： RAPL：最新のx86システムのほとんどはRAPLでCPU、RAM、オンボードGPUの電力消費が測れます バッテリーの充電状態： バッテリーを搭載したノートパソコンのようなシステムでは、電源プラグを外し、バッテリーからワークロードを実行することができます。バッテリーの放電を観察することで、消費量を計算することができます スマートプラグ： スマートプラグは、電源コンセントとコンピューターシステムのような電気消費機器の間に挿入できるデバイスです。スマートプラグは、WLANまたはRJ-45を介してネットワークに接続し、接続された消費者の消費電力を報告する 上記の3つの方法には長所と短所があります。RAPLはx86アーキテクチャでしか利用できず、システム全体の消費量を測定できません。バッテリーとスマートプラグは、特定のハードウェアを要ります。では、いくつかのワークロードの消費電力を測定しましょう。 研究環境 システム2台を使いましょう： 制御システム：データの収集と可視化のシステム。SUT を準備し、テストを開始するために、PCP と Ansible エンジンがインストールされています 消費量を測定する被試験システム（System Under Test, SUT）。今回は、Thinkpad L480を使いました。Thinkpad L480は、3つの方法すべてが利用可能で、Linuxのサポートが良いので、選びました 今回のpmda-denki研究環境 このテストでは、ワークロードを間実行し、3 つの方法でエネルギー消費量を測定します。その後、さまざまな方法で測定された消費量を比較し、システムがどの程度効率的であったか、また単一のジョブに対してどの程度のエネルギーを消費したかを計算することができます。 初期設定 制御システムはFedora 38とPCP 6を使用します。代わりにRHEL 8またはRHEL 9システムを使用することもできます。 $ sudo dnf -y install pcp-zeroconf pcp-pmda-denki $ cd /var/lib/pcp/pmdas/denki/ && sudo ./Install $ cd /var/lib/pcp/pmdas/openmetrics/ && sudo ./Install SUT は RHEL 9 を実行し、pcp と pmda-denkiをインストールし、制御シス テムが SUT から直接メトリクスを読み込めるように pmcd を構成しました。 $ sudo dnf -y install pcp pcp-pmda-denki pcp-system-tools $ cd /var/lib/pcp/pmdas/denki/ && sudo ./Install $ sudo echo 'PMCD_LOCAL=0' >>/etc/sysconfig/pmcd $ sudo systemctl restart pmcd $ sudo systemctl enable pmcd これを実行すると、制御システムの電気関係のメトリクスが読めます： $ pmrep -h <IP-of-SUT> denki 次に、スマートプラグのメトリクスを利用可能にします。詳細は、特定のスマート・プラグによって異なります。上品のプラグは、RJ-45イーサネットコネクターを使って消費メトリクスを提供します。この記事では、オープンソースのファームウェアTasmotaでサポートされているスマートプラグを使いました。スマートプラグは無線ネットワークに接続しています。制御システム上で、/etc/pcp/openmetrics/tasmotalive4.shというファイルを配置し、/var/lib/pcp/pmdas/openmetrics/config.d/tasmotalive4.shへのシンボリックリンクを作成しました。 このコマンドを実行してメトリックを照会すると、tasmotalive4.shが起動します： $ pmrep openmetrics.tasmotalive4 tasmotalive4.shというスクリプトはこれを出力されます： $ curl -s http://ip/cm?cmnd=Status%208 スクリプトは出力から消費電力を抽出します。このメトリクスはopenmetricsに渡され、pmrepで利用できるようになります。 3種類のメトリクスはすべて、制御システムから読むことができます。pmrepのようなクライアントで読み込むこともできるし、後で調べるためにアーカイブファイルに記録することもできます。 これでメトリクスにアクセスできるようになりました。例えば、以下はRAPL（1～4でラベル付けされた列）とtasmota（5列）のメトリクスであります： $ pmrep -g denki.rapl.rate -p openmetrics.tasmotalive4.Power [ 1] - denki.rapl.rate["package-0"] - /s [ 2] - denki.rapl.rate["core"] - /s [ 3] - denki.rapl.rate["uncore"] - /s [ 4] - denki.rapl.rate["dram"] - /s [ 5] - openmetrics.tasmotalive4.Power["0 var:out"] - none 1 2 3 4 5 17:38:13 N/A N/A N/A N/A N/A 17:38:15 4.578 2.289 0.000 0.183 8.000 17:38:16 4.973 3.978 0.000 0.000 0.000 17:38:17 4.855 2.913 0.000 0.971 12.000 17:38:18 5.046 3.027 0.000 0.000 12.000 17:38:19 6.208 4.138 0.000 1.035 12.000 ここの図形が出来ます： RAPL図形 今回のワークロード 上記のメトリクスが利用できるようになったので、SUT 上でワークロードを実行し、3 つの方法を使用して消費量を測定することができます。制御システム上で実行する Python3 ラッパースクリプトを作成しました。このスクリプトは、以下のタスクを実行します： Ansible playbook が SSH 経由で SUT にログインし、必要なパッケージがインストールします。Playbook はまた、実際の負荷スクリプトのようなファイルを SUT にコピーします スマートプラグの測定値が収集される場合、Ansible プレイブックは、制御システムが測定値をファイルにアーカイブするようにします。これにより、後でアーカイブファイルを確認し、負荷が実行されている間にスマートプラ グによって測定された消費電力を計算することができます その後、実際のワークロードが始まります。最初の負荷は、デフォルトで SUT 上でスリープを実行します。これは、後で計算ジョブに起因する負荷を適切に測定するために、可能な限り低くなければならないシステムのアイドル消費電力を提供する 次に、スクリプトにより SUT の全 CPU コアを負荷状態にします。最大消費量を測ります スクリプトは、ループで tar.xz ファイルを抽出し、抽出されたファイルを削除し、あらためて実行します。メモリ内で実行します。今回は、Apacheウェブ・サーバーのソースを抽出しています 最後に、スクリプトが少なくとも300秒間ループします。その期間、Apacheのソースをコピーし、'configure'を実行し、Apacheをコンパイルします 各ジョブの実行中の平均消費量を計算します。例えば、1回のApacheコンパイルにどれだけのエネルギーが消費されたかを計算します。 ここのスクリプトは例です。自分のワークロードを実行し、消費量を測定してください。例えば、あなたが書いたソフトウェアの2つのバージョンを実行し、それらの消費量を比較することができます。 ワークロードの消費量の測定 コンパイル・ジョブを実行したときの例： ### Running job_httpd_compile.sh for at least 300 sec.. executing: ssh -x chris@dennou "cd /dev/shm; ./job_httpd_compile.sh 300" Workload did run 8 times, a single job did run 37.5 sec. ### RAPL Average power consumption: 11.46 W Single job run, power consumption: 0.11934 Wh ### Battery Average power consumption: 16.68 W Single job run, power consumption: 0.17375 Wh それぞれの方法で測った消費量： Job name | RAPL | Battery | Tasmota sleep | 0.2W | 1.4W | 2.7W just-load | 18.4W | 23.6W | 28.2W httpd-src-extract | 11.5W | 15.7W | 18.2W httpd-compile | 11.5W | 16.7W | 17.6W 最初のジョブは5分間システムをスリープさせます。Thinkpad L480で実行すると、この5分間で平均0.2Wが消費されたことがRAPLから報告されました。バッテリー測定では1.4W、スマートプラグでは2.7Wと報告されています。このパターンは他の負荷でも発生します： RAPLはCPU/メモリ/GPUのみを対象としており、最も低い測定値を報告しています。バッテリーの測定は、マザーボード、USBデバイスなどをカバーしています。その測った値はもっと高いです。スマートプラグの値はもっと高いです。 ジャストロード・ジョブでは、md5sum /dev/urandomのインスタンスを４つも動かしています。RAPLは18.4Wになります。この負荷でファンも回転しています。この追加消費は、バッテリーとTasmotaメトリクスの値に入っています。 他の2つのジョブでは、全部のcpuコアが使われていないので、消費は下がります。 重要なことは、様々な方法は異なる値を報告しますが、どの方法もワークロードを比較するには適しているということです。あるソフトウェアの2つのバージョンがある場合、これらの方法はすべて消費量の比較に役立ちます。 制御システム上で実行するスクリプト（SUT上でジョブを実行する）と、それから準備のためのAnsibleスクリプトは、 私のGitリポジトリ から入手できます。ディレクトリdenki-jobrunnerにはジョブスクリプトがあり、openmetricsにはTasmotaスマートプラグからメトリクスを取得するスクリプトがあります。 それを気軽に使ってもよいですが、レッドハットサポート外となります。 消費電力メトリクス 消費電力メトリクスを利用可能にする方法と、さまざまなワークロードの消費電力を比較する方法が分かりました。利用可能な場合、pmda-denkiのバッテリーベースのメトリクスは、システム全体の消費電力を計算する事ができます。RAPLは一部のサブシステムをカバーしているだけですが、ほぼすべてのサーバーで利用可能です。PCP、pmda-denki、pmieを使用すれば、消費電力が突然上昇した場合にアラートを送信する事もできます。 KDEは持続可能性に関わるecoプロジェクトを開始し、フリーソフトウェアは持続可能なソフトウェアであるに関してのプレゼンテーションも増えています。pmda-denki のようなツールは、ワークロードの消費電力を比較し、新しいgitコミットが消費電力を増加させることに気づくのに役立ちます。 PCP/Grafanaをインストール、pmda-denkiメトリクスを可視化する方法のブログ記事 PCPのセットアップについての製品ドキュメント になります。新しいRHELバージョンがリリースされるとともに、更新されます。 PCP/Grafanaを設定するための対ラボ もあります pmda-denkiハンドブック にはインストールと使用例に関する詳細があります この記事の 英語版 もあります。

Red Hatのもえわきです。Red Hat Tech Night 2023運営チームからの熱烈な説得もとい依頼を受け、前回に続き、先週10/11に行われたRed Hat Tech Nightのハイライトをお伝えします。 Red Hat Tech Nightとは Red Hat Forum 2018（その後昨年からRed Hat Summit: Connectと名前を変えております）に合わせて、レッドハット日本法人のエンジニアの発案から、オープンソースの技術をより多くの人に広める活動としてはじまったこの勉強会、今回でなんと5回目の開催となりました。 2018年の開催に至った背景や経緯は、以下のブログ記事をご確認ください。 rheb.hatenablog.com コロナ禍でのオンライン開催を経て、とうとうオンサイトでの開催となった昨年のRed Hat Summit: Connectですが、開催を終え撤収、反省会と続くなか、多くの社員から聞こえてきた「Tech Nightないの？」「Tech Nightないと寂しいね」という声が印象的でした。そして今年2年目となったRed Hat Summit: Connectで、とうとう復活！発表された時はあの熱気を思い出して一気に期待が高まりました。 目次 Red Hat Tech Nightとは Red Hat Tech Night 2023レポート ハイライト1: 今年もやってきた「ライトニングトーク」 ハイライト2: ダイバーシティの象徴となった「パネルディスカッション」 さいごに 運営チームからひとこと Red Hat Tech Night 2023レポート Tech Nightと聞いて最初に頭に浮かぶのが「聴講者を置いてきぼりにする新感覚ミートアップ」「Red Hatの珍獣を眺める会」ですが、まずは合計100歳となる癖のある司会者の登場です。 打ち合わせ中のお二人。その手が動く被り物から目が離せません...。 ハイライト1: 今年もやってきた「ライトニングトーク」 今回のTech Night、一番の課題になったのは「時間」。運営チームが当初聞いていた時間がさらに短くなり、30分でプログラムを終わらせる必要が出てきました。 そんな厳しい条件のもと、多くの立候補者の中から選ばれたのは、以下の2つ。 タイトル: 5分で分かる！ Podmanの日本語最新情報 内容: 2023/9/16に発売された『Podmanイン・アクション』の紹介から、Podmanの参考文献やWebサイト、今後開催されるPodmanハンズオン、ウェビナーの紹介をします。 発表者: 田中司恩 a.k.a. podmanjp タイトル: Ansible Automation Platform 実行環境(Execution Environment)をおさらい 内容: Ansible Automation Platformの実行環境の変遷とPodmanコンテナを利用した最新のジョブ実行の仕組みについて解説します。 発表者: 八木澤健人 a.k.a. ひよこ大佐 今回、私が一番注目していたのがPodman。実はワタクシ、書籍『Podmanイン・アクション』の翻訳プロジェクトに参加したので、翻訳本が大スクリーンに映されることを楽しみにしてたのですが、そんな私のささやかな楽しみがふっとんだ、登壇者のこの姿をご覧ください。 おもわず三度見しちゃいました！ さすがの珍獣っぷりですね。ちなみにTech Nightの開催後、運営チームから「そういう恰好するなら先に言っておいてよ」とツッコミが入っておりました。 2つ目の発表は、Red Hat Summit: Connectでも注目が集まったAnsible。Ansible世界の平和を守る「ひよこ大佐」こと八木澤さんの登場です。Twitter（X）がきっかけでRed Hatに転職したというユニークな経歴をお持ちの八木澤さんは、導入部分から受ける印象とは異なるとっても真面目な発表をされ、非エンジニアのワタクシは見事に置いていかれました。 ハイライト2: ダイバーシティの象徴となった「パネルディスカッション」 Tech Nightと謳いながら一番長い時間が取られたのは、なんとパネルディスカッション。しかし、Red Hatでいま何がホットなトピックなのかがよくわかるセッションとなりました。 タイトル: 社内のいろんな人から見たRed Hat 内容: 技術職、営業職、採用担当など様々な役割の社員に、Red Hatの社内制度やパンデミック後のオフィス事情について率直な想いを語っていただきます。 Tech Nightは、その名前が示す通り、元々、Red Hatで日頃活躍されている「エンジニア」の皆様が自身のゴリゴリした技術を「聴講者（エンジニアであっても）を置いてきぼりにする」レベルで話をする会だったのが、コロナ禍を経て大きく変わってきました。一昨年に行われたオンライン開催で一番大きかった変化は、ワタクシのような「非エンジニア」が何人も登壇したことです。 2021年のオンライン開催については、以下のブログ記事をご確認ください。 rheb.hatenablog.com 今年もこの流れを踏襲したようです。またこれは、Red Hatが現在力を入れているダイバーシティを見事に表しており、エンジニア2名、営業1名、採用担当1名の登壇となりました。テック企業でありながら非テックが活躍する、そしてそれをテックの人も一緒になって盛り上げる、これがまさしくRed HatがRed Hatである所以です。テーマの内容も、メンタリングプログラムであったり、キャリアアッププログラムであったり、またコロナ禍で社員全員が完全リモートとなり、現在も出社が選択制のなか、Red Hatが大事にする「社員同士のつながり」をどのように維持しているのかと、社員の私でも非常に興味深いお話が色々と聞けました。ただ「上品」「ちゃんとしてる」「もっと暴れてほしい」「猛獣が足りない」（注: すべて誉め言葉です）と、私の横で発表を聴きながら、次回に向けて運営チームが改善点を話し合ってる姿が印象的でした。 そして閉会の挨拶では、司会が「通常は2時間枠だったので、次回は2時間やりましょう！」と自己判断で宣言していました。司会が話すとおり、この短い時間でRed Hatの珍獣達をご紹介するにはやはり足りないというのが多くの社員の共通認識になったと思います。そんなわけで、完全復活まではあと一歩なのかもしれませんが、オンライン開催など様々な形を模索してきた猛者達が今回も趣向を凝らしたものを作り上げてくれたので、楽しい一時を過ごすことができました。 さいごに 数年のブランクを経て、短時間でありながらとうとう復活した今回のオンサイトイベント、ご参加いただいた皆様いかがでしたでしょうか。配信がなく、展示スペースの一角にあるこじんまりとした会場で、まだまだ大きな声を出すのが躊躇われる環境でしたが、お食事されながら大画面をずっと見上げてる方だけでなく、イベントスペースの中でも外でも歓談される姿が多く見られました。その場で会話を楽しんでいる方達にちょっとしたトピックを提供する、そんな意味もこめて今回のイベントは大成功と言えるでしょう。運営チームの皆様、大変お疲れ様でした。そして、私もTech Nightの熱い雰囲気を存分に味わいたいので、次回のレポートはぜひ別の社員にお願いしてくださいネ！我こそはと思う方の立候補もお待ちしております！！ 運営チームからひとこと Tech Nightは有志ボランティアメンバーおよびマーケット部門の方々のコラボレーションにより、無事に終了致しました！ 第5回は規模を縮小したミニ開催でお送りしましたが、実は準備期間もTech Night史上もっともタイトなスケジュールでした。しかしながら、社員から社内チャットでTech Night開催の打診がポストされると、賛同のレスポンスとともに、わずか数時間で有志メンバーが結成されました。 そのような皆様のおかげで、限られた準備期間にも関わらず大盛況となりました。ありがとうございました。また次回開催の際にはより多くの方にご参加・関心を持って頂けると嬉しいです！ 最後になりましたが、ライトニングトークやパネルディスカッションに登壇いただいた皆さん、運営チームを支えてくださったすべての方、Twitterで会を盛り上げてくださったすべての方、そして当日会場に足を運んでいただいたすべての方に感謝を申し上げます。

Red Hatの小島です。 本記事では、AWS/Azure/GCP Marketplaceで提供している従量課金制のSelf-Managed OpenShiftについてご紹介します。 前置き 提供状況 利用時のポイント サポート 料金 参考情報 前置き Red Hat OpenShiftは、Red Hatから直接購入する場合、年間のサブスクリプション制のサービスとして利用できます。ただし、OpenShiftの利用方式はこれだけではなく、利用した分の料金が請求される従量課金方式もあります。こうした従量課金制のOpenShiftには、Managed OpenShiftサービスであるRed Hat OpenShift Service on AWS (ROSA)やAzure Red Hat OpenShift (ARO)などがありますが、ユーザーが管理するSelf-Managed OpenShiftもあります。ここでは、このSelf-Managed OpenShiftについて、AWS/Azure/GCP Marketplaceでの利用時のポイントをご紹介します。 提供状況 2023年10月時点では、日本のお客様には、AWS/Azure MarketplaceでのSelf-Managed OpenShiftは提供していません。これは、AWS/Azureのアカウントの居住国が日本として設定されている場合、利用がブロックされるという意味になります。この情報については、AWSとAzureで次のような手順で確認できます。 AWSコンソールの右上にあるアカウント名→「アカウント」をクリックして表示される「サービスプロバイダー」を確認 Azureコンソールの「Microsoft Entra ID」→左サイドメニューの「プロパティ」をクリックして表示される「国または地域」を確認 居住国が日本の場合、AWSの「サービスプロバイダー」は「Amazon Web Services Japan G.K.」と表示され、Azureの「国または地域」は「Japan」と表示されるようになっています。 一方で、GCP Marketplaceではそのような制限はなく、日本のお客様でもSelf-Managed OpenShiftを利用できるようになっています。 利用時のポイント AWS/Azure/GCP MarketplaceでのSelf-Managed OpenShift利用時のポイントは、下記となります。 Marketplaceのカタログなどにある申請リンクから、従量課金制OpenShift専用のサブスクリプションを、Red Hatにリクエスト 基本的なインストールと利用手順は、年間サブスクリプションのOpenShiftをAWS/Azure/GCPに持ち込む時と同じ AWS/Azure/GCP Marketplace用OpenShiftのイメージIDを、OpenShiftインストール時の設定ファイルで指定 Marketplaceのコンソールから直接インストールすることはできない Red Hatが24時間365日のプレミアムサポートを提供 All-In-Oneの1台構成と、3台構成はサポートされない OpenShiftのホストOSはRed Hat Enterprise Linux CoreOS (RHCOS)となり、RHELは利用不可 AWS/Azure/GCP Marketplaceでは、それぞれのクラウドプロバイダーで従量課金用のイメージを使えるようにするためのお作法(Marketplace製品のサブスクライブ手続きやイメージ利用条件の同意手続きなど)があったりしますが、基本的には持ち込みのOpenShiftサブスクリプションを利用する時と同じ手順でインストールして利用できます。Marketplaceのコンソールからのインストールはできませんので、ご注意ください。 従量課金用のOpenShiftイメージについては、ユーザーのアプリケーションを実行するコンピュートノードで利用します。コントロールプレーンとインフラノードについては、OpenShiftサブスクリプション料金がかからない、パブリックなイメージを利用します。従量課金用のOpenShiftのイメージIDを指定した、GCP MarketplaceでのOpenShiftインストール用設定ファイル(install-config.yaml)の例が下記です。従量課金用OpenShiftでサポートされる最小構成である、コントロール3台、コンピュート2台の5台構成となります。 additionalTrustBundlePolicy: Proxyonly apiVersion: v1 baseDomain: gcp.sampledomain001.io compute: - architecture: amd64 hyperthreading: Enabled name: worker platform: gcp: type: e2-standard-2 osImage: project: redhat-marketplace-public name: redhat-coreos-oke-413-x86-64-202305021736 replicas: 2 controlPlane: architecture: amd64 hyperthreading: Enabled name: master platform: gcp: type: n2-standard-4 replicas: 3 metadata: creationTimestamp: null name: mycluster01 networking: clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 machineNetwork: - cidr: 10.0.0.0/16 networkType: OVNKubernetes serviceNetwork: - 172.30.0.0/16 platform: gcp: projectID: myTestProject001 region: asia-northeast1 publish: External pullSecret: '{"auths":{"cloud.openshift.com": ... ,"email":"XXXXX@xxxxx.com"}}}' sshKey: | ssh-rsa ... OpenShiftインストール時の最小要件については、下記ドキュメントもご参照ください。 docs.openshift.com 持ち込みのOpenShiftサブスクリプションを利用する時との違いは、「compute.platform.gcp.osImage.{project,name}」でMarketplace用のOpenShiftイメージIDを指定しているところです。このサンプルでは、 OpenShift Kubernetes Engine (OKE) 用のイメージIDを指定しています。このイメージIDについては、「compute.platform.gcp.osImage.name」で、 OpenShift Container Platform (OCP) や OpenShift Container Platform Plus (OPP) 用のものを指定することもできます。GCP Marketplaceでの、それぞれのOpenShift 4.13用イメージIDは下記となります。AWS/Azure MarketplaceでのイメージIDは、これらとは異なるものとなります。 OKE: projects/redhat-marketplace-public/global/images/redhat-coreos-oke-413-x86-64-202305021736 OCP: projects/redhat-marketplace-public/global/images/redhat-coreos-ocp-413-x86-64-202305021736 OPP: projects/redhat-marketplace-public/global/images/redhat-coreos-opp-413-x86-64-202305021736 また、インストール後に、OpenShiftのMachinesetリソースで定義されている上記のイメージIDを変更することで、コンピュートノードが利用するイメージを変更できます。Machinesetの変更を反映するために、Machinesetに紐づいているコンピュートノードの削除と再作成を手動で実行する必要がありますが、これにより既存の年間サブスクリプションを利用して構築した、AWS/Azure/GCP上のOKE/OCP/OPPクラスターについて、Marketplaceのイメージを使うように切り替えることが可能です。 この年間サブスクリプションが、Red Hatが24時間365日のプレミアムサポートを直接提供するものの場合、1つのOpenShiftクラスター内で年間サブスクリプション用のイメージとMarketplaceのイメージを混ぜて利用することができます。 Machinesetの変更手順については、下記のドキュメントをご参照ください。 access.redhat.com サポート AWS/Azure/GCP MarketplaceでのSelf-Managed OpenShiftは、Red HatがサードパーティとしてMarketplace経由で販売しており、いずれの場合もRed Hatが24時間365日のプレミアムサポートを提供する旨を、Marketplaceのカタログの説明文に記載しています。そのため、ユーザーはRed Hatのサポートケースを作成するための、 Red Hatカスタマーポータル のRed Hatアカウントが必要になります。 インストールが完了すると、持ち込みのOpenShiftサブスクリプションを利用するときと同じく、60日間のSelf-Support評価版サブスクリプションが自動的に割り当てられた状態になっています。Red Hatからのプレミアムサポートを受けるために、サブスクリプションの設定を変更しておきましょう。これは Hybrid Cloud Console に表示された、該当クラスターをクリックした後に表示される「Edit subscription settings」から変更できます。 SLA はPremium、Support typeはRed Hat(L1-3)、Cluster usageは用途に応じて適切なものを選択、Subscription unitはサブスクリプションを数える単位となりますのでCores/vCPUsを選択して保存することで、サブスクリプションの設定変更を完了します。この設定については、後から変更できます。 料金 AWS/Azure/GCP MarketplaceでのSelf-Managed OpenShiftの利用料金は、OpenShiftのコンピュートノードに課金されるサブスクリプション利用料金と、クラウドプロバイダーのクラウドリソース(仮想マシン/ネットワーク/ストレージなど)の利用料金の合計金額となります。ユーザーはこの利用料金を、Red Hatではなく、クラウドプロバイダーに支払います。 OpenShiftのサブスクリプション料金は、AWS/Azure/GCP Marketplaceの全リージョンで統一されており、vCPUまたはコアの利用時間に基づく料金として設定しています。x86_64版とARM版(AWS限定)の、2023年10月時点のOpenShiftサブスクリプション料金は下記です。 OKE: $0.0371/vCPU/時間 または $0.0742/コア/時間 OCP: $0.1484/vCPU/時間 または $0.2968/コア/時間 OPP: $0.1855/vCPU/時間 または $0.371/コア/時間 前述したインストール用設定ファイル(install-config.yaml)のサンプルを利用して、実際にGCP Marketplaceで最小構成(コントロールプレーン3台+コンピュートノード2台の5台構成)のOpenShiftクラスターを、東京リージョンで26時間ほど起動してみた場合の利用料金は、大体$31となりました。こちらもご参考にしてください。 コントロールプレーン x3 (マシンタイプ:n2-standard-4, 4vCPU/RAM16GB) コンピュートノード(OKE) x2 (マシンタイプ:e2-standard-2, 2vCPU/RAM8GB) 参考情報 access.redhat.com access.redhat.com access.redhat.com AWS Marketplace イメージの取得 access.redhat.com Azure Marketplace イメージの選択 access.redhat.com GCP Marketplace オファリングの使用 access.redhat.com www.redhat.com

Red Hat のソリューションアーキテクトの瀬戸です。 この記事はRed Hat Developerのブログ記事、 What's new for developers in JDK 21 | Red Hat Developer を、許可をうけて翻訳したものです。 Java開発者にとってエキサイティングな情報として、今年 9 月 19 日に JDK 21 がリリースされました。 このリリースには、仮想スレッド(Virtual Thread)、レコードパターン(Record Patterns)、順序付コレクション(Sequenced Collections)など、Javaのエコシステムに利益をもたらす多くの新機能が含まれています。JDK 21 のプレビューには、文字列テンプレート(String Templates)、スコープ付値(Scoped Values)、構造化並列処理(Structured Concurrency)など、いくつかの興味深い機能もあります。この記事では、このリリースの 6 つの新機能について説明します。 仮想スレッド Virtual Thread Java の従来のスレッドモデルではアプリケーションがオペレーティング システム (OS) が処理できる以上のスレッドを作成すると即座に高コストの操作になる可能性があります。 また、スレッドの生存期間が長くない場合はスレッド作成のためのコストのオーバーヘッドが大きくなります。 仮想スレッド が導入されると、Java スレッドをキャリアスレッドにマッピングし、キャリアスレッドへのスレッド操作を管理 (つまりマウント/アンマウント) することで、この問題を解決します。キャリアスレッドは OS スレッドと連携して動作します。これは開発者に柔軟性と制御する余地を与える抽象化です。図 1 を参照してください。 図1: JDK 21の仮想スレッドモデル 以下は仮想スレッドの例であり、OS/プラットフォームのスレッドと比べた例です。プログラムは ExecutorService を使用して10,000 個のタスクを作成し、それらがすべて完了するまで待機します。JDK はこれらをバックグラウンドで限られた数の キャリア/OS スレッドで実行し、並列処理コードを簡単に作成できる安定性を提供します。 try ( var executor = Executors.newVirtualThreadPerTaskExecutor()) { IntStream.range( 0 , 10_000 ).forEach(i -> { executor.submit(() -> { Thread.sleep(Duration.ofSeconds( 1 )); return i; }); }); } // executor.close() is called implicitly, and waits ※訳注: スレッド作成のオーバーヘッドが強調されていますが、主な導入メリットはI/O操作が行われた時に実質的にスレッドでの処理が止まってしまい無駄なリソースが発生してしまうため、その余剰リソースを無駄にしないようになります。 構造化並列処理 Structured concurrency (Preview) 構造化並列処理 は仮想スレッドと密接に関係しており、キャンセル、シャットダウン、スレッド リークなどの一般的なリスクを排除する開発者のエクスペリエンスを向上させる API を提供することを目的としています。タスクが並列実行されるサブタスクに分割された場合、それらはすべて同じ場所、つまりタスクのコード ブロックに戻る必要があります。 図 2 では、 findUser と fetchOrder の両方を実行してそれぞれのサービスからデータを取得し、両方のデータを使用して結果を作成し、コンシューマーに応答として送り返す必要があります。通常、これらのタスクは並列に処理できますが、 findUser が結果を返さないといったエラーが発生しやすく、 fetchOrder は他の処理が完了するまで待ってから、最後に結合操作を実行する必要があります。 図2: 構造化並列処理のサンプル さらに、サブタスクの生存期間は親タスク自体の生存期間を超えることは出来ません。複数スレッドで非同期に実行される複数の高速な実行 I/O 操作の結果を合成するタスク操作を想像してください。構造化並列処理モデルは、仮想スレッド API と StructuredTaskScope を活用することで、スレッド プログラミングをシングル スレッド の 書き方の簡単さに近づけます。 Response handle() throws ExecutionException, InterruptedException { try ( var scope = new StructuredTaskScope.ShutdownOnFailure()) { Supplier<String> user = scope.fork(() -> findUser()); Supplier<Integer> order = scope.fork(() -> fetchOrder()); scope.join() // Join both subtasks .throwIfFailed(); // ... and propagate errors // Here, both subtasks have succeeded, so compose their results return new Response(user.get(), order.get()); } } スコープ付値 Scoped values (Preview) スコープ付値 は、 スレッドを使用したプログラミング時の生産性にも面白い変更をもたらします。 歴史的に、Java 開発者は、スレッド中の呼び出しチェーンを通して同じデータにアクセスするために、 ThreadLocal を使用してきました。 しかしながら、ThreadLocal変数を使用することで呼び出しチェーンを通してデータを変更するのも簡単に行えます。 そのため、プログラミングが難しくなり、時にはエラーが発生しやすくなり、安全でないコードになる危険性があります。 ScopeValue はスレッドがスコープ内でデータを変更できないようにしたデータを共有できるモデルを提供することでこの問題を解決することを目指しています。 ScopeValue のデータは不変であり実行時の最適化が可能になります。 セキュリティ プリンシパル、トランザクション、共有コンテキストを使用するマルチスレッドアプリケーションはスコープ付値の恩恵を受けます。 次の ScopeValue<String> の例は、 runWhere のスコープで作成および使用される実行可能なメソッドを示しています。 public class WithUserSession { // Creates a new ScopedValue private final static ScopedValue<String> USER_ID = new ScopedValue.newInstance(); public void processWithUser(String sessionUserId) { // sessionUserId is bound to the ScopedValue USER_ID for the execution of the // runWhere method, the runWhere method invokes the processRequest method. ScopedValue.runWhere(USER_ID, sessionUserId, () -> processRequest()); } // ... } 順序付コレクション Sequenced collections JDK 21では、コレクションの使用エクスペリエンスを向上させるために、新しいコレクション インターフェイスが導入されています (図 3)。たとえば、使用中のコレクションによっては、コレクションから要素を逆の順序で取得することが面倒な作業になる可能性があります。使用されているコレクションによっては、逆順の取得に不一致が発生する可能性があります。たとえば、 SortedSet は順序を実装していますが　 HashSet は順序を実装していないので、異なるデータセットでこれを実現するのは面倒です。 図3: 順序付コレクション ※訳注: 図ではSequencedSetがSequencedCollectionを継承していないように見えますが、実際には継承しています。 これを解決するために SequencedCollection インターフェースに逆順で取得するメソッドや最初と最後の要素を取得する機能を追加してアクセス順序を補助します。 さらに SequencedMap と SequencedSet インターフェースもあります。 interface SequencedCollection<E> extends Collection<E> { // new method SequencedCollection<E> reversed(); // methods promoted from Deque void addFirst(E); void addLast(E); E getFirst(); E getLast(); E removeFirst(); E removeLast(); } そのため、アクセス順序に一貫性を持たせるだけでなく、最初と最後の要素を削除したり追加したりすることもできるようになりました。 レコードパターン Record patterns レコードは Java 14 でプレビューとして導入され、Java 列挙型も提供されました。 record は Java の特殊な型であり、データ キャリアとしてのみ機能するクラスの開発プロセスを容易にするために実装されました。 JDK 21 では、 レコードパターン と型パターンをネストして宣言的で構造的な形式のデータ ナビゲーションと処理を可能にすることができます。 // To create a record: Public record Todo(String title, boolean completed){} // To create an Object: Todo t = new Todo(“Learn Java 21 ”, false ); JDK 21 以前では、アクセサーを扱うにはレコード全体にアクセスする必要がありました。しかし、現在では値の取得がはるかに簡素化されています。例えば次のようになります： static void printTodo(Object obj) { if (obj instanceof Todo(String title, boolean completed)) { System.out.print(title); System.out.print(completed); } } レコード パターンのもう 1 つの利点は、ネストされたレコードとそれ自体へのアクセスです。JEP 定義での例は、 Rectangle にネストされている ColoredPoint の一部の値を取得する機能を示しています。これにより、毎回すべてのアクセサーを経由していく必要があった以前よりもはるかに便利になります。 // As of Java 21 static void printColorOfUpperLeftPoint(Rectangle r) { if (r instanceof Rectangle(ColoredPoint(Point p, Color c), ColoredPoint lr)) { System.out.println(c); } } 文字列テンプレート String templates (Preview) 文字列テンプレート はJDK 21 ではプレビュー機能です。しかし、インジェクションなどの望ましくない結果につながる可能性がある一般的な落とし穴を回避できるため、 String の操作の信頼性とエクスペリエンスが向上します。テンプレート式を書いて、それを String でレンダリングできるようになりました。 // As of Java 21 String name = "Shaaf" String greeting = STR. "Hello \{ name}" ; System.out.println(greeting); この例では2 行目は式であり、呼び出すと Hello Shaaf が表示されるはずです。 さらに、不正な String （SQL文やセキュリティ問題を引き起こす可能性のあるHTMLなど）が存在する可能性がある場合、テンプレートのルールはエスケープされた引用符のみを許可し、HTMLドキュメント内の不正なエンティティを許可しません。 ※訳注: 元の文章でSTR.が抜けていたのを直しました。 Java のサポートを受けるには OpenJDK と Eclipse Temurin のサポートは Red Hat Runtimes やRed Hat Enterprise Linuxおよび Red Hat OpenShift のサブスクリプションを通じて Red Hat のお客様に提供されます。 詳細については、お近くの Red Hat 代理店または Red Hat 営業 にお問い合わせください。Java やその他のランタイムのサポートポリシーは、 Red Hat Application Services 製品のアップデートとサポートポリシー に記載されています。 ※訳注: JBoss EAPを含むRed Hat RuntimesはWindows上でも動作します。また、Windows上でのOpenJDK単体のリーズナブルなサポートや、Oracle Javaからの移行に対するご相談も受け付けておりますので お問い合わせください 。 リソース Video: What is Eclipse Temurin? Getting started with Eclipse Temurin Red Hat joins the Eclipse Adoptium Working Group Eclipse Adoptium achieves its first Java SE release Red Hat Introduces Commercial Support for OpenJDK on Microsoft Windows The history and future of OpenJDK ※2023/09/25 文章を調整しました。 @skrb , @yusuke , @kis Thanks!

こんにちは、Red Hatでソリューションアーキテクトをしている石川です。 5月末に行われたRed Hat Summitの中でRed Hat OpenShift AIが発表となりました。 www.redhat.com 上記リンクのニュースリリースにもあるように、OpenShift AIではOpenShift上でAI/MLモデルの学習/提供基盤環境を実現することを目指しています。その一方で、既にOpenShiftにはOpenShift Data Scienceというアドオン製品も存在しており、それらがどういった関係になるのか疑問を持たれた方もいらっしゃるかも知れません。 今回のブログではその辺りの情報を補足しつつ、現在予定されている幾つかの機能について解説していきたいと思います。 OpenShift AIの位置付け まず始めにOpenShift AIとはそもそも何なのかという点についてです。 こちらについて一言で表すならばOpenShift上で利用可能なAI/MLのプロダクトポートフォリオとなります。つまりOpenShift AIそのものは製品やサービスではなく、そうしたものを取りまとめる総称だと捉えて頂くと良いです。 ではこのOpenShift AIに含まれる製品が何かというと、Red Hat OpenShift Data Science(RHODS)になります。 RHODSはAI/MLの開発ライフサイクルをサポートする様々なOSSを統合して提供する製品で、OpenShiftのアドオンとして利用することが可能となっています。 インストール方法や機能の詳しい紹介については以前のブログについても合わせて参照下さい。 rheb.hatenablog.com rheb.hatenablog.com 現在OpenShift AIに含まれるのはRHODSのみとなりますが、今回Red Hat Summitの中であえてこうした発表を行なったのは、今後この領域に対してRed Hatがより注力していくことの表れとも言えるでしょう。今後の更なる発表にもご期待ください。 OpenShift Data Scienceに新たに追加された機能 今回のRed Hat Summitの中で、RHODSに対する新たな機能追加としてData Science Pipelinesの提供が発表されました。 Data Science PipelinesはOSSの Kubeflow Pipelines をRHODSの一機能として利用可能としたものです。データの取得や前処理、学習、検証といったデータサイエンスの各プロセスをコンポーネント化しパイプラインとして定義することで、繰り返し行う作業の自動化やコードの再利用性を高めることが可能となります。 アップストリームのKubeflow Pipelinesでは、実際のパイプライン実行を行うワークフローエンジンとしてArgo WorkflowとTekton Pipelinesのどちらかを選択する形となりますが、RHODSのData Science PipelinesではOpenShift Pipelinesと連携し、Tektonでの実行がサポートされています。 またこのData Science Pipelinesでは Elyra というツールを使ってGUIを使ってパイプラインを定義することも可能となっています。既にあるPythonスクリプトやNotebookファイルを組み合わせてパイプラインを組むことができるため、ツール導入に伴う学習コストを下げることができます。 大規模モデル学習への対応 今回のSummitの発表の中で生成AIを利用したサービスとして Ansible Lightspeedが発表 されました。 このサービスで利用されているモデルはIBMが提供予定である基盤モデルをAnsibleのコード生成用にカスタマイズ（転移学習）したものです。実は元となる基盤モデルの学習や転移学習はOpenShiftとRHODSのアップストリームであるOpen Data Hubプロジェクトを利用して行われています。 （画像は IBM ResearchのBlog より） 基盤モデルのような大規模モデルを学習させる場合、一つのGPUだけではモデルのパラメータ等の情報を保持するための必要なメモリが足りないため、複数のGPUによる分散学習を行う必要があります。 CodeFlare はOpen Data Hubの一部となる分散学習のためのプロジェクトで、以下のツール群を包含します。 ・CodeFlare SDK: Code Flareの各ツールをPythonで利用するためのSDK。 ・MCAD: バッチ処理を効率的に行うためのPodのスケジューリング機能(e.g. Gang Scheduling)を提供。 ・InstaScale: ジョブ要求に応じてオンデマンドにクラスタにGPUノードを追加。 ・KubeRay: K8s上に分散処理を行うための Ray クラスタを構築。 現在（2023年7月時点）はこれらの機能はRHODSでは提供されていませんが、今年の下半期中には機能追加が行われる予定です。 まとめ 本記事ではOpenShift AIについて紹介させて頂きました。今後もRHODSに対する更なる機能追加や、RHODS以外の新規の製品、サービスの発表が期待されます。是非OpenShift AIに注目して見て下さい。 最後にデモ動画を紹介します。以下ではHugging Faceより取得してきたモデルを元に転移学習を行い、モデルのサービングまで実施しています。面白い内容なので良ければチェックしてみて下さい。 www.youtube.com

Red Hatでソリューションアーキテクトをしている田中司恩( @tnk4on )です。 この記事は Red Hat Developer の Managing Java containers with Quarkus and Podman Desktop を、許可をうけて翻訳したものです。 本記事で紹介する Podman や Podman Desktop に関する情報を日本語で紹介するTwitter アカウントがあります。こちらもフォローして情報収集に活用ください。(ハッシュタグ #podmanjp ) Podman( https://t.co/ipoaatoD4a )の非公式Twitterアカウント。 #Podman に関する情報を日本語で配信中。ツイートは個人のものであり特定の組織や企業を代表するものではありません。The unofficial Twitter account for Podman. Tweets are my own. #podmanjp — podmanjp (@podman_jp) July 9, 2023 ソフトウェア開発の世界は急速に変化しており、 Java 開発者も例外ではありません。Javaコンテナを管理するために新しいスキルを学ぶ必要があります。 従来のJava開発の世界では、Javaアーティファクト（それが.jarであれ、.warであれ、.earであれ）を構築し、「壁の向こうに放り投げて」ミドルウェアや運用担当者に引き渡すのが一般的でした。というのも、エンタープライズ・アプリケーション・サーバーの設定と実行は必ずしも簡単ではなく、最終的には、開発者のラップトップはステージング環境や本番環境の仕様とおそらく一致しないため、いずれにせよ設定が異なってしまうからです。結局のところ、私たちは皆、「私のマシンでは動く」という決まり文句を知っています。 最近では、物事はより速く、より優れたデリバリー(delivery)を必要とし、本番環境での問題は、しばしば非常に迅速な方法で解決する必要があります。というのも、ダウンタイムの1秒1秒が、組織の収益損失を引き起こす可能性があるからです。アプリケーションを提供する新しい方法が考え出され、それに伴い、クラウドネイティブ・アプリケーション、 コンテナ 、 DevOps が登場しました。「でも、私のマシンでは動いた」という言い訳はもはや通用しません。 Java開発者はコンテナで作業できる必要があります。コンテナは、ローカル・マシンの本番環境に近い環境でアプリケーションをテストする実用的な方法だからです。開発者や組織の中には、ローカルマシンからクラウドへと開発を移行し、IDE 自身を再現可能なコンテナ化された環境で実行することで、一貫性をさらに高めることを選択する人もいます。 Red Hat OpenShift Dev Spaces はこれを実現する1つの方法ですが、この記事の範囲外です。 Javaを使用したコンテナの構築 しかし、コンテナの構築と管理は、Java開発者にとってはすぐに圧倒されてしまいます。表面的には、アーティファクトをベース・イメージにコピーする指示とともに Dockerfileを作成し、Dockerビルドを行う「だけ」の問題です。しかし実際には、アプリケーションからコンテナイメージを作成するには、それ以上に多くのことを考慮する必要があります。 ベースイメージの選択 まず始めに、ベースイメージが必要です。ゼロから始めて依存関係を個別に追加するのか？それともすでにJava仮想マシン（JVM）実装が含まれているベースイメージを使うのか？あるいは、アプリケーションの ネイティブビルド を選択し、コンテナ内でJVMを実行する必要がないかもしれません。いずれにせよ、テスト済みでセキュリティが確保され、理想的には署名され、 Open Container Initiative (OCI) に準拠し、対象としている特定のJavaバージョンの安定したイメージを提供している信頼できるソースを見つける必要があります。そして願わくば、このソースがサポートを提供し、将来にわたってパッチを保守し、バックポートしてくれることを期待します。ベースイメージは、おそらくパフォーマンスを最適化するためのチューニングも必要になるでしょう。 Red Hatの Universal Base Images (UBI) は、コンテナイメージを構築するための良い出発点です。UBIは 無償で使用でき 、Red Hat Enterprise Linux(RHEL)ディストリビューションのサブセットを中核としており、コンテナ構築のための安定した、安全な、最適化された、信頼性の高い基盤を提供すします。いくつかの JVMベースのUBIイメージ が利用可能で、ネイティブバイナリをデプロイするためのUBI-microもあります。 コンテナ・イメージの構築 ベースイメージが決まったら、コンテナイメージをビルドする方法が必要になります。最もよく知られている方法は、Dockerfile（またはContainerfile）を作成し、それをDockerでビルドすることです。 しかし、これはコンテナをビルドする唯一の方法ではありません。同じContainerfileを使ってPodmanでイメージをビルドすることもできます。Podmanは完全にオープンソースのコンテナエンジンで、 Dockerエンジンよりもかなり多くの機能を備えています 。また、 Buildah という、コンテナイメージを構築するために特別に作られた別のオープンソースツールを使うこともできます。 Containerfileを必要とせずにコンテナをビルドする方法もあります。 Source2Image (S2I) 、 Buildpacks 、 Jib などのビルドツールがあります。これらのツールの複雑さはさまざまですが、いずれもコンテナのビルドプロセスを合理化することを目的としており、特に開発者にとっては便利です。 例えば、JibはJavaでコンテナイメージをビルドするために特別に作られたビルドツールです。S2Iは、ソースコードを受け取って、それがどのようなアプリケーションなのかを調べるためにイントロスペクションを行い（例えば、 pom.xml があればJavaアプリケーションであることを示す）、S2Iツールによって事前に定義されたビルドイメージや、ユーザーによって提供されたカスタムビルドイメージを使用して、アプリケーションのソースコードからコンテナイメージをビルドするツールです。Buildpacksも同様に動作しますが、Buildpacksビルダーイメージが必要です。 デメリットとしては、これらのコンテナビルドツールごとに特定のコマンドラインインターフェース（CLI）プログラムをインストールし、それらの使い方を理解する必要があるということです。さらに、これらのビルドツールが使用するベースイメージ (該当する場合) を知るか、自分で用意し、それらが安全に使用できるかどうかを判断する必要があります。 コンテナ用語の詳細については、Scott McCartyが この記事 で包括的な紹介をしています。 QuarkusがContainerfileをどのようにサポートするのか Quarkus はJavaスタックで、Java開発者がクラウドネイティブな開発を容易にできるようにすることを目的としています。Quarkusは、 Quarkus CLI の quarkus create app コマンドの実行や、 code.quarkus.io 上でのスタータープロジェクトの生成、VS CodeやIntelliJでの Quarkusプラグイン の使用など、開発者がQuarkusアプリケーションをブートストラップした瞬間からContainerfileを提供します。 新しいQuarkusアプリケーションをブートストラップすることで、 src/main/docker に、この記事で以前に紹介したUBIイメージに基づく事前に準備されたContainerfile（この場合、 Dockerfile.* という名前）が入ったフォルダが作成されます（図1）。 図1：アプリケーションのブートストラップ時にQuarkusが提供するDockerfile Quarkusには、使用ケースに応じて4種類のコンテナファイルが用意されています： Dockerfile.jvm はデフォルトで使用され、QuarkusアプリケーションをJVMモードで実行するJavaコンテナを構築します。 Dockerfile.legacy-jar`はlegacy-jarパッケージングタイプ( Quarkusのlegacy対fast-jarの詳細 )の場合に使用されます。 Dockerfile.native はネイティブにコンパイルされたQuarkusアプリを実行するためにJVMなしのUBIを使用します。 Dockerfile.native-micro はネイティブのQuarkusアプリを実行するための カスタムビルドのUBI-microイメージ です。 これらのコンテナファイルは通常のDockerやPodmanコマンドで使用できますが、QuarkusではMavenやGradleなどのビルドツールから直接コンテナイメージをビルドすることもできます。基本的には、例えば mvn package quarkus:image-build でイメージをビルドすることができ、QuarkusはデフォルトでQuarkusプロジェクトに付属している Dockerfile.jvm を使用してコンテナイメージを自動的にビルドします。 同様に、ネイティブにコンパイルされたバイナリを実行するJVMなしでイメージをビルドするには、コマンド（この場合はMaven）に --Dnative パラメータを追加するだけです。 後者のコマンドには1つ注意点があります。 GraalVM Native Image Builder の実行ファイル（native-imageと呼ばれる）をインストールする必要があります。しかし、Quarkusには、native-image実行ファイルをローカルにインストールすることなく、GraalVMのNative Image Buildを活用する代替方法があります。Quarkusは実際、ネイティブイメージ実行ファイルがないことを検出し、ネイティブJavaコンパイルを行うビットを含むコンテナイメージのダウンロードを試み、コンテナ内でネイティブバイナリを実際にビルドします（もちろん、DockerまたはPodmanがインストールされていることが前提です）。ネイティブ・バイナリー・ビルダー・イメージは Mandrel に基づいています。これはGraalVMコミュニティ・エディションのダウンストリーム・ディストリビューションで、特にQuarkusをサポートするためのネイティブ・イメージ・リリースを提供することを主な目的としています。 Quarkusを使ったCLIのさらなるマジック Quarkus CLI は、要するに、MavenやGradleビルドツールの便利なラッパーであり、プロジェクトの作成、Quarkusの開発モードやテストモードでの起動、拡張機能の管理、ビルド、開発、デプロイを行うことができます。ツールを切り替えることなく、完全なインナーループ開発体験をコントロールする方法を提供します。 Quarkus CLIのおかげで、 quarkus image build のような覚えやすいシンプルなコマンドを実行できます。舞台裏では、Quarkusが選択したビルドツールを起動し、アプリケーションをパッケージ化し、前述のContainerfileとローカルのDockerまたはPodmanインスタンスを使用してコンテナイメージをビルドします（図2を参照）。 同様に、JibまたはBuildpacksを使用するには、同じコマンドを実行し、 quarkus image build jib または quarkus image build buildpack のように、好みのコンテナビルドツールを追加で指定します。 図2：Quarkusイメージビルドの実行後のイメージビルドの成功メッセージ Quarkus CLI では、 quarkus image push を使用して、コンテナイメージをレジストリにプッシュすることもできます。例えば、 quarkus image push --also-build のように--also-buildフラグを追加することで、アプリケーションのビルド、コンテナのビルド、コンテナのプッシュを一度に行うことができます。あるいは、ネイティブにコンパイルされたバイナリとして、 quarkus image push --also-build --native とすることもできる。 Podman Desktopでコンテナを管理・実行する コンテナイメージがビルドされたら、そのコンテナが実際に動作することを確認したり、他のアプリケーショ ンで使用したりするために、コンテナを実行したくなるでしょう。 podman run や docker run といったPodmanやDockerコマンドの使い方を学ぶこともできますが、ポートの公開、ボリュームのマウント、コマンドの実行など、少なくともこれらのツールに関する専門知識が必要になります。 Podman Desktop は直感的なユーザーエクスペリエンスでコンテナの実行と管理をより簡単にするUIツールです。Windows（WSL付き）、macOS、Linuxにインストールでき、必要に応じて基礎となるPodmanユーティリティもインストールされます。 図3に示すように、コンテナイメージの横にあるPlayボタンをクリックすると、イメージビューからコンテナを起動できます。その後、コンテナのランタイム設定をカスタマイズしたり、イメージの EXPOSE 値（Quarkus ではデフォルトで 8080 ）に基づいてコンテナの外部ポートをアプリの内部ポートに自動的にマッピングさせたりすることができます。Podmanは、マシン上の別のプロセスが既にそのポートを使用しているかどうかを自動的に把握し、コンテナの外部ポートを別のポートに割り当て直すことができる。これは優れた機能であり、通常システム管理者の領域である netstat や lsof のようなコマンドを使って、自分のマシンでポートが使われているかどうかを手動で調べなければならないのとは対照的です。 図3：Podman DesktopのImagesビューにコンテナを起動する「play」ボタンがある Podman Desktopのその他の機能 Podman Desktop はコンテナを実行するだけではありません。例えば、デバッグやアクセス、あるいは設定を変更するためにコンテナに ssh で入りたいかもしれません。それには、CLI を使って、（例えば podman ps で）コンテナ名を調べて、 podman exec -it CONTAINER_ID /bin/bash のようなコマンドを覚えておく必要があります。Podman Desktop では、コンテナビューでコンテナを選択して Terminal タブをクリックするだけです。 図4：Podman Desktopを使ってコンテナ内のターミナルでコマンドを実行する 同様に、コンテナのログにアクセスしたい場合は、 Logs タブをクリックします。また、コンテナの状態を検査したい場合、例えば、使用しているファイルシステムや設定されている環境変数などを確認したい場合は、 Inspect をクリックするだけです。 Kubernetes以外でPodを使う Podman Desktopはその名の通り、コンテナをPodとして実行することもできる。例えば、キャッシュデータベース（Redis や Infinispan）のような別のコンテナを実行し、アプリケーションのコンテナと組み合わせてPodにすることができます。 Kubernetes と Podman Desktop Podman DesktopからKubernetesインスタンスにコンテナやPodを直接デプロイすることも可能です（図5）。そのためには、Podman Desktopビューの右上にあるロケットアイコンをクリックするだけです。Podman DesktopはKubernetesコンテキストを検出し（ kubectl login などでKubernetesクラスタにログインしている場合）、コンテナをPodとしてクラスタにデプロイします。 図5：KubernetesへのデプロイボタンがハイライトされたPodman Desktopのログビュー Kubernetesクラスタが利用できない場合、Podman Desktopの設定で利用できるKind拡張機能を使ってKubernetes-in-Docker（Kind）クラスタを起動できます。 もう一つの選択肢は、コストのかからない Developer Sandbox for Red Hat OpenShift インスタンスを作成することです。 developers.redhat.com/developer-sandbox にアクセスし、Create a free OpenShift Sandbox instance に従ってプロビジョニングできます。これで、コンテナ化されたアプリケーションをデプロイするために使用できる、完全に機能する Kubernetes インスタンスが手に入ります！ 今すぐ始める Javaコンテナの構築と実行は、ここ数年で非常に簡単になりました。Quarkusのようなフレームワークや、Podman Desktop、OpenShiftのようなツールを使うことで、クラウドネイティブの世界に慣れていないJava開発者でも、コンテナを使って簡単に作業を始めることができます。 Quarkusアプリケーションの作成 、 コンテナイメージへのビルド 、 Podman Desktop上での実行 を今すぐお試しください。 追加のリソース What is Podman Desktop? A developer's introduction Podman Desktop 1.0: Local container development made easy Tutorial: Deploy and test Kubernetes containers using Podman Desktop Kubernetes-native inner loop development with Quarkus Learn Quarkus faster in the Developer Sandbox for Red Hat OpenShift Build your first Java serverless function using a Quarkus quick start Quarkus for Spring developers: Kubernetes-native design patterns 関連の記事 Enable user-managed networking with ZTP How to use Debezium SMT with Groovy to filter routing events How to use Kafka Cruise Control for cluster optimization A developer’s guide to secure coding with FORTIFY_SOURCE Managing Java containers with Quarkus and Podman Desktop 関連のコンテンツ Deploy and test Kubernetes containers using Podman Desktop What is Podman Desktop? A developer's introduction Podman Desktop 1.0: Local container development made easy Cloud-native Java applications made easy: Eclipse JKube 1.0.0 now available Quarkus, a Kubernetes-native Java runtime, now fully supported by Red Hat

こんにちは。レッドハットで OpenShift とかストレージとかを生業にしている宇都宮(うつぼ)です。 なんだか久しぶりな感じがしますが、今回は Red Hat Trusted Software Supply Chain について話します。 今年の5月にアメリカで Red Hat Summit 2023 が開催されました。その中では様々な新しいプロダクトやサービスが発表されました。 その中の一つが Red Hat Trusted Software Supply Chain (RHTSSC) です。 TL;DR 無理やり3行でまとめてみます。Red Hat Trusted Software Supply Chain とは、 Red Hat OpenShift 上でセキュアなソフトウェアサプライチェーンの実装を実現する、Red Hat のマネージドサービスである。 Red Hat Trusted Content, Red Hat Trusted Application Pipeline など複数のサービスを使い、Red Hat が持つ DevSecOps のプラクティスを適用できる。 現在は "サービスプレビュー" 状態でまだ GA ではないが、waitlistに登録することはできる。 こういうものです。 急増するサプライチェーン攻撃 専門家じゃないヤツが偉そうに言うのもなんですが、ソフトウェアサプライチェーンとはざっくり言えば、アプリケーションが生み出され初めて使われなくなるまで、ゆりかごから墓場までに関わってくるあらゆる構成要素や依存関係の総称です。 開発者が生み出すコードはもちろんのこと、パッケージやライブラリ、パイプラインツールやビルドツール、Git、テストツール、成果物のリポジトリ、ベースイメージ、コンテナレジストリ、コンテナプラットフォーム、、、挙げればキリがありません。 これほどまでたくさんあると、残念ながらどうしても攻撃を受けてしまう隙が生じるものです。 コードにおいては OSS コミュニティで公開されているパッケージやライブラリを活用することもあるでしょうし、その他も公開されているソフトウェアやツール類を使うことが多いでしょう。 こういった誰もが利用できるものが攻撃を受けやすいのです。 例えば CI パイプラインに侵入されてしまうと、Git リポジトリへの経路ができます。この後コードから機密情報を引き抜かれてしまったり、悪意のあるコードを差し込んだりなど、やりたい放題されてしまいます。 PyPI や npm といったツールで何気なくパッケージをインストールすると、実は悪意のある人間によってバックドアが仕込まれたもので、そこから攻撃されてしまうといったこともあります。 こういったソフトウェアサプライチェーンへの攻撃は、 Sonatype 社のレポート によると過去3年間で742%も激増しています。したがって、こういった攻撃への対策は急務です。 Red Hat Trusted Software Supply Chainってナンだ Red Hat Trusted Software Supply Chain (RHTSSC) は、こういった攻撃への対策を施した、セキュアなソフトウェアサプライチェーンの実装を実現します。 セキュアなソフトウェアサプライチェーンを作るには、いわゆる DevSecOps と呼ばれる手法を使いますが、そうですかそれではやります、と言えるほど簡単ではありません。 何をどうどの程度セキュリティ対策すれば丁度良いのか、など様々なことに関する深い知識と経験に基づくアプローチを取ることが理想的です。 RHTSSC では、Red Hat の知識と経験に基づいた DevSecOps のプラクティスを利用することができます。 RHTSSC はマネージドサービスであり、Red Hat Hybrid Cloud Console からアクセスすることができます。 RHTSSC はこれ自身の名前のサービスがあるわけではなくて、いくつかのサービスを併用した総称です。 Red Hat Trusted Application Pipeline (RHTAP) https://console.redhat.com/preview/hac/application-pipeline Red Hat Trusted Content (RHTC) https://console.redhat.com/preview/application-services/trusted-content Red Hat Advanced Cluster Security Cloud Service (RHACS Cloud) https://console.redhat.com/preview/application-services/acs/overview もちろんそれぞれのサービスは別々に利用することが、えー、、でき、、ます。。。かな？💧 なんで歯切れが悪いのかと言うと、この3つのサービスはまだ一般的には使えないからです。 RHTAP と RHTC、この2つは、現在 "サービスプレビュー" というステータスで、まだ GA されたサービスではありません。 そして RHACS Cloud は "Limited Available" といって利用できるユーザーさんが限定されています。近いうちに米国と欧州で GA 予定ではありますが、日本ではその先です。 そういうことで、今日明日すぐ使えるというものではないのです。以後の紹介はそういった前提でご覧いただけると幸甚の至りでございますです。 お試しで使ってみたいなぁ、という方は、waitlist に登録して専用の Slack Channel に参加すると、使い方を教えてもらえると思います。 Red Hat Trusted Application Pipeline RHTAP は主にマネージドサービス型の OpenShift Pipeline/Gitops と考えていただいて構いません。 この中でセキュリティ対策を盛り込んだ標準のパイプラインがあって、これを活用する形になります。パイプラインはカスタマイズもできます。 パイプラインの中でアプリケーションの SBOM(Software Bill of Materials) が作られます。 SBOM はサプライチェーンの要素一覧表のようなものです。SBOM と外部の脆弱性データベースを照会することで、実はハイリスクな脆弱性をはらむ OSS を意図せず使っていたりする場合に気づくことができます。 また、パイプライン中で生み出されたコンテナイメージや SBOM などの成果物に署名をすることができます。 成果物に署名することで、攻撃者によるマルウェアなど出元不明なソフトウェアを入れ込まれたり、改ざんされたりするリスクを下げられます。 Red Hat Trusted Content RHTC は開発するアプリケーションのセキュリティチェックをします。vscode などのコードエディタにプラグインとして稼働します。 RHTC はアプリケーションが依存するパッケージやソフトウェア診断し、脆弱性や OSS ライセンス違反などを検出してくれます。 また Red Hat が提供するパッケージについては、その SBOM と VEX(Vulnerability Exploitability eXchange) を入手することができます。 VEX とは、SBOM と脆弱性 DB から検出された脆弱性が実際にアプリケーションに影響を及ぼすかを評価する上で役立つものです。 SBOM と VEX の関係性については、 こちらのブログ が詳しく書かれています。 これは実は Red Hat Dependency Analytics という既存のサービスとほぼ同じで、これが利用できるとイメージしていただいても大丈夫かなと思います。 Red Hat Dependency Analytics についてはこちらの記事に詳しいので、こちらをご覧下さい。 Red Hat Advanced Cluster Security Cloud Service RHACS Cloud は、セルフマネージの Red Hat Advanced Cluster Security (RHACS) のマネージドサービス版です。 RHACS との機能的な違いもほぼなく、RHACS については過去にも何回か記事で取り上げられていますので、ここでは説明は省略します。 まとめ というわけで、Red Hat Trusted Software Supply Chain の簡単な紹介をしました。 サイバー攻撃は極めて多岐にわたるため全てを網羅的に対策することは極めて難しいと言えます。しかも、ITセキュリティは結構専門的な分野なので分かる人材は多くありません。 しかし何も対策しないでおくことは許されない。専門家でなくとも自衛できる範囲では自衛することが必要です。 前述の通り、サプライチェーン攻撃は急増しています。誰もが知っているような先進的な企業でも被害に遭っており、対策は急務です。 セキュリティ対策の基本は、脅威の認識と予防、迅速な検知、そして素早い対応ですが、ソフトウェアサプライチェーンでこれらを広くカバーするのが Red Hat Trusted Software Supply Chain です。 残念ながら今はまだGA前ですが、こういったサービスも Red Hat は提供しているんだと頭の片隅に置いていただければ幸いです。 というわけで今回はここまで。

はじめに みなさん、こんにちは。 レッドハットでソリューションアーキテクトをしている小野です。 本記事では、5月のRed Hat Summit 2023@Bostonでも発表のあった「Red Hat Service Interconnect」についてご紹介します。 www.redhat.com   Red Hat Service Interconnectは「Skupper」というオープンソースがベースです。 過去の記事でSkupperについてや、その便利な使い方についてご紹介したことがありますのでリンクしておきます。 こちらも参考になれば幸いです。   rheb.hatenablog.com   qiita.com   rheb.hatenablog.com   お試し環境 Red Hat Service Interconnectは、以下のページで実際にハンズオンしながら、どのようなソフトウェアなのかご体験いただけます。     [Launch]ボタン→[Start]ボタンと順に押していくと、ハンズオン環境が払い出されます。環境の払い出しに15分くらいかかりますが、ハンズオン自体は30分かからないくらいで体験できます。ぜひお試しください！   KIOSKモードで表示したい方は以下のURLからもアクセスできます。 https://play.instruqt.com/embed/openshift/tracks/red-hat-service-interconnect-jp?token=em_uMIOxTeWiFzR7k5_   以降より、このハンズオンで体験できるシナリオをベースにRed Hat Service Interconnectについて解説します。 シナリオ 例えば、みなさんが「患者ポータルの開発者」であるとします。 患者ポータルは、患者の氏名や住所、通院履歴などの個人情報を含むデータをブラウザに表示して、支払い処理を行うシステムです。みなさんは、ポータルのフロントエンドアプリケーションを、運用性を考慮してパブリッククラウドへデプロイすることにしました。しかし、会社のセキュリティチームより、「患者情報は個人情報に該当するためオンプレミスの外に出すことはNG」と言われます。 このとき、皆さんはどの様に患者ポータルを構築しますか？ 例えば、オンプレミスとクラウドとの間でVPNを接続することも解決策の一つです。しかし、VPNの接続はアプリケーション開発チームだけで対応するのが難しいので、ネットワーク管理者へ依頼し、VPN をセットアップしてもらう必要があります。 また、患者DBや支払いアプリがNATやFWの背後にあり、外部からのアクセスが制限されている場合、外部からのアクセスを許可するようにNATやFWの設定変更が伴います。 これらの対応には、時間を要する承認プロセスが伴うことも少なくありません。     このようなシーンで、Red Hat Service Interconnectは有用です。 Red Hat Service Interconnectという選択肢 Red Hat Service Interconnectは、異なる環境に実行されるアプリケーション同士を連携するための、専用のL7ベースのネットワークを構成します。そして、オンプレミスとクラウドで実行されるそれぞれのアプリケーションは、このL7ベースのネットワークを介してNATやFW越えで連携できるようになります。その際に、ネットワークへ追加の設定変更は必要ありません。     また、Red Hat Service InterconnectによってセットアップされるネットワークはmTLSに基づいています。そのため、アプリケーション通信のセキュリティも確保されます。 そして、Red Hat Service Interconnect のスコープはOpenShift やKubernetes上のコンテナに限らず、オンプレミスで稼働しているさまざまなデプロイメント (仮想マシン、やベアメタル上にデプロイされたプロセスなど) とクラウドで稼働しているアプリケーションとの接続にも活用できます。 Red Hat Service Interconnectをセットアップ ここで、Red Hat Service Interconnectのセットアップ方法を確認しましょう。以下の図の4ステップで完了です。     STEP.1 Skupperの初期化 Skupperを使うには 「skupper init」コマンドを実行し、対象のアプリケーションが稼働するNamespaceへSkupperをデプロイします。Skupperは、PublicとPrivateの両方の環境へデプロイする必要があります。   STEP.2 トークン生成 Skupperのデプロイが完了したら、 Publicの環境で Skupperのトークンを生成します。   STEP.3 リンク生成 STEP.2で作成したトークンを利用してSkupperのリンクを張ります。Privateの環境のFWの設定が、外から中への通信を許可していない場合、Skupperのリンクは Private->Public の向きで張るようにします。   STEP.4 サービス公開 リンクが生成できたら、そのリンク上で公開したいサービスを「skupper expose」コマンドで指定します。 これにより、パブリッククラウドのクラスタから、オンプレミスのクラスタの支払いアプリや患者DBのKubernetesのServiceリソースが見えるようになりました。フロントエンドのアプリケーションはこのService名へ接続すれば、オンプレミス上の支払いアプリや患者DBへアクセスできます。     このように、Red Hat Service Interconnectのセットアップは非常に簡単です。アプリケーション開発チームは、この簡単なセットアップで、ネットワークの専門家に頼ることなく、異なる環境にある他のアプリケーションとのセキュアな相互接続を確立することができます。   （参考）Skupperの仕組み 「skupper init」コマンドを実行すると、「Skupper Router」と「コントロールプレーン」の2つのDeploymentがデプロイされます。 このSkupper Routerは、「Apache Qpid Dispatch Router」というソフトウェアをベースに、アプリケーション間通信をAMQPでルーティングします。 みなさんがオンプレミス上のサービスを「skupper expose」により公開すると、Skupper Router同士が情報を交換し、パブリッククラウドのクラスタへ、公開したオンプレミス上のサービスの名前を伝播します。 パブリッククラウドから見えるオンプレミスのサービスのエンドポイントはSkupper Routerとなっており、公開したサービス名宛のリクエストをSkupper Routerがルーティングします。 Skupper Routerはよくあるルータの様に動作し、環境間の1対1の接続だけでなく、ハブ＆スポークなど、さまざまなネットワークトポロジーをサポートします。 Skupper Routerで構成されたネットワーク上で、アプリケーション通信はOSPFの最短経路のアルゴリズムで経路計算されており、多段でSkupper Routerが配置される構成でも、最適な経路でアプリケーション通信を中継します。 まとめ 本記事では、Red Hat Service Interconnectについてご紹介しました。 Red Hat Service Interconnectを使うことで、ネットワークインフラの設定はそのままに、エッジやプライベートクラウド、パブリッククラウドなどの様々な環境で実行されたアプリケーション同士を、サクッと簡単かつセキュアに連携させることができます。 異なる環境間のアプリケーション連携を実装する際は、ぜひRed Hat Service Interconnectも選択肢の一つとしてご検討ください！  

Red Hatでソリューションアーキテクトをしている田中司恩( @tnk4on )です。 この記事は Red Hat Developer の Deploy and test Kubernetes containers using Podman Desktop を、許可をうけて翻訳したものです。 本記事で紹介する Podman や Podman Desktop に関する情報を日本語で紹介するTwitter アカウントがあります。こちらもフォローして情報収集に活用ください。(ハッシュタグ #podmanjp ) Podman( https://t.co/ipoaatoD4a )の非公式Twitterアカウント。 #Podman に関する情報を日本語で配信中。ツイートは個人のものであり特定の組織や企業を代表するものではありません。The unofficial Twitter account for Podman. Tweets are my own. #podmanjp — podmanjp (@podman_jp) July 9, 2023 Podman Desktop （ 現在一般公開中 ）は、 コンテナー化されたアプリケーション をローカルで構築、実行、管理するための素晴らしいツールですが、現実の環境では、 Kubernetes などのコンテナーオーケストレーションプラットフォームにアプリケーションをデプロイすることが必要です。エンタープライズグレードの Kubernetes を探しているのであれば、 Red Hat OpenShift をおいて他にないでしょう。 Podman Desktop の OpenShift 拡張機能を使って、デスクトップから Red Hat OpenShift の無償の Developer Sandbox にコンテナー化したアプリケーションをデプロイしてテストしてみましょう。 はじめに Podman Desktop（図1）をまだインストールしていない場合は、 podman-desktop.io にアクセスして、Windows、macOS、 Linux に対応する最新リリースをお使いのマシンにダウンロードしてください。 図1: Podman Desktop のダッシュボード このチュートリアルでは、 Developer Sandbox for Red Hat OpenShift の拡張機能を使い、コンテナー化されたアプリケーションを無料のクラウドベースの OpenShift クラスターに 30 日間デプロイすることができます。この拡張機能を使用すると、Developer Sandbox に簡単にサインアップでき、ローカルにインストールしたり Podman Desktop を離れたりすることなく、ホストされた OpenShift 環境に Pod や YAML を簡単にデプロイできます。 OpenShift 拡張機能をインストールする Podman Desktop 用のDeveloper Sandbox 拡張機能 をインストールするには、Podman Desktop の左下にある Settings ボタンに移動します。次に、左側のメニューから Extentions を選択します。そこから、機能拡張のリストから Developer Sandbox 拡張機能をインストールします（図2）。Podman Desktop には、OCI イメージや Docker Desktop extensions から新しい拡張機能をインストールする機能もあります！ 図2：Desktop Extensions タブから Podman Desktop 用の OpenShift 拡張機能をインストールする ボタンをクリックして Developer Sandbox 拡張機能をインストールすると、パネルの左側の Extensions セクションの下に新しいセクションがあることに気付きます。 Red Hat Developer Sandbox 拡張機能(図3)をクリックすると、拡張機能のステータスに関連する情報 (拡張機能の起動、停止、または削除も可能) が表示されます。 図3: インストールされた Developer Sandbox 拡張機能の詳細を見る Developer Sandbox に登録して接続する このチュートリアルでは、 Developer Sandbox for Red Hat OpenShift を使用して、アプリケーションをデプロイしてテストするための無料のOpenShift クラスターを 30 日間入手できます。始めるには、 Settings の左側にある Resources セクションにアクセスしてください。ここで、OpenShift の認証トークンを使って Developer Sandbox 環境に接続することができます。とりあえず、図4のように、 Sign up for the Developer Sandbox というリンクをクリックしてみましょう。(既に Developer Sandbox インスタンスを持っている場合は、次のセクションにスキップできます)。 図4：Resources タブのリンクをクリックして、Developer Sandbox のサインアップページに移動する Developer Sandbox for Red Hat OpenShift では、14 GB の RAM と 40 GB のストレージを備えた共有 OpenShift および Kubernetes クラスターに無料でアクセスできます。Red Hat アカウントを使ってログインし、電話認証プロセスを完了するだけです (図5)。 図5: Red Hat OpenShift の Developer Sandbox にログインする Developer Sandbox にログインしたら、Podman Desktop を OpenShift クラスターに接続します。OpenShift クラスターの右上で、Red Hat ユーザー名の下のドロップダウンメニューを選択し、 Copy login command. をクリックします。 Display token ボタンをクリックしてクラスターの URL とトークンを表示し、図6 に示すようにコマンド全体をコピーします。 図6: OpenShift Web コンソールから OpenShift 認証トークンを取得する。 Podman Desktop に戻り、 Resources 設定ページで Create new Developer Sandbox を選択します。ここで、Podman Desktop 内で簡単に見つけられるように Developer Sandbox インスタンスのコンテキスト名を設定し、OpenShift Web コンソールから完全なログインコマンドを貼り付けます。準備ができたら、 Create ボタンをクリックして Red Hat OpenShift クラスターに認証するだけです (図7)。 図 7: OpenShift クラスターに認証します。 OpenShift クラスターにアプリケーションをデプロイする Podman Desktop の Developer Sandbox 拡張機能を使って OpenShift クラスターに接続できたら、いよいよコンテナー化されたアプリケーションをデプロイしましょう。このガイドでは、 Containerfile からコンテナーイメージをビルドすることは取り上げませんが、Podman Desktop を使って、Developer Sandbox にデプロイする前にコンテナーレジストリからイメージをプルダウンすることができます。 コンテナーレジストリーからイメージを Pull する Docker Hub に似たオープンソースのパブリック・コンテナー・レジストリである Quay.io からイメージのサンプルを Pull しましょう。Podman Desktop の左側のパネルから Images タブを選択します。ここで、Podman Desktop の右上にある Pull an image を選択します。 Pull する画像には、 quay.io/rhdevelopers/quarkus-demo:v1 というタグが付いた基本的な Quarkus のデモアプリケーションを使用できます。 Pull image を選択して、ダウンロードを開始します（図8）。 図8：Podman Desktop を使って画像を Pull する イメージを Podman Desktop に Pull すると、イメージをコンテナーとして実行したり、イメージを削除したり、イメージの履歴を表示したりできるようになります。Developer Sandbox にデプロイする前に、このコンテナーをローカルでチェックしてみましょう。ローカルでテストすることで、デプロイする前に Kubernetes や OpenShift 環境でアプリケーションがスムーズに動作することを確認できます。 左メニューの Images セクションに戻って、新しくダウンロードしたイメージを選択し、図9 に示すように、 Run Image アイコンをクリックします。ここでは、デフォルトの構成を選択し、 Start を選択する。次に、 Containers セクションから新しいコンテナーを選択すると、ログ、ターミナルを使用したコンテナーのシェルへのアクセス、さらにはコンテナーのクラスター上に実行中のポッドを作成するために必要な Kubernetes YAML など、実行中のコンテナーに関するさまざまな情報を表示できます。 図 9: 実行中のコンテナーのテストと詳細表示 Developer Sandbox にコンテナーをデプロイする コンテナーの実行または停止が完了したら、ローカルの kubeconfig ファイルに登録されているクラスター情報を使用して、Developer Sandbox にデプロイします。その前に、まず Podman Desktop Tray をクリックして Kubernetes を選択し、 Developer Sandbox コンテキスト（または別のカスタム名）を選択して、正しい Kubernetes ネームスペースを選択したことを確認しましょう。図10 を参照してください。Podman Desktop に戻って、 Deploy ボタン（ロケットの絵文字）を選択し、クラスター上に Kubernetes Pod を生成します。 図 10: Kubernetes コンテキストの切り替えと Pod のデプロイ デフォルトで生成された Pod 名を使用し、Kubernetes YAML を確認し、 Create OpenShift routes を選択し、 Deploy を再度クリックすると、Developer Sandbox 上で Pod の作成プロセスが開始されます（図11）。Developer Sandbox 拡張機能は、このコンテナーをクラスターにデプロイする際のDeployment、Service と Route の作成を処理します。 図 11: Deploy をクリックすると、Developer Sandbox に Pod が作成される OpenShift ウェブコンソールを使ってデプロイ状況を確認する Podman Desktop 用の Developer Sandbox 拡張機能を使用してコンテナーがクラスターにデプロイされたので、OpenShift ウェブコンソールを見て、すべてが正しく見えることを確認してみましょう。 Developer Sandboxに戻って、 Developer ビューに向かい、左側のメニューから Topology タブを選択します。ここには、新しい Quarkus アプリケーションのデプロイメント、作成されたばかりのサービス、実行中の Pod 、アプリケーションにアクセスするために作成された Route へのリンクに関する詳細が表示されます（図12）。リンクを選択して、ブラウザでアプリケーションを表示します。 図12：ブラウザでアプリケーションを表示する。 さらに、Podman Desktopを使ったときと同じように、Pod名を選択してメトリクスやログなどの関連する詳細を表示したり、ターミナルを使ったりすることもできます（図13）。 図 13: OpenShift ウェブコンソールで Pod の詳細を表示する。 まとめ おめでとうございます！Developer Sandbox 拡張機能を使って Podman Desktop から直接、無償の Developer Sandbox for Red Hat OpenShift にコンテナーイメージをデプロイする方法を学びました。詳しくは Podman Desktop documentation をご覧ください。 Red Hat Developer のその他の Podman とコンテナーのリソースも参照してください。 What is Podman Desktop? A developer's introduction Remote container development with VS Code and Podman Podman expands to the Desktop 関連の記事 How to create a workspace via Try in Dev Spaces extension What's new in Red Hat build of Cryostat 2.3 New C++ features in GCC 13 My advice for designing features for the hybrid cloud How to set up MongoDB Atlas on OpenShift 関連のコンテンツ Transitioning from Docker to Podman Podman expands to the Desktop Remote container development with VS Code and Podman What is Podman Desktop? A developer's introduction Podman basics: Resources for beginners and experts

こんにちは、Red Hatでソリューションアーキテクトをしている石川です。 今回はOpenShift上で利用することができるアプリケーション開発環境であるOpenShift Dev Spacesを使う際のお役立ち情報を紹介したいと思います。 OpenShift Dev Spacesは昨年末のOpenShift Advend Calendar 2022の中でも以下の記事で紹介されています。 こちらの記事も併せてご覧下さい。 qiita.com qiita.com OpenShift Dev Spacesの仕組み Dev Spacesは Devfile というyamlファイルの中で定義された開発環境をコンテナとして起動し、ブラウザ経由でユーザー（アプリケーション開発者）に提供する機能です。 この開発環境を定義するDevfileは、CNCFのSandboxプロジェクトとして開発が進められているオープンソースのプロジェクトで、複数の開発サービスで利用可能することができます。 具体的には、Dev Spacesのアップストリームである Eclipse Cheや、Amazon CodeCatalyst、JetBrains Spaceなどでの利用がサポート されています。 OpenShift Dev SpacesではこのDevfileの内容を元に、DevWorkspaceというカスタムリソースオブジェクトを作成し、開発環境となるコンテナを起動しています。 Devfileは開発対象となるアプリケーションのリポジトリと一緒に管理することが推奨されますが、例えばはじめてDev Spacesを使用するときなどファイルが存在しない場合もあります。その場合、デフォルトの設定として Universal Developer Image (UDI) というコンテナイメージを起動します。 UDIはUBIをベースとし、様々なCLIや言語特有のツールを含むコンテナイメージです。このイメージを使うことでユーザーが自分でツールをインストールすることなく、すぐに開発を行うことができます。 UDIのGitHubには Dockerfile もあるため気になる方はこちらも見てみて下さい。 自分でDevfileを準備する場合には使用するコンテナイメージを指定することも可能ですが、基本的には最新のUDIを使うのが良いでしょう。 利用可能なコードエディターとして オープンソースのVSCode がデフォルトで選択されます。これ以外にInteliJ IDEAも利用可能ですが、こちらは Dev Spacesのv3.6現在ではテックプレビュー の機能です。これらのエディターの機能は元々UDIに含まれているわけではなく、開発環境となるPod起動時にinitContainersにより挿入しています。 このVSCode環境では Open VSX Registry というオープンソースのプラグインレジストリから拡張機能をインストールして利用することも可能です。こちらはMicrosoft社が提供するレジストリではないため、ローカル環境で利用するVSCodeとは利用可能なプラグインに差がある場合があるため、その点は注意しましょう。 開発環境の標準化 チームで利用する開発環境を標準化する場合、自分達のプロジェクトに合わせDevfileを作成し、プラグインや設定の情報と合わせてアプリケーションリポジトリに配置します。 プラグインの管理 エディターにインストールするプラグインの情報について、リポジトリ直下に .vscode というディレクトリを作成し、 extensions.json というJSONファイルを作成します。この extensions.json にプロジェクトの中で共通的に利用するプラグインの情報を記載しておくことで、ワークスペース起動時に自動的にこれらをインストールすることができます。 { "recommendations": [ "redhat.vscode-quarkus", "redhat.vscode-yaml", "redhat.vscode-openshift-connector" ] } "recommendations" 以下に ${publisher}.${name} という形式で記載をします。 Publisherの名前や、プラグイン名はOpen VSX RegistryのURLから確認することができます。 例えば、 https://www.open-vsx.org/extension/redhat/fabric8-analytics であればPublisher名が redhat 、プラグイン名が fabric8-analytics です。 上記のJSONファイルに追記すると以下のようになります。 { "recommendations": [ "redhat.vscode-quarkus", "redhat.vscode-yaml", "redhat.vscode-openshift-connector", "redhat.fabric8-analytics" // 追記 ] } ワークスペースの設定 VSCodeでは settings.json というJSONファイルでエディターの設定を変更することができますが、この settings.json にはユーザーごとに設定するものと、ワークスペースに対して適用するものの二つがあります。 ワークスペースに対して適用する settings.json についてはプラグインと同様に .vscode ディレクトリの中で管理しておくことで、対象のリポジトリを開いたときに自動でその設定を反映することができます。 そのため、こちらにはFormatterやLinterなど、チームで共通して適用したいツールの設定を記入しておき、その他、各個人で変えたい設定（フォントサイズ、エディターのテーマ、など）はユーザー側の settings.json で管理すると良いでしょう。 ユーザーごとにPVを割り当てている場合、ユーザー側の settigns.json はこのPVの中で管理されるため、新たに別のワークスペースで作業するような場合でも個人の設定を引き継ぐことが可能となります。 設定についてより詳しくは こちら のVSCodeのドキュメントを参照してみて下さい。 Devfileの作成 Devfileでは起動するコンテナイメージや、それに割り当てるCPUやMemoryなどのリソース、コンテナにマウントするボリューム、エディターで使用するショートカットコマンドなどについて記載します。 schemaVersion: 2.2.0 metadata: name: sample-devfile attributes: controller.devfile.io/storage-type: per-user components: - container: image: registry.redhat.io/devspaces/udi-rhel8:latest cpuLimit: 2000m cpuRequest: 500m memoryLimit: 4Gi memoryRequest: 2Gi mountSources: true sourceMapping: /projects volumeMounts: - name: cache path: /cache name: sample-udi - volume: size: 1G name: cache commands: - id: 01-run-tests exec: label: 01. Run Tests component: sample-udi commandLine: mvn verify - id: 02-live-coding exec: label: 02. Start Live Coding component: sample-udi commandLine: mvn clean quarkus:dev -Dquarkus.http.host=0.0.0.0 - id: 03-package-app exec: label: 03. Package App for OpenShift component: sample-udi commandLine: mvn package -DskipTests - id: 04-build-native exec: label: 04. Build Native App component: sample-udi commandLine: mvn package -Pnative -DskipTests - id: 05-run-fast-jar exec: label: 05. Run Fast Jar component: sample-udi commandLine: java -Dquarkus.http.port=8081 -jar target/quarkus-app/quarkus-run.jar - id: 06-run-native exec: label: 06. Run Native App component: sample-udi commandLine: ./target/people-1.0-SNAPSHOT-runner -Dquarkus.http.port=8081 .attributes.controller.devfile.io/storage-type ではボリュームの作成方法と作成単位を指定しています。 上記では per-user （デフォルト値）が設定されており、各ユーザー単位でデータ永続化のためのPVが払い出されます。 これ意外に ephemeral を指定することでボリュームを永続化せずに使用したり、 per-workspace を指定し、ユーザーではなく起動するワークスペースごとにPVを作成することも可能です。 PVを利用する場合、Devfileの中でボリュームのマウントを明示せずともコンテナの /projects ディレクトリ以下にボリュームがアタッチされ、そちらにリポジトリからクローンしてきたコードが配置されます。 開発環境として利用するコンテナの情報は .components[].container 以下に記載します。 今回は こちら のコンテナカタログにある最新のUDIを指定し、それに対しCPU/MemoryのRequest/Limitを設定しています。 上記のDevfileでは一つのコンテナのみを指定していますが、これ以外にも複数のコンテナを指定し一つのPodとして起動することも可能です。 例えば以下のようにPostgreSQLを追加するよう設定すると、一つのPodの中で開発用の一時的なデータベースを利用することができるようになります。 components: - container: image: registry.redhat.io/devspaces/udi-rhel8:latest (...中略...) // データベースを追加 - container: image: 'quay.io/centos7/postgresql-13-centos7:latest' env: - name: POSTGRESQL_USER value: user - name: POSTGRESQL_PASSWORD value: password - name: POSTGRESQL_DATABASE value: food_db - name: PGDATA value: /tmp/pgdata name: postgresql データベース追加の例については以下に動画もあるためよければこちらも見てみて下さい。 www.youtube.com .commands では開発中に使用する色々なCLIツールのショートカットを定義することができ、VSCodeのコマンドパレット（Ctrl + Shift + p or CMD + Shift + p）から実行することができます。 以下のようにコマンドパレットで"task"と検索すると Tasks: Run Task という実行メニューが見つかるので、あとは devfile を選択するとファイルの中で定義したコマンドを実行することができます。 ターミナルを開かずビルドやテストを実行したり、チームの中で実行する際のコマンドを統一しておくことができます。 Devfileは基本的にアプリケーションのリポジトリと一緒に置いておき、そこからワークスペースを起動するのが一般的ですが、DevSpacesのv3.6から ローカルで編集したDevfileからワークスペースを再起動することが可能 となりました。これにより少し設定を変えて試したい場合などに、コードをコミットせずともワークスペースの設定を変更することが可能となります。 コマンドパレットから"dev spaces"で検索すると、 Dev Spaces: Restart Workspace from Local Devfile というメニューが見つかります。 こちらを選択し、Devfileがあるディレクトリのパスを指定するとワークスペースが再起動し、新たな設定が反映されます。 今回ご紹介した以外にもDevfileには様々な設定を行うができます。より詳しくは 公式ドキュメント を参照してみて下さい。 まとめ 今回はOpenShift上で利用可能な開発環境であるOpenShift Dev Spacesについてご紹介しました。 Dev Spacesは単純にコンテナとして開発環境を準備するというだけでなく、Devfileによってチームの開発環境を標準化し効率的な開発をサポートします。また Red Hat Developer サイトで無料で試すこともできるのでご興味持たれたら是非触ってみて下さい。

Red Hatでソリューションアーキテクトをしている田中司恩( @tnk4on )です。 Apple Silicon搭載Mac（以下、ARM Mac）へのOpenShiftのインストール方法としてUPI編、エージェントベース編の2つをこれまでに紹介しました。今回はこれまでの2つよりも圧倒的に簡単にインストールできる「支援付きインストーラー」についてご紹介します。 （いつものお約束。本記事の内容は検証を目的としており、本番環境での使用や公式なサポートを保証するものではありません。） [UPI編] 本記事でも度々参照しますので合わせて確認してください。 rheb.hatenablog.com [エージェントベース編] UPIよりも柔軟なCLIベースでのインストール方法です。 rheb.hatenablog.com -目次- 支援付きインストーラー SNO on ARM Mac（支援付きインストーラー）の構成概要 構成図 構成の特徴、前提条件、パラメーター一覧 インストール方法 0. 前提条件 (1) SSH公開鍵 (2) OpenShiftノード (3) DNSサーバ 1. クラスターの新規作成 (1) Cluster details (2) Static network configurations (3) Operators (4) Host discovery (5) Storage (6) Networking (7) Review and create 2. インストールのモニタリング トラブルシュート まとめ 支援付きインストーラー 支援付きインストーラー（Assisted Installer）はRed Hat Hybrid Cloud Console(上のRed Hat OpenShift Cluster Manager)で提供されるGUIを使用したインストールソリューションです。OpenShift 4.10でGAになりました。現在ではベアメタル、vSphere、Nutanixがサポート対象のプラットフォームになっています。CLI操作不要でGUIを通じてOpenShiftのインストールに必要なインストーラーイメージ(Discovery ISO)を作成できます。インストール作業自体もインストーラーイメージを使ってノードを起動するだけで自動的にインストールが完了するお手軽仕様です。今回使用するシングルノード構成（以下、SNO）だけでなく、3ノードクラスター、複数のコンピュートノードを使用する可用性構成にも対応します。各ノードの固定IPアドレス設定もGUI上からできるので、小規模なOpenShiftのインストールでは今後推奨のインストール方法です。 1.7. テクノロジープレビューの機能 OpenShift Container Platform 4.10 SNO on ARM Mac（支援付きインストーラー）の構成概要 支援付きインストーラーでは openshift-install の導入は不要です。SSHキーペアの作成を除き、インストールに必要な作業は全てGUIで行います。 構成図 Single Node OpenShift on ARM Mac(Assisted Installer)のアーキテクチャー 構成の特徴、前提条件、パラメーター一覧 構成の特徴、前提条件、パラメーター一覧はUPI編の記事を参照してください。 構成の特徴 前提条件 パラメーター一覧 インストール方法 参照する製品ドキュメントは2つあります。1. は支援付きインストーラーの単体のドキュメント、2.はOpenShiftのインストールドキュメントの単一ノードの章です。2.の方は簡略化した内容しか載っていないため、1. を基本的には読むことになります。 OpenShift Container Platform の支援付きインストーラー Assisted Installer for OpenShift Container Platform 2022 | Red Hat Customer Portal 15.2. 単一ノードでの OpenShift のインストール OpenShift Container Platform 4.12 | Red Hat Customer Portal 0. 前提条件 (1) SSH公開鍵 下記を参考に、SSHキーペアを事前に準備します。 25.1.6. クラスターノードの SSH アクセス用のキーペアの生成 (2) OpenShiftノード 使用する仮想環境アプリでOpenShiftノード用の仮想マシンを作成します (3) DNSサーバ UPI編の記事を参照 - DNSサーバーの実行 1. クラスターの新規作成 ここからがインストール作業の本番開始です。GUIでの操作がメインなのでスクリーンショットが多めです。 Red Hat OpenShift Cluster Manager へアクセスします。 https://console.redhat.com/openshift/create 「Datacenter」タブへ切り替え、「Create cluster」を押します。 新しいクラスターの作成 (1) Cluster details まず初めにクラスターの詳細情報を入力します。 下記のパラメーターを入力し、「Next」を押します。 項目 サンプル値 説明 Cluster name sno Base domain home.lab OpenShift version OpenShift 4.13.0-rc.7 要4.13.0-rc.6以降 CPU architecture Arm64 Install single node OpenShift(SNO) チェック 選択必須 Edit pull secret チェック無し Host's network configuration Static IP,bridges and bonds DHCPで固定IPアドレスの割り当てが可能なら DHCP only を選択 Encryption of installation disks Disabled Cluster details (2) Static network configurations 前項で静的IPアドレスの選択したので必要な情報を入力します。 下記のパラメーターを入力後、「Next」を押します。 項目 サンプル値 説明 Configure via Form view Networking stack type IPv4 Use VLAN チェック無し DNS 192.168.1.150 Machine network 192.168.1.0/24 Default gateway 192.168.1.1 Network-wide configrations 次の画面でOpenShiftノードのMACアドレスとIPアドレスを入力します。 下記のパラメーターを入力後、「Next」を押します。 項目 サンプル値 説明 MAC Address 6a:75:4d:0c:7e:a5 仮想環境アプリで確認します IP address(IPv4) 192.168.1.40 Host specific configrations (3) Operators Operatorはクラスター導入後に追加できます。 ここでは何も選択せず、「Next」を押します。 Operators (4) Host discovery ここではインストールに必要な設定が入力済みの Discovery ISO ファイルを作成し、ダウンロードします。 「Add host」を選択します。 Host discovery Add host 下記のパラメーターを入力後、「Generate Discovery ISO」を押します。 項目 サンプル値 説明 Provisioning type Full image file SSH public key <YOUR KEY> 事前に作成済みのSSH公開鍵を入力します Configure cluster-wide proxy settings チェック無し Configure cluster-wide trusted certificates チェック無し Generate Discovery ISO ブラウザ用のリンクと、CLI用のリンクが表示されるのでお好みの方法で Discovery ISO をダウンロードします。 タイミングによってはダウンロードに30分以上かかる場合があるので、時間に余裕を持って作業を行いましょう Download Discovery ISO Discovery ISO のダウンロード完了後、仮想環境アプリでISOを指定しVMを起動します。 正常にVMの起動後、数分するとHost Inventory上に起動したOpenShiftノードが自動で表示されます。 起動したノードが自動で登録される ホスト名の左側を展開すると、ホストの詳細が確認できます。CPUアーキテクチャーやハードウェアの情報が確認できます。 ホストの詳細 インストールに必要な条件を満たすと、Statusが Ready になり「Next」が選択できます。 ノードの登録直後はNTP statusがエラーになっていることがあります。しばらくすると自動でNTPの同期が行われ「Synced」になります。 詳細の確認後、「Next」を押します。 (5) Storage ISOの起動ディスクとは別に、インストール先のディスクが登録されていることを確認します。 確認後「Next」を押します。 Storage インストール先ディスクの容量が実際の容量(100GB)よりも多いのはSwap領域も含めての数字となっていると思われます。正常な動作です。 (6) Networking 最初に入力したネットワーク情報が正しく反映されているか確認します。 詳細の確認後、「Next」を押します。 Networking (7) Review and create ここまででインストールに必要な情報の入力、ノードのチェックは完了しています。 「Install cluster」を押してインストールを開始します。 Review and create 2. インストールのモニタリング インストールの開始後は自動で作業が進行します。またインストール中に必要な2回の再起動も自動で行われます。 インストール先のマシン性能にもよりますが、インストール完了までに30分以上は時間がかかります（手元のM1 Maxで確認）。 インストールデモ動画（100倍速） インストールの完了後、Webコンソールのログインに必要な kubeadmin のパスワードが入手できます。また、「Download kubeconfig」ボタンを押して kubeconfig をダウンロードすることができます。なお、 kubeconfig ファイルは20日間後に自動で消去されるため、正常にクラスターのインストールが完了したら確実に入手しておきましょう。 インストールの完了 トラブルシュート 支援付きインストールではクラスターのインストールが完了するまで kubeconfig は入手できません。そのため他のインストール方法で可能な openshift-install コマンドを用いたインストールの進捗確認はできません（その代わりにGUI上で確認ができるのですが）。インストール中に発生するイベントは「View Cluster Events」ボタンを押すことで確認ができます。 Cluster Events また、インストール中のOpenShiftノード（RHCOS）へのSSH接続は可能です。 export IP=192.168.1.40 sed -i -e "/${IP}/d" ~/.ssh/known_hosts ssh core@${IP} -o "StrictHostKeyChecking=no" journalctl -b -f （参考）UPI編：インストール状況のモニタリング まとめ UPIインストール、エージェントベースインストール、そして支援付きインストーラー、この3つのインストール方法でARM MacへのSNOのインストールが可能になりました。ようやく安定したインストール手法が確立できたばかりで実際にどう活用していくかはまだまだこれからです。x86_64に比べARMアーキテクチャーに対応したOperator Hub上のOperatorの種類もまだまだ少ないですが（現時点で1/10ほど）、OpenShift 4.13からARMアーキテクチャーもサポート対象となります *1 。マルチアーキテクチャーがもはや当たり前の世の中で、ARM MacでSNOを使うことでOpenShift/Kubernetesにおけるマルチアーキテクチャーについて考える良い機会になるのではないでしょうか。 さあ3つのインストール方法を駆使しして、目指せ ポケモンマスター OpenShiftインストールマスター！ *1 : What's New in OpenShift 4.13 [Technical Product Update] https://www.youtube.com/watch?v=KxvW_lVhsNo

Red Hat コンサルタントの菅原です。先週に引き続いての投稿になりますが、今回は NUMA アーキテクチャにおけるメモリチューニングに関連した話題です。 この記事を書くきっかけとなったできごとは、あるお客様の2ソケットサーバーで片方の NUMA ノードのメモリはほぼフリーであったのにもう片方の NUMA ノードのメモリが一杯で OOM Kill を引き起こしたことです。その事象の直接的な原因としては、大量にメモリを使用していたプロセスの NUMA アフィニティが手動で固定されていて、もう一方の NUMA ノードのメモリがいくら空いていてもそちらからアロケートできないようにそもそも設定されていたのが原因だったのですが、アフィニティが設定されていない他のプロセスを空いている NUMA ノードに移動させればまだ空きが作れたのでは、NUMA ノードごとのメモリ利用率が極端に異なっているのに両者をバランスさせるような挙動が起きないのはなぜか、といったお客様の疑問を解消するために調べ始め、自分でも湧いてきた疑問を解消するためにさらに調べたことを、記録としてブログに残すことにしました。 書き始めたときは1本の記事で完結するつもりだったのですが、書いているうちにひどく長くなってしまったので、これは2パート構成のパート1とします。 NUMA アーキテクチャとは 本題に入る前に、NUMA アーキテクチャについて軽くおさらいをしておきましょう。 NUMA は Non-uniform Memory Access の略で、「共有メモリ型マルチプロセッサコンピュータシステムのアーキテクチャのひとつで、複数プロセッサが共有するメインメモリへのアクセスコストが、メモリ領域とプロセッサに依存して均一でないアーキテクチャ」です [1]。1990 年代末期に実用化された初期の NUMA システムは、4 プロセッサ程度の SMP サーバー筐体が単一 NUMA ノードを構成し、複数の筐体を専用インターコネクトで相互接続したような形態となっていましたが、2000 年代の AMD Opteron を皮切りに、それ以降の CPU ではチップレベルで NUMA が組み込まれた製品が多数開発・販売されており、現在では複数ソケットを備えるコンピュータはほぼ 100% が NUMA アーキテクチャと言えるまでに普及しています。CPU 自体が NUMA 対応の製品では、単一の CPU チップとそれに直結したメモリとで、単一の NUMA ノードを構成しています。 相互接続された複数の NUMA ノード上のメモリは全体としてひとつ物理アドレス空間上に配置され、どの CPU からどのメモリに対してもアクセスが可能です。そのため、ソフトウェア的には単なる SMP システムのように扱うことも可能ですが、性能的には「ローカルメモリアクセス性能」＞「リモートメモリアクセス性能」となっています。ここでいう「ローカル」はある CPU にとって同じ NUMA ノード内のメモリ、「リモート」はある CPU にとっては別の NUMA ノード内のメモリを指します。CPU とメモリの組み合わせによってメモリアクセス性能が不均一 (Non-uniform) な特性から、NUMA と名付けられました。 CPU とメモリの位置関係によってアクセスコストが変化するので、リモートアクセスが多くなるとアプリケーションの実行性能が低下してしまいます。しかし幸いなことに、多くのソフトウェアには「参照の局所性」という、ざっくりとは大半のプログラムは大方決まったメモリばかりを頻繁に参照しているという特性があるので、実行している CPU とそれが頻繁にアクセスするメモリを同一 NUMA ノードにうまいこと配置してあげることによって、大部分のメモリアクセスをローカルアクセスとして高速に行えるので性能低下を最小限に抑えつつ多数のプログラムを並列実行できる、というのが NUMA アーキテクチャの狙いとなります。 ここで重要なのが、「実行している CPU とそれが頻繁にアクセスするメモリを同一 NUMA ノードにうまいこと配置してあげる」という部分です。常に最適な配置を保とうとするとメモリの移動が増えてそちらのコストが増大してしまうことになったり、あまりカリカリにチューニングして最適値を求めたとしても前提が少し変化しただけで最適ではなくなってしまいますので、あまり最適を追い求めるのも意味がないのですが、全く無頓着でも思った結果が出ないことがあるでしょう。チューニング可能なポイントを知っておくことにより、完全に自動でシステムに自律的に調整させる、と、完全に手動ですべてのアフィニティを明示的に設定する、の間の丁度良いポイントを探してみると良いと思います。 Linux での NUMA 構成の確認方法 実際の Linux システムで NUMA 構成がどのように認識されているかを確認するには、numactl -H コマンドを使います。以下は実行例です。 # numactl -H available: 2 nodes (0-1) node 0 cpus: 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 node 0 size: 63765 MB node 0 free: 422 MB node 1 cpus: 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 node 1 size: 64507 MB node 1 free: 25923 MB node distances: node 0 1 0: 10 21 1: 21 10 この例の出力を見ると、NUMA ノード 0 と 1 の 2 ノード構成で、それぞれのノードに論理 16 コア (実は HT 有効なので物理 8 コア) と 64GB のメモリ、システム全体では論理 32 コア (物理 16 コア) と物理 128GB メモリが搭載されたハードウェア構成であることがわかります。 最後の node distances は各 NUMA ノード間の「相対距離」を表現したマトリックスで、ローカルメモリアクセスコストを 10 とした相対値でリモートメモリアクセスコストが表現されています。ただし、このアクセスコストはファームウェアから得られる情報であって、アクセス遅延実測値を正しく反映しているとは限りません。 Linux カーネルの NUMA チューニングポイント sysctl パラメータ kernel.numa_balancing RHEL 7 の製品ドキュメント [2] に記載されていたパラメータです。RHEL 8/9 のドキュメントには記載されていないのですが、パラメータとしては存在します。 [2] のドキュメントには、「自動 NUMA バランシングは、スレッドまたはプロセスである可能性のあるタスクを、アクセスしているメモリーの近くに移動します。また、アプリケーションデータを、それを参照するタスクに近いメモリーに移動します。」と記載されていますが、[3] を読むと "When this feature is enabled the kernel samples what task thread is accessing memory by periodically unmapping pages and later trapping a page fault. At the time of the page fault, it is determined if the data being accessed should be migrated to a local memory node." と記されており、プロセスのメモリが複数 NUMA ノードにまたがっているときにこの機能を有効化すると片 NUMA ノードに寄せられること(が多いの)が、実験でも確認済みです(実験については後ほど詳しく記します)。また、[3] の記載と合致して、有効化するだけで恒常的にページフォルトが発生することも確認済みです。なお、デフォルト設定値は 1＝enabled です。 関連して以下の4つのパラメータでプロセスメモリをスキャンするレートとサイズを制御できます。頻度を上げる、またはサイズを大きくする、どちらでもリモートからローカルへのメモリ移動のスピードを上げられますが、オーバーヘッドも増大します。 numa_balancing_scan_period_min_ms numa_balancing_scan_delay_ms numa_balancing_scan_period_max_ms numa_balancing_scan_size_mb 自動 NUMA バランシングの有効化によりオーバーヘッドが発生しますので、手動で十分にチューニングされた環境では無効化した方が良好な性能が得られる可能性もあります。 sysctl パラメータ vm.zone_reclaim_mode ゾーン内でのメモリ回収の積極性を制御するパラメータです。ゾーンという概念は NUMA と直接関連するものではありませんが、メモリ階層においてゾーンは NUMA ノードより下の階層、つまり、単一 NUMA ノードは複数ゾーンに分割されますが、単一ゾーンが複数 NUMA ノードにまたがることはありませんので、ゾーン内でのメモリ回収を積極的に行うということは、NUMA ノード内でも積極的にメモリ回収することを意味します。設定値と動作モードの関連については、[4][5] を参照ください ([5] の日本語版では RHEL 5 と 6 だけが対象として記載されていますが、RHEL 7 以降にも存在するパラメータで、意味も変更ありません)。なお、今回の実験ではこのパラメータの影響は見ておりません。 numactl 先ほどのハードウェア構成の確認にも使用したコマンドですが、プロセス起動時の CPU アフィニティやメモリポリシーを設定する機能があり、手動で CPU とメモリの配置を決めたい場合に有効です。今回の実験では numactl を使用することで、どういうポリシーでどの NUMA ノードからメモリをアロケートするかの指定を行っています。 numad 各プロセスのメモリ利用状況などをモニタリングし自律的に最適化するコマンドもしくはシステムサービスで、numa_balancing よりもかなり積極的に NUMA ノード間のメモリ利用率のバランシングを行いますが、その一方で手動で設定したアフィニティを上書きしてノード間のプロセス移動を行う挙動も確認されており、手動チューニングとの併用には注意が必要です。デフォルトの systemd ユニットファイルの設定では tuned との併用などは考慮されている様子がありません。 実験の動機 kernel.numa_balancing の項にも少し書きましたが、このパラメータがその名前の通りに NUMA ノード間の資源利用をバランスする効果があるのか、あるとしてどの程度なのか、を調べるために実験を開始しました。のですが、今回の実験では当初の動機を超えるような範囲の実験も行っています。 実験環境 実験環境は最新の RHEL 8.7 (kernel-4.18.0-425.19.2.el8_7.x86_64) を稼働中の DELL PowerEdge R640 で、NUMA の構成は前述の numactl -H 出力の通り 2 ノード、各ノードに 16 論理コアと 64GB メモリを搭載した環境となります。 実験手法 実験には手軽にメモリ負荷をかけることができる stress ユーティリティを利用しました。このツールは RHEL には同梱されていませんが EPEL [6] からインストール可能です。RHEL レポジトリからインストールできる stress-ng もありますが、やりたいのは容量を指定してローカル/リモートメモリをアロケートすること、アロケートしたメモリを定期的にアクセスさせること、ぐらいでしたので、より手軽に実行できる stress を選択しました。 なお、CPU アフィニティはプロセス起動後に taskset コマンドにプロセス ID を渡して再設定することもできますが、メモリポリシーの設定を行う set_mempolicy(2) システムコールは呼び出したスレッドのメモリポリシーを設定するインターフェイスとなっていますので、外から他のプロセスのメモリポリシーを操作することはできません。というわけで、numactl コマンド経由で stress コマンドを起動することで、メモリが割り当てられる NUMA ノードを指定するようにしています。 stress コマンドの起動時引数は以下のようにしています。 numactl --cpunodebind=<node> <mempolicy_opt> --cpustress -t <timeout> -m <nr_children> --vm-bytes <alloc_size> --vm-keep ここで、各引数の意味は、node は実行 CPU コアを選択する NUMA ノード、mempolicy_opt はメモリポリシーを設定するオプション、timeout はテスト実行時間、nr_children は起動する子プロセスの数、alloc_size は子プロセスごとにアロケートするメモリ容量を、それぞれ指定します。最後の --vm-keep オプションは、アロケートしたメモリを解放せずに書き換え続けるという意味となります。 メモリポリシーを設定するオプションには以下があります (numactl(8) から抜粋)。 --interleave=nodes, -i nodes 指定された各ノードからラウンドロビンでまんべんなくメモリをアロケートします。--interleave と --membind には複数ノードが指定可能です。 --membind=nodes, -m nodes 指定されたノードからのみメモリをアロケートします。指定ノードのメモリが不足しているとアロケートは失敗します。 --localalloc, -l プロセスが現在実行しているノードのメモリを優先してアロケートします。不足した場合は他のノードの空きメモリを使用します。デフォルトポリシーです。 --preferred=node 指定したノードのメモリを優先してアロケートしますが、不足している場合は他のノードの空きメモリを使用します。このオプションで指定できるノードはひとつだけです。 実験シナリオ 実験はいくつかの異なるシナリオに沿って実施しました。当初の動機としては kernel.numa_balancing の効果を見ることでしたので、基本的にはどのシナリオでも numa_balancing を無効化 (0 を書き込み) stress を起動 各プロセスの CPU および NUMA ノードごとのメモリアロケート状況を確認 stress プロセスの CPU アフィニティを taskset コマンドで変更して、全ノードの CPU を利用可とする しばらくの間定期的に各プロセスの CPU および NUMA ノードごとのメモリアロケート状況を確認して経過を観察 kernel.numa_balancing を有効化 (1 を書き込み) しばらくの間定期的に各プロセスの NUMA ノードごとのメモリアロケート状況の変化を観察 という流れになります。この共通部分に対して各シナリオで異なっているのは、ステップ 2 のプロセス数とメモリ容量をシナリオに合わせて調整している点が主となります。 なお、上記各ステップで使用しているコマンドは以下の通りです。 ステップ 1、6 (ステップ 6 で書き込む値は 1) sudo sysctl -w kernel.numa_balancing=0 ステップ 2 numactl --cpunodebind=1 --localalloc --cpustress -t 7200s -m <nr_children> --vm-bytes <alloc_size> --vm-keep ステップ 3、5、7 ps --no-headers -C stress -o pid,ppid,psr,rss,args | sort -n numastat -p stress ステップ 4 taskset -apc 0-31 $stress_pid シナリオ 1 このシナリオでは、ステップ 2 で --cpunodebind に片ノードだけ、メモリポリシーは --localalloc を指定して片ノードのメモリを優先的にアロケートするように指定しました。ただし、合計アロケートメモリ容量が片ノードの搭載メモリを超えるようにして、必ずリモートメモリが使用されるようにしています。また、ステップ 4 の後、プロセスが当初指定したのと逆ノードに移行するかどうかも観察のポイントです。numa_balancing を有効にしてからは、ノード移行とリモートからローカルへのメモリ移行がどのように行われるかを観察しました。 実験前の仮説として以下のような想定がありました。 メモリ移動はコストが高いので CPU 移行が主に使用され、プロセス内でメモリがより多くアロケートされているノードの CPU が割り当てられるのでは 現在割り当てられている CPU のローカルアクセスが多くなるように、メモリ移行はアロケート量が少ないノードから多いノードへと起こるのでは つまり、numa_balancing から想起される両ノードのメモリ利用率をバランスする動きではなく、名前とは裏腹に片ノードへメモリを片寄せするような動きが支配的になるのではないか、という予想です。 シナリオ 2 このシナリオでは、基本的にシナリオ 1 と同じ手順ですが、ステップ 1.5 としてあらかじめ stress を起動して片ノードのメモリの半分程度をある程度アロケートしてしまう追加をしています。ステップ 2 の段階で意図的にメモリ不足を発生させて、リモートメモリが多くアロケートされる stress プロセスを作れるのでは、そしてそのようなプロセスに対して numa_balancing がどのような挙動を見せるのかという点に興味があって考えたシナリオです。 1.5. stress #1 を起動 numactl --cpunodebind=1 --localalloc --cpustress -t 7200s -m 6 --vm-bytes 4G --vm-keep 2. stress #2 を起動 numactl --cpunodebind=1 --localalloc --cpustress -t 7200s -m 16 --vm-bytes 6G --vm-keep シナリオ 3 このシナリオでは、シナリオ 2 の手順に加えて、ステップ 6.5 としてステップ 1.5 で起動した stress を先に終了させて故意にメモリに空きを作る手順を追加しました (実際には 1.5 の timeout を短かく指定することで早く終了させています)。大半のメモリをアロケートする片ノードにそれなりの空きができて、メモリ移動が比較的自由にできる状況になったときの numa_balancing の挙動を見たいと考えたものです。 シナリオ 4 最後のシナリオは、ここまでの実験をするうちに新たに考えついた仮説を実証するためのシナリオとなります。どういう仮説かというと、numa_balancing は現在実行中プロセスに対してリモートアクセスを削減してできるだけローカルアクセスさせようとメモリ移動するだけで、システム全体として NUMA ノード間のメモリ利用のバランスをとろうとしているわけではないのでは、というものです。片ノードの CPU 100% に近い状態を stress で作っておいてから、もう一方のノードのメモリを大量に割り当てて numa_balancing がどのような挙動を示すか見るものです。 と、だいぶ長くなってしまいました、というよりは、実はこの後の実験結果と考察が恐しく長くなりそうなので、実験結果と考察については次の記事に記したいと思います。次回までもう少しお待ちください。余力があれば numa_balancing だけではなく numad の挙動もお見せしたいと考えています(検証自体は実施済みです)。 参考文献 [1] https://ja.wikipedia.org/wiki/NUMA [2] RHEL 7 『仮想化のチューニングと最適化ガイド』9.2.自動 NUMA バランシング [3] Linux Kernel "Documentation for /proc/sys/kernel/*" [4] Linux Kernel "Documentation for /proc/sys/vm/*" [5] Red Hat Customer Portal / Solutions / "vm.zone_reclaim_mode カーネルパラメーターは何を示していますか?" [6] Extra Packages for Enterprise Linux

Red Hat コンサルタントの菅原です。こちらでの投稿は2回目です。 前回と比べると今回は小ネタといって良いと思いますが、RHEL で長年ネットワーク設定ファイルとして使われてきた ifcfg-rh 形式から NetworkManager ネイティブである keyfile 形式への、設定ファイルフォーマットの移行についてお話ししたいと思います。 ifcfg-rh 形式 古くから RHEL や RHEL 互換 OS (CentOS Linux 等) をお使いのユーザーにはおなじみの、/etc/sysconfig/network-scripts に保存される ifcfg-XXX (XXX の部分はデバイス名) というテキストファイルです。 例えばこんなものです。 TYPE="Ethernet" NAME="em1" DEVICE="em1" ONBOOT="yes" BOOTPROTO="static" DEFROUTE="yes" IPADDR="192.168.1.11" PREFIX="24" GATEWAY="192.168.1.254" DNS1="192.168.1.1" DELAY=0 RHEL に NetworkManager が含まれるようになったのが RHEL 6 の頃でしたっけ、などと思ってカスタマーポータルで確認したら、2005 年にリリースされた RHEL 4 に既に NetworkManager RPM が同梱されていてちょっと驚いてしまったのですが、それから20年近く経った現在でも広く使われている、initscripts 由来のファイル形式が ifcfg-rh です。NetworkManager が同梱されるようになってから20年近く経過したとはいえ、現在主力の RHEL 8 でもデフォルトのネットワーク設定ファイル形式は依然として ifcfg-rh です。また、最新の RHEL 9 でも /etc/sysconfig/network-scripts/ に ifcfg-rh 形式で保存した NIC 設定はサポートされています(非推奨ではありますが)。 keyfile 形式 NetworkManager のネイティブな設定ファイル形式がこちらの keyfile 形式となります。一般的には「INI ファイル」と書いたほうが通りが良いかも知れません。参考文献[1]がマニュアルで、記述の仕方など詳しく解説されています。RHEL 9 から、ついにこちらの形式がデフォルトのネットワーク設定ファイル形式に変更されており、保存場所も従来の場所から /etc/NetworkManager/system-connections/ に変更されています。 例えばこんな内容になります。 [connection] id=Main eth0 uuid=27afa607-ee36-43f0-b8c3-9d245cdc4bb3 type=802-3-ethernet autoconnect=true [ipv4] method=auto [802-3-ethernet] mac-address=00:23:5a:47:1f:71 なお、ここでの「デフォルトのネットワーク設定ファイル形式」というのは、nmcli コマンド等、NetworkManager を使って NIC を設定したときに保存される設定ファイルの形式のことです。設定ファイルを直接作成する(例えば vim で書くなどの)際には、当然ですがファイルの保存場所に応じたファイル形式を利用します。前節でも触れましたが、RHEL 9 までは ifcfg-rh 形式もサポートされますので、従来からの ifcfg-rh 設定ファイルは /etc/sysconfig/network-scripts/ に保存すれば、従来通りに動きます(参考文献[2][3]) RHEL 9 での変更点 前述したデフォルトの設定ファイル形式以外にも、ネットワーク周りの大きな変更点として、RHEL 9 では network-scripts RPM が廃止されました(参考文献[4][5])ので、ifup や ifdown といったおなじみのコマンドは使えません。nmcli コマンドなどを利用してください。 例えば nmcli con up を ifup として alias を定義したり、シェルスクリプト等で ifup・ifdown を実装したりすることを止める権利は誰にもありませんので、運用手順の連続性を図ることは不可能ではありません。しかし、そうした手順は厳密には製品のサポート範囲から外れますので、例えばネットワークの初期化で何らかの問題が発生してサポートに問い合わせを行ったときに、RHEL 9 に存在しない ifup などを使っていると、RHEL 9 でサポートされる方式(例えば nmcli con up)でネットワークの初期化を行って同じ問題を再現できるかどうかを確認するように求められるなど、余分なトランザクションが必要になる可能性もあります。 また、RHEL 9 以降では network-scripts が廃止されてネットワーク管理には NetworkManager を利用する以外の選択肢はなくなりました。これは RHEL に限った話ではなく、他の Linux ディストリビューションでも同様だと思います。NetworkManager を利用する他ないのであれば、NetworkManager ネイティブなファイル形式とコマンドを使って全機能を活用いただくことが、長い目で見れば一番良いのではと考えています。 RHEL 9.1 での新機能 さて、RHEL 9.1 には、ifcfg-rh 形式と keyfile 形式の設定ファイルを相互にフォーマット変換することができる、 nmcli connection migrate コマンドが新機能として追加されています(参考文献[6])。 基本的な使い方は以下の通りです。 nmcli connection migrate [ --plugin ファイル形式 ] コネクション名 変換先フォーマットを選択する --plugin オプションで指定できるファイル形式は keyfile または ifcfg-rh で、keyfile の場合は --plugin オプションの指定は省略可能です。つまり、デフォルトで keyfile への変換が行われる仕様になっています。 実際に使ってみた実行例を以下に示します。ここでは /etc/NetworkManager/system-connections/enp1s0.nmconnection というファイルだけが存在する状態で試しています。 [root@dhcp-201-195 ~]# nmcli connection migrate --plugin ifcfg-rh enp1s0 Connection 'enp1s0' (5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03) successfully migrated. [root@dhcp-201-195 ~]# ls /etc/NetworkManager/system-connections/ /etc/sysconfig/network-scripts/ /etc/NetworkManager/system-connections/: /etc/sysconfig/network-scripts/: ifcfg-enp1s0 readme-ifcfg-rh.txt [root@dhcp-201-195 ~]# _ このように、変換元のファイルは削除され、代わりに /etc/sysconfig/network-scripts/ifcfg-enp1s0 が作成されていることがわかります。 この状態でさらに逆方向の変換を試してみると(変換先フォーマットが keyfile なので --plugin オプションは省略しました)、 [root@dhcp-201-195 ~]# nmcli connection migrate enp1s0 Connection 'enp1s0' (5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03) successfully migrated. [root@dhcp-201-195 ~]# ls /etc/NetworkManager/system-connections/ /etc/sysconfig/network-scripts/ /etc/NetworkManager/system-connections/: enp1s0.nmconnection /etc/sysconfig/network-scripts/: readme-ifcfg-rh.txt [root@dhcp-201-195 ~]# このように、やはり変換元のファイルが削除され、変換後のファイルだけが残ります。 変換元のファイルが削除されますので、本番環境などで試す場合は事前にバックアップを取ることをお勧めします。 なぜ ifcfg-rh 形式から keyfile 形式に移行するのか 移行の理由が、RHEL の上流に当たる Fedora Project の Wiki (参考文献[7])に記載されています。長いのでまとめると、以下のいくつかの論点に要約できるかと思います。 keyfile は常に NetworkManager のネイティブかつデフォルトのファイル形式であるのに対し、ifcfg-rh は Fedora/RHEL 特有で、NetworkManager での利用に plugin が必要 ifcfg-rh は network-scripts 由来のファイル形式だが、network-scripts と NetworkManager はそれぞれの拡張を行っていて全く同じ動作を保証するのが困難 keyfile は NetworkManager のすべてのプロファイルタイプを統一的にサポートするが、ifcfg-rh はすべてのプロファイルタイプをサポートしない ifcfg-rh の文法は keyfile より間違いなく醜い 複数の plugin が存在するのはユーザーにとって混乱の元だし、開発者にとっても保守の重荷 過去には ifcfg-rh で全設定が実装されないバグもあった keyfile 形式は他のどの Linux ディストリビューションでも利用できる唯一の NetworkManager の設定ファイル形式 色々書いてありますが、つまるところ、ネットワーク管理には NetworkManager を利用していく大前提において「本質的に同じことをするために複数のファイル形式をサポートするのは労力の無駄なので、どのディストリビューションでも使える標準形式に統一した方がユーザーにも開発者にもみんなにとってベストなのでは」といったところが一番の動機なのではないかと思います。 むすび RHEL 9.1 のリリースノート(参考文献[6])を読むと「設定をキーファイル形式に移行することで、RHEL 9 以降の互換性が保証されます。」と書いてあることから、次期メジャーリリース (RHEL 10 になるでしょうか)では ifcfg-rh 形式が廃止されて利用できなくなる可能性があるように読み取れます。 長年慣れ親しんできたファイル形式や運用手順を変更することに抵抗があるのはよくわかりますが、RHEL 9 でも ifcfg-rh 形式は既に非推奨とされていますし、nmcli コマンドによりフォーマット変換で keyfile 形式に移行できるようにもなっていますので、今のうちに古い ifcfg-rh 形式と ifup/ifdown 等のコマンドから、NetworkManager 標準の keyfile 形式と nmcli コマンドに移行して RHEL 9 後のリリースに備えられてはいかがでしょうか。 参考文献 [1] GNOME Developer "nm-settings-keyfile" [2] Red Hat Enterprise Linux 9 Product Documentation "9.1 リリースノート" "第10章 非推奨になった機能" "10.3. ネットワーク" [3] Red Hat Enterprise Linux 9 Product Documentation "RHEL 9 の採用における考慮事項" "11.3. NetworkManager" [4] Red Hat Enterprise Linux 9 Product Documentation "9.0 リリースノート" "第1章 概要" "1.1. RHEL 9.0 における主な変更点" "ネットワーク" [5] Red Hat Enterprise Linux 9 Product Documentation "RHEL 9 の採用における考慮事項" "11.7. 廃止された機能" [6] Red Hat Enterprise Linux 9 Product Documentation "9.1 リリースノート" "第4章 新機能" "4.8. ネットワーク" "NetworkManager が ifcfg-rh からキーファイルへの移行をサポートするようになりました" [7] Fedora wiki "Changes/NetworkManager keyfile instead of ifcfg rh"

こんにちは、Red Hat Middleware Technical Account Manager のイアンです。 お客様のサポートケースの対応では、現象を再現させるために稼働しているJavaアプリケーションのコードを修正/パッチする場合があります。そのときには、 Byteman をよく使っていますが、新しいツールを紹介したいと思います。 Java Runtime (De)compiler (以降JRDとして略）は弊社社員が作って提供しているJavaのデコンパイルと修正したコードをアプリケーションへ挿入するためのツールです 1 。最新バージョン 7.2 は Java 11 以降に対応していますが、古いバージョン 6 は Java 8 でも使えるように見えます（未検証ですが）。 簡単な例で使い方を説明いたします。 環境準備 この例では、以下の製品とソフトウェアを使用します。 OpenJDK 11 JBoss Enterprise Application Platform (EAP) 7.4 helloworld-rs quickstart JRD 7.2 JBoss EAP は Red Hat Customer Portal からダウンロードし、ローカルで展開します。JRDに接続できるために、 $EAP_HOME/bin/standalone.conf に以下の行を追加します： JAVA_OPTS="$JAVA_OPTS -Djdk.attach.allowAttachSelf=true" jboss-eap-quickstarts リポジトリをローカルにクローンし、 helloworld-rs に移動し、Mavenを使ってビルドします。 $ git clone https://github.com/jboss-developer/jboss-eap-quickstarts.git $ cd jboss-eap-quickstarts/helloworld-rs $ mvn clean package target ディレクトリに作成した helloworld-rs.war を $EAP_HOME/standalone/deployments にコピーします。 最後に、JRD 7.2 を Releases ページからダウンロードし、ローカルで展開します。 準備ができたら、 $EAP_HOME/bin/standalone.sh を実行し、EAPサーバーを起動します。 現状確認 curl を使って、現状の挙動を確認しましょう。 $ curl -w "\n" http://localhost:8080/helloworld-rs/rest/json {"result":"Hello World!"} helloworld-rsアプリは "Hello World!" の結果を返しています。 コード修正 JRDの展開ディレクトリの中の start.sh を実行すると、JRDのGUIが表示されます。 左側には、ローカル環境で稼働しているJavaプロセス一覧になります。 EAPのプロセス(①)をクリックすると、ロードしているクラス一覧が真ん中に表示されます。helloworld-rsアプリのコードを修正したいので、フィルター(②)に org.jboss.as.quickstart.* を入力して、Quickstart関連のクラスに絞り込みます。 HelloWorld クラス(③)を選択すると、右側にデコンパイルされたコードが表示されます。 getHelloWorldJSON() の中の World を Japan に置き換えましょう。コードを以下のように修正します。 @GET @Path (value= "/json" ) @Produces (value={ "application/json" }) public String getHelloWorldJSON() { return "{ \" result \" : \" " + this .helloService.createHelloMessage( "Japan" ) + " \" }" ; } 修正したら、右上の Compile and Upload ボタン(②)をクリックします。 そうすると、以下のような画面が表示され、新しいコードがEAPへアップロードされます。 curl を使って、挙動を確認しましょう。 $ curl -w "\n" http://localhost:8080/helloworld-rs/rest/json {"result":"Hello Japan!"} JRDを用いて無事にコードを修正できました！ まとめ 簡単な紹介でしたが、JRDツールを使って、動いているアプリケーションのコードをオンラインで修正できます。また、GUIベースですので、試行錯誤しているときにはBytemanより手軽に修正できると考えております。 なお、修正はメモリ上に存在するだけですので、EAPを再起動したら、元のコードに戻ります。 オープンソースツールで、Red Hatからのサポートはいたしかねます。不具合などがあれば、直接に Issue を起票して頂ければ幸いです。 ↩

Red Hatでソリューションアーキテクトをしている田中司恩( @tnk4on )です。 Podmanはコンテナを実行するツールであることはよく知られてますが、そのPodmanを「コンテナ内で実行する」ことができるのはご存知でしょうか？今回はこの「Running Podman within a container」のポイントを2つピックアップしてご紹介します。 Podmanをコンテナ内で動かす取り組みにはPodman上で動かす「Podman in Podman(PINP)」やKubernetes上のPod内で動かす方法などがありますが、今回は前者を対象として取り上げたいと思います。 さて、本題に入る前に余談。Podmanのロゴのキャラクターは何なのか？と、まれに話題になりますが、答えは 前回記事 で紹介した「 Podman in Action 」の中にありました。 Podmanのロゴ The Podman logo in figure 1.2 is a group of Selkies, the Irish concept of a mermaid. Groups of Selkies are called pods. 図1.2のPodmanロゴは、アイルランドの人魚の概念であるセルキーのグループです。セルキーのグループはポッドと呼ばれます。 ここで出てくるセルキーは Wikipedia によると「ふだんは海中で生活しているが、陸にあがるときは「アザラシの皮」を脱いで人間と化すると言われている。」と書かれています。よく言われる「Podmanはアザラシ」というのもあながち間違っていないような気もしますね。 *1 -目次- Podmanをコンテナ内で動かす目的 参考となるリソース Podmanコンテナイメージ セキュリティオプション まとめ Podmanをコンテナ内で動かす目的 コンテナの実行環境自体をコンテナ内で動かす取り組み自体は目新しい技術ではありません。Dockerは公式イメージとして「Docker-in-Docker(DIND)」のコンテナイメージを以前から公開しています docker - Official Image | Docker Hub 主要な目的の1つはコンテナ実行ツール自体の開発に利用できる、というものです（DockerならDocker、PodmanならPodmanの開発）。コンテナの特性を活用することで、開発途中のバージョンを迅速かつ簡単に実行することができます。これにより、継続的な開発がより便利になります。 このことはツールの開発だけでなく、一般的なPodmanの利用にも活かすことができます。 例えばPodmanのバージョンアップのテストに使用することができます。コンテナ内でPodmanを動かすことで、ホストマシンに影響を与えることなく、異なるバージョンのPodmanをテストすることができます。これにより、アプリケーションが互換性のあるPodmanバージョンを使用していることを確認できます。 また、Podmanをコンテナ内で動かすことは、CI（継続的インテグレーション）での使用にも役立ちます。CIシステムは、アプリケーションをビルド、テスト、デプロイするために、複数の環境を使用する必要があります。コンテナ内でPodmanを実行することにより、CIシステムは同じ環境を再現することができ、アプリケーションの品質と安定性を維持することができます。 つまり、Podmanをコンテナ内で動かすことは、アプリケーションの開発やテストをスムーズに行うための重要な手段の一つであり、効果的なCIプロセスの実現にも不可欠です。 参考となるリソース コンテナ内でPodmanを実行するために役立つリソースが2つあります。 （ブログ記事） How to use Podman inside of a container （電子書籍） Podman in Action : 8.4 Running Podman within a container この2つがカバーしている範囲は少し異なるので両方を合わせて確認することをお勧めします。 上記2つのリソースからポイントとなる点を2つピックアップしてみました。 Podmanコンテナイメージ セキュリティオプションの組み合わせ これらの内容についてご紹介します。 Podmanコンテナイメージ Dockerと同様に、Podmanもコンテナ内で動かすコンテナイメージが公式から提供されています。 podman/stable · Quay このコンテナイメージのビルドの元になった Containerfile 、 containers.conf がPodmanのGitHubリポジトリで公開されています。 podman/contrib/podmanimage/stable at main · containers/podman · GitHub ブログ記事 ではこの Containerfile の各プロセスについて詳細な解説があります。中身を見ていくとベースイメージはPodmanの開発やテスト版のパッケージのリリースに使われる Fedora が使われていることが分かります。また、1つのコンテナイメージでルートフルとルートレスの2つのモードに対応できるように、事前定義済みの containers.conf を利用したり、適切なUIDの設定（主にルートレス向け）やコンテナ内でfuse-overlayfsを実行する工夫が行われています。これらの工夫は普段の Containerfile の作成にも役立てるのではないでしょうか。 公開されているコンテナイメージのバージョンはv3.3.0が最も古く、そこからPodmanのリリースごとのバージョンが揃っています。特定のPodmanのバージョンのイメージを使ってテストするなんて場合にも便利ですね。またQuay.ioのリポジトリ上で定期的なコンテナイメージのスキャンが行われており、コンテナイメージの脆弱性情報も確認できるので安心して使うことができます。 Podmanコンテナイメージ自体の解説や使用方法について、リポジトリの README にも記載があるのでそちらも是非参考にしてください。 セキュリティオプション もう一つのポイントがPodmanコンテナイメージを実行する時に付与するセキュリティオプションです。コンテナ内でコンテナ実行ツールを動かすためには強い権限が必要となります。いくつかの工夫はPodmanコンテナイメージで対応されていますが、実際にはコンテナ実行時( podman run )にも適切なセキュリティオプションの付与が必要です。一番簡単な解決方法は --privileged フラグをつけて実行することです。ほとんどの場合はこれで事足りるはずです。ですが --privileged は不必要な権限も与えてしまう恐れがあります。そこで ブログ記事 や Podman in Action では --privileged を使わずに必要なセキュリティオプションのみを与える解説が行われています。Podmanではルートフル、ルートレスの2つのモードがあるので実行するホスト、モードの組み合わせは下記のようになります。 ＜ホストモード - コンテナモード＞ ルートフル - ルートフル ルートフル - ルートレス ルートレス - ルートフル ルートレス - ルートレス これらのモードの組み合わせで必要なセキュリティオプションをまとめた表が下記になります（ Podman in Action より、転載）。 ホストモード コンテナモード セキュリティオプション 解説 ルートフル ルートフル CAP_SYS_ADMIN ホストユーザーのネームスペースへのフルアクセス権を持つ ルートフル ルートレス CAP_SETUID, CAP_SETGID コンテナ内の/etc/subuidと/etc/subgidに基づく別のユーザーのネームスペースで実行される ルートレス ルートフル Namespaced CAP_SYS_ADMIN ユーザーのユーザーネームスペースへのフルアクセス権を持つ ルートレス ルートレス Namespaced CAP_SETUID, CAP_SETGID コンテナ内の /etc/subuid と /etc/subgid に基づく別のユーザーネームスペースで実行される。ユーザーネームスペースは、Podmanコマンドを実行しているユーザーネームスペースのサブセットである必要がある。 これらの詳細な解説はご紹介した2つの参考リソースにお任せするとして、ポイントをまとめるとこのようになります。 Podmanでは実行するモードの組み合わせにより4つのパターンがあり、それぞれに適切なセキュリティオプションを付与して実行する（ Podman in Action の表 8.1を参照） まとめ 今回ご紹介した2つの参考リソースはPodmanをコンテナ内で実行する際に必要となる情報がしっかりと記載されていますので是非参考にしてください。また、セキュリティオプションについては、 --privileged を使わない場合のコンテナ実行の仕組みはどうなっているのかということを考えるのに良い機会だと思います。さらに、PodmanコンテナイメージはPodmanだけでなくDockerやKubernetes上でも実行できます（PINP、PIND、PINK...）。参考リソースを活用してさまざまな場面でコンテナ内でPodmanを実行することに挑戦してみてください。 *1 : 今回記事のサムネ絵はセルキーをイメージして Bing Image Creator に書いてもらいました。

Podman in Action Red Hatでソリューションアーキテクトをしている田中司恩( @tnk4on )です。 Red Hat Developerから無償で入手できる電子書籍「 Podman in Action 」（以下、本書）についてご紹介します。 本書はコンテナの基礎からPodmanを利用した高度な使い方、またコンテナセキュリティまで網羅的に解説されています。 コンテナに興味のある人全員に必読の内容なのですが、英語であることとその思想的背景について理解が無いと少し分かりづらい部分があります。 そこで、本記事では書籍冒頭にあるロードマップをベースに少し解説を加えて、読み進めるためのガイドとなることを目指します。 （注意：本記事の内容は独自に解説したもので、公式なものではない点ご了承下さい） 本書は下記URLより入手が可能です（PDFのダウンロードにはRed Hatアカウントの作成が必要です）。 developers.redhat.com なお、本書の著者でありPodman開発の主要メンバーであるDaniel Walsh と 同じく主要開発メンバーのBrent Baudeの2名によるポッドキャストを日本語翻訳した記事があります。Dockerとのセキュリティにおける思想的違いやPodmanが生まれた背景などが語られています。是非こちらも合わせて参考にしてください。 rheb.hatenablog.com -目次- 全体構成 各章解説 第1部「基礎編」（難易度：低） 第2部「デザイン」（難易度：中） 第3部「高度なトピック」（難易度：中） 第4部「コンテナセキュリティ」（難易度：高） 付録（難易度：低） まとめ 参考リンク 全体構成 本文は4部構成で全10章あります。加えて6つの付録があります。 第1部「基礎編」 第1章：Podman：次世代コンテナエンジン 第2章：コマンドライン 第3章：ボリューム 第4章：ポッド 第2部「デザイン」 第5章：カスタマイズと構成ファイル 第6章：ルートレスコンテナ 第3部「高度なトピック」 第7章：systemdとの連携 第8章：Kubernetesとの連携 第9章：Podmanサービス 第4部「コンテナセキュリティ」 第10章：コンテナを分離するセキュリティ 第11章：セキュリティに関するその他の留意点 付録 付録A：Podman関連コンテナツール 付録B：OCIランタイム 付録C：Podmanの始め方 付録D：Podmanへの貢献 付録E：macOSのPodman 付録F：WindowsのPodman これらに加えて冒頭に「序章」と「本書について」があります。この冒頭部分に本書の目指す内容がまとまっているので、まずは冒頭部分に目を通してみるのをお勧めします。 それ以外は次の各章の解説を参考に、読み進めたい部分を選んで読んでみるのをお勧めします。参考までに各部の難易度を低中高の3段階で分類してみました。 各章解説 第1部「基礎編」（難易度：低） 章 タイトル 内容 第1章 Podman：次世代コンテナエンジン コンテナランタイム、コンテナエンジン、コンテナオーケストレーションについての概要。コンテナとLinuxのプロセス分離機能。コンテナイメージの解説、PodmanとDockerの比較。ポッドキャストで語っていた内容をより詳細に解説している。 第2章 コマンドライン Podmanのコマンドの基本機能の紹介。よくあるコンテナ解説とほぼ同じ流れ。すでにDockerに慣れていれば読み飛ばしても問題無し。PodmanではContainerfileが標準の名前に使用（Dockerfileと構文は同じ）。 第3章 ボリューム データを永続化するボリュームの使用、マウントオプションの解説、SELinuxマウントオプションの解説。第6章でも出てくる podman unshare については第2章のコマンド紹介と合わせて確認すること。 第4章 ポッド Podman podsの概要、Podman podsのコマンド紹介。Podmanの特徴であるPodについて知りたい場合はここを読む。 第2部「デザイン」（難易度：中） 章 タイトル 内容 第5章 カスタマイズと構成ファイル Podmanを構成する複数のライブラリの中から、ストレージ(storage.conf)、イメージ(registries.conf)、エンジン(contaiers.conf)の各構成ファイルの解説。UID/GIDの使用については後段の6章と合わせて確認する。 第6章 ルートレスコンテナ Podmanにおけるルートレスコンテナの動作の解説。UID/GIDのマッピングの挙動を事例と共に解説。ルートレスコンテナ実行時のネットワーク、conmonの動きのアーキテクチャーの解説。 第3部「高度なトピック」（難易度：中） 章 タイトル 内容 第7章 systemdとの連携 コンテナとsystemdを組みあせてどう実装するかの解説。コンテナ内でinitを実行するubi-initの紹介。Podmanのコンテナをsystemdのサービスとして登録する方法。ロギングやイベントの確認方法などPodmanでコンテナを常時稼働するために必要な内容を知ることができる。 第8章 Kubernetesとの連携 PodmanでKubernetes YAMLファイルを使ってPodを実行する解説。 podman generate kube で出力したYAMLファイルの構文の解説、 podman play kube でYAMLファイルからPodman podsを実行する方法。Kubernetes上でのPodmanの動作を行う「Podman in Podman」の解説。 第9章 Podmanサービス ここでいうサービスとは第7章のsystemdサービスではなく、PodmanでREST APIを受け付けるサーバーとして見立てた時の挙動を表す表現。デーモンレスなPodmanにおけるpodman.socketのアーキテクチャ解説。Docker互換のAPIの提供、Pythonやdocker-composeとの連携。Podmanリモートクライアント podman --remote の解説 第4部「コンテナセキュリティ」（難易度：高） 章 タイトル 内容 第10章 コンテナを分離するセキュリティ コンテナを分離するためのLinuxのセキュリティ機能が詳細に解説されています。本書で最も力が入っている部分、最重要ポイント。コンテナに携わる上で必ず行き着く部分。必読。 第11章 セキュリティに関するその他の留意点 デーモン構成のDockerとforc/execモデルのPodmanを詳細に比較解説。Podmanにおけるシークレットの取り扱い（ podman secret 解説）。Podmanにおけるイメージの信頼、署名、スキャンの解説。 付録（難易度：低） 章 タイトル 内容 付録A Podman関連コンテナツール Skopeo、Buildah、CRI-Oの紹介。Buildahはコマンドラインでのコンテナビルドのサンプル解説あり。Buildah名の命名の逸話は要チェック。 付録B OCIランタイム runc、crun、Kata、gVisorの解説。 付録C Podmanの始め方 macOS、Windows、Linux各ディストリビューションごとのPodmanの導入方法。ソースからのビルド方法。Podman Desktopの紹介。 付録D Podmanへの貢献 Podmanコミュニティのサイトと開発GitHubリポジトリの紹介。 付録E macOSのPodman macOS環境でのPodmanの導入とPodman machineの実行方法。 付録F WindowsのPodman Windows環境でのPodmanの導入と、WSL2を使ったPodman machineの実行方法。 まとめ 「Podman in Action」は無料の電子書籍でありながら300ページ近くあり、とても濃い内容となっています。コンテナ初学者からDockerに使い慣れた方でも隅々まで目を通すべき内容が多くあります。 すでにコンテナの普及期には入ったといえ、正しい情報ソースで基本から学ぶ機会はそれほど多くないと思います。本書を通じてあらためてコンテナについて学習することをお勧めします。 本記事が読書の参考になれば幸いです。 参考リンク https://podman.io/ https://podman-desktop.io/ https://github.com/containers/podman/ https://kubernetespodcast.com/episode/164-podman/

Red Hatでソリューションアーキテクトをしている田中司恩( @tnk4on )です。 Apple Silicon搭載Mac（以下、ARM Mac）へのOpenShiftのインストールがさらに簡単になりました！ 前回の記事 から短期間での内容更新ですが、動作確認ができたので世界最速で新しいインストール手順をご紹介します！ （いつものお約束。本記事の内容は検証を目的としており、本番環境での使用や公式なサポートを保証するものではありません。） [前回記事] 本記事でも度々参照しますので合わせて確認してください。 rheb.hatenablog.com （2023/5/10、追記） 支援付きインストーラーの記事を公開しました！ rheb.hatenablog.com -目次- エージェントベースのインストール SNO on ARM Mac（エージェントベース）の構成概要 構成図 構成の特徴、前提条件、パラメーター一覧 インストール方法 Gitリポジトリのクローン インストーラーとOpenShift CLIの入手 RHCOS ISOの入手 DNSサーバーの実行 Macホストの設定変更 RHCOS ISOのテスト起動とデバイス名の確認 install-config.yamlの更新 1. プルシークレット 2. SSHキー agent-config.yamlの更新 1. ランデブーIP 2. ネットワーク設定 3. ルートデバイスヒント エージェントISO作成用コンテナイメージのビルド Containerfile コンテナのビルド エージェントISOの作成 エージェントISOの起動 （参考）NetworkManager TUI インストール中の自動再起動 インストール完了の確認 （参考）インストール状況のモニタリング 環境のリセット まとめ エージェントベースのインストール エージェントベース（Agent-based）のインストールは、OpenShift Container Platform 4.12 でGAになった新しいインストール方法です。支援付きインストーラー（Assisted Installer）の使いやすさをオンプレのインストールに活用することができるインストール方法です。支援付きインストーラーのような対話式のGUIはありませんが、CLIでシンプルに実行ができ、また非接続環境への導入も可能な柔軟性も兼ね備えています。 install-config.yaml ファイルと agent-config.yaml を使って起動用のエージェントISOを作成し、このISOで起動することでOpenShiftクラスターが自動で作成されます。 今回の記事ではエージェントベースのインストール自体は深く掘り下げませんが、下記の公式ブログで紹介されていますので参考にしてください。 OpenShift Container Platform 4.12 リリースノート Meet The New Agent-Based OpenShift Installer Introducing a Game-Changing New Way to Deploy OpenShift Clusters in Disconnected Environments SNO on ARM Mac（エージェントベース）の構成概要 エージェントベースのインストールの場合でもARM Macへのインストールの構成自体はほぼ変わりません。 coreos-installer の代わりに openshift-install をコンテナで実行する用に変更になったくらいです。 構成図 Single Node OpenShift on ARM Mac(Agent-based)のアーキテクチャー 構成の特徴、前提条件、パラメーター一覧 構成の特徴、前提条件、パラメーター一覧は前回の記事を参照してください。 構成の特徴 前提条件 パラメーター一覧 インストール方法 参照するインストールドキュメントは下記をベースとしますが、今回もARM Mac用に様々なカスタマイズを加えています。 第14章 エージェントベースのインストーラーを使用したオンプレミスクラスターのインストール 前回記事と重複する部分は多いですが、 agent-config.yaml の修正や openshift-install 用のコンテナのビルドは今回新しく追加された手順です。 Gitリポジトリのクローン インストールに必要なファイル類のテンプレートを用意しています。下記URLのリポジトリをクローンしてご利用ください。 GitHub - tnk4on/sno-on-arm-mac: Install Single Node OpenShift on Apple Silicon-based Mac (ARM Mac) git clone https://github.com/tnk4on/sno-on-arm-mac.git cd sno-on-arm-mac agent-basedディレクトリ配下のファイルを使用します インストーラーとOpenShift CLIの入手 インストールに必要な openshift-install とクライアントの oc を入手して実行パスに配置します。 今回のインストール方法ではコンテナ内で openshift-install を実行するのでMacに導入するものは直接インストールに関係しませんが、インストール中のログ確認等に使用するので導入しておきましょう。 export OCP_VERSION=4.13.0-rc.2 export ARCH=aarch64 mkdir src cd src curl -LO https://mirror.openshift.com/pub/openshift-v4/$ARCH/clients/ocp/$OCP_VERSION/openshift-install-mac.tar.gz curl -LO https://mirror.openshift.com/pub/openshift-v4/$ARCH/clients/ocp/$OCP_VERSION/openshift-client-mac.tar.gz tar zxf openshift-install-mac.tar.gz tar zxf openshift-client-mac.tar.gz sudo cp openshift-install oc /usr/local/bin/ cd .. OCP_VERSION : 「4.13.0-rc.2」以降を指定します （注意）4.13.0-rc.0ではインストールが完了しません ARCH : ARM Macに対応した「aarch64」を指定します ダウンロードしたアーカイブは src ディレクトリに一時保存します 実行バイナリの配置先はPATH環境変数であればどこでも可能です RHCOS ISOの入手 今回はインストールには使用しませんが、 agent-config.yaml に記載するストレージデバイス名とNIC名の確認に使用します。 mkdir iso export ISO_URL=$(openshift-install coreos print-stream-json | grep location | grep $ARCH | grep iso | cut -d\" -f4) curl -L $ISO_URL -o iso/rhcos-live.iso 一度デバイス名の確認が完了すれば削除してしまって問題ありません DNSサーバーの実行 前回の記事を参照 - DNSサーバーの実行 Macホストの設定変更 前回の記事を参照 - Macホストの設定変更 RHCOS ISOのテスト起動とデバイス名の確認 前回の記事を参照 - RHCOS ISOのテスト起動とデバイス名の確認 install-config.yamlの更新 ご利用の環境に合わせて install-config.yaml の内容を修正します。前回記事との違いはインストール先ディスクの指定が無い点です。 *1 agent-based/install-config.yamlのサンプルを展開 apiVersion: v1 baseDomain: home.lab compute: - name: worker replicas: 0 controlPlane: name: master replicas: 1 metadata: name: sno networking: clusterNetworks: - cidr: 10.128.0.0/14 hostPrefix: 23 machineNetwork: - cidr: 192.168.1.0/24 networkType: OVNKubernetes serviceNetwork: - 172.30.0.0/16 platform: none: {} pullSecret: '{"auths":...}' sshKey: 'ssh-ed25519 AAAA...' 1. プルシークレット 前回の記事を参照 - 1. プルシークレット 2. SSHキー 前回の記事を参照 - SSHキー agent-config.yamlの更新 今回のインストール方法のポイントとなるセクションです。使用環境に合わせて内容を修正します。 agent-based/agent-config.yamlのサンプルを展開 apiVersion: v1alpha1 kind: AgentConfig metadata: name: sno rendezvousIP: 192.168.1.40 hosts: - hostname: m1-ocp interfaces: - name: enp0s1 macAddress: 6a:75:4d:0c:7e:a5 rootDeviceHints: deviceName: /dev/vda networkConfig: interfaces: - name: enp0s1 type: ethernet state: up mac-address: 6a:75:4d:0c:7e:a5 ipv4: enabled: true address: - ip: 192.168.1.40 prefix-length: 24 dhcp: false dns-resolver: config: server: - 192.168.1.150 routes: config: - destination: 0.0.0.0/0 next-hop-address: 192.168.1.1 next-hop-interface: enp0s1 table-id: 254 1. ランデブーIP rendezvousIP: ：シングルノード構成なのでOpenShiftノードと同じIPアドレスを設定します 2. ネットワーク設定 hostname: ：OpenShiftノードのホスト名を設定します macAddress: , mac-address: ：NICのMACアドレスを記載します。RHCOSのテスト起動時や仮想環境アプリで確認してください。2箇所あります。 NIC名：確認したNIC名を記載します。3箇所あります。 hosts: interfaces: - name: enp0s1 networkConfig: interfaces: - name: enp0s1 next-hop-interface: enp0s1 DNSサーバー：コンテナ実行したDNSサーバーを使用するためARM MacホストのIPアドレスを指定します dns-resolver: config: server: - 192.168.1.150 next-hop-address: ：デフォルトゲートウェイのIPアドレスを記載します 3. ルートデバイスヒント 確認したストレージデバイス名を記載します。 rootDeviceHints: deviceName: /dev/vda ルートデバイスヒントは記載しなくてもインストールが可能ですが、ディスクの検出のプロセスに時間がかかるため記載しておくと時間短縮になります （注意）ストレージの容量は必ず120GB以上にしてください。120GB未満だとディスクが検出されてもインストールが開始されません。 エージェントISO作成用コンテナイメージのビルド エージェントISOの作成は openshift-install を使用します。今回は agent-config.yaml に静的IPアドレスの設定を加えており、このネットワークの設定を行うために NMState が必要です。RHELなどのLinuxサーバーであれば NMState は簡単にインストールできますが、調べたところMac用はありません。そこで openshift-install と NMState が入ったLinuxベースのコンテナイメージを作成し、その中でエージェントISOの作成を行うようにします。 Containerfile コンテナイメージのビルドに使用するContainerfileは下記の内容になります。 agent-based/Containerfileの内容を展開 # Preparation Build FROM quay.io/centos/centos:stream9-minimal as prep # ARG ARG VERSION # ENV ENV VERSION=${VERSION} ENV ARCH=aarch64 # Download binary RUN microdnf install tar gzip -y RUN curl -LO https://mirror.openshift.com/pub/openshift-v4/${ARCH}/clients/ocp/${VERSION}/openshift-install-linux.tar.gz RUN curl -LO https://mirror.openshift.com/pub/openshift-v4/${ARCH}/clients/ocp/${VERSION}/openshift-client-linux.tar.gz RUN tar xzf openshift-install-linux.tar.gz RUN tar xzf openshift-client-linux.tar.gz # Build image FROM quay.io/centos/centos:stream9-minimal as build RUN microdnf update -y \ && microdnf install nmstate -y \ && microdnf clean all COPY --from=prep openshift-install /usr/local/bin COPY --from=prep oc /usr/local/bin ENTRYPOINT ["/usr/local/bin/openshift-install"] ベースイメージにCentOS 9 Stream minimalを使用します *2 ツールのダウンロードと実行用のステージを分けたマルチステージビルドを行います openshift-install の実行の際に oc も必要となるので oc も導入します ビルド引数を使用してOpenShiftのバージョンを指定します ENTRYPOINTに openshift-install の実行を指定します コンテナのビルド ビルド引数にOpenShiftのバージョンを指定してビルドを実行します export OCP_VERSION=4.13.0-rc.2 podman build -f agent-based/Containerfile -t openshift-install --build-arg VERSION=${OCP_VERSION} podman run -it --rm openshift-install version バージョンが表示されたらコンテナのビルドは成功です タグ名は openshift-install にしてますが、任意で変更可能です エージェントISOの作成 インストールディレクトリおよびイメージ、ツール類が格納されるキャッシュディレクトリを作成します。 install-config.yaml と agent-config.yaml をインストールディレクトリにコピーし、ビルドした openshift-install コンテナイメージを使用してエージェントISOの作成を実行します。 mkdir -p ocp image_cache files_cache cp agent-based/*.yaml ocp podman run --privileged --rm \ -v $PWD:/data \ -v ./image_cache:/root/.cache/agent/image_cache \ -v ./files_cache:/root/.cache/agent/files_cache \ -w /data openshift-install:latest \ --dir ocp agent create image 初回は元になるISO（image_cache配下に保存される）のダウンロードから開始するので時間がかかります。 2回目以降の実行時はキャッシュを再利用します。キャッシュを検証し、インストーラーのバージョンが更新されていれば再度ダウンロードが行われます。 （注意）ISOを作成すると使用した install-config.yaml と agent-config.yaml は失われるので、毎回コピーして元ファイルを残すようにしましょう エージェントISOの作成後のインストールディレクトリとキャッシュディレクトリの構成は下記のようになります . ├── files_cache │ ├── agent-tui │ └── libnmstate.so.1.3.3 ├── image_cache │ └── coreos-aarch64.iso └── ocp ├── .openshift_install.log ├── .openshift_install_state.json ├── agent.aarch64.iso ├── auth │ ├── kubeadmin-password │ └── kubeconfig └── rendezvousIP ocp/.openshift_install.log にエージェントISO作成時のログが作成されます。うまくいかない時はログの内容をチェックしてみてください。 エージェントISOの起動 インストールディレクトリ配下に作成された agent.aarch64.iso を使用して仮想マシンを起動します。ISO起動後は自動でクラスターのインストールが開始されます。 起動後しばらくすると下記のような画面が表示されます。ネットワークの接続確認にパスするとさらに追加で設定変更するかどうかの選択ができます。事前に agent-config.yaml で設定済みなので変更する必要はありません。そのまま放置すると自動でインストールが継続されます。 エージェントベースインストールのNetworkManager TUI （参考）NetworkManager TUI エージェントベースインストールの特徴がエージェントISO起動時に出てくるNetworkManager TUIです。ツール自体はRHELでもお馴染みの nmtui そのものです。設定画面を開いてみると agent-config.yaml で設定した内容が自動で入力されているのが確認できます。 NetworkManager TUIの接続設定 NetworkManager TUIの接続のアクティベート NetworkManager TUIのホスト名の設定 NetworkManager TUIのネットワークステータス インストール中の自動再起動 インストールの自動実行中、下記のタイミングで再起動が2回行われます。 1回目：ISO起動→ディスクへ書き込み完了後 2回目：Bootstrap開始→Bootstrap完了後 インストール完了の確認 下記のコマンドを実行し、クラスターのインストールが完了したことを確認します。 export KUBECONFIG=ocp/auth/kubeconfig openshift-install --dir=ocp wait-for install-complete インストール完了後のログ出力で kubeadmin のパスワードを確認できます。 〜省略〜 INFO Install complete! INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/Users/*****/***/ocp-on-arm-mac/ocp/auth/kubeconfig' INFO Access the OpenShift web-console here: https://console-openshift-console.apps.sno.home.lab INFO Login to the console with user: "kubeadmin", and password: "BJpWp-8dGqa-XNGoW-vzGfV" 同じくログに表示されているWebコンソールのURLにアクセスしてOpenShiftを使用開始します （参考）インストール状況のモニタリング OpenShiftのインストール実行中、ターミナルウィンドウを複数開き下記のコマンドを利用してログのモニタリングができます。 前回の記事を参照 - （参考）インストール状況のモニタリング エージェントベースのインストール用に下記のモニタリングコマンドが使えます。 export KUBECONFIG=ocp/auth/kubeconfig openshift-install --dir=ocp agent wait-for bootstrap-complete wait-for bootstrap-complete はISO起動からBootstrap完了まで インストールログのサンプルを展開 INFO Waiting for cluster install to initialize. Sleeping for 30 seconds 〜中略〜 INFO Waiting for cluster install to initialize. Sleeping for 30 seconds INFO Cluster is not ready for install. Check validations WARNING Cluster validation: The cluster has hosts that are not ready to install. WARNING Host m1-ocp validation: Host couldn't synchronize with any NTP server WARNING Host m1-ocp: updated status from discovering to insufficient (Host cannot be installed due to following failing validation(s): Host couldn't synchronize with any NTP server) INFO Host m1-ocp: updated status from insufficient to known (Host is ready to be installed) INFO Cluster is ready for install INFO Cluster validation: All hosts in the cluster are ready to install. INFO Preparing cluster for installation INFO Host m1-ocp: updated status from known to preparing-for-installation (Host finished successfully to prepare for installation) INFO Host m1-ocp: New image status quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:250b5a39dd30e13afcdcefdfa99586811b438c3e6dc9df350f9a4132188d4fe6. result: success. time: 7.04 seconds; size: 438.75 Megabytes; download rate: 65.31 MBps WARNING Host's disk /dev/disk/by-path/pci-0000:00:05.0 is slower than the supported speed, and may cause degraded cluster performance (fdatasync duration: 21 ms) INFO Host m1-ocp: updated status from preparing-for-installation to preparing-successful (Host finished successfully to prepare for installation) INFO Cluster installation in progress INFO Host m1-ocp: updated status from preparing-successful to installing (Installation is in progress) INFO Host: m1-ocp, reached installation stage Installing: bootstrap INFO Host: m1-ocp, reached installation stage Waiting for bootkube INFO Bootstrap Kube API Initialized INFO Host: m1-ocp, reached installation stage Writing image to disk INFO Host: m1-ocp, reached installation stage Writing image to disk: 11% INFO Host: m1-ocp, reached installation stage Writing image to disk: 24% INFO Host: m1-ocp, reached installation stage Writing image to disk: 36% INFO Host: m1-ocp, reached installation stage Writing image to disk: 49% INFO Host: m1-ocp, reached installation stage Writing image to disk: 61% INFO Host: m1-ocp, reached installation stage Writing image to disk: 66% INFO Host: m1-ocp, reached installation stage Writing image to disk: 77% INFO Host: m1-ocp, reached installation stage Writing image to disk: 88% INFO Host: m1-ocp, reached installation stage Writing image to disk: 94% INFO Host: m1-ocp, reached installation stage Writing image to disk: 100% INFO Bootstrap configMap status is complete INFO cluster bootstrap is complete 環境のリセット インストールに問題があった場合はインストールディレクトリを削除してエージェントISOの作成からやり直します。毎回キャッシュ済みのISOやツール類のチェックは行われるので、キャッシュディレクトリは残しておいて問題ありません。 インストールディレクトリの削除 rm -rf ocp エージェントISOの再作成 mkdir -p ocp cp agent-based/*.yaml ocp podman run --privileged --rm \ -v $PWD:/data \ -v ./image_cache:/root/.cache/agent/image_cache \ -v ./files_cache:/root/.cache/agent/files_cache \ -w /data openshift-install:latest \ --dir ocp agent create image まとめ 前回記事の最後にチラッと紹介したエージェントベースのインストールが早くも使えるようになりました。エージェントISO作成用のコンテナイメージさえ事前に用意しておけばすぐにインストールが開始できます。前回記事のUPIをベースとした手動インストールもかなり手順を簡略化しましたが、今後はこのエージェントベースのみでも十分になりそうです。 前回、今回の記事を活用するとRed Hat公式のARM Macで動作するOpenShift Localのリリース待つまでもなくすぐにお手持ちのM1、M2 MacでOpenShiftを動かせます。さぁ、ARM MacでのOpenShift体験を今すぐ試してみましょう！ *1 : どちらかというと通常のUPI用のinstall-config.yamlに戻った状態 *2 : 残念ながらUBIはNMStateのインストールができなかったため採用を見送りました