InfoGrab Docs

Auto DevOps 커스터마이즈

요약

필요에 맞게 Auto DevOps의 구성 요소를 커스터마이즈할 수 있습니다. 다음 경우에 빌드팩을 커스터마이즈할 수 있습니다: Auto Test는 .buildpacks 파일을 사용할 수 없으므로 Auto DevOps는 다중 빌드팩을 지원하지 않습니다.

필요에 맞게 Auto DevOps의 구성 요소를 커스터마이즈할 수 있습니다. 예를 들어 다음이 가능합니다:

커스텀 빌드팩#

다음 경우에 빌드팩을 커스터마이즈할 수 있습니다:

  • 프로젝트에서 자동 빌드팩 감지가 실패할 때.
  • 빌드를 더 세밀하게 제어해야 할 때.

Cloud Native 빌드팩으로 빌드팩 커스터마이즈#

다음 중 하나를 지정하세요:

다중 빌드팩#

Auto Test는 .buildpacks 파일을 사용할 수 없으므로 Auto DevOps는 다중 빌드팩을 지원하지 않습니다. .buildpacks 파일을 파싱하기 위해 백엔드에서 사용되는 빌드팩 heroku-buildpack-multi는 필요한 명령 bin/test-compilebin/test를 제공하지 않습니다.

단일 커스텀 빌드팩만 사용하려면 프로젝트 CI/CD 변수 BUILDPACK_URL을 대신 제공해야 합니다.

커스텀 Dockerfile#

프로젝트 리포지터리 루트에 Dockerfile이 있으면 Auto DevOps가 Dockerfile을 기반으로 Docker 이미지를 빌드합니다. 빌드팩을 사용하는 것보다 빠를 수 있습니다. 특히 Dockerfile이 Alpine을 기반으로 하는 경우 더 작은 이미지를 생성할 수도 있습니다.

DOCKERFILE_PATH CI/CD 변수를 설정하면 Auto Build가 기본 위치 대신 해당 위치에서 Dockerfile을 찾습니다.

docker build에 인수 전달#

AUTO_DEVOPS_BUILD_IMAGE_EXTRA_ARGS 프로젝트 CI/CD 변수를 사용하여 docker build에 인수를 전달할 수 있습니다.

예를 들어 기본 ruby:latest 대신 ruby:alpine을 기반으로 Docker 이미지를 빌드하려면:

  1. AUTO_DEVOPS_BUILD_IMAGE_EXTRA_ARGS--build-arg=RUBY_VERSION=alpine으로 설정하세요.

  2. 커스텀 Dockerfile에 다음을 추가하세요:

    ARG RUBY_VERSION=latest
    FROM ruby:$RUBY_VERSION
    
    # 여기에 내용을 포함하세요
    

공백과 줄 바꿈과 같은 복잡한 값을 전달하려면 Base64 인코딩을 사용하세요. 인코딩되지 않은 복잡한 값은 문자 이스케이프 문제를 일으킬 수 있습니다.

Warning

Docker 빌드 인수로 시크릿을 전달하지 마세요. 시크릿이 이미지에 남아 있을 수 있습니다. 자세한 내용은 시크릿에 관한 모범 사례 논의를 참조하세요.

커스텀 컨테이너 이미지#

기본적으로 Auto DeployAuto Build가 GitLab 레지스트리에 빌드하고 푸시한 컨테이너 이미지를 배포합니다. 특정 변수를 정의하여 이 동작을 재정의할 수 있습니다:

항목 기본값 재정의 가능한 방법
이미지 경로 브랜치 파이프라인의 경우 $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG. 태그 파이프라인의 경우 $CI_REGISTRY_IMAGE. $CI_APPLICATION_REPOSITORY
이미지 태그 브랜치 파이프라인의 경우 $CI_COMMIT_SHA. 태그 파이프라인의 경우 $CI_COMMIT_TAG. $CI_APPLICATION_TAG

이 변수는 Auto Build와 자동 컨테이너 스캔에도 영향을 미칩니다. $CI_APPLICATION_REPOSITORY:$CI_APPLICATION_TAG에 이미지를 빌드하고 푸시하지 않으려면 Jobs/Deploy.gitlab-ci.yml만 포함하거나 build 작업을 건너뛰세요.

자동 컨테이너 스캔을 사용하고 $CI_APPLICATION_REPOSITORY 값을 설정하는 경우 $CS_DEFAULT_BRANCH_IMAGE도 업데이트해야 합니다. 자세한 내용은 기본 브랜치 이미지 설정을 참조하세요.

.gitlab-ci.yml에서의 설정 예:

variables:
  CI_APPLICATION_REPOSITORY: <your-image-repository>
  CI_APPLICATION_TAG: <the-tag>

API로 Auto DevOps 확장#

GitLab API를 사용하여 Auto DevOps 구성을 확장하고 관리할 수 있습니다:

빌드 환경으로 CI/CD 변수 전달#

빌드 환경으로 CI/CD 변수를 전달하려면 전달할 변수 이름을 AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES CI/CD 변수에 추가하세요. 여러 변수는 쉼표로 구분하세요.

예를 들어 CI_COMMIT_SHACI_ENVIRONMENT_NAME 변수를 전달하려면:

variables:
  AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES: CI_COMMIT_SHA,CI_ENVIRONMENT_NAME

빌드팩을 사용하는 경우 전달된 변수는 환경 변수로 자동으로 사용 가능합니다.

Dockerfile을 사용하는 경우:

  1. 실험적 Dockerfile 구문을 활성화하려면 Dockerfile에 다음을 추가하세요:

    # syntax = docker/dockerfile:experimental
    
  2. Dockerfile의 모든 RUN $COMMAND에서 시크릿을 사용하려면 시크릿 파일을 마운트하고 $COMMAND를 실행하기 전에 소스로 지정하세요:

    RUN --mount=type=secret,id=auto-devops-build-secrets . /run/secrets/auto-devops-build-secrets && $COMMAND
    

AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES가 설정되면 Auto DevOps는 --secret 플래그를 사용하기 위해 실험적 Docker BuildKit 기능을 활성화합니다.

커스텀 Helm 차트#

Auto DevOps는 Helm을 사용하여 Kubernetes에 애플리케이션을 배포합니다. 프로젝트 리포지터리에 차트를 번들링하거나 프로젝트 CI/CD 변수를 지정하여 사용되는 Helm 차트를 재정의할 수 있습니다:

  • 번들된 차트 - 프로젝트에 Chart.yaml 파일이 있는 ./chart 디렉토리가 있으면 Auto DevOps가 이 차트를 감지하고 기본 차트 대신 사용합니다.

  • 프로젝트 변수 - 커스텀 차트 URL을 사용하여 프로젝트 CI/CD 변수 AUTO_DEVOPS_CHART를 생성하세요. 다음 다섯 가지 프로젝트 변수도 생성할 수 있습니다:

    • AUTO_DEVOPS_CHART_REPOSITORY - 커스텀 차트 리포지터리의 URL.
    • AUTO_DEVOPS_CHART - 차트 경로.
    • AUTO_DEVOPS_CHART_REPOSITORY_INSECURE - 비어 있지 않은 값으로 설정하면 Helm 명령에 --insecure-skip-tls-verify 인수를 추가합니다.
    • AUTO_DEVOPS_CHART_CUSTOM_ONLY - 비어 있지 않은 값으로 설정하면 커스텀 차트만 사용합니다. 기본적으로 최신 차트가 GitLab에서 다운로드됩니다.
    • AUTO_DEVOPS_CHART_VERSION - 배포 차트 버전.

Helm 차트 값 커스터마이즈#

기본 Helm 차트values.yaml 파일에 있는 기본값을 재정의하려면 다음 중 하나를 선택하세요:

  • 리포지터리에 .gitlab/auto-deploy-values.yaml이라는 파일을 추가하세요. 이 파일은 기본적으로 Helm 업그레이드에 사용됩니다.
  • 다른 이름이나 경로를 가진 파일을 리포지터리에 추가하세요. 파일의 경로와 이름을 사용하여 HELM_UPGRADE_VALUES_FILE CI/CD 변수를 설정하세요.

