환경과 배포

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

환경은 코드가 배포되는 위치를 설명합니다.

매번 GitLab CI/CD가 환경에 코드 버전을 배포할 때마다, 배포가 생성됩니다.

GitLab은:

각 환경에 대한 배포의 전체 이력을 제공합니다.
배포를 추적하여 항상 서버에 배포된 내용을 알 수 있습니다.

프로젝트와 연관된 배포 서비스가 있다면, 예를 들어 Kubernetes, 이를 사용하여 배포를 지원할 수 있습니다.

환경 및 배포 보기

사전 요구사항:

개인 프로젝트에서는 최소한 Reporter 역할이 필요합니다. 환경 권한을 참조하세요.

주어진 프로젝트의 환경 목록을 보는 방법은 몇 가지가 있습니다:

프로젝트의 개요 페이지에서, 최소한 하나의 환경이 사용 가능할 경우(정지되지 않은 상태여야 함).
왼쪽 사이드바에서 Operate > Environments를 선택합니다.
환경이 표시됩니다.
환경의 배포 목록을 보려면 환경 이름을 선택합니다.
예를 들어, staging.

배포는 배포 작업이 생성된 후에만 이 목록에 나타납니다.

환경 검색

GitLab 15.5에서 도입됨.

GitLab 15.7에서 폴더 내 환경 검색 도입됨, Feature flag enable_environments_search_within_folder. 기본적으로 활성화됨.

GitLab 17.4에서 일반 사용 가능. Feature flag enable_environments_search_within_folder 제거됨.

이름으로 환경을 검색하려면:

왼쪽 사이드바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
Operate > Environments를 선택합니다.
검색창에 검색어를 입력합니다.
- 검색어는 3자 이상이어야 합니다.
- 일치하는 것은 환경 이름의 시작 부분에서 적용됩니다.
  - 예를 들어, devel은 환경 이름 development와 일치하지만, elop는 일치하지 않습니다.
- 폴더 이름 형식의 환경에 대해, 일치는 기본 폴더 이름 이후에 적용됩니다.
  - 예를 들어, 이름이 review/test-app일 경우, 검색어 test는 review/test-app와 일치합니다.
  - 또한, review/test와 같이 폴더 이름이 접두어로 붙으면 review/test-app와 일치합니다.

CI/CD 변수

환경과 배포를 사용자 정의하려면, 모든 미리 정의된 CI/CD 변수를 사용하고, 사용자 정의 CI/CD 변수를 정의할 수 있습니다.

환경 상태

환경 상태는 환경의 정지 작업이 실행되었는지 여부를 나타냅니다.
상태는 세 가지입니다:

available: 환경이 존재합니다. 배포가 있을 수 있습니다.
stopping: _정지 작업_이 시작되었습니다. 이 상태는 정의된 정지 작업이 없을 경우 적용되지 않습니다.
stopped: _정지 작업_이 실행되었거나, 사용자가 수동으로 작업을 정지했습니다.

환경 유형

환경은 정적이거나 동적입니다:

정적 환경
- 일반적으로 연속 배포에 재사용됩니다.
- 정적 이름을 가집니다 - 예를 들어, staging 또는 production.
- 수동으로 생성되거나 CI/CD 파이프라인의 일환으로 생성됩니다.
동적 환경
- 일반적으로 CI/CD 파이프라인에서 생성되며 단일 배포에만 사용되며, 이후에는 중지되거나 삭제됩니다.
- 동적 이름을 가지며, 보통 CI/CD 변수의 값을 기반으로 합니다.
- 리뷰 앱의 특성입니다.

정적 환경 만들기

UI 또는 .gitlab-ci.yml 파일에서 정적 환경을 만들 수 있습니다.

UI에서

필수 조건:

최소한 개발자 역할이 있어야 합니다.

UI에서 정적 환경을 만들려면:

왼쪽 사이드바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
Operate > Environments를 선택합니다.
Create an environment를 선택합니다.
필드를 완료합니다.
Save를 선택합니다.

`.gitlab-ci.yml` 파일에서

필수 조건:

최소한 개발자 역할이 있어야 합니다.

.gitlab-ci.yml 파일에서 정적 환경을 만들려면:

deploy 단계에서 작업을 정의합니다.
작업에서 환경의 name과 url을 정의합니다. 파이프라인이 실행될 때 해당 이름의 환경이 존재하지 않으면 생성됩니다.

참고: 일부 문자는 환경 이름에 사용할 수 없습니다. environment 키워드에 대한 자세한 내용은 .gitlab-ci.yml 키워드 참조를 참조하세요.

예를 들어, staging이라는 이름의 환경을 URL https://staging.example.com으로 생성하려면:

deploy_staging:
  stage: deploy
  script:
    - echo "Deploy to staging server"
  environment:
    name: staging
    url: https://staging.example.com

동적 환경 만들기

동적 환경을 만들려면 각 파이프라인에 고유한 CI/CD 변수를 사용합니다.

필수 조건:

최소한 개발자 역할이 있어야 합니다.

.gitlab-ci.yml 파일에서 동적 환경을 만들려면:

deploy 단계에서 작업을 정의합니다.
작업에서 다음 환경 속성을 정의합니다:
- name: $CI_COMMIT_REF_SLUG와 같은 관련 CI/CD 변수를 사용합니다. 선택적으로, 환경 이름에 정적 접두사를 추가하여 UI에서 그룹화합니다.
- url: 선택적. $CI_ENVIRONMENT_SLUG와 같은 관련 CI/CD 변수를 사용하여 호스트 이름에 접두사를 붙입니다.

참고: 일부 문자는 환경 이름에 사용할 수 없습니다. environment 키워드에 대한 자세한 내용은 .gitlab-ci.yml 키워드 참조를 참조하세요.

다음 예제에서는 deploy_review_app 작업이 실행될 때마다 환경의 이름과 URL이 고유한 값을 사용하여 정의됩니다.

deploy_review_app:
  stage: deploy
  script: make deploy
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: https://$CI_ENVIRONMENT_SLUG.example.com
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: never
    - if: $CI_COMMIT_BRANCH

동적 환경 URL 설정하기

일부 외부 호스팅 플랫폼은 각 배포에 대해 무작위 URL을 생성합니다. 예를 들어:
https://94dd65b.amazonaws.com/qa-lambda-1234567. 이는 .gitlab-ci.yml 파일에서 URL을 참조하는 것을 어렵게 만듭니다.

이 문제를 해결하기 위해, 배포 작업을 구성하여 일련의 변수를 보고하도록 할 수 있습니다. 이러한 변수에는 외부 서비스에 의해 동적으로 생성된 URL이 포함됩니다. GitLab은 dotenv (.env) 파일 형식을 지원하며, .env 파일에 정의된 변수로 environment:url 값을 확장합니다.

이 기능을 사용하려면, .gitlab-ci.yml에서 artifacts:reports:dotenv 키워드를 지정하십시오.

또한, environment:url에서 https://$DYNAMIC_ENVIRONMENT_URL와 같이 URL의 정적 부분을 지정할 수 있습니다. 만약 DYNAMIC_ENVIRONMENT_URL의 값이 example.com이라면, 최종 결과는 https://example.com이 됩니다.

review/your-branch-name 환경에 할당된 URL은 UI에서 볼 수 있습니다.

개요는 작업이 완료된 후 동적 URL 설정을 참조하세요.

다음 예제에서는 리뷰 앱이 각 병합 요청에 대해 새로운 환경을 생성합니다:

review 작업은 모든 푸시에서 트리거되며, review/your-branch-name이라는 이름의 환경을 생성하거나 업데이트합니다. 환경 URL은 $DYNAMIC_ENVIRONMENT_URL로 설정됩니다.
review 작업이 완료되면, GitLab은 review/your-branch-name 환경의 URL을 업데이트합니다. 이 과정에서 deploy.env 보고 아티팩트를 파싱하고, 런타임에 생성된 변수 목록을 등록하며, environment:url: $DYNAMIC_ENVIRONMENT_URL을 확장하고 이를 환경 URL로 설정합니다.

review:
  script:
    - DYNAMIC_ENVIRONMENT_URL=$(deploy-script)                                 # 스크립트에서 환경 URL을 가져옵니다.
    - echo "DYNAMIC_ENVIRONMENT_URL=$DYNAMIC_ENVIRONMENT_URL" >> deploy.env    # 값을 dotenv 파일에 추가합니다.
  artifacts:
    reports:
      dotenv: deploy.env                                                       # dotenv 파일을 rails에 보고합니다.
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: $DYNAMIC_ENVIRONMENT_URL                                              # 생성된 변수를 `environment:url`에 설정합니다.
    on_stop: stop_review

stop_review:
  script:
    - ./teardown-environment
  when: manual
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: stop

다음 사항에 유의하세요:

stop_review는 dotenv 보고 아티팩트를 생성하지 않으므로, DYNAMIC_ENVIRONMENT_URL 환경 변수를 인식하지 않습니다. 따라서 stop_review 작업에서 environment:url을 설정하지 않아야 합니다.
환경 URL이 유효하지 않으면(예: URL이 잘못된 형식), 시스템은 환경 URL을 업데이트하지 않습니다.
stop_review에서 실행되는 스크립트가 여러분의 리포지토리에만 존재하고 GIT_STRATEGY: none 또는 GIT_STRATEGY: empty를 사용할 수 없는 경우, 이러한 작업을 위해 병합 요청 파이프라인을 구성하세요. 이는 러너가 기능 브랜치가 삭제된 후에도 리포지토리를 가져올 수 있도록 합니다. 자세한 내용은 러너에 대한 Ref Specs를 참조하세요.

Windows 러너의 경우, PowerShell Add-Content 명령을 사용하여 .env 파일에 쓰세요.

Add-Content -Path deploy.env -Value "DYNAMIC_ENVIRONMENT_URL=$DYNAMIC_ENVIRONMENT_URL"

환경 이름 바꾸기

API를 사용하여 환경의 이름을 바꾸는 것은 GitLab 15.9에서 사용 중단되었습니다.

API로 환경의 이름을 바꾸는 것은 GitLab 16.0에서 제거되었습니다.

환경의 이름을 바꿀 수 없습니다.

환경 이름을 바꾸는 것과 동일한 결과를 얻으려면:

기존 환경 중지하기.
기존 환경 삭제하기.
원하는 이름으로 새 환경 만들기.

환경의 배포 티어

때때로 production과 같은 산업 표준 환경 이름 대신 customer-portal과 같은 코드 이름을 사용하고 싶을 수 있습니다.

customer-portal과 같은 이름을 사용하는 데 기술적인 이유는 없지만, 그 이름은 더 이상 환경이 배포에 사용된다는 것을 나타내지 않습니다. 이는 배포 빈도와 같은 메트릭이 계산되는 방식에 영향을 줄 수 있습니다.

