• 要件
• デザインの選択
• 設定
• インストールコマンドラインオプション
• チャート構成例
  • エクストラエンバイロメント
  • 画像.pullSecrets
• このChartのコミュニティ版を使って
• 外部サービス
  • Redis
    • ホスト
    • サービス名
    • ポート
    • パスワード
    • 衛兵
  • PostgreSQL
    • ホスト
    • サービス名
    • ポート
    • データベース
    • ステートメント
    • ユーザー名
    • パスワード

GitLab-Migrationsチャートの使い方

migrations サブチャートは GitLab データベースのシード/マイグレーションを行う単一のマイグレーションジョブを提供します。 このチャートは GitLab Rails コードベースを使って実行されます。

移行後、このジョブはデータベースのアプリケーション設定を編集し、認証鍵ファイルへの書き込みをオフにします。Chartでは認証鍵ファイルへの書き込みをサポートする代わりに、SSHAuthorizedKeysCommand でのGitLab Authorized Keys APIの使用のみをサポートしています。

要件

このチャートはRedisとPostgreSQLに依存しており、GitLabチャートの一部として、あるいはこのチャートがデプロイされているKubernetesクラスターからアクセス可能な外部サービスとして提供されています。

デザインの選択

migrations はチャートがデプロイされるたびに新しい migrationsジョブを作成します。 ジョブ名の衝突を防ぐために、チャートのリビジョンと、作成されるたびにランダムな英数字をジョブ名に付加します。 ランダムなテキストの目的についてはこのセクションで詳しく説明します。

今のところ、ジョブが完了した後もオブジェクトとしてクラスターに残るようにしています。 これはマイグレーションログを観察するためです。現在のところ、これらのジョブはhelm uninstallの後でも残ります。 これはジョブ名にランダムなテキストを付加する理由の1つで、同じリリース名を使用する将来のデプロイがコンフリクトを引き起こさないようにするためです。 ある形式のログシッピングを導入したら、これらのオブジェクトの永続性を再検討することができます。

このChartで使用しているコンテナには、現在このChartでは使用していない追加の最適化があります。 主に、マイグレーションがすでに最新であれば、railsアプリケーションを起動して確認しなくても、実行中のマイグレーションをすばやくスキップする機能です。 この最適化には、マイグレーションステータスを永続化する必要があります。 現時点ではこのChartでは行っていません。 将来的には、このChartにマイグレーションステータスのストレージサポートを導入する予定です。

設定

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

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

以下の表は、--set フラグを使用して、helm install コマンドに供給可能なすべてのチャート・コンフィギュレーションです。

チャート構成例

エクストラエンバイロメント

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

画像.pullSecrets

pullSecrets を使うと、非公開レジストリで認証してポッドのイメージを取り出せるようになります。

非公開レジストリとその認証方法についての詳細は、Kubernetesのドキュメントに記載されています。

以下はpullSecretsの使用例です：

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

このChartのコミュニティ版を使って

デフォルトでは、HelmチャートはGitLabのEnterprise Editionを使用します。 必要であれば、代わりにCommunity Editionを使用することもできます。両者の違いについてはこちらをご覧ください。

Community Editionを使用するには、image.repository 。registry.gitlab.com/gitlab-org/build/cng/gitlab-task-runner-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

ホスト

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

サービス名

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

ポート

Redis サーバーに接続するポート。デフォルトは6379です。

パスワード

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

• secret からプルするKubernetesSecret の名前を定義します。
• key はパスワードを含む上記の秘密のキーの名前を定義します。

衛兵

sentinels 属性はRedis HAクラスターへの接続を許可します。 サブキーは各Sentinel接続を説明します。

• host Sentinelサービスのホスト名を定義します。
• port は、Sentinelサービスにアクセスするためのポート番号を定義します。26379

_注意:_現在のRedis Sentinelサポートは、GitLabチャートとは別にデプロイされたSentinelのみをサポートしています。 そのため、GitLabチャートを介したRedisのデプロイは、redis.install=false。 Redisのパスワードを含むシークレットは、GitLabチャートをデプロイする前に手動で作成する必要があります。

PostgreSQL

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

ホスト

使用するデータベースがある PostgreSQL サーバのホスト名です。postgresql.install=true の場合は省略可能です（デフォルトは non-production）。

サービス名

PostgreSQLデータベースをオペレーションしているサービスの名前です。 これが存在し、かつhost 存在しない場合、Chartは host値のhost 代わりにサービスのホスト名をテンプレート化 hostします。

ポート

PostgreSQL サーバに接続するポート。 デフォルトは5432です。

データベース

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

ステートメント

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

ユーザー名

データベースを認証するユーザー名。 デフォルトはgitlab

パスワード

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

• secret からプルするKubernetesSecret の名前を定義します。
• key はパスワードを含む上記の秘密のキーの名前を定義します。