View a markdown version of this page

CLI を使用して ROSA with HCP ROSA クラスターを作成する - Red Hat OpenShift Service on AWS
前提条件Amazon VPC アーキテクチャの作成必要な IAM ロールと OpenID Connect 設定を作成するCLI と を使用して ROSA with HCP ROSA クラスターを作成する AWS STSID プロバイダーを設定し、 クラスター アクセス権を付与するへのアクセスをユーザーに許可する クラスターcluster-admin のアクセス許可を設定します。dedicated-admin のアクセス許可を設定します。Red Hat Hybrid Cloud コンソール クラスター から にアクセスするDeveloper Catalog からアプリケーションをデプロイするユーザーから cluster-admin 権限を取り消すユーザーから dedicated-admin 権限を取り消すへのユーザーアクセスを取り消す クラスタークラスターと AWS STS リソースを削除する

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

CLI を使用して ROSA with HCP ROSA クラスターを作成する

以下のセクションでは、 AWS STS および CLI を使用して、ホスト型コントロールプレーン (ROSA with HCP) で ROSA ROSA の使用を開始する方法について説明します。Terraform を使用して ROSA with HCP クラスターを作成する手順については、Red Hat のドキュメントを参照してください。 ROSA クラスターを作成するための Terraform プロバイダーの詳細については、Terraform ドキュメントを参照してください。

ROSA CLI は auto モードまたは manual モードを使用して、 の作成に必要な IAM ROSA リソースと OpenID Connect (OIDC) 設定を作成します クラスター。 auto モードは、必要な IAM ロールとポリシーと OIDC プロバイダーを自動的に作成します。 manual モードは、 IAM リソースを手動で作成するために必要な AWS CLI コマンドを出力します。manual モードを使用すると、生成された AWS CLI コマンドを手動で実行する前に確認できます。manual モードを使用すると、コマンドを組織内の別の管理者またはグループに渡して、リソースを作成してもらうこともできます。

このドキュメントの手順では、 CLI ROSA の auto モードを使用して、HCP を使用する ROSA に必要な IAM リソースと OIDC 設定を作成します。開始するためのその他のオプションについては、「」を参照してくださいの使用を開始する ROSA。

前提条件

に記載されている前提条件となるアクションを完了しますを使用するように をセットアップする ROSA。

Amazon VPC アーキテクチャの作成

次の手順では、クラスターをホストするために使用できる Amazon VPC アーキテクチャを作成します。すべての クラスター リソースはプライベートサブネットでホストされます。パブリックサブネットは、プライベートサブネットからのアウトバウンドトラフィックを NAT ゲートウェイ経由でパブリックインターネットにルーティングします。この例では、 Amazon VPCに CIDR ブロック 10.0.0.0/16 を使用しています。別の CIDR ブロックを選択することもできます。詳細については、「VPC のサイズ設定」を参照してください。

重要

Amazon VPC 要件を満たさない場合、クラスターの作成は失敗します。

例
Terraform

  1. Terraform CLI をインストールします。詳細については、Terraform ドキュメントのインストール手順を参照してください。

  2. ターミナルセッションを開き、Terraform VPC リポジトリのクローンを作成します。

    git clone https://github.com/openshift-cs/terraform-vpc-example

  3. 作成したディレクトリに移動します。

    cd terraform-vpc-example

  4. Terraform ファイルを開始します。

    terraform init

    完了すると、CLI は Terraform が正常に初期化されたことを示すメッセージを返します。

  5. 既存のテンプレートに基づいて Terraform プランを構築するには、次のコマンドを実行します。を指定 AWS リージョン する必要があります。必要に応じて、クラスター名を指定できます。

    terraform plan -out rosa.tfplan -var region=<region>

    コマンドが実行されると、rosa.tfplanファイルが hypershift-tf ディレクトリに追加されます。詳細については、Terraform VPC リポジトリの README ファイルを参照してください。

  6. プランファイルを適用して VPC を構築します。

    terraform apply rosa.tfplan

    完了すると、CLI は、追加されたリソースを検証する成功メッセージを返しました。

    1. (オプション) HCP クラスターで ROSA を作成するときに使用する Terraform でプロビジョニングされたプライベートサブネット、パブリックサブネット、およびマシンプールサブネット IDs の環境変数を作成します。

      export SUBNET_IDS=$(terraform output -raw cluster-subnets-string)

    2. (オプション) 環境変数が正しく設定されていることを確認します。

      echo $SUBNET_IDS
