• 要求
• 设计选择
• 配置
• 安装命令行选项
• Chart 配置示例
  • extraEnv
  • extraEnvFrom
  • image.pullSecrets
• 外部服务
  • Redis
    • host
    • serviceName
    • port
    • password
    • sentinels
  • PostgreSQL
    • host
    • serviceName
    • port
    • database
    • preparedStatements
    • username
    • password

使用 GitLab-Migrations Chart

migrations 子 chart 提供了一个单一的迁移 Job，用于处理播种/迁移 GitLab 数据库。 该 chart 使用 GitLab Rails 代码库运行。

迁移后，此作业还会编辑数据库中的应用程序设置以关闭对授权密钥文件的写入。在 chart 中，我们仅支持将 GitLab 授权密钥 API 与 SSH AuthorizedKeysCommand 一起使用，而不支持写入授权密钥文件。

要求

该 chart 依赖于 Redis 和 PostgreSQL，作为完整 GitLab chart 的一部分或作为可从该图表部署到的 Kubernetes 集群访问的外部服务提供。

设计选择

每次部署 chart 时，migrations 都会创建一个新的迁移 Job。为了防止 job 名称冲突，我们在每次创建 job 名称时附加 chart 版本和随机字母数字值。本节将进一步描述随机文本的用途。

现在，我们还让 job 在完成后作为对象保留在集群中。 这样我们就可以观察迁移日志。目前，这意味着即使在 helm uninstall 之后，这些 job 仍然存在。 这是我们将随机文本附加到 Job 名称的原因之一，以便将来使用相同版本名称的部署不会导致冲突。 一旦我们有了某种形式的日志传送，我们就可以重新审视这些对象的持久化。

此 chart 中使用的容器具有一些我们当前未在此 chart 中使用的额外优化。主要是能够快速跳过正在运行的迁移（如果它们已经是最新的），而无需启动 rails 应用程序进行检查。 这种优化需要我们持久化迁移状态。 我们目前没有在此 chart 中这样做。 将来，我们将在此 chart 中引入对迁移状态的存储支持。

配置

migrations chart 配置为两部分：外部服务和 chart 设置。

安装命令行选项

下表包含可以使用 --set 标志提供给 helm install 命令的所有可能的 chart 配置

Chart 配置示例

extraEnv

extraEnv 允许您在 Pod 的所有容器中暴露额外的环境变量。

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 允许您从 pod 中的所有容器中的其它数据源，暴露其它环境变量。

下面是一个使用 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 允许您对私有仓库进行身份验证，以拉取 pod 的镜像。

有关私有仓库及其身份验证方法的其它详细信息，请参见 Kubernetes 文档。

下面是一个使用 pullSecrets 的例子：

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

外部服务

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 Sentinels，则需要将 host 属性设置为 sentinel.conf 中指定的集群名称。

serviceName

正在操作 Redis 数据库的 service 的名称。 如果它存在，而 host 不存在，chart 将服务的主机名（和当前的 .Release.Name）作为模板代替 host 值。当使用 Redis 作为整个 GitLab chart 的一部分时，这很方便。默认值为 redis。

port

连接到 Redis 服务器的端口。 默认为6379。

password

Redis 的 password 属性有两个子键：

• secret 定义了要拉取的 Kubernetes Secret 的名称
• key 定义了包含密码的上述 secret 中的 key 名称。

sentinels

sentinels 属性允许连接到 Redis HA 集群。 子键描述每个 Sentinel 连接。

• host 定义了 Sentinel 服务的主机名
• port 定义了到达 Sentinel 服务的端口号，默认为 26379

注意：目前 Redis Sentinel 只支持已经脱离 GitLab chart 单独部署的 Sentinel。因此，应使用 redis.install=false 禁用通过 GitLab chart 的 Redis 部署。 在部署 GitLab chart 之前，需要手动创建包含 Redis 密码的 Secret。

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 不存在，chart 将服务的主机名作为模板代替 host 值。

port

连接到 PostgreSQL 服务器的端口。默认为5432。

database

要在 PostgreSQL 服务器上使用的数据库的名称。默认为gitlabhq_production。

preparedStatements

与 PostgreSQL 服务器通信时是否应使用 preparedStatements。 默认为false。

username

用于对数据库进行身份验证的用户名。默认为gitlab。

password

PostgreSQL 的 password 属性有两个子键：

• secret 定义了要拉取的 Kubernetes Secret 的名称。
• key 定义了包含密码的上述 secret 中的 key 名称。