Aller au contenu

Alertmanager Ingress#

Sur Caascad, cette documentation n'est pas applicable. Alertmanager n'est pas déployé avec un Ingress.

Présentation#

Sur NGOT, il existe deux sortes d'Alertmanagers : ceux des zones de service monitoring-stack et monitoring-stack-client.

Tous sont déployés en cluster (avec deux membres) et avec 3 ingresses (un pour chaque membre et un pour le service).

Les Alertmanagers des zones monitoring-stack utilisent des ingresses privés.

Les API d'Alertmanager des zones monitoring-stack-client:

  • par défaut, ne sont pas exposées publiquement, dans ce cas l'ingress est configuré avec une whitelist;
  • peuvent être exposées sur Internet, dans ce cas l'ingress est configuré sans whitelist (voir ci-dessous pour plus de détails).

Exposition de l'API d'Alertmanager client#

Par défaut, une whitelist est configurée dans les ingress d'Alertmanager. L'exposition de l'API d'Alertmanager s'effectue dans ngot-zones dans le fichier de définition de la zone.

Tout se passe dans envs-ng. Il faut créer une branche de travail.

Par défaut, ingressClassName n'est pas indiqué.

Pour supprimer la whitelist, il faut l'ajouter comme dans l'exemple (simplifié) ci-dessous :

"svc-monitoring-stack-client-xxxxx": {
    type:               "service"
    subtype:            "monitoring-stack-client"
    ...
    parameters: {
        "monitoring-stack": {
            ...
            alertmanager: ingressClassName: "ingress-nginx-public"
            ...
        }
    }
}

A l'inverse, pour ajouter la whitelist, il faut supprimer la ligne alertmanager: ingressClassName: "ingress-nginx-public".

Regénérer les zones statiques : 

generate-static-zones-files

Puis redéployer : 

cd contexts/ngot
trackbone apply -z <zone> -c alertmanager

Pour vérifier, il faut se connecter au cluster qui porte le service : 

kswitch <zone de service>
kubectl get ingress -l app=alertmanager-v2 -n monitoring-stack-client-obs-<nom_client> -o yaml | grep  nginx.ingress.kubernetes.io/whitelist-source-range
Cette commande:

  • Ne retourne aucun résultat si l'API d'Alertmanager est exposée publiquement.
  • Retourne une ligne par Alertmanager contenant cette annotation, avec les réseaux du client figurant dans la whitelist sur le load balancer, si l'Alertmanager du client reste configuré en privé (comportement par défaut).

Un test complémentaire consiste à tester depuis internet (hors réseau interne Orange, hors VPN) si le service répond.

Enfin, il faut enregistrer les changements dans une MR à faire valider et à déployer effectivement selon les workflows appropriés.

Identifiants#

Important

Si le client demande de passer son Alertmanager d'un mode privé à public, cela n'implique pas de modifier les identifiants. Ceux-ci restent inchangés. Il suffit simplement de les ajouter en tant que variables dans le repository GitopsWorkflow du client. Pour plus de détails, consultez la section Communiquer les identifiants via GitLab (Ext).

L'authentification des Alertmanagers est de type basic avec un identifiant et un mot de passe.

Lors d'un changement de mot de passe, il n'y a pas de cohabitation entre l'ancien et le nouveau. Il n'y a jamais qu'un seul mot de passe en cours d'utilisation.

Emplacement#

L'identifiant et le mot de passe sont stockés dans Vault à cet emplacement : 

secret/zones/fe/<zone de service>/alertmanager-auth

Exemple : secret/zones/fe/svc-monitoring-stack-client-test04/alertmanager-auth

Note

Cet emplacement est valable pour les deux types de zones monitoring-stack et monitoring-stack-client.

Le mot de passe est également stocké dans un secret sur le cluster. C'est le secret qui est utilisé. Vault ne sert qu'à faciliter son obtention en évitant la recherche du secret et du cluster sur lequel il se trouve, ainsi que sa manutention.

Changement du mot de passe#

Pour changer de mot de passe, il faut redéployer l'Alertmanager avec le mode bootstrap :

trackbone apply -z <zone> -c alertmanager -t bootstrap=true

Exemple :

trackbone apply -z svc-monitoring-stack-client-test04 -c alertmanager -t bootstrap=true

Tip

Avant de lancer la commande, récupérer l'ancien mot de passe dans Vault. Cela permettra de constater le changement après avoir lancé la commande.

Communiquer les identifiants via Gitlab(Ext)#

Pour communiquer les identifiants via Gitlab(Ext), il faut les indiquer dans les variables de CI/CD ALERTMANAGER_USERNAME et ALERTMANAGER_PASSWORD.

Cela peut être réalisé avec le script client_repo_set_credentials.py du repo applications/gitops-tools. Exemple :

./client_repo_set_credentials.py -c configs/comet-stg.yaml -C obs-test04 -a alertmanager