Web terminals (deprecated)

Information about Web terminals.

히스토리 이 기능은 GitLab 14.5에서 더 이상 사용되지 않습니다 . GitLab 15.0에서 GitLab Self-Managed에서 비활성화 되었습니다. Feature flag GitLab Self-Managed에서는 기본적으로 이 기능을 사용할 수 없습니다. 사용하려면 관리자가 certificate_based_clusters 라는 기능 플래그를 활성화 하면 됩니다. 더 이상 사용되지 않는 기능이 아닌 Web IDE를 통해 접근하는 웹 터미널 에 대한 자세한 내용을 참고합니다. 더 이상 사용되지 않는 기능이 아닌 실행 중인 CI job에서 접근하는 웹 터미널 에 대한 자세한 내용을 참고합니다. Kubernetes 통합 이 도입되면서 GitLab은 Kubernetes 클러스터의 자격 증명을 저장하고 사용할 수 있습니다. GitLab은 이 자격 증명을 사용해 환경의 웹 터미널 에 대한 접근을 제공합니다. Note 프로젝트에 대해 최소 Maintainer 권한 을 가진 사용자만 웹 터미널에 접근할 수 있습니다. 웹 터미널 동작 방식 # 웹 터미널의 아키텍처와 동작 방식에 대한 자세한 개요는 이 문서 에서 확인할 수 있습니다. 요약하면 다음과 같습니다. GitLab은 사용자가 직접 Kubernetes 자격 증명을 제공하고, 배포 시 생성하는 Pod에 적절한 레이블을 지정하는 것에 의존합니다. 사용자가 환경의 터미널 페이지로 이동하면 GitLab으로 WebSocket 연결을 여는 JavaScript 애플리케이션이 제공됩니다. WebSocket은 Rails 애플리케이션 서버가 아니라 Workhorse 에서 처리합니다. Workhorse는 Rails에 연결 정보와 사용자 권한을 질의합니다. Rails는 Sidekiq 를 사용해 백그라운드에서 Kubernetes에 이를 질의합니다. Workhorse는 사용자 브라우저와 Kubernetes API 사이에서 프록시 서버 역할을 하며, 양쪽 사이로 WebSocket 프레임을 전달합니다. Workhorse는 주기적으로 Rails를 폴링하며, 사용자가 더 이상 터미널에 접근할 권한이 없거나 연결 정보가 바뀌면 WebSocket 연결을 종료합니다. 보안 # GitLab과 GitLab Runner 는 둘 사이의 대화형 웹 터미널 데이터를 암호화하고 모든 것을 인가 검사로 보호하기 위해 몇 가지 예방 조치를 취합니다. 자세한 내용은 아래에 설명되어 있습니다. [session_server] 를 구성하지 않으면 대화형 웹 터미널은 완전히 비활성화됩니다. 러너가 시작될 때마다 wss (Web Socket Secure) 연결에 사용할 x509 인증서를 생성합니다. 생성되는 job 마다 무작위 URL 이 생성되며 job 이 끝나면 폐기됩니다. 이 URL은 웹 소켓 연결을 맺는 데 사용됩니다. 세션 URL의 형식은 (IP|HOST):PORT/session/$SOME_HASH 이며, IP/HOST 와 PORT 는 구성된 listen_address 입니다. 생성된 모든 세션 URL에는 wss 연결을 맺기 위해 전송해야 하는