typeable/octopod
1
0
Fork 0
mirror of https://github.com/typeable/octopod.git synced 2024-11-22 08:45:20 +03:00
Code Issues Projects Releases Wiki Activity

Resolved some inconsistencies in docs (#126)

Browse Source
This commit is contained in:
iko 2021-10-05 14:22:05 +03:00 committed by GitHub
parent 2867969131
commit cd1d7268b2
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 7 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
docs/en/Octo_user_guide.md
View File

@ -6,15 +6,15 @@ All commands _octo CLI_ executes require the executable to send authenticated re
### `OCTOPOD_URL`
> **_NOTE:_** this argument is **required** for _octo CLI_ to function.
`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`.
### `TLS_CERT_PATH` and `TLS_KEY_PATH`
### `OCTO_AUTHORIZATION_HEADER`
`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_.
`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:
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`.
```bash
kubectl -n octopod get secret octopod-cli-auth-secret -o jsonpath='{.data.cli-secret}' | base64 -d
```
## Commands

2
docs/en/Overview.md
View File

@ -39,7 +39,7 @@ This is **a lot** of overhead just to test the color of a button. Note that most
_Octopod_ aims to factor out the common parts of creating and deploying a staging.
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.
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.
![](../diagrams/images/sample_deployment.png)

2
docs/en/Technical_architecture.md
View File

@ -37,7 +37,7 @@ The server receives commands from the [_octo CLI_](#-octo-cli) and the [_Web UI_
### 🎛 octo CLI
_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).
_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).
It can perform all actions available in the [_Web UI_](#-web-ui), but also has access to view deployment logs.