GitLab 14 변경 사항

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

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

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

GitLab Helm 차트를 업그레이드하는 자세한 내용은 5.0 릴리스 노트를 참조하십시오.

14.10.0

  • GitLab 14.10으로 업그레이드하기 전에 인스턴스에 최신 14.9.Z가 설치되어 있어야 합니다. GitLab 14.10으로 업그레이드하면 ci_job_artifacts 데이터베이스 테이블에서 불필요한 항목을 동시 인덱스 삭제합니다. 특히 테이블에 트래픽이 많고 마이그레이션이 잠금을 획들지 못하는 경우에는 이 작업이 여러 분 동안 실행될 수 있으므로, 이 프로세스가 완료될 때까지 기다리는 것이 좋습니다. 다시 시작하면 데이터 손실이 발생할 수 있습니다.

  • 외부 PostgreSQL(특히 AWS RDS)에서 GitLab을 실행하는 경우, GitLab 14.8 이상으로 업그레이드하기 전에 PostgreSQL을 최소 12.7 또는 13.3 패치 수준으로 업그레이드해야 합니다. GitLab Enterprise Edition의 경우 14.8에서 및 GitLab Community Edition의 경우 15.0에서 Loose Foreign Keys라는 GitLab 기능이 활성화되었습니다.

    활성화된 후 데이터베이스 엔진 버그로 인해 예상치 못한 PostgreSQL 재시작이 발생하는 보고가 있었습니다. 더 많은 정보는 이슈 364763을 참조하십시오.

  • 패치 수준 14.10.3 이상으로 업그레이드하면, GitLab 14.9에서 완료되지 않은 장기 실행 데이터베이스 데이터 변경으로 인해 1시간 제한 시간 초과가 발생할 수 있습니다. 

    FATAL: Mixlib::ShellOut::CommandTimeout: rails_migration[gitlab-rails] (gitlab::database_migrations line 51) had an error: [..] Mixlib::ShellOut::CommandTimeout: Command timed out after 3600s:

    데이터 변경 및 업그레이드를 수동으로 완료하는 해결 방법이 있습니다.

Linux 패키지 설치

  • GitLab 14.10에서 Gitaly는 새로운 런타임 디렉터리를 도입했습니다. 이 디렉터리는 Gitaly가 올바르게 작동하기 위해 런타임에서 생성해야 하는 모든 파일 및 디렉터리를 보관하는 데 사용됩니다. 예를 들어 내부 소켓, Git 실행 환경 또는 임시 후크 디렉터리 등이 있습니다.

    이 새로운 구성은 gitaly['runtime_dir']을 통해 설정할 수 있습니다. 이는 이전 gitaly['internal_socket_dir'] 구성을 대체합니다. 내부 소켓 디렉터리가 명시적으로 구성되지 않은 경우에는 소켓이 런타임 디렉터리에 생성됩니다.

    gitaly['internal_socket_dir']의 지원은 15.0에서 제거될 예정입니다.

14.9.0

  • GitLab 14.9로 업그레이드로 인해 데이터베이스 변경 사항이 큰 GitLab 인스턴스에서 완료되기까지 몇 시간 또는 몇 일이 걸릴 수 있습니다. 이 일괄 배경 마이그레이션은 projects 테이블의 각 레코드에 대한 namespaces 테이블의 해당 레코드를 업데이트하여 전체 데이터베이스 테이블을 업데이트합니다.

    14.9.0 이상 패치 버전으로 업그레이드하면 일괄 배경 마이그레이션이 완료되어야 하며, 나중에 버전을 업그레이드하기 전에 마이그레이션이 완료되지 않은 채로 업그레이드하려고 하면 다음과 같은 오류가 표시됩니다. 

    예상했던 일괄 배경 마이그레이션이 '완료'로 표시되기를 기대했지만 '활성'으로 표시됩니다:

    또는 

    작업 'bash[migrate gitlab-rails database]'에 대한 '실행' 동작 실행 중 오류 발생 ================================================================================

Mixlib::ShellOut::ShellCommandFailed
------------------------------------
명령 실행 실패. 민감한 리소스에 대한 STDOUT/STDERR가 제거되었습니다.

  • GitLab 14.9.0에는 영원히 대기 중 상태로 남아있을 수 있는 백그라운드 마이그레이션 ResetDuplicateCiRunnersTokenValuesOnProjects이 포함되어 있을 수 있습니다.

    이러한 지연된 작업을 정리하려면 다음을 GitLab 레일즈 콘솔에서 실행하십시오. 

    Gitlab::Database::BackgroundMigrationJob.pending.where(class_name: "ResetDuplicateCiRunnersTokenValuesOnProjects").find_each do |job|
  puts Gitlab::Database::BackgroundMigrationJob.mark_all_as_succeeded("ResetDuplicateCiRunnersTokenValuesOnProjects", job.arguments)
end

  • 외부 PostgreSQL(특히 AWS RDS)에서 GitLab을 실행하는 경우, GitLab 14.8 이상으로 업그레이드하기 전에 PostgreSQL을 최소 12.7 또는 13.3 패치 수준으로 업그레이드해야 합니다. GitLab Enterprise Edition의 경우 14.8에서 및 GitLab Community Edition의 경우 15.0에서 Loose Foreign Keys라는 GitLab 기능이 활성화되었습니다.

    활성화된 후 데이터베이스 엔진 버그로 인해 예상치 못한 PostgreSQL 재시작이 발생하는 보고가 있었습니다. 더 많은 정보는 이슈 364763을 참조하십시오.

Geo 설치

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

