Oefening: Elastic implementeren op virtuele Azure-machines

In deze oefening bereidt u een zelfbeheerd Elasticsearch-cluster voor op drie Azure VM's en installeert u Kibana op een afzonderlijke VM. Gebruik geauthenticeerde HTTPS-verzoeken en een synthetisch document om te bevestigen dat de knooppunten één cluster vormen. Het is een leeromgeving, geen productiemigratie. Koppelingen naar de richtlijnen waarnaar in deze oefening wordt verwezen, vindt u in de sectie Meer informatie van de samenvatting.

Tenzij in een stap expliciet beheerderswerkstation wordt vermeld, voert u opdrachtvoorbeelden uit in Bash in een SSH-sessie op de benoemde Ubuntu-VM, niet in lokale Windows PowerShell. Voer elk blok in de gegeven volgorde uit en stop als een opdracht mislukt. Vervang elke placeholder tussen punthaken door uw eigen waarde. Gebruik de RPM-opdrachten niet uit andere zelfstudies van leveranciers.

1. Het lab voorbereiden

Elastic 9.5.5 is de gepubliceerde release die is geselecteerd voor deze revisie. Voordat u begint, controleert u het beleid voor Elastic Support Matrix en versie; als deze release geen onderhoud meer ontvangt, gebruikt u een goedgekeurde, onderhouden release consistent in de stack en controleert u de bijbehorende installatie-instructies opnieuw.

Gebruik de volgende referentieconfiguratie met alleen synthetische gegevens:

Setting	Labwaarde
Resourcegroep	Een nieuw elastic-on-azure-vm-rg
Regio	East US 2 of een andere goedgekeurde regio met het vereiste quotum en de vereiste grootten
Installatiekopieën van het besturingssysteem	Ubuntu Server 24.04 LTS, x64, Generatie 2
Elastic-pakketten	Elasticsearch en Kibana 9.5.5
VMs	es-node1, es-node2, es-node3 en kibana-node
Grootte van elke VM	Standard_D2s_v5: 2 vCPU's en 8 GiB RAM
Opslag per VM	64 GiB permanente beheerde besturingssysteemschijf, Standard SSD LRS; geen tijdelijke besturingssysteemschijf
Network	elastic-lab-vnet, adresruimte 10.42.0.0/16; subnet elastic-lab-subnet, 10.42.0.0/24
Privéadressen	es-node1: es-node2; es-node3: 10.42.0.11; 10.42.0.10: 10.42.0.12; kibana-node: 10.42.0.20
Administrateur	azureuser, geverifieerd met een openbare SSH-sleutel
Uitgaande connectiviteit	Standaard NAT-gateway en het bijbehorende openbare STANDAARD-IP-adres of een goedgekeurd bestaand uitgaand pad

Bevestig machtigingen voor het maken van resources, ten minste acht beschikbare regionale vCPU's en voldoende Dsv5-familiequotum. Deze VM-grootten zijn een beginconfiguratie voor dit kleine lab, geen prestatiegarantie. In de Azure-prijscalculator maakt u een schatting van vier VM's, vier beheerde schijven, NAT Gateway, het bijbehorende openbare IP-adres, gegevensverwerking/overdracht en eventuele beheerdersconnectiviteitsbronnen. Noteer de regio, valuta, verwachte runtime en eventuele vervangende grootten.

U hebt een beheerderswerkstation met SSH/SCP nodig en gerouteerde privéconnectiviteit naar dit subnet, bijvoorbeeld via een goedgekeurde bestaande VPN. De browser van het werkstation moet ook het privé-Kibana-adres bereiken. Haal het BRON-IP-bereik van de beheerder op dat het subnet daadwerkelijk zal zien en bevestig dat het voorgestelde VNet-bereik geen verbonden netwerken overlapt. Als deze overlapt, kiest u een ander bereik en vervangt u de voorbeeldadressen doorheen deze hele oefening.

Voor browser-HTTPS moet u een goedgekeurd certificaat/privésleutel verkrijgen waarvan de subject alternative name (SAN) het privé-IP-adres van Kibana bevat, of de procedure voor het genereren van certificaten alleen voor het lab in stap 8 volgen. Uw browser moet de uitgever vertrouwen. Als het beleid van uw organisatie geen tijdelijke lab-CA toestaat, regelt u een goedgekeurd certificaat voordat u doorgaat.

2. De Azure resources inrichten

