GitLab 16 변경 사항

Tier: Free, Premium, Ultimate Offering: Self-managed

이 페이지에는 GitLab 16의 마이너 및 패치 버전에 대한 업그레이드 정보가 포함되어 있습니다. 다음을 위해 이 지침을 검토해야 합니다:

  • 설치 유형.
  • 현재 버전과 대상 버전 사이의 모든 버전.

GitLab 헬름 차트를 업그레이드하는 자세한 정보는 릴리스 노트 7.0를 참조하세요.

15.11에서 업그레이드할 때 주의할 사항

  • GitLab 16부터는 PostgreSQL 12가 지원되지 않습니다. GitLab 16.0 이상으로 업그레이드하기 전에 PostgreSQL을 적어도 버전 13.6으로 업그레이드하세요.
  • GitLab 인스턴스가 먼저 15.11.0, 15.11.1 또는 15.11.2로 업그레이드되면 데이터베이스 스키마가 올바르지 않습니다. 16.x로 업그레이드하기 전에 일시적 해결책을 수행하세요.
  • 16.0부터 GitLab Self-managed 설치는 기본적으로 한 개가 아닌 두 개의 데이터베이스 연결을 갖습니다. 이 변경으로 PostgreSQL 연결 수가 두 배로 늘어납니다. 이 변경으로 Self-managed 버전의 GitLab이 GitLab.com과 유사하게 작동하도록 만들어졌으며 Self-managed 버전의 GitLab에서 CI 기능에 대한 별도의 데이터베이스 사용을 가능하게 하는 단계입니다. 16.0으로 업그레이드하기 전에 PostgreSQL의 최대 연결 수를 증가시킬 필요 여부를 결정하세요.

  • 대부분의 설치는 16.0, 16.1 및 16.2를 건너뛸 수 있으며, 업그레이드 경로 상에서 첫 번째 필수 중지점은 16.3입니다. 모든 경우에 해당되며 해당 중간 버전에 대한 주의 사항을 검토해야 합니다.

    일부 GitLab 설치는 사용되는 기능과 환경의 크기에 따라 해당 중간 버전에서 중지해야 합니다:

    인스턴스가 영향을 받고 이러한 중지점을 건너뛴 경우:

    • 업그레이드에 몇 시간이 걸릴 수 있습니다.
    • 모든 데이터베이스 변경이 완료될 때까지 인스턴스에서 500 오류가 발생하며 이후에 Puma와 Sidekiq를 재시작해야 합니다.
    • 리눅스 패키지 설치에서 시간 초과가 발생하고 데이터베이스 변경을 완료하기 위한 수동 해결책이 필요합니다.

  • GitLab 16.0은 프로젝트 크기에 대한 제한을 강제하는 변경 사항을 도입했습니다. Self-managed에서 이러한 제한을 사용하는 경우, 한 그룹 내의 영향을 받지 않는 Git 저장소로 푸시할 때 제한에 도달한 프로젝트는 오류 메시지를 발생시킵니다. 오류는 종종 0바이트의 제한(limit of 0 B)을 초과한다는 내용입니다.

    푸시가 성공하지만 오류는 그렇지 않다는 뜻이며 자동화에 문제를 일으킬 수 있습니다. 문제에 대해 더 읽어보세요(https://gitlab.com/gitlab-org/gitlab/-/issues/416646). 문제는 GitLab 16.5 이후에 수정되었습니다.

  • 일반적으로 PgBouncer가 있는 환경에서는 백업들이 GITLAB_BACKUP_로 접두사가 있는 변수를 설정하여 PgBouncer를 우회해야 합니다. 그러나 이슈로 gitlab-backup은 오버라이드에 정의된 직접 연결 대신에 PgBouncer를 통해 일반 데이터베이스 연결을 사용하고 데이터베이스 백업이 실패합니다. 해결책은 pg_dump를 직접 사용하는 것입니다.

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정된 버전
    15.11 모든 없음
    16.0 모든 없음
    16.1 모든 없음
    16.2 모든 없음
    16.3 모든 없음
    16.4 모든 없음
    16.5 모든 없음
    16.6 모든 없음
    16.7 16.7.0 - 16.7.6 16.7.7
    16.8 16.8.0 - 16.8.3 16.8.4

리눅스 패키지 설치

  • GitLab 16로 업그레이드하기 전에 Gitaly 및 Praefect 구성 구조를 변경해야 합니다. 데이터 손실을 피하기 위해 먼저 Praefect를 다시 구성하고 새 구성의 일환으로 메타데이터 확인을 비활성화하세요. 자세한 내용은 다음을 참조하세요:

  • Gitaly를 /var/opt/gitlab/git-data/repositories 외의 위치에 저장하기 위해 다시 구성하는 경우, 패키지형 GitLab 16.0 이상에서는 자동으로 디렉토리 구조를 작성하지 않습니다. 자세한 내용 및 해결책에 대해 이슈를 읽어보세요.

16.11.0

  • JSON 웹 토큰(ID 토큰)에 groups_direct 필드가 추가되었습니다.
    • GitLab CI/CD ID 토큰을 사용하여 제3자 서비스에 인증하는 경우, 이 변경으로 인해 HTTP 헤더 크기가 증가할 수 있습니다. 헤더가 너무 커지면 프록시 서버가 요청을 거부할 수 있습니다.
    • 가능하다면 수신 시스템의 헤더 제한을 늘리세요.
    • 자세한 내용은 issue 467253에서 확인할 수 있습니다.
  • GitLab 16.11로 업그레이드한 후 일부 환경과 데이터베이스가 큰 사용자가 웹 UI에서 소스 코드 페이지를로드하는 동안 시간 초과가 발생합니다.
    • 이러한 시간 초과는 파이프라인 데이터에 대한 느린 PostgreSQL 쿼리로 인한 것으로, 이는 내부 60초 제한을 초과합니다.
    • 여전히 Git 리포지토리를 복제하고, 리포지토리 데이터에 대한 다른 요청도 작동합니다.
    • 자세한 내용은 issue 472420을 확인하고 영향을 받는지 확인하고 PostgreSQL에서 실행할 housekeeping 등의 단계를 확인하세요.

Linux 패키지 설치

GitLab 16.11에서 다음 경우를 제외하고 PostgreSQL은 자동으로 14.x로 업그레이드됩니다.

  • Patroni를 사용하여 고가용성으로 데이터베이스를 실행 중인 경우.
  • 데이터베이스 노드가 GitLab Geo 구성의 일부인 경우.
  • PostgreSQL을 자동으로 업그레이드에서 opt-out한 경우.
  • /etc/gitlab/gitlab.rb에서 postgresql['version'] = 13을 명시적으로 설정한 경우.

고가용성 및 Geo 설치는 PostgreSQL 14로의 수동 업그레이드를 지원합니다. 자세한 내용은 HA/Geo 클러스터에 배포된 패키지 PostgreSQL을 참조하세요.

Geo 설치

  • GitLab 16.5에서 도입된 버그로 인해 Geo 이중화 사이트에서 GitLab Pages 배포 파일이 버려지고 있습니다. 페이지 배포가 로컬에 저장된 경우 이는 남은 저장 공간이 0이 되어 장애 조치로 데이터 손실로 이어질 수 있습니다. 문제의 자세한 내용 및 해결 방법은 이슈 #457159을 참조하세요.

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정된 버전
    16.5 모든 없음
    16.6 모든 없음
    16.7 모든 없음
    16.8 모든 없음
    16.9 모든 없음
    16.10 16.10.0 - 16.10.6 16.10.7
    16.11 16.11.0 - 16.11.3 16.11.4

  • GitLab 16.11에서 17.2를 통해 누락된 PostgreSQL 인덱스로 인해 고 CPU 사용, 느린 작업 아티팩트 확인 진행, 느린 또는 타임 아웃된 Geo 메트릭 상태 업데이트가 발생할 수 있습니다. 이 인덱스는 GitLab 17.3에 추가되었습니다. 인덱스를 수동으로 추가하려면 Geo Troubleshooting - High CPU usage on primary during job artifact verification를 참조하세요.

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정된 버전
    16.11 모든 없음
    17.0 모든 없음
    17.1 모든 없음
    17.2 모든 없음

16.10.0

GitLab 16.10 이상으로 업그레이드 중 다음 오류가 발생할 수 있습니다: 

PG::UndefinedColumn: ERROR:  column namespace_settings.delayed_project_removal does not exist

이 오류는 컬럼을 제거하는 마이그레이션이 이후에 이제 삭제된 컬럼을 참조하는 마이그레이션이 실행될 때 발생할 수 있습니다. 이 버그에 대한 수정이 16.11 릴리스에서 계획되어 있습니다.

이 문제를 해결하려면:

  1. 일시적으로 컬럼을 재생성하세요. gitlab-psql을 사용하거나 수동으로 데이터베이스에 연결하여 다음과 같이 실행하세요: 

    ALTER TABLE namespace_settings ADD COLUMN delayed_project_removal BOOLEAN DEFAULT NULL;

  2. 보류 중인 마이그레이션을 적용하세요: 

    gitlab-ctl reconfigure

  3. 최종 확인: 

    gitlab-ctl upgrade-check

  4. 컬럼을 제거하세요. gitlab-psql을 사용하거나 수동으로 데이터베이스에 연결하여 다음과 같이 실행하세요: 

    ALTER TABLE namespace_settings DROP COLUMN delayed_project_removal;

Linux 패키지 설치

GitLab 16.10의 Linux 패키지 설치에는 Patroni의 새 주 버전으로의 업그레이드가 포함됩니다. 버전 2.1.0에서 버전 3.0.1로의 업그레이드입니다.

고가용성 (HA)를 사용하고 있는 참조 아키텍처 중 하나를 사용 중이라면, Patroni를 사용하는 Linux 패키지 설치용 PostgreSQL 복제 및 장애 조치를 사용 중입니다.

이 경우, 멀티 노드 인스턴스를 업그레이드하는 방법에 대해 다운타임있는 멀티 노드 업그레이드를 읽으세요.

버전 2.1.0 및 버전 3.0.1 사이에서 도입된 변경 사항에 대한 자세한 내용은 Patroni 릴리스 노트를 참조하세요.

Geo 설치

  • GitLab 16.5에서 발생한 버그로 인해 17.0에서 수정되었으며, GitLab Pages 배포 파일이 보조 Geo 사이트에서 고아 처리됩니다. 페이지 배치가 로컬에 저장된 경우 장애 조치(failover) 시에 저장 공간이 없어져 이후 데이터 손실을 유발할 수 있습니다. 문제의 세부 정보 및 해결 방법은 이슈 #457159에 설명되어 있습니다.

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정된 버전
    16.5 모든 없음
    16.6 모든 없음
    16.7 모든 없음
    16.8 모든 없음
    16.9 모든 없음
    16.10 16.10.0 - 16.10.6 16.10.7
    16.11 16.11.0 - 16.11.3 16.11.4

16.9.0

GitLab 16.9.0으로 업그레이드 중에 다음 오류가 발생할 수 있습니다: 

PG::UndefinedTable: ERROR:  relation "p_ci_pipeline_variables" does not exist

모든 마이그레이션이 완료되었는지 확인하고 모든 Rails 및 Sidekiq 노드를 다시 시작하세요. 이 버그에 대한 수정은 16.9.1에서 계획되어 있습니다.

Geo 설치

  • 컨테이너 복제 버그로 인해 잘못 구성된 보조 시스템이 실패한 컨테이너 복제를 성공으로 표시할 수 있습니다. 후속 검증에서 체크섬 불일치로 인해 컨테이너가 실패로 표시됩니다. 해결 방법은 보조 구성을 수정하는 것입니다. 영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정된 버전
    모든 모든 16.10.2

  • GitLab 16.5에서 발생한 버그로 인해 개인 스니펫이 보조 Geo 사이트로 복제되지 않습니다. 이로 인해 Geo 장애 조치(failover) 시 개인 스니펫 데이터 유실이 발생할 수 있습니다. 문제의 세부 정보 및 해결 방법은 이슈 #439933에 설명되어 있습니다.

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정된 버전
    16.5 모든 없음
    16.6 모든 없음
    16.7 모든 없음
    16.8 16.8.0 - 16.8.3 16.8.4
    16.9 16.9.0 - 16.9.1 16.9.2

  • 일부 컨테이너 레지스트리 이미지의 체크섬 불일치로 인해 일부 이미지의 검증이 실패할 수 있습니다. 이슈 442667에 자세한 내용이 설명되어 있습니다. 데이터가 보조 사이트로 정확하게 복제되고 있지만 성공적으로 검증되고 있지는 않습니다. 현재 알려진 해결 방법은 없습니다.

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정된 버전
    16.8 16.8.0 - 16.8.3 16.8.4
    16.9 16.9.0 - 16.9.1 16.9.2

  • GitLab 16.5에서 발생한 버그로 인해 17.0에서 수정되었으며, GitLab Pages 배포 파일이 보조 Geo 사이트에서 고아 처리됩니다. 페이지 배치가 로컬에 저장된 경우 장애 조치(failover) 시에 저장 공간이 없어져 이후 데이터 손실을 유발할 수 있습니다. 문제의 세부 정보 및 해결 방법은 이슈 #457159에 설명되어 있습니다.

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정된 버전
    16.5 모든 없음
    16.6 모든 없음
    16.7 모든 없음
    16.8 모든 없음
    16.9 모든 없음
    16.10 16.10.0 - 16.10.6 16.10.7
    16.11 16.11.0 - 16.11.3 16.11.4

Linux 패키지 설치

  • Sidekiq min_concurrency 및 max_concurrency 옵션은 GitLab 16.9.0에서 사용 중지되었으며 GitLab 17.0.0에서 제거될 예정입니다. GitLab 16.9.0 이상에서는 GitLab 17.0.0에서의 호환성 문제를 피하려면 새로운 concurrency 옵션을 설정하고 min_concurrency 및 max_concurrency 옵션을 제거하세요.

16.8.0

  • GitLab 16.8.0 및 16.8.1에서 Sidekiq gem이 업그레이드되었으며 최신 버전은 Redis 6.2 이상을 필요로 합니다. Redis 6.0을 사용 중인 경우, 16.8.2로 직접 업그레이드하세요 (Redis 6.0과의 호환성을 복원합니다).

  • 참고: Redis 6.0은 더 이상 지원되지 않습니다 - Redis 6.2 이상으로 업그레이드해야 합니다.

  • 보통 PgBouncer가 있는 환경에서는 백업이 GITLAB_BACKUP_로 접두사가 붙은 변수를 설정하여 PgBouncer를 우회해야 합니다. 그러나 이슈로 인해 gitlab-backup은 오버라이드에서 정의된 직접 연결 대신 PgBouncer를 통해 일반 데이터베이스 연결을 사용하고 데이터베이스 백업에 실패합니다. 해결 방법은 pg_dump를 직접 사용하는 것입니다.

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정된 버전
    15.11 모든 없음
    16.0 모든 없음
    16.1 모든 없음
    16.2 모든 없음
    16.3 모든 없음
    16.4 모든 없음
    16.5 모든 없음
    16.6 모든 없음
    16.7 16.7.0 - 16.7.6 16.7.7
    16.8 16.8.0 - 16.8.3 16.8.4

지오 설치

  • GitLab 16.7 이상의 최신 설치에서는 PostgreSQL 버전 14가 기본값입니다. 알려진 이슈로 인해 기존 Geo 보조 사이트는 PostgreSQL 버전 14로 업그레이드할 수 없습니다. 자세한 내용은 issue 7768을 참조하십시오. 모든 Geo 사이트는 동일한 버전의 PostgreSQL을 실행해야 합니다. GitLab 16.7부터 16.8.1에 새로운 Geo 보조 사이트를 추가하려면 구성에 따라 다음 조치 중 하나를 취해야 합니다:

    • 첫 번째 Geo 보조 사이트를 추가하려면: 새로운 Geo 보조 사이트를 설정하기 전에 Primary 사이트를 PostgreSQL 14로 업그레이드 해야 합니다. Primary 사이트가 이미 PostgreSQL 14를 실행 중이면 특별한 조치가 필요하지 않습니다.
    • 하나 이상의 기존 Geo 보조 사이트가 모두 PostgreSQL 13을 실행하는 경우, 새로운 Geo 보조 사이트를 고정된 PostgreSQL 버전 13으로 설치해야 합니다.
    • 모든 기존 사이트가 PostgreSQL 14를 실행하는 경우: 특별한 조치가 필요하지 않습니다.
    • 새로운 Geo 보조 사이트를 배포에 추가하기 전에 모든 기존 사이트를 GitLab 16.8.2 이상 및 PostgreSQL 14로 업그레이드해야 합니다.

  • GitLab 16.5에서 소개된 버그로 인해 개인 스니펫이 보조 Geo 사이트로 복제되지 않습니다. 이로 인해 Geo 장애 조치 발생 시 개인 스니펫 데이터가 손실될 수 있습니다. 문제의 세부 정보 및 해결 방법은 issue #439933에서 확인할 수 있습니다.

    영향 받는 릴리스:

    영향 받는 마이너 릴리스 영향 받는 패치 릴리스 수정 사항
    16.5 모두 없음
    16.6 모두 없음
    16.7 모두 없음
    16.8 16.8.0 - 16.8.3 16.8.4
    16.9 16.9.0 - 16.9.1 16.9.2

  • 기본 사이트와 보조 사이트 간에 일부 컨테이너 레지스트리 이미지의 체크섬 일치하지 않아 검증 오류가 발생할 수 있습니다. Issue 442667에 자세한 내용이 설명되어 있습니다. 데이터가 보조 사이트로 올바르게 복제되지만 검증에 실패하는 상황에서 직접적인 데이터 손실 위험이 없습니다. 현재는 알려진 해결책이 없습니다.

    영향 받는 릴리스:

    영향 받는 마이너 릴리스 영향 받는 패치 릴리스 수정 사항
    16.8 16.8.0 - 16.8.3 16.8.4
    16.9 16.9.0 - 16.9.1 16.9.2

  • GitLab 16.5에서 소개된 버그로 인해 보조 Geo 사이트에 GitLab Pages 배포 파일이 고아 파일로 남게 됩니다. 페이지 배포가 로컬에 저장된 경우, Geo 장애 조치 시 남은 저장 공간이 없어져 결국 데이터가 손실될 수 있습니다. 문제의 세부 정보 및 해결 방법은 issue #457159에서 확인할 수 있습니다.

    영향 받는 릴리스:

    영향 받는 마이너 릴리스 영향 받는 패치 릴리스 수정 사항
    16.5 모두 없음
    16.6 모두 없음
    16.7 모두 없음
    16.8 모두 없음
    16.9 모두 없음
    16.10 16.10.0 - 16.10.6 16.10.7
    16.11 16.11.0 - 16.11.3 16.11.4

16.7.0

  • GitLab 16.7은 필수 업그레이드 단계입니다. 이는 모든 자체 관리형 인스턴스에 GitLab 16.7 및 이전 버전에서 도입된 모든 데이터베이스 변경 사항이 구현된 후에 의존적인 변경사항이 GitLab 16.8 이상에서 출시될 수 있게 합니다. Issue 429611에서 자세한 내용을 확인할 수 있습니다.

    • 업그레이드 경로에서 16.6을 건너뛰는 경우, 인스턴스가 GitLab 16.6 릴리스에서 백그라운드 데이터베이스 마이그레이션을 처리할 때 16.7로 업그레이드한 후 성능 문제가 발생할 수 있습니다. ci_builds 마이그레이션에 대해 16.6.0 업그레이드 노트에서 자세히 알아보십시오.

  • 일반적으로 PgBouncer가 있는 환경에서는 변수 값이 GITLAB_BACKUP_로 접두어가 붙은 변수를 설정하여 PgBouncer를 우회해야 합니다. 그러나 이슈로 gitlab-backup은 오버라이드에서 정의된 직접 연결 대신 PgBouncer를 통해 일반 데이터베이스 연결을 사용하고 데이터베이스 백업이 실패합니다. 해결책은 직접적으로 pg_dump를 사용하는 것입니다.

    영향 받는 릴리스:

    영향 받는 마이너 릴리스 영향 받는 패치 릴리스 수정 사항
    15.11 모두 없음
    16.0 모두 없음
    16.1 모두 없음
    16.2 모두 없음
    16.3 모두 없음
    16.4 모두 없음
    16.5 모두 없음
    16.6 모두 없음
    16.7 16.7.0 - 16.7.6 16.7.7
    16.8 16.8.0 - 16.8.3 16.8.4

Linux 패키지 설치

리눅스 패키지 설치에 대한 구체적인 정보는 다음과 같습니다.

  • GitLab 16.7부터 PostgreSQL 14가 Linux 패키지와 함께 기본 버전으로 설치됩니다. 패키지를 업그레이드하는 동안 데이터베이스는 PostgreSQL 14로 업그레이드되지 않습니다. PostgreSQL 14로 업그레이드하려면 수동으로 수행해야 합니다.

    PostgreSQL 13을 사용하려면 /etc/gitlab/gitlab.rb에서 postgresql['version'] = 13을 설정해야 합니다.

Geo 설치

  • GitLab 16.7 이상의 새로운 설치에는 PostgreSQL 버전 14가 기본값입니다. 알려진 문제로 기존 Geo 이중 사이트는 PostgreSQL 버전 14로 업그레이드할 수 없습니다. 자세한 내용은 이슈를 참조하십시오. 모든 Geo 사이트는 동일한 PostgreSQL 버전을 실행해야 합니다. GitLab 16.7부터 16.8.1을 기반으로 새 Geo 이중 사이트를 추가하려면 구성에 따라 다음 조치 중 하나를 취해야 합니다:

    • 첫 번째 Geo 이중 사이트를 추가하는 경우: 새 Geo 이중 사이트를 설정하기 전에 기본 사이트를 PostgreSQL 14로 업그레이드하십시오. 기본 사이트가 이미 PostgreSQL 14를 실행 중인 경우 특별한 조치가 필요하지 않습니다.
    • 하나 이상의 기존 Geo 이중 사이트가 PostgreSQL 13을 실행하는 경우: 새 Geo 이중 사이트를 고정된 PostgreSQL 버전 13으로 설치하십시오.
    • 모든 기존 사이트가 PostgreSQL 14를 실행하는 경우: 특별한 조치가 필요하지 않습니다.
    • 새 Geo 이중 사이트를 배포에 추가하기 전에 모든 기존 사이트를 GitLab 16.8.2 이상 및 PostgreSQL 14로 업그레이드하십시오.

  • 기본 사이트와 이중 사이트 간에 검사합격 실패가 발생할 수 있습니다. 이는 기본 사이트와 이중 사이트 간의 체크섬 불일치로 인해 발생합니다. 자세한 내용은 이 이슈에서 추적됩니다. 데이터는 올바르게 복제되므로 데이터 손실 위험이 없습니다. 영향을 받는 프로젝트를 복제하는 사용자는 항상 기본 사이트로 리디렉션됩니다. 현재 알려진 해결책은 없습니다. 문제를 열심히 해결 중입니다.

    영향 받는 릴리스:

    영향 받는 마이너 릴리스 영향 받는 패치 릴리스 해결된 버전
    16.3 모두 없음
    16.4 모두 없음
    16.5 모두 없음
    16.6 16.6.0 - 16.6.5 16.6.6
    16.7 16.7.0 - 16.7.3 16.7.4

  • GitLab 16.5에서 발생한 버그로 인해 개인 스니펫이 이중 Geo 사이트로 복제되지 않습니다. 이로 인해 Geo 장애 조치 시 개인 스니펫 데이터가 손실될 수 있습니다. 문제의 세부 내용 및 해결 방법은 이 이슈에서 확인할 수 있습니다.

    영향 받는 릴리스:

    영향 받는 마이너 릴리스 영향 받는 패치 릴리스 해결된 버전
    16.5 모두 없음
    16.6 모두 없음
    16.7 모두 없음
    16.8 16.8.0 - 16.8.3 16.8.4
    16.9 16.9.0 - 16.9.1 16.9.2

  • GitLab 16.5에서 발생한 버그로 인해 GitLab Pages 배포 파일이 이중 Geo 사이트에서 고아가 됩니다. 페이지 배포가 로컬에 저장된 경우 장애조치 시 저장 공간이 소진되고 이로 인해 데이터가 손실될 수 있습니다. 이 문제의 세부 내용 및 해결 방법은 이 이슈에서 확인할 수 있습니다.

    영향 받는 릴리스:

    영향 받는 마이너 릴리스 영향 받는 패치 릴리스 해결된 버전
    16.5 모두 없음
    16.6 모두 없음
    16.7 모두 없음
    16.8 모두 없음
    16.9 모두 없음
    16.10 16.10.0 - 16.10.6 16.10.7
    16.11 16.11.0 - 16.11.3 16.11.4

16.6.0

  • GitLab 16.6에서는 CI jobs 테이블(ci_builds)의 기본 키를 64비트로 업그레이드하는 백그라운드 마이그레이션이 도입되었습니다. 대부분의 GitLab 인스턴스에서 ci_builds는 가장 큰 테이블 중 하나이므로 이 마이그레이션은 보통보다 더 적극적으로 실행되어 합리적인 시간이 소요되도록 보장됩니다. 백그라운드 마이그레이션은 일반적으로 일괄 처리 간에 일시 중지되지만, 이 마이그레이션은 그렇지 않습니다.

    이로 인해 자기 관리 환경에서 성능 문제가 발생할 수 있습니다:

    • 디스크 I/O가 평소보다 높을 수 있습니다. 이는 디스크 I/O가 제한되는 클라우드 제공 업체에서 특히 문제가 될 수 있습니다.
    • Autovacuum는 오래된 행(불필요한 튜플)이 제거되고 관련 housekeeping이 수행되도록 보장하기 위해 백그라운드에서 더 자주 실행될 수 있습니다.
    • PostgreSQL이 비효율적인 쿼리 계획을 선택하여 일시적으로 쿼리가 느리게 실행될 수 있습니다. 이는 테이블에 변경이 많은 경우에 트리거될 수 있습니다.

    해결 방법:

    • 관리자 영역에서 실행 중인 마이그레이션을 일시 중지합니다.

    • 올바른 쿼리 계획이 선택되도록 데이터베이스 콘솔에서 테이블 통계를 수동으로 재생성합니다: 

      SET statement_timeout = 0;
VACUUM FREEZE VERBOSE ANALYZE public.ci_builds;
  • GitLab 16.6로 업그레이드한 후 CI Environment 파기 작업이 생성될 수 있습니다.

  • PgBouncer가 있는 환경의 백업은 일반적으로 GITLAB_BACKUP_으로 접두어가 지정된 변수를 설정하여 PgBouncer를 우회해야 합니다. 그러나 이슈로 인해 gitlab-backup은 오버라이드에서 정의된 직접 연결 대신 PgBouncer를 통해 일반 데이터베이스 연결을 사용하고 데이터베이스 백업이 실패합니다. 해결 방법은 pg_dump를 직접 사용하는 것입니다.

    영향 받는 릴리스:

    영향 받는 마이너 릴리스 영향 받는 패치 릴리스 해결된 버전
    15.11 모두 없음
    16.0 모두 없음
    16.1 모두 없음
    16.2 모두 없음
    16.3 모두 없음
    16.4 모두 없음
    16.5 모두 없음
    16.6 모두 없음
    16.7 16.7.0 - 16.7.6 16.7.7
    16.8 16.8.0 - 16.8.3 16.8.4

지오 설치

  • 기본 사이트와 보조 사이트 간의 체크섬 불일치로 일부 프로젝트에서 확인 실패가 발생할 수 있습니다. 자세한 내용은 이 문제에서 추적됩니다. 데이터가 보조 사이트로 올바르게 복제되고 있기 때문에 데이터 손실의 위험이 없습니다. 지오 보조 사이트에서 영향을 받는 프로젝트를 복제하는 사용자는 항상 기본 사이트로 리디렉션됩니다. 현재 알려진 해결방법은 없습니다. 문제를 해결하기 위해 노력하고 있습니다.

    영향을 받는 릴리스:

    영향 받는 마이너 릴리스 영향 받는 패치 릴리스 수정된 버전
    16.3 모든 없음
    16.4 모든 없음
    16.5 모든 없음
    16.6 16.6.0 - 16.6.5 16.6.6
    16.7 16.7.0 - 16.7.3 16.7.4

  • GitLab 16.5에서 버그가 발생하여 개인 스니펫이 보조 지오 사이트로 복제되지 않습니다. 이로 인해 지오 장애 조치 시 개인 스니펫 데이터 손실이 발생할 수 있습니다. 문제에 대한 자세한 내용 및 해결 방법은 문제 #439933에서 확인할 수 있습니다.

    영향을 받는 릴리스:

    영향 받는 마이너 릴리스 영향 받는 패치 릴리스 수정된 버전
    16.5 모든 없음
    16.6 모든 없음
    16.7 모든 없음
    16.8 16.8.0 - 16.8.3 16.8.4
    16.9 16.9.0 - 16.9.1 16.9.2

  • GitLab 16.5에서 발생한 버그로 인해 17.0에서 수정되기 전까지 GitLab Pages 배포 파일이 보조 지오 사이트에서 고아 상태가 됩니다. Pages 배포가 로컬에 저장되어 있으면, 이로 인해 장애 조치 시 남은 저장 공간이 0이 되고 이에 따라 데이터 손실이 발생할 수 있습니다. 문제에 대한 자세한 내용 및 해결 방법은 문제 #457159에서 확인할 수 있습니다.

    영향을 받는 릴리스:

    영향 받는 마이너 릴리스 영향 받는 패치 릴리스 수정된 버전
    16.5 모든 없음
    16.6 모든 없음
    16.7 모든 없음
    16.8 모든 없음
    16.9 모든 없음
    16.10 16.10.0 - 16.10.6 16.10.7
    16.11 16.11.0 - 16.11.3 16.11.4

16.5.0

  • Gitaly에서는 Git 2.42.0 이상이 필요합니다. 자체 컴파일 설치의 경우, Gitaly에서 제공하는 Git 버전을 사용해야 합니다.
  • 때로는 리그레이션이 그룹을 탐색할 때 HTTP 500 오류를 유발할 수 있습니다. GitLab 16.6 이상으로 업그레이드하면 문제가 해결됩니다.
  • 리그레이션으로 선택되지 않은 고급 검색 패싯을 불러오지 않을 수 있습니다. 16.6 이상으로 업그레이드하면 문제가 해결됩니다.

  • unique_batched_background_migrations_queued_migration_version 인덱스가 16.5에서 도입되었으며, 포스트 배포 마이그레이션 DeleteOrphansScanFindingLicenseScanningApprovalRules2은 이 고유한 제약 조건을 깨뜨릴 수 있습니다. 문제 #437291에서 오류를 해결하는 사용 가능한 해결책이 제공됩니다: 

    PG::UniqueViolation: ERROR:  duplicate key value violates unique constraint
"unique_batched_background_migrations_queued_migration_version"
DETAIL:  Key (queued_migration_version)=(20230721095222) already exists.

  • PgBouncer가 있는 환경에서는 일반적으로 변수를 설정하여 PgBouncer를 우회해야 합니다만, 문제로 인해 gitlab-backup은 오버라이드에서 정의된 직접 연결 대신 PgBouncer를 통해 일반 데이터베이스 연결을 사용하고 데이터베이스 백업이 실패합니다. 해결책은 직접 pg_dump를 사용하는 것입니다.

    영향을 받는 릴리스:

    영향 받는 마이너 릴리스 영향 받는 패치 릴리스 수정된 버전
    15.11 모든 없음
    16.0 모든 없음
    16.1 모든 없음
    16.2 모든 없음
    16.3 모든 없음
    16.4 모든 없음
    16.5 모든 없음
    16.6 모든 없음
    16.7 16.7.0 - 16.7.6 16.7.7
    16.8 16.8.0 - 16.8.3 16.8.4

Linux 패키지 설치

  • SSH 클론 URL은 이제 /etc/gitlab/gitlab.rb에서 gitlab_rails['gitlab_ssh_host']를 설정하여 사용자 정의로 변경할 수 있습니다. 이 설정은 이제 저장소 클론 URL에서 사용할 수 있는 유효한 호스트 이름이어야 합니다. 이전에는 저장소 클론 URL에서 사용되는 임의의 문자열로 사용되어 사용자 정의 호스트 이름과 포트를 보여주는 데 사용되었지만, 이제는 호스트 이름과 포트를 개별적으로 지정해야 합니다.

    예를 들어, GitLab 16.5 이전에는 다음 설정이 작동했습니다: 

    gitlab_rails['gitlab_ssh_host'] = "gitlab.example.com:2222"

    GitLab 16.5부터는 호스트 이름과 포트를 따로 지정해야 합니다: 

    gitlab_rails['gitlab_ssh_host'] = "gitlab.example.com"
gitlab_rails['gitlab_shell_ssh_port'] = 2222

    설정을 변경한 후에는 GitLab을 다시 구성해야 합니다: 

    sudo gitlab-ctl reconfigure

Geo 설치

Geo를 사용하여 설치하는 경우 특정 정보가 적용됩니다:

  • 16.3.0에서 일부 Prometheus 지표가 부적절하게 제거되어 대시보드 및 경고 기능이 손상될 수 있습니다:

    영향 받는 지표 16.5.2 및 이후에 복원된 지표 16.3+에서 사용 가능한 대체품
    geo_repositories_synced 예 geo_project_repositories_synced
    geo_repositories_failed 예 geo_project_repositories_failed
    geo_repositories_checksummed 예 geo_project_repositories_checksummed
    geo_repositories_checksum_failed 예 geo_project_repositories_checksum_failed
    geo_repositories_verified 예 geo_project_repositories_verified
    geo_repositories_verification_failed 예 geo_project_repositories_verification_failed
    geo_repositories_checksum_mismatch 아니요 사용 가능한 것이 없음
    geo_repositories_retrying_verification 아니요 사용 가능한 것이 없음
    • 영향받는 버전:
      • 16.3.0에서 16.5.1까지
    • 수정된 버전:
      • 16.5.2 및 이후

    자세한 내용은 이슈 429617을 참조하십시오.

  • GitLab 16.4에 객체 저장소 확인이 추가되었습니다. 그러나 문제로 인해 일부 Geo 설치에서 메모리 사용량이 높아져 기본 사이트의 GitLab 애플리케이션이 응답하지 않을 수 있습니다.

    객체 저장소를 사용하도록 구성했고 GitLab 관리형 객체 저장소 복제를 활성화한 경우 설치에 영향을 받을 수 있습니다.

    이 문제가 해결될 때까지 객체 저장소 확인을 비활성화해야 합니다. 기본 사이트의 레일스 노드 중 하나에서 다음 명령을 실행합니다: 

    sudo gitlab-rails runner 'Feature.disable(:geo_object_storage_verification)'

    영향 받는 릴리스:

    영향 받는 마이너 릴리스 영향 받는 패치 릴리스 수정 버전
    16.4 16.4.0 - 16.4.2 16.4.3
    16.5 16.5.0 - 16.5.1 16.5.2

  • GitLab 16.3에 그룹 위키 확인이 추가된 이후에 누락된 그룹 위키 저장소가 잘못된 상태로 Geo 내에서 잘못된 재현/확인 실패로 플래그 처리됩니다. 이 문제는 실제 재현/확인 실패가 아닌 Geo 내의 이러한 누락된 저장소에 대한 잘못된 내부 상태로, 로그와 확인 진행상황에서 이러한 그룹 위키 저장소에 대한 실패 상태가 잘못 표시됩니다.

    문제의 자세한 내용 및 해결 방법은 이슈 #426571을 참조하십시오.

    영향 받는 릴리스:

    영향 받는 마이너 릴리스 영향 받는 패치 릴리스 수정 버전
    16.3 모두 없음
    16.4 모두 없음
    16.5 16.5.0 - 16.5.1 16.5.2

  • 본사 사이트와 보조 사이트 간에 체크섬 불일치로 일부 프로젝트에서 확인 실패가 발생할 수 있습니다. 자세한 내용은 다음 이슈에서 추적할 수 있습니다. 보조 사이트에서 영향을 받는 프로젝트를 복제하는 사용자는 항상 기본 사이트로 리디렉션됩니다. 현재 알려진 해결책은 없습니다. 현재 문제에 대해 노력하고 있습니다.

    영향 받는 릴리스:

    영향 받는 마이너 릴리스 영향 받는 패치 릴리스 수정 버전
    16.3 모두 없음
    16.4 모두 없음
    16.5 모두 없음
    16.6 16.6.0 - 16.6.5 16.6.6
    16.7 16.7.0 - 16.7.3 16.7.4

  • GitLab 16.5에서 발생한 버그로 인해 개인 스니펫이 보조 Geo 사이트에 복제되지 않습니다. Geo 장애 조치 발생 시 개인 스니펫 데이터가 손실될 수 있습니다. 문제의 자세한 내용 및 해결 방법은 이슈 #439933을 참조하십시오.

    영향 받는 릴리스:

    영향 받는 마이너 릴리스 영향 받는 패치 릴리스 수정 버전
    16.5 모두 없음
    16.6 모두 없음
    16.7 모두 없음
    16.8 16.8.0 - 16.8.3 16.8.4
    16.9 16.9.0 - 16.9.1 16.9.2

  • GitLab 16.5에서 발생한 버그로 인해 17.0에서 수정되기 전에 GitLab 페이지 배포 파일이 보조 Geo 사이트에 고립되고 있습니다. 페이지 배포가 로컬에 저장된 경우 재해 조치 시 남아있는 저장소가 없어지고 결과적으로 데이터 손실이 발생할 수 있습니다. 문제의 자세한 내용 및 해결 방법은 이슈 #457159을 참조하십시오.

    영향 받는 릴리스:

    영향 받는 마이너 릴리스 영향 받는 패치 릴리스 수정 버전
    16.5 모두 없음
    16.6 모두 없음
    16.7 모두 없음
    16.8 모두 없음
    16.9 모두 없음
    16.10 16.10.0 - 16.10.6 16.10.7
    16.11 16.11.0 - 16.11.3 16.11.4

16.4.0

  • 업데이트된 그룹 경로에 버그 수정를 받았으며, 이 버그 수정은 16.3에서 소개된 데이터베이스 인덱스를 사용합니다.

    만약 16.3보다 낮은 버전에서 16.4로 업그레이드한다면, 사용하기 전에 데이터베이스에서 ANALYZE packages_packages;를 실행해야 합니다.

  • GitLab 16.4 이상으로 업그레이드하는 동안 다음과 같은 오류가 발생할 수 있습니다: 

    main: == 20230830084959 ValidatePushRulesConstraints: migrating =====================
main: -- execute("SET statement_timeout TO 0")
main:    -> 0.0002s
main: -- execute("ALTER TABLE push_rules VALIDATE CONSTRAINT force_push_regex_size_constraint;")
main:    -> 0.0004s
main: -- execute("RESET statement_timeout")
main:    -> 0.0003s
main: -- execute("ALTER TABLE push_rules VALIDATE CONSTRAINT delete_branch_regex_size_constraint;")
rails aborted!
StandardError: An error has occurred, all later migrations canceled:

PG::CheckViolation: ERROR:  check constraint "delete_branch_regex_size_constraint" of relation "push_rules" is violated by some row

    이러한 제약 조건은 오류를 반환할 수 있습니다:

    • author_email_regex_size_constraint
    • branch_name_regex_size_constraint
    • commit_message_negative_regex_size_constraint
    • commit_message_regex_size_constraint
    • delete_branch_regex_size_constraint
    • file_name_regex_size_constraint
    • force_push_regex_size_constraint

    오류를 수정하려면, push_rules 테이블에서 511 글자 제한을 초과하는 레코드를 찾으세요. 

    ;; `delete_branch_regex`를 제약 조건에서 사용하는 필드 이름으로 바꿉니다.
SELECT id FROM push_rules WHERE LENGTH(delete_branch_regex) > 511;

    푸시 규칙이 프로젝트, 그룹 또는 인스턴스에 속하는지 확인하려면 Rails 콘솔에서 이 스크립트를 실행하세요. 

    ;; `delete_branch_regex`를 제약 조건에서 사용하는 필드 이름으로 바꿉니다.
long_rules = PushRule.where("length(delete_branch_regex) > 511")

array = long_rules.map do |lr|
  if lr.project
    "Push rule with ID #{lr.id} is configured in a project #{lr.project.full_name}"
  elsif lr.group
    "Push rule with ID #{lr.id} is configured in a group #{lr.group.full_name}"
  else
    "Push rule with ID #{lr.id} is configured on the instance level"
  end
end

puts "Total long rules: #{array.count}"
puts array.join("\n")

    영향을 받는 푸시 규칙 레코드의 정규식 필드 값을 줄이고, 마이그레이션을 다시 시도하세요.

    영향을 받는 푸시 규칙이 많고, GitLab UI를 통해 업데이트할 수 없는 경우, GitLab 지원팀에 문의하세요.

  • 일반적으로, PgBouncer가 있는 환경에서 백업을 수행할 때는 변수 이름이 GITLAB_BACKUP_로 시작하는 변수를 설정하여 PgBouncer를 우회해야 합니다. 그러나 이슈로 인해 gitlab-backup은 오버라이드에서 정의된 직접적인 연결 대신 PgBouncer를 통해 일반적인 데이터베이스 연결을 사용하고 데이터베이스 백업에 실패합니다. 이 문제를 해결하기 위한 임시방편은 pg_dump를 직접 사용하는 것입니다.

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정된 버전
    15.11 모든 없음
    16.0 모든 없음
    16.1 모든 없음
    16.2 모든 없음
    16.3 모든 없음
    16.4 모든 없음
    16.5 모든 없음
    16.6 모든 없음
    16.7 16.7.0 - 16.7.6 16.7.7
    16.8 16.8.0 - 16.8.3 16.8.4

자체 컴파일 설치

  • GitLab 16.4 이상에서는 GitLab 시크릿 및 사용자 정의 후크의 경로를 구성하는 새로운 방법이 선호됩니다:
    1. 구성을 업데이트하여 [gitlab] secret_file을 GitLab 시크릿 토큰의 경로를 구성합니다.
    2. 사용자 정의 후크가 있는 경우, 구성을 업데이트하여 [hooks] custom_hooks_dir을 서버 측 사용자 정의 후크의 경로를 구성합니다.
    3. [gitlab-shell] dir 구성을 제거하세요.

Geo 설치

Geo를 사용하는 설치에는 특정 정보가 적용됩니다:

  • 16.3.0에서 잘못 제거된 일부 Prometheus 메트릭은 대시보드 및 경고를 손상시킬 수 있습니다.

    영향을 받는 메트릭 16.5.2 및 이후에 복구된 메트릭 16.3+에서 사용 가능한 대체
    geo_repositories_synced 예 geo_project_repositories_synced
    geo_repositories_failed 예 geo_project_repositories_failed
    geo_repositories_checksummed 예 geo_project_repositories_checksummed
    geo_repositories_checksum_failed 예 geo_project_repositories_checksum_failed
    geo_repositories_verified 예 geo_project_repositories_verified
    geo_repositories_verification_failed 예 geo_project_repositories_verification_failed
    geo_repositories_checksum_mismatch 아니요 사용 가능한 사항 없음
    geo_repositories_retrying_verification 아니요 사용 가능한 사항 없음
    • 영향을 받는 버전:
      • 16.3.0 ~ 16.5.1
    • 수정된 버전 포함:
      • 16.5.2 및 이후

    자세한 내용은 이슈 429617을 참조하세요.

  • GitLab 16.4에서 객체 저장소 검증가 추가되었습니다. 그러나 이슈로 인해 일부 Geo 설치에서 GitLab 애플리케이션이 응답하지 않을 수 있는 고 메모리 사용량이 보고되고 있습니다.

    설치가 객체 저장소를 사용하고 GitLab에서 관리하는 객체 저장소 복제를 활성화한 경우, 설치에 영향을 받을 수 있습니다.

    이 문제를 해결하지 않는 한, 객체 저장소 검증을 비활성화하세요. 기본 사이트의 Rails 노드 중 하나에서 다음 명령을 실행하세요. 

    sudo gitlab-rails runner 'Feature.disable(:geo_object_storage_verification)'

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정된 버전
    16.4 16.4.0 - 16.4.2 16.4.3
    16.5 16.5.0 - 16.5.1 16.5.2

  • 이슈로 인해 동기화 상태가 보류 상태에 갇히는 것은 영향을 받는 항목의 동기화가 무기한으로 멈추고 관련된 데이터 손실 위험을 야기할 수 있습니다. 이 문제는 주로 저장소 동기화에 영향을 미치지만 컨테이너 레지스트리 동기화에도 영향을 줄 수 있습니다. 데이터 손실 위험을 피하기 위해 수정된 버전으로 업그레이드하는 것이 좋습니다.

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정된 버전
    16.3 16.3.0 - 16.3.5 16.3.6
    16.4 16.4.0 - 16.4.1 16.4.2

  • GitLab 16.3에서 그룹 위키 검증이 추가된 후 실제 동기화/검증 오류가 아닌 개 내부적인 상태로 인해 누락된 그룹 위키 저장소가 잘못된 상태로 표시됩니다. 이 문제는 이슈 #426571에서 자세한 내용과 해결 방법을 확인할 수 있습니다.

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정된 버전
    16.3 모두 없음
    16.4 모두 없음
    16.5 16.5.0 - 16.5.1 16.5.2

  • 주요 사이트와 보조 사이트 간에 체크섬 불일치로 일부 프로젝트에서 검증 오류가 발생할 수 있습니다. 자세한 내용은 이 이슈에서 확인할 수 있습니다. 현재 알려진 해결책은 없습니다.

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정된 버전
    16.3 모두 없음
    16.4 모두 없음
    16.5 모두 없음
    16.6 16.6.0 - 16.6.5 16.6.6
    16.7 16.7.0 - 16.7.3 16.7.4

16.3.0

  • GitLab 16.3.5 이상으로 업데이트하세요. 이렇게 함으로써 issue 425971가 발생하는 것을 피할 수 있습니다. 이 문제는 GitLab 16.3.3 및 16.3.4에서 데이터베이스 디스크 공간을 과도하게 사용하는 원인이 됩니다.

  • 중복되는 NPM 패키지가 데이터베이스에 없음을 보장하기 위해 고유한 인덱스가 추가되었습니다. 중복되는 NPM 패키지가 있는 경우, 16.1로 먼저 업그레이드해야하며, 그렇지 않으면 다음 오류가 발생할 수 있습니다: PG::UniqueViolation: ERROR: could not create unique index "idx_packages_on_project_id_name_version_unique_when_npm".

  • Go 애플리케이션의 경우, crypto/tls: verifying certificate chains containing large RSA keys is slow (CVE-2023-29409) 암호화/TLS 연결에 8192비트 이상의 RSA 키가 포함된 인증서 체인을 확인하는 데 시간이 오래 걸리게 됩니다. GitLab의 경우, 다음 애플리케이션에 대해 RSA 키를 구성할 수 있습니다:

    업그레이드하기 전에 위의 애플리케이션 중 하나에 대한 RSA 키의 크기를 확인해야 합니다 (openssl rsa -in <your-key-file> -text -noout | grep "Key:").

  • BackfillCiPipelineVariablesForPipelineIdBigintConversion 백그라운드 마이그레이션이 EnsureAgainBackfillForCiPipelineVariablesPipelineIdIsFinished 포스트-디플로이 마이그레이션으로 완료되었습니다. GitLab 16.2.0에서 일괄 배치 백그라운드 마이그레이션이 소개되어 ci_pipeline_variables 테이블의 bigint pipeline_id 값 백필을 위한 마이그레이션이 진행되었습니다. 기존에는 큰 GitLab 인스턴스에서 이 마이그레이션이 오랜 시간이 걸릴 수 있습니다 (한 경우에는 5000만 개의 row를 처리하는 데 4시간이 걸렸음). 긴 업그레이드 다운타임을 피하기 위해 업그레이드하기 전에 마이그레이션이 성공적으로 완료되었는지 확인하십시오.

    데이터베이스 콘솔에서 ci_pipeline_variables 테이블의 크기를 확인할 수 있습니다. 

    select count(*) from ci_pipeline_variables;

  • PgBouncer를 사용하는 환경에서 백업을 수행할 때 보통은 GITLAB_BACKUP_으로 접두어가 지정된 변수를 설정하여 PgBouncer를 우회해야 합니다. 그러나 이슈로 인해 gitlab-backup은 우회로 정의된 직접 연결 대신 PgBouncer를 통해 보통의 데이터베이스 연결을 사용하고 데이터베이스 백업이 실패합니다. 해결책은 pg_dump를 직접 사용하는 것입니다.

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정된 내용
    15.11 모두 없음
    16.0 모두 없음
    16.1 모두 없음
    16.2 모두 없음
    16.3 모두 없음
    16.4 모두 없음
    16.5 모두 없음
    16.6 모두 없음
    16.7 16.7.0 - 16.7.6 16.7.7
    16.8 16.8.0 - 16.8.3 16.8.4

Linux 패키지 설치

Linux 패키지 설치에는 특정 정보가 적용됩니다:

  • GitLab 16.0에서 공지한 기본 Docker 이미지의 업그레이드되었습니다. 이 이미지에는 새 버전의 OpenSSH Server가 포함되었습니다. 새 버전의 의도하지 않은 결과로 인해 기본적으로 SSH RSA SHA-1 서명을 수락하지 않게 됩니다. 이 문제는 매우 오래된 SSH 클라이언트를 사용하는 사용자들에게만 영향을 줄 것으로 예상됩니다.

    SHA-1 서명을 사용할 수 없게 되면서 발생할 수 있는 문제를 피하기 위해 사용자들은 보안상의 이유로 SHA-1 서명을 사용하지 않는 것이 권장됩니다.

    사용자가 즉시 SSH 클라이언트를 업데이트할 수 없는 경우를 대비하여, GitLab 16.3 이후에는 Dockerfile에서 GITLAB_ALLOW_SHA1_RSA 환경 변수를 지원합니다. GITLAB_ALLOW_SHA1_RSA가 true로 설정된 경우에만 이제는 사용이 중지된 지원이 다시 활성화됩니다.

    우리는 보안 최선의 방법을 촉진하고 상류 라이브러리의 권고를 따르기를 원하기 때문에, 이 환경 변수는 GitLab 17.0에서 지원이 해제될 예정입니다.

    자세한 내용은 다음을 참조하세요:

Geo 설치

Geo를 사용하는 설치에는 특정 정보가 적용됩니다:

  • 보조 Geo 사이트로의 Git 풀은 해당 보조 사이트가 최신 상태일 때에도 기본 Geo 사이트로 프록시됩니다. 이 문제는 보조 Geo 사이트에서 Git 풀 요청을 가속화하기 위해 Geo를 사용 중인 경우 영향을 받습니다.

    • 영향을 받는 버전:
      • 16.3.0부터 16.3.3까지
    • 수정된 버전을 포함한 버전:
      • 16.3.4 및 이후

    자세한 내용은 issue 425224를 참조하십시오.

  • 16.3.0에서 일부 Prometheus 메트릭이 잘못 제거되어 대시보드 및 경고가 손상될 수 있습니다:

    영향을 받는 메트릭 16.5.2 이후에 복원된 메트릭 16.3+에서 사용 가능한 대체품
    geo_repositories_synced 예 geo_project_repositories_synced
    geo_repositories_failed 예 geo_project_repositories_failed
    geo_repositories_checksummed 예 geo_project_repositories_checksummed
    geo_repositories_checksum_failed 예 geo_project_repositories_checksum_failed
    geo_repositories_verified 예 geo_project_repositories_verified
    geo_repositories_verification_failed 예 geo_project_repositories_verification_failed
    geo_repositories_checksum_mismatch 아니요 사용 가능하지 않음
    geo_repositories_retrying_verification 아니요 사용 가능하지 않음
    • 영향을 받는 버전:
      • 16.3.0부터 16.5.1까지
    • 수정된 버전을 포함한 버전:
      • 16.5.2 이후

    자세한 내용은 issue 429617를 참조하십시오.

  • 동기 상태가 대기 상태에 멈추는 문제로 인해 영향을 받는 항목에 대한 복제가 영원히 멈출 수 있으므로 장애 조치 시 데이터 손실 위험이 있습니다. 이는 주로 저장소 동기화에 영향을 끼치지만 컨테이너 레지스트리 동기화에도 영향을 줄 수 있습니다. 데이터 손실 위험을 피하기 위해 수정된 버전으로 업그레이드하는 것이 좋습니다.

  • 주요 프로젝트 중 일부에서 기본 사이트와 보조 사이트 간의 체크섬 불일치로 인해 검증 실패가 발생할 수 있습니다. 자세한 내용은 issue 427493을 참조하십시오. 데이터가 보조 사이트에 올바르게 복제되고 있기 때문에 데이터 손실 위험이 없습니다. 영향을 받는 프로젝트를 복제하는 사용자는 항상 기본 사이트로 리디렉션됩니다. 알려진 해결책이 없으며 수정된 버전으로 업그레이드해야 합니다.

    영향을 받는 버전:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정된 내용
    16.3 16.3.0 - 16.3.5 16.3.6
    16.4 16.4.0 - 16.4.1 16.4.2

  • GitLab 16.3에서 그룹 위키(Group Wiki) 검증이 추가되었지만, 실제 복제/검증 실패가 아닌이 그룹 위키 저장소가 검증 실패로 잘못 표시되고 있습니다. 이는 Geo 안에서 이러한 누락된 저장소에 대한 내부적인 잘못된 상태로 인한 문제로 로그에 오류가 포함되어 있고 검증 진행 사항이 이러한 그룹 위키 저장소에 대한 실패 상태를 기록합니다.

    문제의 세부 정보 및 해결 방법은 issue #426571에서 확인할 수 있습니다.

    영향을 받는 버전:

    영향을 받는 마이너 릴리스 영햁을 받는 패치 릴리스 수정된 내용
    16.3 모두 없음
    16.4 모두 없음
    16.5 16.5.0 - 16.5.1 16.5.2

16.2.0

  • 이전 LDAP 구성 설정들은 NoMethodError: undefined method 'devise' for User:Class 오류를 일으킬 수 있습니다. 이 오류는 tls_options 해시에 지정되지 않은 TLS 옵션(예: ca_file)이 있거나 레거시 gitlab_rails['ldap_host'] 옵션을 사용하는 경우 발생합니다. 자세한 내용은 구성 해결책을 참조하세요.

  • GitLab 데이터베이스가 15.11.0 - 15.11.2 버전을 통해 생성되거나 업그레이드된 경우, GitLab 16.2로 업그레이드하려고 하면 실패할 수 있습니다: 

    PG::UndefinedColumn: ERROR:  relation "ci_build_needs"의 "id_convert_to_bigint" 컬럼이 존재하지 않습니다
LINE 1: ...db_config_name:main*/ UPDATE "ci_build_needs" SET "id_conver...

    자세한 내용 및 해결 방법은 세부 정보 및 해결 방법을 참조하세요.

  • GitLab 16.2 이상으로 업그레이드하는 도중 다음 오류가 발생할 수 있습니다: 

    main: == 20230620134708 ValidateUserTypeConstraint: migrating =======================
main: -- execute("ALTER TABLE users VALIDATE CONSTRAINT check_0dd5948e38;")
rake aborted!
StandardError: An error has occurred, all later migrations canceled:
PG::CheckViolation: ERROR:  relation "users"의 "check_0dd5948e38" 체크 제약 조건이 몇 가지 행에 의해 위반되었습니다

    자세한 내용은 이슈 421629를 참조하세요.

  • GitLab 16.2 이상으로 업그레이드한 후 다음과 같은 오류가 발생할 수 있습니다: 

    PG::NotNullViolation: ERROR:  relation "ci_sources_pipelines"의 "source_partition_id" 컬럼에 null 값이 not-null 제약 조건을 위배하였습니다

    이 문제를 해결하려면 Sidekiq 및 Puma 프로세스를 재시작해야 합니다.

  • 보통 PgBouncer가있는 환경에서 백업을 해야하는 경우, GITLAB_BACKUP_ 접두어로 시작하는 변수를 설정하여 PgBouncer를 우회해야 합니다. 그러나 이슈로 gitlab-backup은 오버라이드에서 정의된 직접 연결 대신 PgBouncer를 통해 일반 데이터베이스 연결을 사용하며 데이터베이스 백업이 실패합니다. 해결책은 pg_dump를 직접 사용하는 것입니다.

    영향 받는 릴리스:

    영향 받는 마이너 릴리스 영향 받는 패치 릴리스 수정 버전
    15.11 전체 없음
    16.0 전체 없음
    16.1 전체 없음
    16.2 전체 없음
    16.3 전체 없음
    16.4 전체 없음
    16.5 전체 없음
    16.6 전체 없음
    16.7 16.7.0 - 16.7.6 16.7.7
    16.8 16.8.0 - 16.8.3 16.8.4

리눅스 패키지 설치

특정 정보는 리눅스 패키지 설치에 적용됩니다:

  • GitLab 16.2부터 PostgreSQL 13.11 및 14.8이 모두 리눅스 패키지와 함께 제공됩니다. 패키지 업그레이드 중, 데이터베이스는 PostgreSQL 14로 업그레이드되지 않습니다. PostgreSQL 14로 업그레이드하려면 수동으로 해야합니다: 

    sudo gitlab-ctl pg-upgrade -V 14

    PostgreSQL 14는 Geo 배포에서 지원되지 않으며 계획에 따라 향후 릴리스에 포함될 예정입니다.

  • 16.2에서 Redis를 6.2.11에서 7.0.12로 업그레이드합니다. 이 업그레이드는 완전히 하위 호환성이 있을 것으로 예상됩니다.

    Redis는 gitlab-ctl reconfigure의 일부로 자동으로 다시 시작되지 않습니다. 따라서 사용자는 재구성 실행 후 sudo gitlab-ctl restart redis를 수동으로 실행하여 새로운 Redis 버전을 사용해야합니다. 재구성 실행이 끝날 때까지 설치된 Redis 버전이 실행 중인 버전과 다르다는 경고가 표시됩니다.

    Redis HA 클러스터를 업그레이드하려면 중단되지 않는 업그레이드 지침에 따르세요.

자체 컴파일 설치

Geo 설치

Geo를 사용하는 설치에 적용되는 특정 정보는 다음과 같습니다:

  • 새 작업 아티팩트는 작업 아티팩트가 객체 저장소에 저장되도록 구성되고 direct_upload가 활성화된 경우 Geo에 의해 복제되지 않습니다. 이 버그는 GitLab 버전 16.1.4, 16.2.3, 16.3.0 및 이후 버전에서 수정되었습니다.
    • 영향을 받는 버전: GitLab 버전 16.1.0 - 16.1.3 및 16.2.0 - 16.2.2.
    • 영향을 받는 버전에서 실행 중에 동기화된 것처럼 보이는 아티팩트는 실제로 보조 사이트에서 누락 될 수 있습니다. 영향을 받는 아티팩트는 16.1.5, 16.2.5, 16.3.1, 16.4.0 또는 이후 버전으로 업그레이드하면 자동으로 동기화됩니다. 필요한 경우 영향을 받는 작업 아티팩트를 수동으로 동기화할 수 있습니다.

보조 사이트에서 LFS 객체를 복제하여 기본 사이트에서 다운로드

LFS 객체에 대한 Geo 프록시 로직 오류로 모든 보조 사이트에 대한 LFS 복제 요청이 보조 사이트가 최신 상태인 경우에도 기본 사이트로 프록시됩니다. 이는 기본 사이트의 부하가 증가하고 보조 사이트에서 복제하는 사용자들의 LFS 객체에 대한 액세스 시간이 늘어나는 결과를 초래할 수 있습니다.

GitLab 15.1에서 프록시 기능은 기본적으로 활성화되었습니다.

영향을 받지 않는 경우:

  • LFS 객체를 사용하는 방식으로 구성되어 있지 않은 경우
  • 원격 사용자를 가속화하기 위해 Geo를 사용하지 않는 경우
  • 원격 사용자를 가속화하기 위해 Geo를 사용하지만 프록시 기능을 비활성화한 경우
영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정 버전
15.1 - 16.2 모두 16.3부터

해결 방법: 가능한 해결 방법은 프록시 기능을 비활성화하는 것입니다. 클론 시점에 복제되지 않은 LFS 파일을 보조 사이트에서 서비스하지 못할 수 있음을 주의하세요.

16.1.0

  • BackfillPreparedAtMergeRequests 배경 마이그레이션이 FinalizeBackFillPreparedAtMergeRequests 배포 후 마이그레이션과 결합되었습니다. GitLab 15.10.0에서 일괄 배경 마이그레이션을 도입하여 merge_requests 테이블의 prepared_at 값을 backfill하는 것이 소개되었습니다. 이 마이그레이션은 대규모 GitLab 인스턴스에서 여러 날이 소요될 수 있습니다. 16.1.0으로 업그레이드하기 전에 마이그레이션이 성공적으로 완료되었는지 확인하세요.
  • GitLab 16.1.0에는 일괄 배경 마이그레이션 MarkDuplicateNpmPackagesForDestruction가 포함되어 중복된 NPM 패키지를 마킹하는 기능이 추가되었습니다. 16.3.0 이상으로 업그레이드하기 전에 마이그레이션이 성공적으로 완료되었는지 확인하세요.

  • BackfillCiPipelineVariablesForBigintConversion 배경 마이그레이션이 EnsureBackfillBigintIdIsCompleted 배포 후 마이그레이션과 결합되었습니다. GitLab 16.0.0에서 일괄 배경 마이그레이션을 도입하여 ci_pipeline_variables 테이블의 bigint id 값을 backfill하는 것이 소개되었습니다. 이 마이그레이션은 대규모 GitLab 인스턴스에서 오랜 시간이 소요될 수 있습니다(한 경우에서 5000만 행을 처리하는 데 4시간이 소요되었다고 보고되었습니다). 오랜 시간 동안 업그레이드 다운타임을 피하려면 마이그레이션이 성공적으로 완료되었는지 확인하세요. 16.1으로 업그레이드하기 전에 ci_pipeline_variables 테이블의 크기를 데이터베이스 콘솔에서 확인할 수 있습니다: 

    select count(*) from ci_pipeline_variables;

자체 컴파일된 설치

  • puma.rb 구성 파일에서 Puma worker killer와 관련된 모든 설정을 제거해야 합니다. 왜냐하면 제거되었기 때문입니다. 자세한 내용은 puma.rb.example 파일을 참조하세요.

  • PgBouncer가 있는 환경에서 백업할 경우 일반적으로 PgBouncer를 우회해야 합니다. 그러나 이슈로 gitlab-backup이 오버라이드에서 정의된 직접 연결 대신에 PgBouncer를 통해 정상적인 데이터베이스 연결을 사용하여 백업이 실패합니다. 해결 방법은 pg_dump를 직접 사용하는 것입니다.

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정 버전
    15.11 모두 없음
    16.0 모두 없음
    16.1 모두 없음
    16.2 모두 없음
    16.3 모두 없음
    16.4 모두 없음
    16.5 모두 없음
    16.6 모두 없음
    16.7 16.7.0 - 16.7.6 16.7.7
    16.8 16.8.0 - 16.8.3 16.8.4

Geo 설치

Tier: 프리미엄, 얼티메이트 Offering: Self-managed

Geo를 사용하는 설치에 적용되는 특정 정보:

  • 일부 프로젝트 가져오기는 프로젝트 생성 시에 위키 리포지토리를 초기화하지 않습니다. 자세한 정보 및 해결 방법을 참조하세요.
  • 프로젝트 디자인 마이그레이션이 SSF로 이동되는 결과로 실제 미디어 파일 저장소가 실패로 오인되는 문제가 발생합니다. 이 문제는 프로젝트 가져오기와 관련이 없는데 Geo 내에서 누락된 이러한 디자인 리포지토리에 대한 잘못된 내부 상태로 인한 것으로, 로그에서 오류가 발생하며 이러한 디자인 리포지토리에 대한 검증 작업이 실패했다는 상태로 보고됩니다. 프로젝트를 가져오지 않은 경우에도 이 문제에 영향을 받을 수 있습니다.
    • 영향을 받는 버전: GitLab 버전 16.1.0 - 16.1.2
    • 문제가 수정된 버전: GitLab 16.1.3 이후
  • 새로운 작업 artifact는 direct_upload가 활성화되어 있고 작업 artifact가 객체 저장소에 저장되도록 구성된 경우 Geo에 의해 복제되지 않습니다. 이 버그는 GitLab 버전 16.1.4, 16.2.3, 16.3.0 등에서 수정되었습니다.
    • 영향을 받는 버전: GitLab 버전 16.1.0 - 16.1.3 및 16.2.0 - 16.2.2
    • 영향을 받는 버전에서는 복제된 것처럼 보이는 artifact가 실제로는 보조 사이트에서 누락될 수 있습니다. 영향을 받는 artifact는 16.1.5, 16.2.5, 16.3.1, 16.4.0 이상으로 업그레이드하면 자동으로 재동기화됩니다. 필요한 경우 영향을 받은 작업 artifact를 수동으로 재동기화할 수 있습니다.
    • 보조 사이트에서 완전히 동기화된 상태에서도 기본 사이트에서 LFS 객체를 복제합니다. 자세한 정보 및 해결 방법을 참조하세요.

프로젝트 생성 시 초기화되지 않는 위키 저장소

영향을 받는 작은 릴리스 영향을 받는 패치 릴리스 수정된 버전
15.11 전체 없음
16.0 전체 없음
16.1 16.1.0 - 16.1.2 16.1.3 이후

일부 프로젝트 가져오기는 프로젝트 생성 시 위키 저장소를 초기화하지 않습니다. 프로젝트 위키를 SSF로 마이그레이션한 후로, 누락된 위키 저장소가 실패한 확인으로 잘못 표시됩니다. 실제 복제/확인 실패가 아닌 누락된 저장소에 대한 잘못된 내부 상태로 인한 것이며 이는 Geo 내부의 이러한 누락된 저장소에 대한 로그 오류 및 확인 진행 중의 실패한 상태로 이루어집니다. 프로젝트를 가져오지 않은 경우 이 문제에 영향을받지 않습니다.

16.0.0

  • /etc/gitlab/gitlab.rb 파일에 비 ASCII 문자가 있으면 Sidekiq가 충돌합니다. 이슈 412767의 해결 방법을 참조하여 이를 해결할 수 있습니다.
  • Sidekiq 작업은 기본적으로 default 및 mailers 대기열로만 라우팅되며 그 결과로 모든 Sidekiq 프로세스도 이러한 대기열을 듣도록 되어 있어서 모든 대기열에서 작업을 처리합니다. 이 동작은 라우팅 규칙을 구성하지 않은 경우에는 적용되지 않습니다.
  • GitLab Docker 이미지를 실행하려면 Docker 20.10.10 이상이 필요합니다. 이전 버전은 시작 시 오류를 발생시킵니다.

  • Azure 저장소를 사용하는 컨테이너 레지스트리에는 태그가 없는 상태일 수 있습니다. 중단 변경 지침을 따라 이를 해결할 수 있습니다.

  • 보통 PgBouncer가있는 환경의 백업은 GITLAB_BACKUP_로 접두어가 지정된 변수를 설정하여 PgBouncer를 우회해야합니다. 그러나 이 문제로 gitlab-backup은 오버라이드에 정의 된 직접 연결 대신 PgBouncer를 통해 일반 데이터베이스 연결을 사용하며 데이터베이스 백업에 실패합니다. 해결 방법은 pg_dump를 직접 사용하는 것입니다.

    영향을 받는 릴리스:

    영향을 받는 작은 릴리스 영향을 받는 패치 릴리스 수정된 버전
    15.11 전체 없음
    16.0 전체 없음
    16.1 전체 없음
    16.2 전체 없음
    16.3 전체 없음
    16.4 전체 없음
    16.5 전체 없음
    16.6 전체 없음
    16.7 16.7.0 - 16.7.6 16.7.7
    16.8 16.8.0 - 16.8.3 16.8.4

리눅스 패키지 설치

리눅스 패키지 설치에 특정 정보가 적용됩니다:

만료되지 않는 액세스 토큰

만료 날짜가 없는 액세스 토큰은 암호가 노출되었을 때 보안 리스크가 발생합니다.

GitLab 16.0 이상으로 업그레이드하면 만료 날짜가 없는 개인, 프로젝트, 또는 그룹 액세스 토큰에 자동으로 업그레이드된 날짜가 적용됩니다.

이 자동 만료일이 적용되기 전에 다음을 수행하여 중단을 최소화해야합니다:

  1. 만료 날짜가 지정되지 않은 액세스 토큰을 식별.
  2. 해당 토큰에 만료 날짜를 지정.

자세한 정보는 다음을 참조하세요.

Geo 설치

Tier: 프리미엄, 얼티메이트 Offering: Self-managed

Geo를 사용하는 설치에 적용되는 특정 정보:

  • 프로젝트 가져오기 중에 일부 프로젝트가 웹 위키 저장소를 프로젝트 생성 시에 초기화하지 않습니다. 세부 정보 및 해결 방법을 참조하세요.
  • 보조 사이트에서 LFS 객체를 복제할 때 보조 사이트가 완전히 동기화되었더라도 기본 사이트에서 다운로드됩니다. 세부 정보 및 해결 방법을 참조하세요.

Gitaly 구성 구조 변경

리눅스 패키지의 Gitaly 구성 구조가 GitLab 16.0부터 변경되어 자체 컴파일된 설치에서 사용되는 Gitaly 구성 구조와 일관성을 유지합니다.

이 변경으로 인해 gitaly['configuration'] 하위에 단일 해시가 대부분의 Gitaly 구성을 보유하게 됩니다. 일부 gitaly['..'] 구성 옵션은 GitLab 16.0 이후에도 계속 사용됩니다:

  • enable
  • dir
  • bin_path
  • env_directory
  • env
  • open_files_ulimit
  • consul_service_name
  • consul_service_meta

기존 구성을 새 구조로 이동하여 마이그레이션하세요. git_data_dirs는 GitLab 17.0까지 지원됩니다. 새 구조는 GitLab 15.10부터 지원됩니다.

새 구조로 마이그레이션

경고: Gitaly 클러스터를 실행 중인 경우, 먼저 Praefect를 새 구성 구조로 마이그레이션하세요. 이 변경이 테스트된 후 Gitaly 노드를 진행하세요. Gitaly가 구성 구조 변경의 일환으로 잘못 구성된 경우, 저장소 검증이 Gitaly 클러스터 작동에 필요한 메타데이터를 삭제합니다.(https://gitlab.com/gitlab-org/gitaly/-/issues/5529). 구성 오류를 방지하려면 Praefect에서 일시적으로 저장소 검증을 비활성화하세요.

  1. Gitaly 클러스터를 실행 중인 경우, 모든 Praefect 노드에서 저장소 검증이 비활성화되었는지 확인하세요. verification_interval: 0을 구성하고 gitlab-ctl reconfigure로 적용하세요.
  2. 구성에 새 구조를 적용하세요:
    1. ...을 이전 키의 값으로 바꾸세요.
    2. git_data_dirs를 대체하기 위해 storage를 구성할 때, path의 값에 /repositories를 추가하세요. 이 단계를 완료하지 않으면 구성이 수정될 때까지 Git 저장소에 액세스할 수 없게 됩니다. 이러한 잘못된 구성으로 메타데이터가 삭제될 수 있습니다.
    3. 이전에 값을 구성하지 않은 키는 건너뛰세요.
    4. 추천: 모든 해시 키에 후행 쉼표를 포함하여 키가 재정렬되거나 추가 키가 추가되어도 해시가 유효하도록 하세요.
  3. gitlab-ctl reconfigure로 변경 사항을 적용하세요.
  4. GitLab에서 Git 저장소 기능을 테스트하세요.
  5. 마이그레이션 후 구성에서 이전 키를 제거한 후 gitlab-ctl reconfigure를 다시 실행하세요.
  6. Gitaly 클러스터를 실행 중이라면 추천: Praefect 저장소 검증을 복원하세요. verification_interval: 0을 제거하세요.

새 구조는 이하에서 설명된 대로 기술 되어 있으며, 구조 변경과 관련된 이전 키가 새 키 위에 주석으로 설명되어 있습니다.

경고: storage를 업데이트한 것을 다시 한 번 확인하세요. path의 값에 /repositories를 추가해야 합니다. 

gitaly['configuration'] = {
  # gitaly['socket_path']
  socket_path: ...,
  # gitaly['runtime_dir']
  runtime_dir: ...,
  # gitaly['listen_addr']
  listen_addr: ...,
  # gitaly['prometheus_listen_addr']
  prometheus_listen_addr: ...,
  # gitaly['tls_listen_addr']
  tls_listen_addr: ...,
  tls: {
    # gitaly['certificate_path']
    certificate_path: ...,
    # gitaly['key_path']
    key_path: ...,
  },
  # gitaly['graceful_restart_timeout']
  graceful_restart_timeout: ...,
  logging: {
    # gitaly['logging_level']
    level: ...,
    # gitaly['logging_format']
    format: ...,
    # gitaly['logging_sentry_dsn']
    sentry_dsn: ...,
    # gitaly['logging_ruby_sentry_dsn']
    ruby_sentry_dsn: ...,
    # gitaly['logging_sentry_environment']
    sentry_environment: ...,
    # gitaly['log_directory']
    dir: ...,
  },
  prometheus: {
    # gitaly['prometheus_grpc_latency_buckets']. 이전 값은 '[0, 1, 2]'와 같은 문자열로 구성되었습니다. 새 값은 [0, 1, 2]와 같은 배열이어야 합니다.
    grpc_latency_buckets: ...,
  },
  auth: {
    # gitaly['auth_token']
    token: ...,
    # gitaly['auth_transitioning']
    transitioning: ...,
  },
  git: {
    # gitaly['git_catfile_cache_size']
    catfile_cache_size: ...,
    # gitaly['git_bin_path']
    bin_path: ...,
    # gitaly['use_bundled_git']
    use_bundled_binaries: ...,
    # gitaly['gpg_signing_key_path']
    signing_key: ...,
    # gitaly['gitconfig']. 이제도 여전히 배열이지만 요소의 유형이 변경되었습니다.
    config: [
      {
        # 이전에 요소에는 'section'과 'subsection'과 함께 'key'가 포함되어 있었지만 이제 'key'만 있어야 합니다. 예를 들어,
        # {section: 'first', subsection: 'middle', key: 'last', value: 'value'}는 {key: 'first.middle.last', value: 'value'}로 변환되어야 합니다.
        key: ...,
        value: ...,
      },
    ],
  },
  # 저장소는 이전에 gitaly['storage'] 또는 'git_data_dirs'를 통해 구성할 수 있었습니다. 관련 구성을 아래 지침에 따라 마이그레이션하세요.
  # 'git_data_dirs'의 경우, 'path'만 gitaly['configuration']로 마이그레이션하고 나머지는 그대로 둬야 합니다.
  storage: [
    {
      # gitaly['storage'][<index>]['name']
      #
      # git_data_dirs[<name>]. 저장소 이름은 맵의 키로 구성되었습니다.
      name: ...,
      # gitaly['storage'][<index>]['path']
      #
      # git_data_dirs[<name>]['path']. 'git_data_dirs[<name>]['path']'의 값을 사용하고 '/repositories'를 추가하세요.
      #
      # 예를 들어, 'git_data_dirs'의 경로가 '/var/opt/gitlab/git-data'였다면
      # '/var/opt/gitlab/git-data/repositories'를 사용해야 합니다. '/repositories' 확장이 'git_data_dirs'에 구성된 경로에 자동으로 추가되었습니다.
      path: ...,
    },
  ],
  hooks: {
    # gitaly['custom_hooks_dir']
    custom_hooks_dir: ...,
  },
  daily_maintenance: {
    # gitaly['daily_maintenance_disabled']
    disabled: ...,
    # gitaly['daily_maintenance_start_hour']
    start_hour: ...,
    # gitaly['daily_maintenance_start_minute']
    start_minute: ...,
    # gitaly['daily_maintenance_duration']
    duration: ...,
    # gitaly['daily_maintenance_storages']
    storages: ...,
  },
  cgroups: {
    # gitaly['cgroups_mountpoint']
    mountpoint: ...,
    # gitaly['cgroups_hierarchy_root']
    hierarchy_root: ...,
    # gitaly['cgroups_memory_bytes']
    memory_bytes: ...,
    # gitaly['cgroups_cpu_shares']
    cpu_shares: ...,
    repositories: {
      # gitaly['cgroups_repositories_count']
      count: ...,
      # gitaly['cgroups_repositories_memory_bytes']
      memory_bytes: ...,
      # gitaly['cgroups_repositories_cpu_shares']
      cpu_shares: ...,
    }
  },
  # gitaly['concurrency']. 구조는 동일하지만 배열 요소의 문자 키는 다른 곳처럼 심볼로 바꿔야 합니다. {'key' => 'value'}는 {key: 'value'}로 바뀌어야 합니다.
  concurrency: ...,
  # gitaly['rate_limiting']. 구조는 동일하지만 배열 요소의 문자 키는 다른 곳처럼 심볼로 바꿔야 합니다. {'key' => 'value'}는 {key: 'value'}로 바뀌어야 합니다.
  rate_limiting: ...,
  pack_objects_cache: {
    # gitaly['pack_objects_cache_enabled']
    enabled: ...,
    # gitaly['pack_objects_cache_dir']
    dir: ...,
    # gitaly['pack_objects_cache_max_age']
    max_age: ...,
  }
}

Praefect 구성 구조 변경

Linux 패키지에서의 Praefect 구성 구조가 변경되어 GitLab 16.0에서 self-compiled 설치에 사용되는 Praefect 구성 구조와 일관성을 유지하도록 되었습니다.

이 변경으로 인해 praefect['configuration'] 하위에 단일 해시가 대부분의 Praefect 구성을 보유하게 됩니다. 일부 praefect['..'] 구성 옵션은 GitLab 16.0 이후에도 계속 사용됩니다:

  • enable
  • dir
  • log_directory
  • env_directory
  • env
  • wrapper_path
  • auto_migrate
  • consul_service_name

기존 구성을 새 구조로 이동하여 마이그레이션하세요. 새 구조는 GitLab 15.9부터 지원됩니다.

새 구조로 마이그레이션

경고: 먼저 Praefect를 새 구성 구조로 마이그레이션하세요. 이 변경이 테스트된 후, Gitaly 노드를 계속 진행하세요. 구성 구조 변경의 일부로 Gitaly가 잘못 구성된 경우, 리포지토리 검증 를 통해 Gitaly 클러스터 작동에 필요한 메타데이터가 삭제될 수 있습니다. 구성 오류를 방지하기 위해 Praefect에서 일시적으로 리포지토리 검증을 비활성화하세요.

  1. 구성에 새 구조를 적용할 때:
    • ...을 이전 키의 값으로 대체하세요.
    • 아래에 나와 있는대로 verification_interval: 0을 사용하여 리포지토리 검증을 비활성화하세요.
    • 이전에 값을 구성하지 않은 키는 건너뛰세요.
    • 모든 해시 키에 쉼표를 붙이는 것이 좋습니다. 이렇게 하면 키가 재정렬되거나 다른 키가 추가될 때 해시가 유효한 상태로 유지됩니다.
  2. 변경 내용을 gitlab-ctl reconfigure로 적용하세요.
  3. GitLab에서 Git 리포지토리 기능을 테스트하세요.
  4. 마이그레이션이 완료된 후 이전 키를 구성에서 제거한 다음 gitlab-ctl reconfigure를 다시 실행하세요.

새 구조는 아래에서 설명되며, 이전 키는 새 키 위에 있는 주석으로 설명됩니다. 

praefect['configuration'] = {
  # praefect['listen_addr']
  listen_addr: ...,
  # praefect['socket_path']
  socket_path: ...,
  # praefect['prometheus_listen_addr']
  prometheus_listen_addr: ...,
  # praefect['tls_listen_addr']
  tls_listen_addr: ...,
  # praefect['separate_database_metrics']
  prometheus_exclude_database_from_default_metrics: ...,
  auth: {
    # praefect['auth_token']
    token: ...,
    # praefect['auth_transitioning']
    transitioning: ...,
  },
  logging: {
    # praefect['logging_format']
    format: ...,
    # praefect['logging_level']
    level: ...,
  },
  failover: {
    # praefect['failover_enabled']
    enabled: ...,
  },
  background_verification: {
    # praefect['background_verification_delete_invalid_records']
    delete_invalid_records: ...,
    # praefect['background_verification_verification_interval']
    #
    # 중요:
    # Praefect를 다시 구성하는 일환으로, 이 기능을 비활성화하세요.
    # 위에서 읽어보세요.
    #
    verification_interval: 0,
  },
  reconciliation: {
    # praefect['reconciliation_scheduling_interval']
    scheduling_interval: ...,
    # praefect['reconciliation_histogram_buckets']. 이전 값은 '[0, 1, 2]'와 같이 문자열로 구성되었지만, 새 값은 [0, 1, 2]와 같이 배열이어야 합니다.
    histogram_buckets: ...,
  },
  tls: {
    # praefect['certificate_path']
    certificate_path: ...,
   # praefect['key_path']
    key_path: ...,
  },
  database: {
    # praefect['database_host']
    host: ...,
    # praefect['database_port']
    port: ...,
    # praefect['database_user']
    user: ...,
    # praefect['database_password']
    password: ...,
    # praefect['database_dbname']
    dbname: ...,
    # praefect['database_sslmode']
    sslmode: ...,
    # praefect['database_sslcert']
    sslcert: ...,
    # praefect['database_sslkey']
    sslkey: ...,
    # praefect['database_sslrootcert']
    sslrootcert: ...,
    session_pooled: {
      # praefect['database_direct_host']
      host: ...,
      # praefect['database_direct_port']
      port: ...,
      # praefect['database_direct_user']
      user: ...,
      # praefect['database_direct_password']
      password: ...,
      # praefect['database_direct_dbname']
      dbname: ...,
      # praefect['database_direct_sslmode']
      sslmode: ...,
      # praefect['database_direct_sslcert']
      sslcert: ...,
      # praefect['database_direct_sslkey']
      sslkey: ...,
      # praefect['database_direct_sslrootcert']
      sslrootcert: ...,
    }
  },
  sentry: {
    # praefect['sentry_dsn']
    sentry_dsn: ...,
    # praefect['sentry_environment']
    sentry_environment: ...,
  },
  prometheus: {
    # praefect['prometheus_grpc_latency_buckets']. 이전 값은 '[0, 1, 2]'와 같이 문자열로 구성되었지만, 새 값은 [0, 1, 2]와 같이 배열이어야 합니다.
    grpc_latency_buckets: ...,
  },
  # praefect['graceful_stop_timeout']
  graceful_stop_timeout: ...,
  # praefect['virtual_storages']. 이전 값은 해시 맵이지만, 새 값은 배열입니다.
  virtual_storage: [
    {
      # praefect['virtual_storages'][VIRTUAL_STORAGE_NAME]. 이전에 이름은 'virtual_storages' 해시의 키였습니다.
      name: ...,
      # praefect['virtual_storages'][VIRTUAL_STORAGE_NAME]['nodes'][NODE_NAME]. 이전 값은 해시 맵이었지만, 새 값은 배열입니다.
      node: [
        {
          # praefect['virtual_storages'][VIRTUAL_STORAGE_NAME]['nodes'][NODE_NAME]. 노드 이름 키를 저장소로 사용하세요.
          storage: ...,
          # praefect['virtual_storages'][VIRTUAL_STORAGE_NAME]['nodes'][NODE_NAME]['address'].
          address: ...,
          # praefect['virtual_storages'][VIRTUAL_STORAGE_NAME]['nodes'][NODE_NAME]['token'].
          token: ...,
        },
      ],
    }
  ]
}


### 두 번째 데이터베이스 연결 비활성화

GitLab 16.0에서 GitLab은 기본적으로 동일한 PostgreSQL 데이터베이스를 가리키는 두 개의 데이터베이스 연결을 사용하도록 설정됩니다.

PostgreSQL은 `max_connections`를 위한 더 큰 값으로 구성될 수 있습니다.
[이것이 필요한지 확인하는 Rake 작업](https://docs.gitlab.com/omnibus/settings/database.html#configuring-multiple-database-connections)이 있습니다.

PgBouncer가 배포된 경우:

- PgBouncer 서버의 프론트엔드 풀(파일 핸들 한도 및 `max_client_conn` 포함)는 [더 크게 필요할 수 있습니다](../../administration/postgresql/pgbouncer.md#fine-tuning).
- PgBouncer는 단일 스레드입니다. 추가 연결은 단일 PgBouncer 데몬을 완전히 포화시킬 수 있습니다.
  [모든 확장된 GitLab 배포에 대해 세 개의 로드 밸런스된 PgBouncer 서버를 실행하는 것이 좋습니다](../../administration/reference_architectures/5k_users.md#configure-pgbouncer), 이 문제를 해결하기 위한 일환으로.

설치 형식에 따라 지침을 따라 단일 데이터베이스 연결로 다시 전환하세요:

::Tabs

:::TabTitle Linux 패키지 및 Docker

1. `/etc/gitlab/gitlab.rb`에 이 설정을 추가하세요:

   ```ruby
   gitlab_rails['databases']['ci']['enable'] = false
  1. gitlab-ctl reconfigure를 실행하세요.

다중 노드 환경의 경우, 이 설정은 모든 Rails 및 Sidekiq 노드에서 업데이트되어야 합니다.

Helm 차트 (Kubernetes)

ci.enabled 키를 false로 설정하세요: 

global:
  psql:
    ci:
      enabled: false
자체 컴파일(소스)

config/database.yml에서 ci: 섹션을 제거하세요.

::EndTabs

장기 실행 사용자 유형 데이터 변경

GitLab 16.0은 users 테이블에 많은 레코드가 있는 대형 GitLab 인스턴스를 위한 필수적인 업그레이드입니다.

임계값은 30,000 사용자이며, 이에는 다음이 포함됩니다:

  • 활성, 차단 및 승인 대기 중인 개발자 및 기타 사용자.
  • 프로젝트 및 그룹 액세스 토큰의 봇 계정.

GitLab 16.0은 배치 배경 마이그레이션을 실행하여 user_type 값들을 NULL에서 0으로 마이그레이션합니다. 이 마이그레이션은 큰 GitLab 인스턴스에서 여러 날이 걸릴 수 있습니다. 16.1.0 이상으로 업그레이드하기 전에 마이그레이션이 성공적으로 완료되었는지 확인하세요.

GitLab 16.1은 FinalizeUserTypeMigration 마이그레이션을 소개하여 16.0 MigrateHumanUserType 백그라운드 마이그레이션이 완료되었는지 확인하고, 완료되지 않은 경우 업그레이드 중에 16.0 변경 사항을 동기적으로 실행합니다.

GitLab 16.2는 다음과 같은 NOT NULL 데이터베이스 제약을 구현합니다: 16.0 마이그레이션이 완료되지 않은 경우 실패합니다.

16.0을 건너뛰었거나 (또는 16.0 마이그레이션이 완료되지 않은 경우) 이후 Linux 패키지 (Omnibus) 및 Docker 업그레이드는 1시간 후에 실패할 수 있습니다: 

FATAL: Mixlib::ShellOut::CommandTimeout: rails_migration[gitlab-rails]
[..]
Mixlib::ShellOut::CommandTimeout: Command timed out after 3600s:

이 문제에 대한 fix-forward workaround가 있습니다.

이 임시 방편을 통해 데이터베이스 변경이 완료되는 동안 GitLab은 사용할 수 없는 상태가 되어 500 오류를 생성합니다. 이 오류는 Sidekiq와 Puma가 데이터베이스 스키마와 호환되지 않는 응용 프로그램 코드를 실행시키기 때문에 발생합니다.

임시 방편 프로세스의 끝에 Sidekiq와 Puma가 다시 시작되어 이 문제를 해결합니다.

16.2 이상으로 업그레이드할 때 정의되지 않은 열 오류

GitLab 15.11에서 발생한 버그로 인해 자체 관리형 인스턴스에서 데이터베이스 변화가 잘못 비활성화되었습니다. 자세한 내용은 issue 408835를 참조하세요.

자체 GitLab 인스턴스가 먼저 15.11.0, 15.11.1 또는 15.11.2로 업그레이드될 경우 데이터베이스 스키마가 정확하지 않아 16.2 이상의 GitLab로의 업그레이드가 오류로 실패합니다. 데이터베이스 변경 이전 수정 사항이 필요합니다: 

PG::UndefinedColumn: ERROR:  column "id_convert_to_bigint" of relation "ci_build_needs" does not exist
LINE 1: ...db_config_name:main*/ UPDATE "ci_build_needs" SET "id_conver...

GitLab 15.11.3은 이 버그에 대한 수정을 적용했지만, 이전 15.11 릴리스를 실행 중인 인스턴스에 대한 문제를 해결하지는 않습니다.

인스턴스가 영향을 받는지 확실하지 않으면 다음 쿼리로 해당 열을 확인하세요: 데이터베이스 콘솔에서: 

select pg_typeof (id_convert_to_bigint) from public.ci_build_needs limit 1;

해당 문제의 경우, 이 쿼리가 실패합니다: 

ERROR:  column "id_convert_to_bigintd" does not exist
LINE 1: select pg_typeof (id_convert_to_bigintd) from public.ci_buil...

영향을 받지 않는 인스턴스는 다음과 같은 결과를 반환합니다: 

 pg_typeof
-----------
 bigint

이 문제의 임시 해결은 GitLab 인스턴스의 데이터베이스 스키마에 따라 다릅니다. 대부분의 인스턴스는 15.9 절차를 사용해야 하지만, 매우 새로운 인스턴스만이 15.10 또는 15.11 절차를 요구합니다. 백업 및 복원을 사용하여 GitLab을 마이그레이션한 경우 데이터베이스 스키마는 원본 인스턴스로부터 제공됩니다. 소스 인스턴스에 따라 해당 절차를 선택하세요.

다음 절은 Linux 패키지 설치를 위한 명령이며, 다른 설치 유형에 대해 달라집니다:

Docker
  • sudo 제외

  • GitLab 컨테이너로 쉘을 실행하고 동일한 명령을 실행합니다: 

    docker exec -it <container-id> bash
자체 컴파일(소스)
Helm 차트 (Kubernetes)

Workaround: 15.9 이하에서 생성된 인스턴스 

# 스키마 복원
sudo gitlab-psql -c "DELETE FROM schema_migrations WHERE version IN ('20230130175512', '20230130104819');"
sudo gitlab-rake db:migrate:up VERSION=20230130175512
sudo gitlab-rake db:migrate:up VERSION=20230130104819

# 백그라운드 마이그레이션 재스케줄링
sudo gitlab-rake db:migrate:down VERSION=20230130202201
sudo gitlab-rake db:migrate:down VERSION=20230130110855
sudo gitlab-rake db:migrate:up VERSION=20230130202201
sudo gitlab-rake db:migrate:up VERSION=20230130110855

Workaround: 15.10에서 생성된 인스턴스 

# sent_notifications 스키마 복원
sudo gitlab-psql -c "DELETE FROM schema_migrations WHERE version = '20230130175512';"
sudo gitlab-rake db:migrate:up VERSION=20230130175512

# sent_notifications를 위한 백그라운드 마이그레이션 재스케줄링
sudo gitlab-rake db:migrate:down VERSION=20230130202201
sudo gitlab-rake db:migrate:up VERSION=20230130202201

# ci_build_needs 스키마 복원
sudo gitlab-rake db:migrate:down VERSION=20230321163547
sudo gitlab-psql -c "INSERT INTO schema_migrations (version) VALUES ('20230321163547');"

Workaround: 15.11에서 생성된 인스턴스 

# sent_notifications 스키마 복원
sudo gitlab-rake db:migrate:down VERSION=20230411153310
sudo gitlab-psql -c "INSERT INTO schema_migrations (version) VALUES ('20230411153310');"

# ci_build_needs 스키마 복원
sudo gitlab-rake db:migrate:down VERSION=20230321163547
sudo gitlab-psql -c "INSERT INTO schema_migrations (version) VALUES ('20230321163547');"