14.3. OpenShift インストールの環境のセットアップ

手順

1. カスタマイズされた br-ex ブリッジネットワークの base64 情報をデコードした NMState 設定ファイルを作成します。

   カスタマイズされた br-ex ブリッジネットワークの NMState 設定の例

   interfaces:
   - name: enp2s0 1
     type: ethernet 2
     state: up 3
     ipv4:
       enabled: false 4
     ipv6:
       enabled: false
   - name: br-ex
     type: ovs-bridge
     state: up
     ipv4:
       enabled: false
       dhcp: false
     ipv6:
       enabled: false
       dhcp: false
     bridge:
       port:
       - name: enp2s0 5
       - name: br-ex
   - name: br-ex
     type: ovs-interface
     state: up
     copy-mac-from: enp2s0
     ipv4:
       enabled: true
       dhcp: true
     ipv6:
       enabled: false
       dhcp: false
   # ...

   1

   インターフェイスの名前。

   2

   イーサネットのタイプ。

   3

   作成後のインターフェイスの要求された状態。

   4

   この例では、IPv4 と IPv6 を無効にします。

   5

   ブリッジが接続されるノードの NIC。

2. cat コマンドを使用して、NMState 設定の内容を base64 でエンコードします。

   $ cat <nmstate_configuration>.yaml | base64 1

   1

   <nmstate_configuration> を NMState リソース YAML ファイルの名前に置き換えます。

3. MachineConfig マニフェストファイルを作成し、次の例に類似したカスタマイズされた br-ex ブリッジネットワーク設定を定義します。

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: worker 1
     name: 10-br-ex-worker 2
   spec:
     config:
       ignition:
         version: 3.2.0
       storage:
         files:
         - contents:
             source: data:text/plain;charset=utf-8;base64,<base64_encoded_nmstate_configuration> 3
           mode: 0644
           overwrite: true
           path: /etc/nmstate/openshift/cluster.yml
   # ...

   1

   クラスター内の各ノードに対して、ノードへのホスト名パスと、マシンタイプに応じた base-64 でエンコードされた Ignition 設定ファイルデータを指定します。/etc/nmstate/openshift/cluster.yml 設定ファイルで、クラスター内のすべてのノードに適用する単一のグローバル設定が指定されている場合は、各ノードのホスト名パスを指定する必要はありません。worker ロールは、クラスター内のノードのデフォルトロールです。MachineConfig マニフェストファイルで各ノードまたはすべてのノードのホスト名パスを指定する場合は、.yaml 拡張子が有効ではありません。

   2

   ポリシーの名前。

   3

   エンコードされた base64 情報を指定されたパスに書き込みます。

手順

1. 次のコマンドを入力して MachineConfig CR を編集します。

   $ oc edit mc <machineconfig_custom_resource_name>

2. 各コンピュートノード設定を CR に追加して、CR がクラスター内の定義済みコンピュートノードごとにロールを管理できるようにします。
3. 最小限の静的 IP 設定を持つ extraworker-secret という名前の Secret オブジェクトを作成します。

4. 次のコマンドを入力して、クラスター内の各ノードに extraworker-secret シークレットを適用します。このステップでは、各コンピュートノードに Ignition 設定ファイルへのアクセスを提供します。

   $ oc apply -f ./extraworker-secret.yaml

5. BareMetalHost リソースを作成し、preprovisioningNetworkDataName パラメーターでネットワークシークレットを指定します。

   ネットワークシークレットが添付された BareMetalHost リソースの例

   apiVersion: metal3.io/v1alpha1
   kind: BareMetalHost
   spec:
   # ...
     preprovisioningNetworkDataName: ostest-extraworker-0-network-config-secret
   # ...

6. クラスターの openshift-machine-api namespace 内で BareMetalHost オブジェクトを管理するには、次のコマンドを入力して namespace に変更します。

   $ oc project openshift-machine-api

7. マシンセットを取得します。

   $ oc get machinesets

8. 次のコマンドを入力して、各マシンセットをスケールします。このコマンドはマシンセットごとに実行する必要があります。

   $ oc scale machineset <machineset_name> --replicas=<n> 1

   1

   <machineset_name> はマシンセットの名前です。<n> はコンピュートノードの数です。

手順

1. HAProxy Ingress Controller を設定して、ポート 6443、22623、443、および 80 でロードバランサーからクラスターへのアクセスを有効化できるようにします。必要に応じて、HAProxy 設定で単一のサブネットの IP アドレスまたは複数のサブネットの IP アドレスを指定できます。

   1 つのサブネットをリストした HAProxy 設定の例

   # ...
   listen my-cluster-api-6443
       bind 192.168.1.100:6443
       mode tcp
       balance roundrobin
     option httpchk
     http-check connect
     http-check send meth GET uri /readyz
     http-check expect status 200
       server my-cluster-master-2 192.168.1.101:6443 check inter 10s rise 2 fall 2
       server my-cluster-master-0 192.168.1.102:6443 check inter 10s rise 2 fall 2
       server my-cluster-master-1 192.168.1.103:6443 check inter 10s rise 2 fall 2
   
   listen my-cluster-machine-config-api-22623
       bind 192.168.1.100:22623
       mode tcp
       balance roundrobin
     option httpchk
     http-check connect
     http-check send meth GET uri /healthz
     http-check expect status 200
       server my-cluster-master-2 192.168.1.101:22623 check inter 10s rise 2 fall 2
       server my-cluster-master-0 192.168.1.102:22623 check inter 10s rise 2 fall 2
       server my-cluster-master-1 192.168.1.103:22623 check inter 10s rise 2 fall 2
   
   listen my-cluster-apps-443
       bind 192.168.1.100:443
       mode tcp
       balance roundrobin
     option httpchk
     http-check connect
     http-check send meth GET uri /healthz/ready
     http-check expect status 200
       server my-cluster-worker-0 192.168.1.111:443 check port 1936 inter 10s rise 2 fall 2
       server my-cluster-worker-1 192.168.1.112:443 check port 1936 inter 10s rise 2 fall 2
       server my-cluster-worker-2 192.168.1.113:443 check port 1936 inter 10s rise 2 fall 2
   
   listen my-cluster-apps-80
      bind 192.168.1.100:80
      mode tcp
      balance roundrobin
     option httpchk
     http-check connect
     http-check send meth GET uri /healthz/ready
     http-check expect status 200
       server my-cluster-worker-0 192.168.1.111:80 check port 1936 inter 10s rise 2 fall 2
       server my-cluster-worker-1 192.168.1.112:80 check port 1936 inter 10s rise 2 fall 2
       server my-cluster-worker-2 192.168.1.113:80 check port 1936 inter 10s rise 2 fall 2
   # ...

   複数のサブネットをリストした HAProxy 設定の例

   # ...
   listen api-server-6443
       bind *:6443
       mode tcp
         server master-00 192.168.83.89:6443 check inter 1s
         server master-01 192.168.84.90:6443 check inter 1s
         server master-02 192.168.85.99:6443 check inter 1s
         server bootstrap 192.168.80.89:6443 check inter 1s
   
   listen machine-config-server-22623
       bind *:22623
       mode tcp
         server master-00 192.168.83.89:22623 check inter 1s
         server master-01 192.168.84.90:22623 check inter 1s
         server master-02 192.168.85.99:22623 check inter 1s
         server bootstrap 192.168.80.89:22623 check inter 1s
   
   listen ingress-router-80
       bind *:80
       mode tcp
       balance source
         server worker-00 192.168.83.100:80 check inter 1s
         server worker-01 192.168.83.101:80 check inter 1s
   
   listen ingress-router-443
       bind *:443
       mode tcp
       balance source
         server worker-00 192.168.83.100:443 check inter 1s
         server worker-01 192.168.83.101:443 check inter 1s
   
   listen ironic-api-6385
       bind *:6385
       mode tcp
       balance source
         server master-00 192.168.83.89:6385 check inter 1s
         server master-01 192.168.84.90:6385 check inter 1s
         server master-02 192.168.85.99:6385 check inter 1s
         server bootstrap 192.168.80.89:6385 check inter 1s
   
   listen inspector-api-5050
       bind *:5050
       mode tcp
       balance source
         server master-00 192.168.83.89:5050 check inter 1s
         server master-01 192.168.84.90:5050 check inter 1s
         server master-02 192.168.85.99:5050 check inter 1s
         server bootstrap 192.168.80.89:5050 check inter 1s
   # ...

