はじめに 前々回の記事ではROSA HCPの概要やメリットを紹介し、前回の記事ではROSA HCPクラスターを実際に構築してきました。 今回は、本番運用を見据えた、ROSA HCPクラスターにおける「ログ保管の自動化」 についてご紹介します。 KubernetesやOpenShift環境では、Podが再起動したり削除されたりすると、コンテナ内に出力されていたログは消えてしまいます。そのため、システムの安定運用やトラブルシューティングを行うためには、コンテナログを保管する仕組みが必須となります。 そこで、AWSの運用に慣れたエンジニアにとって、最も親和性が高く手軽なログ保管先となるのが「Amazon CloudWatch Logs」です。 本記事では、具体的な設定手順に進む前の前提知識として、まずはROSA環境におけるログ保管の全体像を整理し、その後CloudWatch Logsへ転送する具体的な設定方法を解説していきます。 ROSAで出力されるログの種類 CloudWatch Logsへの転送設定を始める前に、まずはROSAが出力するログの種類についてご紹介します。 ROSAを構成するコンポーネントから出力されるログは以下の3種類に大別されます。 ROSA with HCPでは、ログ種別によってログの転送方法が異なるため注意が必要です。 ログ種別 概要 転送方法 アプリケーションログ ユーザーがデプロイしたPod(コンテナ)から出力されるログ OpenShift Logging インフラストラクチャログ ワーカーノードやOpenShiftのシステムコンポーネント(※)から出力されるログ OpenShift Logging 監査ログ クラスター内での操作履歴のログ ROSA with HCPの標準機能 ※インフラストラクチャログにおけるシステムコンポーネントの定義 OpenShfitの仕様上、以下のnamespaceで実行されているPodはすべて「OpenShiftのシステムコンポーネント」とみなされ、それらが出力するログはインフラストラクチャログとして分類されます。 default kube–xxx openshift-xxx   OpenShift Loggingとは ROSA with HCPにおいて、アプリケーションログ・インフラストラクチャログを収集し、外部へ転送するための機能が「OpenShift Logging」です。 Kubernetes標準の機能だけでは、Podが再起動したり削除されたりするとコンテナ内のログも一緒に消えてしまいます。OpenShift Loggingは、クラスター内の各コンテナが出力するログをリアルタイムに収集し、外部（今回はCloudWatch Logs）へと転送するパイプラインを自動管理してくれます。 OpenShift Loggingを構成する主要コンポーネント 現在のOpenShift Loggingは以下のコンポーネントで構成されます。 Cluster Logging Operator ログ収集エンジンや転送設定全体のライフサイクルを管理するコンポーネントです。 ログ収集エンジン 各ワーカーノードにDaemonSetとして配置され、ノード上で動くコンテナのログを収集するコンポーネントです。以前のOpenShiftではFluentdがログ収集エンジンとして使用されていましたが、現在の最新バージョンではパフォーマンスとリソース効率に優れたVectorがデフォルトのエンジンとして採用されています。   ログ転送パイプラインを定義する「ClusterLogForwarder」 OpenShift Loggingは、ログの転送パイプラインの定義を「ClusterLogForwarder」というカスタムリソースで定義します。 これにより、YAMLファイルを1つ定義するだけで、「どのログを」「どこへ転送するか」を自由に設定することができるようになっています。  ClusterLogForwarderに定義する転送パイプラインは、主に以下の３つの要素を組み合わせて設定します。 Inputs（入力元）： どのログを対象にするか Outputs（出力先）： どこに送るか Pipelines（経路の結合）： どのInputsを、どのOutputsへ紐付けるか ログ転送のデータフロー OpenShift Loggingを利用したログ転送のデータフローを図に示すと以下のようになります。 ログ収集エンジンであるVectorはClusterLogForwarderの定義に従い、Inputsに設定したアプリケーションログやインフラストラクチャログを収集し、Outputsに設定したCloudWatch Logsにログを転送します。 OpenShift Loggingを利用したCloudWatch Logsへのログ転送設定 ここからは実際にOpenShift Loggingを利用したCloudWatch Logsへのログ転送設定をご紹介します。 前提条件 ROSAクラスターが構築済みであること（前回の記事を参照） ROSAクラスターにCLIでログインできていること ROSAクラスターの管理コンソールにWebブラウザからログインできていること 事前準備（ロググループとIAMロール・ポリシーの作成） ロググループの作成 まずは転送先ロググループを作成します。 以下はCloudFormationでロググループを作成する際のサンプルになります AWSTemplateFormatVersion: '2010-09-09' Description: 'Log Group for OpenShift Logging' Resources: # アプリケーションログ用のロググループ LogGroupApp: Type: AWS::Logs::LogGroup DeletionPolicy: "Delete" Properties: LogGroupName: /rosa/hcp-cluster/application # インフラストラクチャログ用のロググループ LogGroupInfra: Type: AWS::Logs::LogGroup DeletionPolicy: "Delete" Properties: LogGroupName: /rosa/hcp-cluster/infrastructure 上記CloudFormationを適用すると以下のロググループが作成されます。 ※OpenShift Loggingはアプリケーションログを「<任意の値>/application」、インフラストラクチャログを「<任意の値>/infrastructure」の名称のロググループにログを転送します。 IAMロール・IAMポリシーの作成 OpenShift Loggingに割り当てるIAMロール・IAMポリシーを作成します。 以下はCloudFormationでIAMロールを作成する際のサンプルになります AWSTemplateFormatVersion: '2010-09-09' Description: 'IAM Role and Policy for OpenShift Logging' Parameters: # ROSA構築時に作成したOIDCエンドポイント OidcEndpoint: Type: String Description: 'The OIDC Endpoint' Resources: # CloudWatch Logs へのアクセス許可ポリシー OpenShiftLoggingPolicy: Type: 'AWS::IAM::ManagedPolicy' Properties: ManagedPolicyName: 'rosa-openshift-logging-policy' PolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Action: - 'logs:PutLogEvents' - 'logs:PutRetentionPolicy' - 'logs:CreateLogStream' - 'logs:DescribeLogGroups' - 'logs:DescribeLogStreams' Resource: 'arn:aws:logs:*:*:*' # ログ転送用 IAM ロール OpenShiftLoggingRole: Type: 'AWS::IAM::Role' Properties: RoleName: 'rosa-openshift-logging-role' AssumeRolePolicyDocument: !Sub | { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::${AWS::AccountId}:oidc-provider/${OidcEndpoint}" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "${OidcEndpoint}:sub": "system:serviceaccount:openshift-logging:cloudwatch-log-forwarder-sa" } } } ] } ManagedPolicyArns: - !Ref OpenShiftLoggingPolicy 上記CloudFormationの「OidcEndpoint」というパラメーターには、前回の記事で作成したoidc-configの情報を以下のrosaコマンドで確認し、「ISSUER URL」の値の「https://」を除いた値を設定してください。 $ rosa list oidc-config # 出力例 ID MANAGED ISSUER URL SECRET ARN XXXXXXXXX true https://xxxx/xxxxx CloudFormationを適用すると以下のIAMロールが作成されます。 OpenShift Loggingのインストール Cluster Logging Operatorのデプロイ まず、OpenShift Loggingのコンポーネントの1つである「Cluster Logging Operator」をデプロイします。 以下はCluster Logging Operatorをyamlファイルでデプロイする際のサンプルになります。 opensfhit-logging-operator.yaml apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: openshift-logging-operaror-group namespace: openshift-logging spec: upgradeStrategy: Default --- apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: openshift-logging-operaror-subscription namespace: openshift-logging spec: # インストールするOpenShift Loggingのチャンネルを指定 channel: stable-6.4 # インストールするOpenShift Loggingのバージョンを指定 startingCSV: cluster-logging.v6.4.1 installPlanApproval: Manual name: cluster-logging source: redhat-operators sourceNamespace: openshift-marketplace 作成したopensfhit-logging-operator.yamlをROSAクラスターにログインし、適用します。 $ oc login https://api.your-cluster-name.xxxx.p1.openshiftapps.com:443 --username cluster-admin --password XXXXX-XXXXX-XXXXX-XXXXX $ oc apply -f opensfhit-logging-operator.yaml OpenShiftの管理コンソール上の「エコシステム」→「インストール済みのOperator」のページで「cluster-logging」が選択できるようになります。 「cluster-logging」を選択し、「installPlan」のページに遷移すると、OpenShift Logging Operatorのインストールの承認確認画面が表示されるため、「承認」を選択します。 インストールを承認すると、ROSAクラスター上にCluster Logging Operatorが起動します。 $ oc get pod -n openshift-logging NAME READY STATUS RESTARTS AGE cluster-logging-operator-dd4646d96-zcw6g 1/1 Running 0 45s Secretリソースのデプロイ 次に、ログ収集エンジンにIAMロールを割り当てるためのSecretリソースをデプロイします。 以下はSecretのサンプルになります。 secret.yaml apiVersion: v1 kind: Secret metadata: name: cloudwatch-credentials namespace: openshift-logging stringData: # 作成したIAMロールのARNを指定 role_arn: arn:aws:iam::xxx:role/rosa-openshift-logging-role 作成したsecret.yamlをROSAクラスターに適用します。 $ oc apply -f secret.yaml ServiceAccountのデプロイ ログ収集エンジンに割り当てるServiceAccoutをデプロイします。 以下はServiceAccountのサンプルになります。 serviceaccount.yaml apiVersion: v1 kind: ServiceAccount metadata: name: cloudwatch-log-forwarder-sa namespace: openshift-logging 作成したserviceaccount.yamlをROSAクラスターに適用します。 $ oc apply -f secret.yaml ClusterRoleBindingのデプロイ ログ収集エンジンにログ収集権限を付与するため、ClusterRoleBindingリソースでServiceAccoutに権限の割り当てを行います。 割り当てるClusterRoleは Cluster Logging Operatorのデプロイ時に自動で作成されるClusterRoleを割り当てます。 以下はClusterRoleBindingのサンプルになります。 cluster-role-binding.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: logging-collector-logs-writer-crb subjects: - kind: ServiceAccount name: cloudwatch-log-forwarder-sa namespace: openshift-logging roleRef: kind: ClusterRole name: logging-collector-logs-writer apiGroup: rbac.authorization.k8s.io --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: collect-application-logs-crb subjects: - kind: ServiceAccount name: cloudwatch-log-forwarder-sa namespace: openshift-logging roleRef: kind: ClusterRole name: collect-application-logs apiGroup: rbac.authorization.k8s.io --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: collect-infrastructure-logs-crb subjects: - kind: ServiceAccount name: cloudwatch-log-forwarder-sa namespace: openshift-logging roleRef: kind: ClusterRole name: collect-infrastructure-logs apiGroup: rbac.authorization.k8s.io 作成したcluster-role-binding.yamlをROSAクラスターに適用します。 $ oc apply -f cluster-role-binding.yaml ClusterLogForwarderのデプロイ ログ収集エンジンをデプロイするためのカスタムリソース(CR)であるClusterLogForwarderをデプロイします。 OpenShift Logging OperatorはClusterLogForwarderに定義した設定内容に基づいてログ収集エンジンをデプロイします。 以下はClusterLogForwarderのサンプルになります。 cluster-log-forwarder.yaml apiVersion: observability.openshift.io/v1 kind: ClusterLogForwarder metadata: name: cloudwatch-cluster-log-forwarder namespace: openshift-logging spec: collector: tolerations: - operator: "Exists" serviceAccount: # 3.ServiceAccoutのデプロイで作成したServiceAccout名を指定 name: cloudwatch-log-forwarder-sa outputs: - name: cloudwatch-output type: cloudwatch cloudwatch: # 作成したロググループ名を指定 # {.log_type||"unknown"}の部分はinputRefsで指定している「application」・「infrastructure」の文字列が埋め込まれる groupName: '/rosa/hcp-cluster/{.log_type||"unknown"}' # ロググループを作成したリージョンを指定 region: us-east-1 authentication: type: iamRole iamRole: roleARN: key: role_arn # 2.Secretリソースのデプロイで作成したSecret名を指定 secretName: cloudwatch-credentials token: from: serviceAccount pipelines: - name: to-cloudwatch # アプリケーションログとインフラストラクチャログを収集するように指定 inputRefs: - application - infrastructure outputRefs: - cloudwatch-output 作成したcluster-log-forwarder.yamlをROSAクラスターに適用します。 $ oc apply -f cluster-log-forcluster-log-forwarder.yaml 動作確認 OpenShift Loggingのインストール後、Podが正常に起動しているか確認してください。 $ oc get pod -n openshift-logging NAME READY STATUS RESTARTS AGE cloudwatch-cluster-log-forwarder-fngmj 1/1 Running 0 61s cloudwatch-cluster-log-forwarder-pgx5h 1/1 Running 0 62s cluster-logging-operator-8646fc6b78-5hh5v 1/1 Running 0 12m 次に、作成したロググループにインフラストラクチャログ・アプリケーションログが転送されていることを確認してください。 ※今回はアプリケーションログを出力させるために「test」というnamespace配下にテスト用の「app-log-test」という名前のPodを起動させ、ログ出力させています。 作成したロググループにアプリケーションログ・インフラストラクチャログのログストリームが作成されていることがわかります。以上で、アプリケーションログ・インフラストラクチャログをCloudWatch Logsに転送する設定は完了になります。 【補足】監査ログ（Audit Logs）の転送設定について ROSA with HCPにおける監査ログはRedHatが管理するコントロールプレーン側で出力されるため、ワーカーノード上に存在するOpenShift Loggingではログの収集が行えません。 そのため、ROSA with HCPでは、監査ログをCloudWatch Logsへ転送する標準機能が用意されています。 監査ログのCloudWatch Logsへの転送を有効化したい場合は、ROSAがCloudWatchにログを書き込むための専用IAMロールを作成し、そのIAMロールのARNを rosa コマンドのオプションに設定します。 以下はCloudFormationでIAMロールを作成する際のサンプルになります。 AWSTemplateFormatVersion: '2010-09-09' Description: 'IAM Role and Policy for ROSA HCP Audit Log' Parameters: # ROSA構築時に作成したOIDCエンドポイント OidcEndpoint: Type: String Description: 'The OIDC Endpoint' Resources: # 1. CloudWatch Logs へのアクセス許可ポリシー RosaAuditLogPolicy: Type: 'AWS::IAM::ManagedPolicy' Properties: ManagedPolicyName: 'rosa-audit-log-policy' PolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Action: - 'logs:CreateLogGroup' - 'logs:CreateLogStream' - 'logs:DescribeLogGroups' - 'logs:DescribeLogStreams' - 'logs:PutLogEvents' - 'logs:PutRetentionPolicy' Resource: 'arn:aws:logs:*:*:*' # 2. Auditログ転送用 IAM ロール RosaAuditLogRole: Type: 'AWS::IAM::Role' Properties: RoleName: 'rosa-audit-log-role' AssumeRolePolicyDocument: !Sub | { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::${AWS::AccountId}:oidc-provider/${OidcEndpoint}" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "${OidcEndpoint}:sub": "system:serviceaccount:openshift-config-managed:cloudwatch-audit-exporter" } } } ] } ManagedPolicyArns: - !Ref RosaAuditLogPolicy 上記CloudFormationの「OidcEndpoint」というパラメーターには、OpenShift Logging用のIAMロールを作成した時と同様に、oidc-configの「ISSUER URL」の「https://」を除いた値を設定してください。 CloudFormationを適用すると以下のIAMロールが作成されます。 以下のrosaコマンドで監査ログの転送を有効化します。 $ rosa edit cluster --cluster=<クラスター名> \ --audit-log-arn="arn:aws:iam::xxxxxxx:role/rosa-audit-log-role" CloudWatch Logsに以下のようなロググループが作成されていれば、監査ログの転送設定は完了です。 ※ロググループ名は「ocm-production-<クラスターのID>-<クラスター名>」の形式で自動作成されます。 また、クラスター構築時に–domain-prefixを設定していた場合は、「ocm-production-<クラスターのID>-<domain-prefixの値>」の形式となります。 おわりに ROSAクラスターにおけるCloudWatch Logsへのログ転送方法について解説しました。 実際にROSAクラスターを運用する際の参考になれば幸いです。 次回はROSAクラスター上のメトリクスをCloudWatchに転送する方法についてご紹介します。 参考文献 https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/4 https://docs.aws.amazon.com/ja_jp/rosa/latest/userguide/what-is-rosa.html https://docs.redhat.com/en/documentation/red_hat_openshift_logging/6.6/html/install/installing-the-red-hat-openshift-logging-operator ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post ROSA（Red Hat OpenShift Service on AWS）を利用したコンテナプラットフォーム構築 ~ ログ転送設定 ~ first appeared on SIOS Tech Lab .

前回の記事 では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 作成するクラスターの一意の名前。任意の英数字で指定。 –sts AWSの安全な一時認証（Security Token Service）を使用するという指定。HCP方式では必須。 –mode auto 途中の質問に対して、すべて自動（デフォルト値）で作成を進めるための指定。 –hosted-cp  HCP方式 でクラスターを作成するためのフラグ。 –subnet-ids クラスターを配置するAWSの既存サブネット（パブリックとプライベート）のIDをカンマ区切りで指定。 –oidc-config-id Operator 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って名前は聞くけど、具体的にどうやって始めれば良いんだろう？」という漠然とした疑問やハードルが、この記事を通して少しでも解消できたら幸いです。 次回からは、ログの保管やメトリクスの転送など、クラスターの内部をさらに充実させていく内容を紹介していきます。ぜひ楽しみにしていてください。 参考資料 Getting started with Red Hat OpenShift Service on AWS ( Red Hat Documentation ) Chapter 2. Creating Red Hat OpenShift Service on AWS clusters using the default options（ Red Hat Documentation） Create a ROSA with HCP cluster using the ROSA CLI（Red Hat Documentation） Hosted Control Planes（rosaworkshop.io） ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post ROSA（Red Hat OpenShift Service on AWS）を利用したコンテナプラットフォーム構築 ~クラスタ構築~ first appeared on SIOS Tech Lab .

