* Add a glossary of Teleport terms
Closes#16121Closes#13363
- Create a Core Concepts page based on the Architecture Overview page.
The Overview page is an outline of core concepts, so I thought it
would make a good starting point for the glossary.
- Add the Core Concepts page to the Home section to make it more
prominent for users who are visiting the docs homepage. This should
give it more traffic than leaving it in the Architecture section.
- Move definitions out of the "Definitions" table. Since this table
repeats content from the body sections and comes after them, it makes
sense to condense all content into brief body sections.
- Alphabetize sections
- Bold the first instance of each keyword within a given section. Not
adding links since these are all to the same page. It might get a bit
confusing to click a link and not see a change in view, since the
target section would already be on the page.
- Remove the intro paragraph of the old Overview page, since it's not
strictly related to core concepts.
* Respond to PR feedback and add further edits
- Group definitions into H3-level sections organized into H2s, improving
readability by presenting the more central components first.
- Group "Machine ID" with "Teleport Services" to simplify the glossary.
- Call instances of a Teleport Service an "agent". This is consistent
with our source and informal language about Teleport. This also
removes the "Node" terminology, which is prone to misuse (does it mean
"a Service instance"? An "SSH Service instance"? Both are present in
the docs) and easily confused with the lowercase "node" (i.e., a
host).
- For simplicity, remove the term "Teleport Process" and simply explain
that multiple Teleport Services can run via the same binary.
- Add a section on Teleport's editions, including the terms "Community
Edition", "Enterprise", and "Enterprise Cloud".
- Remove the mention of Teleport Discover, which isn't documented yet.
- Minor wording/readability changes.
* Respond to PR feedback
* Respond to zmb3 feedback
* Organize docs guide sections chronologically
This change aims to make docs navigation easier by organizing some docs
sections according to the sequence of steps a user would take to set up
Teleport.
The current docs organization uses a variety of categories and schemes
to organize the docs. For example, there is a "Home" section that
includes the Changelog, Installation page, and Getting Started guides; a
"Setup" section that includes references and admin guides; and
edition-specific sections (Enterprise, Cloud). For a user who is setting
up Teleport--or who has already done some setup work and wants more
advanced instructions--it's difficult to know where in the docs to find
the right information.
This change organizes our how-to guides into the following categories
that describe the process of setting up Teleport:
- Try out Teleport
- Deploy a Cluster (including choosing an edition)
- Configure Access (including SSO, RBAC, and Access Requests)
- Manage your Cluster (admin guides, operations, etc.)
- Use Teleport (this section already exists)
I moved the Reference section after this chronology, since users can
access the reference guides anywhere in the setup process.
As part of the change, I have also moved the content from the
"Enterprise" and "Cloud" sections into "Deploy a Cluster", since this
content has to do with how to deploy a specific edition of Teleport.
Note that this change does _not_ attempt to reorganize our
protocol-specific sections. While adding resources is part of the
Teleport setup process, we have a lot of content in our
protocol-specific sections, and moving it all into a single section
related to adding resources to a cluster would (a) exceed the maximum
depth for subsections in the nav bar and (b) cause more confusion than
it alleviates.
* Respond to PR feedback
- Create a "Compliance Frameworks" section of "Configure Access" with
the FedRAMP and SOC 2 guides
- Rename "Use Teleport" to "Connect your Client"
- Move the database GUI client guide into "Connect your Client"
* Add redirects
* Fix linter issues
Our architecture section was written almost 5 years ago
and was completely obsolete.
I refactored all of it to be up to date, added Kuberentes
and other resource type references, replaced and created new diagrams.
* Add Cloud instructions to five guides
See #10637
Database Access FAQ
- Add tabbed instructions where answers differ for Cloud/Self-Hosted
- Style/grammar tweaks
Dynamic Registration
- While this guide is edition agnostic, I have added the tctl.mdx
partial so Cloud users know to log in to Teleport before running
tctl commands.
Configuration reference
- The only part that required different instructions for Cloud users
was the reference configuration for the Proxy Service. I have
supplied the values hardcoded in Teleport Cloud.
CLI reference
- Add ScopedBlocks where examples mention proxy.example.com--use a
Cloud tenant address for Cloud readers.
- Light style/grammar edits
Architecture
- This guide is mostly edition agnostic. After the overview diagram,
I used a ScopedBlock to make it clear to Cloud users that the Proxy
Service uses the Teleport Cloud tenant address.
* Respond to PR feedback
Also remove mongo_public_addr from the Cloud proxy_service config,
since this was included incorrectly.
Steven Martin