1.9. ホストインベントリーの概要


ホストインベントリー管理とオンプレミスクラスターのインストールは、マルチクラスターエンジン Operator の Central Infrastructure Management 機能を使用して利用できます。

Central infrastructure management 機能は、ライフサイクル中のベアメタルホストの管理に重点を置いた、マルチクラスターエンジン Operator の Red Hat OpenShift Container Platform インストールエクスペリエンスです。

Assisted Installer は、エージェントを使用してターゲットホストに事前インストールされた検証を実行し、中央サービスを使用してインストールの進行状況を評価および追跡する、OpenShift Container Platform のインストール方法です。

Red Hat OpenShift のインフラストラクチャー Operator は、Assisted Installer サービスを実行するワークロードを管理およびインストールするマルチクラスターエンジン Operator コンポーネントです。

コンソールを使用してホストインベントリーを作成できます。これは、オンプレミスの OpenShift Container Platform クラスターの作成に使用できるベアメタルまたは仮想マシンのプールです。これらのクラスターには、コントロールプレーン専用のマシンを備えたスタンドアロンと、コントロールプレーンがハブクラスター上の Pod として実行される Hosted Control Plane があります。

スタンドアロンクラスターは、コンソール、API、またはゼロタッチプロビジョニング (ZTP) を使用する GitOps を使用してインストールできます。詳細は、Red Hat OpenShift Container Platform ドキュメントの 非接続環境での GitOps ZTP のインストール を参照してください。

マシンは、Discovery Image で起動した後、ホストインベントリーに参加します。Discovery Image は、以下を含む Red Hat CoreOS ライブイメージです。

  • 検出、検証、およびインストールタスクを実行するエージェント。
  • ハブクラスター上のサービスにアクセスするために必要な設定 (該当する場合、エンドポイント、トークン、静的ネットワーク設定など)。

各インフラストラクチャー環境に Discovery イメージを 1 つ用意します。この環境は、共通のプロパティーセットを共有するホストセットです。InfraEnv カスタムリソース定義は、このインフラストラクチャー環境と関連する Discovery Image を表します。InfraEnv カスタムリソースの osImageVersion フィールドを設定して、Discovery イメージに使用される Red Hat Core OS バージョンを指定できます。値を指定しない場合は、最新の Red Hat Core OS バージョンが使用されます。

ホストが起動し、エージェントがサービスに接続すると、サービスはそのホストを表すハブクラスター上に新しい Agent カスタムリソースを作成します。Agent リソースはホストインベントリーを設定します。

後でホストを OpenShift ノードとしてインベントリーにインストールできます。エージェントは、必要な設定とともにオペレーティングシステムをディスクに書き込み、ホストを再起動します。

注記: Red Hat Advanced Cluster Management 2.9 以降および Central infrastructure management は、AgentClusterInstall を使用して Nutanix プラットフォームをサポートしますが、これには Nutanix 仮想マシンを作成することによる追加の設定が必要です。詳細は、Assisted Installer ドキュメントの オプション: Nutanix へのインストール を参照してください。

ホストインベントリーと Central Infrastructure Management の詳細は、以下を参照してください。

1.9.1. Central Infrastructure Management サービスの有効化

Central Infrastructure Management サービスはマルチクラスターエンジン Operator とともに提供され、OpenShift Container Platform クラスターをデプロイします。ハブクラスターで MultiClusterHub Operator を有効にすると、Central infrastructure management サービスが自動的にデプロイされますが、サービスは手動で有効にする必要があります。

1.9.1.1. 前提条件

Central Infrastructure Management サービスを有効にする前に、次の前提条件を確認してください。

  • サポートされている OpenShift Container Platform バージョンと、サポートされている Red Hat Advanced Cluster Management for Kubernetes バージョンにハブクラスターがデプロイされている。
  • クラスターを作成するために必要なイメージを取得するためのハブクラスターへのインターネットアクセス (接続済み)、あるいはインターネットへの接続がある内部またはミラーレジストリーへの接続 (非接続) がある。
  • ベアメタルプロビジョニングに必要なポートが開いている。OpenShift Container Platform ドキュメントの 必須ポートが開いていることを確認する を参照してください。
  • ベアメタルホストのカスタムリソース定義がある。
  • OpenShift Container Platform プルシークレット がある。詳細は、イメージプルシークレットの使用 を参照してください。
  • 設定済みのデフォルトのストレージクラスがある。
  • 非接続環境の場合のみ、OpenShift Container Platform ドキュメントの ネットワーク遠端のクラスター に関する手順を完了してください。

以下のセクションを参照してください。

1.9.1.2. ベアメタルホストのカスタムリソース定義の作成

Central Infrastructure Management サービスを有効にする前に、ベアメタルホストのカスタムリソース定義が必要です。

  1. 次のコマンドを実行して、ベアメタルホストのカスタムリソース定義がすでに存在するかどうかを確認します。

    oc get crd baremetalhosts.metal3.io
    • ベアメタルホストのカスタムリソース定義がある場合、出力にはリソースが作成された日付が表示されます。
    • リソースがない場合は、次のようなエラーが表示されます。
    Error from server (NotFound): customresourcedefinitions.apiextensions.k8s.io "baremetalhosts.metal3.io" not found
  2. ベアメタルホストのカスタムリソース定義がない場合は、metal3.io_baremetalhosts.yaml ファイルをダウンロードし、次のコマンドを実行することでコンテンツを適用して、リソースを作成します。

    oc apply -f

1.9.1.3. Provisioning リソースの作成または変更

Central Infrastructure Management サービスを有効にする前に、Provisioning リソースが必要です。

  1. 次のコマンドを実行して、Provisioning リソースがあるかどうかを確認します。

    oc get provisioning
    • すでに Provisioning リソースがある場合は、Provisioning リソースの変更 に進みます。
    • Provisioning リソースがない場合は、No resources found というエラーが表示されます。Provisioning リソースの作成 に進みます。
1.9.1.3.1. Provisioning リソースの変更

すでに Provisioning リソースがある場合は、ハブクラスターが次のいずれかのプラットフォームにインストールされている場合、リソースを変更する必要があります。

  • ベアメタル
  • Red Hat OpenStack Platform
  • VMware vSphere
  • ユーザープロビジョニングインフラストラクチャー (UPI) 方式とプラットフォームは None です

ハブクラスターが別のプラットフォームにインストールされている場合は、非接続環境での Central Infrastructure Management の有効化 または 接続環境での Central Infrastructure Management の有効化 に進みます。

  1. provisioning リソースを変更し、以下のコマンドを実行してベアメタル Operator がすべての namespace を監視できるようにします。

    oc patch provisioning provisioning-configuration --type merge -p '{"spec":{"watchAllNamespaces": true }}'
1.9.1.3.2. Provisioning リソースの作成

Provisioning リソースがない場合は、次の手順を実行します。

  1. 次の YAML コンテンツを追加して、Provisioning リソースを作成します。

    apiVersion: metal3.io/v1alpha1
    kind: Provisioning
    metadata:
      name: provisioning-configuration
    spec:
      provisioningNetwork: "Disabled"
      watchAllNamespaces: true
  2. 次のコマンドを実行してコンテンツを適用します。

    oc apply -f

1.9.1.4. 非接続環境での Central Infrastructure Management の有効化

非接続環境で Central Infrastructure Management を有効にするには、以下の手順を実行します。

  1. インフラストラクチャー Operator と同じ namespace に ConfigMap を作成し、ミラーレジストリーの ca-bundle.crt および registries.conf の値を指定します。ファイルの ConfigMap は次の例のようになります。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: <mirror-config>
      namespace: multicluster-engine
      labels:
        app: assisted-service
    data:
      ca-bundle.crt: |
        <certificate-content>
      registries.conf: |
        unqualified-search-registries = ["registry.access.redhat.com", "docker.io"]
        [[registry]]
           prefix = ""
           location = "registry.redhat.io/multicluster-engine"
           mirror-by-digest-only = true
           [[registry.mirror]]
           location = "mirror.registry.com:5000/multicluster-engine"

    注記: リリースイメージはダイジェストを使用して指定されるため、mirror-by-digest-onlytrue に設定する必要があります。

    unqualified-search-registries のリストにあるレジストリーは、PUBLIC_CONTAINER_REGISTRIES 環境変数の認証無視リストに自動的に追加されます。マネージドクラスターのプルシークレットの検証時に、指定されたレジストリーは認証を必要としません。

  2. すべての osImage リクエストで送信するヘッダーとクエリーパラメーターを表すキーペアを書き込みます。両方のパラメーターが必要ない場合は、ヘッダーのみ、またはクエリーパラメーターのみのキーペアを作成します。