Amazon VPC console

  1. Amazon VPC コンソール を開きます。

  2. VPC ダッシュボードで、[Create VPC (VPC を作成する)] を選択します。

  3. [Resources to create] (作成するリソース) で、[VPC and more] (VPC など) を選択します。

  4. [名前タグの自動生成] を選択したままにすると VPC リソース用の名前タグが作成され、オフにすると VPC リソース用の独自の名前タグが作成されます。

  5. [IPv4 CIDR ブロック] に VPC の IPv4 アドレス範囲を入力します。VPC には IPv4 アドレス範囲が必要です。

  6. (オプション) IPv6 トラフィックをサポートするには、IPv6 CIDR ブロック、Amazon 提供の IPv6 CIDR ブロックを選択します。

  7. テナンシーは のままにしますDefault。

  8. アベイラビリティーゾーンの数 (AZs) で、必要な数を選択します。マルチ AZ 配置の場合、 ROSA には 3 つのアベイラビリティーゾーンが必要です。サブネットの AZ を選択するには、[AZ のカスタマイズ] を展開します。

    注記

    一部の ROSA インスタンスタイプは、一部のアベイラビリティーゾーンでのみ使用できます。 ROSA CLI rosa list instance-types コマンドを使用して、使用可能なすべての ROSA インスタンスタイプを一覧表示できます。特定のアベイラビリティーゾーンでインスタンスタイプが使用可能かどうかを確認するには、 AWS CLI コマンド を使用しますaws ec2 describe-instance-type-offerings --location-type availability-zone --filters Name=location,Values=<availability_zone> --region <region> --output text | egrep "<instance_type>"。

  9. サブネットを設定するには、[パブリックサブネットの数] と [プライベートサブネットの数] の値を選択します。サブネットの IP アドレス範囲を選択するには、[サブネット CIDR ブロックをカスタマイズ] を展開します。

    注記

    HCP を備えた ROSA では、お客様がクラスターの作成に使用するアベイラビリティーゾーンごとに少なくとも 1 つのパブリックサブネットとプライベートサブネットを設定する必要があります。

  10. プライベートサブネット内のリソースに IPv4 経由でパブリックインターネットへのアクセスを許可するには、NAT ゲートウェイの場合は、NAT ゲートウェイを作成する AZs の数を選択します。本番環境では、パブリックインターネットへのアクセスを必要とするリソースがある各 AZ に NAT ゲートウェイをデプロイすることをお勧めします。

  11. (オプション) VPC Amazon S3 から直接 にアクセスする必要がある場合は、VPC エンドポイント、S3 Gateway を選択します。

  12. デフォルトの DNS オプションを選択したままにします。VPC での DNS ホスト名のサポート ROSA が必要です。

  13. 追加タグを展開し、新しいタグを追加を選択し、次のタグキーを追加します。 は、これらのタグが使用されていることを確認する自動プリフライトチェック ROSA を使用します。

    • [Key] (キー): kubernetes.io/role/elb

    • [Key] (キー): kubernetes.io/role/internal-elb

  14. [Create VPC（VPC の作成）] を選択します。

AWS CLI

  1. 10.0.0.0/16 CIDR ブロックを持つ VPC を作成します。

     aws ec2 create-vpc \
     --cidr-block 10.0.0.0/16 \
     --query Vpc.VpcId \
     --output text

    前述のコマンドは VPC ID を返します。以下に出力例を示します。

    vpc-1234567890abcdef0

  2. VPC ID を 環境変数に保存します。

    export VPC_ID=vpc-1234567890abcdef0

  3. VPC_ID 環境変数を使用して、VPC のNameタグを作成します。

    aws ec2 create-tags --resources $VPC_ID --tags Key=Name,Value=MyVPC

  4. VPC で DNS ホスト名サポートを有効にします。

    aws ec2 modify-vpc-attribute \
    --vpc-id $VPC_ID \
    --enable-dns-hostnames

  5. VPC にパブリックサブネットとプライベートサブネットを作成し、リソースを作成するアベイラビリティーゾーンを指定します。

    重要

    HCP を備えた ROSA では、お客様がクラスターの作成に使用するアベイラビリティーゾーンごとに少なくとも 1 つのパブリックサブネットとプライベートサブネットを設定する必要があります。マルチ AZ 配置の場合、3 つのアベイラビリティーゾーンが必要です。これらの要件を満たさないと、クラスターの作成は失敗します。

    注記

    一部の ROSA インスタンスタイプは、一部のアベイラビリティーゾーンでのみ使用できます。 ROSA CLI rosa list instance-types コマンドを使用して、使用可能なすべての ROSA インスタンスタイプを一覧表示できます。特定のアベイラビリティーゾーンでインスタンスタイプが使用可能かどうかを確認するには、 AWS CLI コマンド を使用しますaws ec2 describe-instance-type-offerings --location-type availability-zone --filters Name=location,Values=<availability_zone> --region <region> --output text | egrep "<instance_type>"。

    aws ec2 create-subnet \
    --vpc-id $VPC_ID \
    --cidr-block 10.0.1.0/24 \
    --availability-zone us-east-1a \
    --query Subnet.SubnetId \
    --output text
aws ec2 create-subnet \
    --vpc-id $VPC_ID \
    --cidr-block 10.0.0.0/24 \
    --availability-zone us-east-1a \
    --query Subnet.SubnetId \
    --output text

  6. パブリックサブネット ID とプライベートサブネット IDsを環境変数に保存します。

    export PUBLIC_SUB=subnet-1234567890abcdef0
export PRIVATE_SUB=subnet-0987654321fedcba0

  7. VPC subnets に次のタグを作成します。これらのタグが使用されていることを確認する ROSA 自動プリフライトチェックを使用します。

    注記

    少なくとも 1 つのプライベートサブネット、および該当する場合は 1 つのパブリックサブネットにタグを付ける必要があります。

    aws ec2 create-tags --resources $PUBLIC_SUB --tags Key=kubernetes.io/role/elb,Value=1
aws ec2 create-tags --resources $PRIVATE_SUB --tags Key=kubernetes.io/role/internal-elb,Value=1

  8. アウトバウンドトラフィック用のインターネットゲートウェイとルートテーブルを作成します。プライベートトラフィックのルートテーブルと Elastic IP アドレスを作成します。

    aws ec2 create-internet-gateway \
    --query InternetGateway.InternetGatewayId \
    --output text
aws ec2 create-route-table \
    --vpc-id $VPC_ID \
    --query RouteTable.RouteTableId \
    --output text
aws ec2 allocate-address \
    --domain vpc \
    --query AllocationId \
    --output text
aws ec2 create-route-table \
    --vpc-id $VPC_ID \
    --query RouteTable.RouteTableId \
    --output text

  9. IDsを環境変数に保存します。

    export IGW=igw-1234567890abcdef0
export PUBLIC_RT=rtb-0987654321fedcba0
export EIP=eipalloc-0be6ecac95EXAMPLE
export PRIVATE_RT=rtb-1234567890abcdef0

  10. インターネットゲートウェイを VPC にアタッチします。

    aws ec2 attach-internet-gateway \
    --vpc-id $VPC_ID \
    --internet-gateway-id $IGW

  11. パブリックルートテーブルをパブリックサブネットに関連付け、インターネットゲートウェイにルーティングするようにトラフィックを設定します。

    aws ec2 associate-route-table \
    --subnet-id $PUBLIC_SUB \
    --route-table-id $PUBLIC_RT
aws ec2 create-route \
    --route-table-id $PUBLIC_RT \
    --destination-cidr-block 0.0.0.0/0 \
    --gateway-id $IGW

  12. NAT ゲートウェイを作成し、Elastic IP アドレスに関連付けて、プライベートサブネットへのトラフィックを有効にします。

    aws ec2 create-nat-gateway \
    --subnet-id $PUBLIC_SUB \
    --allocation-id $EIP \
    --query NatGateway.NatGatewayId \
    --output text

  13. プライベートルートテーブルをプライベートサブネットに関連付け、NAT ゲートウェイにルーティングするようにトラフィックを設定します。

    aws ec2 associate-route-table \
    --subnet-id $PRIVATE_SUB \
    --route-table-id $PRIVATE_RT
