GitLab 환경은 개발, 스테이징 또는 프로덕션과 같이 애플리케이션의 특정 배포 대상을 나타냅니다. 이를 사용하여 소프트웨어 라이프사이클의 다양한 단계에서 다양한 구성을 관리하고 코드를 배포합니다.

환경을 사용하면 다음과 같은 작업을 수행할 수 있습니다:

• 배포 프로세스의 일관성과 반복 가능성 유지
• 어디에 어떤 코드가 배포되었는지 추적
• 문제 발생 시 이전 버전으로 롤백
• 무단 변경으로부터 민감한 환경 보호
• 보안 경계를 유지하기 위해 환경별 배포 변수 제어
• 환경 상태 모니터링 및 문제 발생 시 알림 수신

환경 및 배포 보기#

사전 조건:

• 비공개 프로젝트에서는 Reporter, Developer, Maintainer 또는 Owner 권한이 있어야 합니다. 환경 권한을 참조하세요.

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

• 최소한 하나의 환경이 사용 가능한 경우(즉, 중지되지 않은 경우) 프로젝트의 개요 페이지에서 볼 수 있습니다.

  

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

  

• 환경의 배포 목록을 보려면 환경 이름(예: staging)을 선택합니다. 배포 job이 배포를 생성한 후에만 이 목록에 배포가 표시됩니다.

  

• 배포 파이프라인의 모든 수동 job 목록을 보려면 실행 ([play]) 드롭다운 목록을 선택합니다.

  

환경 URL#

히스토리

• GitLab 15.2에서 임의의 URL을 유지하도록 변경되었습니다. soft_validation_on_external_url이라는 플래그가 있습니다. 기본적으로 비활성화됩니다.
• GitLab 15.3에서 일반 제공됩니다. 기능 플래그 soft_validation_on_external_url이 제거되었습니다.

환경 URL은 GitLab의 몇 가지 곳에 표시됩니다:

• 머지 리퀘스트에서 링크로:

  

• 환경 보기에서 버튼으로:

  

• 배포 보기에서 버튼으로:

  

다음 조건이 모두 충족되면 머지 리퀘스트에서 이 정보를 볼 수 있습니다:

• 머지 리퀘스트가 기본 브랜치(일반적으로 main)에 머지됩니다.
• 해당 브랜치도 환경(예: staging 또는 production)에 배포됩니다.

예:

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

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

환경 유형#

환경은 정적 또는 동적으로 구분됩니다.

정적 환경:

• 일반적으로 연속 배포에 의해 재사용됩니다.
• 정적 이름을 갖습니다. 예: staging 또는 production.
• 수동으로 또는 CI/CD 파이프라인의 일부로 생성됩니다.

동적 환경:

• 일반적으로 CI/CD 파이프라인에서 생성되며 단일 배포에만 사용된 후 중지 또는 삭제됩니다.
• 동적 이름을 가지며, 일반적으로 CI/CD 변수의 값을 기반으로 합니다.
• 리뷰 앱의 기능입니다.

환경은 정지 job이 실행되었는지 여부에 따라 세 가지 상태 중 하나를 가집니다:

• available: 환경이 존재합니다. 배포가 있을 수 있습니다.
• stopping: _on stop job_이 시작되었습니다. on stop job이 정의되지 않은 경우 이 상태는 적용되지 않습니다.
• stopped: _on stop job_이 실행되었거나 사용자가 수동으로 job을 중지했습니다.

정적 환경 생성#

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

UI에서#

사전 조건:

• Developer, Maintainer 또는 Owner 권한이 있어야 합니다.

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

1. 상단 표시줄에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 운영 > 환경을 선택합니다.
3. 환경 생성을 선택합니다.
4. 필드를 완성합니다.
5. 저장을 선택합니다.

.gitlab-ci.yml 파일에서#

사전 조건:

• Developer, Maintainer 또는 Owner 권한이 있어야 합니다.

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

1. deploy 스테이지에 job을 정의합니다.
2. job에서 환경 name과 url을 정의합니다. 파이프라인이 실행될 때 해당 이름의 환경이 없으면 생성됩니다.

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

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

동적 환경 생성#

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

사전 조건:

• Developer, Maintainer 또는 Owner 권한이 있어야 합니다.

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

1. deploy 스테이지에 job을 정의합니다.
2. job에서 다음 환경 속성을 정의합니다:
   • name: $CI_COMMIT_REF_SLUG와 같은 관련 CI/CD 변수를 사용합니다. 선택적으로 환경 이름에 정적 접두사를 추가하면 UI에서 그룹화됩니다.
   • url: 선택 사항. 호스트 이름 앞에 $CI_ENVIRONMENT_SLUG와 같은 관련 CI/CD 변수를 붙입니다.

