환경 및 배포 보기
환경 검색
CI/CD 변수
환경 상태
환경의 유형
환경의 배포 등급
수동 배포 구성
배포별 신규 포함된 병합 요청 추적
환경 작업
환경 권한
관련 주제
문제 해결

환경 및 배포

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

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

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

GitLab:

각 환경으로의 전체 배포 이력 제공
배포를 추적하여 서버에 배포된 내용을 항상 파악할 수 있음

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

환경 및 배포 보기

필수 사항:

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

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

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

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

환경 검색

GitLab 15.5에서 도입.
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에서

필수 사항:

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

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

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

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

필수 사항:

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

.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 변수를 사용합니다.

전제 조건: - 적어도 개발자 역할이 있어야 합니다.

동적 환경을 만들려면 .gitlab-ci.yml 파일에서 다음을 수행하세요:

deploy 단계에서 작업을 정의합니다.
해당 작업에서 다음 환경 속성을 정의합니다:
- name: 관련 CI/CD 변수(예: $CI_COMMIT_REF_SLUG)를 사용합니다. 환경 이름에 정적 접두어를 추가하여 환경의 이름에 UI에서 그룹화되는 동일한 접두어를 가진 모든 환경을 추가할 수도 있습니다.
- url: 선택 사항입니다. 호스트 이름에 관련 CI/CD 변수(예: $CI_ENVIRONMENT_SLUG)를 접두어로 추가합니다.

참고: 일부 문자는 환경 이름에 사용할 수 없습니다. 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을 사용할 수 없습니다. 이를 해결하려면 병합 요청 파이프라인을 구성하십시오. 이는 러너가 피처 브랜치가 삭제된 후에도 레포지토리를 가져올 수 있도록 보장합니다. 자세한 내용은 런너용 참조 사양을 참조하세요.

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

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

환경 이름 변경

GitLab 14.3에서 UI를 사용하여 환경 이름을 변경하는 기능이 제거되었습니다.
GitLab 15.9에서 API를 사용하여 환경 이름을 변경하는 기능이 폐기되었습니다.
GitLab 16.0에서 API를 사용하여 환경 이름을 변경하는 기능이 제거되었습니다.

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

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

기존 환경을 중지.
기존 환경을 삭제.
원하는 이름으로 새로운 환경을 생성하세요.

환경의 배포 등급

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에서 해당 작업에 대한 재생 버튼을 노출하며 텍스트는 <environment>에 수동으로 배포할 수 있음입니다.
deploy_prod 작업은 재생 버튼이 선택된 경우에만 트리거됩니다.

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

배포별 신규 포함된 병합 요청 추적

기본적으로 비활성화되어 있고 GitLab 16.10에서 도입된 기능 플래그 link_fast_forward_merge_requests_to_deployment입니다.

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

추적을 활성화하려면:

프로젝트의 병합 방법을 설정하세요. 병합 방법:
- Fast-forward 병합이 아니어야 합니다.
- link_fast_forward_merge_requests_to_deployment 기능 플래그가 활성화된 경우 Fast-forward 병합이어도 괜찮습니다.
환경을 구성하세요. 다음 중 하나여야 합니다:
- 환경 이름이 /로 구분된 폴더를 사용하지 않습니다(장기 또는 최상위 환경).
- 환경 등급이 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에서 임의의 URL을 저장하도록 플래그인 soft_validation_on_external_url로 수정됨. 기본값은 비활성화됨.
GitLab 15.3에서 일반적으로 사용 가능 : 기능 플래그 soft_validation_on_external_url이 제거됨.

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

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

이 정보는 다음과 같은 경우에 병합 요청에서 확인할 수 있습니다:

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

예시:

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

GitLab의 Route Maps를 사용하면 Review Apps에 설정된 환경에서 소스 파일에서 곧바로 공개 페이지로 이동할 수 있습니다.

환경 중지

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

브랜치 삭제 시 환경 중지

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

다음 예시에서 deploy_review 작업은 환경을 정리하고 중지시키기 위해 stop_review 작업을 호출합니다.

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

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

병합 요청이 병합되거나 닫힐 때 환경 중지

병합 요청 파이프라인 구성을 사용하는 경우 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

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

Feature flag environment_stop_actions_include_all_finished_deployments가 GitLab 16.9에서 도입되었습니다. 기본 상태는 비활성화되어 있습니다.

플래그: 자체 관리형 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가 활성화된 경우:

환경이 중지될 때 최신 완료된 파이프라인의 완료된 배포의 중지 작업이 실행됩니다.
배포 또는 파이프라인이 성공적, 취소된 또는 실패한 상태인 경우 해당 배포나 파이프라인은 완료된 상태입니다.

필수 구성 요소:

배포 및 중지 작업은 동일한 규칙 또는 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

특정 시간이 지난 후 환경 중지

일정 시간이 지난 후 환경을 자동으로 중지할 수 있습니다.

참고: 자원 제한으로 인해 환경을 중지하는 백그라운드 워커는 1시간마다 한 번만 실행됩니다. 즉, 환경이 정확한 시간 경과 후에 중지되지 않을 수 있으며, 대신 백그라운드 워커가 만료된 환경을 감지하면 중지됩니다.

.gitlab-ci.yml 파일에서 environment:auto_stop_in 키워드를 지정하십시오. 1시간 30분 또는 1일과 같이 자연어로 시간을 지정합니다. 시간이 경과하면 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

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

환경이 특정 시간이 지난 후 중지하도록 예약된 경우, 해당 환경의 만료 날짜 및 시간을 확인할 수 있습니다.

환경의 만료 날짜와 시간 확인 방법:

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

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

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

환경이 지정된 시간 이후에 중지 예정으로 예약되었을 때 중지를 재정의할 수 있습니다.

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

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

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

`on_stop` 액션 실행 없이 환경 중지

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

on_stop 액션을 실행하지 않고 환경을 중지하려면 force=true 매개변수를 사용하여 환경 중지 API를 실행합니다.

UI를 사용하여 환경 중지

참고: 환경 보기에서 on_stop 액션을 트리거하고 환경을 수동으로 중지하려면 중지 및 배포 작업이 동일한 resource_group에 있어야 합니다.

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

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

환경에 대한 여러 중지 작업

GitLab 14.10에서 도입, environment_multiple_stop_actions라는 플래그로 비활성화됨, 기본적으로 비활성화됨.
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을 병렬로 실행합니다.

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

환경 삭제

환경을 모두 제거하려는 경우 환경을 삭제합니다.

전제 조건:

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

환경을 삭제하려면:

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

환경 접근을 위한 준비 또는 확인 목적으로 접근

GitLab 13.2에서 도입됨.

검증 또는 준비와 같은 다양한 목적으로 환경에 접근하는 작업을 정의할 수 있습니다. 이렇게 하면 배포 생성을 우회하여 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

환경 사고 관리

생산 환경은 예상치 못하게 다운될 수 있으며, 통제 범위를 벗어난 이유로도 다운될 수 있습니다. 예를 들어, 외부 종속성 문제, 인프라 문제 또는 인적 실수로 환경에 심각한 문제가 발생할 수 있습니다. 다음과 같은 경우들이 있습니다:

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

긴요한 문제가 발생해 즉각적인 주의가 필요한 경우 사고 관리를 사용할 수 있습니다.

환경의 최신 경고 확인

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

소개됨 in GitLab 13.4.

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

경고를 발생시킨 이슈가 해결되면 제거되어 더 이상 환경 페이지에 표시되지 않습니다.

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

자동 롤백

세부 정보: Tier: 최고 Offering: GitLab.com, Self-managed, GitLab Dedicated

소개됨 in GitLab 13.7.

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

GitLab 자동 롤백은 중대한 경고가 감지될 때 자동으로 롤백을 시작하여 이 워크플로우를 용이하게 합니다. GitLab은 가장 최근에 성공한 배포를 선택하고 다시 배포합니다.

GitLab 자동 롤백의 제약사항:

경고가 감지된 상태에서 배포가 실행 중이면 롤백이 건너뛰어집니다.
롤백은 세 분에 한 번만 발생할 수 있습니다. 동시에 여러 경고가 감지되어도 한 번의 롤백만 수행합니다.

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

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

웹 터미널 (더 이상 사용되지 않음)

GitLab 14.5에서 사용 중닥됨.

경고: 이 기능은 GitLab 14.5에서 사용되지 않음.

만약 배포 서비스의 도움을 받아 환경에 배포한다면 (예를 들어, Kubernetes 통합), GitLab은 환경에 대한 터미널 세션을 열 수 있습니다. 그러면 웹 브라우저를 떠나지 않고도 문제를 디버깅할 수 있습니다.

웹 터미널은 컨테이너 기반 배포로, 종종 기본 도구 (예: 에디터)가 부족하며 언제든지 중지되거나 다시 시작될 수 있습니다. 이런 경우, 모든 변경 사항이 사라집니다. 웹 터미널은 포괄적인 온라인 IDE가 아닌 디버깅 도구로 취급하세요.

웹 터미널:

프로젝트 유지보수자 및 소유자만 사용할 수 있습니다.
활성화되어야 합니다.

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

특정 환경 페이지에서도 터미널 버튼에 접근할 수 있습니다:

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

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

셸 명령 실행 및 실시간으로 응답 받기.
로그 확인.
설정 또는 코드 수정 시도하기.

동일한 환경에 여러 터미널을 열 수 있습니다. 각각이 자체 셸 세션과 screen 또는 tmux와 같은 멀티플렉서를 얻습니다.

로컬로 배포 확인

각 배포마다 Git 저장소에 참조가 저장되므로 현재 환경의 상태를 파악하는 것은 git fetch만으로 가능합니다.

Git 구성에서 [remote "<your-remote>"] 블록에 추가로 fetch 라인을 추가하세요.

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

이전 배포 아카이브

GitLab 14.5에 도입됨.
GitLab 14.6에서 GitLab.com 및 Self-Managed에서 활성화됨.
GitLab 14.0에서 일반적으로 사용 가능. 기능 플래그 deployments_archive 삭제됨.

프로젝트에 새로운 배포가 발생하면 GitLab은 해당 배포를 위한 특별한 Git-ref를 생성합니다. 이러한 Git-ref는 원격 GitLab 저장소에서 생성되므로 프로젝트의 배포 수가 증가함에 따라 git-fetch 및 git-pull과 같은 Git 작업이 느려질 수 있습니다.

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

참고: GitLab은 모든 커밋을 keep-around ref로 유지하여 배포된 커밋이 배포 ref에서 참조되지 않더라도 가비지 수집되지 않습니다.

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

GitLab Premium 9.4에 도입됨.
CI/CD 변수의 환경 범위는 GitLab Premium에서 Gitlab Free로 이동됨.
그룹 CI/CD 변수의 환경 범위는 GitLab Premium에서 13.11에 추가되었습니다(https://gitlab.com/gitlab-org/gitlab/-/issues/2874).

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

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/* 및 * 스펙보다 우선합니다.

환경 권한

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

환경 보기

공개 프로젝트에서는 비회원을 포함한 누구나 환경 목록을 볼 수 있습니다.
비공개 프로젝트에서는 환경 목록을 볼려면 적어도 기고자 역할이 있어야 합니다.

환경 생성 및 업데이트

새로운 환경을 생성하거나 기존의 보호되지 않은 환경을 업데이트하려면 적어도 개발자 역할이 있어야 합니다.
기존 환경이 보호되어 있고 액세스할 수 없는 경우 환경을 업데이트할 수 없습니다.

중지 및 삭제 환경

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

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

보호된 브랜치에 푸시하거나 병합할 수 있다면:

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

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

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

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

문제 해결

‘action: stop’를 사용한 작업이 실행되지 않음

특정 상황에서 환경이 중지되지 않을 수 있습니다. 이는 on_stop 작업이 구성되었음에도 불구하고 발생합니다. 이는 해당 action: stop를 가진 작업이 stages: 또는 needs: 설정 때문에 실행할 수 없는 상태에 있기 때문입니다.

예를 들어:

환경이 실패한 작업이 있는 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!라는 브랜치 이름으로 생성한다면, 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 14.5부터 GitLab은 이전의 배포 참조를 삭제하여 귀하의 Git 저장소를 성능적으로 유지합니다.

만약 아카이브된 Git-참조를 복원해야 한다면, 자체 호스팅된 GitLab 인스턴스의 관리자에게 다음 명령어를 Rails 콘솔에서 실행하도록 요청하세요.

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

GitLab은 성능상의 이유로 이 지원을 향후에 중단할 수 있습니다. 이 기능의 동작에 대해 토론하기 위해 GitLab Issue Tracker에서 이슈를 열 수 있습니다.

환경 및 배포

환경 및 배포 보기

환경 검색

CI/CD 변수

환경 상태

환경의 유형

정적 환경 생성

UI에서

.gitlab-ci.yml 파일에서

동적 환경 생성

동적 환경 URL 설정

환경 이름 변경

환경의 배포 등급

수동 배포 구성

배포별 신규 포함된 병합 요청 추적

환경 작업

환경 롤백

배포 다시 시도 또는 롤백

환경 URL

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

환경 중지

브랜치 삭제 시 환경 중지

병합 요청이 병합되거나 닫힐 때 환경 중지

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

특정 시간이 지난 후 환경 중지

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

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

on_stop 액션 실행 없이 환경 중지

UI를 사용하여 환경 중지

환경에 대한 여러 중지 작업

환경 삭제

환경 접근을 위한 준비 또는 확인 목적으로 접근

유사한 환경 그룹화

환경 사고 관리

환경의 최신 경고 확인

자동 롤백

웹 터미널 (더 이상 사용되지 않음)

로컬로 배포 확인

이전 배포 아카이브

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

환경 권한

환경 보기

환경 생성 및 업데이트

중지 및 삭제 환경

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

관련 주제

문제 해결

‘action: stop’를 사용한 작업이 실행되지 않음

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

만약 리뷰 앱에서 이 오류를 받는다면

배포 참조를 찾을 수 없음

도움말

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

도움받기

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

`on_stop` 액션 실행 없이 환경 중지