이전 옵션으로는 재정의할 수 없는 값이 있지만 이 이슈에서 이 동작을 변경하도록 제안합니다. replicaCount와 같은 설정을 재정의하려면 REPLICAS 빌드 및 배포 CI/CD 변수를 사용하세요.

helm upgrade 커스터마이즈#

auto-deploy-imagehelm upgrade 명령을 사용합니다. 이 명령을 커스터마이즈하려면 HELM_UPGRADE_EXTRA_ARGS CI/CD 변수로 옵션을 전달하세요.

예를 들어 helm upgrade가 실행될 때 업그레이드 전후 훅을 비활성화하려면:

variables:
  HELM_UPGRADE_EXTRA_ARGS: --no-hooks

전체 옵션 목록은 공식 helm upgrade 문서를 참조하세요.

하나의 환경으로 Helm 차트 제한#

커스텀 차트를 하나의 환경으로 제한하려면 CI/CD 변수에 환경 범위를 추가하세요. 자세한 내용은 CI/CD 변수의 환경 범위 제한을 참조하세요.

.gitlab-ci.yml 커스터마이즈#

Auto DevOps 템플릿.gitlab-ci.yml 파일의 구현이기 때문에 Auto DevOps는 매우 커스터마이즈 가능합니다. 이 템플릿은 .gitlab-ci.yml의 모든 구현에서 사용 가능한 기능만 사용합니다.

Auto DevOps에서 사용하는 CI/CD 파이프라인에 커스텀 동작을 추가하려면:

  1. 리포지터리 루트에 다음 내용의 .gitlab-ci.yml 파일을 추가하세요:

    include:
      - template: Auto-DevOps.gitlab-ci.yml
    
  2. .gitlab-ci.yml 파일에 변경 사항을 추가하세요. 변경 사항은 Auto DevOps 템플릿과 병합됩니다. include가 변경 사항을 병합하는 방법에 대한 자세한 내용은 include 문서를 참조하세요.

Auto DevOps 파이프라인에서 동작을 제거하려면:

  1. Auto DevOps 템플릿을 프로젝트에 복사하세요.
  2. 필요에 따라 템플릿 사본을 편집하세요.

Auto DevOps의 개별 구성 요소 사용#

Auto DevOps에서 제공하는 기능의 일부만 필요한 경우 자체 .gitlab-ci.yml에 개별 Auto DevOps 작업을 포함할 수 있습니다. .gitlab-ci.yml 파일에서 각 작업에 필요한 스테이지도 정의해야 합니다.

예를 들어 Auto Build를 사용하려면 .gitlab-ci.yml에 다음을 추가하세요:

stages:
  - build

include:
  - template: Jobs/Build.gitlab-ci.yml

사용 가능한 작업 목록은 Auto DevOps 템플릿을 참조하세요.

여러 Kubernetes 클러스터 사용#

Auto DevOps를 위한 여러 Kubernetes 클러스터를 참조하세요.

Kubernetes 네임스페이스 커스터마이즈#

GitLab 14.5 이하에서는 environment:kubernetes:namespace를 사용하여 환경의 네임스페이스를 지정할 수 있었습니다. 그러나 이 기능은 인증서 기반 통합과 함께 Deprecated되었습니다.

이제 KUBE_NAMESPACE 환경 변수를 사용하고 환경 범위를 제한해야 합니다.

로컬 Docker 레지스트리에서 호스팅된 이미지 사용#

많은 Auto DevOps 작업이 오프라인 환경에서 실행되도록 구성할 수 있습니다:

  1. Docker Hub 및 registry.gitlab.com에서 필요한 Auto DevOps Docker 이미지를 로컬 GitLab 컨테이너 레지스트리에 복사하세요.

  2. 이미지가 로컬 레지스트리에서 호스팅되고 사용 가능해지면 로컬에서 호스팅된 이미지를 가리키도록 .gitlab-ci.yml을 편집하세요. 예:

    include:
      - template: Auto-DevOps.gitlab-ci.yml
    
    variables:
      REGISTRY_URL: "registry.gitlab.example"
    
    build:
      image: "$REGISTRY_URL/docker/auto-build-image:v0.6.0"
      services:
        - name: "$REGISTRY_URL/greg/docker/docker:20.10.16-dind"
          command: ['--tls=false', '--host=tcp://0.0.0.0:2375']
    

PostgreSQL 데이터베이스 지원#

Warning

기본적으로 PostgreSQL 데이터베이스를 프로비저닝하는 것은 GitLab 15.8에서 Deprecated되었으며 16.0부터는 기본값이 되지 않습니다. 데이터베이스 프로비저닝을 활성화하려면 관련 CI/CD 변수를 설정하세요.

데이터베이스가 필요한 애플리케이션을 지원하기 위해 기본적으로 PostgreSQL이 프로비저닝됩니다. 데이터베이스에 접근하기 위한 자격 증명이 사전 구성되어 있습니다.

자격 증명을 커스터마이즈하려면 관련 CI/CD 변수를 설정하세요. 커스텀 DATABASE_URL도 정의할 수 있습니다:

postgres://user:password@postgres-host:postgres-port/postgres-database

PostgreSQL 업그레이드#

GitLab은 기본적으로 차트 버전 8.2.1을 사용하여 PostgreSQL을 프로비저닝합니다. 버전은 0.7.1에서 8.2.1까지 설정할 수 있습니다.

이전 차트 버전을 사용하는 경우 최신 PostgreSQL로 데이터베이스를 마이그레이션해야 합니다.

기본 프로비저닝된 PostgreSQL을 제어하는 CI/CD 변수 AUTO_DEVOPS_POSTGRES_CHANNELGitLab 13.0에서 2로 변경되었습니다. 이전 PostgreSQL을 사용하려면 AUTO_DEVOPS_POSTGRES_CHANNEL 변수를 1로 설정하세요.

PostgreSQL Helm 차트의 값 커스터마이즈#

커스텀 값을 설정하려면 다음 중 하나를 수행하세요:

  • 리포지터리에 .gitlab/auto-deploy-postgres-values.yaml이라는 파일을 추가하세요. 발견되면 이 파일이 자동으로 사용됩니다. 이 파일은 기본적으로 PostgreSQL Helm 업그레이드에 사용됩니다.
  • 리포지터리에 다른 이름이나 경로를 가진 파일을 추가하고 경로와 이름을 사용하여 POSTGRES_HELM_UPGRADE_VALUES_FILE 환경 변수를 설정하세요.
  • POSTGRES_HELM_UPGRADE_EXTRA_ARGS 환경 변수를 설정하세요.

외부 PostgreSQL 데이터베이스 제공자 사용#

Auto DevOps는 프로덕션 환경을 위한 PostgreSQL 컨테이너를 즉시 지원합니다. 그러나 AWS Relational Database Service와 같은 외부 관리형 제공자를 사용할 수도 있습니다.

외부 관리형 제공자를 사용하려면:

  1. 환경 범위 CI/CD 변수를 사용하여 필요한 환경에 대한 내장 PostgreSQL 설치를 비활성화하세요. 리뷰 앱 및 스테이징을 위한 내장 PostgreSQL 설정으로 충분하기 때문에 production에 대해서만 설치를 비활성화하면 될 수 있습니다.

    Auto Metrics

  2. 애플리케이션에서 사용 가능한 환경 범위 변수로 DATABASE_URL 변수를 정의하세요. 이는 다음 형식의 URL이어야 합니다:

    postgres://user:password@postgres-host:postgres-port/postgres-database
    
  3. Kubernetes 클러스터가 PostgreSQL이 호스팅되는 곳에 네트워크로 접근할 수 있는지 확인하세요.

