# Welcome to your ${REPOS_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

* [Get me to my Namespace](https://console-openshift-console.apps.${CLUSTER_NAME}.kvant.cloud/k8s/cluster/projects/${REPOS_NAME}-ns)
* [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.
`${REPOS_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 |