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 데이터베이스 테이블에서 불필요한 항목을 동시 인덱스 삭제합니다. 이 과정은 트래픽이 많고 마이그레이션이 잠금을 얻지 못할 경우 특히 여러 분이 걸릴 수 있으므로 프로세스가 완료될 때까지 기다리는 것이 좋습니다. 다시 시작하면 데이터 손실이 발생할 수 있습니다.

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

— (중략) —

Geo 설치

Tier: Premium, Ultimate Offering: Self-Managed

14.8.0

  • 14.6.5, 14.7.4 또는 14.8.2 이전 버전에서 업그레이드하는 경우, 크리티컬 보안 릴리스: 14.8.2, 14.7.4 및 14.6.5 블로그 게시물을 확인하십시오. 14.8.2 이후로 업데이트하면 그룹 및 프로젝트의 러너 등록 토큰이 재설정됩니다.

— (중략) —

14.7.0

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

  • GitLab 14.7에서는 Gitaly에서 /tmp 디렉터리에 지속 파일을 예상하는 변경이 있었습니다. Gitaly를 실행 중인 노드에서 /tmp에 noatime 마운트 옵션을 사용하는 경우 대부분의 Linux 배포판에서 Git 서버 후크가 삭제되는 문제가 발생합니다. Linux 배포본이 /tmp에서 파일을 tmpfiles.d 서비스로 관리하는 경우 Gitaly 파일에 대한 tmpfiles.d의 동작을 재정의하고 이 문제를 피할 수 있습니다. 

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

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

Linux 패키지 설치

  • GitLab 14.8에서는 Redis를 6.0.16에서 6.2.6으로 업그레이드합니다. 이 업그레이드는 완전히 하위 호환성이 있을 것으로 예상됩니다. Redis HA 클러스터를 업그레이드하는 제로 다운타임 지침에 따르세요.

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이 관리하는 객체 리포지터리 복제를 사용할 때 Geo에 영향을 미치는 GitLab 14.2부터 14.7까지의 문제가 있습니다. 이로 인해 blob 객체 유형이 동기화에 실패합니다.

    GitLab 14.2부터 검증 실패는 동기화 실패로 이어지고 이러한 객체의 재동기화를 유발합니다.

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

    이를 해결하려면 Troubleshooting - GitLab이 관리하는 객체 리포지터리 복제 실패를 참조하세요.

14.6.0

  • 이전 버전인 14.6.5, 14.7.4 또는 14.8.2보다 업그레이드하는 경우 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이 관리하는 객체 리포지터리 복제를 사용할 때 Geo에 영향을 미치는 GitLab 14.2부터 14.7까지의 문제가 있습니다. 이로 인해 blob 객체 유형이 동기화에 실패합니다.

    GitLab 14.2부터 검증 실패는 동기화 실패로 이어지고 이러한 객체의 재동기화를 유발합니다.

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

    이를 해결하려면 Troubleshooting - GitLab이 관리하는 객체 리포지터리 복제 실패를 참조하세요.

14.5.0

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

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

    모든 Merge Request 차이 커밋은 이러한 변경을 자동으로 적용하며 업그레이드를 수행하는 데 추가 요구 사항이 없습니다. merge_request_diff_commits 테이블의 기존 데이터는 VACUUM FULL merge_request_diff_commits를 실행할 때까지 미압축 상태로 유지됩니다. 그러나 VACUUM FULL 작업이 전체 merge_request_diff_commits 테이블을 잠그고 다시 작성하기 때문에 이 작업은 일부 시간을 필요로 하며 이 프로세스가 종료될 때까지 이 테이블에 대한 액세스를 차단합니다. 이 작업이 완료되는 데 걸리는 시간은 select pg_size_pretty(pg_total_relation_size('merge_request_diff_commits'));를 사용하여 테이블의 크기에 따라 다릅니다.

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

  • GitLab 14.5.0에는 백그라운드 마이그레이션 UpdateVulnerabilityOccurrencesLocation이 포함되어 있습니다. 이 마이그레이션의 대상을 충족하는 레코드가 없는 경우에는 대기 중 상태로 영원히 남을 수 있습니다.

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

    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에 영향을 미치며 블롭 객체 유형의 동기화 실패가 발생합니다.

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

    파일 리포지터리에 저장된 파일에 대해 아직 검증이 구현되지 않았으므로(이슈 13845에서 자세한 내용 참조), 이는 파일 리포지터리에 저장된 모든 객체에 대해 일관된 실패가 발생하도록 하는 루프로 이어집니다.

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

14.4.4

14.4.1 및 14.4.2

Geo 설치

Tier: Premium, Ultimate Offering: Self-Managed

14.4.0

리눅스 패키지 설치

  • GitLab 14.4에서 제공된 Grafana 버전은 7.5이며, 이는 GitLab 14.3에서 소개된 Grafana 8.1 버전으로의 다운그레이드입니다. 이는 더 최신 AGPL 라이선스 릴리스의 영향을 고려하기 위해 이전에 돌아간 Apache 라이선스 릴리스로 다시 되돌린 것입니다.

    플러그인이나 라이브러리 패널로 Grafana 설치를 사용자 정의한 사용자는 다운그레이드 후에 Grafana에서 오류를 경험할 수 있습니다. 오류가 지속되면 Grafana를 재시동한 후에 사용자 정의를 재설정해야 할 수 있습니다. Grafana 데이터베이스는 sudo gitlab-ctl reset-grafana로 재설정할 수 있습니다.

Geo 설치

Tier: Premium, Ultimate Offering: Self-Managed

14.3.0

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

  • GitLab 14.3.0에는 아래 나열된 테이블의 정수 PK가 있는 테이블에 대한 Primary Key 오버플로우 리스크를 해결하기 위한 배포 후 마이그레이션이 포함되어 있습니다:

    만약 마이그레이션이 다운타임 없는 배포의 일부로 실행된다면, 애플리케이션 로직과의 락 충돌로 인해 실패할 수 있어 락 시간 초과나 데드락으로 이어질 수 있습니다. 각각의 경우, 이러한 마이그레이션은 성공적으로 다시 실행할 수 있습니다: 

    # Omnibus GitLab용
sudo gitlab-rake db:migrate
  
# 소스 설치용
sudo -u git -H bundle exec rake db:migrate RAILS_ENV=production

  • 14.3으로 업그레이드한 후, GitLab 14.5 이상으로 업그레이드를 계속하기 전에 모든 MigrateMergeRequestDiffCommitUsers 백그라운드 마이그레이션 작업이 완료되었는지 확인하세요. 특히 GitLab 인스턴스에 merge_request_diff_commits 테이블이 큰 경우에 이 작업은 특히 중요합니다. 보류 중인 MigrateMergeRequestDiffCommitUsers 백그라운드 마이그레이션 작업은 GitLab 14.5에서 전경으로 나와 완료하는 데 오랜 시간이 소요될 수 있습니다. 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)을 설정할 때 다음과 같은 오류가 발생할 수 있습니다. 

    You must provide a valid current password
  • 응용 프로그램을 시작할 때 I18n::InvalidLocale: :en is not a valid locale 오류가 발생하는 경우, 패치 프로세스를 따릅니다. mr_iid로 122978를 사용하세요.

자체 컴파일된 설치

Geo 설치

자세한 정보: Tier: Premium, Ultimate Offering: Self-Managed

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

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

    파일의 검증이 아직 구현되지 않았기 때문에(is not yet implemented for files stored), 객체 리포지터리에 저장된 모든 객체에 대해 일관되게 실패하는 루프가 발생합니다.

    문제를 해결하는 방법은 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

    Geo 및 멀티 아키텍처 컨테이너를 사용하고 14.1 이전 버전을 실행 중이라면, 최소한 GitLab 14.1로 업그레이드하는 것이 좋습니다.

14.2.0

Geo 설치

자세한 정보: Tier: Premium, Ultimate Offering: Self-Managed

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

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

    파일의 검증이 아직 구현되지 않았기 때문에(is not yet implemented for files stored), 객체 리포지터리에 저장된 모든 객체에 대해 일관되게 실패하는 루프가 발생합니다.

    문제를 해결하는 방법은 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

    Geo 및 멀티 아키텍처 컨테이너를 사용하고 14.1 이전 버전을 실행 중이라면, 최소한 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의 diff 커밋 데이터베이스 마이그레이션은 실행 소요 시간이 수 시간이 걸릴 수 있지만, 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

  • 우리는 이슈를 발견했습니다. 이슈는 컨테이너 레지스트리 복제가 멀티-아키텍처 이미지를 사용하는 경우에 완전히 작동하지 않는 것을 보여줍니다. 멀티-아키텍처 이미지의 경우, 기본 아키텍처 (예: 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 이전 버전을 사용하고 컨테이너 레지스트리에서 멀티-아키텍처 컨테이너를 사용하는 경우, 적어도 GitLab 14.1로 업그레이드하는 것을 권장합니다.

  • 주요 사이트를 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 패치 버전으로 업데이트한 후, 일괄 배경 마이그레이션이 반드시 완료되어야 하며 나중에 업그레이드하기 전에 마이그레이션이 완료되지 않았다면 다음과 같은 오류가 표시됩니다. 

    Expected batched background migration for the given configuration to be marked as 'finished', but it is '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 및 Git에서 토큰을 사용하여 인증할 수 없게 되었습니다. 이는 만료된 암호 유효성 검사 부족 보안 수정으로 인한 것입니다. 업그레이드 후에 사용자가 인증 문제를 겪는 경우, 사용자의 암호가 만료되지 않았는지 확인하세요:

    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 패키지와 함께 제공되지 않습니다.

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

  • Geo 및 다중 노드 PostgreSQL 설치의 Consul 버전이 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의 출력에 오류가 발생합니다: 

    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: Self-Managed

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

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

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

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