GitLab 16 변경 사항

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

이 페이지에는 GitLab 16의 마이너 및 패치 버전 업그레이드 정보가 포함되어 있습니다.

  • 귀하의 설치 유형을 검토하십시오.
  • 현재 버전과 대상 버전 사이의 모든 버전을 검토하십시오.

GitLab Helm Chart 업그레이드에 대한 더 많은 정보는 7.0의 릴리스 노트를 참조하십시오.

15.11에서 업그레이드할 때 주의해야 할 문제

  • PostgreSQL 12는 GitLab 16부터 지원되지 않습니다. GitLab 16.0 이상으로 업그레이드하기 전에 PostgreSQL을 최소 13.6 버전으로 업그레이드하십시오.
  • GitLab 인스턴스가 먼저 15.11.0, 15.11.1 또는 15.11.2로 업그레이드된 경우 데이터베이스 스키마가 잘못되었습니다.
    업그레이드하기 전에 우회 방법을 수행하십시오.
  • 16.0부터 GitLab 자체 관리 설치에서는 기본적으로 이제 하나가 아닌 두 개의 데이터베이스 연결이 있습니다. 이 변경으로 PostgreSQL 연결 수가 두 배로 늘어납니다. 이는 GitLab.com과 유사한 방식으로 동작하게 하며, GitLab 자체 관리 버전의 CI 기능을 위한 별도의 데이터베이스를 활성화하는 단계입니다. 16.0으로 업그레이드하기 전에 PostgreSQL의 최대 연결 수를 늘릴 필요가 있는지 확인하십시오.

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

    일부 GitLab 설치는 사용되는 기능과 환경의 크기에 따라 이러한 중간 버전에서 중지해야 하며:

    • 16.0.8: 사용자 테이블에 많은 레코드가 있는 인스턴스.
      자세한 내용은 오래 실행되는 사용자 유형 데이터 변경을 참조하십시오.
    • 16.1.5: NPM 패키지 레지스트리를 사용하는 인스턴스.
    • 16.2.8: 많은 파이프라인 변수를 가진 인스턴스(이력 파이프라인 포함).

    귀하의 인스턴스가 영향을 받으며 이러한 중간 정지를 건너뛰면:

    • 업그레이드가 완료되는 데 몇 시간이 걸릴 수 있습니다.
    • 모든 데이터베이스 변경이 완료될 때까지 인스턴스가 500 오류를 생성하며, 그 후에
      Puma 및 Sidekiq가 다시 시작되어야 합니다.
    • Linux 패키지 설치의 경우, 시간 초과가 발생하고
      마이그레이션을 완료하기 위한 수동 우회 방법이 필요합니다.

  • GitLab 16.0은 프로젝트 크기에 대한 제한을 강화하는 변경 사항을 도입했습니다. 자체 관리형에서 이러한 제한을 사용하는 경우, 제한에 도달한 프로젝트는 동일한 그룹의 영향을 받지 않는 Git 리포지토리로 푸시할 때 오류 메시지를 발생시킵니다. 오류는 종종 0 바이트 초과를 지칭합니다(limit of 0 B).

    푸시는 성공하지만 오류는 그렇지 않음을 나타내며 자동화에 문제를 일으킬 수 있습니다.
    문제에 대한 더 많은 정보를 읽어보세요.
    버그는 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

리눅스 패키지 설치

  • Gitaly 및 Praefect 구성 구조는 GitLab 16으로 업그레이드하기 전에 변경되어야 합니다.
    데이터 손실을 방지하기 위해 먼저 Praefect를 재구성하고 새로운 구성의 일환으로 메타데이터 검증을 비활성화하세요.
    자세한 내용을 읽어보세요:

  • /var/opt/gitlab/git-data/repositories가 아닌 다른 위치에 Git 데이터를 저장하도록 Gitaly를 재구성하는 경우,
    패키지된 GitLab 16.0 이후에는 자동으로 디렉토리 구조가 생성되지 않습니다.
    자세한 내용과 해결 방법을 읽어보세요.

16.11.0

  • groups_direct 필드가 추가되었습니다
    JSON 웹 토큰(ID 토큰)에.
    • GitLab CI/CD ID 토큰을 사용하여 타사 서비스에 인증하는 경우,
      이 변경은 HTTP 헤더 크기가 증가할 수 있습니다. 프록시 서버는
      헤더가 너무 커지면 요청을 거부할 수 있습니다.
    • 가능하다면 수신 시스템에서 헤더 제한을 늘리세요.
    • 이슈 467253에서 자세한 내용을 참조하세요.
  • GitLab 16.11로 업그레이드한 후 일부 대규모 환경 및 데이터베이스를 가진 사용자들은
    웹 UI에서 소스 코드 페이지 로드 시 타임아웃을 경험합니다.
    • 이러한 타임아웃은 파이프라인 데이터를 위한 느린 PostgreSQL 쿼리로 인해 발생하며, 이는 내부 60초 타임아웃을 초과하게 됩니다.
    • 여전히 Git 리포지토리를 클론할 수 있으며, 리포지토리 데이터에 대한 다른 요청은 정상적으로 작동합니다.
    • 이슈 472420에서 자세한 내용을 참조하세요.
      영향을 받는지 확인하는 단계와 PostgreSQL에서 실행할 유지 관리 작업도 포함되어 있습니다.

리눅스 패키지 설치

GitLab 16.11에서는 PostgreSQL이 자동으로 14.x로 업그레이드되지만, 다음 경우는 제외됩니다:

  • 고가용성을 위해 Patroni를 사용하여 데이터베이스를 운영하고 있습니다.
  • 데이터베이스 노드가 GitLab Geo 구성의 일부입니다.
  • 자동으로 PostgreSQL 업그레이드를 선택 해제하셨습니다.
  • /etc/gitlab/gitlab.rb에 postgresql['version'] = 13이 설정되어 있습니다.

장애 허용 및 Geo 설치는 PostgreSQL 14로 수동 업그레이드를 지원합니다.
HA/Geo 클러스터에 배포된 패키지 PostgreSQL을 참조하세요.

Geo 설치

  • GitLab 16.5에서 도입된 버그로 인해, GitLab 17.0에서 수정된 GitLab Pages 배포 파일이
    2차 Geo 사이트에서 고아 상태가 됩니다. 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부터 GitLab 17.2까지, 누락된 PostgreSQL 인덱스는 높은 CPU 사용량, 느린 작업 아티팩트 검증 진행 및
    느리거나 타임아웃된 Geo 메트릭 상태 업데이트를 초래할 수 있습니다. 인덱스는 GitLab 17.3에서 추가되었습니다.
    인덱스를 수동으로 추가하려면 Geo 문제 해결 - 작업 아티팩트 검증 중 기본에서 높은 CPU 사용량을 참조하세요.

    영향을 받는 릴리스:

    영향을 받는 마이너 릴리스 영향을 받는 패치 릴리스 수정됨
    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;

리눅스 패키지 설치

GitLab 16.10에 대한 리눅스 패키지 설치는 Patroni의 새로운 주요 버전으로 업그레이드합니다. 버전 2.1.0에서 3.0.1로 변경됩니다.

High Availability (HA) (3천 사용자 이상)을 가능하게 하는 참조 아키텍처 중 하나를 사용 중이라면 리눅스 패키지 설치를 위한 PostgreSQL 복제 및 장애 조치를 사용하고 있으며, 여기에 Patroni가 사용됩니다.

이 경우, 다중 노드 인스턴스를 업그레이드하는 방법에 대한 다운타임이 있는 다중 노드 업그레이드를 읽어보세요.

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

Geo 설치

  • GitLab 16.5에서 도입된 버그로 인해 GitLab 17.0에서 수정된 GitLab Pages 배포 파일이 보조 Geo 사이트에서 고아가 되고 있습니다. 페이지 배포가 로컬에 저장되면, 이로 인해 남은 저장공간이 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.9.0

GitLab 16.9.0으로 업그레이드하는 동안 다음 오류가 발생할 수 있습니다:

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

모든 마이그레이션이 완료되었는지 확인하고 모든 Rails 및 Sidekiq 노드를 다시 시작하세요.

이 버그에 대한 수정은 16.9.1에서 릴리즈될 예정입니다.

Geo 설치

  • 컨테이너 복제에서의 버그로 인해 잘못 구성된 2차 노드가 실패한 컨테이너 복제를 성공으로 표시할 수 있습니다. 이후 검증 단계에서 체크섬 불일치로 인해 컨테이너가 실패로 표시됩니다. 우회 방법은 2차 구성 문제를 수정하는 것입니다.
    영향을 받는 릴리즈:

    영향 받는 마이너 릴리즈 영향 받는 패치 릴리즈 수정됨
    모두 모두 16.10.2

  • GitLab 16.5에서 도입된 버그로 인해 개인 스니펫이 2차 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

  • 체크섬 불일치로 인해 기본 사이트와 2차 사이트 간의 일부 컨테이너 레지스트리 이미지에 대한 검증 실패가 발생할 수 있습니다. 이슈 442667에서 자세한 내용을 설명합니다. 데이터가 2차 사이트에 올바르게 복제되고 있지만 성공적으로 검증되지 않기 때문에 데이터 손실 위험은 없습니다. 현재 알려진 우회 방법은 없습니다.

    영향을 받는 릴리즈:

    영향 받는 마이너 릴리즈 영향 받는 패치 릴리즈 수정됨
    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 배포 파일이 2차 Geo 사이트에서 고아가 되고 있습니다. 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

리눅스 패키지 설치

  • 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

Geo 설치

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

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

  • 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

  • 컨테이너 레지스트리 이미지의 일부에서 확인 실패가 발생할 수 있으며, 이는 기본 사이트와 보조 사이트 간의 체크섬 불일치로 인한 것입니다. 문제 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 사이트에 고아로 남아 있습니다. 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.7.0

  • GitLab 16.7은 필수 업그레이드 단계입니다. 이는 GitLab 16.7 및 이전에 도입된 모든 데이터베이스 변경 사항이 모든 자기 관리 인스턴스에 구현되었음을 보장합니다. 이후 종속 변경 사항은 GitLab 16.8 및 이후 버전에서 릴리즈될 수 있습니다. 이슈 429611에는 추가 세부정보가 제공됩니다.

    • 16.6을 업그레이드 경로에서 건너뛰면 GitLab 16.6 릴리즈에서 백그라운드 데이터베이스 마이그레이션을 처리할 때 16.7로 업그레이드 한 후 성능 문제가 발생할 수 있습니다. ci_builds 마이그레이션에 대한 자세한 내용을 16.6.0 업그레이드 노트에서 읽어보세요.

  • 일반적으로 PgBouncer가 있는 환경에서 백업은 변수를 설정하여 PgBouncer를 우회해야 합니다(변수는 GITLAB_BACKUP_로 시작). 그러나 문제로 인해 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.7부터 PostgreSQL 14가 Linux 패키지에 기본적으로 설치되는 버전입니다.

    패키지 업그레이드 중 데이터베이스는 PostgreSQL 14로 업그레이드되지 않습니다.

    PostgreSQL 14로 업그레이드하려면 수동으로 해야 합니다.

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

Geo 설치

  • PostgreSQL 14 버전은 GitLab 16.7 및 이후의 새로운 설치에 기본값입니다. 알려진 문제로 인해 기존 Geo 보조 사이트는 PostgreSQL 14로 업그레이드할 수 없습니다. 자세한 내용은 이슈를 참조하세요.

    모든 Geo 사이트는 동일한 PostgreSQL 버전을 실행해야 합니다. GitLab 16.7에서 16.8.1로 기반한 새로운 Geo 보조 사이트를 추가하려면 구성을 기반으로 다음 조치를 취해야 합니다:

    • 첫 번째 Geo 보조 사이트를 추가 중입니다: 기본 사이트를 PostgreSQL 14로 업그레이드하세요 새로운 Geo 보조 사이트를 설정하기 전에. 기본 사이트가 이미 PostgreSQL 14를 실행 중이라면 특별한 조치는 필요하지 않습니다.

    • 이미 하나 이상의 Geo 보조 사이트가 있는 배포에 새 Geo 보조 사이트를 추가 중입니다:

  • 기본 사이트와 보조 사이트 간의 체크섬 불일치로 인해 일부 프로젝트에서 검증 실패가 발생할 수 있습니다. 세부정보는 이슈에서 추적되고 있습니다. 데이터가 보조 사이트에 올바르게 복제되고 있으므로 데이터 손실 위험은 없습니다. Geo 보조 사이트에서 영향을 받는 프로젝트를 복제하는 사용자는 항상 기본 사이트로 리다이렉션됩니다. 현재 알려진 해결 방법은 없습니다. 우리는 수정 작업을 진행 중입니다.

    영향을 받는 릴리즈:

    영향을 받는 마이너 릴리즈 영향을 받는 패치 릴리즈 수정됨
    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에 도입된 버그로 인해 GitLab Pages 배포 파일이 보조 Geo 사이트에서 고아가 되고 있습니다. 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.6.0

  • GitLab 16.6는 기본 키를 64비트로 업그레이드하는 과정의 일환으로 CI 작업 테이블(ci_builds)의 모든 행을 다시 작성하는 백그라운드 마이그레이션을 소개합니다. ci_builds는 대부분의 GitLab 인스턴스에서 가장 큰 테이블 중 하나이므로, 이 마이그레이션은 합리적인 시간 내에 완료되도록 더 공격적으로 실행됩니다. 백그라운드 마이그레이션은 일반적으로 행 배치 간에 일시 중지되지만, 이 마이그레이션은 중지되지 않습니다.

    이는 셀프 관리 환경에서 성능 문제를 일으킬 수 있습니다:

    • 디스크 I/O가 평소보다 높아집니다. 이는 디스크 I/O가 제한된 클라우드 제공업체에서 호스팅되는 인스턴스에서 특히 문제입니다.
    • 오래된 행(죽은 튜플)이 제거되도록 보장하기 위해 백그라운드에서 Autovacuum이 더 자주 실행될 수 있으며, 기타 관련 유지 관리 작업을 수행합니다.
    • PostgreSQL에서 비효율적인 쿼리 계획이 선택되기 때문에 쿼리가 일시적으로 느리게 실행될 수 있습니다. 이는 테이블의 변경량에 의해 유발될 수 있습니다.

    우회 방법:

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

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

      SET statement_timeout = 0;