2. curl CLI コマンドを使用して、ユーザー管理ロードバランサーとそのリソースが動作していることを確認します。

   1. 次のコマンドを実行して応答を観察し、クラスターマシン設定 API が Kubernetes API サーバーリソースにアクセスできることを確認します。

      $ curl https://<loadbalancer_ip_address>:6443/version --insecure

      設定が正しい場合は、応答として JSON オブジェクトを受信します。

      {
        "major": "1",
        "minor": "11+",
        "gitVersion": "v1.11.0+ad103ed",
        "gitCommit": "ad103ed",
        "gitTreeState": "clean",
        "buildDate": "2019-01-09T06:44:10Z",
        "goVersion": "go1.10.3",
        "compiler": "gc",
        "platform": "linux/amd64"
      }

   2. 次のコマンドを実行して出力を確認し、クラスターマシン設定 API がマシン設定サーバーリソースからアクセスできることを確認します。

      $ curl -v https://<loadbalancer_ip_address>:22623/healthz --insecure

      設定が正しい場合、コマンドの出力には次の応答が表示されます。

      HTTP/1.1 200 OK
      Content-Length: 0

   3. 次のコマンドを実行して出力を確認し、コントローラーがポート 80 の Ingress Controller リソースにアクセスできることを確認します。

      $ curl -I -L -H "Host: console-openshift-console.apps.<cluster_name>.<base_domain>" http://<load_balancer_front_end_IP_address>

      設定が正しい場合、コマンドの出力には次の応答が表示されます。

      HTTP/1.1 302 Found
      content-length: 0
      location: https://console-openshift-console.apps.ocp4.private.opequon.net/
      cache-control: no-cache

   4. 次のコマンドを実行して出力を確認し、コントローラーがポート 443 の Ingress Controller リソースにアクセスできることを確認します。

      $ curl -I -L --insecure --resolve console-openshift-console.apps.<cluster_name>.<base_domain>:443:<Load Balancer Front End IP Address> https://console-openshift-console.apps.<cluster_name>.<base_domain>

      設定が正しい場合、コマンドの出力には次の応答が表示されます。

      HTTP/1.1 200 OK
      referrer-policy: strict-origin-when-cross-origin
      set-cookie: csrf-token=UlYWOyQ62LWjw2h003xtYSKlh1a0Py2hhctw0WmV2YEdhJjFyQwWcGBsja261dGLgaYO0nxzVErhiXt6QepA7g==; Path=/; Secure; SameSite=Lax
      x-content-type-options: nosniff
      x-dns-prefetch-control: off
      x-frame-options: DENY
      x-xss-protection: 1; mode=block
      date: Wed, 04 Oct 2023 16:29:38 GMT
      content-type: text/html; charset=utf-8
      set-cookie: 1e2670d92730b515ce3a1bb65da45062=1bf5e9573c9a2760c964ed1659cc1673; path=/; HttpOnly; Secure; SameSite=None
      cache-control: private

3. ユーザー管理ロードバランサーのフロントエンド IP アドレスをターゲットにするようにクラスターの DNS レコードを設定します。ロードバランサー経由で、クラスター API およびアプリケーションの DNS サーバーのレコードを更新する必要があります。

   変更された DNS レコードの例

   <load_balancer_ip_address>  A  api.<cluster_name>.<base_domain>
   A record pointing to Load Balancer Front End

   <load_balancer_ip_address>   A apps.<cluster_name>.<base_domain>
   A record pointing to Load Balancer Front End

   重要

   DNS の伝播では、各 DNS レコードが使用可能になるまでに時間がかかる場合があります。各レコードを検証する前に、各 DNS レコードが伝播されることを確認してください。

4. OpenShift Container Platform クラスターでユーザー管理ロードバランサーを使用するには、クラスターの install-config.yaml ファイルで次の設定を指定する必要があります。

   # ...
   platform:
     baremetal:
       loadBalancer:
         type: UserManaged 1
         apiVIPs:
         - <api_ip> 2
         ingressVIPs:
         - <ingress_ip> 3
   # ...

   1

   クラスターのユーザー管理ロードバランサーを指定するには、type パラメーターに UserManaged を設定します。パラメーターのデフォルトは OpenShiftManagedDefault で、これはデフォルトの内部ロードバランサーを示します。openshift-kni-infra namespace で定義されたサービスの場合、ユーザー管理ロードバランサーは coredns サービスをクラスター内の Pod にデプロイできますが、keepalived および haproxy サービスは無視します。

   2

   ユーザー管理ロードバランサーを指定する場合に必須のパラメーターです。Kubernetes API がユーザー管理ロードバランサーと通信できるように、ユーザー管理ロードバランサーのパブリック IP アドレスを指定します。

   3

   ユーザー管理ロードバランサーを指定する場合に必須のパラメーターです。ユーザー管理ロードバランサーのパブリック IP アドレスを指定して、ユーザー管理ロードバランサーがクラスターの Ingress トラフィックを管理できるようにします。

検証

1. curl CLI コマンドを使用して、ユーザー管理ロードバランサーと DNS レコード設定が動作していることを確認します。

   1. 次のコマンドを実行して出力を確認し、クラスター API にアクセスできることを確認します。

      $ curl https://api.<cluster_name>.<base_domain>:6443/version --insecure

      設定が正しい場合は、応答として JSON オブジェクトを受信します。

      {
        "major": "1",
        "minor": "11+",
        "gitVersion": "v1.11.0+ad103ed",
        "gitCommit": "ad103ed",
        "gitTreeState": "clean",
        "buildDate": "2019-01-09T06:44:10Z",
        "goVersion": "go1.10.3",
        "compiler": "gc",
        "platform": "linux/amd64"
        }

   2. 次のコマンドを実行して出力を確認し、クラスターマシン設定にアクセスできることを確認します。

      $ curl -v https://api.<cluster_name>.<base_domain>:22623/healthz --insecure

      設定が正しい場合、コマンドの出力には次の応答が表示されます。

      HTTP/1.1 200 OK
      Content-Length: 0

   3. 以下のコマンドを実行して出力を確認し、ポートで各クラスターアプリケーションにアクセスできることを確認します。

      $ curl http://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure

      設定が正しい場合、コマンドの出力には次の応答が表示されます。

      HTTP/1.1 302 Found
      content-length: 0
      location: https://console-openshift-console.apps.<cluster-name>.<base domain>/
      cache-control: no-cacheHTTP/1.1 200 OK
      referrer-policy: strict-origin-when-cross-origin
      set-cookie: csrf-token=39HoZgztDnzjJkq/JuLJMeoKNXlfiVv2YgZc09c3TBOBU4NI6kDXaJH1LdicNhN1UsQWzon4Dor9GWGfopaTEQ==; Path=/; Secure
      x-content-type-options: nosniff
      x-dns-prefetch-control: off
      x-frame-options: DENY
      x-xss-protection: 1; mode=block
      date: Tue, 17 Nov 2020 08:42:10 GMT
      content-type: text/html; charset=utf-8
      set-cookie: 1e2670d92730b515ce3a1bb65da45062=9b714eb87e93cf34853e87a92d6894be; path=/; HttpOnly; Secure; SameSite=None
      cache-control: private

   4. 次のコマンドを実行して出力を確認し、ポート 443 で各クラスターアプリケーションにアクセスできることを確認します。

      $ curl https://console-openshift-console.apps.<cluster_name>.<base_domain> -I -L --insecure

      設定が正しい場合、コマンドの出力には次の応答が表示されます。

      HTTP/1.1 200 OK
      referrer-policy: strict-origin-when-cross-origin
      set-cookie: csrf-token=UlYWOyQ62LWjw2h003xtYSKlh1a0Py2hhctw0WmV2YEdhJjFyQwWcGBsja261dGLgaYO0nxzVErhiXt6QepA7g==; Path=/; Secure; SameSite=Lax
      x-content-type-options: nosniff
      x-dns-prefetch-control: off
      x-frame-options: DENY
      x-xss-protection: 1; mode=block
      date: Wed, 04 Oct 2023 16:29:38 GMT
      content-type: text/html; charset=utf-8
      set-cookie: 1e2670d92730b515ce3a1bb65da45062=1bf5e9573c9a2760c964ed1659cc1673; path=/; HttpOnly; Secure; SameSite=None
      cache-control: private

1. install-config.yaml を設定します。pullSecret、sshKey など、環境に合わせて適切な変数を変更します。

   apiVersion: v1
   baseDomain: <domain>
   metadata:
     name: <cluster_name>
   networking:
     machineNetwork:
     - cidr: <public_cidr>
     networkType: OVNKubernetes
   compute:
   - name: worker
     replicas: 2 1
   controlPlane:
     name: master
     replicas: 3
     platform:
       baremetal: {}
   platform:
     baremetal:
       apiVIPs:
         - <api_ip>
       ingressVIPs:
         - <wildcard_ip>
       provisioningNetworkCIDR: <CIDR>
       bootstrapExternalStaticIP: <bootstrap_static_ip_address> 2
       bootstrapExternalStaticGateway: <bootstrap_static_gateway> 3
       bootstrapExternalStaticDNS: <bootstrap_static_dns> 4
       hosts:
         - name: openshift-master-0
           role: master
           bmc:
             address: ipmi://<out_of_band_ip> 5
             username: <user>
             password: <password>
           bootMACAddress: <NIC1_mac_address>
           rootDeviceHints:
            deviceName: "<installation_disk_drive_path>" 6
         - name: <openshift_master_1>
           role: master
           bmc:
             address: ipmi://<out_of_band_ip>
             username: <user>
             password: <password>
           bootMACAddress: <NIC1_mac_address>
           rootDeviceHints:
            deviceName: "<installation_disk_drive_path>"
         - name: <openshift_master_2>
           role: master
           bmc:
             address: ipmi://<out_of_band_ip>
             username: <user>
             password: <password>
           bootMACAddress: <NIC1_mac_address>
           rootDeviceHints:
            deviceName: "<installation_disk_drive_path>"
         - name: <openshift_worker_0>
           role: worker
           bmc:
             address: ipmi://<out_of_band_ip>
             username: <user>
             password: <password>
           bootMACAddress: <NIC1_mac_address>
         - name: <openshift_worker_1>
           role: worker
           bmc:
             address: ipmi://<out_of_band_ip>
             username: <user>
             password: <password>
           bootMACAddress: <NIC1_mac_address>
           rootDeviceHints:
            deviceName: "<installation_disk_drive_path>"
   pullSecret: '<pull_secret>'
   sshKey: '<ssh_pub_key>'

   1

   OpenShift Container Platform クラスターの一部であるコンピュートノードの数に基づいて、コンピュートマシンをスケーリングします。replicas 値の有効なオプションは 0 で、2 以上の整数です。3 ノードクラスターのみが含まれる 3 ノードクラスターをデプロイするには、レプリカ数を 0 に設定します。3 ノードクラスターは、テスト、開発、本番に使用できる、より小さく、よりリソース効率の良いクラスターです。コンピュートノードが 1 つだけのクラスターをインストールすることはできません。

   2

   静的 IP アドレスを使用してクラスターをデプロイする場合、ベアメタルネットワークに DHCP サーバーがない場合は、bootstrapExternalStaticIP 設定を設定して、ブートストラップ VM の静的 IP アドレスを指定する必要があります。

   3

   静的 IP アドレスを使用してクラスターをデプロイする場合、ベアメタルネットワークに DHCP サーバーがない場合は、bootstrapExternalStaticGateway 設定を設定して、ブートストラップ仮想マシンのゲートウェイ IP アドレスを指定する必要があります。

   4

   静的 IP アドレスを使用してクラスターをデプロイする場合、ベアメタルネットワークに DHCP サーバーがない場合は、bootstrapExternalStaticDNS 設定を設定して、ブートストラップ仮想マシンの DNS アドレスを指定する必要があります。

   5

   その他のオプションについては、BMC アドレス指定のセクションを参照してください。

   6

   インストールディスクドライブへのパスを設定するには、ディスクのカーネル名を入力します。たとえば、/dev/sda です。

   重要

   ディスクの検出順序は保証されていないため、複数のディスクを備えたマシンの起動オプションによってディスクのカーネル名が変わる可能性があります。たとえば、/dev/sda は /dev/sdb になり、その逆も同様です。この問題を回避するには、ディスクの World Wide Name (WWN) や /dev/disk/by-path/ などの永続的なディスク属性を使用する必要があります。ストレージの場所への /dev/disk/by-path/<device_path> リンクを使用することを推奨します。ディスク WWN を使用するには、deviceName パラメーターを wwnWithExtension パラメーターに置き換えます。使用するパラメーターに応じて、次のいずれかの値を入力します。

   • ディスク名。たとえば、/dev/sda、または /dev/disk/by-path/ です。
   • ディスクの WWN。たとえば、"0x64cd98f04fde100024684cf3034da5c2" です。ディスク WWN 値が 16 進数値ではなく文字列値として使用されるように、ディスク WWN 値を引用符で囲んで入力してください。

   これらの rootDeviceHints パラメーター要件を満たさない場合、次のエラーが発生する可能性があります。

   ironic-inspector inspection failed: No disks satisfied root device hints

   注記

   OpenShift Container Platform 4.12 より前では、クラスターインストールプログラムが、apiVIP および ingressVIP 設定の IPv4 アドレスまたは IPv6 アドレスのみを受け入れていました。OpenShift Container Platform 4.12 以降では、これらの設定は非推奨です。代わりに、apiVIPs および ingressVIPs 設定でリスト形式を使用して、IPv4 アドレス、IPv6 アドレス、または両方の IP アドレス形式を指定してください。

