部署 Python 仓库

Python 库和工具

我们使用 poetry 将库和工具部署到 pypi，使用 gitlab 用户。在 pyproject.toml 文件中配置部署：

[tool.poetry]
name = "gitlab-<your package name>"
version = "0.1.0"
description = "<Description of your library/utility>"
authors = ["gitlab"]
readme = "README.md"
packages = [{ include = "<your module>" }]
homepage = ""https://gitlab.com/gitlab/<path/to/repository>"
repository = "https://gitlab.com/gitlab/<path/to/repository>"

有关更多配置选项，请参考 poetry 的文档。

配置 PyPI 包的部署：

1. 使用在 1Password 中找到的 “PyPI GitLab” 凭据 登录 PyPI（目前 PyPI 不支持组织）。

2. 在 账户设置 > 添加 API 令牌 下创建一个令牌。

3. 对于首次发布，选择 整个账户（所有项目） 范围。如果项目已存在，则将令牌范围限定到特定项目。

4. 配置凭据：

   本地：

   poetry config pypi-token.pypi <your-api-token>

   使用 CI 配置部署时，将 POETRY_PYPI_TOKEN_PYPI 设置为创建的令牌。或者，为项目定义一个 可信发布者，这样就不需要令牌了。

5. 使用 Poetry 发布 你的包：

   poetry publish

Python 服务

为 .com 部署 Runway

使用 CloudConnect 的 GitLab.com、GitLab Dedicated 和自托管客户的服务使用 Runway 部署。有关如何添加或管理 Runway 服务的详细信息，请参阅项目文档。

在自托管环境中部署

将服务部署到自托管环境存在挑战，因为服务不是单体架构的一部分。目前，Runway 不支持自托管实例，Omnibus 也不支持 Python 服务，因此部署只能通过用户拉取服务镜像来实现。

镜像指南

1. 使用不同于 root 用户的用户
2. 正确配置 poetry 变量以避免运行时问题
3. 使用 多阶段 Docker 构建 镜像来创建更轻量的镜像

镜像示例

版本控制

自托管客户需要知道哪个版本的服务与其 GitLab 安装兼容。Python 服务不使用 托管版本控制，因此每个服务都需要处理自己的版本控制和发布。

如果服务可以通过 cloud-connector 访问，它必须遵循 GitLab 支持声明，为当前和前两个主要版本的 GitLab 提供稳定的部署。

提示

创建与 GitLab 版本匹配的版本

在支持自托管部署时，拥有一个与 GitLab 版本匹配的版本标签很重要，这样用户就能更轻松地配置其环境的不同组件。在 GitLab 发布过程中添加一个管道，使用相同的标签标记服务仓库，这将触发一个管道来创建带有定义标签的镜像。

示例：GitLab 上的一个管道 在 AI Gateway 上创建一个标签，该标签 发布新镜像。

多版本部署

支持 3 个主要版本可能会导致代码库混乱，因为代码路径太多。一种既能保持支持又能允许代码清理的替代方案是为服务的多个版本提供部署。例如，假设 GitLab 版本是 19.5，这将需要三个服务部署：

• 一个用于服务版本 17.11，支持所有 GitLab 17.x 版本
• 一个用于服务版本 18.11，支持所有 GitLab 18.x 版本
• 一个用于服务版本 19.5，支持 GitLab 版本 19.0-19.5。

一旦版本 18.0 发布，就可以安全地移除 17.x 版本中未使用的代码，因为会有遗留部署。然后，一旦版本 20.0 发布，并且不再支持 GitLab 版本 17.x，遗留部署也可以被移除。

发布镜像

镜像必须发布在项目的容器注册表中。

也建议在 DockerHub 上发布镜像。要在 Docker Hub 上创建镜像仓库，使用您的 GitLab 用户名创建一个账户，并创建访问请求以添加到 GitLab 组织。镜像仓库创建后，确保用户 gitlabcibuild 对该仓库有读写权限。

Linux 包部署

待补充。

在 GitLab Dedicated 上部署

目前不支持在 GitLab Dedicated 上部署 Python 服务