14.8.0

  • 14.6.5, 14.7.4 또는 14.8.2 이전 버전에서 업그레이드하는 경우, Critical Security Release: 14.8.2, 14.7.4 및 14.6.5 블로그 게시물을 검토하십시오. 14.8.2 이상으로 업데이트하면 그룹 및 프로젝트의 러너 등록 토큰이 재설정됩니다.

  • Kubernetes를 위한 에이전트 서버는 Omnibus 설치에서 기본적으로 활성화됩니다. GitLab을 대규모로 실행하는 경우, 참조 아키텍처와 같은 서버 유형에서 다음 서버에서 에이전트를 비활성화해야 합니다. 에이전트가 필요하지 않은 경우.

    • Praefect
    • Gitaly
    • Sidekiq
    • Redis(redis['enable'] = true로 구성되었고 roles를 통해 설정되지 않은 경우)
    • 컨테이너 레지스트리
    • GitLab Rails 노드와 같은 roles(['application_role'])에 기반한 기타 서버 유형

    참조 아키텍처가이 구성 변경 및 독립형 Redis 서버를위한 특정 역할로 업데이트되었습니다.

    에이전트 비활성화 단계:

    1. gitlab_kas['enable'] = false를 gitlab.rb에 추가합니다.
    2. 서버가 이미 14.8로 업그레이드되었으면 gitlab-ctl reconfigure를 실행합니다.

  • GitLab 14.8.0에는 pending 상태로 영구적으로 남아있을 수 있는 백그라운드 마이그레이션 PopulateTopicsNonPrivateProjectsCount이 포함되어 있을 수 있습니다.

    이 막혀있는 작업을 정리하려면 GitLab Rails Console에서 다음을 실행하십시오: 

    Gitlab::Database::BackgroundMigrationJob.pending.where(class_name: "PopulateTopicsNonPrivateProjectsCount").find_each do |job|
  puts Gitlab::Database::BackgroundMigrationJob.mark_all_as_succeeded("PopulateTopicsNonPrivateProjectsCount", job.arguments)
end
  • 14.3.0 이전 버전에서 업그레이드하는 경우, 작업 재시도 문제를 피하려면 먼저 GitLab 14.7.x으로 업그레이드하고 모든 일괄 마이그레이션이 완료되었는지 확인합니다.
  • 14.3.0 이상 버전에서 업그레이드하는 경우, BackfillNamespaceIdForNamespaceRoute라는 일괄 배치 마이그레이션에서 실패한 것을 알 수 있습니다. 이를 무시할 수 있습니다. 버전 14.9.x로 업그레이드한 후에 다시 시도하십시오.

  • 외부 PostgreSQL(특히 AWS RDS)에서 GitLab을 실행하는 경우, GitLab 14.8 이상으로 업그레이드하기 전에 PostgreSQL을 최소한 12.7 또는 13.3의 패치 레벨로 업그레이드해야합니다.

    14.8에서는 GitLab Enterprise Edition 및 15.0은 GitLab Community Edition의 기능인 루즈 외래 키가 활성화되었습니다.

    활성화된 후 데이터베이스 엔진 버그로 인해 발생하는 의도하지 않은 PostgreSQL 재시작에 대한 보고서가 있었습니다.

    자세한 내용은 issue 364763을 참조하십시오.

14.7.0

  • 14.6.5, 14.7.4, 또는 14.8.2 이전 버전에서 업그레이드하는 경우 Critical Security Release: 14.8.2, 14.7.4, and 14.6.5 블로그 게시물을 확인하십시오. 14.7.4 이상으로 업데이트하면 그룹 및 프로젝트의 실행자 등록 토큰이 재설정됩니다.

  • GitLab 14.7에서는 Gitaly가 /tmp 디렉토리에 지속 파일을 예상하는 변경이 있었습니다. Gitaly를 실행하는 노드에서 /tmp에 noatime 마운트 옵션을 사용하는 경우 대부분의 Linux 배포판에서 Git 서버 후크가 삭제되는 문제가 발생합니다. 이러한 조건은 기본 Amazon Linux 구성에 있습니다.

    Linux 배포판이 /tmp의 파일을 tmpfiles.d 서비스로 관리하는 경우 tmpfiles.d의 동작을 Gitaly 파일에 대해 재정의하고 이 문제를 피할 수 있습니다: 

    sudo printf "x /tmp/gitaly-%s-*\n" hooks git-exec-path >/etc/tmpfiles.d/gitaly-workaround.conf

    이 문제는 Gitaly runtime directory를 사용하여 지속 파일을 저장할 위치를 지정할 때 GitLab 14.10 이상에서 해결됩니다.

Linux 패키지 설치

  • GitLab 14.8에서 Redis를 6.0.16에서 6.2.6으로 업그레이드합니다. 이 업그레이드는 완전히 하위 호환성이 있는 것으로 예상됩니다.

    인스턴스가 Redis HA(고가용성)를 사용하는 경우 Sentinel로 업그레이드 단계를 따라야합니다. Redis HA (using Sentinel)에 문서화된 업그레이드 단계를 따르십시오.

Geo 설치