다음 예에서 deploy_review_app job이 실행될 때마다 환경의 이름과 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을 참조하기 어렵습니다.

배포 job이 생성된 URL을 dotenv 변수로 캡처하여 environment:url에 전달하도록 구성할 수 있습니다. job에서 artifacts:reports:dotenv를 지정합니다. job이 완료되면 GitLab은 dotenv 보고서를 파싱하고 해당 변수 값으로 environment:url을 확장합니다. 할당된 URL은 UI에서 확인할 수 있습니다.

https://$DYNAMIC_ENVIRONMENT_URL처럼 정적 접두사와 변수를 조합할 수도 있습니다. DYNAMIC_ENVIRONMENT_URL이 example.com이면 결과는 https://example.com이 됩니다.

개요를 보려면 job이 완료된 후 동적 URL 설정을 참조하세요.

다음 예에서 리뷰 앱은 각 머지 리퀘스트에 대해 새 환경을 생성합니다:

• review job은 모든 푸시에 의해 트리거되며 review/your-branch-name이라는 환경을 생성하거나 업데이트합니다. 환경 URL은 $DYNAMIC_ENVIRONMENT_URL로 설정됩니다.
• review job이 완료되면 GitLab은 review/your-branch-name 환경의 URL을 업데이트합니다. deploy.env 보고서를 파싱하여 변수를 추출하고, 이를 사용하여 environment: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 job에서 environment:url을 설정하면 안 됩니다.
• 환경 URL이 유효하지 않은 경우(예: URL 형식이 잘못된 경우) 시스템은 환경 URL을 업데이트하지 않습니다.
• stop_review에서 실행되는 스크립트가 리포지터리에만 있는 경우 GIT_STRATEGY: none 또는 GIT_STRATEGY: empty를 사용할 수 없다면 이러한 job에 대해 머지 리퀘스트 파이프라인을 구성하세요. 이렇게 하면 기능 브랜치가 삭제된 후에도 러너가 리포지터리를 가져올 수 있습니다. 자세한 내용은 러너를 위한 Ref 스펙을 참조하세요.

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

환경의 배포 티어#

동일한 그룹 내 프로젝트들이 같은 배포 티어에 서로 다른 환경 이름을 사용할 수 있습니다. 예를 들어 한 프로젝트는 production을, 다른 프로젝트는 같은 티어에 custom-portal을 사용할 수 있습니다. 그룹 보호 환경은 이러한 차이를 처리하기 위해 배포 티어를 사용합니다.

사용 가능한 배포 티어는 다음과 같습니다:

• development
• testing
• staging
• production
• other

GitLab은 다음 패턴에 따라 환경 이름으로부터 배포 티어를 자동으로 추측합니다:

패턴과 일치하지 않는 환경 이름은 other로 추측됩니다.

자동 추측을 방지하려면 deployment_tier 키워드를 사용합니다.

UI에서 배포 티어를 설정할 수 없습니다.

환경 이름 바꾸기#

히스토리

• API를 사용한 환경 이름 바꾸기는 GitLab 15.9에서 더 이상 사용되지 않습니다.
• API를 사용한 환경 이름 바꾸기는 GitLab 16.0에서 제거되었습니다.

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

환경 이름 바꾸기와 동일한 결과를 얻으려면:

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

CI/CD 변수#

환경과 배포를 커스터마이즈하려면 미리 정의된 CI/CD 변수를 사용하고 커스텀 CI/CD 변수를 정의할 수 있습니다.

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

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

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

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

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

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

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

다음 환경 범위가 일치합니다:

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

환경 검색#

히스토리

• GitLab 15.5에서 도입되었습니다.
• 폴더 내에서 환경 검색은 GitLab 15.7에서 기능 플래그 enable_environments_search_within_folder와 함께 도입되었습니다. 기본적으로 활성화됩니다.
• GitLab 17.4에서 일반 제공됩니다. 기능 플래그 enable_environments_search_within_folder가 제거되었습니다.

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

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

유사한 환경 그룹화#

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

환경 중지#

환경을 중지하면 배포를 대상 서버에서 더 이상 액세스할 수 없습니다. 환경을 삭제하기 전에 중지해야 합니다.

on_stop 액션을 사용하여 환경을 중지하면 job이 아카이브되지 않은 경우 실행됩니다.

UI를 사용하여 환경 중지#

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

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

