Red Hat OpenShift Service on AWS のデプロイ

多くの企業が、すべてのアプリケーションの開発と実行を行うための共通プラットフォームとして Red Hat OpenShift を選択しています。それにより、複雑性を増す原因となる異種混在環境を回避しています。そうした企業は、Red Hat OpenShift で新しいクラウドネイティブ・アプリケーションを構築して実行するだけでなく、レガシーアプリケーションを OpenShift に移行することもできます。

OpenShift を使用する主な利点の 1 つは、基盤となるプラットフォームに関する詳細が抽象化され、開発者が 1 つのインタフェースを習得するだけで済むことです。これにより、生産性が大幅に向上します。

Red Hat OpenShift Service on AWS (ROSA)

OpenShift の導入を決定したお客様の中には、単純化をさらに一歩進めたい組織もあります。そのようなお客様は、クラスタのインフラストラクチャの準備とその管理について頭を悩ませたくないと考えています。チームが初日から高い生産性を発揮し、アプリケーションの開発のみに集中できるようにすることを重視します。そのようなお客様向けの選択肢の 1 つが Red Hat OpenShift Service on AWS (ROSA) です。

ROSA は、Amazon Web Services (AWS) パブリッククラウドで完全にホストされます。保守は Red Hat と AWS が共同で行います。コントロールプレーンとコンピュートノードは Red Hat のサイト信頼性エンジニア (SRE) チームによって完全に管理され、サポートは Red Hat と Amazon が共同で提供します。これは、すべてのノードでのインストール、管理、保守、およびアップグレードが対象となります。

ROSA のデプロイメントの選択肢

ROSA をデプロイする方法は主に、パブリッククラスタにデプロイする方法とプライベートリンクにデプロイする方法の 2 つがあります。いずれの場合も、レジリエンシー (回復力) と高可用性 (HA) を実現するために、複数のアベイラビリティゾーンにデプロイすることをお勧めします。 

パブリッククラスタは基本的に、厳格なセキュリティ要件のないワークロードで使用します。クラスタは、プライベートサブネット (この中にコントロールプレーン・ノード、インフラストラクチャ・ノード、アプリケーションを実行するワーカーノードが含まれる) 内の 仮想プライベートクラウド (VPC) にデプロイされます。それでもインターネットからアクセスされるので、VPC に加えてパブリックサブネットが必要です。 

このパブリックサブネットにデプロイされた AWS ロードバランサー (Elastic および Network Load Balancer) により、SRE チームとアプリケーションにアクセスするユーザー (つまり、クラスタへの ingress トラフィック) の両方が接続できるようになります。ユーザーの場合、トラフィックはロードバランサーによって、インフラストラクチャ・ノードで実行されているルーターサービスにリダイレクトされ、そこからワーカーノードの 1 つで実行されている目的のアプリケーションに転送されます。SRE チームは、専用の AWS アカウントを使用し、さまざまなロードバランサーを介してコントロールノードとインフラストラクチャ・ノードに接続します。 

図 1. ROSA パブリッククラスタ

より厳格なセキュリティニーズを伴うプロダクション・ワークロードの場合は、PrivateLink クラスタをデプロイすることをお勧めします。この場合、クラスタが存在する VPC はプライベートサブネットのみを持ちます。つまり、パブリックインターネットからは一切アクセスできません。 

SRE チームは、AWS PrivateLink エンドポイントを介して AWS ロードバランサーに接続する、専用の AWS アカウントを使用します。ロードバランサーは、必要に応じてトラフィックをコントロールノードまたはインフラストラクチャ・ノードにリダイレクトします。(AWS PrivateLink の作成後、SRE チームが使用する AWS アカウントからのアクセスをお客様が承認する必要があります。) ユーザーは AWS ロードバランサーに接続し、インフラストラクチャ・ノードのルーターサービスにリダイレクトされます。そこから、アクセスしようとしているアプリケーションが実行されているワーカーノードに転送されます。

PrivateLink クラスタの実装では、クラスタの Egress トラフィックをオンプレミス・インフラストラクチャまたは AWS クラウド内の他の VPC にリダイレクトしたいというお客様も少なくありません。そのためには、AWS Transit Gateway または AWS Direct Connect を使用できます。これにより、クラスタが存在する VPC にパブリックサブネットをデプロイする必要はありません。Egress トラフィックをインターネットに転送する必要がある場合でも、AWS NAT ゲートウェイ と AWS Internet Gateway を備えたパブリックサブネットを持つ VPC に (AWS Transit Gateway を介して) 接続することができます。

図 2. PrivateLink を使用する ROSA プライベートクラスタ

パブリックの実装と PrivateLink の実装の両方で、クラスタは AWS VPC エンドポイントを使用して他の AWS サービスと対話し、目的のサービスを備えたクラスタのある VPC と通信できます。

クラスタへの接続

SRE チームが ROSA クラスタにログオンして管理タスクを実行するために推奨される方法は、AWS Security Token Service (STS) を使用することです。最小権限の概念を適用して、タスクを実行するためにどうしても必要なロールのみが割り当てられるようにします。トークンは一時的なもので、1 回限り使用できるので、期限が切れた後に同様のタスクを再度実行する必要がある場合は、新しいトークンを要求しなければなりません。

STS の使用は、対象範囲を広げて、ROSA クラスタから EC2 (たとえば、クラスタ用に新しいサーバーをスピンアップする必要がある場合) や EBS (永続ストレージが必要な場合) などの他の AWS サービスへの接続にも適用できます。

まとめ

DevOps 手法を導入し、OpenShift のようなエンタープライズ Kubernetes プラットフォームを使用してアプリケーションのデプロイ方法をモダナイズすることは、あらゆるタイプのお客様に有効です。お客様はオンプレミスでホストして社内で管理することも可能ですが、それを望まない場合の選択肢の 1 つが ROSA です。ROSA クラスタは数多くの AWS サービスと連携できるので、お客様がプラットフォームを最大限に活用するのに役立ちます。

さらに詳しく

• Red Hat OpenShift Service on AWS の実装