환경 및 배포 보기
환경 검색
CI/CD 변수
환경 상태
환경 유형
환경의 배포 계층
매뉴얼 배포 구성
배포별로 포함된 새로운 Merge Request 추적
환경 작업
환경 권한
관련 주제
문제 해결

환경 및 배포

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

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

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

GitLab:

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

프로젝트에 Kubernetes와 같은 배포 서비스가 연결되어 있다면 해당 서비스를 사용하여 배포를 지원할 수 있습니다.

환경 및 배포 보기

전제 조건:

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

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

프로젝트 개요 페이지에서, 하나 이상의 환경(즉, 중지되지 않은 환경)이 있는 경우.
왼쪽 사이드바에서 운영 > 환경을 선택합니다. 환경이 표시됩니다.
특정 환경 이름(예: staging)을 선택하여 해당 환경의 배포 디렉터리을 볼 수 있습니다.

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

환경 검색

GitLab 15.5에서 도입됨 (https://gitlab.com/gitlab-org/gitlab/-/issues/10754).
GitLab 15.7에서 폴더 내에서 환경 검색이 도입되었으며 피처 플래그 enable_environments_search_within_folder에 의해 기본적으로 활성화됨.

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

왼쪽 사이드바에서 검색 또는 이동을 선택하여 프로젝트를 찾습니다.
운영 > 환경을 선택합니다.
검색 창에 검색어를 입력합니다.
- 검색어의 길이는 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에서

전제 조건:

적어도 Developer 역할이 있어야 합니다.

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

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

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

전제 조건:

적어도 Developer 역할이 있어야 합니다.

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

deploy 단계에서 작업을 정의합니다.
작업에서 환경 이름과 url을 정의합니다. 파이프라인 실행 시 그 이름의 환경이 없으면 생성됩니다.

일부 문자는 환경 이름으로 사용할 수 없습니다. 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 변수를 사용합니다.

전제 조건:

적어도 Developer 역할이 있어야 합니다.

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

deploy 단계에서 작업을 정의합니다.
작업에서 다음과 같은 환경 속성을 정의합니다.
- name: $CI_COMMIT_REF_SLUG와 같은 관련 CI/CD 변수를 사용합니다. 환경 이름의 경우에는 해당 이름과 관련된 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 설정를 참조하십시오.

다음 예제에서 리뷰 앱은 각 Merge Request에 대해 새 환경을 생성합니다:

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을 사용할 수 없는 경우, 이러한 작업에 대한 Merge Request 파이프라인을 구성하십시오. 이렇게 하면 러너가 피처 브랜치가 삭제된 후에도 리포지터리를 가져올 수 있습니다. 자세한 내용은 러너에 대한 ref 명세를 참조하십시오.

Windows 러너의 경우 .env 파일에 쓰기 위해 PowerShell의 Add-Content 명령을 사용해야 합니다.

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

환경 이름 변경

GitLab 15.9에서 API를 사용하여 환경 이름을 변경하는 것은 deprecated되었습니다.
GitLab 16.0에서 API를 사용하여 환경 이름을 변경하는 것이 삭제되었습니다.

환경 이름을 변경할 수 없습니다.

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

기존 환경을 중지합니다.
기존 환경을 삭제합니다.
원하는 이름으로 새 환경을 생성합니다.

환경의 배포 계층

가끔은 production과 같은 산업 표준 환경 이름 대신 customer-portal과 같은 코드 이름을 사용하고 싶을 수 있습니다. customer-portal과 같은 이름을 사용하는 기술적인 이유는 없지만, 그 이름은 이제 환경이 프로덕션용으로 사용되고 있는지를 더 이상 나타내지 않습니다.

특정 환경이 특정 용도로 사용되는 것을 나타내려면 환경 계층을 사용할 수 있습니다:

환경 계층	환경 이름 예시
`production`	Production, Live
`staging`	Staging, Model, Demo
`testing`	Test, QC
`development`	Dev, Review apps, 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에서 작업에 대한 실행() 버튼을 노출하며, 텍스트는 <environment>에 매뉴얼으로 배포할 수 있음입니다.
deploy_prod 작업은 수동으로 트리거해야 합니다.

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

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

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

추적을 활성화하려면 환경을 다음 중 하나로 구성하세요:

environment name이 /로 구분된 폴더를 사용하지 않음(지속적으로 사용되는 또는 최상위 환경).
environment tier가 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 명령이 여러 작업으로 분리된 경우에는 배포 또는 롤백 작업을 매뉴얼으로 실행해야 합니다.

배포를 다시 시도하거나 롤백하기

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

배포를 다시 시도하거나 롤백하려면 다음을 수행하세요:

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

프로젝트에서 누적된 배포 작업을 방지했다면, 롤백 버튼이 숨겨지거나 비활성화될 수 있습니다. 이 경우, 롤백 배포를 위한 작업 재시도를 확인하세요.

환경 URL

GitLab 15.2에서 soft_validation_on_external_url이라는 플래그로 임의의 URL을 영구적으로 저장하도록 변경.
GitLab 15.3에서 일반적으로 사용 가능하게 되었으며, 피처 플래그 soft_validation_on_external_url가 제거되었습니다.

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

Merge Request 내에서 링크로:
환경 보기에서 버튼으로:
배포 보기에서 버튼으로:

이 정보를 볼 수 있는 경우:

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

예를 들어:

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

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

환경 중지

환경을 중지하면 해당 환경의 배포에 대한 서버에서의 접근이 불가능해집니다. 환경을 삭제하기 전에 반드시 환경을 중지해야 합니다.

브랜치 삭제 시 환경 중지

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

다음과 같이 deploy_review 작업이 환경을 정리하고 중지하는 stop_review 작업을 호출하는 예제입니다.

두 작업은 동일한 rules 또는 only/except 설정을 가져야 합니다. 그렇지 않으면 stop_review 작업이 deploy_review 작업을 포함하는 모든 파이프라인에 포함되지 않을 수 있으며, 자동으로 환경을 중지하는 action: stop을 트리거할 수 없습니다.
action: stop이 있는 작업은 별도로 실행되지 않을 수 있습니다.
만약 Merge Request 파이프라인을 사용할 수 없는 경우, stop_review 작업의 .gitlab-ci.yml 파일에서 GIT_STRATEGY를 none으로 설정하세요. 그럼 러너(runner)는 브랜치가 삭제된 후에 코드 체크아웃을 시도하지 않습니다.

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

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.
GitLab 17.0에서 제거된 피처 플래그 environment_stop_actions_include_all_finished_deployments.

환경의 배포 작업에 on_stop 동작을 정의하여 환경에 stop 작업을 정의할 수 있습니다.

가장 최근 파이프라인에서 완료된 배포의 중지 작업이 환경이 중지될 때 실행됩니다. 배포 또는 파이프라인이 성공적, 취소됨, 실패의 상태일 때, 배포 또는 파이프라인이 _완료_됩니다.

전제 조건:

배포 및 중지 작업은 동일한 규칙 또는 only/except 구성을 가져야 합니다.
중지 작업에는 다음 키워드를 정의해야합니다.
- when, 작업 수준에서 정의:
  - 작업 수준에서 정의된 경우.
  - 규칙 절에 정의된 경우. rules 및 when: manual을 사용하는 경우 작업이 실행되지 않아도 파이프라인이 완료되도록 allow_failure: true를 설정해야 합니다.

다음 예에서:

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

특정 기간 후에 환경 중지

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

자원 제한으로 인해 환경을 중지하는 백그라운드 워커는 1시간에 한 번만 실행됩니다. 따라서 설정된 정확한 시간이 아닌 환경이 만료될 때 중지됩니다.

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

다음 예에서:

Merge Request에 대한 각 커밋은 가장 최근 변경을 환경에 배포하고 만료 기간을 재설정하는 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

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

환경이 지정된 기간 후에 중지 예정으로 예약된 경우, 만료 날짜와 시간을 볼 수 있습니다.

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

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

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

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

환경이 지정된 기간 후에 중지 예정으로 예약된 경우, 만료를 재정의할 수 있습니다.

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

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

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

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

auto_stop_in 설정이 재정의되고 환경은 매뉴얼으로 중지될 때까지 활성 상태로 유지됩니다.

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

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

on_stop 동작을 실행하지 않고 환경을 중지하려면 force=true 매개변수와 함께 Stop an environment API를 실행하십시오.

UI를 사용하여 환경 중지

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

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

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

환경에 대한 여러 중지 동작

GitLab 15.0에서 일반적으로 사용 가능. 피처 플래그 environment_multiple_stop_actions 제거됨.

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

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

환경의 모든 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 "cloud a에 배포"
  environment:
    name: test
    on_stop: teardown-cloud-a

deploy-to-cloud-b:
  script: echo "cloud b에 배포"
  environment:
    name: test
    on_stop: teardown-cloud-b

teardown-cloud-a:
  script: echo "cloud a의 리소스 삭제"
  environment:
    name: test
    action: stop
  when: manual

teardown-cloud-b:
  script: echo "cloud b의 리소스 삭제"
  environment:
    name: test
    action: stop
  when: manual

환경 삭제

환경을 삭제하려면 해당 환경과 모든 배포를 제거하려고 할 때 삭제할 수 있습니다.

전제 조건:

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

환경을 삭제하려면:

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

준비 또는 확인 목적으로 환경 액세스

확인 또는 준비와 같은 여러 목적으로 환경에 액세스하는 작업을 정의할 수 있습니다. 이를 통해 배포 생성을 우회하여 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

환경 사고 관리

프로덕션 환경은 예기치 못하게 다운될 수 있으며, 이는 외부 의존성, 인프라, 또는 인적 실수와 같은 이유로 발생할 수 있습니다. 다음과 같이 말이죠:

의존하는 클라우드 서비스가 다운됨.
서드파티 라이브러리가 업데이트되었지만 응용프로그램과 호환되지 않음.
누군가 서버의 취약한 엔드포인트로 DDoS 공격을 수행함.
운영자가 인프라를 잘못 구성함.
프로덕션 응용프로그램 코드에 버그가 포함됨.

사고 관리를 사용하여 즉각 조치가 필요한 중요한 문제에 대한 알림을 받을 수 있습니다.

환경의 최신 알림 보기

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

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

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

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

자동 롤백

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

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

GitLab Auto Rollback은 중요 경고가 감지되면 자동으로 롤백을 트리거하여 이 워크플로우를 간소화합니다. GitLab이 올바른 환경을 선택하고 가장 최근의 성공적인 배포를 재배포합니다.

GitLab Auto Rollback의 제한 사항:

경고가 감지된 상태에서 배포가 진행 중이면 롤백이 건너뜀.
롤백은 3분마다 한 번만 발생합니다. 한 번에 여러 경고가 감지되더라도 하나의 롤백만 수행됩니다.

GitLab Auto Rollback은 기본적으로 비활성화되어 있습니다. 활성화하려면:

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

웹 터미널 (deprecated)

이 기능은 GitLab 14.5에서 deprecated되었습니다.

프로젝트의 환경을 배포 서비스(예: Kubernetes 통합)를 통해 배포하면 GitLab이 환경에 대한 터미널 세션을 열 수 있습니다. 그럼 이를 통해 웹 브라우저를 벗어나지 않고 문제를 디버깅할 수 있습니다.

웹 터미널은 컨테이너 기반 배포로, 기본적인 툴 (예: 에디터)이 부족하며 언제든지 중지 또는 다시 시작될 수 있습니다. 이렇게 되면 모든 변경 사항이 손실됩니다. 웹 터미널은 포괄적인 온라인 IDE가 아닌 디버깅 도구로 취급해야 합니다.

웹 터미널:

프로젝트 관리자 및 소유자에게만 사용할 수 있습니다.
활성화해야 합니다.

UI에서 환경 색인에서 터미널을 선택하여 웹 터미널을 볼 수 있습니다:

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

버튼을 선택하여 터미널 세션을 시작할 수 있습니다:

이것은 다른 터미널과 마찬가지로 작동합니다. 배포로 만든 컨테이너에 있으므로 다음을 할 수 있습니다:

셸 명령 실행 및 실시간으로 응답 받기
로그 확인
구성 또는 코드 조정 시도

동일한 환경에 여러 터미널을 열 수 있습니다. 각각 자체 셸 세션이 생기며, screen이나 tmux와 같은 멀티플렉서도 사용할 수 있습니다.

로컬로 배포 확인

각 배포에 대해 Git 리포지터리에 참조가 저장되므로 현재 환경 상태를 알아내려면 git fetch만 하면 됩니다.

Git 구성에서 추가적인 fetch 줄을 포함하여 [remote "<your-remote>"] 블록을 수정하십시오.

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

이전 배포 아카이브

프로젝트에서 새로운 배포가 발생하면 GitLab은 배포에 대한 특별한 Git-ref를 만듭니다. 이러한 Git-ref는 원격 GitLab 리포지터리에서 가져온 것이므로 프로젝트 내의 배포 수가 증가함에 따라 git-fetch 및 git-pull과 같은 일부 Git 작업이 느려질 수 있습니다.

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

GitLab은 배포 리프에 의해 참조되지 않더라도 배포된 커밋을 keep-around refs로 유지하여 쓰레기 수집되지 않습니다.

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

기본적으로 CI/CD 변수는 파이프라인의 모든 작업에서 사용할 수 있습니다. 작업 내의 테스트 도구가 손상되면, 해당 도구는 작업에서 사용 가능한 모든 CI/CD 변수를 가져오려고 시도할 수 있습니다. 이러한 공급망 공격을 완화하기 위해 민감한 변수의 환경 범위를 해당 변수가 필요한 작업에만 제한해야 합니다.

CI/CD 변수의 환경 범위를 정의하여 해당 변수가 사용 가능한 환경을 제한할 수 있습니다. 기본 환경 범위는 * 와일드카드이므로 모든 작업에서 해당 변수에 액세스할 수 있습니다.

특정 매칭을 사용하여 특정 환경을 선택할 수 있습니다. 예를 들어, 변수의 환경 범위를 production으로 설정하여 환경이 production인 작업에서만 해당 변수에 액세스하도록 할 수 있습니다.

또한 모든 리뷰 앱 중 일부 환경 그룹을 선택하기 위해 와일드카드 매칭(*)을 사용할 수 있습니다.

예를 들어, 다음 네 가지 환경이 있는 경우:

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

다음과 같이 환경 범위가 일치합니다.

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

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

환경 권한

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

환경 보기

공개 프로젝트에서 비회원을 포함한 누구나 환경 디렉터리을 볼 수 있습니다.
비공개 프로젝트에서는 최소한 Reporter 역할이 있어야 환경 디렉터리을 볼 수 있습니다.

환경 생성 및 업데이트

새 환경을 만들거나 기존의 보호되지 않은 환경을 업데이트하려면 최소한 Developer 역할이 필요합니다.
기존 환경이 보호되어 있고 해당 환경에 액세스할 수 없는 경우 환경을 업데이트할 수 없습니다.

중지 및 삭제 환경

보호되지 않은 환경을 중지하거나 삭제하려면 최소한 Developer 역할이 필요합니다.
환경이 보호되어 있고 해당 환경에 액세스할 수 없는 경우 환경을 중지하거나 삭제할 수 없습니다.

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

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

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

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

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

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

문제 해결

`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_SLUG로 미리 정의된 변수를 사용하여 CI_COMMIT_REF_NAME을 대체하세요. 이 변수를 사용하면 모든 유효하지 않은 문자가 제거됩니다.
```
review:
  script: deploy review app
  environment: review/$CI_COMMIT_REF_SLUG
```

배포 refs를 찾을 수 없음

GitLab은 이전 배포 refs를 삭제하여 귀하의 Git 리포지터리의 성능을 유지합니다.

백업된 Git-refs를 복원해야 하는 경우, Self-Managed형 GitLab 인스턴스의 관리자에게 다음 명령을 Rails 콘솔에서 실행하도록 요청하십시오:

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

GitLab은 향후 성능 관련 우려로 이러한 지원을 중단할 수 있습니다. 이 기능의 동작에 대해 논의하려면 GitLab 이슈 트래커에서 이슈를 열 수 있습니다.

환경 및 배포

환경 및 배포 보기

환경 검색

CI/CD 변수

환경 상태

환경 유형

정적 환경 생성

UI에서

.gitlab-ci.yml 파일에서

동적 환경 생성

동적 환경 URL 설정

환경 이름 변경

환경의 배포 계층

매뉴얼 배포 구성

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

환경 작업

환경 롤백

배포를 다시 시도하거나 롤백하기

환경 URL

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

환경 중지

브랜치 삭제 시 환경 중지

머지 요청이 Merge되거나 닫힐 때 환경을 중지합니다

환경이 중지된 후 파이프라인 작업 실행하기

특정 기간 후에 환경 중지

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

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

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

UI를 사용하여 환경 중지

환경에 대한 여러 중지 동작

환경 삭제

준비 또는 확인 목적으로 환경 액세스

유사한 환경 그룹화

환경 사고 관리

환경의 최신 알림 보기

자동 롤백

웹 터미널 (deprecated)

로컬로 배포 확인

이전 배포 아카이브

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

환경 권한

환경 보기

환경 생성 및 업데이트

중지 및 삭제 환경

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

관련 주제

문제 해결

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

“이 작업은 유효하지 않은 매개변수가 있는 환경을 작성하게 될 수 없으므로 실행할 수 없습니다” 오류로 인해 배포 작업이 실패함

리뷰 앱에서 이 오류를 받은 경우

배포 refs를 찾을 수 없음

도움말

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

도움받기

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

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

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