Backup fichiers EDS - bucket S3 -> SCW avec réplication et versionning

[igorrenquin]

• Lors de l'ajout de backups sur SWC il faudrait activer par défaut la replication et le versioning.
• Pour le moment on ne peut pas l'activer via l'interface car cela pourrait créer des conflits avec le futur IAC.

[igorrenquin]

prochain sprint ops 2014-04-2

[igorrenquin]

@LucasBassoOcto ajout de la documentation dans notion

[igorrenquin]

• Revue des fonctionnalités du module @octomir

[matmut7]

Après un test sur cette MR, je confirme que la création d'un bucket OVH répliqué sur SCW avec le versioning fonctionne correctement.

J'ai une seule remarque, un peu hors sujet mais j'en profite tant que la nouvelle version n'est pas livrée et migrée : le module n'est pas très simple à utiliser pour les SRE qui ne maîtrisent pas Terraform. Cela se manifeste aussi sur d'autres modules : on se retrouve souvent à copier coller des modules d''autre part et à essayer d'identifier tant bien que mal les paramètres à modifier.

Par exemple, voici le module final pour un bucket de test répliqué et versioné, écrit avec l'aide des OPS :

locals {
  extra_atlantis_dependencies = [
    find_in_parent_folders("env.hcl"),
    find_in_parent_folders("region.hcl"),
    find_in_parent_folders("env.sops.yaml"),
    find_in_parent_folders(),
  ]
  env_config      = read_terragrunt_config(find_in_parent_folders("env.hcl"))
  region_config   = read_terragrunt_config(find_in_parent_folders("region.hcl"))
  rancher_api_url = "https://rancher.fabrique.social.gouv.fr"
  env_secrets     = yamldecode(sops_decrypt_file(find_in_parent_folders("env.sops.yaml")))
  offer_type      = "io"
}

terraform {
  source = "git::ssh://git@gitlab.fabrique.social.gouv.fr/infra/terraform-modules/ovh/storage-object.git?ref=v1.3.4"
}

generate provider_rancher2 {
  path      = "provider-rancher2.tf"
  if_exists = "overwrite_terragrunt"
  contents  = <<EOF
provider rancher2 {
  api_url    = "${local.rancher_api_url}"
  access_key = "${local.env_secrets.rancher_ci_user_access_key}"
  secret_key = "${local.env_secrets.rancher_ci_user_secret_key}"
}
EOF
}

generate provider_aws {
  path      = "provider-aws.tf"
  if_exists = "skip"
  contents  = <<EOF
provider "aws" {
    region      = "${local.region_config.locals.region_ovh}"
    access_key  = "${local.env_secrets.ops_iac_credentials_ovh_s3_access_key}"
    secret_key  = "${local.env_secrets.ops_iac_credentials_ovh_s3_secret_key}"

    #OVH implementation has no STS service
    skip_credentials_validation = true
    skip_requesting_account_id  = true
    # the gra region is unknown to AWS hence skipping is needed.
    skip_region_validation = true
    endpoints {
        s3 = "https://s3.${local.region_config.locals.region_ovh}.${local.offer_type}.cloud.ovh.net"
    }
    skip_metadata_api_check = true
}
EOF
}

generate provider_scaleway {
  path      = "provider-scaleway.tf"
  if_exists = "overwrite_terragrunt"
  contents  = <<EOF
provider scaleway {
  access_key = "${local.env_secrets.scw_azure-db-backups_access_key}"
  secret_key = "${local.env_secrets.scw_azure-db-backups_access_secret}"
  project_id = "${local.env_secrets.scw_azure-db-backups_id}"
  }
EOF
}

generate provider_kubernetes {
  path      = "provider-kubernetes.tf"
  if_exists = "overwrite_terragrunt"
  contents  = <<EOF
provider kubernetes {
  host  = "${local.env_secrets.terragrunt_ovh_dev_kubeconfig_host}"
  client_certificate     = <<EOC
${base64decode(local.env_secrets.terragrunt_ovh_dev_kubeconfig_certificate)}
EOC
  client_key             = <<EOC
${base64decode(local.env_secrets.terragrunt_ovh_dev_kubeconfig_client_key)}
EOC
  cluster_ca_certificate = <<EOC
${base64decode(local.env_secrets.terragrunt_ovh_dev_kubeconfig_ca_certificate)}
EOC
}
EOF
}

include {
  path = find_in_parent_folders()
}

inputs = {
  ovh_endpoint           = "ovh-eu"
  ovh_application_key    = local.env_secrets.ops_iac_credentials_ovh_application_key
  ovh_application_secret = local.env_secrets.ops_iac_credentials_ovh_application_secret
  ovh_consumer_key       = local.env_secrets.ops_iac_credentials_ovh_consumer_key

  bucket_name = "secretariat-test-bucket"

  scaleway_replication_enabled              = true
  scaleway_replication_bucket_access_key    = local.env_secrets.scw_azure-db-backups_access_key
  scaleway_replication_bucket_secret_key    = local.env_secrets.scw_azure-db-backups_access_secret
  scaleway_replication_rancher_cluster_name = "ovh-dev"
  scaleway_replication_rancher_project_name = "secretariat"
  scaleway_replication_retention_days       = 30
  scaleway_replication_rclone_limits_cpu    = "500m"

  secret_delivery_enabled              = true
  secret_delivery_namespace            = "ci-secretariat"
  secret_delivery_rancher_cluster_name = "ovh-dev"
  secret_delivery_rancher_project_name = "secretariat"

  harbor_registry = local.env_secrets.harbor_pull_registry 
  harbor_username = local.env_secrets.harbor_pull_username 
  harbor_password = local.env_secrets.harbor_pull_password 
}

Cependant, si je retire tous les champs qui ne m'importent pas au moment où je consomme le module, c'est-à-dire quand je crée concrètement un bucket, il me reste seulement ces champs :

terraform {
  source = "git::ssh://git@gitlab.fabrique.social.gouv.fr/infra/terraform-modules/ovh/storage-object.git?ref=v1.3.4"
}

inputs = {
  bucket_name = "secretariat-test-bucket"

  scaleway_replication_enabled              = true

  secret_delivery_enabled              = true
  secret_delivery_namespace            = "ci-secretariat"
  secret_delivery_rancher_cluster_name = "ovh-dev"
  secret_delivery_rancher_project_name = "secretariat"
}

En supprimant :

• le bloc locals qui je crois est assez constant
• les blocs providers
• le bloc include
• plusieurs paramètres dans le bloc inputs

Je ne sais pas en pratique si c'est aussi simple que ça mais je veux simplement poser la question de l'interface : est-il possible pour les utilisateurs du module de n'avoir à donner que les paramètre nécessaires, sans copier coller de la logique et des constantes ?

[matmut7]

A priori ce type d'abstraction n'est pas si simple à mettre en place. On privilégie un système d'exemples pour mieux présenter les paramètres possibles de chaque module TF