Aller au contenu

Environnement de test (Supervision + Grafana)#

Objectifs#

  • déployer des zones de service sur staging

Points de vigilance#

La documentation ci-dessous est écrite pour les zones de Staging. Cependant, elle pointe sur des documentations de Production.

Il faudra

  • remplacer ou ajouter le suffixe -stg là où c'est nécessaire ;
  • indiquer son trigramme et le ticket Jira de référence pour faciliter les recherches en cas de problème sur ces environnements de test ;
  • vérifier chaque commande avant de l'exécuter car les erreurs (prd au lieu de stg) surviennent vite.

Principe général#

Le principe général pour déployer est :

  1. de suivre la documentation permettant de déployer un contrat et une zone de supervision pour déployer une zone "contract" et une première zone ;
  2. de suivre les documentations prévues pour la Production et de les adapter à Staging.

Note

Le principe général pour supprimer les envs devrait suivre la même logique. Cependant, les documentations n'existent pas encore (08/09/2023).

Déploiement#

Création des zones#

La documentation mentionne l'étape préliminaire de demande d'habilitations. Cette étape doit être ignorée sauf si on en a vraiment besoin. En l'ignorant, on devra donc s'authentifier sur Grafana avec le compte admin.

La création des zones de contrat et de service nécessite de modifier le fichier values.cue. Ici, on préférera créer un fichier dédié indiquant le trigramme et le ticket Jira : zones/ngot_zones/values-PFnnnn-XXX.cue (où PFnnnn est le ticket Jira et XXX le trigramme).

Note

L'exemple ci-dessous donne une idée du contenu du fichier. Cependant, il est préférable de le créer à partir de copier/collers du fichier values.cue qui peut être plus à jour que cette documentation.

values-PFnnnn-XXX.cue
package ngot_zones

clients: staging: "yme-pf1990": email: "yves.mettier@orange.com"

_zones: {
    /////////////
    // STAGING //
    /////////////

    // CONTRACTS //
    "obs-yme-pf1990": {
        type: "contract"
        provider: type: "fe"
        metadata: line: "staging"
        parent_zone_name: "admin-stg"
        client_name:      "yme-pf1990"
    }

    // SERVICES //
    "svc-grafana-client-yme-pf1990": {
        let shortname = "yme-pf1990"
        type:               "service"
        subtype:            "grafana-client"
        parent_zone_name:   "kub-10002"
        contract_zone_name: "obs-\(shortname)"
        parameters: {
            _thanos_query_connected_services_default: "\(shortname)": _
            thanos_query_connected_services: _thanos_query_connected_services_default[shortname]

            _datasource_thanos: "\(shortname)":       _
            _datasource_alertmanager: "\(shortname)": _
            datasources: {
                _datasource_thanos[shortname]
                _datasource_alertmanager[shortname]
            }
        }
    }

    "svc-monitoring-stack-client-yme-pf1990": {
        type:               "service"
        subtype:            "monitoring-stack-client"
        parent_zone_name:   "kub-10002"
        contract_zone_name: "obs-yme-pf1990"
        parameters: {
            "monitoring-stack": {
                namespace: "\(subtype)-\(contract_zone_name)"
            }
        }
    }
}

Contrairement à ce qui est indiqué dans la documentation, sur Staging, il n'y a pas de problème à mutualiser des zones de services liés à des contrats différents sur le même cluster.

Warning

Les clusters kub-10000, kub-10007 et kub-10008 sont à éviter.

Les deux premiers (kub-10000 et kub-10007) portent les zones centrales de monitoring et les tests ne devraient pas les perturber.

Au 08/09/2023, le cluster kub-10008 est marqué explicitement dans ngot-zones comme exception au déploiement de Rancher. Cela est bloquant pour le déploiement des zones de supervision.

La suite de la documentation peut ensuite s'appliquer normalement. Il faut être très vigilant à déployer sur Staging à chaque commande.

Finalisation du déploiement#

Contrôles dans Karma#

Vérifier au bout de quelques minutes que vous n'avez pas généré d'alertes.

Vérifier sur Staging et Production. En Production, il s'agit de vérifier qu'il n'y a pas eu une confusion Staging/Production quelque part ou un déploiement imprévu en Production.

En cas de pose de silences :

  • indiquez en commentaire le ticket Jira plus quelques mots d'explication ;
  • posez le silence sur les 2 alertmanagers des zones centrales (n'oubliez pas le deuxième) ;
  • généralement, supprimez tous les filtres. Ne gardez que obs_client=<votre contract>.

Applications (Grafana, Loki...)#

Il est souhaitable de tester toutes les applications déployées.

  • Grafana
  • Loki
  • ...

Note

Tant que la MR n'est pas mergée, la zone de sevice n'est pas connue de kswitch. En guise de contournement, on peut lancer kswitch sur la zone cluster qui héberge le service.

Merge Request#

Faire une MR comme pour les zones de Production, la faire valider et la merger rapidement.

Cela évite ces désagréments :

  • obligation de rebaser le code à chaque déploiement d'un composant de la zone de test ;
  • rebase avec conflits (à cause des fichiers générés des zones) ;
  • kswitch ne connaît que la branche master ;
  • améliorations continues non déployées sur la zone de test ;
  • effacements de configurations de la zone de test après des déploiements de zones légitimes (principalement les zones centrales de monitoring) ;
  • code non partagé (s'il est sur un branche publiée, il n'y a pas moyen de savoir que c'est cette branche) ;
  • seule la personne qui a déployé peut facilement destroy ses zones.

Credentials Grafana#

Les credentials du compte administrateur s'obtiennent ainsi :

CONTRACT_NAME=obs-xxxxxxx
kubectl -n "grafana-client-${CONTRACT_NAME}" get secret grafana-secret -o json | jq '.data | map_values(@base64d)'

Suppression#

La suppression de l'environnement de test (zones de service et de contract) s'effectue en suivant la documentation.

Note

Au 08/09/2023, la suppression de zones n'est pas documentée. Il faudra le faire dès que possible.

En attendant, le principe générale est de lancer trackbone destroy -t purge=true sur tout ce qui est possible.

Puis il existe quelques étapes supplémentaires :

  • vérifier sur le cluster que les namespaces ont été supprimés ;
  • redéployer les rules, les probes et Blackbox-Exporter sur les clusters centraux ;
  • faire le ménage dans vault ;
  • vérifier la suppression des buckets S3 ;
  • vérifier la suppression des PV ;
  • si des namespaces ont été créés pour le Gitops Workflow, il faut faire le ménage (suppression des namespaces, déréférencement du client dans les templates...) ;
  • ...

Et enfin créer une MR avec la suppression des zones dans ngot-zones. La faire valider et la merger.