Restructure wiki
parent
b48755f326
commit
006fa694b1
GPG key ID:
2681291F9206E471
2 changed files with 214 additions and 118 deletions
101
Environments.md
Normal file
101
Environments.md
Normal file
|
|
@ -0,0 +1,101 @@
|
|||
# Environments
|
||||
|
||||
## Variables
|
||||
{WIP}
|
||||
|
||||
## Secret
|
||||
|
||||
{WIP}
|
||||
### Encryption
|
||||
|
||||
In regard of GitOps there is multiple way to handle encryption of secret that
|
||||
live within a git repository. We recommending you to use [SOPS](https://getsops.io/) as
|
||||
you encryption engine.
|
||||
|
||||
We have already Setup a key [Private key](Path_to_sops_private_key) dedicated
|
||||
to your namespace that will be able to decrypt any secret that you is in your git repository.
|
||||
|
||||
|
||||
[`./sops.yaml`](https://git.kvant.cloud/phoenix/tenant-tpl/src/branch/main/.sops.yaml) is the configuration file that will
|
||||
handle how you secret will be encrypted while using sops.
|
||||
|
||||
#### Quick Start
|
||||
|
||||
To work with secret you'll need:
|
||||
* [SOPS stable release](https://github.com/getsops/sops/releases)
|
||||
* [age](https://age-encryption.org/)
|
||||
|
||||
##### Create your own key
|
||||
|
||||
###### Linux
|
||||
|
||||
```shell
|
||||
mkdir -p $XDG_CONFIG_HOME/sops/age
|
||||
age-keygen -o $XDG_CONFIG_HOME/sops/age/keys.txt
|
||||
```
|
||||
###### MacOS
|
||||
|
||||
```shell
|
||||
mkdir -p "$HOME/Library/Application Support/sops/age"
|
||||
age-keygen -o "$HOME/Library/Application Support/sops/age/keys.txt"
|
||||
```
|
||||
##### Propagate your Public key
|
||||
|
||||
Edit the [`./sops.yaml`](https://git.kvant.cloud/phoenix/tenant-tpl/src/branch/main/.sops.yaml) file and add your public key
|
||||
that you have generated previously.
|
||||
|
||||
Please notice that you can copy this file into any subfolder of your project in case you need to have different keys depending
|
||||
on your secrets file. This is useful to limit who has access to the production secrets while all developers might have access to
|
||||
the dev secrets.
|
||||
|
||||
|
||||
```shell
|
||||
$ cat .sops.yaml
|
||||
---
|
||||
|
||||
# This example uses YAML anchors which allows reuse of multiple keys
|
||||
# without having to repeat yourself.
|
||||
# Also see https://github.com/Mic92/dotfiles/blob/master/nixos/.sops.yaml
|
||||
# for a more complex example.
|
||||
keys:
|
||||
age:
|
||||
- &cluster_age_key age13jnzxrtrghlh8zvc9q3d8yd2a9xdp8jset72l8dwz6pept3j3c0qkmxd47
|
||||
- &YOUR_KEY_NAME <PUBLIC_KEY>
|
||||
creation_rules:
|
||||
- path_regex: .+secret(\.sops)?\.ya?ml
|
||||
input_type: yaml
|
||||
encrypted_regex: ^(data|stringData)$
|
||||
key_groups:
|
||||
- age: &key_groups
|
||||
- *cluster_age_key
|
||||
- *YOUR_KEY_NAME
|
||||
- path_regex: .+secret(\.sops)?\.env
|
||||
input_type: env
|
||||
key_groups:
|
||||
- age: *key_groups
|
||||
stores:
|
||||
yaml:
|
||||
indent: 2
|
||||
```
|
||||
##### Create your first secret
|
||||
|
||||
```
|
||||
$ sops name_of_you_file.secret.sops.yaml
|
||||
|
||||
```
|
||||
You can then deploy it the cluster will be able to Decrypt it using it's public
|
||||
key
|
||||
|
||||
##### Rewrapping secret
|
||||
|
||||
In case add/remove a key secret generated previously will need to be
|
||||
reencrypted with the appropriate key. We have place a [shell
|
||||
script](https://git.kvant.cloud/phoenix/tenant-tpl/src/branch/main/scripts/rewrap-secrets.sh) that will do that for you.
|
||||
|
||||
It will reencrypt all the secret that it will find in folder and subfolder
|
||||
following the .sops.yaml rules files of your directory.
|
||||
|
||||
|
||||
| :boom: INFOS |
|
||||
|:----------------------------|
|
||||
| You can have as many .sops.yaml file as you want in your repository |
|
||||
231
Tenant--Wiki.md
231
Tenant--Wiki.md
|
|
@ -4,11 +4,13 @@
|
|||
## About Git Ops
|
||||
|
||||
This repository is already fully configured to work in a GitOps Way
|
||||
(https://www.gitops.tech/#what-is-gitops). We use [`FluxCD`](#Flux-Doc) has our
|
||||
(https://www.gitops.tech/#what-is-gitops). We use [`FluxCD`](https://fluxcd.io/flux/) has our
|
||||
GitOps Tools. We highly recommand to take advantage of that setup to deploy
|
||||
your application however it's not mandatory and you can use another way to ship
|
||||
them.
|
||||
|
||||
All example above is taking tenant-tpl as a our 'Tenant name'
|
||||
|
||||
### Our Flux Setup
|
||||
|
||||
`Repository Overview`
|
||||
|
|
@ -16,36 +18,122 @@ them.
|
|||
```shell
|
||||
.
|
||||
├── echo-server
|
||||
│ ├── app
|
||||
│ │ ├── helmrelease.yaml
|
||||
│ │ └── kustomization.yaml
|
||||
│ └── ks.yaml
|
||||
│ ├── app
|
||||
│ │ └── helmrelease.yaml
|
||||
│ └── ks.yaml
|
||||
├── kustomization.yaml
|
||||
├── README.md
|
||||
└── repos
|
||||
├── helm
|
||||
│ ├── bjw-s.yaml
|
||||
│ └── kustomization.yaml
|
||||
└── kustomization.yaml
|
||||
├── repos
|
||||
│ ├── helm
|
||||
│ │ └── bjw-s.yaml
|
||||
│ └── ks.yaml
|
||||
├── scripts
|
||||
│ └── rewrap-secrets.sh
|
||||
└── vars
|
||||
├── ks.yaml
|
||||
└── tenant-tpl
|
||||
├── cluster-settings.yaml
|
||||
└── README.md
|
||||
|
||||
```
|
||||
We use the [`./kustomization.yaml`](https://git.kvant.cloud/phoenix/tenant-tpl/src/branch/main/kustomization.yaml) as our
|
||||
main entrypoint that will include our [flux
|
||||
kustomization](https://fluxcd.io/flux/components/kustomize/kustomizations/).
|
||||
|
||||
[`./echo-server/ks.yaml`](https://git.kvant.cloud/phoenix/tenant-tpl/src/branch/main/echo-server/ks.yaml) Is a good example
|
||||
on how create new flux kustomization definition you could use it as a template
|
||||
for your next kusto. You'll find inside a breakdown and comments on line that
|
||||
are mandatory.
|
||||
|
||||
The echo-server [helmrelease](https://git.kvant.cloud/phoenix/tenant-tpl/src/branch/main/echo-server/app/helmrelease.yaml) is
|
||||
example of a simple application that is accessible at a given URI. It use the
|
||||
helmchart template [bjw-s.yaml](https://git.kvant.cloud/phoenix/tenant-tpl/src/branch/main/repos/helm/bjw-s.yaml). This chart
|
||||
should cover pretty much all you need to deploy an app.
|
||||
`Flux Organisation`
|
||||
|
||||
|
||||
## How To
|
||||
`$ flux get all -n tenant-tpl`
|
||||
|
||||
### SSL and DNS
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A["<b>Git Repository: tenant-repos</b>"]:::gitRepo
|
||||
|
||||
subgraph Kustomization
|
||||
B["<b style='color: orange;'>kustomization/tenant-apps</b>"]:::mainEntry
|
||||
end
|
||||
|
||||
F["<b style='color: teal;'>helmrepository/bjw-s</b>"]:::helmRepo
|
||||
G["<b style='color: violet;'>helmchart/tenant-tpl-echo-server</b>"]:::helmChart
|
||||
H["<b style='color: tomato;'>helmrelease/echo-server</b>"]:::helmRelease
|
||||
|
||||
I["<b style='color: lightcoral;'>kustomization/echo-server</b>"]:::echoServer
|
||||
J["<b style='color: lightgreen;'>kustomization/repos-sync</b>"]:::reposSync
|
||||
K["<b style='color: lightblue;'>kustomization/vars</b>"]:::vars
|
||||
|
||||
A --> B
|
||||
B --> C["<b style='color: lightblue;'>vars/ks.yaml</b>"]
|
||||
B --> D["<b style='color: lightgreen;'>repos/ks.yaml</b>"]
|
||||
B --> E["<b style='color: lightcoral;'>echo-server/ks.yaml</b>"]
|
||||
E --> I
|
||||
D --> J
|
||||
C --> K
|
||||
I --> H
|
||||
J --> F
|
||||
K --> G
|
||||
|
||||
classDef gitRepo fill:#d1e7dd,stroke:#0f5132,stroke-width:2px;
|
||||
classDef mainEntry fill:#fff3cd,stroke:#856404,stroke-width:2px;
|
||||
classDef helmRepo fill:#d1ecf1,stroke:#0c5460,stroke-width:2px;
|
||||
classDef helmChart fill:#ede7f6,stroke:#4a148c,stroke-width:2px;
|
||||
classDef helmRelease fill:#f8d7da,stroke:#721c24,stroke-width:2px;
|
||||
classDef echoServer fill:#ffe6e6,stroke:#cc0000,stroke-width:2px;
|
||||
classDef reposSync fill:#d4edda,stroke:#155724,stroke-width:2px;
|
||||
classDef vars fill:#d1ecf1,stroke:#0c5460,stroke-width:2px;
|
||||
|
||||
```
|
||||
<b style='color: orange;'>tenant-apps</b> Is the main entry point and is not
|
||||
defined within your git Repository but while we are creating the tenant for
|
||||
you.
|
||||
|
||||
|
||||
<b style='color: lightcoral;'>kustomization/echo-server</b>
|
||||
This is example application. While it's just an example it already does quite a
|
||||
lot such as.
|
||||
* Deploying an application using the `bjw-s` helm chart.
|
||||
* Exposing the application to the internet using a SSL certificate.
|
||||
* Requesting persistent storage
|
||||
|
||||
[`./echo-server/app/helmrelease.yaml`](https://git.kvant.cloud/phoenix/tenant-tpl/src/branch/main/echo-server/app/helmrelease.yaml)
|
||||
|
||||
**This is a very good example to begin with and we will refer to it very much.**
|
||||
|
||||
<b style='color: lightgreen;'>kustomization/repos-sync</b>
|
||||
If you ever need to import a helm repository in your namespace this is the
|
||||
right place. You'll find an already working example with the `bjw-s` repository
|
||||
imported.
|
||||
|
||||
|
||||
<b style='color: lightblue;'>kustomization/vars</b>
|
||||
|
||||
Here we are defining our applications secret or variables. Please refers to [vars](var)
|
||||
|
||||
### Usefull Links
|
||||
|
||||
* [flux kustomization](https://fluxcd.io/flux/components/kustomize/kustomizations/)
|
||||
* [bjw-s template helmchart](https://bjw-s.github.io/helm-charts/docs/app-template/)
|
||||
|
||||
# How to
|
||||
|
||||
|
||||
```toctree
|
||||
:maxdepth: 2
|
||||
:caption: Contents
|
||||
|
||||
Environments
|
||||
Variables
|
||||
Secret
|
||||
Encryption
|
||||
Storage
|
||||
Persistent Storage
|
||||
Object Storage
|
||||
Database
|
||||
PostgreSQL
|
||||
MongoDB
|
||||
Exposing your application
|
||||
SSL
|
||||
Certificate
|
||||
Domain
|
||||
|
||||
|
||||
|
||||
# SSL and DNS
|
||||
|
||||
#### Bring your own certificate and domain
|
||||
|
||||
|
|
@ -85,96 +173,3 @@ data:
|
|||
accessMode: ReadWriteOnce
|
||||
size: 1Gi
|
||||
```
|
||||
### Secret Encryption
|
||||
|
||||
In regard of GitOps there is multiple way to handle encryption of secret that
|
||||
live within a git repository. We recommending you to use [SOPS](https://getsops.io/) as
|
||||
you encryption engine.
|
||||
|
||||
We have already Setup a key [Private key](Path_to_sops_private_key) dedicated
|
||||
to your namespace that will be able to decrypt any secret that you is in your git repository.
|
||||
|
||||
|
||||
[`./sops.yaml`](https://git.kvant.cloud/phoenix/tenant-tpl/src/branch/main/.sops.yaml) is the configuration file that will
|
||||
handle how you secret will be encrypted while using sops.
|
||||
|
||||
#### Quick Start
|
||||
|
||||
To work with secret you'll need:
|
||||
* [SOPS stable release](https://github.com/getsops/sops/releases)
|
||||
* [age](https://age-encryption.org/)
|
||||
|
||||
##### Create your own key
|
||||
|
||||
###### Linux
|
||||
|
||||
```shell
|
||||
mkdir -p $XDG_CONFIG_HOME/sops/age
|
||||
age-keygen -o $XDG_CONFIG_HOME/sops/age/keys.txt
|
||||
```
|
||||
###### MacOS
|
||||
|
||||
```shell
|
||||
mkdir -p "$HOME/Library/Application Support/sops/age"
|
||||
age-keygen -o "$HOME/Library/Application Support/sops/age/keys.txt"
|
||||
```
|
||||
##### Propagate your Public key
|
||||
|
||||
Edit the [`./sops.yaml`](https://git.kvant.cloud/phoenix/tenant-tpl/src/branch/main/.sops.yaml) file and add your public key
|
||||
that you have generated previously.
|
||||
|
||||
Please notice that you can copy this file into any subfolder of your project in case you need to have different keys depending
|
||||
on your secrets file. This is useful to limit who has access to the production secrets while all developers might have access to
|
||||
the dev secrets.
|
||||
|
||||
|
||||
```shell
|
||||
$ cat .sops.yaml
|
||||
---
|
||||
|
||||
# This example uses YAML anchors which allows reuse of multiple keys
|
||||
# without having to repeat yourself.
|
||||
# Also see https://github.com/Mic92/dotfiles/blob/master/nixos/.sops.yaml
|
||||
# for a more complex example.
|
||||
keys:
|
||||
age:
|
||||
- &cluster_age_key age13jnzxrtrghlh8zvc9q3d8yd2a9xdp8jset72l8dwz6pept3j3c0qkmxd47
|
||||
- &YOUR_KEY_NAME <PUBLIC_KEY>
|
||||
creation_rules:
|
||||
- path_regex: .+secret(\.sops)?\.ya?ml
|
||||
input_type: yaml
|
||||
encrypted_regex: ^(data|stringData)$
|
||||
key_groups:
|
||||
- age: &key_groups
|
||||
- *cluster_age_key
|
||||
- *YOUR_KEY_NAME
|
||||
- path_regex: .+secret(\.sops)?\.env
|
||||
input_type: env
|
||||
key_groups:
|
||||
- age: *key_groups
|
||||
stores:
|
||||
yaml:
|
||||
indent: 2
|
||||
```
|
||||
##### Create your first secret
|
||||
|
||||
```
|
||||
$ sops name_of_you_file.secret.sops.yaml
|
||||
|
||||
```
|
||||
You can then deploy it the cluster will be able to Decrypt it using it's public
|
||||
key
|
||||
|
||||
##### Rewrapping secret
|
||||
|
||||
In case add/remove a key secret generated previously will need to be
|
||||
reencrypted with the appropriate key. We have place a [shell
|
||||
script](https://git.kvant.cloud/phoenix/tenant-tpl/src/branch/main/scripts/rewrap-secrets.sh) that will do that for you.
|
||||
|
||||
It will reencrypt all the secret that it will find in folder and subfolder
|
||||
following the .sops.yaml rules files of your directory.
|
||||
|
||||
|
||||
| :boom: INFOS |
|
||||
|:----------------------------|
|
||||
| You can have as many .sops.yaml file as you want in your repository |
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue