Adding reloader doc

Baptiste Bonnot 2025-05-15 09:48:40 +02:00
parent e3a8f9126f
commit 22f9a8280a
Signed by: baptiste.bonnot
GPG key ID: 2681291F9206E471

@ -3,6 +3,175 @@
## Variables
{WIP}
## Secret
{WIP}
## Reloader
We have deployed on our cluster https://github.com/stakater/Reloader which
allow your application to automatically be redeployed if a secret or confimaps
change is detected.
Simply annotate your deployment,cronjob,statefullset etc....
```yaml
annotations:
reloader.stakater.com/auto: "true"
```
In the context of the App template bwj-s since we are using a helmRelease you
should annotate the controller. As an example for the echo-server.
```yaml
values:
controllers:
echo-server:
annotations:
reloader.stakater.com/auto: "true"
replicas: 2
strategy: RollingUpdate
```
### 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
##### Edit secrets
You can use the same command used to create new secrets to edit existing files
You can also use [this VSCode plugin](https://marketplace.visualstudio.com/items?itemName=signageos.signageos-vscode-sops)
##### 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 |
=======
# Environments
## Variables
<b style='color: lightblue;'>kustomization/vars</b>
We already introduce you to the vars kustomization earlier. This kustomization
is responsable for loading any variables into your tenant
```mermaid
graph LR
A["<b style='color: #FF8C00;'>tenant-apps</b>"]:::mainEntry -->|Loading| B["<b style='color: #1E90FF;'>vars/kustomization</b>"]:::intermediate
B -->|Loading| C["<b style='color: #32CD32;'>/vars/tenant_name/kustomization.yaml</b>"]:::finalStep
classDef mainEntry fill:#FFFACD,stroke:#FF8C00,stroke-width:2px,stroke-dasharray: 5 5;
classDef intermediate fill:#E0FFFF,stroke:#1E90FF,stroke-width:2px,stroke-dasharray: 5 5;
classDef finalStep fill:#E0FFD1,stroke:#32CD32,stroke-width:2px,stroke-dasharray: 5 5;
```
Once variables are loaded you can referenced them on any Kube Ressources
In our example.
```shell
$ oc get configmap -n tenant-tpl(our_tenant_name)
NAME DATA AGE
example-vars 1 16s
```
### Using varialbes into Flux HelmRelease
From our echo-server HR definition you can see the following sections
*
## Secret
{WIP}
@ -86,12 +255,6 @@ $ 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
##### Edit secrets
You can use the same command used to create new secrets to edit existing files
You can also use [this VSCode plugin](https://marketplace.visualstudio.com/items?itemName=signageos.signageos-vscode-sops)
##### Rewrapping secret
In case add/remove a key secret generated previously will need to be