InfoGrab Docs

튜토리얼: 엔터프라이즈 규모에 맞는 패키지 레지스트리 구조화

요약

조직이 성장함에 따라 패키지 관리가 점점 복잡해질 수 있습니다. 이 튜토리얼에서는 GitLab 패키지 레지스트리 모델을 엔터프라이즈 그룹 구조에 통합하는 방법을 배울 것입니다. 이 튜토리얼을 마치면 다음을 알게 됩니다:

조직이 성장함에 따라 패키지 관리가 점점 복잡해질 수 있습니다. GitLab 패키지 레지스트리 모델은 엔터프라이즈 패키지 관리를 위한 강력한 솔루션을 제공합니다. 패키지 레지스트리를 활용하는 방법을 이해하는 것은 안전하고 간단하며 대규모로 패키지를 작업하는 데 중요합니다.

이 튜토리얼에서는 GitLab 패키지 레지스트리 모델을 엔터프라이즈 그룹 구조에 통합하는 방법을 배울 것입니다. 여기서 제공된 예시는 Maven 및 npm 패키지에 특화되어 있지만 이 튜토리얼의 개념을 GitLab 패키지 레지스트리에서 지원하는 모든 패키지로 확장할 수 있습니다.

이 튜토리얼을 마치면 다음을 알게 됩니다:

  1. 단일 루트 또는 최상위 그룹을 설정하여 작업을 구조화하는 방법.
  2. 명확한 소유권으로 패키지를 게시하기 위한 프로젝트 구성.
  3. 단순화된 액세스를 위한 최상위 그룹 패키지 소비 설정.
  4. 팀이 조직의 패키지에 액세스할 수 있도록 배포 토큰 추가.
  5. 패키지와 함께 안전하게 작동하도록 CI/CD 구성.

시작하기 전에#

이 튜토리얼을 완료하려면 다음이 필요합니다:

  • npm 또는 Maven 패키지.
  • GitLab 패키지 레지스트리에 대한 친숙함.
  • 테스트 프로젝트. 기존 프로젝트를 사용하거나 이 튜토리얼을 위해 프로젝트를 만들 수 있습니다.

GitLab 패키지 레지스트리 이해#

JFrog Artifactory 및 Sonatype Nexus와 같은 전통적인 패키지 관리자는 패키지를 저장하고 업데이트하기 위해 단일 중앙화된 저장소를 사용합니다. GitLab에서는 그룹 또는 프로젝트에서 직접 패키지를 관리합니다. 이는 다음을 의미합니다:

  • 팀은 코드를 저장하는 프로젝트에 패키지를 게시합니다.
  • 팀은 하위의 모든 패키지를 집계하는 루트 그룹 레지스트리에서 패키지를 사용합니다.
  • 액세스 제어는 기존 GitLab 권한에서 상속됩니다.

패키지가 코드처럼 저장되고 관리되기 때문에 기존 프로젝트나 그룹에 패키지 관리를 추가할 수 있습니다. 이 모델은 여러 가지 이점을 제공합니다:

  • 소스 코드와 함께 패키지의 명확한 소유권
  • 추가 구성 없이 세분화된 액세스 제어
  • 단순화된 CI/CD 통합
  • 팀 구조와의 자연스러운 정렬
  • 루트 그룹 소비를 통해 모든 회사 패키지에 액세스하기 위한 단일 URL

엔터프라이즈 구조 생성#

단일 최상위 그룹 아래에 코드를 구성하는 것을 고려하세요. 예를 들어:

company/ (top-level group)
├── retail-division/
│   ├── shared-libraries/    # Division-specific shared code
│   └── teams/
│       ├── checkout/        # Team publishes packages here
│       └── inventory/       # Team publishes packages here
├── banking-division/
│   ├── shared-libraries/    # Division-specific shared code
│   └── teams/
│       ├── payments/        # Team publishes packages here
│       └── fraud/           # Team publishes packages here
└── shared-platform/         # Enterprise-wide shared code
    ├── java-commons/        # Shared Java libraries
    └── ui-components/       # Shared UI components

이 구조에서 회사의 모든 팀은 코드와 패키지를 자신의 프로젝트에 게시하면서 최상위 company/ 그룹의 구성을 상속합니다.

최상위 그룹 설정#

Owner 역할이 있는 기존 최상위 그룹이 있는 경우 사용할 수 있습니다.

그룹이 없는 경우 만듭니다:

  1. 오른쪽 상단에서 새로 만들기 (+) 및 새 그룹을 선택합니다.
  2. 그룹 이름에서 그룹 이름을 입력합니다.
  3. 그룹 URL에서 네임스페이스로 사용할 그룹 경로를 입력합니다.
  4. 가시성 수준을 선택합니다.
  5. 선택 사항. 경험을 개인화하기 위한 정보를 입력합니다.
  6. 그룹 만들기를 선택합니다.

이 그룹은 조직의 다른 그룹 및 프로젝트를 저장합니다. 다른 프로젝트와 그룹이 있는 경우 관리를 위해 새 최상위 그룹으로 이전할 수 있습니다.

진행하기 전에 최소한 다음이 있는지 확인하세요:

  • 최상위 그룹.
  • 최상위 그룹 또는 하위 그룹 중 하나에 속하는 프로젝트.

패키지 게시#

명확한 소유권을 유지하기 위해 팀은 자신의 패키지 레지스트리에 패키지를 게시해야 합니다. 이렇게 하면 패키지가 소스 코드와 함께 유지되고 버전 이력이 프로젝트 활동과 연결됩니다.

Maven 패키지를 게시하려면:

  • 프로젝트의 패키지 레지스트리에 게시하도록 pom.xml 파일을 구성합니다:

    <!-- checkout/pom.xml -->
