3.2.5.2.17. エンドポイント
すべてのタイプのコンポーネントは、Docker イメージが公開するエンドポイントを指定できます。CodeReady Workspaces クラスターが OpenShift Ingress または OpenShift ルートを使用し、ワークスペース内の他のコンポーネントを使用して実行している場合は、これらのエンドポイントにアクセスできます。アプリケーションまたはデータベースサーバーがポートをリッスンし、直接対話できるようにする場合や、他のコンポーネントで対話できるようにする場合は、アプリケーションまたはデータベースのエンドポイントを作成できます。
エンドポイントには、以下の例のように複数のプロパティーがあります。
ここでは、2 つの Docker イメージがあり、1 つのエンドポイントを定義します。エンドポイントは、ワークスペース内や、一般に UI からアクセス可能なアクセス可能なポートです。各エンドポイントには名前とポートがあります。これは、コンテナー内で実行中の特定のサーバーがリッスンするポートです。エンドポイントに設定できる属性を以下に示します。
-
discoverable
: エンドポイントが検出可能な場合、その名前をワークスペースコンテナー内のホスト名として使用してアクセスできることを意味します(OpenShift パリスでは、指定された名前でサービスが作成されます)。55 -
公開
: エンドポイントはワークスペースの外部でもアクセスできます(このようなエンドポイントは CodeReady Workspaces ユーザーインターフェースからアクセスできます)。このようなエンドポイントは、常にポート80
または443
で公開されます(CodeReady Workspaces でtls
が有効かどうかによって異なります)。 -
protocol
: パブリックエンドポイントの場合、プロトコルはエンドポイントアクセスの URL を構築する方法の UI へのヒントになります。通常の値はhttp
、https
、
wss
です。 Secure
: アクセスを許可するために JWT ワークスペーストークンを必要とする JWT プロキシーの背後に配置するブール値(false
にデフォルト設定)。JWT プロキシーはサーバーと同じ Pod にデプロイされ、サーバーが127.0.0.1
などのローカルループバックインターフェースでのみリッスンすることを前提とします。警告ローカルループバック以外のインターフェースをリッスンすると、対応する IP アドレスのクラスターネットワーク内で JWT 認証がなくてもアクセスできるため、セキュリティーリスクが発生します。
-
path
: エンドポイントの URL。 -
unsecuredPaths
:secure 属性が
でないままにするエンドポイントパスのコンマ区切りリスト。true
に設定されている場合でもセキュア CookieAuthEnabled
:true
に設定すると(デフォルトはfalse
)、JWT ワークスペーストークンは自動的に取得され、リクエストが JWT プロキシーを通過できるようにワークスペース固有のクッキーに含まれます。警告この設定では、POST リクエストを使用するサーバーとともに使用されると、CSRF 攻撃が可能になる可能性があります。
コンポーネント内で新しいサーバーを起動すると、CodeReady Workspaces がこれを自動検出し、UI はこのポートを パブリック
ポートとして自動的に公開します。これは、たとえば Web アプリケーションのデバッグに役立ちます。コンテナーで自動起動するサーバー(データベースサーバーなど)では、これは実行できません。このようなコンポーネントについては、エンドポイントを明示的に指定します。
kubernetes
/openshift
および chePlugin / cheEditor タイプ
のエンドポイントを指定する例: