Deploying resources on Firestartr Documentation

Mon, 01 Jan 0001 00:00:00 +0000

Introduction#

Lately, we have the need to migrate old state repos to our new app state repo structure. This article will describe the steps needed to be followed to properly do this migration. Note that the following steps should be done in a dev or pre environment first, and once everything is working then applied to the pro environment (during an intervention window which must be request beforehand).

Step 0: 🛠️ prerrequisites#

Go to the charts repo of the organization and locate the deployment.yaml file (or equivalent, such as statefulset.yaml, daemonset.yaml, etc.) for the application of the repo you are updating. Update the following line in the annotations of the deployment (not the pod):

Mon, 01 Jan 0001 00:00:00 +0000

🔍 Overview#

This documentation focuses on the structure and purpose of application repositories for deploying workloads in Kubernetes. Each application has its own dedicated repository to ensure isolation, clear organization, and streamlined management of configuration and deployment files.

The repository serves as the single source of truth for the application’s configuration across clusters, tenants, and environments.

📂 Repository directory structure#

Applications are organized in the following directory structure within the Git repository:

Mon, 01 Jan 0001 00:00:00 +0000

🔍 Overview#

This repository is dedicated to managing system services for Kubernetes clusters, referred to as sys-services. These services are critical components that ensure the smooth operation of the Kubernetes clusters, such as ingress controllers, configuration reloading utilities (e.g., Stakater Reloader), and other essential utilities.

The repository centralizes all sys-service definitions and deployment configurations to ensure consistency, manageability, and automation across multiple Kubernetes clusters.

📂 Structure of the repository#

The repository is organized into a hierarchical folder structure to map services to clusters:

Mon, 01 Jan 0001 00:00:00 +0000

📄 Introduction#

When using Firestartr, each client should have a repository called .firestartr, which should contain a variety of YAML files describing many different aspects of the client’s repository, registry and application structures.

📁 Repo structure#

The repo structure is as follows:

apps/
 ├─ app1.yaml # app1 configuration YAML
 ├─ app2.yml # app2 configuration YAML
docker_registries/
 ├─ releases.yaml # releases registry configuration YAML
 ├─ snapshots.yaml # snapshots registry configuration YAML
platforms/
 ├─ cluster1.yaml # cluster1 configuration YAML
 └─ cluster2.yml # cluster2 configuration YAML
providers/
 └─ [app-name]/
 └─ [claim-kind]/ # currently only the 'TFWorkspace' kind is supported
 └─ [tenant]/
 └─ [env]/
 └─ provider1.yaml
 └─ provider2.yaml
validations/
 └─ apps/
 └─ [app-name]/
 └─ [claim-kind]/ # currently only the 'TFWorkspace' kind is supported
 └─ validation1.yaml
 └─ validation2.yaml
 └─ policies/
 └─ policy1.rego
 └─ policy2.rego

A detailed explanation of each configuration file will be provided below.

Mon, 01 Jan 0001 00:00:00 +0000

Go to the .firestartr repository and create the validations folder structure. More info here
Inside the validations/policies folder, create the policy as a .rego file. You can learn more about Rego here
Inside the apps/[app-name]/[claim-kind] folder create a YAML file as follows:

name: my-validation
description: "My validation description"
regoFile: path/to_the/rego_file.rego
applyTo:
 - app: sample-app
data:
 data1: test-data1
 data2: test-data2
 ...

Description of each field:

name: the name of the validation file, which must be unique between them.
description: a brief description of what this validation does. Purely for human readability purpouses.
regoFile: path to the rego file, relative to the policies folder (i.e., this field’s value will be concatenated to .firestartr/validations/policies like so: .firestartr/validations/policies/[this_fields_value])
applyTo: a list of conditions which describe to which claims this validation applies to. For this, for each value in each element of the list, an AND operation is done with each other value of that element, then for each element an OR operation is done against each other element. See “About the applyTo field values” to learn more about the possible values of this field.
data: key-value pairs, where each key is a variable name and each name its value, to be used inside the regoFile file.

❗ About the applyTo field values#

Each element of the applyTo field can have the following values: