Exercice - Déployer Elastic sur des machines virtuelles Azure

Dans cet exercice, préparez un cluster Elasticsearch auto-géré sur trois machines virtuelles Azure et installez Kibana sur une machine virtuelle distincte. Utilisez des requêtes HTTPS authentifiées et un document synthétique pour confirmer que les nœuds forment un cluster. Il s’agit d’un environnement d’apprentissage jetable, pas d’une migration de production. Les liens vers les conseils référencés dans cet exercice se trouvent dans la section Plus d’informations du résumé.

Sauf si une étape indique explicitement une station de travail d’administrateur, exécutez des exemples de commandes dans Bash dans une session SSH sur la machine virtuelle Ubuntu nommée, et non dans Windows powerShell local. Exécutez chaque bloc dans l’ordre et arrêtez en cas d’échec d’une commande. Remplacez chaque espace réservé entre chevrons par la valeur de votre choix. N’utilisez pas les commandes RPM provenant de tutoriels d’autres fournisseurs.

1. Préparer le laboratoire

Elastic 9.5.5 est la version publiée sélectionnée pour cette révision. Avant de commencer, consultez la matrice de compatibilité et la politique de gestion des versions d’Elastic. Si cette version ne bénéficie plus de maintenance, utilisez une version approuvée et toujours maintenue de manière cohérente dans l’ensemble de la pile, puis vérifiez à nouveau ses instructions d’installation.

Utilisez la configuration de référence suivante avec des données synthétiques uniquement :

Setting	Valeur du laboratoire
Groupe de ressources	Un nouveau elastic-on-azure-vm-rg
Region	East US 2 ou une autre région approuvée avec le quota et les tailles requis
image du système d'exploitation	Ubuntu Server 24.04 LTS, x64, Génération 2
Packages Elastic	Elasticsearch et Kibana 9.5.5
Machines virtuelles	es-node1, es-node2, es-node3 et kibana-node
Taille de chaque machine virtuelle	Standard_D2s_v5: 2 processeurs virtuels et 8 Gio de RAM
Stockage par machine virtuelle	Disque de système d’exploitation managé persistant de 64 Gio, disque SSD Standard LRS ; aucun disque de système d’exploitation éphémère
Network	elastic-lab-vnet, espace d’adressage 10.42.0.0/16; sous-réseau elastic-lab-subnet, 10.42.0.0/24
Adresses privées	es-node1: es-node2; 10.42.0.11: 10.42.0.10; es-node3: 10.42.0.12; kibana-node: 10.42.0.20
Administrator	azureuser, authentifié avec une clé publique SSH
Connectivité sortante	Passerelle NAT standard et son adresse IP publique standard ou un chemin d’accès de sortie existant approuvé

Vérifiez les autorisations de création de ressources, au moins huit processeurs virtuels régionaux disponibles et un quota de famille Dsv5 suffisant. Ces tailles de machine virtuelle sont une configuration de démarrage pour ce petit laboratoire, et non une garantie de performances. Dans la calculatrice de prix Azure, estimez quatre machines virtuelles, quatre disques managés, une passerelle NAT, son adresse IP publique, le traitement/le transfert de données et toutes les ressources de connectivité d’administrateur. Consignez la région, la devise, le temps d’exécution prévu et les tailles substituées.

Vous avez besoin d’une station de travail administrateur avec SSH/SCP et d’une connectivité privée routée vers ce sous-réseau, par exemple via un VPN existant approuvé. Le navigateur de la station de travail doit également atteindre l’adresse Kibana privée. Obtenez la plage d’adresses IP sources de l’administrateur que le sous-réseau verra et vérifiez que la plage VNet proposée ne chevauche pas les réseaux connectés. Si elle se chevauche, choisissez une plage différente et remplacez les exemples d’adresses tout au long de cet exercice.

Pour le protocole HTTPS dans le navigateur, obtenez soit un certificat et une clé privée approuvés dont le nom alternatif du sujet (SAN) couvre l’adresse IP privée de Kibana, soit suivez la procédure de génération de certificat réservée au laboratoire à l’étape 8. Votre navigateur doit faire confiance à son émetteur. Si la politique de votre organisation n’autorise pas l’utilisation d’une autorité de certification (CA) temporaire pour le laboratoire, procurez-vous un certificat approuvé avant de poursuivre.

2. Déployer les ressources Azure

Créez le groupe de ressources exercice uniquement. Si le nom existe déjà, choisissez-en un autre au lieu de réutiliser le groupe. Créez le réseau virtuel (VNet) et le sous-réseau de l’étape 1, puis établissez le chemin d’accès administrateur routé approuvé. Ne placez pas de VPN partagé ou d’autre infrastructure partagée dans ce groupe de ressources jetable.

Utilisez le guide Créer une machine virtuelle Linux dans le portail Azure pour le flux de création, mais remplacez ses exemples de paramètres :

1. Créez chacune des quatre machines virtuelles avec l’image, la taille et l’administrateur définis à l’étape 1. Utilisez votre clé publique SSH approuvée et conservez la clé privée correspondante sur la station de travail, et non sur une machine virtuelle.
2. Sur les disques, sélectionnez un disque de système d’exploitation managé de 64 Gio avec stockage SSD Standard . Ce laboratoire utilise le répertoire de données par défaut /var/lib/elasticsearch du package sur ce disque de système d’exploitation persistant. Les charges de travail de production doivent être dimensionnées séparément, généralement avec des disques de données managés dédiés.
3. Sur Mise en réseau, sélectionnez elastic-lab-vnet et elastic-lab-subnet. Définissez l’adresse IP publique sur Aucun et les ports entrants publics sur Aucun. Appliquez ces paramètres à Kibana ainsi qu’à tous les nœuds Elasticsearch. Ne créez pas d’équilibreur de charge, n’installez pas NGINX et n’ouvrez pas le port 80.
4. Sélectionnez Vérifier + créer, examinez les résultats de la validation et les tarifs, puis sélectionnez Créer et confirmez la clé SSH si nécessaire. Attendez la fin du déploiement.
5. Avant d’installer Elastic, ouvrez les paramètres Réseau>Paramètres réseau de chaque machine virtuelle, sélectionnez son interface réseau, puis accédez à Configurations IP> et à sa configuration IP principale. Définissez l’affectation de l’adresse IP privée sur Statique, saisissez l’adresse indiquée à l’étape 1, puis enregistrez. Une modification d’adresse peut redémarrer la machine virtuelle ; attendez la fin avant de vous connecter. Laissez l’interface réseau d’Ubuntu configurée par DHCP plutôt que de modifier manuellement son adresse IP de l’invité.

Consultez les instructions sur la configuration d’adresses IP privées statiques, les disques managés et les chemins de données Elasticsearch. Ne placez pas les données de cluster sur un stockage temporaire. Un déploiement Azure réussi ne signifie pas encore qu'Elasticsearch est installé.

3. Configurer la connexion réseau avant de télécharger des paquets

Pour un nouveau laboratoire basé sur NAT, consultez la section Créer la passerelle NAT de Créer une passerelle NAT standard. Créez elastic-lab-nat dans le groupe de ressources et la région du labo, créez son adresse IP publique Standard elastic-lab-egress-ip, et associez la passerelle à elastic-lab-subnet. Ne répétez pas le déploiement de VM ou de Bastion de ce guide de démarrage rapide. L’adresse IP publique appartient à la passerelle, et non à une machine virtuelle. Si un chemin de pare-feu/sortie approuvé existe déjà, utilisez-le à la place ; ne modifiez pas le routage partagé ou n’ajoutez pas NAT sans discrimination.

Autorisez la résolution DNS, la synchronisation de temps et les points de terminaison de package Ubuntu et Elastic via ce chemin d’accès de sortie. NAT seul n’est pas un filtre de contenu sortant.

Créez elastic-lab-nsg dans le groupe de ressources lab et associez-le à elastic-lab-subnet. Ajoutez les règles de trafic entrant suivantes avant de vous connecter. Utilisez Adresses IP pour définir explicitement les adresses source et de destination, Toutes pour les ports source, et remplacez <administrator-source-CIDR> par la plage source routée approuvée. Chaque liste séparée par des virgules représente plusieurs adresses IP dans une règle augmentée.

