Merge commit 'f755e2bd45ca994bfac99232b643d85447532262' into lukeshu/…

…tel2.3.7/mono
telepresenceio · Jul 23, 2021 · 18374e5 · 18374e5
2 parents ae66885 + 38be3aa
commit 18374e5
Show file tree

Hide file tree

Showing 33 changed files with 479 additions and 213 deletions.
diff --git a/concepts/devloop.md b/concepts/devloop.md
@@ -6,7 +6,7 @@ The developer experience is the workflow a developer uses to develop, test, depl
 
 Typically this experience has consisted of both an inner dev loop and an outer dev loop. The inner dev loop is where the individual developer codes and tests, and once the developer pushes their code to version control, the outer dev loop is triggered.
 
-The outer dev loop is _everything else_ that happens leading up to release. This includes code merge, automated code review, test execution, deployment, [controlled (canary) release](/docs/argo/latest/concepts/canary/), and observation of results. The modern outer dev loop might include, for example, an automated CI/CD pipeline as part of a [GitOps workflow](/docs/argo/latest/concepts/gitops/#what-is-gitops) and a progressive delivery strategy relying on automated canaries, i.e. to make the outer loop as fast, efficient and automated as possible.
+The outer dev loop is _everything else_ that happens leading up to release. This includes code merge, automated code review, test execution, deployment, [controlled (canary) release](https://www.getambassador.io/docs/argo/latest/concepts/canary/), and observation of results. The modern outer dev loop might include, for example, an automated CI/CD pipeline as part of a [GitOps workflow](https://www.getambassador.io/docs/argo/latest/concepts/gitops/#what-is-gitops) and a progressive delivery strategy relying on automated canaries, i.e. to make the outer loop as fast, efficient and automated as possible.
 
 Cloud-native technologies have fundamentally altered the developer experience in two ways: one, developers now have to take extra steps in the inner dev loop; two, developers need to be concerned with the outer dev loop as part of their workflow, even if most of their time is spent in the inner dev loop.
 

diff --git a/concepts/devworkflow.md b/concepts/devworkflow.md
@@ -1,7 +1,7 @@
 # The changing development workflow
 
-A changing workflow is one of the main challenges for developers adopting Kubernetes. Software development itself isn’t the challenge. Developers can continue to [code using the languages and tools with which they are most productive and comfortable](/resources/kubernetes-local-dev-toolkit/). That’s the beauty of containerized development.
+A changing workflow is one of the main challenges for developers adopting Kubernetes. Software development itself isn’t the challenge. Developers can continue to [code using the languages and tools with which they are most productive and comfortable](https://www.getambassador.io/resources/kubernetes-local-dev-toolkit/). That’s the beauty of containerized development.
 
-However, the cloud-native, Kubernetes-based approach to development means adopting a new development workflow and development environment. Beyond the basics, such as figuring out how to containerize software, [how to run containers in Kubernetes](/docs/kubernetes/latest/concepts/appdev/), and how to deploy changes into containers, for example, Kubernetes adds complexity before it delivers efficiency. The promise of a “quicker way to develop software” applies at least within the traditional aspects of the inner dev loop, where the single developer codes, builds and tests their software. But both within the inner dev loop and once code is pushed into version control to trigger the outer dev loop, the developer experience changes considerably from what many developers are used to.
+However, the cloud-native, Kubernetes-based approach to development means adopting a new development workflow and development environment. Beyond the basics, such as figuring out how to containerize software, [how to run containers in Kubernetes](https://www.getambassador.io/docs/kubernetes/latest/concepts/appdev/), and how to deploy changes into containers, for example, Kubernetes adds complexity before it delivers efficiency. The promise of a “quicker way to develop software” applies at least within the traditional aspects of the inner dev loop, where the single developer codes, builds and tests their software. But both within the inner dev loop and once code is pushed into version control to trigger the outer dev loop, the developer experience changes considerably from what many developers are used to.
 
 In this new paradigm, new steps are added to the inner dev loop, and more broadly, the developer begins to share responsibility for the full life cycle of their software. Inevitably this means taking new workflows and tools on board to ensure that the full life cycle continues full speed ahead.
diff --git a/concepts/faster.md b/concepts/faster.md
@@ -1,10 +1,10 @@
 # Making the remote local: Faster feedback, collaboration and debugging
 
-With the goal of achieving [fast, efficient development](/use-case/local-kubernetes-development/), developers need a set of approaches to bridge the gap between remote Kubernetes clusters and local development, and reduce time to feedback and debugging.
+With the goal of achieving [fast, efficient development](https://www.getambassador.io/use-case/local-kubernetes-development/), developers need a set of approaches to bridge the gap between remote Kubernetes clusters and local development, and reduce time to feedback and debugging.
 
 ## How should I set up a Kubernetes development environment?
 
-[Setting up a development environment](/resources/development-environments-microservices/) for Kubernetes can be much more complex than the set up for traditional web applications. Creating and maintaining a Kubernetes development environment relies on a number of external dependencies, such as databases or authentication.
+[Setting up a development environment](https://www.getambassador.io/resources/development-environments-microservices/) for Kubernetes can be much more complex than the set up for traditional web applications. Creating and maintaining a Kubernetes development environment relies on a number of external dependencies, such as databases or authentication.
 
 While there are several ways to set up a Kubernetes development environment, most introduce complexities and impediments to speed. The dev environment should be set up to easily code and test in conditions where a service can access the resources it depends on.
 

diff --git a/doc-links.yml b/doc-links.yml
@@ -1,76 +1,73 @@
-- title: Home
-  link: /docs/
-
-- title: Products
-  collapsable: false
-  items:
-    - title: Telepresence
-      items:
-        - title: Quick start
-          link: /quick-start
-        - title: Install Telepresence
-          items:
-            - title: Install
-              link: /install/
-            - title: Upgrade
-              link: /install/upgrade/
-            - title: Install Traffic Manager with Helm
-              link: /install/helm/
-            - title: Migrate from legacy Telepresence
-              link: /install/migrate-from-legacy/
-        - title: Core concepts
-          items:
-            - title: The changing development workflow
-              link: /concepts/devworkflow
-            - title: The developer experience and the inner dev loop
-              link: /concepts/devloop
-            - title: 'Making the remote local: Faster feedback, collaboration and debugging'
-              link: /concepts/faster
-            - title: Context propagation
-              link: /concepts/context-prop
-        - title: How do I...
-          items:
-            - title: Intercept a service in your own environment
-              link: /howtos/intercepts
-            - title: Share dev environments with preview URLs
-              link: /howtos/preview-urls
-            - title: Proxy outbound traffic to my cluster
-              link: /howtos/outbound
-            - title: Send requests to an intercepted service
-              link: /howtos/request
-        - title: Technical reference
-          items:
-            - title: Architecture
-              link: /reference/architecture
-            - title: Networking through Virtual Network Interface
-              link: /reference/tun-device
-            - title: Client reference
-              link: /reference/client
-            - title: Laptop-side configuration
-              link: /reference/config
-            - title: Cluster-side configuration
-              link: /reference/cluster-config
-            - title: Using Docker for intercepts
-              link: /reference/docker-run
-            - title: Running Telepresence in a Docker container
-              link: /reference/inside-container
-            - title: Environment variables
-              link: /reference/environment
-            - title: Intercepts
-              link: /reference/intercepts
-            - title: Volume mounts
-              link: /reference/volume
-            - title: DNS resolution
-              link: /reference/dns
-            - title: RBAC
-              link: /reference/rbac
-            - title: Using Telepresence with Linkerd
-              link: /reference/linkerd
-        - title: FAQs
-          link: /faqs
-        - title: Troubleshooting
-          link: /troubleshooting
-        - title: Community
-          link: /community
-        - title: Release Notes
-          link: /release-notes
+ - title: Quick start
+   link: quick-start
+ - title: Install Telepresence
+   items:
+     - title: Install
+       link: install/
+     - title: Upgrade
+       link: install/upgrade/
+     - title: Install Traffic Manager with Helm
+       link: install/helm/
+     - title: Migrate from legacy Telepresence
+       link: install/migrate-from-legacy/
+ - title: Core concepts
+   items:
+     - title: The changing development workflow
+       link: concepts/devworkflow
+     - title: The developer experience and the inner dev loop
+       link: concepts/devloop
+     - title: 'Making the remote local: Faster feedback, collaboration and debugging'
+       link: concepts/faster
+     - title: Context propagation
+       link: concepts/context-prop
+ - title: How do I...
+   items:
+     - title: Intercept a service in your own environment
+       link: howtos/intercepts
+     - title: Share dev environments with preview URLs
+       link: howtos/preview-urls
+     - title: Proxy outbound traffic to my cluster
+       link: howtos/outbound
+     - title: Send requests to an intercepted service
+       link: howtos/request
+ - title: Technical reference
+   items:
+     - title: Architecture
+       link: reference/architecture
+     - title: Client reference
+       link: reference/client
+       items:
+         - title: login
+           link: reference/client/login
+     - title: Laptop-side configuration
+       link: reference/config
+     - title: Cluster-side configuration
+       link: reference/cluster-config
+     - title: Using Docker for intercepts
+       link: reference/docker-run
+     - title: Running Telepresence in a Docker container
+       link: reference/inside-container
+     - title: Environment variables
+       link: reference/environment
+     - title: Intercepts
+       link: reference/intercepts
+     - title: Volume mounts
+       link: reference/volume
+     - title: DNS resolution
+       link: reference/dns
+     - title: RBAC
+       link: reference/rbac
+     - title: Networking through Virtual Network Interface
+       link: reference/tun-device
+     - title: Connection Routing
+       link: reference/routing
+     - title: Using Telepresence with Linkerd
+       link: reference/linkerd
+ - title: FAQs
+   link: faqs
+ - title: Troubleshooting
+   link: troubleshooting
+ - title: Community
+   link: community
+ - title: Release Notes
+   link: release-notes
diff --git a/faqs.md b/faqs.md
@@ -29,7 +29,7 @@ Telepresence currently works natively on macOS and Linux. We are working on a na
 - gRPC
 - GraphQL
 
-If you need another protocol supported, please [drop us a line](/feedback/) to request it.
+If you need another protocol supported, please [drop us a line](https://www.getambassador.io/feedback/) to request it.
 
 ** When using Telepresence to intercept a pod, are the Kubernetes cluster environment variables proxied to my local machine?**
 
@@ -113,12 +113,12 @@ protocol over that TCP connection.
 * GitLab
 * Google
 
-More authentication mechanisms and identity provider support will be added soon. Please [let us know](/feedback/) which providers are the most important to you and your team in order for us to prioritize those.
+More authentication mechanisms and identity provider support will be added soon. Please [let us know](https://www.getambassador.io/feedback/) which providers are the most important to you and your team in order for us to prioritize those.
 
 ** Is Telepresence open source?**
 
  Telepresence will be open source soon, in the meantime it is free to download. We prioritized releasing the binary as soon as possible for community feedback, but are actively working on the open sourcing logistics.
 
 ** How do I share my feedback on Telepresence?**
 
- Your feedback is always appreciated and helps us build a product that provides as much value as possible for our community. You can chat with us directly on our [feedback page](/feedback/), or you can [join our Slack channel](https://a8r.io/Slack) to share your thoughts.
+ Your feedback is always appreciated and helps us build a product that provides as much value as possible for our community. You can chat with us directly on our [feedback page](https://www.getambassador.io/feedback/), or you can [join our Slack channel](https://a8r.io/Slack) to share your thoughts.
diff --git a/howtos/intercepts.md b/howtos/intercepts.md
@@ -165,25 +165,32 @@ You can now:
 
 ## 4. Create a preview URL to only intercept certain requests to your service
 
-When working on a development environment with multiple engineers, you don't want your intercepts to impact your
-teammates. Ambassador Cloud automatically generates a preview URL when creating an intercept if you are logged in. By
-doing so, Telepresence can route only the requests coming from that preview URL to your local environment; the rest will
-be routed to your cluster as usual.
+When working on a development environment with multiple engineers, you
+don't want your intercepts to impact your teammates.  If you are
+[logged in](../../reference/client/login/), then when creating an
+intercept, by default Telpresence will automatically talk to
+Ambassador Cloud to generate a preview URL.  By doing so, Telepresence
+can route only the requests coming from that preview URL to your local
+environment; the rest will be routed to your cluster as usual.
 
 1. Clean up your previous intercept by removing it:
 `telepresence leave <service name>`
 
-2. Login to Ambassador Cloud, a web interface for managing and sharing preview URLs:
-`telepresence login`
+2. Log in to Ambassador Cloud, a web interface for managing and
+   sharing preview URLs:
 
-  ```
-  $ telepresence login
-
-     Launching browser authentication flow...
-     <browser opens, login and choose your org>
-     Login successful.
+   ```console
+   $ telepresence login
+   Launching browser authentication flow...
+   <web browser opens, log in and choose your organization>
+   Login successful.
    ```
 
+   If you are in an environment where Telepresence cannot launch a
+   local browser for you to interact with, you will need to pass the
+   [`--apikey` flag to `telepresence
+   login`](../../reference/client/login/).
+
 3. Start the intercept again:
 `telepresence intercept <service-name> --port <local-port>[:<remote-port>] --env-file <path-to-env-file>`
 
@@ -194,7 +201,7 @@ be routed to your cluster as usual.
    4. **Ingress layer 5 hostname**: If your ingress controller routes traffic based on a domain name (often using the `Host` HTTP header), this is the value you would need to enter here.
 
     <Alert severity="info">
-        Telepresence supports any ingress controller, not just <a href="/docs/edge-stack/latest/tutorials/getting-started/">Ambassador Edge Stack</a>.
+        Telepresence supports any ingress controller, not just <a href="https://www.getambassador.io/docs/edge-stack/latest/tutorials/getting-started/">Ambassador Edge Stack</a>.
     </Alert>
 
    For the example below, you will create a preview URL that will send traffic to the `ambassador` service in the `ambassador` namespace on port `443` using TLS encryption and setting the `Host` HTTP header to `dev-environment.edgestack.me`:

diff --git a/howtos/preview-urls.md b/howtos/preview-urls.md
@@ -32,17 +32,21 @@ Need a sample app to try with preview URLs?  Check out the <a href="../../quick-
 
     * If the service is in a different namespace, specify it with the `--namespace` flag
 
-2. Login to Ambassador Cloud where you can manage and share preview URLs:
-`telepresence login`
-
-  ```
-  $ telepresence login
-
-     Launching browser authentication flow...
-     <browser opens, login and choose your org>
-     Login successful.
+2. Log in to Ambassador Cloud where you can manage and share preview
+   URLs:
+
+   ```console
+   $ telepresence login
+   Launching browser authentication flow...
+   <web browser opens, log in and choose your organization>
+   Login successful.
    ```
 
+   If you are in an environment where Telepresence cannot launch a
+   local browser for you to interact with, you will need to pass the
+   [`--apikey` flag to `telepresence
+   login`](../../reference/client/login/).
+
 3. Start the intercept:
 `telepresence intercept <service-name> --port <TCP-port> --env-file <path-to-env-file>`
 
@@ -118,7 +122,13 @@ Need a sample app to try with preview URLs?  Check out the <a href="../../quick-
 
 7. Share with a teammate.
 
-  You can collaborate with teammates by sending your preview URL to them. They will be asked to log in to Ambassador Cloud if they are not already. Upon log in they must select the same identity provider and org as you are using; that is how they are authorized to access the preview URL (see the [list of supported identity providers](../../faqs/#idps)). When they visit the preview URL, they will see the intercepted service running on your laptop.
+   You can collaborate with teammates by sending your preview URL to
+   them.  They will be asked to log in to Ambassador Cloud if they are
+   not already.  Upon login they must select the same identity
+   provider and org as you are using; that is how they are authorized
+   to access the preview URL (see the [list of supported identity
+   providers](../../faqs/#idps)).  When they visit the preview URL,
+   they will see the intercepted service running on your laptop.
 
 <Alert severity="success">
   <strong>Congratulations!</strong> You have now created a dev environment and shared it with a teammate!  While you and your partner work together to debug your service, the production version remains unchanged to the rest of your team until you commit your changes.

diff --git a/install/migrate-from-legacy.md b/install/migrate-from-legacy.md
@@ -1,6 +1,6 @@
 # Migrate from legacy Telepresence
 
-Telepresence (formerly referenced as Telepresence 2, which is the current major version) has different mechanics and requires a different mental model from [legacy Telepresence 1](https://www.telepresence.io/docs/v1/) when working with local instances of your services.
+Telepresence (formerly referenced as Telepresence 2, which is the current major version) has different mechanics and requires a different mental model from [legacy Telepresence 1](/docs/v1/) when working with local instances of your services.
 
 In legacy Telepresence, a pod running a service was swapped with a pod running the Telepresence proxy. This proxy received traffic intended for the service, and sent the traffic onward to the target workstation or laptop. We called this mechanism "swap-deployment".
 

diff --git a/install/nightly-version-tabs.js b/install/nightly-version-tabs.js
@@ -5,9 +5,9 @@ import AppBar from '@material-ui/core/AppBar';
 import Tabs from '@material-ui/core/Tabs';
 import Tab from '@material-ui/core/Tab';
 import Box from '@material-ui/core/Box';
-import CodeBlock from '../../../../../src/components/CodeBlock';
-import LinuxIcon from '../../../../../src/assets/icons/linux.inline.svg';
-import AppleIcon from '../../../../../src/assets/icons/apple.inline.svg';
+import CodeBlock from '@src/components/CodeBlock';
+import LinuxIcon from '@src/assets/icons/linux.inline.svg';
+import AppleIcon from '@src/assets/icons/apple.inline.svg';
 
 function TabPanel(props) {
   const { children, value, index, ...other } = props;