Auto DevOps 커스터마이즈

Tier: Free, Premium, Ultimate
Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
원문 보기
요약

필요에 맞게 Auto DevOps의 구성 요소를 커스터마이즈할 수 있습니다. 다음 경우에 빌드팩을 커스터마이즈할 수 있습니다: Auto Test는 .buildpacks 파일을 사용할 수 없으므로 Auto DevOps는 다중 빌드팩을 지원하지 않습니다.

필요에 맞게 Auto DevOps의 구성 요소를 커스터마이즈할 수 있습니다. 예를 들어 다음이 가능합니다:

커스텀 빌드팩#

다음 경우에 빌드팩을 커스터마이즈할 수 있습니다:

  • 프로젝트에서 자동 빌드팩 감지가 실패할 때.
  • 빌드를 더 세밀하게 제어해야 할 때.

Cloud Native 빌드팩으로 빌드팩 커스터마이즈#

다음 중 하나를 지정하세요:

다중 빌드팩#

Auto Test는 .buildpacks 파일을 사용할 수 없으므로 Auto DevOps는 다중 빌드팩을 지원하지 않습니다. .buildpacks 파일을 파싱하기 위해 백엔드에서 사용되는 빌드팩 heroku-buildpack-multi는 필요한 명령 bin/test-compilebin/test를 제공하지 않습니다.

단일 커스텀 빌드팩만 사용하려면 프로젝트 CI/CD 변수 BUILDPACK_URL을 대신 제공해야 합니다.

커스텀 Dockerfile#

프로젝트 리포지터리 루트에 Dockerfile이 있으면 Auto DevOps가 Dockerfile을 기반으로 Docker 이미지를 빌드합니다. 빌드팩을 사용하는 것보다 빠를 수 있습니다. 특히 Dockerfile이 Alpine을 기반으로 하는 경우 더 작은 이미지를 생성할 수도 있습니다.

DOCKERFILE_PATH CI/CD 변수를 설정하면 Auto Build가 기본 위치 대신 해당 위치에서 Dockerfile을 찾습니다.

docker build에 인수 전달#

AUTO_DEVOPS_BUILD_IMAGE_EXTRA_ARGS 프로젝트 CI/CD 변수를 사용하여 docker build에 인수를 전달할 수 있습니다.

예를 들어 기본 ruby:latest 대신 ruby:alpine을 기반으로 Docker 이미지를 빌드하려면:

  1. AUTO_DEVOPS_BUILD_IMAGE_EXTRA_ARGS--build-arg=RUBY_VERSION=alpine으로 설정하세요.

  2. 커스텀 Dockerfile에 다음을 추가하세요:

    ARG RUBY_VERSION=latest
    FROM ruby:$RUBY_VERSION
    
    # 여기에 내용을 포함하세요
    

공백과 줄 바꿈과 같은 복잡한 값을 전달하려면 Base64 인코딩을 사용하세요. 인코딩되지 않은 복잡한 값은 문자 이스케이프 문제를 일으킬 수 있습니다.

Warning

Docker 빌드 인수로 시크릿을 전달하지 마세요. 시크릿이 이미지에 남아 있을 수 있습니다. 자세한 내용은 시크릿에 관한 모범 사례 논의를 참조하세요.

커스텀 컨테이너 이미지#

기본적으로 Auto DeployAuto Build가 GitLab 레지스트리에 빌드하고 푸시한 컨테이너 이미지를 배포합니다. 특정 변수를 정의하여 이 동작을 재정의할 수 있습니다:

항목 기본값 재정의 가능한 방법
이미지 경로 브랜치 파이프라인의 경우 $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG. 태그 파이프라인의 경우 $CI_REGISTRY_IMAGE. $CI_APPLICATION_REPOSITORY
이미지 태그 브랜치 파이프라인의 경우 $CI_COMMIT_SHA. 태그 파이프라인의 경우 $CI_COMMIT_TAG. $CI_APPLICATION_TAG

이 변수는 Auto Build와 자동 컨테이너 스캔에도 영향을 미칩니다. $CI_APPLICATION_REPOSITORY:$CI_APPLICATION_TAG에 이미지를 빌드하고 푸시하지 않으려면 Jobs/Deploy.gitlab-ci.yml만 포함하거나 build 작업을 건너뛰세요.

자동 컨테이너 스캔을 사용하고 $CI_APPLICATION_REPOSITORY 값을 설정하는 경우 $CS_DEFAULT_BRANCH_IMAGE도 업데이트해야 합니다. 자세한 내용은 기본 브랜치 이미지 설정을 참조하세요.

.gitlab-ci.yml에서의 설정 예:

variables:
  CI_APPLICATION_REPOSITORY: <your-image-repository>
  CI_APPLICATION_TAG: <the-tag>

API로 Auto DevOps 확장#

GitLab API를 사용하여 Auto DevOps 구성을 확장하고 관리할 수 있습니다:

빌드 환경으로 CI/CD 변수 전달#

빌드 환경으로 CI/CD 변수를 전달하려면 전달할 변수 이름을 AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES CI/CD 변수에 추가하세요. 여러 변수는 쉼표로 구분하세요.

예를 들어 CI_COMMIT_SHACI_ENVIRONMENT_NAME 변수를 전달하려면:

variables:
  AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES: CI_COMMIT_SHA,CI_ENVIRONMENT_NAME

빌드팩을 사용하는 경우 전달된 변수는 환경 변수로 자동으로 사용 가능합니다.

Dockerfile을 사용하는 경우:

  1. 실험적 Dockerfile 구문을 활성화하려면 Dockerfile에 다음을 추가하세요:

    # syntax = docker/dockerfile:experimental
    
  2. Dockerfile의 모든 RUN $COMMAND에서 시크릿을 사용하려면 시크릿 파일을 마운트하고 $COMMAND를 실행하기 전에 소스로 지정하세요:

    RUN --mount=type=secret,id=auto-devops-build-secrets . /run/secrets/auto-devops-build-secrets && $COMMAND
    

AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES가 설정되면 Auto DevOps는 --secret 플래그를 사용하기 위해 실험적 Docker BuildKit 기능을 활성화합니다.

커스텀 Helm 차트#

Auto DevOps는 Helm을 사용하여 Kubernetes에 애플리케이션을 배포합니다. 프로젝트 리포지터리에 차트를 번들링하거나 프로젝트 CI/CD 변수를 지정하여 사용되는 Helm 차트를 재정의할 수 있습니다:

  • 번들된 차트 - 프로젝트에 Chart.yaml 파일이 있는 ./chart 디렉토리가 있으면 Auto DevOps가 이 차트를 감지하고 기본 차트 대신 사용합니다.

  • 프로젝트 변수 - 커스텀 차트 URL을 사용하여 프로젝트 CI/CD 변수 AUTO_DEVOPS_CHART를 생성하세요. 다음 다섯 가지 프로젝트 변수도 생성할 수 있습니다:

    • AUTO_DEVOPS_CHART_REPOSITORY - 커스텀 차트 리포지터리의 URL.
    • AUTO_DEVOPS_CHART - 차트 경로.
    • AUTO_DEVOPS_CHART_REPOSITORY_INSECURE - 비어 있지 않은 값으로 설정하면 Helm 명령에 --insecure-skip-tls-verify 인수를 추가합니다.
    • AUTO_DEVOPS_CHART_CUSTOM_ONLY - 비어 있지 않은 값으로 설정하면 커스텀 차트만 사용합니다. 기본적으로 최신 차트가 GitLab에서 다운로드됩니다.
    • AUTO_DEVOPS_CHART_VERSION - 배포 차트 버전.

Helm 차트 값 커스터마이즈#

기본 Helm 차트values.yaml 파일에 있는 기본값을 재정의하려면 다음 중 하나를 선택하세요:

  • 리포지터리에 .gitlab/auto-deploy-values.yaml이라는 파일을 추가하세요. 이 파일은 기본적으로 Helm 업그레이드에 사용됩니다.
  • 다른 이름이나 경로를 가진 파일을 리포지터리에 추가하세요. 파일의 경로와 이름을 사용하여 HELM_UPGRADE_VALUES_FILE CI/CD 변수를 설정하세요.

이전 옵션으로는 재정의할 수 없는 값이 있지만 이 이슈에서 이 동작을 변경하도록 제안합니다. replicaCount와 같은 설정을 재정의하려면 REPLICAS 빌드 및 배포 CI/CD 변수를 사용하세요.

helm upgrade 커스터마이즈#

auto-deploy-imagehelm upgrade 명령을 사용합니다. 이 명령을 커스터마이즈하려면 HELM_UPGRADE_EXTRA_ARGS CI/CD 변수로 옵션을 전달하세요.

예를 들어 helm upgrade가 실행될 때 업그레이드 전후 훅을 비활성화하려면:

variables:
  HELM_UPGRADE_EXTRA_ARGS: --no-hooks

전체 옵션 목록은 공식 helm upgrade 문서를 참조하세요.

하나의 환경으로 Helm 차트 제한#

커스텀 차트를 하나의 환경으로 제한하려면 CI/CD 변수에 환경 범위를 추가하세요. 자세한 내용은 CI/CD 변수의 환경 범위 제한을 참조하세요.

.gitlab-ci.yml 커스터마이즈#

Auto DevOps 템플릿.gitlab-ci.yml 파일의 구현이기 때문에 Auto DevOps는 매우 커스터마이즈 가능합니다. 이 템플릿은 .gitlab-ci.yml의 모든 구현에서 사용 가능한 기능만 사용합니다.

Auto DevOps에서 사용하는 CI/CD 파이프라인에 커스텀 동작을 추가하려면:

  1. 리포지터리 루트에 다음 내용의 .gitlab-ci.yml 파일을 추가하세요:

    include:
      - template: Auto-DevOps.gitlab-ci.yml
    
  2. .gitlab-ci.yml 파일에 변경 사항을 추가하세요. 변경 사항은 Auto DevOps 템플릿과 병합됩니다. include가 변경 사항을 병합하는 방법에 대한 자세한 내용은 include 문서를 참조하세요.

Auto DevOps 파이프라인에서 동작을 제거하려면:

  1. Auto DevOps 템플릿을 프로젝트에 복사하세요.
  2. 필요에 따라 템플릿 사본을 편집하세요.

Auto DevOps의 개별 구성 요소 사용#

Auto DevOps에서 제공하는 기능의 일부만 필요한 경우 자체 .gitlab-ci.yml에 개별 Auto DevOps 작업을 포함할 수 있습니다. .gitlab-ci.yml 파일에서 각 작업에 필요한 스테이지도 정의해야 합니다.

예를 들어 Auto Build를 사용하려면 .gitlab-ci.yml에 다음을 추가하세요:

stages:
  - build

include:
  - template: Jobs/Build.gitlab-ci.yml

사용 가능한 작업 목록은 Auto DevOps 템플릿을 참조하세요.

여러 Kubernetes 클러스터 사용#

Auto DevOps를 위한 여러 Kubernetes 클러스터를 참조하세요.

Kubernetes 네임스페이스 커스터마이즈#

GitLab 14.5 이하에서는 environment:kubernetes:namespace를 사용하여 환경의 네임스페이스를 지정할 수 있었습니다. 그러나 이 기능은 인증서 기반 통합과 함께 Deprecated되었습니다.

이제 KUBE_NAMESPACE 환경 변수를 사용하고 환경 범위를 제한해야 합니다.

로컬 Docker 레지스트리에서 호스팅된 이미지 사용#

많은 Auto DevOps 작업이 오프라인 환경에서 실행되도록 구성할 수 있습니다:

  1. Docker Hub 및 registry.gitlab.com에서 필요한 Auto DevOps Docker 이미지를 로컬 GitLab 컨테이너 레지스트리에 복사하세요.

  2. 이미지가 로컬 레지스트리에서 호스팅되고 사용 가능해지면 로컬에서 호스팅된 이미지를 가리키도록 .gitlab-ci.yml을 편집하세요. 예:

    include:
      - template: Auto-DevOps.gitlab-ci.yml
    
    variables:
      REGISTRY_URL: "registry.gitlab.example"
    
    build:
      image: "$REGISTRY_URL/docker/auto-build-image:v0.6.0"
      services:
        - name: "$REGISTRY_URL/greg/docker/docker:20.10.16-dind"
          command: ['--tls=false', '--host=tcp://0.0.0.0:2375']
    

PostgreSQL 데이터베이스 지원#

Warning

기본적으로 PostgreSQL 데이터베이스를 프로비저닝하는 것은 GitLab 15.8에서 Deprecated되었으며 16.0부터는 기본값이 되지 않습니다. 데이터베이스 프로비저닝을 활성화하려면 관련 CI/CD 변수를 설정하세요.

데이터베이스가 필요한 애플리케이션을 지원하기 위해 기본적으로 PostgreSQL이 프로비저닝됩니다. 데이터베이스에 접근하기 위한 자격 증명이 사전 구성되어 있습니다.

자격 증명을 커스터마이즈하려면 관련 CI/CD 변수를 설정하세요. 커스텀 DATABASE_URL도 정의할 수 있습니다:

postgres://user:password@postgres-host:postgres-port/postgres-database

PostgreSQL 업그레이드#

GitLab은 기본적으로 차트 버전 8.2.1을 사용하여 PostgreSQL을 프로비저닝합니다. 버전은 0.7.1에서 8.2.1까지 설정할 수 있습니다.

이전 차트 버전을 사용하는 경우 최신 PostgreSQL로 데이터베이스를 마이그레이션해야 합니다.

기본 프로비저닝된 PostgreSQL을 제어하는 CI/CD 변수 AUTO_DEVOPS_POSTGRES_CHANNELGitLab 13.0에서 2로 변경되었습니다. 이전 PostgreSQL을 사용하려면 AUTO_DEVOPS_POSTGRES_CHANNEL 변수를 1로 설정하세요.

PostgreSQL Helm 차트의 값 커스터마이즈#

커스텀 값을 설정하려면 다음 중 하나를 수행하세요:

  • 리포지터리에 .gitlab/auto-deploy-postgres-values.yaml이라는 파일을 추가하세요. 발견되면 이 파일이 자동으로 사용됩니다. 이 파일은 기본적으로 PostgreSQL Helm 업그레이드에 사용됩니다.
  • 리포지터리에 다른 이름이나 경로를 가진 파일을 추가하고 경로와 이름을 사용하여 POSTGRES_HELM_UPGRADE_VALUES_FILE 환경 변수를 설정하세요.
  • POSTGRES_HELM_UPGRADE_EXTRA_ARGS 환경 변수를 설정하세요.

외부 PostgreSQL 데이터베이스 제공자 사용#

Auto DevOps는 프로덕션 환경을 위한 PostgreSQL 컨테이너를 즉시 지원합니다. 그러나 AWS Relational Database Service와 같은 외부 관리형 제공자를 사용할 수도 있습니다.

외부 관리형 제공자를 사용하려면:

  1. 환경 범위 CI/CD 변수를 사용하여 필요한 환경에 대한 내장 PostgreSQL 설치를 비활성화하세요. 리뷰 앱 및 스테이징을 위한 내장 PostgreSQL 설정으로 충분하기 때문에 production에 대해서만 설치를 비활성화하면 될 수 있습니다.

    Auto Metrics

  2. 애플리케이션에서 사용 가능한 환경 범위 변수로 DATABASE_URL 변수를 정의하세요. 이는 다음 형식의 URL이어야 합니다:

    postgres://user:password@postgres-host:postgres-port/postgres-database
    
  3. Kubernetes 클러스터가 PostgreSQL이 호스팅되는 곳에 네트워크로 접근할 수 있는지 확인하세요.