チュートリアル

1. AWS コンソールページ で Get started ボタンをクリックして、ROSA with HCP 製品をアクティブ化します。

   図2.1 使用してみる

   

   以前に ROSA をアクティブ化したが、プロセスを完了していない場合は、ボタンをクリックして、次の手順で説明するようにアカウントのリンクを完了できます。

2. 連絡先情報を Red Hat と共有することを確認し、サービスを有効にします。

   図2.2 ROSA の有効化

   
   • このステップでサービスを有効にしても料金は発生しません。課金と計測が連携されるのは、最初のクラスターをデプロイした後のみです。これには数分かかる場合があります。

3. プロセスが完了すると、確認メッセージが表示されます。

   図2.3 ROSA 有効化の確認

   

4. この検証ページの他のセクションには、追加の前提条件 (が満たされているかどうか) のステータスが表示されます。これらの前提条件のいずれかが満たされていない場合は、対応するメッセージが表示されます。選択したリージョンで割り当てが不十分な例を次に示します。

   図2.4 サービスクォータ

   
   1. Increase service quotas ボタンをクリックするか、Learn more リンクを使用して、サービスクォータの管理方法に関する詳細情報を取得します。クォータが不十分な場合、クォータはリージョン固有であることに注意してください。Web コンソールの右上隅にあるリージョンスイッチャーを使用して、関心のあるリージョンのクォータチェックを再実行し、必要に応じてサービスクォータの増加リクエストを送信できます。

5. すべての前提条件が満たされている場合、ページは次のようになります。

   図2.5 ROSA の前提条件の確認

   

   ELB サービスにリンクされたロールは自動的に作成されます。青色の小さな Info リンクをクリックすると、状況に応じたヘルプやリソースが表示されます。

1. オレンジ色の Continue to Red Hat ボタンをクリックして、アカウントのリンクを続行します。

   図2.6 Red Hat に進む

   

2. 現在のブラウザーのセッションで Red Hat アカウントにまだログインしていない場合は、アカウントにログインするように求められます。

   注記

   お使いの AWS アカウントが 1 つの Red Hat 組織にリンクされている必要があります。

   図2.7 Red Hat アカウントへのログイン

   
   • このページでは、新しい Red Hat アカウントに登録したり、パスワードをリセットしたりすることもできます。
   • 前の手順で ROSA with HCP をアクティブ化した AWS アカウントに関連付ける予定の Red Hat アカウントにログインしてください。
   • サービスの請求に使用する AWS アカウントは、1 つの Red Hat アカウントにのみ関連付けることができます。通常は、AWS 支払者のアカウントが、ROSA へのサブスクライブと、アカウントのリンクおよび請求に使用されます。
   • 同じ Red Hat 組織に属するすべてのチームメンバーが、ROSA with HCP クラスターの作成中に、サービスの請求用にリンクされた AWS アカウントを使用できます。

3. 利用規約を確認した後、Red Hat アカウントの連携を完了させます。

   注記

   この手順は、AWS アカウントが以前にどの Red Hat アカウントにもリンクされていない場合にのみ使用できます。

   ユーザーがログイン中の Red Hat アカウントに AWS アカウントがすでにリンクされている場合、この手順はスキップされます。

   AWS アカウントが別の Red Hat アカウントにリンクされている場合は、エラーが表示されます。トラブルシューティングについては、Correcting Billing Account Information for HCP clusters を参照してください。

   図2.8 アカウント連携の完了

   

   Red Hat と AWS の両方のアカウント番号がこの画面に表示されます。

4. サービス規約に同意する場合は、Connect accounts ボタンをクリックします。

   Red Hat Hybrid Cloud Console を初めて使用する場合は、最初の ROSA クラスターを作成する前に、一般的なマネージドサービスの利用規約に同意するよう求められます。

   図2.9 利用規約

   

   View Terms and Conditions ボタンをクリックすると、確認して同意する必要がある追加の利用規約が表示されます。

   図2.10 Red Hat の利用規約

   

   この時点で追加の条件を確認し、プロンプトが表示されたら同意を確定します。

5. Hybrid Cloud Console に、AWS アカウントのセットアップ完了に関する確認メッセージと、クラスターのデプロイの前提条件が表示されます。

   図2.11 ROSA の前提条件の完了

   

   このページの最後のセクションでは、rosa CLI または Web コンソールを使用したクラスターデプロイメントオプションを示します。

   図2.12 クラスターのデプロイとアクセスの設定

   

1. rosa create cluster コマンドを使用してクラスターのデプロイを開始します。コンソールの Set up Red Hat OpenShift Service on AWS (ROSA) ページ で コピー ボタンをクリックし、コマンドをターミナルに貼り付けることができます。これにより、クラスター作成プロセスが対話モードで起動します。

   図2.13 クラスターのデプロイとアクセスの設定

   
2. カスタムの AWS プロファイルを使用するには、~/.aws/credentials で指定したデフォルト以外のプロファイルのいずれかを使用します。rosa create cluster コマンドに –profile <profile_name> のセレクターを追加すると、コマンドは rosa create cluster –profile stage のようになります。このオプションを使用して、AWS CLI プロファイルが指定されていない場合は、デフォルトの AWS CLI プロファイルにより、AWS インフラストラクチャーのプロファイルがどのクラスターにデプロイされるかが決定されます。請求用 AWS プロファイルは、次のいずれかの手順で選択します。

3. ROSA with HCP クラスターをデプロイする場合、請求先の AWS アカウントを指定する必要があります。

   図2.14 請求先アカウントの指定

   
   • ユーザーがログイン中の Red Hat アカウントにリンクされている AWS アカウントのみが表示されます。
   • 指定した AWS アカウントに ROSA サービスの使用料が課金されます。

   • 特定の AWS 請求先アカウントに対して ROSA の契約が有効になっているかどうかが表示されます。

     • Contract enabled というラベルが表示されている AWS 請求先アカウントを選択した場合、前払い済みの契約の容量が消費されるまで、オンデマンドの消費料金は課金されません。
     • Contract enabled というラベルのない AWS アカウントには、該当するオンデマンド消費料金が課金されます。

1. Web コンソールを使用してクラスターを作成するには、ROSA のセットアップ ページの下部セクションにある 2 番目のオプションを選択します。

   図2.15 Web インターフェイスでのデプロイ

   
   注記

   Web コンソールでのデプロイプロセスを開始する前に、前提条件を完了してください。

   アカウントロールの作成など、一部のタスクには rosa CLI が必要です。ROSA を初めてデプロイする場合は、CLI の手順に従い、rosa whoami コマンドを実行した後に、Web コンソールでのデプロイ手順を開始してください。

2. Web コンソールを使用して ROSA クラスターを作成する場合の最初のステップは、コントロールプレーンの選択です。Next ボタンをクリックする前に、Hosted オプションが選択されていることを確認してください。

   図2.16 Hosted オプションの選択

   

3. 次のステップ Accounts and roles では、インフラストラクチャー AWS アカウントを指定できます。このアカウントが ROSA クラスターのデプロイ先となり、そこでリソースが消費および管理されます。

   図2.17 AWS インフラストラクチャーアカウント

   
   • ROSA クラスターのデプロイ先のアカウントが表示されない場合は、How to associate a new AWS account をクリックして、この関連付けに関して、アカウントロールの作成またはリンクの情報を参照してください。
   • これには rosa CLI を使用します。
   • 複数の AWS アカウントを使用しており、それらのプロファイルが AWS CLI 用に設定されている場合は、rosa CLI コマンドを使用するときに --profile セレクターを使用して AWS プロファイルを指定できます。

4. 請求先の AWS アカウントは、すぐ次のセクションで選択されます。

   図2.18 AWS 請求先アカウント

   
   • ユーザーがログイン中の Red Hat アカウントにリンクされている AWS アカウントのみが表示されます。
   • 指定した AWS アカウントに ROSA サービスの使用料が課金されます。

   • 特定の AWS 請求先アカウントに対して ROSA の契約が有効になっているかどうかが表示されます。

     • Contract enabled というラベルが表示されている AWS 請求先アカウントを選択した場合、前払い済みの契約の容量が消費されるまで、オンデマンドの消費料金は課金されません。
     • Contract enabled というラベルのない AWS アカウントには、該当するオンデマンド消費料金が課金されます。

1. ROSA with HCP のプライベートオファーを承認すると、販売者が指定した特定の AWS アカウント ID でのみアクセスできる一意の URL が提供されます。

   注記

   購入者として指定された AWS アカウントを使用してログインしていることを確認してください。別の AWS アカウントを使用してオファーにアクセスしようとすると、以下のトラブルシューティングセクションの図 11 に示すように、"page not found" というエラーメッセージが表示されます。

   1. 図 1 はオファー選択ドロップダウンメニューを示しています。通常のプライベートオファーが事前に選択されています。このタイプのオファーは、パブリックオファーまたは別のプライベートオファーを使用する前に ROSA with HCP がアクティブ化されていない場合にのみ承認することができます。

      図3.1 通常のプライベートオファー

      

   2. 図 2 は、以前にパブリックオファーを使用して ROSA with HCP をアクティブ化した AWS アカウント用に作成されたプライベートオファーを示しています。製品名が表示され、"Upgrade" というラベルの付いたプライベートオファーが選択されています。このオファーを承認すると、現在締結中の ROSA with HCP の契約が置き換えられます。

      図3.2 プライベートオファー選択画面

      

   3. ドロップダウンメニューを使用して、複数のオファーから選択できます (利用可能な場合)。以前にアクティブ化されたパブリックオファーは、図 3 のように、"Upgrade" というラベルが付いた、新しく提供された同意ベースのオファーと一緒に表示されます。

      図3.3 プライベートオファー選択ドロップダウン

      

2. オファー設定が選択されていることを確認します。図 4 は、オファーの詳細が記載されたオファーページの下部を示しています。

   注記

   契約終了日、オファーに含まれるユニット数、および支払いスケジュールが表示されます。この例には、1 つのクラスターと、4 つの仮想 CPU を使用する最大 3 つのノードが含まれています。

   図3.4 プライベートオファーの詳細

   

3. オプション: 購入するサブスクリプションに 独自の注文書 (PO) 番号を追加 して、後の AWS 請求書にその番号を含めることができます。また、"New offer configuration details" の範囲を超える使用量に対して課金される "Additional usage fees" を確認します。

   注記

   プライベートオファーには、利用可能な設定がいくつかあります。

   • 承認するプライベートオファーに、固定された将来の開始日が設定されている可能性があります。
   • プライベートオファー、パブリックオファー、または古いプライベートオファーのエンタイトルメントを承認する時点で、別のアクティブな ROSA with HCP サブスクリプションがない場合は、プライベートオファー自体を承認し、指定されたサービス開始日以降にアカウントのリンク手順とクラスターのデプロイ手順を続行します。

   これらの手順を完了するには、ROSA with HCP の有効なエンタイトルメントが必要です。サービス開始日は、常に UTC タイムゾーンで表示されます。

4. 契約を作成またはアップグレードします。

   1. ROSA with HCP をまだアクティブ化しておらず、このサービス用の契約を初めて作成する AWS アカウントによってプライベートオファーを承認する場合は、Create contract ボタンをクリックします。

      図3.5 Create contract ボタン

      

   2. 同意ベースのオファーの場合は、Upgrade current contract ボタンをクリックします (図 4 および 6 を参照)。

      図3.6 Upgrade current contract ボタン

      

5. Confirm をクリックします。

   図3.7 プライベートオファー承認の確認ウィンドウ

   

6. 承認するプライベートオファーのサービス開始日がオファー承認の直後に設定されている場合、確認モーダルウィンドウで Set up your account ボタンをクリックします。

   図3.8 サブスクリプションの確認

   

7. 承認するプライベートオファーに将来の開始日が指定されている場合は、サービス開始日後にプライベートオファーページに戻り、Setup your account ボタンをクリックして、Red Hat と AWS アカウントのリンクを続行します。

   注記

   同意が有効でない場合、以下に説明するアカウントリンクがトリガーされず、"アカウントのセットアップ" プロセスを "Service start date" 以降まで実行できません。

   これらの日付は常に UTC タイムゾーンの日付です。

1. 前の手順で Set up your account ボタンをクリックすると、AWS と Red Hat のアカウントをリンクする手順に進みます。この時点で、オファーを承認した AWS アカウントですでにログインしています。Red Hat アカウントでログインしていない場合は、ログインするように求められます。

   ROSA with HCP のエンタイトルメントは、Red Hat 組織アカウントを通じて他のチームメンバーと共有されます。同じ Red Hat 組織内の既存の全ユーザーは、上記の手順に従って、プライベートオファーを承認した請求 AWS アカウントを選択できます。Red Hat 組織管理者としてログインしている場合は、Red Hat 組織内のユーザーを管理 し、新しいユーザーを招待したり作成したりできます。

   注記

   ROSA with HCP のプライベートオファーは、AWS License Manager を通じて AWS にリンクされたアカウントと共有することはできません。

2. ROSA クラスターをデプロイするユーザーを追加します。Red Hat アカウントのユーザー管理タスクの詳細は、こちらのユーザー管理に関する FAQ を参照してください。
3. すでにログインしている Red Hat アカウントに、承認されたプライベートオファーを利用し、ROSA クラスターをデプロイするユーザーがすべて含まれていることを確認します。

4. Red Hat アカウント番号と AWS アカウント ID が、リンクさせる目的のアカウントであることを確認します。このリンクは一意であり、Red Hat アカウントと連携できるのは 1 つの AWS (請求先) アカウントだけです。

   図3.9 AWS と Red Hat アカウントの連携

   

