GitLab Pagesチャートの使用

gitlab-pagesサブチャートは、GitLabプロジェクトから静的ウェブサイトを提供するためのデーモンを提供します。

要件

このチャートは、完全なGitLabチャートの一部として、またはこのチャートがデプロイされるKubernetesクラスタから到達可能な外部サービスとして提供される、Workhorseサービスへのアクセスに依存します。

設定

gitlab-pagesチャートは、次のように設定されます: グローバル設定とチャートの設定。

グローバル設定

いくつかの一般的なグローバル設定は、チャート間で共有されます。詳細については、グローバルドキュメントを参照してください。

チャートの設定

以下の2つのセクションの表には、helm installフラグを使用して--setコマンドに指定できる、チャートのすべての可能な設定が含まれています。

一般設定

Pages固有の設定

ingressを設定する

このセクションでは、GitLab Pages Ingressを制御します。

チャート設定例

extraVolumes

extraVolumesを使用すると、チャート全体の追加ボリュームを設定できます。

extraVolumesの使用例を以下に示します:

extraVolumes: |
  - name: example-volume
    persistentVolumeClaim:
      claimName: example-pvc

extraVolumeMounts

extraVolumeMountsを使用すると、チャート全体のすべてのコンテナで追加のvolumeMountsを設定できます。

extraVolumeMountsの使用例を以下に示します:

extraVolumeMounts: |
  - name: example-volume
    mountPath: /etc/example

networkpolicyを設定する

このセクションでは、NetworkPolicyを制御します。この設定はオプションで、ポッドのエグレスとイングレスを特定エンドポイントに制限するために使用されます。

ネットワークポリシーの例

gitlab-pagesサービスには、ポート80および443のIngress接続と、デフォルトのworkhorseポート8181へのさまざまなエグレス接続が必要です。この例では、次のネットワークポリシーを追加します:

• Ingressリクエストを許可:
  • nginx-ingressポッドからポート8090へ
  • prometheusポッドからポート9235へ
• エグレスリクエストを許可:
  • kube-dnsのポート53へ
  • webserviceポッドからポート8181へ
  • S3のAWS VPCエンドポイントなどのエンドポイントから、ポート443の172.16.1.0/24へ

提供されている例は単なる例であり、完全ではない可能性があることに注意してください

この例は、kube-dnsがネームスペースkube-systemに、prometheusがネームスペースmonitoringに、nginx-ingressがネームスペースnginx-ingressにデプロイされたという前提に基づいています。

networkpolicy:
  enabled: true
  ingress:
    enabled: true
    rules:
      - from:
          - namespaceSelector:
              matchLabels:
                kubernetes.io/metadata.name: monitoring
            podSelector:
              matchLabels:
                app: prometheus
                component: server
                release: gitlab
        ports:
          - port: 9235
      - from:
          - namespaceSelector:
              matchLabels:
                kubernetes.io/metadata.name: nginx-ingress
            podSelector:
              matchLabels:
                app: nginx-ingress
                component: controller
        ports:
          - port: 8090
  egress:
    enabled: true
    rules:
      - to:
          - namespaceSelector:
              matchLabels:
                kubernetes.io/metadata.name: kube-system
            podSelector:
              matchLabels:
                k8s-app: kube-dns
        ports:
          - port: 53
            protocol: UDP
      - to:
          - ipBlock:
              cidr: 172.16.1.0/24
        ports:
          - port: 443
      - to:
          - podSelector:
              matchLabels:
                app: webservice
        ports:
          - port: 8181

GitLab PagesへのTLSアクセス

GitLab Pages機能へのTLSアクセスを実現するには、次の手順に従ってください:

1. この形式でGitLab Pagesドメイン専用のワイルドカード証明書を作成します: *.pages.<yourdomain>。

2. Kubernetesでシークレットを作成します:

   kubectl create secret tls tls-star-pages-<mysecret> --cert=<path/to/fullchain.pem> --key=<path/to/privkey.pem>

3. このシークレットを使用するようにGitLab Pagesを設定します:

   gitlab:
     gitlab-pages:
       ingress:
         tls:
           secretName: tls-star-pages-<mysecret>

4. *.pages.<yourdomaindomain>を指す名前で、DNSプロバイダーにDNSエントリを作成します。

ワイルドカードDNSのないPagesドメイン

1. グローバルなPages設定でnamespaceInPathを有効にします。

   global:
     pages:
       namespaceInPath: true

2. pages.<yourdomaindomain>という名前で、お使いのDNSプロバイダーにエントリを作成し、ロードバランサーを指すようにします。

ワイルドカードDNSなしのGitLab PagesドメインへのTLSアクセス

1. この形式で、GitLab Pagesドメインの証明書を作成します: pages.<yourdomain>。

2. Kubernetesでシークレットを作成します:

   kubectl create secret tls tls-star-pages-<mysecret> --cert=<path/to/fullchain.pem> --key=<path/to/privkey.pem>

3. このシークレットを使用するようにGitLab Pagesを設定します:

   gitlab:
     gitlab-pages:
       ingress:
         tls:
           secretName: tls-star-pages-<mysecret>

アクセス制御の設定

1. グローバルなPages設定でaccessControlを有効にします。

   global:
     pages:
       accessControl: true

2. オプション。TLSアクセスが構成されている場合は、GitLab PagesのシステムOAuthアプリケーションのリダイレクトURIを更新して、HTTPSプロトコルを使用してください。

レート制限

サービス拒否（DoS）攻撃のリスクを最小限に抑えるために、レート制限を適用できます。詳細なレート制限のドキュメントをご利用いただけます。

特定のIP範囲（サブネット）がすべてのレート制限を回避できるようにするには、次の手順に従います:

• rateLimitSubnetsAllowList: すべてのレート制限を回避させるIP範囲（サブネット）を指定する許可リストを設定します。

レート制限のサブネット許可リストを設定する

charts/gitlab/charts/gitlab-pages/values.yamlで、IP範囲（サブネット）を持つ許可リストを設定します:

gitlab:
  gitlab-pages:
    rateLimitSubnetsAllowList:
     - "1.2.3.4/24"
     - "2001:db8::1/32"

KEDAの設定

このkedaセクションでは、通常のHorizontalPodAutoscalersの代わりにKEDA ScaledObjectsのインストールを有効にします。この設定はオプションであり、カスタムまたは外部メトリクスに基づいてオートスケールが必要な場合に使用できます。

ほとんどの設定は、該当する場合、hpaセクションで設定された値にデフォルト設定されています。

以下が当てはまる場合、hpaセクションで設定されたCPUとメモリのしきい値に基づいて、CPUとメモリのトリガーが自動的に追加されます:

• triggersが設定されていません。
• 対応するrequest.cpu.requestまたはrequest.memory.request設定も、ゼロ以外の値に設定されます。

トリガーが設定されていない場合、ScaledObjectは作成されません。

これらの設定の詳細については、KEDAのドキュメントを参照してください。

serviceAccount

このセクションでは、ServiceAccountを作成する必要があるかどうか、およびデフォルトのアクセストークンをポッドにマウントする必要があるかどうかを制御します。

アフィニティ

詳細については、affinityを参照してください。