GitLabマネージドアプリ

GitLabは、設定したクラスターに直接追加できる様々なアプリをワンクリックでインストールできるGitLab Managed Appsを提供しています。

これらのアプリケーションは、Auto DevOpsを使用する際のレビューアプリとデプロイに必要です。

クラスターを作成した後にインストールできます。

アプリケーションのインストール

GitLabによって管理されるアプリケーションはgitlab-managed-apps ネームスペースにインストールされます。

この名前空間：

  • プロジェクトのデプロイに使用されるネームスペースとは異なります。
  • 作成は一度だけ。
  • 設定不可能な名前。

インストール可能なアプリケーションの一覧を表示するには、以下の手順に従います：

注意:GitLab 11.6では、アプリケーションをインストールする前にGitLabがサポートする最新バージョンにHelmをアップグレードします。

インストールできるアプリケーションは以下の通りです：

Knativeを除き、アプリケーションはgitlab-managed-appsという専用の名前空間にインストールされます。

注意:一部のアプリケーションはプロジェクト・レベルのクラスターにのみインストール可能です。 グループ・レベルのクラスターにこれらのアプリケーションをインストールするためのサポートは、将来のリリースで予定されています。 アップデートについては、イシュー追跡の進捗を参照してください。
注意:既にHelmがインストールされている既存のKubernetesクラスタがある場合、GitLabはそれを検出できないので注意が必要です。 この場合、アプリケーション経由でHelmをインストールすると、クラスタに2回Helmがインストールされることになり、デプロイ時に混乱する可能性があります。

Helm

  • GitLab 10.2でプロジェクトレベルのクラスターに導入されました。
  • GitLab 11.6でグループレベルのクラスターに導入されました。
  • GitLab 13.2では、機能フラグの後ろにローカルTillerオプションが導入され、デフォルトで有効になりました。
  • GitLab.comでは、ローカルTillerの機能フラグが有効になっています。

HelmはKubernetes用のパッケージマネージャで、GitLabが管理するアプリのインストールに使用されます。 GitLabはクラスター内部のgitlab-managed-apps 名前空間内のポッドで、helm の各コマンドを実行します。

GitLab 13.2では、インテグレーションはデフォルトでローカルのTillerを使用します。 ローカルのTillerを使用する場合、Helmアプリケーションをインストールする必要はなく、アプリケーションのリストにも表示されません。

注意:GitLabのHelmインテグレーションはプロキシの背後にあるアプリケーションのインストールをサポートしていませんが、回避策はあります。

ローカルティラーの有効/無効

Local Tillerは開発中ですが、本番環境での使用は可能です。デフォルトで有効になっている機能フラグの後ろにデプロイされています。 GitLab RailsコンソールにアクセスできるGitLab管理者は、インスタンスで有効にすることができます。

有効にするには: 

# Instance-wide
Feature.enable(:managed_apps_local_tiller)

無効化するには: 

# Instance-wide
Feature.disable(:managed_apps_local_tiller)

サートマネージャー

GitLab 11.6で導入されたプロジェクトレベルとグループレベルのクラスター。

cert-managerは、証明書の発行を支援するネイティブのKubernetes証明書管理コントローラです。 クラスターにcert-managerをインストールすると、Let’s Encryptによる証明書が発行され、証明書が有効で最新のものであることが保証されます。

このアプリケーションのインストールに使用するChartは、使用するGitLabのバージョンによって異なります。 で：

GitLab 12.3より前にcert-managerをインストールしている場合、Let’s Encryptは古いバージョンのcert-managerからのリクエストをブロックします。

これを解決するには

  1. cert-managerをアンインストールします（追加設定をバックアップすることを検討してください）。
  2. cert-managerを再度インストールしてください。

GitLabランナー

  • GitLab 10.6でプロジェクトレベルのクラスターに導入されました。
  • GitLab 11.10でグループレベルのクラスターに導入されました。

GitLab Runnerはジョブを実行し、結果をGitLabに送り返すためのオープンソースプロジェクトです。 ジョブを調整するGitLabに含まれるオープンソースの継続的インテグレーションサービスであるGitLab CI/CDと組み合わせて使用します。

プロジェクトがGitLab.com上にある場合、共有Runnerが利用できます（最初の2000分は無料で、後で追加購入できます）。 プロジェクト固有のRunnerが必要な場合や共有Runnerがない場合は、簡単にデプロイできます。

デプロイされたRunnerは特権として設定されることに注意してください。 これは基本的に基礎となるマシンへのrootアクセスを持つことを意味します。 これはDockerイメージをビルドするために必要なので、デフォルトになっています。 デプロイする前にセキュリティの意味を読んでください。

注:このアプリケーションのインストールには、runner/gitlab-runnerChartが使用されます。は事前に設定された](https://gitlab.com/gitlab-org/charts/gitlab-runner/-/blob/master/values.yaml)ファイルです。このファイルを変更してインストールをカスタマイズすることはサポートされていません。

イングレス

  • GitLab 10.2でプロジェクトレベルのクラスターに導入されました。
  • GitLab 11.6でグループレベルのクラスターに導入されました。

Ingressは、ロードバランシング、SSLターミネーション、名前ベースのバーチャルホスティングをすぐに提供します。 アプリケーションのウェブプロキシとして機能し、Auto DevOpsを使用したり、独自のウェブアプリをデプロイしたい場合に便利です。

インストールされているIngress Controllerは、KubernetesコミュニティでサポートされているIngress-NGINXです。

注:以下の手順では、エンドポイントを取得するためにロードバランサをクラスターにインストールする必要があります。 Ingress、またはKnativeを使用している場合はKnative独自のロードバランサ（Istio）のいずれかを使用できます。

ウェブアプリケーションを公開するためには、まずロードバランサに関連付けられた IP アドレスかホスト名となるエンドポイントを見つける必要があります。

インストールするには、IngressのInstallボタンをクリックしてください。 GitLabが外部エンドポイントの決定を試み、数分以内に利用可能になるはずです。

外部エンドポイントの自動決定

GitLab 10.6で導入されました。

Ingressのインストール後、外部エンドポイントは数分以内に利用可能になるはずです。

ヒント:このエンドポイントは、KUBE_INGRESS_BASE_DOMAIN 環境変数を使用してAuto DevOps ベースドメインに使用できます。

エンドポイントが表示されず、クラスターがGoogle Kubernetes Engine上で動作している場合：

  1. GoogleKubernetes Engine上のKubernetesクラスターをチェックし、そのノードにエラーがないことを確認します。
  2. Google Kubernetes Engineに十分なQuotasがあることを確認してください。 詳細については、リソースQuotasを参照してください。
  3. GoogleCloudのステータスを確認し、障害が発生していないことを確認してください。

インストールが完了すると、クラウドプロバイダーによっては “Ingress IP Address” の? が表示されることがあります。 EKS の場合は特に、ELB が IP アドレスではなく DNS 名で作成されるためです。 GitLab が Ingress または Knative アプリケーションのエンドポイントをまだ特定できない場合は、手動で特定することができます。

注：stable/nginx-ingressChartは、このアプリケーションを](https://gitlab.com/gitlab-org/gitlab/blob/master/vendor/ingress/values.yaml)ファイルでインストールする場合に使用します。

外部エンドポイントの手動決定

クラスターがGKE上にある場合は、Advanced settingsのGoogle Kubernetes Engineリンクをクリックするか、Google Kubernetes Engineダッシュボードに直接アクセスして適切なプロジェクトとクラスターを選択します。 次にConnectをクリックし、ローカルターミナルまたはCloud Shellを使用してgcloud コマンドを実行します。

クラスターがGKE上にない場合は、Kubernetesプロバイダの特定の指示に従って、正しい認証情報でkubectl 。以下の例の出力には、クラスターの外部エンドポイントが表示されます。 この情報を使用して、デプロイされたアプリケーションへの外部アクセスを許可するDNSエントリと転送ルールを設定できます。

Ingressをアプリケーションからインストールした場合は、以下のコマンドを実行してください： 

kubectl get service --namespace=gitlab-managed-apps ingress-nginx-ingress-controller -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

Kubernetesクラスタの中には、AmazonEKSのようにホスト名を返すものもあります。 これらのプラットフォームでは、実行します： 

kubectl get service --namespace=gitlab-managed-apps ingress-nginx-ingress-controller -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'

Istio/Knativeの場合、コマンドは異なります： 

kubectl get svc --namespace=istio-system istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip} '

