• 환경 및 배포 보기
• 환경 검색
• CI/CD 변수
• 환경 상태
• 환경 유형
  • 정적 환경 생성
    • UI에서
    • .gitlab-ci.yml 파일에서
  • 동적 환경 생성
    • 동적 환경 URL 설정
  • 환경 이름 변경
• 환경의 배포 티어
• 수동 배포 구성
• 배포별로 새로 포함된 병합 요청 추적하기
• 환경 작업하기
  • 환경 롤백
    • 배포를 다시 시도하거나 롤백하기
  • 환경 URL
    • 소스 파일에서 공개 페이지로 이동
  • 환경 중지
    • 브랜치가 삭제될 때 환경 중지
    • 병합 요청이 병합되거나 닫힐 때 환경 정지
    • 환경이 중지될 때 파이프라인 작업 실행
    • 특정 시간 경과 후 환경 중지
      • 환경의 예약된 중지 날짜 및 시간 보기
      • 환경의 예약된 중지 날짜 및 시간 재정의
    • on_stop 액션을 실행하지 않고 환경 중지
    • UI를 사용하여 환경 중지
    • 환경에 대한 여러 중지 액션
  • 환경 삭제
  • 오래된 환경 정리
  • 준비 또는 확인 목적으로 환경 접근
  • 유사한 환경 그룹화
  • 환경 이슈 관리
    • 최신 알림을 확인합니다.
    • 자동 되감기
  • 웹 터미널 (사용 중단됨)
  • 로컬로 배포 내용 확인
  • 이전 배포 보관
  • CI/CD 변수의 환경 범위 제한
• 환경 권한
  • 환경 보기
  • 환경 만들기 및 업데이트하기
  • 환경 중지 및 삭제
  • 보호된 환경에서 배포 작업 실행
• 관련 주제
• 문제 해결
  • action: stop과 함께하는 작업이 실행되지 않음
  • 오류: 작업이 잘못된 매개변수로 환경을 생성하려고 합니다
    • 리뷰 앱에서 이 오류가 발생하는 경우
  • 배포 refs를 찾을 수 없음

환경 및 배포

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

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

GitLab:

• 각 환경에 대한 배포 이력을 제공합니다.
• 배포를 추적하여 항상 서버에 배포된 내용을 파악할 수 있습니다.

프로젝트와 관련된 Kubernetes와 같은 배포 서비스가 있는 경우 이를 사용하여 배포를 지원할 수 있습니다.

환경 및 배포 보기

전제 조건:

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

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

• 프로젝트 개요 페이지에서 환경이 하나 이상 사용 가능한 경우(멈추지 않은 경우)에 나타납니다.

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

  

• 환경 목록에서 환경 이름(예: staging)을 선택하여 환경에 대한 배포 목록을 보려면 다음을 수행합니다.

  

배포는 배포 작업이 생성된 후에만 이 목록에 표시됩니다.

환경 검색

• 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과 일치합니다.
     • 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에서 정적 환경을 생성하려면:

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

.gitlab-ci.yml 파일에서

전제 조건:

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

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

1. deploy 단계에 작업을 정의합니다.
2. 작업에서 name 및 url 환경을 정의합니다. 파이프라인 실행시 해당 이름의 환경이 없는 경우 생성됩니다.

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

예를 들어, production이름의 환경을 생성하고 URL이 https://staging.example.com인 경우:

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

동적 환경 생성

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

전제 조건:

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

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

1. deploy 단계에 작업을 정의합니다.
2. 작업에서 다음 환경 속성을 정의합니다:
   • name: $CI_COMMIT_REF_SLUG과 같은 관련 CI/CD 변수 사용. 환경 이름에 정적 접두사를 추가하여 동일한 접두사가 있는 모든 환경을 그룹화할 수 있습니다.
   • url: 선택 사항. 호스트 이름 앞에 $CI_ENVIRONMENT_SLUG와 같은 관련 CI/CD 변수를 추가합니다.