Priority	Name	Protocole / port de destination	Sources	Destinations	Action
100	AllowAdminSSH	TCP / 22	<administrator-source-CIDR>	10.42.0.10,10.42.0.11,10.42.0.12,10.42.0.20	Autoriser
110	AllowElasticsearchTransport	TCP / 9300	10.42.0.10,10.42.0.11,10.42.0.12	10.42.0.10,10.42.0.11,10.42.0.12	Autoriser
120	AllowElasticsearchHTTPS	TCP / 9200	10.42.0.10,10.42.0.11,10.42.0.12,10.42.0.20	10.42.0.10,10.42.0.11,10.42.0.12	Autoriser
130	AllowAdminKibana	TCP / 5601	<administrator-source-CIDR>	10.42.0.20	Autoriser
200	DenyOtherLabIngress	N’importe lequel / N’importe lequel	N'importe lequel	10.42.0.0/24	Deny

La règle de refus est essentielle : la règle par défaut AllowVNetInBound de Azure autorise sinon d'autres trafics de réseau virtuel. Les priorités numériques inférieures sont évaluées en premier. Conservez les règles de trafic sortant par défaut pour ce laboratoire temporaire basé sur NAT ; le filtrage du trafic sortant de l’organisation est une opération distincte. Faites correspondre les règles du pare-feu du système invité à ces flux et examinez les règles effectives du sous-réseau et de la carte réseau. Les groupes de sécurité réseau sont avec état. Par conséquent, le trafic de réponse pour les connexions sortantes autorisées n’a pas besoin d’une autorisation entrante supplémentaire. Ces règles supposent le prérequis d’une station de travail routée ; une conception de gestion différente nécessite des règles correspondantes. Consultez les instructions sur l’évaluation des règles de groupe de sécurité réseau.

À partir de la station de travail administrateur, connectez-vous à chaque machine virtuelle à l’aide de son adresse privée, par exemple :

ssh -i "<ssh-private-key-path>" azureuser@10.42.0.10

Vérifiez l’identité de l’hôte SSH par le biais de votre processus approuvé. Sur chaque machine virtuelle, exécutez sudo apt-get update et résolvez les erreurs DNS, de routage ou de référentiel avant de continuer.

4. Installer et démarrer le premier nœud Elasticsearch

Sur es-node1, configurez le dépôt APT officiel. Répétez ce bloc de référentiel ultérieurement sur chacune des trois autres machines virtuelles avant d’installer son package. Ces commandes sont destinées aux hôtes Ubuntu frais ; n’ajoutez pas de référentiel Elastic en double à une installation existante.

sudo apt-get update
sudo apt-get install -y ca-certificates curl gnupg unzip
curl --fail --silent --show-error https://artifacts.elastic.co/GPG-KEY-elasticsearch \
  -o /tmp/elastic-signing-key.asc
gpg --show-keys --with-fingerprint /tmp/elastic-signing-key.asc

Comparez l’empreinte de la clé primaire avec 4609 5ACC 8548 582C 1A26 99A9 D27D 666C D88E 42B4 dans le guide d’installation de Debian. S’il diffère, arrêtez et vérifiez les instructions officielles plutôt que d’importer une clé non vérifiée.

sudo gpg --dearmor --output /usr/share/keyrings/elasticsearch-keyring.gpg \
  /tmp/elastic-signing-key.asc
sudo chmod 644 /usr/share/keyrings/elasticsearch-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/elasticsearch-keyring.gpg] https://artifacts.elastic.co/packages/9.x/apt stable main" \
  | sudo tee /etc/apt/sources.list.d/elastic-9.x.list
sudo apt-get update

Installez la version exacte et enregistrez la version installée :

sudo apt-get install -y elasticsearch=9.5.5
dpkg-query -W -f='${Package} ${Version}\n' elasticsearch

Utilisez le JDK groupé. Si la version demandée ne peut pas être installée, arrêtez et vérifiez la disponibilité du package et la stratégie de maintenance ; n’installez pas silencieusement une autre version sur un nœud.

Avant de démarrer chaque nœud Elasticsearch, passez en revue les instructions de configuration du système. Désactivez l’échange pour ces hôtes de laboratoire dédiés avec sudo swapoff -a, et commentez toutes les entrées d’échange dans /etc/fstab; désactivez également tout mécanisme spécifique à l’image qui recrée l’échange. Vérifiez swapon --show à nouveau après un redémarrage du système d’exploitation. Vérifiez sysctl vm.max_map_count ; si la valeur est inférieure à 1048576, définissez vm.max_map_count=1048576 dans /etc/sysctl.conf, exécutez sudo sysctl --system, puis vérifiez à nouveau. Le package peut configurer ce paramètre automatiquement, donc inspectez la valeur effective au lieu d’ajouter des définitions conflictuelles.

Le package configure les limites du service. Inspectez-les à l’aide de systemctl show elasticsearch -p LimitNOFILE -p LimitNPROC ; utilisez les instructions de configuration du système si les vérifications de démarrage échouent. Conservez le dimensionnement automatique du tas et les rôles de nœud par défaut.

Ouvrir /etc/elasticsearch/elasticsearch.yml avec sudoedit. En suivant la section Configurer un nœud comme premier nœud d’un cluster du guide du package, modifiez les paramètres existants plutôt que d’ajouter des clés en double :

cluster.name: es-on-azure
transport.host: 10.42.0.10
transport.port: 9300
http.host: 0.0.0.0
http.port: 9200

Conservez le nom du nœud par défaut, les paramètres TLS/keystore générés par le package et l’entrée de démarrage initiale pour ce premier nœud. Ne remplacez pas l’intégralité du fichier et ne définissez pas discovery.seed_hosts avant ce démarrage initial. La configuration de liaison HTTP inclut le bouclage pour les vérifications locales et l’interface privée pour l’enrôlement et Kibana ; elle est appropriée ici uniquement, car aucune machine virtuelle n’a d’adresse IP publique et l’accès réseau est restreint.

Activez et démarrez le service du package :

sudo systemctl daemon-reload
sudo systemctl enable elasticsearch.service
sudo systemctl start elasticsearch.service
sudo systemctl status elasticsearch.service --no-pager

Pour une installation Debian/systemd, définissez ou réinitialisez le mot de passe administrateur intégré avec l’outil documenté ; n’attendez pas un message de mot de passe de démarrage interactif :

sudo /usr/share/elasticsearch/bin/elasticsearch-reset-password -u elastic

Stockez les informations d’identification générées en toute sécurité. Ne le collez pas dans le module, dans des commandes, des captures d’écran ou dans un document partagé. Vérifiez le point de terminaison HTTPS local ; curl demande le mot de passe :

sudo curl --fail --silent --show-error \
  --cacert /etc/elasticsearch/certs/http_ca.crt \
  --user elastic "https://localhost:9200/"

Vérifiez le nom du cluster attendu et la version installée. Inspectez la configuration et les journaux générés pour vérifier que la sécurité, LE PROTOCOLE TLS HTTP et le protocole TLS de transport sont activés, avec les entrées de magasin de clés/certificats requises présentes. Un point de terminaison HTTP fonctionnel ne prouve pas, à lui seul, que le chiffrement TLS du transport est opérationnel. Si le démarrage, la configuration TLS ou HTTPS échoue, inspectez les journaux Elasticsearch et les exceptions de configuration automatique avant de continuer. Ne désactivez pas la sécurité, n’ajoutez pas de configuration TLS manuelle incomplète et ne supprimez pas un répertoire de données existant pour contourner une erreur.

5. Inscrire les autres nœuds Elasticsearch

Sur es-node2, répétez la configuration du dépôt de l’étape 4, l’installation du package dans sa version exacte et les vérifications des prérequis du système d’exploitation, mais ne démarrez pas son service et ne copiez pas la configuration d’amorçage du premier nœud. Sur le premier nœud en cours d’exécution, créez un jeton d’inscription de nœud :

