Rename "Online terminal" to "Web terminal" in the docs

This commit is contained in:
Nick Thomas 2016-12-20 11:05:39 +00:00
parent 4e169327bf
commit ff31f4f922
5 changed files with 18 additions and 18 deletions

View file

@ -34,7 +34,7 @@
- [Integration](integration/README.md) How to integrate with systems such as JIRA, Redmine, Twitter.
- [Issue closing pattern](administration/issue_closing_pattern.md) Customize how to close an issue from commit messages.
- [Koding](administration/integration/koding.md) Set up Koding to use with GitLab.
- [Online terminals](administration/integration/terminal.md) Provide terminal access to environments from within GitLab.
- [Web terminals](administration/integration/terminal.md) Provide terminal access to environments from within GitLab.
- [Libravatar](customization/libravatar.md) Use Libravatar instead of Gravatar for user avatars.
- [Log system](administration/logs.md) Log system.
- [Environment Variables](administration/environment_variables.md) to configure GitLab.

View file

@ -50,11 +50,11 @@ Read more on high-availability configuration:
1. [Configure NFS](nfs.md)
1. [Configure the GitLab application servers](gitlab.md)
[^1]: [Terminal support](../../ci/environments.md#terminal-support) requires
[^1]: [Web terminal](../../ci/environments.md#web-terminals) support requires
your load balancer to correctly handle WebSocket connections. When using
HTTP or HTTPS proxying, this means your load balancer must be configured
to pass through the `Connection` and `Upgrade` hop-by-hop headers. See the
[online terminal](../integration/terminal.md) integration guide for
[web terminal](../integration/terminal.md) integration guide for
more details.
[^2]: When using HTTPS protocol for port 443, you will need to add an SSL
certificate to the load balancers. If you wish to terminate SSL at the

View file

@ -1,17 +1,17 @@
# Online terminals
# Web terminals
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7690)
in GitLab 8.15. Only project masters and owners can access online terminals.
in GitLab 8.15. Only project masters and owners can access web terminals.
With the introduction of the [Kubernetes](../../project_services/kubernetes.md)
project service, GitLab gained the ability to store and use credentials for a
Kubernetes cluster. One of the things it uses these credentials for is providing
access to [online terminals](../../ci/environments.html#online-terminals)
access to [web terminals](../../ci/environments.html#web-terminals)
for environments.
## How it works
A detailed overview of the architecture of online terminals and how they work
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:
@ -31,7 +31,7 @@ In brief:
## Enabling and disabling terminal support
As online terminals use WebSockets, every HTTP/HTTPS reverse proxy in front of
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
@ -56,7 +56,7 @@ 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](../../update/8.14-to-8.15.md#nginx-configuration)
document for more details.
If you'd like to disable online terminal support in GitLab, just stop passing
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:
@ -69,5 +69,5 @@ 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 an online terminal. In
turn, they will receive a `Connection failed` message.
`400 Bad Request` response to users attempting to use a web terminal. In turn,
they will receive a `Connection failed` message.

View file

@ -27,7 +27,7 @@ so every environment can have one or more deployments. GitLab keeps track of
your deployments, so you always know what is currently being deployed on your
servers. If you have a deployment service such as [Kubernetes][kubernetes-service]
enabled for your project, you can use it to assist with your deployments, and
can even access a terminal for your environment from within GitLab!
can even access a web terminal for your environment from within GitLab!
To better understand how environments and deployments work, let's consider an
example. We assume that you have already created a project in GitLab and set up
@ -235,10 +235,10 @@ Remember that if your environment's name is `production` (all lowercase), then
it will get recorded in [Cycle Analytics](../user/project/cycle_analytics.md).
Double the benefit!
## Terminal support
## Web terminals
>**Note:**
Terminal support was added in GitLab 8.15 and is only available to project
Web terminals were added in GitLab 8.15 and are only available to project
masters and owners.
If you deploy to your environments with the help of a deployment service (e.g.,

View file

@ -48,16 +48,16 @@ GitLab CI build environment:
- `KUBE_NAMESPACE`
- `KUBE_CA_PEM` - only if a custom CA bundle was specified
## Terminal support
## Web terminals
>**NOTE:**
Added in GitLab 8.15. You must be the project owner or have `master` permissions
to use terminals. Support is currently limited to the first container in the
first pod of your environment.
When enabled, the Kubernetes service adds online [terminal support](../ci/environments.md#terminal-support)
to your environments. This is based on the `exec` functionality found in
When enabled, the Kubernetes service adds [web terminal](../ci/environments.md#web-terminals)
support to your environments. This is based on the `exec` functionality found in
Docker and Kubernetes, so you get a new shell session within your existing
containers. To use this integration, you should deploy to Kubernetes using
the deployment variables above, ensuring any pods you create are labelled with
`app=$CI_ENVIRONMENT_SLUG`.
`app=$CI_ENVIRONMENT_SLUG`. GitLab will do the rest!