참고: 일부 문자는 환경 이름에 사용할 수 없습니다. 환경 키워드에 대한 자세한 정보는 .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의 정적 부분을 지정할 수도 있습니다. 예를 들어 https://$DYNAMIC_ENVIRONMENT_URL 같은 형태로 지정할 수 있습니다. 이때 DYNAMIC_ENVIRONMENT_URL의 값이 example.com이라면 최종 결과는 https://example.com이 됩니다.

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

자세한 내용은 작업 완료 후 동적 URL 설정을 참조하세요.

아래 예시에서 리뷰 앱은 각 병합 요청마다 새로운 환경을 생성합니다: - review 작업은 모든 push에 의해 트리거되며 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)                                 # 환경 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                                              # 환경 설정 변수에 스크립트에서 생성된 변수를 설정
    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 또는 GIT_STRATEGY: empty를 사용할 수 없는 경우, 병합 요청 파이프라인을 구성하십시오. 이를 통해 러너가 기능 브랜치를 삭제한 후에도 저장소를 가져올 수 있도록합니다. 더 자세한 정보는 러너를 위한 Ref 스펙을 확인하세요.

참고: Windows 러너의 경우, PowerShell의 Add-Content 명령어를 사용하여 .env 파일에 쓰도록 설정해야 합니다.

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

환경 이름 변경

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

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

환경을 이름을 변경하는 것과 동일한 결과를 얻으려면:

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

환경의 배포 티어

가끔씩 production과 같은 산업 표준 환경 이름 대신 customer-portal과 같은 코드 이름을 사용하는 것이 좋을 수 있습니다. customer-portal과 같은 이름을 사용하는 데 기술적인 이유가 없는 한, 이러한 이름은 더 이상 해당 환경이 프로덕션용으로 사용되고 있음을 나타내지 않습니다. 이는 배포 빈도와 같은 메트릭을 어떻게 계산할지에 영향을 미칠 수 있습니다.

특정 환경이 특정 용도에 사용된다는 것을 나타내려면 티어를 사용할 수 있습니다:

기본적으로 GitLab은 환경 이름을 기반으로 티어를 가정합니다. UI를 사용하여 환경 티어를 설정할 수 없습니다. 대신, 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 작업은 수동으로 트리거해야 합니다.

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

배포별로 새로 포함된 병합 요청 추적하기

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

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

• 환경 이름이 /를 사용하지 않도록 합니다(지속적 또는 최상위 환경).
• 환경 티어가 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 명령을 여러 작업으로 분리하는 경우, 배포 또는 롤백 작업을 수동으로 실행해야 합니다.

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

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

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

1. 왼쪽 사이드바에서 검색 또는 이동을 선택하여 프로젝트를 찾습니다.
2. 작동 > 환경을 선택합니다.
3. 환경을 선택합니다.
4. 배포 이름 오른쪽에:
   • 배포를 다시 시도하려면 환경으로 다시 배포를 선택합니다.
   • 배포를 롤백하려면 이전에 성공한 배포 옆에 환경 롤백을 선택합니다.

참고: 프로젝트에서 오래된 배포 작업 방지를 설정한 경우, 롤백 버튼이 숨겨지거나 비활성화될 수 있습니다. 이 경우 롤백 배포를 위한 작업 다시 시도를 참조하십시오.

환경 URL

• 변경됨으로 GitLab 15.2에서 soft_validation_on_external_url이라는 플래그와 함께 GitLab 15.3에서 일반적으로 사용 가능합니다. 기본적으로 비활성화됩니다.
• GitLab 15.3에서 특성 플래그 soft_validation_on_external_url이 제거되었습니다.

환경 URL은 GitLab의 여러 위치에 표시됩니다:

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

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

• 병합 요청이 기본 브랜치(일반적으로 main)에 병합되는 경우.
• 해당 브랜치가 환경(예: staging 또는 production)에 배포되는 경우.

예를 들어:

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

GitLab Route Maps를 사용하면 리뷰 앱에서 소스 파일에서 공개 페이지로 직접 이동할 수 있습니다.

환경 중지

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

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

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

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

• 두 작업은 동일한 rules 또는 only/except 구성을 가져야 합니다. 그렇지 않으면 stop_review 작업이 deploy_review 작업이 포함된 모든 파이프라인에 포함되지 않을 수 있으며, action: stop을 자동으로 트리거하여 환경을 중지할 수 없습니다.
• 환경을 시작한 작업보다 나중에 단계에 있으면 action: stop`이 실행되지 않을 수 있습니다.
• 병합 요청 파이프라인을 사용할 수없는 경우 stop_review 작업에서 GIT_STRATEGY를 none 또는 empty로 설정합니다. 그런 다음 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

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

병합 요청 파이프라인 구성을 사용하는 경우 stop 트리거가 자동으로 활성화됩니다.

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

:::yaml 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 :::

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

• 기능 플래그 environment_stop_actions_include_all_finished_deployments은 GitLab 16.9에서 소개되었습니다. 기본 상태는 비활성화입니다.
• 기능 플래그 environment_stop_actions_include_all_finished_deployments은 GitLab 17.0에서 제거되었습니다.

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

최신 완료된 파이프라인에서 완료된 배포의 중지 작업이 실행되고 환경이 중지됩니다. 배포 또는 파이프라인이 성공적, 취소됨, 또는 실패한 상태라면 완료된 것으로 간주됩니다.

전제 조건:

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

다음 예에서:

• review_app 작업은 첫 번째 작업이 완료된 후 stop_review_app 작업을 호출합니다.
• stop_review_app은 when에 따라 트리거됩니다. 여기서는 수동으로 설정되어 있으므로 GitLab UI에서 수동 동작이 필요합니다.
• GIT_STRATEGY가 none으로 설정되어 있습니다. stop_review_app 작업이 자동으로 트리거될 때 코드를 체크하려 하지 않습니다. :::yaml 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-ci.yml 파일에서 environment:auto_stop_in 키워드를 지정하세요. 1 hour and 30 minutes 또는 1 day와 같이 자연어로 시간을 지정하세요. 지정된 시간이 경과하면 GitLab은 환경을 중지시키기 위해 작업을 자동으로 트리거합니다.

다음 예에서:

• 병합 요청에 대한 각 커밋은 최신 변경을 환경에 배포하고 만료 기간을 재설정하는 review_app 작업을 트리거합니다.
• 환경이 일주일 이상 비활성화된 경우 GitLab은 환경을 중지하기 위해 자동으로 stop_review_app 작업을 트리거합니다. :::yaml 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 :::

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

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

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

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

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

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

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

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

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

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

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

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

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

on_stop 액션을 실행하지 않고 환경을 중지하려는 경우가 있을 수 있습니다. 예를 들어 compute quota를 사용하지 않고 많은 환경을 삭제하려는 경우입니다.

on_stop 액션을 실행하지 않고 환경을 중지하려면 force=true 파라미터로 Stop an environment API를 실행하세요.

UI를 사용하여 환경 중지

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

GitLab UI에서 환경을 중지하려면 다음 단계를 수행하세요:

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

환경에 대한 여러 중지 액션

• GitLab 15.0에서 일반적으로 사용 가능해짐. Feature flag environment_multiple_stop_actions 제거됨.

한 환경에서 여러 병렬 중지 액션을 구성하려면 동일한 environment에 대해 .gitlab-ci.yml 파일에 정의된 여러 배포 작업에서 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 "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

환경 삭제

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

전제 조건:

• 적어도 개발자 역할이 있어야 합니다.
• 삭제 전에 stop을 해야합니다.

환경을 삭제하려면 다음을 수행하세요:

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

오래된 환경 정리

• GitLab 15.8에서 stop_stale_environments이라는 플래그와 함께 도입됐습니다. 기본적으로 비활성화됩니다.
• GitLab 15.10에서 일반적으로 사용 가능해짐. Feature flag stop_stale_environments 제거됨.

프로젝트에서 오래된 환경을 중지하려는 경우 오래된 환경을 정리하세요.

전제 조건:

• 적어도 관리자 역할이 있어야 합니다.

오래된 환경을 정리하려면 다음을 수행하세요:

1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 운영 > 환경(Operate > Environments)을 선택합니다.
3. 환경 정리(Clean up environments)를 선택합니다.
4. 오래된 환경을 고려하는 데 사용할 날짜를 선택합니다.
5. 정리(Clean up)를 선택합니다.

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

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

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

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

유사한 환경 그룹화

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

환경 이슈 관리

생산 환경은 외부 요소, 인프라 또는 인간 에러와 같은 이유로 예기치 않게 다운될 수 있습니다. 예를 들어 다음과 같은 중대한 문제가 발생할 수 있습니다.

• 의존 클라우드 서비스 다운.
• 3rd party 라이브러리가 업데이트되고 응용 프로그램과 호환되지 않음.
• 취약한 엔드포인트에 DDoS 공격 수행.
• 운영자가 인프라를 잘못 구성.
• 생산 응용 프로그램 코드에 버그가 도입.

즉시 주의가 필요한 중요한 문제가 발생했을 때 이슈 관리를 사용하여 경고를 받을 수 있습니다.

최신 알림을 확인합니다.

경보 통합을 설정하면 환경의 알림이 환경 페이지에 표시됩니다. 가장 심각한 경보가 표시되어 즉각적인 조치가 필요한 환경을 확인할 수 있습니다.

알림을 일으킨 문제가 해결되면 해당 알림이 제거되어 더 이상 환경 페이지에 표시되지 않습니다.

알림이 되감기를 요청하는 경우, 환경 페이지에서 배포 탭을 선택하고 되감을 원하는 배포를 선택할 수 있습니다.

자동 되감기

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

GitLab Auto Rollback은 자동으로 중대한 경보가 감지되면 되감기를 트리거하여 이 워크플로우를 단순화합니다. 되감기를 위해 GitLab이 적절한 환경을 선택하려면 경보에 환경 이름을 나타내는 gitlab_environment_name 키가 포함되어 있어야 합니다. GitLab은 최신 성공적인 배포를 선택하고 다시 배포합니다.

GitLab Auto Rollback의 제한 사항:

• 경보가 감지되었을 때 배포가 진행 중이면 되감기가 건너뛰어집니다.
• 되감기는 3분당 한 번만 발생할 수 있습니다. 한 번에 여러 경보가 감지되어도 한 번의 되감기만 수행됩니다.

GitLab Auto Rollback는 기본적으로 꺼져 있습니다. 켜려면 다음을 수행하세요:

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

웹 터미널 (사용 중단됨)

경고: 이 기능은 GitLab 14.5에서 사용 중단되었습니다.

환경에 배포 서비스의 도움을 받아 배포하는 경우 GitLab은 환경으로 터미널 세션을 열 수 있습니다. 이후 웹 브라우저를 종료하지 않고 문제를 디버깅할 수 있습니다.

웹 터미널은 컨테이너 기반 배포로, 종종 기본 도구(편집기와 같은)가 부족하며 언제든지 중지되거나 다시 시작될 수 있습니다. 이런 경우 변경 사항을 모두 잃게 됩니다. 이 웹 터미널은 포괄적인 온라인 IDE가 아닌 디버깅 도구로 다루어야 합니다.

웹 터미널은 다음과 같습니다:

• 프로젝트 유지보수자 및 소유자에게만 제공됩니다.
• 활성화되어 있어야 합니다.

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

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

터미널 세션을 설정하려면 해당 버튼을 선택합니다:

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

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

동일한 환경으로 여러 터미널을 열 수 있습니다. 각각 고유한 셸 세션을 사용하며 screen 또는 tmux와 같은 멀티플렉서도 사용할 수 있습니다.

로컬로 배포 내용 확인

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

Git 구성에서 [remote "<your-remote>"] 블록에 추가적인 fetch 줄을 추가하세요:

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

이전 배포 보관

프로젝트에 새로운 배포가 발생하면 GitLab은 배포에 대한 특별한 Git-ref를 만듭니다. 이러한 Git-refs는 원격 GitLab 저장소에서 채워지기 때문에 프로젝트의 배포 수가 증가할수록 git-fetch 및 git-pull과 같은 Git 작업이 느려질 수 있습니다.

Git 동작의 효율성을 유지하기 위해 GitLab은 최근 배포 ref(최대 50,000)만 유지하고 이전 배포 ref는 삭제합니다. 보관된 배포는 감사 목적을 위해 UI 또는 API를 통해 여전히 사용할 수 있습니다. 또한 보관된 커밋은 ref가 없어도 GitLab 저장소에서 가져올 수 있으며 예를 들어 git checkout <deployment-sha>를 사용하여 확인할 수 있습니다.

참고: GitLab은 모든 커밋을 keep-around refs로 유지하여 배포된 커밋이 삭제되지 않도록 합니다.

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

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

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

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

또한 * 와일드카드를 사용하여 특정 환경 그룹을 선택할 수 있으며, 예를 들어 review/*와 같이 모든 리뷰 앱을 선택할 수 있습니다.

다음과 같은 네 가지 환경이 있는 경우:

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

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

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

환경 권한

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

환경 보기

• 공개 프로젝트의 경우 모든 사람이 환경 목록을 볼 수 있으며 멤버가 아닌 사람도 포함됩니다.
• 비공개 프로젝트의 경우 환경 목록을 보려면 적어도 기고자(Reporter) 역할이 있어야 합니다.

환경 만들기 및 업데이트하기

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

환경 중지 및 삭제

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

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

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

• 적어도 기고자(Reporter) 역할이 있어야 합니다.

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

• 기고자(Reporter) 역할이 있는 그룹의 일부여야 합니다.

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

관련 주제

• Kubernetes 대시보드
• 배포를 위한 하류 파이프라인
• GitLab CI/CD를 사용하여 여러 환경으로 배포(블로그 글)
• 리뷰 앱
• 보호된 환경
• 환경 대시보드
• 배포 안전성
• 외부 배포 도구의 배포 추적
• Kubernetes 배포 구성(사용 중단)

문제 해결

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

일부 경우에는 on_stop 작업이 구성된 상태임에도 불구하고 환경이 중지되지 않을 수 있습니다. 이는 stages: 또는 needs: 구성으로 인해 action: stop이 실행 가능한 상태에 있지 않기 때문입니다.

예를 들어:

• 환경이 실패한 작업을 포함하는 스테이지에서 시작할 수도 있습니다. 그러면 이후 스테이지의 작업이 시작되지 않습니다. 환경에 대한 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은 무효한 키워드를 이미 무시하고 있기 때문에 키워드를 제거해도 배포 파이프라인이 유지됩니다. - 배포 작업에서 환경 키워드를 제거하세요. - 파이프라인에서 지원되는 변수에 대한 제한 사항을 확인하세요. 지원되는 변수 제한.

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

예를 들어, .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
  

배포 refs를 찾을 수 없음

GitLab은 깃 리포지토리의 성능을 유지하기 위해 이전의 배포 refs를 삭제합니다.

보관된 Git-refs를 복원해야 하는 경우, 자체 호스팅된 GitLab 인스턴스의 관리자에게 다음 명령을 Rails 콘솔에서 실행하도록 요청하세요:

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

GitLab은 퍼포먼스를 위해 이러한 기능의 지원을 중단할 수 있습니다. 이러한 기능의 동작을 논의하기 위해 GitLab 이슈 트래커에 이슈를 열 수 있습니다.