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

환경을 사용하면 다음을 할 수 있습니다:

• 배포 프로세스를 일관되고 반복 가능하게 유지

• 어느 곳에 어떤 코드가 배포되었는지 추적

• 문제가 발생할 때 이전 버전으로 롤백

• 권한이 없는 변경으로부터 민감한 환경 보호

• 환경별 배포 변수를 제어하여 보안 경계 유지

• 환경 상태를 모니터링하고 문제가 발생하면 알림 수신

환경 및 배포 보기#

필수 조건:

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

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

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

[

](/19.2/ci/environments/img/environments_project_home_v15_9.png)

왼쪽 사이드바에서 Operate > Environments를 선택합니다. 환경이 표시됩니다.

[

](/19.2/ci/environments/img/environments_list_v14_8.png)

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

[

](/19.2/ci/environments/img/deployments_list_v13_10.png)

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

[

](/19.2/ci/environments/img/view_manual_jobs_v17_10.png)

환경 URL#

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

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

[

](/19.2/ci/environments/img/environments_mr_review_app_v11_10.png)

Environments 보기에서 버튼으로:

[

](/19.2/ci/environments/img/environments_open_live_environment_v14_8.png)

Deployments 보기에서 버튼으로:

[

](/19.2/ci/environments/img/deployments_view_v11_10.png)

머지 리퀘스트에서 이 정보를 볼 수 있는 경우:

• 머지 리퀘스트가 최종적으로 기본 브랜치(일반적으로 main)에 머지되는 경우.

• 해당 브랜치가 환경(예: staging 또는 production)에도 배포되는 경우.

예를 들어:

[

](/19.2/ci/environments/img/environments_link_url_mr_v10_1.png)

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

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

환경 유형#

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

정적 환경:

• 보통 연속된 배포에서 재사용됩니다.

• 정적 이름을 가집니다. 예: staging 또는 production.

• 수동으로 생성되거나 CI/CD 파이프라인의 일부로 생성됩니다.

동적 환경:

• 보통 CI/CD 파이프라인에서 생성되며 단일 배포에서만 사용된 다음 중지되거나 삭제됩니다.

• 동적 이름을 가지며, 보통 CI/CD 변수 값을 기반으로 합니다.

• 리뷰 앱의 기능입니다.

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

• available: 환경이 존재합니다. 배포가 있을 수 있습니다.

• stopping: on stop job이 시작되었습니다. on stop job이 정의되지 않은 경우에는 이 상태가 적용되지 않습니다.

• stopped: on stop job이 실행되었거나 사용자가 수동으로 job을 중지했습니다.

정적 환경 생성#

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

UI에서#

필수 조건:

• Developer, Maintainer 또는 Owner 권한이 필요합니다.

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

• 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.

• 왼쪽 사이드바에서 Operate > Environments를 선택합니다.

• Create an environment을 선택합니다.

• 필드를 작성합니다.

• Save를 선택합니다.

.gitlab-ci.yml 파일에서#

필수 조건:

• Developer, Maintainer 또는 Owner 권한이 필요합니다.

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

• deploy Stage에서 job을 정의합니다.

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

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

  예를 들어, 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 파일에서:

• deploy Stage에서 job을 정의합니다.

• job에서 다음 환경 속성을 정의합니다:

name: $CI_COMMIT_REF_SLUG와 같은 관련 CI/CD 변수를 사용합니다. 선택적으로 환경 이름에 정적 접두사를 추가하면 UI에서 같은 접두사를 가진 모든 환경을 그룹화합니다.

• url: 선택 사항입니다. $CI_ENVIRONMENT_SLUG와 같은 관련 CI/CD 변수로 호스트명에 접두사를 붙입니다.

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

  다음 예제에서 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을 참조하기 어렵습니다.

생성된 URL을 dotenv 변수로 캡처하고 environment:url에 전달하도록 배포 job을 구성할 수 있습니다. 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 Spec을 참조하세요.

  Windows 러너의 경우 PowerShell Add-Content 명령을 사용하여 .env 파일에 써야 합니다.

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에서는 배포 티어를 설정할 수 없습니다.

환경 이름 바꾸기#

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

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

• 기존 환경 중지.

• 기존 환경 삭제.

• 원하는 이름으로 새 환경 생성.