Tier: Premium, Ultimate Offering: Self-managed
  • GitLab 14.6.0에서 14.7.2까지 LFS 객체 가져오기 및 미러 문제가 있었습니다. Geo가 활성화되어 있는 경우 가져오거나 미러된 프로젝트에 LFS 객체가 저장되지 못합니다. 이 버그는 GitLab 14.8.0에서 수정되었으며 14.7.3으로 백포트되었습니다.

  • GitLab 14.2부터 14.7까지의 문제는 GitLab에서 관리하는 객체 저장소 복제를 사용할 때 Geo에 영향을 미칩니다. 블롭 객체 유형이 동기화에 실패합니다.

    GitLab 14.2부터 검증 실패로 인해 동기화 실패가 발생하고 이러한 객체의 재동기화가 발생합니다.

    객체 저장소에 저장된 파일에 대해 아직 검증이 구현되지 않았기 때문에(자세한 내용은 이슈 13845를 참조하십시오) 모든 객체에 대해 일관되게 실패하는 루프가 발생합니다.

    이 문제를 해결하는 방법에 대한 정보는 Troubleshooting - Failed syncs with GitLab-managed object storage replication를 참조하십시오.

14.6.0

  • 14.6.5보다 이전 버전에서 업그레이드하는 경우 Critical Security Release: 14.8.2, 14.7.4, and 14.6.5 블로그 게시물을 확인하십시오. 14.6.5 이상으로 업데이트하면 그룹 및 프로젝트의 실행자 등록 토큰이 재설정됩니다.

Geo 설치

Tier: Premium, Ultimate Offering: Self-managed
  • GitLab 14.6.0에서 14.7.2까지 LFS 객체 가져오기 및 미러 문제가 있었습니다. Geo가 활성화되어 있는 경우 가져오거나 미러된 프로젝트에 LFS 객체가 저장되지 못합니다. 이 버그는 GitLab 14.8.0에서 수정되었으며 14.7.3으로 백포트되었습니다.

  • GitLab 14.2부터 14.7까지의 문제는 GitLab에서 관리하는 객체 저장소 복제를 사용할 때 Geo에 영향을 미칩니다. 블롭 객체 유형이 동기화에 실패합니다.

    GitLab 14.2부터 검증 실패로 인해 동기화 실패가 발생하고 이러한 객체의 재동기화가 발생합니다.

    객체 저장소에 저장된 파일에 대해 아직 검증이 구현되지 않았기 때문에(자세한 내용은 이슈 13845를 참조하십시오) 모든 객체에 대해 일관되게 실패하는 루프가 발생합니다.

    이 문제를 해결하는 방법에 대한 정보는 Troubleshooting - Failed syncs with GitLab-managed object storage replication를 참조하십시오.

14.5.0

  • 워크호스와 기탈리 간의 연결은 기본적으로 Gitaly backchannel 프로토콜을 사용합니다. 워크호스와 기탈리 사이에 gRPC 프록시를 배포했다면, 워크호스는 더 이상 연결할 수 없습니다. 해결책으로 임시 workhorse_use_sidechannel 기능 플래그를 비활성화하세요. 워크호스와 기탈리 사이에 프록시가 필요한 경우 TCP 프록시를 사용하세요. 이 변경에 대한 피드백이 있다면, 해당 이슈로 이동하세요.

  • 14.1 버전에서는 병합 요청(diff 커밋)을 저장하는 방식을 변경하는 백그라운드 마이그레이션을 소개했으며, 이를 통해 필요한 저장 공간을 크게 줄였습니다. 14.5에서는 이 프로세스를 마무리하는 일련의 마이그레이션을 소개하여, merge_request_diff_commits 테이블에 남아 있는 모든 작업이 완료되도록 합니다. 대부분의 경우에 이미 이러한 작업이 처리되어 있으므로 14.5로의 업그레이드 시 추가 시간이 필요하지 않습니다. 그러나 남은 작업이 있거나 14.1로 업그레이드하지 않았다면, 배포하는 데 여러 시간이 걸릴 수 있습니다.

    모든 병합 요청 diff 커밋은 이러한 변경을 자동으로 반영하며, 업그레이드를 수행하기 위한 추가 요구 사항은 없습니다. merge_request_diff_commits 테이블의 기존 데이터는 VACUUM FULL merge_request_diff_commits를 실행할 때까지 압축되지 않은 상태로 유지됩니다. 그러나 VACUUM FULL 작업은 전체 merge_request_diff_commits 테이블을 잠그고 다시 작성하기 때문에 이 작업이 완료될 때까지 이 테이블에 대한 액세스가 차단됩니다. 이 명령은 GitLab이 활발하게 사용되지 않을 때 또는 프로세스 기간 동안 오프라인 상태일 때만 실행하는 것이 좋습니다. 완료에 걸리는 시간은 select pg_size_pretty(pg_total_relation_size('merge_request_diff_commits'));를 사용하여 얻을 수 있는 테이블의 크기에 따라 다릅니다.

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

  • GitLab 14.5.0에는 UpdateVulnerabilityOccurrencesLocation 백그라운드 마이그레이션이 포함되어 있는데, 해당 마이그레이션의 대상과 일치하는 레코드가 없는 인스턴스에서 해당 작업이 영구적으로 대기 중 상태로 남을 수 있습니다.

    해당 작업을 정리하려면, GitLab 레일즈 콘솔에서 다음을 실행하세요: 

    Gitlab::Database::BackgroundMigrationJob.pending.where(class_name: "UpdateVulnerabilityOccurrencesLocation").find_each do |job|
  puts Gitlab::Database::BackgroundMigrationJob.mark_all_as_succeeded("UpdateVulnerabilityOccurrencesLocation", job.arguments)
end

  • 14.5(또는 그 이후)로 업그레이드하면 데이터 변경이 긴 시간이 걸리므로 1시간 제한 시간 초과가 발생할 수 있습니다. 

    FATAL: Mixlib::ShellOut::CommandTimeout: rails_migration[gitlab-rails]
