26.7. OpenShift SDN ネットワークプロバイダーへのロールバック


クラスター管理者は、オフライン 移行方法または 制限付きライブ 移行方法のいずれかを使用して、OVN-Kubernetes ネットワークプラグインから OpenShift SDN ネットワークプラグインにロールバックできます。これは、OVN-Kubernetes ネットワークプラグインへの移行が正常に完了した後にのみ実行できます。

注記
  • オフライン移行方法を使用して OVN-Kubernetes ネットワークプラグインから OpenShift SDN ネットワークプラグインに移行した場合は、オフライン移行ロールバック方法を使用する必要があります。
  • 制限付きライブマイグレーション方式を使用して OVN-Kubernetes ネットワークプラグインから OpenShift SDN ネットワークプラグインに移行した場合は、制限付きライブマイグレーションロールバック方式を使用する必要があります。
注記

OpenShift SDN CNI は、OpenShift Container Platform 4.14 以降非推奨になりました。OpenShift Container Platform 4.15 以降の新規インストールでは、ネットワークプラグインというオプションはなくなりました。今後のリリースでは、OpenShift SDN ネットワークプラグインは削除され、サポートされなくなる予定です。Red Hat は、この機能が削除されるまでバグ修正とサポートを提供しますが、この機能は拡張されなくなります。OpenShift SDN CNI の代わりに、OVN Kubernetes CNI を使用できます。

26.7.1. オフライン移行方法を使用した OpenShift SDN ネットワークプラグインへのロールバック

クラスター管理者は、オフライン移行方法を使用して、OpenShift SDN Container Network Interface (CNI) ネットワークプラグインにロールバックできます。移行中は、クラスター内のすべてのノードを手動で再起動する必要があります。オフライン移行方法では、ダウンタイムが発生し、その間はクラスターにアクセスできなくなります。

重要

ロールバックを開始する前に、OpenShift SDN から OVN-Kubernetes ネットワークプラグインへの移行プロセスが成功するまで待つ必要があります。

OpenShift SDN へのロールバックが必要な場合は、以下の表がプロセスを説明します。

Expand
表26.12 OpenShift SDN へのロールバックの実行
ユーザーが開始する手順移行アクティビティー

MCO を一時停止し、移行が中断されないようにします。

MCO が停止します。

cluster という名前の Network.operator.openshift.io カスタムリソース (CR) の migration フィールドを OpenShiftSDN に設定します。migration フィールドを値に設定する前に null であることを確認します。

CNO
cluster という名前の Network.config.openshift.io CR のステータスを更新します。

networkType フィールドを更新します。

CNO

以下のアクションを実行します。

  • OVN-Kubernetes コントロールプレーン Pod を破棄します。
  • OpenShift SDN コントロールプレーン Pod をデプロイします。
  • Multus オブジェクトを更新して、新しいネットワークプラグインを反映します。

クラスターの各ノードを再起動します。

クラスター
ノードがリブートすると、クラスターは OpenShift-SDN ネットワーク上の Pod に IP アドレスを割り当てます。

クラスターのすべてのノードが再起動した後に MCO を有効にします。

MCO
OpenShift SDN に必要な systemd 設定の更新をロールアウトします。デフォルトでは、MCO はプールごとに一度に 1 台のマシンを更新するため、移行にかかる合計時間はクラスターのサイズに応じて増加します。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin ロールが割り当てられたユーザーを使用してクラスターにアクセスできる。
  • インフラストラクチャーにインストールされたクラスターが OVN-Kubernetes ネットワークプラグインで設定されている。
  • etcd データベースの最新のバックアップが利用可能である。
  • ノードごとに手動の再起動をトリガーできる。
  • クラスターは既知の正常な状態にあり、エラーがない。

