• Auto DevOps 배너
• 사용자 정의 빌드팩
  • 클라우드 네이티브 빌드팩으로 빌드팩 사용자 정의
  • Herokuish로 빌드팩 사용자 정의 (사용 중단됨)
  • 다중 빌드팩
• 사용자 정의 Dockerfiles
  • docker build에 인수 전달
• 자체 컨테이너 이미지
• API를 사용하여 Auto DevOps 구성 확장
• CI/CD 변수를 빌드 환경으로 전달기
• 사용자 정의 Helm 차트
  • Helm 차트 값을 사용자 정의하기
  • helm upgrade를 사용자 정의하기
  • Helm 차트를 하나의 환경에 제한하기
• .gitlab-ci.yml 사용자 정의하기
  • Auto DevOps의 개별 컴포넌트 사용
• 다중 Kubernetes 클러스터 사용
• Kubernetes 네임스페이스 사용자 정의
• 로컬 Docker 레지스트리에 호스팅된 이미지 사용
• PostgreSQL 데이터베이스 지원
  • PostgreSQL 업그레이드
  • PostgreSQL Helm 차트를 위한 값 사용자 정의
  • 외부 PostgreSQL 데이터베이스 제공업체 사용

Auto DevOps 사용자 정의

Auto DevOps 컴포넌트를 사용자의 요구에 맞게 사용자 정의할 수 있습니다. 예를 들어, 다음을 수행할 수 있습니다:

• 사용자 정의 빌드팩, Dockerfiles, 및 Helm 차트 추가.
• 사용자 정의 CI/CD 구성으로 스테이징 및 카나리 배포 활성화.
• GitLab API로 Auto DevOps 확장.

Auto DevOps 배너

Auto DevOps가 활성화되지 않은 경우, 적어도 Maintainer 역할을 가진 사용자를 위해 배너가 표시됩니다:

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

• 사용자가 직접 닫을 때.
• 프로젝트가 명시적으로 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"
    

사용자 정의 빌드팩

다음 상황에서 빌드팩을 사용자 정의할 수 있습니다:

• 프로젝트에 대한 자동 빌드팩 감지가 실패한 경우.
• 빌드에 대한 더 많은 제어가 필요한 경우.

클라우드 네이티브 빌드팩으로 빌드팩 사용자 정의

• GitLab 12.10에 도입.

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

• pack의 URI 지정 형식 중 하나를 사용하여 CI/CD 변수 BUILDPACK_URL을 사용합니다.
• 빌드팩을 포함하고 싶은 project.toml 프로젝트 설명자인 .toml 프로젝트 기술서를 사용합니다.

Herokuish로 빌드팩 사용자 정의 (사용 중단됨)

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

• CI/CD 변수 BUILDPACK_URL을 사용합니다.
• 프로젝트 루트에 있는 .buildpacks 파일을 사용합니다. 이 파일에는 한 줄에 하나의 빌드팩 URL이 포함되어 있습니다.

빌드팩 URL은 Git 리포지터리 URL 또는 tarball URL을 가리킬 수 있습니다.

Git 리포지터리의 경우, Git 리포지터리 URL 뒤에 #<ref>를 추가하여 특정 Git 참조를 가리킬 수 있습니다. 예를 들어 다음과 같이 가리킬 수 있습니다:

• 태그 v142: https://github.com/heroku/heroku-buildpack-ruby.git#v142.
• 브랜치 mybranch: https://github.com/heroku/heroku-buildpack-ruby.git#mybranch.
• 커밋 SHA f97d8a8ab49: https://github.com/heroku/heroku-buildpack-ruby.git#f97d8a8ab49.

다중 빌드팩

Auto Test는 .buildpacks 파일을 사용할 수 없기 때문에 Auto DevOps는 여러 빌드팩을 지원하지 않습니다. 백엔드에서 .buildpacks 파일을 구문 분석하는 데 사용되는 빌드팩 heroku-buildpack-multi은 bin/test-compile 및 bin/test과 같은 필요한 명령을 제공하지 않습니다.

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

사용자 정의 Dockerfiles

• GitLab 13.2에서 DOCKERFILE_PATH가 도입되었습니다.

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

DOCKERFILE_PATH CI/CD 변수를 설정하면 Auto 빌드는 거기서 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 인코딩을 사용해서 전달해야 합니다. 복잡하고 인코딩되지 않은 값은 문자 이스케이핑 문제를 일으킬 수 있습니다.

자체 컨테이너 이미지

기본적으로 Auto Deploy는 Auto Build에 의해 GitLab 레지스트리에 빌드 및 푸시된 컨테이너 이미지를 배포합니다. 다음을 정의하여 이 동작을 재정의할 수 있습니다.

이러한 변수는 Auto Build 및 Auto 컨테이너 스캐닝에 영향을 미칩니다. $CI_APPLICATION_REPOSITORY:$CI_APPLICATION_TAG에 이미지를 빌드하고 푸시하고 싶지 않다면, Jobs/Deploy.gitlab-ci.yml만 포함하거나 cicd_variables.md#job-disabling-variables를 사용하여 build 작업을 비활성화할 수 있습니다.

Auto 컨테이너 스캐닝을 사용하고 $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 구성 확장

Auto DevOps 구성을 GitLab API로 확장하고 관리할 수 있습니다.

• API 호출을 사용하여 설정에 액세스 auto_devops_enabled를 포함한 설정에 액세스하여 프로젝트에 기본값으로 Auto DevOps를 활성화합니다.
• 새 프로젝트를 만듭니다.
• 그룹을 편집합니다.
• 프로젝트를 편집합니다.

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

• GitLab 12.3에서 도입.

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

Buildpacks를 사용하는 경우 전달된 변수는 자동으로 환경 변수로 사용할 수 있습니다.

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

사용자 정의 Helm 차트

Auto DevOps는 애플리케이션을 Kubernetes로 배포하기 위해 Helm을 사용합니다. 프로젝트 리포지터리에 차트를 번들링하거나 프로젝트 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 차트 값을 사용자 정의하기

• GitLab 12.6에서 도입, 기본으로 .gitlab/auto-deploy-values.yaml 파일이 Helm 업그레이드에 사용됩니다.

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

• 리포지터리에 .gitlab/auto-deploy-values.yaml 파일을 추가합니다. 이 파일이 자동으로 사용됩니다.
• 파일의 이름이나 경로가 다른 파일을 리포지터리에 추가합니다. 경로와 파일의 이름을 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 파일의 구현으로 사용하는 데, 이 템플릿은 어떤 구현에서도 사용 가능한 기능만 사용합니다.

Auto DevOps에서 사용되는 CI/CD 파이프라인에 사용자 정의 동작을 추가하려면:

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

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

2. .gitlab-ci.yml 파일에 변경 사항을 추가합니다. 변경 사항이 Auto DevOps 템플릿과 Merge됩니다. include가 변경 사항을 Merge하는 방법에 대한 자세한 정보는 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. 필요한 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이 프로비저닝됩니다. 데이터베이스 액세스 자격 증명은 사전 구성되어 있습니다.

자격 증명을 사용자 정의하려면 관련된 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로 설정할 수 있습니다.

더 오래된 차트 버전을 사용 중이라면, 데이터베이스를 마이그레이션해야 합니다.

AUTO_DEVOPS_POSTGRES_CHANNEL CI/CD 변수를 사용하여 기본적으로 프로비저닝되는 PostgreSQL의 제어가 GitLab 13.0에서 2로 변경되었습니다. 구버전 PostgreSQL을 사용하려면 AUTO_DEVOPS_POSTGRES_CHANNEL 변수를 1로 설정하십시오.

PostgreSQL Helm 차트를 위한 값 사용자 정의

• Auto-deploy-image v2로 소개됨

사용자 정의 값을 설정하려면 다음 중 하나를 수행하십시오:

• .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. 필요한 환경에 대해 기본적으로 제공되는 PostgreSQL 설치를 비활성화하십시오. 환경 범위가 있는 CI/CD 변수를 비활성화해야 합니다. 리뷰 앱 및 스테이징을 위한 기본 PostgreSQL 설정이 충분하므로, production에 대해서만 비활성화할 수 있을 것입니다.

   

2. DATABASE_URL 변수를 환경 범위 변수로 정의하여 사용 가능하도록 하십시오. 이것은 다음 형식의 URL이어야 합니다:

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

3. Kubernetes 클러스터가 PostgreSQL이 호스팅된 위치에 네트워크 액세스 권한이 있는지 확인하십시오.