mirror of
https://github.com/gravitational/teleport
synced 2024-10-19 08:43:58 +00:00
Lowercase "Teleport Service" (#24149)
The Core Concepts page uses "Teleport Service" in uppercase. While I think it is appropriate to capitalize "Service" when naming specific Teleport architectural components, e.g., "Database Service", "Application Service", etc., I'm not sure we want to imply that "Teleport Service" is a distinct product by making it a proper noun. The docs tend to use "Teleport service", where "service" is a general computing term. We don't lose any meaning by using "Teleport service" instead of "Teleport Service", and don't risk suggesting that Teleport services have more in common than they really do.
This commit is contained in:
parent
2370355068
commit
fd02bc54f6
|
@ -11,7 +11,7 @@ familiar with them before following other pages in the documentation.
|
|||
|
||||
The key concept of Teleport's architecture is the **cluster**. A Teleport
|
||||
cluster consists of the **Teleport Auth Service** and **Teleport Proxy
|
||||
Service**, plus the **Teleport Services** that manage traffic to resources
|
||||
Service**, plus the **Teleport services** that manage traffic to resources
|
||||
within your infrastructure, such as Kubernetes clusters and Windows desktops.
|
||||
|
||||
A minimal Teleport cluster consists of the **Teleport Auth Service** and
|
||||
|
@ -28,7 +28,7 @@ issues certificates to clients and maintains an audit log.
|
|||
|
||||
The Auth Service is the only component of a cluster that has to be connected to
|
||||
a backend, which it uses to store cluster state and the certificate authorities'
|
||||
private keys. **Teleport Services** are stateless and interact with the Auth
|
||||
private keys. **Teleport services** are stateless and interact with the Auth
|
||||
Service via a gRPC API.
|
||||
|
||||
You can run multiple Auth Service instances in a cluster for high availability.
|
||||
|
@ -52,13 +52,13 @@ resources with Teleport-issued certificates directly.
|
|||
Read our guide to [how the Teleport Proxy Service
|
||||
works](./architecture/proxy.mdx).
|
||||
|
||||
## Teleport Services
|
||||
## Teleport services
|
||||
|
||||
A **Teleport Service** manages access to resources in your infrastructure, such
|
||||
A **Teleport service** manages access to resources in your infrastructure, such
|
||||
as Kubernetes clusters, Windows desktops, internal web applications, and
|
||||
databases.
|
||||
|
||||
A single running `teleport` process can run one or more **Teleport Services**,
|
||||
A single running `teleport` process can run one or more **Teleport services**,
|
||||
depending on the user's configuration. Read about all subcommands of `teleport`
|
||||
in our [CLI Reference](./reference/cli.mdx#teleport).
|
||||
|
||||
|
@ -110,15 +110,15 @@ Bot users can connect to resources in your infrastructure without relying
|
|||
on static credentials (e.g., certificates and private keys) that become more
|
||||
vulnerable to attacks the longer they remain in use.
|
||||
|
||||
Unlike other **Teleport Services**, Machine ID runs via the `tbot` binary,
|
||||
Unlike other **Teleport services**, Machine ID runs via the `tbot` binary,
|
||||
rather than the `teleport` binary.
|
||||
|
||||
Read more in our [Machine ID guide](./machine-id/introduction.mdx).
|
||||
|
||||
### Agent
|
||||
|
||||
An instance of a **Teleport Service** is called an **agent**. For all Teleport
|
||||
Services besides the **Teleport SSH Service**, an agent can enable access to
|
||||
An instance of a **Teleport service** is called an **agent**. For all Teleport
|
||||
services besides the **Teleport SSH Service**, an agent can enable access to
|
||||
multiple resources, and can run on a separate host from the resources it enables
|
||||
access to. All agents must run in the same network as their target resources.
|
||||
|
||||
|
|
|
@ -148,7 +148,7 @@ ssh_service:
|
|||
|
||||
</Details>
|
||||
|
||||
Start or restart the Teleport Service. For new Teleport nodes, the examples below
|
||||
Start or restart the Teleport service. For new Teleport nodes, the examples below
|
||||
depend on how you installed Teleport (from a system package or a TAR archive):
|
||||
|
||||
<Tabs>
|
||||
|
|
|
@ -492,4 +492,4 @@ $ docker stop teleport
|
|||
|
||||
Teleport is now removed from your system.
|
||||
|
||||
Any Teleport Services will stop appearing in your Teleport Web UI or the output of `tsh ls` once their last heartbeat has timed out. This usually occurs within 10-15 minutes of stopping the Teleport process.
|
||||
Any Teleport services will stop appearing in your Teleport Web UI or the output of `tsh ls` once their last heartbeat has timed out. This usually occurs within 10-15 minutes of stopping the Teleport process.
|
||||
|
|
|
@ -8,7 +8,7 @@ Teleport instances to join your Teleport cluster without sharing any secrets
|
|||
when they are running in an Azure Virtual Machine.
|
||||
|
||||
The Azure join method is available in Teleport 12.1+. It is available to any
|
||||
Teleport Service running in an Azure Virtual Machine.
|
||||
Teleport service running in an Azure Virtual Machine.
|
||||
|
||||
<Details
|
||||
scope={["oss", "enterprise", "cloud"]}
|
||||
|
|
Loading…
Reference in a new issue