Skip to content

Commit 02e5cd9

Browse files
committed
Add documentation for 2.19.1
Signed-off-by: Thomas Hallgren <[email protected]>
1 parent 0da7e60 commit 02e5cd9

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

52 files changed

+5460
-0
lines changed

docs/latest

+1
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
v2.19

docs/v2.19/README.md

+23
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,23 @@
1+
# Telepresence Documentation
2+
3+
This folder contains the Telepresence documentation in a format suitable for a versioned folder in the
4+
telepresenceio/telepresence.io repository. The folder will show up in that repository when a new minor revision
5+
tag is created here.
6+
7+
Assuming that a 2.20.0 release is pending, and that a release/v2.20.0 branch has been created, then:
8+
```console
9+
$ export TELEPRESENCE_VERSION=v2.20.0
10+
$ make prepare-release
11+
$ git push origin {,rpc/}v2.20.0 release/v2.20.0
12+
```
13+
14+
will result in a `docs/v2.20` folder with this folder's contents in the telepresenceio/telepresence.io repository.
15+
16+
Subsequent bugfix tags for the same minor tag, i.e.:
17+
```console
18+
$ export TELEPRESENCE_VERSION=v2.20.1
19+
$ make prepare-release
20+
$ git push origin {,rpc/}v2.20.1 release/v2.20.1
21+
```
22+
will not result in a new folder when it is pushed, but it will update the content of the `docs/v2.20` folder to
23+
reflect this folder's content for that tag.

docs/v2.19/community.md

+8
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,8 @@
1+
# Community
2+
3+
## Contributor's guide
4+
Please review our [contributor's guide](https://github.com/telepresenceio/telepresence/blob/release/v2/CONTRIBUTING.md)
5+
on GitHub to learn how you can help make Telepresence better.
6+
7+
## Meetings
8+
Check out our community [meeting schedule](https://github.com/telepresenceio/telepresence/blob/release/v2/MEETING_SCHEDULE.md) for opportunities to interact with Telepresence developers.

docs/v2.19/concepts/devloop.md

+54
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,54 @@
1+
---
2+
title: "The developer and the inner dev loop | Ambassador "
3+
---
4+
5+
# The developer experience and the inner dev loop
6+
7+
## How is the developer experience changing?
8+
9+
The developer experience is the workflow a developer uses to develop, test, deploy, and release software.
10+
11+
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.
12+
13+
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, and observation of results. The modern outer dev loop might include, for example, an automated CI/CD pipeline as part of a GitOps workflow and a progressive delivery strategy relying on automated canaries, i.e. to make the outer loop as fast, efficient and automated as possible.
14+
15+
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.
16+
17+
Engineers now must design and build distributed service-based applications _and_ also assume responsibility for the full development life cycle. The new developer experience means that developers can no longer rely on monolithic application developer best practices, such as checking out the entire codebase and coding locally with a rapid “live-reload” inner development loop. Now developers have to manage external dependencies, build containers, and implement orchestration configuration (e.g. Kubernetes YAML). This may appear trivial at first glance, but this adds development time to the equation.
18+
19+
## What is the inner dev loop?
20+
21+
The inner dev loop is the single developer workflow. A single developer should be able to set up and use an inner dev loop to code and test changes quickly.
22+
23+
Even within the Kubernetes space, developers will find much of the inner dev loop familiar. That is, code can still be written locally at a level that a developer controls and committed to version control.
24+
25+
In a traditional inner dev loop, if a typical developer codes for 360 minutes (6 hours) a day, with a traditional local iterative development loop of 5 minutes — 3 coding, 1 building, i.e. compiling/deploying/reloading, 1 testing inspecting, and 10-20 seconds for committing code — they can expect to make ~70 iterations of their code per day. Any one of these iterations could be a release candidate. The only “developer tax” being paid here is for the commit process, which is negligible.
26+
27+
![traditional inner dev loop](../images/trad-inner-dev-loop.png)
28+
29+
## In search of lost time: How does containerization change the inner dev loop?
30+
31+
The inner dev loop is where writing and testing code happens, and time is critical for maximum developer productivity and getting features in front of end users. The faster the feedback loop, the faster developers can refactor and test again.
32+
33+
Changes to the inner dev loop process, i.e., containerization, threaten to slow this development workflow down. Coding stays the same in the new inner dev loop, but code has to be containerized. The _containerized_ inner dev loop requires a number of new steps:
34+
35+
* packaging code in containers
36+
* writing a manifest to specify how Kubernetes should run the application (e.g., YAML-based configuration information, such as how much memory should be given to a container)
37+
* pushing the container to the registry
38+
* deploying containers in Kubernetes
39+
40+
Each new step within the container inner dev loop adds to overall development time, and developers are repeating this process frequently. If the build time is incremented to 5 minutes — not atypical with a standard container build, registry upload, and deploy — then the number of possible development iterations per day drops to ~40. At the extreme that’s a 40% decrease in potential new features being released. This new container build step is a hidden tax, which is quite expensive.
41+
42+
43+
![container inner dev loop](../images/container-inner-dev-loop.png)
44+
45+
## Tackling the slow inner dev loop
46+
47+
A slow inner dev loop can negatively impact frontend and backend teams, delaying work on individual and team levels and slowing releases into production overall.
48+
49+
For example:
50+
51+
* Frontend developers have to wait for previews of backend changes on a shared dev/staging environment (for example, until CI/CD deploys a new version) and/or rely on mocks/stubs/virtual services when coding their application locally. These changes are only verifiable by going through the CI/CD process to build and deploy within a target environment.
52+
* Backend developers have to wait for CI/CD to build and deploy their app to a target environment to verify that their code works correctly with cluster or cloud-based dependencies as well as to share their work to get feedback.
53+
54+
New technologies and tools can facilitate cloud-native, containerized development. And in the case of a sluggish inner dev loop, developers can accelerate productivity with tools that help speed the loop up again.

docs/v2.19/concepts/docker.md

+104
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,104 @@
1+
# Telepresence with Docker Golden Path
2+
3+
## Why?
4+
5+
It can be tedious to adopt Telepresence across your organization, since in its handiest form, it requires admin access, and needs to get along with any exotic
6+
networking setup that your company may have.
7+
8+
If Docker is already approved in your organization, this Golden path should be considered.
9+
10+
## How?
11+
12+
When using Telepresence in Docker mode, users can eliminate the need for admin access on their machines, address several networking challenges, and forego the need for third-party applications to enable volume mounts.
13+
14+
You can simply add the docker flag to any Telepresence command, and it will start your daemon in a container.
15+
Thus removing the need for root access, making it easier to adopt as an organization
16+
17+
Let's illustrate with a quick demo, assuming a default Kubernetes context named default, and a simple HTTP service:
18+
19+
```cli
20+
$ telepresence connect --docker
21+
Connected to context default (https://default.cluster.bakerstreet.io)
22+
23+
$ docker ps
24+
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
25+
7a0e01cab325 datawire/telepresence:2.12.1 "telepresence connec…" 18 seconds ago Up 16 seconds 127.0.0.1:58802->58802/tcp tp-default
26+
```
27+
28+
This method limits the scope of the potential networking issues since everything stays inside Docker. The Telepresence daemon can be found under the name `tp-<your-context>` when listing your containers.
29+
30+
Start an intercept and a corresponding intercept-handler:
31+
32+
```cli
33+
$ telepresence intercept echo-easy --port 8080:80 --docker-run -- jmalloc/echo-server
34+
Using Deployment echo-easy
35+
Intercept name : echo-easy
36+
State : ACTIVE
37+
Workload kind : Deployment
38+
Destination : 127.0.0.1:8080
39+
Service Port Identifier: proxied
40+
Intercepting : all TCP requests
41+
Echo server listening on port 8080.
42+
```
43+
44+
Using `--docker-run` starts the local container that acts as the intercept handler so that it uses the same network as the container that runs the telepresence daemon. It will also
45+
have the remote volumes mounted in the same way as the remote container that it intercepts.
46+
47+
If you want to curl your remote service, you'll need to do that from a container that shares the daemon container's network. You can find the network using `telepresence status`:
48+
```cli
49+
$ telepresence status | grep 'Container network'
50+
Container network : container:tp-default-default-cn
51+
```
52+
53+
Now curl with a `docker run` that uses that network:
54+
```cli
55+
$ docker run --network container:tp-default-default-cn --rm curlimages/curl echo-easy
56+
% Total % Received % Xferd Average Speed Time Time Time Current
57+
Dload Upload Total Spent Left Speed
58+
100 99 100 99 0 0 21104 0 --:--:-- --:--:-- -Request served by 4b225bc8d6f1
59+
60+
GET / HTTP/1.1
61+
62+
Host: echo-easy
63+
Accept: */*
64+
User-Agent: curl/8.6.0
65+
-:--:-- 24750
66+
```
67+
68+
Similarly, if you want to start your intercept handler manually using `docker run`, you must ensure that it shares the daemon container's network:
69+
70+
```cli
71+
$ docker run \
72+
--network=container:tp-default \
73+
-e PORT=8080 jmalloc/echo-server
74+
Echo server listening on port 8080.
75+
```
76+
77+
### Tip. Use named connections
78+
You can use the `--name` flag to name the connection and get a shorter network name:
79+
80+
```
81+
$ telepresence quit
82+
$ telepresence connect --docker --name a
83+
```
84+
Now, the network name will be `tp-a` instead of `tp-default-default-cn`.
85+
86+
Naming is also very useful when you want to connect to several namespaces simultaneously, e.g.
87+
88+
```
89+
$ telepresence connect --docker --name alpha --namespace alpha
90+
$ telepresence connect --docker --name beta --namespace beta
91+
```
92+
93+
Now, with two connections active, you must pass the flag `--use <name pattern>` to other commands, e.g.
94+
```
95+
$ telepresence intercept echo-easy --use alpha --port 8080:80 --docker-run -- jmalloc/echo-server
96+
```
97+
98+
## Key learnings
99+
100+
* Using the Docker mode of telepresence **does not require root access**, and makes it **easier** to adopt it across your organization.
101+
* It **limits the potential networking issues** you can encounter.
102+
* It **limits the potential mount issues** you can encounter.
103+
* It **enables simultaneous intercepts in multiple namespaces**.
104+
* It leverages **Docker** for your interceptor.

docs/v2.19/concepts/faster.md

+28
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,28 @@
1+
---
2+
title: Install the Telepresence Docker extension | Ambassador
3+
---
4+
# Making the remote local: Faster feedback, collaboration and debugging
5+
6+
With the goal of achieving fast, efficient 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.
7+
8+
## How should I set up a Kubernetes development environment?
9+
10+
Setting up a development environment for Kubernetes can be much more complex than the setup for traditional web applications. Creating and maintaining a Kubernetes development environment relies on a number of external dependencies, such as databases or authentication.
11+
12+
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.
13+
14+
A good way to meet the goals of faster feedback, possibilities for collaboration, and scale in a realistic production environment is the "single service local, all other remote" environment. Developing in a fully remote environment offers some benefits, but for developers, it offers the slowest possible feedback loop. With local development in a remote environment, the developer retains considerable control while using tools like [Telepresence](..) to facilitate fast feedback, debugging and collaboration.
15+
16+
## What is Telepresence?
17+
18+
Telepresence is an open source tool that lets developers [code and test microservices locally against a remote Kubernetes cluster](../quick-start). Telepresence facilitates more efficient development workflows while relieving the need to worry about other service dependencies.
19+
20+
## How can I get fast, efficient local development?
21+
22+
The dev loop can be jump-started with the right development environment and Kubernetes development tools to support speed, efficiency and collaboration. Telepresence is designed to let Kubernetes developers code as though their laptop is in their Kubernetes cluster, enabling the service to run locally and be proxied into the remote cluster. Telepresence runs code locally and forwards requests to and from the remote Kubernetes cluster, bypassing the much slower process of waiting for a container to build, pushing it to registry, and deploying to production.
23+
24+
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.
25+
26+
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.
27+
28+
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.

docs/v2.19/concepts/intercepts.md

+94
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,94 @@
1+
---
2+
title: "Types of intercepts"
3+
description: "Short demonstration of personal vs global intercepts"
4+
---
5+
6+
import React from 'react';
7+
8+
import Alert from '@material-ui/lab/Alert';
9+
import AppBar from '@material-ui/core/AppBar';
10+
import Paper from '@material-ui/core/Paper';
11+
import Tab from '@material-ui/core/Tab';
12+
import TabContext from '@material-ui/lab/TabContext';
13+
import TabList from '@material-ui/lab/TabList';
14+
import TabPanel from '@material-ui/lab/TabPanel';
15+
import Animation from '@src/components/InterceptAnimation';
16+
17+
export function TabsContainer({ children, ...props }) {
18+
const [state, setState] = React.useState({curTab: "personal"});
19+
React.useEffect(() => {
20+
const query = new URLSearchParams(window.location.search);
21+
var interceptType = query.get('intercept') || "regular";
22+
if (state.curTab != interceptType) {
23+
setState({curTab: interceptType});
24+
}
25+
}, [state, setState])
26+
var setURL = function(newTab) {
27+
history.replaceState(null,null,
28+
`?intercept=${newTab}${window.location.hash}`,
29+
);
30+
};
31+
return (
32+
<div class="TabGroup">
33+
<TabContext value={state.curTab}>
34+
<AppBar class="TabBar" elevation={0} position="static">
35+
<TabList onChange={(ev, newTab) => {setState({curTab: newTab}); setURL(newTab)}} aria-label="intercept types">
36+
<Tab class="TabHead" value="regular" label="No intercept"/>
37+
<Tab class="TabHead" value="global" label="Intercept"/>
38+
</TabList>
39+
</AppBar>
40+
{children}
41+
</TabContext>
42+
</div>
43+
);
44+
};
45+
46+
<TabsContainer>
47+
<TabPanel class="TabBody" value="regular">
48+
49+
# No intercept
50+
51+
<Paper style="padding: 1em">
52+
<Animation class="mode-regular" />
53+
54+
This is the normal operation of your cluster without Telepresence.
55+
56+
</Paper>
57+
</TabPanel>
58+
<TabPanel class="TabBody" value="global">
59+
60+
# Intercept
61+
62+
<Paper style="padding: 1em">
63+
<Animation class="mode-global" />
64+
65+
**Intercepts** replace the Kubernetes "Orders" service with the
66+
Orders service running on your laptop. The users see no change, but
67+
with all the traffic coming to your laptop, you can observe and debug
68+
with all your dev tools.
69+
70+
</Paper>
71+
72+
### Creating and using intercepts
73+
74+
1. Creating the intercept: Intercept your service from your CLI:
75+
76+
```shell
77+
telepresence intercept SERVICENAME
78+
```
79+
80+
<Alert severity="info">
81+
82+
Make sure your current kubectl context points to the target
83+
cluster. If your service is running in a different namespace than
84+
your current active context, use or change the `--namespace` flag.
85+
86+
</Alert>
87+
88+
2. Using the intercept: Send requests to your service:
89+
90+
All requests will be sent to the version of your service that is
91+
running in the local development environment.
92+
93+
</TabPanel>
94+
</TabsContainer>

docs/v2.19/doc-links.yml

+73
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,73 @@
1+
- title: Quick start
2+
link: quick-start
3+
- title: Install Telepresence
4+
items:
5+
- title: Install Client
6+
link: install/
7+
- title: Upgrade Client
8+
link: install/upgrade/
9+
- title: Install Traffic Manager
10+
link: install/manager/
11+
- title: Cloud Provider Prerequisites
12+
link: install/cloud/
13+
- title: Core concepts
14+
items:
15+
- title: The developer experience and the inner dev loop
16+
link: concepts/devloop
17+
- title: "Making the remote local: Faster feedback, collaboration and debugging"
18+
link: concepts/faster
19+
- title: Intercepts
20+
link: concepts/intercepts
21+
- title: How do I...
22+
items:
23+
- title: Intercept a service in your own environment
24+
link: howtos/intercepts
25+
- title: Proxy outbound traffic to my cluster
26+
link: howtos/outbound
27+
- title: Work with large clusters
28+
link: howtos/large-clusters
29+
- title: Host a cluster in a local VM
30+
link: howtos/cluster-in-vm
31+
- title: Technical reference
32+
items:
33+
- title: Architecture
34+
link: reference/architecture
35+
- title: Client reference
36+
link: reference/client
37+
- title: Laptop-side configuration
38+
link: reference/config
39+
- title: Cluster-side configuration
40+
link: reference/cluster-config
41+
- title: Using Docker for intercepts
42+
link: reference/docker-run
43+
- title: Running Telepresence in a Docker container
44+
link: reference/inside-container
45+
- title: Environment variables
46+
link: reference/environment
47+
- title: Intercepts
48+
link: reference/intercepts
49+
items:
50+
- title: Configure intercept using CLI
51+
link: reference/intercepts/cli
52+
- title: Volume mounts
53+
link: reference/volume
54+
- title: DNS resolution
55+
link: reference/dns
56+
- title: RBAC
57+
link: reference/rbac
58+
- title: Telepresence and VPNs
59+
link: reference/vpn
60+
- title: Networking through Virtual Network Interface
61+
link: reference/tun-device
62+
- title: Connection Routing
63+
link: reference/routing
64+
- title: FAQs
65+
link: faqs
66+
- title: Troubleshooting
67+
link: troubleshooting
68+
- title: Community
69+
link: community
70+
- title: Release Notes
71+
link: release-notes
72+
- title: Licenses
73+
link: licenses

0 commit comments

Comments
 (0)