5. AWS アカウントを、このページの図 9 に示されているもの以外の Red Hat アカウントにリンクする場合は、アカウントを連携する前に Red Hat Hybrid Cloud Console からログアウトし、すでに承認されているプライベートオファー URL に戻ってアカウントの設定手順を再度実行します。

   AWS アカウントと連携できるのは、1 つの Red Hat アカウントだけです。Red Hat アカウントと AWS アカウントを連携すると、ユーザーはこれを変更できなくなります。変更が必要な場合、ユーザーはサポートチケットを作成する必要があります。

6. 利用規約に同意して、Connect accounts をクリックします。

1. スクリプトを使用するには、bash ターミナルで次のコマンドを実行します (-p オプションはロールの接頭辞を定義します)。

   $ mkdir scratch
   $ cd scratch
   $ cat << 'EOF' > verify-permissions.sh
   #!/bin/bash
   while getopts 'p:' OPTION; do
     case "$OPTION" in
       p)
         PREFIX="$OPTARG"
         ;;
       ?)
         echo "script usage: $(basename \$0) [-p PREFIX]" >&2
         exit 1
         ;;
     esac
   done
   shift "$(($OPTIND -1))"
   rosa create account-roles --mode manual --prefix $PREFIX
   INSTALLER_POLICY=$(cat sts_installer_permission_policy.json | jq )
   CONTROL_PLANE_POLICY=$(cat sts_instance_controlplane_permission_policy.json | jq)
   WORKER_POLICY=$(cat sts_instance_worker_permission_policy.json | jq)
   SUPPORT_POLICY=$(cat sts_support_permission_policy.json | jq)
   simulatePolicy () {
       outputFile="${2}.results"
       echo $2
       aws iam simulate-custom-policy --policy-input-list "$1" --action-names $(jq '.Statement | map(select(.Effect == "Allow"))[].Action | if type == "string" then . else .[] end' "$2" -r) --output text > $outputFile
   }
   simulatePolicy "$INSTALLER_POLICY" "sts_installer_permission_policy.json"
   simulatePolicy "$CONTROL_PLANE_POLICY" "sts_instance_controlplane_permission_policy.json"
   simulatePolicy "$WORKER_POLICY" "sts_instance_worker_permission_policy.json"
   simulatePolicy "$SUPPORT_POLICY" "sts_support_permission_policy.json"
   EOF
   $ chmod +x verify-permissions.sh
   $ ./verify-permissions.sh -p SimPolTest

2. スクリプトが完了したら、各結果ファイルを確認して、必要な API 呼び出しがブロックされていないことを確認します。

   $ for file in $(ls *.results); do echo $file; cat $file; done

   出力は以下のようになります。

   sts_installer_permission_policy.json.results
   EVALUATIONRESULTS       autoscaling:DescribeAutoScalingGroups   allowed *
   MATCHEDSTATEMENTS       PolicyInputList.1       IAM Policy
   ENDPOSITION     6       195
   STARTPOSITION   17      3
   EVALUATIONRESULTS       ec2:AllocateAddress     allowed *
   MATCHEDSTATEMENTS       PolicyInputList.1       IAM Policy
   ENDPOSITION     6       195
   STARTPOSITION   17      3
   EVALUATIONRESULTS       ec2:AssociateAddress    allowed *
   MATCHEDSTATEMENTS       PolicyInputList.1       IAM Policy
   ...

   注記

   アクションがブロックされている場合は、AWS が提供するエラーを確認し、管理者に相談して、SCP によって必要な API 呼び出しがブロックされているかどうかを判断してください。

1. 次の環境変数を設定します。

   $ export VPC_ID=<vpc_ID> 1
   $ export REGION=<region> 2
   $ export VPC_CIDR=<vpc_CIDR> 3

   1

   <vpc_ID> は、クラスターをインストールする VPC の ID に置き換えます。

   2

   <region> は、クラスターをインストールする AWS リージョンに置き換えます。

   3

   <vpc_CIDR> は、VPC の CIDR 範囲に置き換えます。

2. 次のセクションに進む前に、すべてのフィールドが正しく出力されていることを確認してください。

   $ echo "VPC ID: ${VPC_ID}, VPC CIDR Range: ${VPC_CIDR}, Region: ${REGION}"

1. セキュリティーグループを作成し、VPC からポート 53/tcp および 53/udp へのアクセスを許可します。

   $ SG_ID=$(aws ec2 create-security-group --group-name rosa-inbound-resolver --description "Security group for ROSA inbound resolver" --vpc-id ${VPC_ID} --region ${REGION} --output text)
   $ aws ec2 authorize-security-group-ingress --group-id ${SG_ID} --protocol tcp --port 53 --cidr ${VPC_CIDR} --region ${REGION}
   $ aws ec2 authorize-security-group-ingress --group-id ${SG_ID} --protocol udp --port 53 --cidr ${VPC_CIDR} --region ${REGION}

2. VPC に Amazon Route 53 Inbound Resolver を作成します。

   $ RESOLVER_ID=$(aws route53resolver create-resolver-endpoint \
     --name rosa-inbound-resolver \
     --creator-request-id rosa-$(date '+%Y-%m-%d') \
     --security-group-ids ${SG_ID} \
     --direction INBOUND \
     --ip-addresses $(aws ec2 describe-subnets --filter Name=vpc-id,Values=${VPC_ID} --region ${REGION} | jq -jr '.Subnets | map("SubnetId=\(.SubnetId) ") | .[]') \
     --region ${REGION} \
     --output text \
     --query 'ResolverEndpoint.Id')

   注記

   上記のコマンドは、動的に割り当てられた IP アドレスを使用して、指定した VPC 内の すべてのサブネット に Amazon Route 53 Inbound Resolver エンドポイントをアタッチします。サブネットや IP アドレスを手動で指定する場合は、代わりに次のコマンドを実行します。

   $ RESOLVER_ID=$(aws route53resolver create-resolver-endpoint \
     --name rosa-inbound-resolver \
     --creator-request-id rosa-$(date '+%Y-%m-%d') \
     --security-group-ids ${SG_ID} \
     --direction INBOUND \
     --ip-addresses SubnetId=<subnet_ID>,Ip=<endpoint_IP> SubnetId=<subnet_ID>,Ip=<endpoint_IP> \1
     --region ${REGION} \
     --output text \
     --query 'ResolverEndpoint.Id')

   1

   <subnet_ID> はサブネット ID に、<endpoint_IP> はインバウンドリゾルバーエンドポイントを追加する静的 IP アドレスに置き換えます。

3. DNS サーバー設定で指定するインバウンドリゾルバーエンドポイントの IP アドレスを取得します。

   $ aws route53resolver list-resolver-endpoint-ip-addresses \
     --resolver-endpoint-id ${RESOLVER_ID} \
     --region=${REGION} \
     --query 'IpAddresses[*].Ip'

   出力例

   [
       "10.0.45.253",
       "10.0.23.131",
       "10.0.148.159"
   ]

手順

1. 秘密鍵と公開証明書から新しい TLS シークレットを作成します。fullchain.pem は完全なワイルドカード証明書チェーン (中間証明書を含む)、privkey.pem はワイルドカード証明書の秘密鍵です。

   例

   $ oc -n openshift-ingress create secret tls waf-tls --cert=fullchain.pem --key=privkey.pem

2. 新規の IngressController リソースを作成します。

   waf-Ingress-controller.yaml の例

   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
     name: cloudfront-waf
     namespace: openshift-ingress-operator
   spec:
     domain: apps.example.com 1
     defaultCertificate:
       name: waf-tls
     endpointPublishingStrategy:
       loadBalancer:
         dnsManagementPolicy: Unmanaged
         providerParameters:
           aws:
             type: NLB
           type: AWS
         scope: External
       type: LoadBalancerService
     routeSelector: 2
       matchLabels:
        route: waf

   1

   IngressController に使用するカスタムドメインに置き換えます。

   2

   Ingress Controller によって提供されるルートのセットをフィルタリングします。このチュートリアルでは waf ルートセレクターを使用しますが、値を指定しないと、フィルター処理は行われません。

3. IngressController を適用します。

   例

   $ oc apply -f waf-ingress-controller.yaml

4. IngressController が外部ロードバランサーを正常に作成したことを確認します。

   $ oc -n openshift-ingress get service/router-cloudfront-waf

   出力例

   NAME                    TYPE           CLUSTER-IP      EXTERNAL-IP                                                                     PORT(S)                      AGE
   router-cloudfront-waf   LoadBalancer   172.30.16.141   a68a838a7f26440bf8647809b61c4bc8-4225395f488830bd.elb.us-east-1.amazonaws.com   80:30606/TCP,443:31065/TCP   2m19s

1. 新しく作成されたカスタム Ingress Controller の NLB ホスト名を取得します。

   $ NLB=$(oc -n openshift-ingress get service router-cloudfront-waf \
     -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')

2. 証明書を Amazon Certificate Manager にインポートします。cert.pem はワイルドカード証明書、fullchain.pem はワイルドカード証明書のチェーン、privkey.pem はワイルドカード証明書の秘密鍵です。

   注記

   この証明書は、クラスターがデプロイされているリージョンに関係なく us-east-1 にインポートする必要があります。Amazon CloudFront はグローバル AWS サービスであるためです。

   例

   $ aws acm import-certificate --certificate file://cert.pem \
     --certificate-chain file://fullchain.pem \
     --private-key file://privkey.pem \
     --region us-east-1

3. AWS コンソール にログインして、CloudFront ディストリビューションを作成します。

4. 次の情報を使用して、CloudFront ディストリビューションを設定します。

   注記

   以下の表でオプションが指定されていない場合は、デフォルトのままにしておきます (空白でも構いません)。

   オプション	値
   Origin domain	前のコマンドからの出力[1]
   名前	rosa-waf-ingress [2]
   Viewer protocol policy	Redirect HTTP to HTTPS
   Allowed HTTP methods	GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE
   Cache policy	CachingDisabled
   Origin request policy	AllViewer
   Web Application Firewall (WAF)	Enable security protections
   Use existing WAF configuration	true
   Choose a web ACL	cloudfront-waf
   Alternate domain name (CNAME)	*.apps.example.com [3]
   Custom SSL certificate	上のステップでインポートした証明書を選択 [4]

   1. origin domain を取得するには、echo ${NLB} を実行します。
   2. 複数のクラスターがある場合は、オリジンの名前が一意であることを確認してください。
   3. これは、カスタム Ingress Controller の作成に使用したワイルドカードドメインと同じである必要があります。
   4. これは、上で入力した alternate domain name と同じである必要があります。

5. Amazon CloudFront ディストリビューションエンドポイントを取得します。

   $ aws cloudfront list-distributions --query "DistributionList.Items[?Origins.Items[?DomainName=='${NLB}']].DomainName" --output text

6. CNAME を持つカスタムのワイルドカードドメインの DNS を、前述のステップの Amazon CloudFront ディストリビューションエンドポイントに更新します。

   例

   *.apps.example.com CNAME d1b2c3d4e5f6g7.cloudfront.net

1. 次のコマンドを実行して、サンプルアプリケーション用の新しいプロジェクトを作成します。

   $ oc new-project hello-world

2. Hello World アプリケーションをデプロイします。

   $ oc -n hello-world new-app --image=docker.io/openshift/hello-openshift

3. カスタムドメイン名を指定してアプリケーションのルートを作成します。

   例

   $ oc -n hello-world create route edge --service=hello-openshift hello-openshift-tls \
   --hostname hello-openshift.${DOMAIN}

4. ルートにラベルを付けて、カスタム Ingress Controller へのアクセスを許可します。

   $ oc -n hello-world label route.route.openshift.io/hello-openshift-tls route=waf

1. アプリが Amazon CloudFront の背後でアクセスできることをテストします。

   例

   $ curl "https://hello-openshift.${DOMAIN}"

   出力例

   Hello OpenShift!

2. WAF が不正な要求を拒否することをテストします。

   例

   $ curl -X POST "https://hello-openshift.${DOMAIN}" \
     -F "user='<script><alert>Hello></alert></script>'"

   出力例

   <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
   <HTML><HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
   <TITLE>ERROR: The request could not be satisfied</TITLE>
   </HEAD><BODY>
   <H1>403 ERROR</H1>
   <H2>The request could not be satisfied.</H2>
   <HR noshade size="1px">
   Request blocked.
   We can't connect to the server for this app or website at this time. There might be too much traffic or a configuration error. Try again later, or contact the app or website owner.
   <BR clear="all">
   If you provide content to customers through CloudFront, you can find steps to troubleshoot and help prevent this error by reviewing the CloudFront documentation.
   <BR clear="all">
   <HR noshade size="1px">
   <PRE>
   Generated by cloudfront (CloudFront)
   Request ID: nFk9q2yB8jddI6FZOTjdliexzx-FwZtr8xUQUNT75HThPlrALDxbag==
   </PRE>
   <ADDRESS>
   </ADDRESS>
   </BODY></HTML>

   予期される結果は 403 ERROR エラーです。このエラーが返されれば、アプリケーションは AWS WAF によって保護されています。

1. 次のコマンドを実行して、AWS Load Balancer Operator をデプロイする新しいプロジェクトを作成します。

   $ oc new-project aws-load-balancer-operator

2. 次のコマンドを実行して、AWS Load Balancer Controller の AWS IAM ポリシーを作成します (まだ存在しない場合)。

   注記

   ポリシーは アップストリームの AWS Load Balancer Controller ポリシー から取得されます。これは Operator が機能するために必要です。

   $ POLICY_ARN=$(aws iam list-policies --query \
        "Policies[?PolicyName=='aws-load-balancer-operator-policy'].{ARN:Arn}" \
        --output text)

   $ if [[ -z "${POLICY_ARN}" ]]; then
       wget -O "${SCRATCH}/load-balancer-operator-policy.json" \
          https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/main/docs/install/iam_policy.json
        POLICY_ARN=$(aws --region "$REGION" --query Policy.Arn \
        --output text iam create-policy \
        --policy-name aws-load-balancer-operator-policy \
        --policy-document "file://${SCRATCH}/load-balancer-operator-policy.json")
   fi

3. AWS Load Balancer Operator の AWS IAM 信頼ポリシーを作成します。

   $ cat <<EOF > "${SCRATCH}/trust-policy.json"
   {
    "Version": "2012-10-17",
    "Statement": [
    {
    "Effect": "Allow",
    "Condition": {
      "StringEquals" : {
        "${OIDC_ENDPOINT}:sub": ["system:serviceaccount:aws-load-balancer-operator:aws-load-balancer-operator-controller-manager", "system:serviceaccount:aws-load-balancer-operator:aws-load-balancer-controller-cluster"]
      }
    },
    "Principal": {
      "Federated": "arn:aws:iam::$AWS_ACCOUNT_ID:oidc-provider/${OIDC_ENDPOINT}"
    },
    "Action": "sts:AssumeRoleWithWebIdentity"
    }
    ]
   }
   EOF

4. AWS Load Balancer Operator の AWS IAM ロールを作成します。

   $ ROLE_ARN=$(aws iam create-role --role-name "${CLUSTER}-alb-operator" \
      --assume-role-policy-document "file://${SCRATCH}/trust-policy.json" \
      --query Role.Arn --output text)

5. 次のコマンドを実行して、以前に作成した IAM ロールに AWS Load Balancer Operator ポリシーを割り当てます。

   $ aws iam attach-role-policy --role-name "${CLUSTER}-alb-operator" \
        --policy-arn ${POLICY_ARN}

6. 新しく作成した AWS IAM ロールを引き受けるための AWS Load Balancer Operator 用のシークレットを作成します。

   $ cat << EOF | oc apply -f -
   apiVersion: v1
   kind: Secret
   metadata:
     name: aws-load-balancer-operator
     namespace: aws-load-balancer-operator
   stringData:
     credentials: |
       [default]
       role_arn = ${ROLE_ARN}
       web_identity_token_file = /var/run/secrets/openshift/serviceaccount/token
   EOF

7. AWS Load Balancer Operator をインストールします。

   $ cat << EOF | oc apply -f -
   apiVersion: operators.coreos.com/v1
   kind: OperatorGroup
   metadata:
     name: aws-load-balancer-operator
     namespace: aws-load-balancer-operator
   spec:
     upgradeStrategy: Default
   ---
   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: aws-load-balancer-operator
     namespace: aws-load-balancer-operator
   spec:
     channel: stable-v1.0
     installPlanApproval: Automatic
     name: aws-load-balancer-operator
     source: redhat-operators
     sourceNamespace: openshift-marketplace
     startingCSV: aws-load-balancer-operator.v1.0.0
   EOF

8. 次の Operator を使用して、AWS Load Balancer Controller のインスタンスをデプロイします。

   注記

   ここでエラーが発生した場合は、少し待ってから再試行してください。エラーが発生するのは、Operator がまだインストールを完了していないためです。

   $ cat << EOF | oc apply -f -
   apiVersion: networking.olm.openshift.io/v1
   kind: AWSLoadBalancerController
   metadata:
     name: cluster
   spec:
     credentials:
       name: aws-load-balancer-operator
     enabledAddons:
       - AWSWAFv2
   EOF

9. Operator Pod とコントローラー Pod の両方が実行されていることを確認します。

   $ oc -n aws-load-balancer-operator get pods

   次のようなメッセージが表示されます。表示されない場合は、少し待ってから再試行してください。

   NAME                                                             READY   STATUS    RESTARTS   AGE
   aws-load-balancer-controller-cluster-6ddf658785-pdp5d            1/1     Running   0          99s
   aws-load-balancer-operator-controller-manager-577d9ffcb9-w6zqn   2/2     Running   0          2m4s

1. サンプルアプリケーション用に新しいプロジェクトを作成します。

   $ oc new-project hello-world

2. Hello World アプリケーションをデプロイします。

   $ oc new-app -n hello-world --image=docker.io/openshift/hello-openshift

3. 事前に作成済みのサービスリソースを NodePort サービスタイプに変換します。

   $ oc -n hello-world patch service hello-openshift -p '{"spec":{"type":"NodePort"}}'

4. AWS Load Balancer Operator を使用して AWS ALB をデプロイします。

   $ cat << EOF | oc apply -f -
   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: hello-openshift-alb
     namespace: hello-world
     annotations:
       alb.ingress.kubernetes.io/scheme: internet-facing
   spec:
     ingressClassName: alb
     rules:
       - http:
           paths:
             - path: /
               pathType: Exact
               backend:
                 service:
                   name: hello-openshift
                   port:
                     number: 8080
   EOF

5. AWS ALB Ingress エンドポイントを curl して、Hello World アプリケーションにアクセスできることを確認します。

   注記

   AWS ALB のプロビジョニングには数分かかります。curl: (6) Could not resolve host というエラーが表示された場合は、待機してから再試行してください。

   $ INGRESS=$(oc -n hello-world get ingress hello-openshift-alb -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')
   $ curl "http://${INGRESS}"

   出力例

   Hello OpenShift!

1. S3 アクセスを許可する IAM ポリシーを作成します。

   $ POLICY_ARN=$(aws iam list-policies --query "Policies[?PolicyName=='RosaOadpVer1'].{ARN:Arn}" --output text)
   if [[ -z "${POLICY_ARN}" ]]; then
   $ cat << EOF > ${SCRATCH}/policy.json
   {
   "Version": "2012-10-17",
   "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:CreateBucket",
        "s3:DeleteBucket",
        "s3:PutBucketTagging",
        "s3:GetBucketTagging",
        "s3:PutEncryptionConfiguration",
        "s3:GetEncryptionConfiguration",
        "s3:PutLifecycleConfiguration",
        "s3:GetLifecycleConfiguration",
        "s3:GetBucketLocation",
        "s3:ListBucket",
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject",
        "s3:ListBucketMultipartUploads",
        "s3:AbortMultipartUpload",
        "s3:ListMultipartUploadParts",
        "ec2:DescribeSnapshots",
        "ec2:DescribeVolumes",
        "ec2:DescribeVolumeAttribute",
        "ec2:DescribeVolumesModifications",
        "ec2:DescribeVolumeStatus",
        "ec2:CreateTags",
        "ec2:CreateVolume",
        "ec2:CreateSnapshot",
        "ec2:DeleteSnapshot"
      ],
      "Resource": "*"
    }
   ]}
   EOF
   $ POLICY_ARN=$(aws iam create-policy --policy-name "RosaOadpVer1" \
   --policy-document file:///${SCRATCH}/policy.json --query Policy.Arn \
   --tags Key=rosa_openshift_version,Value=${CLUSTER_VERSION} Key=rosa_role_prefix,Value=ManagedOpenShift Key=operator_namespace,Value=openshift-oadp Key=operator_name,Value=openshift-oadp \
   --output text)
   fi
   $ echo ${POLICY_ARN}

2. クラスターの IAM ロール信頼ポリシーを作成します。

   $ cat <<EOF > ${SCRATCH}/trust-policy.json
   {
     "Version": "2012-10-17",
     "Statement": [{
       "Effect": "Allow",
       "Principal": {
         "Federated": "arn:aws:iam::${AWS_ACCOUNT_ID}:oidc-provider/${OIDC_ENDPOINT}"
       },
       "Action": "sts:AssumeRoleWithWebIdentity",
       "Condition": {
         "StringEquals": {
            "${OIDC_ENDPOINT}:sub": [
              "system:serviceaccount:openshift-adp:openshift-adp-controller-manager",
              "system:serviceaccount:openshift-adp:velero"]
         }
       }
     }]
   }
   EOF
   $ ROLE_ARN=$(aws iam create-role --role-name \
    "${ROLE_NAME}" \
     --assume-role-policy-document file://${SCRATCH}/trust-policy.json \
     --tags Key=rosa_cluster_id,Value=${ROSA_CLUSTER_ID} Key=rosa_openshift_version,Value=${CLUSTER_VERSION} Key=rosa_role_prefix,Value=ManagedOpenShift Key=operator_namespace,Value=openshift-adp Key=operator_name,Value=openshift-oadp \
     --query Role.Arn --output text)
   
   $ echo ${ROLE_ARN}

3. IAM ポリシーを IAM ロールに割り当てます。

   $ aws iam attach-role-policy --role-name "${ROLE_NAME}" \
    --policy-arn ${POLICY_ARN}

1. OADP の namespace を作成します。

   $ oc create namespace openshift-adp

2. 認証情報のシークレットを作成します。

   $ cat <<EOF > ${SCRATCH}/credentials
   [default]
   role_arn = ${ROLE_ARN}
   web_identity_token_file = /var/run/secrets/openshift/serviceaccount/token
   region=<aws_region> 1
   EOF
   $ oc -n openshift-adp create secret generic cloud-credentials \
    --from-file=${SCRATCH}/credentials

   1

   <aws_region> は、Security Token Service (STS) エンドポイントに使用する AWS リージョンに置き換えます。

3. OADP Operator をデプロイします。

   注記

   現在、Operator のバージョン 1.1 では、バックアップが PartiallyFailed ステータスになるという問題があります。これはバックアップと復元のプロセスには影響しないと思われますが、それに関連する問題があるため注意が必要です。

   $ cat << EOF | oc create -f -
   apiVersion: operators.coreos.com/v1
   kind: OperatorGroup
   metadata:
    generateName: openshift-adp-
    namespace: openshift-adp
    name: oadp
   spec:
    targetNamespaces:
    - openshift-adp
   ---
   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
    name: redhat-oadp-operator
    namespace: openshift-adp
   spec:
    channel: stable-1.2
    installPlanApproval: Automatic
    name: redhat-oadp-operator
    source: redhat-operators
    sourceNamespace: openshift-marketplace
   EOF

4. Operator の準備が整うまで待ちます。

   $ watch oc -n openshift-adp get pods

   出力例

   NAME                                                READY   STATUS    RESTARTS   AGE
   openshift-adp-controller-manager-546684844f-qqjhn   1/1     Running   0          22s

5. クラウドストレージを作成します。

   $ cat << EOF | oc create -f -
   apiVersion: oadp.openshift.io/v1alpha1
   kind: CloudStorage
   metadata:
    name: ${CLUSTER_NAME}-oadp
    namespace: openshift-adp
   spec:
    creationSecret:
      key: credentials
      name: cloud-credentials
    enableSharedConfig: true
    name: ${CLUSTER_NAME}-oadp
    provider: aws
    region: $REGION
   EOF

6. アプリケーションのストレージのデフォルトのストレージクラスを確認します。

   $ oc get pvc -n <namespace> 1

   1

   アプリケーションの namespace を入力します。

   出力例

   NAME     STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
   applog   Bound    pvc-351791ae-b6ab-4e8b-88a4-30f73caf5ef8   1Gi        RWO            gp3-csi        4d19h
   mysql    Bound    pvc-16b8e009-a20a-4379-accc-bc81fedd0621   1Gi        RWO            gp3-csi        4d19h

   $ oc get storageclass

   出力例

   NAME                PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
   gp2                 kubernetes.io/aws-ebs   Delete          WaitForFirstConsumer   true                   4d21h
   gp2-csi             ebs.csi.aws.com         Delete          WaitForFirstConsumer   true                   4d21h
   gp3                 ebs.csi.aws.com         Delete          WaitForFirstConsumer   true                   4d21h
   gp3-csi (default)   ebs.csi.aws.com         Delete          WaitForFirstConsumer   true                   4d21h

   gp3-csi、gp2-csi、gp3、または gp2 のいずれかを使用すると機能します。バックアップ対象のアプリケーションがすべて CSI を使用した PV を使用している場合は、OADP の DPA 設定に CSI プラグインを含めます。

7. CSI のみ: Data Protection Application をデプロイします。

   $ cat << EOF | oc create -f -
   apiVersion: oadp.openshift.io/v1alpha1
   kind: DataProtectionApplication
   metadata:
    name: ${CLUSTER_NAME}-dpa
    namespace: openshift-adp
   spec:
    backupImages: true
    features:
      dataMover:
        enable: false
    backupLocations:
    - bucket:
        cloudStorageRef:
          name: ${CLUSTER_NAME}-oadp
        credential:
          key: credentials
          name: cloud-credentials
        prefix: velero
        default: true
        config:
          region: ${REGION}
    configuration:
      velero:
        defaultPlugins:
        - openshift
        - aws
        - csi
      restic:
        enable: false
   EOF

   注記

   CSI ボリュームに対してこのコマンドを実行する場合は、次のステップをスキップできます。

8. 非 CSI ボリューム: Data Protection Application をデプロイします。

   $ cat << EOF | oc create -f -
   apiVersion: oadp.openshift.io/v1alpha1
   kind: DataProtectionApplication
   metadata:
    name: ${CLUSTER_NAME}-dpa
    namespace: openshift-adp
   spec:
    backupImages: true
    features:
      dataMover:
        enable: false
    backupLocations:
    - bucket:
        cloudStorageRef:
          name: ${CLUSTER_NAME}-oadp
        credential:
          key: credentials
          name: cloud-credentials
        prefix: velero
        default: true
        config:
          region: ${REGION}
    configuration:
      velero:
        defaultPlugins:
        - openshift
        - aws
      restic:
        enable: false
    snapshotLocations:
      - velero:
          config:
            credentialsFile: /tmp/credentials/openshift-adp/cloud-credentials-credentials
            enableSharedConfig: 'true'
            profile: default
            region: ${REGION}
          provider: aws
   EOF