VACUUM FREEZE VERBOSE ANALYZE public.ci_builds;
  • GitLab 16.6으로 업그레이드한 후에 오래된 CI 환경 파괴 작업이 생성될 수 있습니다.

  • 일반적으로 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

Geo 설치

  • 체크섬 불일치로 인해 일부 프로젝트에서 검증 실패가 발생할 수 있습니다. 세부 사항은 이 문제에서 추적됩니다. 데이터가 올바르게 복제되고 있으므로 데이터 손실의 위험은 없습니다. 영향을 받는 프로젝트를 Geo 보조 사이트에서 복제하는 사용자는 항상 기본 사이트로 리디렉션됩니다. 현재로서는 알려진 우회 방법이 없습니다. 우리는 해결 작업을 적극적으로 진행하고 있습니다.

    영향을 받는 릴리스:

    영향받는 소규모 릴리스 영향받는 패치 릴리스 수정됨
    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에 도입된 버그로 인해 GitLab 16.5에서 수정된 GitLab Pages 배포 파일이 보조 Geo 사이트에서 고아 상태가 됩니다. Pages 배포가 로컬에 저장된 경우, 이는 남은 스토리지가 0이 되고 subsequently 장애 조치가 발생할 경우 데이터 손실로 이어질 수 있습니다. 문제 및 우회 방법에 대한 자세한 내용은 문제 #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

