diff options
Diffstat (limited to 'doc/administration/integration/terminal.md')
-rw-r--r-- | doc/administration/integration/terminal.md | 26 |
1 files changed, 13 insertions, 13 deletions
diff --git a/doc/administration/integration/terminal.md b/doc/administration/integration/terminal.md index fa58d0ef15f..06ef6988014 100644 --- a/doc/administration/integration/terminal.md +++ b/doc/administration/integration/terminal.md @@ -14,17 +14,17 @@ A detailed overview of the architecture of web terminals and how they work can be found in [this document](https://gitlab.com/gitlab-org/gitlab-workhorse/blob/master/doc/terminal.md). In brief: -* GitLab relies on the user to provide their own Kubernetes credentials, and to +- GitLab relies on the user to provide their own Kubernetes credentials, and to appropriately label the pods they create when deploying. -* When a user navigates to the terminal page for an environment, they are served +- 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), +- The WebSocket is handled in [Workhorse](https://gitlab.com/gitlab-org/gitlab-workhorse), 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 +- 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 API, passing WebSocket frames between the two. -* Workhorse regularly polls Rails, terminating the WebSocket connection if the +- Workhorse regularly polls Rails, terminating the WebSocket connection if the user no longer has permission to access the terminal, or if the connection details have changed. @@ -40,10 +40,10 @@ However, if you run a [load balancer](../high_availability/load_balancer.md) 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: -* [Apache](https://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.html) -* [NGINX](https://www.nginx.com/blog/websocket-nginx/) -* [HAProxy](http://blog.haproxy.com/2012/11/07/websockets-load-balancing-with-haproxy/) -* [Varnish](https://www.varnish-cache.org/docs/4.1/users-guide/vcl-example-websockets.html) +- [Apache](https://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.html) +- [NGINX](https://www.nginx.com/blog/websocket-nginx/) +- [HAProxy](http://blog.haproxy.com/2012/11/07/websockets-load-balancing-with-haproxy/) +- [Varnish](https://www.varnish-cache.org/docs/4.1/users-guide/vcl-example-websockets.html) 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 @@ -60,8 +60,8 @@ 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: -* Find the `nginx['proxy_set_headers']` section of your `gitlab.rb` file -* Ensure the whole block is uncommented, and then comment out or remove the +- Find the `nginx['proxy_set_headers']` section of your `gitlab.rb` file +- Ensure the whole block is uncommented, and then comment out or remove the `Connection` and `Upgrade` lines. For your own load balancer, just reverse the configuration changes recommended |