Maak de resourcegroep alleen voor oefeningen. Als de naam al bestaat, kiest u een andere naam in plaats van de groep opnieuw te gebruiken. Maak het VNet en het subnet uit stap 1 en stel vervolgens het goedgekeurde gerouteerde beheerderspad in. Plaats gedeelde VPN of andere gedeelde infrastructuur niet in deze wegwerpresourcegroep.

Gebruik de handleiding Een virtuele Linux-machine maken in de Azure-portal voor de procedure voor het maken, maar overschrijf de voorbeeldinstellingen:

1. Maak elk van de vier VM's met de installatiekopie, grootte en beheerder uit stap 1. Gebruik uw goedgekeurde openbare SSH-sleutel en behoud de bijbehorende privésleutel op het werkstation, niet op een virtuele machine.
2. Selecteer op Schijven een beheerde besturingssysteemschijf van 64 GiB met Standard SSD-opslag. In dit lab wordt de standaardgegevensmap /var/lib/elasticsearch van het pakket op die permanente besturingssysteemschijf gebruikt. Productieworkloads moeten afzonderlijk worden gedimensioneerd, meestal met toegewezen beheerde gegevensschijven.
3. Selecteer op elastic-lab-vnetelastic-lab-subnet en . Stel het openbare IP-adres in op Geen - en Openbare binnenkomende poorten op Geen. Pas deze instellingen toe op Kibana en alle Elasticsearch-knooppunten. Maak geen load balancer aan, installeer NGINX niet en open poort 80 niet.
4. Selecteer Beoordelen en maken, controleer de validatie en prijsinformatie, selecteer vervolgens Maken en voltooi eventuele SSH-sleutelbevestiging. Wacht tot de implementatie is voltooid.
5. Voordat u Elastic installeert, opent u de Netwerken> van elke virtuele machine, selecteert u de netwerkinterface en vervolgens IP-configuraties> selecteert u de primaire IP-configuratie. Stel een privé-IP-toewijzing in op Statisch en stel het adres uit stap 1 in, en sla het vervolgens op. Een adreswijziging kan de VM opnieuw opstarten; wacht op voltooiing voordat u verbinding maakt. Laat de netwerkinterface van Ubuntu geconfigureerd door DHCP in plaats van het gast-IP-adres handmatig te wijzigen.

Zie de richtlijnen voor statische privé-IP-configuratie, beheerde schijven en Elasticsearch-gegevenspaden. Plaats geen clustergegevens in tijdelijke opslag. Een geslaagde Azure-implementatie betekent nog niet dat Elasticsearch is geïnstalleerd.

3. Connectiviteit configureren voordat pakketten worden gedownload

Voor een nieuw NAT-gebaseerd lab volgt u de sectie De NAT-gateway maken van Een standaard NAT-gateway maken. Maak elastic-lab-nat in de labresourcegroep en -regio, maak het standaard openbare IP-adres elastic-lab-egress-ipen koppel de gateway aan elastic-lab-subnet. Herhaal de VM of Bastion-implementatie van die quickstart niet. Het openbare IP-adres behoort tot de gateway, niet tot een virtuele machine. Als er al een goedgekeurd firewall- of uitgaand pad bestaat, gebruik het in plaats daarvan; wijzig gedeelde routering niet en voeg niet lukraak NAT toe.

Sta DNS-omzetting, tijdsynchronisatie en de Ubuntu- en Elastic-pakketeindpunten via dat uitgaande pad toe. NAT op zichzelf is geen uitgaand inhoudsfilter.

Maak elastic-lab-nsg in de labresourcegroep en koppel deze aan elastic-lab-subnet. Voeg de volgende regels voor inkomend verkeer toe voordat u verbinding maakt. Gebruik IP-adressen voor expliciete bron-/doeladressen, Alle voor bronpoorten en vervang <administrator-source-CIDR> door het goedgekeurde gerouteerde bronbereik. Elke door komma's gescheiden lijst vertegenwoordigt meerdere IP-adressen in één uitgebreide regel.

Prioriteit	Name	Protocol/doelpoort	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	Toestaan
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	Toestaan
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	Toestaan
130	AllowAdminKibana	TCP / 5601	<administrator-source-CIDR>	10.42.0.20	Toestaan
200	DenyOtherLabIngress	Alle / alle	Any	10.42.0.0/24	Deny