aws ec2 create-route \
    --route-table-id $PRIVATE_RT \
    --destination-cidr-block 0.0.0.0/0 \
    --gateway-id $NATGW

  14. (オプション) マルチ AZ 配置の場合は、上記のステップを繰り返して、パブリックサブネットとプライベートサブネットでさらに 2 つのアベイラビリティーゾーンを設定します。

必要な IAM ロールと OpenID Connect 設定を作成する

HCP クラスターで ROSA を作成する前に、必要な IAM ロールとポリシー、および OpenID Connect (OIDC) 設定を作成する必要があります。HCP を使用した ROSA の IAM ロールとポリシーの詳細については、「」を参照してくださいAWS の 管理ポリシー ROSA。

この手順では、 CLI ROSA の auto モードを使用して、HCP クラスターで ROSA を作成するために必要な OIDC 設定を自動的に作成します。

  1. 必要な IAM アカウントロールとポリシーを作成します。--force-policy-creation パラメータは、存在する既存のロールとポリシーを更新します。ロールとポリシーが存在しない場合、コマンドは代わりにこれらのリソースを作成します。

    rosa create account-roles --force-policy-creation
    注記

    オフラインアクセストークンの有効期限が切れている場合、 ROSA CLI は認可トークンを更新する必要があることを示すエラーメッセージを出力します。トラブルシューティングの手順については、「」を参照してくださいCLI ROSA の有効期限が切れたオフラインアクセストークンのトラブルシューティング。

  2. クラスターへのユーザー認証を有効にする OpenID Connect (OIDC) 設定を作成します。この設定は OpenShift クラスターマネージャー (OCM) で使用できるように登録されます。

    rosa create oidc-config --mode=auto

  3. CLI 出力で指定された OIDC 設定 ID ROSA をコピーします。HCP を備えた ROSA クラスターを作成するには、後で OIDC 構成 ID を指定する必要があります。

  4. ユーザー組織に関連するクラスターで使用可能な OIDC 設定を確認するには、以下のコマンドを実行します。

    rosa list oidc-config

  5. 必要な IAM オペレータロールを作成し、 を前にコピーした OIDC 設定 ID <OIDC_CONFIG_ID>に置き換えます。

    例
    重要

    オペレータロールを作成するときは、<PREFIX_NAME> でプレフィックスを指定する必要があります。そうしないと、エラーが発生します。

    rosa create operator-roles --prefix <PREFIX_NAME> --oidc-config-id <OIDC_CONFIG_ID> --hosted-cp

  6. IAM オペレータロールが作成されたことを確認するには、次のコマンドを実行します。

    rosa list operator-roles

CLI と を使用して ROSA with HCP ROSA クラスターを作成する AWS STS

AWS Security Token Service (AWS STS) と CLI で提供されているautoモード クラスター を使用して、HCP で ROSA ROSA を作成できます。クラスターを作成するには、パブリック API と Ingress を使用するか、プライベート API と Ingress を使用するかを選択できます。

は、単一のアベイラビリティーゾーン (シングル AZ) または複数のアベイラビリティーゾーン (マルチ AZ) クラスター で作成できます。いずれの場合も、マシンの CIDR 値は VPC の CIDR 値と一致する必要があります。

次の手順では、 rosa create cluster --hosted-cp コマンドを使用して、HCP でシングル AZ ROSA を作成します クラスター。マルチ AZ を作成するには クラスター、 コマンドmulti-azで を指定し、デプロイする各プライベートサブネットのプライベートサブネット IDs を指定します。

  1. 次のいずれかのコマンドを使用して、HCP クラスターを持つ ROSA を作成します。

    • パブリック API と Ingress を使用して HCP を備えた ROSA クラスターを作成し、クラスター名、オペレーターロールプレフィックス、OIDC 構成 ID、パブリックサブネット ID とプライベートサブネット ID を指定します。

      rosa create cluster --cluster-name=<CLUSTER_NAME> --sts --mode=auto --hosted-cp --operator-roles-prefix <OPERATOR_ROLE_PREFIX> --oidc-config-id <OIDC_CONFIG_ID> --subnet-ids=<PUBLIC_SUBNET_ID>,<PRIVATE_SUBNET_ID>

    • プライベート API と Ingress を使用して HCP を備えた ROSA クラスターを作成し、クラスター名、オペレーターロールプレフィックス、OIDC 構成 ID、プライベートサブネット ID を指定します。

      rosa create cluster --private --cluster-name=<CLUSTER_NAME> --sts --mode=auto --hosted-cp --subnet-ids=<PRIVATE_SUBNET_ID>

  2. のステータスを確認します クラスター。

    rosa describe cluster -c <CLUSTER_NAME>
    注記

    作成プロセスが失敗した場合、または Stateフィールドが 10 分後に準備完了ステータスに変わらない場合は、「」を参照してくださいトラブルシューティング。

    サポートが必要な場合は、 サポート 「」または「Red Hat サポート」を参照してくださいROSA サポートを受ける。

  3. OpenShift インストーラログを監視して、 クラスター 作成の進行状況を追跡します。

    rosa logs install -c <CLUSTER_NAME> --watch

