Elastic Stack unter Rocky Linux 9: Installation, TLS und ILM im Betrieb

EdwardMoon

Der Aufbau eines Elastic Stack endet nicht mit der Installation von vier Paketen. Authentifizierung der Erfassung, TLS und Rechte in Elasticsearch, Erreichbarkeit von Kibana, Aufbewahrung und Snapshot-Wiederherstellung bilden einen gemeinsamen Betriebsrahmen. Dieser Leitfaden beschreibt reproduzierbare Installations- und Prüfverfahren für Rocky Linux 9 und Elastic Stack 9.4.2.

Die Übung beginnt auf einem einzelnen Host; im Produktivbetrieb werden Rollen und Ausfallbereiche getrennt. Zu den Befehlen gehören Zweck und Prüfung. Passwörter und API-Schlüssel werden weder im Artikel noch im Shell-Verlauf fest eingetragen; die von Elastic standardmäßig aktivierten Sicherheitsfunktionen bleiben eingeschaltet.

Umfang und Komponenten

Planung und Voraussetzungen

Rocky Linux 9 ist RHEL-kompatibel. Falls kommerzieller Support benötigt wird, die genaue Betriebssystemkombination in der Elastic-Supportmatrix prüfen. Alle Stack-Komponenten auf dieselbe Version abstimmen. Die Beispiele verwenden 9.4.2; das ist keine Aussage über die jeweils neueste Version. Bei der Installation Paketverfügbarkeit im offiziellen Repository und Supportmatrix prüfen.

Übungs- und Produktionstopologie unterscheiden

Hostressourcen und Zeitsynchronisierung prüfen

sudo dnf install -y curl jq

cat /etc/rocky-release
uname -r
timedatectl status
free -h
df -hT /var/lib /var/log
sysctl vm.max_map_count
ulimit -n

Elasticsearch nutzt neben dem JVM-Heap intensiv den Dateisystemcache. Aufwendige Logstash-Verarbeitung auf demselben Host kann daher leicht zu Speicherkonkurrenz führen. Zunächst die automatische Heap-Dimensionierung verwenden. Xms und Xmx nur auf Grundlage von Lasttests auf denselben manuellen Wert setzen.

Repository und Pakete für Version 9.4.2 installieren

Den offiziellen GPG-Schlüssel und das RPM-Repository für 9.x verwenden. Ein standardmäßig deaktiviertes Repository verringert unerwartete Versionswechsel bei gewöhnlichen dnf-update-Läufen. Vor der Installation Änderungsverlauf und Kompatibilität prüfen.

Offiziellen GPG-Schlüssel und Repository registrieren

sudo rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch

sudo tee /etc/yum.repos.d/elastic-9.x.repo >/dev/null <<'EOF'
[elastic-9.x]
name=Elastic repository for 9.x packages
baseurl=https://artifacts.elastic.co/packages/9.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=0
type=rpm-md
EOF

sudo dnf clean metadata
sudo dnf --disablerepo='*' --enablerepo=elastic-9.x list available   elasticsearch kibana logstash filebeat

Einheitliche Versionen installieren und Versionsbindung prüfen

STACK_VERSION='9.4.2'
sudo dnf install --enablerepo=elastic-9.x   "elasticsearch-${STACK_VERSION}"   "kibana-${STACK_VERSION}"   "logstash-${STACK_VERSION}"   "filebeat-${STACK_VERSION}"

rpm -q elasticsearch kibana logstash filebeat
sudo dnf install python3-dnf-plugin-versionlock
sudo dnf versionlock add elasticsearch kibana logstash filebeat

Elasticsearch als sicheren Einzelknoten konfigurieren

In der Einzelknotenübung Elasticsearch nur an Loopback binden. Beim ersten Start richtet Elastic 9.x Authentifizierung sowie HTTP- und Transport-TLS automatisch ein. Diese Funktionen beibehalten und die Clients so konfigurieren, dass sie der erzeugten CA vertrauen.

Minimale elasticsearch.yml-Einstellungen für die Übung

Mit den folgenden Befehlen die Datei sichern und bearbeiten. Jeden nachfolgenden YAML-Schlüssel genau einmal in der bestehenden Datei setzen und die automatisch erzeugten Authentifizierungs- und TLS-Einstellungen erhalten. Die Gesamtdatei nicht durch diesen kurzen YAML-Ausschnitt ersetzen.

sudo cp -a /etc/elasticsearch/elasticsearch.yml /etc/elasticsearch/elasticsearch.yml.before-lab
sudoedit /etc/elasticsearch/elasticsearch.yml

cluster.name: logs-lab
node.name: es01
network.host: 127.0.0.1
http.host: 127.0.0.1
transport.host: 127.0.0.1
discovery.type: single-node

sudo systemctl daemon-reload
sudo systemctl enable --now elasticsearch
sudo systemctl status elasticsearch --no-pager

Vorhandene Schlüssel ändern, statt sie doppelt hinzuzufügen. Bei fehlgeschlagenem Dienststart zunächst Journal und Elasticsearch-Logs auf Bootstrap-Prüfungen, Rechte und YAML-Fehler untersuchen; Sicherheitsfunktionen nicht deaktivieren.

sudo journalctl -u elasticsearch --since '-10 min' --no-pager
sudo tail -n 100 /var/log/elasticsearch/logs-lab.log
sudo ss -lntp | grep -E ':(9200|9300)\b'

Passwort zurücksetzen und HTTPS mit CA-Prüfung testen

Nur das öffentliche CA-Zertifikat an einen separaten Ort kopieren, damit curl es aus einer gewöhnlichen Shell lesen kann. Den privaten CA-Schlüssel sowie Transport- und HTTP-Keystores nicht kopieren.

sudo install -d -m 0755 /etc/elastic-client
sudo install -o root -g root -m 0644 /etc/elasticsearch/certs/http_ca.crt /etc/elastic-client/http_ca.crt
openssl x509 -in /etc/elastic-client/http_ca.crt -noout -fingerprint -sha256

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

read -rsp 'elastic password: ' ELASTIC_PASSWORD
echo
export ELASTIC_PASSWORD

curl --fail --silent --show-error   --cacert /etc/elastic-client/http_ca.crt   -u "elastic:${ELASTIC_PASSWORD}"   https://127.0.0.1:9200/ | jq .

unset ELASTIC_PASSWORD

Ohne Zertifikatsprüfung kann eine Verbindung bestehen, ohne einen gefälschten Server zu erkennen. CA-Fingerabdruck oder CA-Datei verteilen und statt persönlicher Passwörter dienstbezogene Konten mit minimalen Rechten oder API-Schlüssel verwenden.

Kibana registrieren und über HTTPS bereitstellen

Kibana kann über ein Enrollment-Token CA und Zugangsdaten von Elasticsearch übernehmen. Eine übersichtliche Anordnung bindet Kibana an 127.0.0.1 und terminiert HTTPS mit einem Organisationszertifikat am Reverse-Proxy, statt Port 5601 direkt für Browser zu veröffentlichen.

Kibana-Enrollment-Token erzeugen und registrieren

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

# Das oben ausgegebene kurzlebige Token im folgenden Befehl eingeben.
sudo /usr/share/kibana/bin/kibana-setup   --enrollment-token '<ONE_TIME_ENROLLMENT_TOKEN>'

sudo tee -a /etc/kibana/kibana.yml >/dev/null <<'EOF'
server.host: "127.0.0.1"
server.port: 5601
server.publicBaseUrl: "https://kibana.example.com"
EOF

sudo systemctl enable --now kibana
sudo journalctl -u kibana --since '-10 min' --no-pager

Beispiel für einen Nginx-HTTPS-Reverse-Proxy

Zuerst Zertifikat und privaten Schlüssel für die Domain an den angegebenen Pfaden ablegen. Den folgenden server-Block unter /etc/nginx/conf.d/kibana.conf speichern. Prüfen, dass der http-Block der grundlegenden nginx.conf dieses Verzeichnis einbindet.

sudo dnf install -y nginx policycoreutils-utils
sudoedit /etc/nginx/conf.d/kibana.conf
# Nginx unter SELinux enforcing den Zugriff auf Kibana über Loopback erlauben.
sudo setsebool -P httpd_can_network_connect on

server {
    listen 443 ssl http2;
    server_name kibana.example.com;

    ssl_certificate     /etc/pki/tls/certs/kibana-fullchain.pem;
    ssl_certificate_key /etc/pki/tls/private/kibana.key;

    location / {
        proxy_pass http://127.0.0.1:5601;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

sudo nginx -t
sudo systemctl enable --now nginx
sudo systemctl reload nginx

# Durch den Adressbereich des Verwaltungsnetzes ersetzen.
sudo firewall-cmd --permanent --new-zone=kibana-admin || true
sudo firewall-cmd --permanent --zone=kibana-admin   --add-source=10.20.0.0/16
sudo firewall-cmd --permanent --zone=kibana-admin --add-service=https
sudo firewall-cmd --reload
sudo firewall-cmd --zone=kibana-admin --list-all

Datenstream und ILM vor der Erfassung vorbereiten

Richtlinie und Vorlage erstellen, bevor die ersten Logs gesendet werden. Vorlagenänderungen gelten nicht rückwirkend für vorhandene Backing-Indizes. Bei bestehenden Streams zunächst die aktuelle ILM-Richtlinie abfragen und Richtlinienwechsel sowie Rollover als eigene Änderung durchführen. Das folgende ILM explain erst nach Erfassungsbeginn und Erstellung eines Backing-Index ausführen.

Wer zeitbasierte Logs unbegrenzt in denselben Index schreibt, erzeugt große Shards und lange Wiederherstellungszeiten. Datenstreams mit ILM wechseln bei definierten Bedingungen auf neue Backing-Indizes und löschen Daten nach Ablauf der Aufbewahrung. Das Beispiel verwendet 50 GB oder einen Tag als Wechselkriterium.

ILM-Richtlinie mit 30 Tagen Aufbewahrung erstellen

read -rsp 'elastic password: ' ELASTIC_PASSWORD
echo

curl --fail --silent --show-error   --cacert /etc/elastic-client/http_ca.crt   -u "elastic:${ELASTIC_PASSWORD}"   -X PUT https://127.0.0.1:9200/_ilm/policy/logs-30d   -H 'Content-Type: application/json' -d @- <<'JSON'
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {"max_primary_shard_size": "50gb", "max_age": "1d"}
        }
      },
      "delete": {
        "min_age": "30d",
        "actions": {"delete": {}}
      }
    }
  }
}
JSON

Indexvorlage für einen Datenstream

curl --fail --silent --show-error   --cacert /etc/elastic-client/http_ca.crt   -u "elastic:${ELASTIC_PASSWORD}"   -X PUT https://127.0.0.1:9200/_index_template/logs-app   -H 'Content-Type: application/json' -d @- <<'JSON'
{
  "index_patterns": ["logs-app-*"],
  "priority": 500,
  "data_stream": {},
  "template": {
    "settings": {
      "index.lifecycle.name": "logs-30d",
      "number_of_shards": 1,
      "number_of_replicas": 1
    }
  }
}
JSON

ILM-Anwendung prüfen

curl --fail --silent --show-error   --cacert /etc/elastic-client/http_ca.crt   -u "elastic:${ELASTIC_PASSWORD}"   'https://127.0.0.1:9200/_ilm/status?pretty'

curl --fail --silent --show-error   --cacert /etc/elastic-client/http_ca.crt   -u "elastic:${ELASTIC_PASSWORD}"   'https://127.0.0.1:9200/.ds-logs-app-*/_ilm/explain?pretty'

Erfassungspipeline mit Logstash und Filebeat

Im lokalen Beispiel sendet Filebeat an Logstash auf Loopback; Logstash prüft das Elasticsearch-Zertifikat anhand der CA. Verbinden sich entfernte Beats mit Port 5044, Server- und Clientzertifikate gesondert verteilen und erlaubte Firewall-Quellen begrenzen.

Erfassungskonto mit minimalen Rechten erstellen

read -rsp 'elastic password: ' ELASTIC_PASSWORD
echo
read -rsp 'logstash_writer password: ' LOGSTASH_WRITER_PASSWORD
echo

curl --fail --silent --show-error   --cacert /etc/elastic-client/http_ca.crt   -u "elastic:${ELASTIC_PASSWORD}"   -X PUT https://127.0.0.1:9200/_security/role/logstash_writer_role   -H 'Content-Type: application/json' -d @- <<'JSON'
{
  "cluster": ["monitor"],
  "indices": [
    {
      "names": ["logs-app-*"],
      "privileges": ["auto_configure", "create_doc"]
    }
  ]
}
JSON

