Red HatでOpenShiftのサポートをしている id:nekop です。 OpenShift 4ではOpenShift Update ServiceというAPIサービスにより特定のバージョンからアップデート可能なバージョン情報を提供しており、このガイドされたバージョン情報を利用することによって安全なアップグレードを実現しています。 fast, stable, candidate, eusチャネル 各バージョンには fast, stable, candidate, eus というチャネルがあり、たとえば4.10であれば fast-4.10. stable-4.10, candidate-4.10, eus-4.10 というチャネルがあります。 fastはRed Hatでのテストをパスし、GAされたリリースが追加されていく、いわゆる通常のリリースチャネルです。 stableはfastにリリースされたものが一定期間経過し、そのバージョンへアップグレードして利用するユーザが一定数認められ、影響の大きな問題が報告されていない、「安定した」と認められるリリースバージョンが追加されていきます。fastから最短で一週間ですが、最長は決まっておらず、fastの段階で報告された問題の影響の調査中などは追加が見送られます。なるべく既知の問題を回避したい、という場合はstableチャネルを利用することで、ある程度新規の問題に遭遇するリスクを下げることが可能になっています。 candidateはテスト前のビルドがリリースされるチャネルです。通常のユーザは利用することはあまりないでしょう。 eusに追加されるリリースはstableと同じですが、eusは偶数マイナーバージョンのみ提供され、たとえばeus-4.8からeus-4.10へアップグレード、というようにマイナーバージョンを2つ連続してアップグレードするためのチャネルです。 EUSのアップグレードのドキュメント があります。 基本的には利用するチャネルを選択して、アップグレードする際には以下の Red Hat OpenShift Container Platform Update Graph (要ログイン)というサービスでアップグレード可能なバージョンを参照し、アップグレードをしていくことになります。 access.redhat.com ここからは少し細かい話をしていきます。アップグレード可能なバージョン、いわゆるアップグレードパスはどのように決められているのでしょうか。まれに新しいバージョンがリリースされているのにアップグレードパスがまだ用意されていない、といった問題や、以前あったはずのアップグレードパスが消えてしまっている、という問題が発生します。これらの問題はなぜ発生するのでしょうか。 アップグレードパスはどのように決められているのか 各チャネルのデータは cincinnati-graph-dataというGitHubリポジトリ で管理されています。各リリースがいつfastに追加され、いつstableへ追加されたか、という情報はこのリポジトリの履歴で確認できます。 github.com たとえば4.7.48は2022/04/13にfastに追加され、2022/04/20にstableへ追加された、ということがわかります。 github.com 各チャネル内のバージョンリストは cincinnati-graph-dataの定義を直接参照する 他、APIからも以下のcurlコマンドで取得できます。 $ curl -sH 'Accept:application/json' 'https://api.openshift.com/api/upgrades_info/v1/graph?channel=fast-4.10' | python3 -mjson.tool | grep '"version": "4.' | sort -V "version": "4.9.25", "version": "4.9.26", "version": "4.9.27", "version": "4.9.28", "version": "4.9.29", "version": "4.10.3", "version": "4.10.4", "version": "4.10.5", "version": "4.10.6", "version": "4.10.8", "version": "4.10.9", "version": "4.10.10", "version": "4.10.11", 各リリースバージョンの情報を持つリリースイメージというものがあり、リリースイメージは以下のようにアップグレード元となるバージョンのリストを保持しています。これを元にアップグレード可能なバージョン、アップグレードパスが計算されます。 $ oc adm release info -o json quay.io/openshift-release-dev/ocp-release:4.10.3-x86_64 | jq .metadata W0426 14:45:35.563030 56281 helpers.go:151] Defaulting of registry auth file to "${HOME}/.docker/config.json" is deprecated. The default will be switched to podman config locations in the future version. { "kind": "cincinnati-metadata-v0", "version": "4.10.3", "previous": [ "4.10.0", "4.10.0-fc.0", "4.10.0-fc.1", "4.10.0-fc.2", "4.10.0-fc.3", "4.10.0-fc.4", "4.10.0-rc.0", "4.10.0-rc.1", "4.10.0-rc.2", "4.10.0-rc.3", "4.10.0-rc.4", "4.10.0-rc.5", "4.10.0-rc.6", "4.10.0-rc.7", "4.10.0-rc.8", "4.10.1", "4.10.2", "4.9.19", "4.9.21", "4.9.22", "4.9.23" ], "metadata": { "url": "https://access.redhat.com/errata/RHSA-2022:0056" } } 上記4.10.3であれば、たとえば4.9.23から4.10.3へのアップグレードが可能、4.9.19以前の4.9.zリリースからはアップデートができない、というのがわかります。 4.9.zの最新にしたら4.10.zへのアップグレードパスが無くなってしまいました、なぜですか？ たとえばこの4.10.3というリリースのあとに4.9.24というリリースがあった場合でも、上記のとおり4.10.3というバージョンは4.9.24からのアップデートが可能、という情報がないため、4.9.24から4.10.3というバージョンへのアップグレードパスは存在しないことになります。バージョンとしては新しいように見えますが、このようにバージョン番号だけではなく、各リリースバージョンの時系列のデータにも基づいているため、単純にバージョン番号だけで「新しい」こと、および「アップグレード可能かどうか」は判別できません。 これは各マイナーリリース最新リリース同士でも発生するもので、たとえば4.9.zの最新にアップデートした場合に、4.10.zの最新へのアップグレードパスがまだ無い、4.10.zへのアップグレードパスがひとつもない、という状況が発生します。4.9.zの最新からのアップデートが可能とされている4.10.zリリースがまだ存在しないためです。このような状況は通常1, 2週間で解消しますが、もし連続したマイナーバージョンアップデートを計画している場合は Red Hat OpenShift Container Platform Update Graph を参照して、最終的に目標とするバージョンへアップグレード可能な経由バージョンを選択してください。 とりあえず各マイナーバージョンの最新を適用してから次のマイナーバージョンへアップグレードしたい。とてもよくわかります。私も初見だとそうすると思います。しかし、上記の仕組み上、現マイナー最新から次マイナーの最新へのアップグレードは常に可能なわけではない、ということになります。OpenShiftのアップグレードパス特有のトリッキーなところだと思います。 4.8.zから4.9.zへのアップグレード、前に確認したときには存在していたのに今見たら消えていました、なんでですか？ fastなどの各チャネルのリリースバージョンは cincinnati-graph-dataというGitHubリポジトリ で管理されている、という話をしましたが、このリポジトリはもうひとつ他のデータを持っています。 blocked-edges というアップグレードパスを明示的に制限する情報です。 アップグレード可能なバージョン、つまりアップグレードパスは各リリースイメージの情報を元に構築されるものですが、まれにリリースされた特定バージョンに影響の大きな問題が発見されることがあります。このときに利用されるのがblocked-edgeによるアップグレード禁止宣言です。たとえば4.9.28までの全ての4.9.zバージョンは、 etcdのデータ不整合が発生する問題 の影響を受けるため、4.8.zからのアップデートがblockされています。 github.com 上記のような影響の大きい問題が後から発見された場合は、その問題の影響を受けるユーザを増やさないようblocked-edgesの定義に追加され、アップグレードパスを無効化してユーザ保護を行います。 stableチャネルで4.yから4.(y+1)へのアップグレードパスがなかなか作成されません stableのマイナーバージョンアップグレードは実績として30日から60日くらい様子を見てからオープンされます。低リスクであることを優先するならstableで待ってください。アップグレードを急ぐ理由があるときはfastを検討してください。 まとめ OpenShiftはアップグレードパスを利用することにより安全なアップグレードを実現している fast, stable, candidate, eusという4つのチャネルがある アップグレードパスの参照は Red Hat OpenShift Container Platform Update Graph サービスを利用する アップグレードパスはチャネル内の各リリースイメージの定義から算出、構成される 仕組み上、現マイナー最新から次マイナーの最新へのアップグレードができないタイミングがある ユーザ保護のためアップグレードパスが後から無効化されることがある

Red Hat で Java Platform Advocate として OpenJDK を担当している伊藤ちひろ（ @chiroito ）です。 こちらは Red Hat が提供しているOpenJDK の Shenandoah GCの日本語情報をまとた記事です。 Shenandoah GC Wiki 翻訳 Shenandoah GCのサポート概要とバグ報告について - 赤帽エンジニアブログ Shenandoah GCの実装概要 - 赤帽エンジニアブログ Shenandoah GCの性能指針と診断 - 赤帽エンジニアブログ Shenandoah GCの機能診断 - 赤帽エンジニアブログ Red Hat Developer Blog 翻訳 すべてのOpenJDK 12ビルドにShenandoahが含まれているわけではない：その理由は... - 赤帽エンジニアブログ JDK 13のShenandoah GC パート1：ロードリファレンスバリア - 赤帽エンジニアブログ JDK 13のShenandoah GC パート2：転送ポインタワードの廃止 - 赤帽エンジニアブログ JDK 13のShenandoah GC パート3：アーキテクチャとオペレーティングシステム - 赤帽エンジニアブログ JDK 14のShenandoah GC パート1：自己修正バリア - 赤帽エンジニアブログ JDK 14のShenandoah GC パート2：並行ルートとクラスアンロード - 赤帽エンジニアブログ OpenJDK 16のShenandoahガベージコレクション：並行参照処理 - 赤帽エンジニアブログ

Red Hat で Java Platform Advocate として OpenJDK を担当している伊藤ちひろ（ @chiroito ）です。 この記事は、OpenJDK のWikiページ、 https://wiki.openjdk.java.net/display/shenandoah/Main の一部を翻訳した記事です。こちらが最後の記事になります。 翻訳の各リンクはこちらです。 Shenandoah GCのサポート概要とバグ報告について - 赤帽エンジニアブログ Shenandoah GCの実装概要 - 赤帽エンジニアブログ Shenandoah GCの性能指針と診断 - 赤帽エンジニアブログ Shenandoah GCの機能診断 - 赤帽エンジニアブログ 目次 機能診断 ソースからビルド リソース 機能診断 このセクションでは、Shenandoahの診断とデバッグの方法について説明します。 これらは、問題箇所を絞り込むためにできるステップです。 -XX:+ShenandoahVerify で実行します。これはGCバグに対する防御の最初の手段です。これはリリースとfastdebugの両方のビルドで利用可能です。Verifierが問題を特定した場合、それはGCバグである可能性が高いです。これをよりよく診断するために、簡単な再現ツールがあると便利でしょう。多くの場合、GCで以前何が起こったかが重要です。例えば、GCで最後に行われたアクションなど。その履歴は通常、関連する hs_err_pidXXXX.log に記録されているので、バグを報告する際にそれを完全に含めることを確認してください。 fastdebugビルド で実行します。多くの場合、これで意味のあるアサートメッセージが表示されます。これは、GCが機能的な異常を検出した最も早いタイミングを指しています。そして、Shenandoahは、たくさんアサートします。これらのビルドは、configureに --enable-debug を追加し、再ビルドすることによって生成できます。例によって、hs_err_pidXXXX.logは、アサーション失敗を調査するのに役立つ環境と履歴データを便利に記録しています。 -XX:ShenandoahGCHeuristics=passive で実行すると、stop-the-worldを伴うGCのみを行い、ほとんどの並行処理を行わないようにします。passiveモードで問題がなくなれば、並行フェーズやバリアでのバグであるはずです。 -Xint (インタープリタのみ), -XX:TieredStopAtLevel=1 (C1のみ), -XX:-TieredCompilation (インタープリタとC2のみ) - どのモードで失敗し、どのモードで失敗しないかを分析するために異なるコンパイラで実行します。これにより、インタープリタ、C1、またはC2でのバリア処理または最適化に問題があるかどうかが明らかになります。これは通常、fastdebug ビルドと組み合わせると便利です。なぜなら、コンパイラもアサートするからです。 -XX:ShenandoahGCHeuristics=aggressive で実行します。このヒューリスティックは、連続してGCを実行し、全ての空でない領域を退避させます。Shenandoahは、ほとんどのGCの重い仕事を並行して行うので、これは、アプリケーションの実行をブロックしません。しかし、このモードでは、GCはより多くのサイクルを消費し、アプリケーションを遅くします。このモードでVerifierを有効にすると、おそらく実用的でないレベルまで性能が低下することに注意してください。 -XX:+ShenandoahVerifyOptoBarriers （C2の理想グラフの障壁を検証）、 -XX:VerifyStrictOopOperations （Oop比較が正しく行われているかを検証するための追加チェックを行う）でさらに検証を追加します。 一般的なデバッグのテクニックはShenandoahにも適用されます： 問題をよりよく理解するために、失敗したアサートの周りのコードにロギング文を入れてください。十分なロギングがあれば、コレクターで起こったことを全て辿れます。 コード中の疑わしい部分の周りにさらにアサート文を追加します。 shenandoahAsserts.hpp のマクロ定義を見て、どのような豊富なアサートが利用可能かを確認しましょう。 ネイティブデバッガをアタッチします。例えばgdb。VMに -XX:OnError="gdb - %p" (%pはプロセスのPIDに置き換えられる)と指定して、失敗時に外部アクションを実行するよう依頼します。 簡単な再現プログラム作成し、Shenandoahの開発者に渡します:) ソースからビルド これは、最新かつ最高のバージョンを実行することを保証するものです。一部の機能やバグフィックスは、古いバージョンのJDKでは利用できない場合があります。古いバージョンのJDKは、より安定しているはずです。 ./configure に --enable-debug を追加すると、より多くの診断を行う "fastdebug" ビルドが生成されます。 ワークスペースのダウンロードに時間がかかりすぎると感じるかもしれません。特に jdk10+ のワークスペースはそうです。そのような場合は、ワークスペースの tarball をここからダウンロードできます。 https://builds.shipilev.net/workspaces/ # JDK master: $ hg clone http://hg.openjdk.java.net/jdk/jdk shenandoah # JDK 11u: $ hg clone http://hg.openjdk.java.net/jdk-updates/jdk11u shenandoah # JDK 8u: $ hg clone http://hg.openjdk.java.net/shenandoah/jdk8 shenandoah $ cd shenandoah/ # JDK 11移行を設定してビルド: $ sh ./configure $ make images # JDK 8を設定してビルド: $ sh ./get_source.sh $ sh ./configure $ make images # JDK 11移行を実行！: $ build/linux-x86_64-normal-server-release/images/jdk/bin/java -XX:+UseShenandoahGC -Xlog:gc [...][info][gc] Using Shenandoah # JDK 8を実行！: $ build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/java -XX:+UseShenandoahGC -version openjdk version "1.8.0-internal" OpenJDK Runtime Environment (build 1.8.0-internal-shade_2016_12_19_15_52-b00) OpenJDK 64-Bit Server VM (build 25.71-b00, mixed mode) 注意：OpenJDKは通常、すべての警告をエラーとして扱ってコンパイルされます。新しいコンパイラは、コードベースがまだ追いついていない警告を多く持っているかもしれません。そのような場合は、 ./configure に --disable-warnings-as-errors を渡すことができます。 ソースからビルドする場合、すべてのケースでテストを実行することは任意ですが、推奨されます。これは、Shenandoahが現在ターゲットにしている以上のプラットフォームや、新しすぎる、あるいは古すぎるツールチェインでビルドする場合に、特に重要です。テストを実行するには、jtregが必要であり、最初にfastdebugビルドに対してテストを実行することは、理にかなっています。 # jtreg を https://ci.adoptopenjdk.net/view/Dependencies/job/jtreg/ からダウンロードして解凍 # jtreg をビルド成果物と接続: $ sh ./configure --with-jtreg=<jtreg folder> --with-debug-level=fastdebug $ sh ./configure --with-jtreg=<jtreg folder> --with-debug-level=release # テストを実行: $ CONF=linux-x86_64-normal-server-fastdebug make images run-test TEST="tier3_gc_shenandoah" $ CONF=linux-x86_64-normal-server-release make images run-test TEST="tier3_gc_shenandoah" リソース Shenandoah プロジェクト リポジトリ メーリングリスト: shenandoah-dev メンバー