それ以外の場合は、すべてのロードバランサーの IP アドレスをリストアップできます： 

kubectl get svc --all-namespaces -o jsonpath='{range.items[?(@.status.loadBalancer.ingress)]}{.status.loadBalancer.ingress[*].ip} '
注：EKSを使用する場合、Elastic Load Balancerも作成され、追加のAWSコストが発生します。
注意:Kubernetesのバージョンによっては末尾に% 。

Ingressはこのアドレスで利用できるようになり、リクエストのDNS名に基づいて、入ってくるリクエストを適切なサービスにルーティングします。 これをサポートするために、ワイルドカードDNS CNAMEレコードを希望するドメイン名に対して作成する必要があります。 例えば、*.myekscluster.com は先に取得したIngressホスト名を指すことになります。

固定IPの使用

デフォルトでは、クラスターのロードバランサーにはエフェメラルな外部IPアドレスが関連付けられています。 エフェメラルなIPをDNSに関連付け、IPが変更された場合、アプリにアクセスできなくなり、DNSレコードを再度変更する必要があります。 これを避けるには、静的な予約IPに変更する必要があります。

GKEでエフェメラル外部IPアドレスを昇格させる方法をお読みください。

DNSを外部エンドポイントに向けます。

外部エンドポイントを設定したら、アプリにアクセスできるように、*.example.com.などのワイルドカード DNS レコードと関連付ける必要があります。 外部エンドポイントが IP アドレスの場合は A レコードを使用します。 外部エンドポイントがホスト名の場合は CNAME レコードを使用します。

ウェブアプリケーションファイアウォール (ModSecurity)

GitLab 12.7から導入されました。

ウェブアプリケーションファイアウォール(WAF) は、送受信されるトラフィックを検査し、悪意のあるトラフィックがアプリケーションに到達する前にブロックすることができます。 WAF の利点は以下のとおりです：

  • アプリケーションのリアルタイム・セキュリティ・モニタリング
  • アプリケーションへのすべてのHTTPトラフィックのロギング
  • アプリケーションのアクセス制御
  • 高度に設定可能なロギングおよびブロックルール

GitLabは、ModSecurityというWAFを提供しています。

ModSecurityは、リアルタイムのWebアプリケーション監視、ロギング、アクセス制御のためのツールキットです。 GitLabの提供により、汎用的な攻撃検知機能を提供するOWASPのCoreルールセットが自動的に適用されます。

この機能：

  • 特に設定しない限り、「検出専用モード」で動作します。

  • Ingressコントローラのmodsec 、ルール違反のログをチェックすることで確認できます： 

     kubectl logs -n gitlab-managed-apps $(kubectl get pod -n gitlab-managed-apps -l app=nginx-ingress,component=controller --no-headers=true -o custom-columns=:metadata.name) modsecurity-log -f

WAFを有効にするには、Ingressアプリケーションをインストールまたはアップデートする際に、それぞれのトグルを有効の位置に切り替えてください。

GitLabのWAFを初めて使う場合は、クイックスタートガイドに従うことをお勧めします。

ModSecurity を有効にすることで、若干のパフォーマンスオーバーヘッドが発生します。 これがアプリケーションにとって大きいと考えられる場合、以下のいずれかの方法で、デプロイされたアプリケーションの ModSecurity のルールエンジンを無効にすることができます：

  1. デプロイ変数AUTO_DEVOPS_MODSECURITY_SEC_RULE_ENGINE をOffに設定します。 これにより ModSecurity は指定されたアプリケーションや環境に対するリクエストを処理できなくなります。

  2. それぞれのトグルを無効の位置に切り替え、変更を保存ボタンで適用します。 これでIngressが最近の変更で再インストールされます。

Disabling WAF

ロギングとブロックモード

WAFルールを調整するために、WAFをグローバルにログまたはブロックモードに設定することができます：

  • ログモード- ルールに一致するトラフィックの通過を許可し、イベントをログに記録します。
  • ブロックモード- ルールに一致するトラフィックの通過を阻止し、イベントをログに記録します。

WAFのモードを変更するには：

  1. まだインストールしていない場合は、ModSecurityをインストールしてください。
  2. cloud-gear} Operations >Kubernetesに移動します。
  3. アプリケーションで、Ingressまでスクロールします。
  4. グローバル・デフォルト（Global default）]で、希望のモードを選択します。
  5. 変更を保存する］をクリックします。
WAFのバージョン更新

ModSecurityのロギングモードの有効化、無効化、変更は、将来のリリースで克服されるかもしれないHelmの制限のため、同じバージョンのIngressでのみ許可されています。

デプロイされたバージョンが GitLab で利用可能なものと異なる場合、ModSecurityUI コントロールは無効になりますが、アンインストールなどのIngressレベルでのアクションは実行できます：

WAF settings disabled

Ingressを最新バージョンにアップデートすることで、バグフィックス、セキュリティフィックス、パフォーマンス改善を利用することができます。Ingressアプリケーションをアップデートするには、まずアンインストールし、ModSecurityのインストールで説明されているように再インストールする必要があります。

Webアプリケーションファイアウォールのトラフィックの表示

GitLab Ultimate12.9で導入されました。

Web Application Firewall のトラフィックは、プロジェクトの [Security& Compliance] > [Threat Monitoring]ページで確認できます。

そこから経年変化を見ることができます：

  • アプリケーションへの総トラフィック量。
  • Web Application Firewall のデフォルトのOWASP ルールセットで異常とみなされるトラフィックの割合。