1. バックアップするワークロードを作成します。

   $ oc create namespace hello-world
   $ oc new-app -n hello-world --image=docker.io/openshift/hello-openshift

2. ルートを公開します。

   $ oc expose service/hello-openshift -n hello-world

3. アプリケーションが動作していることを確認します。

   $ curl `oc get route/hello-openshift -n hello-world -o jsonpath='{.spec.host}'`

   出力例

   Hello OpenShift!

4. ワークロードをバックアップします。

   $ cat << EOF | oc create -f -
   apiVersion: velero.io/v1
   kind: Backup
   metadata:
    name: hello-world
    namespace: openshift-adp
   spec:
    includedNamespaces:
    - hello-world
    storageLocation: ${CLUSTER_NAME}-dpa-1
    ttl: 720h0m0s
   EOF

5. バックアップが完了するまで待ちます。

   $ watch "oc -n openshift-adp get backup hello-world -o json | jq .status"

   出力例

   {
    "completionTimestamp": "2022-09-07T22:20:44Z",
    "expiration": "2022-10-07T22:20:22Z",
    "formatVersion": "1.1.0",
    "phase": "Completed",
    "progress": {
      "itemsBackedUp": 58,
      "totalItems": 58
    },
    "startTimestamp": "2022-09-07T22:20:22Z",
    "version": 1
   }

6. デモワークロードを削除します。

   $ oc delete ns hello-world

7. バックアップから復元します。

   $ cat << EOF | oc create -f -
   apiVersion: velero.io/v1
   kind: Restore
   metadata:
    name: hello-world
    namespace: openshift-adp
   spec:
    backupName: hello-world
   EOF

8. 復元が完了するまで待ちます。

   $ watch "oc -n openshift-adp get restore hello-world -o json | jq .status"

   出力例

   {
    "completionTimestamp": "2022-09-07T22:25:47Z",
    "phase": "Completed",
    "progress": {
      "itemsRestored": 38,
      "totalItems": 38
    },
    "startTimestamp": "2022-09-07T22:25:28Z",
    "warnings": 9
   }

9. ワークロードが復元されていることを確認します。

   $ oc -n hello-world get pods

   出力例

   NAME                              READY   STATUS    RESTARTS   AGE
   hello-openshift-9f885f7c6-kdjpj   1/1     Running   0          90s

   $ curl `oc get route/hello-openshift -n hello-world -o jsonpath='{.spec.host}'`

   出力例

   Hello OpenShift!

10. トラブルシューティングのヒントについては、OADP チームの トラブルシューティングドキュメント を参照してください。
11. 追加のサンプルアプリケーションは、OADP チームの サンプルアプリケーションディレクトリー にあります。

1. ワークロードを削除します。

   $ oc delete ns hello-world

2. バックアップおよび復元リソースが不要になった場合は、クラスターからリソースを削除します。

   $ oc delete backups.velero.io hello-world
   $ oc delete restores.velero.io hello-world

3. s3 のバックアップ/復元オブジェクトとリモートオブジェクトを削除するには、以下を実行します。

   $ velero backup delete hello-world
   $ velero restore delete hello-world

4. Data Protection Application を削除します。

   $ oc -n openshift-adp delete dpa ${CLUSTER_NAME}-dpa

5. クラウドストレージを削除します。

   $ oc -n openshift-adp delete cloudstorage ${CLUSTER_NAME}-oadp

   警告

   このコマンドがハングした場合は、ファイナライザーの削除が必要になる場合があります。

   $ oc -n openshift-adp patch cloudstorage ${CLUSTER_NAME}-oadp -p '{"metadata":{"finalizers":null}}' --type=merge

6. Operator が不要になった場合は、Operator を削除します。

   $ oc -n openshift-adp delete subscription oadp-operator

7. Operator の namespace を削除します。

   $ oc delete ns redhat-openshift-adp

8. カスタムリソース定義が不要になった場合は、クラスターからカスタムリソース定義を削除します。

   $ for CRD in `oc get crds | grep velero | awk '{print $1}'`; do oc delete crd $CRD; done
   $ for CRD in `oc get crds | grep -i oadp | awk '{print $1}'`; do oc delete crd $CRD; done

9. AWS S3 バケットを削除します。

   $ aws s3 rm s3://${CLUSTER_NAME}-oadp --recursive
   $ aws s3api delete-bucket --bucket ${CLUSTER_NAME}-oadp

10. ロールからポリシーの割り当てを解除します。

    $ aws iam detach-role-policy --role-name "${ROLE_NAME}" \
     --policy-arn "${POLICY_ARN}"

11. ロールを削除します。

    $ aws iam delete-role --role-name "${ROLE_NAME}"

1. AWS Load Balancer Controller の AWS IAM ポリシーを作成します。

   注記

   このポリシーは、アップストリームの AWS Load Balancer Controller ポリシー に加えて、サブネット上にタグを作成する権限から取得されます。これは Operator が機能するために必要です。

   $ oc new-project aws-load-balancer-operator
   $ POLICY_ARN=$(aws iam list-policies --query \
        "Policies[?PolicyName=='aws-load-balancer-operator-policy'].{ARN:Arn}" \
        --output text)
   $ if [[ -z "${POLICY_ARN}" ]]; then
       wget -O "${SCRATCH}/load-balancer-operator-policy.json" \
          https://raw.githubusercontent.com/rh-mobb/documentation/main/content/rosa/aws-load-balancer-operator/load-balancer-operator-policy.json
        POLICY_ARN=$(aws --region "$REGION" --query Policy.Arn \
        --output text iam create-policy \
        --policy-name aws-load-balancer-operator-policy \
        --policy-document "file://${SCRATCH}/load-balancer-operator-policy.json")
   fi
   $ echo $POLICY_ARN

2. AWS Load Balancer Operator の AWS IAM 信頼ポリシーを作成します。

   $ cat <<EOF > "${SCRATCH}/trust-policy.json"
   {
    "Version": "2012-10-17",
    "Statement": [
    {
    "Effect": "Allow",
    "Condition": {
      "StringEquals" : {
        "${OIDC_ENDPOINT}:sub": ["system:serviceaccount:aws-load-balancer-operator:aws-load-balancer-operator-controller-manager", "system:serviceaccount:aws-load-balancer-operator:aws-load-balancer-controller-cluster"]
      }
    },
    "Principal": {
      "Federated": "arn:aws:iam::$AWS_ACCOUNT_ID:oidc-provider/${OIDC_ENDPOINT}"
    },
    "Action": "sts:AssumeRoleWithWebIdentity"
    }
    ]
   }
   EOF

3. AWS Load Balancer Operator の AWS IAM ロールを作成します。

   $ ROLE_ARN=$(aws iam create-role --role-name "${ROSA_CLUSTER_NAME}-alb-operator" \
      --assume-role-policy-document "file://${SCRATCH}/trust-policy.json" \
      --query Role.Arn --output text)
   $ echo $ROLE_ARN
   
   $ aws iam attach-role-policy --role-name "${ROSA_CLUSTER_NAME}-alb-operator" \
        --policy-arn $POLICY_ARN

4. 新しく作成した AWS IAM ロールを引き受けるための AWS Load Balancer Operator 用のシークレットを作成します。

   $ cat << EOF | oc apply -f -
   apiVersion: v1
   kind: Secret
   metadata:
     name: aws-load-balancer-operator
     namespace: aws-load-balancer-operator
   stringData:
     credentials: |
       [default]
       role_arn = $ROLE_ARN
       web_identity_token_file = /var/run/secrets/openshift/serviceaccount/token
   EOF

5. AWS Load Balancer Operator をインストールします。

   $ cat << EOF | oc apply -f -
   apiVersion: operators.coreos.com/v1
   kind: OperatorGroup
   metadata:
     name: aws-load-balancer-operator
     namespace: aws-load-balancer-operator
   spec:
     upgradeStrategy: Default
   ---
   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: aws-load-balancer-operator
     namespace: aws-load-balancer-operator
   spec:
     channel: stable-v1.0
     installPlanApproval: Automatic
     name: aws-load-balancer-operator
     source: redhat-operators
     sourceNamespace: openshift-marketplace
     startingCSV: aws-load-balancer-operator.v1.0.0
   EOF

6. 次の Operator を使用して、AWS Load Balancer Controller のインスタンスをデプロイします。

   注記

   ここでエラーが発生した場合は、少し待ってから再試行してください。エラーが発生するのは、Operator がまだインストールを完了していないためです。

   $ cat << EOF | oc apply -f -
   apiVersion: networking.olm.openshift.io/v1
   kind: AWSLoadBalancerController
   metadata:
     name: cluster
   spec:
     credentials:
       name: aws-load-balancer-operator
   EOF

7. Operator Pod とコントローラー Pod の両方が実行されていることを確認します。

   $ oc -n aws-load-balancer-operator get pods

   次のようなメッセージが表示されます。表示されない場合は、少し待ってから再試行してください。

   NAME                                                             READY   STATUS    RESTARTS   AGE
   aws-load-balancer-controller-cluster-6ddf658785-pdp5d            1/1     Running   0          99s
   aws-load-balancer-operator-controller-manager-577d9ffcb9-w6zqn   2/2     Running   0          2m4s

1. 新しいプロジェクトを作成します。

   $ oc new-project hello-world

2. Hello World アプリケーションをデプロイします。

   $ oc new-app -n hello-world --image=docker.io/openshift/hello-openshift

3. AWS ALB が接続する NodePort サービスを設定します。

   $ cat << EOF | oc apply -f -
   apiVersion: v1
   kind: Service
   metadata:
     name: hello-openshift-nodeport
     namespace: hello-world
   spec:
     ports:
       - port: 80
         targetPort: 8080
         protocol: TCP
     type: NodePort
     selector:
       deployment: hello-openshift
   EOF

4. AWS Load Balancer Operator を使用して AWS ALB をデプロイします。

   $ cat << EOF | oc apply -f -
   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: hello-openshift-alb
     namespace: hello-world
     annotations:
       alb.ingress.kubernetes.io/scheme: internet-facing
   spec:
     ingressClassName: alb
     rules:
       - http:
           paths:
             - path: /
               pathType: Exact
               backend:
                 service:
                   name: hello-openshift-nodeport
                   port:
                     number: 80
   EOF

5. AWS ALB Ingress エンドポイントを curl して、Hello World アプリケーションにアクセスできることを確認します。

   注記

   AWS ALB のプロビジョニングには数分かかります。curl: (6) Could not resolve host というエラーが表示された場合は、待機してから再試行してください。

   $ INGRESS=$(oc -n hello-world get ingress hello-openshift-alb \
       -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')
   $ curl "http://${INGRESS}"

   出力例

   Hello OpenShift!

6. Hello World アプリケーション用に AWS NLB をデプロイします。

   $ cat << EOF | oc apply -f -
   apiVersion: v1
   kind: Service
   metadata:
     name: hello-openshift-nlb
     namespace: hello-world
     annotations:
       service.beta.kubernetes.io/aws-load-balancer-type: external
       service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: instance
       service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
   spec:
     ports:
       - port: 80
         targetPort: 8080
         protocol: TCP
     type: LoadBalancer
     selector:
       deployment: hello-openshift
   EOF

7. AWS NLB エンドポイントをテストします。

   注記

   NLB のプロビジョニングには数分かかります。curl: (6) Could not resolve host というエラーが表示された場合は、待機してから再試行してください。

   $ NLB=$(oc -n hello-world get service hello-openshift-nlb \
     -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')
   $ curl "http://${NLB}"

   出力例

   Hello OpenShift!

1. hello world アプリケーションの namespace (および namespace 内のすべてのリソース) を削除します。

   $ oc delete project hello-world

2. AWS Load Balancer Operator と AWS IAM ロールを削除します。

   $ oc delete subscription aws-load-balancer-operator -n aws-load-balancer-operator
   $ aws iam detach-role-policy \
     --role-name "${ROSA_CLUSTER_NAME}-alb-operator" \
     --policy-arn $POLICY_ARN
   $ aws iam delete-role \
     --role-name "${ROSA_CLUSTER_NAME}-alb-operator"

3. AWS IAM ポリシーを削除します。

   $ aws iam delete-policy --policy-arn $POLICY_ARN

手順

1. 指定の変数を変更し、次のコマンドを実行して、クラスターの OAuth コールバック URL を作成します。

   注記

   このコールバック URL を忘れずに保存してください。後のプロセスで必要になります。

   $ domain=$(rosa describe cluster -c <cluster_name> | grep "DNS" | grep -oE '\S+.openshiftapps.com')
   $ echo "OAuth callback URL: https://oauth-openshift.apps.$domain/oauth2callback/AAD"

   OAuth コールバック URL の末尾にある "AAD" ディレクトリーは、このプロセスで後で設定する OAuth アイデンティティープロバイダー名と同じである必要があります。

2. Azure portal にログインして Entra ID アプリケーションを作成し、App registrations ブレード を選択します。次に、New registration を選択して新しいアプリケーションを作成します。

   

3. アプリケーションに名前を付けます (例: openshift-auth)。
4. Redirect URI ドロップダウンから Web を選択し、前のステップで取得した OAuth コールバック URL の値を入力します。

5. 必要な情報を入力したら、Register をクリックしてアプリケーションを作成します。

   

6. Certificates & secrets サブブレードを選択し、New client secret を選択します。

   

7. 要求された詳細を入力し、生成されたクライアントシークレット値を保存します。このシークレットは、このプロセスで後で必要になります。

   重要

   初期セットアップ後は、クライアントシークレットを確認できません。クライアントシークレットを保存しなかった場合は、新しいクライアントシークレットを生成する必要があります。

   

8. Overview サブブレードを選択し、Application (client) ID と Directory (tenant) ID をメモします。これらの値は後のステップで必要になります。

   

1. Token configuration サブブレードをクリックし、Add optional claim ボタンを選択します。

   

2. ID ラジオボタンを選択します。

   

3. email クレームのチェックボックスを選択します。

   

4. preferred_username クレームのチェックボックスを選択します。次に、Add をクリックし、Entra ID アプリケーションの email および preferred_username クレームを設定します。

   

5. ページの上部にダイアログボックスが表示されます。プロンプトに従って、必要な Microsoft Graph 権限を有効にします。

   

手順

1. Token configuration サブブレードで、Add groups claim をクリックします。

   

2. Entra ID アプリケーションのグループクレームを設定するには、Security groups を選択し、Add をクリックします。

   注記

   この例では、グループクレームに、ユーザーがメンバーとなっているすべてのセキュリティーグループを含めます。実際の実稼働環境では、グループクレームに、Red Hat OpenShift Service on AWS に適用するグループのみを含めてください。

   

手順

1. 次のコマンドを実行して変数を作成します。

   $ CLUSTER_NAME=example-cluster 1
   $ IDP_NAME=AAD 2
   $ APP_ID=yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy 3
   $ CLIENT_SECRET=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 4
   $ TENANT_ID=zzzzzzzz-zzzz-zzzz-zzzz-zzzzzzzzzzzz 5

   1

   これは ROSA クラスターの名前に置き換えます。

   2

   この値は、このプロセスで前に生成した OAuth コールバック URL で使用した名前に置き換えます。

   3

   これはアプリケーション (クライアント) ID に置き換えます。

   4

   これはクライアントシークレットに置き換えます。

   5

   これはディレクトリー (テナント) ID に置き換えます。

2. 次のコマンドを実行して、クラスターの OAuth プロバイダーを設定します。グループクレームを有効にした場合は、必ず --group-claims groups 引数を使用してください。

   • グループクレームを有効にした場合は、次のコマンドを実行します。

     $ rosa create idp \
     --cluster ${CLUSTER_NAME} \
     --type openid \
     --name ${IDP_NAME} \
     --client-id ${APP_ID} \
     --client-secret ${CLIENT_SECRET} \
     --issuer-url https://login.microsoftonline.com/${TENANT_ID}/v2.0 \
     --email-claims email \
     --name-claims name \
     --username-claims preferred_username \
     --extra-scopes email,profile \
     --groups-claims groups

   • グループクレームを有効にしなかった場合は、次のコマンドを実行します。

     $ rosa create idp \
     --cluster ${CLUSTER_NAME} \
     --type openid \
     --name ${IDP_NAME} \
     --client-id ${APP_ID} \
     --client-secret ${CLIENT_SECRET} \
     --issuer-url https://login.microsoftonline.com/${TENANT_ID}/v2.0 \
     --email-claims email \
     --name-claims name \
     --username-claims preferred_username \
     --extra-scopes email,profile

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

   $ oc login --token=<your-token> --server=<your-server-url>

   ログイントークンを見つけるには、Red Hat OpenShift Cluster Manager からプルシークレット でクラスターにアクセスします。

2. 次のコマンドを実行して、クラスターに STS があることを検証します。

   $ oc get authentication.config.openshift.io cluster -o json \
     | jq .spec.serviceAccountIssuer

   出力例

   "https://xxxxx.cloudfront.net/xxxxx"

   出力が異なる場合は、続行しないでください。このプロセスを続行する前に、STS クラスターの作成に関する Red Hat ドキュメント を参照してください。

3. 次のコマンドを実行して、CSI ドライバーの実行を許可するように SecurityContextConstraints 権限を設定します。

   $ oc new-project csi-secrets-store
   $ oc adm policy add-scc-to-user privileged \
       system:serviceaccount:csi-secrets-store:secrets-store-csi-driver
   $ oc adm policy add-scc-to-user privileged \
       system:serviceaccount:csi-secrets-store:csi-secrets-store-provider-aws

4. 次のコマンドを実行して、このプロセスで後で使用する環境変数を作成します。

   $ export REGION=$(oc get infrastructure cluster -o=jsonpath="{.status.platformStatus.aws.region}")
   $ export OIDC_ENDPOINT=$(oc get authentication.config.openshift.io cluster \
      -o jsonpath='{.spec.serviceAccountIssuer}' | sed  's|^https://||')
   $ export AWS_ACCOUNT_ID=`aws sts get-caller-identity --query Account --output text`
   $ export AWS_PAGER=""

1. 次のコマンドを実行し、Helm を使用してシークレットストア CSI ドライバーを登録します。

   $ helm repo add secrets-store-csi-driver \
       https://kubernetes-sigs.github.io/secrets-store-csi-driver/charts

2. 次のコマンドを実行して、Helm リポジトリーを更新します。

   $ helm repo update

3. 次のコマンドを実行して、シークレットストア CSI ドライバーをインストールします。

   $ helm upgrade --install -n csi-secrets-store \
       csi-secrets-store-driver secrets-store-csi-driver/secrets-store-csi-driver

4. 次のコマンドを実行して、AWS プロバイダーをデプロイします。

   $ oc -n csi-secrets-store apply -f \
       https://raw.githubusercontent.com/rh-mobb/documentation/main/content/misc/secrets-store-csi/aws-provider-installer.yaml

5. 次のコマンドを実行して、両方の Daemonset が実行されていることを確認します。

   $ oc -n csi-secrets-store get ds \
       csi-secrets-store-provider-aws \
       csi-secrets-store-driver-secrets-store-csi-driver

6. 次のコマンドを実行して、シークレットストア CSI ドライバーにラベルを付けて、制限付き Pod セキュリティープロファイルとともに使用することを許可します。

   $ oc label csidriver.storage.k8s.io/secrets-store.csi.k8s.io security.openshift.io/csi-ephemeral-volume-profile=restricted

1. 次のコマンドを実行して、Secrets Manager のシークレットを作成します。

   $ SECRET_ARN=$(aws --region "$REGION" secretsmanager create-secret \
       --name MySecret --secret-string \
       '{"username":"shadowman", "password":"hunter2"}' \
       --query ARN --output text); echo $SECRET_ARN

2. 次のコマンドを実行して、IAM アクセスポリシードキュメントを作成します。

   $ cat << EOF > policy.json
   {
      "Version": "2012-10-17",
      "Statement": [{
         "Effect": "Allow",
         "Action": [
           "secretsmanager:GetSecretValue",
           "secretsmanager:DescribeSecret"
         ],
         "Resource": ["$SECRET_ARN"]
         }]
   }
   EOF

3. 次のコマンドを実行して、IAM アクセスポリシーを作成します。

   $ POLICY_ARN=$(aws --region "$REGION" --query Policy.Arn \
   --output text iam create-policy \
   --policy-name openshift-access-to-mysecret-policy \
   --policy-document file://policy.json); echo $POLICY_ARN

4. 次のコマンドを実行して、IAM ロール信頼ポリシードキュメントを作成します。

   注記

   信頼ポリシーは、このプロセスで後で作成する namespace のデフォルトのサービスアカウントにロックされます。

   $ cat <<EOF > trust-policy.json
   {
      "Version": "2012-10-17",
      "Statement": [
      {
      "Effect": "Allow",
      "Condition": {
        "StringEquals" : {
          "${OIDC_ENDPOINT}:sub": ["system:serviceaccount:my-application:default"]
         }
       },
       "Principal": {
          "Federated": "arn:aws:iam::$AWS_ACCOUNT_ID:oidc-provider/${OIDC_ENDPOINT}"
       },
       "Action": "sts:AssumeRoleWithWebIdentity"
       }
       ]
   }
   EOF

5. 次のコマンドを実行して、IAM ロールを作成します。

   $ ROLE_ARN=$(aws iam create-role --role-name openshift-access-to-mysecret \
   --assume-role-policy-document file://trust-policy.json \
   --query Role.Arn --output text); echo $ROLE_ARN

6. 次のコマンドを実行して、ロールをポリシーに割り当てます。

   $ aws iam attach-role-policy --role-name openshift-access-to-mysecret \
       --policy-arn $POLICY_ARN

1. 次のコマンドを実行して、OpenShift プロジェクトを作成します。

   $ oc new-project my-application

2. 次のコマンドを実行して、STS ロールを使用するようにデフォルトのサービスアカウントにアノテーションを付けます。

   $ oc annotate -n my-application serviceaccount default \
       eks.amazonaws.com/role-arn=$ROLE_ARN

3. 次のコマンドを実行して、シークレットにアクセスするためのシークレットプロバイダークラスを作成します。

   $ cat << EOF | oc apply -f -
   apiVersion: secrets-store.csi.x-k8s.io/v1
   kind: SecretProviderClass
   metadata:
     name: my-application-aws-secrets
   spec:
     provider: aws
     parameters:
       objects: |
         - objectName: "MySecret"
           objectType: "secretsmanager"
   EOF

4. 次のコマンドでシークレットを使用してデプロイメントを作成します。

   $ cat << EOF | oc apply -f -
   apiVersion: v1
   kind: Pod
   metadata:
     name: my-application
     labels:
       app: my-application
   spec:
     volumes:
     - name: secrets-store-inline
       csi:
         driver: secrets-store.csi.k8s.io
         readOnly: true
         volumeAttributes:
           secretProviderClass: "my-application-aws-secrets"
     containers:
     - name: my-application-deployment
       image: k8s.gcr.io/e2e-test-images/busybox:1.29
       command:
         - "/bin/sleep"
         - "10000"
       volumeMounts:
       - name: secrets-store-inline
         mountPath: "/mnt/secrets-store"
         readOnly: true
   EOF

5. 次のコマンドを実行して、Pod にシークレットがマウントされていることを確認します。

   $ oc exec -it my-application -- cat /mnt/secrets-store/MySecret

1. 次のコマンドを実行してアプリケーションを削除します。

   $ oc delete project my-application

2. 次のコマンドを実行して、シークレットストア CSI ドライバーを削除します。

   $ helm delete -n csi-secrets-store csi-secrets-store-driver

3. 次のコマンドを実行して、Security Context Constraints を削除します。

   $ oc adm policy remove-scc-from-user privileged \
       system:serviceaccount:csi-secrets-store:secrets-store-csi-driver; oc adm policy remove-scc-from-user privileged \
       system:serviceaccount:csi-secrets-store:csi-secrets-store-provider-aws

4. 次のコマンドを実行して、AWS プロバイダーを削除します。

   $ oc -n csi-secrets-store delete -f \
   https://raw.githubusercontent.com/rh-mobb/documentation/main/content/misc/secrets-store-csi/aws-provider-installer.yaml

5. 次のコマンドを実行して、AWS のロールとポリシーを削除します。

   $ aws iam detach-role-policy --role-name openshift-access-to-mysecret \
       --policy-arn $POLICY_ARN; aws iam delete-role --role-name openshift-access-to-mysecret; aws iam delete-policy --policy-arn $POLICY_ARN

6. 次のコマンドを実行して、Secrets Manager のシークレットを削除します。

   $ aws secretsmanager --region $REGION delete-secret --secret-id $SECRET_ARN

1. 次の環境変数を設定し、お使いのクラスターに合わせてクラスター名を変更します。

   $ export CLUSTER_NAME=$(oc get infrastructure cluster -o=jsonpath="{.status.infrastructureName}"  | sed 's/-[a-z0-9]\{5\}$//')
   $ export REGION=$(rosa describe cluster -c ${ROSA_CLUSTER_NAME} --output json | jq -r .region.id)
   $ export OIDC_ENDPOINT=$(oc get authentication.config.openshift.io cluster -o json | jq -r .spec.serviceAccountIssuer | sed  's|^https://||')
   $ export AWS_ACCOUNT_ID=`aws sts get-caller-identity --query Account --output text`
   $ export ACK_SERVICE=s3
   $ export ACK_SERVICE_ACCOUNT=ack-${ACK_SERVICE}-controller
   $ export POLICY_ARN=arn:aws:iam::aws:policy/AmazonS3FullAccess
   $ export AWS_PAGER=""
   $ export SCRATCH="/tmp/${ROSA_CLUSTER_NAME}/ack"
   $ mkdir -p ${SCRATCH}

2. 次のセクションに進む前に、すべてのフィールドが正しく出力されていることを確認してください。

   $ echo "Cluster: ${ROSA_CLUSTER_NAME}, Region: ${REGION}, OIDC Endpoint: ${OIDC_ENDPOINT}, AWS Account ID: ${AWS_ACCOUNT_ID}"

1. ACK Operator の AWS Identity Access Management (IAM) 信頼ポリシーを作成します。

   $ cat <<EOF > "${SCRATCH}/trust-policy.json"
   {
    "Version": "2012-10-17",
    "Statement": [
    {
    "Effect": "Allow",
    "Condition": {
      "StringEquals" : {
        "${OIDC_ENDPOINT}:sub": "system:serviceaccount:ack-system:${ACK_SERVICE_ACCOUNT}"
      }
    },
    "Principal": {
      "Federated": "arn:aws:iam::$AWS_ACCOUNT_ID:oidc-provider/${OIDC_ENDPOINT}"
    },
    "Action": "sts:AssumeRoleWithWebIdentity"
    }
    ]
   }
   EOF

2. AmazonS3FullAccess ポリシーを割り当てた、ACK Operator が引き受ける AWS IAM ロールを作成します。

   注記

   推奨されるポリシーは、各プロジェクトの GitHub リポジトリー (例: https://github.com/aws-controllers-k8s/s3-controller/blob/main/config/iam/recommended-policy-arn) で見つけることができます。

   $ ROLE_ARN=$(aws iam create-role --role-name "ack-${ACK_SERVICE}-controller" \
      --assume-role-policy-document "file://${SCRATCH}/trust-policy.json" \
      --query Role.Arn --output text)
   $ echo $ROLE_ARN
   
   $ aws iam attach-role-policy --role-name "ack-${ACK_SERVICE}-controller" \
        --policy-arn ${POLICY_ARN}

1. ACK S3 Operator をインストールするプロジェクトを作成します。

   $ oc new-project ack-system

2. ACK S3 Operator の設定を含むファイルを作成します。

   注記

   ACK_WATCH_NAMESPACE は、コントローラーがクラスター内のすべての namespace を適切に監視できるように、意図的に空白のままにします。

   $ cat <<EOF > "${SCRATCH}/config.txt"
   ACK_ENABLE_DEVELOPMENT_LOGGING=true
   ACK_LOG_LEVEL=debug
   ACK_WATCH_NAMESPACE=
   AWS_REGION=${REGION}
   AWS_ENDPOINT_URL=
   ACK_RESOURCE_TAGS=${CLUSTER_NAME}
   ENABLE_LEADER_ELECTION=true
   LEADER_ELECTION_NAMESPACE=
   EOF

3. 前のステップのファイルを使用して ConfigMap を作成します。

   $ oc -n ack-system create configmap \
     --from-env-file=${SCRATCH}/config.txt ack-${ACK_SERVICE}-user-config

4. OperatorHub から ACK S3 Operator をインストールします。

   $ cat << EOF | oc apply -f -
   apiVersion: operators.coreos.com/v1
   kind: OperatorGroup
   metadata:
     name: ack-${ACK_SERVICE}-controller
     namespace: ack-system
   spec:
     upgradeStrategy: Default
   ---
   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: ack-${ACK_SERVICE}-controller
     namespace: ack-system
   spec:
     channel: alpha
     installPlanApproval: Automatic
     name: ack-${ACK_SERVICE}-controller
     source: community-operators
     sourceNamespace: openshift-marketplace
   EOF

5. ACK S3 Operator サービスアカウントに、割り当てる AWS IAM ロールのアノテーションを付けて、デプロイメントを再起動します。

   $ oc -n ack-system annotate serviceaccount ${ACK_SERVICE_ACCOUNT} \
     eks.amazonaws.com/role-arn=${ROLE_ARN} && \
     oc -n ack-system rollout restart deployment ack-${ACK_SERVICE}-controller

6. ACK S3 Operator が実行されていることを確認します。

   $ oc -n ack-system get pods

   出力例

   NAME                                 READY   STATUS    RESTARTS   AGE
   ack-s3-controller-585f6775db-s4lfz   1/1     Running   0          51s

1. S3 バケットリソースをデプロイします。

   $ cat << EOF | oc apply -f -
   apiVersion: s3.services.k8s.aws/v1alpha1
   kind: Bucket
   metadata:
      name: ${CLUSTER-NAME}-bucket
      namespace: ack-system
   spec:
      name: ${CLUSTER-NAME}-bucket
   EOF

2. S3 バケットが AWS で作成されたことを確認します。

   $ aws s3 ls | grep ${CLUSTER_NAME}-bucket

   出力例

   2023-10-04 14:51:45 mrmc-test-maz-bucket

1. S3 バケットリソースを削除します。

   $ oc -n ack-system delete bucket.s3.services.k8s.aws/${CLUSTER-NAME}-bucket

2. ACK S3 Operator と AWS IAM ロールを削除します。

   $ oc -n ack-system delete subscription ack-${ACK_SERVICE}-controller
   $ aws iam detach-role-policy \
     --role-name "ack-${ACK_SERVICE}-controller" \
     --policy-arn ${POLICY_ARN}
   $ aws iam delete-role \
     --role-name "ack-${ACK_SERVICE}-controller"

3. ack-system プロジェクトを削除します。

   $ oc delete project ack-system

1. 次の環境変数を設定します。

   $ export DOMAIN=<apps.example.com> 1
   $ export AWS_PAGER=""
   $ export CLUSTER=$(oc get infrastructure cluster -o=jsonpath="{.status.infrastructureName}"  | sed 's/-[a-z0-9]\{5\}$//')
   $ export REGION=$(oc get infrastructure cluster -o=jsonpath="{.status.platformStatus.aws.region}")
   $ export AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
   $ export SCRATCH="/tmp/${CLUSTER}/external-dns"
   $ mkdir -p ${SCRATCH}

   1

   IngressController に使用するカスタムドメインに置き換えます。

2. 次のセクションに進む前に、すべてのフィールドが正しく出力されていることを確認してください。

   $ echo "Cluster: ${CLUSTER}, Region: ${REGION}, AWS Account ID: ${AWS_ACCOUNT_ID}"

   注記

   前のコマンドからの "Cluster" の出力は、クラスターの名前、クラスターの内部 ID、またはクラスターのドメイン接頭辞である可能性があります。別の識別子を使用する場合は、次のコマンドを実行して手動でこの値を設定できます。

   $ export CLUSTER=my-custom-value

手順

1. 秘密鍵と公開証明書から新しい TLS シークレットを作成します。fullchain.pem は完全なワイルドカード証明書チェーン (中間証明書を含む)、privkey.pem はワイルドカード証明書の秘密鍵です。

   $ oc -n openshift-ingress create secret tls external-dns-tls --cert=fullchain.pem --key=privkey.pem

2. 新規の IngressController リソースを作成します。

   $ cat << EOF | oc apply -f -
   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
     name: external-dns-ingress
     namespace: openshift-ingress-operator
   spec:
     domain: ${DOMAIN}
     defaultCertificate:
       name: external-dns-tls
     endpointPublishingStrategy:
       loadBalancer:
         dnsManagementPolicy: Unmanaged
         providerParameters:
           aws:
             type: NLB
           type: AWS
         scope: External
       type: LoadBalancerService
   EOF

   警告

   この IngressController の例では、インターネットにアクセス可能な Network Load Balancer (NLB) を AWS アカウントに作成します。代わりに内部 NLB をプロビジョニングするには、IngressController リソースを作成する前に、.spec.endpointPublishingStrategy.loadBalancer.scope パラメーターを Internal に設定します。

3. カスタムドメイン IngressController が外部ロードバランサーを正常に作成したことを確認します。

   $ oc -n openshift-ingress get service/router-external-dns-ingress

   出力例

   NAME                          TYPE           CLUSTER-IP      EXTERNAL-IP                                                                     PORT(S)                      AGE
   router-external-dns-ingress   LoadBalancer   172.30.71.250   a4838bb991c6748439134ab89f132a43-aeae124077b50c01.elb.us-east-1.amazonaws.com   80:32227/TCP,443:30310/TCP   43s

1. Amazon Route 53 のパブリックホストゾーン ID を取得します。

   $ export ZONE_ID=$(aws route53 list-hosted-zones-by-name --output json \
     --dns-name "${DOMAIN}." --query 'HostedZones[0]'.Id --out text | sed 's/\/hostedzone\///')

2. Ingress Controller の正規ドメインの DNS 解決を有効にするために必要な DNS 変更のあるドキュメントを準備します。

   $ NLB_HOST=$(oc -n openshift-ingress get service/router-external-dns-ingress -ojsonpath="{.status.loadBalancer.ingress[0].hostname}")
   $ cat << EOF > "${SCRATCH}/create-cname.json"
   {
     "Comment":"Add CNAME to ingress controller canonical domain",
     "Changes":[{
         "Action":"CREATE",
         "ResourceRecordSet":{
           "Name": "router-external-dns-ingress.${DOMAIN}",
         "Type":"CNAME",
         "TTL":30,
         "ResourceRecords":[{
           "Value": "${NLB_HOST}"
         }]
       }
     }]
   }
   EOF

   外部 DNS Operator は、この正規ドメインを CNAME レコードのターゲットとして使用します。

3. 変更を伝播するために Amazon Route 53 に送信します。

   aws route53 change-resource-record-sets \
     --hosted-zone-id ${ZONE_ID} \
     --change-batch file://${SCRATCH}/create-cname.json

4. External DNS Operator がカスタムドメインのパブリックホストゾーン のみ を更新できるようにする AWS IAM ポリシードキュメントを作成します。

   $ cat << EOF > "${SCRATCH}/external-dns-policy.json"
   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Action": [
           "route53:ChangeResourceRecordSets"
         ],
         "Resource": [
           "arn:aws:route53:::hostedzone/${ZONE_ID}"
         ]
       },
       {
         "Effect": "Allow",
         "Action": [
           "route53:ListHostedZones",
           "route53:ListResourceRecordSets"
         ],
         "Resource": [
           "*"
         ]
       }
     ]
   }
   EOF

