ROSA(Red Hat OpenShift Service on AWS)を利用したコンテナプラットフォーム構築 ~クラスタ構築~

ROSA: Red Hat OpenShift Service on AWS—Japanese title slide with ROSA logo on a dark background.

前回の記事ではHCPの概要やメリットについて触れましたが、本記事では実際にROSA HCPクラスターを構築する手順を徹底解説します。

各種CLIツールのインストールから、ROSA特有のIAMロールの作成、そして実際のクラスターデプロイと接続確認まで、ハンズオン形式で一通り実践できる内容となっています。

「ROSAを触ってみたいけれど、何から始めればいいか分からない」という方は、ぜひ手元の環境で実際に構築してみてください。

ROSA構築のための事前準備

ROSA(Red Hat OpenShift on AWS)でクラスターを実際に作成していくにあたって、事前に必要となるアカウントや環境は以下の通りです。

AWSアカウント

この記事では、AWSアカウントが作成済みであることを前提としています。

補足:ROSAの構築には適切なIAM権限(AdministratorAccessなど)が必要になります。

Red Hatアカウント

この記事では、Red Hatアカウントが作成済みであることを前提としています。

まだ作成していない場合は、Red Hatの公式サイトからアカウントを作成してください。

AWSアカウントとRed Hatアカウントの紐づけ

AWSコンソールから、Red Hat OpenShift Service on AWS (ROSA)ページに移動し、「使用を開始」をクリックします。

ROSA HCPを有効化にし、「Red Hatに進む」でRed Hat側でアカウントを紐づけてください。

ターミナル

この記事では、Windowsの WSL(Ubuntu) を使用して構築を進めていきます。

  • macOS: 標準のターミナル(bash/zsh)であれば、基本的にそのまま同様の手順で進行可能です。
  • その他(GitBash, PowerShellなど): コマンドの挙動が異なる場合があり、動作を保証できませんのでご注意ください。

注意事項

ROSAの構築・利用にあたっては、AWSのインフラ利用料およびRed Hatのサブスクリプション料金(従量課金など)が発生します。 予期せぬ課金を防ぐため、検証が終わったら必ずクラスターを削除するなど、料金面についてあらかじめご承知おきください。


環境設定

それでは、実際にROSA構築に入る前に、必要なツール(CLI)をインストールしていきましょう。

ROSAの構築・操作には、基本的に以下の3つのCLIを利用します。

  • AWS CLI
  • ROSA CLI
  • OpenShift CLI

AWS CLIのインストール

ROSAはAWSのマネジードサービスであるため、AWSアカウントにログインしている状態で利用できます。まずは、以下のコマンドでAWS CLIをインストールします。

# インストーラーのダウンロードと解凍
$ curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
$ sudo apt update && sudo apt install -y unzip
$ unzip awscliv2.zip

# インストール実行
$ sudo ./aws/install

# インストール確認
$ aws --version

ROSA CLIのインストール

ROSA CLIは、ROSAクラスターの新規作成や、クラスター全体のステータス確認・削除など、クラスター単位の操作で使用するCLIです。

以下のコマンドでROSA CLIをインストールします。

# ダウンロードと解凍
$ curl -L  https://github.com/openshift/rosa/releases/download/v1.2.60/rosa_Linux_x86_64.tar.gz -o rosa-linux.tar.gz
$ tar xvzf rosa-linux.tar.gz

# binaryディレクトリに移動
$ sudo mv ./rosa /usr/local/bin/

# インストール確認
$ rosa version

OpenShift CLIのインストール

OpenShift CLI(oc)は、作成したROSAクラスターの内部にある各種リソース(NodeやPodなど)を操作するためのCLIです。KubernetesのkubectlのOpenShift拡張版とイメージしていただければ大丈夫です。 以下のコマンドでOpenShift CLIをインストールします。

# ダウンロードと解凍
$ curl -LO https://mirror.openshift.com/pub/openshift-v4/clients/ocp/4.20.12/openshift-client-linux.tar.gz
$ tar -xvf openshift-client-linux.tar.gz
# binaryディレクトリに移動
$ sudo mv ./oc ./kubectl /usr/local/bin/

# インストール確認
$ oc version client