(gitlab::database_migrations line 51) had an error:
[..]
Mixlib::ShellOut::CommandTimeout: Command timed out after 3600s:

    데이터 변경 및 업그레이드를 수동으로 완료하는데 대한 해결책이 있습니다.

  • 실시간 이슈 담당자를 활성화를 위한 일환으로 Action Cable이 기본적으로 활성화되었습니다. 자체 컴파일(소스) 설치의 경우, config/cable.yml 파일이 필요합니다.

    아래 명령을 실행하여 구성하세요: 

    cd /home/git/gitlab
sudo -u git -H cp config/cable.yml.example config/cable.yml

# Debian / Ubuntu 기본 구성을 사용하지 않는 경우 Redis 소켓 경로를 변경하세요
sudo -u git -H editor config/cable.yml

자체 컴파일 설치

  • make를 실행하면, Gitaly 빌드가 이제 루트 디렉토리가 아니라 _build/bin에 생성됩니다. 자체 컴파일 설치를 사용하는 경우, 시스템디 유닛 파일 또는 init 스크립트에서 이진 파일의 경로를 업데이트하세요. 이에 따른 문서를 참고하여 업데이트하세요.

Geo 설치

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

14.4.4

  • 별도의 Web 및 API 노드가 있는 GitLab 클러스터에서 제로 다운타임 업그레이드를 위해서는 GitLab Web 노드를 14.4로 업그레이드하기 전에 paginated_tree_graphql_query 기능 플래그를 활성화해야 합니다. 이는 우리가 14.4에서 기본적으로 paginated_tree_graphql_query를 활성화했기 때문입니다, 따라서 GitLab UI가 14.4에 있고 해당 API가 14.3에 있으면 프론트엔드에서는 이 기능이 활성화되지만 백엔드에서는 비활성화됩니다. 이로 인해 다음과 같은 오류가 발생합니다: 

    bundle.esm.js:63 Uncaught (in promise) Error: GraphQL error: Field 'paginatedTree' doesn't exist on type 'Repository'

14.4.1 및 14.4.2

Geo 설치

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

14.4.0

Linux 패키지 설치

  • GitLab 14.4에서 제공되는 Grafana 버전은 7.5입니다. 이는 Grafana 8.1 버전에서 Grafana 8.1 버전으로 변경된 것입니다. GitLab 14.3에 소개된 것보다 후퇴한 것입니다. 이것은 더 최신의 AGPL 라이센스가 적용된 릴리스의 영향을 고려할 시간을 확보하기 위해 Apache 라이센스가 적용된 Grafana 릴리스로 되돌린 것입니다.

    플러그인이나 라이브러리 패널로 Grafana 설치를 사용자화한 사용자는 후퇴 이후에 Grafana에서 오류를 경험할 수 있습니다. 만약 오류가 계속해서 발생한다면, Grafana를 다시 시작한 후에 Grafana 데이터베이스를 재설정하고 사용지정들을 다시 추가해야 합니다. Grafana 데이터베이스는 sudo gitlab-ctl reset-grafana로 재설정할 수 있습니다.

Geo 설치

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

  • GitLab 14.2부터 14.7에 걸친 문제가 있으며, GitLab 관리 오브젝트 저장소 복제가 사용되는 경우 Geo에 영향을 미쳐 blob 오브젝트 유형이 동기화에 실패합니다.

    GitLab 14.2부터 검증 실패는 동기화 실패를 의미하며, 이로 인해 이러한 오브젝트들의 재동기화가 발생합니다.

    파일이 객체 저장소에 저장된 경우에는 아직 검증이 구현되지 않았기 때문에(자세한 내용은 이슈 13845 참조) 객체 저장소에 저장된 모든 오브젝트에 대해 일관되게 실패하는 루프가 발생합니다.

    이에 대한 수정 방법은 GitLab 관리 객체 저장소 복제 실패 해결를 참조하세요.

  • GitLab 14.4.0부터 14.4.2에 걸친 문제가 Geo와 크론 작업을 이용하는 다른 기능들에 영향을 줄 수 있습니다. GitLab 14.4.3 이상으로 업그레이드하는 것을 권장합니다.

14.3.0

  • 14.0.0 - 14.0.4에서 실행 중인 인스턴스는 바로 14.2 이상으로 업그레이드해서는 안됩니다.
  • 14.3.Z 이전의 GitLab 14 릴리스에서 14.3.Z로 업그레이드하기 전에 batched background migration을 완료하십시오.

  • GitLab 14.3.0에는 아래 테이블들의 정수 PK를 사용하는 테이블에 대한 기본 키 오버플로우 위험을 해결하기 위한 배포 이후 마이그레이션이 포함되어 있습니다:

    마이그레이션이 무정지 배포의 일환으로 실행될 경우 응용 프로그램 로직과의 Lock 충돌로 실패할 위험이 있으며, 이로 인해 Lock 타임아웃이나 데드락이 발생할 수 있습니다. 각 경우 모두 이러한 마이그레이션은 성공할 때까지 다시 실행해도 안전합니다: 

    # Omnibus GitLab을 위한
sudo gitlab-rake db:migrate

# 소스 설치를 위한
sudo -u git -H bundle exec rake db:migrate RAILS_ENV=production

  • 14.3로 업그레이드한 후, 모든 MigrateMergeRequestDiffCommitUsers 백그라운드 마이그레이션 작업이 GitLab 14.5 이상으로 업그레이드하는 것은 계속하기 전에 완료되었는지 확인하십시오. 특히 GitLab 인스턴스에 큰 merge_request_diff_commits 테이블이 있는 경우 이것은 특히 중요합니다. 보류 중인 MigrateMergeRequestDiffCommitUsers 백그라운드 마이그레이션 작업 수를 PostgreSQL 콘솔(또는 sudo gitlab-psql)을 사용하여 확인할 수 있습니다: 

    select status, count(*) from background_migration_jobs