手順

  1. Machine Config Operator (MCO) によって管理されるすべてのマシン設定プールを停止します。

    • CLI で次のコマンドを入力して、master 設定プールを停止します。

      $ oc patch MachineConfigPool master --type='merge' --patch \
        '{ "spec": { "paused": true } }'
      Copy to Clipboard Toggle word wrap
    • CLI で次のコマンドを入力して、worker マシン設定プールを停止します。

      $ oc patch MachineConfigPool worker --type='merge' --patch \
        '{ "spec":{ "paused": true } }'
      Copy to Clipboard Toggle word wrap
  2. 移行の準備をするには、CLI で次のコマンドを入力して、移行フィールドを null に設定します。

    $ oc patch Network.operator.openshift.io cluster --type='merge' \
      --patch '{ "spec": { "migration": null } }'
    Copy to Clipboard Toggle word wrap
  3. CLI で次のコマンドを入力して、Network.config.openshift.io オブジェクトの移行ステータスが空であることを確認します。空のコマンド出力は、オブジェクトが移行操作中ではないことを示しています。

    $ oc get Network.config cluster -o jsonpath='{.status.migration}'
    Copy to Clipboard Toggle word wrap
  4. CLI で次のコマンドを入力して、Network.operator.openshift.io オブジェクトにパッチを適用し、ネットワークプラグインを OpenShift SDN に戻します。

    $ oc patch Network.operator.openshift.io cluster --type='merge' \
      --patch '{ "spec": { "migration": { "networkType": "OpenShiftSDN" } } }'
    Copy to Clipboard Toggle word wrap
    重要

    Network.operator.openshift.io オブジェクトでパッチ操作が終了する前に Network.config.openshift.io オブジェクトにパッチを適用した場合、Cluster Network Operator (CNO) は degradation 状態になり、CNO が degradation 状態から回復するまでわずかな遅延が発生します。

  5. CLI で次のコマンドを入力して、Network.config.openshift.io cluster オブジェクトのネットワークプラグインの移行ステータスが OpenShiftSDN であることを確認します。

    $ oc get Network.config cluster -o jsonpath='{.status.migration.networkType}'
    Copy to Clipboard Toggle word wrap
  6. CLI で次のコマンドを入力して、Network.config.openshift.io オブジェクトにパッチを適用し、ネットワークプラグインを OpenShift SDN に戻します。

    $ oc patch Network.config.openshift.io cluster --type='merge' \
      --patch '{ "spec": { "networkType": "OpenShiftSDN" } }'
    Copy to Clipboard Toggle word wrap
  7. オプション: いくつかの OVN-Kubernetes 機能の OpenShift SDN 同等機能への自動移行を無効化します。

    • Egress IP
    • Egress ファイアウォール
    • マルチキャスト

    前述の OpenShift SDN 機能の設定の自動移行を無効にするには、次のキーを指定します。

    $ oc patch Network.operator.openshift.io cluster --type='merge' \
      --patch '{
        "spec": {
          "migration": {
            "networkType": "OpenShiftSDN",
            "features": {
              "egressIP": <bool>,
              "egressFirewall": <bool>,
              "multicast": <bool>
            }
          }
        }
      }'
    Copy to Clipboard Toggle word wrap

    ここでは、以下のようになります。

    bool: 機能の移行を有効にするかどうかを指定します。デフォルトは true です。

  8. オプション: ネットワークインフラストラクチャーの要件を満たすように OpenShift SDN の以下の設定をカスタマイズできます。

    • 最大伝送単位 (MTU)
    • VXLAN ポート

    前述の設定のいずれかまたは両方をカスタマイズするには、CLI で次のコマンドをカスタマイズして入力します。デフォルト値を変更する必要がない場合は、パッチのキーを省略します。

    $ oc patch Network.operator.openshift.io cluster --type=merge \
      --patch '{
        "spec":{
          "defaultNetwork":{
            "openshiftSDNConfig":{
              "mtu":<mtu>,
              "vxlanPort":<port>
        }}}}'
    Copy to Clipboard Toggle word wrap
    mtu
    VXLAN オーバーレイネットワークの MTU。この値は通常は自動的に設定されますが、クラスターにあるノードすべてが同じ MTU を使用しない場合、これを最小のノード MTU 値よりも 50 小さく設定する必要があります。
    port
    VXLAN オーバーレイネットワークの UDP ポート。値が指定されない場合は、デフォルトは 4789 になります。ポートは OVN-Kubernetes で使用される Geneve ポートと同じにすることはできません。Geneve ポートのデフォルト値は 6081 です。

    patch コマンドの例

    $ oc patch Network.operator.openshift.io cluster --type=merge \
      --patch '{
        "spec":{
          "defaultNetwork":{
            "openshiftSDNConfig":{
              "mtu":1200
        }}}}'
    Copy to Clipboard Toggle word wrap

  9. クラスター内の各ノードを再起動します。次のいずれかの方法で、クラスター内のノードを再起動できます。

    • oc rsh コマンドでは、次のような bash スクリプトを使用できます。

      #!/bin/bash
      readarray -t POD_NODES <<< "$(oc get pod -n openshift-machine-config-operator -o wide| grep daemon|awk '{print $1" "$7}')"
      
      for i in "${POD_NODES[@]}"
      do
        read -r POD NODE <<< "$i"
        until oc rsh -n openshift-machine-config-operator "$POD" chroot /rootfs shutdown -r +1
          do
            echo "cannot reboot node $NODE, retry" && sleep 3
          done
      done
      Copy to Clipboard Toggle word wrap
    • ssh コマンドでは、次のような bash スクリプトを使用できます。このスクリプトは、パスワードの入力を求めないように sudo が設定されていることを前提としています。

      #!/bin/bash
      
      for ip in $(oc get nodes  -o jsonpath='{.items[*].status.addresses[?(@.type=="InternalIP")].address}')
      do
         echo "reboot node $ip"
         ssh -o StrictHostKeyChecking=no core@$ip sudo shutdown -r -t 3
      done
      Copy to Clipboard Toggle word wrap
  10. Multus デーモンセットのロールアウトが完了するまで待機します。次のコマンドを実行して、ロールアウトのステータスを確認します。

    $ oc -n openshift-multus rollout status daemonset/multus
    Copy to Clipboard Toggle word wrap

    Multus Pod の名前の形式は multus-<xxxxx> です。ここで、<xxxxx> は文字のランダムなシーケンスになります。Pod が再起動するまでにしばらく時間がかかる可能性があります。

    出力例

    Waiting for daemon set "multus" rollout to finish: 1 out of 6 new pods have been updated...
    ...
    Waiting for daemon set "multus" rollout to finish: 5 of 6 updated pods are available...
    daemon set "multus" successfully rolled out
    Copy to Clipboard Toggle word wrap

  11. クラスター内のノードが再起動し、multus Pod がロールアウトされたら、次のコマンドを実行してすべてのマシン設定プールを起動します。

    • マスター設定プールを開始します。

      $ oc patch MachineConfigPool master --type='merge' --patch \
        '{ "spec": { "paused": false } }'
      Copy to Clipboard Toggle word wrap
    • ワーカー設定プールを開始します。

      $ oc patch MachineConfigPool worker --type='merge' --patch \
        '{ "spec": { "paused": false } }'
      Copy to Clipboard Toggle word wrap

    MCO が各設定プールのマシンを更新すると、各ノードを再起動します。

    デフォルトで、MCO は一度にプールごとに単一のマシンを更新するため、移行が完了するまでに必要な時間がクラスターのサイズと共に増加します。

  12. ホスト上の新規マシン設定のステータスを確認します。

    1. マシン設定の状態と適用されたマシン設定の名前をリスト表示するには、CLI で以下のコマンドを入力します。

      $ oc describe node | egrep "hostname|machineconfig"
      Copy to Clipboard Toggle word wrap

      出力例

      kubernetes.io/hostname=master-0
      machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b
      machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b
      machineconfiguration.openshift.io/reason:
      machineconfiguration.openshift.io/state: Done
      Copy to Clipboard Toggle word wrap

      以下のステートメントが true であることを確認します。

      • machineconfiguration.openshift.io/state フィールドの値は Done です。
      • machineconfiguration.openshift.io/currentConfig フィールドの値は、machineconfiguration.openshift.io/desiredConfig フィールドの値と等しくなります。
    2. マシン設定が正しいことを確認するには、CLI で以下のコマンドを入力します。

      $ oc get machineconfig <config_name> -o yaml
      Copy to Clipboard Toggle word wrap

      ここで、<config_name>machineconfiguration.openshift.io/currentConfig フィールドのマシン設定の名前になります。

  13. 移行が正常に完了したことを確認します。

    1. ネットワークプラグインが OpenShift SDN であることを確認するには、CLI で次のコマンドを入力します。status.networkType の値は OpenShiftSDN である必要があります。

      $ oc get Network.config/cluster -o jsonpath='{.status.networkType}{"\n"}'
      Copy to Clipboard Toggle word wrap
    2. クラスターノードが Ready 状態にあることを確認するには、CLI で以下のコマンドを入力します。

      $ oc get nodes
      Copy to Clipboard Toggle word wrap
    3. ノードが NotReady 状態のままになっている場合、マシン設定デーモン Pod のログを調べ、エラーを解決します。

      1. Pod をリスト表示するには、CLI で次のコマンドを入力します。

        $ oc get pod -n openshift-machine-config-operator
        Copy to Clipboard Toggle word wrap

        出力例

        NAME                                         READY   STATUS    RESTARTS   AGE
        machine-config-controller-75f756f89d-sjp8b   1/1     Running   0          37m
        machine-config-daemon-5cf4b                  2/2     Running   0          43h
        machine-config-daemon-7wzcd                  2/2     Running   0          43h
        machine-config-daemon-fc946                  2/2     Running   0          43h
        machine-config-daemon-g2v28                  2/2     Running   0          43h
        machine-config-daemon-gcl4f                  2/2     Running   0          43h
        machine-config-daemon-l5tnv                  2/2     Running   0          43h
        machine-config-operator-79d9c55d5-hth92      1/1     Running   0          37m
        machine-config-server-bsc8h                  1/1     Running   0          43h
        machine-config-server-hklrm                  1/1     Running   0          43h
        machine-config-server-k9rtx                  1/1     Running   0          43h
        Copy to Clipboard Toggle word wrap

        設定デーモン Pod の名前は以下の形式になります。machine-config-daemon-<seq><seq> 値は、ランダムな 5 文字の英数字シーケンスになります。

      2. 前の出力に示されている各マシン設定デーモン Pod の Pod ログを表示するには、CLI で次のコマンドを入力します。

        $ oc logs <pod> -n openshift-machine-config-operator
        Copy to Clipboard Toggle word wrap

        ここで、pod はマシン設定デーモン Pod の名前になります。

      3. 直前のコマンドの出力で示されるログ内のエラーを解決します。
    4. Pod がエラー状態ではないことを確認するには、CLI で次のコマンドを入力します。

      $ oc get pods --all-namespaces -o wide --sort-by='{.spec.nodeName}'
      Copy to Clipboard Toggle word wrap

      ノードの Pod がエラー状態にある場合は、そのノードを再起動します。

  14. 以下の手順は、移行に成功し、クラスターの状態が正常である場合にのみ実行します。

    1. Cluster Network Operator 設定オブジェクトから移行設定を削除するには、CLI で次のコマンドを入力します。

      $ oc patch Network.operator.openshift.io cluster --type='merge' \
        --patch '{ "spec": { "migration": null } }'
      Copy to Clipboard Toggle word wrap
    2. OVN-Kubernetes 設定を削除するには、CLI で次のコマンドを入力します。

      $ oc patch Network.operator.openshift.io cluster --type='merge' \
        --patch '{ "spec": { "defaultNetwork": { "ovnKubernetesConfig":null } } }'
      Copy to Clipboard Toggle word wrap
    3. OVN-Kubernetes ネットワークプロバイダー namespace を削除するには、CLI で次のコマンドを入力します。

      $ oc delete namespace openshift-ovn-kubernetes
      Copy to Clipboard Toggle word wrap