2. クラスター設定を保存するディレクトリーを作成します。

   $ mkdir ~/clusterconfigs

3. install-config.yaml ファイルを新しいディレクトリーにコピーします。

   $ cp install-config.yaml ~/clusterconfigs

4. OpenShift Container Platform クラスターをインストールする前に、すべてのベアメタルノードの電源がオフになっていることを確認します。

   $ ipmitool -I lanplus -U <user> -P <password> -H <management-server-ip> power off

5. 以前に試行したデプロイメントにより古いブートストラップリソースが残っている場合は、これを削除します。

   for i in $(sudo virsh list | tail -n +3 | grep bootstrap | awk {'print $2'});
   do
     sudo virsh destroy $i;
     sudo virsh undefine $i;
     sudo virsh vol-delete $i --pool $i;
     sudo virsh vol-delete $i.ign --pool $i;
     sudo virsh pool-destroy $i;
     sudo virsh pool-undefine $i;
   done

手順

1. 次のコマンドを実行して、BMC の IP アドレスまたはホスト名を設定します。

   $ export SERVER=<ip_address> 1

   1

   <ip_address> を、BMC の IP アドレスまたはホスト名に置き換えます。

2. 次のコマンドを実行して、システムの ID を設定します。

   $ export SystemID=<system_id> 1

   1

   <system_id> をシステム ID に置き換えます。たとえば、System.Embedded.1 または 1 です。詳細は、以下のベンダー固有 BMC セクションを参照してください。

Redfish API のリスト

1. 次のコマンドを実行して、power on のサポートを確認します。

   $ curl -u $USER:$PASS -X POST -H'Content-Type: application/json' -H'Accept: application/json' -d '{"ResetType": "On"}' https://$SERVER/redfish/v1/Systems/$SystemID/Actions/ComputerSystem.Reset

2. 次のコマンドを実行して、power off のサポートを確認します。

   $ curl -u $USER:$PASS -X POST -H'Content-Type: application/json' -H'Accept: application/json' -d '{"ResetType": "ForceOff"}' https://$SERVER/redfish/v1/Systems/$SystemID/Actions/ComputerSystem.Reset

3. 次のコマンドを実行して、pxe を使用する一時的なブート実装を確認します。

   $ curl -u $USER:$PASS -X PATCH -H "Content-Type: application/json"  https://$Server/redfish/v1/Systems/$SystemID/ -d '{"Boot": {"BootSourceOverrideTarget": "pxe", "BootSourceOverrideEnabled": "Once"}}

4. 次のコマンドを実行して、Legacy または UEFI を使用する BIOS ブートモードの設定ステータスを確認します。

   $ curl -u $USER:$PASS -X PATCH -H "Content-Type: application/json"  https://$Server/redfish/v1/Systems/$SystemID/ -d '{"Boot": {"BootSourceOverrideMode":"UEFI"}}

Redfish 仮想メディア API のリスト

1. 次のコマンドを実行して、cd または dvd を使用する一時ブートデバイスを設定できるか確認します。

   $ curl -u $USER:$PASS -X PATCH -H "Content-Type: application/json" https://$Server/redfish/v1/Systems/$SystemID/ -d '{"Boot": {"BootSourceOverrideTarget": "cd", "BootSourceOverrideEnabled": "Once"}}'

2. 次のコマンドを実行して、仮想メディアをマウントできるか確認します。

   $ curl -u $USER:$PASS -X PATCH -H "Content-Type: application/json" -H "If-Match: *" https://$Server/redfish/v1/Managers/$ManagerID/VirtualMedia/$VmediaId -d '{"Image": "https://example.com/test.iso", "TransferProtocolType": "HTTPS", "UserName": "", "Password":""}'

手順

1. オプション: インストーラーは NMState YAML 構文をチェックしないため、install-config.yaml ファイルに含める前に nmstatectl gc で NMState 構文をテストすることを検討してください。

   注記

   YAML 構文にエラーがあると、ネットワーク設定の適用に失敗する可能性があります。さらに、検証済みの YAML 構文を維持すると、デプロイ後に Kubernetes NMState を使用して変更を適用する場合、またはクラスターを拡張する場合に役立ちます。

   1. NMState YAML ファイルを作成します。

      interfaces:
      - name: <nic1_name> 1
        type: ethernet
        state: up
        ipv4:
          address:
          - ip: <ip_address> 2
            prefix-length: 24
          enabled: true
      dns-resolver:
        config:
          server:
          - <dns_ip_address> 3
      routes:
        config:
        - destination: 0.0.0.0/0
          next-hop-address: <next_hop_ip_address> 4
          next-hop-interface: <next_hop_nic1_name> 5

      1 2 3 4 5

      <nic1_name>、<ip_address>、<dns_ip_address>、<next_hop_ip_address>、および <next_hop_nic1_name> を適切な値に置き換えます。

   2. 次のコマンドを実行して、設定ファイルをテストします。

      $ nmstatectl gc <nmstate_yaml_file>

      <nmstate_yaml_file> を設定ファイル名に置き換えます。

2. install-config.yaml ファイル内のホストに NMState 設定を追加して、networkConfig 設定を使用します。

       hosts:
         - name: openshift-master-0
           role: master
           bmc:
             address: redfish+http://<out_of_band_ip>/redfish/v1/Systems/
             username: <user>
             password: <password>
             disableCertificateVerification: null
           bootMACAddress: <NIC1_mac_address>
           bootMode: UEFI
           rootDeviceHints:
             deviceName: "/dev/sda"
           networkConfig: 1
             interfaces:
             - name: <nic1_name> 2
               type: ethernet
               state: up
               ipv4:
                 address:
                 - ip: <ip_address> 3
                   prefix-length: 24
                 enabled: true
             dns-resolver:
               config:
                 server:
                 - <dns_ip_address> 4
             routes:
               config:
               - destination: 0.0.0.0/0
                 next-hop-address: <next_hop_ip_address> 5
                 next-hop-interface: <next_hop_nic1_name> 6

   1

   NMState YAML 構文を追加して、ホストインターフェイスを設定します。

   2 3 4 5 6

   <nic1_name>、<ip_address>、<dns_ip_address>、<next_hop_ip_address>、および <next_hop_nic1_name> を適切な値に置き換えます。

   重要

   クラスターをデプロイした後、install-config.yaml ファイルの networkConfig 設定を変更して、ホストネットワークインターフェイスを変更することはできません。Kubernetes NMState Operator を使用して、デプロイ後にホストネットワークインターフェイスに変更を加えます。

手順

1. 静的 IP アドレスを使用する場合は、install-config.yaml ファイルの machineNetwork にサブネットを追加します。

   networking:
     machineNetwork:
     - cidr: 10.0.0.0/24
     - cidr: 192.168.0.0/24
     networkType: OVNKubernetes

2. 静的 IP アドレスまたはボンディングなどの高度なネットワークを使用する場合は、NMState 構文を使用して、各エッジコンピュートノードの networkConfig パラメーターにゲートウェイと DNS 設定を追加します。

   networkConfig:
     interfaces:
     - name: <interface_name> 1
       type: ethernet
       state: up
       ipv4:
         enabled: true
         dhcp: false
         address:
         - ip: <node_ip> 2
           prefix-length: 24
         gateway: <gateway_ip> 3
     dns-resolver:
       config:
         server:
         - <dns_ip> 4

   1

   <interface_name> をインターフェイス名に置き換えます。

   2

   <node_ip> をノードの IP アドレスに置き換えます。

   3

   <gateway_ip> をゲートウェイの IP アドレスに置き換えます。

   4

   <dns_ip> を DNS サーバーの IP アドレスに置き換えます。

手順

1. オプション: インストールプログラムは NMState YAML 構文をチェックしないため、install-config.yaml ファイルに含める前に nmstatectl gc コマンドを使用して NMState YAML 構文をテストすることを検討してください。

   1. NMState YAML ファイルを作成します。

      interfaces:
      - name: eth0
        ipv6:
          addr-gen-mode: <address_mode> 1

      1

      <address_mode> を、クラスター内の IPv6 アドレスに必要なアドレス生成モードのタイプに置き換えます。有効な値は、eui64、stable-privacy、または random です。

   2. 次のコマンドを実行して、設定ファイルをテストします。

      $ nmstatectl gc <nmstate_yaml_file> 1

      1

      <nmstate_yaml_file> を、テスト設定ファイルの名前に置き換えます。

2. NMState 設定を、install-config.yaml ファイル内の hosts.networkConfig セクションに追加します。

       hosts:
         - name: openshift-master-0
           role: master
           bmc:
             address: redfish+http://<out_of_band_ip>/redfish/v1/Systems/
             username: <user>
             password: <password>
             disableCertificateVerification: null
           bootMACAddress: <NIC1_mac_address>
           bootMode: UEFI
           rootDeviceHints:
             deviceName: "/dev/sda"
           networkConfig:
             interfaces:
             - name: eth0
               ipv6:
                 addr-gen-mode: <address_mode> 1
   ...

   1

   <address_mode> を、クラスター内の IPv6 アドレスに必要なアドレス生成モードのタイプに置き換えます。有効な値は、eui64、stable-privacy、または random です。

手順