5. AWS IAM ユーザーを作成します。

   $ aws iam create-user --user-name "${CLUSTER}-external-dns-operator"

6. ポリシーを割り当てします。

   $ aws iam attach-user-policy --user-name "${CLUSTER}-external-dns-operator" --policy-arn $POLICY_ARN

   注記

   これは将来的には IRSA を使用した STS に変更される予定です。

7. IAM ユーザーの AWS キーを作成します。

   $ SECRET_ACCESS_KEY=$(aws iam create-access-key --user-name "${CLUSTER}-external-dns-operator")

8. 静的認証情報を作成します。

   $ cat << EOF > "${SCRATCH}/credentials"
   [default]
   aws_access_key_id = $(echo $SECRET_ACCESS_KEY | jq -r '.AccessKey.AccessKeyId')
   aws_secret_access_key = $(echo $SECRET_ACCESS_KEY | jq -r '.AccessKey.SecretAccessKey')
   EOF

1. 新しいプロジェクトを作成します。

   $ oc new-project external-dns-operator

2. OperatorHub から External DNS Operator をインストールします。

   $ cat << EOF | oc apply -f -
   apiVersion: operators.coreos.com/v1
   kind: OperatorGroup
   metadata:
     name: external-dns-group
     namespace: external-dns-operator
   spec:
     targetNamespaces:
     - external-dns-operator
   ---
   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: external-dns-operator
     namespace: external-dns-operator
   spec:
     channel: stable-v1.1
     installPlanApproval: Automatic
     name: external-dns-operator
     source: redhat-operators
     sourceNamespace: openshift-marketplace
   EOF

3. External DNS Operator が実行されるまで待ちます。

   $ oc rollout status deploy external-dns-operator --timeout=300s

4. AWS IAM ユーザー認証情報からシークレットを作成します。

   $ oc -n external-dns-operator create secret generic external-dns \
     --from-file "${SCRATCH}/credentials"

5. ExternalDNS コントローラーをデプロイします。

   $ cat << EOF | oc apply -f -
   apiVersion: externaldns.olm.openshift.io/v1beta1
   kind: ExternalDNS
   metadata:
     name: ${DOMAIN}
   spec:
     domains:
       - filterType: Include
         matchType: Exact
         name: ${DOMAIN}
     provider:
       aws:
         credentials:
           name: external-dns
       type: AWS
     source:
       openshiftRouteOptions:
         routerName: external-dns-ingress
       type: OpenShiftRoute
     zones:
       - ${ZONE_ID}
   EOF

6. コントローラーが実行されるまで待ちます。

   $ oc rollout status deploy external-dns-${DOMAIN} --timeout=300s

1. サンプルアプリケーション用に新しいプロジェクトを作成します。

   $ oc new-project hello-world

2. Hello World アプリケーションをデプロイします。

   $ oc new-app -n hello-world --image=docker.io/openshift/hello-openshift

3. カスタムドメイン名を指定してアプリケーションのルートを作成します。

   $ oc -n hello-world create route edge --service=hello-openshift hello-openshift-tls \
   --hostname hello-openshift.${DOMAIN}

4. DNS レコードが ExternalDNS によって自動的に作成されたかどうかを確認します。

   注記

   レコードが Amazon Route 53 に表示されるまでに数分かかる場合があります。

   $ aws route53 list-resource-record-sets --hosted-zone-id ${ZONE_ID} \
      --query "ResourceRecordSets[?Type == 'CNAME']" | grep hello-openshift

5. オプション: TXT レコードを表示して、レコードが ExternalDNS によって作成されたことを確認することもできます。

   $ aws route53 list-resource-record-sets --hosted-zone-id ${ZONE_ID} \
      --query "ResourceRecordSets[?Type == 'TXT']" | grep ${DOMAIN}

6. curl を実行して新しく作成した DNS レコードをサンプルアプリケーションを取得し、Hello World アプリケーションにアクセスできることを確認します。

   $ curl https://hello-openshift.${DOMAIN}

   出力例

   Hello OpenShift!

1. 次の環境変数を設定します。

   $ export DOMAIN=apps.example.com 1
   $ export EMAIL=email@example.com 2
   $ export AWS_PAGER=""
   $ export CLUSTER=$(oc get infrastructure cluster -o=jsonpath="{.status.infrastructureName}"  | sed 's/-[a-z0-9]\{5\}$//')
   $ export OIDC_ENDPOINT=$(oc get authentication.config.openshift.io cluster -o json | jq -r .spec.serviceAccountIssuer | sed  's|^https://||')
   $ export REGION=$(oc get infrastructure cluster -o=jsonpath="{.status.platformStatus.aws.region}")
   $ export AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
   $ export SCRATCH="/tmp/${CLUSTER}/dynamic-certs"
   $ mkdir -p ${SCRATCH}

   1

   IngressController に使用するカスタムドメインに置き換えます。

   2

   Let's Encrypt が証明書に関する通知を送信するために使用するメールに置き換えます。