sudo /usr/share/elasticsearch/bin/elasticsearch-create-enrollment-token -s node

Sur es-node2, utilisez le jeton avec l’outil de reconfiguration Debian/RPM avant le premier démarrage du service :

sudo /usr/share/elasticsearch/bin/elasticsearch-reconfigure-node \
  --enrollment-token "<node-enrollment-token>"

Passez en revue et confirmez l’invite de reconfiguration. Dans elasticsearch.yml, définissez cluster.name: es-on-azure, transport.host: 10.42.0.11, transport.port: 9300, http.host: 0.0.0.0 et http.port: 9200. Conservez le certificat généré, la configuration de confiance et les paramètres de découverte. Utilisez les commandes de service de l’étape 4 pour activer et démarrer le service, puis confirmez qu’il rejoint le cluster d’origine.

Dès que le deuxième nœud se joint, effectuez l’étape 6 sur les deux premiers nœuds avant tout redémarrage. Répétez ensuite la séquence d’inscription pour es-node3, à l’aide de transport.host: 10.42.0.12 et d’un jeton nouvellement généré, puis appliquez l’étape 6 aux trois nœuds. Les jetons expirent après 30 minutes. Traitez-les comme des informations d’identification temporaires. Un jeton créé avec -s kibana ne permet pas d’inscrire un nœud Elasticsearch. N'initialisez pas trois clusters indépendants et ne tentez pas de fusionner leurs répertoires de données.

Consultez la section Reconfigurer un nœud du guide Debian pour rejoindre un cluster existant.

6. Consolider la configuration de la découverte

Dès que le deuxième nœud a rejoint, mettez à jour la configuration de découverte du premier nœud avant tout redémarrage. Une fois que les trois nœuds ont rejoint le cluster, vérifiez la configuration sur chaque nœud.

Supprimez cluster.initial_master_nodes de la configuration du cluster établi et définissez discovery.seed_hosts sur les adresses privées stables des trois nœuds éligibles au rôle de maître :

discovery.seed_hosts:
  - "10.42.0.10:9300"
  - "10.42.0.11:9300"
  - "10.42.0.12:9300"

Ne réintroduisez pas cluster.initial_master_nodes lors du redémarrage ou de l’ajout de nœuds. Utilisez la section Mettre à jour les fichiers de configuration du guide Debian. Cela importe même lorsque l’inscription initiale semble avoir réussi.

7. Vérifier l’appartenance et l’état de santé du cluster

Sur es-node1, exécutez des requêtes HTTPS authentifiées :

sudo curl --fail --silent --show-error \
  --cacert /etc/elasticsearch/certs/http_ca.crt \
  --user elastic "https://localhost:9200/_cat/nodes?v"

sudo curl --fail --silent --show-error \
  --cacert /etc/elasticsearch/certs/http_ca.crt \
  --user elastic "https://localhost:9200/_cluster/health?pretty"

Attendez-vous à trois nœuds dans le cluster prévu. Vérifiez les rôles, le nœud maître élu et l’absence de conditions d’intégrité masquées. Pour ce laboratoire à trois nœuds avec des réplicas allocatables, exigez une intégrité verte avant de déclarer la réussite ; examinez les shards non assignés plutôt que de traiter une réponse HTTP 200 comme réussie.

Depuis les autres nœuds, vérifiez le même cluster_uuid à l’aide de la requête HTTPS locale à la racine décrite à l’étape 4, ainsi que du même mot de passe administrateur du cluster. Après la consolidation de la découverte, exécutez sudo systemctl restart elasticsearch.service sur un seul nœud à la fois, en laissant chaque nœud rejoindre le cluster et celui-ci retrouver son état normal avant de redémarrer le suivant. Il s’agit d’une vérification de laboratoire et ne remplace pas la procédure de redémarrage progressif de production.

8. Installer Kibana et configurer HTTPS

Sur kibana-node, répétez l’installation du dépôt de l’étape 4, puis installez Kibana, et non Elasticsearch :

sudo apt-get install -y kibana=9.5.5
dpkg-query -W -f='${Package} ${Version}\n' kibana

