第18章 オブジェクトのプルーニング
18.1. 概要
OpenShift Container Platform で作成される API オブジェクトは、一定期間が経過すると、アプリケーションのビルドやデプロイなどの通常のユーザー操作によって etcd データストアに蓄積されます。
管理者は、不要になった古いバージョンのオブジェクトを OpenShift Container Platform インスタンスから定期的にプルーニングできます。たとえば、イメージのプルーニングにより、使用されなくなったものの、ディスク領域を使用している古いイメージや層を削除できます。
18.2. プルーニングの基本操作
CLI は、共通の親コマンドでプルーニング操作を分類します。
$ oc adm prune <object_type> <options>
これにより、以下が指定されます。
-
builds、deployments、またはimagesなどのアクションを実行するための<object_type>です。 -
オブジェクトタイプのプルーニングの実行においてサポートされる
<options>です。
18.3. デプロイメントのプルーニング
使用年数やステータスによりシステムで不要となったデプロイメントをプルーニングするために、管理者は以下のコマンドを実行できます。
$ oc adm prune deployments [<options>]
表18.1 デプロイメントのプルーニング用の CLI の設定オプション
| オプション | 説明 |
|---|---|
|
|
ドライランの実行ではなく、プルーニングが実行されることを示します。 |
|
|
デプロイメント設定が存在せず、ステータスが complete (完了) または failed (失敗) で、レプリカ数がゼロであるすべてのデプロイメントをプルーニングします。 |
|
|
デプロイメント設定に基づき、ステータスが complete (完了) で、レプリカ数がゼロである最後の N デプロイメントを保持します (デフォルト: |
|
|
デプロイメント設定に基づき、ステータスが failed (失敗) で、レプリカ数がゼロである最後の N デプロイメントを保持します (デフォルト: |
|
|
現在の時間との対比で |
プルーニング操作によって削除されるものを確認するには、以下を実行します。
$ oc adm prune deployments --orphans --keep-complete=5 --keep-failed=1 \
--keep-younger-than=60mプルーニング操作を実際に実行するには、以下を実行します。
$ oc adm prune deployments --orphans --keep-complete=5 --keep-failed=1 \
--keep-younger-than=60m --confirm18.4. ビルドのプルーニング
使用年数やステータスによりシステムで不要となったビルドをプルーニングするために、管理者は以下のコマンドを実行できます。
$ oc adm prune builds [<options>]
表18.2 ビルドのプルーニング用の CLI の設定オプション
| オプション | 説明 |
|---|---|
|
|
ドライランの実行ではなく、プルーニングが実行されることを示します。 |
|
|
ビルド設定が存在せず、ステータスが complete (完了)、failed (失敗)、error (エラー)、または canceled (中止) のすべてのビルドをプルーニングします。 |
|
|
ビルド設定に基づき、ステータスが complete (完了) の最後の N ビルドを保持します (デフォルト: |
|
|
ビルド設定に基づき、ステータスが failed (失敗)、error (エラー)、または canceled (中止) の最後の N ビルドを保持します (デフォルト: |
|
|
現在の時間との対比で |
プルーニング操作によって削除されるものを確認するには、以下を実行します。
$ oc adm prune builds --orphans --keep-complete=5 --keep-failed=1 \
--keep-younger-than=60mプルーニング操作を実際に実行するには、以下を実行します。
$ oc adm prune builds --orphans --keep-complete=5 --keep-failed=1 \
--keep-younger-than=60m --confirm開発者は、ビルド設定を変更することにより、自動ビルドプルーニングを有効にできます。
18.5. イメージのプルーニング
使用年数やステータスまたは制限の超過によりシステムで不要となったイメージをプルーニングするために、管理者は以下のコマンドを実行できます。
$ oc adm prune images [<options>]
--prune-registry=false が使用されていない限り、イメージのプルーニングにより、統合レジストリーのデータが削除されます。この操作が適切に機能するには、storage:delete:enabled が true に設定された状態での レジストリーの設定を確認します。
--namespace フラグの付いたイメージをプルーニングしてもイメージは削除されず、イメージストリームのみが削除されます。イメージは namespace を使用しないリソースです。そのため、プルーニングを特定の namespace に制限すると、イメージの現在の使用量を算出できなくなります。
デフォルトで、統合レジストリーは Blob メタデータをキャッシュしてストレージに対する要求数を減らし、要求の処理速度を高めます。プルーニングによって統合レジストリーのキャッシュが更新されることはありません。プルーニング後にプッシュされる、プルーニングされた層を含むイメージは破損します。キャッシュにメタデータを持つプルーニングされた層はプッシュされないためです。したがって、プルーニング後はキャッシュをクリアする必要があります。これは、レジストリーの再デプロイによって実行できます。
$ oc rollout latest dc/docker-registry
統合レジストリーが Redis キャッシュを使用する場合は、データベースを手動でクリーンアップする必要があります。
プルーニング後にレジストリーを再デプロイするのオプションを実行できない場合は、キャッシュを永久に無効にする必要があります。
表18.3 イメージのプルーニング用の CLI の設定オプション
| オプション | 説明 |
|---|---|
|
|
レジストリーにプッシュされていないものの、プルスルー (pullthrough) でミラーリングされたイメージを組み込みます。これはデフォルトでオンに設定されます。プルーニングを統合レジストリーにプッシュされたイメージに制限するには、 |
|
|
OpenShift Container Platform で管理されるレジストリーと通信する際に使用する認証局ファイルへのパスです。デフォルトは現行ユーザーの設定ファイルの認証局データに設定されます。これが指定されている場合、セキュアな通信が実行されます。 |
|
|
ドライランを実行する代わりにプルーニングが実行されることを示します。これには、統合 Docker レジストリーへの有効なルートが必要になります。このコマンドがクラスターネットワーク外で実行される場合、ルートは |
|
|
このオプションは注意して使用してください。 HTTP 経由でホストされているか、または無効な HTTPS 証明書を持つ Docker レジストリーへの非セキュアな接続を許可します。詳細は、「セキュアまたは非セキュアな接続の使用」を参照してください。 |
|
|
それぞれのイメージストリームについては、タグごとに最大 N のイメージリビジョンを保持します (デフォルト: |
|
|
現在の時間との対比で |
|
|
同じプロジェクトに定義される最小の制限を超える各イメージをプルーニングします。このフラグは |
|
|
レジストリーと通信する際に使用するアドレスです。このコマンドは、管理されるイメージおよびイメージストリームから判別されるクラスター内の URL の使用を試行します。これに失敗する (レジストリーを解決できないか、これにアクセスできない) 場合、このフラグを使用して他の機能するルートを指定する必要があります。レジストリーのホスト名の前には、特定の接続プロトコルを実施する |
|
|
他のオプションで規定される条件と共に、このオプションは、OpenShift Container Platform イメージ API オブジェクトに対応するレジストリーのデータがプルーニングされるかどうかを制御します。デフォルトで、イメージのプルーニングは、イメージ API オブジェクトとレジストリーの対応するデータの両方を処理します。このオプションは、イメージオブジェクトの数を減らすなどの目的で etcd の内容のみを削除することを検討していて、レジストリーのストレージのクリーンアップは検討していない場合や、レジストリーの適切なメンテナンス期間中などに レジストリーのハードプルーニングによってこれを別途実行しようとする場合に役立ちます。 |
18.5.1. イメージのプルーニングの各種条件
--keep-younger-than分前よりも後に作成され、現時点で以下によって参照されていない「OpenShift Container Platform で管理される」イメージ (アノテーションopenshift.io/image.managedを持つイメージ) を削除します。-
--keep-younger-than分前よりも後に作成された Pod。 -
--keep-younger-than分前よりも後に作成されたイメージストリーム。 - 実行中の Pod。
- 保留中の Pod。
- レプリケーションコントローラー。
- デプロイメント設定。
- ビルド設定。
- ビルド。
-
stream.status.tags[].itemsの--keep-tag-revisionsの最新のアイテム。
-
同じプロジェクトで定義される最小の制限を超えており、現時点で以下によって参照されていない「OpenShift Container Platform で管理される」イメージ (アノテーション
openshift.io/image.managedを持つイメージ) を削除します。- 実行中の Pod。
- 保留中の Pod。
- レプリケーションコントローラー。
- デプロイメント設定。
- ビルド設定。
- ビルド。
- 外部レジストリーからのプルーニングはサポートされていません。
-
イメージがプルーニングされる際、イメージのすべての参照は
status.tagsにイメージの参照を持つすべてのイメージストリームから削除されます。 - イメージによって参照されなくなったイメージ層も削除されます。
--prune-over-size-limit は --keep-tag-revisions または --keep-younger-than フラグと共に使用することができません。これを実行すると、この操作が許可されないことを示す情報が返されます。
--prune-registry=false とその後に レジストリーのハードプルーニング を実行することで、OpenShift Container Platform イメージ API オブジェクトの削除とイメージデータのレジストリーからの削除を分離することができます。これによりタイミングウィンドウが制限され、1 つのコマンドで両方をプルーニングする場合よりも安全に実行できるようになります。ただし、タイミングウィンドウを完全に取り除くことはできません。
たとえばプルーニングの実行時にプルーニング対象のイメージを特定する場合も、そのイメージを参照する Pod を引き続き作成することができます。また、プルーニングの操作時にイメージを参照している可能性のある API オブジェクトを追跡することもできます。これにより、削除されたコンテンツの参照に関連して発生する可能性のある問題を軽減することができます。
また、--prune-registry オプションを指定しないか、または --prune-registry=true を指定してプルーニングを再実行しても、--prune-registry=false を指定して以前にプルーニングされたイメージの、イメージレジストリー内で関連付けられたストレージがプルーニングされる訳ではないことに注意してください。--prune-registry=false を指定してプルーニングされたすべてのイメージは、レジストリーのハードプルーニングによってのみ削除できます。
プルーニング操作によって削除されるものを確認するには、以下を実行します。
最高 3 つのタグリビジョンを保持し、6 分前よりも後に作成されたリソース (イメージ、イメージストリームおよび Pod) を保持します。
$ oc adm prune images --keep-tag-revisions=3 --keep-younger-than=60m
定義された制限を超えるすべてのイメージをプルーニングします。
$ oc adm prune images --prune-over-size-limit
前述のオプションでプルーニング操作を実際に実行するには、以下を実行します。
$ oc adm prune images --keep-tag-revisions=3 --keep-younger-than=60m --confirm $ oc adm prune images --prune-over-size-limit --confirm
18.5.2. セキュアまたは非セキュアな接続の使用
セキュアな通信の使用は優先され、推奨される方法です。これは、必須の証明書検証と共に HTTPS 経由で実行されます。prune コマンドは、可能な場合は常にセキュアな通信の使用を試行します。これを使用できない場合には、非セキュアな通信にフォールバックすることがあり、これには危険が伴います。この場合、証明書検証は省略されるか、または単純な HTTP プロトコルが使用されます。
非セキュアな通信へのフォールバックは、--certificate-authority が指定されていない場合、以下のケースで可能になります。
-
pruneコマンドが--force-insecureオプションと共に実行される。 -
指定される
registry-urlの前にhttp://スキームが付けられる。 -
指定される
registry-urlがローカルリンクアドレスまたは localhost である。 -
現行ユーザーの設定が非セキュアな接続を許可する。これは、ユーザーが
--insecure-skip-tls-verifyを使用してログインするか、またはプロンプトが出される際に非セキュアな接続を選択することによって生じる可能性があります。
レジストリーのセキュリティーが、OpenShift Container Platform で使用されるものとは異なる認証局で保護される場合、これを --certificate-authority フラグを使用して指定する必要があります。そうしないと、prune コマンドは、「正しくない認証局の使用」または「セキュリティーが保護されたレジストリーに対する非セキュアな接続の使用」で一覧表示されているエラーと同様のエラーを出して失敗します。
18.5.3. イメージのプルーニングに関する問題
イメージがプルーニングされない
イメージが蓄積し続け、prune コマンドが予想よりも小規模な削除を実行する場合、プルーニング候補のイメージについて満たすべき条件があることを確認します。
とくに削除する必要のあるイメージが、それぞれのタグ履歴において選択したタグリビジョンのしきい値よりも高い位置にあることを確認します。たとえば、sha:abz という名前の古く陳腐化したイメージがあるとします。イメージがタグ付けされている namespace N で以下のコマンドを実行すると、イメージが myapp という単一イメージストリームで 3 回タグ付けされていることに気づかれるでしょう。
$ image_name="sha:abz"
$ oc get is -n N -o go-template='{{range $isi, $is := .items}}{{range $ti, $tag := $is.status.tags}}'\
'{{range $ii, $item := $tag.items}}{{if eq $item.image "'"${image_name}"\
$'"}}{{$is.metadata.name}}:{{$tag.tag}} at position {{$ii}} out of {{len $tag.items}}\n'\
'{{end}}{{end}}{{end}}{{end}}'
myapp:v2 at position 4 out of 5
myapp:v2.1 at position 2 out of 2
myapp:v2.1-may-2016 at position 0 out of 1
デフォルトオプションが使用される場合、イメージは myapp:v2.1-may-2016 タグの履歴の 0 の位置にあるためプルーニングされません。イメージがプルーニングの対象と見なされるようにするには、管理者は以下を実行する必要があります。
oc adm prune imagesコマンドで--keep-tag-revisions=0を指定します。注意このアクションを実行すると、イメージが指定されたしきい値よりも新しいか、またはこれよりも新しいオブジェクトによって参照されていない限り、すべてのタグが基礎となるイメージと共にすべての namespace から削除されます。
-
リビジョンのしきい値より下にあるすべての istag、つまり
myapp:v2.1およびmyapp:v2.1-may-2016を削除します。 - 同じ istag にプッシュする新規ビルドを実行するか、または他のイメージをタグ付けしてイメージを履歴内でさらに移動させます。ただし、これは古いリリースタグの場合には常に適切な操作となる訳ではありません。
特定のイメージのビルド日時が名前の一部になっているタグは、その使用を避ける必要があります (イメージが未定義の期間保持される必要がある場合を除きます)。このようなタグは履歴内で 1 つのイメージのみに関連付けられる可能性があり、その場合にこれらをプルーニングできなくなります。詳細は、istag の命名規則を参照してください。
非セキュアなレジストリーに対するセキュアな接続の使用
oc adm prune images の出力で以下のようなメッセージが表示される場合、レジストリーのセキュリティーは保護されておらず、oc adm prune images クライアントがセキュアな接続の使用を試行することを示しています。
error: error communicating with registry: Get https://172.30.30.30:5000/healthz: http: server gave HTTP response to HTTPS client
-
推奨される解決法として、レジストリーのセキュリティーを保護することができます。これが必要でない場合には、
--force-insecureをコマンドに追加して、クライアントが非セキュアな接続の使用を強制することができます (推奨される方法ではありません)｡
18.5.3.1. セキュリティーが保護されたレジストリーに対する非セキュアな接続の使用
oc adm prune images コマンドの出力に以下のエラーのいずれかが表示される場合、レジストリーのセキュリティー保護に使用されている認証局で署名された証明書が、接続の検証用に oc adm prune images クライアントで使用されるものとは異なることを意味します。
error: error communicating with registry: Get http://172.30.30.30:5000/healthz: malformed HTTP response "\x15\x03\x01\x00\x02\x02" error: error communicating with registry: [Get https://172.30.30.30:5000/healthz: x509: certificate signed by unknown authority, Get http://172.30.30.30:5000/healthz: malformed HTTP response "\x15\x03\x01\x00\x02\x02"]
デフォルトでは、ユーザーの接続ファイルに保存されている認証局データが使用されます。これはマスター API との通信の場合も同様です。
--certificate-authority オプションを使用して Docker レジストリーサーバーに適切な認証局を指定します。
正しくない認証局の使用
以下のエラーは、セキュリティーが保護された Docker レジストリーの証明書の署名に使用される認証局がクライアントで使用される認証局とは異なることを示しています。
error: error communicating with registry: Get https://172.30.30.30:5000/: x509: certificate signed by unknown authority
フラグ --certificate-authority を使用して適切な認証局を指定します。
回避策として、--force-insecure フラグを代わりに追加することもできます (推奨される方法ではありません)。
18.6. レジストリーのハードプルーニング
OpenShift Container レジストリーは、OpenShift Container Platform クラスターの etcd で参照されない Blob を蓄積します。基本的なイメージプルーニングの手順はこれらに対応しません。これらの Blob は 孤立した Blob と呼ばれています。
孤立した Blob は以下のシナリオで発生する可能性があります。
-
oc delete image <sha256:image-id>コマンドを使ってイメージを手動で削除すると、etcd のイメージのみが削除され、レジストリーのストレージからは削除されない。 - docker デーモンの障害によって生じるレジストリーへのプッシュにより、一部の Blob はアップロードされるものの、(最後のコンポーネントとしてアップロードされる) イメージマニフェスト はアップロードされない。固有のイメージ Blob すべては孤立する。
- OpenShift Container Platform がクォータの制限によりイメージを拒否する。
- 標準のイメージプルーナーがイメージマニフェストを削除するが、関連する Blob を削除する前に中断される。
- 対象の Blob を削除できないというレジストリープルーナーのバグにより、それらを参照するイメージオブジェクトは削除されるが、Blob は孤立する。
基本的なイメージプルーニングとは異なるレジストリーの ハードプルーニング により、孤立した Blob を削除することができます。OpenShift Container レジストリーのストレージ領域が不足している場合や、孤立した Blob があると思われる場合にはハードプルーニングを実行する必要があります。
これは何度も行う操作ではなく、多数の孤立した Blob が新たに作成されているという証拠がある場合にのみ実行する必要があります。または、(作成されるイメージの数によって異なりますが) 1 日 1 回などの定期的な間隔で標準のイメージプルーニングを実行することもできます。
孤立した Blob をレジストリーからハードプルーニングするには、以下を実行します。
- ログイン: CLI を使用し、アクセストークンを持つユーザーとしてログインします。
基本的なイメージプルーニングの実行: 基本的なイメージプルーニングにより、不要になった追加のイメージが削除されます。ハードプルーニングによってイメージが削除される訳ではなく、レジストリーストレージに保存された Blob のみが削除されます。したがって、ハードプルーニングの実行前にこれを実行する必要があります。
手順については、「イメージのプルーニング」を参照してください。
レジストリーの読み取り専用モードへの切り替え: レジストリーが読み取り専用モードで実行されていない場合、プルーニングと同時に実行されているプッシュの結果は以下のいずれかになります。
- 失敗する。さらに孤立した Blob が新たに発生する。
- 成功する。ただし、(参照される Blob の一部が削除されたため) イメージをプルできない。
プッシュは、レジストリーが読み取り書き込みモードに戻されるまで成功しません。したがって、ハードプルーニングは注意してスケジューリングする必要があります。
レジストリーを読み取り専用モードに切り換えるには、以下を実行します。
以下の環境変数を設定します。
$ oc env -n default \ dc/docker-registry \ 'REGISTRY_STORAGE_MAINTENANCE_READONLY={"enabled":true}'デフォルトで、レジストリーは直前の手順が完了すると自動的に再デプロイするはずです。再デプロイが完了するのを待機してから次に進んでください。ただし、これらのトリガーを無効にしている場合は、レジストリーを手動で再デプロイし、新規の環境変数が選択されるようにする必要があります。
$ oc rollout -n default \ latest dc/docker-registry
system:image-pruner ロールの追加: 一部のリソースを一覧表示するには、レジストリーインスタンスの実行に使用するサービスアカウントに追加のパーミッションが必要になります。
サービスアカウント名を取得します。
$ service_account=$(oc get -n default \ -o jsonpath=$'system:serviceaccount:{.metadata.namespace}:{.spec.template.spec.serviceAccountName}\n' \ dc/docker-registry)system:image-pruner クラスターロールをサービスアカウントに追加します。
$ oc adm policy add-cluster-role-to-user \ system:image-pruner \ ${service_account}
(オプション) プルーナーのドライランモードでの実行: 削除される Blob の数を確認するには、ドライランモードでハードプルーナーを実行します。これにより変更が加えられることはありません。
$ oc -n default \ exec -i -t "$(oc -n default get pods -l deploymentconfig=docker-registry \ -o jsonpath=$'{.items[0].metadata.name}\n')" \ -- /usr/bin/dockerregistry -prune=checkまたは、プルーニング候補の実際のパスを取得するには、ロギングレベルを上げます。
$ oc -n default \ exec "$(oc -n default get pods -l deploymentconfig=docker-registry \ -o jsonpath=$'{.items[0].metadata.name}\n')" \ -- /bin/sh \ -c 'REGISTRY_LOG_LEVEL=info /usr/bin/dockerregistry -prune=check'出力サンプル (切り捨て済み)
$ oc exec docker-registry-3-vhndw \ -- /bin/sh -c 'REGISTRY_LOG_LEVEL=info /usr/bin/dockerregistry -prune=check' time="2017-06-22T11:50:25.066156047Z" level=info msg="start prune (dry-run mode)" distribution_version="v2.4.1+unknown" kubernetes_version=v1.6.1+$Format:%h$ openshift_version=unknown time="2017-06-22T11:50:25.092257421Z" level=info msg="Would delete blob: sha256:00043a2a5e384f6b59ab17e2c3d3a3d0a7de01b2cabeb606243e468acc663fa5" go.version=go1.7.5 instance.id=b097121c-a864-4e0c-ad6c-cc25f8fdf5a6 time="2017-06-22T11:50:25.092395621Z" level=info msg="Would delete blob: sha256:0022d49612807cb348cabc562c072ef34d756adfe0100a61952cbcb87ee6578a" go.version=go1.7.5 instance.id=b097121c-a864-4e0c-ad6c-cc25f8fdf5a6 time="2017-06-22T11:50:25.092492183Z" level=info msg="Would delete blob: sha256:0029dd4228961086707e53b881e25eba0564fa80033fbbb2e27847a28d16a37c" go.version=go1.7.5 instance.id=b097121c-a864-4e0c-ad6c-cc25f8fdf5a6 time="2017-06-22T11:50:26.673946639Z" level=info msg="Would delete blob: sha256:ff7664dfc213d6cc60fd5c5f5bb00a7bf4a687e18e1df12d349a1d07b2cf7663" go.version=go1.7.5 instance.id=b097121c-a864-4e0c-ad6c-cc25f8fdf5a6 time="2017-06-22T11:50:26.674024531Z" level=info msg="Would delete blob: sha256:ff7a933178ccd931f4b5f40f9f19a65be5eeeec207e4fad2a5bafd28afbef57e" go.version=go1.7.5 instance.id=b097121c-a864-4e0c-ad6c-cc25f8fdf5a6 time="2017-06-22T11:50:26.674675469Z" level=info msg="Would delete blob: sha256:ff9b8956794b426cc80bb49a604a0b24a1553aae96b930c6919a6675db3d5e06" go.version=go1.7.5 instance.id=b097121c-a864-4e0c-ad6c-cc25f8fdf5a6 ... Would delete 13374 blobs Would free up 2.835 GiB of disk space Use -prune=delete to actually delete the dataハードプルーニングの実行: ハードプルーニングを実行するには、docker-registry Pod の実行中インスタンスで以下のコマンドを実行します。
$ oc -n default \ exec -i -t "$(oc -n default get pods -l deploymentconfig=docker-registry -o jsonpath=$'{.items[0].metadata.name}\n')" \ -- /usr/bin/dockerregistry -prune=delete出力サンプル
$ oc exec docker-registry-3-vhndw \ -- /usr/bin/dockerregistry -prune=delete Deleted 13374 blobs Freed up 2.835 GiB of disk spaceレジストリーを読み取り書き込みモードに戻す: プルーニングの終了後は、以下を実行してレジストリーを読み取り書き込みモードに戻すことができます。
$ oc env -n default dc/docker-registry REGISTRY_STORAGE_MAINTENANCE_READONLY-
18.7. cron ジョブのプルーニング
cron ジョブについては、現時点ではテクノロジープレビュー機能です。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。
Red Hat のテクノロジープレビュー機能のサポートについての詳細は、https://access.redhat.com/support/offerings/techpreview/ を参照してください。
cron ジョブは正常なジョブのプルーニングを実行できますが、失敗したジョブを適切に処理しない可能性があります。そのため、クラスター管理者は定期的なジョブのクリーンアップを手動で実行する必要があります。また、信頼できるユーザーの小規模なグループに cron ジョブへのアクセスを制限し、ジョブや Pod が作成され過ぎないように適切なクォータを設定することも推奨されます。
Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.