배포

배포 (Deployments)

코드의 특정 버전을 환경에 배포하면 그게 곧 배포(디플로이)가 돼요. 보통 환경마다 활성 배포는 하나뿐입니다. GitLab은 각 환경으로의 배포 전체 이력을 제공하고, 배포를 추적해서 서버에 지금 무엇이 배포되어 있는지 항상 알 수 있게 해줍니다.

출처: 문서

본문

코드 버전을 환경에 배포하면 배포가 만들어집니다. 보통 환경당 활성 배포는 하나뿐이에요.

GitLab은:

각 환경으로의 배포 전체 이력을 제공합니다.
배포를 추적해서 서버에 무엇이 배포되어 있는지 항상 알 수 있게 해줘요.

프로젝트에 Kubernetes 같은 배포 서비스가 연결되어 있다면 배포를 도와주는 데 사용할 수 있습니다.

배포가 만들어진 후에는 사용자에게 롤아웃할 수 있어요.

수동 배포 설정하기

누군가 수동으로 배포를 시작해야 하는 잡을 만들 수 있습니다. 예를 들어:

deploy_prod:
  stage: deploy
  script:
    - echo "Deploy to production server"
  environment:
    name: production
    url: https://example.com
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      when: manual

when: manual 동작은:

GitLab UI에서 잡에 Run(플레이) 버튼을 노출하며, Can be manually deployed to <environment> 라는 텍스트를 보여줍니다.
deploy_prod 잡이 수동으로 트리거되어야 함을 의미합니다.

Run(플레이)은 파이프라인, 환경, 배포, 잡 뷰에서 찾을 수 있어요.

배포당 새로 포함된 머지 리퀘스트 추적

GitLab은 배포당 새로 포함된 머지 리퀘스트를 추적할 수 있어요. 배포가 성공하면 시스템이 최신 배포와 이전 배포 사이의 커밋 차이를 계산합니다. Deployment API로 추적 정보를 가져오거나, 머지 리퀘스트 페이지의 머지 후 파이프라인에서 볼 수 있습니다.

추적을 활성화하려면 환경을 다음과 같이 구성하세요.

환경 이름이 /를 사용하는 폴더가 아니거나(장기 유지되거나 최상위 환경).
환경 티어가 production 또는 staging.

.gitlab-ci.yml에서 environment 키워드를 사용한 몇 가지 예시 구성입니다.

# 추적 가능 (Trackable)
environment: production
environment: production/aws
environment: development

# 추적 불가 (Non Trackable)
environment: review/$CI_COMMIT_REF_SLUG
environment: testing/aws

설정 변경은 새 배포에만 적용됩니다. 기존 배포 기록에는 머지 리퀘스트가 연결되거나 연결 해제되지 않아요.

배포를 로컬에서 확인하기

각 배포에 대해 Git 저장소에 참조가 저장되므로, 현재 환경의 상태를 알아내는 것은 git fetch 한 번이면 됩니다.

Git 구성의 [remote "<your-remote>"] 블록에 fetch 줄을 하나 추가하세요.

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

오래된 배포 아카이브

프로젝트에서 새 배포가 일어나면 GitLab이 배포에 대한 특별한 Git-ref를 만듭니다. 이 Git-ref들은 원격 GitLab 저장소에서 채워지므로, 프로젝트의 배포 수가 늘어나면 git-fetch나 git-pull 같은 일부 Git 작업이 느려질 수 있어요.

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

GitLab은 모든 커밋을 keep-around refs로 보존해서, 배포 ref에 참조되지 않더라도 배포된 커밋이 가비지 컬렉션되지 않게 합니다.

배포 롤백

특정 커밋에서 배포를 롤백하면 새 배포가 만들어집니다. 이 배포는 고유한 잡 ID를 가지며, 롤백하려는 커밋을 가리킵니다.

롤백이 성공하려면 배포 프로세스가 잡의 script에 정의되어 있어야 합니다.

배포 잡만 실행됩니다. 이전 잡이 배포 시 다시 생성해야 할 아티팩트를 만들고 있다면, 파이프라인 페이지에서 필요한 잡을 수동으로 실행해야 해요. 예를 들어 Terraform을 쓰면서 plan과 apply 명령이 여러 잡으로 나뉘어 있다면, 배포하거나 롤백하려면 잡을 수동으로 실행해야 합니다.

배포 재시도 또는 롤백

배포에 문제가 있으면 재시도하거나 롤백할 수 있어요.

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

상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
왼쪽 사이드바에서 Operate > Environments를 선택하세요.
환경을 선택합니다.
배포 이름 오른쪽에서: 배포를 재시도하려면 Re-deploy to environment를, 이전에 성공한 배포로 롤백하려면 Rollback environment를 선택합니다.

프로젝트에서 오래된 배포 잡 방지를 활성화했다면 롤백 버튼이 숨겨지거나 비활성화될 수 있어요. 이 경우 롤백 배포의 잡 재시도를 참고하세요.

문제 해결

배포로 작업할 때 다음 문제가 발생할 수 있어요.

배포 ref를 찾을 수 없을 때

GitLab은 오래된 배포 ref를 삭제해서 Git 저장소의 성능을 유지합니다.

GitLab Self-Managed에서 아카이브된 Git-ref를 복원해야 한다면 관리자에게 Rails 콘솔에서 다음 명령을 실행하도록 요청하세요.

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

성능 우려로 GitLab이 이 지원을 향후 없앨 수도 있습니다. 이 기능의 동작에 대해 논의하려면 GitLab Issue Tracker에서 이슈를 열 수 있어요.

더 알아보기

배포는 환경 개념과 긴밀하게 연결돼 있어요. 배포마다 Git-ref가 저장되고 최대 50,000개까지만 유지된다는 점, 그리고 롤백이 실행되면 새 배포가 만들어진다는 점이 핵심입니다. 다음으로는 Environments 문서와 배포 안전, 그리고 다운스트림 파이프라인 문서를 함께 읽어 배포 흐름 전체를 파악해 보세요.

배포