기본 중지 동작#

GitLab은 연관된 브랜치가 삭제되거나 머지될 때 자동으로 환경을 중지합니다. 이 동작은 명시적인 on_stop CI/CD job이 정의되지 않은 경우에도 유지됩니다.

그러나 이슈 428625는 명시적인 on_stop CI/CD job이 정의된 경우에만 프로덕션 및 스테이징 환경이 중지되도록 이 동작을 변경하도록 제안합니다.

환경 API에서 auto_stop_setting 매개변수로 환경의 중지 동작을 구성할 수 있습니다.

브랜치 삭제 시 환경 중지#

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

다음 예에서 deploy_review job은 stop_review job을 호출하여 환경을 정리하고 중지합니다.

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

deploy_review:
  stage: deploy
  script:
    - echo "Deploy a review app"
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: https://$CI_ENVIRONMENT_SLUG.example.com
    on_stop: stop_review

stop_review:
  stage: deploy
  script:
    - echo "Remove review app"
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: stop
  when: manual

머지 리퀘스트가 머지되거나 닫힐 때 환경 중지#

머지 리퀘스트 파이프라인 구성을 사용하면 stop 트리거가 자동으로 활성화됩니다.

다음 예에서 deploy_review job은 stop_review job을 호출하여 환경을 정리하고 중지합니다.

• 파이프라인이 성공해야 함 설정이 켜져 있을 때, stop_review job에 allow_failure: true 키워드를 구성하여 파이프라인 및 머지 리퀘스트를 차단하지 않도록 할 수 있습니다.

deploy_review:
  stage: deploy
  script:
    - echo "Deploy a review app"
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    on_stop: stop_review
  rules:
    - if: $CI_MERGE_REQUEST_ID

stop_review:
  stage: deploy
  script:
    - echo "Remove review app"
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: stop
  rules:
    - if: $CI_MERGE_REQUEST_ID
      when: manual

특정 시간 이후 환경 중지#

특정 시간이 지나면 환경이 자동으로 중지되도록 설정할 수 있습니다.

.gitlab-ci.yml 파일에서 environment:auto_stop_in 키워드를 지정합니다. 1 hour and 30 minutes 또는 1 day와 같이 자연어로 시간을 지정합니다. 시간이 경과하면 GitLab은 자동으로 환경을 중지하는 job을 시작합니다.

다음 예에서:

• 머지 리퀘스트의 각 커밋은 review_app job을 실행하여 최신 변경 사항을 환경에 배포하고 만료 기간을 재설정합니다.
• 환경이 일주일 이상 비활성 상태이면 GitLab은 자동으로 stop_review_app job을 실행하여 환경을 중지합니다.

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

environment:action 키워드를 사용하여 환경이 중지되도록 예약된 시간을 재설정할 수 있습니다. 자세한 내용은 준비 또는 확인 목적으로 환경 액세스를 참조하세요.

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

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

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

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

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

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

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

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

1. 상단 표시줄에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 운영 > 환경을 선택합니다.
3. 환경 이름을 선택합니다.
4. 오른쪽 상단 모서리에서 압정 아이콘 ([thumbtack])을 선택합니다.

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

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

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

오래된 환경 정리#

히스토리

• GitLab 15.8에서 stop_stale_environments라는 플래그와 함께 도입되었습니다. 기본적으로 비활성화됩니다.
• GitLab 15.10에서 일반 제공됩니다. 기능 플래그 stop_stale_environments가 제거되었습니다.

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

사전 조건:

• Maintainer 또는 Owner 권한이 있어야 합니다.

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

1. 상단 표시줄에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 운영 > 환경을 선택합니다.
3. 환경 정리를 선택합니다.
4. 오래된 환경으로 간주하는 데 사용할 날짜를 선택합니다.
5. 정리를 선택합니다.

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

환경이 중지될 때 파이프라인 job 실행#

히스토리

• 기능 플래그 environment_stop_actions_include_all_finished_deployments가 GitLab 16.9에서 도입되었습니다. 기본적으로 비활성화됩니다.
• 기능 플래그 environment_stop_actions_include_all_finished_deployments가 GitLab 17.0에서 제거되었습니다.

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

환경이 중지되면 최신 완료 파이프라인에서 완료된 배포의 중지 job이 실행됩니다. 배포 또는 파이프라인은 성공, 취소 또는 실패 상태이면 완료된 것입니다.

사전 조건:

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

다음 예에서:

• review_app job은 첫 번째 job이 완료된 후 stop_review_app job을 호출합니다.
• stop_review_app은 when 아래에 정의된 것에 따라 트리거됩니다. 이 경우 manual로 설정되므로 실행하려면 GitLab UI에서 수동 액션이 필요합니다.
• GIT_STRATEGY가 none으로 설정됩니다. stop_review_app job이 자동으로 트리거되는 경우 브랜치 삭제 후 러너가 코드를 체크아웃하려 하지 않습니다.

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 15.0에서 일반 제공됩니다. 기능 플래그 environment_multiple_stop_actions가 제거되었습니다.

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

환경이 중지되면 성공적인 배포 job에서만 일치하는 on_stop 액션이 특정 순서 없이 병렬로 실행됩니다.

다음 예에서 test 환경에 두 가지 배포 job이 있습니다:

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

환경이 중지되면 시스템은 on_stop 액션 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

on_stop 액션을 실행하지 않고 환경 중지#

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

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

환경 삭제#

환경과 모든 배포를 제거하려면 환경을 삭제합니다.

사전 조건:

• Developer, Maintainer 또는 Owner 권한이 있어야 합니다.
• 삭제하기 전에 환경을 중지해야 합니다.

환경을 삭제하려면:

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

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

히스토리

• GitLab 17.7에서 prepare 및 access 액션에 대해 auto_stop_in을 재설정하도록 업데이트되었습니다.

확인 또는 준비와 같은 다양한 목적으로 환경에 액세스하는 job을 정의할 수 있습니다. 이는 배포 생성을 효과적으로 건너뛰어 CD 워크플로를 더욱 정확하게 조정할 수 있게 합니다.

이를 위해 job의 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

이렇게 하면 환경 범위 변수에 액세스할 수 있으며, 무단 액세스로부터 빌드를 보호하는 데 사용할 수 있습니다. 또한 오래된 배포 job 방지 기능을 방지하는 데 효과적입니다.

환경이 특정 시간 이후 중지되도록 구성된 경우, access 또는 prepare 액션이 있는 job은 예약된 중지 시간을 재설정합니다. 시간을 재설정할 때 가장 최근의 성공적인 배포 job에서 environment:auto_stop_in이 사용됩니다. 예를 들어, 가장 최근의 배포에서 auto_stop_in: 1 week를 사용하고 나중에 action: access가 있는 job이 액세스하면, 환경은 액세스 job 완료 후 1주일 뒤에 중지되도록 재예약됩니다.

예약된 중지 시간을 변경하지 않고 환경에 액세스하려면 verify 액션을 사용합니다.

환경 인시던트 관리#

프로덕션 환경은 귀하의 통제 밖의 이유를 포함하여 예기치 않게 다운될 수 있습니다. 예를 들어 외부 의존성, 인프라 문제 또는 인적 오류로 인해 환경에 주요 문제가 발생할 수 있습니다. 다음과 같은 문제들:

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

즉각적인 주의가 필요한 중요한 문제가 있을 때 알림을 받으려면 인시던트 관리를 사용할 수 있습니다.

환경의 최신 알림 보기#

알림 통합을 설정하면 환경 페이지에 환경의 알림이 표시됩니다. 가장 높은 심각도의 알림이 표시되므로 즉각적인 주의가 필요한 환경을 식별할 수 있습니다.

알림을 트리거한 문제가 해결되면 알림이 제거되고 환경 페이지에 더 이상 표시되지 않습니다.

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

자동 롤백#

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

GitLab 자동 롤백은 중요 알림이 감지될 때 자동으로 롤백을 트리거하여 이 워크플로를 간소화합니다. GitLab이 롤백에 적합한 환경을 선택하려면 알림에 환경 이름이 포함된 gitlab_environment_name 키가 있어야 합니다. GitLab은 가장 최근의 성공적인 배포를 선택하여 재배포합니다.

GitLab 자동 롤백의 제한 사항:

• 알림이 감지될 때 배포가 실행 중이면 롤백을 건너뜁니다.
• 롤백은 3분에 한 번만 발생할 수 있습니다. 여러 알림이 동시에 감지되면 하나의 롤백만 수행됩니다.

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

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

환경 권한#

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

환경 보기#

• 공개 프로젝트에서는 비멤버를 포함하여 누구나 환경 목록을 볼 수 있습니다.
• 비공개 프로젝트에서는 Reporter, Developer, Maintainer 또는 Owner 권한이 있어야 환경 목록을 볼 수 있습니다.

환경 생성 및 업데이트#

• Developer, Maintainer 또는 Owner 권한이 있어야 새 환경을 생성하거나 기존 보호되지 않은 환경을 업데이트할 수 있습니다.
• 보호된 환경은 배포 허용 목록에 포함되어 있어야 합니다.

