유지보수
GitLab Dedicated 인스턴스는 보안, 신뢰성 및 최적의 성능을 보장하기 위해 정기적인 유지보수를 받습니다.
유지보수 창
GitLab은 주간 유지보수 창을 활용하여 인스턴스를 최신 상태로 유지하고, 보안 문제를 수정하며, 환경의 전반적인 신뢰성과 성능을 보장합니다.
업그레이드 및 패치
귀하의 인스턴스는 선호하는 유지보수 창 동안 정기적인 업그레이드를 받습니다. 이 업그레이드는 현재 GitLab 릴리즈보다 하나의 버전이 뒤인 최소 버전의 최신 패치 릴리스를 포함합니다. 예를 들어, 최신 GitLab 버전이 16.8인 경우 귀하의 GitLab Dedicated 인스턴스는 16.7에서 실행됩니다.
월간 업데이트에는 다음이 포함됩니다:
- 한 개의 마이너 릴리스
- 두 개의 패치 릴리스
인스턴스에 대한 세부정보를 보려면 예정된 유지보수 및 현재 GitLab 버전을 포함하여 Switchboard에 로그인하세요.
자세한 정보는 GitLab 릴리스 및 유지보수 정책을 참조하세요.
제로 다운타임 업그레이드
배포는 제로 다운타임 업그레이드 절차를 따라 업그레이드 중 하위 호환성을 보장합니다. 인프라 변경이나 유지보수 작업으로 인해 다운타임이 필요하지 않은 경우에는 업그레이드 중 인스턴스를 사용하는 것이 가능하며 안전합니다.
GitLab 버전 업데이트 중에 정적 자산이 변경될 수 있으며 두 버전 중 하나에서만 사용할 수 있습니다. 이 상황을 완화하기 위해 세 가지 기술이 채택됩니다:
- 각 정적 자산은 콘텐츠가 변경될 때 이름이 변경되는 고유한 이름을 가집니다.
- 브라우저는 각 정적 자산을 캐시합니다.
- 동일한 브라우저의 각 요청은 일시적으로 동일한 서버로 라우팅됩니다.
이러한 기술들은 자산 가용성에 대한 강력한 보장을 제공합니다:
- 업그레이드 중에 새 버전을 실행하는 서버로 라우팅된 사용자는 같은 서버에서 자산을 받아서 끊어진 페이지를 받을 위험을 없앱니다.
- 구 버전으로 라우팅된 일반 사용자는 자산이 브라우저에 캐시되어 있습니다.
- 캐시되지 않은 경우, 요청된 페이지와 자산을 동일한 서버에서 받습니다.
- 요청 중 특정 서버가 업그레이드되는 경우, 여전히 동일한 버전을 실행하는 다른 서버로 라우팅될 수 있습니다.
- 새 서버가 업그레이드된 버전을 실행 중이고 요청된 자산이 변경된 경우, 페이지에서 일부 사용자 인터페이스 글리치가 발생할 수 있습니다.
업그레이드의 효과는 일반적으로 눈에 띄지 않습니다. 그러나 드문 경우에 새로운 사용자가 일시적인 인터페이스 불일치를 경험할 수 있습니다:
- 사용자가 업그레이드 중에 처음으로 연결합니다.
- 처음에는 구 버전을 실행하는 서버로 라우팅됩니다.
- 이후 자산 요청은 새 버전을 가진 서버로 전달됩니다.
- 요청된 자산이 새 버전에서 변경되었습니다.
이런 가능성이 낮은 순서가 발생하면 페이지를 새로 고침하면 시각적 불일치가 해결됩니다.
주의:
네트워크에서 캐싱 프록시를 구현하면 이 위험을 더욱 줄일 수 있습니다.
긴급 유지보수
긴급 유지보수는 인스턴스의 보안, 가용성 또는 신뢰성에 영향을 미치는 고위험 문제를 해결합니다. 중요한 패치 릴리스를 사용할 수 있을 때 GitLab Dedicated 인스턴스는 긴급 유지보수 절차를 사용하여 가능한 한 빨리 업그레이드됩니다.
도움말