Aller au contenu

Démantèlement des zones d'un client NGOT#

Préparatifs#

Warning

Attention de les garder pour les avoir après le lancement de nix-shell.

CLIENT=xxxx       # pour obs-pf : CLIENT=pf
ENVS_NG=xxx       # exemple : ENVS_NG=$HOME/git/caascad/terraform/envs-ng
CLUSTER=xxx       # pour obs-pf : CLUSTER=kub-9
export VAULT_ADDR=https://vault.infra-prd.caascad.com/
export VAULT_FORMAT=json
vault token lookup > /dev/null 2>&1 || vault login -method oidc

Prévenir sur #Opérations et incidents.

Gestion des silences#

Afin d'éviter d'alerter pendant la période de démantèlement d'une nouvelle zone NGOT, il est important de poser un silence sur toute la zone.

Depuis cette URL :

xdg-open 'https://karma-infra.infra-prd.caascad.com/?m='$(echo '{"am":[{"label":"svc-monitoring-stack-corp-prd-1","value":["svc-monitoring-stack-corp-prd-1"]},{"label":"svc-monitoring-stack-corp-prd-2","value":["svc-monitoring-stack-corp-prd-2"]}],"m":[{"n":"obs_client","r":false,"e":true,"v":["CLIENT"]}],"d":10080,"c":"silence_cop '"$(date "+%d%m%Y" -d "8 day")"' Decom NGOT client CLIENT (silence to remove after decom)"}' | sed -e "s/CLIENT/${CLIENT}/g" | base64 -w0)

Ancienne méthode : dans Karma mettez un silence :

  • il faut poser les silences sur les deux alertmanagers de Prod : svc-monitoring-stack-corp-prd-1 et svc-monitoring-stack-corp-prd-2 ;
  • filtre dans Karma le nom de la zone : obs_client=${CLIENT} ;
  • commentaire : Decom NGOT client ${CLIENT} ;
  • durée : 7 jours

Exemple : Silences dans karma

À la fin du démantèlement il sera nécessaire de supprimer les silences mis en place.

Zone grafana-client#

cd ${ENVS_NG}
nix-shell
cd contexts/ngot
trackbone destroy -t purge=true -z "svc-grafana-client-${CLIENT}" --non-interactive --detailed-exitcode -n 8 --add-services

Note

Vérifier INFO Trackbone Stats: Succeeded=x Skipped=x Failed=x Disabled=x Total=x.

Si la valeur Failed est plus grande que 0, identifier les configurations en échec et lancer trackbone destroy -t purge=true avec ces configurations.

for i in "$(vault list secret/zones/fe/svc-grafana-client-${CLIENT} | jq -r '.[]')"; do echo "vault delete secret/zones/fe/svc-grafana-client-${CLIENT}/${i}"; done
for i in "$(vault list secret/zones/fe/svc-grafana-client-${CLIENT} | jq -r '.[]')"; do echo "vault delete secret/zones/fe/svc-grafana-client-${CLIENT}/${i}"; done

Note

Il est possible que les secrets Vault aient déjà tous été supprimés.

Suppression du PV à faire seulement si la suppression a échouée avec la commande trackbone : 

kswitch ${CLUSTER}
pv=$(kubectl get pv -o json | jq -r --arg client "${CLIENT}" '.items[] | select(.spec.claimRef.name == "grafana-obs-"+$client) | .metadata.name')
kubectl get pv "${pv}" -o json | jq '[.metadata.name, .status.phase,.spec.claimRef.name,.spec.persistentVolumeReclaimPolicy]'
Après le contrôle, supprimer le pv s'il existe. 
kubectl delete pv "${pv}"

Suppression des backups#

Lister les backups 

kubectl get backup -n velero -l velero.io/schedule-name=grafana-obs-${CLIENT}

Delete des backup 

velero backup delete --selector=velero.io/schedule-name=grafana-obs-${CLIENT}

Vérification (aucune ligne doit sortir des cmds suivantes) 

velero backup get -l velero.io/schedule-name=grafana-obs-${CLIENT}
kubectl get backup -n velero | grep grafana | grep $CLIENT

Restart de Velero et vérification que le pod running et ready 

kubectl rollout restart -n velero deploy/velero
kubectl get pod -n velero

Zone monitoring-stack-client#

trackbone destroy#

trackbone destroy -t purge=true -z "svc-monitoring-stack-client-${CLIENT}" --non-interactive --detailed-exitcode -n 8 --add-services

Note

Vérifier INFO Trackbone Stats: Succeeded=x Skipped=x Failed=x Disabled=x Total=x.

Si la valeur Failed est plus grande que 0, identifier les configurations en échec et lancer trackbone destroy -t purge=true avec ces configurations.

Suppression des secrets dans Vault#

On récupère la liste des commandes de suppression à lancer : 

for i in $(vault list secret/zones/fe/svc-monitoring-stack-client-${CLIENT}/ | jq -r '.[]'); do echo "vault delete secret/zones/fe/svc-monitoring-stack-client-${CLIENT}/$i"; done
for i in $(vault list secret/zones/fe/svc-monitoring-stack-client-${CLIENT}/prometheus-ingress/ | jq -r '.[]'); do echo "vault delete secret/zones/fe/svc-monitoring-stack-client-${CLIENT}/prometheus-ingress/$i"; done
for i in $(vault list secret/zones/fe/svc-monitoring-stack-client-${CLIENT}/cloudeye-exporter-client | jq -r '.[]'); do echo "vault delete secret/zones/fe/svc-monitoring-stack-client-${CLIENT}/cloudeye-exporter-client/$i"; done
for i in $(vault list secret/zones/fe/svc-monitoring-stack-client-${CLIENT}/stackdriver-exporter-client | jq -r '.[]'); do echo "vault delete secret/zones/fe/svc-monitoring-stack-client-${CLIENT}/stackdriver-exporter-client/$i"; done
for i in $(vault list secret/zones/fe/svc-monitoring-stack-client-${CLIENT}/yace-client | jq -r '.[]'); do echo "vault delete secret/zones/fe/svc-monitoring-stack-client-${CLIENT}/yace-client/$i"; done
for i in $(vault list secret/zones/fe/svc-monitoring-stack-client-${CLIENT}/promitor-client | jq -r '.[]'); do echo "vault delete secret/zones/fe/svc-monitoring-stack-client-${CLIENT}/promitor-client/$i"; done

On vérifie la liste des secrets supprimés et on lance les commandes.

Gitops workflow#

Projet du client#

Se connecter à https://sourcehub.orange-business.com/cs-factory/cs-factory-environments/obs-XXXX, avec le compte robot :

  • supprimer les utilisateurs non gérés par MyPortal ("Direct member by")
  • archiver le projet

Projets communs#

Dans cs-factory/templates-ci déplier la section Variables .

  • éditer la variable LIST_CLIENT et supprimer la ligne contenant l'ID du projet du client ;
  • supprimer les variables mentionnant le nom du client (CLIENT_grafana_roleid, CLIENT_grafana_secretid, CLIENT_monitoring_roleid, CLIENT_monitoring_secretid) ;
  • supprimer les branches mentionnant le nom du client s'il en existe.

Tip

Si l'ID du projet du client a été perdu, il est possible de le retrouver dans la variable LIST_CLIENT qui contient la liste des ID et des noms des clients.

Alertinghub#

Redéploiement de nginx-alertreceiver#

Supprimer la zone dans contexts/pf/nginx-alertreceiver.cue : 

#ZonesMonitoredByTruesight: ["lrdm", ..., "$old_client"]