Préparer le certificat du navigateur

Si vous disposez déjà d’un certificat serveur approuvé et de la clé privée correspondante, transférez-les de manière sécurisée vers kibana-node, puis passez à la section Installer le certificat et inscrire Kibana. Incluez les certificats intermédiaires nécessaires dans le fichier de certificat de serveur. Son nom alternatif du sujet (SAN) doit couvrir 10.42.0.20, ou utilisez votre nom DNS approuvé de manière cohérente dans le certificat et l’URL du navigateur.

Sinon, avec l’autorisation de faire confiance à une autorité de certification de laboratoire temporaire, exécutez ce qui suit sur es-node1. Il crée une autorité de certification distincte et de courte durée pour le protocole HTTPS entre le navigateur et Kibana ; il ne remplace pas l’autorité de certification configurée automatiquement par Elasticsearch, ni les certificats de transport.

sudo install -d -m 700 /root/elastic-lab-pki
sudo /usr/share/elasticsearch/bin/elasticsearch-certutil ca --pem \
  --days 30 --out /root/elastic-lab-pki/kibana-ca.zip
sudo unzip /root/elastic-lab-pki/kibana-ca.zip -d /root/elastic-lab-pki
sudo /usr/share/elasticsearch/bin/elasticsearch-certutil cert --pem \
  --name kibana-server --ip 10.42.0.20 --days 30 \
  --ca-cert /root/elastic-lab-pki/ca/ca.crt \
  --ca-key /root/elastic-lab-pki/ca/ca.key \
  --out /root/elastic-lab-pki/kibana-server.zip
sudo unzip /root/elastic-lab-pki/kibana-server.zip -d /root/elastic-lab-pki
install -d -m 700 "$HOME/kibana-tls"
sudo install -o azureuser -g azureuser -m 600 \
  /root/elastic-lab-pki/kibana-server/kibana-server.crt "$HOME/kibana-tls/"
sudo install -o azureuser -g azureuser -m 600 \
  /root/elastic-lab-pki/kibana-server/kibana-server.key "$HOME/kibana-tls/"
sudo install -o azureuser -g azureuser -m 600 \
  /root/elastic-lab-pki/ca/ca.crt "$HOME/kibana-tls/kibana-lab-ca.crt"
sudo openssl x509 -in /root/elastic-lab-pki/ca/ca.crt -noout -fingerprint -sha256

Conservez la clé privée de l’autorité de certification sur es-node1 ; ne la copiez jamais sur la station de travail ou la machine virtuelle Kibana. Ce laboratoire utilise des clés de serveur PEM protégées par le système de fichiers et non chiffrées. Pour la production, utilisez le processus PKI et de protection des clés de votre organisation. La référence de l’utilitaire de certificat décrit les options.

Sur la station de travail administrateur, passez à un répertoire privé non synchronisé auquel seul votre compte a accès. Téléchargez les trois fichiers préparés via SSH, puis chargez uniquement le certificat de serveur et la clé privée du serveur sur Kibana. Utilisez la clé SSH correcte pour chaque machine virtuelle :

scp -i "<es-node1-ssh-private-key-path>" azureuser@10.42.0.10:kibana-tls/kibana-server.crt .
scp -i "<es-node1-ssh-private-key-path>" azureuser@10.42.0.10:kibana-tls/kibana-server.key .
scp -i "<es-node1-ssh-private-key-path>" azureuser@10.42.0.10:kibana-tls/kibana-lab-ca.crt .
scp -i "<kibana-ssh-private-key-path>" kibana-server.crt kibana-server.key azureuser@10.42.0.20:

Vérifiez que l’empreinte digitale du certificat SHA-256 de l’autorité de certification téléchargée correspond à celle affichée sur es-node1. Importez uniquement kibana-lab-ca.crt dans le magasin de certificats de confiance utilisé par le navigateur de votre laboratoire, en suivant la politique de votre plateforme et de votre organisation. Consignez cette modification de la configuration de confiance afin de pouvoir l’annuler lors du nettoyage. N’importez jamais une clé privée en tant qu’autorité de certification racine de confiance, ne contournez jamais un avertissement de certificat et ne distribuez jamais cette autorité de certification de laboratoire pour un usage général.

Installer le certificat et enrôler Kibana

Sur kibana-node, installez les fichiers PEM :

sudo install -o root -g kibana -m 640 "$HOME/kibana-server.crt" /etc/kibana/kibana-server.crt
sudo install -o root -g kibana -m 640 "$HOME/kibana-server.key" /etc/kibana/kibana-server.key
rm -- "$HOME/kibana-server.crt" "$HOME/kibana-server.key"

Si vous utilisez un certificat organisationnel, adaptez les noms de fichiers sources. Si sa clé privée est chiffrée, fournissez server.ssl.keyPassphrase à l’aide du magasin de clés Kibana, plutôt que de la publier dans un exemple. La documentation de référence du paramètre de phrase de passe de clé privée de Kibana décrit son objectif.

Ouvrez sudoedit avec /etc/kibana/kibana.yml et configurez l’écouteur privé et le protocole TLS du navigateur, en modifiant les clés existantes plutôt que de créer des doublons :

server.host: "10.42.0.20"
server.port: 5601
server.ssl.enabled: true
server.ssl.certificate: /etc/kibana/kibana-server.crt
server.ssl.key: /etc/kibana/kibana-server.key

Laissez les paramètres de connexion Elasticsearch non configurés jusqu’à l’inscription. Consultez les recommandations relatives à HTTPS dans Kibana pour connaître les autorisations des certificats et les paramètres de confiance du navigateur.

Générez un nouveau jeton d’inscription Kibana sur un nœud Elasticsearch :

sudo /usr/share/elasticsearch/bin/elasticsearch-create-enrollment-token -s kibana

Sur kibana-node, démarrez le service :

sudo systemctl daemon-reload
sudo systemctl enable kibana.service
sudo systemctl start kibana.service
sudo systemctl status kibana.service --no-pager

Enregistrez le code de vérification à six chiffres dans l’état du service ou inspectez sudo journalctl -u kibana.service --no-pager si nécessaire. Dans le navigateur de station de travail, ouvrez https://10.42.0.20:5601 (ou le nom DNS approuvé). Fournissez le jeton d’inscription Kibana, sélectionnez Configurer Elastic et fournissez le code de vérification si vous y êtes invité. Si le jeton a expiré, générez-en un autre. Suivez la procédure d’inscription Debian. Connectez-vous avec elastic pour l’administration initiale, puis créez des utilisateurs avec des autorisations adaptées pour le travail de routine.

Vérifiez que Kibana se connecte au cluster prévu via HTTPS et qu’il fait confiance à l’autorité de certification HTTP d’Elasticsearch. Les relations de confiance Browser-to-Kibana et Kibana-to-Elasticsearch sont séparées ; ne remplacez pas l’autorité de certification Elasticsearch de l’inscription par la CA de labo du navigateur.

Après l’inscription, mettez à jour le paramètre existant elasticsearch.hosts pour inclure les trois nœuds :

elasticsearch.hosts:
  - "https://10.42.0.10:9200"
  - "https://10.42.0.11:9200"
  - "https://10.42.0.12:9200"

Conservez les paramètres d’authentification du compte de service et elasticsearch.ssl.certificateAuthorities générés lors de l’inscription. Redémarrez Kibana avec sudo systemctl restart kibana.service et confirmez à nouveau l’accès. Consultez les instructions de connexion à plusieurs nœuds.

9. Vérifier un document synthétique

Utilisez la console Outils de développement de Kibana pendant l’administration initiale. Créez un index lab dédié avec un réplica explicite :

PUT module-lab-check
{
  "settings": {
    "number_of_shards": 1,
    "number_of_replicas": 1
  }
}

PUT module-lab-check/_doc/1?refresh=wait_for
{
  "message": "Azure VM lab connectivity check"
}

GET module-lab-check/_doc/1

GET _cluster/health/module-lab-check?wait_for_status=green&timeout=60s

GET _cat/shards/module-lab-check?v

Vérifiez que la réponse du document contient "found": true et le message attendu. La réponse d’intégrité doit contenir "status": "green" et "timed_out": false. La réponse de partition doit afficher un primaire (p) et un réplica (r), tous deux STARTED sur des nœuds différents. Une réponse avec HTTP 200 seul n’est pas suffisante.

Dans Kibana, recherchez Vues de données à l’aide de la recherche globale, créez une vue de données avec le modèle d’index module-lab-check, puis sélectionnez Je ne souhaite pas utiliser le filtre temporel, car le document ne comporte aucun champ d’horodatage. Ouvrez Discover, sélectionnez cette vue de données et recherchez le message. Consultez le guide Créer une vue de données.

N’utilisez pas de transactions réelles, d’informations d’identification ou de données client comme charge utile. Un projet d’ingestion facultatif utilisant Logstash est distinct de cet exercice ; consultez les étapes suivantes du résumé.

10. Résoudre les problèmes sans affaiblir la configuration

Utilisez les vérifications suivantes pour résoudre les problèmes courants sans désactiver les contrôles de sécurité :

Symptôme	Vérification
La connexion SSH ou au navigateur expire	Vérifiez la route du poste de travail, la plage réelle d’adresses IP source, les règles NSG effectives du sous-réseau et de la carte réseau, le pare-feu du système invité, l’adresse d’écoute et l’état du service
Échec du téléchargement du package	Connectivité sortante DNS et explicite, référentiel correct, clé de signature et disponibilité de la version exacte du package
Un nœud ne parvient pas à démarrer	/var/log/elasticsearch/es-on-azure.log, paramètres système, capacité de mémoire/disque, clés YAML dupliquées et configuration de démarrage
Échec de l’inscription du nœud	Vérifiez qu’un jeton récent limité à node a été généré, que le premier nœud est accessible via HTTPS, que la connectivité de transport privée fonctionne et que les versions ainsi que le nom du cluster correspondent
Erreur de certificat	Vérifiez l’autorité de certification émettrice, la date d’expiration du certificat, son nom alternatif du sujet (SAN), la correspondance de la clé du serveur et les autorisations de lecture du service. N’utilisez jamais curl -k
Kibana ne démarre pas	sudo journalctl -u kibana.service --no-pager, format de certificat/clé et autorisations, hôtes Elasticsearch et paramètres d’inscription
État du cluster jaune ou rouge	État de partition et GET _cluster/allocation/explain dans Dev Tools ; corrigez la cause d’allocation plutôt que de définir les réplicas sur zéro

11. Nettoyer

Dans le portail Azure, ouvrez le groupe de ressources d’exercice, examinez son contenu, sélectionnez Supprimer le groupe de ressources, puis terminez l’invite de nom/confirmation. Attendez la fin de la suppression. Recherchez les ressources de laboratoire créées en dehors de ce groupe, notamment les disques, les instantanés, les adresses IP publiques et les ressources de trafic sortant. Supprimez uniquement les ressources appartenant à cet exercice. Si nécessaire, demandez à l’administrateur réseau de supprimer la configuration de connectivité spécifique au laboratoire, sans supprimer les services de connectivité partagée.

Supprimez la clé privée téléchargée du serveur et d’autres copies de certificat temporaires de la station de travail. Supprimez uniquement l’entrée de confiance de l’autorité de certification du laboratoire temporaire que vous avez ajoutée, à l’aide de son empreinte digitale enregistrée ; ne supprimez pas les ancres de confiance organisationnelle. Supprimez des clés privées SSH spécifiques au laboratoire uniquement si elles ne sont pas utilisées ailleurs. Examinez d’abord le groupe et poursuivez uniquement s’il contient exclusivement des ressources temporaires créées pour l’exercice.

L'arrêt d'un service ou l'arrêt du système d'exploitation invité ne constitue pas un nettoyage complet d’Azure. La désallocation arrête les frais de calcul de la machine virtuelle, mais ne met pas nécessairement fin à la facturation du stockage ou des ressources réseau conservés. Consultez les recommandations relatives aux états de facturation des machines virtuelles.