환경 및 배포

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

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

각각의 GitLab CI/CD가 환경으로 코드 버전을 배포할 때마다, 배포가 생성됩니다.

GitLab:

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

프로젝트와 연관된 Kubernetes처럼 배포 서비스가 있는 경우 배포를 지원하기 위해 사용할 수 있습니다.

환경 및 배포 보기

전제 조건:

  • 비공개 프로젝트인 경우, 적어도 Reporter 역할이 있어야 합니다. 환경 권한을 참조하세요.

주어진 프로젝트의 환경 디렉터리을 보는 몇 가지 방법이 있습니다:

  • 프로젝트 개요 페이지에서, 하나의 환경 이상이 있을 때 환경 디렉터리(즉, 중지되지 않은)을 볼 수 있습니다. 환경 수

  • 왼쪽 사이드바에서 운영 > 환경을 선택합니다. 환경이 표시됩니다.

    환경 디렉터리

  • 환경 디렉터리에서 특정 환경 이름(예: staging)을 선택하여 해당 환경의 배포 디렉터리을 보려면 배포 디렉터리

배포는 배포 작업이 생성된 후에만 이 디렉터리에 나타납니다.

환경 검색

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

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하여 프로젝트를 찾습니다.
  2. 운영 > 환경을 선택합니다.
  3. 검색 창에 검색어를 입력합니다.
    • 검색어의 길이는 3자 이상이어야 합니다.
    • 일치하는 항목은 환경 이름의 시작부터 적용됩니다.
      • 예를 들어 devel은 환경 이름 development과 일치하지만, elop은 일치하지 않습니다.
    • 폴더 이름 형식의 환경의 경우, 일치하는 항목은 기본 폴더 이름 이후에 적용됩니다.
      • 예를 들어 이름이 review/test-app일 때, 검색어 test는 review/test-app와 일치합니다.
      • 또한 review/test와 같이 폴더 이름을 접두사로 검색하면 review/test-app과 일치합니다.

CI/CD 변수

환경 및 배포를 사용자 정의하려면 사전 정의된 CI/CD 변수 중 하나를 사용하고 사용자 정의 CI/CD 변수를 정의할 수 있습니다.

환경 상태

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

  • 사용 가능: 환경이 존재하며 배포가 있을 수 있습니다.
  • 중지 중: _중지 작업_이 시작되었습니다. 이 상태는 중지 작업이 정의되지 않은 경우에는 적용되지 않습니다.
  • 중지됨: _중지 작업_이 실행되었거나 사용자가 작업을 매뉴얼으로 중지했습니다.

환경 유형

환경은 정적 환경 또는 동적 환경 중 하나입니다:

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

정적 환경 생성

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

UI에서

전제 조건:

  • 적어도 개발자 역할이 있어야 합니다.

UI에서 정적 환경을 생성하려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하여 프로젝트를 찾습니다.
  2. 운영 > 환경을 선택합니다.
  3. 환경 만들기를 선택합니다.
  4. 필드를 작성합니다.
  5. 저장을 선택합니다.

.gitlab-ci.yml 파일에서

전제 조건:

  • 적어도 개발자 역할이 있어야 합니다.

.gitlab-ci.yml 파일에서 정적 환경을 생성하려면:

  1. deploy 단계에서 작업을 정의합니다.
  2. 작업에서 환경의 이름과 url을 정의합니다. 파이프라인 실행 시 해당 이름의 환경이 없으면 만들어집니다.
note
일부 문자는 환경 이름으로 사용할 수 없습니다. environment 키워드에 대한 자세한 내용은 .gitlab-ci.yml 키워드 참조를 참조하세요.

예를 들어, staging이름과 URL https://staging.example.com로 환경을 만들려면: 

deploy_staging:
  stage: deploy
  script:
    - echo "스테이징 서버로 배포"
  environment:
    name: staging
    url: https://staging.example.com

동적 환경 생성

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

전제 조건:

  • 적어도 개발자 역할이 있어야 합니다.

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

  1. deploy 단계에서 작업을 정의합니다.
  2. 작업에서 다음 환경 속성을 정의합니다.
    • name: 관련 CI/CD 변수인 $CI_COMMIT_REF_SLUG와 같은 관련 CI/CD 변수를 사용합니다. 환경 이름에 정적 접두사를 추가하여 UI에서 유사한 환경 그룹화를 할 수도 있습니다.
    • url: 선택 사항입니다. 호스트명 앞에 $CI_ENVIRONMENT_SLUG와 같은 관련 CI/CD 변수를 추가합니다.
note
일부 문자는 환경 이름으로 사용할 수 없습니다. 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에서 URL의 정적 부분을 지정할 수도 있습니다. 예를 들어, environment:url에 https://$DYNAMIC_ENVIRONMENT_URL을 지정할 수 있습니다. 만약 DYNAMIC_ENVIRONMENT_URL 값이 example.com이라면 최종 결과는 https://example.com이 됩니다.

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

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

다음 예에서 리뷰 앱은 각 Merge Request마다 새로운 환경을 생성합니다:

  • review 작업은 각 푸시마다 트리거되어 review/your-branch-name이라는 환경을 생성하거나 업데이트합니다. 환경 URL은 $DYNAMIC_ENVIRONMENT_URL로 설정됩니다.
  • review 작업이 완료되면 GitLab은 review/your-branch-name 환경의 URL을 업데이트합니다. deploy.env 보고 artifact를 파싱하고, 런타임에 생성된 변수 디렉터리을 등록하며, environment:url: $DYNAMIC_ENVIRONMENT_URL를 확장하고, 환경 URL로 설정합니다. 
review:
  script:
    - DYNAMIC_ENVIRONMENT_URL=$(deploy-script)                                 # In script, get the environment URL.
    - echo "DYNAMIC_ENVIRONMENT_URL=$DYNAMIC_ENVIRONMENT_URL" >> deploy.env    # Add the value to a dotenv file.
  artifacts:
    reports:
      dotenv: deploy.env                                                       # Report back dotenv file to rails.
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: $DYNAMIC_ENVIRONMENT_URL                                              # and set the variable produced in script to `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 보고 artifact를 생성하지 않으므로 DYNAMIC_ENVIRONMENT_URL 환경 변수를 인식하지 않습니다. 따라서 stop_review 작업에서 environment:url을 설정해서는 안됩니다.
  • 환경 URL이 유효하지 않을 경우(예: URL이 잘못되었을 경우) 시스템이 환경 URL을 업데이트하지 않습니다.
  • stop_review에서 실행되는 스크립트가 귀하의 리포지터리에만 존재하며 따라서 GIT_STRATEGY: none을 사용할 수 없는 경우, 이러한 작업을 위해 Merge Request 파이프라인을 구성하십시오. 이렇게 하면 러너가 기능 브랜치를 삭제한 후에도 리포지터리를 가져올 수 있습니다. 자세한 내용은 러너용 참조 사양을 참조하십시오.
note
Windows 러너의 경우 PowerShell Add-Content 명령어를 사용하여 .env 파일에 쓰도록 하십시오.
Add-Content -Path deploy.env -Value "DYNAMIC_ENVIRONMENT_URL=$DYNAMIC_ENVIRONMENT_URL"

환경 이름 변경

  • UI를 사용하여 환경 이름을 제거했습니다 (GitLab 14.3).
  • API를 사용하여 환경 이름을 제거했습니다 (GitLab 16.0).

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

환경 이름을 변경한 것과 동일한 결과를 얻으려면 다음을 수행하세요:

  1. 기존 환경을 중지하십시오.
  2. 기존 환경을 삭제하십시오.
  3. 원하는 이름으로 새로운 환경을 생성하십시오.

환경의 배포 티어

  • GitLab 13.10에서 도입되었습니다.

가끔은 production과 같은 산업 표준 환경 이름 대신 customer-portal과 같은 코드 이름을 사용하는 것이 좋을 수 있습니다. customer-portal과 같은 이름을 사용하는 것에 기술적인 이유는 없지만, 해당 이름은 더 이상 환경이 운영에 사용된다는 것을 나타내지 않습니다.