리눅스 패키지 설치

  • SSH 클론 URL은 /etc/gitlab/gitlab.rb에서 gitlab_rails['gitlab_ssh_host']를 설정하여 사용자 정의할 수 있습니다. 이제 이 설정은 유효한 호스트 이름이어야 합니다. 이전에는 사용자 정의 호스트 이름과 포트를 표시하는 데 사용되는 임의의 문자열일 수 있었습니다.

    예를 들어 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 관리 객체 저장소 복제를 활성화한 경우 영향을 받을 수 있습니다.

    이 문제가 해결될 때까지 객체 저장소 검증을 비활성화하는 우회 방법이 있습니다.

    기본 사이트의 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

  • GitLab 16.3에 Group Wiki 검증이 추가된 후, 유실된 Group Wiki 저장소가 잘못된 검증 실패로 표시되고 있습니다. 이 문제는 실제 복제/검증 실패의 결과가 아니라 Geo 내부의 누락된 저장소에 대한 잘못된 내부 상태로 인해 발생하며, 로그 오류와 이 Group Wiki 저장소에 대한 검증 진행 상황이 실패 상태로 보고되는 결과를 초래합니다.

    문제 및 우회 방법에 대한 자세한 내용은 이슈 #426571에서 참조하세요.

    영향 받는 릴리즈:

    영향 받는 마이너 릴리즈 영향 받는 패치 릴리즈 수정된 릴리즈
    16.3 전체 없음
    16.4 전체 없음
    16.5 16.5.0 - 16.5.1 16.5.2

  • 일부 프로젝트에서 검증 실패가 발생할 수 있으며, 이는 기본 사이트와 보조 사이트 간의 체크섬 불일치로 인해 발생합니다. 세부 정보는 이슈에서 추적되고 있습니다. 데이터 손실 위험은 없으며, 데이터는 보조 사이트로 올바르게 복제되고 있습니다. 영향을 받는 프로젝트를 Geo 보조 사이트에서 클론하는 사용자는 항상 기본 사이트로 리디렉션됩니다. 현재 알려진 우회 방법은 없습니다. 우리는 수정 작업을 적극적으로 진행하고 있습니다.

    영향 받는 릴리즈:

    영향 받는 마이너 릴리즈 영향 받는 패치 릴리즈 수정된 릴리즈
    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에서 도입된 버그로 인해 GitLab Pages 배포 파일이 보조 Geo 사이트에서 고아 상태가 되고 있습니다. Pages 배포가 로컬에 저장되어 있는 경우, 이는 남은 저장 공간이 제로로 줄어들고 결과적으로 장애 조치 발생 시 데이터 손실로 이어질 수 있습니다.

    문제 및 우회 방법에 대한 자세한 내용은 이슈 #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

    오류를 수정하려면, 511자 제한을 초과하는 push_rules 테이블의 레코드를 찾아야 합니다.

    ;; 제약 조건에서 사용된 필드의 이름으로 `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
    "ID #{lr.id}를 가진 푸시 규칙은 프로젝트 #{lr.project.full_name}에 구성되어 있습니다."
  elsif lr.group
    "ID #{lr.id}를 가진 푸시 규칙은 그룹 #{lr.group.full_name}에 구성되어 있습니다."
  else
    "ID #{lr.id}를 가진 푸시 규칙은 인스턴스 수준에 구성되어 있습니다."
  end
end

puts "총 긴 규칙: #{array.count}"
puts array.join("\n")

    영향을 받는 푸시 규칙 레코드의 정규 표현식 필드 값 길이를 줄인 다음, 마이그레이션을 다시 시도하십시오.

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

  • 일반적으로 PgBouncer가 있는 환경에서는 변수를 설정하여 PgBouncer를 우회해야 합니다 변수는 GITLAB_BACKUP_로 접두사가 붙어야 합니다. 하지만 문제로 인해 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 설정을 업데이트하여 비밀 토큰 경로를 설정하세요.

    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에 추가된 후, 누락된 그룹 위키 저장소가 잘못된 검증 실패로 표시되고 있습니다. 이 문제는 실제 복제/검증 실패가 아니라 Geo 내부에서 이러한 누락된 저장소의 잘못된 내부 상태로 인해 발생하며, 로그에 오류를 발생시키고 이러한 그룹 위키 저장소에 대한 검증 진행 상황이 실패 상태로 보고되는 결과를 초래합니다.

    문제 및 해결 방법에 대한 자세한 내용은 이슈 #426571을 참조하세요.

    영향받는 릴리스:

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

  • 기본 사이트와 보조 사이트 간의 체크섬 불일치로 인해 일부 프로젝트에서 검증 실패를 경험할 수 있습니다. 세부 사항은 이 문제에서 추적됩니다. 데이터 손실 위험은 없으며 데이터는 보조 사이트에 올바르게 복제되고 있습니다. 영향을 받는 프로젝트를 Geo 보조 사이트에서 클론하려는 사용자는 항상 기본 사이트로 리다이렉션됩니다. 현재 알려진 해결 방법은 없습니다. 우리는 수정 작업을 활발히 진행하고 있습니다.

    영향받는 릴리스:

    영향받는 마이너 릴리스 영향받는 패치 릴리스 수정된 버전
    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 또는 그 이후로 업데이트하십시오. 이는 GitLab 16.3.3 및 16.3.4에서 데이터베이스 디스크 공간을 과도하게 사용하는 문제 425971을 피하는 데 도움이 됩니다.

  • 데이터베이스 내에서 중복 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: 대형 RSA 키가 포함된 인증서 체인 검증이 느림 (CVE-2023-29409) 은 RSA 키에 대해 8192 비트의 하드 제한을 도입했습니다. GitLab에서 Go 애플리케이션의 맥락에서 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만 행을 처리하는 데 4시간 소요됨), 업그레이드 중 긴 중단 시간을 피하려면 16.3으로 업그레이드하기 전에 마이그레이션이 성공적으로 완료되었는지 확인하십시오.

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

    select count(*) from ci_pipeline_variables;

  • 일반적으로 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

리눅스 패키지 설치

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

  • GitLab 16.0에서 업그레이드된 기본 Docker 이미지를 발표하였으며, 새로운 버전의 OpenSSH Server가 포함되어 있습니다. 새로운 버전의 의도치 않은 결과로 기본적으로 SSH RSA SHA-1 서명을 수용하지 않도록 비활성화합니다. 이 문제는 매우 오래된 SSH 클라이언트를 사용하는 사용자에게만 영향을 미칩니다.

    SHA-1 서명을 사용할 수 없는 문제를 피하기 위해, 사용자는 보안상의 이유로 SHA-1 서명이 권장되지 않기 때문에 SSH 클라이언트를 업데이트해야 합니다.

    사용자들이 즉시 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 이후

    자세한 정보는 이슈 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 이후

    자세한 정보는 이슈 429617를 참조하세요.

  • 이슈와 관련하여 동기화 상태가 보류 상태로 고착되며, 이는 영향을 받는 항목의 복제 중단을 초래하여 장애 조치 시 데이터 손실 위험이 발생할 수 있습니다. 이는 주로 저장소 동기화에 영향을 미치지만 컨테이너 레지스트리 동기화에도 영향을 미칠 수 있습니다. 데이터 손실의 위험을 피하기 위해 수정된 버전으로 업그레이드하는 것이 좋습니다.

  • 체크섬 불일치로 인해 일부 프로젝트에서 검증 실패를 경험할 수 있습니다. 세부사항은 이슈 427493에서 추적됩니다. 데이터는 보조 사이트에 올바르게 복제되고 있으므로 데이터 손실 위험은 없습니다. Geo 보조 사이트에서 영향을 받는 프로젝트를 클론하는 사용자는 항상 주 사이트로 리디렉션됩니다. 알려진 해결방법은 없으며, 수정이 포함된 버전으로 업그레이드해야 합니다.

    영향을 받는 릴리즈:

    영향을 받는 마이너 릴리즈 영향을 받는 패치 릴리즈 수정됨
    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 16.3.0 - 16.3.5 16.3.6
    16.4 16.4.0 - 16.4.1 16.4.2

  • GitLab 16.3에서 그룹 위키 검증이 추가된 후, 누락된 그룹 위키 저장소가 잘못된 검증 실패로 표시되고 있습니다. 이 문제는 실제 복제/검증 실패의 결과가 아니라 Geo 내에서 이 누락된 저장소의 잘못된 내부 상태로 인해 발생하며, 이로 인해 로그에 오류가 발생하고 이 그룹 위키 저장소의 검증 진행이 실패 상태를 보고하게 됩니다.

    문제의 세부사항 및 해결방법은 이슈 #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:  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 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:  check constraint "check_0dd5948e38" of relation "users" is violated by some row

    추가 정보는 문제 421629을 참조하세요.

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

    PG::NotNullViolation: ERROR:  null value in column "source_partition_id" of relation "ci_sources_pipelines" violates not-null constraint

    이 문제를 해결하려면 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의 일환으로 자동으로 재시작되지 않습니다.
    따라서, 사용자는 재구성이 진행된 후 새로운 Redis 버전이 사용되도록 sudo gitlab-ctl restart 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에서는 일괄 백그라운드 마이그레이션이 도입되어 머지 요청 테이블에서 prepared_at 값을 백필하는 기능이 추가되었습니다.
    이 마이그레이션은 더 큰 GitLab 인스턴스에서는 여러 날이 걸릴 수 있습니다.
    16.1.0으로 업그레이드하기 전에 마이그레이션이 성공적으로 완료되었는지 확인하십시오.

  • GitLab 16.1.0은 복제된 NPM 패키지를 파괴하기 위해 마킹하는 일괄 백그라운드 마이그레이션 MarkDuplicateNpmPackagesForDestruction을 포함합니다.
    16.3.0 또는 그 이후 버전으로 업그레이드하기 전에 마이그레이션이 성공적으로 완료되었는지 확인하십시오.

  • BackfillCiPipelineVariablesForBigintConversion 백그라운드 마이그레이션이 EnsureBackfillBigintIdIsCompleted 포스트 배포 마이그레이션과 함께 완료되었습니다.
    GitLab 16.0.0에서는 일괄 백그라운드 마이그레이션이 도입되어 ci_pipeline_variables 테이블에서 bigint id 값을 백필하는 기능이 추가되었습니다.
    이 마이그레이션은 더 큰 GitLab 인스턴스에서 완료되는 데 오랜 시간이 걸릴 수 있습니다(한 경우에는 50백만 행을 처리하는 데 4시간이 걸림).
    장시간의 업그레이드 중단을 피하기 위해 16.1로 업그레이드하기 전에 마이그레이션이 성공적으로 완료되었는지 확인하십시오.

    다음 SQL 명령어를 사용하여 데이터베이스 콘솔에서 ci_pipeline_variables 테이블의 크기를 확인할 수 있습니다:

    select count(*) from ci_pipeline_variables;

Self-compiled installations

  • puma.rb 구성 파일에서 Puma 작업자 킬러와 관련된 모든 설정을 제거해야 합니다.
    이러한 설정은 제거되었습니다.
    자세한 내용은 puma.rb.example 파일을 참조하세요.

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

    영향을 받는 릴리즈:

    영향을 받는 마이너 릴리즈 영향을 받는 패치 릴리즈 수정됨
    15.11 All None
    16.0 All None
    16.1 All None
    16.2 All None
    16.3 All None
    16.4 All None
    16.5 All None
    16.6 All None
    16.7 16.7.0 - 16.7.6 16.7.7
    16.8 16.8.0 - 16.8.3 16.8.4

Geo 설치

상세 정보:

Tier: Premium, Ultimate Offering: Self-managed

Geo를 사용하는 설치에 대한 특정 정보:

  • 일부 프로젝트 가져오기는 프로젝트 생성 시 위키 저장소를 초기화하지 않습니다.
    자세한 내용과 해결 방법을 참조하세요.

  • 프로젝트 디자인의 SSF로의 마이그레이션 때문에,
    누락된 디자인 저장소가 잘못된 검증 실패로 표시되고 있습니다.
    이 문제는 실제 복제/검증 실패의 결과가 아니라 Geo 내에서
    누락된 저장소의 잘못된 내부 상태로 인해 발생하며, 로그에서 오류가 발생하고
    검증 진행 상태가 해당 디자인 저장소에 대해 실패 상태로 보고됩니다.
    프로젝트를 가져오지 않았다면 이 문제의 영향을 받지 않을 수 있습니다.

    • 영향받는 버전: GitLab 버전 16.1.0 - 16.1.2
    • 수정된 버전: GitLab 16.1.3 이상.

  • 작업 아티팩트가 객체 저장소에 저장되도록 구성되고 direct_upload가 활성화된 경우,
    Geo에 의해 새로운 작업 아티팩트가 복제되지 않습니다. 이 버그는 GitLab 버전
    16.1.4, 16.2.3, 16.3.0 및 그 이후에 수정되었습니다.

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

영향을 받는 소수 릴리즈 영향을 받는 패치 릴리즈 수정됨
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 저장소를 사용하는 컨테이너 레지스트리는 태그가 0개인 경우
    비어있을 수 있습니다. 중단 변경 사항 지침을
    따라 이 문제를 해결할 수 있습니다.

  • 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

리눅스 패키지 설치

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

  • PostgreSQL 12의 이진 파일이 제거되었습니다.

    업그레이드 전에, 리눅스 패키지 설치 관리자들은 설치가 PostgreSQL 13를 사용하고 있는지 확인해야 합니다.

  • GitLab과 함께 번들된 Grafana는 사용 중지되었으며 더 이상 지원되지 않습니다. GitLab 16.3에서 제거되었습니다.

  • openssh-server가 1:8.9p1-3으로 업그레이드됩니다.

    이전 OpenSSH 클라이언트와 함께 ssh-keyscan -t rsa를 사용하여 공개 키 정보를 얻는 것은 OpenSSH 8.7 릴리즈 노트에 나열된 사용 중지된 사항 때문에 더 이상 유효하지 않습니다.

    해결 방법은 다른 키 유형을 사용하거나 클라이언트 OpenSSH를 버전 >= 8.7로 업그레이드하는 것입니다.

  • Praefect 구성 구조를 새 구조로 마이그레이션하여 모든 praefect['..'] 설정이 GitLab 16.0 및 이후 버전에서 계속 작동하도록 합니다.

  • Gitaly 구성 구조를 새 구조로 마이그레이션하여 모든 gitaly['..'] 설정이 GitLab 16.0 및 이후 버전에서 계속 작동하도록 합니다.

만료되지 않는 액세스 토큰

만료일이 없는 액세스 토큰은 무한정 유효하며, 이 액세스 토큰이 유출되면 보안 위험이 발생합니다.

GitLab 16.0 및 이후 버전으로 업그레이드하면 만료일이 없는 개인, 프로젝트, 또는 그룹 액세스 토큰에는 자동으로 업그레이드 날짜로부터 1년 후의 만료일이 설정됩니다.

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

  1. 만료일이 없는 액세스 토큰 식별하기.
  2. 그 토큰에 만료일 부여하기.

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

Geo 설치

Tier: Premium, Ultimate Offering: Self-managed

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

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부터 지원됩니다.

새 구조로 마이그레이션하기

caution
Gitaly 클러스터를 실행 중인 경우, Praefect를 새 구성 구조로 먼저 마이그레이션 하세요.
이 변경 사항이 테스트되면 Gitaly 노드로 이동합니다.
구성 구조 변경의 일환으로 Gitaly가 잘못 구성되면, 저장소 검증이
Gitaly 클러스터가 작동하는 데 필요한 메타데이터를 삭제합니다.
구성 오류를 방지하기 위해 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 클러스터를 운영 중인 경우, verification_interval: 0을 제거하여
    Praefect 저장소 검증을 복원합니다.

아래에 새로운 구조가 문서화되어 있으며, 새로운 키 위에 이전 키가 주석으로 설명되어 있습니다.

caution
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에서 변경되었습니다 자체 컴파일 설치에서 사용되는 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]. 저장소로 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 작업이 있습니다.

PgBouncer가 배포된 경우:

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

리눅스 패키지 및 Docker

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

    gitlab_rails['databases']['ci']['enable'] = false

  2. gitlab-ctl reconfigure를 실행하세요.

다중 노드 환경에서는 이 설정을 모든 Rails 및 Sidekiq 노드에서 업데이트해야 합니다.

Helm 차트 (Kubernetes)

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

global:
  psql:
    ci:
      enabled: false
소스에서 자체 컴파일

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

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

GitLab 16.0은 users 테이블에 많은 레코드가 있는 대규모 GitLab 인스턴스의 필수 중단점입니다.

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

  • 활성, 차단 및 승인 대기 중인 모든 상태의 개발자 및 기타 사용자.

  • 프로젝트 및 그룹 액세스 토큰을 위한 봇 계정.

GitLab 16.0은 배치 배경 마이그레이션을 도입하여

NULL에서 0으로의 user_type 값 마이그레이션을 수행합니다. 이 마이그레이션은 더 큰 GitLab 인스턴스에서 완료하는 데 며칠이 걸릴 수 있습니다.

16.1.0 또는 이후 버전으로 업그레이드하기 전에 마이그레이션이 성공적으로 완료되었는지 확인하세요.

GitLab 16.1에서는 FinalizeUserTypeMigration 마이그레이션이 도입되어,

16.0 MigrateHumanUserType 배경 마이그레이션이 완료되도록 하며,

업그레이드 중에 완료되지 않은 경우 16.0 변경 사항이 동기적으로 실행됩니다.

GitLab 16.2는 NOT NULL 데이터베이스 제약 조건을 구현하여,

16.0 마이그레이션이 완료되지 않으면 실패합니다.

16.0이 건너뛰어진 경우(또는 16.0 마이그레이션이 완료되지 않은 경우) 이후의 리눅스 패키지(Omnibus) 및 Docker 업그레이드는 한 시간 후에 실패할 수 있습니다:

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

이 문제에 대한 수정된 우회 방법이 있습니다.

우회 방법이 데이터베이스 변경을 완료하는 동안, GitLab은 사용 불가능 상태일 가능성이 높으며, 500 오류를 생성하게 됩니다. 이 오류는 데이터베이스 스키마와 호환되지 않는 애플리케이션 코드를 실행하는 Sidekiq 및 Puma로 인해 발생합니다.

우회 과정이 끝날 때, Sidekiq와 Puma가 다시 시작되어 이 문제를 해결합니다.

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

GitLab 15.11의 버그로 인해 self-managed 인스턴스에서 데이터베이스 변경 사항이 잘못 비활성화되었습니다.

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

GitLab 인스턴스가 먼저 15.11.0, 15.11.1 또는 15.11.2로 업그레이드된 경우 데이터베이스 스키마가 잘못되어 있으며, GitLab 16.2 이상으로 업그레이드하려고 하면 오류가 발생합니다.

데이터베이스 변경 사항은 이전 수정을 적용해야 합니다:

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.9
15.10 15.10
15.11 15.11

대부분의 인스턴스는 15.9 절차를 사용해야 합니다. 매우 새로운 인스턴스만 15.10 또는 15.11 절차가 필요합니다. 백업 및 복원을 사용하여 GitLab을 마이그레이션한 경우, 데이터베이스 스키마는 원본 인스턴스에서 가져온 것입니다. 원본 인스턴스를 기반으로 우회 방법을 선택하세요.

다음 섹션의 명령은 Linux 패키지 설치용이며, 다른 설치 유형에 따라 다릅니다:

Docker
  • sudo 생략

  • GitLab 컨테이너에 셸로 들어가고 동일한 명령을 실행합니다:

    docker exec -it <container-id> bash
셀프 컴파일(소스)
Helm 차트(쿠버네티스)

해결 방법: 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

해결 방법: 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');"

해결 방법: 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');"