git.iko.soy/typeable/octopod
on master help sign in
Resolved some inconsistencies in docs (#126)
commitcd1d7268b2f1a68e6cee0a6a01cd3c4cc36ea7b7 authoriko <ilyakooo0@gmail.com> dateTue 5 Oct 2021, 14:22 (5 years ago) parent2867969
3 files changed+7−7
compare with master
unifiedsplit
docs/en/Octo_user_guide.md+5−5 docs/en/Overview.md+1−1 docs/en/Technical_architecture.md+1−1
docs/en/Octo_user_guide.md+5−5
@@ -6,15 +6,15 @@ All commands _octo CLI_ executes require the executable to send authenticated re
66
77### `OCTOPOD_URL`
88
9−> **_NOTE:_** this argument is **required** for _octo CLI_ to function.
10−
119`OCTOPOD_URL` is an environment variable _octo CLI_ reads to find your particular _Octopod Server_ installation. For example, it could contain `https://octopod-power-app.example.com:443`.
1210
13−### `TLS_CERT_PATH` and `TLS_KEY_PATH`
11+### `OCTO_AUTHORIZATION_HEADER`
1412
15−`TLS_CERT_PATH` should contain the path to the TLS certificate you generated when setting up _Octopod Server_ and `TLS_KEY_PATH` should contain the path to the TLS key you generated when setting up _Octopod Server_. These files are used to authenticate the requests to _Octopod Server_.
13+`OCTO_AUTHORIZATION_HEADER` is an environment variable that should contain the `Authorization` header to use to authenticate requests to your Octopod server. You can obtain the header value by running the following command after installing Octopod:
1614
17−If these variables are not set, then _octo CLI_ tries to read the certificate from the path `./cert.pem`, and the key from the path `./key.pem`.
15+```bash
16+kubectl -n octopod get secret octopod-cli-auth-secret -o jsonpath='{.data.cli-secret}' | base64 -d
17+```
1818
1919## Commands
2020
docs/en/Overview.md+1−1
@@ -39,7 +39,7 @@ This is **a lot** of overhead just to test the color of a button. Note that most
3939
4040_Octopod_ aims to factor out the common parts of creating and deploying a staging.
4141
42−If developers were using _Octopod_ to deploy stagings, literally the only thing needed from them would be to specify the git commit hash in the _Web UI_ of _Octopod_. The common infrastructure (shown in **blue**) which is the same across different stagings would not require any additional setup. The only difference between the two button feature staging would be the actual server that required changing the color. And that server is most likely also built in a uniform way, meaning it can be done automatically.
42+If developers were using _Octopod_ to deploy stagings, literally the only thing needed from them would be to specify the git commit hash (if you use git commit hashes as tags for your docker images) in the _Web UI_ of _Octopod_. The common infrastructure (shown in **blue**) which is the same across different stagings would not require any additional setup. The only difference between the two button feature staging would be the actual server that required changing the color. And that server is most likely also built in a uniform way, meaning it can be done automatically.
4343
4444![](../diagrams/images/sample_deployment.png)
4545
docs/en/Technical_architecture.md+1−1
@@ -37,7 +37,7 @@ The server receives commands from the [_octo CLI_](#-octo-cli) and the [_Web UI_
3737
3838### 🎛 octo CLI
3939
40−_octo CLI_ – a command-line interface used to manage deployments. It sends HTTP/1.1 requests to [_Octopod Server_](#-octopod-server). The requests are [authenticated through SSL certificates](Security_model.md#octo-cli-authentication).
40+_octo CLI_ – a command-line interface used to manage deployments. It sends HTTP/1.1 requests to [_Octopod Server_](#-octopod-server). The requests are [authenticated through the `Authorization` header](Security_model.md#octo-cli-authentication).
4141
4242It can perform all actions available in the [_Web UI_](#-web-ui), but also has access to view deployment logs.
4343