トラフィックのかなりの割合が異常である場合、潜在的な脅威がないか調査する必要があります。これは、Web アプリケーション・ファイアウォールのログを調べることで可能です。

Threat Monitoring

ジュピターハブ

  • GitLab 11.0でプロジェクトレベルのクラスターに導入されました。
  • GitLab 12.3でグループとインスタンスレベルのクラスターに導入されました。

JupyterHubは、チーム全体でノートブックを管理するためのマルチユーザーサービスです。Jupyter Notebooksは、データ分析、可視化、機械学習に使用されるWebベースのインタラクティブなプログラミング環境を提供します。

認証は、プロジェクト・レベルのクラスターではプロジェクト・メンバ、グループ・レベルのクラスターではグループ・メンバで、関連するプロジェクトまたはグループに対して開発者以上のアクセス権を持つ場合にのみ有効になります。

また、NurtchのRubixライブラリで構築された、すぐに使えるDevOps Runbookもご覧いただけます。

実行可能なランブックの作成に関する詳細は、Runbooksドキュメントを参照してください。 JupyterHubをインストールする前に、Ingressがインストールされ、IPアドレスが割り当てられている必要があることに注意してください。

注：jupyter/jupyterhubChartは、このアプリケーションを](https://gitlab.com/gitlab-org/gitlab/blob/master/vendor/jupyter/values.yaml)ファイルでインストールする場合に使用します。

Jupyter Gitインテグレーション

KubernetesクラスターにJupyterHubをインストールすると、JupyterLabのGitエクステンションが自動的にプロビジョニングされ、認証されたユーザーを使用して設定されます：

  • 名前
  • Eメール
  • 新しく作成されたアクセストークンです。

JupyterLabのGitエクステンションは、ノートブックの完全なバージョン管理とJupyter内でのGitコマンドの発行を可能にします。 Gitコマンドは、左パネルのGitタブまたはJupyterのコマンドラインプロンプトから発行できます。

注意:JupyterLabのGitエクステンションは、ユーザートークンをJupyterHub DBには暗号化された形式で、シングルユーザのJupyterインスタンスにはプレーンテキストとして保存します。 これは、Gitが認証情報をプレーンテキストとして保存することを要求しているためです。 悪意のあるユーザがシングルユーザのJupyterインスタンスのファイルシステムから読み取る方法を見つけた場合、トークンを取得できる可能性があります。

Jupyter's Git Extension

リポジトリはJupyterのファイルタブからクローンできます：

Jupyter clone repository

ナティブ

  • GitLab 11.5でプロジェクトレベルのクラスターに導入されました。
  • GitLab 12.3で導入された、グループとインスタンスレベルのクラスター。

Knativeは、Kubernetesクラスターからサーバーレスワークロードを作成、デプロイ、管理するためのプラットフォームを提供します。Istioと組み合わせて使用され、Knativeがホストするすべてのプログラムに外部IPアドレスを提供します。

アプリケーションを公開するワイルドカードドメインを入力するプロンプトが表示されます。 そのドメインの外部IPアドレスを使用するようにDNSサーバを設定します。 作成されインストールされたアプリケーションは、<program_name>.<kubernetes_namespace>.<domain_name>としてアクセスできるようになります。 このためには、KubernetesクラスターでRBACが有効になっている必要があります。

注knative/knativeChartはこのアプリケーションのインストールに使用します。

Prometheus

  • GitLab 10.4でプロジェクトレベルのクラスターに導入されました。
  • GitLab 11.11でグループレベルのクラスターに導入されました。

Prometheusは、デプロイされたアプリケーションを監視するのに便利なオープンソースの監視およびアラートシステムです。

GitLabはPrometheusインテグレーションを利用して、アプリケーションを自動的に監視することができます。 KubernetesコンテナのCPUとメモリのメトリクスが自動的に収集され、NGINX Ingressからもレスポンスのメトリクスが取得されます。

監視を有効にするには、インストールボタンでクラスターにPrometheusをインストールするだけです。

注：stable/prometheusChartは、このアプリケーションを](https://gitlab.com/gitlab-org/gitlab/blob/master/vendor/prometheus/values.yaml)ファイルでインストールする場合に使用します。

クロスプレーン

Crossplaneは、複数のクラウドにまたがるアプリケーションやインフラストラクチャを管理するのに便利なマルチクラウドのコントロールプレーンです。 Kubernetes APIを使用して拡張します：

  • カスタムリソース。
  • これらのカスタムリソースを監視するコントローラ。

Crossplaneは、クラウドプロバイダー固有の設定を抽象化することで、クラウドプロバイダー間で統一された方法でインフラストラクチャ・コンポーネントのプロビジョニングとライフサイクル管理を可能にします。

Crossplane GitLabが管理するアプリケーション：

  • プロジェクトリポジトリに接続されたKubernetesクラスターに、任意のプロバイダーでCrossplaneをインストールします。
  • その後、Auto DevOpsパイプラインを介して、PostgreSQL（GCPのCloudSQLやAWSのRDSなど）やアプリケーションに必要なその他のサービスなどのインフラストラクチャやマネージドアプリケーションのプロビジョニングに使用できます。

クラスターにインストールされたCrossplaneの設定については、「Crossplaneの設定」を参照してください。

注:](https://github.com/crossplane/crossplane/blob/master/cluster/charts/crossplane/values.yaml.tmpl)ファイルを使用したCrossplaneのインストールには、alpha/crossplane chart v0.4.1を使用します。

弾性スタック

GitLab 12.7でプロジェクトレベル、グループレベルのクラスターに導入されました。

Elastic Stackは、様々なマシンから生成されたログの詳細な検索、分析、可視化を支援する、完全なエンドツーエンドのログ分析ソリューションです。

GitLabはクラスタ内のポッドからログを自動的に収集することができます。 Filebeatはクラスタ内の各ノードでDaemonSetとして実行され、クエリ用にコンテナログをElasticsearchに送信します。 GitLabはKubernetes APIの代わりにElasticsearchにログを接続し、より高度なクエリ機能を利用できるようになります。

ログデータはCuratorを使用して30日後に自動的に削除されます。

ログ配送を有効にするには

  1. クラスターにf1-micro,g1-small,n1-standard-1よりも大きいインスタンス・タイプのノードが少なくとも3つ含まれていることを確認してください。
  2. cloud-gear} Operations >Kubernetesに移動します。
  3. Kubernetes Clusterで、クラスターを選択します。
  4. アプリケーションセクションでElastic Stackを探し、インストールをクリックします。
注：gitlab/elastic-stackChartは、このアプリケーションを](https://gitlab.com/gitlab-org/gitlab/blob/master/vendor/elastic_stack/values.yaml)ファイルでインストールする場合に使用します。
注：このチャートは、コロケーションできない同一のElasticsearchポッドを3つデプロイしており、それぞれ1CPUと2GBのRAMを必要とするため、3ノード未満のクラスターや、f1-micro,g1-small,n1-standard-1,*-highcpu-2 インスタンスタイプで構成されるクラスターとは互換性がありません。
注：Elastic Stackクラスタアプリケーションは、ログ集約ソリューションとして開発されたものであり、別のElasticsearchクラスタを使用するAdvanced Global Search機能とは関係ありません。

オプション：高度なクエリを実行するためにKibanaをデプロイします。

上級ユーザーで、kubectl とhelmを使用して Kubernetes クラスターに直接アクセスできる場合は、手動で Kibana をデプロイできます。

以下は、helm がhelm initで初期化されていると仮定しています。

以下をkibana.ymlに保存してください： 

elasticsearch:
  enabled: false

filebeat:
  enabled: false

kibana:
  enabled: true
  elasticsearchHosts: http://elastic-stack-elasticsearch-master.gitlab-managed-apps.svc.cluster.local:9200

その後、クラスターにインストールしてください： 

helm repo add gitlab https://charts.gitlab.io
helm install --name kibana gitlab/elastic-stack --values kibana.yml

Kibanaにアクセスするには、ローカル・マシンにポートを転送します： 

kubectl port-forward svc/kibana-kibana 5601:5601

次に、http://localhost:5601で Kibana をご覧ください。

フルエント

GitLab 12.10でプロジェクトとグループレベルのクラスターに導入されました。

Fluentdはオープンソースのデータコレクターで、データの収集と消費を一元化し、データをより良く利用し理解することができます。 Fluentd は syslog フォーマットでログを送信します。

Fluentdを有効にするには

  1. cloud-gear}オペレーション>Kubernetesに移動し、アプリケーションをクリックします。 syslog経由でWAFログを送信するホスト、ポート、プロトコルを入力するよう求められます。
  2. SIEM Hostnameにホストドメイン名またはURLを入力します。
  3. SIEM Portにホストポート番号を入力します。
  4. SIEMプロトコルを選択します。
  5. 利用可能なログ（WAFやCiliumなど）の少なくとも1つを選択します。
  6. 変更を保存する］をクリックします。

Fluentd input fields

未来のアプリ

新しいGitLab管理アプリに貢献することに興味がありますか？開発ガイドラインのページをご覧ください。

GitLab CI/CDを使ったインストール（アルファ版）

GitLab 12.6 で導入されました。

警告：これは_アルファ版の_機能であり、予告なしに変更される場合があります。

この代替方法では、GitLab CI/CDを使ってGitLabが管理するアプリケーションをインストールすることができます。また、Helmvalues.yaml ファイルを使ってインストールをカスタマイズすることもできます。

対応アプリケーション

使用方法

クラスター・アプリケーション・プロジェクトの例では、以下のすべてのファイルを参照し、インポートすることができます。

GitLab CI/CDを使ってアプリケーションをインストールするには：

  1. クラスターをクラスター管理プロジェクトに接続します。

  2. そのプロジェクトに、以下の内容の.gitlab-ci.yml ： 

    include:
  - template: Managed-Cluster-Applications.gitlab-ci.yml
    注意:このテンプレートで提供されるジョブは、カスタムDockerイメージで提供されるツールを使用してクラスターに接続します。 Docker、Kubernetes、またはDocker Machineのexecutorにランナーを登録しておく必要があります。

  3. .gitlab/managed-apps/config.yaml ファイルを追加し、インストールするアプリケーションを定義します。installed キーを、アプリケーションをインストールする場合はtrue と定義し、アプリケーションをアンインストールする場合はfalse と定義します。 例えば、Ingress をインストールする場合： 

    ingress:
  installed: true
  4. オプションで、.gitlab/managed-apps/<application>/values.yaml ファイルを定義し、インストールされたアプリケーションの値をカスタマイズします。

GitLab CI/CD パイプラインがmaster ブランチ上で実行され、設定したアプリケーションがインストールされます。 パイプラインが失敗した場合、HelmTillerバイナリの出力は CIジョブのアーティファクトとして保存されます。

重要な注意事項

以下に注意してください。

  • クラスタ管理プロジェクトは、クラスターへのデプロイを管理するためだけに使用することをお勧めします。 このようなプロジェクトにアプリケーションのソースコードを追加しないでください。
  • installed キーの値をfalseに戻すと、アプリケーションはクラスターからプロビジョニング解除されます。
  • .gitlab/managed-apps/<application>/values.yaml を新しい値で更新すると、アプリケーションは再デプロイされます。

GitLab CI/CDを使ったIngressのインストール

Ingressをインストールするには、.gitlab/managed-apps/config.yaml ： 

ingress:
  installed: true

Ingress はクラスターのgitlab-managed-apps 名前空間にインストールされます。

クラスター管理プロジェクトで.gitlab/managed-apps/ingress/values.yaml ファイルを定義することで、Ingress のインストールをカスタマイズできます。 利用可能な設定オプションについては、Chartを参照してください。

注:Ingress管理アプリケーションのインストールに関するサポートはGitLab Configureグループによって提供されています。 不明な問題が発生した場合は、新しいイシューを開き、Configureグループの少なくとも2人にpingを送ってください。

GitLab CI/CDを使ったcert-managerのインストール

cert-managerはGitLab CI/CDを利用して、.gitlab/managed-apps/config.yamlで設定を定義してインストールします。

cert-manager：

  • クラスターのgitlab-managed-apps 名前空間にインストールされます。
  • デフォルトのLet’s EncryptClusterIssuerの有無にかかわらずインストールできます。この場合、電子メールアドレスの指定が必要です。この電子メールアドレスは、Let’s Encrypt が証明書の期限切れやアカウントに関する問題についてお客様に連絡するために使用します。

GitLab CI/CDを使ってcert-managerをインストールするには以下の設定が必要です： 

certManager:
  installed: true
  letsEncryptClusterIssuer:
    installed: true
    email: "user@example.com"

以下は、デフォルトのClusterIssuerを使わずに GitLab CI/CD を使って cert-manager をインストールします： 

certManager:
  installed: true
  letsEncryptClusterIssuer:
    installed: false

クラスター管理プロジェクトで.gitlab/managed-apps/cert-manager/values.yaml ファイルを定義することで、cert-manager のインストールをカスタマイズできます。 使用可能な設定オプションについては、Chartを参照してください。

注：Cert Manager管理アプリケーションのインストールに関するサポートは、GitLab Configureグループによって提供されます。 不明な問題が発生した場合は、新しいイシューを開き、Configureグループの少なくとも2人にpingを送信してください。

GitLab CI/CDを使ったSentryのインストール

注意:Sentry Helmチャートでは、データベースの移行に少なくとも3GBの利用可能なRAMを推奨しています。

Sentryをインストールするには、.gitlab/managed-apps/config.yaml ： 

sentry:
  installed: true

Sentryはクラスターのgitlab-managed-apps 名前空間にインストールされます。

クラスター管理プロジェクトで.gitlab/managed-apps/sentry/values.yaml ファイルを定義することにより、Sentryのインストールをカスタマイズできます。 利用可能な設定オプションについては、チャートを参照してください。

以下の設定オプションに細心の注意を払うことをお勧めします：

  • email.ユーザーをSentryインスタンスに招待し、エラーメールを送信するために必要です。
  • userデフォルトの管理者ユーザーのログイン情報を設定できます。
  • postgresql今後のアップデートを実行する際に使用できる PostgreSQL パスワード。
注意:アップグレードの際には、既存のPostgreSQLのパスワード（postgresql.postgresqlPassword キーで与えられたもの）を提供することが重要です。さもないと認証エラーが発生します。 詳細はPostgreSQLのチャートドキュメントを参照してください。

以下はSentryの設定例です： 

# Admin user to create
user:
  # Indicated to create the admin user or not,
  # Default is true as the initial installation.
  create: true
  email: "<your email>"
  password: "<your password>"

email:
  from_address: "<your from email>"
  host: smtp
  port: 25
  use_tls: false
  user: "<your email username>"
  password: "<your email password>"
  enable_replies: false

ingress:
  enabled: true
  hostname: "<sentry.example.com>"

# Needs to be here between runs.
# See https://github.com/helm/charts/tree/master/stable/postgresql#upgrade for more info
postgresql:
  postgresqlPassword: example-postgresql-password
注：Sentry管理アプリケーションのインストールに関するサポートは、GitLab Healthグループによって提供されています。 不明な問題が発生した場合は、新しいイシューを開き、Healthグループの少なくとも2人にpingを送信してください。

GitLab CI/CDを使ったPostHogのインストール

PostHogᦔは開発者に優しいオープンソースの製品分析プラットフォームです。

PostHogをクラスターのgitlab-managed-apps 名前空間にインストールするには、.gitlab/managed-apps/config.yaml ファイルを次のように定義します： 

posthog:
  installed: true

クラスタ管理プロジェクトで.gitlab/managed-apps/posthog/values.yaml。利用可能な設定オプションについては、PostHogチャートのREADMEのConfigurationセクションを参照してください。

注意:PostgreSQLのパスワードをpostgresql.postgresqlPassword。さもないと認証エラーが発生します。 詳細はPostgreSQLチャートのドキュメントを参照してください。

Redis ポッドはアップグレードのたびに再起動されます。 ダウンタイムを防ぐには、redis.password キーを使用して Redis パスワードを指定します。 これにより、再起動のたびに新しいパスワードが生成されるのを防ぐことができます。

以下はPostHogの設定例です： 

ingress:
  enabled: true
  hostname: "<posthog.example.com>"

# This will be autogenerated if you skip it. Include if you have 2 or more web replicas
posthogSecret: 'long-secret-key-used-to-sign-cookies'

# Needs to be here between runs.
# See https://github.com/helm/charts/tree/master/stable/postgresql#upgrade for more info
postgresql:
  postgresqlPassword: example-postgresql-password

# Recommended to set this to a value to redis prevent downtime between upgrades
redis:
  password: example-redis-password
注：PostHog管理アプリケーションのサポートはPostHogチームによって提供されます。 イシューに遭遇した場合は、直接サポートチケットを開いてください。

GitLab CI/CDを使ったPrometheusのインストール

GitLab 12.8で導入されました。

Prometheusは、デプロイされたアプリケーションを監視するためのオープンソースの監視およびアラートシステムです。

クラスターのgitlab-managed-apps ネームスペースに Prometheus をインストールするには、.gitlab/managed-apps/config.yaml ファイルを次のように定義します： 

prometheus:
  installed: true

クラスタ管理プロジェクトで.gitlab/managed-apps/prometheus/values.yaml を定義することで、Prometheus のインストールをカスタマイズできます。利用可能な設定オプションについては、Prometheus チャートの README の Configuration セクションを参照してください。

注：Prometheus管理アプリケーションのインストールに関するサポートはGitLab APMグループによって提供されています。 不明な問題が発生した場合は、新しいイシューを開き、APMグループの少なくとも2人にpingを送信してください。

GitLab CI/CDを使ったGitLab Runnerのインストール

GitLab Runner は GitLab CI/CD を利用して.gitlab/managed-apps/config.yamlで設定を定義してインストールします。

GitLab CI/CDを使用してGitLab Runnerをインストールするには、以下の設定が必要です： 

gitlabRunner:
  installed: true

GitLab Runner はクラスターのgitlab-managed-apps 名前空間にインストールされます。

GitLab Runnerを機能させるには、以下を指定する必要があります：

  • gitlabUrl - Runnerを登録するGitLabサーバーの完全なURL（例えば、https://example.gitlab.com）。
  • runnerRegistrationToken - GitLab に新しい Runner を追加するための登録トークン。 GitLab インスタンスから取得する必要があります。

これらの値はCI変数を使って指定することができます：

  • GITLAB_RUNNER_GITLAB_URL はgitlabUrlに使用されます。
  • GITLAB_RUNNER_REGISTRATION_TOKEN に使用されます。runnerRegistrationToken

クラスター管理プロジェクトで.gitlab/managed-apps/gitlab-runner/values.yaml ファイルを定義することで、GitLab Runner のインストールをカスタマイズできます。 利用可能な設定オプションについては、チャートを参照してください。

注：Runner管理アプリケーションのインストールに関するサポートはGitLab Runnerグループによって提供されています。 不明な問題が発生した場合は、新しいイシューを開き、Runnerグループから少なくとも2人にpingを送信してください。

GitLab CI/CDを使ったCiliumのインストール

GitLab 12.8で導入されました。

Ciliumは、NetworkPolicyリソースのサポートを実装するために使用できるKubernetes用のネットワーキングプラグインです。 詳細については、ネットワークポリシーを参照してください。

概要については、GitLab 12.8のコンテナネットワークセキュリティデモをご覧ください。

インストールするには、.gitlab/managed-apps/config.yaml ファイルで Cilium を有効にしてください： 

# possible values are gke, eks or you can leave it blank
clusterType: gke

cilium:
  installed: true

clusterType 変数は、対応するクラスタタイプの推奨 Helm 変数を有効にします。 デフォルト値は空白です。各クラスタタイプの推奨変数は公式ドキュメントで確認できます：

クラスタ管理プロジェクトで.gitlab/managed-apps/cilium/values.yaml ファイルを定義することで、Cilium の Helm 変数をカスタマイズできます。 利用可能な設定オプションについては、Cilium のチャートを参照してください。

注意：Cilium のインストールと削除を行うには、影響を受けるすべてのネームスペースのポッドが正しいネットワーキング・プラグインによって管理されるように、手動で再起動する必要があります。
注：メジャーアップグレードの場合、追加のセットアップ手順が必要になる場合があります。詳細については、公式アップグレードガイドを参照してください。

デフォルトでは、Cilium はポリシーデプロイ時にすべての不許可パケットをドロップします。 しかし、auditmodeでは、Cilium は不許可パケットをドロップしません。policy-verdict ログを使用して、ポリシー関連の決定を観察できます。.gitlab/managed-apps/cilium/values.yamlに以下を追加することで、audit mode を有効にできます： 

