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