Skip to content

Commit

Permalink
Temp update to catch up with relesase/v2.21 branch.
Browse files Browse the repository at this point in the history
Signed-off-by: Thomas Hallgren <[email protected]>
  • Loading branch information
thallgren committed Dec 8, 2024
1 parent 385ca6b commit 63f0bc0
Show file tree
Hide file tree
Showing 6 changed files with 92 additions and 62 deletions.
2 changes: 0 additions & 2 deletions versioned_docs/version-2.21/concepts/faster.md
Original file line number Diff line number Diff line change
Expand Up @@ -27,5 +27,3 @@ The dev loop can be jump-started with the right development environment and Kube
A rapid and continuous feedback loop is essential for productivity and speed; Telepresence enables the fast, efficient feedback loop to ensure that developers can access the rapid local development loop they rely on without disrupting their own or other developers' workflows. Telepresence safely intercepts traffic from the production cluster and enables near-instant testing of code and local debugging in production.

Telepresence works by deploying a two-way network proxy in a pod running in a Kubernetes cluster. This pod proxies data from the Kubernetes environment (e.g., TCP/UDP connections, environment variables, volumes) to the local process. This proxy can intercept traffic meant for the service and reroute it to a local copy, which is ready for further (local) development.

The intercept proxy works thanks to context propagation, which is most frequently associated with distributed tracing but also plays a key role in controllable intercepts.
12 changes: 6 additions & 6 deletions versioned_docs/version-2.21/howtos/intercepts.md
Original file line number Diff line number Diff line change
Expand Up @@ -49,7 +49,7 @@ network telepresence, and remote mounts must be made relative to a specific moun

3. Get the name of the port you want to intercept on your service:
`kubectl get service &lt;service name&gt; --output yaml`.

If we assume that the service and deployment use the same name:

```console
Expand Down Expand Up @@ -85,7 +85,7 @@ network telepresence, and remote mounts must be made relative to a specific moun
```
5. &lt;a name="start-local-instance"&gt;&lt;/a&gt;Start your local application using the environment variables retrieved in the previous step.
The following are some examples of how to pass the environment variables to your local process:
The following are some examples of how to pass the environment variables to your local process:
* **Visual Studio Code:** specify the path to the environment variables file in the `envFile` field of your configuration.
* **JetBrains IDE (IntelliJ, WebStorm, PyCharm, GoLand, etc.):** use the [EnvFile plugin](https://plugins.jetbrains.com/plugin/7861-envfile).
Expand Down Expand Up @@ -148,9 +148,9 @@ present challenges in terms of toolchain integration, debugging, and the overall
telepresence intercept &lt;workload-name&gt; --port [&lt;local-port&gt;][:&lt;remote-port&gt;] --docker-run -- &lt;your local container&gt;.
```
* For `--port`: If the intercepted service exposes multiple ports, specify the service port you want to intercept after a colon.
The local port can be empty to default to the same as the targeted container port.
* For `--port`: If the intercepted service exposes multiple ports, specify the service port you want to intercept after a colon.
The local port can be empty to default to the same as the targeted container port.
The example below shows Telepresence intercepting traffic going to deployment `example-app`. The local container inherits
the environment and the volume mounts from the targeted container, and requests to the service on port `http` in the
cluster get routed to the local container and the environment variables of the service are written to `~/example-app-intercept.env`.
Expand Down Expand Up @@ -183,7 +183,7 @@ but you don't wish to intercept any traffic intended for the targeted workload.
comes into play. Just like intercept, it will make the environment and mounted containers of the targeted container available locally,
but it will not intercept any traffic.
This example assumes that you have the `example-app`
This example assumes that you have the `example-app`
### Running everything directly on the workstation
Expand Down
41 changes: 40 additions & 1 deletion versioned_docs/version-2.21/install/manager.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,13 @@ hide_table_of_contents: true

# Install/Uninstall the Traffic Manager

Telepresence uses a traffic manager to send/receive cloud traffic to the user. Telepresence uses [Helm](https://helm.sh) under the hood to install the traffic manager in your cluster. The `telepresence` binary embeds both `helm` and a helm-chart for a traffic-manager that is of the same version as the binary.
Telepresence uses a traffic manager to send/receive cloud traffic to the user. Telepresence uses [Helm](https://helm.sh) under the
hood to install the traffic manager in your cluster. The `telepresence` binary embeds both `helm` and a helm-chart for a
traffic-manager that is of the same version as the binary.

The Telepresence Helm chart documentation is published at [ArtifactHUB](https://artifacthub.io/packages/helm/telepresence-oss/telepresence-oss).

You can also use `helm` command directly, see [Install With Helm](#install-with-helm) for more details.

## Prerequisites

Expand Down Expand Up @@ -180,3 +186,36 @@ Telepresence Traffic Manager does require some [RBAC](../reference/rbac.md) for
To make it easier for operators to introspect / manage RBAC separately, you can use `rbac.only=true` to
only create the rbac-related objects.
Additionally, you can use `clientRbac.create=true` and `managerRbac.create=true` to toggle which subset(s) of RBAC objects you wish to create.

## Install with Helm

Before you begin, you must ensure that the [helm command](https://helm.sh/docs/intro/install/) is installed.

The Telepresence Helm chart is published at GitHub in the ghcr.io repository.

### Installing

Install the latest stable version of the traffic-manager into the default "ambassador" namespace with the following command:

```bash
helm install --create-namespace --namespace ambassador traffic-manager oci://ghcr.io/telepresenceio/telepresence-oss
```

### Upgrading/Downgrading

Use this command if you installed the Traffic Manager into the "ambassador" namespace, and you just wish to upgrade it
to the latest version without changing any configuration values:

```bash
helm upgrade --namespace ambassador --reuse-values traffic-manager oci://ghcr.io/telepresenceio/telepresence-oss
```

If you want to upgrade (or downgrade) the Traffic Manager to a specific version, add a `--version` flag with the version
number to the upgrade command, e.g.: `--version v2.20.3`.

### Uninstalling

Use the following command to uninstall the Traffic Manager:
```bash
helm uninstall --namespace ambassador traffic-manager
```
Loading

0 comments on commit 63f0bc0

Please sign in to comment.