SSH経由でのGitのサポート
この文書では、さまざまな環境/プラットフォームでのGit over SSHの設定ガイドラインを示します。
概要
GitLab Shell Helm chartは、GitLabへのGit SSHアクセス用に設定されたSSHサーバを提供します。このコンポーネントは、ポート22 でクラスターの外部に公開する必要があります。
GitLab Operatorは、gitlab.gitlab-shell.enabled がtrueに設定されている場合、gitlab-shell をデプロイします。 これはデフォルトの設定です。
ターゲットプラットフォームに基づく要件をまとめると、以下のようになります：
| GitをSSHで使う必要がありますか？ | Kubernetes | OpenShift |
|---|---|---|
| なし | 以下のNGINX Ingressプロバイダのいずれかを使用する必要があります（KubernetesにはIngressプロバイダが組み込まれていません）。 | 以下のIngressプロバイダは必要ありません - 組み込みのRoutesをIngressプロバイダとして使用できます。 |
| はい | 以下のNGINX Ingressプロバイダのいずれかを使用する必要があります（KubernetesにはIngressプロバイダが組み込まれていません）。 | 以下のIngressプロバイダのいずれかを使用する必要があります - Routesはポート22 の公開をサポートしていません。 |
Ingressプロバイダ
以下は、Ingressプロバイダーのリストと、関連する注意事項、プラットフォーム固有の詳細です。
NGINX-Ingressヘルムチャート
GitLabは、SSH経由のGitをサポートするように変更されたNGINXリソースを「そのまま」デプロイするために使用できる、forkedNGINX-ingress chart を維持しています。
これはGitLab Operatorを使用する際のデフォルト設定で、GitLab CRのnginx-ingress.enabled={true,false} 。false に設定すると、外部のNGINXインスタンスを使用できます。
このIngressプロバイダはKubernetesとOpenShiftの両方で使用できます。
NGINX Ingressプロバイダのインストールオプションの詳細については、インストールドキュメントをご覧ください。
NGINX Ingress オペレータ
組み込みのNGINX-Ingress Helmチャートフォークの代替として、NGINX Ingress Operatorを使用してgitlab-shell 。
このオプションにはいくつかの注意点があります：
- NGINXINCのTransportServer/GlobalConfiguration CustomResourceDefinitionsは機能プレビューであり、本番環境での使用には注意が必要です。
- NGINX Inc.Operatorはまだバージョン0.3.0と比較的若いものです。より成熟したHelm Chartほど多くの設定オプションは含まれていません。
- このオプションを使用するには、NGINX サービスでポート
22を_手動で_公開する必要があります（これは NGINXIngressController CR では設定できません）。
より広範な調査については#58 を参照してください。
OpenShift ルート
OpenShiftRoutesはOpenShiftクラスター用の組み込みコンポーネントです。Kubernetes Ingresses に相当する OpenShift のコンポーネントです。
OpenShiftにデプロイする際、GitLab CRでnginx-ingress.enabled=false 、OpenShift Routesが内部トラフィックのフローを制御できるように設定できます。GitLab OperatorがIngressオブジェクトをリコンサイルすると、OpenShiftはクラスターのベースドメインにマッピングする同等のRouteオブジェクトを自動的に作成します。
OpenShift Routes は TCP トラフィック（ポート22 の SSH）の公開をサポートしていないため、gitlab-shell 経由の SSH 経由の Git には使用できないことに注意してください。
考慮事項
以下はIngressを使用する際に考慮すべき項目です。
OpenShiftでサードパーティのIngressプロバイダを使う場合
OpenShiftでサードパーティのIngressコントローラを使用する場合、OpenShiftのIngressコントローラがサードパーティのIngressコントローラと競合するケースがあります。
一例として、NGINX Ingress Controller が IngressADDRESS を NGINX サービスの内部 IP アドレスに設定し、OpenShift Ingress Controller がそれをクラスターのベースドメインで上書きすることがあります。これは DNS 設定と衝突する可能性があります。特に、Ingress が IP アドレスを持つことに依存するexternal-dns のようなサービスを使用している場合、特定の NGINX サービスに URL をマッピングするための A レコードを作成することができます。これはGitLab Operator CI環境でのケースです。
これを回避するために、OpenShift Ingress Controller にパッチを当ててOpenShift 固有の名前空間のみを管理するようにし、GitLab 固有の名前空間で作成した Ingress が望ましくない形で変更されないようにしています。