SKS variant

This folder contains the variant to use when deploying in Exoscale using an SKS cluster.

Usage

This module can be declared by adding the following block on your Terraform configuration:

module "thanos" {
  source = "git::https://github.com/camptocamp/devops-stack-module-thanos//sks?ref=<RELEASE>"

  cluster_name     = module.sks.cluster_name
  base_domain      = module.sks.base_domain
  cluster_issuer   = local.cluster_issuer
  cluster_id       = module.sks.cluster_id
  argocd_namespace = module.argocd_bootstrap.argocd_namespace

  metrics_storage = {
    bucket_name = resource.aws_s3_bucket.this["thanos"].id
    region      = resource.aws_s3_bucket.this["thanos"].region
    access_key  = resource.exoscale_iam_access_key.s3_iam_key["thanos"].key
    secret_key  = resource.exoscale_iam_access_key.s3_iam_key["thanos"].secret
  }

  thanos = {
    oidc = module.oidc.oidc
  }

  dependency_ids = {
    argocd       = module.argocd_bootstrap.id
    traefik      = module.traefik.id
    cert-manager = module.cert-manager.id
    keycloak     = module.keycloak.id
    oidc         = module.oidc.id
    longhorn     = module.longhorn.id
  }
}
You are in charge of creating a S3 bucket for Thanos to store the archived metrics. We’ve decided to keep the creation of this bucket outside of this module, mainly because the persistence of the data should not be related to the instantiation of the module itself.
Check the SKS deployment example to see how to create the S3 bucket and to better understand the values passed on the example above.
Do not forget that the bucket configuration also needs to be passed to the module kube-prometheus-stack.

OIDC

This module was developed with OIDC in mind.

There is an OIDC proxy container deployed as a sidecar on each pod that has a web interface. Consequently, the thanos variable is expected to have a map oidc containing at least the Issuer URL, the Client ID, and the Client Secret.

You can pass these values by pointing an output from another module (as above), or by defining them explicitly:

module "thanos" {
  ...
  thanos = {
    oidc = {
      issuer_url    = "<URL>"
      client_id     = "<ID>"
      client_secret = "<SECRET>"
    }
  }
  ...
}

Resource Configuration

Since the resource requirements are not the same on every deployment and because the consumed resources also influence the cost associated, we refrained from configuring default resource requirements for the components of Thanos. We did, however, set memory limits for some of the pods (query, storegateway and compactor all have a 1 GB memory limit). These values should be customized as you see fit, although there is not really a need in a test deployment.

Technical Reference

Dependencies

module.argocd_bootstrap.id

Obviously, the module depends on an already running Argo CD in the cluster in order for the application to be created.

module.traefik.id and module.cert-manager.id

This module has multiple ingresses and consequently it must be deployed after the module traefik and cert-manager.

module.keycloak.id and module.oidc.id

When using Keycloak as an OIDC provider for the Longhorn Dashboard, you need to add Keycloak and the OIDC module as dependencies.

module.longhorn.id

This module requires a Persistent Volume so it needs to be deployed after the module Longhorn.

Requirements

The following requirements are needed by this module:

Modules

The following Modules are called:

thanos

Source: ../

Version:

Required Inputs

The following input variables are required:

cluster_id

Description: ID of the SKS cluster.

Type: string

metrics_storage

Description: Exoscale SOS bucket configuration values for the bucket where the archived metrics will be stored.

Type:

object({
    bucket_name = string
    region      = string
    access_key  = string
    secret_key  = string
  })

cluster_name

Description: Name given to the cluster. Value used for the ingress' URL of the application.

Type: string

base_domain

Description: Base domain of the cluster. Value used for the ingress' URL of the application.

Type: string

Optional Inputs

The following input variables are optional (have default values):

subdomain

Description: Subdomain of the cluster. Value used for the ingress' URL of the application.

Type: string

Default: "apps"

argocd_project

Description: Name of the Argo CD AppProject where the Application should be created. If not set, the Application will be created in a new AppProject only for this Application.

Type: string

Default: null

argocd_labels

Description: Labels to attach to the Argo CD Application resource.

Type: map(string)

Default: {}

destination_cluster

Description: Destination cluster where the application should be deployed.

Type: string

Default: "in-cluster"

target_revision

Description: Override of target revision of the application chart.

Type: string

Default: "v3.2.0"

cluster_issuer

Description: SSL certificate issuer to use. Usually you would configure this value as letsencrypt-staging or letsencrypt-prod on your root *.tf files.

Type: string

Default: "selfsigned-issuer"

helm_values

Description: Helm chart value overrides. They should be passed as a list of HCL structures.

Type: any

Default: []

deep_merge_append_list

Description: A boolean flag to enable/disable appending lists instead of overwriting them.

Type: bool

Default: false

app_autosync

Description: Automated sync options for the Argo CD Application resource.

Type:

object({
    allow_empty = optional(bool)
    prune       = optional(bool)
    self_heal   = optional(bool)
  })

Default:

{
  "allow_empty": false,
  "prune": true,
  "self_heal": true
}

dependency_ids

Description: IDs of the other modules on which this module depends on.

Type: map(string)

Default: {}

thanos

Description: Most frequently used Thanos settings. This variable is merged with the local value thanos_defaults, which contains some sensible defaults. You can check the default values on the local.tf file. If there still is anything other that needs to be customized, you can always pass on configuration values using the variable helm_values.

Type: any

Default: {}

enable_service_monitor

Description: Boolean to enable the deployment of a service monitor for Prometheus. This also enables the deployment of default Prometheus rules, which are embedded inside the chart templates and are taken from the official Thanos examples, available here.

Type: bool

Default: false

enable_monitoring_dashboard

Description: Boolean to enable the provisioning of multiple Grafana dashboards, one for each component of Thanos. These dashboards are embedded inside the chart templates and are taken from the official Thanos examples, available here. Requires the variable enable_service_monitor to be set to true.

Type: bool

Default: true

Outputs

The following outputs are exported:

id

Description: ID to pass other modules in order to refer to this module as a dependency. It takes the ID that comes from the main module and passes it along to the code that called this variant in the first place.

Reference in table format

Show tables

= Requirements

Name Version

argocd

>= 5

null

>= 3

random

>= 3

utils

>= 1

= Modules

Name Source Version

thanos

= Inputs

Name Description Type Default Required

cluster_id

ID of the SKS cluster.

string

n/a

yes

metrics_storage

Exoscale SOS bucket configuration values for the bucket where the archived metrics will be stored.

 
object({
    bucket_name = string
    region      = string
    access_key  = string
    secret_key  = string
  })

n/a

yes

cluster_name

Name given to the cluster. Value used for the ingress' URL of the application.

string

n/a

yes

base_domain

Base domain of the cluster. Value used for the ingress' URL of the application.

string

n/a

yes

subdomain

Subdomain of the cluster. Value used for the ingress' URL of the application.

string

"apps"

no

argocd_project

Name of the Argo CD AppProject where the Application should be created. If not set, the Application will be created in a new AppProject only for this Application.

string

null

no

argocd_labels

Labels to attach to the Argo CD Application resource.

map(string)

{}

no

destination_cluster

Destination cluster where the application should be deployed.

string

"in-cluster"

no

target_revision

Override of target revision of the application chart.

string

"v3.2.0"

no

cluster_issuer

SSL certificate issuer to use. Usually you would configure this value as letsencrypt-staging or letsencrypt-prod on your root *.tf files.

string

"selfsigned-issuer"

no

helm_values

Helm chart value overrides. They should be passed as a list of HCL structures.

any

[]

no

deep_merge_append_list

A boolean flag to enable/disable appending lists instead of overwriting them.

bool

false

no

app_autosync

Automated sync options for the Argo CD Application resource.

 
object({
    allow_empty = optional(bool)
    prune       = optional(bool)
    self_heal   = optional(bool)
  })
 
{
  "allow_empty": false,
  "prune": true,
  "self_heal": true
}

no

dependency_ids

IDs of the other modules on which this module depends on.

map(string)

{}

no

thanos

Most frequently used Thanos settings. This variable is merged with the local value thanos_defaults, which contains some sensible defaults. You can check the default values on the local.tf file. If there still is anything other that needs to be customized, you can always pass on configuration values using the variable helm_values.

any

{}

no

enable_service_monitor

Boolean to enable the deployment of a service monitor for Prometheus. This also enables the deployment of default Prometheus rules, which are embedded inside the chart templates and are taken from the official Thanos examples, available here.

bool

false

no

enable_monitoring_dashboard

Boolean to enable the provisioning of multiple Grafana dashboards, one for each component of Thanos. These dashboards are embedded inside the chart templates and are taken from the official Thanos examples, available here. Requires the variable enable_service_monitor to be set to true.

bool

true

no

= Outputs

Name Description

id

ID to pass other modules in order to refer to this module as a dependency. It takes the ID that comes from the main module and passes it along to the code that called this variant in the first place.