第18章 OpenStack へのインストール


18.1. OpenStack へのインストールの準備

Red Hat OpenStack Platform (RHOSP) に OpenShift Container Platform をインストールできます。

18.1.1. 前提条件

18.1.2. OpenStack に OpenShift Container Platform をインストールする方法の選択

OpenShift Container Platform をインストーラーまたはユーザーによってプロビジョニングされるインフラストラクチャーにインストールすることができます。デフォルトのインストールタイプは、インストーラーでプロビジョニングされるインフラストラクチャーを使用します。この場合、インストールプログラムがクラスターの基礎となるインフラストラクチャーをプロビジョニングします。OpenShift Container Platform は、ユーザーによってプロビジョニングされるインフラストラクチャーにインストールすることもできます。インストールプログラムがプロビジョニングするインフラストラクチャーを使用しない場合は、クラスターリソースをユーザー自身で管理し、維持する必要があります。

インストーラーおよびユーザーによってプロビジョニングされるインストールプロセスの詳細は、インストールプロセス を参照してください。

18.1.2.1. インストーラーでプロビジョニングされるインフラストラクチャーへのクラスターのインストール

以下の方法のいずれかを使用して、OpenShift Container Platform インストールプログラムでプロビジョニングされる Red Hat OpenStack Platform (RHOSP) インフラストラクチャーに、クラスターをインストールできます。

  • カスタマイズによる OpenStack へのクラスターのインストール: カスタマイズされたクラスターを RHOSP にインストールできます。インストールプログラムは、インストールの段階で一部のカスタマイズを適用できるようにします。その他の数多くのカスタマイズオプションは、インストール後 に利用できます。
  • Kuryr を使用した OpenStack へのクラスターのインストール: Kuryr SDN を使用する RHOSP にカスタマイズされた OpenShift Container Platform クラスターをインストールできます。Kuryr と OpenShift Container Platform の統合は主に、RHOSP の仮想マシンで実行する OpenShift Container Platform クラスター用に設計されました。Kuryr は、OpenShift Container Platform Pod を RHOSP SDN にプラグインしてネットワークのパフォーマンスを強化します。さらに、これは Pod と RHOSP 仮想インスタンス間の接続を可能にします。
  • ネットワークが制限された環境での OpenStack へのクラスターのインストール: インストールリリースコンテンツの内部ミラーを作成して、OpenShift Container Platform をネットワークが制限された環境またはネットワークの非接続環境で RHOSP にインストールできます。この方法を使用して、ソフトウェアコンポーネントを取得するためにアクティブなインターネット接続を必要としないクラスターをインストールできます。また、このインストール方法を使用して、クラスターが外部コンテンツに対する組織の制御の条件を満たすコンテナーイメージのみを使用するようにすることもできます。

18.1.2.2. ユーザーによってプロビジョニングされるインフラストラクチャーへのクラスターのインストール

以下の方法のいずれかを使用して、独自にプロビジョニングする RHOSP インフラストラクチャーにクラスターをインストールできます。

18.1.3. RHOSP エンドポイントをスキャンしてレガシー HTTPS 証明書を探す

OpenShift Container Platform 4.10 以降、HTTPS 証明書にはサブジェクト代替名 (SAN) フィールドが含まれている必要があります。次のスクリプトを実行して、Red Hat Open Stack Platform (RHOSP) カタログ内の各 HTTPS エンドポイントをスキャンし、CommonName フィールドのみを含むレガシー証明書を探します。

重要

OpenShift Container Platform は、インストールまたは更新の前に、基盤となる RHOSP インフラストラクチャーのレガシー証明書をチェックしません。提供されているスクリプトを使用して、これらの証明書をご自身で確認してください。クラスターをインストールまたは更新する前にレガシー証明書を更新しないと、クラスターが機能しなくなります。

前提条件