jq -n --arg password "$LOGSTASH_WRITER_PASSWORD"   '{password:$password,roles:["logstash_writer_role"]}' | curl --fail --silent --show-error   --cacert /etc/elastic-client/http_ca.crt   -u "elastic:${ELASTIC_PASSWORD}"   -X PUT https://127.0.0.1:9200/_security/user/logstash_writer   -H 'Content-Type: application/json' --data-binary @-

unset LOGSTASH_WRITER_PASSWORD

Logstash-Syntax und Verbindung prüfen

sudo install -d -o logstash -g logstash -m 0750 /etc/logstash/certs
sudo install -o logstash -g logstash -m 0640   /etc/elasticsearch/certs/http_ca.crt   /etc/logstash/certs/http_ca.crt

sudo /usr/share/logstash/bin/logstash-keystore   --path.settings /etc/logstash create
sudo /usr/share/logstash/bin/logstash-keystore   --path.settings /etc/logstash add ES_PASSWORD

ES_PASSWORD muss das Passwort des eigens angelegten Erfassungskontos mit minimalen Rechten enthalten, nicht das elastic-Konto aus der Übung. Die folgende Konfiguration verweist auf Keystore-Variablen, damit keine Geheimnisse in der Konfigurationsdatei stehen.

sudo tee /etc/logstash/conf.d/beats-to-elasticsearch.conf >/dev/null <<'EOF'
input {
  beats { host => "127.0.0.1" port => 5044 }
}

filter {
  if ![@metadata][pipeline] { mutate { add_tag => ["pipeline-default"] } }
}

output {
  elasticsearch {
    hosts => ["https://127.0.0.1:9200"]
    user => "logstash_writer"
    password => "${ES_PASSWORD}"
    ssl_enabled => true
    ssl_certificate_authorities => ["/etc/logstash/certs/http_ca.crt"]
    ecs_compatibility => "v8"
    manage_template => false
    ilm_enabled => false
    data_stream => "true"
    data_stream_type => "logs"
    data_stream_dataset => "app"
    data_stream_namespace => "default"
  }
}
EOF

sudo chown logstash:logstash /etc/logstash/logstash.keystore
sudo chmod 0600 /etc/logstash/logstash.keystore

sudo -u logstash /usr/share/logstash/bin/logstash   --path.settings /etc/logstash --config.test_and_exit
sudo systemctl enable --now logstash

Filebeat-filestream-Eingabe und Ausgabe konfigurieren

sudo tee /etc/filebeat/filebeat.yml >/dev/null <<'EOF'
filebeat.inputs:
  - type: filestream
    id: system-messages
    enabled: true
    paths:
      - /var/log/messages

output.elasticsearch:
  enabled: false

output.logstash:
  hosts: ["127.0.0.1:5044"]

logging.level: info
EOF

sudo filebeat test config -e
sudo filebeat test output -e
sudo systemctl enable --now filebeat
sudo journalctl -u filebeat --since '-10 min' --no-pager

Prüfen, ob Filebeat /var/log/messages lesen darf. Statt pauschal root zu verwenden, Dienstkonto und Rechtemodell des Pakets prüfen. Sensible Felder, personenbezogene Daten und Tokens vor der Erfassung entfernen oder schwärzen. Parsing-Fehler mit eigenen Tags und Dashboards beobachten.

Auf einen produktiven Drei-Knoten-Cluster erweitern

Die drei masterfähigen Knoten in unterschiedlichen Ausfallbereichen betreiben. Bei nur zwei Knoten bleibt nach einem Knotenausfall keine Mehrheit erhalten. Neue Knoten per Enrollment-Token aufnehmen und nach vollständiger Clusterbildung die Discovery-Konfiguration bereinigen.

Knoten aufnehmen und Cluster prüfen

Mit unveränderten Loopback- und Einzelknoteneinstellungen können keine weiteren Knoten hinzukommen. Auf dem vorhandenen Knoten discovery.type: single-node entfernen und transport.host auf eine für die anderen Knoten erreichbare Adresse im privaten Netz setzen. Enrollment benötigt auch die HTTPS-API des vorhandenen Knotens. Deshalb http.host um die private Adresse und Loopback konfigurieren und die Zertifikats-SANs prüfen. Port 9200 nur für die beteiligten Verwaltungshosts, 9300 nur für Clusterknoten erlauben. TLS-Einstellungen erhalten.

