GitLab 14 변경 사항

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

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

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

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

14.10.0

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

  • 특히 AWS RDS와 같은 외부 PostgreSQL에서 GitLab을 실행하는 경우, GitLab 14.8 이상으로 업그레이드하기 전에 PostgreSQL을 12.7 이상 또는 13.3 이상의 패치 수준으로 업그레이드해야 합니다.

    14.8에서는 기업 버전 및 15.0에서는 커뮤니티 버전용으로 GitLab 기능 인 Loose Foreign Keys가 활성화되었습니다.

    이를 활성화한 후 데이터베이스 엔진 버그로 인해 발생하는 정상 종료되지 않은 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 또는 이후 14.9 패치 버전으로 업그레이드한 후에는 일괄 배경 마이그레이션이 완료되어야 합니다. 마이그레이션이 완료되지 않은 상태에서 나중 버전으로 업그레이드하려고 하면 다음과 같은 오류가 표시됩니다. 

    예상된 일괄 배경 마이그레이션이 '활성'으로 표시되어야 하지만 '활성' 상태입니다:

    또는 

    리소스 'bash[migrate gitlab-rails database]'의 `run` 작업 실행 중 오류 발생
==============================================================
  
Mixlib::ShellOut::ShellCommandFailed
------------------------------------
명령 실행 실패. 민감한 리소스의 STDOUT/STDERR이 억제됨

  • GitLab 14.9.0에는 영원히 동작 대기 상태로 남아 있는 배경 마이그레이션 ResetDuplicateCiRunnersTokenValuesOnProjects이 포함되어 있을 수 있습니다.

    이러한 막힌 작업을 정리하려면 GitLab Rails 콘솔에서 다음을 실행하십시오: 

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

  • 특히 AWS RDS와 같은 외부 PostgreSQL에서 GitLab을 실행하는 경우, GitLab 14.8 이상으로 업그레이드하기 전에 PostgreSQL을 12.7 이상 또는 13.3 이상의 패치 수준으로 업그레이드해야 합니다.

    14.8에서는 기업 버전 및 15.0에서는 커뮤니티 버전용으로 GitLab 기능 인 Loose Foreign Keys가 활성화되었습니다.

    이를 활성화한 후 데이터베이스 엔진 버그로 인해 발생하는 정상 종료되지 않은 PostgreSQL 재시작에 대한 보고가 있습니다.

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

Geo 설치

Tier: Premium, Ultimate Offering: Self-managed

  • 반드시 GitLab 14.9.0으로 업그레이드하지 마십시오. 대신, 14.9.1 이상의 버전을 사용하십시오.

    Geo의 CI 확인 기능에 문제가 발견되어 잡 추적이 손실될 수 있습니다. 이 문제는 GitLab 14.9.1 패치 릴리스에서 수정되었습니다.

    이미 GitLab 14.9.0으로 업그레이드한 경우 문제를 일으키는 기능을 비활성화할 수 있습니다.

14.8.0

  • 14.6.5, 14.7.4 또는 14.8.2 이전 버전에서 업그레이드하는 경우, Critical Security Release: 14.8.2, 14.7.4, and 14.6.5 블로그 글을 확인하세요. 14.8.2 이상으로 업데이트하면 그룹과 프로젝트의 runner 등록 토큰이 재설정됩니다.

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

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

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

    에이전트 비활성화 단계:

    1. gitlab.rb에 gitlab_kas['enable'] = false를 추가합니다.
    2. 서버가 이미 14.8로 업그레이드된 경우, gitlab-ctl reconfigure를 실행하세요.

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

    이러한 정체된 작업을 정리하려면, GitLab Rails 콘솔에서 다음을 실행하세요: 

    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로 GitLab을 실행하는 경우, 특히 AWS RDS의 경우, GitLab 14.8 이상으로 업그레이드하기 전에 PostgreSQL을 최소 12.7 또는 13.3 이상으로 패치해야 합니다.

    GitLab Enterprise Edition의 14.8에서 및 GitLab Community Edition의 15.0에서 GitLab 기능인 Loose Foreign Keys가 활성화되었습니다.

    이 기능이 활성화된 후에는 데이터베이스 엔진 버그로 인해 예기치 않은 PostgreSQL 재시작으로 인한 보고가 있었습니다.

    자세한 정보는 이슈 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 이상으로 업데이트하면 그룹과 프로젝트의 runner 등록 토큰이 재설정됩니다.

  • 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

    이 문제는 GitLab 14.10 이상에는 Gitaly 런타임 디렉터리를 사용하여 지속 파일을 저장할 위치를 지정할 때 해결됩니다.

