- Auto DevOps 배너
- 사용자 정의 빌드팩
- 사용자 정의 Docker 파일
- 사용자 지정 컨테이너 이미지
- API를 사용하여 Auto DevOps 확장
- CI/CD 변수를 빌드 환경으로 전달
- 사용자 정의 Helm 차트
-
.gitlab-ci.yml
사용자 정의 - 여러 Kubernetes 클러스터 사용하기
- Kubernetes 네임스페이스 사용자 정의
- 로컬 Docker 레지스트리에 호스팅된 이미지 사용하기
- PostgreSQL 데이터베이스 지원
Auto DevOps 사용자 지정
귀하의 요구에 맞게 Auto DevOps 구성 요소를 사용자 정의할 수 있습니다. 예를 들어 다음과 같은 작업을 수행할 수 있습니다.
- 사용자 정의 빌드팩, 도커 파일 및 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: <개인_액세스_토큰>" "https://gitlab.example.com/api/v4/features/auto_devops_banner_disabled"
-
사용자 정의 빌드팩
프로젝트에서 다음 중 하나가 발생할 때 빌드팩을 사용자 정의할 수 있습니다.
- 프로젝트의 자동 빌드팩 감지가 실패한 경우
- 빌드에 대한 더 많은 제어가 필요한 경우
Cloud Native Buildpacks로 빌드팩 사용자 정의
- GitLab 12.10에서 도입.
다음 중 하나를 지정합니다.
-
pack
의 URI 지정 형식 중 하나와 함께 CI/CD 변수BUILDPACK_URL
- 빌드에 포함하고자 하는 빌드팩이 포함된
project.toml
프로젝트 설명자
Herokuish로 빌드팩 사용자 정의 (사용 중지됨)
경고: Herokuish 지원은 GitLab 15.8에서 사용 중지되었으며 17.0에서 제거될 예정입니다. 대신 Cloud Native Buildpacks를 사용하십시오.
다음 중 하나를 지정합니다.
- CI/CD 변수
BUILDPACK_URL
- 프로젝트 루트에 있는
.buildpacks
파일, 파일에는 한 줄에 하나의 빌드팩 URL이 포함됨
빌드팩 URL은 Git 저장소 URL 또는 tarball URL을 가리킬 수 있습니다.
Git 저장소에 대해 특정 Git 참조를 가리키려면 Git 저장소 URL에 #<ref>
를 추가합니다. 예를 들어 다음을 참조할 수 있습니다.
- 태그
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
을 제공해야 합니다.
사용자 정의 Docker 파일
DOCKERFILE_PATH
가 GitLab 13.2에서 도입되었습니다.
프로젝트 저장소의 루트에 Dockerfile이 있는 경우, Auto DevOps는 Dockerfile을 기반으로 Docker 이미지를 빌드합니다. 이는 빌드팩을 사용하는 것보다 빠를 수 있습니다. 특히 Dockerfile이 Alpine을 기반으로 하는 경우 이미지가 더 작을 수도 있습니다.
DOCKERFILE_PATH
CI/CD 변수를 설정하면 Auto Build는 대신 해당 위치에 Dockerfile을 찾습니다.
docker build
에 인수 전달하기
docker build
에 인수를 전달하려면 AUTO_DEVOPS_BUILD_IMAGE_EXTRA_ARGS
프로젝트 CI/CD 변수를 사용합니다.
예를 들어, 기본 ruby:latest
대신 ruby:alpine
을 기반으로 하는 도커 이미지를 빌드하려면 다음과 같이 설정합니다:
-
AUTO_DEVOPS_BUILD_IMAGE_EXTRA_ARGS
를--build-arg=RUBY_VERSION=alpine
로 설정합니다. -
커스텀 Dockerfile에 다음을 추가합니다:
ARG RUBY_VERSION=latest FROM ruby:$RUBY_VERSION # ... 여기에 작성하세요
스페이스나 새 줄 같은 복잡한 값은 Base64 인코딩을 사용하여 전달합니다. 복잡하고 인코딩되지 않은 값은 문자 이스케이핑 문제를 일으킬 수 있습니다.
경고: 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
만 포함하거나
build
작업을 비활성화하세요.
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 구성을 확장하고 관리할 수 있습니다:
-
API 호출을 사용하여 설정에 액세스,
그 중에
auto_devops_enabled
를 포함해서 프로젝트에서 기본적으로 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을 사용하는 경우:
-
실험적인 Dockerfile 구문을 활성화하려면 Dockerfile에 다음을 추가하세요:
# syntax = docker/dockerfile:experimental
-
시크릿을
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는 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 차트 값 사용자 정의
- 소개된 GitLab 12.6에서
.gitlab/auto-deploy-values.yaml
은 Helm 업그레이드에 기본적으로 사용됩니다.
values.yaml
파일에서 기본값을 재정의하려면
기본 Helm 차트에서 다음을 수행하세요:
-
.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
실행 시 pre- 및 post-upgrade 훅을 비활성화하려면:
variables:
HELM_UPGRADE_EXTRA_ARGS: --no-hooks
옵션의 전체 목록은 공식 helm upgrade
문서를 참조하세요.
Helm 차트를 하나의 환경으로 제한하기
사용자 정의 차트를 하나의 환경으로 제한하려면, CI/CD 변수에 환경 범위를 추가하세요. 자세한 내용은 CI/CD 변수의 환경 범위 제한하기를 참조하세요.
.gitlab-ci.yml
사용자 정의
자동화 DevOps는 Auto DevOps 템플릿이 .gitlab-ci.yml
파일의 구현이기 때문에 매우 사용자 정의할 수 있습니다.
이 템플릿은 .gitlab-ci.yml
의 어떤 구현에서도 사용 가능한 기능만 사용합니다.
Auto DevOps 파이프라인에 사용자 정의 동작을 추가하려면:
-
리포지토리 루트에 다음 내용을 가진
.gitlab-ci.yml
파일을 추가하세요:include: - template: Auto-DevOps.gitlab-ci.yml
-
.gitlab-ci.yml
파일에 변경 사항을 추가하세요. 변경 사항은 Auto DevOps 템플릿과 병합됩니다. 변경 사항을 병합하는include
에 대한 자세한 내용은 include 문서를 참조하세요.
Auto DevOps 파이프라인에서 동작을 제거하려면:
- Auto DevOps 템플릿을 프로젝트에 복사하세요.
- 필요에 따라 템플릿을 편집하세요.
Auto DevOps의 개별 구성 요소 사용하기
Auto DevOps가 제공하는 기능의 하위 집합만 필요한 경우, 자체 .gitlab-ci.yml
에 개별 Auto DevOps 작업을 포함시킬 수 있습니다.
각 작업에 필요한 stage도 꼭 정의하세요.
예를 들어, Auto Build를 사용하려면, .gitlab-ci.yml
에 다음을 추가하세요:
stages:
- build
include:
- template: Jobs/Build.gitlab-ci.yml
사용 가능한 작업 목록은 Auto DevOps 템플릿을 참조하세요.
경고:
GitLab 13.0부터, only
또는 except
를 사용하는 Auto DevOps 템플릿은 rules
구문으로 전환되었습니다.
만약 .gitlab-ci.yml
이 이러한 Auto DevOps 템플릿을 확장하고 only
또는 except
을 오버라이드한다면, 템플릿을
rules
구문으로 이전하세요.
이전할 수 없는 경우, 템플릿을 GitLab 12.10 기반 템플릿에 고정할 수 있습니다.
여러 Kubernetes 클러스터 사용하기
Auto DevOps를 위한 여러 Kubernetes 클러스터를 참조하십시오.
Kubernetes 네임스페이스 사용자 정의
GitLab 14.5 및 이전 버전에서는 환경에 대한 네임스페이스를 지정하기 위해 environment:kubernetes:namespace
을(를) 사용할 수 있었습니다.
그러나 이 기능은 폐기되었으며, certificate 기반 통합과 함께 폐기되었습니다.
이제 KUBE_NAMESPACE
환경 변수를 사용하고 환경 범위를 제한해야 합니다.
로컬 Docker 레지스트리에 호스팅된 이미지 사용하기
많은 Auto DevOps 작업을 오프라인 환경에서 실행하도록 구성할 수 있습니다:
- 필요한 Auto DevOps Docker 이미지를 Docker Hub 및
registry.gitlab.com
에서 로컬 GitLab 컨테이너 레지스트리로 복사합니다. -
이미지가 호스팅되고 로컬 레지스트리에서 사용 가능한 경우
.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 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로 마이그레이션해야 합니다.
AUTO_DEVOPS_POSTGRES_CHANNEL
CI/CD 변수는 기본적으로 프로비저닝된 PostgreSQL을 제어합니다.
GitLab 13.0에서 이전 PostgreSQL을 사용하려면 AUTO_DEVOPS_POSTGRES_CHANNEL
변수를 1
로 설정하십시오.
PostgreSQL Helm 차트를 위한 값 사용자 정의
- auto-deploy-image v2와 함께 GitLab 13.8에서 도입되었습니다.
사용자 정의 값을 설정하려면 다음 중 하나를 수행하십시오:
- 저장소에
.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와 같은 외부 관리 제공업체를 사용하고 싶을 수 있습니다.
외부 관리 제공업체를 사용하려면 다음을 수행하십시오:
-
Review Apps 및 스테이징을 위해 기본 PostgreSQL 설정을 비활성화하려면 환경 범위에 따라 CI/CD 변수를 비활성화하십시오. Review Apps 및 스테이징을 위해 기본 PostgreSQL 설정은 충분하므로
production
에 대해서만 비활성화하면 될 것입니다. -
DATABASE_URL
변수를 애플리케이션에서 이용할 수 있도록 환경 범위로 설정하십시오. 이는 다음과 같은 형식의 URL이어야 합니다:postgres://user:password@postgres-host:postgres-port/postgres-database
-
Kubernetes 클러스터가 PostgreSQL이 호스팅된 위치에 네트워크 액세스할 수 있도록 확인하십시오.