config:
  policyAuditMode: true

agent:
  monitor:
    eventTypes: ["drop", "policy-verdict"]

トラフィックの Cilium モニターログは、cilium-monitor サイドカーコンテナによってログアウトされます。これらのログは、以下のコマンドで確認できます： 

kubectl -n gitlab-managed-apps logs cilium-XXXX cilium-monitor

.gitlab/managed-apps/cilium/values.yamlでモニターログを無効にすることができます： 

agent:
  monitor:
    enabled: false

Hubbleモニタリング・デーモンはデフォルトで有効になっており、ネームスペースごとのフロー・メトリクスを収集するように設定されています。 このメトリクスは、脅威モニタリング・ダッシュボードでアクセスできます。.gitlab/managed-apps/cilium/values.yamlに以下を追加することで、Hubble を無効にできます： 

global:
  hubble:
    enabled: false

ハッブルのHelm値は.gitlab/managed-apps/cilium/values.yamlからも調整できます： 

global:
  hubble:
    enabled: true
    metrics:
      enabled:
      - 'flow:sourceContext=namespace;destinationContext=namespace'
注：Cilium管理アプリケーションのインストールに関するサポートは、GitLabコンテナセキュリティグループによって提供されています。 不明な問題が発生した場合は、新しいイシューを開き、コンテナセキュリティグループから少なくとも2人にpingを送信してください。

GitLab CI/CDを使用したFalcoのインストール

GitLab 13.1で導入されました。

GitLab コンテナホストセキュリティモニタリングは、eBPF を使って Linux カーネルをリッスンするランタイムセキュリティツールとしてFalco を使っています。 Falco はシステムコールを解析し、設定可能なルールエンジンに対してリアルタイムでストリームをアサートします。 詳細については、Falco のドキュメントを参照してください。

ファルコは.gitlab/managed-apps/config.yaml ファイルで有効にできます： 

falco:
  installed: true

クラスター管理プロジェクトで.gitlab/managed-apps/falco/values.yaml ファイルを定義することにより、 Falco の Helm 変数をカスタマイズすることができます。 利用可能な設定オプションについては、Falco のチャートを参照してください。

注意:デフォルトではeBPFサポートが有効になっており、FalcoはeBPFプローブを使用してシステムコールをユーザ空間に渡します。 クラスターがこれをサポートしていない場合は、](https://falco.org/docs/event-sources/drivers/#using-the-ebpf-probe)に以下を追加することで、代わりにFalcoカーネルモジュールを使用するように設定できます：
ebpf:
  enabled: false

クラスターへのプローブの自動インストールが不可能な場合や、カーネル/プローブがプリコンパイルされていない場合は、手動でカーネルモジュールまたはeBPFプローブをdriverkitで準備し、各クラスターノードにインストールする必要があります。

デフォルトでは、Falco は限定されたルールセットとともにデプロイされています。 より多くのルールを追加するには、.gitlab/managed-apps/falco/values.yaml に以下を追加してください（Cloud Native Security Hubから例を得ることができます）： 

customRules:
  file-integrity.yaml: |-
    - rule: Detect New File
      desc: detect new file created
      condition: >
        evt.type = chmod or evt.type = fchmod
      output: >
        File below a known directory opened for writing (user=%user.name
        command=%proc.cmdline file=%fd.name parent=%proc.pname pcmdline=%proc.pcmdline gparent=%proc.aname[2])
      priority: ERROR
      tags: [filesystem]
    - rule: Detect New Directory
      desc: detect new directory created
      condition: >
        mkdir
      output: >
        File below a known directory opened for writing (user=%user.name
        command=%proc.cmdline file=%fd.name parent=%proc.pname pcmdline=%proc.pcmdline gparent=%proc.aname[2])
      priority: ERROR
      tags: [filesystem]

デフォルトでは、Falco はセキュリティイベントを JSON オブジェクトとしてログに出力するだけです。外部 APIまたはアプリケーションに出力するように設定するには、.gitlab/managed-apps/falco/values.yamlに以下を追加してください： 

falco:
  programOutput:
    enabled: true
    keepAlive: false
    program: mail -s "Falco Notification" someone@example.com

  httpOutput:
    enabled: true
    url: http://some.url

これらのログは以下のコマンドで確認できます： 

kubectl logs -l app=falco -n gitlab-managed-apps
注：Falco管理アプリケーションのインストールに関するサポートは、GitLabコンテナセキュリティグループによって提供されます。 不明な問題が発生した場合は、新しい問題を開き、コンテナセキュリティグループから少なくとも2人にpingを送信してください。

GitLab CI/CDを使ったVaultのインストール

GitLab 12.9で導入されました。

Hashicorp Vaultは、パスワード、クレデンシャル、証明書などを安全に管理・保管できるシークレット管理ソリューションです。 Vaultをインストールすることで、アプリケーションやGitLab CI/CDジョブなどで使用するクレデンシャルを安全に保管することができます。 また、インフラストラクチャ内のシステムやデプロイメントにSSL/TLS証明書を提供することもできます。 Vaultをこれらのクレデンシャルを管理する単一のソースとして活用することで、すべての機密クレデンシャルや証明書へのアクセス、管理、監査が可能になり、セキュリティが強化されます。

Vaultをインストールするには、.gitlab/managed-apps/config.yaml ファイルで有効にします： 

vault:
  installed: true

デフォルトでは、スケーラブルなストレージバックエンドを持たない基本的なVaultセットアップが提供されます。 これは、単純なテストや小規模なデプロイには十分ですが、スケーリングには限界があり、シングルインスタンスのデプロイであるため、Vaultアプリケーションのアップグレード時にダウンタイムが発生します。

本番環境でVaultを最適に使用するためには、Vaultの内部とその設定方法をよく理解していることが理想的です。 これは、VaultのドキュメントやVault Helm chartvalues.yaml ファイルを読むことで行うことができます。

最低限、セットアップすることになるでしょう：

以下は、Google Key Management Service の自動アンシール、Google Cloud Storage バックエンドの使用、Vault UI の有効化、および 3 つのポッドレプリカによる HA の有効化を設定する値ファイル (.gitlab/managed-apps/vault/values.yaml) の例です。storage およびseal のスタンザは例であり、ご使用の環境に固有の設定に置き換えてください。 

# Enable the Vault WebUI
ui:
  enabled: true
server:
  # Disable the built in data storage volume as it's not safe for Hight Availability mode
  dataStorage:
    enabled: false
  # Enable High Availability Mode
  ha:
    enabled: true
    # Configure Vault to listen on port 8200 for normal traffic and port 8201 for inter-cluster traffic
    config: |
      listener "tcp" {
        tls_disable = 1
        address = "[::]:8200"
        cluster_address = "[::]:8201"
      }
      # Configure Vault to store its data in a GCS Bucket backend
      storage "gcs" {
        path = "gcs://my-vault-storage/vault-bucket"
        ha_enabled = "true"
      }
      # Configure Vault to automatically unseal storage using a GKMS key
      seal "gcpckms" {
         project     = "vault-helm-dev-246514"
         region      = "global"
         key_ring    = "vault-helm-unseal-kr"
         crypto_key  = "vault-helm-unseal-key"
      }

Vaultのインストールに成功したら、Vaultを初期化して初期ルートトークンを取得する必要があります。 これを行うには、VaultがデプロイされたKubernetesクラスタにアクセスする必要があります。 Vaultを初期化するには、Kubernetes内で実行されているVaultポッドの1つにシェルを取得します（通常、これはkubectl コマンドラインツールを使用して行います）。ポッドにシェルを取得したら、vault operator init ： 

kubectl -n gitlab-managed-apps exec -it vault-0 sh
/ $ vault operator init

Vaultのライフサイクル全体を通して、これらのキーが必要になります。

注：Vault管理アプリケーションのインストールに関するサポートは、GitLabリリース管理グループによって提供されています。 不明な問題が発生した場合は、新しいイシューを開き、リリース管理グループの少なくとも2人にpingを送信してください。

GitLab CI/CDを使ったJupyterHubのインストール

GitLab 12.8で導入されました。

JupyterHubのインストールはGitLab CI/CDを利用し、.gitlab/managed-apps/config.yaml で以下のように設定を定義します： 

jupyterhub:
  installed: true
  gitlabProjectIdWhitelist: []
  gitlabGroupWhitelist: []

コンフィギュレーションでは

  • gitlabProjectIdWhitelist GitLab 認証を、指定したプロジェクトのメンバーだけに制限します。
  • gitlabGroupWhitelist GitLab 認証を指定したグループのメンバーのみに制限します。
  • 両方に空の配列を指定すると、GitLabインスタンス上のどのユーザーでもサインインできるようになります。

JupyterHubはクラスターのgitlab-managed-apps 名前空間にインストールされます。

JupyterHubを機能させるためには、OAuth Applicationを設定する必要があります。 設定を行います：

  • “Redirect URI” をhttp://<JupyterHub Host>/hub/oauth_callbackに。
  • “Scope” からapi read_repository write_repository。

また、CI変数を用いて以下の変数を指定する必要があります：

CI変数 説明
JUPYTERHUB_PROXY_SECRET_TOKEN ハブからの通信の署名に使用されるセキュア文字列。proxy.secretTokenを参照してください。
JUPYTERHUB_COOKIE_SECRET hub.cookieSecretを参照してください。
JUPYTERHUB_HOST インストールに使用するホスト名。例えば、jupyter.gitlab.example.com。
JUPYTERHUB_GITLAB_HOST 認証に使用するGitLabインスタンスのホスト名。インスタンスの例：gitlab.example.com.
JUPYTERHUB_AUTH_CRYPTO_KEY auth.state.cryptoKeyを設定するために使用される32バイトの暗号化キー。
JUPYTERHUB_AUTH_GITLAB_CLIENT_ID OAuth アプリケーションの “アプリケーション ID”。
JUPYTERHUB_AUTH_GITLAB_CLIENT_SECRET OAuthアプリケーションの “シークレット”。

デフォルトでは、JupyterHubはデフォルトの値ファイルを使ってインストールされます。クラスター管理プロジェクトで.gitlab/managed-apps/jupyterhub/values.yaml ファイルを定義することで、JupyterHubのインストールをカスタマイズできます。

利用可能な構成オプションについては、Chartリファレンスを参照してください。

注：JupyterHub管理アプリケーションのインストールに関するサポートはGitLab Configureグループによって提供されています。 不明な問題が発生した場合は、新しいイシューを開き、Configureグループの少なくとも2人にpingを送ってください。

GitLab CI/CDを使ったElastic Stackのインストール

GitLab 12.8で導入されました。

Elastic StackはGitLab CI/CDを利用して、.gitlab/managed-apps/config.yamlで設定を定義してインストールします。

GitLab CI/CDを使ってElastic Stackをインストールするには以下の設定が必要です： 

elasticStack:
  installed: true

Elastic Stackはクラスターのgitlab-managed-apps 名前空間にインストールされます。

このChartに設定したデフォルトのvalues.yaml 。

クラスター管理プロジェクトで.gitlab/managed-apps/elastic-stack/values.yaml ファイルを定義することで、Elastic Stackのインストールをカスタマイズできます。 利用可能な設定オプションについては、Chartを参照してください。

注意:CI経由でElastic Stackをインストールするこのアルファ版の実装では、Elasticsearch経由での環境ログの読み取りはサポートされていません。UI経由でインストールする場合はサポートされます。
注：Elastic Stack管理アプリケーションのインストールに関するサポートはGitLab APMグループによって提供されています。 不明な問題が発生した場合は、新しいイシューを作成し、APMグループの少なくとも2人にpingを送信してください。

GitLab CI/CDを使ったCrossplaneのインストール

GitLab 12.9で導入されました。

CrossplaneはGitLab CI/CDを使用して、.gitlab/managed-apps/config.yamlで設定を定義することでインストールされます。

GitLab CI/CDを使ってCrossplaneをインストールするには、以下の設定が必要です： 

Crossplane:
  installed: true

Crossplaneはクラスターのgitlab-managed-apps 名前空間にインストールされます。

このChartに設定したデフォルトのvalues.yaml。

クラスター管理プロジェクトで.gitlab/managed-apps/crossplane/values.yaml ファイルを定義することで、Crossplane のインストールをカスタマイズできます。 利用可能な設定オプションについては、Chartを参照してください。 このリンクは現在の開発リリースのドキュメントを指しており、インストールされているバージョンとは異なる場合があることに注意してください。

注：Crossplaneマネージド・アプリケーションのサポートは、Crossplaneチームによって提供されます。 イシューが発生した場合は、直接サポートチケットをご申請ください。

GitLab CI/CD を使った Fluentd のインストール

GitLab 12.10 で導入されました。

GitLab CI/CD を使ってクラスターのgitlab-managed-apps 名前空間に Fluentd をインストールするには、.gitlab/managed-apps/config.yamlに以下の設定を定義します： 

Fluentd:
  installed: true

このChartに設定されているデフォルト値は、values.yaml ファイルでレビューすることもできます。

クラスター管理プロジェクトで.gitlab/managed-apps/fluentd/values.yaml ファイルを定義することで、Fluentd のインストールをカスタマイズすることができます。 利用可能なオプションについては、Fluentd の現在の開発リリースの設定チャートを参照してください。

注意:設定Chartのリンクは現在の開発者リリースを指しており、インストールされているバージョンとは異なる場合があります。 互換性を確保するには、使用している特定のブランチまたはタグに切り替えてください。
注意:Fluentd 管理アプリケーションのインストールに関するサポートは GitLab コンテナセキュリティグループによって提供されています。 不明な問題が発生した場合は、新しいイシューを開き、コンテナセキュリティグループの少なくとも2人に ping を送ってください。

GitLab CI/CDを使ったKnativeのインストール

Knativeをインストールするには、.gitlab/managed-apps/config.yaml ： 

knative:
  installed: true

クラスター管理プロジェクトで.gitlab/managed-apps/knative/values.yamlファイルを定義することで、Knativeのインストールをカスタマイズできます。利用可能な設定オプションについては、Chartを参照してください。

Knativeの設定例です： 

domain: 'my.wildcard.A.record.dns'

GitLab Serverlessの機能を使用する予定がある場合は、カスタム設定でAレコードのワイルドカードドメインを必ず設定してください。

注：Knative管理アプリケーションのインストールに関するサポートはGitLab Configureグループによって提供されています。 不明な問題が発生した場合は、新しいイシューを開き、Configureグループの少なくとも2人にpingを送信してください。

メトリクス

GitLabは関数のInvocation Metricsを提供します。 これらのメトリクスを収集するには、以下のものが必要です：

  1. クラスターにインストールされたKnativeとPrometheusのマネージドアプリケーション。

  2. 以下のコマンドを実行して、手動でクラスターにカスタム・メトリクスを適用します： 

    kubectl apply -f https://gitlab.com/gitlab-org/cluster-integration/cluster-applications/-/raw/02c8231e30ef5b6725e6ba368bc63863ceb3c07d/src/default-data/knative/istio-metrics.yaml

Knativeのアンインストール

Knativeをアンインストールするには、まず以下のコマンドを実行して、追加したカスタム・メトリクスを手動で削除する必要があります： 

kubectl delete -f https://gitlab.com/gitlab-org/cluster-integration/cluster-applications/-/raw/02c8231e30ef5b6725e6ba368bc63863ceb3c07d/src/default-data/knative/istio-metrics.yaml

GitLab CI/CDを使用したAppArmorのインストール

GitLab 13.1で導入されました。

GitLab CI/CDを使用してAppArmorをクラスターのgitlab-managed-apps 名前空間にインストールするには、.gitlab/managed-apps/config.yaml.に以下の設定を定義します： 

apparmor:
  installed: true

1つまたは複数のAppArmorプロファイルを定義するには、以下のように.gitlab/managed-apps/apparmor/values.yaml ： 

profiles:
  profile-one: |-
    profile profile-one {
      file,
    }

このチャートの詳細については、AppArmorチャートを参照してください。

デプロイでのAppArmorプロファイルの使用

AppAmorをインストールした後、ポッドアノテーションを追加することでプロファイルを使用することができます。 Auto DevOpsを使用している場合、ポッドにアノテーションを付けるためにauto-deploy-values.yamlをカスタマイズすることができます。カスタム属性のリストを知っておくと便利ですが、podAnnotations を設定する必要があるのは以下のことだけです： 

podAnnotations:
  container.apparmor.security.beta.kubernetes.io/auto-deploy-app: localhost/profile-one

ここで変更する情報はプロファイル名のみで、この例ではprofile-one 。AppArmorがKubernetesにインテグレーションされる方法の詳細については、AppArmorチュートリアルを参照してください。

注：AppArmor管理アプリケーションのインストールに関するサポートは、GitLabコンテナセキュリティグループが提供しています。 不明な問題が発生した場合は、新しいイシューを開き、コンテナセキュリティグループの少なくとも2人にpingを送信してください。

アプリケーションのアップグレード

GitLab 11.8 で導入されました。

以下のアプリケーションはアップグレード可能です。

アプリケーション GitLabバージョン
Runner 11.8+

アプリケーションをアップグレードするには

  1. にとって：
  2. クラスターを選択します。
  3. アップグレードが可能な場合は、[アップグレード]ボタンが表示されます。 ボタンをクリックしてアップグレードします。
注：アップグレードを行うと、runnerのチャートに組み込まれた値にリセットされます。values.yaml

アプリケーションのアンインストール

GitLab 11.11で導入されました。

以下のアプリケーションはアンインストールできます。

アプリケーション GitLabバージョン 備考
サートマネージャー 12.2+ デプロイされたアプリケーションは HTTPS を使用し続けますが、証明書は更新されません。 アンインストールする前に、構成をバックアップするか、証明書を失効することをお勧めします。
GitLabランナー 12.2+ 実行中のパイプラインはすべてキャンセルされます。
Helm 12.2+ 関連する Tiller ポッド、gitlab-managed-apps 名前空間、およびそのリソースはすべて削除され、復元できません。
イングレス 12.1+ また、JupyterHubがインストールされていないとアンインストールできません。
ジュピターハブ 12.1+ GitLabにコミットされていないデータはすべて削除され、復元することはできません。
ナティブ 12.1+ 関連するIPは削除され、復元することはできません。
Prometheus 11.11+ すべてのデータは削除され、復元することはできません。
クロスプレーン 12.5+ すべてのデータは削除され、復元することはできません。
弾性スタック 12.7+ すべてのデータは削除され、復元することはできません。
セントリー 12.6+ PostgreSQLの永続ボリュームは残りますので、手動で削除して完全にアンインストールする必要があります。

アプリケーションをアンインストールするには

  1. にとって：
  2. クラスターを選択します。
  3. アプリケーションのアンインストールボタンをクリックします。

すべてのアプリケーションのアンインストールのサポートは、順次展開される予定です。 進捗状況については、関連するエピックをご覧ください。

アプリケーションのトラブルシューティング

アプリケーションは以下のエラーで失敗することがあります： 

Error: remote error: tls: bad certificate

インストールエラーを避けるためです：

  • アプリケーションのインストールを開始する前に、GitLabサーバーとKubernetesクラスターの間で時刻が同期されていることを確認してください。

  • 証明書が同期されていないことを確認してください。 アプリケーションをインストールする際、GitLabはHelmがインストールされていない新しいクラスターを想定しています。

    証明書の一致は、kubectlで確認できます： 

     kubectl get configmaps/values-content-configuration-ingress -n gitlab-managed-apps -o \
 "jsonpath={.data['cert\.pem']}" | base64 -d > a.pem
 kubectl get secrets/tiller-secret -n gitlab-managed-apps -o "jsonpath={.data['ca\.crt']}" | base64 -d > b.pem
 diff a.pem b.pem

EKSクラスターへの管理アプリインストールエラー

AWS EKS上のマネージドクラスターを使用していて、マネージドアプリの一部がインストールできない場合は、ログの確認を検討してください。

以下のコマンドを実行することで、ログを確認することができます： 

kubectl get pods --all-namespaces
kubectl get services --all-namespaces

Failed to assign an IP address to container エラーが発生する場合は、AWS の設定で指定したインスタンスタイプが原因である可能性があります。 ノードの数とサイズが、これらのポッドを実行またはインストールするのに十分な IP アドレスを持たない可能性があります。

参考までに、すべての AWS インスタンス IP 制限は GitHub のAWS リポジトリにあります (InstanceENIsAvailableで検索)。