De weigeringsregel is essentieel: de standaardregel AllowVNetInBound van Azure staat anders ander VNet-verkeer toe. Lagere numerieke prioriteiten worden eerst geëvalueerd. Behoud de standaardregels voor uitgaand verkeer voor dit op NAT gebaseerde wegwerplab; het filteren van uitgaand verkeer van de organisatie is gescheiden. Koppel alle gastfirewallregels aan deze stromen en inspecteer zowel subnet- als NIC-effectieve regels. NSG's zijn stateful, dus reactieverkeer voor toegestane uitgaande verbindingen heeft geen extra regel voor inkomend verkeer nodig. Bij deze regels wordt ervan uitgegaan dat het gerouteerde werkstation een voorwaarde is; voor een ander beheerontwerp zijn overeenkomstige regels vereist. Zie de richtlijnen voor de evaluatie van NSG-regels.

Maak vanaf het beheerwerkstation verbinding met elke VIRTUELE machine met behulp van het privéadres, bijvoorbeeld:

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

Controleer de SSH-hostidentiteit via uw goedgekeurde proces. Voer op elke VM sudo apt-get update uit en los eventuele DNS-, routerings- of repositoryfouten op voordat u doorgaat.

4. Het eerste Elasticsearch-knooppunt installeren en starten

Configureer op es-node1 de officiële APT-opslagplaats. Herhaal dit repositoryblok later op elk van de andere drie VM's voordat u het pakket installeert. Deze opdrachten zijn voor nieuwe Ubuntu-hosts; voeg geen dubbele Elastic repository toe aan een bestaande installatie.

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

Vergelijk de vingerafdruk van de primaire sleutel met 4609 5ACC 8548 582C 1A26 99A9 D27D 666C D88E 42B4 in de Debian-installatiehandleiding. Als deze verschilt, stop en controleer de officiële richtlijnen in plaats van een niet-geverifieerde sleutel te importeren.

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

Installeer de exacte release en noteer de geïnstalleerde versie:

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

Gebruik de gebundelde JDK. Als de aangevraagde versie niet kan worden geïnstalleerd, stop dan en controleer de beschikbaarheid van pakketten en het onderhoudsbeleid; installeer niet stilzwijgend een andere versie op één knooppunt.

Raadpleeg de richtlijnen voor systeemconfiguratie voordat u elk Elasticsearch-knooppunt start. Schakel swap uit voor deze toegewezen labhosts met sudo swapoff -a, en zet eventuele swap-vermeldingen in /etc/fstab in commentaar; schakel ook een imagespecifiek mechanisme uit waarmee swap opnieuw wordt aangemaakt. Controleer swapon --show opnieuw nadat het besturingssysteem opnieuw is opgestart. Controleer sysctl vm.max_map_count; als het onder 1048576 ligt, stel vm.max_map_count=1048576 in /etc/sysctl.conf, voer sudo sysctl --system uit en controleer het opnieuw. Het pakket kan dit automatisch configureren, dus inspecteer de effectieve waarde in plaats van conflicterende definities toe te voegen.

Het pakket configureert servicelimieten. Inspecteer ze met behulp van systemctl show elasticsearch -p LimitNOFILE -p LimitNPROC; gebruik de systeemconfiguratierichtlijnen als bootstrapcontroles mislukken. Automatische heap-grootte en de standaardknooppuntrollen behouden.

Open /etc/elasticsearch/elasticsearch.yml met sudoedit. Na de sectie Een knooppunt instellen als het eerste knooppunt in een cluster in de pakkethandleiding te volgen, kunt u bestaande instellingen bewerken in plaats van dubbele sleutels toe te voegen:

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

Behoud de standaardnaam van het knooppunt, de door het pakket gegenereerde TLS/keystore-instellingen en de eerste bootstrap-vermelding voor dit eerste knooppunt. Vervang niet het hele bestand en stel discovery.seed_hosts niet in vóór deze eerste bootstrap. De HTTP-binding bevat loopback voor lokale controles en de privé-interface voor registratie en Kibana; dit is alleen geschikt omdat geen enkele virtuele machine een openbaar IP-adres heeft en de netwerktoegang beperkt is.

Schakel de pakketservice in en start deze:

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

Voor een Debian/systemd-installatie stelt u het ingebouwde beheerderswachtwoord in of stelt u het opnieuw in met het gedocumenteerde hulpprogramma; wacht niet op een interactief wachtwoordbericht:

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

Sla de gegenereerde inloggegevens veilig op. Plak deze niet in de module, commando's, schermopnamen of een gedeeld document. Controleer het lokale HTTPS-eindpunt; curl vraagt om het wachtwoord:

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