Red Hat で Java Platform Advocate として OpenJDK を担当している伊藤ちひろ（ @chiroito ）です。 この記事は、OpenJDK のWikiページ、 https://wiki.openjdk.java.net/display/shenandoah/Main の一部を翻訳した記事です。何回かに分けて翻訳していきますので、ぜひ最後までごらん下さい。 翻訳の各リンクはこちらです。 Shenandoah GCのサポート概要とバグ報告について - 赤帽エンジニアブログ Shenandoah GCの実装概要 - 赤帽エンジニアブログ Shenandoah GCの性能指針と診断 - 赤帽エンジニアブログ Shenandoah GCの機能診断 - 赤帽エンジニアブログ 目次 性能指針と診断 一般的な考え方 基本設定 モード ヒューリスティック 障害モード 性能分析 性能指針と診断 一般的な考え方 ヒープサイズ : Shenandoahの性能は、ほとんど全ての他のGCの性能のように、ヒープサイズに依存します。並行フェーズ（アプリケーションと同時に動くフェーズ）が実行されている間、割り当てを収容するのに十分なヒープスペースがある場合、より良いパフォーマンスを発揮するはずです（下記の「 障害モード 」セクションを参照）。並行フェーズの時間は、生きているデータセットサイズ（LDS）、つまり生きているデータによって占有されるスペースと相関があります。 したがって、妥当なヒープサイズは、LDSと処理負荷からの割り当て具合に依存します。ある割り当て具合に対して、より大きなLDSは、比例してより大きなヒープサイズを必要とします。より大きなLDSに対して、より大きな割り当て具合はより大きなヒープサイズを必要とします。 極小のLDSと適度な割り当て具合を持つ一部の処理では、1～2GBのヒープが良好な性能を発揮します。私たちは日常的に、最大80%のLDSサイズを持つさまざまな処理で4～128GBヒープをテストしています。恥ずかしがらずに、さまざまなヒープサイズを試して、自分の処理に合うものを見つけてください。 停止 ：Shenandoahの停止動作は、ルートの走査と更新というルートセットの処理に大きく影響されます。ルートセットには、ローカル変数、生成されたコードに埋め込まれた参照、インターンされた文字列、クラスローダからの参照（例えば、静的なファイナル参照）、JNI参照、JVMTI参照が含まれます。ルートセットが大きいと、一般的にShenandoahでの停止時間が長くなります。これは、具体的なJDKのバージョンが、その仕事の一部を並行に行う機能を持ち、Shenandoahがそれを使用できる場合を除きます。 二次的な影響としては、a) 弱参照の処理 (ファイナルマーク停止中に発生)、ただし処理が必要な参照のみ、b) クラスのアンロードとその他のJDKクリーンアップ (こちらもファイナルマークの停止中に発生) が挙げられます。これらの二次的な影響は、追加のオプションを設定することで軽減できます。これらは、処理の頻度の制御（完全に無効にすることも含む）、および/または、アプリケーションを少し良く動作するように変更することです。 処理量（スループット） ：Shenandoahは並行処理GCであるため、収集サイクル中に不変性を維持するために障壁（バリア）を使用します。これらのバリアは、測定できるほどのスループットの損失を引き起こすかもしれません。そこで何が起こっているかを詳細に調べる方法については、以下の診断セクションを参照してください。一部のユーザーは、バリアによるスループットの低下は、空きコアや その他のアイドルコアに並行実行中の GC 処理を自然にオフロードすることで補われている と報告しています。言い換えれば、場合によっては、より高いアプリケーション＋JVMの利用とより高いアプリケーションのスループットは引き換えになります。 ほとんどの場合、停止時間は0〜10ms以内、スループットの損失は0〜15%以内です。実際の性能の数値は、実際のアプリケーションや負荷の状態などに大きく依存します。ルートや弱参照、クラスの除去があまりないアプリケーションでは、停止はミリ秒以下の範囲に収まることがあります。ヒープをあまり変更しないアプリケーションや、現在のコンパイラで十分に最適化されているアプリケーションでは、バリアのオーバーヘッドはゼロに近くなる可能性があります。残りのセクションでは、Shenandoahの性能の振る舞いをテストし、診断するための手順について説明します。もし、あなたの具体的な使用例で何かおかしいと思ったら、開発者に知らせることを検討してください。可能性として、それは管理可能な問題か、真っ当なバグであることがあります。 基本設定 基本的な設定とコマンドラインオプションです。 -Xlog:gc (JDK 9 以降) または -verbose:gc (JDK 8 まで) は、個々の GC タイミングを表示します。 -Xlog:gc+ergo (JDK 9以降) または -XX:+PrintGCDetails (JDK8まで) または試行錯誤的な決定を表示します。これは、もしあれば、異常値を明らかにするかもしれません。 -Xlog:gc+stats （JDK9以降）または -verbose:gc （JDK8まで）は、実行の最後にShenandoah内部のタイミングに関する概要一覧を出力します。 ロギングを有効にして実行することは、ほとんどの場合、良いアイデアです。この概要一覧は、GCパフォーマンスに関する重要な情報を伝えます。そして、性能バグレポートでほぼ必然的に1つを求めることになります。試行錯誤的なログは、GCの異常値を把握するのに便利です。 その他に推奨されるJVMオプションは以下の通りです。 -XX:+AlwaysPreTouch ：ヒープが使うページをメモリ上に前もって確保すること（コミット）は、遅延の小さな停止時間を軽減できます。 -Xms と -Xmx ： -Xms = -Xmx でヒープサイズを変更不可にすることで、ヒープ管理による小さな停止時間を軽減します。 AlwaysPreTouch と組み合わせることで、 -Xms = -Xmx は起動時にすべてのメモリを確保するため、メモリが最終的に使用されたときの小さな停止時間を回避できます。 -Xms はまた、メモリの開放（アンコミット）の境界の下限を定義するので、 -Xms = -Xmx では、すべてのメモリは確保されたままになります。つまり、Shenandoahをより低いリソース使用量で構成したい場合は、 -Xms を低く設定することが推奨されます。コミット/アンコミットの処理コストとメモリ使用量のバランスを取るために、どの程度低く設定するかを決定する必要があります。多くの場合、 -Xms を任意に低く設定することは問題ないでしょう。 ラージページを使用することで、大きなヒープでのパフォーマンスが大幅に改善されます。これを使用する方法は2つあります。 -XX:+UseLargePages はhugetlbfs（Linux）またはWindows（適切な特権を持つ）のサポートを有効にします。 -XX:+UseTransparentHugePages は、透過的にそれを有効にします。透過的なラージページでは、 /sys/kernel/mm/transparent_hugepage/enabled と /sys/kernel/mm/transparent_hugepage/defrag を "madvise" に設定することが推奨されます。AlwaysPreTouchを付けて実行すると、起動時にデフラグのコストも前もって支払うことになります。 -XX:+UseNUMA : Shenandoahは、まだ明示的にNUMAをサポートしていません。ですが、マルチソケットのハードウェアでNUMAインターリーブを有効にするために、これを有効にするのは良いアイデアです。AlwaysPreTouchと組み合わせることで、デフォルトの設定よりも優れたパフォーマンスを提供します。 -XX:-UseBiasedLocking : 競合しない（バイアスド）ロッキングのスループットと、必要に応じて有効・無効を切り替えるためにJVMが行うセーフポイントとの間にはトレードオフがあります。遅延重視の負荷では、バイアスド・ロッキングをオフにすることは理にかなっています。 -XX:+DisableExplicitGC : ユーザーコードからSystem.gc()を起動すると、Shenandoahは追加のGCサイクルの実行を強制します; System.gc()を悪用するコードから守るために、これを無効にすると有益な場合があります。 -XX:+ExplicitGCInvokesConcurrent はデフォルトで有効になっているので、通常は問題ないでしょう。これは、STW（Stop The World:アプリケーションが完全に停止する）のフルGCではなく、並行GCサイクルが呼び出されることを意味します。 モード モードは、Shenandoahの主な実行方法を定義します。これは、もしあれば、Shenandoahがどのようなバリアを使っているかを定義し、主要な性能特性を定義します。モードは、 -XX:ShenandoahGCMode=<名前> で選択できます。利用可能なモードは以下の通りです。 normal/satb （製品、デフォルト）。このモードは、SATB（Snapshot-At-The-Beginning）マーキングと並行したGCを実行します。このマーキングモードは、G1が行っていることに似ています。G1は書き込みを妨げ、「以前の」オブジェクトを通してマーキングします。 iu (実験的). このモードは増分更新(IU)マーキングと並行してGCを実行します。このマーキングモードは、SATBモードを反映します。これは、書き込みを阻止し、「新しい」オブジェクトを通してマークします。このため、特に弱参照にアクセスする場合、マークが甘くなることがあります。 passive (診断)。このモードはstop-the-worldを伴うGCを実行します。このモードは機能テストに使われますが、時にはGCバリアで性能異常を二分したり（下記参照）、アプリケーションの実際の生きているデータサイズを把握するのに便利です。 ヒューリスティック モードが選択された後、ヒューリスティックによって、ShenandoahがGCサイクルを開始するタイミングと、避難のために判断する領域を指示します。ヒューリスティックは、 -XX:ShenandoahGCHeuristics=<名前> で選択できます。いくつかのヒューリスティックは、あなたの使用状況にGC操作をよりよく調整するのを助けるかもしれない構成パラメータを受け入れます。利用可能なヒューリスティックは、次のとおりです。 adaptive (デフォルト).このヒューリスティックは、以前のGCサイクルを観察し、ヒープが枯渇する前に完了できるように、次のGCサイクルを開始しようとします。 -XX:ShenandoahInitFreeThreshold=# : 「学習」コレクションの引き金となる初期閾値 -XX:ShenandoahMinFreeThreshold=# : ヒューリスティックが無条件にGCを起動させる空き容量閾値 -XX:ShenandoahAllocSpikeFactor=# : 割り当て急増を吸収するために確保すべきヒープ量 -XX:ShenandoahGarbageThreshold=# : ゴミ収集のためにマークされる前に、その領域が含む必要のあるゴミの割合を設定します。 static （以前は皮肉にもdynamicと呼ばれていた）。 このヒューリスティックは、ヒープの占有率に基づいてGCサイクルの開始を決定します。このヒューリスティックのチューニングの取っ掛かりは以下の通りです： -XX:ShenandoahMinFreeThreshold=# : GCサイクルを開始する空きヒープの割合を設定します。 -XX:ShenandoahGarbageThreshold=# : 収集のためにマークされる前に領域が含むべきゴミの割合を設定します。 compact （以前はcontinuousと誤って呼ばれていた）。このヒューリスティックは、GCサイクルを連続的に実行し、前のサイクルが終了するとすぐに次のサイクルを開始し、割り当てが発生する限り、実行します。このヒューリスティックは通常、スループットのオーバーヘッドを発生させますが、最も迅速なスペースの再利用を提供します。有用なチューニングの取っ掛かりは以下の通りです： -XX:ConcGCThreads=# : GCスレッドの並行処理数を削減し、アプリケーションの実行に余裕を持たせる。 -XX:ShenandoahAllocationThreshold=# : 最後のGCサイクルから割り当てられたメモリのパーセンテージを、次のGCサイクルを開始する前に設定します。 aggressive (診断)。このヒューリスティックは、GCが完全に活性化するように指示します。前のGCサイクルが終了するとすぐに新しいGCサイクルを開始し（「compact」のように）、すべての生きてるオブジェクトを退避させます。このヒューリスティックは、コレクタ自体の機能テストに便利です。しかし、大きなパフォーマンス・ペナルティが発生します。 障害モード Shenandoahのような並列GCは、アプリケーションが割り当てるよりも速く収集することに暗黙のうちに依存しています。もし、割り当て要求が高く、GCの実行中に割り当てを受け入れるのに十分なスペースがない場合、最終的に割り当て失敗が発生します。Shenandoahは、このようなケースを乗り切るために、緩やかな縮退の梯子（Graceful Degradation Ladder）を持っています。この梯子は次のように構成されています。 歩調（ -XX:+ShenandoahPacing 、デフォルトで有効）。GCが実行されているとき、どれだけのGC作業が必要で、どれだけの空き領域がアプリケーションに利用可能であるかという考えを持っています。歩調の管理者は、GCの進捗が十分な速度でない場合、スレッドの割り当てを停止しようとします。通常の状態では、GC はアプリケーションが割り当てるよりも速く収集し、歩調の管理者は当然ながら失速することはありません。歩調は、ローカルなスレッド毎の遅延を導入することに注意してください。この遅延は通常のプロファイリングツールでは見えません。このため、失速は無限ではなく、 -XX:ShenandoahPacingMaxDelay=#ms で制限されています。最大遅延の期限が過ぎると、いずれにせよ割り当ては行われます。ほとんどの場合、軽度の割り当て急増は、歩調の管理者によって解決されます。割り当て圧力が非常に高い場合、歩調の管理者は対処できず、低下は次のステップに 進みます。通常の遅延は<10 msで引き起こされます。 縮退GC ( -XX:+ShenandoahDegeneratedGC 、デフォルトで有効)。アプリケーションが割り当て失敗に陥った場合、Shenandoahはstop-the-worldによる停止に移行し、アプリケーション全体を停止し、一時中断下でサイクルを継続させます。縮退GCは、stop-the-worldの下で進行中の「並行」サイクルを継続します。多くの場合、割り当て失敗は、かなりの量のGC作業がすでに行われた後に起こり、GC作業のごく一部を完了させる必要があります。これが、STWの停止が通常大規模にならない理由です。それはGCログでGC停止のように報告されるでしょう。これは、通常の監視や定期的な監視をするスレッドばかりです。実際、STW 停止を発生させる理由の 1 つは、並行モードの障害を明確に観察できるようにすることです。GCサイクルがあまりにも遅く開始された場合、または非常に大きな割り当て急増が発生した場合、縮退GCが発生する可能性があります。縮退したサイクルは、同時実行のサイクルよりも速いかもしれません。なぜなら、リソースをめぐってアプリケーションと争うことがなく、スレッドプールのサイジングに -XX:ConcGCThreads ではなく -XX:ParallelGCThreads を使用するためです。通常<100msの遅延が誘発されます。ですが、縮退ポイントによってはそれ以上になることもあります。 フルGC。縮退したGCで十分なメモリが解放されなかった場合など、何をやってもダメな場合は、フルGCサイクルが発生し、ヒープを最大限まで圧縮してくれます。異常に断片化されたヒープと性能バグや見落としのような実装のようなあるシナリオは、フルGCによってのみ修正されるでしょう。この最後の手段のGCは、少なくともいくつかのメモリが利用可能である場合、アプリケーションがOOMで失敗しないことを保証します。通常100ms以上の遅延が発生します。特にヒープが非常に占有されている場合はそれ以上になることもあります。 個々の縮退GCとフルGCのイベントを表示する通常のGCログに加えて、 -Xlog:gc+stats は実行の最後に次のようなものを表示します。 Under allocation pressure, concurrent cycles may cancel, and either continue cycle under stop-the-world pause or result in stop-the-world Full GC. Increase heap size, tune GC heuristics, set more aggressive pacing delay, or lower allocation rate to avoid Degenerated and Full GC cycles. （割り当て圧力がかかると、並行サイクルがキャンセルされ、Stop-the-Worldによる停止で サイクルを継続するか、Stop-the-Worldを伴うフルGCとなる可能性があります。 ヒープサイズを増やす、GCのヒューリスティックを調整する、より積極的な歩調の遅延を設定する、 または縮退およびフルGCサイクルを回避するために割り当て率を下げて下さい） 4912 successful concurrent GCs（成功した並行GC） 0 invoked explicitly（明示的に起動） 3 Degenerated GCs（縮退GC） 3 caused by allocation failure（割り当て失敗による物） 3 happened at Update Refs（参照の更新で発生） 0 upgraded to Full GC（フルGCにアップグレードされた） 0 Full GCs（フルGC） 0 invoked explicitly（明示的に起動） 0 caused by allocation failure（割り当て失敗による物） 0 upgraded from Degenerated GC（縮退GCからアップグレードされた） ALLOCATION PACING:（割り当ての歩調） Max pacing delay is set for 10 ms.（最大の歩調の遅延は10msに設定） Higher delay would prevent application outpacing the GC, but it will hide the GC latencies from the STW pause times. Pacing affects the individual threads, and so it would also be invisible to the usual profiling tools, but would add up to end-to-end application latency. Raise max pacing delay with care. （遅延が大きいと、アプリケーションがGCを追い越すのを防げます。 しかし、それはSTWの停止時間からGCの遅延を隠すことになります。 歩調は個々のスレッドに影響します。そのため、通常のプロファイリングツールでは見えません。 しかし、それは結局アプリケーションの遅延を増加させることになります。 歩調の遅延の最大値を上げるには、注意が必要です。） Actual pacing delays histogram:（実際の歩調の遅れの推移） From - To Count 1 ms - 2 ms: 87 2 ms - 4 ms: 142 4 ms - 8 ms: 297 8 ms - 16 ms: 1733 16 ms - 32 ms: 21 32 ms - 64 ms: 1 このことから、アプリケーションがこれらの縮退のステップのいずれかに遭遇した場合に試すべきことがいくつかあります。 アプリケーションにもっとヒープを持たせる。これにより、GCが実行されているときに、より多くの割り当てを受けられるようになります。 ヒープ内の生きたデータの量を減らす。これにより、GCサイクルがより速く実行され、割り当てにうまく対処できるようになります。 割り当ての圧力を減らしてください。例えば、割り当てを行うスレッドの数を減らす、またはアプリケーションの主要な割り当ての負荷を修正します。 できるだけ早くGCサイクルを開始するためにヒューリスティックをチューニングします。GCログによると、GCはすでに連続してサイクルを実行している場合、それは役に立たないかもしれません。 歩調の遅延を増加させる。これは、縮退したGCやフルGCに昇格する代わりに、割り当てスレッドをより停止させるでしょう - これはまだそれらの割り当てスレッドに遅延をもたらすことに注意してください 性能分析 性能解析のアプローチ 割り当てに失敗してGCや長い最終マークのようないくつかのおかしな性能の挙動は、ヒューリスティックの問題で説明できます。 -Xlog:gc+ergo は、そこでのあなたの味方になります。もし、長時間稼働する負荷がある場合、Shenandoah Visualizerで実行すると、高レベルのGCの挙動を理解できます。時々、おかしな挙動がそこではっきり見えることがあります。 この性能差は、Shenandoahでの割り当て圧力がより大きいことで説明できます。それは各オブジェクトに転送ポインタが含まれるためです。それが問題かもしれないかどうか、割り当て率を見てください。そして、それを確認できるような実験をしてください（例えば、オブジェクトを改善することで、別のコレクタに対する性能差が減少するはずです）。メモリ使用量が大きいとCPUキャッシュから脱落するケースがあるので、L1/L2/LLCのミス差を調べてみてください。 多くのスループットの違いは、GCバリアのオーバーヘッドで説明できます。 -XX:ShenandoahGCHeuristics=passive で実行し、 このヒューリスティックのみ では、バリアは不要なので、ヒューリスティックはそれらを無効にします。その後、選択的にバリアを有効に戻し、どのバリアがスループット性能に影響を与えているかを確認できます。"passive"ヒューリスティックが無効にしているバリアの一覧は、以下のようにGC出力に一覧化されます。 $ java -XX:+UseShenandoahGC -XX:ShenandoahGCHeuristics=passive -Xlog:gc [0.002s][info][gc] Passive heuristics implies -XX:-ShenandoahSATBBarrier by default [0.002s][info][gc] Passive heuristics implies -XX:-ShenandoahKeepAliveBarrier by default [0.002s][info][gc] Passive heuristics implies -XX:-ShenandoahWriteBarrier by default [0.002s][info][gc] Passive heuristics implies -XX:-ShenandoahReadBarrier by default [0.002s][info][gc] Passive heuristics implies -XX:-ShenandoahStoreValReadBarrier by default [0.002s][info][gc] Passive heuristics implies -XX:-ShenandoahCASBarrier by default [0.002s][info][gc] Passive heuristics implies -XX:-ShenandoahAcmpBarrier by default [0.002s][info][gc] Passive heuristics implies -XX:-ShenandoahCloneBarrier by default [0.003s][info][gc] Using Shenandoah 4 . ネイティブGCコードのプロファイリングは、Linux perfで簡単にできます。 . OpenJDK を --with-native-debug-symbols=internal でビルドすると、C++ コードへの対応が得られます。 . perf record java ...で負荷を実行します。または perf record -g java ... で負荷を実行します。 . perf report でレポートを開きます。 . レポート内を移動し、疑わしいホットメソッド/パスがどこにあるかを確認します。メソッド上で "a "を押すと、通常そのメソッドの詳細な逆アセンブリが表示されます。 5 . バリアコードのプロファイリングには、PrintAssemblyが有効なビルドが必要です。JMH -prof perfasmを使って分離したシナリオを作成し、Shenandoahの下で生成されたコードを見ることをお勧めします。 通常のアプリケーションでは、GCによる停止だけが応答時間の大きな要因ではないと、理解することが重要です。大きな GC 停止があると、非常に高い確率で応答時間の問題が発生します。しかし、長い GC 停止がないからといって、常に適切な応答時間が得られるとは限りません。キューイング遅延、ネットワーク遅延、他のサービスの遅延、OSスケジューラのジッターなどがコストとして寄与している可能性があります。システムで何が起こっているかの全体像を把握するために、応答時間測定と共にShenandoahを実行することが推奨されます。これはその後、GC休止時間の統計と相関させるために使用できます。 例えば、これは、負荷の1つにjHiccupを使用したサンプルレポートです：

Red Hatの認定資格をご存知ですか？ 全世界共通の認定資格で、Linuxシステム管理のコアスキルから、DevOpsの認定資格まで、Red Hatのテクノロジー・ポートフォリオを網羅する、さまざまな認定資格があります。 一番の特徴は、資格を得るための認定試験は、すべて 「実技試験」 であるということ。 読んで覚えただけの知識を試す試験、ではなく、実務で必要となる作業が実際にこなせるかどうかを試す試験、になっています。 そのため、この認定資格を持っているということは、「現場で使える技術を身につけている」ことの証明になります。 具体的に、どのような認定資格があるのか、紹介します。 Red Hatの認定資格は、 全部で30種類 くらいあります。 これらは体系的になっていて、その最上位に君臨するのが、 Red Hat Certified Architect（RHCA） です。 Red Hat Certified Architect (RHCA) : Red Hat 認定アーキテクト Red Hat認定資格の最高位で、２種類あります。 Red Hat Certified Architect - Infrastructure - Red Hat Certified Architect - Enterprise Applications - インフラ系のエンジニアか、アプリ開発系のエンジニアかによって、どちらを目指すか選択できます。 それぞれ、指定された中から６つまたは７つの試験に合格することで、RHCAの認定が受けられます。 試験に合格することで付与される認定にはそれぞれ期限がありますが、続けて合格することで、認定の期限を延長することができます。 日本国内で、RHCA認定を持っている人は、 約10名 。 かなりの難関ということがうかがえますね。 どのようにして、RHCA認定を取得されたか？興味のある方はこちらのインタビュー記事をどうぞ！ インタビュー記事１ インタビュー記事２ まずはここから！Red Hat Certified System Admimistrator (RHCSA) : Red Hat 認定システム管理者 数ある認定資格の中でも、最も多くの方がチャレンジされる最初の入口ともいえるのが、この資格です。 Red Hat Enterprise Linux(RHEL)環境で必要なコアシステム管理スキルを実行できることを証明する資格です。 RHCSA認定試験（EX200） に合格すると、認定が付与されます。 RHCA - infrastructure -を目指すならば、まず最初に取る資格です。 Linuxの資格は、他社でもいくつかありますが、Enterpriseで最も多く利用されているLinuxである、Red Hat Enterprise Linux(RHEL)を実際に使えるスキルの証明として、RHCSAは高く評価されています。 RHCSAの国内認定者数は、約700名います。（現時点での有効数のみカウント） なお、各試験の合格には、まず、トレーニングコースを受講されることをおすすめします。 Red Hatトレーニングは、トレーニングベンダー様各社経由、または直接Red Hatにお申し込みいただけます。 たとえば、RHCSA資格取得を目指す場合、 RH199 RHCSA速習コース がおすすめです。 トレーニングコースは、インストラクターによるオンラインライブ形式の"バーチャルトレーニング"と、e-learning形式の"オンライントレーニング”とが選択できます。 次に目指すIT資格として、ぜひ、Red Hat 認定資格にチャレンジしてみてください。 Red Hat Training （松田）

こんにちは、Red Hat で Solution Architect をやっています 花田です。 本日は、 OpenShift Platform Plus *1 という製品をご紹介したいと思います。 Red Hat OpenShift Platform Plus とは Red Hat OpenShift Platform Plus は( 正式名は少し長いので、以下 OPP と呼ぶ事にします)、以下の既存製品から構成されているパッケージ製品です。 Red Hat OpenShift Container Platform (通称 OCP ) - Red Hat が提供する Kubernetes ディストリビューション Red Hat Advanced Cluster Management for Kubernetes (通称 ACM : 赤帽ブログ記事 ) - マルチクラスタ管理製品 Red Hat Advanced Cluster Security for Kubernetes (通称 ACS : 赤帽ブログ記事 ) - コンテナセキュリティ管理製品 Red Hat OpenShift Data Foundation Essential Edition(通称 ODF Essential Edition ) - Kubernetes の PV や Object Storage を提供する ストレージソフト Red Hat Quay の (オンプレミス版、1インスタンス分) - コンテナ・レジストリ製品 ( 赤帽ブログ記事 ) OPPが登場したのは 2021年5月 ですが、この時は ODF がパッケージに含まれていませんでした。が、 2022年のパッケージの見直しにより、 ODF Essential Edition が含まれるようになりました。 他の OpenShift 関連製品との関係を図に表すと以下のようになります。 OpenShift 関連製品の関係 一番小さい灰色の四角は、 OKE (OpenShift Kubernetes Engine) という OCP (OpenShift Container Platform) のサブパッケージです。OKE のパッケージ詳細については、こちらの「 OpenShift Kubernetes Engineのご紹介 」をご参照下さい。 図の真ん中に位置する OCP (OpenShift Container Platform) は、コンテナの開発や運用に必要な、Open Source 製品をパッケージにして提供しています。Monitoring 機能、Logging 機能、CI/CD ツール、Service Mesh 等のコンテナ環境の運用で必要なツールの他に、開発ツールや、コンテナを稼働させる ホストOS のエンタイトルメントまでも含んでいます。 一方で、コンテナが広く使われるようになり、エンタプライズ環境で、さらに厳しい要件がデフォルトで求められたり、構築までのスピードを求められる事が多くなってきました。しかしコンテナの周辺のエコシステムは複雑で全体のインフラ設計をするのも一苦労です。 OPP (OpenShift Platform Plus) では、 OCP (OpenShift Container Platform) の考え方を拡張して、別パッケージで単体としても販売されている ACM 、 ACS 、 Quay 、 ODF と言った製品もセットにし、コンテナ環境をエンタープライズ視点で構築する際に 必要なソフトウェアを、包括的に一つのパッケージとして提供 するものです。また、これらの製品を 個別に購入するよりも安価にご提供しています 。 OPP に付属する ODF の Edition OPP には標準で、 ODF Essential Edition が付属していますが、 ODF Advanced Edition に変更する事も可能です。 ODF Essential Edition ではホストNode の内蔵ディスクを使ってストレージを構築する Internal Mode だけが使用できますが、 ODF Advanced Edition では、クラスターの外部に Ceph ストレージ として単体で別途構築できる External Mode を使用する事ができます。 External Mode では複数の OpenShift クラスターからストレージを共有して使用する事ができます。他にも暗号化周りの機能をサポートしています。 またコンテナの大きな魅力は「可搬性 *2 」です。依存関係をコンテナのイメージ内に詰め込む事で、Linux 環境であれば簡単に別のホストに動かす事が可能です。 ただアプリケーションの「移動」と言った時には、アプリケーションが使用している Database などのデータも同時に移動させる必要があります。 ODF Advanced Edition では、クラスター間のデータのコピーを、同期で行う Metro DR や 、非同期で行う Reginal DR 等の機能もリリース予定です(原稿執筆時点)。これらの機能を使って、データを伴ったアプリケーションの「移動」をより楽に実現できるようになる予定です。 ソフトウェアが定義するインフラ 2010年前後に、 SDN(Software Defined Network) や SDS(Software Defined Storage) 、 SDDC(Software Defined Data Center) 、はたまた SDE(Software Defined Environment) などの Software Defined の考え方が流行し、たくさんの SDx という言葉が誕生しました。 これらの言葉が主に意味した所は、必要な機能の実装をハードウェア側に実装するよりも、コモディティのハードウェア上に、ソフトウェアを使った実装する事で、拡張性と柔軟性を手に入れようという試みです。 当時は、ソフトウェアによる仮想化が進む事で、ハードウェアレイヤーと切り離された世界が実現され、全てのハードウェアはコモディティ化する。と言う未来も提示されていました。 ですが、現在のIT界を見渡してみると、Host システムも、UNIXも健在です。 OpenFlow スイッチのような SDN を指向したスイッチやコモディティの x86マシンにソフトをインストールするタイプのネットワーク・スイッチよりも、Network ベンダー製の専用ハードウェア・スイッチが一般的と言って良いでしょう。ストレージでは、SDS 製品が存在感を示すようになりましたが、同時に専用ハードウェアのストレージも多くの場で活躍しています。 シェアに変動があるものの、これらの製品は、適材適所で使われている。という感じに収束しているように見えます。 同時に新しいインフラのレイヤーとして、クラウドプロバイダーが大きく普及しました。これらのプラットフォームは、ユーザー視点で見ると、APIで制御できるソフトウェアではありますが、ベンダー毎に違ったお作法が必要になる新しいインフラのプラットフォームです。同じ x86 のプラットフォームで構成されていても、クラウドプロバイダー独自のソフトウェアのレイヤーを被せる事により、個別の新しいインフラ・プラットフォームとなり、以前よりも選択肢と必要な知識の幅が増加した事になります。 振り返って見るとソフトウェアによる仮想化で、インフラの柔軟さが増した反面、 多くのプレイヤーが登場し、よりたくさんの知識を要求するようになった 印象も受けます。そして、私達の手元にあるのは、 より多くの選択肢 です。これは同時に大量の知識を要求するようになりますが、人間が一生のうちに処理できる知識と時間は限られています。 新しいインフラについての知識は最小限に抑え、オンプレミス、クラウド、どのインフラのプラットフォームでも同じようにアプリケーションがデプロイできるアプリケーション・プラットフォームが欲しくなります。 オープン・ハイブリッド・クラウド という未来 Red Hat では、「 オープン・ハイブリッド・クラウド 」 *3 という戦略を進めています。 OpenShift Platform Plus で提供されるソフトウェア群は、オンプレミス環境でも、クラウド環境でも、殆どの環境でインストール可能です。 これらのソフトウェア群を使えば、 異なるインフラ環境でもその違いを覆い隠し 、同じ Kubernetes 運用環境を構築する事ができます。 OpenShift は、 VMware の上でも ベアメタルサーバー 上でも、 AWS の上でも Azure の上でも GCP の上でも同じ OpenShift がインストールできます。マルチ・プラットフォームへの対応は、OpenShift が力を入れている分野の一つです。 ODF (OpenShift Data Foundation) を使えば、ホストOSにアタッチできる内蔵ディスクを使って、OpenShift から使用できるスケーラブルな SDS (Software Defined Storage) を作成できます。 VMware であれば、 vmdk ディスク を使った SDS が構成できますし、 AWS であれば、 EBS を使った SDS が構成できます。ストレージの違いは ODF が隠蔽してくれます。 ODF では様々なインターフェイスを提供しており、 RWX も RWO の PV (Persistent Volume) も、S3互換のオブジェクトストレージも使えます。 Open Hybrid Cloud で マルチ Cloud な環境 また、 Kubernetes の本番運用を考えていくと、複数クラスターの運用が視野に入ってきます。 ACM (Advanced Cluster Management for Kubernetes) は、複数クラスタの運用を簡単にするための製品で、コンソール上から VMWare や AWS 等のクラウドプロバイダー上に簡単に OpenShift クラスターの払い出しを行う事ができます。また、複数のクラスター間で、コンプライアンスが守られた設定がされているか設定を一元管理する事が可能です。 さらに、上の図で示されているように、 クラスター間を IPSec のオーバーレイ・ネットワークで結ぶ事が可能 なので、インターネットに公開していないアプリケーションを、クラスターをまたいで連携させる事も可能です。 ACS(Advanced Cluster Security for Kubernetes) も複数クラスターの管理に対応しており、運用中のコンテナの脆弱性のスキャンや、コンテナ内の不審なコマンドの実行や、いつもとは違う通信などの不審なアクティビティをチェックする事が可能です。 これらのクラスターにデプロイするコンテナを保管するコンテナレジストリーも必要です。 OPP のパッケージには、Red Hat のエンタープライズ向けコンテナ・レジストリーの Quay が含まれているので、 Quay を中央レジストリーとして活用する事が可能です。 まとめ プラットフォームの選択肢が広がった現在では、情報がたくさんあり過ぎるため、以前よりも特定のベンダーのインフラ技術に固定されやすくなっているように思います。 Red Hat の Kubernetes 製品スイートである、 OPP (OpenShift Platform Plus) を使う事で、異なるインフラ環境の違いをソフトウェアで吸収し、オンプレ、クラウド関わらず、同様に扱える Kubernetes 環境を構築する事ができます。 さらには、エンタープライズ向けのセキュリティ管理が全てのクラスターに適用でき、複数の OpenShift クラスタの構成管理も効率的に行う事ができます。 補則：OPPに含まれる各製品がサポートする環境 OPP にパッケージされている製品が全て同じ環境をサポートしているか。というとそういう訳でもありません。 メジャーな環境であれば、大体サポートしていると思って頂いて良いのですが、使用方法 (管理対象としてのサポートなのか、ソフトウェアインストール先としてのサポートなのか）等によっても異なってきますので、環境については公開されているドキュメントなどを参照し、確認が必要になります。 以下に公開されているサポート環境のドキュメントリンクをまとめました。(参照には、無償で作成できる Red Hat アカウント が必要です） OpenShift がテスト済みの環境 OpenShift Container Platform 4.x Tested Integrations (for x86_x64) OpenShift Container Platform 4.x Tested Integrations (for s390x) - Red Hat Customer Portal OpenShift Container Platform 4.x Tested Integrations (for ppc64le) - Red Hat Customer Portal ACMがサポートする環境 Red Hat Advanced Cluster Management for Kubernetes 2.4 Support Matrix - Red Hat Customer Portal ※ ACM は、バージョン毎にサポート環境のKBが出るので最新のものを参照して下さい。 ACS がサポートする環境 Red Hat Advanced Cluster Security for Kubernetes Support Policy - Red Hat Customer Portal ODF がサポートする環境 Red Hat OpenShift Data Foundation(previously known as OpenShift Container Storage) Supportability and Interoperability Guide - Red Hat Customer Portal Quay のテスト済み環境 Quay Enterprise 3.x Tested Integrations *1 : Red Hat OpenShift Platform Plus 製品紹介サイト *2 : コンテナの可搬性について、最近 こちらのブログ を書きましたので、よろしければ併せてご参照下さい。 *3 : オープンハイブリッドクラウド戦略

レッドハットの杉村です。Ansible のテクニカルサポートをしています。毎月1つは何か書くことを目標にしているのですが、3月があっという間に去ってしまいました。 今回はたまにお問い合わせいただく変数について紹介してみようと思います。Ansible のバージョンは Ansible Core 2.12.1 で試しています。 まずはこのような playbook を題材にしてみます。 --- - hosts: all tasks: - name: debug debug: msg: "Hello Ansible!" 実行するとこうなります。 $ ansible-playbook playbook.yml -i localhost, -e ansible_connection=local PLAY [all] ************************************************************************************************************************************************************************ TASK [Gathering Facts] ************************************************************************************************************************************************************ ok: [localhost] TASK [debug] ********************************************************************************************************************************************************************** ok: [localhost] => { "msg": "Hello Ansible!" } PLAY RECAP ************************************************************************************************************************************************************************ localhost : ok=2 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 モジュールに渡す変数 この Hello Ansible! の文字列を変数にすることができます。 --- - hosts: all tasks: - name: debug debug: msg: "{{ message }}" vars: message: "Hello Ansible!" debug モジュールについては、msg パラメータの代わりに変数を var パラメータで渡すこともできます。 --- - hosts: all tasks: - name: debug debug: var: message #msg: "{{ message }}" vars: message: "Hello Ansible!" タスクに定義する形ではあまりありがたくないかもしれません。プレイに定義することが多いでしょう。 --- - hosts: all vars: message: "Hello Ansible!" tasks: - name: debug debug: var: message ファイルに外出しすることもできます。variables.yml に書いたとします。 --- message: "Hello Ansible!" このとき playbook.yml ではファイル名を指定します。 --- - hosts: all vars_files: - variables.yml tasks: - name: debug debug: var: message 変数の型 上の例では変数は文字列でしたが、他にもこのようなものがあります。 真偽値 (true/false) 文字列 数値 ディクショナリ リスト 厳密なところは YAML の文法定義などを見ていただいて、ここではざっくりと紹介します。 真偽値 true を yes と書いたり、false を no と書いたりすることもできます。わたしは true / false が好みですが、Ansible のドキュメントでは yes / no で書いてあることもよくあります。True のように大文字で始める流儀も結構目にします。 文字列 ‘文字列’ や “文字列” のように書きます。”” の中で {{ }} を使って変数参照して連結するのがよくあります。 --- - hosts: all vars_files: - variables.yml tasks: - name: debug debug: msg: "Good morning! {{ message }}" 数値 file モジュールでよくひっかかるやつです。 - name: touch file: path: /tmp/temporaryfile.tmp state: touch mode: 644 例えばこのように書いて実行しますと、このようによくわからない権限がつけられてしまいます。644 が数値として解釈されたために、8進法では 1204 となってそのように設定されます。 $ ls -l /tmp/temporaryfile.tmp --w----r-T. 1 sugimura sugimura 0 4月 7 14:28 /tmp/temporaryfile.tmp 正しくはこのように文字列型として指定するか、8進法の数値であることを明示するために 0 で始めます。 - name: touch file: path: /tmp/temporaryfile.tmp state: touch mode: 0644 # mode: "0644" ... こちらをおすすめします ディクショナリ key: value の組を並べたものです。 --- a_dict_variable: foo: true bar: "hello" baz: 123456 このような形で定義します。変数名の後に、同じレベルのインデントで key: value の形で並べていきます。 --- - hosts: all vars_files: - dict.yml tasks: - name: debug debug: var: a_dict_variable 出力してみるとこのように出てきます。{ } でくくられています。 TASK [debug] ********************************************************************************************************************************************************************** ok: [localhost] => { "a_dict_variable": { "bar": "hello", "baz": 123456, "foo": true } } 中身を取り出すこともできます。 - name: debug debug: msg: "The numeric var is {{ a_dict_variable['baz'] }}" このように . で接続する形でも取れますが、変数名によっては取れないことがありますので注意してください。 - name: debug debug: msg: "The numeric var is {{ a_dict_variable.baz }}" docs.ansible.com リスト 他の言語では配列と呼ぶこともあります。同じ要素を並べているものです。 変数名の後ろで - を使って並べていきます。インデントはしなくてもいいようですが、したほうが好みです。 --- list_example: - "item1" - "item2" - "item3" 出力してみると [ ] でくくられていることがわかります。 TASK [debug] ********************************************************************************************************************************************************************** ok: [localhost] => { "list_example": [ "item1", "item2", "item3" ] } 配列は [n] で参照することができます。0 始まりです。 - name: debug debug: var: list_example[1] [1] は2番目なので、”item2” が取れています。 TASK [debug] ********************************************************************************************************************************************************************** ok: [localhost] => { "list_example[1]": "item2" } ディクショナリとリストの組み合わせ ディクショナリとリストを組み合わせることができます。 例えば setup モジュールではマネージドノード(管理対象)からさまざまな情報を収集して変数に格納することができますが、この変数はディクショナリとリストの組み合わせで成り立っていることがわかります。 $ ansible -m setup -i localhost, -e ansible_connection=local localhost localhost | SUCCESS => { "ansible_facts": { "ansible_all_ipv4_addresses": [ "192.168.0.xxx", "10.88.0.1" ], "ansible_all_ipv6_addresses": [ "2404:xxxx:xxxx:xxxx:250:56ff:xxxx:f278", "fe80::250:56ff:xxxx:f278", "fe80::54ff:d9ff:xxxx:1fe8" ], "ansible_apparmor": { "status": "disabled" }, "ansible_architecture": "x86_64", "ansible_bios_date": "12/24/2020", "ansible_bios_vendor": "VMware, Inc.", "ansible_bios_version": "VMW71.00V.17369862.B64.2012240522", "ansible_board_asset_tag": "NA", "ansible_board_name": "440BX Desktop Reference Platform", "ansible_board_serial": "NA", "ansible_board_vendor": "Intel Corporation", "ansible_board_version": "None", "ansible_chassis_asset_tag": "No Asset Tag", "ansible_chassis_serial": "NA", "ansible_chassis_vendor": "No Enclosure", "ansible_chassis_version": "N/A", "ansible_cmdline": { "BOOT_IMAGE": "(hd0,gpt2)/vmlinuz-4.18.0-348.el8.x86_64", "crashkernel": "auto", "quiet": true, "rd.lvm.lv": "rhel_rhel85/swap", "resume": "/dev/mapper/rhel_rhel85-swap", "rhgb": true, "ro": true, "root": "/dev/mapper/rhel_rhel85-root" }, ... "ansible_facts" は {} で始まっていることから全体としてはディクショナリになっていて、その要素の "ansible_all_ipv4_addresses" では IP アドレスがリストになっていたり、"ansible_cmdline" はさらにディクショナリになっていたりということがわかります。 ansible_facts は特別な処理を行っているので、この下の要素を直接指定して値を得ることができます。 --- - hosts: all gather_facts: true tasks: - name: debug debug: var: ansible_architecture リストを loop で回しつつ、その中の値をディクショナリとして参照するというのはよくある使い方です。 --- - hosts: all gather_facts: true tasks: - name: debug debug: msg: "{{ item.mount }} : {{ item.size_total }}" loop: "{{ ansible_mounts }}" 変数の加工 これまで見てきたものでほとんどの用途はカバーできますが、加工して条件判定や他のタスクに渡したくなったり、うまくループするために参照方法を工夫したいということがあります。このあたりのドキュメントをよく読んでいます。他にも役に立つものがありますので探してみてください。 docs.ansible.com docs.ansible.com docs.ansible.com docs.ansible.com 終わりに 今回は Ansible で扱う変数について紹介してみました。次回はこの変数を受け渡しすることについてまとめてみようと思います。 Ansible Automation Platform の試用版はこちらをご覧ください。 www.redhat.com Happy Automation!

皆さんこんにちは、Red Hat ソリューションアーキテクトの岡野です。 前回 で AAP2.1 への移行の考え方と手法についてご紹介しました。今回、Isolated Node の移行についてご説明します。Automation Controller から直接アクセスできないホストに対するジョブ実行に関しては、AAP 1.2 では Isolated Node がサポートされていました。この方法は Python の virtualenv を使っていたため、実行環境がコンテナ化された AAP 2.1 では利用できなくなってしまったのですが、それを置き換える機能として新たに『automation mesh』が実装されました！単に Isolated Node を置き換えるだけではなく、Automation Controller のスケーラビリティや管理性を飛躍的に向上させる凄く魅力的な機能です。♪ automation mesh 詳細 automation mesh を一言で言うと、Automation Controller の分割実装です。 『 4 種類のノードを必要に応じてメッシュ状に組み合わせて Automation Controller を構成できる』 これが automation mesh です。4 種類のノードは以下の通りです。 ハイブリッドノード コントロールノードと実行ノードの機能を併せ持つノード。旧 Ansible Tower ノードに相当します。 コントロールノード ダッシュボードや API、ジョブスケジュール、実行ログ、通知などバックエンドの処理を行うノード。PostgreSQL に接続される。ユーザージョブの実行は自身では行わず実行ノードに転送し実行する。 実行ノード コントロールノードやハイブリッドノードから転送されたジョブをコンテナ化された実行環境内で実行する。 ホップノード コントロールノードやハイブリッドノードからのジョブ実行命令を実行ノードに転送する。 つまり、Automation Controller を、『コントロールプレーン』、『実行プレーン』、そして『転送プレーン』に分割して構成できるのが automation mesh です。この機能により、 『 ホップノード』を使った分離されたネットワークへのジョブ転送 『実行ノード』追加による容易なスケールアウト（管理対象ノードが増えてきた時など） 『ハイブリッドノード』または『コントロールノード』による実行環境の集中コントロール が可能となりました。 AAP 1.2 では分離されたネットワークへの対応は Isolated ノードを使ってジョブ実行を行っていました。Isolated Node への接続は ssh (port 22) で、必要に応じ Jumphost で多段接続するようなちょっとした『力技』を使っていましたが、AAP 2.1 では各ノードの接続用に receptor (port 27199) という仕組みが組み込まれ、ジョブが receptor を通じで必要な実行ノードに転送され、実行されます。 automation mesh の構築に関してはインストール時のインベントリーファイルにノードの種別と接続先を入力するだけ。インストール後に変数等の設定を行う必要も無いため簡単です。 また、AAP 1.2 の Isolated ノードは、Python の virtualenv を使っていたため、実行環境の更新やカスタム化された実行環境が必要になった場合、各 Isolated Node を手動で更新する必要がありましたが、AAP 2.1 では実行環境がコンテナ化されたために集中管理できるようになり、管理性が大幅に向上しました。管理対象ノードが増えてきた際は、実行ノードを簡単に追加できるため拡張性にも優れます。 AAP 1.2 の Isolated Node と AAP 2.1 の automation mesh の比較は以下の通りです。 Automation Controller の構成（例）と構成するためのインベントリーファイルの例（抜粋）を 3つ示します。勿論これ以外にも柔軟に構成は可能です。 1. 『ハイブリッドノード』のみで構成した例 ハイブリッドノードを Cluster で構成していますが、実行ノードやホップノードを含まない基本的な構成例です。旧 AAP 1.2 でも同様の構成が可能です。 [automationcontroller] aac00.example.com aac01.example.com aac02.example.com aac03.example.com [database] db00.example.com ...以下略... 2. 『コントロールノード』+『実行ノード』で構成した例 管理系はコントロールノード、ユーザーのジョブ実行は実行ノードで分けて構成した例です。AAP 1.2 の Isolated ノードに近い構成です。赤で示したコンテナ化された実行環境 ee は、ユーザージョブを実行する実行ノードだけでなく、管理系のジョブを実行するコントロールノードにもダウンロードされます。 [automationcontroller] aac00.example.com node_type=control peers=execution_nodes aac01.example.com node_type=control peers=execution_nodes aac02.example.com node_type=control peers=execution_nodes [execution_nodes] ee00.example.com node_type=execution ee01.example.com node_type=execution ee02.example.com node_type=execution ee03.example.com node_type=execution [database] db00.example.com ...以下略... ※ node_type でノード種別 control 、 execution 、 hop を明示的に指定します。 メッシュによるノード間接続に関しては、 peers で、『送信元側』に『接続先』として記述します。上記例ではコントロールノードに接続先として実行ノードを指定しています。上記例では、 peers でグループ名 execution_nodes を接続先として指定していますがホスト個別での指定も可能です。 3. 『コントロールノード』と『実行ノード』を『ホップノード』で接続した例 ネットワークが多段に分離されている場合に有用な構成例です。ジョブ転送のみ行うホップノードを組み込んでいます。ホップノードはジョブ実行を行わないため実行環境のダウンロードは行われません。 [automationcontroller] aac00.example.com node_type=control peers=hop00.example.com,hop01.example.com aac01.example.com node_type=control peers=hop00.example.com,hop01.example.com aac02.example.com node_type=control peers=hop00.example.com,hop01.example.com [execution_nodes] hop00.example.com node_type=hop peers=ee00.example.com,ee01.example.com,ee02.example.com hop01.example.com node_type=hop peers=ee00.example.com,ee01.example.com,ee02.example.com ee00.example.com node_type=execution ee01.example.com node_type=execution ee02.example.com node_type=execution [database] db00.example.com ...以下略... こちらは、 peers でグループ名を使わずホスト個別に記述しています。 Isolated Node を含む AAP 1.2 環境のアップグレードの際の注意点 2022年4月時点（Ansible Tower 3.8.5-3 / AAP 2.1.1）で以下のことが分かっています。Isolated Node を含む、AAP 1.2 のアップグレードを行う際はご注意ください。 AAP 1.2 から AAP 2.1 へはインプレースアップグレードが出来るので、単純に考えると、 Ansible Tower 3.8 + Isolated Node の構成を以下の様にアップグレードしたくなるかも知れません・・・、が、実はこのアップグレード、実行すると失敗します。つまり現時点では出来ません。 Ansible Tower 3.8 ---> AAP 2.1 ハイブリッドノード Isolated Node ---> AAP 2.1 実行ノード これは、AAP 1.2 の Isolated Node にインストールされている ansible-runner v1 から、AAP 2.1 の ansible-runner v2 へのアップグレードがサポートされていない、つまり失敗する事に起因する様です。 では、どうすれば良いかというと、AAP 2.1 の実行ノードを新規で準備（可能ならIsolated Node と同一ホスト名、IP アドレスで準備*）し、インプレースアップグレードを行えば OK です。以下のような感じです。 Ansible Tower 3.8 ---> AAP 2.1 ハイブリッドノード 新規 RHEL 8.4 or later ---> AAP 2.1 実行ノード つまり、旧 Isolated Node はアップグレードホストとしては利用しない、という事ですね。 *アップグレードではインスタンスグループの情報も維持されるため、AAP 2.1 環境へのアップグレード後、インスタンスグループの再設定が不要で手間が省けます。 まとめ 今回、AAP 1.2 環境で、Isolated Nodeを利用している場合の移行方法と、AAP 2.1 注目の新機能、automation mesh についてご説明させていただきました。automation mesh は拡張性と管理性に優れた魅力的な機能を提供します。AAP 1.2 で Isolated Nodeをご利用の方は是非、AAP 2.1 の automation mesh に移行いただければと思います。♬ automation mesh の詳細については以下のマニュアルを参照ください。 access.redhat.com

Red Hat で Java Platform Advocate として OpenJDK を担当している伊藤ちひろ（ @chiroito ）です。 この記事は、OpenJDK のWikiページ、 https://wiki.openjdk.java.net/display/shenandoah/Main の一部を翻訳した記事です。何回かに分けて翻訳していきますので、ぜひ最後までごらん下さい。 翻訳の各リンクはこちらです。 Shenandoah GCのサポート概要とバグ報告について - 赤帽エンジニアブログ Shenandoah GCの実装概要 - 赤帽エンジニアブログ Shenandoah GCの性能指針と診断 - 赤帽エンジニアブログ Shenandoah GCの機能診断 - 赤帽エンジニアブログ 実装の概要 実装の概要 Shenandoahは領域化されたコレクタであり、ヒープを領域の集合体として維持します。 通常のShenandoahのGCサイクルは、以下のようになります： GC(3) Pause Init Mark 0.771ms GC(3) Concurrent marking 76480M->77212M(102400M) 633.213ms GC(3) Pause Final Mark 1.821ms GC(3) Concurrent cleanup 77224M->66592M(102400M) 3.112ms GC(3) Concurrent evacuation 66592M->75640M(102400M) 405.312ms GC(3) Pause Init Update Refs 0.084ms GC(3) Concurrent update references 75700M->76424M(102400M) 354.341ms GC(3) Pause Final Update Refs 0.409ms GC(3) Concurrent cleanup 76244M->56620M(102400M) 12.242ms 上記のフェーズでは、おおよそ以下のようなことをします： Init Markは並行マーキングを開始します。ヒープとアプリケーションスレッドを並行マーク用に準備し、次にルートセットをスキャンします。これはサイクルの最初の停止であり、最も支配的な消費者はルートセットのスキャンです。したがって、その持続時間はルートセットサイズに依存します。 並行マーキングはヒープ上を走査し、到達可能なオブジェクトを追跡します。このフェーズはアプリケーションと並行して実行されます。そして、その時間は生きているオブジェクトの数とヒープ内のオブジェクトグラフの構造に依存します。このフェーズでは、アプリケーションは新しいデータを自由に割り当てられるため、並行マーキング中はヒープ占有率が上昇します。 Final Markは、保留中のマーキング/更新キューをすべて排出し、ルートセットを再スキャンすることで、並行マーキングを終了します。また、退避させる領域（コレクションセット）を決定し、いくつかのルートを事前に退避させ、一般的に次のフェーズのための処理を準備することによって、退避を初期化します。この作業の一部は、並行事前クリーニング・フェーズの間に同時に行われます。これはサイクルの2番目の停止で、ここで最も支配的な時間消費者は、キューを排出し、ルートセットをスキャンすることです。 並行クリーンアップは、即時ゴミ領域が再要求されます。この領域はつまり、並行マーキングの後に検出された生きているオブジェクトが存在しない領域です。 並行退避は、コレクションセットから他の領域にオブジェクトをコピーします。ここが他のOpenJDKのGCと大きく異なる点です。このフェーズは再びアプリケーションと一緒に実行されます。そして、アプリケーションは自由に割り当てられます。その期間は、そのサイクルで選択されたコレクションセットのサイズに依存します。 参照更新の初期化（Init-UR）は、参照元を更新するフェーズを初期化します。これは、すべてのGCとアプリケーションのスレッドで退避を完了したことを確認し、次のフェーズのためにGCを準備する以外はほとんど何もしません。これはサイクルの3番目の休止で、すべての中で最も短いものです。 並行更新参照はヒープ上を走査し、並行退避中に移動したオブジェクトへの参照を更新します。ここが他のOpenJDKのGCとの大きな違いです。その時間はヒープ内のオブジェクト数に依存しますが、オブジェクトグラフ構造には依存しません。なぜなら、ヒープを直線的にスキャンするためです。このフェーズは、アプリケーションと同時に実行されます。 最終参照更新（Filan-UR）は、既存のルートセットを再更新することで、参照更新フェーズを終了します。また、そのコレクションセットから領域を再利用します。なぜなら、現在ヒープには（古い）オブジェクトへの参照はないからです。これはサイクルの最後の停止です。その期間はルートセットのサイズに依存します。 並行クリーンアップでは、コレクションセット領域が再要求されます。これは現在ではその領域への参照はないためです。

Red Hat で Java Platform Advocate として OpenJDK を担当している伊藤ちひろ（ @chiroito ）です。 この記事は、OpenJDK のWikiページ、 https://wiki.openjdk.java.net/display/shenandoah/Main の一部を翻訳した記事です。何回かに分けて翻訳していきますので、ぜひ最後までごらん下さい。 翻訳の各リンクはこちらです。 Shenandoah GCのサポート概要とバグ報告について - 赤帽エンジニアブログ Shenandoah GCの実装概要 - 赤帽エンジニアブログ Shenandoah GCの性能指針と診断 - 赤帽エンジニアブログ Shenandoah GCの機能診断 - 赤帽エンジニアブログ Shenandoahは低い停止時間のガベージコレクタです。これは、実行中のJavaプログラムと同時に、より多くのガベージコレクション作業を行うことで、GCの停止時間を短縮します。Shenandoahは、同時コンパクションを含め、GC作業の大部分を同時進行で行います。つまり、停止時間はヒープサイズに正比例しなくなりました。200GBのヒープをガベージコレクションしても、2GBのヒープをガベージコレクションしても、同様の低い停止時間の動作になるべきです。 サポート概要 OS サポート ハードウェアサポート JDK サポート リリース ナイトリービルド サポート概要 OS サポート ShenandoahはOSから特別な要求があるわけではありません。しかし、ビルドにはコードをいじる必要があるかもしれません。 サポート コメント Linux 主要ターゲット、継続的にテスト Windows 次点のターゲット、継続的にテスト macOS 追加ターゲット、コミュニティでテスト Solaris 追加ターゲット、コミュニティでテスト. その他 移植は些細なことであるはずです。成功・失敗の報告をShenandoahの開発者に連絡してみてください ハードウェアサポート Shenandoahは、いくつかのハードウェア固有のビットを実装する必要があります。移植には、いくつかのアセンブリレベルのコーディングが必要です。 サポート コメント x86_64 主要ターゲット、継続的にテスト x86_32 次点ターゲット、継続的にテスト AArch64 主要ターゲット、継続的にテスト PPC64 次点ターゲット、コミュニティによるテスト RISCV64 次点ターゲット、コミュニティによるテスト。riscv-portの一部 ARM32 ゆっくり開発中、ヘルプ歓迎 S390X サポートしてません。貢献歓迎 SPARC サポートしてません。試験をするハードウェアがない Others 他のプラットフォームにShenandoahを移植する意思がある場合は、Shenandoah開発者に連絡して指導を受けてください。 JDK サポート Shenandoahは、アップストリームのOpenJDK 12+ ( JEP 189 )に含まれています。その後、OpenJDK 11u にコントリビュートされました。 OpenJDK 8uへのダウンストリームバックポートも利用可能です。Shenandoahは、"express "開発モデルに従っています。機能およびバグフィックスは、サポートされる以前のJDKリリースに継続的にバックポートされます。重要なバグフィックスは、最初にバックポートされます。そして、できるだけ早くリリースされます。クリティカルでないバグフィックスや機能は、少し遅れてバックポートされるかもしれません。共有GCやランタイムコードの改良は、簡単にバックポートできないかもしれません。OpenJDK Updatesプロジェクトの一部として、それらのいくつかはバックポートされています。主要なGCの改良は、さらに後に出荷されるかもしれません。 Supported Ready for Production Role Comment JDK 8 安定版LTS 8uの主流ではないバックポートとして利用可能です。利用可能かどうかはベンダに確認してください。以下の既知のベンダーのリストを参照してください。 JDK 9 終了、早急に11/17に移行してください。 JDK 10 終了、早急に11/17に移行してください。 JDK 11 安定版LTS 11.0.9以降OpenJDK 11uに搭載されています。ビルド時に事前の許可が必要です。利用可能かどうかはベンダに確認してください。以下の既知のベンダーのリストを参照してください。 JDK 12 終了、早急に17に移行してください。 JDK 13 終了、17に移行してください。 JDK 14 終了、17に移行してください。 JDK 15 終了、17に移行してください。 JDK 16 終了、17に移行してください。 JDK 17 安定版LTS 主流のOpenJDKビルドです JDK 18 Dev/Test 主流のOpenJDKビルドです 最新のJDKリリースを選択しなくても、ほとんどの修正と便利な機能を利用することができます。しかし、後の方のリリースの方がより最新である可能性があります。 開発リポジトリとビルドの間でどのように変更が行われるのか、その詳細を理解したい場合は、 こちら をご覧ください。 リリース Shenandoahの利用可能性は、ベンダーやJDKのリリースによって異なります。OpenJDK 12以降のビルドは、通常、デフォルトでShenandoahを含んでいます。OpenJDK 11では、ビルド時に事前の許可が必要です。 既知のベンダーのステータスは Red Hat Fedora 24+ OpenJDK 8+ ビルドはShenandoahを含む RHEL 7.4+ は 技術プレビュー としてShenandoah GCを含んだOpenJDK 8+ があります。 Red Hat OpenJDK 8u builds for Windows はShenandoah を含む Amazon Amazon Correttoは, OpenJDK 11.0.9からShenandoahを含む Oracle OpenJDKビルドと独自ビルドの両方において如何なるリリースでShenandoahを 含めない 。 Azul Azul Zuluは, OpenJDK 11.0.9からShenandoahを含む SAP (ステータス不明) AdoptOpenJDK デフォルトバイナリで, OpenJDK 11.0.9からShenandoahを含む Linux distributions Debian は, OpenJDK 11.0.9からShenandoahを含む Gentoo ebuilds for IcedTea は Shenandoah を使うフラグ を持つ RHEL/Fedoraをベースとするディストリビューションやそれらのパッケージを使う他のディストリビューションもまたShenandoahが有効化されている。注目すべきは, CentOS, Oracle Linux, とAmazon Linux には含まれていると知られています。 ナイトリービルド これらの場所では、（毎晩/毎週）開発ビルドが公開されています： Linuxのナイトリービルドは builds.shipilev.net で入手可能です。 Linux/x86_64 のナイトリービルドは Docker イメージ としても利用可能です。 例： # イメージを最新のものに更新： $ docker pull shipilev/openjdk $ docker pull shipilev/openjdk:11 $ docker pull shipilev/openjdk-shenandoah:8 # 最新版の実行： $ docker run --rm -it shipilev/openjdk java -XX :+UseShenandoahGC -Xlog :gc -version [ 0 .007s ][ info ][ gc ] Using Shenandoah ... # JDK 11 バージョンを実行： $ docker run --rm -it shipilev/openjdk:11 java -XX :+UseShenandoahGC -Xlog :gc -version [ 0 .008s ][ info ][ gc ] Using Shenandoah ... # JDK 8 バックポート： $ docker run --rm -it shipilev/openjdk-shenandoah:8 java -XX :+UseShenandoahGC -verbose :gc -version ... バグを報告 バグを報告するには、いくつかの方法があります。以下はそのチェックリストです： 最新のナイトリービルドを試す。上のセクションを参照。 以下の「機能診断」と「パフォーマンス診断」のセクションのテクニックを使って、バグを絞り込んでみてください。 その問題に対する最小限のテストケースを考えてみてください。開発者が自分でビルドして実行できるのであれば、大規模なプロジェクトも問題ありません。 以下の3つの選択肢で、バグレポートを提出してください： すべてのJDKのバージョン： shenandoah-dev メーリングリスト にメッセージを送る。このメーリングリストは管理されているので、最初に購読するか、進行役があなたのメッセージを受け入れるのを待ちます。 JDK 8, JDK 11：Red Hatのサブスクリプションに加入しており、FedoraまたはRHELからバイナリを実行している場合、Red Hatのサポートを通じてバグを報告してください。 JDK 12 以降：OpenJDKのバグレポートに、どのビルドで動作しているのかを明記して提出してください。これは、Shenandoahの開発者に渡す前に、Oracleの人々が最初にバグを受け入れることを必要とします。 いくつかの追加の質問に答えられるように準備しておきましょう。 時間があれば、パッチやナイトリーバイナリーをテストする準備をしておいてください。

こんにちは。Red Hatでソリューションアーキテクトをしている杉本 拓です。 今回はクラウドネイティブなAPI管理ソリューションである Kuadrant に含まれている、APIをセキュアにするための新しいオープンソースプロジェクト Authorino について、 Red Hat Developer のブログ記事 Authorino: Making open source, cloud-native API security simple and flexible の翻訳を通じて紹介をしたいと思います。 なお、赤帽エンジニアブログの別の記事において、このAuthorinoのサンプルアプリケーションの動かし方について紹介していますので、そちらもご覧いただければ幸いです。 rheb.hatenablog.com Authorino: Making open source, cloud-native API security simple and flexible (クラウドネイティブなAPIセキュリティをシンプルかつ柔軟にするオープンソース) Authorino は、インターネットの利用がより安全にできるようにアプリケーションの改修を行う際、 セキュリティ のことを考慮されずに構築されたAPIに対して認証や認可を追加しなければならないという、常に発生する問題に対してソリューションを提供するものです。Authorinoを使用すれば、簡単でクラウドネイティブなやり方で、そのようなAPIを公開することができるようになります。APIを修正したり、作り直したりする必要はありません。Authorinoは外部の認可フィルタを備えた軽量なリバースプロキシ層で、 Kubernetes のAPI経由で全て設定が可能となっており、要件に応じて適切な認証・認可モデルを追加することができます。 この記事では、Authorinoの用途とメリットの概要、その基本的な仕組み、そしてユースケース例に基づく簡単なデモンストレーションを紹介します。 Authorinoのユースケース Authorinoの使用頻度の高いシナリオを想像してみましょう。例えば自分が APIの開発者 であるとして、何か要件が明確になったり、面白そうな機能拡張の要望が新しく来たとします。あなたはホワイトボードのところに行き、サービスとAPIをベースにした素晴らしいソフトウェアのソリューションを思いつきます。あなたは自分のお気に入りの開発ツールを選び、プロジェクトにおいて重要な機能のコーディングに取りかかります。数時間から数日で、ベータ版を公開し、実際に使ってもらうことができるようになりました。あなたのソリューションは、機能的に豊富ではありませんが、求められていた機能には重点が置かれ、効率的に作られています。万事順調でした。ある現実的な要件、特にアクセスコントロールの要件が現れてくるまでは。 さて、あなたは微細なセキュリティに関する問いに対応しなくてはならなくなりました。誰がAPIにアクセスするのか？ ユーザーのIDはどのように確認するのか？ ユーザーはデータベースに格納すべきか？ パーミッションについてはどうでしょうか？ 認可のルールはどれくらいの頻度で変更されるのか？ ロールベースのアクセスコントロール(RBAC)を実装すべきか？ 読み取り専用アクセスを許可すべきでしょうか？ このように動的かつ複雑なこともある様々なポリシーを適用しなくてはならず、準拠すべき認証・認可の標準やプロトコルもあり、認可のシステムも複数あり、さらにはレガシーシステムとの連携も必要となってくるとなると、APIをセキュアにするということに対して、あっという間に途方に暮れてしまいます。 アクセス制御のルールをすべてAPIの実装コードに押し込むことは、設計上の重要な原則である「関心事の分離」に明らかに反することになります。もしそのようなことをしてしまうと、APIが本来持つべき機能、パフォーマンス、保守性、スケーラビリティなどに問題が生じることになるでしょう。if else文でソースコードが汚くなってしまうだけでなく、アクセス制御をソースコードに組み込んでしまうことにより、実装とライブラリや周辺テクノロジーとの結合度が強くなってしまい、コードの再利用性は確実に制限されてしまいます。 一方、市場にある特化型の個別ソリューションはあまり魅力的とは言えず、かと言って別途サーバを立ち上げ、複雑な設定ファイルを扱って...、というのもあまりいいとは思われません。 今時の開発者が望むのは、パフォーマンスに優れ、アプリケーションのコアな部分に集中できるような、特化型でいいソリューションです。また、彼らが望むのは既存のインフラや使い慣れている開発言語と技術要素を活かしつつ、習得が容易でデプロイや運用も簡単なソリューションでもあります。 Authorinoとは？ youtu.be Authorinoは、APIを保護するためのKubernetesネイティブな外部認可サービスの オープンソース です。API設計のリバースプロキシパターンに基づいて構築され、APIの ゼロトラストセキュリティ をサポートします。Authorinoは、ネットワークのエッジやバックエンドサービス、コンテナ間のクラスタ内通信（内部プロキシ経由）、受信トラフィック（ingress ゲートウェイ経由）など、いろんな場所で動作します。 Authorinoは Envoyプロキシ の上に構築され、 gRPCプロトコル を使用して External Authorization (外部システムでの認証認可) を行います。そのプロキシ上で、AuthorinoはAPIへのリクエストに対して非常に高速にユーザIDの検証と認可ポリシーの適用を行うレイヤーとなり、これにより適切に認証および認可されない限り、トラフィックがサービスに到達するのを防ぎます。 Authorinoを使用することにより、APIキー、 OpenID Connect（署名入りJSON Web トークン） 、 OAuth 2.0イントロスペクション 、 Kubernetes認証 などを使用してAPIの公開と認証トークン/クレデンシャルの検証を行うことが可能です。またAuthorinoでは、シンプルなJSONパターンマッチングルール（JWTクレームチェックやHTTPリクエスト属性チェックなど）、複雑な Open Policy Agent (OPA) Regoポリシー 、 Kubernetes SubjectAccessReview (Kubernetes RBAC)などの認可ポリシーによる、柔軟なアクセス制御が可能になります。業界標準やプロトコルの中から最適なものを選択し、それらを組み合わせて使用することができます。外部の認証サーバーやリソースデータのレジストリと接続したり、キャッシュを利用したり、デプロイメントのトポロジーにおいても集中型ゲートウェイやサイドカーなど様々な方式から選択が可能です。 Authorinoを使用するメリット Authorinoは、現代のWebに関わる様々な認可の要件に対応することができます。以下はそのメリットの一部です： 汎用性: Authorinoにより、互換性の高いAPIセキュリティの実現が可能になります。Authorinoは何か特定の仕様を強制するものではなく、何かをするのに一つの方法しかできないということがないようにしています。そのため、APIキー、OAuth 2.0、OIDC、ネイティブなKubernetes認証トークン、 Red Hat OpenShift のユーザー認証、 mTLS 等々、さまざまな認証モデルやプロトコルをサポートしています。API保護のニーズに最も適した方式を1つ選択することも、あるいは複数を組み合わせて別のIDソースと連携しながら、各ユーザーグループに対してアサーティブで適切な認可ポリシーを適用することができます。Authorinoには、 Open Policy Agent (OPA)とJSONパターンマッチングに基づいてポリシーを評価する強力な仕組みが組み込まれており、エッジに格納されたユーザー情報、JWT、コンテキスト、あるいはその場で取得してキャッシュされた属性データに基づいたRBAC、UBAC、またはABACなど、あらゆる種類のアクセス制御の方式を実装するための認可ルールを記述することができます。AuthorinoはKubernetesのSubjectAccessReviewに基づく認可もサポートしています。 クリーン: Authorinoを使えば、開発者はAPIソリューションのコアな部分に集中でき、認証サーバーやIDプロバイダーとの統合、ユーザープロファイルの管理、複雑なアクセス制御システムのif else文の処理など、認証認可の処理に関わるオーバーヘッドをすべて強力なセキュリティエージェントに任せることができます。Envoyフィルターを使用したAPIへのアクセスにおいてリバースプロキシやゲートウェイのパターンを活用することで、AuthorinoはAPIのセキュリティを強化しつつ、ほとんどのユースケースでAPIのコードに変更を加える必要がありません。 Kubernetesネイティブ: AuthorinoはKubernetes上で動作するように設計されています。不親切な設定ファイルや標準化されていない管理用APIの代わりに、 Kubernetesのカスタムリソース を通じてAuthorinoでサービスを保護することができるようになります。Authorinoのカスタムコントローラは、Kubernetesサーバー内のリソースの状態を監視し、信頼できる唯一のデータソースが確実なものであるとすることで、真のクラウドネイティブなユーザーエクスペリエンスを提供します。もちろん、コンテナオーケストレーションの環境で当然期待されるような、スケーリング、自動化、監視、監査も可能です。稼働しているAPIのセキュリティの状態を誰が変更できるのかに関しても、API開発者に直接責任を委ねるのか、あるいは DevOps や SRE を含めたより複雑なワークフローで処理するのか、KubernetesのRBACを利用した権限管理を行うことができます。 柔軟性: Authorinoは、APIのネットワークアーキテクチャに関しても何かを強制することはありません。むしろ1つのプロキシ構成で複数のAPIに対応する一般的なシングルゲートウェイのトポロジーに対応したり、集中型または完全分散型のAuthorinoサイドカーに接続する専用プロキシにすることもできます。Authorinoは柔軟で、完全にステートレスなアプリケーションであり、硬直的なアーキテクチャにならず、本質的なボトルネックも無いため、DevOpsチームはNorth-SouthあるいはEast-WestのAPIアクセスのいずれにも対応したスケーリングを自在に実現することができます。 効率性: APIセキュリティのスタックにはキャッシュのレイヤーが自動的に追加されます。OpenID Connectや User-Managed Access （UMA）の設定、JSON Web Key Set（JWKS）、コンパイル済みのOPAポリシーなど、さまざまなオプションが用意されています。今後、失効したアクセストークンの情報や、要求されたリソースデータのキャッシュ機能も追加される予定です。 シームレス: Authorinoはスタンドアローンで使用することもできますが、今後 Red Hat 3scale API Management がKuadrant連携して利用することも可能になる予定です。Kuadrantは、Authorinoとの認証・認可をはじめ、流量制御、OASのサポート、カスタムの開発者ポータルなど、完全にクラウドネイティブなAPI管理を実現するものです。Kuadrantのデータプレーンにより、Kubernetesサービス、Ingressゲートウェイ、OpenShiftルート、Istio VirtualServicesやHTTPRoutesなどのネットワークリソースとAPI管理機能のオーケストレーションをシンプルかつまとまりのある形で行うことができ、高レベルのAPI仕様をAuthorinoカスタムリソースを含む低レベルのリソースに変換してくれます。 オープンソース: Authorinoは、Kubernetes、OpenShift、OAuth、OIDC、OPA、UMAなど、信頼性が高く、広く採用されているオープンソースの技術に基づいています。AuthorinoはGo言語で書かれており、Red Hatの支援を受けています。 Authorinoの仕組み AuthorinoはEnvoy ProxyのExternal Authorizationを利用し、gRPCプロトコルを実装しています。まず最初にAPIの開発者がAPIを実装してデプロイし、Envoy ProxyのエンドポイントでそのAPIを公開します。プロキシは、External Authorizationフィルタとその呼び出し先であるAuthorinoサービスを設定する必要があります。開発者はAPIを公開するトポロジーに合わせてこの設定を手動で行うこともできますし、Kuadrantが提供する自動化機能を活用することもできます。APIに対する保護機能の追加とリクエストの受け付けの開始を効果的に行うためには、開発者はKubernetesの AuthConfig カスタムリソース（CR）をクラスターに適用します。 AuthConfig CRには、APIへのリクエストに適用されるID検証と認可のルールを記述します。ユーザークレデンシャルやアクセストークンを検証する際に信頼できるIDソースと認証方式をリストアップし、認証は、OIDCのJWT、OAuth 2.0 opaqueトークンイントロスペクション、Kubernetesのアクセストークンなどのプロトコルを使用して外部の認証サーバーやIdPで行うこともでき（アクセストークンの検証はリクエスト時にAuthorinoが行います）、あるいはAPIキー、mTLS、HMAC認証などの組み込みの方式を使用して行うことも可能です。 AuthConfig CRでは、認可の形式を定義することも可能です。Authorinoの認可ポリシーは、単純なJSONパターンマッチングルール（JWTクレームチェックなど）として表現したり、インラインで記述されたり外部のポリシーレジストリから取得したOpen Policy Agent (OPA) Rego言語 で定義したり、あるいはKubernetesのSubjectAccessReviewに基づく認可を使用することも可能です。 保護されたAPIを利用するユーザーは、有効なトークンまたはクレデンシャルを取得してAPIにアクセスし、指定された認証フィールド（HTTPのAuthorizationヘッダー、カスタムヘッダー、クエリー文字列のパラメーター、あるいはクッキーなど）にそれらのクレデンシャルを格納してリクエストを送信します。リクエストはEnvoy Proxyによってインターセプトされ、Envoy ProxyはAuthorinoとのgRPC接続を高速に行います。Authorinoは、ポリシーを適用するために有効なカスタムリソースを検索し、認証パイプラインをトリガーします。Authorinoは認証パイプラインを通じて、提供されたトークンまたはクレデンシャルが少なくとも1つの信頼できるIDソースに受け入れられているか、そしてすべての認可ポリシーでAPIで要求されたリソースに対するユーザーのアクセスが許可されているかどうかを検証します。図1はその基本的なフローを示しています。 図1: プロキシを介した認可におけるAuthorinoの役割を示すシーケンス図 認可ポリシーは、リクエストのコンテキストデータ（HTTPリクエストの属性など）、クレデンシャルから解決されたIDの属性（ユーザー情報、JWTクレームなど）、外部サービスから取得したメタデータなど、認証パイプラインを通じて収集されたあらゆる情報を利用することができます。 Authorinoはリクエストごとに認可JSONを生成し、それが実行時に認可ポリシーが評価される際のインプットとなります。ポリシーはRego言語で記述したり、組み込みのOPAモジュールで実行したり、SubjectAccessReviewを使用してKubernetesのRBACの評価を行ったり、あるいは "is equal to"、"matches a regex"、"include" などの演算子による単純なJSONパターンマッチングルールにすることも可能です。図2はリクエストを受け付けた際のAuthorinoの認証認可のパイプラインを示しています。 図2: Authorinoによるリクエストの認証認可のステップ AuthorinoがユーザーのID検証に成功し、すべてのポリシーでユーザーのアクセスが許可された場合、Envoyはトラフィックを要求通りに保護されたAPIにリダイレクトします。そうでない場合は、要求された API に到達することはなく、適切な HTTP ステータス コードがユーザーに返されます。APIをリダイレクトする前に、AuthorinoはオプションでカスタムのHTTPヘッダーや Envoy Dynamic Metadata をインジェクトしたり、 トークン正規化 および エッジ認証 の実装に使用できる署名付きOIDC準拠JWTであるFestival Wristbandトークンの発行を行うことも可能です。 ユースケース例 Authorinoは、APIを保護する機能をユースケースに応じて柔軟にパッケージングすることができるように設計されています。例えば、あるAPIに対してリクエストがあるとしましょう。異なる認証プロトコルで取得された異なるIDソースからのアクセストークンを受け入れて、すべてのケースをカバーするためにRegoで書かれた1つのOPAベースの認可ポリシーでアクセスを管理することを選択するかもしれません。あるいは他のプロジェクトにおいては、常に単一の信頼できるIDソースから発行されたアクセストークンを許可し、認可ポリシーを複数の単純なパターンマッチングルールに分割する方がいいかもしれません。Authorinoでは、このような様々なユースケースをすべて混在させたり組み合わせたりすることが可能です。 OIDC認証に基づいたAPI保護ポリシーで、さらにRBACとUBACのポリシールールを適用する場合、Authorinoの AuthConfig カスタムリソースの記述は以下のようになります。 apiVersion: apiVersion: authorino.kuadrant.io/v1beta1 kind: AuthConfig metadata: name: my-api-protection-1 spec: hosts: - my-api.io identity: - name: users oidc: issuer: http://my-trusted-idp.example.com authorization: - name: rbac when: - selector: auth.identity.roles operator: excl value: admin json: rules: - selector: auth.content.request.method operator: eq value: GET - name: ubac json: rules: - selector: auth.identity.email_verified operator: eq value: "true" この例では、ユーザーがOIDCサーバーで認証し、保護されたAPIへのリクエストで取得したJWTを提示します。Authorinoは、OIDCの設定とJKWSを検索し、JWTを検証して2つの認可ポリシーを適用します。最初の認可ポリシーは、 admin ロールではないユーザーはAPIに対して GET HTTPリクエストしか送信することができず、2つ目の認可ポリシーは、検証されていない電子メールアドレスを持つユーザーからのリクエストを禁止しています。 もう1つの例は、API対するリクエストを行ったのが、Kubernetesサーバーのクライアントとして認証されたユーザーの場合なのか、APIキー（各APIキーはKubernetes Secret リソースとして保存されています）により認証されたユーザーの場合なのか、2つのパターンが考えられるAPIのケースです。認可の部分については、Regoで書かれた1つのポリシーで、Kubernetesで認証されたユーザーはAPIにフルアクセスできるのに対し、APIキーで認証されたユーザーはUTCの午前8時前にのみAPIにアクセスできるとしています。 apiVersion: apiVersion: authorino.kuadrant.io/v1beta1 kind: AuthConfig metadata: name: my-api-protection-2 spec: hosts: - my-other-api.io identity: - name: k8s-users kubernetes: {} - name: api-key-users apiKey: labelSelectors: audience: api-user credentials: in: custom_header keySelector: X-APIKEY authorization: - name: my-policy opa: inlineRego: | k8s_user { input.auth.identity.iss == "kubernetes.default.svc" } api_key_user { input.auth.identity.kind == "Secret" } before_8am { beginning_of_day := floor(time.now_ns()/86400000000000)*86400 (input.context.request.time.seconds - beginning_of_day) < (8*3600) } allow { k8s_user } allow { api_key_user; before_8am } Authorinoについてもっと詳しく知るには もし、この記事に興味を持っていただき、Authorinoについてもっと知りたいと思われたなら、GitHubの Authorinoリポジトリ をチェックしてみてください。様々なのユースケースに基づいた多くの ユーザーガイドとチュートリアル 、 アーキテクチャ とAuthorinoの動作に関する詳細な情報、ドキュメント化された 全機能のリスト などの資料があります。 Authorinoは現在ベータ版であり、公式リリースはまもなく開始される予定です。Red Hatのいくつかのチームは、Authorinoの機能に関するユースケースを調査してきており、ソリューションの設計をしています。このプロジェクトに参加し貢献するのはとても刺激になることでしょう。 ぜひSlackのオープンチャンネルに参加してみてください: kuadrant.slack.com

みなさん、こんにちは！ Red HatでOpenShiftのソリューションアーキテクトをしている小野です。 エッジコンピューティングのプラットフォームをオープンソースベースで検討する場合、単一のソフトウェアで全てをカバーする事は難しく、多くのソフトウェアを組み合わせて技術スタックを組み上げる必要があります。パズルの様に複数の組み合わせのパターンを一つずつ検証するとなると非常にハードルが高いかと思います。 そこで今回は、エッジコンピューティングのユースケース毎にRed Hatにて検証済みのアーキテクチャパターンをまとめた「Red Hat Edge validated patterns」についてご紹介します。   Red Hat Edge validated patternsとは Red Hat Edge validated patternsは、エッジコンピューティングのユースケース毎にRed Hatにて検証済みのパターンを公開したものです。エッジコンピューティングのプラットフォームの検討の促進、早期のPoCに繋げる事を目的に、GitHubにサンプルが公開されています。 各パターンは、基本的にRed Hatの製品とエコシステムをベースにデザインされています。多くのソフトウェアを利用していて難しさを感じることもあるかもしれませんが、「こんなユースケース実現できないかな」と思った時のリファレンスとしても活用できるかと思います。 www.redhat.com 公開されている内容（2022.3.30時点） 各パターンの詳細は以下の「Hybrid Cloud Patterns」というページに記載されています。 hybrid-cloud-patterns.io   現状は大きく、 Multicloud GitOps 、 Industrial Edge(産業用エッジ) 、 Medical Diagnosis(医療診断) の3つのパターンが公開されています。   Multicloud GitOpsは、ArgoCDベースの OpenShift GitOps と Advanced Cluster Management for Kubernetes を用いてGitを神様として複数のクラウドへ展開されたOpenShiftクラスタへアプリケーションをデプロイするユースケースです。Red Hatのポートフォリオアーキテクチャチームによって作成されました。     github.com   参考記事:  rheb.hatenablog.com   Industrial Edgeは、 ドイツのRed Hatのミドルウェアソリューションアーキテクトによって作られたデモがベースになっています。同じアーキテクチャで 他のユースケースにも簡単に拡張できます。 工場内のラインサーバのデータを収集し、異常検出AIを実行しつつ、クラウドで学習しモデル改善を図るアーキテクチャで実装されており、工場内には Red Hat AMQ とAIアプリケーションが、中央のデータセンターへは Open Data Hub によるML環境がそれぞれデプロイされます。     github.com   Medical Diagnosisは、 胸部X線写真を自動で分析するデータパイプラインのデモです。 Cephなどのオブジェクトストアに 写真をアップロードすると、オブジェクトストアがkafkaトピックを通知、KnativeにてトリガーしAIを実行します。 Grafanaダッシュボードにはパイプラインがリアルタイムで表示され、受信、処理、匿名化画像、メトリクス情報が表示されます。     github.com   参考記事:  rheb.hatenablog.com   導入方法 各パターン共通して、OpenShift GitOpsを用いてデプロイされます。 OpenShiftのOperatorHubにある Validated Patterns Operator を用いると簡単に試すことができますので、Operatorを利用した手順を以下にまとめます。   1. GitHubのアカウントを作成し、試したいパターンのGitリポジトリをFork (*) ここではIndustrial Edgeパターンを例として示します。 (*) OpenDataHubはOpenShift v4.9以降だとうまく動かないため、v4.8でお試し下さい。     2. OpenShiftコンソールのOperatorHubにて 「 Validated Patterns Operator」を検索   3.  Validated Patterns Operatorをインストール   4. Patternの[インスタンスの作成]を押下     5. Patternの作成画面にて以下の項目を入力し[作成]ボタンを押下   名前 → 任意の名前を入力 Cluster Group Name → 任意の名前を入力 Target Repo → ForkしたGitHubリポジトリのURLを入力 GitHubの[Code]ボタンを押して表示されるURL (例) https://github.com/ [アカウント名]/industrial-edge.git Target Revision → mainを入力     デモアプリのドメインを確認します。 $  oc get route -n manuela-stormshift-line-dashboard -o jsonpath='{.items[*].spec.host}{"\n"}' line-dashboard-manuela-stormshift-line-dashboard.hogehoge https:// line-dashboard-manuela-stormshift-line-dashboard.hogehoge へブラウザでアクセスし、以下の画面が表示されたら成功です。 何分か経つとラインサーバーのシミュレータから異常値が出力され、異常検出AIにて検知し、異常があった旨のアラートが出力されます。     まとめ 今回は、Red Hatが公開するエッジコンピューティングの検証済みパターン「Red Hat Edge validated patterns」を紹介しました。オープンソースを活用したエッジコンピューティングの実装の検討に参考になると思いますので、ぜひお試しください！

こんにちは、ソリューションアーキテクトの蒸野（ムシノ）です。 今回は 「Red Hat 3scale API Management」について取り上げてみたいと思います。 今更APIの重要性を説明する必要はないかと思いますので、こちらの「API管理と3scaleの基礎知識」をご覧いただけたらと思います。 thinkit.co.jp API Managementの特徴と言えばAPIの管理が容易になるということですが、このAPIの管理が容易になるというのは具体的にはどういうことかまずは整理したいと思います。 一般的にAPIを公開した後、API管理者が行わなければならない課題は多岐に渡ります。APIを作成した時点では始まりに過ぎず、例えば下記の図のような課題があります。 3scale の特徴はAPI利用者からAPI提供者までこのようなAPI管理に関わる課題を包括的に解決してくれる点にあります。 API提供者は、API登録やセキュリティの設定、API利用状況管理を行い、API利用者はデベロッパーポータルなどからAPI仕様を確認し、アプリケーションの開発を行って行きます。 また、 3scale は大きく「API Manager」と「API Gateway」という２つのコンポーネントに分かれています。「API Gateway」はnginxをベースとした非常に軽量なゲートウェイとして動作するというのが特徴になっています。「API Gateway」と「API Manager」は非同期で通信をすることで高い可用性を実現しており、API呼び出し時に遅延が少なく、パフォーマンスとスケーラビリティに優れているという点も 3scale の差別化要素になっています。 3scaleの機能としては次のようなものが挙げられます。 Red HatではAPI管理を簡単に始めることができる SaaS版 3scale を提供しています。 本記事ではこのSaaS版環境を使って 3scaleの機能を具体的に紹介していきたいと思います。 まずは、下記にアクセスして下さい。 https://www.3scale.net この環境ではトライアル環境として3scaleをご利用いただけます。「Sign up」していただくことで90日間のトライアルアカウントの申請することができ、無償でお試し頂くことができます。 もちろんいつでもアップグレード可能です。 SaaS版 3scale への Sign up まずは必要事項を記載していただきます。「お名前」「メールアドレス」や「ご利用目的」にあわせてご質問事項にお答えいただければと思います。また、赤枠で示した部分はSaaS版 3scale内でユニークである必要があります。プロジェクト名や会社名などを組み合わせ、分かりやすい名称を付けることをお勧めいたします。 確認メールからアクティベーションする 「Sign up」 すると次のようなメールが届きますので、URLをクリックして「Activation」します。 アクティベーション後のアクセス アクティベーション後は次にような画面になります。 ここからは初期設定を進めていきます。基本的にデフォルト設定のまま、ボタンをクリックしていきます。 1.How does 3scale work? 2.Add your API 3.Design a Product 4.Use your Backend in your Product 5.make a test GET request 6.you are running in 3scale 7.What's next? 3scale 管理ポータル画面 ここからは一通り管理ポータル画面の紹介を行います。 管理ポータル画面：ダッシュボード 上部にあるメニューから「Dashboard」を選択します。「APIs」>「Products」 からAPI設定を確認します。 「Products」のメニューから「Overview」を選択します。 管理ポータル画面：API設定（Integration） 上部メニューが「Products」になっていることを確認します。左のメニューから「Integration」>「Configuration」をクリックします。 ここではAPIゲートウェイの設定やエンドポイントの設定を行います。 管理ポータル画面：API設定（Application plans） 上部メニューが「Products」になっていることを確認します。左のメニューから「Application」>「Application plans」をクリックします。 ここではアプリケーションプランの設定を行います。 アプリケーションプランは、APIを使用するためのルール（ベーシック、プレミアムのような、制限事項、価格など）を設定します。 管理ポータル画面：分析 上部メニューが「Products」になっていることを確認します。左のメニューから「Analytics」>「Traffic」をクリックします。 APIの利用状況に関する利用状況を表示します。一通り、いろんな観点からの利用状況を確認することができます。 標準では時間表示が「UTC」になっていると思いますので、 上部メニューから「Account Settings」>「Account Details」からEdit>から「Time Zone」を変更することができます。 管理ポータル画面：デベロッパー管理 上部メニューが「Audience」になっていることを確認します。左のメニューから「Accounts」>「Listing」をクリックします。 API利用者になるデベロッパーに関する情報を表示します。対象デベロッパーを選択すればデベロッパー詳細が表示されます。 管理ポータル画面：アプリケーション管理 上部メニューが「Audience」になっていることを確認します。左のメニューから「Applications」>「Listing」をクリックします。 デベロッパーが作成したアプリケーションを確認することができます。 管理ポータル画面：デベロッパーポータルの管理 上部メニューが「Audience」になっていることを確認します。左のメニューから「Developer Portal」>「Visit Portal」をクリックします。 別ブラウザでデベロッパーポータル画面を見ることができます。 「デベロッパーポータル」ではこのような画面が表示されます。 サンプルデータからの変更 それではセットアップ時のサンプルデータから変更してみて、操作方法の理解を深めていきましょう。 今回は下記の内容を実施してみたいと思います。 1. APIの設定：API Backend変更とMethodの定義 2. APIの設定：Integrationの設定 1. APIの設定：Backend変更とMethodの定義 1.1. API Backend を更新します 「Dashboard」>「Backends」>「Edit」にアクセスします。 下記にようにサンプルデータを変えてみます。入力後「Update Backend」をクリックします。 ・Description： Backend of API Test ここではサンプルから「Description」のみを変更していますが、お試ししたいAPIがあれば「Private Base URL」や「Name」なども変更することができます。 1.2. Method を作成します。 次に、左のメニューから「API Backends」>「Methods and Metrics」>「Add method」から Method を作成します。 1．Articles 下記にように入力し、「Create Method」をクリックします。 Friendly Name： Get Articles System Name： get_articles 2．Categories 下記にように入力し、「Create Method」をクリックします。 Friendly Name： Get Categories System Name： get_categories 3．Brand 下記にように入力し、「Create Method」をクリックします。 Friendly Name： Get Brand System Name： get_brand 1.3. Mapping Method を作成します。 次も左のメニューから「API Backends」>「Mapping Rules」>「Create Mapping Rules」から Rule を作成します。 1．Articles 下記にように入力し、「Create Mapping Rule」をクリックします。 Pattern： /articles Method： Get Articles 2．Categories 下記にように入力し、「Create Mapping Rule」をクリックします。 Pattern： /categories Method： Get Categories 3．Brand 下記にように入力し、「Create Mapping Rule」をクリックします。 Pattern： /brands/{id} Method： Get Brand 最終的にはこのようなリストになります。 2. APIの設定：Integrationの設定 2.1. Integration を更新します 「Dashboard」>「Products」>「Integration」からBackendの変更内容を有効にすることができます。 その前に、URLパターンで “/”を残しておくとAPIのコール数が重複してカウントされるので左メニューの「Integration」>「Mapping Rules」から“/”を削除します。 同画面にアクセス後、ゴミ箱アイコンから“/”を削除しておきます。 次に左メニューの「Integration」>「Configuration」をクリックします。 三角の注意マークが表示され、「Staging APIcast」と「Production APIcast」共にプロモーションできる状態になっているかと思います。 マッピングルールも確認し、先程設定した「Articles 」「Categories」「Brand」が反映されていることも確認しておきましょう。 ステージングとプロダクション環境にデプロイします。それぞれプロモーションをクリックしデプロイを実行します。 無事デプロイされ、それぞれバージョン番号が変更（もしくは付与）されたことが分かります。 2.2. APIの疎通確認 それでは設定したIntegrationの「Staging APIcast」と「Production APIcast」のレスポンスを試してみます。 「Staging APIcast」にある「Example curl for testing」のcurlコマンドをそのまま実行してみることもできますし、下記のようにプロダクト環境に変更しリクエストすることもできます。下記の例ではマスクしていますがご自身の払い出された 3scale 環境に合わせて実行してみてください。ちなみに、「user_key」は「Staging APIcastにあるExample curl for testing」を参考にします。 curl "https://api-xxxxxxxxxxxx.production.gw.apicast.io:443/articles?user_key=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" { "method": "GET", "path": "/articles", "args": "user_key=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", "body": "", "headers": { "HTTP_VERSION": "HTTP/1.1", "HTTP_HOST": "echo-api.3scale.net", "HTTP_X_REAL_IP": "127.0.0.1", "HTTP_X_3SCALE_PROXY_SECRET_TOKEN": "Shared_secret_sent_from_proxy_to_API_backend_xxxxxxxxxxxxxxxxxxxxxx", "HTTP_USER_AGENT": "curl/7.79.1", "HTTP_ACCEPT": "*/*", "HTTP_X_FORWARDED_FOR": "省略します", "HTTP_X_FORWARDED_PROTO": "https", "HTTP_X_ENVOY_EXTERNAL_ADDRESS": "省略します", "HTTP_X_REQUEST_ID": "省略します", "HTTP_X_ENVOY_EXPECTED_RQ_TIMEOUT_MS": "15000" }, "uuid": "287d9f81-ee13-4d77-a6a7-2d67a500de6c" } curl "https://api-xxxxxxxxxxxx.production.gw.apicast.io:443/categories?user_key=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" { "method": "GET", "path": "/categories", "args": "user_key=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", "body": "", "headers": { "HTTP_VERSION": "HTTP/1.1", "HTTP_HOST": "echo-api.3scale.net", "HTTP_X_REAL_IP": "127.0.0.1", "HTTP_X_3SCALE_PROXY_SECRET_TOKEN": "Shared_secret_sent_from_proxy_to_API_backend_xxxxxxxxxxxxxxxxxxxxxx", "HTTP_USER_AGENT": "curl/7.79.1", "HTTP_ACCEPT": "*/*", "HTTP_X_FORWARDED_FOR": "省略します", "HTTP_X_FORWARDED_PROTO": "https", "HTTP_X_ENVOY_EXTERNAL_ADDRESS": "省略します", "HTTP_X_REQUEST_ID": "省略します", "HTTP_X_ENVOY_EXPECTED_RQ_TIMEOUT_MS": "15000" }, "uuid": "5b4e0dab-48e5-4fe4-a1ec-556ccd2afa91" } curl "https://api-xxxxxxxxxxxx.production.gw.apicast.io:443/brands/1?user_key=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" { "method": "GET", "path": "/brands/1", "args": "user_key=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", "body": "", "headers": { "HTTP_VERSION": "HTTP/1.1", "HTTP_HOST": "echo-api.3scale.net", "HTTP_X_REAL_IP": "127.0.0.1", "HTTP_X_3SCALE_PROXY_SECRET_TOKEN": "Shared_secret_sent_from_proxy_to_API_backend_xxxxxxxxxxxxxxxxxxxxxx", "HTTP_USER_AGENT": "curl/7.79.1", "HTTP_ACCEPT": "*/*", "HTTP_X_FORWARDED_FOR": "省略します", "HTTP_X_FORWARDED_PROTO": "https", "HTTP_X_ENVOY_EXTERNAL_ADDRESS": "省略します", "HTTP_X_REQUEST_ID": "省略します", "HTTP_X_ENVOY_EXPECTED_RQ_TIMEOUT_MS": "15000" }, "uuid": "adc0877e-0303-4023-a784-4fca5e2e9a2f" } 最後に いかがでしたでしょうか？ SaaS版 3scale を使った環境で、直ぐにでもAPI管理を始めることができることご理解頂けたのではないでしょうか？ また、Red Hat では、本記事の内容を含んだAPI管理の基本的な操作を理解いただける無償ハンズオントレーニングを実施しています。 興味を持っていただけましたら、是非とも担当営業にお声がけいただけたらと思います。 参考情報として以下、掲載させていただきます。 * API管理と3scaleの基礎知識 | Think IT（シンクイット） * Red Hat 3scale API Management * Red Hat OpenShift API Management * SaaS 版 Red Hat 3scale API Management リリースノート - Red Hat Customer Portal * スタートガイド Red Hat 3Scale 2-saas | Red Hat Customer Portal 補足： 「2021 Gartner Magic Quadrant for Full Lifecycle API Management」について補足させていただきます。 最近お問い合わせが多い内容につき、少しご注意事項として記載させていただきます。「2021 Gartner Magic Quadrant for Full Lifecycle API Management」ではRed Hatが Niche Players として位置づけられています。しかし、Red Hat では「Red Hat 3scale API Management」や「Red Hat OpenShift API Management」にこれまでと変わらず積極的な投資を行っており、2021年も多くのお客様に支持をいただいております。またForresterは「API Management Solutions, 2020」において Red Hat「Contender」から「Strong Performer」に引き上げたことを発表しました。また、KuppingerColeは2021年8月にRed Hatをリーダーとして認定しました。Red HatとしてはアプリケーションのAPI連携はもちろんのこと、データストリーミング、メッセージングなどのクラウドネイティブアプリケーションプラットフォームの一部としてのAPI Managementを求めることが多くなっているため、クラウドネイティブアプリケーションのための優れたAPI基盤を提供しています。「2021 Gartner Magic Quadrant for Full Lifecycle API Management」においては Red Hat が提供するクラウドネイティブアプリケーションのためAPI基盤の全て表したものではないことにご注意頂けたらと思います。

こんにちは、Red Hatでソリューションアーキテクトをしている石川です。 前回の記事ではOpenShift Pipelines（Tekton）の中でskopeoを動かし、CIパイプラインでビルドしたイメージを別クラスタのコンテナレジストリにコピーしました。 この際、あて先となるクラスタではコンテナレジストリに接続するためのrouteを公開し、それを通じてCI実行側のクラスタからイメージをコピーしました。 rheb.hatenablog.com 今回の記事ではSkupperを使うことであて先クラスタ側でrouteを公開することなくイメージのコピーを実施したいと思います。 そもそもSkupperとは？について知りたい方は赤帽ブログのこちらの記事を参照下さい。 rheb.hatenablog.com TL;DR ・Skupperを使うと異なるクラスタのNamespace間で動いているサービスを簡単に繋ぐことができます ・OpenShiftではSkupper Operatorがあるので導入しやすいです ・今回はCIパイプラインのユースケースでSkupperを使ってみました 作りたい構成 今回も前回と同様にCIパイプラインを実行し、コンテナのビルドやイメージのコピーを行うクラスタとしてROSAクラスタを構築します。（上図左） そしてイメージのコピー先としてAWS上にIPIでOCPクラスタを構築します。（上図右） 今回はこの２つのクラスタの特定のNamespace間でSkupperによるAMQP Linkを結び、こちらを介してコンテナイメージのコピーを実施したいと思います。 クラスタ間でのLink作成 Skupperを使いクラスタ間でLinkを作成するステップとしては以下となります。 ・各クラスタにSkupper Operatorをインストール ・Linkを結びたいNamespaceにてSkupperを初期化 ・Tokenを生成しLinkを作成 Skupper Operatorのインストール まずそれぞれのクラスタでSkupper Operatorをインストールします。 OpenShiftコンソールからOperatorHubを開き、Skupperを検索してインストールしましょう。 デフォルトの設定だとクラスタ全体でSkupper Operatorを利用可能ですが、特定のNamespaceのみを対象としてインストールすることも可能です。 今回はデフォルト設定のままインストールを行います。 Skupperの初期化 Skupper Operatorをインストールできたら続いて各NamespaceでSkupperの初期化を行います。 ここからは skupper CLIを使用していきます。 Skupperのサイト に記載されている通り以下のコマンドで skupper コマンドを導入することができます。 # For Linux or Mac curl https://skupper.io/install.sh | sh 導入された skupper コマンドを実行すると以下が表示されます。 skupper --- Usage: skupper [command] Available Commands: completion Output shell completion code for bash debug Debug skupper installation delete Delete skupper installation expose Expose a set of pods through a Skupper address gateway Manage skupper gateway definitions help Help about any command init Initialise skupper installation link Manage skupper links definitions revoke-access Revoke all previously granted access to the site. service Manage skupper service definitions status Report the status of the current Skupper site token Manage skupper tokens unexpose Unexpose a set of pods previously exposed through a Skupper address update Update skupper installation version version Report the version of the Skupper CLI and services Flags: -c, --context string The kubeconfig context to use -h, --help help for skupper --kubeconfig string Path to the kubeconfig file to use -n, --namespace string The Kubernetes namespace to use Use "skupper [command] --help" for more information about a command. skupper コマンドが導入できたら各Namespace上で skupper init を実行します。 各クラスタにログインし、Linkを作成したいNamespaceへ変更しておきましょう。 ## 以下をそれぞれのクラスタに対し実施 # ログイン oc login https://api.xxxxxxx.xxxx.openshiftapps.com:6443 --username $USER --password $PASSWORD # Namespace変更 oc project source # skupper初期化 skupper init --- Skupper is now installed in namespace 'source'. Use 'skupper status' to get more information. ここで１つ気を付けるポイントとして、あて先クラスタのNamespaceは openshift-image-registry を指定します。 最終的なコンテナイメージのコピー先は destination Namespaceとなりますが、Link作成はコンテナレジストリのPod等が動いているこちらのNamespaceで実施する必要があります。 Tokenの生成とLink作成 続いてTokenを作成し、そのTokenを使いLinkを作成していきます。 今回はCI実行側のクラスタでTokenを生成し、それをあて先クラスタ側で適用します。 # Tokenの生成（CI実行側のクラスタで実施） skupper token create $HOME/secret.yaml # Tokenの適用（あて先クラスタで実施） skupper link create $HOME/secret.yaml それぞれのコマンドを実行する際にクラスタを切り替えるため適宜 oc login コマンドを実施しましょう。 正しくLinkが作成できると以下のコマンドで状況を確認できます。 skupper link status --- Link link1 is active 無事アクティブなLinkが作成されました。 せっかくなのでSkupperのコンソールでも状況を確認したいと思います。 コンソールのURLについては skupper status コマンドで確認できます。 # URLの確認 skupper status --- Skupper is enabled for namespace "source" in interior mode. It is connected to 1 other site. It has no exposed services. The site console url is: https://skupper-source.apps.xxxxxxx.xxxx.openshiftapps.com The credentials for internal console-auth mode are held in secret: 'skupper-console-users' # 認証情報の確認 oc get secret skupper-console-users -o json | jq .data.admin -r | base64 -d ブラウザから表示されたURLにアクセスし認証を行うとSkupperコンソールが表示されます。 画面左の"Network"から2つのクラスタのNamespace間でLinkが張られていることが確認できます。 Serviceのexpose Linkが作成できたら、あて先クラスタの openshift-image-registry Namespaceにある image-registry Serviceをexposeすることで、CI実行側のクラスタからあて先クラスタのコンテナレジストリに対しアクセス可能とします。 あて先クラスタにログインし以下のコマンドを実行します。 # レジストリの公開 skupper expose service image-registry --address dest-registry あらためてSkupperのコンソールを見てみましょう。 画面左の"Site"を選択するとexposed serviceとしてServiceが公開されているのが確認できました。 またCI実行側クラスタのコンソールを見ると、確かに dest-registry という名前でServiceが作成されているのがわかります。 これでCI実行側のNamespaceからあて先クラスタのコンテナレジストリに対しアクセス可能な状態となりました。 CIパイプラインの実行 レジストリにアクセス可能な状態を作ることができたため、CIパイプラインを実行していきます。 TektonのPipelineについては前回の記事と同じものを利用します。 skopeo-pipeline.yaml (クリックで展開) apiVersion: tekton.dev/v1beta1 kind: Pipeline metadata: name: skopeo-pipeline spec: workspaces: - name: shared-workspace - name: tmp-vol params: - name: git-url type: string - name: git-revision type: string - name: target-path type: string - name: dest-imageurl type: string tasks: - name: git-clone-health taskRef: name: git-clone kind: ClusterTask params: - name: url value: $(params.git-url) - name: revision value: $(params.git-revision) workspaces: - name: output workspace: shared-workspace - name: build-container taskRef: name: s2i-nodejs kind: ClusterTask runAfter: - git-clone-health workspaces: - name: source workspace: shared-workspace params: - name: PATH_CONTEXT value: $(workspaces.source.path)/$(params.target-path) - name: IMAGE value: image-registry.openshift-image-registry.svc:5000/source/health-record:latest - name: copy-image taskRef: name: skopeo-copy kind: ClusterTask runAfter: - build-container workspaces: - name: images-url workspace: tmp-vol params: - name: srcImageURL value: 'docker://image-registry.openshift-image-registry.svc:5000/source/health-record' - name: destImageURL value: $(params.dest-imageurl) - name: srcTLSverify value: 'false' - name: destTLSverify value: 'false' CI実行側のクラスタに適用しておきましょう。 続いてレジストリへの認証情報とServiceAccountの紐付けです。 今回もあて先クラスタの destination Namespaceにおける builder から認証情報を取得します。 # 認証情報の取得 SECRET=$(oc -n destination get secret | grep builder-docker | awk {'print $1'}) oc -n destination get secret $SECRET -o jsonpath="{.data['\.dockercfg']}" | base64 --decode | jq '.["image-registry.openshift-image-registry.svc:5000"].password' こちらをpipeline-dockercfgから始まるSecretに追加していくのですが、今回はここであて先となるレジストリサーバーのアドレスにクラスタ内部の dest-registry Serviceのアドレスを指定します。 パスワードには取得した認証情報を登録します。 これでCIパイプラインによりイメージをコピーする準備が整いました。 前回と同様にTektonのPipelineRunを作成し、実行してみましょう。 skopeo-pipelinerun.yaml (クリックで展開) apiVersion: tekton.dev/v1beta1 kind: PipelineRun metadata: generateName: skopeo-pipeline-run- spec: pipelineRef: name: skopeo-pipeline params: - name: target-path value: 'site' - name: git-url value: 'https://gitlab.com/jpishikawa/starter-kit-cicd-app' - name: git-revision value: 'main' - name: dest-imageurl value: 'docker://dest-registry.source.svc:5000/destination/starter-kit-cicd-app' workspaces: - name: shared-workspace volumeClaimTemplate: spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi - name: tmp-vol emptyDir: {} .spec.params.dest-imageurl の中であて先のレジストリのアドレスを記載していますが、今回はこちらを dest-registry Serviceのアドレスに書き換えています。 PipelineRunを適用してしばらく待つとPipeline実行が成功し、無事にskopeoによるイメージのコピーまで完了したことを確認できます。 またあて先クラスタのコンソールからイメージストリームを確認すると無事にイメージが保管されています。 Skupperを通じてイメージのコピーを実行することができました！ まとめ 前回の方法ではコンテナレジストリのrouteを外部公開していましたが、今回はSkupperを使うことでコンテナレジストリへのアクセスを実現しました。 今回はCIパイプラインと組み合わせてSkupperを使用してみましたが、Skupper自体には他にも色々な用途があると考えられます。記事の中でもご紹介した通り、OpenShiftにはSkupper Operatorもあり、比較的簡単に試すことができるため皆さんもぜひ触ってみて下さい。

この記事は Building Red Hat Enterprise Linux 9 for the x86-64-v2 microarchitecture level | Red Hat Developer の翻訳です。 Red Hat Enterprise Linux 9 はこの記事で紹介されている x86-64-v2 アーキテクチャむけにビルドされています。 Linuxディストリビューションを構築する際、初期に決定する最も重要なことの1つが、サポートするハードウェアの範囲です。ディストリビューションのデフォルトのコンパイラ・フラグは、ハードウェア・プラットフォームの互換性にとって重要です。新しいCPU命令を使用するプログラムは、古いCPUでは動作しないかもしれません。この記事では、Red Hat Enterprise Linux (RHEL) 9のx86-64バージョンをビルドするための新しいアプローチについて説明し、そのビルドに関するRed Hatの推奨事項を共有します。 x86-64マイクロアーキテクチャレベルの背景 GNU Cライブラリ(glibc)は、すべてのシステムに存在するとは限らない追加のハードウェア機能を使用する最適化されたライブラリをロードする方法を提供しています。元々、このメカニズムは、通常 /usr/lib64 ディレクトリにインストールされるデフォルト(フォールバック)実装に加え、おそらく1つか2つの代替ライブラリ実装をサポートするように設計されています。しかし、ライブラリ検索機構によるパワーセット構築は、 CPUのオプション機能が数多く存在する現在のプラットフォームにはうまくマッチしません 。特にx86アーキテクチャでは、長年にわたって多くのオプション機能が追加されています (一覧は CPUID命令のWikipediaの記事 を参照してください)。このような選択肢の多さは、ダイナミックリンカーだけでなく、プログラマーにとっても問題です。最近まで、最適化されたライブラリでどのようなCPUの機能を想定すべきか、ほとんど指針がありませんでした。 GCCとglibcは機能セットの定義について意見が分かれており 、 glibcの選択機構はベンダーごとに異なっています 。 2020年夏、AMD、Intel、Red Hat、SUSEは共同で、x86-64ベースラインの上に3つのx86-64マイクロアーキテクチャのレベルを定義しました。3つのマイクロアーキテクチャは、ハードウェアのリリース日に基づいて、CPUの機能を大まかにまとめています。 x86-64-v2では、Streaming SIMD Extensions 4.2(SSE4.2)およびSupplemental Streaming SIMD Extensions 3 (SSSE3) までのベクトル命令、POPCNT命令 (データ解析や一部のデータ構造でのビット操作に有用)、CMPXCHG16B (並列アルゴリズムに有用な2ワードの比較およびスワップ命令) などがサポートされています。 x86-64-v3は、AVX2までのベクトル命令、MOVBE(ビッグエンディアン・データ・アクセス用)、および追加のビット操作命令を追加しました。 x86-64-v4では、AVX-512の一部のバリエーションからベクタ命令が追加されました。 x86-64のpsABIの補足 で、3つのレベルの詳細を文書化しました。今後リリースされるGCCバージョン11とLLVMバージョン12では、 -march= 引数でこれらをサポートする予定です。 (パワーセット構築ではない)新しいメカニズムで glibc ダイナミックローダを拡張するパッチが glibc-hwcaps の名前で glibc に組み込まれました。これらの変更は glibc の次期2.33リリースの一部となる予定です。 RHEL 9のアーキテクチャに関する考慮点 これまで、x86_64 Red Hat Enterprise Linuxのユーザースペースは、AMD K8ベースラインからAMD固有の3Dnow! を除いたものでした。この決定は、最新バージョンの Red Hat Enterprise Linux 8 まで維持されています。しかし、カーネルドライバが削除されたため、古いハードウェア (第一世代のOpteron CPUを搭載したシステムなど) ではRed Hat Enterprise Linuxを有用な形で実行できません。また、古いハードウェアを実行する場合、大きな電力を必要とします。 今までにも、 IFUNC 、 関数のマルチバージョン化 、 dlopen による代替実装のロードなどのメカニズムによって、新しいCPU機能を利用できましたが、これは現在進行中の glibc-hwcaps 作業で自動化できる可能性があります。これらのアプローチはそれぞれ、特に指定されたコードのブロックにのみ適用されます。ディストリビューションの残りの部分はまだ追加のCPU機能を採用していないため、CPUのこれらの部分は本質的に休止状態になっています。 x86-64マイクロアーキテクチャレベルを定義することの歓迎すべき副次的効果として、Linuxディストリビューションのアーキテクチャのベースラインを議論するための便利な言語を手に入れました。このままオリジナルのK8ベースラインを使うことも、後の3つのレベルのうち1つを適用することもできます。 RHEL 9での推奨 Red Hat Enterprise Linux 9では、x86-64-v2が適切な選択であると考えます。 この推奨は、以下の見解に基づいています。 ホストがサポートしているにもかかわらず、x86-64-v2 CPU機能を人為的にマスクする仮想マシンモデルは、比較的簡単に調整できます。 次のレベルであるx86-64-v3は、x86-64アーキテクチャ用に1つの統一ディストリビューションを構築する予定であるため、使用できない。 2020年発売の新サーバークラスCPU は、AVX命令セットを実装していません。 AVX命令も一部のソフトウェア実装では利用できません( valgrind ツールはサポートしていますが)。エミュレーションのサポートがないため、Red Hat Enterprise Linux 9をターゲットとする開発者が制約を受ける可能性があります。 以前のRed Hat Enterprise Linuxバージョンと同様に、IFUNCと関数のマルチバージョン化によって (x86-64-v2以外の) 他のCPU機能を引き続きサポートする予定です。また、最適化されたバージョンのライブラリをロードするためにglibc-hwcapsメカニズムを使用する可能性もあります。通常通り、これらの計画はRed Hat Enterprise Linux 9のリリース前に随時変更される可能性があります。 現在のところ、 Fedora ELN 以外のFedoraにはこの変更は適用されません。(訳注: 記事執筆時点である2021年1月の状況です。) 他のアーキテクチャのサポート ハードウェアパートナーとともに、Red Hatはすべてのアーキテクチャのベースラインを定期的に見直しています。IBM POWERとIBM Zについては、歴史的にメジャーリリースごとにベースラインを更新してきました。例えば、Red Hat Enterprise Linux 8にはPOWERリトルエンディアン (ppc64le) と、s390xアーキテクチャではz13以降のCPUが必要です。 まとめ この記事では、Red Hat Enterprise Linux 9のx86-64マイクロアーキテクチャレベルを選択するRed Hatのアプローチを導く基準について説明しました。 推奨するx86-64-v2は、追加のベクトル命令 (SSE4.2およびSSSE 3まで)、データ分析用のPOPCNT命令、並列処理アルゴリズム用のCMPXCHG16B命令をサポートします。 最終更新日2021年1月29日

  本日の記事はOpenShiftで仮想マシンを扱うことが出来るOpenShift VirtualizationをAWS上にデプロイし、AWSのベアメタルインスタンスで仮想マシンを扱ってみたいと思います。 アップストリームプロジェクトはKubeVirtになっています。本記事の内容は本記事執筆時にはTechnical Previewのサポート状況であり本番で利用することはできません。 軽快に検証できる点を重視して記事を提供致します。 OpenShift Virtualizationのデプロイしてテストインスタンスを立ち上げる プラットフォームはAWSを使用 OpenShiftインストールメソッドはIPI ストレージにはOpenShift Data Foundationを使用 ２つMachineSetを作成しODF、OCP-V用ノードを追加 何らかのOpenShiftのサブスクリプションを所有されていることが前提 マイグレーションなど機能のテストは次回 TOC はじめに OpenShiftをAWS IPIでインストール アカウント設定 アカウント確認 OpenShift CLIダウンロード インストールコンフィグの作成 デプロイ実行 デプロイ完了を確認 MachineSet作成してODFノード(ストレージ用)、Baremetalノード(OCP Virtualization用親ノード)追加 Operatorインストール （ODF） Storage System CR作成 デフォルト ストレージクラスの変更 HCO CR作成 仮想インスタンスの立ち上げ 次回 はじめに コンテナプラットフォームの上で仮想マシンを動かす。そんな謎ソリューションが気になってくしゃみが止まらなくなった日はありませんか？私は年々ひどくなる花粉症に理由を付けて現実逃避をする日々が続いております。 クラウドインフラ全般を担当しているソリューションアーキテクトの伊藤です。   こちらのKBでOpenShift VirtualizationをAWS上にデプロイするナレッジが公開されています。 access.redhat.com 最近リリースされたOpenShift 4.10にアドオンできるOpenShift Virtualization 4.10のリリースノートに、「OpenShift VirtualizationのワーカーノードにAWSのBaremetalノードを使用することについてはTechPreviewです」と明記されるようになりました。実は以前からデプロイは出来たのですが、今回ドキュメントに明記されたことから、本記事では実際に行ってみたいと思います。 ＃仮想マシンにはRWX属性を持った共有ストレージが必要であるため、OpenShift Data Foundationも同時にデプロイします。   今回デプロイするのはこの構成(最小構成、シングルAZ)  Masterノード (3nodes, m5.2xlarge)  標準のWorkerノード (2nodes, m6i.large)  ストレージ用のODF Workerノード (3nodes, m6i.4xlarge)  仮想マシンを動かすベアメタルWorkerノード (2nodes, m5.metal) １と２はopenshift-installerによって初期にデプロイされます。 ３と４は初期デプロイが完了したあと、machinesetを作成してノードを拡張します。 OpenShiftをAWS IPIでインストール access.redhat.com 基本は上記のクイックインストールの通りですが、費用削減とテストのためAZを1つに絞ります。 アカウント設定 AWS CLIが使えるIAMアカウントを作成してください。 アカウント確認 AWS CLIを叩いたときに意図したアカウントであるか確認してください。 OpenShift CLIダウンロード console.redhat.com 上記のURLからOpenShift installerとCommand line interfaceを両方最新をDLして展開します。 インストールコンフィグの作成 mkdir aws4103 #クラスタ毎にディレクトリを作ることをお勧めします。 openshift-isntall create install-config #以下のインタラクティブが行われます。 SSH公開鍵、プラットフォーム、リージョン、ベースドメイン、クラスタ名、pullsecretの６つを指定します。そして生成されたinstall-config.yamlファイルを以下のdiffの様に書き換えます。 [takitou@takuya-PC aws410]$ diff -uda install-config.yaml.org install-config.yaml --- install-config.yaml.org 2022-03-28 13:59:53.296185800 +0900 +++ install-config.yaml 2022-03-28 14:03:13.925747800 +0900 @@ -4,13 +4,20 @@ - architecture: amd64 hyperthreading: Enabled name: worker - platform: {} - replicas: 3 + platform: + aws: + zones: + - ap-northeast-1d + replicas: 2 controlPlane: architecture: amd64 hyperthreading: Enabled name: master - platform: {} + platform: + aws: + zones: + - ap-northeast-1d + type: m5.2xlarge replicas: 3 metadata: creationTimestamp: null [takitou@takuya-PC aws410]$   デプロイ実行 [takitou@takuya-PC aws410]$ openshift-install create cluster --dir . --log-level=debug 特に問題なければクラスタ作成コマンドを実行し、４０分弱でクラスタがデプロイされて管理者のログインパスワードが表示されます。 INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/home/takitou/aws410/auth/kubeconfig' INFO Access the OpenShift web-console here: https://console-openshift-console.apps.ocpv.sandbox1779.opentlc.com INFO Login to the console with user: "kubeadmin", and password: "1234-5678-9012-3456" デプロイ完了を確認 export KUBECONFIG=./auth/kubeconfig oc get co oc get machines -n openshift-machine-api Cluster Operatorが全てAvailable: Ture, Degraded: Falseになっていることを確認します。 MachineSet作成してODFノード(ストレージ用)、Baremetalノード(OCP Virtualization用親ノード)追加 マシンセットの作成は以下のドキュメントを参考にします。 access.redhat.com oc get machineset -n openshift-machine-api NAME DESIRED CURRENT READY AVAILABLE AGE ocpv-rskd2-worker-ap-northeast-1d 2 2 2 2 34m oc get machineset -n openshift-machine-api  ocpv-rskd2-worker-ap-northeast-1d -o yaml > ocpv-odf-apne-1d.yaml ODFノード用のMachineSetの定義は以下のdiffのように変更 [takitou@takuya-PC aws410]$ diff -uda ocpv-worker-apne-1d.yaml ocpv-odf-apne-1d.yaml --- ocpv-worker-apne-1d.yaml    2022-03-28 14:51:47.205147700 +0900 +++ ocpv-odf-apne-1d.yaml       2022-03-28 14:55:15.593765900 +0900 @@ -1,34 +1,35 @@  apiVersion: machine.openshift.io/v1beta1  kind: MachineSet  metadata: -  annotations: -    machine.openshift.io/GPU: "0" -    machine.openshift.io/memoryMb: "8192" -    machine.openshift.io/vCPU: "2" -  creationTimestamp: "2022-03-28T05:16:55Z" -  generation: 1    labels:      machine.openshift.io/cluster-api-cluster: ocpv-rskd2 -  name: ocpv-rskd2-worker-ap-northeast-1d +  name: ocpv-rskd2-odf-ap-northeast-1d    namespace: openshift-machine-api -  resourceVersion: "23688" -  uid: 8bbed1d2-3ce9-43bb-b412-a330fac4df2c  spec: -  replicas: 2 +  replicas: 3    selector:      matchLabels:        machine.openshift.io/cluster-api-cluster: ocpv-rskd2 -      machine.openshift.io/cluster-api-machineset: ocpv-rskd2-worker-ap-northeast-1d +      machine.openshift.io/cluster-api-machineset: ocpv-rskd2-odf-ap-northeast-1d    template:      metadata:        labels:          machine.openshift.io/cluster-api-cluster: ocpv-rskd2          machine.openshift.io/cluster-api-machine-role: worker          machine.openshift.io/cluster-api-machine-type: worker -        machine.openshift.io/cluster-api-machineset: ocpv-rskd2-worker-ap-northeast-1d +        machine.openshift.io/cluster-api-machineset: ocpv-rskd2-odf-ap-northeast-1d      spec:        lifecycleHooks: {} -      metadata: {} +      taints: +      - effect: NoSchedule +        key: node.ocs.openshift.io/storage +        value: "true" +      metadata: +        creationTimestamp: null +        labels: +          node-role.kubernetes.io/worker: "" +          node-role.kubernetes.io/infra: "" +          cluster.ocs.openshift.io/openshift-storage: ""        providerSpec:          value:            ami: @@ -47,7 +48,7 @@            deviceIndex: 0            iamInstanceProfile:              id: ocpv-rskd2-worker-profile -          instanceType: m6i.large +          instanceType: m6i.4xlarge            kind: AWSMachineProviderConfig            metadata:              creationTimestamp: null @@ -69,9 +70,3 @@              value: owned            userDataSecret:              name: worker-user-data -status: -  availableReplicas: 2 -  fullyLabeledReplicas: 2 -  observedGeneration: 1 -  readyReplicas: 2 -  replicas: 2 [takitou@takuya-PC aws410]$ 続いて、Baremetalノード用のMachineSetを作成します。 oc get machineset -n openshift-machine-api  mymetal-dqhvp-worker-ap-northeast-1d -o yaml > ocpv-metal-apne-1d.yaml Baremetalノード用のMachineSetの定義は以下のdiffのように変更 [takitou@takuya-PC aws410]$ diff -uda ocpv-worker-apne-1d.yaml ocpv-metal-apne-1d.yaml --- ocpv-worker-apne-1d.yaml    2022-03-28 14:51:47.205147700 +0900 +++ ocpv-metal-apne-1d.yaml     2022-03-28 14:56:54.514627400 +0900 @@ -1,34 +1,29 @@  apiVersion: machine.openshift.io/v1beta1  kind: MachineSet  metadata: -  annotations: -    machine.openshift.io/GPU: "0" -    machine.openshift.io/memoryMb: "8192" -    machine.openshift.io/vCPU: "2" -  creationTimestamp: "2022-03-28T05:16:55Z" -  generation: 1    labels:      machine.openshift.io/cluster-api-cluster: ocpv-rskd2 -  name: ocpv-rskd2-worker-ap-northeast-1d +  name: ocpv-rskd2-metal-ap-northeast-1d    namespace: openshift-machine-api -  resourceVersion: "23688" -  uid: 8bbed1d2-3ce9-43bb-b412-a330fac4df2c  spec:    replicas: 2    selector:      matchLabels:        machine.openshift.io/cluster-api-cluster: ocpv-rskd2 -      machine.openshift.io/cluster-api-machineset: ocpv-rskd2-worker-ap-northeast-1d +      machine.openshift.io/cluster-api-machineset: ocpv-rskd2-metal-ap-northeast-1d    template:      metadata:        labels:          machine.openshift.io/cluster-api-cluster: ocpv-rskd2          machine.openshift.io/cluster-api-machine-role: worker          machine.openshift.io/cluster-api-machine-type: worker -        machine.openshift.io/cluster-api-machineset: ocpv-rskd2-worker-ap-northeast-1d +        machine.openshift.io/cluster-api-machineset: ocpv-rskd2-metal-ap-northeast-1d      spec:        lifecycleHooks: {} -      metadata: {} +      metadata: +        creationTimestamp: null +        labels: +          node-role.kubernetes.io/worker: ""        providerSpec:          value:            ami: @@ -47,7 +42,7 @@            deviceIndex: 0            iamInstanceProfile:              id: ocpv-rskd2-worker-profile -          instanceType: m6i.large +          instanceType: m5.metal            kind: AWSMachineProviderConfig            metadata:              creationTimestamp: null @@ -69,9 +64,3 @@              value: owned            userDataSecret:              name: worker-user-data -status: -  availableReplicas: 2 -  fullyLabeledReplicas: 2 -  observedGeneration: 1 -  readyReplicas: 2 -  replicas: 2 [takitou@takuya-PC aws410]$ 作成したマニフェストをOpenShiftクラスタに適用します。 oc create -f ocpv-odf-apne-1d.yaml oc create -f ocpv-metal-apne-1d.yaml AWSのクラウドAPIを叩いて実際にノードを作成するため少し時間が掛かります。適用したことを確認します。 oc get machine -n openshift-machine-api oc get machineset -n openshift-machine-api これでODFとOpenShift Virtualization用のノードがデプロイできました。 Operatorインストール （ODF） OperatorHubでODFを検索しクリックします。 特に変更なくインストールを行います。 インストールが完了したら、同時にOpenShift Virtualization Operatorもインストールします。 Storage System CR作成 次にODFのカスタムリソースであるStorage Systemを作成し、ストレージクラスタを構成します。 提供されるAPIのStorage Systemをクリックします。 1については特に変更なく進みます。 2の容量およびノードについては、MachineSetを作成するためのマニフェストにラベルを付与していましたので、デフォルトで対象のノードが選択された状態になっています。このまま進みます。 セキュリティおよびネットワークについても特に変更点ありません。このまま進めてStorage Systemを作成していまいます。 作成が完了すると、ODFのコンソールが確認できるようになります。 デフォルト ストレージクラスの変更 ODFでStorage Systemを作成してから、OpenShift VirtualizationのHyper Converged CRを作成するまでの間に行う重要なことがあります。 デフォルトのStorage ClassをODFで作成した ocs-storagecluster-ceph-rbdに変更します。 この変更によって、この後作成するHyper Converged CRによって仮想マシンテンプレートのOSイメージ保存先が変更されます。デフォルトの gp2だとRWX属性ではないため、gp2で作成された仮想マシンでライブマイグレーションが実施できません。 HCO CR作成 続いて、HyperConveged CRも作成します。内容はデフォルトのままで問題ありません。 Administratorパースペクティブに仮想化のビューが出現しました。 仮想インスタンスの立ち上げ なんと！OpenShift 4.10から、いくつかの仮想マシンのテンプレートにブートソース(OSイメージ)がデフォルトで設定されるようになりました。 特にコンフィグレーションを変更していない場合は、このブートソースのOSイメージは常に最新を目指します。機能追加、脆弱性修正などで新しいパッチバージョンがリリースされた場合、これに追従します。 ブートソースのPVのストレージクラスがデフォルトで指定したocs-storagecluster-ceph-rbdであることが確認できます。   最後にOpenShiftで仮想マシンが立ち上げられることを確認します。 次回 次回は実際にマイグレーションなどの機能を確認して使ってみようと思います。      

Red Hat のソリューションアーキテクトの杉本拓です。 Red Hat にはクラウドネイティブアプリの開発に役立つ、ソフトウェアのラインナップが充実していることをご存知ですか？ ここでは、それらのソフトウェア [Red Hat Application Services] に関する注目ニュースを、各製品技術に特化したソリューションアーキテクトが、ご紹介します。 今回は 2022/4月号となります。 想定読者 エンタープライズアーキテクト アプリケーション開発者 システムの提案をするSIerの方 特集1: Quarkusのアーキテクチャ -スレッド編- Quarkusの特徴としてあげられるノンブロッキングですが、どの様な効果があって、ブロッキング処理とどの様に使い分ければ良いのか。また、ブロッキング処理を実装しないといけない場合にどの様な事を注意しないといけないのかを簡単にまとめました。 rheb.hatenablog.com 特集2: クラウドネイティブなAPI管理を実現するKuadrantとそのサブプロジェクトAuthorino KuadrantはKubernetesにデプロイされているAPIを安全に公開、利用できるようにするためのクラウドネイティブなAPI管理のオープンソースプロジェクトです。KuadrantではAPI管理の機能が疎結合なコンポーネントとして独立して動作することを目的として設計されており、ここではKuadrantのサブプロジェクトで、認証認可のコンポーネントとなるAuthorinoについて概要とサンプルアプリケーションの動かし方を紹介しています。 rheb.hatenablog.com 好評開催中！クラウドネイティブアプリ開発関連のWebinar全６回 Cloud Nativeを見据えたアプリケーションアーキテクチャとレガシーモダナイゼーション コンテナ時代の開発ツールチェインと開発プロセスのベストプラクティス クラウド/コンテナを前提とした時代のアプリケーション実行環境の選択 マイクロサービス/サーバーレス実践入門 これからのシステム連携を実現するデジタル基盤とアプローチ Cloud Nativeなデータパイプラインの作り方とオープンハイブリッドクラウドへの展開 各回とも、オンデマンドで視聴出来ます。（お名前とメールアドレス等の登録のみで視聴可能です） 下記リンクよりぜひご登録ください。 www.redhat.com 直近GAになった製品群 最近リリースとなった Application Services 製品群のリストをご紹介します。 見逃している製品が無いか、是非一度ご確認ください。 PAM/DM 7.12 Red Hat Data Grid 8.3

皆さんこんにちは、Red Hat ソリューションアーキテクトの岡野です。 前回 は AAP2.1 の大きな変更点であるコンテナ化された実行環境と、Ansible Automation Controller による実行方法についてご説明しました。今回、ansible-navigator のご説明をしよう！と思っていたのですが、ちょっと予定を変更して、旧バージョンからのアップグレードに関してご説明しようと思います。 旧バージョンである、AAP 1.2（Ansible Tower 3.8）は、2022年11月18日 でサポート終了（EOL）なのですが、実はこれを見越してか弊社サポートには、 『Ansible Tower 3.8 の11月18日以降のサポートってどうなるんですか!?』 というような問い合わせが複数来ている様です。勿論 EOL 後はサポートが無くなるので、AAP 2.1 へ早めの移行をお願いします！となるのですが、アップグレードへの不安も大きいのかなとも思い、 『ブログで早くご紹介しなければ』 と思い立ったというのが背景です。その方がお互いハッピーですしね。♬ まず、最初に申し上げておくと、AAP 1.2 → AAP 2.1 へのバージョンアップは決して難しくありません。 押さえておくべき点は以下の2つです。 アップグレードの手法としては『インプレースアップグレード』または『バックアップ・リストア』が可能 但し、使える手法は既存環境に依存 変更またはサポートされなくなった機能とその移行方法について理解する AAP 1.2 と AAP 2.1 の『主な違い』は下記の通りです。 システム要件 最小 4CPU/16GB など、OSはRHEL 8.4 or later のみサポート（RHEL 7.x / CentOS が非サポートに） ※Disk などその他の要件はマニュアルをご確認ください。 Python の仮想環境 (virtualenv) → execution environment virtualenv を使っている場合は実行環境への移行を検討 ansible engine 2.9 → ansible-core 2.12 モジュール提供方法の違い 現在 AAP 1.2 環境で利用しているモジュールと AAP 2.1 での提供方法についての確認 必要な場合は実行環境へのモジュールの追加 Isolated Node → Automation Mesh （その２でご紹介） Isolated Node を使っている場合は Automation Mesh の機能の理解と移行方法の確認 その他 AAP 2.0 以降サポートされなくなった機能に関しては以下のリリースノートをご確認ください。 docs.ansible.com では、上記を考慮した具体的なアップグレード方法を見ていきます。 1. システム要件を考慮したアップグレード手法の選択 AAP 1.2 → AAP 2.1 へのバージョンアップの方法は以下の2つが提供されています。 インプレースアップグレード バックアップリストア 簡単なのは『1』です。既存の AAP 1.2 環境に対する AAP 2.1 の上書きインストールなので、AAP 2.1 の新規インストールを理解した方であれば簡単です。但し、この方法は旧環境が AAP 1.2 であること、また、AAP 2.1 のシステム要件を旧環境が満たしている事が条件となります。例えば、Ansible Tower 3.7 (既にEOLですが...) をご利用の場合には、AAP 1.2 への事前アップグレード、RHEL 7.x をご利用の場合は、RHEL 8 へのアップグレード（以下のリンク参照）を事前に実施いただく必要があります。 access.redhat.com 既存 が CentOS の場合、また、既存は RHEL 7.x なんだけど、やっぱり RHEL 8 は新規でインストールしたい・・・、という場合など、新たな OS の上に AAP 2.1 をインストールする場合は、『2』 のバックアップリストアを行う事になります。この際の注意点は、 『バックアップ元の AAP とリストア先の AAP のバージョンは同一であること』 という条件がある事です。このため、以下のようなアップグレード手順となります。 新たに RHEL 8.4 (or later) をインストール 新環境に AAP 1.2 をインストール (./setup.sh) 旧 AAP 1.2 のバックアップを取得 (./setup.sh -b) 新 AAP 1.2 環境にバックアップイメージをリストア (./setup.sh -r) 新環境を AAP 1.2 → AAP 2.1 にインプレースアップグレード AAP 1.2 のバクアップイメージを直接 AAP 2.1 環境にリストア出来ないため、手順が少し多くなりますが似たようなコマンド叩くだけなので難しいことはありません。Ansible Towerのバックアップリストアに関してはこちらもご参照ください。 rheb.hatenablog.com 2. Python の仮想環境 (virtualenv) → execution environment 3. ansible engine 2.9 → ansible-core 2.12 モジュール提供方法の違い 2 と 3 ですが、共に『実行環境をカスタムで作成する事』により対応します。前回 Part 1で、AAP 2.1 で利用するコンテナ化された実行環境は Red Hat Ecosystem Catalog より提供されるというご説明をしましたが、カスタムで作成する事も可能です。カスタムでの実行環境の作成が必要となるのは主に以下の二つのケースです。 AAP 1.2 で利用している virtualenv の移行 モジュールや依存パッケージのインストール AAP 1.2 で Python の仮想環境である virtualenv を利用されている場合、AAP 2.1 では、その環境をコンテナ化された実行環境に移行するのがベストプラクティスです。また、既存の AAP 1.2 環境で ansible 2.9 に対して Collections を追加インストールしている様な場合は、それらを含む実行環境のカスタム作成が基本スタンスとなります。ただ、 『実行環境をカスタムで作成するって難しそう...』 ・・・ですよね。でも、AAP 2.1 でサポートされた実行環境のカスタマイズツールである ansible-builder を使うと簡単です！ ansible-builder は AAP 2.1 とは別インストールの CLI ツールです。まずは、ansible-builder のコマンドラインから直接読み込まれる execution-environment.yml ファイルを作成し、さらにその中から最大4つのファイルを読み込んで実行環境を作成します。要はこのファイルの中に自分が追加したいコンポーネントを記載してコマンドを実行すればOK。考えるよりやってみると実は簡単です。 execution-environment.yml コマンド実行時に指定するファイル。この中で以下のファイルを指定します。 ansible.cfg Collections のダウンロード先に関する情報とアクセストークン情報 requirements.yml ダウンロード対象の Collections の指定 requirements.txt Collections が必要とする Python モジュール bindep.txt Collections が必要とする OS パッケージ execution-environment.yml から読み込まれる4つのファイルについては必要なファイルのみ作成の上指定すればOKです。一例ですが、カスタマイズ用の最小のイメージ ee-minimal-rhel8 に vmware のコミュニティモジュール community.vmware を追加する場合はこんな感じでファイルを作成します。 ・execution-environment.yml version: 1 build_arg_defaults: EE_BASE_IMAGE: 'registry.redhat.io/ansible-automation-platform-21/ee-minimal-rhel8:latest' EE_BUILDER_IMAGE: 'registry.redhat.io/ansible-automation-platform-21/ansible-builder-rhel8:latest' ansible_config: 'ansible.cfg' dependencies: galaxy: requirements.yml python: requirements.txt system: bindep.txt 　 ・ansible.cfg url=https://cloud.redhat.com/api/automation-hub/ auth_url=https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token token=<your_access_token_here> ※ アクセストークンはご自身の物に置き換えてください 　 ・requirements.yml collections: - community.vmware ※requirements.txt と bindep.txt は今回は空ファイルです。 　 ansible-builder 及び、 ansible-navigator をインストールしていない場合はインストールしましょう。 $ sudo subscription-manager repos --enable ansible-automation-platform-2.1-for-rhel-8-x86_64-rpms $ sudo dnf install ansible-navigator $ sudo dnf install ansible-builer ### ベースイメージのダウンロードに必要な Red Hat Ecosystem Catalog へのログイン $ podman login registry.redhat.io ansible-builer build コマンドでビルドします！！ $ ansible-builder build -t com-vmware:0.0.1 podman コマンドで作成した実行環境イメージについて確認してみます。 $ podman images REPOSITORY TAG IMAGE ID CREATED SIZE localhost/com-vmware 0.0.1 7baa2662f467 53 minutes ago 553 MB <none> <none> 724422227dd8 49 minutes ago 422 MB <none> <none> 699ecae59108 49 minutes ago 403 MB <none> はビルドに利用した中間イメージです。容量を食うので削除しておきましょう。♬ $ podman image prune ansible-navigator による実行環境の詳細確認 $ ansible-navigator images --pp never 作成したイメージと、ビルドに利用した実行環境のイメージが一覧表示されます。詳細確認には左横の番号をキーボード入力ください。上記の場合は、『5』です。作成に利用したベースイメージは『10』ですね。 さらに、『2』を入力して、インストールされた Collections を確認してみてください。 community.vmware がインストールされていることが分かります。『esc』キーを使って元に戻り、さらに『3』を入力して、Python パッケージを確認してみてください。 community.vmware に必要な pyvmomi 、 vSphere-Automation-SDK がインストールされていることが分かります。興味ある方は、上記内容を、ベースとなったイメージと比べてみると良いと思います。これで、ansible-core 2.12 の実行環境にcommunity.vmware を組み込む事が出来ましたので、後はこの実行環境を使って実際の vSphere の環境を操作できるか確認すれば完了です！簡単ですよね♬ 上記では簡単な例として、 community.vmware モジュールを追加しましたが、 ansible.posix 、 amazon.aws 、 ansible.windows を追加する場合は、 requirement.yml を以下の様に編集しビルドすればOKです。 ・requirements.yml collections: - ansible.posix - amazon.aws - ansible.windows 慣れると簡単ですので、色々作成して遊んでみてください。♬ ansible-builder を使ってカスタムビルドの実行環境が出来る様になったら、 virtualenv の移行も簡単です。以下のマニュアルに分かり易く記載されていますのでご確認いただければと思います。 access.redhat.com 基本的には、以下の手順となります。 既存環境で定義されている全てのカスタム仮想環境とそのパスを一覧表示 (list_custom_venvs) 移行予定のカスタム仮想環境に依存するAutomation Controller のリソースを表示 (custom_venv_associations) 移行予定のカスタム仮想環境を requirements.txt としてエクスポートする (export_custom_venv -q)。 requirements.txt を使って実行環境をビルド ちょっと長くなりましたので、Isolated Node → Automation Mesh については次回ご説明したいと思います。 まとめ アップグレードを検討する際のポイントは以下となります。 システム要件や機能など AAP 1.2 との差異を理解する サポートされなくなった機能の AAP 1.2 での利用の有無を確認する サポートされなくなった機能の移行とその方法について理解する virtualenv → execution environment Isolated Node → Automation Mesh （次回説明）など ansible-builder の利用詳細については以下のマニュアルを参照ください。 access.redhat.com

Red Hatでソリューションアーキテクトをしている杉本 拓です。今回の赤帽ブログではKuadrantについてご紹介します。 Kuadrant は、Kubernetesで動作するアプリケーションを開発するデベロッパーが、そのKubernetesのサービスを安全に公開、利用できるようにするためのクラウドネイティブなAPI管理のオープンソースプロジェクトです。一般的にAPI管理の機能として、APIゲートウェイ、認証認可、流量制御、分析、デベロッパーポータル、課金などの機能が求められますが、Kuadrantではそれらの機能が疎結合なコンポーネントとして独立して動作することを目的として設計されています。まだすべてのコンポーネントが実装されている訳ではありませんが、認証認可については Authorino というサブプロジェクト、流量制御については Limitador というサブプロジェクトで開発が進められています。このブログでは認証認可のAuthorinoについて、概要を紹介し、サンプルアプリケーションを動かしていきたいと思います。 Authorinoについて Authorinoを使用することで、アプリケーションのソースコードに手を加えずに、業界標準となっている認証プロトコルや認可のポリシーを自由に組み合わせてAPIをセキュアにすることが可能になります。 Authorinoは Envoy Proxy の External Authorization のgRPCプロトコルを実装しており、KubernetesのCustom Resource DefinitionsとOperatorパターンをベースにしています。 Authorinoを使用した認可のフローは以下のようになっています。 ユーザーまたはサービスアカウント（以下、コンシューマ）は、Upstreamサービス (APIバックエンド) のリソースにアクセスするためのアクセストークンを取得し、Envoy ingressエンドポイントにリクエストを送信します。 Envoy ProxyはAuthorinoとのgRPC接続を確立し、Authorino はHTTPリクエストのデータ（コンテキスト情報）を元にAuthConfigカスタムリソースを参照して認証認可を適用します。 アイデンティティの検証（認証）フェーズ - Authorinoは、IDプロバイダを経由してコンシューマのIDを検証します。 外部メタデータフェーズ - Authorinoは、外部のデータソースから認可のための追加のメタデータを取得します（オプション）。 ポリシー適用（認可）フェーズ - Authorinoは、コンテキスト情報、IDオブジェクト、前フェーズで取得した追加のメタデータから構成されるJSONを入力として受け取り、ユーザー定義の認可ポリシーを適用します。 レスポンス（メタデータ出力）フェーズ - Authorinoは、ユーザー定義のカスタム・レスポンス（動的JSONオブジェクトやFestival Wristband OIDCトークン）を構成し、クライアントやアップストリーム・サービスにHTTPヘッダやEnvoyの動的メタデータとして提供します（オプション）。 AuthorinoとEnvoyは、OK/NOK (Not-OK) のいずれかのレスポンスで認可プロトコルを処理します。 許可された場合、Envoyは他のHTTPフィルター（もしあれば）をトリガーし、Authorinoから返された動的メタデータをインジェクトし、最終的にリクエストをUpstreamにリダイレクトします。 Upstreamは要求されたリソースをコンシューマに提供します。 AuthorinoでのAPIキーによる認証 ではAuthorinoでAPIキーを使用した認証がどのように行われるのか、Authorinoのユーザガイドにあるサンプルアプリケーションで確認していきましょう。 AuthorinoはKubernetesで動作しますが、ここではローカルにKubernetesクラスタを簡単に構築できるツールKindを使用します。Kindのセットアップについては、こちらのページ ( https://kind.sigs.k8s.io/ ) をご参照ださい。Authorinoのサンプルアプリケーションを動かすために、以下のKindを使用してKubernetesクラスタ環境を構築しておきます。 kind create cluster --name authorino-trial 1 - Authorinoオペレータのインストール kubectl apply -f https://raw.githubusercontent.com/Kuadrant/authorino-operator/main/config/deploy/manifests.yaml 2 - ネームスペースの作成 kubectl create namespace authorino 3 - Talker API のデプロイ Talker APIはAuthorinoに含まれているサンプルのAPI実装で、HTTPのレスポンス情報を返すシンプルなEcho APIとなっており、ここではこのTalker APIをAPIキーを使用して保護します。 kubectl -n authorino apply -f https://raw.githubusercontent.com/kuadrant/authorino-examples/main/talker-api/talker-api-deploy.yaml 4 - Authorinoのデプロイ kubectl -n authorino apply -f -<<EOF apiVersion: operator.authorino.kuadrant.io/v1beta1 kind: Authorino metadata: name: authorino spec: listener: tls: enabled: false oidcServer: tls: enabled: false EOF このコマンドにより、AuthorinoはTalker APIのサイドカーやその他のサービスとは別のサービスとして、TLS終端は無効状態でデプロイされます。 5 - Envoyのセットアップ Authorinoに含まれるサンプルアプリケーションでは、以下のコマンドによりEnvoyの設定を行い、Envoy Proxyをデプロイします。これによりEnvoy ProxyがTalker APIのリバースプロキシとなり、AuthorinoでEnvoyのExternal Authorizationが適用されるようになります。 kubectl -n authorino apply -f https://raw.githubusercontent.com/kuadrant/authorino-examples/main/envoy/envoy-notls-deploy.yaml 上記コマンドでは、talker-api-authorino.127.0.0.1.nip.io　というホスト名でIngressが作成されますが、Kindコマンドを使用して構築されたローカルのKubernetesクラスタを使用している場合、リクエストがEnvoyサービスに到達できるようにするためには8000ポートへのリクエストをKubernetesクラスタにフォワードする必要があります。 kubectl -n authorino port-forward deployment/envoy 8000:8000 & 6 - AuthConfigの作成 kubectl -n authorino apply -f -<<EOF apiVersion: authorino.kuadrant.io/v1beta1 kind: AuthConfig metadata: name: talker-api-protection spec: hosts: - talker-api-authorino.127.0.0.1.nip.io identity: - name: friends apiKey: labelSelectors: group: friends credentials: in: authorization_header keySelector: APIKEY EOF 7 - APIキーの作成 kubectl -n authorino apply -f -<<EOF apiVersion: v1 kind: Secret metadata: name: api-key-1 labels: authorino.kuadrant.io/managed-by: authorino group: friends stringData: api_key: ndyBzreUzF4zqDQsqSPMHkRhriEOtcRx type: Opaque EOF 8 - APIへのリクエスト 適切なAPIキーをつけてAPIに対してリクエストを行う場合: curl -H 'Authorization: APIKEY ndyBzreUzF4zqDQsqSPMHkRhriEOtcRx' http://talker-api-authorino.127.0.0.1.nip.io:8000/hello # HTTP/1.1 200 OK この場合認証が成功し、200のステータスコードでレスポンスが返ってきます。 不適切なAPIキーをつけてAPIに対してリクエストを行う場合: curl -H 'Authorization: APIKEY invalid' http://talker-api-authorino.127.0.0.1.nip.io:8000/hello -i # HTTP/1.1 401 Unauthorized # www-authenticate: APIKEY realm="friends" # x-ext-auth-reason: the API Key provided is invalid APIキーが無かったり正しくない場合には認証に失敗し、401のステータスコードでレスポンスが返ってきます。 9 - APIキーの削除（APIへのアクセスの取り消し） kubectl -n authorino delete secret/api-key-1 以上のように、Authorinoを使用することでAPIの実装に手を加えることなく、APIキーを使用してAPIを保護することができるようになります。 上記のサンプルアプリケーションの環境をクリーンアップするには、以下のコマンドを実行することでKubernetesクラスタを削除することができます。 kind delete cluster --name authorino-trial ステップ1と2で作成したネームスペースだけを削除したい場合には以下のコマンドを実行します。 kubectl -n authorino namespace authorino kubectl -n authorino namespace authorino-operator Authorinoのユーザガイドには、他にもOAuth2のトークンイントロスペクション、OIDCのJWT認証、OIDCのRBAC、トークンの正規化、Keycloackとの連携など、さまざまなサンプルアプリケーションが公開されています。 その他のデプロイ方式、AuthorinoのアーキテクチャやCRDの詳細情報については、ドキュメントの Getting Startedページ 、 Architectureページ 、Authorino Operatorリポジトリにある Authorino CRDの仕様 を確認してください。

こんにんちは、Red Hat でソリューション・アーキテクトをしています花田です。 本日は、コンテナ向けのセキュリティ製品である RHACS (Red Hat Advanced Cluster Security for Kubernetes) をご紹介したいと思います。 RHACS と言うとちょっと長いので、以降 ACS と呼びます。 ACS とは ACS とは一言で言うと Red Hat の提供する Kubernetes 向けのセキュリティ製品です。 元になったのは、Red Hat 社が 2021年の1月に買収した StackRox 社 の製品です。 現在は、マニュアルも Red Hat 風のスタイルに統一され、 こちら から参照できるようになっています。 ACS の構成 ACS のアーキクテクチャーは、コンテナ形式で提供される Central と呼ばれる管理サーバーと、 Central の管理対象となる Kubernetes クラスターに別れます。 ACS構成 上の図では、 Central と Central の管理対象である Kubernetes クラスターは分かれて描かれていますが、 Central のインストール先も Kubernetes クラスターですので、自分自身のインストール先を管理対象とする事も可能です。 サポート対象の環境は、 Central のソフトウェアを導入する Kubernetes クラスターと、 Central の管理対象となりセキュリティを管理される側の Kubernetes クラスターで別になっています。サポート環境については、 こちらのドキュメント をご参照下さい。 現在、 Central のインストール先としてサポートされているのは、基本的に OpenShift 4 の環境になります。ただ、StackRox 社時代は、OpenShift 以外の Kubernetes 環境もサポートされていた歴史的な経緯もあり、通常の Kubernetes 環境にも 技術的にはインストールは可能とされていますが、現在は限定的なサポート( Commercially Reasonable Support )となっています。 また、ACS リリース当初は、 Central のサポートは、ユーザーがインストールした OpenShift 4 環境のみのサポートでしたが、現在では OSD *1 / ARO *2 / ROSA *3 等の OpenShift 4のマネージドサービス環境 も Central のインストール先としてサポートされるようになっています。 Central の管理対象となる Kubernetes は、OpenShift だけでなく、EKS、GKE、AKSもサポート対象としてカバーしています。 ダッシュボード インストールされた ACS にログインすると、管理対象の Kubernetes クラスターのセキュリティの状態を示す専用のダッシュボードが現れます。このダッシュボードは OpenShift のダッシュボードとは別で、ACS が提供しているものです。 ACS ダッシュボード 管理者はこのダッシュボードを見て、日々のセキュリティにまつわるタスクをこなしていく事になります。 ACS 内で生成されたアラートなどは、 Slack 等のコミュニケーションツールや、 splunk や sumo logic と言ったログ管理システムや email 等にフォワードできるようになっています。 イメージ・レジストリとの統合 ACSは、 Amazon ECR や、 Docker Hub 、 Google Container Registry 、 IBM Cloud Container Registry 、 Microsoft Azure Container Registry (ACR) 、 Red Hat Quay 等の Docker Registry HTTP API をサポートする 各種イメージ・レジストリと統合する事ができます 。 イメージ・レジストリと統合する事で、イメージの詳細の情報を取得したり、イメージのスキャンなどを行う事ができるようになります。 尚、ACS 自体には、イメージ・レジストリのソフトウェアそのものは付属していないのでご注意下さい。 ACS の基本コンセプト ACSでは、コンテナが Build されて、 Kubernetes 上に Deploy され、その後、運用に入って実際にコンテナが稼働している状況 ( Run ) と言ったコンテナのライフサイクルの各フェーズにおいて、セキュリティ対策を提供しています。 ACS の コンセプト それぞれのフェーズで、脆弱性のスキャンだけでなく、適用するセキュリティのポリシーをユーザーが作成する事が可能です。 コンテナのビルドプロセスとの統合 コンテナのビルドのプロセスは、通常 CLIでの操作を前提としているので、ビルドプロセスとセキュリティの検査を統合するには、CLIのツールが必用になってきます。 多くの脆弱性スキャン製品がそうであるように、ACS も roxctl と呼ばれるCLIツールを提供しています。 roxctl CLI roxctl コマンドは、実行時に ACS の Central に問い合わせを行います。 このコマンドを使用してコンテナのビルドプロセスにおける脆弱性スキャンや、ACS内でユーザーが定義したセキュリティ・ポリシーに違反していないかスキャンを行う事ができます。 例えば以下のようなコマンドでイメージがセキュリティポリシーに適合しているがスキャンをする事が可能です。 roxctl image check --image <image_name> -e $ROX_CENTRAL_ADDRESS roxctl コマンドによるイメージのスキャン結果 KubeLinter 英語で Lint Remover と言うと、毛玉や糸くずを取るツールの事を指します。プログラミングの世界では、開発者の書いたプログラムの構文を解析して様々なチェックしてくれるツールの事を Linter と呼びます。 Kubernetes の世界では、 YAML地獄 と呼ばれる用語があるくらいに YAML のマニフェスト・ファイルをたくさん書かなければいけません。 これらの YAMLのファイルは構文ミスがあれば、 Kubernetes 側が受け付けてくれませんが、省略しても良い記述などについては、構文が合っている限りは受け付けてくれます。 ですので、開発者は省略しても大丈夫な記述は省略しがちですし、記述するのが面倒なので、セキュリティ的に甘い設定の記述をしがちです。 開発者が(主に楽をするために) 省略しがちな設定や、甘めのセキュリティの指定の記述を事前にチェックしてくれる KuberLinter というツールがあります。 KubeLinter は、現状、ACS に製品として含まれているツールではないのですが、StackRox 社によって開発されて、OpenSource として公開されています。 製品に含まれているものではないため、製品解説のこのブログで詳細は取り扱いませんが、代わりに こちら に簡単な使い勝手の記事を書きましたのでよろしければご参照下さい。 ポリシーの作成 ACS では、ユーザーが「ポリシー」を作成する事ができます。このポリシーを使って、作成しているイメージや、イメージをデプロイするための Kubernetes の Deployment のマニフェストの内容をチェックする事ができます。 ACS の Policy 作成画面 上記の左側の例は、コンテナのイメージに、Alpine Linux のパッケージ管理ツールである apk が含まれてないかチェックするポリシーの例です。 コンテナは完成したアプリケーション・イメージですので、パッケージ管理ツールは、イメージが完成した後は必要のないツールになります。残っていると攻撃者に対して新規のパッケージを追加する機会を与えてしまう可能性があるので、こう言ったポリシーが作れるようになっています。 ポリシーで行える事はたくさんあり、全てはここではご紹介できませんが、上記のようなイメージに含まれるコンポーネントのチェックの他にも、マニフェスト内の annotation のチェックや、CPU や Memory のリクエスト量のチェック等の構成にまつわるもの、ある一定レベル以上の CVSS (Common Vulnerability Scoring System) スコアを持つ脆弱性が含まれていないか等もチェックする事が可能です。 また、ACS では、前述のように、 Build 、 Deploy 、 Run の３段階でコンテナのライフサイクルを区分しています。 作成されたポリシーは、この３つのどの段階で適用するか選べるようになっています。(内容によっては、特定のフェーズでしか設定できないものもあります) 稼働中の脆弱性の報告 ビルドした時には、脆弱性が特に無かったイメージでも、時間の経過とともに脆弱性が発見されていきます。そのため、デプロイされたコンテナも定期的に脆弱性のスキャンを行う必要があります。 脆弱性管理のためのダッシュボード 一般的にこれらの稼働中のコンテナのスキャンは、実際に実行されているコンテナをスキャンすると、コンテナの稼働に影響があるので、コンテナを PULL してきたイメージ・レジストリに対して行います。コンテナはイメージで、実行される度にコンテナデプロイ用のマニフェストに記述されている、コンテナのレジストリから PULL されてくるので、実行中のイメージを確認しなくても良いという特徴があります。 ACS では稼働中のコンテナのイメージの脆弱性のチェックを定期的にスキャンして行うようになっています。また、前述のポリシーを使って一定の期間、更新が無いイメージを含む Deployment を通知する事も可能です。 脆弱性の検知は、 Kubernetes の Deployment 単位毎に評価結果がまとめられて表示されます。脆弱性管理のダッシュボード上から、危険度の高い Deployment → コンテナに含まれる CVE → 各CVE情報の詳細 という流れで情報を追いかける事ができるようになっています。 Network の Baseline とプロセスのランタイム検知 ACS では、ある時点でのコンテナの通信のアクセス先やポートなどの情報を教えてくれます。正常な状態の通信先を Baseline として記録しておく事で、 Baseline から外れた通信を検知する事ができます。 その他にも、コンテナ内でのシェルや、コマンド実行を検知する事も可能です。 ACS-Network-Activity また、コンテナ内で実行される怪しいプロセスの検知も行う事ができます。 bash 等の起動だったり、コンテナ内に追加のパッケージをインストールするための yum や dnf などの起動を検知する事が可能です。 ランタイム検知 Process の Baseline と Baseline に存在しないプロセスの検知 ACS は、Network の Baseline と同様に Deployment 内で起動される プロセスに対しても Baseline を作成します。 Baseline には存在しないプロセスの実行を検知する事が可能です。 ACS の process baseline コンプライアンスの準拠状況 ACS には、 CIS Benchmark(Docker, Kubernetes) 、 HIPPA 、 NIST (SP800-190 / 800-53) 、 PCI-DSS 等のコンプライアンスへの遵守状況をレポートするダッシュボードが組み込まれています。 コンプライアンスの遵守状況 これらのコンプライアンチェック機能は、デフォルトで ACS に組み込まれています。 コアな OpenShfit ユーザーであれば、OpenShift (OKE / OCP) にも Compliance Operator という機能が提供されており、似たようなコンプライアンスチェック機能がある事をご存じだと思います。 OpenShift 本体の Compliance Operator と、ACS のコンプライアンスの機能は、現状ではそれぞれ並行して開発が進められています。 どちらが良い。とは一概には言えないのですが、Compliance Operator は、基本 CLI による操作になる一方で、ACS では GUIから管理するのが基本的なスタイルになっていて、レポートの生成までサポートしているなど、使い勝手の面などで違いがあります。 まとめ 本ブログでは、 Kubernetes 向けのセキュリティ管理ツールである ACS (Advanced Cluster Security) の機能概要について簡単にご紹介してみました。 Enterprise 環境への Kubernetes の適用が進むにつれて、コンテナ環境のセキュリティについても注目が集まってきています。煩雑なコンテナセキュリティの管理を楽にするツールとして、ACS をご検討頂ければ幸いです。 参考リソース ACS マニュアル StackRox コミニュティ・ページ *1 : OSD = OpenShift Dedicated: AWS or GCP の上で提供される OpenShift の Managed Service. Red Hat が直接販売するサービス *2 : ARO = Azure Red Hat OpenShift: Azure 上で提供されている OpenShift の Managed Service. Azure ポータルから使用可能 *3 : ROSA = Red Hat OpenShift on AWS) AWS 上で提供されている OpenShift の Managed Service. AWS ポータルから使用可能