2. 次のセクションに進む前に、すべてのフィールドが正しく出力されていることを確認してください。

   $ echo "Cluster: ${CLUSTER}, Region: ${REGION}, OIDC Endpoint: ${OIDC_ENDPOINT}, AWS Account ID: ${AWS_ACCOUNT_ID}"

   注記

   前のコマンドからの "Cluster" の出力は、クラスターの名前、クラスターの内部 ID、またはクラスターのドメイン接頭辞である可能性があります。別の識別子を使用する場合は、次のコマンドを実行して手動でこの値を設定できます。

   $ export CLUSTER=my-custom-value

1. Amazon Route 53 のパブリックホストゾーン ID を取得します。

   注記

   このコマンドは、DOMAIN 環境変数として以前指定したカスタムドメインに一致するパブリックホストゾーンを検索します。Amazon Route 53 パブリックホストゾーンを手動で指定するには、export ZONE_ID=<zone_ID> を実行し、<zone_ID> を特定の Amazon Route 53 パブリックホストゾーン ID に置き換えます。

   $ export ZONE_ID=$(aws route53 list-hosted-zones-by-name --output json \
     --dns-name "${DOMAIN}." --query 'HostedZones[0]'.Id --out text | sed 's/\/hostedzone\///')

2. 指定されたパブリックホストゾーン のみ を更新する機能を提供する cert-manager Operator の AWS IAM ポリシードキュメントを作成します。

   $ cat <<EOF > "${SCRATCH}/cert-manager-policy.json"
   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Action": "route53:GetChange",
         "Resource": "arn:aws:route53:::change/*"
       },
       {
         "Effect": "Allow",
         "Action": [
           "route53:ChangeResourceRecordSets",
           "route53:ListResourceRecordSets"
         ],
         "Resource": "arn:aws:route53:::hostedzone/${ZONE_ID}"
       },
       {
         "Effect": "Allow",
         "Action": "route53:ListHostedZonesByName",
         "Resource": "*"
       }
     ]
   }
   EOF

3. 前のステップで作成したファイルを使用して IAM ポリシーを作成します。

   $ POLICY_ARN=$(aws iam create-policy --policy-name "${CLUSTER}-cert-manager-policy" \
     --policy-document file://${SCRATCH}/cert-manager-policy.json \
     --query 'Policy.Arn' --output text)

4. cert-manager Operator の AWS IAM 信頼ポリシーを作成します。

   $ cat <<EOF > "${SCRATCH}/trust-policy.json"
   {
    "Version": "2012-10-17",
    "Statement": [
    {
    "Effect": "Allow",
    "Condition": {
      "StringEquals" : {
        "${OIDC_ENDPOINT}:sub": "system:serviceaccount:cert-manager:cert-manager"
      }
    },
    "Principal": {
      "Federated": "arn:aws:iam::$AWS_ACCOUNT_ID:oidc-provider/${OIDC_ENDPOINT}"
    },
    "Action": "sts:AssumeRoleWithWebIdentity"
    }
    ]
   }
   EOF

5. 前のステップで作成した信頼ポリシーを使用して、cert-manager Operator の IAM ロールを作成します。

   $ ROLE_ARN=$(aws iam create-role --role-name "${CLUSTER}-cert-manager-operator" \
      --assume-role-policy-document "file://${SCRATCH}/trust-policy.json" \
      --query Role.Arn --output text)

6. 権限ポリシーをロールに割り当てます。

   $ aws iam attach-role-policy --role-name "${CLUSTER}-cert-manager-operator" \
     --policy-arn ${POLICY_ARN}

1. cert-manager Operator をインストールするプロジェクトを作成します。

   $ oc new-project cert-manager-operator

   重要

   クラスター内で複数の cert-manager Operator を使用しないでください。クラスターにコミュニティーの cert-manager Operator がインストールされている場合は、それをアンインストールしてから cert-manager Operator for Red Hat OpenShift をインストールする必要があります。

2. cert-manager Operator for Red Hat OpenShift をインストールします。

   $ cat << EOF | oc apply -f -
   apiVersion: operators.coreos.com/v1
   kind: OperatorGroup
   metadata:
     name: openshift-cert-manager-operator-group
     namespace: cert-manager-operator
   spec:
     targetNamespaces:
     - cert-manager-operator
   ---
   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: openshift-cert-manager-operator
     namespace: cert-manager-operator
   spec:
     channel: stable-v1
     installPlanApproval: Automatic
     name: openshift-cert-manager-operator
     source: redhat-operators
     sourceNamespace: openshift-marketplace
   EOF

   注記

   この Operator がインストールされ、セットアップが完了するまでに数分かかります。

3. cert-manager Operator が実行されていることを確認します。

   $ oc -n cert-manager-operator get pods

   出力例

   NAME                                                        READY   STATUS    RESTARTS   AGE
   cert-manager-operator-controller-manager-84b8799db5-gv8mx   2/2     Running   0          12s

4. cert-manager Pod によって使用されるサービスアカウントに、前に作成した AWS IAM ロールのアノテーションを付けます。

   $ oc -n cert-manager annotate serviceaccount cert-manager eks.amazonaws.com/role-arn=${ROLE_ARN}

5. 次のコマンドを実行して、既存の cert-manager コントローラー Pod を再起動します。

   $ oc -n cert-manager delete pods -l app.kubernetes.io/name=cert-manager

6. DNS-01 チャレンジ解決の問題を防ぐために、外部ネームサーバーを使用するように Operator の設定にパッチを適用します。

   $ oc patch certmanager.operator.openshift.io/cluster --type merge \
     -p '{"spec":{"controllerConfig":{"overrideArgs":["--dns01-recursive-nameservers-only","--dns01-recursive-nameservers=1.1.1.1:53"]}}}'

7. 次のコマンドを実行して、Let's Encrypt を使用する ClusterIssuer リソースを作成します。

   $ cat << EOF | oc apply -f -
   apiVersion: cert-manager.io/v1
   kind: ClusterIssuer
   metadata:
     name: letsencrypt-production
   spec:
     acme:
       server: https://acme-v02.api.letsencrypt.org/directory
       email: ${EMAIL}
       # This key doesn't exist, cert-manager creates it
       privateKeySecretRef:
         name: prod-letsencrypt-issuer-account-key
       solvers:
       - dns01:
           route53:
            hostedZoneID: ${ZONE_ID}
            region: ${REGION}
            secretAccessKeySecretRef:
              name: ''
   EOF

8. ClusterIssuer リソースの準備ができていることを確認します。

   $ oc get clusterissuer.cert-manager.io/letsencrypt-production

   出力例

   NAME                     READY   AGE
   letsencrypt-production   True    47s

1. 証明書リソースを作成して設定し、カスタムドメイン Ingress Controller の証明書をプロビジョニングします。

   注記

   次の例では、単一のドメイン証明書を使用します。SAN およびワイルドカード証明書もサポートされています。

   $ cat << EOF | oc apply -f -
   apiVersion: cert-manager.io/v1
   kind: Certificate
   metadata:
     name: custom-domain-ingress-cert
     namespace: openshift-ingress
   spec:
     secretName: custom-domain-ingress-cert-tls
     issuerRef:
        name: letsencrypt-production
        kind: ClusterIssuer
     commonName: "${DOMAIN}"
     dnsNames:
     - "${DOMAIN}"
   EOF

2. 証明書が発行されたことを確認します。

   注記

   Let's Encrypt によってこの証明書が発行されるまでに数分かかります。5 分以上かかる場合は、oc -n openshift-Ingress describe certificate.cert-manager.io/custom-domain-Ingress-cert を実行して、cert-manager によって報告された問題を確認します。

   $ oc -n openshift-ingress get certificate.cert-manager.io/custom-domain-ingress-cert

   出力例

   NAME                         READY   SECRET                           AGE
   custom-domain-ingress-cert   True    custom-domain-ingress-cert-tls   9m53s

3. 新規の IngressController リソースを作成します。

   $ cat << EOF | oc apply -f -
   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
     name: custom-domain-ingress
     namespace: openshift-ingress-operator
   spec:
     domain: ${DOMAIN}
     defaultCertificate:
       name: custom-domain-ingress-cert-tls
     endpointPublishingStrategy:
       loadBalancer:
         dnsManagementPolicy: Unmanaged
         providerParameters:
           aws:
             type: NLB
           type: AWS
         scope: External
       type: LoadBalancerService
   EOF

   警告

   この IngressController の例では、インターネットにアクセス可能な Network Load Balancer (NLB) を AWS アカウントに作成します。代わりに内部 NLB をプロビジョニングするには、IngressController リソースを作成する前に、.spec.endpointPublishingStrategy.loadBalancer.scope パラメーターを Internal に設定します。

4. カスタムドメイン IngressController が外部ロードバランサーを正常に作成したことを確認します。

   $ oc -n openshift-ingress get service/router-custom-domain-ingress

   出力例

   NAME                           TYPE           CLUSTER-IP      EXTERNAL-IP                                                                     PORT(S)                      AGE
   router-custom-domain-ingress   LoadBalancer   172.30.174.34   a309962c3bd6e42c08cadb9202eca683-1f5bbb64a1f1ec65.elb.us-east-1.amazonaws.com   80:31342/TCP,443:31821/TCP   7m28s

5. カスタムドメイン Ingress Controller の DNS 解決を有効にするために必要な DNS 変更を含むドキュメントを準備します。

   $ INGRESS=$(oc -n openshift-ingress get service/router-custom-domain-ingress -ojsonpath="{.status.loadBalancer.ingress[0].hostname}")
   $ cat << EOF > "${SCRATCH}/create-cname.json"
   {
     "Comment":"Add CNAME to custom domain endpoint",
     "Changes":[{
         "Action":"CREATE",
         "ResourceRecordSet":{
           "Name": "*.${DOMAIN}",
         "Type":"CNAME",
         "TTL":30,
         "ResourceRecords":[{
           "Value": "${INGRESS}"
         }]
       }
     }]
   }
   EOF

6. 変更を伝播するために Amazon Route 53 に送信します。

   $ aws route53 change-resource-record-sets \
     --hosted-zone-id ${ZONE_ID} \
     --change-batch file://${SCRATCH}/create-cname.json

   注記

   ワイルドカード CNAME レコードを使用すると、カスタムドメイン Ingress Controller を使用してデプロイする新しいアプリケーションごとに新しいレコードを作成する必要がなくなりますが、これらの各アプリケーションが使用する証明書は、ワイルドカード証明書 ではありません。

1. cert-manager による OpenShift ルートの証明書の管理に必要な OpenShift リソースを作成します。

   このステップでは、クラスター内のアノテーション付きルートを特別に監視する新しいデプロイメント (とその Pod) を作成します。新しいルートで issuer-kind および issuer-name アノテーションが検出された場合、ルートの作成時に指定されたホスト名を受け入れる、このルートに固有の新しい証明書を発行者 (この場合は ClusterIssuer) に要求します。

   注記

   クラスターから GitHub にアクセスできない場合は、raw コンテンツをローカルに保存し、oc apply -f localfilename.yaml -n cert-manager を実行します。

   $ oc -n cert-manager apply -f https://github.com/cert-manager/openshift-routes/releases/latest/download/cert-manager-openshift-routes.yaml

   このステップでは、次の追加の OpenShift リソースも作成されます。

   • ClusterRole - クラスター全体のルートを監視および更新する権限を付与します。
   • ServiceAccount - 新しく作成された Pod を実行する権限を使用します。
   • ClusterRoleBinding - これら 2 つのリソースをバインドします。

2. 新しい cert-manager-openshift-routes Pod が正常に実行されていることを確認します。

   $ oc -n cert-manager get pods

   結果の例:

   NAME                                             READY   STATUS    RESTARTS   AGE
   cert-manager-866d8f788c-9kspc                    1/1     Running   0          4h21m
   cert-manager-cainjector-6885c585bd-znws8         1/1     Running   0          4h41m
   cert-manager-openshift-routes-75b6bb44cd-f8kd5   1/1     Running   0          6s
   cert-manager-webhook-8498785dd9-bvfdf            1/1     Running   0          4h41m

1. サンプルアプリケーション用に新しいプロジェクトを作成します。

   $ oc new-project hello-world

2. Hello World アプリケーションをデプロイします。

   $ oc -n hello-world new-app --image=docker.io/openshift/hello-openshift

3. クラスターの外部からアプリケーションを公開するためのルートを作成します。

   $ oc -n hello-world create route edge --service=hello-openshift hello-openshift-tls --hostname hello.${DOMAIN}

4. ルートの証明書が信頼されていないことを確認します。

   $ curl -I https://hello.${DOMAIN}

   出力例

   curl: (60) SSL: no alternative certificate subject name matches target host name 'hello.example.com'
   More details here: https://curl.se/docs/sslcerts.html
   
   curl failed to verify the legitimacy of the server and therefore could not
   establish a secure connection to it. To learn more about this situation and
   how to fix it, please visit the web page mentioned above.

5. ルートにアノテーションを付けて、cert-manager をトリガーしてカスタムドメインの証明書をプロビジョニングします。

   $ oc -n hello-world annotate route hello-openshift-tls cert-manager.io/issuer-kind=ClusterIssuer cert-manager.io/issuer-name=letsencrypt-production

   注記

   証明書の作成には 2 - 3 分かかります。証明書の更新は、有効期限が近づくと、cert-manager Operator によって自動的に処理されます。

6. ルートの証明書が信頼されていることを確認します。

   $ curl -I https://hello.${DOMAIN}

   出力例

   HTTP/2 200
   date: Thu, 05 Oct 2023 23:45:33 GMT
   content-length: 17
   content-type: text/plain; charset=utf-8
   set-cookie: 52e4465485b6fb4f8a1b1bed128d0f3b=68676068bb32d24f0f558f094ed8e4d7; path=/; HttpOnly; Secure; SameSite=None
   cache-control: private