1. install-config.yaml ファイル内のホストの networkConfig フィールドに NMState 設定を追加します。

       hosts:
         - name: worker-0
           role: worker
           bmc:
             address: redfish+http://<out_of_band_ip>/redfish/v1/Systems/
             username: <user>
             password: <password>
             disableCertificateVerification: false
           bootMACAddress: <NIC1_mac_address>
           bootMode: UEFI
           networkConfig: 1
             interfaces: 2
              - name: eno1 3
                type: ethernet 4
                state: up
                mac-address: 0c:42:a1:55:f3:06
                ipv4:
                  enabled: true
                  dhcp: false 5
                ethernet:
                  sr-iov:
                    total-vfs: 2 6
                ipv6:
                  enabled: false
                  dhcp: false
              - name: sriov:eno1:0
                type: ethernet
                state: up 7
                ipv4:
                  enabled: false 8
                ipv6:
                  enabled: false
              - name: sriov:eno1:1
                type: ethernet
                state: down
              - name: eno2
                type: ethernet
                state: up
                mac-address: 0c:42:a1:55:f3:07
                ipv4:
                  enabled: true
                ethernet:
                  sr-iov:
                    total-vfs: 2
                ipv6:
                  enabled: false
              - name: sriov:eno2:0
                type: ethernet
                state: up
                ipv4:
                  enabled: false
                ipv6:
                  enabled: false
              - name: sriov:eno2:1
                type: ethernet
                state: down
              - name: bond0
                type: bond
                state: up
                min-tx-rate: 100 9
                max-tx-rate: 200 10
                link-aggregation:
                  mode: active-backup 11
                  options:
                    primary: sriov:eno1:0 12
                  port:
                    - sriov:eno1:0
                    - sriov:eno2:0
                ipv4:
                  address:
                    - ip: 10.19.16.57 13
                      prefix-length: 23
                  dhcp: false
                  enabled: true
                ipv6:
                  enabled: false
             dns-resolver:
               config:
                 server:
                   - 10.11.5.160
                   - 10.2.70.215
             routes:
               config:
                 - destination: 0.0.0.0/0
                   next-hop-address: 10.19.17.254
                   next-hop-interface: bond0 14
                   table-id: 254

   1

   networkConfig フィールドには、ホストのネットワーク設定に関する情報を含めます。interfaces、dns-resolver、routes などのサブフィールドがあります。

   2

   interfaces フィールドは、ホスト用に定義されたネットワークインターフェイスの配列です。

   3

   インターフェイスの名前。

   4

   インターフェイスのタイプ。この例では、イーサネットインターフェイスを作成します。

   5

   厳密に必要ではない場合、物理機能 (PF) の DHCP を無効にするには、これを false に設定します。

   6

   インスタンス化する SR-IOV 仮想機能 (VF) の数に設定します。

   7

   これを up に設定します。

   8

   ボンドに接続された VF の IPv4 アドレス指定を無効にするには、これを false に設定します。

   9

   VF の最小伝送速度 (Mbps) を設定します。このサンプル値は、100 Mbps のレートを設定します。

   • この値は、最大伝送レート以下である必要があります。
   • Intel NIC は min-tx-rate パラメーターをサポートしていません。詳細は、BZ#1772847 を参照してください。

   10

   VF の最大伝送速度 (Mbps) を設定します。このサンプル値は、200 Mbps のレートを設定します。

   11

   目的のボンディングモードを設定します。

   12

   ボンディングインターフェイスの優先ポートを設定します。ボンディングは、プライマリーデバイスをボンディングインターフェイスの最初のデバイスとして使用します。ボンディングは、障害が発生しない限り、プライマリーデバイスインターフェイスを放棄しません。この設定が特に役立つのは、ボンディングインターフェイスの NIC の 1 つが高速なため、大規模な負荷に対応できる場合です。この設定は、ボンディングインターフェイスが active-backup モード (モード 1) および balance-tlb (モード 5) の場合のみに有効です。

   13

   ボンドインターフェイスの静的 IP アドレスを設定します。これはノードの IP アドレスです。

   14

   デフォルトルートのゲートウェイとして bond0 を設定します。

   重要

   クラスターをデプロイした後は、install-config.yaml ファイルの networkConfig 設定を変更してホストネットワークインターフェイスを変更することはできません。Kubernetes NMState Operator を使用して、デプロイ後にホストネットワークインターフェイスに変更を加えます。

1. OpenShift Container Platform マニフェストを作成します。

   $ ./openshift-baremetal-install --dir ~/clusterconfigs create manifests

   INFO Consuming Install Config from target directory
   WARNING Making control-plane schedulable by setting MastersSchedulable to true for Scheduler cluster settings
   WARNING Discarding the OpenShift Manifest that was provided in the target directory because its dependencies are dirty and it needs to be regenerated

手順

1. 次のコマンドを使用して、インストールホストに Butane をインストールします。

   $ sudo dnf -y install butane

2. コントロールプレーンノードの chrony.conf ファイルのコンテンツを含む Butane 設定 (99-master-chrony-conf-override.bu) を作成します。

   注記

   Butane の詳細は、「Butane を使用したマシン設定の作成」を参照してください。

   Butane 設定例

   variant: openshift
   version: 4.16.0
   metadata:
     name: 99-master-chrony-conf-override
     labels:
       machineconfiguration.openshift.io/role: master
   storage:
     files:
       - path: /etc/chrony.conf
         mode: 0644
         overwrite: true
         contents:
           inline: |
             # Use public servers from the pool.ntp.org project.
             # Please consider joining the pool (https://www.pool.ntp.org/join.html).
   
             # The Machine Config Operator manages this file
             server openshift-master-0.<cluster-name>.<domain> iburst 1
             server openshift-master-1.<cluster-name>.<domain> iburst
             server openshift-master-2.<cluster-name>.<domain> iburst
   
             stratumweight 0
             driftfile /var/lib/chrony/drift
             rtcsync
             makestep 10 3
             bindcmdaddress 127.0.0.1
             bindcmdaddress ::1
             keyfile /etc/chrony.keys
             commandkey 1
             generatecommandkey
             noclientlog
             logchange 0.5
             logdir /var/log/chrony
   
             # Configure the control plane nodes to serve as local NTP servers
             # for all compute nodes, even if they are not in sync with an
             # upstream NTP server.
   
             # Allow NTP client access from the local network.
             allow all
             # Serve time even if not synchronized to a time source.
             local stratum 3 orphan

   1

   <cluster-name> はクラスターの名前に置き換え、<domain> は完全修飾ドメイン名に置き換える必要があります。

3. Butane を使用して、コントロールプレーンノードに配信される設定が含まれる MachineConfig オブジェクトファイル (99-master-chrony-conf-override.yaml) を生成します。

   $ butane 99-master-chrony-conf-override.bu -o 99-master-chrony-conf-override.yaml

4. コントロールプレーンノード上の NTP サーバーを参照するコンピュートノードの chrony.conf ファイルの内容を含む Butane 設定 99-worker-chrony-conf-override.bu を作成します。

   Butane 設定例

   variant: openshift
   version: 4.16.0
   metadata:
     name: 99-worker-chrony-conf-override
     labels:
       machineconfiguration.openshift.io/role: worker
   storage:
     files:
       - path: /etc/chrony.conf
         mode: 0644
         overwrite: true
         contents:
           inline: |
             # The Machine Config Operator manages this file.
             server openshift-master-0.<cluster-name>.<domain> iburst 1
             server openshift-master-1.<cluster-name>.<domain> iburst
             server openshift-master-2.<cluster-name>.<domain> iburst
   
             stratumweight 0
             driftfile /var/lib/chrony/drift
             rtcsync
             makestep 10 3
             bindcmdaddress 127.0.0.1
             bindcmdaddress ::1
             keyfile /etc/chrony.keys
             commandkey 1
             generatecommandkey
             noclientlog
             logchange 0.5
             logdir /var/log/chrony

   1

   <cluster-name> はクラスターの名前に置き換え、<domain> は完全修飾ドメイン名に置き換える必要があります。

5. Butane を使用して、ワーカーノードに配信される設定が含まれる MachineConfig オブジェクトファイル (99-worker-chrony-conf-override.yaml) を生成します。

   $ butane 99-worker-chrony-conf-override.bu -o 99-worker-chrony-conf-override.yaml

手順

1. install-config.yaml ファイルを保存するディレクトリーに移動します。

   $ cd ~/clusterconfigs

2. manifests サブディレクトリーに切り替えます。

   $ cd manifests

3. cluster-network-avoid-workers-99-config.yaml という名前のファイルを作成します。

   $ touch cluster-network-avoid-workers-99-config.yaml

4. エディターで cluster-network-avoid-workers-99-config.yaml ファイルを開き、Operator 設定を記述するカスタムリソース (CR) を入力します。

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     name: 50-worker-fix-ipi-rwn
     labels:
       machineconfiguration.openshift.io/role: worker
   spec:
     config:
       ignition:
         version: 3.2.0
       storage:
         files:
           - path: /etc/kubernetes/manifests/keepalived.yaml
             mode: 0644
             contents:
               source: data:,

   このマニフェストは、ingressVIP 仮想 IP アドレスをコントロールプレーンノードに配置します。また、このマニフェストは、コントロールプレーンノードにのみ以下のプロセスをデプロイします。

   • openshift-ingress-operator
   • keepalived
5. cluster-network-avoid-workers-99-config.yaml ファイルを保存します。

6. manifests/cluster-ingress-default-ingresscontroller.yaml ファイルを作成します。

   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
     name: default
     namespace: openshift-ingress-operator
   spec:
     nodePlacement:
       nodeSelector:
         matchLabels:
           node-role.kubernetes.io/master: ""

7. manifests ディレクトリーのバックアップの作成を検討してください。インストーラーは、クラスターの作成時に manifests/ ディレクトリーを削除します。

8. cluster-scheduler-02-config.yml マニフェストを変更し、mastersSchedulable フィールドを true に設定して、コントロールプレーンノードをスケジュール対象にします。デフォルトでは、コントロールプレーンノードはスケジュール対象ではありません。以下に例を示します。

   $ sed -i "s;mastersSchedulable: false;mastersSchedulable: true;g" clusterconfigs/manifests/cluster-scheduler-02-config.yml

   注記

   この手順の完了後にコントロールプレーンノードをスケジュールできない場合には、クラスターのデプロイに失敗します。

手順

1. router-replicas.yaml ファイルを作成します。

   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
     name: default
     namespace: openshift-ingress-operator
   spec:
     replicas: <num-of-router-pods>
     endpointPublishingStrategy:
       type: HostNetwork
     nodePlacement:
       nodeSelector:
         matchLabels:
           node-role.kubernetes.io/worker: ""

   注記

   <num-of-router-pods> を適切な値に置き換えます。1 つのコンピュートノードのみを使用する場合は、replicas: を 1 に設定します。3 つ以上のコンピュートノードを使用する場合は、必要に応じて、replicas: をデフォルト値 2 から増やすことができます。

2. router-replicas.yaml ファイルを保存し、これを clusterconfigs/openshift ディレクトリーにコピーします。

   $ cp ~/router-replicas.yaml clusterconfigs/openshift/99_router-replicas.yaml

手順

1. マニフェストを作成します。

2. ノードに対応する BareMetalHost リソースファイルを変更します。

   $ vim clusterconfigs/openshift/99_openshift-cluster-api_hosts-*.yaml

3. BIOS 設定を BareMetalHost リソースの spec セクションに追加します。

   spec:
     firmware:
       simultaneousMultithreadingEnabled: true
       sriovEnabled: true
       virtualizationEnabled: true

   注記

   Red Hat は 3 つの BIOS 設定をサポートしています。BMC タイプirmcのサーバーのみがサポートされます。他のタイプのサーバーは現在サポートされていません。

4. クラスターを作成します。

手順

1. マニフェストを作成します。

2. ノードに対応する BareMetalHost リソースを変更します。

   $ vim clusterconfigs/openshift/99_openshift-cluster-api_hosts-*.yaml

   注記

   OpenShift Container Platform 4.16 はソフトウェア RAID をサポートしていないため、次の例ではハードウェア RAID 設定を使用します。

   1. 特定の RAID 設定を spec セクションに追加した場合、これが原因でノードは preparing フェーズで元の RAID 設定を削除し、RAID で指定された設定を実行します。以下に例を示します。

      spec:
        raid:
          hardwareRAIDVolumes:
          - level: "0" 1
            name: "sda"
            numberOfPhysicalDisks: 1
            rotational: true
            sizeGibibytes: 0

      1

      levelは必須フィールドであり、その他はオプションのフィールドです。

   2. spec セクションに空の RAID 設定を追加した場合、空の設定が原因で、ノードは preparing フェーズで元の RAID 設定を削除しますが、新しい設定は実行しません。以下に例を示します。

      spec:
        raid:
          hardwareRAIDVolumes: []

   3. spec セクションに raid フィールドを追加しない場合、元の RAID 設定は削除されず、新しい設定は実行されません。
3. クラスターを作成します。

1. custom-partitions.yaml ファイルを作成し、パーティションレイアウトを含む MachineConfig オブジェクトを含めます。

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: primary
     name: 10_primary_storage_config
   spec:
     config:
       ignition:
         version: 3.2.0
       storage:
         disks:
           - device: </dev/xxyN>
             partitions:
               - label: recovery
                 startMiB: 32768
                 sizeMiB: 16384
         filesystems:
           - device: /dev/disk/by-partlabel/recovery
             label: recovery
             format: xfs

2. custom-partitions.yaml ファイルを保存して、clusterconfigs/openshift ディレクトリーにコピーします。

   $ cp ~/<MachineConfig_manifest> ~/clusterconfigs/openshift

手順

1. レジストリーノードでファイアウォールポートを開きます。

   $ sudo firewall-cmd --add-port=5000/tcp --zone=libvirt  --permanent

   $ sudo firewall-cmd --add-port=5000/tcp --zone=public   --permanent

   $ sudo firewall-cmd --reload

2. レジストリーノードに必要なパッケージをインストールします。

   $ sudo yum -y install python3 podman httpd httpd-tools jq

3. リポジトリー情報が保持されるディレクトリー構造を作成します。

   $ sudo mkdir -p /opt/registry/{auth,certs,data}

手順

1. OpenShift Container Platform ダウンロード ページを確認し、インストールする必要のある OpenShift Container Platform のバージョンを判別し、Repository Tags ページで対応するタグを判別します。