重要: ヘッダーとクエリーパラメーターは、HTTPS を使用する場合にのみ暗号化されます。セキュリティーの問題を避けるために、必ず HTTPS を使用してください。

  1. headers という名前のファイルを作成し、次の例のような内容を追加します。

    {
      "Authorization": "Basic xyz"
    }
  2. query_params という名前のファイルを作成し、次の例のような内容を追加します。

    {
      "api_key": "myexampleapikey",
    }
    1. 次のコマンドを実行して、作成したパラメーターファイルからシークレットを作成します。パラメーターファイルを 1 つだけ作成した場合は、作成しなかったファイルの引数を削除します。

      oc create secret generic -n multicluster-engine os-images-http-auth --from-file=./query_params --from-file=./headers
    2. 自己署名証明書またはサードパーティー CA 証明書とともに HTTPS osImage を使用する場合は、証明書を image-service-additional-ca ConfigMap に追加します。証明書を作成するには、次のコマンドを実行します。

      oc -n multicluster-engine create configmap image-service-additional-ca --from-file=tls.crt
    3. 次の YAML コンテンツを agent_service_config.yaml ファイルに保存して、AgentServiceConfig カスタムリソースを作成します。

      apiVersion: agent-install.openshift.io/v1beta1
      kind: AgentServiceConfig
      metadata:
       name: agent
      spec:
        databaseStorage:
          accessModes:
          - ReadWriteOnce
          resources:
            requests:
              storage: <db_volume_size>
        filesystemStorage:
          accessModes:
          - ReadWriteOnce
          resources:
            requests:
              storage: <fs_volume_size>
        mirrorRegistryRef:
          name: <mirror_config> 1
        unauthenticatedRegistries:
          - <unauthenticated_registry> 2
        imageStorage:
          accessModes:
          - ReadWriteOnce
          resources:
            requests:
              storage: <img_volume_size> 3
        OSImageAdditionalParamsRef:
      	    name: os-images-http-auth
        OSImageCACertRef:
          name: image-service-additional-ca
        osImages:
          - openshiftVersion: "<ocp_version>" 4
            version: "<ocp_release_version>" 5
            url: "<iso_url>" 6
            cpuArchitecture: "x86_64"
    1
    mirror_config は、ミラーレジストリー設定の詳細が含まれる ConfigMap の名前に置き換えます。
    2
    認証を必要としないミラーレジストリーを使用している場合は、オプションの unauthenticated_registry パラメーターを含めます。このリストのエントリーは検証されず、プルシークレットにエントリーを含める必要はありません。
    3
    img_volume_sizeimageStorage フィールドのボリュームのサイズに置き換えます (例: オペレーティングシステムイメージごとに 10Gi)。最小値は 10Gi ですが、推奨される値は 50Gi 以上です。この値は、クラスターのイメージに割り当てられるストレージの量を指定します。実行中の Red Hat Enterprise Linux CoreOS の各インスタンスに 1 GB のイメージストレージを許可する必要があります。Red Hat Enterprise Linux CoreOS のクラスターおよびインスタンスが多数ある場合は、より高い値を使用する必要がある場合があります。
    4
    ocp_version は、インストールする OpenShift Container Platform バージョン (例: 4.14) に置き換えます。
    5
    ocp_release_version は、特定のインストールバージョン (例: 49.83.2021032516400) に置き換えます。
    6
    iso_url は、ISO URL に置き換えます (例: https://mirror.openshift.com/pub/openshift-v4/x86_64/dependencies/rhcos/4.13/4.13.3/rhcos-4.13.3-x86_64-live.x86_64.iso)。他の値は rhoc で確認できます。

自己署名証明書またはサードパーティー CA 証明書を持つ HTTPS osImage を使用している場合は、OSImageCACertRef 仕様でその証明書を参照してください。

重要: 遅延バインディング機能を使用しており、AgentServiceConfig カスタムリソースの spec.osImages リリースがバージョン 4.13 以降である場合、クラスターの作成時に使用する OpenShift Container Platform リリースイメージが同じバージョンである必要があります。バージョン 4.13 以降の Red Hat Enterprise Linux CoreOS イメージは、以前のイメージと互換性がありません。

assisted-service デプロイメントおよび assisted-image-service デプロイメントをチェックし、その Pod が準備ができており実行中であることを確認することで、Central infrastructure management サービスが正常であることを確認できます。

1.9.1.5. 接続環境での Central Infrastructure Management の有効化

接続環境で Central infrastructure management を有効にするには、以下の YAML コンテンツを agent_service_config.yaml ファイルに保存して、AgentServiceConfig カスタムリソースを作成します。

apiVersion: agent-install.openshift.io/v1beta1
kind: AgentServiceConfig
metadata:
 name: agent
spec:
  databaseStorage:
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: <db_volume_size> 1
  filesystemStorage:
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: <fs_volume_size> 2
  imageStorage:
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: <img_volume_size> 3
1
db_volume_sizedatabaseStorage フィールドのボリュームサイズに置き換えます (例: 10Gi )。この値は、クラスターのデータベーステーブルやデータベースビューなどのファイルを格納するために割り当てられるストレージの量を指定します。必要な最小値は 1Gi です。クラスターが多い場合は、より高い値を使用する必要がある場合があります。
2
fs_volume_sizefilesystemStorage フィールドのボリュームのサイズに置き換えます (例: クラスターごとに 200M、サポートされる OpenShift Container Platform バージョンごとに 2-3Gi)。必要な最小値は 1Gi ですが、推奨される値は 100Gi 以上です。この値は、クラスターのログ、マニフェスト、および kubeconfig ファイルを保存するために割り当てられるストレージのサイズを指定します。クラスターが多い場合は、より高い値を使用する必要がある場合があります。
3
img_volume_sizeimageStorage フィールドのボリュームのサイズに置き換えます (例: オペレーティングシステムイメージごとに 10Gi)。最小値は 10Gi ですが、推奨される値は 50Gi 以上です。この値は、クラスターのイメージに割り当てられるストレージの量を指定します。実行中の Red Hat Enterprise Linux CoreOS の各インスタンスに 1 GB のイメージストレージを許可する必要があります。Red Hat Enterprise Linux CoreOS のクラスターおよびインスタンスが多数ある場合は、より高い値を使用する必要がある場合があります。

Central Infrastructure Management サービスが設定されている。assisted-serviceassisted-image-service デプロイメントをチェックして、Pod の準備ができ、実行されていることを確認して、正常性を検証できます。

1.9.1.6. Assisted Installer を使用して FIPS 対応クラスターをインストールする

FIPS モードの OpenShift Container Platform クラスターバージョン 4.15 以前をインストールする場合は、AgentServiceConfig リソースで、インストーラーが Red Hat Enterprise Linux (RHEL) バージョン 8 を実行するように指定する必要があります。

必要なアクセス: AgentServiceConfig および AgentClusterInstall リソースを編集するためのアクセス権が必要です。

AgentServiceConfig リソースを更新するには、次の手順を実行します。

  1. 次のコマンドを使用して、マネージドクラスターにログインします。

    oc login
  2. AgentServiceConfig リソースに agent-install.openshift.io/service-image-base: el8 アノテーションを追加します。

    AgentServiceConfig リソースは、次の YAML のようになります。

    apiVersion: agent-install.openshift.io/v1beta1
    kind: AgentServiceConfig
    metadata:
      annotations:
        agent-install.openshift.io/service-image-base: el8
    ...

1.9.1.7. 関連情報

1.9.2. Amazon Web Services での Central Infrastructure Management の有効化

Amazon Web Services でハブクラスターを実行していて、Central Infrastructure Management サービスを有効にする場合は、Central Infrastructure Management を central infrastructure management の有効化 後に、次の手順を実行します。

  1. ハブクラスターにログインしていることを確認し、次のコマンドを実行して、assisted-image-service で設定された一意のドメインを見つけます。

    oc get routes --all-namespaces | grep assisted-image-service

    ドメインは assisted-image-service-multicluster-engine.apps.<yourdomain>.com のようになります。

  2. ハブクラスターにログインしていることを確認し、NLB type パラメーターを使用して一意のドメインで新しい IngressController を作成します。以下の例を参照してください。

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: ingress-controller-with-nlb
      namespace: openshift-ingress-operator
    spec:
      domain: nlb-apps.<domain>.com
      routeSelector:
          matchLabels:
            router-type: nlb
      endpointPublishingStrategy:
        type: LoadBalancerService
        loadBalancer:
          scope: External
          providerParameters:
            type: AWS
            aws:
              type: NLB
  3. nlb-apps.<domain>.com<domain><yourdomain> に置き換えて、IngressControllerdomain パラメーターに <yourdomain> を追加します。
  4. 次のコマンドを実行して、新しい IngressController を適用します。

    oc apply -f ingresscontroller.yaml
  5. 次の手順を実行して、新しい IngressControllerspec.domain パラメーターの値が既存の IngressController と競合していないことを確認します。

    1. 次のコマンドを実行して、すべての IngressController を一覧表示します。

      oc get ingresscontroller -n openshift-ingress-operator
    2. 先ほど作成した ingress-controller-with-nlb を除く各 IngressControllers で次のコマンドを実行します。

      oc edit ingresscontroller <name> -n openshift-ingress-operator

      spec.domain レポートが見つからない場合は、nlb-apps.<domain>.com を除く、クラスターで公開されているすべてのルートに一致するデフォルトドメインを追加します。

      spec.domain レポートが提供されている場合は、指定された範囲から nlb-apps.<domain>.com ルートが除外されていることを確認してください。

  6. 次のコマンドを実行して、assisted-image-service ルートを編集し、nlb-apps の場所を使用します。

    oc edit route assisted-image-service -n <namespace>

    デフォルトの namespace は、マルチクラスターエンジン Operator をインストールした場所です。

  7. 次の行を assisted-image-service ルートに追加します。

    metadata:
      labels:
        router-type: nlb
      name: assisted-image-service
  8. assisted-image-service ルートで、spec.host の URL 値を見つけます。URL は次の例のようになります。

    assisted-image-service-multicluster-engine.apps.<yourdomain>.com
  9. URL 内の appsnlb-apps に置き換えて、新しい IngressController で設定されたドメインと一致させます。
  10. Central Infrastructure Management サービスが Amazon Web Services で有効になっていることを確認するには、次のコマンドを実行して Pod が正常であることを確認します。

    oc get pods -n multicluster-engine | grep assist
  11. 新しいホストインベントリーを作成し、ダウンロード URL が新しい nlb-apps URL を使用していることを確認します。

1.9.3. コンソールを使用したホストインベントリーの作成

ホストインベントリー (インフラストラクチャー環境) を作成して、OpenShift Container Platform クラスターをインストールできる物理マシンまたは仮想マシンを検出できます。

1.9.3.1. 前提条件

  • Central Infrastructure Management サービスを有効にする。詳細は、Central Infrastructure Management サービスの有効化 を参照してください。

1.9.3.2. ホストインベントリーの作成

コンソールを使用してホストインベントリーを作成するには、次の手順を実行します。

  1. コンソールから、Infrastructure > Host inventory に移動して、Create infrastructure environment をクリックします。
  2. 次の情報をホストインベントリー設定に追加します。

    • 名前: インフラストラクチャー環境の一意の名前。コンソールを使用してインフラストラクチャー環境を作成すると、選択した名前で InfraEnv リソースの新しい namespace も作成されます。コマンドラインインターフェイスを使用して InfraEnv リソースを作成し、コンソールでリソースを監視する場合は、namespace と InfraEnv に同じ名前を使用します。
    • ネットワークタイプ: インフラストラクチャー環境に追加するホストが DHCP または静的ネットワークを使用するかどうかを指定します。静的ネットワーク設定には、追加の手順が必要です。
    • 場所: ホストの地理的な場所を指定します。地理的なロケーションを使用して、ホストが配置されているデータセンターを定義できます。
    • ラベル: このインフラストラクチャー環境で検出されたホストにラベルを追加できるオプションのフィールド。指定した場所はラベルのリストに自動的に追加されます。
    • インフラストラクチャープロバイダーの認証情報: インフラストラクチャープロバイダーの認証情報を選択すると、プルシークレットおよび SSH 公開鍵フィールドに認証情報内の情報が自動的に入力されます。詳細は、オンプレミス環境の認証情報の作成 を参照してください。
    • プルシークレット: OpenShift Container Platform リソースへのアクセスを可能にする OpenShift Container Platform プルシークレット。インフラストラクチャープロバイダーの認証情報を選択した場合、このフィールドには自動的に入力されます。
    • SSH 公開鍵: ホストとのセキュアな通信を可能にする SSH キー。これを使用してホストに接続し、トラブルシューティングを行うことができます。クラスターをインストールした後は、SSH 鍵を使用してホストに接続できなくなります。通常、鍵は id_rsa.pub ファイルにあります。デフォルトのファイルパスは ~/.ssh/id_rsa.pub です。SSH 公開鍵の値を含むインフラストラクチャープロバイダーの認証情報を選択した場合、このフィールドには自動的に入力されます。
    • ホストのプロキシー設定を有効にする場合は、有効にする設定を選択し、次の情報を入力します。

      • HTTP プロキシー URL: HTTP リクエストのプロキシーの URL。
      • HTTPS プロキシー URL: HTTP リクエストのプロキシーの URL。URL は HTTP で始まる必要があります。HTTPS はサポートされていません。値を指定しない場合、デフォルトで HTTP 接続と HTTPS 接続の両方に HTTP プロキシー URL が使用されます。
      • プロキシーなしドメイン: プロキシーを使用しないドメインのコンマ区切りのリスト。ドメイン名をピリオド (.) で開始し、そのドメインにあるすべてのサブドメインを組み込みます。アステリスク (*) を追加し、すべての宛先のプロキシーをバイパスします。
    • 必要に応じて、NTP プールまたはサーバーの IP 名またはドメイン名のコンマ区切りリストを指定して、独自のネットワークタイムプロトコル (NTP) ソースを追加します。

コンソールでは使用できない詳細な設定オプションが必要な場合は、コマンドラインインターフェイスを使用したホストインベントリーの作成 に進みます。

高度な設定オプションが必要ない場合は、必要に応じて静的ネットワークの設定を続行し、インフラストラクチャー環境へのホストの追加を開始できます。

1.9.3.3. ホストインベントリーへのアクセス

ホストインベントリーにアクセスするには、コンソールで Infrastructure > Host inventory を選択します。一覧からインフラストラクチャー環境を選択し、詳細とホストを表示します。

1.9.3.4. 関連情報

ベアメタル上で Hosted Control Plane を設定するプロセスの一環としてホストインベントリーを作成した場合は、次の手順を実行します。

1.9.4. コマンドラインインターフェイスを使用したホストインベントリーの作成

ホストインベントリー (インフラストラクチャー環境) を作成して、OpenShift Container Platform クラスターをインストールできる物理マシンまたは仮想マシンを検出できます。自動化されたデプロイメントや、以下の高度な設定オプションには、コンソールの代わりにコマンドラインインターフェイスを使用します。

  • 検出されたホストを既存のクラスター定義に自動的にバインドする
  • Discovery Image の Ignition 設定をオーバーライドする
  • iPXE の動作を制御する
  • Discovery Image のカーネル引数を変更する
  • 検出フェーズ中にホストに信頼させる追加の証明書を渡す
  • 最新バージョンのデフォルトオプションではない、テスト用に起動する Red Hat CoreOS バージョンを選択する

1.9.4.1. 前提条件

1.9.4.2. ホストインベントリーの作成

コマンドラインインターフェイスを使用してホストインベントリー (インフラストラクチャー環境) を作成するには、次の手順を実行します。

  1. 次のコマンドを実行して、ハブクラスターにログインします。

    oc login
  2. リソースの namespace を作成します。

    1. namespace.yaml という名前のファイルを作成し、次の内容を追加します。

      apiVersion: v1
      kind: Namespace
      metadata:
        name: <your_namespace> 1
      1
      コンソールでインベントリーを監視するには、namespace とインフラストラクチャー環境に同じ名前を使用します。
    2. 以下のコマンドを実行して YAML コンテンツを適用します。

      oc apply -f namespace.yaml
  3. OpenShift Container Platform プルシークレット を含む Secret カスタムリソースを作成します。

    1. pull-secret.yaml ファイルを作成し、以下の内容を追加します。

      apiVersion: v1
      kind: Secret
      type: kubernetes.io/dockerconfigjson
      metadata:
        name: pull-secret 1
        namespace: <your_namespace>
      stringData:
        .dockerconfigjson: <your_pull_secret> 2
      1
      namesapce を追加します。
      2
      プルシークレットを追加します。
    2. 以下のコマンドを実行して YAML コンテンツを適用します。

      oc apply -f pull-secret.yaml
  4. インフラストラクチャー環境を作成します。

    1. infra-env.yaml ファイルを作成し、以下の内容を追加します。必要に応じて値を置き換えます。

      apiVersion: agent-install.openshift.io/v1beta1
      kind: InfraEnv
      metadata:
        name: myinfraenv
        namespace: <your_namespace>
      spec:
        proxy:
          httpProxy: <http://user:password@ipaddr:port>
          httpsProxy: <http://user:password@ipaddr:port>
          noProxy:
        additionalNTPSources:
        sshAuthorizedKey:
        pullSecretRef:
          name: <name>
        agentLabels:
          <key>: <value>
        nmStateConfigLabelSelector:
          matchLabels:
            <key>: <value>
        clusterRef:
          name: <cluster_name>
          namespace: <project_name>
        ignitionConfigOverride: '{"ignition": {"version": "3.1.0"}, …}'
        cpuArchitecture: x86_64
        ipxeScriptType: DiscoveryImageAlways
        kernelArguments:
          - operation: append
            value: audit=0
        additionalTrustBundle: <bundle>
        osImageVersion: <version>

InfraEnv テーブルの次のフィールドの説明を参照してください。

表1.6 InfraEnv のフィールドの表
フィールド任意または必須設定

proxy

任意

InfraEnv リソースを使用するエージェントとクラスターのプロキシー設定を定義します。proxy の値を設定しない場合、エージェントはプロキシーを使用するように設定されません。

httpProxy

任意

HTTP リクエストのプロキシーの URLURL は http で開始する必要があります。HTTPS はサポートされていません。

httpsProxy

任意

HTTP リクエストのプロキシーの URLURL は http で開始する必要があります。HTTPS はサポートされていません。

noProxy

任意

プロキシーを使用しない場合は、コンマで区切られたドメインおよび CIDR のリスト。

additionalNTPSources

任意

すべてのホストに追加するネットワークタイムプロトコル (NTP) ソース (ホスト名または IP) のリスト。これらは、DHCP などの他のオプションを使用して設定された NTP ソースに追加されます。

sshAuthorizedKey

任意

検出フェーズ中のデバッグに使用するためにすべてのホストに追加される SSH 公開鍵。検出フェーズは、ホストを Discovery Image を起動するときです。

name

必須

プルシークレットが含まれる Kubernetes シークレットの名前。

agentLabels

任意

InfraEnv で検出されたホストを表す Agent リソースに自動的に追加されるラベル。キーと値を必ず追加してください。

nmStateConfigLabelSelector

任意

ホストの静的 IP、ブリッジ、ボンディングなどの高度なネットワーク設定を統合します。ホストネットワーク設定は、選択したラベルを持つ 1 つ以上の NMStateConfig リソースで指定されます。nmStateConfigLabelSelector プロパティーは、選択したラベルと一致する Kubernetes ラベルセレクターです。このラベルセレクターに一致するすべての NMStateConfig ラベルのネットワーク設定は、Discovery Image に含まれています。起動時に、各ホストは各設定をそのネットワークインターフェイスと比較し、適切な設定を適用します。高度なネットワーク設定の詳細は、インフラストラクチャー環境向けの高度なネットワークの設定 を参照してください。

clusterRef

任意

スタンドアロンのオンプレミスクラスターを記述する既存の ClusterDeployment リソースを参照します。デフォルトでは設定されません。clusterRef が設定されていない場合は、後でホストを 1 つ以上のクラスターにバインドできます。あるクラスターからホストを削除し、別のクラスターに追加できます。clusterRef が設定されている場合、InfraEnv で検出されたすべてのホストが、指定されたクラスターに自動的にバインドされます。クラスターがまだインストールされていない場合は、検出されたすべてのホストがそのインストールに含まれます。クラスターがすでにインストールされている場合は、検出されたすべてのホストが追加されます。

ignitionConfigOverride

任意

ファイルの追加など、Red Hat CoreOS ライブイメージの Ignition 設定を変更します。必要に応じて ignitionConfigOverride のみを使用してください。クラスターのバージョンに関係なく、ignition バージョン 3.1.0 を使用する必要があります。

cpuArchitecture

任意

サポートされている CPU アーキテクチャー x86_64、aarch64、ppc64le、または s390x のいずれかを選択します。デフォルト値は x86_64 です。

ipxeScriptType

任意

起動に iPXE を使用している場合に、デフォルト値である DiscoveryImageAlways に設定すると、イメージサービスが常に iPXE スクリプトを提供するようになります。その結果、ホストがネットワーク検出イメージから起動します。値を BootOrderControl に設定すると、イメージサービスがホストの状態に応じて iPXE スクリプトを返すタイミングを決定するようになります。その結果、ホストがプロビジョニングされていてクラスターの一部になっている場合、ホストはディスクから起動します。

kernelArguments

任意

Discovery Image の起動時にカーネル引数を変更できます。operation に使用できる値は、appendreplace、または delete です。

additionalTrustBundle

任意

PEM エンコードされた X.509 証明書バンドル。通常、ホストが再暗号化中間者 (MITM) プロキシーを備えたネットワーク内にある場合、またはコンテナーイメージレジストリーなど、他の目的でホストが証明書を信頼しなければならない場合に必要です。InfraEnv によって検出されたホストは、このバンドル内の証明書を信頼します。InfraEnv によって検出されたホストから作成されたクラスターは、このバンドル内の証明書も信頼します。

osImageVersion

任意

InfraEnv に使用する Red Hat CoreOS イメージのバージョン。バージョンが AgentServiceConfig.spec.osImages またはデフォルトの OS イメージのリストで指定された OS イメージを参照していることを確認してください。各リリースには、特定の Red Hat CoreOS イメージバージョンのセットがあります。OSImageVersion は、OS イメージリストの OpenShift Container Platform バージョンと一致する必要があります。OSImageVersionClusterRef を同時に指定できません。デフォルトでは存在しない別のバージョンの Red Hat CoreOS イメージを使用する場合は、AgentServiceConfig.spec.osImages でそのバージョンを指定して、手動で追加する必要があります。バージョンの追加に関する詳細は、 Central infrastructure management サービスの有効化 を参照してください。

  1. 以下のコマンドを実行して YAML コンテンツを適用します。

    oc apply -f infra-env.yaml
  2. ホストインベントリーが作成されたことを確認するには、次のコマンドでステータスを確認します。

    oc describe infraenv myinfraenv -n <your_namespace>

重要なプロパティーのリストは次のとおりです。

  • conditions: イメージが正常に作成されたかどうかを示す標準の Kubernetes 条件。
  • isoDownloadURL: Discovery Image をダウンロードするための URL。
  • createdTime: イメージが最後に作成された時刻。InfraEnv を変更する場合は、新しいイメージをダウンロードする前にタイムスタンプが更新されていることを確認してください。

注: InfraEnv リソースを変更する場合は、createdTime プロパティーを確認して、InfraEnv が新しい Discovery Image を作成したことを確認してください。すでにホストを起動している場合は、最新の Discovery Image でホストを再起動します。

必要に応じて静的ネットワークを設定し、インフラストラクチャー環境へのホストの追加を開始することで続行できます。

1.9.4.3. 関連情報

1.9.5. インフラストラクチャー環境用の高度なネットワークの設定

1 つのインターフェイスで DHCP 以外のネットワークを必要とするホストの場合は、高度なネットワークを設定する必要があります。必要な設定には、1 つ以上のホストのネットワークを記述する NMStateConfig リソースの 1 つ以上のインスタンスの作成が含まれます。

NMStateConfig リソースには、InfraEnv リソースの nmStateConfigLabelSelector に一致するラベルが含まれている必要があります。nmStateConfigLabelSelector の詳細は、コマンドラインインターフェイスを使用したホストインベントリーの作成 を参照してください。

Discovery Image には、参照されているすべての NMStateConfig リソースで定義されたネットワーク設定が含まれています。起動後、各ホストは各設定をそのネットワークインターフェイスと比較し、適切な設定を適用します。

1.9.5.1. 前提条件

1.9.5.2. コマンドラインインターフェイスを使用した高度なネットワークの設定

コマンドラインインターフェイスを使用してインフラストラクチャー環境の詳細ネットワークを設定するには、以下の手順を実行します。

  1. nmstateconfig.yaml という名前のファイルを作成し、以下のテンプレートのようなコンテンツを追加します。必要に応じて値を置き換えます。

    apiVersion: agent-install.openshift.io/v1beta1
    kind: NMStateConfig
    metadata:
      name: mynmstateconfig
      namespace: <your-infraenv-namespace>
      labels:
        some-key: <some-value>
    spec:
      config:
        interfaces:
          - name: eth0
            type: ethernet
            state: up
            mac-address: 02:00:00:80:12:14
            ipv4:
              enabled: true
              address:
                - ip: 192.168.111.30
                  prefix-length: 24
              dhcp: false
          - name: eth1
            type: ethernet
            state: up
            mac-address: 02:00:00:80:12:15
            ipv4:
              enabled: true
              address:
                - ip: 192.168.140.30
                  prefix-length: 24
              dhcp: false
        dns-resolver:
          config:
            server:
              - 192.168.126.1
        routes:
          config:
            - destination: 0.0.0.0/0
              next-hop-address: 192.168.111.1
              next-hop-interface: eth1
              table-id: 254
            - destination: 0.0.0.0/0
              next-hop-address: 192.168.140.1
              next-hop-interface: eth1
              table-id: 254
      interfaces:
        - name: "eth0"
          macAddress: "02:00:00:80:12:14"
        - name: "eth1"
          macAddress: "02:00:00:80:12:15"
表1.7 NMStateConfig のフィールドの表
フィールド任意または必須設定

name

必須

設定しているホストに関連した名前を使用してください。

namespace

必須

namespace は、InfraEnv リソースの namespace と一致する必要があります。

some-key

必須

nmStateConfigLabelSelector に一致する 1 つ以上のラベルを InfraEnv リソースに追加します。

config

任意

NMstate 形式のネットワーク設定を説明します。形式の指定と追加の例については、Declarative Network API を参照してください。この設定は、ホストごとに 1 つの NMStateConfig リソースがある単一のホストに適用することも、単一の NMStateConfig リソースで複数のホストのインターフェイスを記述することもできます。

interfaces

任意

指定された NMstate 設定で見つかったインターフェイス名とホストで見つかった MAC アドレスの間のマッピングを記述します。マッピングがホスト上に存在する物理インターフェイスを使用していることを確認してください。たとえば、NMState 設定でボンドまたは VLAN が定義されている場合、マッピングには親インターフェイスのエントリーのみが含まれます。マッピングには次の目的があります。* ホスト上のインターフェイス名と一致しないインターフェイス名を設定で使用できるようにします。オペレーティングシステムによりインターフェイス名 (これは予測できない) が選択されるので、便利な場合があります。* 起動後に検索する MAC アドレスをホストに指示し、正しい NMstate 設定を適用します。

注: イメージサービスは、InfraEnv プロパティーを更新するか、そのラベルセレクターに一致する NMStateConfig リソースを変更すると、新しいイメージを自動的に作成します。InfraEnv リソースの作成後に NMStateConfig リソースを追加する場合は、InfraEnvcreatedTime プロパティーを確認して、InfraEnv が新しい Discovery Image を作成していることを確認してください。すでにホストを起動している場合は、最新の Discovery Image でホストを再起動します。

  1. 以下のコマンドを実行して YAML コンテンツを適用します。

    oc apply -f nmstateconfig.yaml

1.9.5.3. 関連情報

1.9.6. Discovery Image を使用したホストのホストインベントリーへの追加

ホストインベントリー (インフラストラクチャー環境) を作成したら、ホストを検出してインベントリーに追加できます。

インベントリーにホストを追加するには、ISO ファイルをダウンロードして各サーバーにアタッチする方法を選択します。たとえば、仮想メディアを使用したり、ISO ファイルを USB ドライブに書き込んだりして、ISO ファイルをダウンロードできます。

重要: インストールが失敗しないようにするには、インストールプロセス中は Discovery ISO メディアをデバイスに接続したままにし、各ホストがデバイスから 1 回起動するように設定します。

1.9.6.1. 前提条件

1.9.6.2. コンソールを使用したホストの追加

以下の手順に従って ISO ファイルをダウンロードしてください。

  1. コンソールで Infrastructure > Host inventory を選択します。
  2. 一覧からお使いのインフラストラクチャー環境を選択します。
  3. Add hosts をクリックし、With Discovery ISO を選択します。

    ISO ファイルをダウンロードするための URL が表示されます。ブートされたホストがホストインベントリーテーブルに表示されます。ホストが表示されるまでに数分かかる場合があります。

    注記: デフォルトでは、提供される ISO は minimal ISO です。最小限の ISO には、ルートファイルシステム RootFS が含まれていません。RootFS は後でダウンロードされます。完全な ISO を表示するには、URL 内の minimal.isofull.iso に置き換えます。

  4. 各ホストを承認して使用できるようにします。Actions をクリックして Approve を選択し、インベントリーテーブルからホストを選択できます。

1.9.6.3. コマンドラインインターフェイスを使用したホストの追加

isoDownloadURL プロパティー内の ISO ファイルをダウンロードするための URL は、InfraEnv リソースのステータスに含まれます。InfraEnv リソースの詳細は、コマンドラインインターフェイス を使用したホストインベントリーの作成を参照してください。

起動したホストごとに、同じ namespace に Agent リソースを作成します。

  1. 次のコマンドを実行して、InfraEnv カスタムリソースのダウンロード URL を表示します。

    oc get infraenv -n <infra env namespace> <infra env name> -o jsonpath='{.status.isoDownloadURL}'

    以下の出力を参照してください。

    https://assisted-image-service-assisted-installer.apps.example-acm-hub.com/byapikey/eyJhbGciOiJFUzI1NiIsInC93XVCJ9.eyJpbmZyYV9lbnZfaWQcTA0Y38sWVjYi02MTA0LTQ4NDMtODasdkOGIxYTZkZGM5ZTUifQ.3ydTpHaXJmTasd7uDp2NvGUFRKin3Z9Qct3lvDky1N-5zj3KsRePhAM48aUccBqmucGt3g/4.16/x86_64/minimal.iso

    注記: デフォルトでは、提供される ISO は minimal ISO です。最小限の ISO には、ルートファイルシステム RootFS が含まれていません。RootFS は後でダウンロードされます。完全な ISO を表示するには、URL 内の minimal.isofull.iso に置き換えます。

  2. URL を使用して ISO ファイルをダウンロードし、ISO ファイルを使用してホストを起動します。

    次に、各ホストを承認する必要があります。以下の手順を参照してください。

  3. すべての エージェント をリスト表示するには、次のコマンドを実行します。

    oc get agent -n <infra env namespace>

    次のような出力が得られます。

    NAME                                   CLUSTER   APPROVED   ROLE          STAGE
    24a92a6f-ea35-4d6f-9579-8f04c0d3591e             false      auto-assign
  4. リストで承認ステータスが falseエージェント を承認します。以下のコマンドを実行します。

    oc patch agent -n <infra env namespace> <agent name> -p '{"spec":{"approved":true}}' --type merge
  5. 承認ステータスを確認するには、次のコマンドを実行します。

    oc get agent -n <infra env namespace>

    値が true の、次のような出力が返されます。

    NAME                                   CLUSTER   APPROVED   ROLE          STAGE
    173e3a84-88e2-4fe1-967f-1a9242503bec             true       auto-assign

1.9.6.4. 関連情報

1.9.7. ベアメタルホストのホストインベントリーへの自動追加

ホストインベントリー (インフラストラクチャー環境) を作成した後、ホストを検出してインベントリーに追加できます。各ホストの BareMetalHost リソースおよび関連する BMC シークレットを作成することで、ベアメタル Operator が各ベアメタルホストのベースボード管理コントローラー (BMC) と通信できるようにすることで、インフラストラクチャー環境の Discovery Image の起動を自動化できます。自動化は、インフラストラクチャー環境を参照する BareMetalHost のラベルによって設定されます。

自動化により以下のアクションが実行されます。

  • インフラストラクチャー環境で表される Discovery Image を使用して、各ベアメタルホストを起動します。
  • インフラストラクチャー環境または関連するネットワーク設定が更新された場合に、各ホストを最新の Discovery Image で再起動します。
  • 検出時に各 Agent リソースを対応する BareMetalHost リソースに関連付けます。
  • BareMetalHost からの情報 (ホスト名、ロール、インストールディスクなど) に基づいて Agent リソースのプロパティーを更新します。
  • Agent をクラスターノードとして使用することを承認します。

1.9.7.1. 前提条件

1.9.7.2. コンソールを使用したベアメタルホストの追加

コンソールを使用してベアメタルホストをホストインベントリーに自動的に追加するには、次の手順を実行します。

  1. コンソールで Infrastructure > Host inventory を選択します。
  2. 一覧からお使いのインフラストラクチャー環境を選択します。
  3. Add hosts をクリックし、With BMC Form を選択します。
  4. 必要な情報を追加し、Create をクリックします。

1.9.7.3. コマンドラインインターフェイスを使用したベアメタルホストの追加

コマンドラインインターフェイスを使用してベアメタルホストをホストインベントリーに自動的に追加するには、以下の手順を実施します。

  1. 次の YAML コンテンツを適用し、必要に応じて値を置き換えて、BMC シークレットを作成します。

    apiVersion: v1
    kind: Secret
    metadata:
      name: <bmc-secret-name>
      namespace: <your_infraenv_namespace> 1
    type: Opaque
    data:
      username: <username>
      password: <password>
    1
    namespace は InfraEnv の namespace と同じである必要があります。
  2. 以下の YAML コンテンツを適用し、必要に応じて値を置き換えてベアメタルホストを作成します。

    apiVersion: metal3.io/v1alpha1
    kind: BareMetalHost
    metadata:
      name: <bmh-name>
      namespace: <your_infraenv_namespace> 1
      annotations:
        inspect.metal3.io: disabled
      labels:
        infraenvs.agent-install.openshift.io: <your-infraenv> 2
    spec:
      online: true
      automatedCleaningMode: disabled 3
      bootMACAddress: <your-mac-address>  4
      bmc:
        address: <machine-address> 5
        credentialsName: <bmc-secret-name> 6
      rootDeviceHints:
        deviceName: /dev/sda 7
    1
    namespace は InfraEnv の namespace と同じである必要があります。
    2
    この名前は InfrEnv の名前と一致し、同じ namespace に存在する必要があります。
    3
    値を設定しない場合、metadata の値が自動的に使用されます。
    4
    MAC アドレスがホスト上のいずれかのインターフェイスの MAC アドレスと一致することを確認してください。
    5
    BMC のアドレスを使用します。詳細は 帯域外管理 IP アドレスのポートアクセス を参照してください。
    6
    credentialsName の値が、作成した BMC シークレットの名前と一致していることを確認してください。
    7
    オプション: インストールディスクを選択します。利用可能なルートデバイスのヒントについては、BareMetalHost spec を参照してください。ホストが Discovery Image で起動され、対応する Agent リソースが作成された後、このヒントに従ってインストールディスクが設定されます。

ホストの電源をオンにすると、イメージのダウンロードが開始されます。これには数分かかる場合があります。ホストが検出されると、Agent カスタムリソースが自動的に作成されます。

1.9.7.4. コマンドラインインターフェイスを使用したマネージドクラスターノードの削除

マネージドクラスターからマネージドクラスターノードを削除するには、サポートされている OpenShift Container Platform バージョンで実行されているハブクラスターが必要です。ノードの起動に必要な静的ネットワーク設定が利用可能である必要があります。エージェントとベアメタルホストを削除するときに、NMStateConfig リソースを削除しないようにしてください。

1.9.7.4.1. ベアメタルホストを使用したマネージドクラスターノードの削除

ハブクラスター上にベアメタルホストがあり、マネージドクラスターからマネージドクラスターノードを削除する場合は、次の手順を実行します。

  1. 削除するノードの BareMetalHost リソースに次のアノテーションを追加します。

    bmac.agent-install.openshift.io/remove-agent-and-node-on-delete: true
  2. 次のコマンドを実行して、BareMetalHost リソースを削除します。<bmh-name> は、BareMetalHost の名前に置き換えます。

    oc delete bmh <bmh-name>
1.9.7.4.2. ベアメタルホストを使用しないマネージドクラスターノードの削除

ハブクラスターにベアメタルホストがなく、マネージドクラスターからマネージドクラスターノードを削除する場合は、OpenShift Container Platform ドキュメントの ノードの削除 手順に従ってください。

1.9.7.5. 関連情報

1.9.8. ホストインベントリーの管理

コンソールまたはコマンドラインインターフェイスを使用して、Agent リソースの編集、ホストインベントリーの管理、既存のホストの編集が可能です。

1.9.8.1. コンソールを使用したホストインベントリーの管理

Discovery ISO で正常に起動した各ホストは、ホストインベントリーの行として表示されます。コンソールを使用してホストを編集および管理できます。ホストを手動で起動し、ベアメタル Operator の自動化を使用していない場合は、使用する前にコンソールでホストを承認する必要があります。OpenShift ノードとしてインストールできるホストが Available ステータスになっています。

1.9.8.2. コマンドラインインターフェイスを使用したホストインベントリーの管理

Agent リソースは、各ホストを表します。Agent リソースで次のプロパティーを設定できます。

  • clusterDeploymentName

    このプロパティーは、クラスターにノードとしてインストールする場合に使用する ClusterDeployment の namespace および名前に設定します。

  • 任意: role

    クラスター内のホストのロールを設定します。使用できる値は、masterworker、および auto-assign です。デフォルト値は auto-assign です。

  • hostname

    ホストのホスト名を設定します。ホストに有効なホスト名が自動的に割り当てられる場合は任意です (例: DHCP を使用)。

  • approved

    ホストを OpenShift ノードとしてインストールできるかどうかを示します。このプロパティーは、デフォルト値が False のブール値です。ホストを手動で起動しており、ベアメタル Operator の自動化を使用していない場合は、ホストをインストールする前にこのプロパティーを True に設定する必要があります。

  • installation_disk_id

    ホストのインベントリーに表示されるインストールディスクの ID。

  • installerArgs

    ホストの coreos-installer 引数のオーバーライドが含まれる JSON 形式の文字列。このプロパティーを使用して、カーネル引数を変更できます。構文例を以下に示します。

    ["--append-karg", "ip=192.0.2.2::192.0.2.254:255.255.255.0:core0.example.com:enp1s0:none", "--save-partindex", "4"]
  • ignitionConfigOverrides

    ホストの Ignition 設定のオーバーライドが含まれる JSON 形式の文字列。このプロパティーを使用して、ignition を使用してファイルをホストに追加できます。構文例を以下に示します。

    {"ignition": "version": "3.1.0"}, "storage": {"files": [{"path": "/tmp/example", "contents": {"source": "data:text/plain;base64,aGVscGltdHJhcHBlZGluYXN3YWdnZXJzcGVj"}}]}}
  • nodeLabels

    ホストのインストール後にノードに適用されるラベルのリスト。