26.7.2. Ansible Playbook を使用した OpenShift SDN ネットワークプラグインへのロールバック

クラスター管理者は、network.offline_migration_sdn_to_ovnk Ansible コレクションの playbooks/playbook-rollback.yml を使用して、OVN-Kubernetes プラグインから OpenShift SDN Container Network Interface (CNI)ネットワークプラグインにロールバックできます。

前提条件

  • python3 パッケージ(最小バージョン 3.10)をインストールしている。
  • jmespath パッケージおよび jq パッケージをインストールしました。
  • Red Hat Hybrid Cloud Console にログインし、Ansible Automation Platform Web コンソールを開いている。
  • すべてのクラウドプラットフォーム上のすべてのノードに対してポート 6081 上の User Datagram Protocol (UDP) パケットを許可するセキュリティーグループルールを作成している。このタスクを実行しないと、クラスターが Pod のスケジュールに失敗する可能性があります。

手順

  1. ansible-core パッケージをインストールします(最小バージョン 2.15)。以下のコマンド例は、Red Hat Enterprise Linux (RHEL)に ansible-core パッケージをインストールする方法を示しています。

    $ sudo dnf install -y ansible-core
    Copy to Clipboard Toggle word wrap
  2. ansible.cfg ファイルを作成し、以下の例のような情報をファイルに追加します。ansible-galaxy コマンドおよび Playbook が実行されるのと同じディレクトリーにファイルが存在することを確認します。

    $ cat << EOF >> ansible.cfg
    [galaxy]
    server_list = automation_hub, validated
    
    [galaxy_server.automation_hub]
    url=https://console.redhat.com/api/automation-hub/content/published/
    auth_url=https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token
    token=
    
    #[galaxy_server.release_galaxy]
    #url=https://galaxy.ansible.com/
    
    [galaxy_server.validated]
    url=https://console.redhat.com/api/automation-hub/content/validated/
    auth_url=https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token
    token=
    EOF
    Copy to Clipboard Toggle word wrap
  3. Ansible Automation Platform Web コンソールから、Connect to Hub ページに移動し、次の手順を実行します。

    1. ページの Offline token セクションで、Load token ボタンをクリックします。
    2. トークンがロードされたら、Copy to clipboard アイコンをクリックします。
    3. ansible.cfg ファイルを開き、API トークンを token= パラメーターに貼り付けます。API トークンは、ansible.cfg ファイルで指定されたサーバー URL に対して認証するために必要です。
  4. 以下の ansible-galaxy コマンドを入力して、network.offline_migration_sdn_to_ovnk Ansible コレクションをインストールします。

    $ ansible-galaxy collection install network.offline_migration_sdn_to_ovnk
    Copy to Clipboard Toggle word wrap
  5. network.offline_migration_sdn_to_ovnk Ansible コレクションがシステムにインストールされていることを確認します。

    $ ansible-galaxy collection list | grep network.offline_migration_sdn_to_ovnk
    Copy to Clipboard Toggle word wrap

    出力例

    network.offline_migration_sdn_to_ovnk   1.0.2
    Copy to Clipboard Toggle word wrap

    network.offline_migration_sdn_to_ovnk Ansible コレクションは、~/.ansible/collections/ansible_collections/network/offline_migration_sdn_to_ovnk/ のデフォルトパスに保存されます。

  6. playbooks/playbook-migration.yml ファイルでロールバック機能を設定します。

    # ...
        rollback_disable_auto_migration: true
        rollback_egress_ip: false
        rollback_egress_firewall: false
        rollback_multicast: false
        rollback_mtu: 1400
        rollback_vxlanPort: 4790
    # ...
    Copy to Clipboard Toggle word wrap
    rollback_disable_auto_migration
    OpenShift SDN CNI プラグインへの OVN-Kubernetes プラグイン機能の自動移行を無効にします。機能の自動移行を無効にする場合は、rollback_egress_ip パラメーター、rollback_egress_firewall パラメーター、および rollback_multicast パラメーターも false に設定する必要があります。機能の自動移行を有効にする必要がある場合は、パラメーターを false に設定します。
    rollback_mtu
    移行プロセス後にクラスターネットワークに特定の最大伝送単位(MTU)を設定するオプションのパラメーター。
    rollback_vxlanPort
    OpenShift SDN CNI プラグインが使用する VXLAN (仮想拡張 LAN)ポートを設定するオプションのパラメーター。このパラメーターのデフォルト値は 4790 です。
  7. playbooks/playbook-rollback.yml ファイルを実行するには、以下のコマンドを入力します。

    $ ansible-playbook -v playbooks/playbook-rollback.yml
    Copy to Clipboard Toggle word wrap