1. Egress IP ルールを作成する前に、使用する Egress IP を特定します。

   注記

   選択する Egress IP は、ワーカーノードがプロビジョニングされているサブネットの一部として存在する必要があります。

2. オプション: AWS Virtual Private Cloud (VPC) Dynamic Host Configuration Protocol (DHCP) サービスとの競合を回避するために、要求した Egress IP を予約します。

   CIDR 予約ページの AWS ドキュメント で明示的な IP 予約をリクエストします。

1. 次のコマンドを実行して新しいプロジェクトを作成します。

   $ oc new-project demo-egress-ns

2. 次のコマンドを実行して、namespace 内のすべての Pod に Egress ルールを作成します。

   $ cat <<EOF | oc apply -f -
   apiVersion: k8s.ovn.org/v1
   kind: EgressIP
   metadata:
     name: demo-egress-ns
   spec:
     # NOTE: these egress IPs are within the subnet range(s) in which my worker nodes
     #       are deployed.
     egressIPs:
       - 10.10.100.253
       - 10.10.150.253
       - 10.10.200.253
     namespaceSelector:
       matchLabels:
         kubernetes.io/metadata.name: demo-egress-ns
   EOF

1. 次のコマンドを実行して新しいプロジェクトを作成します。

   $ oc new-project demo-egress-pod

2. 次のコマンドを実行して、Pod の Egress ルールを作成します。

   注記

   spec.namespaceSelector は必須フィールドです。

   $ cat <<EOF | oc apply -f -
   apiVersion: k8s.ovn.org/v1
   kind: EgressIP
   metadata:
     name: demo-egress-pod
   spec:
     # NOTE: these egress IPs are within the subnet range(s) in which my worker nodes
     #       are deployed.
     egressIPs:
       - 10.10.100.254
       - 10.10.150.254
       - 10.10.200.254
     namespaceSelector:
       matchLabels:
         kubernetes.io/metadata.name: demo-egress-pod
     podSelector:
       matchLabels:
         run: demo-egress-pod
   EOF

1. 次のコマンドを実行してクラスターをクリーンアップします。

   $ oc delete svc demo-service -n default; \
   $ oc delete pod demo-service -n default; \
   $ oc delete project demo-egress-ns; \
   $ oc delete project demo-egress-pod; \
   $ oc delete egressip demo-egress-ns; \
   $ oc delete egressip demo-egress-pod

2. 次のコマンドを実行して、割り当てられたノードラベルをクリーンアップします。

   警告

   マシンプールのノードラベルに依存している場合は、このコマンドによってそれらのラベルが置き換えられます。ノードラベルを保持するには、必要なラベルを --labels フィールドに入力します。

   $ rosa update machinepool ${ROSA_MACHINE_POOL_NAME} \
     --cluster="${ROSA_CLUSTER_NAME}" \
     --labels ""

1. cluster-admin 権限を持つアカウントを使用してクラスターにログインします。

2. クラスター名の環境変数を設定します。

   $ export CLUSTER_NAME=$(oc get infrastructure cluster -o=jsonpath="{.status.infrastructureName}"  | sed 's/-[a-z0-9]\{5\}$//')

3. 次のセクションに進む前に、すべてのフィールドが正しく出力されていることを確認してください。

   $ echo "Cluster: ${CLUSTER_NAME}"

   出力例

   Cluster: my-rosa-cluster

1. デフォルトのホスト名でコンポーネントルートに到達できることを確認します。

   openshift-console および openshift-authentication プロジェクトでルートのリストをクエリーすることで、ホスト名を確認できます。

   $ oc get routes -n openshift-console
   $ oc get routes -n openshift-authentication

   出力例

   NAME        HOST/PORT                                                                          PATH       SERVICES    PORT    TERMINATION          WILDCARD
   console     console-openshift-console.apps.my-example-cluster-aws.z9a9.p1.openshiftapps.com    ... 1 more  console    https   reencrypt/Redirect   None
   downloads   downloads-openshift-console.apps.my-example-cluster-aws.z9a9.p1.openshiftapps.com  ... 1 more  downloads  http    edge/Redirect        None
   NAME              HOST/PORT                                                             PATH        SERVICES          PORT   TERMINATION            WILDCARD
   oauth-openshift   oauth-openshift.apps.my-example-cluster-aws.z9a9.p1.openshiftapps.com ... 1 more  oauth-openshift   6443   passthrough/Redirect   None

   この出力から、ベースホスト名が z9a9.p1.openshiftapps.com であることを確認できます。

2. 次のコマンドを実行して、デフォルト Ingress の ID を取得します。

   $ export INGRESS_ID=$(rosa list ingress -c ${CLUSTER_NAME} -o json | jq -r '.[] | select(.default == true) | .id')

3. 次のセクションに進む前に、すべてのフィールドが正しく出力されていることを確認してください。

   $ echo "Ingress ID: ${INGRESS_ID}"

   出力例

   Ingress ID: r3l6

   これらのコマンドを実行すると、クラスターのデフォルトのコンポーネントルートが次のとおりであることがわかります。

   • console-openshift-console.apps.my-example-cluster-aws.z9a9.p1.openshiftapps.com (Console の場合)
   • downloads-openshift-console.apps.my-example-cluster-aws.z9a9.p1.openshiftapps.com (Downloads の場合)
   • oauth-openshift.apps.my-example-cluster-aws.z9a9.p1.openshiftapps.com (OAuth の場合)

1. 各コンポーネントルートの証明書を生成し、使用するコンポーネントルートのカスタムドメインに、証明書のサブジェクト (-subj) を設定するように注意してください。

   例

   $ openssl req -newkey rsa:2048 -new -nodes -x509 -days 365 -keyout key-console.pem -out cert-console.pem -subj "/CN=console.my-new-domain.dev"
   $ openssl req -newkey rsa:2048 -new -nodes -x509 -days 365 -keyout key-downloads.pem -out cert-downloads.pem -subj "/CN=downloads.my-new-domain.dev"
   $ openssl req -newkey rsa:2048 -new -nodes -x509 -days 365 -keyout key-oauth.pem -out cert-oauth.pem -subj "/CN=oauth.my-new-domain.dev"

   これにより、.pem ファイル、key-<component>.pem、cert-<component>.pem ペアが 3 つ生成されます。

1. openshift-config namespace に 3 つの TLS シークレットを作成します。

   これは、このガイドで後にコンポーネントルートを更新するときのシークレット参照になります。

   $ oc create secret tls console-tls --cert=cert-console.pem --key=key-console.pem -n openshift-config
   $ oc create secret tls downloads-tls --cert=cert-downloads.pem --key=key-downloads.pem -n openshift-config
   $ oc create secret tls oauth-tls --cert=cert-oauth.pem --key=key-oauth.pem -n openshift-config

1. rosa edit Ingress コマンドを使用して、デフォルトの Ingress ルートを新しいベースドメインとそれに関連付けられたシークレット参照で更新します。その際、各コンポーネントルートのホスト名を更新するように注意してください。

   $ rosa edit ingress -c ${CLUSTER_NAME} ${INGRESS_ID} --component-routes 'console: hostname=console.my-new-domain.dev;tlsSecretRef=console-tls,downloads: hostname=downloads.my-new-domain.dev;tlsSecretRef=downloads-tls,oauth: hostname=oauth.my-new-domain.dev;tlsSecretRef=oauth-tls'

   注記

   変更しないコンポーネントルートを空の文字列に設定したままにして、コンポーネントルートのサブセットのみを編集することもできます。たとえば、コンソールおよび OAuth サーバーのホスト名および TLS 証明書のみを変更する場合は、以下のコマンドを実行します。

   $ rosa edit ingress -c ${CLUSTER_NAME} ${INGRESS_ID} --component-routes 'console: hostname=console.my-new-domain.dev;tlsSecretRef=console-tls,downloads: hostname="";tlsSecretRef="", oauth: hostname=oauth.my-new-domain.dev;tlsSecretRef=oauth-tls'

2. rosa list ingress コマンドを実行して、変更が正常に行われたことを確認します。

   $ rosa list ingress -c ${CLUSTER_NAME} -ojson | jq ".[] | select(.id == \"${INGRESS_ID}\") | .component_routes"

   出力例

   {
     "console": {
       "kind": "ComponentRoute",
       "hostname": "console.my-new-domain.dev",
       "tls_secret_ref": "console-tls"
     },
     "downloads": {
       "kind": "ComponentRoute",
       "hostname": "downloads.my-new-domain.dev",
       "tls_secret_ref": "downloads-tls"
     },
     "oauth": {
       "kind": "ComponentRoute",
       "hostname": "oauth.my-new-domain.dev",
       "tls_secret_ref": "oauth-tls"
     }
   }

3. ローカルシステムのトラストストアに証明書を追加し、ローカル Web ブラウザーを使用して新しいルートでコンポーネントにアクセスできることを確認します。

1. 次のコマンドを実行して管理ユーザーを作成します。

   rosa create admin --cluster=<cluster-name>

   出力例

   W: It is recommended to add an identity provider to login to this cluster. See 'rosa create idp --help' for more information.
   I: Admin account has been added to cluster 'my-rosa-cluster'. It may take up to a minute for the account to become active.
   I: To login, run the following command:
   oc login https://api.my-rosa-cluster.abcd.p1.openshiftapps.com:6443 \
   --username cluster-admin \
   --password FWGYL-2mkJI-00000-00000

2. 前のステップで返されたログインコマンドをコピーし、ターミナルに貼り付けます。これにより、CLI を使用してクラスターにログインし、クラスターの使用を開始できるようになります。

   $ oc login https://api.my-rosa-cluster.abcd.p1.openshiftapps.com:6443 \
   >    --username cluster-admin \
   >    --password FWGYL-2mkJI-00000-00000

   出力例

   Login successful.
   
   You have access to 79 projects, the list has been suppressed. You can list all projects with ' projects'
   
   Using project "default".

3. 管理ユーザーとしてログインしていることを確認するには、次のコマンドのいずれかを実行します。

   • オプション 1:

     $ oc whoami

     出力例

     cluster-admin

   • オプション 2:

     oc get all -n openshift-apiserver

     このコマンドをエラーなしで実行できるのは管理ユーザーのみです。

4. これでクラスターを管理ユーザーとして使用できるようになりました。このチュートリアルではこれで十分です。実際のデプロイメントでは、アイデンティティープロバイダーをセットアップすることを強く推奨します。これについては、次のチュートリアル で説明します。

手順

1. GitHub Webhook トリガーのシークレットを取得するために、ターミナルで次のコマンドを実行します。

   $ oc get bc/ostoy-microservice -o=jsonpath='{.spec.triggers..github.secret}'

   出力例

   `o_3x9M1qoI2Wj_cz1WiK`

   重要

   このプロセスの後のステップでこのシークレットを使用する必要があります。

2. OSToy の buildconfig から GitHub Webhook トリガーの URL を取得するために、次のコマンドを実行します。

   $ oc describe bc/ostoy-microservice

   出力例

   [...]
   Webhook GitHub:
   	URL:	https://api.demo1234.openshift.com:443/apis/build.openshift.io/v1/namespaces/ostoy-s2i/buildconfigs/ostoy/webhooks/<secret>/github
   [...]

3. GitHub Webhook URL の <secret> テキストを、取得したシークレットに置き換えます。実際の URL は、次の出力例のようになります。

   出力例

   https://api.demo1234.openshift.com:443/apis/build.openshift.io/v1/namespaces/ostoy-s2i/buildconfigs/ostoy-microservice/webhooks/o_3x9M1qoI2Wj_czR1WiK/github

4. GitHub リポジトリーで Webhook URL を設定します。

   1. リポジトリーで、Settings > Webhooks > Add webhook をクリックします。

      
   2. "Payload URL" フィールドに、Secret を含む GitHub Webhook URL を貼り付けます。
   3. "Content type" を application/json に変更します。

   4. Add webhook ボタンをクリックします。

      

      Webhook が正常に設定されたことを示す GitHub のメッセージが表示されます。これで、GitHub リポジトリーに変更をプッシュするたびに、新しいビルドが自動的に開始し、ビルドが成功すると新しいデプロイが開始します。

5. ソースコードを変更します。変更すると、ビルドとデプロイが自動的にトリガーされます。この例では、OSToy アプリケーションのステータスを示す色がランダムに選択されます。設定をテストするために、グレースケールのみを表示するようにボックスを変更します。

   1. リポジトリー内のソースコード https://github.com/<username>/ostoy/blob/master/microservice/app.js に移動します。
   2. ファイルを編集します。
   3. 8 行目 (let randomColor = getRandomColor(); を含む行) をコメントアウトします。

   4. 9 行目 (let randomColor = getRandomGrayScaleColor(); を含む行) のコメントを解除します。

      7   app.get('/', function(request, response) {
      8   //let randomColor = getRandomColor(); // <-- comment this
      9   let randomColor = getRandomGrayScaleColor(); // <-- uncomment this
      10
      11  response.writeHead(200, {'Content-Type': 'application/json'});

   5. "changed box to grayscale colors" など、更新を示すメッセージを入力します。
   6. 下部の Commit クリックして、変更をメインブランチにコミットします。

6. クラスターの Web UI で、Builds > Builds をクリックして、ビルドのステータスを確認します。このビルドが完了すると、デプロイが開始します。ターミナルで oc status を実行してステータスを確認することもできます。

   

7. デプロイが完了したら、ブラウザーで OSToy アプリケーションに戻ります。左側の Networking メニュー項目にアクセスします。ボックスの色がグレースケールの色だけに制限されるようになります。