ID プロバイダーを設定し、 クラスター アクセス権を付与する

ROSA には組み込みの OAuth サーバーが含まれています。 クラスター を作成したら、ID プロバイダーを使用するように OAuth を設定する必要があります。次に、設定した ID プロバイダーにユーザーを追加すると、そのユーザーに クラスターへのアクセス権を付与できます。必要に応じて、これらのユーザーに cluster-admin または dedicated-admin 権限を付与できます。

ROSA クラスターにはさまざまな ID プロバイダータイプを設定できます。サポートされているタイプには、GitHub、GitHub Enterprise、GitLab、Google、LDAP、OpenID Connect、および HTPasswd ID プロバイダーが含まれます。

重要

HTPasswd ID プロバイダーは、単一の静的な管理者ユーザーを作成できるようにするためだけに組み込まれています。HTPasswd は ROSAにおける汎用の ID プロバイダーとしてはサポートされていません。

以下の手順では、例として GitHub ID プロバイダーを設定します。サポートされている各 ID プロバイダータイプを設定する方法については、「AWS STS用 ID プロバイダーの設定」を参照してください。

  1. github.com に移動し、GitHub アカウントにログインします。

  2. の ID プロビジョニングに使用する GitHub 組織がない場合は クラスター、作成します。詳細については、GitHub ドキュメントの手順を参照してください。

  3. CLI ROSA のインタラクティブモードを使用して、クラスターの ID プロバイダーを設定します。

    rosa create idp --cluster=<CLUSTER_NAME> --interactive

  4. 出力の設定プロンプトに従って、GitHub 組織のメンバー クラスター へのアクセスを制限します。

    I: Interactive mode enabled.
Any optional fields can be left empty and a default will be selected.
? Type of identity provider: github
? Identity provider name: github-1
? Restrict to members of: organizations
? GitHub organizations: <GITHUB_ORG_NAME>
? To use GitHub as an identity provider, you must first register the application:
  - Open the following URL:
    https://github.com/organizations/<GITHUB_ORG_NAME>/settings/applications/new?oauth_application%5Bcallback_url%5D=https%3A%2F%2Foauth-openshift.apps.<CLUSTER_NAME>/<RANDOM_STRING>.p1.openshiftapps.com%2Foauth2callback%2Fgithub-1&oauth_application%5Bname%5D=<CLUSTER_NAME>&oauth_application%5Burl%5D=https%3A%2F%2Fconsole-openshift-console.apps.<CLUSTER_NAME>/<RANDOM_STRING>.p1.openshiftapps.com
  - Click on 'Register application'
...

  5. 出力内の URL を開き、<GITHUB_ORG_NAME> を GitHub 組織の名前に置き換えます。

  6. GitHub ウェブページで、[アプリケーションを登録] を選択して、新しい OAuth アプリケーションを GitHub 組織に登録します。

  7. 次のコマンドを実行して、GitHub OAuth ページの情報を使用して残りの rosa create idp インタラクティブプロンプトを入力します。<GITHUB_CLIENT_ID> と <GITHUB_CLIENT_SECRET> を GitHub OAuth アプリケーションの認証情報に置き換えます。

    ...