특정 환경이 특정 용도임을 나타내기 위해, 다음과 같은 티어를 사용할 수 있습니다:

환경 티어	환경 이름 예시
`production`	Production, Live
`staging`	Staging, Model, Demo
`testing`	Test, QC
`development`	Dev, Review apps, Trunk
`other`

기본적으로 GitLab은 환경 이름에 따라 티어를 가정합니다.

UI를 사용하여 환경 티어를 설정할 수 없습니다.

대신, deployment_tier 키워드를 사용하여 티어를 지정할 수 있습니다.

수동 배포 구성

수동으로 배포를 시작해야 하는 작업을 생성할 수 있습니다.

예를 들어:

deploy_prod:
  stage: deploy
  script:
    - echo "Deploy to production server"
  environment:
    name: production
    url: https://example.com
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      when: manual

when: manual 액션:

GitLab UI에서 작업의 실행 () 버튼을 노출시키고, 텍스트는 수동으로 <environment>에 배포될 수 있습니다입니다.
deploy_prod 작업은 수동으로 트리거해야 함을 의미합니다.

실행 ()는 파이프라인, 환경, 배포 및 작업 뷰에서 찾을 수 있습니다.

배포당 새로 포함된 병합 요청 추적

GitLab은 배포당 새로 포함된 병합 요청을 추적할 수 있습니다.

배포가 성공하면 시스템은 최신 배포와 이전 배포 간의 커밋 차이를 계산합니다.

배포 API를 사용하여 추적 정보를 가져오거나 병합 요청 페이지에서 포스트 매지 병합 파이프라인으로 확인할 수 있습니다.

추적을 활성화하려면 다음 중 하나로 환경을 구성하십시오:

환경 이름이 /가 포함된 폴더를 사용하지 않습니다(장기 또는 최상위 환경).
환경 티어가 production 또는 staging입니다.

다음은 .gitlab-ci.yml에서 environment 키워드를 사용하는 몇 가지 예제 구성입니다:

# 추적 가능
environment: production
environment: production/aws
environment: development

# 추적 불가능
environment: review/$CI_COMMIT_REF_SLUG
environment: testing/aws

구성 변경 사항은 새로운 배포에만 적용됩니다. 기존 배포 기록에는 병합 요청이 연결되거나 연결 해제되지 않습니다.

환경 작업

환경이 구성되면 GitLab은 아래에 문서화된 여러 기능을 통해 이를 작업할 수 있습니다.

환경 롤백

특정 커밋에서 배포를 롤백할 때, 새로운 배포가 생성됩니다.

이 배포는 고유한 작업 ID를 가지고 있으며, 롤백할 커밋을 가리킵니다.

롤백이 성공하려면 배포 프로세스가 작업의 script에 정의되어 있어야 합니다.

오직 배포 작업만 실행됩니다.

이전 작업이 배포 시 재생성해야 하는 아티팩트를 생성하는 경우, 파이프라인 페이지에서 필요한 작업을 수동으로 실행해야 합니다.

예를 들어, Terraform을 사용하고 plan 및 apply 명령이 여러 작업으로 분리되어 있는 경우, 배포 또는 롤백을 위해 작업을 수동으로 실행해야 합니다.

배포 재시도 또는 롤백

배포에 문제가 있는 경우, 이를 재시도하거나 롤백할 수 있습니다.

배포를 재시도하거나 롤백하려면:

왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
작업 > 환경을 선택합니다.
환경을 선택합니다.
배포 이름의 오른쪽에서:
- 배포를 재시도하려면 환경에 다시 배포를 선택합니다.
- 배포를 롤백하려면, 이전에 성공한 배포 옆에서 환경 롤백을 선택합니다.

참고: 프로젝트에서 구형 배포 작업을 방지한 경우, 롤백 버튼이 숨겨지거나 비활성화될 수 있습니다.

이 경우, 롤백 배포에 대한 작업 재시도를 참조하세요.

환경 URL

GitLab 15.2에서 [변경됨](https://gitlab.com/gitlab-org/gitlab/-/issues/337417) 플래그 soft_validation_on_external_url로 임의의 URL를 지속할 수 있게 되었습니다. 기본적으로 비활성화되어 있습니다.

GitLab 15.3에서 [일반 제공](https://gitlab.com/gitlab-org/gitlab/-/issues/337417)되었습니다. 기능 플래그 soft_validation_on_external_url 제거됨.

환경 URL은 GitLab의 몇몇 장소에 표시됩니다:

병합 요청에서 링크로:
환경 보기에서 버튼으로:
배포 보기에서 버튼으로:

병합 요청에서 이 정보를 볼 수 있는 경우는:

병합 요청이 최종적으로 기본 브랜치(보통 main)에 병합되었을 때.
해당 브랜치도 환경(예: staging 또는 production)에 배포되었을 때.

예를 들어:

소스 파일에서 공개 페이지로 이동

GitLab Route Maps를 사용하면 소스 파일에서 검토 앱을 위한 환경으로 설정된 공개 페이지로 직접 이동할 수 있습니다.

환경 중지

환경을 중지한다는 것은 해당 배포가 대상 서버에서 접근할 수 없다는 것을 의미합니다.

환경을 삭제하기 전에 중지해야 합니다.

브랜치가 삭제될 때 환경 중지

브랜치가 삭제될 때 환경을 중지하도록 구성할 수 있습니다.

다음 예제에서는 deploy_review 작업이 stop_review 작업을 호출하여 정리하고 환경을 중지합니다.

두 작업 모두 동일한 rules 또는 only/except 구성이 있어야 합니다. 그렇지 않으면, stop_review 작업이 deploy_review 작업이 포함된 모든 파이프라인에 포함되지 않을 수 있으며, 환경을 자동으로 중지하기 위해 action: stop을 트리거할 수 없습니다.
action: stop이 있는 작업은 실행되지 않을 수 있습니다. 작업이 환경을 시작한 작업보다 나중 단계에 있을 경우에는 실행되지 않습니다.
Merge Request 파이프라인을 사용할 수 없는 경우, stop_review 작업에서 GIT_STRATEGY를 none 또는 empty로 설정하십시오. 그러면 러너가 브랜치가 삭제된 후 코드를 체크아웃하려고 시도하지 않습니다.

deploy_review:
  stage: deploy
  script:
    - echo "리뷰 앱 배포"
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: https://$CI_ENVIRONMENT_SLUG.example.com
    on_stop: stop_review

stop_review:
  stage: deploy
  script:
    - echo "리뷰 앱 제거"
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: stop
  when: manual

Merge Request가 병합되거나 닫힐 때 환경 중지

Merge Request 파이프라인 구성을 사용할 때, stop 트리거가 자동으로 활성화됩니다.

다음 예제에서는 deploy_review 작업이 stop_review 작업을 호출하여 정리하고 환경을 중지합니다.

deploy_review:
  stage: deploy
  script:
    - echo "리뷰 앱 배포"
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    on_stop: stop_review
  rules:
    - if: $CI_MERGE_REQUEST_ID

stop_review:
  stage: deploy
  script:
    - echo "리뷰 앱 제거"
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: stop
  rules:
    - if: $CI_MERGE_REQUEST_ID
      when: manual

환경이 중지될 때 파이프라인 작업 실행

기능 플래그 environment_stop_actions_include_all_finished_deployments는 GitLab 16.9에서 소개됨. 기본적으로 비활성화되어 있습니다.

기능 플래그 environment_stop_actions_include_all_finished_deployments는 GitLab 17.0에서 제거됨.

환경의 배포 작업에서 on_stop 동작을 사용하여 중지 작업을 정의할 수 있습니다.

환경이 중지될 때, 최신 완료된 파이프라인의 완료된 배포 중지 작업이 실행됩니다. 배포 또는 파이프라인은 성공, 취소 또는 실패 상태일 때 _완료_로 간주됩니다.

전제 조건:

배포 작업과 중지 작업 모두 동일한 규칙 또는 only/except 구성이 있어야 합니다.
중지 작업은 다음 키워드를 정의해야 합니다:
- when, 다음 중 하나에서 정의됨:
  - 작업 수준.
  - 규칙 절에서. rules와 when: manual을 사용하는 경우, 작업이 실행되지 않더라도 파이프라인이 완료될 수 있도록 allow_failure: true도 설정해야 합니다.
- environment:name
- environment:action

다음 예제에서는:

review_app 작업이 첫 번째 작업이 완료된 후 stop_review_app 작업을 호출합니다.
stop_review_app는 when 아래에 정의된 내용에 따라 트리거됩니다. 이 경우, manual로 설정되어 있어서 GitLab UI에서 수동 작업이 필요합니다.
GIT_STRATEGY는 none으로 설정되어 있습니다. stop_review_app 작업이 자동으로 트리거되면 러너가 브랜치가 삭제된 후 코드를 체크아웃하려고 시도하지 않습니다.

review_app:
  stage: deploy
  script: make deploy-app
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: https://$CI_ENVIRONMENT_SLUG.example.com
    on_stop: stop_review_app

stop_review_app:
  stage: deploy
  variables:
    GIT_STRATEGY: none
  script: make delete-app
  when: manual
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: stop

특정 기간 후 환경 중지

환경을 특정 기간 후 자동으로 중지하도록 설정할 수 있습니다.

참고:
리소스 제한으로 인해 환경을 중지하는 백그라운드 작업자는 매시간 한 번만 실행됩니다.
이것은 환경이 지정된 정확한 기간 후에 중지되지 않을 수 있으며,
백그라운드 작업자가 만료된 환경을 감지할 때 중지됩니다.

.gitlab-ci.yml 파일에서 environment:auto_stop_in
키워드를 지정합니다. 자연어로 기간을 지정하세요, 예를 들어 1 hour and 30 minutes 또는 1 day와 같이.
기간이 지나면 GitLab이 자동으로 작업을 트리거하여 환경을 중지합니다.

다음 예제에 대해:

병합 요청의 각 커밋은 최신 변경 내용을 환경에 배포하고 만료 기간을 리셋하는 review_app 작업을 트리거합니다.
환경이 1주일 이상 비활성 상태인 경우, GitLab은 자동으로 stop_review_app 작업을 트리거하여 환경을 중지합니다.

review_app:
  script: deploy-review-app
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    on_stop: stop_review_app
    auto_stop_in: 1 week
  rules:
    - if: $CI_MERGE_REQUEST_ID

stop_review_app:
  script: stop-review-app
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: stop
  rules:
    - if: $CI_MERGE_REQUEST_ID
      when: manual

환경의 예정된 중지 날짜와 시간 보기

환경이 지정된 기간 후 중지되도록 예정된 경우,
만료 날짜와 시간을 볼 수 있습니다.

환경의 만료 날짜와 시간을 보기 위해:

왼쪽 사이드바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
Operate > Environments를 선택합니다.
환경의 이름을 선택합니다.

만료 날짜와 시간은 환경의 이름 옆 왼쪽 상단 모서리에 표시됩니다.

환경의 예정된 중지 날짜와 시간 재정의

환경이 지정된 기간 후 중지되도록 예정된 경우,
만료를 재정의할 수 있습니다.

UI에서 환경의 만료를 재정의하려면:

왼쪽 사이드바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
Operate > Environments를 선택합니다.
배포 이름을 선택합니다.
오른쪽 상단 모서리에서 핀() 아이콘을 선택합니다.

.gitlab-ci.yml에서 환경의 만료를 재정의하려면:

프로젝트의 .gitlab-ci.yml을 엽니다.
해당 배포 작업의 auto_stop_in 설정을 auto_stop_in: never로 업데이트합니다.

auto_stop_in 설정이 재정의되고 환경은 수동으로 중지될 때까지 활성 상태를 유지합니다.

`on_stop` 작업을 실행하지 않고 환경 중지

정의된 on_stop 작업을 실행하지 않고 환경을 중지하고 싶은 경우가 있을 수 있습니다.
예를 들어, compute quota 없이 여러 환경을 삭제하고 싶습니다.

정의된 on_stop 작업을 실행하지 않고 환경을 중지하려면,
force=true 매개변수를 사용하여 Stop an environment API를 실행합니다.

UI를 사용하여 환경 중지

참고:

on_stop 작업을 트리거하고 Environments 뷰에서 환경을 수동으로 중지하려면, 중지 및 배포 작업이 동일한 resource_group에 있어야 합니다.

GitLab UI에서 환경을 중지하려면:

왼쪽 사이드바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
Operate > Environments를 선택합니다.
중지하려는 환경 옆에서 Stop을 선택합니다.
확인 대화상자에서 Stop environment를 선택합니다.

환경에 대한 여러 중지 작업

GitLab 15.0에서 일반적으로 사용 가능. 기능 플래그 environment_multiple_stop_actions가 제거되었습니다.

환경에 대해 여러 병렬 중지 작업을 구성하려면, 동일한 environment에 대해 여러 배포 작업에 걸쳐 on_stop 키워드를 지정합니다. .gitlab-ci.yml 파일에 정의된 대로.

환경이 중지되면, 성공적인 배포 작업에서만 일치하는 on_stop 작업이 병렬로 실행됩니다. 순서는 정해져 있지 않습니다.

참고:

환경에 대한 모든 on_stop 작업은 동일한 파이프라인에 속해야 합니다. 하위 파이프라인에서 여러 on_stop 작업을 사용하려면, 상위 파이프라인에서 환경 작업을 구성해야 합니다. 더 많은 정보는 배포를 위한 하위 파이프라인을 참조하세요.

다음 예에서 test 환경에는 두 개의 배포 작업이 있습니다:

deploy-to-cloud-a
deploy-to-cloud-b

환경이 중지되면 시스템은 teardown-cloud-a와 teardown-cloud-b를 병렬로 실행합니다.

deploy-to-cloud-a:
  script: echo "클라우드 A에 배포"
  environment:
    name: test
    on_stop: teardown-cloud-a

deploy-to-cloud-b:
  script: echo "클라우드 B에 배포"
  environment:
    name: test
    on_stop: teardown-cloud-b

teardown-cloud-a:
  script: echo "클라우드 A의 리소스를 삭제"
  environment:
    name: test
    action: stop
  when: manual

teardown-cloud-b:
  script: echo "클라우드 B의 리소스를 삭제"
  environment:
    name: test
    action: stop
  when: manual

환경 삭제

리소스와 모든 배포를 제거하려는 경우 환경을 삭제합니다.

전제 조건:

최소한 Developer 역할이 있어야 합니다.
삭제하기 전에 환경을 중지해야 합니다.

환경을 삭제하려면:

왼쪽 사이드바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
Operate > Environments를 선택합니다.
Stopped 탭을 선택합니다.
삭제하려는 환경 옆에서 Delete environment를 선택합니다.
확인 대화상자에서 Delete environment를 선택합니다.

오래된 환경 정리

GitLab 15.8에서 도입됨 플래그와 함께 이름이 stop_stale_environments. 기본적으로 비활성화됨.

GitLab 15.10에서 일반적으로 사용 가능. 기능 플래그 stop_stale_environments가 제거되었습니다.

오래된 환경을 정리하려면 프로젝트에서 오래된 환경을 중지합니다.

전제 조건:

최소한 Maintainer 역할이 있어야 합니다.

오래된 환경을 정리하려면:

왼쪽 사이드바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
Operate > Environments를 선택합니다.
Clean up environments를 선택합니다.
어떤 환경을 오래된 것으로 간주할지를 결정하기 위해 사용할 날짜를 선택합니다.
Clean up을 선택합니다.

지정된 날짜 이후 업데이트되지 않은 활성 환경은 중지됩니다. 보호된 환경은 무시되며 중지되지 않습니다.

준비 또는 검증 목적으로 환경에 접근하기

다양한 목적, 예를 들어 검증 또는 준비를 위해 환경에 접근하는 작업을 정의할 수 있습니다.

이것은 배포 생성을 효과적으로 우회하므로 CD 워크플로우를 보다 정확하게 조정할 수 있습니다.

이를 위해 작업의 environment 섹션에 action: prepare, action: verify 또는 action: access를 추가하세요:

build:
  stage: build
  script:
    - echo "앱 빌드 중"
  environment:
    name: staging
    action: prepare
    url: https://staging.example.com

이렇게 하면 환경 범위 변수에 접근할 수 있으며, 비인가 접근으로부터 빌드를 보호하는 데 사용할 수 있습니다. 또한, 구식 배포 작업 방지 기능을 피하는 데 효과적입니다.

유사한 환경 그룹화

UI에서 환경을 접을 수 있는 섹션으로 그룹화할 수 있습니다.

예를 들어, 모든 환경 이름이 review로 시작하는 경우, UI에서는 해당 제목 아래에 환경이 그룹화됩니다:

다음 예시는 환경 이름을 review로 시작하는 방법을 보여줍니다. $CI_COMMIT_REF_SLUG 변수는 런타임에 브랜치 이름으로 채워집니다:

deploy_review:
  stage: deploy
  script:
    - echo "리뷰 앱 배포 중"
  environment:
    name: review/$CI_COMMIT_REF_SLUG

환경 사고 관리

프로덕션 환경은 예기치 않게 중단될 수 있으며, 이는 제어할 수 없는 이유로 발생할 수 있습니다. 예를 들어, 외부 의존성, 인프라, 또는 인적 오류로 인해 환경에 심각한 문제가 발생할 수 있습니다. 예시는 다음과 같습니다:

의존하는 클라우드 서비스가 중단됩니다.
3rd 파티 라이브러리가 업데이트되어 귀하의 애플리케이션과 호환되지 않습니다.
누군가 귀하의 서버에서 취약한 엔드포인트에 DDoS 공격을 가합니다.
운영자가 인프라를 잘못 구성합니다.
프로덕션 애플리케이션 코드에 버그가 도입됩니다.

사고 관리를 사용하여 즉각적인 주의가 필요한 심각한 문제가 발생했을 때 경고를 받을 수 있습니다.

환경에 대한 최신 경고 보기

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

경고 통합을 설정하면, 환경에 대한 경고가 환경 페이지에 표시됩니다.

가장 높은 심각도의 경고가 표시되므로, 즉각적인 주의가 필요한 환경을 식별할 수 있습니다.

경고를 유발한 문제가 해결되면 해당 경고는 제거되며, 더 이상 환경 페이지에 표시되지 않습니다.

경고가 롤백을 요구하는 경우, 환경 페이지에서 배포 탭을 선택하고 롤백할 배포를 선택할 수 있습니다.

자동 롤백

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

일반적인 지속적 배포 워크플로우에서 CI 파이프라인은 프로덕션에 배포하기 전에 모든 커밋을 테스트합니다.

하지만, 문제 있는 코드가 프로덕션에 배포될 수 있습니다. 예를 들어, 논리적으로 올바르지만 성능 저하를 초래하는 비효율적인 코드가 테스트를 통과할 수 있습니다.

운영자 및 SRE는 이러한 문제를 가능한 한 빨리 포착하기 위해 시스템을 모니터링합니다. 문제가 있는 배포를 발견하면 이전의 안정적인 버전으로 롤백할 수 있습니다.

GitLab 자동 롤백은 중요 경고가 감지되었을 때 자동으로 롤백을 트리거하여 이 작업을 용이하게 합니다.

GitLab이 롤백을 위해 적절한 환경을 선택하려면 경고에 gitlab_environment_name 키와 환경 이름이 포함되어야 합니다.

GitLab은 가장 최근의 성공적인 배포를 선택하고 재배포합니다.

GitLab 자동 롤백의 한계:

경고가 감지될 때 배포가 실행 중인 경우 롤백이 건너뜁니다.
롤백은 3분에 한 번만 발생할 수 있습니다. 여러 개의 경고가 동시에 감지된 경우, 하나의 롤백만 수행됩니다.

GitLab 자동 롤백은 기본적으로 꺼져 있습니다. 이를 켜려면:

왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
설정 > CI/CD를 선택합니다.
자동 배포 롤백을 확장합니다.
자동 롤백 활성화 체크박스를 선택합니다.
변경 사항 저장을 선택합니다.

웹 터미널 (사용 중단됨)

경고:

이 기능은 사용 중단되었습니다 GitLab 14.5에서.

배포 서비스를 사용하여 환경에 배포하는 경우 (예: Kubernetes 통합), GitLab은 환경에 대한 터미널 세션을 열 수 있습니다. 그러면 웹 브라우저를 떠나지 않고도 문제를 디버깅할 수 있습니다.

웹 터미널은 컨테이너 기반의 배포로, 기본 도구 (편집기와 같은)가 부족하고 언제든지 중지되거나 재시작될 수 있습니다. 이 경우 모든 변경 사항이 손실됩니다. 웹 터미널을 종합적인 온라인 IDE가 아닌 디버깅 도구로 간주하세요.

웹 터미널:

프로젝트 관리자 및 소유자에게만 제공됩니다.
활성화되어야 합니다.

UI에서, 동작 메뉴에서 Terminal을 선택하여 웹 터미널을 볼 수 있습니다:

특정 환경의 페이지에서도 터미널 버튼에 액세스할 수 있습니다:

버튼을 선택하여 터미널 세션을 설정합니다:

이는 다른 터미널과 동일하게 작동합니다. 배포에 의해 생성된 컨테이너에 있으므로 다음을 수행할 수 있습니다:

실시간으로 셸 명령을 실행하고 응답을 받을 수 있습니다.
로그를 확인할 수 있습니다.
구성이나 코드 수정 사항을 시도할 수 있습니다.

동일한 환경에 여러 개의 터미널을 열 수 있습니다. 각 터미널은 자체 셸 세션과 screen 또는 tmux와 같은 다중화기를 가집니다.

로컬에서 배포 확인하기

각 배포에 대한 Git 저장소에 참조가 저장되므로, 현재 환경의 상태를 아는 것은 단지 git fetch로 가능합니다.

Git 구성에서, [remote "<your-remote>"] 블록에 추가로 fetch 라인을 추가합니다:

fetch = +refs/environments/*:refs/remotes/origin/environments/*

이전 배포 보관하기

프로젝트에서 새 배포가 발생할 때, GitLab은 배포에 대한 특수 Git-ref를 생성합니다. 이러한 Git-ref는 원격 GitLab 저장소에서 채워지기 때문에, 프로젝트의 배포 수가 증가할수록 git-fetch 및 git-pull와 같은 일부 Git 작업이 느려질 수 있습니다.

Git 작업의 효율성을 유지하기 위해, GitLab은 최근 배포 참조만 유지하고 (최대 50,000) 나머지 오래된 배포 참조는 삭제합니다. 보관된 배포는 여전히 UI 또는 API를 사용하여 감사 목적으로 사용할 수 있습니다. 또한, 보관 후에도 커밋 SHA를 지정하여 저장소에서 배포된 커밋을 여전히 가져올 수 있습니다 (예: git checkout <deployment-sha>).

참고:

GitLab은 모든 커밋을 keep-around refs로 보존하여 배포된 커밋이 배포 참조에 의해 참조되지 않더라도 가비지 수집되지 않도록 합니다.

CI/CD 변수의 환경 범위 제한하기

기본적으로, 모든 CI/CD 변수는 파이프라인의 모든 작업에서 사용할 수 있습니다.

작업의 테스트 도구가 손상되면, 해당 도구는 작업에서 사용할 수 있는 모든 CI/CD 변수를 복구하려고 시도할 수 있습니다. 이러한 공급망 공격을 완화하기 위해, 민감한 변수의 환경 범위를 그것이 필요로 하는 작업으로만 제한하는 것이 좋습니다.

CI/CD 변수의 환경 범위를 제한하려면, 변수가 사용 가능한 환경을 정의해야 합니다. 기본 환경 범위는 * 와일드카드로, 어떤 작업이든 변수를 접근할 수 있습니다.

특정 환경을 선택하기 위해 특정 매칭을 사용할 수 있습니다. 예를 들어, 변수의 환경 범위를 production으로 설정하여 [environment](../yaml/index.md#environment)가 production인 작업만 변수를 접근하도록 허용합니다.

와일드카드 매칭(*)을 사용하여 특정 환경 그룹을 선택할 수도 있습니다. 예를 들어, 모든 리뷰 앱을 review/*로 설정할 수 있습니다.

예를 들어, 다음 네 가지 환경이 있을 때:

production
staging
review/feature-1
review/feature-2

이러한 환경 범위는 다음과 같이 일치합니다:

↓ 범위 / 환경 →	`production`	`staging`	`review/feature-1`	`review/feature-2`
`*`	일치	일치	일치	일치
`production`	일치
`staging`		일치
`review/*`			일치	일치
`review/feature-1`			일치

환경 범위 변수를 rules 또는 include와 함께 사용해서는 안 됩니다. 변수가 GitLab이 파이프라인 생성 시 파이프라인 구성을 검증할 때 정의되지 않을 수 있습니다.

환경 권한

역할에 따라 공개 및 비공개 프로젝트에서 환경과 상호작용할 수 있습니다.

환경 보기

공개 프로젝트에서는 누구나 목록을 볼 수 있습니다. 비회원도 포함됩니다.
비공식 프로젝트에서는 환경 목록을 보기 위해 최소한 Reporter 역할이 필요합니다.

환경 생성 및 업데이트

새로운 환경을 생성하거나 기존의 보호되지 않은 환경을 업데이트하기 위해서 최소한 Developer 역할이 필요합니다.
기존 환경이 보호되어 있고 해당 환경에 접근할 수 없다면 환경을 업데이트할 수 없습니다.

환경 중지 및 삭제

보호되지 않은 환경을 중지하거나 삭제하기 위해서는 최소한 Developer 역할이 필요합니다.
환경이 보호되어 있고 해당 환경에 접근할 수 없다면 환경을 중지하거나 삭제할 수 없습니다.

보호된 환경에서 배포 작업 실행

보호된 브랜치에 푸시하거나 병합할 수 있는 경우:

최소한 Reporter 역할이 필요합니다.

보호된 브랜치에 푸시할 수 없는 경우:

Reporter 역할이 있는 그룹의 일원이어야 합니다.

보호된 환경에 대한 배포 전용 액세스를 참조하세요.

문제 해결

`action: stop` 작업이 실행되지 않음

경우에 따라 on_stop 작업이 구성되어 있음에도 불구하고 환경이 중지되지 않을 수 있습니다. 이는 action: stop이 포함된 작업이 stages: 또는 needs: 구성 때문에 실행 가능한 상태에 있지 않기 때문입니다.

예를 들어:

환경이 실패한 작업이 있는 단계에서 시작될 수 있습니다.
그런 다음 후속 단계의 작업이 시작되지 않습니다.
환경을 위한 action: stop 작업이 후속 단계에 있다면, 시작할 수 없고 환경이 삭제되지 않습니다.
action: stop 작업이 완료되지 않은 작업에 의존할 수 있습니다.

필요할 때 action: stop이 항상 실행될 수 있도록 하려면:

두 작업을 동일한 단계에 배치하십시오:

stages:
  - build
  - test
  - deploy

...

deploy_review:
  stage: deploy
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: https://$CI_ENVIRONMENT_SLUG.example.com
    on_stop: stop_review

stop_review:
  stage: deploy
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: stop
  when: manual

action: stop 작업에 needs 항목을 추가하여
작업이 단계 순서와 상관없이 시작될 수 있도록 합니다:

stages:
  - build
  - test
  - deploy
  - cleanup

...

deploy_review:
  stage: deploy
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: https://$CI_ENVIRONMENT_SLUG.example.com
    on_stop: stop_review

stop_review:
  stage: cleanup
  needs:
    - deploy_review
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: stop
  when: manual

오류: 잘못된 매개변수로 환경을 생성하는 작업

프로젝트가 동적 환경을 생성하도록 구성되어 있으면 배포 작업에서 이 오류가 발생할 수 있습니다. 동적으로 생성된 매개변수는 환경을 생성하는 데 사용할 수 없기 때문입니다:

이 작업은 잘못된 매개변수로 환경을 생성하기 때문에 실행할 수 없습니다.

예를 들어, 프로젝트에 다음과 같은 .gitlab-ci.yml 파일이 있습니다:

deploy:
  script: echo
  environment: production/$ENVIRONMENT

$ENVIRONMENT 변수가 파이프라인에 존재하지 않기 때문에, GitLab은 production/이라는 이름의 환경을 생성하려고 시도하여 환경 이름 제약에 위배됩니다.

이 문제를 해결하려면 다음 중 하나의 솔루션을 사용하세요:

배포 작업에서 environment 키워드를 제거하세요. GitLab은 이미 잘못된 키워드를 무시하고 있으므로, 키워드 제거 후에도 배포 파이프라인은 그대로 유지됩니다.
파이프라인에서 변수가 존재하는지 확인하세요. 지원되는 변수의 제한 사항을 검토하세요.

리뷰 앱에서 이 오류가 발생하는 경우

예를 들어, .gitlab-ci.yml 파일에 다음과 같은 내용이 있을 경우:

review:
  script: deploy review app
  environment: review/$CI_COMMIT_REF_NAME

bug-fix!라는 브랜치 이름으로 새로운 머지 요청을 만들면, review 작업은 review/bug-fix!라는 환경을 만들려고 시도합니다. 그러나 !는 환경에 유효하지 않은 문자이므로, 환경 없이 실행될 예정이었던 배포 작업이 실패합니다.

이 문제를 해결하려면 다음 중 하나의 솔루션을 사용하세요:

잘못된 문자가 없는 새 기능 브랜치를 다시 생성하세요, 예: bug-fix.
CI_COMMIT_REF_NAME 미리 정의된 변수를 CI_COMMIT_REF_SLUG로 교체하세요. 이 변수는 잘못된 문자를 모두 제거합니다:
```
review:
  script: deploy review app
  environment: review/$CI_COMMIT_REF_SLUG
```

배포 참조를 찾을 수 없음

GitLab은 오래된 배포 참조를 삭제하여 Git 리포지토리의 성능을 유지합니다.

archived Git-refs를 복원해야 하는 경우, self-managed GitLab 인스턴스의 관리자가 Rails 콘솔에서 다음 명령을 실행하도록 요청하세요:

Project.find_by_full_path(<your-project-full-path>).deployments.where(archived: true).each(&:create_ref)

GitLab은 성능 문제로 인해 향후 이 지원을 중단할 수 있습니다. 이 기능의 동작에 대해 논의하려면 GitLab Issue Tracker에 이슈를 열 수 있습니다.

On this page

환경과 배포

환경 및 배포 보기

환경 검색

CI/CD 변수

환경 상태

환경 유형

정적 환경 만들기

UI에서

.gitlab-ci.yml 파일에서

동적 환경 만들기

동적 환경 URL 설정하기

환경 이름 바꾸기

환경의 배포 티어

수동 배포 구성

배포당 새로 포함된 병합 요청 추적

환경 작업

환경 롤백

배포 재시도 또는 롤백

환경 URL

소스 파일에서 공개 페이지로 이동

환경 중지

브랜치가 삭제될 때 환경 중지

Merge Request가 병합되거나 닫힐 때 환경 중지

환경이 중지될 때 파이프라인 작업 실행

특정 기간 후 환경 중지

환경의 예정된 중지 날짜와 시간 보기

환경의 예정된 중지 날짜와 시간 재정의

on_stop 작업을 실행하지 않고 환경 중지

UI를 사용하여 환경 중지

환경에 대한 여러 중지 작업

환경 삭제

오래된 환경 정리

준비 또는 검증 목적으로 환경에 접근하기

유사한 환경 그룹화

환경 사고 관리

환경에 대한 최신 경고 보기

자동 롤백

웹 터미널 (사용 중단됨)

로컬에서 배포 확인하기

이전 배포 보관하기

CI/CD 변수의 환경 범위 제한하기

환경 권한

환경 보기

환경 생성 및 업데이트

환경 중지 및 삭제

보호된 환경에서 배포 작업 실행

관련 주제

문제 해결

action: stop 작업이 실행되지 않음

오류: 잘못된 매개변수로 환경을 생성하는 작업

리뷰 앱에서 이 오류가 발생하는 경우

배포 참조를 찾을 수 없음

도움말

기능 사용 가능성과 제품 평가판

도움받기

On this page

`.gitlab-ci.yml` 파일에서

`on_stop` 작업을 실행하지 않고 환경 중지

`action: stop` 작업이 실행되지 않음