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