<distributionManagement>
    <repository>
        <id>gitlab-maven</id>
        <url>${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/maven</url>
    </repository>
</distributionManagement>

npm 패키지를 게시하려면:

  • package.json 파일을 구성합니다:

    // ui-components/package.json
{
  "name": "@company/ui-components",
  "publishConfig": {
    "registry": "${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/npm/"
  }
}

패키지 사용#

프로젝트가 단일 최상위 그룹 아래에 구성되어 있으므로 패키지를 조직에서 여전히 액세스할 수 있습니다. 팀이 패키지를 사용할 수 있도록 단일 API 엔드포인트를 구성해 보겠습니다.

  • 최상위 그룹에서 패키지에 액세스하도록 pom.xml을 구성합니다:

    <!-- Any project's pom.xml -->
<repositories>
    <repository>
        <id>gitlab-maven</id>
        <url>https://gitlab.example.com/api/v4/groups/company/-/packages/maven</url>
    </repository>
</repositories>

  • .npmrc 파일을 구성합니다:

    # Any project's .npmrc
@company:registry=https://gitlab.example.com/api/v4/groups/company/-/packages/npm/

이 구성은 프로젝트 기반 게시의 이점을 유지하면서 조직 전체의 모든 패키지에 자동으로 액세스를 제공합니다.

배포 토큰 추가#

다음으로 읽기 전용 배포 토큰을 추가합니다. 이 토큰은 조직의 하위 그룹 및 프로젝트에 저장된 패키지에 액세스를 제공하여 팀이 개발에 사용할 수 있도록 합니다.

  1. 최상위 그룹의 왼쪽 사이드바에서 설정 > 저장소를 선택합니다.
  2. 배포 토큰을 확장합니다.
  3. 토큰 추가를 선택합니다.
  4. 필드를 완성하고 범위를 read_repository로 설정합니다.
  5. 배포 토큰 만들기를 선택합니다.

필요한 만큼 최상위 그룹에 배포 토큰을 추가할 수 있습니다. 토큰을 주기적으로 교체하세요. 토큰이 노출되었다고 의심되면 즉시 취소하고 교체하세요.

CI/CD와 함께 패키지 사용#

CI/CD 작업이 패키지 레지스트리에 액세스해야 할 때 사전 정의된 CI/CD 변수 CI_JOB_TOKEN으로 인증합니다. 이 인증은 자동으로 이루어지므로 추가 구성이 필요하지 않습니다:

publish:
  script:
    - mvn deploy  # For Maven packages
    # or
    - npm publish # For npm packages
  # CI_JOB_TOKEN provides automatic authentication

요약 및 다음 단계#

GitLab 프로젝트를 하나의 최상위 그룹 아래에 구성하면 여러 가지 이점이 있습니다:

  • 단순화된 구성:
    • 모든 패키지 액세스를 위한 하나의 URL
    • 팀 전체의 일관된 설정
    • 쉬운 토큰 교체
  • 명확한 소유권:
    • 패키지는 소스 코드와 함께 유지됩니다
    • 팀은 게시에 대한 제어권을 유지합니다
    • 버전 이력은 프로젝트 활동과 연결됩니다
  • 자연스러운 조직:
    • 그룹이 회사 구조와 일치합니다
    • 팀은 자율적으로 유지하면서 협업할 수 있습니다

GitLab 패키지 레지스트리 모델은 엔터프라이즈 패키지 관리를 위한 강력한 솔루션을 제공합니다. 프로젝트 기반 게시와 최상위 그룹 소비를 결합하면 명확한 소유권과 단순화된 액세스 모두를 얻을 수 있습니다.

이 접근 방식은 보안과 사용 편의성을 유지하면서 조직과 함께 자연스럽게 확장됩니다. 단일 팀이나 부서에서 이 모델을 구현하는 것부터 시작하고, 통합된 접근 방식의 이점을 보면서 확장하세요. 이 튜토리얼은 Maven 및 npm에 초점을 맞췄지만 GitLab에서 지원하는 모든 패키지 유형에 동일한 원칙이 적용된다는 점을 기억하세요.

튜토리얼: 엔터프라이즈 규모에 맞는 패키지 레지스트리 구조화

원문 보기
요약

조직이 성장함에 따라 패키지 관리가 점점 복잡해질 수 있습니다. 이 튜토리얼에서는 GitLab 패키지 레지스트리 모델을 엔터프라이즈 그룹 구조에 통합하는 방법을 배울 것입니다. 이 튜토리얼을 마치면 다음을 알게 됩니다:

조직이 성장함에 따라 패키지 관리가 점점 복잡해질 수 있습니다. GitLab 패키지 레지스트리 모델은 엔터프라이즈 패키지 관리를 위한 강력한 솔루션을 제공합니다. 패키지 레지스트리를 활용하는 방법을 이해하는 것은 안전하고 간단하며 대규모로 패키지를 작업하는 데 중요합니다.

이 튜토리얼에서는 GitLab 패키지 레지스트리 모델을 엔터프라이즈 그룹 구조에 통합하는 방법을 배울 것입니다. 여기서 제공된 예시는 Maven 및 npm 패키지에 특화되어 있지만 이 튜토리얼의 개념을 GitLab 패키지 레지스트리에서 지원하는 모든 패키지로 확장할 수 있습니다.

이 튜토리얼을 마치면 다음을 알게 됩니다:

  1. 단일 루트 또는 최상위 그룹을 설정하여 작업을 구조화하는 방법.
  2. 명확한 소유권으로 패키지를 게시하기 위한 프로젝트 구성.
  3. 단순화된 액세스를 위한 최상위 그룹 패키지 소비 설정.
  4. 팀이 조직의 패키지에 액세스할 수 있도록 배포 토큰 추가.
  5. 패키지와 함께 안전하게 작동하도록 CI/CD 구성.

시작하기 전에#

이 튜토리얼을 완료하려면 다음이 필요합니다:

  • npm 또는 Maven 패키지.
  • GitLab 패키지 레지스트리에 대한 친숙함.
  • 테스트 프로젝트. 기존 프로젝트를 사용하거나 이 튜토리얼을 위해 프로젝트를 만들 수 있습니다.

GitLab 패키지 레지스트리 이해#

JFrog Artifactory 및 Sonatype Nexus와 같은 전통적인 패키지 관리자는 패키지를 저장하고 업데이트하기 위해 단일 중앙화된 저장소를 사용합니다. GitLab에서는 그룹 또는 프로젝트에서 직접 패키지를 관리합니다. 이는 다음을 의미합니다:

  • 팀은 코드를 저장하는 프로젝트에 패키지를 게시합니다.
  • 팀은 하위의 모든 패키지를 집계하는 루트 그룹 레지스트리에서 패키지를 사용합니다.
  • 액세스 제어는 기존 GitLab 권한에서 상속됩니다.

패키지가 코드처럼 저장되고 관리되기 때문에 기존 프로젝트나 그룹에 패키지 관리를 추가할 수 있습니다. 이 모델은 여러 가지 이점을 제공합니다:

  • 소스 코드와 함께 패키지의 명확한 소유권
  • 추가 구성 없이 세분화된 액세스 제어
  • 단순화된 CI/CD 통합
  • 팀 구조와의 자연스러운 정렬
  • 루트 그룹 소비를 통해 모든 회사 패키지에 액세스하기 위한 단일 URL

엔터프라이즈 구조 생성#

단일 최상위 그룹 아래에 코드를 구성하는 것을 고려하세요. 예를 들어:

company/ (top-level group)
├── retail-division/
│   ├── shared-libraries/    # Division-specific shared code
│   └── teams/
│       ├── checkout/        # Team publishes packages here
│       └── inventory/       # Team publishes packages here
├── banking-division/
│   ├── shared-libraries/    # Division-specific shared code
│   └── teams/
│       ├── payments/        # Team publishes packages here
│       └── fraud/           # Team publishes packages here
└── shared-platform/         # Enterprise-wide shared code
    ├── java-commons/        # Shared Java libraries
    └── ui-components/       # Shared UI components

이 구조에서 회사의 모든 팀은 코드와 패키지를 자신의 프로젝트에 게시하면서 최상위 company/ 그룹의 구성을 상속합니다.

최상위 그룹 설정#

Owner 역할이 있는 기존 최상위 그룹이 있는 경우 사용할 수 있습니다.

그룹이 없는 경우 만듭니다:

  1. 오른쪽 상단에서 새로 만들기 (+) 및 새 그룹을 선택합니다.
  2. 그룹 이름에서 그룹 이름을 입력합니다.
  3. 그룹 URL에서 네임스페이스로 사용할 그룹 경로를 입력합니다.
  4. 가시성 수준을 선택합니다.
  5. 선택 사항. 경험을 개인화하기 위한 정보를 입력합니다.
  6. 그룹 만들기를 선택합니다.

이 그룹은 조직의 다른 그룹 및 프로젝트를 저장합니다. 다른 프로젝트와 그룹이 있는 경우 관리를 위해 새 최상위 그룹으로 이전할 수 있습니다.

진행하기 전에 최소한 다음이 있는지 확인하세요:

  • 최상위 그룹.
  • 최상위 그룹 또는 하위 그룹 중 하나에 속하는 프로젝트.

패키지 게시#

명확한 소유권을 유지하기 위해 팀은 자신의 패키지 레지스트리에 패키지를 게시해야 합니다. 이렇게 하면 패키지가 소스 코드와 함께 유지되고 버전 이력이 프로젝트 활동과 연결됩니다.

Maven 패키지를 게시하려면:

  • 프로젝트의 패키지 레지스트리에 게시하도록 pom.xml 파일을 구성합니다:

    <!-- checkout/pom.xml -->
<distributionManagement>
    <repository>
        <id>gitlab-maven</id>
        <url>${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/maven</url>
    </repository>
</distributionManagement>

npm 패키지를 게시하려면:

  • package.json 파일을 구성합니다:

    // ui-components/package.json
{
  "name": "@company/ui-components",
  "publishConfig": {
    "registry": "${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/npm/"
  }
}

패키지 사용#

프로젝트가 단일 최상위 그룹 아래에 구성되어 있으므로 패키지를 조직에서 여전히 액세스할 수 있습니다. 팀이 패키지를 사용할 수 있도록 단일 API 엔드포인트를 구성해 보겠습니다.

  • 최상위 그룹에서 패키지에 액세스하도록 pom.xml을 구성합니다:

    <!-- Any project's pom.xml -->
<repositories>
    <repository>
        <id>gitlab-maven</id>
        <url>https://gitlab.example.com/api/v4/groups/company/-/packages/maven</url>
    </repository>
</repositories>

  • .npmrc 파일을 구성합니다:

    # Any project's .npmrc
@company:registry=https://gitlab.example.com/api/v4/groups/company/-/packages/npm/

이 구성은 프로젝트 기반 게시의 이점을 유지하면서 조직 전체의 모든 패키지에 자동으로 액세스를 제공합니다.

배포 토큰 추가#

다음으로 읽기 전용 배포 토큰을 추가합니다. 이 토큰은 조직의 하위 그룹 및 프로젝트에 저장된 패키지에 액세스를 제공하여 팀이 개발에 사용할 수 있도록 합니다.

  1. 최상위 그룹의 왼쪽 사이드바에서 설정 > 저장소를 선택합니다.
  2. 배포 토큰을 확장합니다.
  3. 토큰 추가를 선택합니다.
  4. 필드를 완성하고 범위를 read_repository로 설정합니다.
  5. 배포 토큰 만들기를 선택합니다.

필요한 만큼 최상위 그룹에 배포 토큰을 추가할 수 있습니다. 토큰을 주기적으로 교체하세요. 토큰이 노출되었다고 의심되면 즉시 취소하고 교체하세요.

CI/CD와 함께 패키지 사용#

CI/CD 작업이 패키지 레지스트리에 액세스해야 할 때 사전 정의된 CI/CD 변수 CI_JOB_TOKEN으로 인증합니다. 이 인증은 자동으로 이루어지므로 추가 구성이 필요하지 않습니다:

publish:
  script:
    - mvn deploy  # For Maven packages
    # or
    - npm publish # For npm packages
  # CI_JOB_TOKEN provides automatic authentication

요약 및 다음 단계#

GitLab 프로젝트를 하나의 최상위 그룹 아래에 구성하면 여러 가지 이점이 있습니다:

  • 단순화된 구성:
    • 모든 패키지 액세스를 위한 하나의 URL
    • 팀 전체의 일관된 설정
    • 쉬운 토큰 교체
  • 명확한 소유권:
    • 패키지는 소스 코드와 함께 유지됩니다
    • 팀은 게시에 대한 제어권을 유지합니다
    • 버전 이력은 프로젝트 활동과 연결됩니다
  • 자연스러운 조직:
    • 그룹이 회사 구조와 일치합니다
    • 팀은 자율적으로 유지하면서 협업할 수 있습니다

GitLab 패키지 레지스트리 모델은 엔터프라이즈 패키지 관리를 위한 강력한 솔루션을 제공합니다. 프로젝트 기반 게시와 최상위 그룹 소비를 결합하면 명확한 소유권과 단순화된 액세스 모두를 얻을 수 있습니다.

이 접근 방식은 보안과 사용 편의성을 유지하면서 조직과 함께 자연스럽게 확장됩니다. 단일 팀이나 부서에서 이 모델을 구현하는 것부터 시작하고, 통합된 접근 방식의 이점을 보면서 확장하세요. 이 튜토리얼은 Maven 및 npm에 초점을 맞췄지만 GitLab에서 지원하는 모든 패키지 유형에 동일한 원칙이 적용된다는 점을 기억하세요.