extern/zrok
1
1
Fork 0
mirror of https://github.com/openziti/zrok.git synced 2025-06-27 05:01:26 +02:00
Code Issues Packages Projects Releases Wiki Activity

fixed enable steps

Browse Source
This commit is contained in:
Michael Quigley 2022-08-17 13:47:58 -04:00
parent b45f01b34a
commit 04267936cf
No known key found for this signature in database
GPG Key ID: 9B60314A9DD20A62
1 changed files with 8 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
docs/overview-v0.1.md
View File

@ -41,6 +41,7 @@ At a high level, the `zrok` stack looks like this:
Let's discuss a couple of the flows through the above use case and talk about what's happening.
### The `zrok enable` Flow
When a new `zrok` user signs up for an account, they are issued a "secret token". This secret token is used to enable shell access to `zrok http` from the command line.
@ -48,10 +49,12 @@ When a new `zrok` user signs up for an account, they are issued a "secret token"
When the user runs `zrok enable` from their shell, here's what happens:
1. The `zrok enable` client reaches out with an enable request to the `zrok` controller.
2. The `zrok` controller creates a new Ziti identity for the environment, enrolls it, and returns the entire SDK configuration back to the `zrok enable` client.
3. The `zrok enable` client then stores the Ziti identity along with a few other housekeeping details in the user's `~/.zrok` folder (we refer to this as `zrokdir`, conceptually in the code).
4. With the Ziti identity and configuration details stored in the user's `zrokdir`, the user is then able to create any number of binding endpoints using the `zrok http` command.
5. The `zrok` controller creates an edge router policy associating the new Ziti identity with `#all` edge routers.
2. The `zrok` controller creates a new Ziti identity for the environment and enrolls it.
3. The `zrok` controller creates an edge router policy associating the new Ziti identity with `#all` edge routers.
4. The `zrok` controller returns the entire SDK configuration back to the `zrok enable` client.
5. The `zrok enable` client then stores the Ziti identity along with a few other housekeeping details in the user's `~/.zrok` folder (we refer to this as `zrokdir`, conceptually in the code).
6. With the Ziti identity and configuration details stored in the user's `zrokdir`, the user is then able to create any number of binding endpoints using the `zrok http` command.
### The `zrok http` Flow
@ -70,6 +73,7 @@ When a `zrok` user issues a `zrok http` command for an endpoint, here's what hap
When the user terminates the `zrok http` client, these resources are removed from the Ziti network.
### `zrok proxy` and HTTP Clients
When `zrok http` exposes a service and returns a URL, that URL is designed to be sent to a `zrok` listening endpoint (`zrok proxy`, currently). The `zrok proxy` is a stateless SDK client with an HTTP(S) listener exposed to the public internet.