2. 必要な環境変数を設定します。

   1. リリースバージョンをエクスポートします。

      $ OCP_RELEASE=<release_version>

      <release_version> について、インストールする OpenShift Container Platform のバージョンに対応するタグを指定します (例: 4.5.4)。

   2. ローカルレジストリー名とホストポートをエクスポートします。

      $ LOCAL_REGISTRY='<local_registry_host_name>:<local_registry_host_port>'

      <local_registry_host_name> については、ミラーレジストリーのレジストリードメイン名を指定し、<local_registry_host_port> については、コンテンツの送信に使用するポートを指定します。

   3. ローカルリポジトリー名をエクスポートします。

      $ LOCAL_REPOSITORY='<local_repository_name>'

      <local_repository_name> については、ocp4/openshift4 などのレジストリーに作成するリポジトリーの名前を指定します。

   4. ミラーリングするリポジトリーの名前をエクスポートします。

      $ PRODUCT_REPO='openshift-release-dev'

      実稼働環境のリリースの場合には、openshift-release-dev を指定する必要があります。

   5. パスをレジストリープルシークレットにエクスポートします。

      $ LOCAL_SECRET_JSON='<path_to_pull_secret>'

      <path_to_pull_secret> については、作成したミラーレジストリーのプルシークレットの絶対パスおよびファイル名を指定します。

   6. リリースミラーをエクスポートします。

      $ RELEASE_NAME="ocp-release"

      実稼働環境のリリースについては、ocp-release を指定する必要があります。

   7. クラスターのアーキテクチャーのタイプをエクスポートします。

      $ ARCHITECTURE=<cluster_architecture> 1

      1

      x86_64、aarch64、s390x、または ppc64le など、クラスターのアーキテクチャーを指定します。

   8. ミラーリングされたイメージをホストするためにディレクトリーへのパスをエクスポートします。

      $ REMOVABLE_MEDIA_PATH=<path> 1

      1

      最初のスラッシュ (/) 文字を含む完全パスを指定します。

3. バージョンイメージをミラーレジストリーにミラーリングします。

   • ミラーホストがインターネットにアクセスできない場合は、以下の操作を実行します。

     1. リムーバブルメディアをインターネットに接続しているシステムに接続します。

     2. ミラーリングするイメージおよび設定マニフェストを確認します。

        $ oc adm release mirror -a ${LOCAL_SECRET_JSON}  \
             --from=quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE} \
             --to=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} \
             --to-release-image=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE} --dry-run

     3. 直前のコマンドの出力の imageContentSources セクション全体を記録します。ミラーの情報はミラーリングされたリポジトリーに一意であり、インストール時に imageContentSources セクションを install-config.yaml ファイルに追加する必要があります。

     4. イメージをリムーバブルメディア上のディレクトリーにミラーリングします。

        $ oc adm release mirror -a ${LOCAL_SECRET_JSON} --to-dir=${REMOVABLE_MEDIA_PATH}/mirror quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE}

     5. メディアをネットワークが制限された環境に移し、イメージをローカルコンテナーレジストリーにアップロードします。

        $ oc image mirror -a ${LOCAL_SECRET_JSON} --from-dir=${REMOVABLE_MEDIA_PATH}/mirror "file://openshift/release:${OCP_RELEASE}*" ${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} 1

        1

        REMOVABLE_MEDIA_PATH の場合、イメージのミラーリング時に指定した同じパスを使用する必要があります。

   • ローカルコンテナーレジストリーがミラーホストに接続されている場合は、以下の操作を実行します。

     1. 以下のコマンドを使用して、リリースイメージをローカルレジストリーに直接プッシュします。

        $ oc adm release mirror -a ${LOCAL_SECRET_JSON}  \
             --from=quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE} \
             --to=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} \
             --to-release-image=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}

        このコマンドは、リリース情報をダイジェストとしてプルします。その出力には、クラスターのインストール時に必要な imageContentSources データが含まれます。

     2. 直前のコマンドの出力の imageContentSources セクション全体を記録します。ミラーの情報はミラーリングされたリポジトリーに一意であり、インストール時に imageContentSources セクションを install-config.yaml ファイルに追加する必要があります。

        注記

        ミラーリングプロセス中にイメージ名に Quay.io のパッチが適用され、podman イメージにはブートストラップ仮想マシンのレジストリーに Quay.io が表示されます。

4. ミラーリングしたコンテンツに基づくインストールプログラムを作成するために、インストールプログラムを展開してリリースに固定します。

   • ミラーホストがインターネットにアクセスできない場合は、以下のコマンドを実行します。

     $ oc adm release extract -a ${LOCAL_SECRET_JSON} --command=openshift-baremetal-install "${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}"

   • ローカルコンテナーレジストリーがミラーホストに接続されている場合は、以下のコマンドを実行します。

     $ oc adm release extract -a ${LOCAL_SECRET_JSON} --command=openshift-baremetal-install "${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}"

     重要

     選択した OpenShift Container Platform のバージョンに適したイメージを確実に使用するために、ミラーリングしたコンテンツからインストールプログラムを展開する必要があります。

     インターネット接続のあるマシンで、このステップを実行する必要があります。

     非接続環境を使用している場合には、must-gather の一部として --image フラグを使用し、ペイロードイメージを参照します。

5. installer-provisioned infrastructure を使用するクラスターの場合は、以下のコマンドを実行します。

   $ openshift-baremetal-install

手順

1. 非接続レジストリーノードの証明書を install-config.yaml ファイルに追加します。

   $ echo "additionalTrustBundle: |" >> install-config.yaml

   証明書は "additionalTrustBundle: |" 行に従い、通常は 2 つのスペースで適切にインデントされる必要があります。

   $ sed -e 's/^/  /' /opt/registry/certs/domain.crt >> install-config.yaml

2. レジストリーのミラー情報を install-config.yaml ファイルに追加します。

   $ echo "imageContentSources:" >> install-config.yaml

   $ echo "- mirrors:" >> install-config.yaml

   $ echo "  - registry.example.com:5000/ocp4/openshift4" >> install-config.yaml

   registry.example.com をレジストリーの完全修飾ドメイン名に置き換えます。

   $ echo "  source: quay.io/openshift-release-dev/ocp-release" >> install-config.yaml

   $ echo "- mirrors:" >> install-config.yaml

   $ echo "  - registry.example.com:5000/ocp4/openshift4" >> install-config.yaml

   registry.example.com をレジストリーの完全修飾ドメイン名に置き換えます。

   $ echo "  source: quay.io/openshift-release-dev/ocp-v4.0-art-dev" >> install-config.yaml