InfoGrab DocsInfoGrab Docs

새 서버로 마이그레이션

요약

GitLab 백업 및 복원을 사용해 Linux 패키지 인스턴스를 새 서버로 마이그레이션합니다. GitLab Geo를 운영 중이라면 계획된 장애 조치를 위한 Geo 재해 복구를 대안으로 사용할 수 있습니다. 새 서버와 기존 서버가 조율 없이 데이터를 처리하는 상황을 피합니다.

GitLab 백업 및 복원을 사용해 Linux 패키지 인스턴스를 새 서버로 마이그레이션합니다. Linux 패키지 GitLab 인스턴스를 Docker로 마이그레이션하는 방법도 있습니다.

GitLab Geo를 운영 중이라면 계획된 장애 조치를 위한 Geo 재해 복구를 대안으로 사용할 수 있습니다. 마이그레이션에 Geo를 선택하기 전에 모든 사이트가 Geo 요구 사항을 충족하는지 확인해야 합니다.

Warning

새 서버와 기존 서버가 조율 없이 데이터를 처리하는 상황을 피합니다. 여러 서버가 동시에 연결되어 같은 데이터를 처리할 수 있습니다. 예를 들어 수신 이메일을 사용할 때 두 GitLab 인스턴스가 동시에 이메일을 처리하면 두 인스턴스 모두 일부 데이터를 놓칩니다. 이러한 문제는 다른 서비스에서도 발생할 수 있습니다. 예를 들어 비패키지 데이터베이스, 비패키지 Redis 인스턴스, 비패키지 Sidekiq 입니다.

사전 요구 사항:

  • 예정된 마이그레이션을 사용자에게 알리기 위해 미리 게시한 브로드캐스트 메시지 배너.
  • 완전하고 최신 상태인 백업. rm과 같은 파괴적 명령이 잘못 실행되는 경우에 대비해 전체 시스템 수준 백업을 생성하거나 마이그레이션에 관여하는 모든 서버의 스냅샷을 확보합니다.
  • 관리자 액세스 권한.

새 서버 준비#

새 서버를 준비하려면 다음 단계를 따릅니다.

  1. 중간자 공격 경고를 피하기 위해 기존 서버의 SSH 호스트 키를 복사합니다. 예시 단계는 기본 사이트의 SSH 호스트 키 수동 복제를 참고합니다.

  2. GitLab을 설치합니다.

  3. 기존 서버의 /etc/gitlab 파일을 새 서버로 복사해 구성하고, 필요에 따라 업데이트합니다. 자세한 내용은 Linux 패키지 설치의 백업 및 복원 안내를 참고합니다.

  4. 해당하는 경우 수신 이메일을 비활성화합니다.

  5. 백업 및 복원 이후 최초 기동 시 새 CI/CD job 이 시작되지 않도록 차단합니다. /etc/gitlab/gitlab.rb를 편집해 다음을 설정합니다.

    nginx['custom_gitlab_server_config'] = "location = /api/v4/jobs/request {\n    deny all;\n    return 503;\n  }\n"

  6. GitLab을 재구성합니다.

    sudo gitlab-ctl reconfigure

  7. 불필요하고 의도하지 않은 데이터 처리를 막기 위해 GitLab을 중지합니다.

    sudo gitlab-ctl stop

  8. Redis를 중지합니다.

    sudo gitlab-ctl stop redis

  9. 새 서버가 Redis 데이터베이스와 GitLab 백업 파일을 받을 수 있도록 구성합니다.

    sudo rm -f /var/opt/gitlab/redis/dump.rdb
sudo chown <your-linux-username> /var/opt/gitlab/redis /var/opt/gitlab/backups

