지금

PostgreSQL HA 사용 가 될 노드를 선택하십시오 Deploy Node. 모든 애플리케이션 노드가 될 수 있지만 프로세스 전체에서 동일한 노드여야 합니다. 노드 배포 에 빈 파일을 만듭니다 /etc/gitlab/skip-auto-reconfigure. 이렇게 하면 gitlab-ctl reconfigure기본적으로 GitLab을 자동으로 중지하고, 모든 데이터베이스 마이그레이션을 실행하고, GitLab을 다시 시작하는 업그레이드가 실행되지 않습니다. sudo touch /etc/gitlab/skip-auto-reconfigure Deploy 노드 를 포함한 모든 노드 reconfigure데이터베이스 마이그레이션이 자동으로 실행 되지 않도록 하려면 gitlab_rails['auto_migrate'] ..

다중 노드/HA 배포 한 번에 하나의 부 릴리스만 업그레이드할 수 있습니다. 따라서 13.6에서 13.7로, 13.8에서는 아닙니다. 부 릴리스를 두 개 이상 시도하면 업그레이드가 실패할 수 있습니다. 웹(Puma) 노드 앞에서 로드 밸런서 사용 Puma를 사용하면 단일 노드 제로 다운타임 업데이트가 더 이상 불가능합니다. 다운타임 없는 업데이트로 HA를 달성하려면 두 노드에 연결을 적절하게 분배하는 로드 밸런서와 함께 최소 두 개의 노드를 사용해야 합니다. 애플리케이션 노드 앞의 로드 밸런서는 서비스가 트래픽을 수락하는지 여부를 확인하기 위해 적절한 상태 확인 엔드포인트를 확인하도록 구성되어야 합니다. Puma의 경우 /-/readiness엔드포인트를 사용해야 하며 /readinessSidekiq 및 ..

GitLab 인스턴스를 오프라인으로 전환하지 않고도 GitLab의 최신 메이저, 마이너 또는 패치 버전으로 업그레이드할 수 있습니다. 그러나 이것이 작동하려면 다음 요구 사항이 있습니다. 한 번에 하나의 부 릴리스만 업그레이드할 수 있습니다. 따라서 13.3이 아닌 13.1에서 13.2로. 릴리스를 건너뛰면 데이터베이스 수정이 잘못된 순서로 실행되고 데이터베이스 스키마가 손상된 상태로 남을 수 있습니다 . 배포 후 마이그레이션 을 사용해야 합니다 . PostgreSQL을 사용하고 있습니다. GitLab 12.1부터 MySQL은 지원되지 않습니다. 다중 노드 GitLab 인스턴스. 단일 노드 인스턴스는 서비스가 다시 시작될 때 잠시 중단될 수 있습니다(특히 Puma) . 위의 모든 요구 사항을 충족하는 경..

소스에서 Community Edition 및 Enterprise Edition 업그레이드 12.0.0으로 업그레이드하려는 사용자는 몇 가지 추가 단계를 수행해야 합니다. 자세한 내용은 12.0.0에 대한 버전별 업그레이드 지침을 참조하십시오. 설치하려는 GitLab의 분기(버전)에서 이 업데이트 가이드를 확인하십시오(예: 11.8). GitLab 문서 페이지의 오른쪽 상단에 있는 드롭다운에서 필요한 문서 버전을 선택할 수 있습니다. 다음 각 예에서 BRANCH업그레이드하려는 버전의 분기로 바꿉니다(예: 11-8-stablefor 11.8). 업그레이드하려는 버전의 분기로 바꿉니다 PREVIOUS_BRANCH(예: 11-7-stable) 11.7. 가장 높은 안정 브랜치가 확실하지 않은 경우 GitLab ..

비 Omnibus 설치에서 업그레이드하는 것은 GitLab.com에서 테스트하지 않았습니다. gitlab.yml, puma.rb및 와 같은 파일의 설정이 손실된다는 점에 유의하십시오 smtp_settings.rb. 에서 해당 설정을 구성/etc/gitlab/gitlab.rb 해야 합니다 . 마이그레이션을 시작하기 전에 정확히 동일한 버전 의 GitLab 으로 이동하고 있는지 확인 하십시오. 설치를 Omnibus로 변환하려면: 현재 GitLab 설치에서 MySQL을 사용하는 경우 먼저 데이터를 PostgreSQL로 마이그레이션해야 합니다. GitLab 12.1부터 PostgreSQL이 유일하게 지원되는 데이터베이스 관리 시스템이기 때문입니다. 이미 PostgreSQL을 사용하고 있다면 이 단계를 건너뛰십시..

패키지 정보 Omnibus GitLab 패키지는 GitLab이 올바르게 작동하는 데 필요한 모든 종속성과 함께 번들로 제공됩니다. 자세한 내용은 종속성 번들 문서 에서 확인할 수 있습니다 . 패키지 버전 릴리스된 패키지 버전은 다음 형식으로 되어 있습니다. MAJOR.MINOR.PATCH-EDITION.OMNIBUS_RELEASE 요소의미예시 메이저.마이너.패치 해당하는 GitLab 버전입니다. 13.3.0 판 해당하는 GitLab의 에디션입니다. 에이 옴니버스_릴리즈 옴니버스 GitLab 릴리스. 일반적으로 이것은 0입니다. GitLab 버전을 변경하지 않고 새 패키지를 빌드해야 하는 경우 증가합니다. 0 라이선스 라이선스 보기 기본값 Omnibus GitLab 패키지는 구성 요소가 제대로 작동하도록 ..

지원 중단 정책 Omnibus GitLab 패키지는 사용자에게 과다한 구성 옵션을 제공하는 다양한 라이브러리 및 서비스와 함께 제공됩니다. 라이브러리와 서비스가 업데이트되면 구성 옵션이 변경되어 더 이상 사용되지 않습니다. 유지 관리 가능성을 높이고 작업 설정을 유지하려면 다양한 구성을 제거해야 합니다. 구성 지원 중단 정책 Omnibus GitLab 패키지는 하나 이상의 주요 버전에 대한 구성을 유지합니다. 더 이상 사용되지 않는 구성을 다음 주요 릴리스에서 사용할 수 있다고 보장할 수 없습니다. 자세한 내용은 예 를 참조하세요. 알아 채다 구성이 더 이상 사용되지 않는 경우 사용 중단을 발표합니다. 의 릴리스 블로그 게시물을 https://about.gitlab.com/blog/통해 블로그 게시물 항..

패키지 정보 Omnibus GitLab 패키지는 GitLab이 올바르게 작동하는 데 필요한 모든 종속성과 함께 번들로 제공됩니다. 자세한 내용은 종속성 번들 문서 에서 확인할 수 있습니다 . 패키지 버전 릴리스된 패키지 버전은 다음 형식으로 되어 있습니다. MAJOR.MINOR.PATCH-EDITION.OMNIBUS_RELEASE 요소의미예시 메이저.마이너.패치 해당하는 GitLab 버전입니다. 13.3.0 판 해당하는 GitLab의 에디션입니다. 에이 옴니버스_릴리즈 옴니버스 GitLab 릴리스. 일반적으로 이것은 0입니다. GitLab 버전을 변경하지 않고 새 패키지를 빌드해야 하는 경우 증가합니다. 0 라이선스 라이선스 보기 기본값 Omnibus GitLab 패키지는 구성 요소가 제대로 작동하도록 ..

루닛 GitLab은 서비스 관리 및 감독을 위해 runit 레시피를 사용합니다. runit 레시피는 OS에서 사용하는 init 시스템을 식별하는 작업을 수행하고 GitLab에 필요한 서비스 파일 생성, 서비스 활성화, 서비스 재로딩과 같은 기본적인 서비스 관리 작업을 수행합니다. runit은 runit_service서비스와 상호 작용하기 위해 다른 레시피에서 사용할 수 있는 정의를 제공 /files/gitlab-cookbooks/runit 합니다. 자세한 내용은 를 참조하십시오. 서비스 서비스는 runit 프로세스 init/supervisor를 사용하여 실행하는 소프트웨어 프로세스입니다. gitlab-ctl명령 을 사용하여 상태를 확인하고 시작, 중지 및 다시 시작할 수 있습니다 . 레시피는 또한 프로세..

개별 소프트웨어 정의 Omnibus GitLab은 배터리 포함 배포 방식을 따릅니다. GitLab 인스턴스의 적절한 기능에 필요한 모든 소프트웨어, 라이브러리 및 바이너리는 패키지의 일부로 포함된 형식으로 제공됩니다. 따라서 옴니버스 아키텍처의 또 다른 주요 구성 요소 중 하나는 소프트웨어 정의 및 구성 입니다. 일반적인 소프트웨어 구성은 다음 부분으로 구성됩니다. 필요한 소프트웨어 버전입니다. 소프트웨어 라이선스. 빌드/실행할 소프트웨어에 대한 종속성. 소프트웨어를 빌드하고 패키지 내부에 포함하는 데 필요한 명령입니다. 때로는 소프트웨어의 소스 코드를 GitLab과 함께 사용하기 위해 패치해야 할 수도 있습니다. 이는 보안 취약점을 수정하거나 GitLab에 필요한 일부 기능을 추가하거나 GitLab의 ..