CI/CD 변수#

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

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

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

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

특정 매칭을 사용하여 특정 환경을 선택할 수 있습니다. 예를 들어 변수의 환경 범위를 production으로 설정하면 production 환경을 가진 job만 변수에 접근할 수 있습니다.

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

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

• production

• staging

• review/feature-1

• review/feature-2

이러한 환경 범위는 다음과 같이 매칭됩니다:

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

환경 검색#

히스토리

• GitLab 17.4에서 일반적으로 사용 가능해짐. 기능 플래그 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과 매칭됩니다.

유사한 환경 그룹화#

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

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

[

](/19.2/ci/environments/img/environments_dynamic_groups_v13_10.png)

다음 예제는 환경 이름을 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이 아카이브되지 않은 경우 job이 실행됩니다.

UI를 사용하여 환경 중지#

Environments 보기에서 `on_stop` 액션을 트리거하고 수동으로 환경을 중지하려면

중지 job과 배포 job이 동일한 resource_group에 있어야 합니다.

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

• 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.

• 왼쪽 사이드바에서 Operate > Environments를 선택합니다.

• 중지할 환경 옆에서 Stop을 선택합니다.

• 확인 대화 상자에서 Stop environment를 선택합니다.

기본 중지 동작#

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

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

Environments 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보다 나중 Stage에 있는 경우.

• 머지 리퀘스트 파이프라인을 사용할 수 없는 경우, 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을 호출합니다.

• Pipelines must succeed 설정이 켜져 있으면, 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

이 기능을 머지 트레인과 함께 사용할 경우 `stop` job은 [중복 파이프라인을 피하는 경우](/19.2/ci/jobs/job_rules/#avoid-duplicate-pipelines)에만 실행됩니다.

특정 시간 기간 후 환경 중지#

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

리소스 제한으로 인해 환경을 중지하는 백그라운드 워커는 매 시간마다 한 번만 실행됩니다. 이는 환경이 지정된 정확한 시간 기간 후에 중지되지 않을 수 있으며, 대신 백그라운드 워커가 만료된 환경을 감지할 때 중지됨을 의미합니다.

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

다음 예제에서:

• 머지 리퀘스트의 각 커밋은 review_app job을 실행하여 최신 변경 사항을 환경에 배포하고 만료 기간을 재설정합니다.

• 환경이 1주일 이상 비활성 상태이면 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 키워드를 사용하여 환경이 중지되도록 예약된 시간을 재설정할 수 있습니다. 자세한 내용은 준비 또는 검증 목적으로 환경 접근을 참조하세요.

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

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

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

• 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.

• 왼쪽 사이드바에서 Operate > Environments를 선택합니다.

• 환경 이름을 선택합니다.

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

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

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

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

• 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.

• 왼쪽 사이드바에서 Operate > Environments를 선택합니다.

• 환경 이름을 선택합니다.

• 오른쪽 상단 모서리에서 압정 아이콘( thumbtack )을 선택합니다.

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

• 프로젝트의 .gitlab-ci.yml을 엽니다.

• 해당 배포 job의 auto_stop_in 설정을 auto_stop_in: never로 업데이트합니다.

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

오래된 환경 정리#

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

필수 조건:

• Maintainer 또는 Owner 권한이 필요합니다.

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

• 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.

• 왼쪽 사이드바에서 Operate > Environments를 선택합니다.

• Clean up environments를 선택합니다.

• 어떤 환경을 오래된 것으로 간주할지 결정하는 데 사용할 날짜를 선택합니다.

• Clean up을 선택합니다.

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

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

히스토리

• GitLab 16.9에서 기능 플래그 environment_stop_actions_include_all_finished_deployments가 도입됨. 기본적으로 비활성화됨.

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

환경의 배포 job에 on_stop 액션과 함께 stop job을 정의할 수 있습니다.

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

필수 조건:

• 배포 job과 stop job 모두 동일한 rules 또는 only/except 구성을 가져야 합니다.

• stop 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

환경에 대한 여러 stop 액션#

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

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

환경의 모든 `on_stop` 액션은 동일한 파이프라인에 속해야 합니다. [다운스트림 파이프라인](/19.2/ci/pipelines/downstream_pipelines/)에서 여러 `on_stop` 액션을 사용하려면 상위 파이프라인에서 환경 액션을 구성해야 합니다. 자세한 내용은 [배포를 위한 다운스트림 파이프라인](/19.2/ci/pipelines/downstream_pipelines/#advanced-example)을 참조하세요.

다음 예제에서 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 권한이 필요합니다.

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

환경을 삭제하려면:

• 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.

• 왼쪽 사이드바에서 Operate > Environments를 선택합니다.

• Stopped 탭을 선택합니다.

• 삭제할 환경 옆에서 Delete environment를 선택합니다.

• 확인 대화 상자에서 Delete environment를 선택합니다.

준비 또는 검증 목적으로 환경 접근#

히스토리

• 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 공격을 수행합니다.

• 운영자가 인프라를 잘못 구성합니다.

• 프로덕션 애플리케이션 코드에 버그가 도입됩니다.

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

환경에 대한 최신 알림 보기#

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

[

](/19.2/ci/environments/img/alert_for_environment_v13_4.png)

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

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

자동 롤백#

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

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

GitLab 자동 롤백의 제한 사항:

• 알림이 감지될 때 배포가 실행 중이면 롤백이 건너뜁니다.

• 롤백은 3분 내에 한 번만 발생할 수 있습니다. 여러 알림이 한 번에 감지되면 하나의 롤백만 수행됩니다.

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

• 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.

• 왼쪽 사이드바에서 Settings > CI/CD를 선택합니다.

• Automatic deployment rollbacks를 확장합니다.

• Enable automatic rollbacks 체크박스를 선택합니다.

• Save changes를 선택합니다.

환경 권한#

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

환경 보기#

• 공개 프로젝트에서는 비멤버를 포함한 누구나 환경 목록을 볼 수 있습니다.

• 비공개 프로젝트에서는 환경 목록을 보려면 Reporter, Developer, Maintainer 또는 Owner 권한이 필요합니다.

환경 생성 및 업데이트#

• 새 환경을 생성하거나 기존의 보호되지 않은 환경을 업데이트하려면 Developer, Maintainer 또는 Owner 권한이 필요합니다.

• 보호된 환경의 경우 Allowed to deploy 목록에 있어야 합니다.

환경 중지 및 삭제#

• 보호되지 않은 환경을 중지하거나 삭제하려면 Developer, Maintainer 또는 Owner 권한이 필요합니다.

• 환경이 보호되어 있고 접근 권한이 없는 경우 환경을 중지하거나 삭제할 수 없습니다.

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

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

• Reporter, Developer, Maintainer 또는 Owner 권한이 필요합니다.

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

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

보호된 환경에 대한 배포 전용 접근을 참조하세요.

Web 터미널 (지원 종료)#

이 기능은 GitLab 14.5에서 [지원 종료](https://gitlab.com/groups/gitlab-org/configure/-/epics/8)되었습니다.

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

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

Web 터미널:

• 프로젝트 Maintainer와 Owner만 사용할 수 있습니다.

• 활성화되어야 합니다.

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

Actions 메뉴에서 Terminal을 선택합니다:

[

](/19.2/ci/environments/img/environments_terminal_button_on_index_v14_3.png)

특정 환경 페이지에서 오른쪽에 있는 Terminal ( terminal )을 선택합니다.

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

• 셸 명령을 실행하고 실시간으로 응답을 받습니다.

• 로그를 확인합니다.

• 구성이나 코드 조정을 시도합니다.

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

관련 항목#

• 쿠버네티스 대시보드

• 배포

• 보호된 환경

• Environments 대시보드

• 배포 안전성

문제 해결#

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

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

예를 들어:

• 환경이 실패한 job이 있는 Stage에서 시작될 수 있습니다. 그러면 나중 Stage의 job이 시작되지 않습니다. 환경의 action: stop이 있는 job도 나중 Stage에 있으면 시작될 수 없어 환경이 삭제되지 않습니다.

• action: stop이 있는 job이 아직 완료되지 않은 job에 대한 의존성을 가질 수 있습니다.

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

두 job을 동일한 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 job에 needs 항목을 추가하여 Stage 순서와 관계없이 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이 잘못된 파라미터로 환경을 생성합니다#

프로젝트가 동적 환경을 생성하도록 구성된 경우, 동적으로 생성된 파라미터를 환경 생성에 사용할 수 없어 배포 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