Python 라이브러리 및 유틸리티#

라이브러리와 유틸리티는 poetry를 사용하여 gitlab 사용자로 pypi에 배포합니다. pyproject.toml 파일에서 배포를 구성하세요:

[tool.poetry]
name = "gitlab-<your package name>"
version = "0.1.0"
description = ""
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 패키지 배포를 구성하려면:

• 1Password에서 찾을 수 있는 "PyPI GitLab" 자격 증명을 사용하여 PyPI에 인증합니다 (PyPI는 현재 조직을 지원하지 않습니다).

• Account Settings > Add API Tokens에서 토큰을 생성합니다.

• 초기 게시의 경우 Entire account (all projects) 범위를 선택합니다. 프로젝트가 이미 존재하는 경우 특정 프로젝트로 토큰 범위를 지정합니다.

• 자격 증명을 구성합니다:

로컬에서:

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

CI로 배포를 구성하려면 POETRY_PYPI_TOKEN_PYPI를 생성한 토큰으로 설정합니다. 또는 프로젝트에 trusted publisher를 정의하면 토큰이 필요하지 않습니다.

• Poetry를 사용하여 패키지를 게시합니다:

poetry publish

Python 서비스#

.com을 위한 Runway 배포#

GitLab.com, GitLab Dedicated 및 CloudConnect를 사용하는 self-hosted 고객을 위한 서비스는 Runway를 사용하여 배포됩니다. Runway 서비스를 추가하거나 관리하는 방법은 프로젝트 문서를 참고하세요.

self-hosted 환경에서의 배포#

서비스를 self-hosted 환경에 배포하는 것은 서비스가 모놀리스의 일부가 아니기 때문에 어려움이 있습니다. 현재 Runway는 self-hosted 인스턴스를 지원하지 않으며, Omnibus는 Python 서비스를 지원하지 않으므로 사용자가 서비스 이미지를 직접 pull하는 방식으로만 배포가 가능합니다.

이미지 가이드라인#

• root 사용자가 아닌 다른 사용자를 사용합니다

• 런타임 문제를 방지하기 위해 poetry 변수를 올바르게 구성합니다

• 더 가벼운 이미지를 만들기 위해 멀티스테이지 Docker 빌드 이미지를 사용합니다

이미지 예시

버전 관리#

self-hosted 고객은 어떤 버전의 서비스가 자신의 GitLab 설치와 호환되는지 알아야 합니다. Python 서비스는 managed versioning을 사용하지 않으므로 각 서비스는 자체 버전 관리와 릴리스 컷을 처리해야 합니다.

서비스가 cloud-connector를 통해 접근 가능한 경우, GitLab Statement Support를 준수해야 하며 현재 및 이전 2개의 주요 릴리즈 GitLab에 대한 안정적인 배포를 제공해야 합니다.

팁#

GitLab 릴리즈와 일치하는 버전 생성 self-hosted 배포를 지원할 때는 GitLab 버전과 일치하는 버전 태그를 갖는 것이 중요합니다. 이렇게 하면 사용자가 환경의 다양한 구성 요소를 더 쉽게 구성할 수 있습니다. 동일한 태그로 서비스 리포지터리에 태그를 지정하는 파이프라인을 GitLab 릴리즈 프로세스에 추가하면, 정의된 태그로 이미지를 생성하는 파이프라인이 트리거됩니다.

예시: GitLab의 파이프라인이 AI Gateway에 태그를 생성하여 새 이미지를 릴리스합니다.

여러 릴리즈 배포 3개의 주요 버전을 지원하면 너무 많은 코드 경로로 인해 코드베이스가 복잡해질 수 있습니다. 코드 정리를 허용하면서도 지원을 유지하는 대안은 여러 버전의 서비스 배포를 제공하는 것입니다. 예를 들어 GitLab이 버전 19.5에 있다면 다음과 같이 세 개의 서비스 배포가 필요합니다:

• 모든 GitLab 17.x 버전을 지원하는 서비스 버전 17.11을 위한 배포

• 모든 GitLab 18.x 버전을 지원하는 서비스 버전 18.11을 위한 배포

• GitLab 버전 19.0-19.5를 지원하는 서비스 버전 19.5를 위한 배포

버전 18.0이 릴리스되면, 레거시 배포가 존재하므로 버전 17.x의 사용되지 않는 코드를 안전하게 제거할 수 있습니다. 그런 다음 버전 20.0이 릴리스되고 GitLab 버전 17.x가 더 이상 지원되지 않으면 레거시 배포도 제거할 수 있습니다.

이미지 게시#

이미지는 프로젝트의 컨테이너 레지스트리에 게시되어야 합니다.

DockerHub에도 이미지를 게시하는 것을 권장합니다. Docker Hub에 이미지 리포지터리를 생성하려면 GitLab 핸들로 계정을 만들고 GitLab 조직에 추가되기 위한 Access Request를 생성합니다. 이미지 리포지터리가 생성되면 gitlabcibuild 사용자에게 리포지터리에 대한 읽기 및 쓰기 접근 권한이 있는지 확인하세요.

Linux 패키지 배포#

추가 예정.

GitLab Dedicated에서의 배포#

GitLab Dedicated에서의 Python 서비스 배포는 현재 지원되지 않습니다.