diff options
Diffstat (limited to 'doc/administration/integration/terminal.md')
| -rw-r--r-- | doc/administration/integration/terminal.md | 22 |
1 files changed, 11 insertions, 11 deletions
diff --git a/doc/administration/integration/terminal.md b/doc/administration/integration/terminal.md index 3c53535d856..f4c242b6e72 100644 --- a/doc/administration/integration/terminal.md +++ b/doc/administration/integration/terminal.md @@ -1,14 +1,14 @@ --- -stage: none -group: unassigned -info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers +stage: Create +group: Ecosystem +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments --- # Web terminals > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/7690) in GitLab 8.15. -NOTE: **Note:** +NOTE: Only project maintainers and owners can access web terminals. With the introduction of the [Kubernetes integration](../../user/project/clusters/index.md), @@ -27,7 +27,7 @@ In brief: - When a user navigates to the terminal page for an environment, they are served a JavaScript application that opens a WebSocket connection back to GitLab. - The WebSocket is handled in [Workhorse](https://gitlab.com/gitlab-org/gitlab-workhorse), - rather than the Rails application server. + rather than the Rails application server. - Workhorse queries Rails for connection details and user permissions. Rails queries Kubernetes for them in the background using [Sidekiq](../troubleshooting/sidekiq.md). - Workhorse acts as a proxy server between the user's browser and the Kubernetes @@ -44,14 +44,14 @@ everything protected with authorization guards. This is described in more detail below. - Interactive web terminals are completely disabled unless [`[session_server]`](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-session_server-section) is configured. -- Every time the runner starts, it will generate an `x509` certificate that will be used for a `wss` (Web Socket Secure) connection. +- Every time the runner starts, it generates an `x509` certificate that is used for a `wss` (Web Socket Secure) connection. - For every created job, a random URL is generated which is discarded at the end of the job. This URL is used to establish a web socket connection. The URL for the session is in the format `(IP|HOST):PORT/session/$SOME_HASH`, where the `IP/HOST` and `PORT` are the configured [`listen_address`](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-session_server-section). - Every session URL that is created has an authorization header that needs to be sent, to establish a `wss` connection. - The session URL is not exposed to the users in any way. GitLab holds all the state internally and proxies accordingly. ## Enabling and disabling terminal support -NOTE: **Note:** +NOTE: AWS Elastic Load Balancers (ELBs) do not support web sockets. AWS Application Load Balancers (ALBs) must be used if you want web terminals to work. See [AWS Elastic Load Balancing Product Comparison](https://aws.amazon.com/elasticloadbalancing/features/#compare) @@ -72,7 +72,7 @@ guides document the necessary steps for a selection of popular reverse proxies: - [HAProxy](https://www.haproxy.com/blog/websockets-load-balancing-with-haproxy/) - [Varnish](https://varnish-cache.org/docs/4.1/users-guide/vcl-example-websockets.html) -Workhorse won't let WebSocket requests through to non-WebSocket endpoints, so +Workhorse doesn'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). @@ -85,7 +85,7 @@ 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 +proxy in the chain. For most users, this is the NGINX server bundled with Omnibus GitLab, in which case, you need to: - Find the `nginx['proxy_set_headers']` section of your `gitlab.rb` file @@ -95,9 +95,9 @@ 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 +When these headers are not passed through, Workhorse returns a `400 Bad Request` response to users attempting to use a web terminal. In turn, -they will receive a `Connection failed` message. +they receive a `Connection failed` message. ## Limiting WebSocket connection time |