クラスター管理者は、クラスターを OpenShift SDN Container Network Interface (CNI) ネットワークプラグインにロールバックできます。この方法による移行中は、ノードは自動的に再起動され、クラスターへのサービスは中断されません。

重要

ロールバックを開始する前に、OpenShift SDN から OVN-Kubernetes ネットワークプラグインへの移行プロセスが成功するまで待つ必要があります。

OpenShift SDN へのロールバックが必要な場合は、以下の表がプロセスを説明します。

Expand
表26.13 OpenShift SDN へのロールバックの実行
ユーザーが開始する手順移行アクティビティー

networkTypeOVNKubernetes から OpenShiftSDN に変更して、クラスターレベルのネットワーク設定にパッチを適用します。

Cluster Network Operator (CNO)

以下のアクションを実行します。

  • network.operator カスタムリソース (CR) の移行関連フィールドを設定し、Machine Config Operator (MCO) によってルーティング可能な MTU がすべてのノードに適用されるまで待機します。
  • network.operator CR にパッチを適用して、OpenShiftSDN の移行モードを Live に設定し、移行モードで OpenShiftSDN ネットワークプラグインをデプロイします。
  • ハイブリッドオーバーレイを有効にして OVN-Kubernetes をデプロイします。
  • 両方の CNI プラグインがデプロイされるのを待機し、network.config CR のステータスの条件を更新します。
  • MCO をトリガーして、新しいマシン設定を各マシン設定プールに適用します。これには、ノードの遮断、ドレイン、および再起動が含まれます。
  • network.operator CR から移行関連のフィールドを削除し、OpenShift SDN リソースの削除や、必要な設定での OVN-Kubernetes の通常モードでの再デプロイなどのクリーンアップアクションを実行します。
  • OpenShiftSDN の再デプロイメントを待機し、移行の完了を示すために network.config CR のステータス条件を更新します。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin ロールが割り当てられたユーザーを使用してクラスターにアクセスできる。
  • インフラストラクチャーにインストールされたクラスターが OVN-Kubernetes ネットワークプラグインで設定されている。
  • etcd データベースの最新のバックアップが利用可能である。
  • ノードごとに手動の再起動をトリガーできる。
  • クラスターは既知の正常な状態にあり、エラーがない。

