GitLab-Migrationsチャートの使用

migrationsサブチャートは、GitLabで使用されるデータベースのseed/移行を処理する単一のジョブを提供します。このチャートは、GitLab Railsコードベースを使用して実行されます。

ClickHouseが有効になっている場合、このサブチャートはClickHouseの移行も実行します。

移行後、このジョブはデータベースのアプリケーション設定も編集して、writes to authorized keys fileを無効にします。このチャートでは、承認済みキーファイルへの書き込みをサポートする代わりに、GitLab承認済みキーAPIとSSH AuthorizedKeysCommandの使用のみをサポートしています。

要件

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

もしClickHouseがインスタンスで有効になっている場合、このチャートもClickHouseに依存します。

設計上の選択肢

このmigrationsチャートは、チャートがインストールされるたびに、または新しいチャートバージョン 、appバージョン 、あるいは何らかの値が変更されてチャートがアップグレードされるたびに、新しい移行ジョブを作成します。

helm installとhelm upgradeを使ってこのチャートをインストールおよびアップグレードすると、このチャートによって作成されたジョブは、次のチャートアップグレードまでクラスター内にオブジェクトとして残ります。これは、移行ログを監視できるようにするためです。ログシッピングの何らかの形式が導入されれば、これらのオブジェクトの永続性について再検討できます。

デプロイがhelm templateおよびkubectl applyまたは同様のツールによって生成されたマニフェストを使用して行われる場合、古い移行ジョブオブジェクトはクラスターから削除されません。

このチャートで使用されているコンテナには、現在ここでは使用されていない追加の最適化機能がいくつかあります。主に、Railsアプリケーションを起動して確認する必要なく、移行が既に最新である場合に、移行の実行を素早くスキップする機能です。この最適化には、移行ステータスの永続化が必要です。現在、このチャートでは行っていません。将来的には、このチャートに移行ステータスに対するストレージサポートを導入する予定です。

設定

このmigrationsチャートは、外部サービスとチャート設定の2つの部分で設定されます。

インストールコマンドラインオプション

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

チャート設定例

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

extraEnvFrom

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

image.pullSecrets

pullSecretsを使用すると、プライベートレジストリに認証することで、ポッド用のイメージをプルできます。

プライベートレジストリとその認証方法に関する追加の詳細は、Kubernetesドキュメントで確認できます。

pullSecretsの使用例を以下に示します。

image:
  repository: my.migrations.repository
  pullPolicy: Always
  pullSecrets:
  - name: my-secret-name
  - name: my-secondary-secret-name

serviceAccount

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

affinity

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

このチャートのCommunity Editionの使用

デフォルトの場合、HelmチャートではGitLabのEnterprise Editionを使用します。必要に応じて、Community Editionを使用することもできます。2つのエディションの違いの詳細については、こちらをご覧ください。

Community Editionを使用するには、image.repositoryをregistry.gitlab.com/gitlab-org/build/cng/gitlab-toolbox-ceに設定します

外部サービス

Redis

redis:
  host: redis.example.com
  serviceName: redis
  port: 6379
  sentinels:
    - host: sentinel1.example.com
      port: 26379
  password:
    secret: gitlab-redis
    key: redis-password

host

使用するデータベースが格納されているRedisサーバーのホスト名。serviceNameの代わりとして省略できます。Redis Sentinelを使用する場合、host属性はsentinel.confで指定されたクラスター名に設定する必要があります。

serviceName

Redisデータベースを操作しているserviceの名前。これが存在し、hostが存在しない場合、チャートはhost値の代わりにサービスのホスト名（および現在の.Release.Name）をテンプレート処理します。これは、RedisをGitLabチャート全体の一部として使用する場合に便利です。これはredisにデフォルト設定されます。

port

Redisサーバーへの接続に使用するポート。6379がデフォルトです。

password

Redisのpassword属性には2つのサブキーがあります:

• secretは、イメージをプルするKubernetes Secretの名前を定義します
• keyは、上記のシークレット内のパスワードを含むキーの名前を定義します。

sentinels

sentinels属性は、Redis HAクラスターへの接続を可能にします。サブキーは各Sentinel接続を記述します。

• hostはSentinelサービスのホスト名を定義します
• portはSentinelサービスに接続するためのポート番号を定義し、26379にデフォルト設定されます

PostgreSQL

psql:
  host: psql.example.com
  serviceName: pgbouncer
  port: 5432
  database: gitlabhq_production
  username: gitlab
  preparedStatements: false
  password:
    secret: gitlab-postgres
    key: psql-password

host

使用するデータベースを持つPostgreSQLサーバーのホスト名。postgresql.install=true （デフォルトは非本番環境）の場合、これは省略できます。

serviceName

PostgreSQLデータベースを操作するサービスの名前。これが存在し、hostが存在しない場合、チャートはhost値の代わりにサービスのホスト名をテンプレート処理します。

port

PostgreSQLサーバーへの接続に使用するポート。5432がデフォルトです。

database

PostgreSQLサーバーで使用するデータベースの名前。デフォルトはgitlabhq_productionです。

preparedStatements

PostgreSQLサーバーとの通信時にプリペアドステートメントを使用するかどうか。falseがデフォルトです。

username

データベースへの認証に使用するユーザー名。これはgitlabにデフォルト設定されます

password

PostgreSQLのpassword属性には2つのサブキーがあります:

• secretは、プル元のKubernetes Secretの名前を定義します。
• keyは、上記のシークレット内のパスワードを含むキーの名前を定義します。

ClickHouse (オプション)

global:
  clickhouse:
    enabled: true
    main:
      url: https://clickhouse.example.com
      database: default
      username: default
      password:
        secret: gitlab-clickhouse-password
        key: main_password

もしClickHouseがインスタンスで有効になっている場合、このチャートはClickHouseデータベースの移行も実行します。ClickHouseの設定は、global.clickhouseキーの下に提供する必要があります。

main.url

ClickHouseインスタンスのURL。

main.database

ClickHouse内のデータベース名。

main.username

ClickHouseで認証するために使用するユーザー名。

main.password

ClickHouseのpassword属性には2つのサブキーが含まれます:

• secretは、イメージをプルするKubernetesシークレットの名前を定義します。
• keyは、上記のsecretシークレット内のパスワードを含むキーの名前を定義します。