Helm 차트 릴리스 생성

Helm 차트 릴리스는 차트의 저장소 위치와 버전, Apollo 제품 식별자 및 기본 구성값을 연결합니다. 제품이 아직 없다면 먼저 생성합니다. 릴리스는 허브의 게시 화면 또는 Apollo CLI로 등록할 수 있습니다.

제품 릴리스 등록은 관리 메타데이터를 게시하는 작업입니다. 차트와 컨테이너 이미지는 지정한 저장소에 계속 존재해야 하며, 배포할 스포크가 그 저장소에 접근할 수 있어야 합니다.

허브에서 릴리스 생성

1. Products에서 대상 Helm 차트 제품을 선택합니다.
2. Create new Release를 선택합니다.

양식의 Group ID와 Artifact ID는 제품 메타데이터에서 미리 채웁니다.

3. Release version에 1.2.3이나 1.2.3-rc1 같은 Apollo 비교 가능 버전을 입력합니다.
4. Product type에서 Helm chart를 선택합니다.
5. Publish type에서 OCI repository 또는 Helm repository를 선택합니다.
6. 차트 정보를 입력합니다.

가상의 OCI 저장소 주소는 oci://docker.example.com/charts, 일반 Helm 저장소 주소의 예는 https://charts.bitnami.com/bitnami입니다. OCI 아티팩트에는 docker.example.com/charts/my-chart:1.0.0 같은 URI를 지정할 수 있습니다.

7. Create release를 선택합니다.
8. 완료 메시지에서 View Product Release로 상세 페이지를 엽니다.

CLI를 사용할 때의 준비

• Apollo CLI를 내려받아 허브 연결을 설정합니다.
• 구성 파일을 포함하여 제품 릴리스를 만들려면 CLI 0.814.0 이상이 필요합니다. 이전 버전도 제품 TGZ 방식을 지원하지만 구성 파일은 포함하지 않습니다.
• 사용할 차트가 Helm 또는 OCI 저장소에 게시되어 있어야 합니다.
• Apollo 인증에는 Bearer 토큰 또는 클라이언트 ID와 클라이언트 비밀값을 사용합니다.
• 차트와 컨테이너 이미지를 읽을 저장소 접근을 준비합니다.

허브에 외부 저장소를 등록하고 아티팩트 레지스트리를 환경에 할당하여 저장소 접근을 구성할 수 있습니다.

배포 환경의 저장소 인증 정보

Kubernetes Secret으로 저장소 인증 정보를 제공하는 구성에서는 차트를 설치할 네임스페이스와 Secret의 네임스페이스가 같아야 합니다.

사용자 이름과 비밀번호 인증 또는 인증서 인증을 사용할 수 있습니다. 예를 들어 docker.io와 charts.bitnami.com에 각각 인증해야 하는 구성에서는 저장소별 Secret을 준비합니다. 비밀값은 실제 저장소의 인증 방식에 맞추어 제공하고 공유 코드나 문서에 기록하지 않습니다.

Apollo 허브에 접근하는 CLI 인증과 스포크가 저장소에 접근하는 인증은 별도로 준비합니다.

Apollo 제품 패키지

Apollo 제품 TGZ는 제품의 Maven 좌표와 차트 위치를 설명하는 매니페스트, 기본 구성값과 선택적인 구성 스키마를 묶습니다.

wordpress-32.1.13
└── deployment
    ├── manifest.yml
    ├── values.yaml
    └── values.schema.json

values.schema.json은 차트가 제공할 때 포함합니다. Apollo는 이 스키마로 설정 재정의를 검증할 수 있습니다.

매니페스트에서 확인할 값

CLI가 작성한 deployment/manifest.yml에서 다음 값을 확인합니다. 제품 유형과 형식 정보는 생성 도구가 작성한 값을 사용합니다.

제품 버전과 차트 버전은 다를 수 있지만 같게 유지하는 것이 권장됩니다. 제품 버전은 Apollo의 비교 가능한 버전 규칙을 충족해야 합니다. 일반적인 Semantic Versioning 문자열 전체를 허용하는 것은 아닙니다.

제품 그룹과 이름, 이미지 이름 및 태그 같은 운영 메타데이터는 문제 조사와 모니터링을 위한 로그에서 Palantir 직원과 환경 관리자에게 보일 수 있습니다. 민감한 내용은 이름에 넣지 않고 비밀정보로 관리합니다.

제품 TGZ 생성

다음은 WordPress 차트 32.1.13을 가상의 제품 ID com.example:wordpress로 등록할 패키지를 만드는 예시입니다. 현재 디렉터리에 CLI가 있고 연결 프로필이 구성되어 있다고 가정합니다.