? Client ID: <GITHUB_CLIENT_ID>
? Client Secret: [? for help] <GITHUB_CLIENT_SECRET>
? GitHub Enterprise Hostname (optional):
? Mapping method: claim
I: Configuring IDP for cluster '<CLUSTER_NAME>'
I: Identity Provider 'github-1' has been created.
   It will take up to 1 minute for this configuration to be enabled.
   To add cluster administrators, see 'rosa grant user --help'.
   To login into the console, open https://console-openshift-console.apps.<CLUSTER_NAME>.<RANDOM_STRING>.p1.openshiftapps.com and click on github-1.
    注記

    ID プロバイダーの設定が有効になるまでに約 2 分かかる場合があります。cluster-admin ユーザーを設定した場合は、oc get pods -n openshift-authentication --watch を実行して OAuth ポッドが更新された設定で再デプロイされることを確認できます。

  8. ID プロバイダーが正しく設定されていることを確認します。

    rosa list idps --cluster=<CLUSTER_NAME>

へのアクセスをユーザーに許可する クラスター

設定済みの ID プロバイダーに追加 クラスター することで、 へのアクセス権をユーザーに付与できます。

以下の手順では、クラスターに ID をプロビジョニングするように設定されている GitHub 組織にユーザーを追加します。

  1. github.com に移動し、GitHub アカウントにログインします。

  2. GitHub 組織 クラスター へのアクセスを必要とするユーザーを招待します。詳細については、GitHub ドキュメントの「ユーザーを組織に招待する」を参照してください。

cluster-admin のアクセス許可を設定します。

  1. 次のコマンドを実行して cluster-admin 権限を付与します。<IDP_USER_NAME> と <CLUSTER_NAME> をお使いのユーザー名とクラスター名に置き換えます。

    rosa grant user cluster-admin --user=<IDP_USER_NAME> --cluster=<CLUSTER_NAME>

  2. ユーザーが cluster-admins グループのメンバーとしてリストされていることを確認します。

    rosa list users --cluster=<CLUSTER_NAME>

dedicated-admin のアクセス許可を設定します。

  1. 次のコマンドを入力して dedicated-admin 権限を付与します。次のコマンド クラスター を実行して、 <IDP_USER_NAME> と をユーザー名とパスワード<CLUSTER_NAME>に置き換えます。

    rosa grant user dedicated-admin --user=<IDP_USER_NAME> --cluster=<CLUSTER_NAME>

  2. ユーザーが cluster-admins グループのメンバーとしてリストされていることを確認します。

    rosa list users --cluster=<CLUSTER_NAME>

Red Hat Hybrid Cloud コンソール クラスター から にアクセスする

Red Hat Hybrid Cloud Console クラスター を使用して にログインします。

  1. 次のコマンド クラスター を使用して、 のコンソール URL を取得します。を の名前<CLUSTER_NAME>に置き換えます クラスター。

    rosa describe cluster -c <CLUSTER_NAME> | grep Console

  2. 出力内のコンソール URL に移動し、ログインします。

    Log in with... ダイアログで、ID プロバイダー名を選択し、プロバイダーから提示された認可リクエストを完了します。

Developer Catalog からアプリケーションをデプロイする

Red Hat Hybrid Cloud Console から、開発者カタログのテストアプリケーションをデプロイし、ルートを使用して公開できます。

  1. Red Hat Hybrid Cloud Console に移動し、アプリケーションをデプロイするクラスターを選択します。

  2. クラスターのページで、[コンソールを開く] を選択します。

  3. 管理者パースペクティブで、[ホーム] > [プロジェクト] > [プロジェクトを作成] を選択します。

  4. プロジェクトの名前を入力し、オプションで [表示名] と [説明] を追加します。

  5. [作成] を選択してプロジェクトを作成します。

  6. 開発者パースペクティブに切り替えて [+追加] を選択します。選択したプロジェクトが、今作成したプロジェクトであることを確認してください。

  7. [開発者カタログ] ダイアログで、[すべてのサービス] を選択します。

  8. [開発者カタログ] ページで、メニューから[言語] > [JavaScript] を選択します。

  9. [Node.js] を選択し、[アプリケーションの作成] を選択して [Source-to-Image アプリケーションの作成] ページを開きます。

    注記

    Node.js オプションを表示するには、[すべてのフィルターをクリア] を選択する必要がある場合があります。

  10. [Git] セクションで、[サンプルを試す] を選択します。

  11. [名前] フィールドに、一意の名前を追加します。

  12. [作成] を選択します。

    注記

    新しいアプリケーションのデプロイには数分かかります。

  13. デプロイが完了したら、アプリケーションのルート URL を選択します。

    ブラウザの新しいタブが開き、次のようなメッセージが表示されます。

    Welcome to your Node.js application on OpenShift

  14. (オプション) アプリケーションを削除し、リソースをクリーンアップします。

    1. 管理者パースペクティブで、[ホーム] > [プロジェクト] を選択します。

    2. プロジェクトのアクションメニューを開き、[プロジェクトを削除] を選択します。

