Auto DevOps 사용자 정의

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

Auto DevOps의 구성 요소를 귀하의 요구에 맞게 사용자 정의할 수 있습니다. 예를 들어, 다음을 수행할 수 있습니다:

Auto DevOps 배너

Auto DevOps가 활성화되지 않은 경우, 최소 Maintainer 역할을 가진 사용자에게 배너가 표시됩니다:

Auto DevOps 배너

배너는 다음에 대해 비활성화할 수 있습니다:

  • 사용자가 스스로 배너를 종료할 경우.
  • 프로젝트에서 명시적으로 Auto DevOps 비활성화를 통해.
  • 전체 GitLab 인스턴스에서:

    • 관리자가 Rails 콘솔에서 다음을 실행하여:

      Feature.enable(:auto_devops_banner_disabled)

    • 관리 액세스 토큰을 사용하여 REST API를 통해:

      curl --data "value=true" --header "PRIVATE-TOKEN: <personal_access_token>" "https://gitlab.example.com/api/v4/features/auto_devops_banner_disabled"

사용자 지정 buildpacks

프로젝트에 대한 자동 buildpack 감지가 실패할 때나 빌드에 대한 제어가 더 필요할 때 사용자 지정 buildpacks를 사용할 수 있습니다.

Cloud Native Buildpacks로 buildpacks 사용자 정의

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

여러 buildpacks

Auto Test는 .buildpacks 파일을 사용할 수 없으므로 Auto DevOps는 여러 buildpacks를 지원하지 않습니다. buildpack
heroku-buildpack-multi는 .buildpacks 파일을 구문 분석하는 데 사용되지만 필요한 명령 bin/test-compile 및 bin/test를 제공하지 않습니다.

단일 사용자 지정 buildpack만 사용하려면 프로젝트 CI/CD 변수
BUILDPACK_URL을 제공해야 합니다.

사용자 지정 Dockerfiles

프로젝트 리포지토리의 루트에 Dockerfile이 있는 경우, Auto DevOps는 해당 Dockerfile을 기반으로 Docker 이미지를 빌드합니다. 이는 buildpack을 사용하는 것보다 더 빠를 수 있습니다. 또한 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 인코딩을 사용하세요. 복잡한 비인코딩 값은 문자 이스케이프에 문제를 일으킬 수 있습니다.

caution
비밀 값은 Docker 빌드 인수로 전달하지 마세요. 비밀은 이미지에 남아 있을 수 있습니다. 비밀과 관련된 모범 사례에 대한 자세한 정보는
이 논의를 참조하세요.

사용자 지정 컨테이너 이미지

기본적으로 자동 배포는 자동 빌드에 의해 빌드되고 GitLab 레지스트리에 푸시된 컨테이너 이미지를 배포합니다.

특정 변수를 정의하여 이 동작을 재정의할 수 있습니다:

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

이 변수들은 또한 자동 빌드 및 자동 컨테이너 스캐닝에 영향을 미칩니다. $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로 자동 DevOps 확장

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

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

CI/CD 변수를 빌드 환경으로 전달하려면 전달하려는 변수의 이름을 AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES CI/CD 변수에 추가합니다.

여러 변수를 쉼표로 구분하세요.

예를 들어, CI_COMMIT_SHA와 CI_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가 설정되면, 자동 DevOps는 실험적인 Docker BuildKit 기능을 사용하여 --secret 플래그를 사용할 수 있도록 합니다.

사용자 지정 Helm 차트

자동 DevOps는 Helm을 사용하여 응용 프로그램을 Kubernetes에 배포합니다.

프로젝트 리포지토리에 차트를 번들하여 또는 프로젝트 CI/CD 변수를 지정하여 사용하는 Helm 차트를 재정의할 수 있습니다:

  • 번들 차트 - 프로젝트에 ./chart 디렉토리와 그 안에 Chart.yaml 파일이 있으면, 자동 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 차트 값 사용자 정의

values.yaml 파일의 기본 값을 재정의하려면

기본 Helm 차트에서, 다음 중 하나를 수행하십시오:

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

일부 값은 위의 옵션으로 재정의할 수 없지만, 이 문제는 이 동작을 변경할 것을 제안합니다.
replicaCount와 같은 설정을 재정의하려면 REPLICAS 빌드 및 배포 CI/CD 변수를 사용하십시오.

helm upgrade 사용자 정의

auto-deploy-image는 helm 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는 Auto DevOps 템플릿
이 .gitlab-ci.yml 파일의 구현이므로 매우 사용자 정의가 가능합니다.
이 템플릿은 모든 .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를 사용하려면 다음을 추가할 수 있습니다:

stages:
  - build

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

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

여러 Kubernetes 클러스터 사용

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

Kubernetes 네임스페이스 사용자 정의

GitLab 14.5 이전에는 environment:kubernetes:namespace를 사용하여 환경에 대한 네임스페이스를 지정할 수 있었습니다. 그러나 이 기능은 더 이상 사용되지 않음으로 표시되었으며, 인증서 기반 통합도 함께 중단되었습니다.

이제는 KUBE_NAMESPACE 환경 변수를 사용하고 환경 범위를 제한하세요.

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

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

  1. 필요한 Auto DevOps Docker 이미지를 Docker Hub 및 registry.gitlab.com에서 로컬 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 데이터베이스 지원

경고: 기본적으로 PostgreSQL 데이터베이스를 프로비저닝하는 것은 더 이상 사용되지 않음으로 표시되었으며, GitLab 16.0부터는 기본값이 되지 않습니다. 데이터베이스 프로비저닝을 활성화하려면 관련된 CI/CD 변수를 설정하세요.

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

자격 증명을 사용자 정의하려면 관련된 CI/CD 변수를 설정하세요. 또한 다음과 같이 사용자 정의 DATABASE_URL을 정의할 수 있습니다:

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

PostgreSQL 업그레이드

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

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

기본 프로비저닝된 PostgreSQL을 제어하는 CI/CD 변수 AUTO_DEVOPS_POSTGRES_CHANNEL은 GitLab 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 관리형 데이터베이스 서비스와 같은 외부 관리 제공업체를 사용하고 싶을 수 있습니다.

외부 관리 제공업체를 사용하려면:

  1. 필요한 환경에 대해 내장된 PostgreSQL 설치를 비활성화합니다. CI/CD 변수에 환경 범위 변수를 사용하세요. 검토 앱과 스테이징을 위한 내장된 PostgreSQL 설정으로 충분하므로 production에 대해서만 설치를 비활성화해야 할 수 있습니다.

    자동 메트릭스

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

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

  3. Kubernetes 클러스터가 PostgreSQL이 호스팅되는 곳으로 네트워크 액세스가 가능하도록 확인합니다.