- アプリケーションのインストール
-
GitLab CI/CDを使ったインストール(アルファ版)
- 使用方法
- 重要な注意事項
- GitLab CI/CDを使ったIngressのインストール
- GitLab CI/CDを使ったcert-managerのインストール
- GitLab CI/CDを使ったSentryのインストール
- GitLab CI/CDを使ったPostHogのインストール
- GitLab CI/CDを使ったPrometheusのインストール
- GitLab CI/CDを使ったGitLab Runnerのインストール
- GitLab CI/CDを使ったCiliumのインストール
- GitLab CI/CDを使用したFalcoのインストール
- GitLab CI/CDを使ったVaultのインストール
- GitLab CI/CDを使ったJupyterHubのインストール
- GitLab CI/CDを使ったElastic Stackのインストール
- GitLab CI/CDを使ったCrossplaneのインストール
- GitLab CI/CD を使った Fluentd のインストール
- GitLab CI/CDを使ったKnativeのインストール
- GitLab CI/CDを使用したAppArmorのインストール
- アプリケーションのアップグレード
- アプリケーションのアンインストール
- アプリケーションのトラブルシューティング
GitLabマネージドアプリ
GitLabは、設定したクラスターに直接追加できる様々なアプリをワンクリックでインストールできるGitLab Managed Appsを提供しています。
これらのアプリケーションは、Auto DevOpsを使用する際のレビューアプリとデプロイに必要です。
クラスターを作成した後にインストールできます。
アプリケーションのインストール
GitLabによって管理されるアプリケーションはgitlab-managed-apps
ネームスペースにインストールされます。
この名前空間:
- プロジェクトのデプロイに使用されるネームスペースとは異なります。
- 作成は一度だけ。
- 設定不可能な名前。
インストール可能なアプリケーションの一覧を表示するには、以下の手順に従います:
- プロジェクトレベルのクラスターは、プロジェクトの Operations > Kubernetesに移動します。
- グループレベルのクラスターでは、グループの Kubernetesページに移動します。
インストールできるアプリケーションは以下の通りです:
Knativeを除き、アプリケーションはgitlab-managed-apps
という専用の名前空間にインストールされます。
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アプリケーションをインストールする必要はなく、アプリケーションのリストにも表示されません。
ローカルティラーの有効/無効
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以降では、jetstack/cert-managerのChartを
values.yaml
。 - GitLab 12.2以前では、stable/cert-managerチャートを使用しました。
GitLab 12.3より前にcert-managerをインストールしている場合、Let’s Encryptは古いバージョンのcert-managerからのリクエストをブロックします。
これを解決するには
- cert-managerをアンインストールします(追加設定をバックアップすることを検討してください)。
- 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-runner
Chartが使用されます。は事前に設定された](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です。
ウェブアプリケーションを公開するためには、まずロードバランサに関連付けられた IP アドレスかホスト名となるエンドポイントを見つける必要があります。
インストールするには、IngressのInstallボタンをクリックしてください。 GitLabが外部エンドポイントの決定を試み、数分以内に利用可能になるはずです。
外部エンドポイントの自動決定
GitLab 10.6で導入されました。
Ingressのインストール後、外部エンドポイントは数分以内に利用可能になるはずです。
KUBE_INGRESS_BASE_DOMAIN
環境変数を使用してAuto DevOps ベースドメインに使用できます。エンドポイントが表示されず、クラスターがGoogle Kubernetes Engine上で動作している場合:
- GoogleKubernetes Engine上のKubernetesクラスターをチェックし、そのノードにエラーがないことを確認します。
- Google Kubernetes Engineに十分なQuotasがあることを確認してください。 詳細については、リソースQuotasを参照してください。
- GoogleCloudのステータスを確認し、障害が発生していないことを確認してください。
インストールが完了すると、クラウドプロバイダーによっては “Ingress IP Address” の?
が表示されることがあります。 EKS の場合は特に、ELB が IP アドレスではなく DNS 名で作成されるためです。 GitLab が Ingress または Knative アプリケーションのエンドポイントをまだ特定できない場合は、手動で特定することができます。
stable/nginx-ingress
Chartは、このアプリケーションを](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} '
%
。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 のルールエンジンを無効にすることができます:
-
デプロイ変数
AUTO_DEVOPS_MODSECURITY_SEC_RULE_ENGINE
をOff
に設定します。 これにより ModSecurity は指定されたアプリケーションや環境に対するリクエストを処理できなくなります。 -
それぞれのトグルを無効の位置に切り替え、変更を保存ボタンで適用します。 これでIngressが最近の変更で再インストールされます。
ロギングとブロックモード
WAFルールを調整するために、WAFをグローバルにログまたはブロックモードに設定することができます:
- ログモード- ルールに一致するトラフィックの通過を許可し、イベントをログに記録します。
- ブロックモード- ルールに一致するトラフィックの通過を阻止し、イベントをログに記録します。
WAFのモードを変更するには:
- まだインストールしていない場合は、ModSecurityをインストールしてください。
- cloud-gear} Operations >Kubernetesに移動します。
- アプリケーションで、Ingressまでスクロールします。
- グローバル・デフォルト(Global default)]で、希望のモードを選択します。
- 変更を保存する]をクリックします。
WAFのバージョン更新
ModSecurityのロギングモードの有効化、無効化、変更は、将来のリリースで克服されるかもしれないHelmの制限のため、同じバージョンのIngressでのみ許可されています。
デプロイされたバージョンが GitLab で利用可能なものと異なる場合、ModSecurityUI コントロールは無効になりますが、アンインストールなどのIngressレベルでのアクションは実行できます:
Ingressを最新バージョンにアップデートすることで、バグフィックス、セキュリティフィックス、パフォーマンス改善を利用することができます。Ingressアプリケーションをアップデートするには、まずアンインストールし、ModSecurityのインストールで説明されているように再インストールする必要があります。
Webアプリケーションファイアウォールのトラフィックの表示
GitLab Ultimate12.9で導入されました。
Web Application Firewall のトラフィックは、プロジェクトの [Security& Compliance] > [Threat Monitoring]ページで確認できます。
そこから経年変化を見ることができます:
- アプリケーションへの総トラフィック量。
- Web Application Firewall のデフォルトのOWASP ルールセットで異常とみなされるトラフィックの割合。
トラフィックのかなりの割合が異常である場合、潜在的な脅威がないか調査する必要があります。これは、Web アプリケーション・ファイアウォールのログを調べることで可能です。
ジュピターハブ
- GitLab 11.0でプロジェクトレベルのクラスターに導入されました。
- GitLab 12.3でグループとインスタンスレベルのクラスターに導入されました。
JupyterHubは、チーム全体でノートブックを管理するためのマルチユーザーサービスです。Jupyter Notebooksは、データ分析、可視化、機械学習に使用されるWebベースのインタラクティブなプログラミング環境を提供します。
認証は、プロジェクト・レベルのクラスターではプロジェクト・メンバ、グループ・レベルのクラスターではグループ・メンバで、関連するプロジェクトまたはグループに対して開発者以上のアクセス権を持つ場合にのみ有効になります。
また、NurtchのRubixライブラリで構築された、すぐに使えるDevOps Runbookもご覧いただけます。
実行可能なランブックの作成に関する詳細は、Runbooksドキュメントを参照してください。 JupyterHubをインストールする前に、Ingressがインストールされ、IPアドレスが割り当てられている必要があることに注意してください。
jupyter/jupyterhub
Chartは、このアプリケーションを](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のコマンドラインプロンプトから発行できます。
リポジトリはJupyterのファイルタブからクローンできます:
ナティブ
- GitLab 11.5でプロジェクトレベルのクラスターに導入されました。
- GitLab 12.3で導入された、グループとインスタンスレベルのクラスター。
Knativeは、Kubernetesクラスターからサーバーレスワークロードを作成、デプロイ、管理するためのプラットフォームを提供します。Istioと組み合わせて使用され、Knativeがホストするすべてのプログラムに外部IPアドレスを提供します。
アプリケーションを公開するワイルドカードドメインを入力するプロンプトが表示されます。 そのドメインの外部IPアドレスを使用するようにDNSサーバを設定します。 作成されインストールされたアプリケーションは、<program_name>.<kubernetes_namespace>.<domain_name>
としてアクセスできるようになります。 このためには、KubernetesクラスターでRBACが有効になっている必要があります。
knative/knative
Chartはこのアプリケーションのインストールに使用します。Prometheus
- GitLab 10.4でプロジェクトレベルのクラスターに導入されました。
- GitLab 11.11でグループレベルのクラスターに導入されました。
Prometheusは、デプロイされたアプリケーションを監視するのに便利なオープンソースの監視およびアラートシステムです。
GitLabはPrometheusインテグレーションを利用して、アプリケーションを自動的に監視することができます。 KubernetesコンテナのCPUとメモリのメトリクスが自動的に収集され、NGINX Ingressからもレスポンスのメトリクスが取得されます。
監視を有効にするには、インストールボタンでクラスターにPrometheusをインストールするだけです。
stable/prometheus
Chartは、このアプリケーションを](https://gitlab.com/gitlab-org/gitlab/blob/master/vendor/prometheus/values.yaml)ファイルでインストールする場合に使用します。クロスプレーン
- GitLab 12.5でプロジェクトレベルのクラスターに導入されました。
Crossplaneは、複数のクラウドにまたがるアプリケーションやインフラストラクチャを管理するのに便利なマルチクラウドのコントロールプレーンです。 Kubernetes APIを使用して拡張します:
- カスタムリソース。
- これらのカスタムリソースを監視するコントローラ。
Crossplaneは、クラウドプロバイダー固有の設定を抽象化することで、クラウドプロバイダー間で統一された方法でインフラストラクチャ・コンポーネントのプロビジョニングとライフサイクル管理を可能にします。
Crossplane GitLabが管理するアプリケーション:
- プロジェクトリポジトリに接続されたKubernetesクラスターに、任意のプロバイダーでCrossplaneをインストールします。
- その後、Auto DevOpsパイプラインを介して、PostgreSQL(GCPのCloudSQLやAWSのRDSなど)やアプリケーションに必要なその他のサービスなどのインフラストラクチャやマネージドアプリケーションのプロビジョニングに使用できます。
クラスターにインストールされたCrossplaneの設定については、「Crossplaneの設定」を参照してください。
alpha/crossplane
chart v0.4.1を使用します。弾性スタック
GitLab 12.7でプロジェクトレベル、グループレベルのクラスターに導入されました。
Elastic Stackは、様々なマシンから生成されたログの詳細な検索、分析、可視化を支援する、完全なエンドツーエンドのログ分析ソリューションです。
GitLabはクラスタ内のポッドからログを自動的に収集することができます。 Filebeatはクラスタ内の各ノードでDaemonSetとして実行され、クエリ用にコンテナログをElasticsearchに送信します。 GitLabはKubernetes APIの代わりにElasticsearchにログを接続し、より高度なクエリ機能を利用できるようになります。
ログデータはCuratorを使用して30日後に自動的に削除されます。
ログ配送を有効にするには
- クラスターに
f1-micro
,g1-small
,n1-standard-1
よりも大きいインスタンス・タイプのノードが少なくとも3つ含まれていることを確認してください。 - cloud-gear} Operations >Kubernetesに移動します。
- Kubernetes Clusterで、クラスターを選択します。
- アプリケーションセクションでElastic Stackを探し、インストールをクリックします。
gitlab/elastic-stack
Chartは、このアプリケーションを](https://gitlab.com/gitlab-org/gitlab/blob/master/vendor/elastic_stack/values.yaml)ファイルでインストールする場合に使用します。f1-micro
,g1-small
,n1-standard-1
,*-highcpu-2
インスタンスタイプで構成されるクラスターとは互換性がありません。オプション:高度なクエリを実行するために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を有効にするには
- cloud-gear}オペレーション>Kubernetesに移動し、アプリケーションをクリックします。 syslog経由でWAFログを送信するホスト、ポート、プロトコルを入力するよう求められます。
- SIEM Hostnameにホストドメイン名またはURLを入力します。
- SIEM Portにホストポート番号を入力します。
- SIEMプロトコルを選択します。
- 利用可能なログ(WAFやCiliumなど)の少なくとも1つを選択します。
- 変更を保存する]をクリックします。
未来のアプリ
新しいGitLab管理アプリに貢献することに興味がありますか?開発ガイドラインのページをご覧ください。
GitLab CI/CDを使ったインストール(アルファ版)
GitLab 12.6 で導入されました。
この代替方法では、GitLab CI/CDを使ってGitLabが管理するアプリケーションをインストールすることができます。また、Helmvalues.yaml
ファイルを使ってインストールをカスタマイズすることもできます。
対応アプリケーション
使用方法
クラスター・アプリケーション・プロジェクトの例では、以下のすべてのファイルを参照し、インポートすることができます。
GitLab CI/CDを使ってアプリケーションをインストールするには:
- クラスターをクラスター管理プロジェクトに接続します。
-
そのプロジェクトに、以下の内容の
.gitlab-ci.yml
:include: - template: Managed-Cluster-Applications.gitlab-ci.yml
注意:このテンプレートで提供されるジョブは、カスタムDockerイメージで提供されるツールを使用してクラスターに接続します。 Docker、Kubernetes、またはDocker Machineのexecutorにランナーを登録しておく必要があります。 -
.gitlab/managed-apps/config.yaml
ファイルを追加し、インストールするアプリケーションを定義します。installed
キーを、アプリケーションをインストールする場合はtrue
と定義し、アプリケーションをアンインストールする場合はfalse
と定義します。 例えば、Ingress をインストールする場合:ingress: installed: true
- オプションで、
.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を参照してください。
GitLab CI/CDを使ったcert-managerのインストール
cert-managerはGitLab CI/CDを利用して、.gitlab/managed-apps/config.yaml
で設定を定義してインストールします。
cert-manager:
- クラスターの
gitlab-managed-apps
名前空間にインストールされます。 - デフォルトのLet’s Encrypt
ClusterIssuer
の有無にかかわらずインストールできます。この場合、電子メールアドレスの指定が必要です。この電子メールアドレスは、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を参照してください。
GitLab CI/CDを使ったSentryのインストール
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.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
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.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
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 セクションを参照してください。
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 のインストールをカスタマイズできます。 利用可能な設定オプションについては、チャートを参照してください。
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 はポリシーデプロイ時にすべての不許可パケットをドロップします。 しかし、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'
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:
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
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
ファイルを読むことで行うことができます。
最低限、セットアップすることになるでしょう:
- マスターキーを暗号化するためのシール。
- 環境とストレージセキュリティの要件に適したストレージバックエンド。
- HAモード。
- ボールトのUI。
以下は、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のライフサイクル全体を通して、これらのキーが必要になります。
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リファレンスを参照してください。
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を参照してください。
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を参照してください。 このリンクは現在の開発リリースのドキュメントを指しており、インストールされているバージョンとは異なる場合があることに注意してください。
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 の現在の開発リリースの設定チャートを参照してください。
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レコードのワイルドカードドメインを必ず設定してください。
メトリクス
GitLabは関数のInvocation Metricsを提供します。 これらのメトリクスを収集するには、以下のものが必要です:
- クラスターにインストールされたKnativeとPrometheusのマネージドアプリケーション。
-
以下のコマンドを実行して、手動でクラスターにカスタム・メトリクスを適用します:
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チュートリアルを参照してください。
アプリケーションのアップグレード
GitLab 11.8 で導入されました。
以下のアプリケーションはアップグレード可能です。
アプリケーション | GitLabバージョン |
---|---|
Runner | 11.8+ |
アプリケーションをアップグレードするには
- にとって:
- プロジェクトレベルのクラスターは、プロジェクトのオペレーション>Kubernetesに移動します。
- グループレベルのクラスターは、グループのKubernetesページに移動します。
- クラスターを選択します。
- アップグレードが可能な場合は、[アップグレード]ボタンが表示されます。 ボタンをクリックしてアップグレードします。
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の永続ボリュームは残りますので、手動で削除して完全にアンインストールする必要があります。 |
アプリケーションをアンインストールするには
- にとって:
- プロジェクトレベルのクラスターは、プロジェクトのオペレーション>Kubernetesに移動します。
- グループレベルのクラスターは、グループのKubernetesページに移動します。
- クラスターを選択します。
- アプリケーションのアンインストールボタンをクリックします。
すべてのアプリケーションのアンインストールのサポートは、順次展開される予定です。 進捗状況については、関連するエピックをご覧ください。
アプリケーションのトラブルシューティング
アプリケーションは以下のエラーで失敗することがあります:
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
で検索)。