Auto DevOps 커스터마이즈

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

귀하의 요구에 맞게 Auto DevOps 구성요소를 커스터마이즈할 수 있습니다. 예를 들어 다음과 같은 작업을 수행할 수 있습니다.

Auto DevOps 배너

Auto DevOps가 비활성화된 경우, 적어도 Maintainer 권한을 가진 사용자에게 배너가 표시됩니다:

Auto DevOps banner

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

  • 사용자가 직접 해제한 경우.
  • 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"

사용자 정의 빌드팩

프로젝트의 자동 빌드팩 감지에 실패한 경우 또는 빌드를 보다 세밀하게 제어해야 하는 경우 빌드팩을 사용자 정의할 수 있습니다.

Cloud Native Buildpacks를 사용하여 빌드팩 사용자 정의

다음 중 하나를 지정합니다:

다중 빌드팩

Auto Test에서 .buildpacks 파일을 사용할 수 없기 때문에 Auto DevOps는 다중 빌드팩을 지원하지 않습니다. 뒷단에서 .buildpacks 파일의 파싱에 사용되는 buildpack인 heroku-buildpack-multi에서 필요한 명령어 ‘bin/test-compile’ 및 ‘bin/test’를 제공하지 않습니다.

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

사용자 정의 Dockerfiles

프로젝트 리포지터리 루트에 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 인코딩을 사용하세요. Base64로 인코딩되지 않은 복잡한 값은 문자 이스케이핑 문제를 일으킬 수 있습니다.

caution
Docker 빌드 인수에 비밀을 전달하지 마십시오. 비밀은 이미지에 지속될 수 있습니다. 자세한 내용은 비밀 관련 모범 사례에 대한 토론을 참조하세요.

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

기본적으로 Auto Deploy는 Auto 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 및 Auto Container Scanning에도 영향을 미칩니다. $CI_APPLICATION_REPOSITORY:$CI_APPLICATION_TAG로 이미지를 빌드하고 푸시하고 싶지 않다면 Jobs/Deploy.gitlab-ci.yml만 포함하거나 빌드 작업 비활성화를 수행하세요.

Auto Container Scanning을 사용하고 $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_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에서 $COMMAND를 실행하기 전에 비밀 파일을 마운트하고 소스를 실행하여 --run=type=secret,id=auto-devops-build-secrets를 추가합니다: 

    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는 실험적인 Docker BuildKit 기능을 활성화하여 --secret 플래그를 사용합니다.

사용자 정의 Helm 차트

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

  • 번들된 차트 - 프로젝트에 ./chart 디렉터리와 그 안에 Chart.yaml 파일이 있는 경우, 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 차트(default Helm chart)의 values.yaml 파일의 기본 값을 재정의하려면 다음 중 하나를 수행하십시오.

  • 리포지터리에 .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 사용자 정의하기

자동 DevOps는 자동 DevOps 템플릿의 구현인 .gitlab-ci.yml 파일을 사용하므로 매우 사용자 정의할 수 있습니다. 이 템플릿은 .gitlab-ci.yml의 모든 구현에서 사용 가능한 기능만 사용합니다.

자동 DevOps 파이프라인에 사용자 지정 동작을 추가하려면 다음을 수행하십시오:

  1. 리포지터리 루트에 다음 내용이 포함된 .gitlab-ci.yml 파일을 추가하십시오. 

    include:
  - template: Auto-DevOps.gitlab-ci.yml

  2. .gitlab-ci.yml 파일에 변경 사항을 추가하십시오. 변경된 내용은 자동 DevOps 템플릿과 Merge됩니다. 변경 내용을 Merge하는 include의 동작에 대한 자세한 내용은 include 문서를 참조하십시오.

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

  1. 프로젝트로 자동 DevOps 템플릿을 복사하십시오.
  2. 필요에 따라 템플릿을 편집하십시오.

자동 DevOps의 개별 구성요소 사용

자동 DevOps가 제공하는 기능 중 일부만 필요한 경우, 자체 .gitlab-ci.yml에 개별 자동 DevOps 작업을 포함할 수 있습니다. .gitlab-ci.yml 파일에서 각 작업에 필요한 stage를 정의하십시오.

예를 들어 자동 빌드를 사용하려면 다음을 .gitlab-ci.yml에 추가하십시오: 

stages:
  - build

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

사용 가능한 작업 디렉터리은 자동 DevOps 템플릿을 참조하십시오.

여러 Kubernetes 클러스터 사용

자동 DevOps를 위한 여러 Kubernetes 클러스터 참조.

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

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

이제 KUBE_NAMESPACE 환경 변수를 사용하고 그 환경 범위를 제한하십시오.

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

오프라인 환경에서 여러 자동 DevOps 작업을 구성할 수 있습니다.

  1. 필요한 자동 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 데이터베이스 지원

caution
기본적으로 PostgreSQL 데이터베이스를 프로비저닝하는 것은 폐지되었습니다 GitLab 15.8에서 폐지되었으며 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을 사용하려면 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 환경 변수를 설정하십시오.

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

자동 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이 호스팅되는 위치에 네트워크 액세스 권한이 있는지 확인하십시오.