本記事では、AWSとRed Hatが共同提供するフルマネージドなOpenShiftサービス「ROSA」について紹介します。 特に、近年の主流であり、インフラ費用や運用負荷を劇的に削減できるROSAの最新アーキテクチャモデル「HCP（Hosted Control Planes）」の仕組みと、導入による4つのメリットを分かりやすく紹介し、最適なコンテナ基盤選定のヒントをお届けします。 ROSAとは ROSA（Red Hat OpenShift Service on AWS）とは、Red Hatが提供しているコンテナオーケストレーションプラットフォームであるOpenShiftを、AWS上のフルマネージドサービスとして利用できるようにしたサービスです。（ OpenShiftについて詳しく知りたい方は、 こちら の記事をご参考ください） ROSAを利用してコンテナ基盤を運用することには、以下の利点があります。 Red HatとAWSの共同サポート ROSAは、サポート窓口が完全に一元化されていて、問い合わせを受けると、裏側でAWSとRed Hatのエンジニアが直接連携して原因を突き止めてくれる仕組みになっています。自分たちでAWS上にOpenShiftを構築した場合、トラブルが起きると「AWSのインフラが悪いのか、それともOpenShiftのバグなのか」を自力で調べ、それぞれのサポートに別々に問い合わせなければなりません。ROSAであればそのようなアクションが一切不要になるため、運用の負担を大きく軽減できます。 Red Hatの専門チームによる24時間監視 ROSAのクラスターは、Red HatのSREチームによって24時間365日体制で監視・運用されるようになります。 クラスターに何か障害が起きても、Red HatのSREチームが裏側で迅速に対応・復旧をしてくれるため、ユーザーとしては、監視や障害対応に対する運用コストを飛躍的に削減できます。 また、パッチ当てやセキュリティのアップデートなどもRed Hat側が対応してくれるので、ユーザーはそのスケジュール（実行するタイミング）を決めるだけで済みます。 AWSサービスと連携しやすくなる ROSAは、最初からAWSの各種サービスとスムーズに連携できるよう設計されています。これによって、複雑なインフラ設定に時間を取られなくなるため、より迅速かつ安全にコンテナ基盤を構築・提供できるようになります。 Copyright © Red Hat, Inc. AWSのRoleとPolicyを利用したRed Hat側との連携 請求書の統合 ROSAの利用料金（OpenShiftのライセンス料やAWSのインフラ費用）は、すべてAWSの請求書に統合されて支払われます。 別個に契約や支払いを行う必要がないため、企業の購買手続きや予算管理の負担を大幅に軽減できるメリットがあります。   ROSAを使うことで、上記のように様々なメリットが得られますが、現在の標準アーキテクチャである「HCP（Hosted Control Planes）」の登場によって、更なるフルマネージドのサービスが利用可能になりました。 ここからは、コストや運用の楽さを劇的に向上させる「ROSA with HCP」について詳しく説明します。 ROSA with HCPとは ROSA with HCP ( Red Hat OpenShift Service on AWS with hosted control planes ) とは、簡単に言うとコントロールプレーンをRed Hat側のAWSに配置し、完全に管理を任せる仕組みです。 HCPが登場する前の従来の方式は、HCPと区別するために「ROSA Classic」と呼ばれていますが、以下の構成図を見ていただくと、一目でその違いが理解できると思います。 Copyright © Red Hat, Inc. ROSA Classicの構成図 Copyright © Red Hat, Inc. ROSA with HCPの構成図 構成図からもわかるように、Classic方式では、コントロールプレーンノードがユーザー自身のAWSアカウント（VPC）内に配置され、ワーカーノードと共存していました。 一方、HCP方式では、コントロールプレーンがユーザーのネットワーク環境から安全に分離された場所に配置され、AWS PrivateLinkを介してやり取りする仕組みになっています。 このような構成の違い以外にも、HCP方式は数多くのメリットを持っています。ここからは、どのようなメリットがあるか紹介します。 コントロールプレーンの管理コストの削減 コントロールプレーンには、APIサーバーやetcdデータベースなど、クラスター全体を制御する極めて重要なコンポーネントが含まれています。これらをRed Hat側が完全に管理・運用してくれるため、ユーザーの運用保守のコストが大幅に削減されます。 AWSインフラ費用（EC2代金）を節約できる 従来のClassic方式では、コントロールプレーンを構成するノード（EC2インスタンス）をユーザー自身のAWS環境内に作成する必要がありました。 OpenShiftの仕様上、クラスターの安定稼働（高可用性）を維持するためには最低3台のコントロールプレーンノードが必須となりますので、小規模な開発環境であっても、ベースとなるEC2の固定費用がどうしても高くなってしまうというコスト面の課題がありました。 HCP方式では、このコントロールプレーンがRed Hat側に完全に移動するので、ユーザーのAWSアカウントからは最低3台分のEC2の料金が完全に消えることになります。 これは、AWSのインフラコストを劇的に節約・削減できるというHCP方式だけの大きなメリットになります。 クラスター作成速度の向上 従来のClassic方式では、クラスターを新規作成するたびに、ユーザーのAWS環境内でコントロールプレーンのインフラも一から組み立てる必要がありました。そのため、クラスターが完全に起動して利用可能になるまでに、約30分〜40分ほどの待ち時間が発生していました。 HCP方式では、コントロールプレーンの構築・プロビジョニングがRed Hat側の環境で迅速に行われます。 ユーザーのAWS環境内では、アプリケーションを動かすためのワーカーノードのみを作成すれば良いため、クラスターの作成時間が約10分程度へと大幅に短縮されました。急ぎで新しい環境が必要になったりするビジネスシーンにおいて、このような時間の短縮は大きなメリットになります。 アップグレードの柔軟性 従来のClassic方式では、コントロールプレーンとワーカーノードのバージョンアップを密に連動させて管理する必要がありました。そのため、互換性の確認や影響範囲の調査を慎重に行わなければならず、事前の計画や検証に多くの工数を割く必要がありました。 HCP方式では、コントロールプレーンとワーカーノードの管理が完全に切り離されていますので、両者のアップグレードを別々のタイミングでスケジュールすることも可能です。 例えば、まずはRed Hat側が管理するコントロールプレーンだけを先行してアップデートし、アプリケーションが動くワーカーノードは業務影響の最も少ない別の日時に実施する、といった柔軟な運用ができるようになりました。   以上が、ROSA Classicと比べたHCP方式の特徴とメリットの解説になります。最後に、これまでご紹介した内容を表で簡単にまとめます。 ROSA ClassicとROSA HCPの比較表 比較項目 ROSA Classic（従来方式） ROSA with HCP（最新モデル） コントロールプレーンの配置 ユーザー自身のAWSアカウント Red Hat側 マスターノードのEC2費用 ユーザー負担 ユーザー側の負担ゼロ（Red Hat側で稼働するため） クラスター作成時間 約40分 約10分 アップグレード調整 両ノードが連動しているため、スケジュールの調整がしづらい 別々のタイミングで柔軟に調整・実行が可能 まとめ 以上、ROSAの概要から、現在の主流である「HCP（Hosted Control Planes）」の特徴と数々のメリットについてご紹介しました。 ROSA with HCPは、コスト・速度・運用のすべてにおいて優れており、現在のROSA構築におけるベストプラクティスとなっています。 これから新しくコンテナ基盤を検討される方に、この記事の内容が参考になれば幸いです。 次回は、実際にAWS上でROSA with HCPのクラスターを構築していく手順を詳しく解説します。ぜひ楽しみにしてください。 参考資料 AWS での Red Hat ソリューション Overview of responsibilities for ROSA ROSA HCP and ROSA classic Capability Matrix （ログイン必要） ROSA Best Practices and Recommendations Red Hat OpenShift Service on AWS 4 Introduction to ROSA ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post ROSA（Red Hat OpenShift Service on AWS）を利用したコンテナプラットフォーム構築 ~ROSAの特徴とメリット~ first appeared on SIOS Tech Lab .