手順

  1. 次のスクリプトをマシンに保存します。

    #!/usr/bin/env bash
    
    set -Eeuo pipefail
    
    declare catalog san
    catalog="$(mktemp)"
    san="$(mktemp)"
    readonly catalog san
    
    declare invalid=0
    
    openstack catalog list --format json --column Name --column Endpoints \
    	| jq -r '.[] | .Name as $name | .Endpoints[] | select(.interface=="public") | [$name, .interface, .url] | join(" ")' \
    	| sort \
    	> "$catalog"
    
    while read -r name interface url; do
    	# Ignore HTTP
    	if [[ ${url#"http://"} != "$url" ]]; then
    		continue
    	fi
    
    	# Remove the schema from the URL
    	noschema=${url#"https://"}
    
    	# If the schema was not HTTPS, error
    	if [[ "$noschema" == "$url" ]]; then
    		echo "ERROR (unknown schema): $name $interface $url"
    		exit 2
    	fi
    
    	# Remove the path and only keep host and port
    	noschema="${noschema%%/*}"
    	host="${noschema%%:*}"
    	port="${noschema##*:}"
    
    	# Add the port if was implicit
    	if [[ "$port" == "$host" ]]; then
    		port='443'
    	fi
    
    	# Get the SAN fields
    	openssl s_client -showcerts -servername "$host" -connect "$host:$port" </dev/null 2>/dev/null \
    		| openssl x509 -noout -ext subjectAltName \
    		> "$san"
    
    	# openssl returns the empty string if no SAN is found.
    	# If a SAN is found, openssl is expected to return something like:
    	#
    	#    X509v3 Subject Alternative Name:
    	#        DNS:standalone, DNS:osp1, IP Address:192.168.2.1, IP Address:10.254.1.2
    	if [[ "$(grep -c "Subject Alternative Name" "$san" || true)" -gt 0 ]]; then
    		echo "PASS: $name $interface $url"
    	else
    		invalid=$((invalid+1))
    		echo "INVALID: $name $interface $url"
    	fi
    done < "$catalog"
    
    # clean up temporary files
    rm "$catalog" "$san"
    
    if [[ $invalid -gt 0 ]]; then
    	echo "${invalid} legacy certificates were detected. Update your certificates to include a SAN field."
    	exit 1
    else
    	echo "All HTTPS certificates for this cloud are valid."
    fi
  2. スクリプトを実行します。
  3. スクリプトが INVALID と報告する証明書を、SAN フィールドを含む証明書に置き換えます。
重要

OpenShift Container Platform 4.10 をインストールする前、またはクラスターをそのバージョンに更新する前に、すべてのレガシー HTTPS 証明書を置き換える必要があります。レガシー証明書は、次のメッセージで拒否されます。

x509: certificate relies on legacy Common Name field, use SANs instead

18.1.3.1. RHOSP エンドポイントをスキャンしてレガシー HTTPS 証明書を手動で探す

OpenShift Container Platform 4.10 以降、HTTPS 証明書にはサブジェクト代替名 (SAN) フィールドが含まれている必要があります。「レガシー HTTPS 証明書の RHOSP エンドポイントのスキャン」にリストされている前提条件ツールにアクセスできない場合は、次の手順を実行して、Red Hat OpenStack Platform (RHOSP) カタログ内の各 HTTPS エンドポイントをスキャンして、CommonName フィールドのみを含むレガシー証明書の Red Hat OpenStack Platform (RHOSP) カタログで各 HTTPS エンドポイントをスキャンします。

重要

OpenShift Container Platform は、インストールまたは更新の前に、基盤となる RHOSP インフラストラクチャーのレガシー証明書をチェックしません。これらの証明書を自分で確認するには、次の手順を使用します。クラスターをインストールまたは更新する前にレガシー証明書を更新しないと、クラスターが機能しなくなります。

手順

  1. コマンドラインで次のコマンドを実行して、RHOSP パブリックエンドポイントの URL を表示します。

    $ openstack catalog list

    コマンドが返す各 HTTPS エンドポイントの URL を記録します。

  2. 各パブリックエンドポイントについて、ホストとポートをメモします。

    ヒント

    スキーム、ポート、およびパスを削除して、エンドポイントのホストを決定します。

  3. エンドポイントごとに次のコマンドを実行して、証明書の SAN フィールドを抽出します。

    1. host 変数を設定します。

      $ host=<host_name>
    2. port 変数を設定します。

      $ port=<port_number>

      エンドポイントの URL にポートがない場合は、値 443 を使用します。

    3. 証明書の SAN フィールドを取得します。

      $ openssl s_client -showcerts -servername "$host" -connect "$host:$port" </dev/null 2>/dev/null \
          | openssl x509 -noout -ext subjectAltName

      出力例

      X509v3 Subject Alternative Name:
          DNS:your.host.example.net

      各エンドポイントについて、前の例に似た出力を探します。エンドポイントの出力がない場合、そのエンドポイントの証明書は無効であるため、再発行する必要があります。

重要

OpenShift Container Platform 4.10 をインストールする前、またはクラスターをそのバージョンに更新する前に、すべてのレガシー HTTPS 証明書を置き換える必要があります。従来の証明書は拒否され、次のメッセージが表示されます。

x509: certificate relies on legacy Common Name field, use SANs instead
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.