Add Wiki links in readme/ move doc to wiki
This commit is contained in:
parent
9ad75a99c8
commit
1e21f028cf
1 changed files with 1 additions and 192 deletions
193
README.md
193
README.md
|
|
@ -1,199 +1,8 @@
|
||||||
# Welcome to your ${REPO_NAME}-tenant
|
# Welcome to your ${REPO_NAME}-tenant
|
||||||
|
|
||||||
## Table of contents
|
|
||||||
|
|
||||||
1. [General Overview](#General-Overview)
|
|
||||||
2. [Usefull Links](#Usefull-links)
|
|
||||||
3. [About GitOps](#About-Git-Ops)
|
|
||||||
4. [How To](#How-To)
|
|
||||||
|
|
||||||
## General Overview
|
|
||||||
|
|
||||||
Your namespace have been deployed and is now accessible from openshift cli or
|
|
||||||
directly through the cluster
|
|
||||||
[console](https://console-openshift-console.apps.${CLUSTER_NAME}.kvant.cloud/)
|
|
||||||
|
|
||||||
A dummy application 'echo-server' have been deployed on it. It's a good example
|
|
||||||
on how we recommend to deploy application using our flux setup. You will find
|
|
||||||
several reference in the [How](#How-To) section that README.
|
|
||||||
|
|
||||||
### Usefull links
|
### Usefull links
|
||||||
|
|
||||||
* [Get me to my Namespace](https://console-openshift-console.apps.${CLUSTER_NAME}.kvant.cloud/k8s/cluster/projects/${REPO_NAME}-ns)
|
* [Get me to my Namespace](https://console-openshift-console.apps.${CLUSTER_NAME}.kvant.cloud/k8s/cluster/projects/${REPO_NAME}-ns)
|
||||||
|
* [WIKI](https://git.kvant.cloud/phoenix/tenant-tpl/wiki/Tenant--Wiki)
|
||||||
* [Monitoring](XXXXX)
|
* [Monitoring](XXXXX)
|
||||||
* [Flux Doc](https://fluxcd.io/flux/)
|
|
||||||
* [Sops](https://getsops.io/)
|
|
||||||
|
|
||||||
## 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
|
|
||||||
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.
|
|
||||||
|
|
||||||
### Our Flux Setup
|
|
||||||
|
|
||||||
`Repository Overview`
|
|
||||||
|
|
||||||
```shell
|
|
||||||
.
|
|
||||||
├── echo-server
|
|
||||||
│ ├── app
|
|
||||||
│ │ ├── helmrelease.yaml
|
|
||||||
│ │ └── kustomization.yaml
|
|
||||||
│ └── ks.yaml
|
|
||||||
├── kustomization.yaml
|
|
||||||
├── README.md
|
|
||||||
└── repos
|
|
||||||
├── helm
|
|
||||||
│ ├── bjw-s.yaml
|
|
||||||
│ └── kustomization.yaml
|
|
||||||
└── kustomization.yaml
|
|
||||||
```
|
|
||||||
We use the [`./kustomization.yaml`](${REPO_LINK}/kustomization.yaml) as our
|
|
||||||
main entrypoint that will include our [flux
|
|
||||||
kustomization](https://fluxcd.io/flux/components/kustomize/kustomizations/).
|
|
||||||
|
|
||||||
[`./echo-server/ks.yaml`](${REPO_LINK}/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](${REPO_LINK}/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](${REPO_LINK}/repos/helm/bjw-s.yaml). This chart
|
|
||||||
should cover pretty much all you need to deploy an app.
|
|
||||||
|
|
||||||
|
|
||||||
## How To
|
|
||||||
|
|
||||||
### SSL and DNS
|
|
||||||
|
|
||||||
#### Bring your own certificate and domain
|
|
||||||
|
|
||||||
[WIP]
|
|
||||||
|
|
||||||
#### Use Predefined Domain
|
|
||||||
|
|
||||||
You can spawn any application using your namespace associated Domain.
|
|
||||||
`${REPO_NAME}.pub.${CLUSTER}.kvant.cloud`
|
|
||||||
|
|
||||||
### Storage
|
|
||||||
|
|
||||||
We are providing two type of storage. Object Storage and Volumes.
|
|
||||||
|
|
||||||
|
|
||||||
### Request a Object Storage
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
apiVersion: objectbucket.io/v1alpha1
|
|
||||||
kind: ObjectBucketClaim
|
|
||||||
metadata:
|
|
||||||
name: <CLAIM-NAME>
|
|
||||||
spec:
|
|
||||||
generateBucketName: <YOUR-BUCKET-NAME>
|
|
||||||
storageClassName: openshift-storage.noobaa.io
|
|
||||||
|
|
||||||
```
|
|
||||||
|
|
||||||
### Request a PV
|
|
||||||
|
|
||||||
In the data section of your helmrelease.
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
data:
|
|
||||||
enabled: true
|
|
||||||
type: persistentVolumeClaim
|
|
||||||
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`](${REPO_LINK}/.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`](${REPO_LINK}/.sops.yaml) file and add your public key
|
|
||||||
that you have generated previously.
|
|
||||||
|
|
||||||
|
|
||||||
```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](${REPO_LINK}/scripts/rewrap-secret.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