특정 용도로 사용되는 환경을 표시하려면 티어를 사용할 수 있습니다:

환경 티어 환경 이름 예시
production Production, Live
staging Staging, Model, Demo
testing Test, QC
development Dev, 리뷰 앱, Trunk
other  

기본적으로 GitLab은 환경 이름을 기반으로 티어를 가정합니다. 그 대신, deployment_tier 키워드를 사용하여 티어를 명시할 수 있습니다.

매뉴얼 배포 구성

매뉴얼으로 배포를 시작하도록 요구하는 작업을 생성할 수 있습니다. 예를 들어: 

deploy_prod:
  stage: deploy
  script:
    - echo "프로덕션 서버로 배포"
  environment:
    name: production
    url: https://example.com
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      when: manual

when: manual 동작:

  • GitLab UI에서 작업에 대한 플레이 버튼을 노출시키며, 텍스트는 Can be manually deployed to <environment>입니다.
  • deploy_prod 작업은 플레이 버튼이 선택될 때에만 트리거됩니다.

플레이 버튼은 파이프라인, 환경, 배포 및 작업 보기에서 찾을 수 있습니다.

배포 당 포함된 새로운 Merge Request 추적

  • GitLab 16.10에 도입된 link_fast_forward_merge_requests_to_deployment 피처 플래그. 기본 설정에서 비활성화됨.

GitLab은 배포 당 포함된 새로운 Merge Request을 추적할 수 있습니다. 배포가 성공하면 시스템은 최신 배포와 이전 배포 간의 커밋 차이를 계산합니다. 추적 정보는 배포 API에서 가져오거나 Merge Request 페이지의 포스트-Merge 파이프라인에서 볼 수 있습니다.

추적을 활성화하려면:

  1. 프로젝트의 Merge 방법을 설정하세요. Merge 방법:

    • 반드시 Fast-forward merge가 아니어야 합니다.
    • link_fast_forward_merge_requests_to_deployment 피처 플래그가 활성화된 경우 Fast-forward merge가 될 수 있습니다.

  2. 환경을 구성하세요. 구성은 다음 중 하나여야 합니다:

    • 환경 이름에 /를 사용하지 않아야 합니다(장기 실행 또는 최상위 환경).
    • 환경 티어가 production 또는 staging이어야 합니다.

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

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

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

구성 변경은 새로운 배포에만 적용됩니다. 기존 배포 레코드에는 연결되거나 연결 해제된 Merge Request이 없습니다.

환경 작업

환경이 구성된 후 GitLab은 해당 환경에 대해 많은 기능을 제공하는데, 아래 설명된 대로 문서화되어 있습니다.

환경 롤백

특정 커밋으로 배포를 롤백하면 새로운 배포가 생성됩니다. 이 배포에는 고유한 작업 ID가 있습니다. 이는 해당 커밋을 가리킵니다.

롤백이 성공하려면 작업의 script가 정의되어 있어야 합니다.

배포 작업만 실행됩니다. 이전 작업이 배포 시에 다시 생성해야 하는 아티팩트를 생성하는 경우, 파이프라인 페이지에서 필요한 작업을 매뉴얼으로 실행해야 합니다. 예를 들어, Terraform을 사용하고 plan 및 apply 명령이 여러 작업으로 분리된 경우, 배포 또는 롤백하는 데 필요한 작업을 매뉴얼으로 실행해야 합니다.

배포 다시 시도 또는 롤백

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

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

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하여 프로젝트를 찾으세요.
  2. 운영 > 환경을 선택하세요.
  3. 환경을 선택하세요.
  4. 배포 이름 오른쪽에:
    • 배포를 다시 시도하려면 환경으로 다시 배포를 선택하세요.
    • 배포를 롤백하려면 이전에 성공한 배포 옆에 환경 롤백을 선택하세요.
note
프로젝트에서 오래된 배포 작업을 방지했다면, 롤백 버튼이 숨겨지거나 비활성화될 수 있습니다. 이 경우, 롤백 배포를 다시 시도하는 작업을 참조하세요.

환경 URL

환경 URL은 GitLab의 몇 군데에서 표시됩니다:

  • Merge Request에서 링크로: Merge Request의 환경 URL
  • 환경 뷰에서 버튼으로: 환경 뷰에서 실시간 환경 열기
  • 배포 뷰에서 버튼으로: 배포에서 환경 URL

이 정보는 다음과 같은 경우에 Merge Request에서 볼 수 있습니다:

  • Merge Request이 최종적으로 기본 브랜치(일반적으로 main)에 Merge됩니다.
  • 해당 브랜치가 환경(예: staging 또는 production)에 배포됩니다.

예를 들면:

Merge Request의 환경 URL

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

GitLab의 경로지도를 사용하면 리뷰 앱용으로 설정된 환경에서 소스 파일에서 공개 페이지로 직접 이동할 수 있습니다.

환경 중지

환경을 중지하면 해당 환경의 배포는 대상 서버에서 접근할 수 없게 됩니다. 삭제하기 전에 환경을 중지해야 합니다.

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

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

다음 예에서 deploy_review 작업은 정리 및 환경 중지를 위해 stop_review 작업을 호출합니다. 

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되거나 닫힐 때 환경을 중지

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

환경이 중지되면 파이프라인 작업 실행

  • GitLab 16.9에 도입된 피처 플래그 environment_stop_actions_include_all_finished_deployments 기본적으로 비활성화됨.

플래그: Self-managed GitLab에서는 이 기능이 기본적으로 사용 안됨. 이 기능을 사용 가능하게 하려면 관리자가 environment_stop_actions_include_all_finished_deployments라는 피처 플래그를 활성화할 수 있습니다. GitLab.com 및 GitLab Dedicated에서는 이 기능을 사용할 수 없습니다.

환경의 배포 작업에서 on_stop 액션으로 환경에 대한 중지 작업을 정의할 수 있습니다.

environment_stop_actions_include_all_finished_deployments이 비활성화되어 있는 경우:

  • 가장 최근의 성공한 파이프라인의 성공적인 배포의 중지 작업이 환경이 중지될 때 실행됩니다.

environment_stop_actions_include_all_finished_deployments이 활성화되어 있는 경우:

  • 최근 완료된 파이프라인의 완료된 배포의 중지 작업이 환경이 중지될 때 실행됩니다.
  • 배포 또는 파이프라인이 성공, 취소, 또는 실패 상태인 경우 완료됩니다.

전제 조건:

  • 배포 및 중지 작업은 동일한 rules 또는 only/except 구성을 가져야 합니다.
  • 중지 작업에는 다음 키워드가 정의되어 있어야 합니다:
    • when, 다음 중 하나에서 정의됨:
    • 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: 앱 배포 만들기
  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: 앱 삭제 만들기
  when: manual
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: stop

특정 시간이 경과한 후 환경 중지

일정한 시간 이후에 환경을 자동으로 중지하도록 설정할 수 있습니다.

note
자원 제한으로 환경 중지를 위한 백그라운드 워커는 1시간에 한 번만 실행됩니다. 이는 환경이 정확한 시간에 중지되는 대신 백그라운드 워커가 만료된 환경을 감지할 때 중지되므로 환경이 중지될 수 있음을 의미합니다.

.gitlab-ci.yml 파일에서 environment:auto_stop_in 키워드를 지정합니다. 1시간 30분 또는 1일과 같이 자연어로 시간을 지정합니다. 시간이 경과하면 GitLab이 환경을 중지시키기 위한 작업이 자동으로 트리거됩니다.

다음 예에서:

  • Merge Request에 대한 각 커밋은 최신 변경을 환경에 배포하고 유효 기간을 재설정하는 review_app 작업을 트리거합니다.
  • 환경이 1주일 이상 비활성 상태인 경우 GitLab은 환경을 중지시키기 위해 자동으로 stop_review_app 작업을 트리거합니다. 
review_app:
  script: 리뷰 앱 배포
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    on_stop: stop_review_app
    auto_stop_in: 1주
  rules:
    - if: $CI_MERGE_REQUEST_ID

stop_review_app:
  script: 리뷰 앱 중지
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: stop
  rules:
    - if: $CI_MERGE_REQUEST_ID
      when: manual
환경의 예정된 중지 날짜와 시간 보기

환경이 지정된 시간 이후에 중지 예정인 경우, 해당 환경의 만료 날짜와 시간을 확인할 수 있습니다.

환경의 만료 날짜와 시간을 보려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
  2. 운영 > 환경를 선택합니다.
  3. 환경의 이름을 선택합니다.

만료 날짜와 시간이 환경 이름 옆 상단에 표시됩니다.

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

환경이 지정된 시간 이후에 중지 예정인 경우, 해당 환경의 만료를 재지정할 수 있습니다.

환경의 만료를 재지정하려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
  2. 운영 > 환경을 선택합니다.
  3. 배포 이름을 선택합니다.
  4. 오른쪽 상단에서 바늘로고 선택합니다.

auto_stop_in 설정이 재지정되며 환경은 매뉴얼으로 중지될 때까지 유지됩니다.

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

가끔은 정의된 on_stop 작업을 실행하지 않고 환경을 중지하려고 하는 경우가 있습니다. 예를 들어, 컴퓨팅 할당량을 사용하지 않고 많은 환경을 삭제하고 싶은 경우입니다.

on_stop 작업을 실행하지 않고 환경을 중지하려면, force=true 매개변수로 환경 중지 API를 실행하세요.

UI를 사용하여 환경 중지하기

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

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

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
  2. 운영 > 환경을 선택합니다.
  3. 중지하려는 환경 옆에서 중지를 선택합니다.
  4. 확인 대화상자에서 환경 중지를 선택합니다.

환경에 대한 여러 중지 작업

환경에서 여러 병렬 중지 작업을 구성하려면, 같은 environment에 대한 여러 배포 작업에서 .gitlab-ci.yml 파일에 정의된대로 on_stop 키워드를 지정하세요.

환경이 중지되면, 성공한 배포 작업의 일치하는 on_stop 작업이 병렬로 실행되며 특정한 순서는 없습니다.

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

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

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

환경이 중지되면, 시스템은 teardown-cloud-a 및 teardown-cloud-b의 on_stop 작업을 병렬로 실행합니다. 

deploy-to-cloud-a:
  script: echo "Deploy to cloud a"
  environment:
    name: test
    on_stop: teardown-cloud-a

deploy-to-cloud-b:
  script: echo "Deploy to cloud b"
  environment:
    name: test
    on_stop: teardown-cloud-b

teardown-cloud-a:
  script: echo "Delete the resources in cloud a"
  environment:
    name: test
    action: stop
  when: manual

teardown-cloud-b:
  script: echo "Delete the resources in cloud b"
  environment:
    name: test
    action: stop
  when: manual

환경 삭제

환경을 제거하고 해당 배포를 모두 제거하려면 환경을 삭제하세요.

필수 사항:

  • 적어도 개발자 역할이 있어야 합니다.
  • 삭제하기 전에 환경을 중지해야 합니다.

환경을 삭제하려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
  2. 운영 > 환경을 선택합니다.
  3. 중지됨 탭을 선택합니다.
  4. 삭제하려는 환경 옆에서 환경 삭제를 선택합니다.
  5. 확인 대화상자에서 환경 삭제를 선택합니다.

준비 또는 확인 목적을 위해 환경에 액세스

여러 목적을 위해 환경에 액세스하는 작업을 정의할 수 있습니다. 이는 배포 생성을 우회하여 CD 워크플로를 보다 정확하게 조정할 수 있도록 합니다.

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

build:
  stage: build
  script:
    - echo "Building the app"
  environment:
    name: staging
    action: prepare
    url: https://staging.example.com

이를 통해 환경 범위의 변수에 액세스할 수 있으며, 빌드를 무단 액세스로부터 보호하는 데 사용할 수 있습니다. 또한, 구식 배포 작업 방지 기능을 피하는 데 효과적입니다.

유사한 환경 그룹화

UI에서 환경을 축소 가능한 섹션으로 그룹화할 수 있습니다.

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

환경 그룹

다음 예에서 review로 환경 이름을 시작합니다. $CI_COMMIT_REF_SLUG 변수는 런타임에 브랜치 이름으로 채워집니다: 

deploy_review:
  stage: deploy
  script:
    - echo "Deploy a review app"
  environment:
    name: review/$CI_COMMIT_REF_SLUG

환경 이슈 관리

프로덕션 환경은 외부 요인으로 인해 예상치 못하게 중단될 수 있습니다. 예를 들어 외부 의존성 문제, 인프라 문제, 또는 인적 실수로 인해 중대한 문제가 발생할 수 있습니다. 다음과 같은 경우입니다:

  • 종속 클라우드 서비스 중단
  • 제3자 라이브러리 업데이트 및 응용프로그램과 호환되지 않음
  • 누군가 서버의 취약한 엔드포인트에 DDoS 공격 수행
  • 운영자가 인프라를 잘못 구성
  • 프로덕션 응용프로그램 코드에 버그 도입

긴급한 주의가 필요한 심각한 문제가 발생하면 사고 관리를 사용하여 경고를 받을 수 있습니다.

환경에 대한 최신 경고 보기

자세:

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

만약 Prometheus 메트릭에 대한 경고를 설정했다면, 환경에 대한 경고가 환경 페이지에 표시됩니다. 가장 심각한 심각도의 경고가 표시되므로 즉각적인 조치가 필요한 환경을 식별할 수 있습니다.

문제를 일으킨 경고가 해결되면, 해당 경고는 제거되어 환경 페이지에서 더 이상 표시되지 않습니다.

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

#### Auto Rollback

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

> - [GitLab 13.7에서 도입됨](https://gitlab.com/gitlab-org/gitlab/-/issues/35404).

일반적인 지속적인 배포 워크플로우에서 CI 파이프라인은 프로덕션 배포 전에 모든 커밋을 테스트합니다. 그러나 문제가 있는 코드는 여전히 프로덕션에 배포될 수 있습니다. 예를 들어 논리적으로 올바른 비효율적인 코드는 심각한 성능 저하를 일으킬 수 있지만 테스트를 통과할 수 있습니다. 운영자 및 SRE는 가능한 빨리 이러한 문제를 발견하기 위해 시스템을 모니터링합니다. 문제가 있는 배포를 발견하면 이전 안정적인 버전으로 롤백할 수 있습니다.

GitLab 자동 롤백은 [중요 경보](../../operations/incident_management/alerts.md)가 감지되면 자동으로 롤백을 트리거하여이 워크플로우를 용이하게 합니다. GitLab은 가장 최근에 성공한 배포를 선택하고 다시 배포합니다.

GitLab Auto Rollback의 제한 사항:

- 경보가 감지 될 때 배포가 실행 중이면 롤백이 건너 뜁니다.
- 3분에 한 번만 롤백이 발생할 수 있습니다. 한 번에 여러 경보가 감지되면 한 번의 롤백만 수행됩니다.

GitLab 자동 롤백은 기본적으로 비활성화되어 있습니다. 활성화하려면:

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

### Web 터미널(사용 중단)

> - [GitLab 14.5에서 사용 중단됨](https://gitlab.com/groups/gitlab-org/configure/-/epics/8).

WARNING:
이 기능은 [GitLab 14.5에서 사용 중단](https://gitlab.com/groups/gitlab-org/configure/-/epics/8)되었습니다.

환경과 관련된 터미널 버튼을 선택하여 터미널을 시작합니다:

![index_v14_3에서 환경 터미널 버튼](img/environments_terminal_button_on_index_v14_3.png)

! [환경에 대한 터미널 버튼](img/environments_terminal_button_on_show_v13_10.png)

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

! [터미널 페이지](../img/environments_terminal_page.png)

이 작업은 일반적인 터미널과 같이 작동합니다. 배포로 생성된 컨테이너에 있으므로 다음 작업을 수행할 수 있습니다.

- 셸 명령을 실행하고 실시간으로 응답받습니다.
- 로그를 확인합니다.
- 구성 또는 코드 변경을 시도합니다.

동일한 환경에 여러 터미널을 열 수 있습니다. 각각 독자적인 셸 세션과 `screen` 또는 `tmux`와 같은 멀티플렉서를 사용할 수 있습니다.

### 로컬로 배포 확인

각 배포에 대해 Git 리포지터리에 참조가 저장되므로 현재 환경 상태를 파악하기는 `git fetch`만으로도 가능합니다.

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

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

이전 배포 아카이브

프로젝트에서 새로운 배포가 발생하면 GitLab은 배포에 대한 특수 Git-ref를 생성합니다. 이러한 Git-ref는 원격 GitLab 리포지터리부터 채워지기 때문에 프로젝트의 배포 수가 증가함에 따라 git-fetch 및 git-pull과 같은 Git 작업이 느려질 수 있습니다.

Git 작업의 효율성을 유지하기 위해 GitLab은 최신 배포 refs(최대 50,000까지) 만 유지하고 이전의 refs는 삭제합니다. 아카이브된 배포는 감사 목적으로 UI에서 또는 API를 사용하여 여전히 사용할 수 있습니다. 또한 아카이브 한 후에도 리포지터리에서 배포된 커밋을 지정하여 가져올 수 있습니다 (예 : git checkout <deployment-sha>).

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

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

CI/CD 변수는 기본적으로 파이프라인의 모든 작업에서 사용할 수 있습니다. 따라서 프로젝트에서 테스트 작업에 손상된 도구를 사용하면 배포 작업에서 사용한 모든 CI/CD 변수가 노출될 수 있습니다. 이는 공급망 공격의 일반적인 시나리오입니다. GitLab은 변수의 환경 범위를 제한함으로써 공급망 공격을 완화하는 데 도움을 줍니다.

CI/CD 변수의 환경 범위를 제한하여 변수가 사용 가능한 환경을 정의함으로써 CI/CD 변수의 환경 범위를 제한할 수 있습니다. 예를 들어, 환경 범위가 production 인 경우 production 환경이 정의 된 작업 만이이 특정 변수를 가질 수 있습니다.

기본 환경 범위는 와일드 카드 (*)이며, 즉 정의된 환경에 관계없이 모든 작업이이 변수를 가질 수 있음을 의미합니다.

환경 범위가 review/*인 경우 review/로 시작하는 환경 이름을 가진 작업만이 해당 변수를 가질 수 있습니다. rules 및 include과 함께 환경 범위 변수를 사용하는 경우 파이프라인에서 예상대로 작동하지 않을 수 있습니다. 환경 범위 변수는 일치하는 작업에서만 설정되므로 GitLab이 파이프라인 구성을 유효성 검사할 때 변수가 정의되지 않을 수 있습니다.

대부분의 경우 이러한 기능은 각 환경 그룹에서 범위를 구현하기위한 효율적인 방법 인 환경 스펙 메커니즘을 사용합니다.

예를 들어 production, staging, review/feature-1, review/feature-2 네 가지 환경이 있다면 각 환경은 다음 환경 스펙과 일치합니다:

환경 스펙 production staging review/feature-1 review/feature-2
* 일치함 일치 안 함 일치함 일치함
production 일치함      
staging   일치함    
review/*     일치함 일치함
review/feature-1     일치함  

특정 매칭을 사용하여 특정 환경을 선택할 수 있습니다. 또한 Review Apps(review/*)와 같은 특정 환경 그룹을 선택하기 위해 와일드 카드 매칭 (*)을 사용할 수 있습니다.

가장 구체적인 스펙이 다른 와일드 카드 일치보다 우선합니다. 이 경우 review/feature-1 스펙이 review/* 및 * 스펙보다 우선합니다. ```

… (The rest of the text is too long and it is omitted)

환경 권한

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

환경 보기

  • 공개 프로젝트에서는 회원이 아닌 사람도 환경 디렉터리을 볼 수 있습니다.
  • 비공개 프로젝트에서는 환경 디렉터리을 보려면 적어도 리포터 역할이 있어야 합니다.

환경 생성 및 업데이트

  • 새 환경을 만들거나 기존의 미보호된 환경을 업데이트하려면 적어도 개발자 역할이 있어야 합니다.
  • 기존 환경이 보호되어 있고 액세스할 수 없으면 환경을 업데이트할 수 없습니다.

환경 중지 및 삭제

  • 미보호된 환경을 중지하거나 삭제하려면 적어도 개발자 역할이 있어야 합니다.
  • 환경이 보호되어 있고 액세스할 수 없으면 환경을 중지하거나 삭제할 수 없습니다.

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

보호된 브랜치로 푸시하거나 머지할 수 있는 경우:

  • 적어도 리포터 역할이 있어야 합니다.

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

  • 리포터 역할이 있는 그룹의 일부여야 합니다.

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

관련 주제

문제 해결

action: stop와 함께하는 작업이 실행되지 않음

경우에 따라 on_stop 작업이 구성되어 있는 환경이 중지되지 않을 수 있습니다. 이는 action: stop이 가능한 상태로 설정되지 않은 경우에 발생합니다.

예를 들어:

  • 환경이 실패한 작업이 있는 stage에서 환경이 시작될 수 있습니다. 그러면 이후 stage의 작업이 시작되지 않습니다. 따라서 환경에 대한 action: stop 작업이 이후 stage에 있으면 시작되지 않고 환경이 삭제되지 않습니다.
  • action: stop을 하는 작업이 아직 완료되지 않은 작업에 종속될 수 있습니다.

필요할 때마다 action: stop이 항상 실행될 수 있도록 하려면 다음 중 하나를 수행할 수 있습니다:

  • 두 작업을 동일한 stage에 넣으세요: 

    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 항목을 추가하여 stage의 순서와 상관없이 작업을 시작할 수 있도록 합니다: 

    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

“This job could not be executed because it would create an environment with an invalid parameter” 오류로 인해 배포 작업이 실패함

-이슈에서 소개됨 - GitLab 14.4에서.

프로젝트가 동적 환경을 생성하도록 구성된 경우, 동적으로 생성된 매개변수를 사용할 수 없어서 이 오류가 발생할 수 있습니다.

예를 들어, 프로젝트에 다음과 같은 .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!를 가진 새 Merge Request를 만드는 경우, review 작업은 review/bug-fix!라는 환경을 생성하려고 합니다. 그러나 !는 환경에 허용되지 않는 문자이므로 환경이 없이 실행하려고 하기 때문에 배포 작업이 실패합니다.

이를 해결하려면 다음 중 하나를 사용할 수 있습니다:

  • 유효하지 않은 문자를 포함하지 않는 새로운 피처 브랜치를 생성하세요. 예를 들어, bug-fix와 같이요.
  • CI_COMMIT_REF_SLUG를 사용하여 CI_COMMIT_REF_NAME 사전 정의된 변수를 대체하세요. 이렇게 하면 유효하지 않은 문자가 제거됩니다.

배포 refs를 찾을 수 없음

GitLab 14.5부터 GitLab은 Git 리포지터리의 성능을 유지하기 위해 구현된 환경를 삭제합니다.

아카이브된 Git refs를 복원해야 하는 경우, GitLab Self-managed 인스턴스의 관리자에게 다음 명령을 실행하도록 요청하세요: 

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

GitLab은 향후 성능에 대한 고민으로 이 지원을 중단할 수 있습니다. 해당 기능에 대한 동작을 논의하기 위해 GitLab 이슈 트래커에서 이슈를 개설할 수 있습니다.