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
.
Required Inputs
The following input variables are required:
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):
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.1.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 |
---|---|
>= 5 |
|
>= 3 |
|
>= 3 |
|
>= 1 |
= Modules
Name | Source | Version |
---|---|---|
= Inputs
Name | Description | Type | Default | Required |
---|---|---|---|---|
ID of the SKS cluster. |
|
n/a |
yes |
|
Exoscale SOS bucket configuration values for the bucket where the archived metrics will be stored. |
|
n/a |
yes |
|
Name given to the cluster. Value used for the ingress' URL of the application. |
|
n/a |
yes |
|
Base domain of the cluster. Value used for the ingress' URL of the application. |
|
n/a |
yes |
|
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. |
|
|
no |
|
Labels to attach to the Argo CD Application resource. |
|
|
no |
|
Destination cluster where the application should be deployed. |
|
|
no |
|
Override of target revision of the application chart. |
|
|
no |
|
SSL certificate issuer to use. Usually you would configure this value as |
|
|
no |
|
Helm chart value overrides. They should be passed as a list of HCL structures. |
|
|
no |
|
A boolean flag to enable/disable appending lists instead of overwriting them. |
|
|
no |
|
Automated sync options for the Argo CD Application resource. |
|
|
no |
|
IDs of the other modules on which this module depends on. |
|
|
no |
|
Most frequently used Thanos settings. This variable is merged with the local value |
|
|
no |
|
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. |
|
|
no |
|
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 |
|
|
no |
= Outputs
Name | 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. |