ユーザーから cluster-admin 権限を取り消す

  1. 次のコマンドを使用して cluster-admin 権限を無効にします。<IDP_USER_NAME> と を自分のユーザー名とパスワード<CLUSTER_NAME>に置き換えます クラスター 。

    rosa revoke user cluster-admin --user=<IDP_USER_NAME> --cluster=<CLUSTER_NAME>

  2. ユーザーが cluster-admins グループのメンバーとしてリストされていないことを確認します。

    rosa list users --cluster=<CLUSTER_NAME>

ユーザーから dedicated-admin 権限を取り消す

  1. 次のコマンドを使用して dedicated-admin 権限を無効にします。<IDP_USER_NAME> と を自分のユーザー名とパスワード<CLUSTER_NAME>に置き換えます クラスター 。

    rosa revoke user dedicated-admin --user=<IDP_USER_NAME> --cluster=<CLUSTER_NAME>

  2. ユーザーが dedicated-admins グループのメンバーとしてリストされていないことを確認します。

    rosa list users --cluster=<CLUSTER_NAME>

へのユーザーアクセスを取り消す クラスター

ID プロバイダーユーザーの クラスター アクセスを取り消すには、設定した ID プロバイダーから削除します。

クラスターにはさまざまな ID プロバイダータイプを設定できます。次の手順では、GitHub 組織のメンバーの クラスター アクセスを取り消します。

  1. github.com に移動し、GitHub アカウントにログインします。

  2. GitHub 組織からユーザーを削除します。詳細については、GitHub ドキュメントの「組織からのメンバーアカウントの削除」を参照してください。

クラスターと AWS STS リソースを削除する

CLI を使用して、 AWS Security Token Service () ROSA クラスター を使用する を削除できますAWS STS。 ROSA CLI を使用して、 によって作成された IAM ロールと OIDC プロバイダーを削除することもできます ROSA。によって作成された IAM ポリシーを削除するには ROSA、 IAM コンソールを使用できます。

注記

IAM によって作成された ロールとポリシーは、同じアカウントの他の ROSA クラスターで使用される ROSA 場合があります。

  1. を削除 クラスター し、ログを確認します。<CLUSTER_NAME> を クラスターの名前または ID で置き換えます。

    rosa delete cluster --cluster=<CLUSTER_NAME> --watch
    重要

    が完全に削除 クラスター されるまで待ってから、 IAM ロール、ポリシー、および OIDC プロバイダーを削除する必要があります。インストーラーが作成したリソースを削除するには、アカウント IAM ロールが必要です。OpenShift オペレーターが作成したリソースをクリーンアップするには、オペレーター IAM ロールが必要です。オペレーターは OIDC プロバイダーを使用して認証します。

  2. 次のコマンドを実行して、 クラスター オペレーターが認証に使用する OIDC プロバイダーを削除します。

    rosa delete oidc-provider -c <CLUSTER_ID> --mode auto

  3. クラスター固有のオペレーター IAM ロールを削除します。

    rosa delete operator-roles -c <CLUSTER_ID> --mode auto

  4. 以下のコマンドを使用してアカウントの IAM ロールを削除します。<PREFIX> を、削除するアカウントの IAM ロールのプレフィックスに置き換えます。アカウントの IAM ロールの作成時にカスタムプレフィックスを指定した場合は、デフォルトの ManagedOpenShift プレフィックスを指定します。

    rosa delete account-roles --prefix <PREFIX> --mode auto

  5. によって作成された IAM ポリシーを削除します ROSA。

    1. IAM コンソールにログインします。

    2. [アクセス管理] の左側のパネルで、[ポリシー] をクリックします。

    3. 削除するポリシーを選択し、[アクション] > [削除] を選択します。

    4. ポリシー名を入力し、[削除] を選択します。

    5. このステップを繰り返して、 クラスターの各 IAM ポリシーを削除します。