Linux 패키지 설치

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

    인스턴스에 Redis HA가 있는 경우, 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까지 문제가 발생하는 Geo에 영향을 미치는 문제가 있습니다. GitLab-managed 객체 리포지터리 복제가 사용될 때, 검증 실패로 인해 동기화 실패가 발생합니다.

    GitLab 14.2부터 검증 실패가 동기화 실패로 이어지며, 이는 객체 리포지터리에 저장된 파일에 대해 아직 검증이 구현되지 않았기 때문에(이슈 13845에서 자세한 내용 참조) 모든 객체에 대해 일관되게 실패하는 루프를 유발합니다.

    이를 해결하는 방법에 대한 정보는 Troubleshooting - Failed syncs with GitLab-managed object storage replication를 참조하세요.

14.6.0

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

Geo 설치

Tier: Premium, Ultimate Offering: Self-managed
  • GitLab 14.6.0에서 14.7.2로 LFS(objects) 가져오기 및 미러 문제가 있습니다. Geo가 활성화되면 가져오거나 미러링된 프로젝트에 LFS(objects)를 저장할 수 없습니다. 이 버그는 GitLab 14.8.0에서 수정되었으며 14.7.3으로 배포되었습니다.
  • GitLab-관리 오브젝트 스토리지 복제가 사용될 때, GitLab 14.2부터 14.7에 문제가 있음. 이로 인해 Geo에 영향을 미치며 검증 실패로 인해 동기화 실패가 발생합니다. 검증 실패는 아직 객체 리포지터리에 저장된 파일에 대해 구현되지 않았기 때문에 이슈 13845를 참조하여이 문제를 해결해야 합니다.

14.5.0

  • Workhorse와 Gitaly 간의 연결은 기본적으로 Gitaly backchannel 프로토콜을 사용합니다. Workhorse와 Gitaly 사이에 gRPC 프록시를 배포한 경우 Workhorse는 더 이상 연결할 수 없습니다. 해결책으로는 일시적인 workhorse_use_sidechannel feature flag를 비활성화하세요. Workhorse와 Gitaly 사이에 프록시가 필요한 경우 TCP 프록시를 사용하세요. 이 변경 사항에 대한 피드백이 있으면 이 이슈로 이동하세요.

  • 14.1에서는 Merge Request diff 커밋을 저장하는 방식을 변경하는 백그라운드 마이그레이션을 도입하여 저장 공간을 크게 줄였습니다. 14.5에서는이 프로세스를 완료하기 위해 merge_request_diff_commits 테이블에 대한 모든 남아있는 작업을 처리하는 일련의 마이그레이션을 도입했습니다. 대부분의 경우이 작업은 이미 처리되었으므로 업그레이드에 대해 추가 시간이 필요하지 않습니다. 그러나 남아있는 작업이나 14.1로 업그레이드하지 않은 경우 배포에 다수 시간이 소요될 수 있습니다.

  • GitLab 14.5.0에는 백그라운드 마이그레이션 UpdateVulnerabilityOccurrencesLocation이 포함되어 있으며, 해당 마이그레이션의 대상과 일치하는 레코드가 부족한 경우 대기 중 상태로 영원히 남아 있을 수 있습니다. 이러한 스태킹된 작업을 정리하려면 GitLab Rails Console에서 다음을 실행하세요: 

    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: Premium, Ultimate Offering: Self-managed

  • GitLab 14.2부터 14.7까지 GitLab 관리 객체 리포지터리 복제를 사용할 때 Geo에 영향을 주는 문제가 발생하여 blob 객체 유형이 동기화에 실패합니다.

    14.2부터 검증 실패로 인해 동기화 실패가 발생하며, 이로 인해 이러한 객체들에 대한 재동기화가 발생합니다.

    검증은 아직 객체 리포지터리에 저장된 파일에 대해 구현되지 않았으므로 issue 13845를 확인하여 자세한 내용을 확인하세요. 이로 인해 객체 리포지터리에 저장된 모든 객체에 대해 일관적으로 실패하는 루프가 발생합니다.

    이를 해결하는 방법에 대한 정보는 GitLab 관리 객체 리포지터리 복제에서 동기화 실패 문제 해결을 참조하세요.

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: Premium, Ultimate Offering: Self-managed

14.4.0

Linux 패키지 설치

  • GitLab 14.4에서 제공되는 Grafana 버전은 7.5이며, 이는 GitLab 14.3에 도입된 Grafana 8.1 버전에서의 다운그레이드입니다. 이는 새로운 AGPL 라이선스의 출시에 대한 결과를 고려할 시간을 확보하기 위해 Apache 라이선스의 Grafana 릴리스로 회귀되었습니다.

    플러그인 또는 라이브러리 패널로 Grafana 설치를 사용자가 사용자 정의한 경우, 다운그레이드 후 Grafana에서 오류가 발생할 수 있습니다. Grafana를 다시 시작한 후에도 오류가 지속될 경우, Grafana db를 재설정하고 사용자 정의를 다시 추가해야 할 수 있습니다. Grafana 데이터베이스는 sudo gitlab-ctl reset-grafana를 사용하여 재설정할 수 있습니다.

Geo 설치

Tier: Premium, Ultimate Offering: 셀프 매니지먼트

  • Geo에 영향을 주는 GitLab 14.2에서 14.7까지의 문제가 있습니다. 이 문제는 GitLab에서 관리하는 객체 리포지터리 복제를 사용할 때 발생하며, 블롭 객체 유형의 동기화에 실패합니다.

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

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

    이 문제를 해결하는 방법은 GitLab에서 관리하는 객체 리포지터리 복제 실패 문제 해결를 참조하세요.

  • GitLab 14.4.0에서 14.4.2까지의 문제가 cron 작업에 의존하는 Geo 및 기타 기능에 영향을 줄 수 있습니다. GitLab 14.4.3 이상으로 업그레이드하는 것을 권장합니다.

14.3.0

  • 14.0.0 - 14.0.4에서 실행 중인 인스턴스는 직접 GitLab 14.2 이상으로 업그레이드하면 안 됩니다(#upgrading-to-later-14y-releases).
  • 이전 GitLab 14 릴리스에서 14.3.Z로 업그레이드하기 전에 일괄 배경 마이그레이션이 완료되었는지 확인하세요.

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

    마이그레이션이 무중단 배포의 일부로 실행되는 경우, 애플리케이션 로직과의 잠금 충돌로 인해 실패할 수 있으며, 잠금 시간 초과 또는 데드락이 발생할 수 있습니다. 이러한 경우, 이러한 마이그레이션은 성공할 때까지 재실행해도 안전합니다: 

    # 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 로그에서 오류를 확인할 수 있습니다: 

    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
      note
      예약된 작업은 /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
      note
      Rails를 사용하여 이러한 배경 마이그레이션을 동기적으로 실행할 때, 프로세스를 실행하는 시스템에 수행할 작업의 자원이 충분한지 확인하세요. 프로세스가 종료된 경우, 메모리가 충분하지 않아서 일어난 것일 수 있습니다. 일정 시간이 지난 후 SSH 세션이 만료되면 screen 또는 tmux와 같은 터미널 멀티플렉서를 사용하여 이전 코드를 실행해야 할 수 있습니다.

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

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

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

  • LDAP 암호를 사용하는 계정에 대해 이중 인증 (2FA)을 설정할 때 다음 오류가 표시될 수 있습니다: 

    유효한 현재 암호를 제공해야 합니다
  • 응용 프로그램을 시작할 때 I18n::InvalidLocale: :en is not a valid locale 오류가 발생하는 경우 패치 과정을 따르세요. mr_iid로 122978을 사용합니다.

자체 컴파일 설치

Geo 설치

Tier: Premium, Ultimate Offering: Self-managed

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

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

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

    이에 대한 해결 방법은 Troubleshooting - Failed syncs with GitLab-managed object storage replication를 참조하세요.

  • Multi-arch 이미지를 사용하는 경우 컨테이너 레지스트리의 복제가 완전히 작동하지 않는 문제가 있었습니다. Multi-arch 이미지의 경우 하나의 기본 아키텍처(예: 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 및 Multi-arch 컨테이너를 사용하는 경우, 최소한 GitLab 14.1로 업그레이드하는 것을 권장합니다.

14.2.0

Geo 설치

Tier: Premium, Ultimate Offering: Self-managed

  • GitLab 14.2에서 14.7까지의 문제가 있으며, 이는 GitLab 관리 객체 리포지터리 복제를 사용할 때 Geo에 영향을 미치며, 블롭 객체 유형의 동기화에 실패합니다.

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

    파일의 경우 아직 검증이 구현되지 않았으므로(자세한 내용은 이슈 13845 참조), 객체 리포지터리에 저장된 모든 객체에 대해 일관된 실패가 발생합니다.

    이를 해결하는 방법에 대한 정보는 Troubleshooting - Failed syncs with GitLab-managed object storage replication을 확인하십시오.

  • 멀티-아키텍처 이미지를 사용한 경우 컨테이너 레지스트리 복제의 문제가 발견되었습니다. 멀티-아키텍처 이미지의 경우 기본 아키텍처(예: 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은 Self-managed 설치와 가장 많은 호환성을 위해 업그레이드 경로에 포함되어 있으며, 14.0.0-14.0.4 설치가 일괄 배경 마이그레이션 명령으로 인한 문제를 겪지 않도록 합니다.

  • GitLab을 14.5 (또는 그 이후)로 업그레이드하면, 적어도 14.1로 업그레이드하기 전에 시간이 오래 걸릴 수 있습니다. 14.1 Merge Request 차이 커밋 데이터베이스 마이그레이션은 실행하는 데 수십 시간이 걸릴 수 있지만, 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를 사용합니다.

Geo 설치

Tier: Premium, Ultimate Offering: Self-managed

  • 주요 사이트를 UI에서 제거할 수 없는 문제가 발견되었습니다.

    이 버그는 UI에서만 발생하며 다른 방법으로 주요 사이트를 제거하는 것을 방해하지는 않습니다.

    영향을 받는 버전을 실행 중이고 주요 사이트를 제거해야 하는 경우, Geo Sites API를 사용하여 주요 사이트를 매뉴얼으로 제거할 수 있습니다.

14.0.0

전제 조건:

긴 기간 동안 일괄 배치된 백그라운드 데이터베이스 마이그레이션:

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

  • Self-managed 인스턴스에서 BatchedBackgroundMigrationWorkers가 작동하지 않았던 문제 로 인해, 14.0.5로의 업데이트가 필요한 수정이 만들어졌습니다. 이 수정은 또한 14.1.0에도 릴리스되었습니다.

    14.0.5 이상의 14.0 패치 버전으로 업데이트한 후에는 일괄 배치된 백그라운드 마이그레이션을 반드시 완료해야 하며, 업그레이드를 위해 나중에 버전으로 업그레이드하기 전에 일괄 배치된 백그라운드 마이그레이션이 반드시 완료되어 있어야 합니다.

    만약 마이그레이션이 완료되지 않은 상태에서 나중에 버전으로 업그레이드하려고 하면, 다음과 같은 오류가 표시됩니다: 

    예상했던 구성에 대한 일괄 배치된 백그라운드 마이그레이션이 '완료'로 표시되었는데, '활성'으로 표시됩니다:

    이 오류를 해결하는 방법을 확인하세요.

다른 이슈들:

  • 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='<USERNAME>';

Linux 패키지 설치

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

  • GitLab 13.0에서 sidekiq-cluster가 기본적으로 활성화되었으며, sidekiq 서비스는 내부적으로 sidekiq-cluster를 실행했습니다. 하지만 사용자는 sidekiq['cluster'] 설정을 사용하여 이 동작을 제어할 수 있었으며, 다양한 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 패키지로 제공되지 않습니다.

    사용자는 문서를 따라 Puma로 마이그레이션해야 하는데, GitLab 14.0으로 업그레이드하기 전에의 단계입니다.

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

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

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

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

  • GitLab 13에서 Redis의 두 구성 옵션이 폐기되었으며 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의 출력에서 오류가 발생할 것입니다: 

    'roles'에서 다음과 같은 올바르지 않은 역할이 설정되었습니다: redis_slave_role

Geo 설치

Tier: Premium, Ultimate Offering: Self-managed

  • 기본 사이트를 UI에서 제거할 수 없는 문제가 발견되었습니다.

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

    영향을 받는 버전을 실행 중이고 기본 사이트를 제거해야 하는 경우 Geo 사이트 API를 사용하여 매뉴얼으로 기본 사이트를 제거할 수 있습니다.

이후 14.Y 릴리스로 업그레이드