Lancer la configuration nginx-alertreceiver (on s'attend à avoir seulement des suppressions pour le client) : 

cd ${ENVS_NG}/contexts/pf
trackbone apply -c nginx-alertreceiver -z prdcasa

Suppression de l'api key#

Suivre la procédure request-an-internal-api-key, avec deux différences notables à prendre en compte :

  • ce n'est pas nécéssaire d'attacher un dictionnaire
  • la description de l'opération : 
    Hello,

I would like to request the deletion of an API key for the xxx project.

The key is: xxxx.

Thank you.

Dans Confluence :

  • déplacer la page client AlertingHUB dans la section ToDelete/Deleted
  • indiquer dans cette page, le numéro de la demande de la suppression d'api key

Suppression du secret dans Vault#

Aller dans Vault : 

xdg-open https://vault.infra-prd.caascad.com/ui/vault/secrets/secret/list/applications/nginx-alertreceiver/${CLIENT}

Supprimer le secret correspondant au client.

Zone loki-client#

trackbone destroy#

On supprime la zone Loki : 

cd ${ENVS_NG}/contexts/ngot
trackbone destroy -t purge=true -z "svc-loki-client-${CLIENT}" --non-interactive --detailed-exitcode -n 8 --add-services

Note

Vérifier INFO Trackbone Stats: Succeeded=x Skipped=x Failed=x Disabled=x Total=x.

Si la valeur Failed est plus grande que 0, identifier les configurations en échec et lancer trackbone destroy -t purge=true avec ces configurations.

Suppression des secrets dans Vault#

La commande suivante ne doit rien retourner : 

for i in $(vault list secret/zones/fe/svc-loki-client-${CLIENT}/ | jq -r '.[]'); do
    echo "vault delete secret/zones/fe/svc-loki-client-${CLIENT}/$i";
done

Si cela retourne des lignes de commande, il est nécessaire de les exécuter.

Git : repo loki-rules#

Suppression du dossier client dans le repo git loki rules.

git clone git@sourcehub.orange-business.com:cs-factory/loki-client-rules.git /tmp/loki-client-rules
cd /tmp/loki-client-rules
git switch -c decom-obs-${CLIENT}
git rm -r obs-${CLIENT}
git commit -m "Removing Loki Rules Directory for obs-${CLIENT}"
git push origin decom-obs-${CLIENT}

Soumettre la MR pour validation et merger.

Note

Ce repo n'est pas accessible aux clients. On peut utiliser notre compte nominatif.

Zone contract#

trackbone destroy -z "obs-${CLIENT}" -t purge=true --non-interactive --detailed-exitcode -n 8

Si la commande échoue, supprimer la zone DNS directement dans AWS.

Se connecter à la console avec le compte Account: ngot (678661912090) en tant que cscd-administrator: URL login.

Aller sur Route 53 -> Zones hébergées et chercher la zone avec le nom du client.

AWS Route 53

Supprimer la zone (si besoin cliquer dans la zone et supprimer les enregistrements dans la zone avant de supprimer la zone).

Post-démantèlement#

  • Créer une MR avec toutes les suppression.

    cd ${ENVS_NG}
git switch -c decom-obs-${CLIENT}
git rm zones/ngot_zones/client-${CLIENT}.cue
git rm zones/ngot_zones/promitor-${CLIENT}.cue # échec si Promitor n'est pas déployé

  • Rechercher des traces de la zone dans contexts 

    grep -ri "${CLIENT}" contexts
    Si des traces sont trouvées, il faut les comprendre, comprendre également la suppression de ces traces, puis supprimer effectivement ces traces.

  • Cas d'une zone pointée par un Grafana Mutualisé 

    grep -r "${CLIENT}" zones/ngot_zones
    Si la zone est référencée dans un fichier client-xxx.cue correspondant à un grafana mutualisé, il faut :

    1. supprimer cette référence
    2. noter qu'il y a du ménage supplémentaire à faire au niveau du grafana mutualisé (cf plus loin)

  • Finaliser la création de la MR 

    generate-static-zones-files
git add gen/ zones/
git commit -m "Decom ${CLIENT}"
git push --set-upstream origin decom-obs-${CLIENT}

  • Faire valider la MR. Puis la merger.

  • Après le merge :

    git switch master && git pull
cd contexts/ngot
trackbone apply -z svc-monitoring-stack-corp-prd-1 -c prometheus-rules -c blackbox-exporter-core -t blackbox_exporter_refresh_cache=true --non-interactive --add-services
trackbone apply -z svc-monitoring-stack-corp-prd-2 -c prometheus-rules -c blackbox-exporter-core --non-interactive --add-services
trackbone apply -z svc-signon-prd -c keycloak_k8s_openid_clients
trackbone apply -z "${CLUSTER}" -c ingress_nginx_public --non-interactive

  • Si le client avait une connexion à Alertinghub, il faut la supprimer :

    cd ${ENVS_NG}/contexts/pf
trackbone apply -z prdcasa -c nginx-alertreceiver --add-services

  • Vérifier qu'il n'y a pas d'alertes liées à la zone démantelée.

  • Supprimer les silences sur la zone démantelée.

  • Supprimer les namespaces :

    kubectl get ns | grep "${CLIENT}"

    Supprimer tous les namespaces ci-dessus.

  • Supprimer les PVs Released :

    kubectl get pv | grep ${CLIENT} | grep Released

    S'il y en a, supprimer les : 

    for pv in $(kubectl get pv | grep ${CLIENT} | grep Released | awk '$1 {print$1}'); do
  kubectl delete pv ${pv}
done

  • Supprimer les pipelines Concourse:

    Pour supprimer les pipelines liées à la zone, suivre la doc de gestion des drifts.

Suppression du cluster#

La suppression du cluster peut être effectuée en suivant la documentation de démantèlement d'une zone cluster.

Cependant, en fonction des besoins, il peut être préférable de garder le cluster pour une réutilisation future.

Cas d'une zone pointée par un Grafana mutualisé#

Mise à jour des certificats#

Si la zone était pointée par un Grafana mutualisé, il faut exécuter les opérations suivantes.

GRAFANA_MUTUALISE=xxx  # exemples: GRAFANA_MUTUALISE=rsc ou GRAFANA_MUTUALISE=monitoring

trackbone apply -c grafana -c thanos-query -c thanos_certificates -z svc-grafana-client-${GRAFANA_MUTUALISE}

kswitch svc-grafana-client-${GRAFANA_MUTUALISE}
kubectl -n grafana-client-obs-${GRAFANA_MUTUALISE} get pod

Les pods doivent avoir redémarré dans les secondes qui précèdent. Sinon : 

# Redémarrer les pods.
kubectl -n grafana-client-obs-$GRAFANA_MUTUALISE rollout restart deploy thanos-querier

# Supprimer une éventuelle annotation qui pourrait générer du drift.
trackbone apply -c thanos-query -z svc-grafana-client-${GRAFANA_MUTUALISE} # pour supprimer une éventuelle annotation qui pourrait générer du drift.

# Attendre un peu...
sleep 10

# Les pods ont-ils bien redémarré ?
kubectl -n grafana-client-obs-${GRAFANA_MUTUALISE} get pod

Les pods doivent avoir redémarré depuis quelques secondes.

Suppression de la datasource dans Grafana#

Se connecter à https://grafana.obs-<GRAFANA_MUTUALISE>.cloudservicesfactory.com.

Aller dans l'onglet Alerting -> Active notifications.

En haut à droite, un menu déroulant Choose Alertmanager contient des datasources. Il faut s'attendre à retrouver celle de la zone démantelée.

kswitch svc-grafana-client-${GRAFANA_MUTUALISE}
kubectl -n grafana-client-obs-${GRAFANA_MUTUALISE} edit cm grafana-obs-${GRAFANA_MUTUALISE}

Il faut repérer une section data -> datasources.yaml -> deleteDatasources. Si la zone décommisionnée n'est pas déjà là, il faut l'ajouter ainsi :

data:
  datasource.yaml:
    deleteDatasources:
      - name: alertmanager-<CLIENT>
        orgId: 1

Puis :

  1. Redémarrer ensuite Grafana 

    kubectl -n grafana-client-obs-${GRAFANA_MUTUALISE} delete pod grafana-obs-${GRAFANA_MUTUALISE}-0

  2. Dans Grafana, vérifier que la source de données a bien disparu.

  3. Exécuter à nouveau la commande suivante pour restaurer la ConfigMap (et supprimer la source de données de la section deleteDatasources). 
    trackbone apply -c grafana -z svc-grafana-client-${GRAFANA_MUTUALISE}
  4. Redémarrer une nouvelle fois Grafana.
  5. Dans Grafana, vérifier que la source de données a bien été supprimée.

Habilitations#

Suppression des habilitations : suivre cette procédure.

Confluence#

Déréférencer le client dans Confluence.

Points de contrôle (démantèlement de zone sans suppression du cluster)#

Les points à contrôler sont définis dans le modèle Jira. Voici quelques précisions :

(x) aucune référence aux zones
* (x) dans envs-ng
* (x) dans Vault
** (x) path : applications/nginx-alertreceiver
** (x) path : applications/alertmanager/receivers
** (x) path : zones/fe
* (x) dans la documentation
* (x) dans Concourse

(x) gitops
* (x) repo archivé
* (x) aucune référence à la zone dans loki-rules
* (x) aucune référence dans les variables de templates-ci

(x) Dans la console FE¹ , aucune ressource liée aux zones
* (x) Buckets s3

(x) Absence d'habilitations (demander au support)

(x) Absence de silences dans Karma

(x) Dans le cluster, absence de PV avec le status {{Released}}

Points de contrôle (démantèlement de zone avec suppression du cluster)#

Les points à contrôler sont définis dans le modèle Jira. Voici quelques précisions :

(x) aucune référence aux zones et au cluster
* (x) dans envs-ng
* (x) dans Vault
** (x) path : applications/nginx-alertreceiver
** (x) path : applications/alertmanager/receivers
** (x) path : zones/fe
* (x) dans Rancher²
* (x) dans la documentation
* (x) dans Concourse

(x) gitops
* (x) repo archivé
* (x) aucune référence à la zone dans loki-rules
* (x) aucune référence dans les variables de templates-ci

(x) Dans la console FE¹ , aucune ressource liée aux zones et au cluster
* (x) VMs
* (x) Buckets s3
* (x) ELB
* (x) CCE

(x) Absence d'habilitations (demander au support)

(x) Absence de silences dans Karma

Note

  • FE¹ - Pour vous connecter aux consoles, cliquez ici et suivez cette documentation.

  • Rancher² - Pour vous connecter en tant qu'admin, cliquez ici et suivez cette documentation.