GitLab-Gitalyチャートの使い方
gitaly
サブチャートはGitalyサーバーのデプロイ設定を提供します。
要件
このチャートは、GitLabチャートの一部として、またはこのチャートがデプロイされるKubernetesクラスターからアクセス可能な外部サービスとして提供されるWorkhorseサービスへのアクセスに依存します。
設計の選択
このチャートで使っているGitalyコンテナには、まだGitalyに移植されていないGitリポジトリに対するアクションを実行するためのGitLab Shellのコードベースも含まれています。GitalyコンテナにはGitLab Shellコンテナのコピーが含まれているので、このチャートではGitLab Shellを設定する必要があります。
設定
gitaly
Chartは、外部サービスとチャート設定の2つの部分で構成されます。
GitalyはデフォルトではGitLabチャートをデプロイする際にコンポーネントとしてデプロイされます。Gitalyを個別にデプロイする場合、global.gitaly.enabled
をfalse
に設定する必要があり、外部のGitalyドキュメントに記載されているように、追加の設定を行う必要があります。
インストールのコマンドラインオプション
以下の表は、--set
フラグを使用してhelm install
コマンドに提供できるすべての可能な Chart 設定です。
パラメータ | デフォルト | 説明 |
---|---|---|
annotations | ポッド注釈 | |
common.labels | {} | このChartで作成されたすべてのオブジェクトに適用される補助ラベル。 |
podLabels | ポッドラベルの補足。セレクタには使用されません。 | |
external[].hostname | - "" | 外部ノードのホスト名 |
external[].name | - "" | 外部ノードのストレージ名 |
external[].port | - "" | 外部ノードのポート |
extraContainers | 追加コンテナのリスト | |
extraInitContainers | 追加コンテナのリスト | |
extraVolumeMounts | 追加ボリュームマウントのリスト | |
extraVolumes | 作成する追加ボリュームのリスト | |
extraEnv | 公開する追加環境変数のリスト | |
extraEnvFrom | 公開する他のデータソースの追加環境変数のリスト | |
gitaly.serviceName | 生成されたGitalyサービスの名前。global.gitaly.serviceName を上書きし、デフォルトは<RELEASE-NAME>-gitaly
| |
gpgSigning.enabled | false | GitalyのGPG署名を使用する場合。 |
gpgSigning.secret | Gitaly GPG署名に使用するシークレットの名前。 | |
gpgSigning.key | GitalyのGPG署名キーを含むGPGシークレットのキー。 | |
image.pullPolicy | Always | Gitalyイメージプルポリシー |
image.pullSecrets | 画像リポジトリのシークレット | |
image.repository | registry.com/gitlab-org/build/cng/gitaly | Gitaly画像リポジトリ |
image.tag | master | Gitaly画像タグ |
init.image.repository | initContainer 画像 | |
init.image.tag | initContainer画像タグ | |
init.containerSecurityContext | initContainer コンテナ固有のsecurityContext | |
internal.names[] | - default | StatefulSet ストレージの順序付けられた名前 |
serviceLabels | {} | 補足サービスラベル |
service.externalPort | 8075 | Gitalyサービス公開ポートに追加します。 |
service.internalPort | 8075 | Gitaly内部ポート |
service.name | gitaly | Serviceオブジェクト内でGitalyがビハインドしているServiceポートの名前です。 |
service.type | ClusterIP | Gitalyサービスタイプ |
securityContext.fsGroup | 1000 | ポッドを起動するグループID |
securityContext.fsGroupChangePolicy | ボリュームの所有権と権限を変更するためのポリシー (Kubernetes 1.23 が必要) | |
securityContext.runAsUser | 1000 | ポッドを起動するユーザーID |
containerSecurityContext | Gitalyコンテナを起動するコンテナsecurityContextをオーバーライドします。 | |
containerSecurityContext.runAsUser | 1000 | Gitalyコンテナが起動される特定のセキュリティ・コンテキストの上書きを許可します。 |
tolerations | [] | ポッド割り当て用のトレラベル |
persistence.accessMode | ReadWriteOnce | Gitaly永続アクセスモード |
persistence.annotations | Gitaly永続性アノテーション | |
persistence.enabled | true | Gitaly持続有効フラグ |
persistence.matchExpressions | 結合するラベル表現 | |
persistence.matchLabels | ラベルの値にマッチしてバインド | |
persistence.size | 50Gi | Gitaly永続ボリュームサイズ |
persistence.storageClass | プロビジョニング用ストレージクラス名 | |
persistence.subPath | Gitaly永続ボリューム・マウント・パス | |
priorityClassName | Gitaly StatefulSet priorityClassName | |
logging.level | ログレベル | |
logging.format | json | ログのフォーマット |
logging.sentryDsn | Sentry DSN URL - Go サーバーからの例外 | |
logging.sentryEnvironment | ロギングに使われるSentry環境 | |
shell.concurrency[] | 各 RPC エンドポイントの同時実行数rpc とmaxPerRepo
| |
packObjectsCache.enabled | false | Gitalyパック・オブジェクト・キャッシュの有効化 |
packObjectsCache.dir | /home/git/repositories/+gitaly/PackObjectsCache | キャッシュファイルを保存するディレクトリ |
packObjectsCache.max_age | 5m | キャッシュエントリーの寿命 |
git.catFileCacheSize | Gitのcat-fileプロセスで使用されるキャッシュサイズ | |
git.config[] | [] | Gitコマンドを起動する際にGitalyが設定すべきGitの設定。 |
prometheus.grpcLatencyBuckets | Gitalyが記録するGRPCメソッド呼び出しのヒストグラムレイテンシに対応するバケット。入力として、文字列形式の配列(例えば、"[1.0, 1.5, 2.0]" )が必要です。 | |
statefulset.strategy | {} | StatefulSetによって利用される更新戦略を設定できます。 |
statefulset.livenessProbe.initialDelaySeconds | 30 | Liveness Probeが開始されるまでの遅延時間 |
statefulset.livenessProbe.periodSeconds | 10 | Livenessプローブの実行頻度 |
statefulset.livenessProbe.timeoutSeconds | 3 | Livenessプローブがタイムアウトした場合 |
statefulset.livenessProbe.successThreshold | 1 | 一度失敗したプローブが成功したとみなされるための最小連続成功回数 |
statefulset.livenessProbe.failureThreshold | 3 | 成功した後に失敗したとみなされるための連続した失敗の最小値 |
statefulset.readinessProbe.initialDelaySeconds | 10 | Readiness Probeが開始されるまでの遅延。 |
statefulset.readinessProbe.periodSeconds | 10 | Readinessプローブの実行頻度 |
statefulset.readinessProbe.timeoutSeconds | 3 | 準備完了プローブがタイムアウトした場合 |
statefulset.readinessProbe.successThreshold | 1 | Readinessプローブが失敗した後、成功したとみなされるための最小連続成功回数 |
statefulset.readinessProbe.failureThreshold | 3 | 成功した後、レディネス・プローブが失敗したとみなされるには、最低連続失敗回数が必要です。 |
metrics.enabled | false | メトリクスエンドポイントをスクレイピングのために利用可能にする場合 |
metrics.port | 9236 | メトリクス・エンドポイント・ポート |
metrics.path | /metrics | メトリクスエンドポイントパス |
metrics.serviceMonitor.enabled | false | Prometheus Operatorがメトリクスのスクレイピングを管理できるようにServiceMonitorを作成する必要がある場合、これを有効にすると、prometheus.io スクレイピング注釈が削除されることに注意してください。 |
metrics.serviceMonitor.additionalLabels | {} | ServiceMonitorに追加するラベル |
metrics.serviceMonitor.endpointConfig | {} | ServiceMonitorの追加エンドポイント設定 |
metrics.metricsPort |
廃止用途metrics.port
|
Chart設定例
extraEnv
extraEnv
を使用すると、ポッド内のすべてのコンテナで追加の環境変数を公開できます。
以下は、extraEnv
の使用例です:
extraEnv:
SOME_KEY: some_value
SOME_OTHER_KEY: some_other_value
コンテナを起動すると、環境変数が公開されていることが確認できます:
env | grep SOME
SOME_KEY=some_value
SOME_OTHER_KEY=some_other_value
追加EnvFrom
extraEnvFrom
を使用すると、ポッド内のすべてのコンテナで、他のデータソースからの追加の環境変数を公開することができます。
以下は、extraEnvFrom
の使用例です:
extraEnvFrom:
MY_NODE_NAME:
fieldRef:
fieldPath: spec.nodeName
MY_CPU_REQUEST:
resourceFieldRef:
containerName: test-container
resource: requests.cpu
SECRET_THING:
secretKeyRef:
name: special-secret
key: special_token
# optional: boolean
CONFIG_STRING:
configMapKeyRef:
name: useful-config
key: some-string
# optional: boolean
画像.pullSecrets
pullSecrets
を使用すると、非公開レジストリで認証してポッドのイメージをプルできるようになります。
非公開レジストリとその認証方法の詳細については、Kubernetesのドキュメントを参照してください。
以下はpullSecrets
image:
repository: my.gitaly.repository
tag: latest
pullPolicy: Always
pullSecrets:
- name: my-secret-name
- name: my-secondary-secret-name
許容範囲
tolerations
汚染されたワーカーノードでポッドのスケジューリングが可能
以下は、tolerations
の使用例です:
tolerations:
- key: "node_label"
operator: "Equal"
value: "true"
effect: "NoSchedule"
- key: "node_label"
operator: "Equal"
value: "true"
effect: "NoExecute"
注釈
annotations
では、Gitalyポッドに注釈を追加することができます。
以下は、annotations
の使用例です:
annotations:
kubernetes.io/example-annotation: annotation-value
priorityClassName
priorityClassName
は、GitalyポッドにPriorityClassを割り当てることができます。
以下は、priorityClassName
の使用例です:
priorityClassName: persistence-enabled
git.config
git.config
を使うと、Gitalyが生成するすべてのGitコマンドに設定を追加することができます。git-config(1)
に書かれている設定を、key
/value
のペアで受け取ります。
git:
config:
- key: "pack.threads"
value: 4
- key: "fsck.missingSpaceBeforeDate"
value: ignore
外部サービス
このChartはWorkhorseサービスに添付してください。
ワークホース
workhorse:
host: workhorse.example.com
serviceName: webservice
port: 8181
名前 | 種類 | デフォルト | 説明 |
---|---|---|---|
host | 文字列 | Workhorse サーバのホスト名。serviceName の代わりに省略することもできます。 | |
port | 整数 | 8181 | Workhorse サーバーに接続するポート。 |
serviceName | 文字列 | webservice | Workhorse サーバをオペレーションしているservice の名前。これが存在し、host が存在しない場合、Chart はhost の値の代わりにサービスのホスト名(と現在の.Release.Name )をテンプレート化します。WorkhorseをGitLabチャート全体の一部として使うときに便利です。 |
チャート設定
以下の値は、Gitalyポッドの設定に使用されます。
global.gitaly.authToken
の値から取得します。さらに、GitalyコンテナにはGitLab Shellのコピーがあり、設定することができます。ShellのauthTokenはglobal.shell.authToken
。Git リポジトリの永続化
このChartでは、PersistentVolumeClaimをプロビジョニングし、対応する永続ボリュームをGitリポジトリのデータ用にマウントします。これを動作させるには、Kubernetesクラスターで利用可能な物理ストレージが必要です。emptyDirを使いたい場合は、PersistentVolumeClaimを無効にしてください:persistence.enabled: false
.
volumeName
など)。特定のボリュームを参照する場合は、PersistentVolumeClaimを手動で作成する必要があります。VolumeClaimTemplate
は不変です。persistence:
enabled: true
storageClass: standard
accessMode: ReadWriteOnce
size: 50Gi
matchLabels: {}
matchExpressions: []
subPath: "data"
annotations: {}
名前 | 種類 | デフォルト | 説明 |
---|---|---|---|
accessMode | 文字列 | ReadWriteOnce | PersistentVolumeClaimで要求されたaccessModeを設定します。詳細はKubernetes Access Modes Documentationを参照してください。 |
enabled | ブール値 | true | リポジトリデータに PersistentVolumeClaims を使用するかどうかを設定します。false の場合、emptyDir ボリュームが使用されます。 |
matchExpressions | 配列 | バインドするボリュームを選択する際に照合するラベル条件オブジェクトの配列を受け付けます。これはPersistentVolumeClaim selector セクションで使用します。ボリュームのドキュメントを参照ください。 | |
matchLabels | マップ | バインドするボリュームを選択する際に照合するラベル名とラベル値の Map を受け付けます。これはPersistentVolumeClaim selector セクションで使用します。ボリュームのドキュメントを参照してください。 | |
size | 文字列 | 50Gi | データ永続化のために要求する最小ボリュームサイズ。 |
storageClass | 文字列 | 動的プロビジョニング用のボリュームクレームの storageClassName を設定します。未設定または NULL の場合、デフォルトのプロビジョナが使用されます。ハイフンを設定すると、動的プロビジョニングは無効になります。 | |
subPath | 文字列 | ボリューム・ルートではなく、マウントするボリューム内のパスを設定します。サブパスが空の場合はルートが使用されます。 | |
annotations | マップ | 動的プロビジョニングのためのVolume Claimのアノテーションを設定します。詳細はKubernetes Annotations Documentationを参照してください。 |
TLS上でのGitalyの実行
Gitalyは他のコンポーネントとのTLS通信をサポートしています。これはglobal.gitaly.tls.enabled
とglobal.gitaly.tls.secretName
の設定によって制御されます。TLS上でGitalyを実行するための手順に従ってください:
-
Helmチャートは、GitalyとTLSで通信するために証明書が提供されることを期待します。この証明書は、存在するすべてのGitalyノードに適用する必要があります。したがって、これらのGitalyノードのすべてのホスト名を、証明書のサブジェクト代替名(SAN) として追加する必要があります。
使用するホスト名を知るには、Toolbox ポッドの
/srv/gitlab/config/gitlab.yml
ファイルをチェックし、その中のrepositories.storages
キーで指定された様々なgitaly_address
フィールドをチェックしてください。kubectl exec -it <Toolbox pod> -- grep gitaly_address /srv/gitlab/config/gitlab.yml
-
作成した証明書を使ってk8s TLSシークレットを作成します。
kubectl create secret tls gitaly-server-tls --cert=gitaly.crt --key=gitaly.key
-
--set global.gitaly.tls.enabled=true
を渡して、Helmチャートを再デプロイします。
グローバルサーバーフック
Gitaly StatefulSetは、Globalサーバーフックをサポートしています。フックスクリプトはGitalyポッド上で実行されるため、Gitalyコンテナで利用可能なツールに限定されます。
フックはConfigMapsを使用して設定され、以下の値を適切に設定することで使用できます:
global.gitaly.hooks.preReceive.configmap
global.gitaly.hooks.postReceive.configmap
global.gitaly.hooks.update.configmap
ConfigMapを生成するには、kubectl
スクリプトのディレクトリを指定します:
kubectl create configmap MAP_NAME --from-file /PATH/TO/SCRIPT/DIR
GitLab が作成した GPG 署名コミット
Gitalyには、WebIDEなどのGitLab UI経由で作成されたすべてのコミットや、マージコミットやスクワッシュなどのGitLabで作成されたコミットにGPG署名する機能があります。
-
GPG秘密鍵を使ってk8s秘密鍵を作成します。
kubectl create secret generic gitaly-gpg-signing-key --from-file=signing_key=/path/to/gpg_signing_key.gpg
-
values.yaml
でGPG署名を有効にしてください。gitlab: gitaly: gpgSigning: enabled: true secret: gitaly-gpg-signing-key key: signing_key