where class_name = 'MigrateMergeRequestDiffCommitUsers' group by status;

    작업이 완료되면, 데이터베이스 레코드는 0(보류 중)에서 1로 변경됩니다. 얼마 동안 후에도 보류 중인 작업 수가 감소하지 않는다면, MigrateMergeRequestDiffCommitUsers 백그라운드 마이그레이션 작업이 실패한 것일 수 있습니다. Sidekiq 로그에서 오류를 확인할 수 있습니다. shell sudo grep MigrateMergeRequestDiffCommitUsers /var/log/gitlab/sidekiq/current | grep -i error 필요한 경우 GitLab Rails 콘솔에서 MigrateMergeRequestDiffCommitUsers 백그라운드 마이그레이션 작업을 수동으로 시도해 볼 수 있습니다. 이는 Sidekiq를 비동기적으로 사용하거나 Rails 프로세스를 직접 사용하여 수행할 수 있습니다:

  • 비동기적으로 작업을 예약하는 경우 Sidekiq 사용: 
# 첫 번째 실행에 대해서만 1개의 마이그레이션을 시도하십시오. 성공하면 이후 실행에 대한 한도를 늘리십시오.
limit = 1

jobs = Gitlab::Database::BackgroundMigrationJob.for_migration_class('MigrateMergeRequestDiffCommitUsers').pending.to_a

pp "#{jobs.length} jobs remaining"

jobs.first(limit).each do |job|
  BackgroundMigrationWorker.perform_in(5.minutes, 'MigrateMergeRequestDiffCommitUsers', job.arguments)
end

여기에 등록된 작업은 /admin/sidekiq 엔드포인트 URI에서 액세스할 수 있는 Sidekiq 관리자 패널을 통해 모니터링할 수 있습니다.

  • Rails로 이러한 백그라운드 마이그레이션을 동기적으로 실행하는 경우: 
def process(concurrency: 1)
  queue = Queue.new

  Gitlab::Database::BackgroundMigrationJob
    .where(class_name: 'MigrateMergeRequestDiffCommitUsers', status: 0)
    .each { |job| queue << job }

  concurrency
    .times
    .map do
      Thread.new do
        Thread.abort_on_exception = true

        loop do
          job = queue.pop(true)
          time = Benchmark.measure do
            Gitlab::BackgroundMigration::MigrateMergeRequestDiffCommitUsers
              .new
              .perform(*job.arguments)
          end

          puts "#{job.id} finished in #{time.real.round(2)} seconds"
        rescue ThreadError
          break
        end
      end
    end
    .each(&:join)
end

ActiveRecord::Base.logger.level = Logger::ERROR
process

이러한 백그라운드 마이그레이션을 동기적으로 실행할 때, 작업을 처리할 충분한 리소스가 있는지 확인하여야 합니다. 프로세스가 중지된다면, 충분한 메모리가 없기 때문일 가능성이 높습니다. SSH 세션이 일정 시간이 지난 후에 끊어진다면, screen이나 tmux와 같은 터미널 멀티플렉서를 사용하여 이전 코드를 실행해야 할 수도 있습니다.

  • 유지 보수 모드가 활성화된 경우, 사용자는 SSO, SAML 또는 LDAP로 로그인할 수 없습니다.

    유지 보수 모드가 활성화된 후에 로그인한 사용자는 계속해서 로그인할 수 있습니다. 유지 보수 모드를 활성화한 관리자가 세션을 잃게 되면 UI를 통해 유지 보수 모드를 비활성화할 수 없습니다. 그런 경우, API 또는 Rails 콘솔을 사용하여 유지 보수 모드를 해제해야 합니다.

    이 버그는 GitLab 14.5.0에서 수정되었으며, 14.4.3 및 14.3.5로 백포팅되었습니다.

  • LDAP 암호를 사용하는 계정에 대해 2단계 인증(2FA) 설정 시 You must provide a valid current password 오류가 발생할 수 있습니다.

  • 어플리케이션을 시작할 때 I18n::InvalidLocale: :en is not a valid locale 오류가 발생할 경우, 패치 과정을 따르십시오. mr_iid로 122978을 사용하십시오.

자체 컴파일 설치

  • Ruby 2.7.4가 필요합니다. 계속 진행하는 방법은 루비 설치 지침을 참조하십시오.

Geo 설치

Tier: 프리미엄, 얼티밋 Offering: Self-Managed

  • GitLab 14.2에서 14.7까지 오류가 있습니다 Geo에 영향을 미치는 문제가 있습니다. GitLab이 관리하는 객체 저장소 복제를 사용하는 경우 blob 객체 유형이 동기화에 실패합니다.

    GitLab 14.2부터 검증 실패로 인해 동기화 실패가 발생하고 이러한 객체들의 재동기화를 야기합니다.

    파일 저장소에 저장된 파일에 대한 아직 검증이 구현되지 않았기 때문에(issue 13845에서 자세한 내용을 확인하세요), 이것은 파일 저장소에 저장된 모든 객체에 대해 일관되게 실패하는 루프로 이어집니다.

    이 문제를 해결하는 방법에 대한 정보는 문제 해결 - GitLab이 관리하는 객체 저장소 복제를 통한 동기화 실패를 참조하십시오.

  • 다중 아키텍처 이미지를 사용하는 경우, 컨테이너 레지스트리 복제가 완전히 작동하지 않는 문제를 발견했습니다. 다중 아키텍처 이미지의 경우, 기본 아키텍처(예: amd64)만 보조 사이트로 복제됩니다. 이는 GitLab 14.3에서 수정되었으며 14.2 및 14.1로 다시 이식되었지만 수동 단계가 필요하여 강제로 다시 동기화해야 합니다.

    영향을 받는지 확인하려면 다음 명령을 실행할 수 있습니다: 

    docker manifest inspect <SECONDARY_IMAGE_LOCATION> | jq '.mediaType'

    여기서 <SECONDARY_IMAGE_LOCATION>은 보조 사이트의 컨테이너 이미지입니다. 출력이 application/vnd.docker.distribution.manifest.list.v2+json과 일치하는 경우(여러 수준에서 mediaType 항목이 있을 수 있지만 우리는 최상위 항목에만 관심이 있습니다), 아무 작업을 수행할 필요가 없습니다.

    그렇지 않으면 각 보조 사이트에 대해 레일즈 애플리케이션 노드에서 레일즈 콘솔을 열고 다음을 실행하십시오: 

     list_type = 'application/vnd.docker.distribution.manifest.list.v2+json'

 Geo::ContainerRepositoryRegistry.synced.each do |gcr|
   cr = gcr.container_repository
   primary = Geo::ContainerRepositorySync.new(cr)
   cr.tags.each do |tag|
     primary_manifest = JSON.parse(primary.send(:client).repository_raw_manifest(cr.path, tag.name))
     next unless primary_manifest['mediaType'].eql?(list_type)

     cr.delete_tag_by_name(tag.name)
   end
   primary.execute
 end

    14.1 이전 버전을 사용하고 있으며 컨테이너 레지스트리에 Geo 및 다중 아키텍처 컨테이너를 사용하는 경우, 적어도 GitLab 14.1로 업그레이드하는 것을 권장합니다.

14.2.0

지오 설치

세부 정보: 티어: 프리미엄, 얼티메이트 오퍼링: 셀프 매니지드

  • GitLab 14.2부터 14.7에서 문제가 발생하는데, 이는 GitLab 관리형 객체 저장소 복제를 사용할 때 Geo에 영향을 미치며, blob 객체 유형이 동기화에 실패합니다.

    GitLab 14.2부터 확인 실패로 동기화 실패가 발생하며 이러한 객체의 재동기화를 유발합니다.

    파일 저장소에 저장된 파일에 대한 확인이 아직 구현되지 않았기 때문에(자세한 내용은 이슈 13845 참조), 이는 객체 저장소에 저장된 모든 객체에 대해 일관되게 실패하는 루프로 이어집니다.

    이에 대한 해결 방법은 GitLab 관리형 객체 저장소 복제 실패를 참조하세요.

  • 멀티 아키텍처 이미지를 사용하는 경우 컨테이너 레지스트리 복제가 완전히 작동하지 않는 문제를 발견했습니다. 멀티 아키텍처 이미지의 경우 주 아키텍처(예: amd64)만 보조 사이트로 복제됩니다. 이는 GitLab 14.3에서 수정되었으며 14.2 및 14.1로 되감아졌지만 수동 단계가 필요하여 강제로 재동기화를 해야 합니다.

    영향을 받는지 확인하려면 다음을 실행하세요: 

    docker manifest inspect <SECONDARY_IMAGE_LOCATION> | jq '.mediaType'

    여기서 <SECONDARY_IMAGE_LOCATION>은 보조 사이트의 컨테이너 이미지입니다. 출력이 application/vnd.docker.distribution.manifest.list.v2+json과 일치하면(여러 수준에 mediaType 항목이 있을 수 있으며, 우리가 관심 있는 것은 최상위 항목입니다) 아무 작업도 필요하지 않습니다.

    그렇지 않은 경우, 각 보조 사이트에 대해 Rails 응용 프로그램 노드에서 Rails 콘솔을 열고 다음을 실행하세요: 

    list_type = 'application/vnd.docker.distribution.manifest.list.v2+json'

Geo::ContainerRepositoryRegistry.synced.each do |gcr|
  cr = gcr.container_repository
  primary = Geo::ContainerRepositorySync.new(cr)
  cr.tags.each do |tag|
    primary_manifest = JSON.parse(primary.send(:client).repository_raw_manifest(cr.path, tag.name))
    next unless primary_manifest['mediaType'].eql?(list_type)

    cr.delete_tag_by_name(tag.name)
  end
  primary.execute
end

    14.1 미만 버전을 실행 중이고 컨테이너 레지스트리에서 Geo와 멀티 아키텍처 컨테이너를 사용하는 경우, 적어도 GitLab 14.1로 업그레이드하는 것을 권장합니다.

14.1.0

  • 14.0.0 - 14.0.4에서 실행 중인 인스턴스는 GitLab 14.2 이상으로 직접 업그레이드하지 말아야 합니다만 14.1.Z로 업그레이드할 수 있습니다.

    14.0.5 (또는 이후)에서 이미 실행 중인 인스턴스는 14.1.Z에서 멈출 필요가 없습니다. 14.1은 자체 관리형 설치의 가장 넓은 호환성을 위해 업그레이드 경로에 포함되어 있으며, 14.0.0-14.0.4 인스턴스가 일괄 배경 마이그레이션 문제를 만나지 않도록 보장합니다.

  • GitLab을 14.5 (또는 이상)으로 업그레이드하면, 적어도 14.1로 업그레이드하지 않으면 매우 오랜 시간이 걸릴 수 있습니다. 14.1 머지 요청 디프 커밋 데이터베이스 마이그레이션이 실행하는 데 몇 시간이 걸릴 수 있지만, GitLab을 사용하는 동안 백그라운드에서 실행됩니다. 14.0에서 14.5 또는 그 이상으로 직접 업그레이드된 GitLab 인스턴스는 마이그레이션을 전경에서 실행해야 하므로 완료하는 데 훨씬 더 오래 걸립니다.

  • 유지 관리 모드를 활성화하면 사용자가 SSO, SAML 또는 LDAP로 로그인할 수 없습니다.

    유지 관리 모드가 활성화되기 전에 로그인한 사용자는 계속 로그인되어 있습니다. 유지 관리 모드를 활성화한 관리자가 세션이 끊기면 UI를 통해 유지 관리 모드를 비활성화할 수 없습니다. 이 경우, API 또는 Rails 콘솔을 통해 유지 관리 모드를 비활성화할 수 있습니다.

    이 버그는 GitLab 14.5.0에서 수정되었으며 14.4.3 및 14.3.5로 되감아졌습니다.

  • 응용 프로그램을 시작할 때 I18n::InvalidLocale: :en is not a valid locale 오류가 발생하는 경우 패치 프로세스를 따르세요. mr_iid로 123475를 사용합니다.

지리적 설치

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

  • 멀티-아키텍쳐 이미지를 사용하는 경우 컨테이너 레지스트리 복제에 관한 이슈를 발견했습니다. 멀티-아키텍처 이미지를 사용하는 경우, 기본 아키텍처(예: amd64)만이 보조 사이트로 복제되는 문제가 있었습니다. 멀티-아키텍처 이미지의 경우 14.3의 경우 이 문제가 해결되었으며 14.2 및 14.1로 백포팅되었으나, 수동 단계가 필요하여 재동기화를 강제해야 합니다.

    영향을 받는지 확인하려면 다음을 실행하여 확인할 수 있습니다: 

    docker manifest inspect <보조_이미지_위치> | jq '.mediaType'

    여기서 <보조_이미지_위치>는 보조 사이트에 있는 컨테이너 이미지입니다. 출력이 application/vnd.docker.distribution.manifest.list.v2+json과 일치 하는 경우 (여러 수준에서 mediaType 항목이 있을 수 있지만, 우리는 최상위 항목에만 관심이 있습니다), 그렇다면 아무것도 할 필요가 없습니다.

    그렇지 않은 경우, 각 보조 사이트에 대해 Rails 애플리케이션 노드에서 레일즈 콘솔을 열고 다음을 실행합니다: 

     list_type = 'application/vnd.docker.distribution.manifest.list.v2+json'

 Geo::ContainerRepositoryRegistry.synced.each do |gcr|
   cr = gcr.container_repository
   primary = Geo::ContainerRepositorySync.new(cr)
   cr.tags.each do |tag|
     primary_manifest = JSON.parse(primary.send(:client).repository_raw_manifest(cr.path, tag.name))
     next unless primary_manifest['mediaType'].eql?(list_type)

     cr.delete_tag_by_name(tag.name)
   end
   primary.execute
 end

    버전이 14.1 이전이고 컨테이너 레지스트리에서 Geo 및 멀티-아키텍처 컨테이너를 사용하는 경우, 적어도 GitLab 14.1로 업그레이드하기를 권장합니다.

  • 기본 사이트를 UI에서 제거할 수 없는 이슈를 발견했습니다.

    이 버그는 UI에서만 발생하며 다른 방법을 사용하여 기본 사이트를 제거하는 데는 영향을 미치지 않습니다.

    영향을 받는 버전을 사용하고 기본 사이트를 제거해야 하는 경우, Geo Sites API를 사용하여 수동으로 기본 사이트를 제거할 수 있습니다.

14.0.0

필수 조건:

장기 실행 배치 배경 데이터베이스 마이그레이션:

  • GitLab 14.0으로의 업그레이드에 의한 데이터베이스 변경 사항은 규모가 큰 GitLab 인스턴스에서 몇 시간 또는 며칠이 걸릴 수 있습니다. 이러한 배치 배경 마이그레이션은 기본 키 오버플로우를 완화하기 위해 전체 데이터베이스 테이블을 업데이트하며 14.2 이상으로 업그레이드하기 전에 완료되어야 합니다.

  • 자체 관리형 인스턴스에서 BatchedBackgroundMigrationWorkers가 작동하지 않았던 문제로 인해 14.0.5로 업데이트해야 하는 수정사항이 만들어졌습니다. 이 수정사항은 또한 14.1.0에서도 릴리스되었습니다.

    14.0.5 이상 버전으로 업데이트한 후에는 배치 배경 마이그레이션을 완료해야 합니다으로 14.2 이상 버전으로 업그레이드하기 전에.

    마이그레이션이 완료되지 않고 다른 버전으로 업그레이드하려고 하면 다음과 같은 오류가 표시됩니다: 

    주어진 구성에 대한 배치 배경 마이그레이션이 'finished'로 표시되었을 것을 기대했지만, 'active'로 표시됩니다:

    이 오류를 해결하는 방법을 참조하세요.

기타 문제:

  • GitLab 13.3에서 일부 파이프라인 처리 방법이 폐기되었으며, 이 코드는 GitLab 14.0에서 완전히 제거되었습니다. GitLab 13.2 또는 이전 버전에서 14.0으로 직접 업그레이드하려는 경우, 이는 지원되지 않습니다. 대신 지원되는 업그레이드 경로를 따르는 것이 좋습니다.

  • 유지 보수 모드가 활성화된 경우, 사용자는 SSO, SAML 또는 LDAP로 로그인할 수 없습니다.

    유지 보수 모드가 활성화된 후에 로그인한 사용자는 계속해서 로그인 상태를 유지합니다. 유지 보수 모드를 활성화한 관리자가 세션을 잃으면 UI를 통해 유지 보수 모드를 비활성화할 수 없습니다. 이 경우, API 또는 Rails 콘솔을 통해 유지 보수 모드를 비활성화할 수 있습니다.

    이 버그는 GitLab 14.5.0에서 수정되었으며 14.4.3 및 14.3.5로 백포팅되었습니다.

  • GitLab 13.12.2 이상에서는 비밀번호가 만료된 사용자는 API 및 토큰을 사용하여 인증할 수 없습니다. 만료된 비밀번호 검증 부족 보안 수정으로 인한 문제입니다. 업그레이드 후 사용자가 인증 문제를 겪는 경우, 비밀번호가 만료되지 않았는지 확인하세요:

    1. PostgreSQL 데이터베이스에 연결하고 다음 쿼리를 실행합니다: 

      select id,username,password_expires_at from users where password_expires_at < now();

    2. 사용자가 반환된 목록에 있는 경우 해당 사용자의 password_expires_at를 재설정하세요: 

      update users set password_expires_at = null where username='<사용자명>';

Linux 패키지 설치

  • PostgreSQL 11 및 repmgr의 이진 파일이 제거되었습니다. 업그레이드 전에 다음을 수행해야 합니다.
    1. PostgreSQL 12를 사용하는지 확인합니다.
    2. repmgr을 사용 중이라면, Patroni를 사용하도록 변환해야 합니다.

  • GitLab 13.0에서 sidekiq-cluster가 기본으로 활성화되었으며 sidekiq 서비스는 내부에서 sidekiq-cluster를 실행했습니다. 그러나 사용자는 sidekiq['cluster'] 설정을 사용하여 이 동작을 제어할 수 있었으며 Sidekiq를 직접 실행하도록 설정할 수도 있었습니다. 또한 사용자는 gitlab.rb에서 사용 가능한 다양한 sidekiq_cluster[*] 설정을 사용하여 sidekiq-cluster를 별도로 실행할 수도 있었습니다. 그러나 이러한 기능은 폐기되었으며 이제 제거되었습니다.

    GitLab 14.0부터 sidekiq-cluster가 Linux 패키지 설치에서 Sidekiq를 실행하는 유일한 방법이 됩니다. 이 과정의 일환으로, gitlab.rb의 다음 설정 지원이 제거됩니다.

    • sidekiq['cluster'] 설정. 이제 Sidekiq는 반드시 sidekiq-cluster를 통해 실행되어야 합니다.
    • sidekiq_cluster[*] 설정. 해당 설정은 각각의 sidekiq[*] 상대 설정을 통해 설정해야 합니다.
    • sidekiq['concurrency'] 설정. 이제 두 설정 sidekiq['min_concurrency'] 및 sidekiq['max_concurrency']을 사용하여 제어해야 합니다.

  • GitLab 13.0에서 Puma가 GitLab의 기본 웹 서버가 되었지만 필요에 따라 사용자는 여전히 Unicorn을 계속 사용할 수 있었습니다. 그러나 GitLab 14.0부터는 Unicorn이 GitLab의 웹 서버로 더 이상 지원되지 않으며 Linux 패키지에 포함되지 않습니다.

    사용자는 GitLab 14.0으로 업그레이드하기 위해 문서에 따라 Puma로 마이그레이션해야 합니다.

  • Geo 및 multi-node PostgreSQL 설치용 Consul 버전이 1.6.10에서 1.9.6으로 업데이트되었습니다. Consul 노드를 하나씩 업그레이드하고 다시 시작해야 합니다.

    자세한 내용은 Consul 노드 업그레이드를 참조하세요.

  • GitLab 14.0부터 GitLab은 초기 관리자 사용자(root)의 비밀번호를 자동으로 생성하고 이 값을 /etc/gitlab/initial_root_password에 저장합니다.

    자세한 내용은 초기 비밀번호 설정을 참조하세요.

  • Redis의 두 구성 옵션이 GitLab 13에서 폐기되었으며 GitLab 14에서 제거되었습니다.

    • redis_slave_role이 redis_replica_role로 대체되었습니다.
    • redis['client_output_buffer_limit_slave']가 redis['client_output_buffer_limit_replica']로 대체되었습니다.

    gitlab.rb에서 여전히 redis_slave_role을 참조하는 Redis Cache 노드가 GitLab 13.12에서 14.0으로 업그레이드되면 gitlab-ctl reconfigure의 출력에서 오류가 발생합니다: 

    There was an error running gitlab-ctl reconfigure:

The following invalid roles have been set in 'roles': redis_slave_role

Geo 설치

Tier: Premium, Ultimate Offering: 자체 관리

  • 프라이머리 사이트를 UI에서 제거할 수 없는 문제를 발견했습니다.

    이 버그는 UI에서만 발생하며 다른 방법을 사용하여 프라이머리 사이트를 제거하는 데는 문제가 없습니다.

    영향을 받는 버전을 실행 중이고 프라이머리 사이트를 제거해야 하는 경우 Geo Sites API를 사용하여 수동으로 프라이머리 사이트를 삭제할 수 있습니다.

14.Y 이후 버전으로 업그레이드