Bevestig de verwachte clusternaam en de geïnstalleerde versie. Controleer de gegenereerde configuratie en logboeken om te bevestigen dat beveiliging, HTTP TLS en transport-TLS zijn ingeschakeld, waarbij de vereiste certificaten/vermeldingen in de keystore aanwezig zijn. Een werkend HTTP-eindpunt bewijst op zichzelf niet dat transport-TLS wordt gebruikt. Als het opstarten, tls-installatie of HTTPS mislukt, controleert u de Elasticsearch-logboeken en de uitzonderingen voor automatische configuratie voordat u doorgaat. Schakel beveiliging niet uit, voeg geen onvolledige handmatige TLS-configuratie toe en verwijder geen bestaande gegevensmap om voorbij een fout te komen.

5. De andere Elasticsearch-knooppunten aanmelden

Op es-node2, herhaal stap 4 voor het instellen van de repository, installatie van het pakket met de exacte versie en controles van vereisten voor het besturingssysteem, maar start de service niet of kopieer de bootstrapconfiguratie van het eerste knooppunt. Maak op het eerste actieve knooppunt een knooppuntinschrijvingstoken:

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

Op es-node2 gebruikt u het token met het herconfiguratieprogramma Debian/RPM voordat de eerste service wordt gestart:

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

Controleer de herconfiguratieprompt en bevestig deze. Stel in elasticsearch.ymlcluster.name: es-on-azure, transport.host: 10.42.0.11, transport.port: 9300, http.host: 0.0.0.0 en http.port: 9200 in. Behoud het gegenereerde certificaat, de vertrouwensrelatie en de discoveryconfiguratie. Gebruik de serviceopdrachten uit stap 4 om de service in te schakelen en te starten en bevestig vervolgens dat deze lid wordt van het oorspronkelijke cluster.

Zodra het tweede knooppunt toetreedt, voert u stap 6 uit op de eerste twee knooppunten voordat er een herstart plaatsvindt. Herhaal vervolgens de inschrijvingsreeks voor es-node3, met gebruik van transport.host: 10.42.0.12 en een nieuw gegenereerd token, en pas stap 6 toe op alle drie de knooppunten. Tokens verlopen na 30 minuten. Behandel ze als tijdelijke inloggegevens. Een token dat is gemaakt met -s kibana kan geen Elasticsearch-knooppunt inschrijven. Start niet drie onafhankelijke clusters op en probeer hun gegevensmappen samen te voegen.

Zie het onderdeel 'Een knooppunt opnieuw configureren om lid te worden van een bestaande cluster' in de Debian-handleiding.

6. Detectieconfiguratie consolideren

Zodra het tweede knooppunt is toegetreden, werkt u de detectieconfiguratie van het eerste knooppunt bij voordat u het opnieuw start. Nadat alle drie de knooppunten zijn toegetreden, controleert u de configuratie op elk knooppunt.

Verwijder cluster.initial_master_nodes uit de configuratie van het tot stand gebrachte cluster en stel discovery.seed_hosts in op de stabiele privéadressen van de drie mastergeschikte knooppunten:

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

Introduceer cluster.initial_master_nodes niet opnieuw bij het opnieuw opstarten of toevoegen van knooppunten. Gebruik de sectie Configuratiebestanden bijwerken in de Debian-handleiding. Dit is zelfs belangrijk wanneer de eerste inschrijving lijkt te zijn geslaagd.

7. Controleer het clusterlidmaatschap en de status

Voer op es-node1 geauthenticeerde HTTPS-verzoeken uit:

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"

Verwacht drie knooppunten in het beoogde cluster. Controleer de rollen, de gekozen master en of er geen gezondheidstoestand wordt verborgen. Voor dit lab met drie knooppunten met allocatable replica's moet u een groene status vereisen voordat u verklaart dat het is gelukt; onderzoek niet-toegewezen shards in plaats van een HTTP 200-antwoord als succes te behandelen.

Controleer op de andere knooppunten hetzelfde cluster_uuid met behulp van de lokale HTTPS-hoofdaanvraag van stap 4 en hetzelfde wachtwoord voor clusterbeheerders. Nadat de discovery-consolidatie is voltooid, voert u sudo systemctl restart elasticsearch.service uit op één knooppunt tegelijk, zodat elk knooppunt weer deel kan uitmaken van het cluster en het cluster kan herstellen voordat u een ander knooppunt opnieuw start. Dit is een labcontrole, geen vervanging voor de rolling-restartprocedure voor productie.

8. Kibana installeren en HTTPS configureren

Op kibana-node, herhaal stap 4 bij de installatie van de opslagplaats en installeer Kibana, niet Elasticsearch:

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

Het browsercertificaat voorbereiden

Als u al een goedgekeurd servercertificaat en de bijbehorende persoonlijke sleutel hebt, moet u deze veilig overdragen naar kibana-node en doorgaan met het installeren van het certificaat en het inschrijven van Kibana. Neem de benodigde tussenliggende certificaten op in het servercertificaatbestand. De alternatieve naam van het onderwerp moet 10.42.0.20 dekken, of gebruik uw goedgekeurde DNS-naam consequent in het certificaat en de browser-URL.

Voer anders, met goedkeuring om een tijdelijke lab-CA te vertrouwen, het volgende uit op es-node1. Er wordt een afzonderlijke, kortdurende CA gemaakt voor browser-naar-Kibana HTTPS; Het vervangt niet de automatisch geconfigureerde CA- of transportcertificaten van Elasticsearch.

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

Bewaar de persoonlijke SLEUTEL van de CA op es-node1; kopieer deze nooit naar het werkstation of de Kibana-VM. In dit lab worden met bestandssystemen beveiligde, niet-versleutelde PEM-serversleutels gebruikt. Gebruik voor productie het PKI- en sleutelbeveiligingsproces van uw organisatie. In de naslaginformatie over het certificaathulpprogramma worden de opties beschreven.

Ga op het werkstation van de beheerder over naar een persoonlijke, niet-gesynchroniseerde map die alleen toegankelijk is voor uw account. Download de drie gefaseerde bestanden via SSH en upload vervolgens alleen het servercertificaat en de privésleutel van de server naar Kibana. Gebruik de juiste SSH-sleutel voor elke VM:

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:

Controleer of de gedownloade SHA-256-certificaatvingerafdruk van de gedownloade CA overeenkomt met de vingerafdruk die wordt weergegeven op es-node1. Importeer alleen kibana-lab-ca.crt in de vertrouwensopslag die door uw labbrowser wordt gebruikt, volgens uw platform- en organisatiebeleid. Noteer die trustwijziging ten behoeve van opschoning. Importeer nooit een privésleutel als een vertrouwd rootcertificaat, sla een certificaatwaarschuwing over of distribueer deze lab-CA voor algemeen gebruik.

Het certificaat installeren en Kibana registreren

Installeer op kibana-node de PEM-bestanden:

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"

Als u een organisatiecertificaat gebruikt, past u de bronbestandsnamen aan. Als de privésleutel is versleuteld, geef server.ssl.keyPassphrase dan op met behulp van het Kibana-sleutelarchief, in plaats van deze in een voorbeeld te publiceren. De referentie voor de instelling voor de wachtwoordzin van de privésleutel van Kibana beschrijft het doel ervan.

Open /etc/kibana/kibana.yml met sudoedit en configureer de persoonlijke listener en browser-TLS, waarbij bestaande sleutels worden bewerkt in plaats van duplicaten te maken:

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

Laat de Elasticsearch-verbindingsinstellingen ongeconfigureerd tot de aanmelding. Zie de Kibana HTTPS-richtlijnen voor certificaatrechten en vertrouwen van de browser.

Genereer een nieuw Kibana-enrollmenttoken op een Elasticsearch-knooppunt:

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

Start de service op kibana-node:

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

Noteer de verificatiecode van zes cijfers in de servicestatus of inspecteer sudo journalctl -u kibana.service --no-pager indien nodig. Open https://10.42.0.20:5601 (of de goedgekeurde DNS-naam) in de werkstationbrowser. Geef het Kibana-enrollmenttoken op, selecteer Elastic configureren en geef de verificatiecode op als hierom wordt gevraagd. Als het token is verlopen, genereert u een nieuw token. Volg het aanmeldproces voor Debian. Meld u aan met elastic voor initieel beheer en maak vervolgens gebruikers met het juiste bereik voor routinewerk.

Controleer of Kibana verbinding maakt met het beoogde cluster met behulp van HTTPS en de Elasticsearch HTTP-CA vertrouwt. Browser-naar-Kibana-vertrouwensrelatie en Kibana-naar-Elasticsearch-vertrouwensrelatie zijn gescheiden; vervang de Elasticsearch-CA van de inschrijving niet door de lab-CA van de browser.

Werk na de inschrijving de bestaande elasticsearch.hosts instelling bij om alle drie de knooppunten op te nemen:

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

Behoud de verificatie en elasticsearch.ssl.certificateAuthorities instellingen van het door de registratie gegenereerde serviceaccount. Herstart Kibana met sudo systemctl restart kibana.service en bevestig de toegang opnieuw. Zie de richtlijnen voor verbindingen met meerdere knooppunten.

9. Een synthetisch document controleren

Gebruik de Dev Tools-console van Kibana tijdens de initiële beheerfase. Maak een toegewezen labindex met een expliciete replica:

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

Controleer of het documentantwoord "found": true en het verwachte bericht bevat. De health-respons moet beschikken over "status": "green" en "timed_out": false. Het shard-antwoord moet één primaire (p) en één replica (r), beide STARTED op verschillende knooppunten, weergeven. Een antwoord met alleen HTTP 200 is niet voldoende.

Zoek in Kibana Data Views via globaal zoeken, maak een gegevensweergave met indexpatroon module-lab-check en selecteer Ik wil het tijdsfilter niet gebruiken omdat het document geen tijdstempelveld heeft. Open Discover, selecteer deze gegevensweergave en zoek het bericht. Zie de handleiding Dataweergave maken.

Gebruik geen echte transacties, inloggegevens of klantgegevens als payload. Een optioneel ingestieproject met behulp van Logstash staat los van deze oefening; zie de volgende stappen van de samenvatting.

10. Problemen oplossen zonder de configuratie te verzwakken

Gebruik de volgende controles om veelvoorkomende problemen op te lossen zonder beveiligingsmaatregelen uit te schakelen:

Symptom	Cheque
Time-out voor SSH- of browserverbindingen	Werkstationroute, daadwerkelijk bron-IP-bereik, subnet/NIC effectieve NSG-regels, gastfirewall, listeneradres en servicestatus
Download van het pakket mislukt	DNS en expliciete uitgaande connectiviteit, juiste repository, ondertekeningssleutel en beschikbaarheid van de exacte pakketversie
Een knooppunt start niet op	/var/log/elasticsearch/es-on-azure.log, systeeminstellingen, geheugen/schijfcapaciteit, dubbele YAML-sleutels en bootstrapconfiguratie
Knooppuntregistratie mislukt	Een nieuw token met node-bereik, https-bereik voor het eerste knooppunt, privétransportconnectiviteit, overeenkomende versies en clusternaam
Certificaatfout	Corrigeer de verlenende CA, de vervaldatum van het certificaat en de Subject Alternative Name, de overeenkomende serversleutel en de leesmachtigingen voor de service; gebruik nooit curl -k
Kibana begint niet	sudo journalctl -u kibana.service --no-pager, certificaat-/sleutelindeling en machtigingen, Elasticsearch-hosts en aanmeldingsinstellingen
Gele/rode gezondheid	Shardstatus en GET _cluster/allocation/explain in Dev Tools; los de oorzaak van de toewijzing op in plaats van replica's in te stellen op nul

11. Opschonen

Open in de Azure-portal de resourcegroep van de oefening, controleer de inhoud, selecteer Resourcegroep verwijderen en vul de naam/bevestigingsprompt in. Wacht totdat het verwijderen is voltooid. Controleer op labresources die buiten die groep zijn gemaakt, waaronder schijven, momentopnamen, openbare IP-adressen en uitgaande resources. Verwijder alleen resources die deel uitmaken van deze oefening. Laat de netwerkbeheerder indien nodig labspecifieke connectiviteitsconfiguratie verwijderen zonder gedeelde connectiviteitsservices te verwijderen.

Verwijder de gedownloade privésleutel van de server en andere tijdelijke certificaatkopieën van het werkstation. Verwijder alleen de tijdelijke ca-vertrouwensvermelding die u hebt toegevoegd, met behulp van de opgenomen vingerafdruk; verwijder geen vertrouwensankers van organisaties. Verwijder labspecifieke SSH-privésleutels alleen als deze niet elders worden gebruikt. Als u de VM-resourcegroep verwijdert, worden geen werkstationbestanden of trust-store-vermeldingen verwijderd.

Het stoppen van een service of het afsluiten van het gastbesturingssysteem betekent niet dat Azure volledig is opgeschoond. Deallocatie stopt de rekenkosten voor VM's, maar stopt niet noodzakelijkerwijs de kosten voor behouden opslag of netwerkresources. Zie de richtlijnen voor VM-factureringsstaten.