cluster.name: logs-lab
node.name: es01
network.host: 10.20.30.11
http.host: ["127.0.0.1", "10.20.30.11"]
transport.host: 10.20.30.11
discovery.seed_hosts: ["10.20.30.11:9300", "10.20.30.12:9300", "10.20.30.13:9300"]

Die Beispieladressen durch die tatsächlichen Adressen der drei Knoten ersetzen und vorhandene YAML-Schlüssel ändern. Im bestehenden Cluster bleibt cluster.initial_master_nodes entfernt. Erst nach erfolgreicher Bootstrap-Prüfung und erfolgreichem Dienstneustart ein eigenes Token für jeden neuen Knoten erzeugen. Vor dessen erstem Start auch identischen cluster.name, eigenen node.name, Adressen und Seed-Hosts prüfen.

sudo systemctl restart elasticsearch
sudo systemctl status elasticsearch --no-pager
sudo ss -lntp | grep -E ":(9200|9300)\b"

# Auf einem bestehenden Clusterknoten ausführen
sudo /usr/share/elasticsearch/bin/elasticsearch-create-enrollment-token   -s node

# Auf dem neuen Knoten direkt nach der Paketinstallation ausführen
sudo /usr/share/elasticsearch/bin/elasticsearch-reconfigure-node   --enrollment-token '<ONE_TIME_NODE_TOKEN>'
sudo systemctl enable --now elasticsearch

# Knoten und Rollen im bestehenden Cluster prüfen
curl --cacert /etc/elastic-client/http_ca.crt   -u "elastic:${ELASTIC_PASSWORD}"   'https://127.0.0.1:9200/_cat/nodes?v&h=name,ip,node.role,master,heap.percent,disk.avail'

cluster.initial_master_nodes wird nur für die erste Wahl eines neuen Clusters verwendet. Nach der Clusterbildung auf allen Knoten entfernen und nicht erneut setzen. Ein verbliebener Eintrag kann beim Neustart versehentlich einen separaten Cluster initialisieren. discovery.seed_hosts enthält masterfähige Knoten, die auch nach Neustarts erreichbar sind.

Snapshots und Wiederherstellungsübungen

Replikate schützen gegen Knotenausfälle und ersetzen keine Sicherung. Versehentliche Dokumentlöschungen werden sofort auf Replikate übertragen. Zu einem abgeschlossenen Aufbau gehören ein Snapshot-Repository außerhalb des Clusters, eine automatische SLM-Richtlinie und tatsächliche Wiederherstellungstests.

Beispiel: Repository auf gemeinsamem Dateisystem registrieren

Auf allen Master- und Datenknoten dasselbe tatsächliche gemeinsame Dateisystem unter demselben Pfad mounten. Lese- und Schreibrechte des Elasticsearch-Dienstkontos prüfen. Gleich benannte, voneinander getrennte lokale Verzeichnisse ergeben keinen gemeinsamen Speicher.

# Den vorhandenen path.repo-Schlüssel in elasticsearch.yml aller Master-/Datenknoten
# auf path.repo: ["/mnt/elastic-backup"] setzen.

# Nach einem rollenden Neustart das Repository registrieren.
curl --fail --silent --show-error   --cacert /etc/elastic-client/http_ca.crt   -u "elastic:${ELASTIC_PASSWORD}"   -X PUT https://127.0.0.1:9200/_snapshot/prod_backup   -H 'Content-Type: application/json' -d @- <<'JSON'
{
  "type": "fs",
  "settings": {
    "location": "/mnt/elastic-backup",
    "compress": true
  }
}
JSON

Repository prüfen und Test-Snapshot erstellen

curl --fail --silent --show-error   --cacert /etc/elastic-client/http_ca.crt   -u "elastic:${ELASTIC_PASSWORD}"   -X POST 'https://127.0.0.1:9200/_snapshot/prod_backup/_verify?pretty'

curl --fail --silent --show-error   --cacert /etc/elastic-client/http_ca.crt   -u "elastic:${ELASTIC_PASSWORD}"   -X PUT 'https://127.0.0.1:9200/_snapshot/prod_backup/smoke-test?wait_for_completion=true&pretty'

curl --fail --silent --show-error   --cacert /etc/elastic-client/http_ca.crt   -u "elastic:${ELASTIC_PASSWORD}"   'https://127.0.0.1:9200/_snapshot/prod_backup/smoke-test?pretty'

Das Kopieren von /var/lib/elasticsearch per rsync oder Dateisystem-Snapshot ist kein unterstütztes Sicherungsverfahren. Auch Repository-Inhalte können beschädigt werden, wenn externe Prozesse sie verändern. Regelmäßig in einen separaten Testcluster wiederherstellen und Indizes, Feature-States und Dashboards prüfen.

Prüfung und Fehlerdiagnose

Dienste, TLS und Clusterzustand gemeinsam prüfen

systemctl --no-pager --full status   elasticsearch kibana logstash filebeat

sudo ss -lntp | grep -E ':(9200|9300|5601|5044)\b'

curl --fail --silent --show-error   --cacert /etc/elastic-client/http_ca.crt   -u "elastic:${ELASTIC_PASSWORD}"   'https://127.0.0.1:9200/_cluster/health?pretty'

curl --fail --silent --show-error   --cacert /etc/elastic-client/http_ca.crt   -u "elastic:${ELASTIC_PASSWORD}"   'https://127.0.0.1:9200/_cat/shards?v&s=state,index'

unset ELASTIC_PASSWORD

Diagnosereihenfolge

1. Ersten Fehlerzeitpunkt anhand systemd-Exitcode und aktuellem Journal bestimmen.
2. Prüfen, dass Ports nur an den vorgesehenen Adressen lauschen.
3. CA, Hostname, Gültigkeitsdauer und Zertifikatsvertrauen des Clients prüfen.
4. Im Clusterzustand Ursachen nicht zugewiesener Shards und Datenträger-Schwellenwerte prüfen.
5. Logstash-Konfigurationstest, persistente Warteschlange, abgewiesene Ereignisse und Filebeat-Ausgabetest prüfen.
6. Aufbewahrungs- und Sicherungsautomatisierung anhand ILM explain und Snapshot-Repository-Prüfung kontrollieren.
7. Mit denselben Eingaben und Einstellungen isoliert reproduzieren und Änderungen dokumentieren.

Häufige Fehler und Alternativen

Upgrades und Betriebscheckliste

• Für alle Komponenten dieselbe Zielversion wählen und Versionshinweise sowie inkompatible Änderungen prüfen.
• Vor Upgrades Clusterzustand, nicht zugewiesene Shards, Datenträger-Schwellen und erfolgreiche Snapshots prüfen.
• Knoten einzeln rollend aktualisieren und jeweils auf erneuten Clusterbeitritt und Shard-Wiederherstellung warten.
• Kompatibilität von Kibana-Saved-Objects, Logstash-Plugins, Beats-Modulen und eigenen Vorlagen prüfen.
• Zertifikatsablauf, Keystore-Einträge, API-Schlüsselwechsel und minimale Rechte regelmäßig kontrollieren.
• Alarme für Erfassungsverzögerung, JVM-Speicherdruck, abgewiesene Anfragen, Shard-Größen sowie ILM- und SLM-Fehler einrichten.

Weiterführende Dokumentation

• Offizielle Elastic-RPM-Installationsanleitung
• Offizielle Elastic-Sicherheitsdokumentation für selbst verwaltete Cluster
• Offizielle Elastic-ILM-Dokumentation
• Offizielle Elastic-Dokumentation zu Snapshots und Wiederherstellung
• Linux: Speicher- und Inode-Mangel diagnostizieren
• Ansible-Playbooks und rollende Bereitstellung
• Linux-Container und Rootless Podman

Zusammenfassung

Ein betreibbarer Elastic Stack erfasst Daten sicher, begrenzt ihre Aufbewahrung planbar und ermöglicht die Wiederherstellung nach Störungen. Mit offiziellen Paketen derselben Version beginnen und automatische TLS- sowie Authentifizierungseinstellungen erhalten. Anschließend minimale Rechte, Loopback- und Firewallgrenzen, Datenstreams, ILM und externe Snapshots schrittweise prüfen. So lässt sich die Einzelknotenübung zu einer produktiven Drei-Knoten-Struktur erweitern.