GitLab 中文文档

Web terminals 概述

GitLab 8.15 引入web终端 功能, 只有项目属主和masters可以访问web终端。

通过引入Kubernetes project service, Gitlab可以对Kubernetes集群进行存储并可使用证书管理。 使用证书管理的功能之一就是为environments 提供了web 终端访问。

How it works 如何工作

A detailed overview of the architecture of web terminals and how they work can be found in this document. In brief:

Enabling and disabling terminal support

As web terminals use WebSockets, every HTTP/HTTPS reverse proxy in front of Workhorse needs to be configured to pass the Connection and Upgrade headers through to the next one in the chain. If you installed GitLab using Omnibus, or from source, starting with GitLab 8.15, this should be done by the default configuration, so there's no need for you to do anything.

However, if you run a load balancer in front of GitLab, you may need to make some changes to your configuration. These guides document the necessary steps for a selection of popular reverse proxies:

Workhorse won't let WebSocket requests through to non-WebSocket endpoints, so it's safe to enable support for these headers globally. If you'd rather had a narrower set of rules, you can restrict it to URLs ending with /terminal.ws (although this may still have a few false positives).

If you installed from source, or have made any configuration changes to your Omnibus installation before upgrading to 8.15, you may need to make some changes to your configuration. See the 8.14 to 8.15 upgrade document for more details.

If you'd like to disable web terminal support in GitLab, just stop passing the Connection and Upgrade hop-by-hop headers in the first HTTP reverse proxy in the chain. For most users, this will be the NGINX server bundled with Omnibus GitLab, in which case, you need to:

For your own load balancer, just reverse the configuration changes recommended by the above guides.

When these headers are not passed through, Workhorse will return a 400 Bad Request response to users attempting to use a web terminal. In turn, they will receive a Connection failed message.

Limiting WebSocket connection time

Introduced in GitLab 8.17.

Terminal sessions use long-lived connections; by default, these may last forever. You can configure a maximum session time in the Admin area of your GitLab instance if you find this undesirable from a scalability or security point of view.