Agent リソースの status には、以下のプロパティーがあります。

  • role

    クラスター内のホストのロールを設定します。これまでに Agent リソースで role をしたことがある場合は、その値が status に表示されます。

  • inventory

    ホスト上で実行されているエージェントが検出するホストプロパティーが含まれます。

  • progress

    ホストのインストールの進行状況。

  • ntpSources

    ホストの設定済みの Network Time Protocol (NTP) ソース。

  • conditions

    次の標準 Kubernetes 条件 (True または False 値) が含まれます。

    • SpecSynced: 指定されたすべてのプロパティーが正常に適用される場合は True。何らかのエラーが発生した場合は、False
    • Connected: インストールサービスへのエージェント接続が禁止されていない場合は True。エージェントがしばらくの間インストールサービスに接続していない場合は False
    • RequirementsMet: ホストがインストールを開始する準備ができている場合は True
    • Validated: すべてのホスト検証に合格した場合は True
    • installed: ホストが OpenShift ノードとしてインストールされている場合は True
    • Bound: ホストがクラスターにバインドされている場合は True
    • Cleanup: Agent リソースの削除リクエストが失敗した場合は False
  • debugInfo

    インストールログおよびイベントをダウンロードするための URL が含まれています。

  • validationsInfo

    ホストの検出後にインストールが成功したことを確認するためにエージェントが実行する検証の情報が含まれます。値が False の場合は、トラブルシューティングを行ってください。

  • installation_disk_id

    ホストのインベントリーに表示されるインストールディスクの ID。

1.9.8.3. 関連情報

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.