기존 서버의 콘텐츠 준비 및 전송#

  1. 기존 서버의 최신 시스템 수준 백업 또는 스냅샷이 있는지 확인합니다.

  2. GitLab 에디션이 지원한다면 유지 관리 모드를 활성화합니다.

  3. 새 CI/CD job 이 시작되지 않도록 차단합니다.

    1. /etc/gitlab/gitlab.rb를 편집해 다음을 설정합니다.

      nginx['custom_gitlab_server_config'] = "location = /api/v4/jobs/request {\n    deny all;\n    return 503;\n  }\n"

    2. GitLab을 재구성합니다.

      sudo gitlab-ctl reconfigure

  4. 주기적 백그라운드 job을 비활성화합니다.

    1. 오른쪽 상단에서 Admin을 선택합니다.
    2. 왼쪽 사이드바에서 Monitoring > Background jobs를 선택해 Sidekiq 대시보드를 표시합니다.
    3. Sidekiq 대시보드 상단 메뉴에서 Cron을 선택합니다.
    4. Sidekiq 대시보드 오른쪽 위에서 Disable All을 선택합니다.

  5. 실행 중인 CI/CD job 이 끝나기를 기다리거나, 완료되지 않은 job 이 유실될 수 있음을 감수합니다. 실행 중인 모든 job을 확인하려면 다음 단계를 따릅니다.

    1. 왼쪽 사이드바에서 CI/CD > Jobs를 선택합니다.
    2. 필터 바에서 Status > Running을 선택합니다.

  6. Sidekiq job 이 끝나기를 기다립니다.

    1. 왼쪽 사이드바에서 Monitoring > Background jobs를 선택합니다.
    2. Sidekiq 대시보드 상단 메뉴에서 Queues를 선택합니다.
    3. Sidekiq 대시보드 오른쪽 위에서 Live Poll을 선택합니다. Busy와 Enqueued가 0으로 떨어질 때까지 기다립니다. 이 큐에는 사용자가 제출한 작업이 들어 있으며, 이 job 이 끝나기 전에 종료하면 해당 작업이 유실될 수 있습니다. 마이그레이션 이후 검증을 위해 Sidekiq 대시보드에 표시된 숫자를 기록해 둡니다.

  7. Redis 데이터베이스를 디스크에 플러시하고, 마이그레이션에 필요한 서비스를 제외한 GitLab을 중지합니다.

    sudo /opt/gitlab/embedded/bin/redis-cli -s /var/opt/gitlab/redis/redis.socket save && \
sudo gitlab-ctl stop && \
sudo gitlab-ctl start postgresql && \
sudo gitlab-ctl start gitaly

  8. GitLab 백업을 생성합니다.

    sudo gitlab-backup create

  9. 백업이 완료되면 /etc/gitlab/gitlab.rb 맨 아래에 다음을 추가해 아래 GitLab 서비스를 비활성화하고 의도하지 않은 재시작을 방지합니다.

    alertmanager['enable'] = false
gitaly['enable'] = false
gitlab_exporter['enable'] = false
gitlab_pages['enable'] = false
gitlab_workhorse['enable'] = false
logrotate['enable'] = false
gitlab_rails['incoming_email_enabled'] = false
nginx['enable'] = false
node_exporter['enable'] = false
postgres_exporter['enable'] = false
postgresql['enable'] = false
prometheus['enable'] = false
puma['enable'] = false
redis['enable'] = false
redis_exporter['enable'] = false
registry['enable'] = false
sidekiq['enable'] = false

  10. GitLab을 재구성합니다.

    sudo gitlab-ctl reconfigure

  11. 모든 것이 중지되었는지 확인하고, 실행 중인 서비스가 없는지 검증합니다.

    sudo gitlab-ctl status

  12. Redis 데이터베이스와 GitLab 백업을 새 서버로 전송합니다.

    sudo scp /var/opt/gitlab/redis/dump.rdb <your-linux-username>@new-server:/var/opt/gitlab/redis
sudo scp /var/opt/gitlab/backups/your-backup.tar <your-linux-username>@new-server:/var/opt/gitlab/backups

Git 및 오브젝트 데이터 용량이 큰 인스턴스#

GitLab 인스턴스의 로컬 볼륨에 데이터가 많다면, 예를 들어 1 TB를 넘는다면 백업에 오랜 시간이 걸릴 수 있습니다. 이 경우 데이터를 새 인스턴스의 해당 볼륨으로 직접 전송하는 편이 수월합니다.

수동으로 마이그레이션해야 할 수 있는 주요 볼륨은 다음과 같습니다.

  • 모든 Git 데이터가 들어 있는 /var/opt/gitlab/git-data 디렉터리. Git 데이터 손상 가능성을 없애기 위해 리포지터리 이전 문서 섹션을 반드시 읽습니다.
  • 아티팩트 같은 오브젝트 데이터가 들어 있는 /var/opt/gitlab/gitlab-rails/shared 디렉터리.
  • 사용자 프로필 사진 같은 업로드 데이터가 들어 있는 /var/opt/gitlab/gitlab-rails/uploads 디렉터리.
  • Linux 패키지에 포함된 번들 PostgreSQL을 사용한다면 /var/opt/gitlab/postgresql/data 아래의 PostgreSQL 데이터 디렉터리도 함께 마이그레이션해야 합니다.

모든 GitLab 서비스를 중지한 뒤에는 rsync 같은 도구나 볼륨 스냅샷 마운트를 사용해 데이터를 새 환경으로 옮길 수 있습니다.

새 서버에서 데이터 복원#

  1. 적절한 파일 시스템 권한을 복원합니다.

    sudo chown gitlab-redis /var/opt/gitlab/redis
sudo chown gitlab-redis:gitlab-redis /var/opt/gitlab/redis/dump.rdb
sudo chown git:root /var/opt/gitlab/backups
sudo chown git:git /var/opt/gitlab/backups/your-backup.tar

  2. Redis를 시작합니다.

    sudo gitlab-ctl start redis

    Redis가 dump.rdb를 자동으로 읽어 복원합니다.

  3. GitLab 백업을 복원합니다.

  4. Redis 데이터베이스가 올바르게 복원되었는지 확인합니다.

    1. 오른쪽 상단에서 Admin을 선택합니다.
    2. 왼쪽 사이드바에서 Monitoring > Background jobs를 선택합니다.
    3. Sidekiq 대시보드에서 기존 서버에 표시되었던 숫자와 일치하는지 확인합니다.
    4. Sidekiq 대시보드에서 Cron을 선택한 다음 Enable All을 선택해 주기적 백그라운드 job을 다시 활성화합니다.

  5. GitLab 인스턴스의 읽기 전용 작업이 정상 동작하는지 테스트합니다. 예를 들어 프로젝트 리포지터리 파일, 머지 리퀘스트, 이슈를 둘러봅니다.

  6. 앞서 활성화했다면 유지 관리 모드를 비활성화합니다.

  7. GitLab 인스턴스가 정상 동작하는지 테스트합니다.

  8. 해당하는 경우 수신 이메일을 다시 활성화하고 정상 동작하는지 테스트합니다.

  9. 새 서버를 가리키도록 DNS 또는 로드 밸런서를 업데이트합니다.

  10. 앞서 추가한 사용자 정의 NGINX 구성을 제거해 새 CI/CD job 이 시작될 수 있도록 차단을 해제합니다.

    # The following line must be removed
nginx['custom_gitlab_server_config'] = "location = /api/v4/jobs/request {\n    deny all;\n    return 503;\n  }\n"

  11. GitLab을 재구성합니다.

    sudo gitlab-ctl reconfigure

  12. 예정된 유지 관리 브로드캐스트 메시지 배너를 제거합니다.

새 서버로 마이그레이션

GitLab v19.4
Tier: Free, Premium, Ultimate
Offering: GitLab Self-Managed
원문 보기

요약

GitLab 백업 및 복원을 사용해 Linux 패키지 인스턴스를 새 서버로 마이그레이션합니다. GitLab Geo를 운영 중이라면 계획된 장애 조치를 위한 Geo 재해 복구를 대안으로 사용할 수 있습니다. 새 서버와 기존 서버가 조율 없이 데이터를 처리하는 상황을 피합니다.

GitLab 백업 및 복원을 사용해 Linux 패키지 인스턴스를 새 서버로 마이그레이션합니다. Linux 패키지 GitLab 인스턴스를 Docker로 마이그레이션하는 방법도 있습니다.

GitLab Geo를 운영 중이라면 계획된 장애 조치를 위한 Geo 재해 복구를 대안으로 사용할 수 있습니다. 마이그레이션에 Geo를 선택하기 전에 모든 사이트가 Geo 요구 사항을 충족하는지 확인해야 합니다.

Warning

새 서버와 기존 서버가 조율 없이 데이터를 처리하는 상황을 피합니다. 여러 서버가 동시에 연결되어 같은 데이터를 처리할 수 있습니다. 예를 들어 수신 이메일을 사용할 때 두 GitLab 인스턴스가 동시에 이메일을 처리하면 두 인스턴스 모두 일부 데이터를 놓칩니다. 이러한 문제는 다른 서비스에서도 발생할 수 있습니다. 예를 들어 비패키지 데이터베이스, 비패키지 Redis 인스턴스, 비패키지 Sidekiq 입니다.

사전 요구 사항:

  • 예정된 마이그레이션을 사용자에게 알리기 위해 미리 게시한 브로드캐스트 메시지 배너.
  • 완전하고 최신 상태인 백업. rm과 같은 파괴적 명령이 잘못 실행되는 경우에 대비해 전체 시스템 수준 백업을 생성하거나 마이그레이션에 관여하는 모든 서버의 스냅샷을 확보합니다.
  • 관리자 액세스 권한.

새 서버 준비#

새 서버를 준비하려면 다음 단계를 따릅니다.

  1. 중간자 공격 경고를 피하기 위해 기존 서버의 SSH 호스트 키를 복사합니다. 예시 단계는 기본 사이트의 SSH 호스트 키 수동 복제를 참고합니다.

  2. GitLab을 설치합니다.

  3. 기존 서버의 /etc/gitlab 파일을 새 서버로 복사해 구성하고, 필요에 따라 업데이트합니다. 자세한 내용은 Linux 패키지 설치의 백업 및 복원 안내를 참고합니다.

  4. 해당하는 경우 수신 이메일을 비활성화합니다.

  5. 백업 및 복원 이후 최초 기동 시 새 CI/CD job 이 시작되지 않도록 차단합니다. /etc/gitlab/gitlab.rb를 편집해 다음을 설정합니다.

    nginx['custom_gitlab_server_config'] = "location = /api/v4/jobs/request {\n    deny all;\n    return 503;\n  }\n"

  6. GitLab을 재구성합니다.

    sudo gitlab-ctl reconfigure

  7. 불필요하고 의도하지 않은 데이터 처리를 막기 위해 GitLab을 중지합니다.

    sudo gitlab-ctl stop

  8. Redis를 중지합니다.

    sudo gitlab-ctl stop redis

  9. 새 서버가 Redis 데이터베이스와 GitLab 백업 파일을 받을 수 있도록 구성합니다.

    sudo rm -f /var/opt/gitlab/redis/dump.rdb
sudo chown <your-linux-username> /var/opt/gitlab/redis /var/opt/gitlab/backups

기존 서버의 콘텐츠 준비 및 전송#

  1. 기존 서버의 최신 시스템 수준 백업 또는 스냅샷이 있는지 확인합니다.

  2. GitLab 에디션이 지원한다면 유지 관리 모드를 활성화합니다.

  3. 새 CI/CD job 이 시작되지 않도록 차단합니다.

    1. /etc/gitlab/gitlab.rb를 편집해 다음을 설정합니다.

      nginx['custom_gitlab_server_config'] = "location = /api/v4/jobs/request {\n    deny all;\n    return 503;\n  }\n"

    2. GitLab을 재구성합니다.

      sudo gitlab-ctl reconfigure

  4. 주기적 백그라운드 job을 비활성화합니다.

    1. 오른쪽 상단에서 Admin을 선택합니다.
    2. 왼쪽 사이드바에서 Monitoring > Background jobs를 선택해 Sidekiq 대시보드를 표시합니다.
    3. Sidekiq 대시보드 상단 메뉴에서 Cron을 선택합니다.
    4. Sidekiq 대시보드 오른쪽 위에서 Disable All을 선택합니다.

  5. 실행 중인 CI/CD job 이 끝나기를 기다리거나, 완료되지 않은 job 이 유실될 수 있음을 감수합니다. 실행 중인 모든 job을 확인하려면 다음 단계를 따릅니다.

    1. 왼쪽 사이드바에서 CI/CD > Jobs를 선택합니다.
    2. 필터 바에서 Status > Running을 선택합니다.

  6. Sidekiq job 이 끝나기를 기다립니다.

    1. 왼쪽 사이드바에서 Monitoring > Background jobs를 선택합니다.
    2. Sidekiq 대시보드 상단 메뉴에서 Queues를 선택합니다.
    3. Sidekiq 대시보드 오른쪽 위에서 Live Poll을 선택합니다. Busy와 Enqueued가 0으로 떨어질 때까지 기다립니다. 이 큐에는 사용자가 제출한 작업이 들어 있으며, 이 job 이 끝나기 전에 종료하면 해당 작업이 유실될 수 있습니다. 마이그레이션 이후 검증을 위해 Sidekiq 대시보드에 표시된 숫자를 기록해 둡니다.

  7. Redis 데이터베이스를 디스크에 플러시하고, 마이그레이션에 필요한 서비스를 제외한 GitLab을 중지합니다.

    sudo /opt/gitlab/embedded/bin/redis-cli -s /var/opt/gitlab/redis/redis.socket save && \
sudo gitlab-ctl stop && \
sudo gitlab-ctl start postgresql && \
sudo gitlab-ctl start gitaly

  8. GitLab 백업을 생성합니다.

    sudo gitlab-backup create

  9. 백업이 완료되면 /etc/gitlab/gitlab.rb 맨 아래에 다음을 추가해 아래 GitLab 서비스를 비활성화하고 의도하지 않은 재시작을 방지합니다.

    alertmanager['enable'] = false
gitaly['enable'] = false
gitlab_exporter['enable'] = false
gitlab_pages['enable'] = false
gitlab_workhorse['enable'] = false
logrotate['enable'] = false
gitlab_rails['incoming_email_enabled'] = false
nginx['enable'] = false
node_exporter['enable'] = false
postgres_exporter['enable'] = false
postgresql['enable'] = false
prometheus['enable'] = false
puma['enable'] = false
redis['enable'] = false
redis_exporter['enable'] = false
registry['enable'] = false
sidekiq['enable'] = false

  10. GitLab을 재구성합니다.

    sudo gitlab-ctl reconfigure

  11. 모든 것이 중지되었는지 확인하고, 실행 중인 서비스가 없는지 검증합니다.

    sudo gitlab-ctl status

  12. Redis 데이터베이스와 GitLab 백업을 새 서버로 전송합니다.

    sudo scp /var/opt/gitlab/redis/dump.rdb <your-linux-username>@new-server:/var/opt/gitlab/redis
sudo scp /var/opt/gitlab/backups/your-backup.tar <your-linux-username>@new-server:/var/opt/gitlab/backups

Git 및 오브젝트 데이터 용량이 큰 인스턴스#

GitLab 인스턴스의 로컬 볼륨에 데이터가 많다면, 예를 들어 1 TB를 넘는다면 백업에 오랜 시간이 걸릴 수 있습니다. 이 경우 데이터를 새 인스턴스의 해당 볼륨으로 직접 전송하는 편이 수월합니다.

수동으로 마이그레이션해야 할 수 있는 주요 볼륨은 다음과 같습니다.

  • 모든 Git 데이터가 들어 있는 /var/opt/gitlab/git-data 디렉터리. Git 데이터 손상 가능성을 없애기 위해 리포지터리 이전 문서 섹션을 반드시 읽습니다.
  • 아티팩트 같은 오브젝트 데이터가 들어 있는 /var/opt/gitlab/gitlab-rails/shared 디렉터리.
  • 사용자 프로필 사진 같은 업로드 데이터가 들어 있는 /var/opt/gitlab/gitlab-rails/uploads 디렉터리.
  • Linux 패키지에 포함된 번들 PostgreSQL을 사용한다면 /var/opt/gitlab/postgresql/data 아래의 PostgreSQL 데이터 디렉터리도 함께 마이그레이션해야 합니다.

모든 GitLab 서비스를 중지한 뒤에는 rsync 같은 도구나 볼륨 스냅샷 마운트를 사용해 데이터를 새 환경으로 옮길 수 있습니다.

새 서버에서 데이터 복원#

  1. 적절한 파일 시스템 권한을 복원합니다.

    sudo chown gitlab-redis /var/opt/gitlab/redis
sudo chown gitlab-redis:gitlab-redis /var/opt/gitlab/redis/dump.rdb
sudo chown git:root /var/opt/gitlab/backups
sudo chown git:git /var/opt/gitlab/backups/your-backup.tar

  2. Redis를 시작합니다.

    sudo gitlab-ctl start redis

    Redis가 dump.rdb를 자동으로 읽어 복원합니다.

  3. GitLab 백업을 복원합니다.

  4. Redis 데이터베이스가 올바르게 복원되었는지 확인합니다.

    1. 오른쪽 상단에서 Admin을 선택합니다.
    2. 왼쪽 사이드바에서 Monitoring > Background jobs를 선택합니다.
    3. Sidekiq 대시보드에서 기존 서버에 표시되었던 숫자와 일치하는지 확인합니다.
    4. Sidekiq 대시보드에서 Cron을 선택한 다음 Enable All을 선택해 주기적 백그라운드 job을 다시 활성화합니다.

  5. GitLab 인스턴스의 읽기 전용 작업이 정상 동작하는지 테스트합니다. 예를 들어 프로젝트 리포지터리 파일, 머지 리퀘스트, 이슈를 둘러봅니다.

  6. 앞서 활성화했다면 유지 관리 모드를 비활성화합니다.

  7. GitLab 인스턴스가 정상 동작하는지 테스트합니다.

  8. 해당하는 경우 수신 이메일을 다시 활성화하고 정상 동작하는지 테스트합니다.

  9. 새 서버를 가리키도록 DNS 또는 로드 밸런서를 업데이트합니다.

  10. 앞서 추가한 사용자 정의 NGINX 구성을 제거해 새 CI/CD job 이 시작될 수 있도록 차단을 해제합니다.

    # The following line must be removed
nginx['custom_gitlab_server_config'] = "location = /api/v4/jobs/request {\n    deny all;\n    return 503;\n  }\n"

  11. GitLab을 재구성합니다.

    sudo gitlab-ctl reconfigure

  12. 예정된 유지 관리 브로드캐스트 메시지 배너를 제거합니다.