ROSAへのログイン

各種CLIの準備ができたら、実際にアカウントへログインしてみましょう。まずROSAを操作するために、AWSへのログイン(認証)を行います。

$ aws login --remote

コマンドを実行すると、https://us-east-1.signin.aws.amazon.com/v1/authorize?response_type=…というURLが表示されるのでブラウザで接続します。

Copy verification codeをクリックしてコピーした認証コードをターミナルのEnter the authorization code displayed in your browser:のところに貼り付けます。

ログイン完了後、以下のコマンドを実行し、認証情報を現在のシェル環境変数にエクスポートしておきます。

$ eval $(aws configure export-credentials --format env)

正しくログインできているか、接続中のAWSアカウント情報を確認してみましょう。  

$ aws sts get-caller-identity

AWSにログインできたら、次はROSAにログインします。

$ rosa login --use-device-code

コマンドを実行すると、以下のようにURLと認証用のコード(XXXX-XXXX 部分)がターミナルに表示されます。

INFO: To login, navigate to https://sso.redhat.com/device on another device and enter code XXXX-XXXX

提示されたURL(https://sso.redhat.com/device)をブラウザで開き、ターミナルに表示されているコードを入力してサインインを承認してください。

ROSAへのログインが完了したら、クラスターを構築するデフォルトのリージョンを指定しておきます(ここではus-east-1を指定しています)。

$ export AWS_REGION=us-east-1

最後に、以下のコマンドで接続中のROSAのアカウント情報を確認し、正しく表示されたら、ROSAのクラスターを作る準備はすべて完了です。

$ rosa whoami

# 出力例
W: The current version (1.2.60) is not up to date with latest rosa cli released version (1.2.64).
W: It is recommended that you update to the latest version.
AWS ARN: arn:aws:iam::123456789:XXXXXX
AWS Account ID: 123456789
AWS Default Region: us-east-1
OCM API: https://api.openshift.com
OCM Account Email: XXXXXX
OCM Account ID: XXXXXXXX
OCM Account Name: XXXXX
OCM Account Username: XXXXXXXX

もしこのようなエラーが出てきたら、AWS CLIのセッション切れが原因です。

E: Failed to create AWS client: operation error STS: GetCallerIdentity, https response error StatusCode: 403, RequestID: 76d46612-1094-49a6-a78c-4635978a2a42, api error ExpiredToken: The security token included in the request is expired

以下のコマンドで認証情報を更新してください。

$ unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN AWS_CREDENTIAL_EXPIRATION
$ eval $(aws configure export-credentials --format env)

その後再度rosaコマンドを試してみてください。


クラスター構築

Account Roleの作成

Account Role(アカウントロール)は、Red Hat側がユーザーのAWSアカウント内でクラスターの構築や運用を行うために、安全に権限を委譲するためのIAMロールです。

AWSアカウント単位の共通権限となるため、ユーザーのAWSアカウントにつき1回だけ生成すれば、以降は使い回すことができます。

以下のコマンドで必要なAccount Roleが一括で自動作成されます。

$ rosa create account-roles --hosted-cp --mode auto

–hosted-cpというのは、前回の記事で紹介したHCP(Hosted Control Planes)方式に最適化されたAccount Roleを生成するという指定です。

Classic方式との一番大きな違いは、ControlPlane-Role(コントロールプレーン用のロール)が作成されない点です。HCP方式では、コントロールプレーンはRed Hat側で管理するため、ユーザーのAWSアカウント側にIAMロールを生成する必要がありません。

具体的には以下の3つのロールが生成されます。ManagedOpenShift はデフォルトのプレフィックス名です。プレフィックスを指定したい場合は、–prefix <指定したいプレフィックス名> で設定可能です。

  • ManagedOpenShift-HCP-ROSA-Installer-Role: クラスターの基盤となるVPCやEC2などを自動で組み立てるための権限。

  • ManagedOpenShift-HCP-ROSA-Support-Role: Red HatのSREチームが障害発生時などにクラスターの状況を調査・対応するための権限。

  • ManagedOpenShift-HCP-ROSA-Worker-Role: アプリケーションが起動するワーカーノード(EC2インスタンス)が、AWSの他の機能(ストレージなど)を操作するための権限。

作成されたAccount Roleは以下のコマンドで確認できます。

$ rosa list account-roles

# 出力例
ROLE NAME ROLE TYPE ROLE ARN OPENSHIFT VERSION AWS Managed
ManagedOpenShift-HCP-ROSA-Worker-Role Worker arn:aws:iam::XXXXXXXXXXXX:role/ManagedOpenShift-HCP-ROSA-Worker-Role 4.21 Yes
ManagedOpenShift-HCP-ROSA-Installer-Role Installer arn:aws:iam::XXXXXXXXXXXX:role/ManagedOpenShift-HCP-ROSA-Installer-Role 4.21 Yes
ManagedOpenShift-HCP-ROSA-Support-Role Support arn:aws:iam::XXXXXXXXXXXX:role/ManagedOpenShift-HCP-ROSA-Support-Role 4.21 Yes

Operator Roleの作成

上で作成したAccount Roleは、Red Hat側がユーザーのAWSアカウントを利用して作業するための権限でしたが、Operator Roleは、OpenShiftの内部からAWSリソースを直接操作するためのIAMロールです。

OpenShiftの内部では、ネットワーク管理やストレージ管理、ログ管理など、それぞれの役割に特化した「Operator(オペレーター)」と呼ばれる複数のプログラムが動いています。それらのプログラムがAWSリソース(ロードバランサーやEBSなど)を自動で作成・管理することになるため、各Operatorに必要な最小限の操作権限だけIAMロールとして切り出して、割り当てる仕組みになっています。

また、OperatorにAWSのアクセスキーなどの永続的な認証情報を持たせるのを防ぐため、「AWS STS(AWS Security Token Service)」という仕組みを利用して、OIDCプロバイダーと連携し安全に一時的な操作権限を受け取れるようにします。

そのため、Operator Roleを作成する前に、連携先となるOIDCプロバイダーを用意する必要があります。 以下のコマンドでOpenID Connect Config(oidc-config)を作成することで、AWS側にもOIDCプロバイダーが自動で作成されます。

$ rosa create oidc-config --mode=auto --managed=true --yes

作成できたら、以下のコマンドで生成されたOIDC Configの情報を確認しましょう。

$ rosa list oidc-config

# 出力例
ID       MANAGED ISSUER URL SECRET ARN
XXXXXXXXX true   XXXXXXXXX

出力結果に表示される IDはこの後の手順で利用するため、手元に控えておきます。

準備が整ったら、以下のコマンドでOperator Roleを生成します。

$ rosa create operator-roles --hosted-cp --mode auto \
	--prefix=demo \
	--oidc-config-id=<上で作成されたOIDC ConfigのID> \
	--installer-role-arn=<上で作成されたInstaller-RoleのARN>

以下のコマンドで作成されたOperator Roleを確認できます。

$ rosa list operator-roles

# 出力例
ROLE PREFIX AMOUNT IN BUNDLE
 demo         8

具体的なAWSのリソースとしては、以下のロールが自動生成されます。

補足:IAMロール名がプレフィックス値を含めて64文字を超える場合は、64文字になるように末尾が切り捨てられます。

  • <prefix>-openshift-ingress-operator-cloud-credentials:ユーザーがアプリを外部公開する際に、AWS側にロードバランサー(ALBやNLB)を自動作成したり、Route 53のDNS設定を管理したりする権限。
  • <prefix>-openshift-cloud-network-config-controller-cloud-credential:OpenShift内部のネットワークと、AWSのネットワークを連動させるための権限。
  • <prefix>-openshift-cluster-csi-drivers-ebs-cloud-credentials:AWSのEBSをコンテナのストレージとして割り当てるための権限。
  • <prefix>-openshift-image-registry-installer-cloud-credentials:コンテナイメージを保存するためにAWSのS3バケットを生成・操作するための権限。

また、従来のClassic方式と比べると、HCP方式ではコントロールプレーンが分離されているため、kube-system-〜 から始まるHCP専用のOperator Roleも生成されます。

  • <prefix>-kube-system-capa-controller-manager:ワーカーノード(EC2)の台数を自動で増減させる機能の権限(オートスケーリングなど)。
  • <prefix>-kube-system-control-plane-operator:Red Hat側のコントロールプレーンからの指示でユーザーのAWS環境のインフラを操作できる権限。
  • <prefix>-kube-system-kube-controller-manager:Kubernetesの標準的な管理プログラムが、AWSのリソースを監視できるようにする権限。
  • <prefix>-kube-system-kms-provider:AWSのKMSと連携し、Kubernetesのシークレットを暗号化するための権

VPCとサブネットの作成

ROSAクラスタをインストールするVPCを作成します。今回はAWSコンソールで簡単に構築してみます。

AWSでVPCを開き、「お使いのVPC」でVPCを作成を選択します。

VPCだけでなくサブネットやNAT Gatewayも一緒に作成するために「VPCなど」を選択します。

選択後の各種設定値は、以下の表を参考にしてください。表に記載がない項目はデフォルト(初期状態)のままで問題ありません。今回はデモのために作るので、なるべく最小限必要な構成にしています。

パラメータ説明
名前タグの自動生成任意の名前(例:rosa-demoなど)
アベイラビリティゾーン (AZ) の数1
パブリックサブネットの数1
プライベートサブネットの数1
NAT ゲートウェイZonal(1 AZ 内に配置)
VPC エンドポイントなし

すべての設定が終わったら、画面一番下にある 「VPC を作成」 ボタンを押します。 (作成完了には数分程度かかります)

また、subnet-から始まるパブリックサブネットのIDとプライベートサブネットのIDはこのあとのクラスター作成で使うため、テキストエディタ等にメモしておいてください。

ROSAクラスター作成

Account RoleとOperator Role、そして事前にAWS側に用意したVPC(サブネット)の準備ができたら、以下のコマンドを実行してクラスターを作成します。

$ rosa create cluster --cluster-name <クラスター名> \
  --sts \
  --mode auto \
  --hosted-cp \
  --subnet-ids <パブリックサブネットID>,<プライベートサブネットID> \
  --oidc-config-id <上で作成されたOIDC ConfigのID> \
  --operator-roles-prefix <Operator Roleを作成するときに指定したprefix> \
 --domain-prefix <クラスターのURLのサブドメイン名> \
  --yes

各パラメータの説明

パラメータ説明
–cluster-name作成するクラスターの一意の名前。任意の英数字で指定。
–stsAWSの安全な一時認証(Security Token Service)を使用するという指定。HCP方式では必須。
–mode auto途中の質問に対して、すべて自動(デフォルト値)で作成を進めるための指定。
–hosted-cp HCP方式 でクラスターを作成するためのフラグ。
–subnet-idsクラスターを配置するAWSの既存サブネット(パブリックとプライベート)のIDをカンマ区切りで指定。
–oidc-config-idOperator Role作成時に指定したprefixの値(例: demo)を指定。
–operator-roles-prefix前の手順で作ったOperator Role群を識別するための接頭辞(例: ManagedOpenShift)を指定。
–domain-prefix自動生成されるクラスターのURL(管理画面やAPIサーバーのURL)のサブドメイン部分をカスタマイズするための設定(オプション)。
–yesコマンド実行時の最終確認(Are you sure?)をスキップするフラグ。

クラスターの作成が完了するまではおよそ10分〜15分程度かかります。バックグラウンドでどのように構築が進んでいるかリアルタイムで確認したい場合は、以下のコマンドを実行してください。

$ rosa logs install --cluster <クラスター名> --watch

# 出力例
bak@1010-00867:~$ rosa logs install -c rosa-demo --watch
W: The current version (1.2.60) is not up to date with latest rosa cli released version (1.2.64).
W: It is recommended that you update to the latest version.
I: Cluster 'rosa-demo' is in validating state waiting for installation to begin. Logs will show up within 5 minutes
\ 0001-01-01 00:00:00 +0000 UTC hostedclusters rosa-demo Version
2026-07-13 07:04:09 +0000 UTC hostedclusters rosa-demo Condition not found in the CVO.
2026-07-13 07:04:09 +0000 UTC hostedclusters rosa-demo The hosted control plane is not found

以下のようなログが出たら、ROSAクラスターのデプロイは完了です。

I: Cluster 'rosa-demo' is now ready

接続確認

クラスターの構築が完了したら、実際にログインして接続確認を行いましょう。 接続するためには、まず管理者アカウントである cluster-admin を作成する必要があります。

以下のコマンドでcluster-adminを作成します。コマンドを実行すると、passwordが自動生成され、そのままログインできるコマンド(oc login〜)がターミナルに出力されます。

$ rosa create admin --cluster=<クラスター名>

# 出力例
I: Admin account has been added to cluster 'your-cluster-name'.
I: Please securely store this generated password. If you lose this password you can delete and recreate the cluster admin user.
I: To login, run the following command:

oc login https://api.your-cluster-name.xxxx.p1.openshiftapps.com:443 --username cluster-admin --password XXXXX-XXXXX-XXXXX-XXXXX

以下のようにoc loginコマンドを入力してLogin successful. と表示されれば、CLIからの接続確認は完了です。

$ oc login https://api.your-cluster-name.xxxx.p1.openshiftapps.com:443 --username cluster-admin --password XXXXX-XXXXX-XXXXX-XXXXX

Login successful.

もし、以下のエラーが出たら、数分待ってから再度試してみてください。

Login failed (401 Unauthorized)
Verify you have provided the correct credentials.

また、CLIからだけでなく、ウェブブラウザを使って管理コンソール(GUI)にログインする方法もあります。 以下のコマンドを実行して、出力結果から「Console URL」の項目を確認します。

$ rosa describe cluster --cluster=<作成したクラスター名>

#出力例
W: The current version (1.2.60) is not up to date with latest rosa cli released version (1.2.64).
W: It is recommended that you update to the latest version.

Name:                       rosa-demo
Domain Prefix:              rosa-demo
Display Name:               rosa-demo
ID:                         XXXXXXXXXX
External ID:                XXXXXXXXXX
Control Plane:              ROSA Service Hosted
OpenShift Version:          4.20.28
Channel Group:              stable
DNS:                        XXXXXXXXXX
AWS Account:                XXXXXXXXXX
AWS Billing Account:        XXXXXXXXXX
API URL:                    XXXXXXXXXX
Console URL:                https://console-openshift-console.apps.rosa.xxxxx.openshiftapps.com

Console URLをブラウザに入力してアクセスすると、以下のように管理コンソールに接続できますので、CLIでのログイン(oc login)時に使用した、管理者(cluster-admin)のusernameとpasswordを入力してログインします。

このような画面が出たら管理コンソールにログイン成功です。

(オプション)後片付け

ROSAを構築するために作成した各種リソースは費用が発生するので、もし今後使わないのであれば片付けておくことをおすすめします。

また、漏れなく削除するために以下の記載順で削除していくことをおすすめします。

1. クラスターの削除

まず、以下のコマンドでクラスターを削除します。

$ rosa delete cluster --cluster=<クラスター名> --yes

削除中のログの確認は以下のコマンドでできます。

$ rosa logs uninstall --cluster=<クラスター名> --watch

実行例です。

$ rosa logs uninstall --cluster=rosa-demo --watch

W: The current version (1.2.60) is not up to date with latest rosa cli released version (1.2.64).
W: It is recommended that you update to the latest version.
2026-07-13 07:41:44 +0000 UTC hostedclusters rosa-demo invalid service account signing key: failed to get hostedcluster ServiceAccountSigningKey secret bound-service-account-signing-key: Secret "bound-service-account-signing-key" not found
2026-07-13 07:41:45 +0000 UTC hostedclusters rosa-demo pull secret unavailable: Secret "rosa-demo-pull" not found
2026-07-13 07:41:46 +0000 UTC hostedclusters rosa-demo Reconciliation completed successfully
2026-07-13 07:45:48 +0000 UTC hostedclusters rosa-demo All is well
2026-07-13 07:45:49 +0000 UTC hostedclusters rosa-demo ValidAWSIdentityProvider StatusUnknown
2026-07-13 07:45:49 +0000 UTC hostedclusters rosa-demo All guest resources destroyed
I: Cluster 'rosa-demo' completed uninstallation

「Cluster ‘XXXXXX’ completed uninstallation」というログが出たら削除完了です。

クラスターの削除が完了したら、AWSコンソールの「VPC」サービス画面を開き、AWSのリソースを削除していきます。

2. NATゲートウェイの削除

VPCコンソール > 左メニューの「NAT ゲートウェイ」に移動し、作成したNATゲートウェイを削除します。削除済み(Deleted)になるまで数分かかることがあります。

3. VPCの削除

VPCコンソール > 左メニューの「お使いの VPC」に移動し、作成したVPCを選択し削除します。VPCを削除すると、以下の関連リソースもすべて削除されます。

  • サブネット(パブリック / プライベート)
  • ルートテーブル
  • インターネットゲートウェイ(IGW)
  • セキュリティグループ

※注意:VPCの削除でエラーが出る場合

クラスターの削除完了直後にVPCを消そうとすると、「eni-xxxx (VPC Endpoint Interface) が使用中(in use)のため削除できません」というエラーが出る場合があります。 5分ほど待つか、AWSコンソールの「VPC」>「エンドポイント」から対象のID(vpce-xxxx)を手動で削除してから、再度VPCの削除を行ってください。

4. Elastic IP(EIP)の解放

VPCコンソール > 左メニューの「Elastic IP」に移動し、NATゲートウェイ用に自動取得されていたElastic IPを選択し、画面右上の「アクション」>「Elastic IP アドレスの解放」をクリックします。

これでクラスターと関連リソースの削除は完了です。

5. オペレーターロールの削除

$ rosa delete operator-roles --prefix=<プレフィックス名> --mode=auto --yes

以下は実行例です。

$ rosa delete operator-roles --prefix=demo --mode=auto --yes

W: The current version (1.2.60) is not up to date with latest rosa cli released version (1.2.64).
W: It is recommended that you update to the latest version.
I: Fetching operator roles for the prefix: demo
I: Deleting operator role 'demo-kube-system-capa-controller-manager'
I: Deleting operator role 'demo-kube-system-control-plane-operator'
I: Deleting operator role 'demo-kube-system-kms-provider'
I: Deleting operator role 'demo-kube-system-kube-controller-manager'
I: Deleting operator role 'demo-openshift-cloud-network-config-controller-cloud-credentials'
I: Deleting operator role 'demo-openshift-cluster-csi-drivers-ebs-cloud-credentials'
I: Deleting operator role 'demo-openshift-image-registry-installer-cloud-credentials'
I: Deleting operator role 'demo-openshift-ingress-operator-cloud-credentials'
I: Successfully deleted the operator roles

6. OIDC Configの削除

$ rosa delete oidc-config --oidc-config-id=<OIDCのID> --mode=auto --yes

以下は実行例です。

$ rosa delete oidc-config --oidc-config-id 2reuclobhhsao2hdrjpc43lcoq5151go

W: The current version (1.2.60) is not up to date with latest rosa cli released version (1.2.64).
W: It is recommended that you update to the latest version.
? OIDC Config deletion mode: auto
? Delete the OIDC provider 'arn:aws:iam::XXXXXXXXXXXX:oidc-provider/oidc.op1.openshiftapps.com/2reuclobhhsao2hdrjpc43lcoq5151go'? Yes
I: Successfully deleted the OIDC provider arn:aws:iam::XXXXXXXXXXXX:oidc-provider/oidc.op1.openshiftapps.com/2reuclobhhsao2hdrjpc43lcoq5151go
I: Registered OIDC Config ID '2reuclobhhsao2hdrjpc43lcoq5151go' has been removed from OCM and can no longer be used

まとめ

以上で、ROSAクラスターの構築に必要な事前準備から、各種IAMロールの作成、実際のデプロイ、そして接続確認までの一連の手順が完了しました。

「ROSAって名前は聞くけど、具体的にどうやって始めれば良いんだろう?」という漠然とした疑問やハードルが、この記事を通して少しでも解消できたら幸いです。

次回からは、ログの保管やメトリクスの転送など、クラスターの内部をさらに充実させていく内容を紹介していきます。ぜひ楽しみにしていてください。

参考資料

ご覧いただきありがとうございます! この投稿はお役に立ちましたか?

役に立った 役に立たなかった

0人がこの投稿は役に立ったと言っています。
エンジニア募集中!

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です