Tenant Gitea template
Find a file Use this template
2024-10-25 17:52:49 +02:00
.gitea Update template rules 2024-10-25 17:51:05 +02:00
echo-server Correct Variables 2024-10-25 17:52:49 +02:00
repos Correct Variables 2024-10-25 17:52:49 +02:00
.sops.yaml WIP Readme 2024-10-25 17:49:08 +02:00
kustomization.yaml WIP Readme 2024-10-25 17:49:08 +02:00
README.md Correct Variables 2024-10-25 17:52:49 +02:00

Welcome to your ${REPO_NAME}-tenant

Table of contents

  1. General Overview
  2. Usefull Links
  3. About GitOps
  4. How To

General Overview

Your namespace have been deployed and is now accessible from openshift cli or directly through the cluster console

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 section that README.

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 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

.
├── 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 as our main entrypoint that will include our flux kustomization.

./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 is example of a simple application that is accessible at a given URI. It use the helmchart template 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

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.

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 as you encryption engine.

We have already Setup a key Private key dedicated to your namespace that will be able to decrypt any secret that you is in your git repository.

./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:

Create your own key
Linux
mkdir -p $XDG_CONFIG_HOME/sops/age
age-keygen -o $XDG_CONFIG_HOME/sops/age/keys.txt
MacOS
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 file and add your public key that you have generated previously.

$ 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 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.

💥 INFOS
You can have as many .sops.yaml file as you want in your repository