환경 중지 및 삭제#

• Developer, Maintainer 또는 Owner 권한이 있어야 보호되지 않은 환경을 중지하거나 삭제할 수 있습니다.
• 환경이 보호되어 있고 이에 액세스할 수 없는 경우 환경을 중지하거나 삭제할 수 없습니다.

보호된 환경에서 배포 job 실행#

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

• Reporter, Developer, Maintainer 또는 Owner 권한이 있어야 합니다.

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

• Reporter 권한이 있는 그룹의 일원이어야 합니다.

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

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

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

Web 터미널은 컨테이너 기반 배포로, 기본 도구(예: 편집기)가 없는 경우가 많으며 언제든지 중지하거나 다시 시작할 수 있습니다. 이 경우 모든 변경 사항이 손실됩니다. Web 터미널을 포괄적인 온라인 IDE가 아닌 디버깅 도구로 취급하세요.

Web 터미널:

• 프로젝트 Maintainer 및 Owner만 사용할 수 있습니다.
• 활성화되어 있어야 합니다.

UI에서 Web 터미널을 보려면 다음 중 하나를 수행합니다:

• 액션 메뉴에서 터미널을 선택합니다:

  

• 특정 환경 페이지의 오른쪽에서 터미널 ([terminal])을 선택합니다.

버튼을 선택하여 터미널 세션을 설정합니다. 다른 터미널과 같이 작동합니다. 배포로 생성된 컨테이너에 있으므로 다음 작업을 수행할 수 있습니다:

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

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

관련 항목#

• Kubernetes 대시보드
• 배포
• 보호된 환경
• 환경 대시보드
• 배포 안전

트러블슈팅#

action: stop이 있는 job이 실행되지 않는 경우#

일부 경우에는 on_stop job이 구성되어 있어도 환경이 중지되지 않습니다. 이는 action: stop이 있는 job이 stages: 또는 needs: 구성으로 인해 실행 가능한 상태가 아닐 때 발생합니다.

예:

• 환경이 실패한 job이 있는 스테이지에서 시작될 수 있습니다. 그러면 나중 스테이지의 job이 시작되지 않습니다. 환경의 action: stop이 있는 job도 나중 스테이지에 있는 경우 시작할 수 없어 환경이 삭제되지 않습니다.
• action: stop이 있는 job이 아직 완료되지 않은 job에 대한 의존성을 가질 수 있습니다.

action: stop이 필요할 때 항상 실행될 수 있도록 다음을 수행할 수 있습니다:

• 두 job을 동일한 스테이지에 배치합니다:

  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 job에 needs 항목을 추가하여 스테이지 순서 외로 job을 시작할 수 있도록 합니다:

  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
  

오류: job would create an environment with an invalid parameter#

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

This job could not be executed because it would create an environment with an invalid parameter.

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

deploy:
  script: echo
  environment: production/$ENVIRONMENT

파이프라인에 $ENVIRONMENT 변수가 존재하지 않으므로 GitLab은 이름이 production/인 환경을 생성하려 하는데, 이는 환경 이름 제약에서 유효하지 않습니다.

이를 해결하려면 다음 해결책 중 하나를 사용합니다:

• 배포 job에서 environment 키워드를 제거합니다. GitLab은 이미 유효하지 않은 키워드를 무시하고 있으므로 키워드를 제거한 후에도 배포 파이프라인은 그대로 유지됩니다.
• 파이프라인에 변수가 존재하는지 확인합니다. 지원되는 변수에 대한 제한 사항을 검토하세요.
• .gitlab-ci.yml에 environment:deployment_tier가 있는 경우, 값이 지원되는 티어 중 하나인지 확인합니다: production, staging, testing, development, 또는 other.

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

예를 들어, .gitlab-ci.yml에 다음이 있는 경우:

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

브랜치 이름이 bug-fix!인 새 머지 리퀘스트를 생성하면, review job은 review/bug-fix!로 환경을 생성하려 합니다. 그러나 !는 환경에 유효하지 않은 문자이므로 배포 job은 환경 없이 실행될 것이었기 때문에 실패합니다.

이를 해결하려면 다음 해결책 중 하나를 사용합니다:

• bug-fix와 같이 유효하지 않은 문자가 없이 기능 브랜치를 다시 생성합니다.

• 유효하지 않은 문자를 제거하는 CI_COMMIT_REF_SLUG로 CI_COMMIT_REF_NAME 미리 정의된 변수를 교체합니다:

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