./apollo-cli product-release helm-chart init \
  --as-tgz \
  --maven-coordinate "com.example:wordpress:32.1.13" \
  --repository-url "oci://registry-1.docker.io/bitnamicharts" \
  --name "oci://registry-1.docker.io/bitnamicharts/wordpress" \
  --version "32.1.13" \
  --output-dir "./chart"

원격 OCI 차트의 --name에는 차트 이름까지 포함한 전체 OCI URL을 지정합니다. 생성 결과는 ./chart/wordpress-32.1.13.config.tgz입니다. 차트에 스키마가 있으면 기본 구성값과 함께 패키지에 포함합니다.

제품 사이의 의존 관계

제품 릴리스의 extensions.product-dependencies에는 순서 없는 의존 관계 목록을 넣습니다. Apollo는 새 버전이 요구하는 의존 제품과 이 제품을 사용하는 다른 개체의 조건을 함께 확인하여 변경 계획을 정합니다.

다음은 가상의 의존 관계를 생성된 매니페스트에 추가하는 구성입니다.

extensions:
  product-dependencies:
    - product-group: com.example.foo
      product-name: foo
      minimum-version: 1.3.5
      maximum-version: 1.x.x
      optional: false
    - product-group: com.example.bar
      product-name: bar
      minimum-version: 2.7.0
      maximum-version: 2.x.x
      optional: true

기존 helm-chart 등 다른 확장은 유지하면서 같은 extensions에 의존 관계 항목을 추가합니다.

선택적 의존 관계는 해당 제품이 설치되어 있지 않아도 됩니다. 설치되어 있다면 선언한 버전 범위를 충족해야 하며, 그 대상의 설치 제거를 막지는 않습니다. 선택적 의존 관계 목록만으로 애플리케이션에 유효한 모든 구성 조합이 결정되지는 않으므로 실제로 사용하는 기능과 의존 제품을 함께 정해야 합니다.

컨테이너 이미지 선언

릴리스가 사용하는 모든 컨테이너 이미지는 extensions.artifacts에 선언합니다. 허브에서 취약점 검사를 사용한다면 검사할 이미지가 정확히 등록되어 있어야 합니다.

다음은 가상의 제품이 이미지 하나를 사용하는 경우의 확장 구조입니다.

extensions:
  artifacts:
    - type: oci
      uri: registry.example.com/apps/order-service:1.4.2

현재 아티팩트 유형은 oci이며 uri에는 실제 사용할 이미지의 위치와 버전을 지정합니다. 차트 자체와 차트가 사용하는 컨테이너 이미지의 위치를 각각 확인합니다.

패키지로 릴리스 등록

APOLLO_URL과 APOLLO_TOKEN에 실제 허브 URL과 토큰을 제공한 뒤 실행합니다. 토큰을 명령 파일에 직접 저장하지 않습니다.

: "${APOLLO_URL:?Apollo 허브 URL이 필요합니다}"
: "${APOLLO_TOKEN:?Apollo 토큰이 필요합니다}"

./apollo-cli product-release create \
  --apollo-url "$APOLLO_URL" \
  --apollo-token "$APOLLO_TOKEN" \
  --product-tgz "./chart/wordpress-32.1.13.config.tgz"

--product-tgz는 포함된 매니페스트와 values.yaml, 존재하는 경우 values.schema.json을 등록합니다. 서비스 계정을 사용하려면 Bearer 토큰 옵션 대신 --apollo-client-id와 --apollo-client-secret을 함께 전달합니다. 두 인증 방식을 동시에 지정하지 않습니다.

기본 조직 밖의 플랫폼 인스턴스에 릴리스를 생성한다면 --space-id에 실제 대상 공간 RID를 추가합니다.

매니페스트와 구성 파일을 따로 등록

차트를 내려받아 풀고, --as-tgz 없이 매니페스트를 생성할 수도 있습니다.

helm pull oci://registry-1.docker.io/bitnamicharts/wordpress \
  --version 32.1.13 \
  --untar

./apollo-cli product-release helm-chart init \
  --chart-path "./wordpress" \
  --repository-url "oci://registry-1.docker.io/bitnamicharts" \
  --maven-coordinate "com.example:wordpress:32.1.13" \
  --output-dir "./chart"

생성된 매니페스트와 차트의 기본 구성 파일을 함께 등록합니다.

./apollo-cli product-release create \
  --apollo-url "$APOLLO_URL" \
  --apollo-token "$APOLLO_TOKEN" \
  --manifest "./chart/manifest.yml" \
  --default-config "./wordpress/values.yaml"

WordPress 32.1.13 차트에는 values.schema.json이 없으므로 이 예시에서는 스키마 옵션을 지정하지 않습니다. 스키마가 있는 차트라면 --default-config와 함께 --config-schema에 해당 파일을 지정합니다. 스키마만 제공하고 기본 구성값을 생략할 수는 없습니다.

다음 버전의 게시를 자동화하려면 같은 초기화와 등록 단계를 CI에 연결할 수 있습니다.