手順

  1. OpenShift SDN へのロールバックを開始するには、次のコマンドを入力します。

    $ oc patch Network.config.openshift.io cluster --type='merge' --patch '{"metadata":{"annotations":{"network.openshift.io/network-type-migration":""}},"spec":{"networkType":"OpenShiftSDN"}}'
    Copy to Clipboard Toggle word wrap
  2. 移行の進行状況を確認するには、次のコマンドを入力します。

    $ watch -n1 'oc get network.config/cluster -o json | jq ".status.conditions[]|\"\\(.type) \\(.status) \\(.reason) \\(.message)\""  -r | column --table --table-columns NAME,STATUS,REASON,MESSAGE --table-columns-limit 4; echo; oc get mcp -o wide; echo; oc get node -o "custom-columns=NAME:metadata.name,STATE:metadata.annotations.machineconfiguration\\.openshift\\.io/state,DESIRED:metadata.annotations.machineconfiguration\\.openshift\\.io/desiredConfig,CURRENT:metadata.annotations.machineconfiguration\\.openshift\\.io/currentConfig,REASON:metadata.annotations.machineconfiguration\\.openshift\\.io/reason"'
    Copy to Clipboard Toggle word wrap

    このコマンドは、次の情報を毎秒出力します。

    • network.config.openshift.io/cluster オブジェクトのステータスの条件。移行の進捗を報告します。
    • machine-config-Operator リソースに関するさまざまなノードのステータス。これには、アップグレード中かアップグレード済みか、および現在の設定と必要な設定が含まれます。
  3. 以下の手順は、移行に成功し、クラスターの状態が正常である場合にのみ実行します。

    1. 次のコマンドを入力して、network.config カスタムリソースから network.openshift.io/network-type-migration= アノテーションを削除します。

      $ oc annotate network.config cluster network.openshift.io/network-type-migration-
      Copy to Clipboard Toggle word wrap
    2. 次のコマンドを入力して、OVN-Kubernetes ネットワークプロバイダーの namespace を削除します。

      $ oc delete namespace openshift-ovn-kubernetes
      Copy to Clipboard Toggle word wrap
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat