Aller au contenu

Déploiement#

Note

Cette documentation ne s'applique qu'à NGOT à partir de la version Comet.

Informations requises#

Pour le déploiement de ce composant, le client doit nous fournir les informations suivantes :

  • le nom du domaine FE ;
  • le nom du projet ;
  • la région ;
  • les identifiants (nom/mot de passe) d'un compte de service spécialement créé avec des droits limités. La section qui suit explique comment le créer ;
  • la liste des métriques disponibles que vous souhaitez collecter ;
  • les labels supplémentaires que vous souhaitez positionner sur ces métriques.

Pour faciliter cet échange nous avons mis en place une stack Terraform pour la création du compte de service. Un repository a été créé afin de suivre les changements. Le client doit nous faire parvenir ces informations sous forme de token à l'aide de la fonctionnalité Wrap de Vault.

Unwrap du token Vault et sauvegardes des données#

La fonctionnalité Wrap/Unwrap de Vault est utilisé pour nous faire parvenir les données sensibles du client de manières sécurisé, un accès au Vault interne OAB est donc nécessaire https://vault-oab.si.fr.intraorange.

Après le déchiffrage du token, nous allons sauvegarder le mot de passe dans le Vault infra et le reste des données dans NGOT-Zone.

Warning

Le token est configuré avec un TTL de 24h.

Warning

Le token peut être déchiffré qu'une seule fois.

Authentification au Vault interne OAB#

export VAULT_ADDR="https://vault-oab.si.fr.intraorange"
vault login -method oidc -path=sso

Unwrap du token#

TOKEN=""
vault unwrap -format=json ${TOKEN} | jq '.data' > data-cloudeye.json

Vérification du contenu du fichier data-cloudeye.json

Warning

Ne pas avoir de doublons sur la liste des namespaces, exemple de doublons:[SYS.ECS, SYS.RDS, SYS.ECS].

Validation des informations du fichier data-cloudeye.json 

OS_AUTH_URL=$(jq -r '.auth_url' data-cloudeye.json)
OS_USERNAME=$(jq -r '.user_name' data-cloudeye.json)
OS_PASSWORD=$(jq -r '.password' data-cloudeye.json)
OS_DOMAIN_NAME=$(jq -r '.domain_name' data-cloudeye.json)
OS_TENANT_NAME=$(jq -r '.project_name' data-cloudeye.json)

curl -is -X POST ${OS_AUTH_URL}/auth/tokens -H "Content-Type: application/json" -d ' { "auth": { "identity": { "methods": ["password"], "password": { "user": { "name": "'$OS_USERNAME'", "domain": { "name": "'$OS_DOMAIN_NAME'" }, "password": "'$OS_PASSWORD'" } } }, "scope": { "project": { "name": "'$OS_TENANT_NAME'" } } } }'

Vous devez recevoir un token, cela valide les différentes informations pour l'authentification.

Si par contre vous avez une erreur 401 unauthorized, vous pouvez arreter et voir avec le client.

Authentification au Vault infra#

INFRA_ZONE_NAME="" # infra-stg | infra-prd
export VAULT_ADDR="https://vault.${INFRA_ZONE_NAME}.caascad.com"
vault login -method oidc

Vérification à effectuer avant d'ajouter le mot de passe dans le Vault d'infrastructure#

Si le caractère "&" ou "/" n'apparaît pas dans votre mot de passe Vault, cette étape n'est pas nécessaire.

Cela est dû au fait que le caractère "&" est remplacé par la chaîne de caractères capturée.Il est donc nécessaire d'échapper le caractère "&". Il est possible qu'il y ait d'autres caractères à échapper, comme "/".

PASSWORD=$(cat /etc/creds/passwordfile | sed 's/&/\\&/g')
Une fois la modification effectuée, il faut ajouter la zone à la liste des zones impactées dans le ticket PF-1934 .

Ajout du mot de passe dans Vault infra#

CLOUDEYE_PW=$(jq -r '.password' data-cloudeye.json)
CLOUDEYE_DOMAIN=$(jq -r '.domain_name' data-cloudeye.json)
CLOUDEYE_PROJECT=$(jq -r '.project_name' data-cloudeye.json)
CLIENT="XXX" # Le nom du client, par exemple `demo`)
vault write "secret/zones/fe/svc-monitoring-stack-client-${CLIENT}/cloudeye-exporter-client/${CLOUDEYE_DOMAIN}-${CLOUDEYE_PROJECT}" password=${CLOUDEYE_PW}

Ajout des données non sensibles dans Ngot-Zone#

Conversion du fichier json en cue et suppression du password#

cue import -f data-cloudeye.json -o non-sensitive-data-cloudeye.cue && sed -i '/^password/d' non-sensitive-data-cloudeye.cue

Modification du fichier ~/git/caascad/terraform/envs-ng/zones/ngot_zones/values.cue#

Création d'une branche dans le repository envs-ng.

Ajout du contenu du fichier non-sensitive-data-cloudeye.cue dans la clé .svc-monitoring-stack-client-${CLIENT}.parameters.monitoring-stack.prometheus.exporters.cloudeyeExporter (où ${CLIENT} est le nom du client, par exemple demo).

Génération des fichiers de zones :

cd ~/git/caascad/terraform/envs-ng
nix-shell
generate-static-zones-files

Trackbone plan avant le CAASCHR#

Après toutes ces modifications, le déploiement de Cloudeye-Exporter-Client est possible.

Plan du déploiement : 

cd ~/git/caascad/terraform/envs-ng/contexts/ngot
trackbone plan -z "svc-monitoring-stack-client-${CLIENT}" -c cloudeye-exporter-client -c prometheus-rules

Si tout est OK, vous pouvez demander la review de votre MR et préparer votre CAASCHR.