Web 터미널 (사용 중단됨)

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

Self-Managed에서 비활성화됨 - GitLab 15.0에서.

이 기능은 사용 중단되었습니다 - GitLab 14.5에서.

Self-Managed GitLab에서는 기본적으로 이 기능을 사용할 수 없습니다. 관리자는 certificate_based_clusters라는 기능 플래그를 활성화할 수 있습니다.

쿠버네티스 통합의 도입으로, GitLab은 쿠버네티스 클러스터의 자격 증명을 저장하고 사용할 수 있습니다. GitLab은 이러한 자격 증명을 사용하여 환경에 대한 웹 터미널에 액세스할 수 있습니다.

프로젝트에 대한 Maintainer 역할을 적어도 가진 사용자만 웹 터미널에 액세스할 수 있습니다.

작동 방식

웹 터미널의 아키텍처 개요 및 작동 방식에 대한 상세한 내용은 이 문서에서 찾을 수 있습니다. 간단히 말하자면:

GitLab은 사용자가 자체 쿠버네티스 자격 증명을 제공하고, 배포할 때 만든 팟을 적절하게 레이블 지정하는 데 의존합니다.
사용자가 환경의 터미널 페이지로 이동하면 GitLab으로의 WebSocket 연결을 열어주는 JavaScript 애플리케이션을 제공합니다.
WebSocket은 Workhorse에서 처리됩니다. Rails 애플리케이션 서버가 아닙니다.
Workhorse는 연결 세부 정보 및 사용자 권한에 대해 Rails에 쿼리합니다. Rails는 Sidekiq을 사용하여 백그라운드에서 이를 위해 쿠버네티스에 쿼리합니다.
Workhorse는 사용자 브라우저와 쿠버네티스 API 간의 프록시 서버 역할을 하며, 두 연결 간의 WebSocket 프레임을 전달합니다.
Workhorse는 정기적으로 Rails에 문의하여, 사용자가 터미널에 더 이상 액세스할 수 없거나 연결 세부 정보가 변경된 경우 WebSocket 연결을 종료합니다.

GitLab 및 GitLab Runner은 상호 작용하는 웹 터미널 데이터를 서로 암호화하고 모든 것을 인가 보호하는 몇 가지 주의를 취합니다. 이에 대한 자세한 내용은 아래에서 설명됩니다.

상호 작용하는 웹 터미널은 [session_server]가 구성되지 않은 경우 완전히 비활성화됩니다.
실행될 때마다 Runner는 wss (Web Socket Secure) 연결에 사용되는 x509 인증서를 생성합니다.
생성된 작업마다 작업이 종료될 때 버려지는 무작위 URL이 생성됩니다. 이 URL은 웹 소켓 연결을 설정하는 데 사용됩니다. 세션의 URL은 (IP|HOST):PORT/session/$SOME_HASH 형식입니다. 여기서 IP/HOST 및 PORT는 구성된 listen_address입니다.
생성된 각 세션 URL에는 wss 연결을 설정하기 위해 전송해야 하는 인가 헤더가 있습니다.
세션 URL은 사용자에게 노출되지 않습니다. GitLab은 모든 상태를 내부적으로 보관하고 그에 따라 프록시합니다.

기본적으로 터미널 세션이 만료되지 않습니다. GitLab 인스턴스에서 터미널 세션 수명을 제한하려면: