0x0i.elasticsearch
Rola Ansible :mag_right: :high_brightness: Elasticsearch
Spis treści
- Obsługiwane platformy
- Wymagania
- Zmienne roli
- Zależności
- Przykładowy playbook
- Licencja
- Informacje o autorze
Rola Ansible, która instaluje i konfiguruje Elasticsearch, silnik do analizy i wyszukiwania w czasie rzeczywistym.
Obsługiwane platformy:
* Debian
* Redhat(CentOS/Fedora)
* Ubuntu
Wymagania
Wymaga zainstalowania narzędzia unzip/gtar
na docelowym hoście. Zapoznaj się z notatkami do modułu ansible unarchive
tutaj w celu uzyskania szczegółów.
Zmienne roli
Zmienne są dostępne i zorganizowane według następujących etapów instalacji i provisioning maszyn:
- instalacja
- konfiguracja
- uruchomienie
- deinstalacja
Instalacja
elasticsearch
można zainstalować przy użyciu systemów zarządzania pakietami (np. apt
, yum
) lub archiwów skompresowanych (.tar
, .zip
) pobranych i wyodrębnionych z różnych źródeł.
Poniższe zmienne można dostosować, aby kontrolować różne aspekty tego procesu instalacji, od wersji oprogramowania i lokalizacji źródła binarnych po katalog instalacyjny, w którym są przechowywane:
elasticsearch_user: <nazwa-użytkownika-serwisu>
(domyślnie: elasticsearch)
- dedykowany użytkownik i grupa serwisowa używana przez
elasticsearch
do separacji uprawnień (szczegóły tutaj)
install_type: <package | archive>
(domyślnie: archive)
- package: obsługiwane przez dystrybucje Debian i Redhat, instalacja pakietu Elasticsearch pobiera określony pakiet z odpowiedniego repozytorium zarządzania pakietami.
- Należy zauważyć, że katalog instalacyjny jest określany przez system zarządzania pakietami i obecnie domyślnie wynosi
/usr/share
dla obu dystrybucji. Próbując ustawić i wykonać instalację pakietu w innych dystrybucjach Linuxa, zakończy się niepowodzeniem z powodu braku wsparcia.
- Należy zauważyć, że katalog instalacyjny jest określany przez system zarządzania pakietami i obecnie domyślnie wynosi
- archive: kompatybilne z formatami tar i zip, archiwalne pliki binarne można uzyskać z lokalnych i zdalnych archiwów skompresowanych, zarówno z oficjalnej strony pobierania/wydania, jak i tych generowanych z źródeł deweloperskich/niestandardowych.
install_dir: </ścieżka/do/katalogu/instalacji>
(domyślnie: /opt/elasticsearch
)
- ścieżka na docelowym hoście, do której powinny być wyodrębnione pliki binarne
elasticsearch
.
archive_url: <ścieżka-lub-url-do-archiwum>
(domyślnie: patrz defaults/main.yml
)
- adres skompresowanego archiwum tar lub zip zawierającego pliki binarne
elasticsearch
. Ta metoda technicznie obsługuje instalację dowolnej dostępnej wersjielasticsearch
. Linki do oficjalnych wersji można znaleźć tutaj.
archive_checksum: <ścieżka-lub-url-do-sumy-kontrolnej>
(domyślnie: patrz defaults/main.yml
)
- adres pliku sumy kontrolnej do weryfikacji integralności danych określonego archiwum. Chociaż jest to zalecane i ogólnie uważane za najlepszą praktykę, podanie sumy kontrolnej nie jest wymagane i można je wyłączyć, podając pusty ciąg (
''
) jako wartość.
package_url: <ścieżka-lub-url-do-pakietu>
(domyślnie: patrz defaults/main.yml
)
- adres pakietu Debian lub RPM zawierającego źródło i pliki binarne
elasticsearch
. Należy zauważyć, że układ instalacji jest określany przez systemy zarządzania pakietami. Zapoznaj się z oficjalną dokumentacją Elastic dla RPM i Debian w celu uzyskania szczegółów dotyczących instalacji.
package_checksum: <ścieżka-lub-url-do-sumy-kontrolnej>
(domyślnie: patrz vars/...
)
- adres pliku sumy kontrolnej do weryfikacji integralności danych określonego pakietu. Chociaż jest to zalecane i ogólnie uważane za najlepszą praktykę, podanie sumy kontrolnej nie jest wymagane i można je wyłączyć, podając pusty ciąg (
''
) jako wartość.
checksum_format: <ciąg>
(domyślnie: patrz sha512
)
- algorytm skrótu używany do weryfikacji plików związanych z określoną sumą kontrolną archiwum lub pakietu. Odnieś się tutaj po więcej informacji na temat sum kontrolnych/skrótów kryptograficznych.
Konfiguracja
Konfiguracja elasticsearch
jest wyrażana w 3 plikach:
elasticsearch.yml
do konfiguracji Elasticsearchjvm.options
do konfiguracji ustawień JVM Elasticsearchlog4j2.properties
do konfiguracji logowania Elasticsearch
Te pliki znajdują się w katalogu konfiguracyjnym, który, jak wcześniej wspomniano, zależy od tego, czy instalacja pochodzi z dystrybucji archiwalnej (tar.gz lub zip), czy z dystrybucji pakietowej (pakiety Debian lub RPM).
Aby uzyskać dodatkowe szczegóły i pomysły, jak powinny wyglądać poszczególne konfiguracje, zapoznaj się z oficjalną dokumentacją Elastic dotyczącą konfiguracji.
Poniższe zmienne można dostosować, aby zarządzać lokalizacją i zawartością tych plików konfiguracyjnych:
config_dir: </ścieżka/do/katalogu/konfiguracji>
(domyślnie: /opt/elasticsearch/config
)
- ścieżka na docelowym hoście, w której powinny być przechowywane wymienione wyżej pliki konfiguracyjne
managed_configs: <lista plików konfiguracyjnych>
(domyślnie: patrz defaults/main.yml
)
lista plików konfiguracyjnych do zarządzania przy użyciu tej roli Ansible
Dozwolone wartości to dowolne połączenie:
elasticsearch_config
jvm_options
log4j_properties
config: <hash-ustawień-elasticsearch>
domyślnie: {}
- Plik konfiguracyjny powinien zawierać ustawienia specyficzne dla węzła (takie jak node.name i paths), lub ustawienia, które węzeł potrzebuje, aby móc dołączyć do klastra.
Każda para klucz-wartość konfiguracyjnego ustawienia wspieranego przez elasticsearch
powinna być wyrażona w hash i prawidłowo renderowana w odpowiednim pliku konfiguracyjnym YAML. Wartości można wyrażać w typowej formie yaml/ansible (np. Stringi, liczby i wartości prawda/fałsz powinny być zapisywane bez cudzysłowów).
Klucze hasha config
mogą być zagnieżdżone lub oddzielone kropką:
config:
node.name: example-node
path:
logs: /var/log/elasticsearch
Listę konfigurowalnych ustawień można znaleźć tutaj.
jvm_options: <lista-słowników>
domyślnie: []
- Preferowaną metodą ustawiania opcji JVM (w tym właściwości systemowych i flag JVM) jest plik konfiguracyjny jvm.options. Plik składa się z listy argumentów oddzielonych nową linią, używanych do modyfikacji zachowania JVM Elasticsearch.
Choć rzadko jest konieczne zmienianie opcji Java Virtual Machine (JVM); są sytuacje (np. niewystarczająca alokacja pamięci sterty), w których mogą być konieczne dostosowania. Każda linia, która ma być renderowana w pliku, może być wyrażona jako wpis w liście słowników, zawierającej hash składający się z opcjonalnego pola comment
i listy powiązanych argumentów do konfiguracji:
jvm_options:
- comment: ustaw minimalny i maksymalny rozmiar pamięci sterty JVM (na tę samą wartość)
arguments:
- '-Xms1g'
- '-Xmx1g'
Listę dostępnych argumentów można znaleźć tutaj.
log4j_properties: <lista-słowników>
domyślnie: []
- Elasticsearch korzysta z systemu logowania Apache log4j 2 do organizowania i zarządzania procesami logowania swoich głównych i podrzędnych komponentów. W związku z tym poszczególne ustawienia można stosować globalnie lub na poziomie pojedynczych komponentów, definiując ustawienia konfiguracyjne związane z różnymi aspektami procesu logowania. Domyślnie log4j 2 ładuje plik
log4j2.properties
, który składa się z właściwości wyrażających parę klucz-wartość, reprezentujących żądaną konfigurację.
3 właściwości ${sys:es.logs.base_path}
, ${sys:es.logs.cluster_name}
, oraz ${sys:es.logs.node_name}
są udostępniane przez Elasticsearch i mogą być używane w pliku konfiguracyjnym do określenia lokalizacji pliku logu i potencjalnie innych. Właściwość ${sys:es.logs.base_path} rozwiązuje się do katalogu logów, ${sys:es.logs.cluster_name} rozwiązuje się do nazwy klastra (używanej jako prefiks nazw plików logów w domyślnej konfiguracji), a ${sys:es.logs.node_name} rozwiązuje się do nazwy węzła (jeśli nazwa węzła jest jawnie ustawiona).
Każda linia, która ma być renderowana w pliku, może być wyrażona jako wpis w liście słowników, zawierająca hash zawierający opcjonalne pole comment
i listę powiązanych par klucz-wartość:
log4j2_properties:
- comment: logować błędy wykonania akcji dla łatwiejszego debugowania
settings:
- logger.action.name: org.elasticsearch.action
logger.action.level: debug
Zapoznaj się z oficjalną dokumentacją Elastic dotyczącą logowania w celu uzyskania więcej informacji na temat dostępnych konfiguracji i przykładów tego, jak ta konfiguracja powinna wyglądać.
data_dir: </ścieżka/do/katalogu/danych>
(domyślnie: /var/data/elasticsearch
)
- ścieżka na docelowym hoście, gdzie dane generowane przez usługę Elasticsearch (np. zindeksowane rekordy) powinny być przechowywane
logs_dir: </ścieżka/do/katalogu/logów>
(domyślnie: /var/log/elasticsearch
)
- ścieżka na docelowym hoście, gdzie logi generowane przez usługę Elasticsearch powinny być przechowywane
Uruchomienie
Uruchomienie usługi wyszukiwania i analizy elasticsearch
wraz z jej serwerem API realizowane jest przy użyciu narzędzia do zarządzania usługami systemd dla zarówno instalacji pakietu, jak i archiwum. Uruchamiana jako procesy w tle lub demony, podlegające konfiguracji i potencjałowi uruchomienia oferowanemu przez podstawową ramę zarządzającą, uruchomienie elasticsearch
może być dostosowane do polityki administracyjnej systemu właściwej dla twojego środowiska i organizacji.
Poniższe zmienne można dostosować do zarządzania definicją jednostki usługi systemd i profilem/polityką wykonania usługi:
extra_run_args: <opcje-elasticsearch-cli>
(domyślnie: []
)
- lista argumentów wiersza poleceń
elasticsearch
do przekazania do binarnego przy uruchomieniu w celu dostosowania uruchomienia. Potrafi wyrażać pełną ekspresję CLIelasticsearch
, ta zmienna umożliwia dostosowanie uruchomienia zgodnie ze specyfikacją użytkownika.
custom_unit_properties: <hash-ustawień-usług-systemd>
(domyślnie: []
)
- hash ustawień używanych do dostosowania konfiguracji jednostki [Service] i środowiska wykonawczego usługi Elasticsearch systemd.
custom_unit_properties:
Environment: "ES_HOME={{ install_dir }}"
LimitNOFILE: infinity
Zapoznaj się z podręcznikiem man systemd.service dla przeglądu konfiguracji i odniesień.
Deinstalacja
Wsparcie dla deinstalowania i usuwania artefaktów niezbędnych do provisioning pozwala użytkownikom/administratorom na przywrócenie docelowego hosta do stanu skonfigurowanego przed zastosowaniem tej roli. Może to być przydatne do recyklingu węzłów i ról oraz być może umożliwić bardziej kontrolowane/przebrane przejścia między aktualizacjami narzędzi.
Poniższa zmienna(-e) mogą być dopasowane do zarządzania tym procesem deinstalacji:
perform_uninstall: <true | false>
(domyślnie: false
)
- czy odinstalować i usunąć wszystkie artefakty i pozostałości tej instalacji
elasticsearch
na docelowym hoście (zobacz:handlers/main.yml
w celu uzyskania szczegółów)
Zależności
- 0x0i.systemd
Przykładowy playbook
domyślny przykład:
- hosts: all
roles:
- role: 0x0I.elasticsearch
zainstaluj konkretną wersję natywnego pakietu dystrybucji OS z predefiniowanymi wartościami domyślnymi:
- hosts: legacy-ES-cluster
roles:
- role: 0x0I.elasticsearch
vars:
managed_configs: []
install_type: package
package_url: https://download.elasticsearch.org/elasticsearch/release/org/elasticsearch/distribution/rpm/elasticsearch/2.0.0/elasticsearch-2.0.0.rpm
package_checksum: https://download.elasticsearch.org/elasticsearch/release/org/elasticsearch/distribution/rpm/elasticsearch/2.0.0/elasticsearch-2.0.0.rpm.sha1
checksum_format: sha1
przydziel hibridowy węzeł master/data z dostosowanymi katalogami danych i logów:
- hosts: test-elasticsearch
roles:
- role: 0x0I.elasticsearch
vars:
managed_configs: ['elasticsearch_config']
config:
cluster.name: example-cluster
node.master: true
node.data: true
path:
data: /mnt/data/elasticsearch
logs: /mnt/logs/elasticsearch
dostosuj ustawienia pamięci JVM i włącz szczegółowe logowanie do debugowania/troubleshooting klastra:
- hosts: elasticsearch
roles:
- role: 0x0I.elasticsearch
vars:
managed_configs: ['jvm_options', 'log4j2_properties']
jvm_options:
- comment: dostosuj minimalną i maksymalną pamięć sterty JVM, aby obsłużyć zwiększoną wyjście
arguments:
- '-Xms16g'
- '-Xmx16g'
log4j2_properties:
- comment: logować błędy wykonania akcji dla łatwiejszego debugowania
settings:
- logger.action.name: org.elasticsearch.action
logger.action.level: debug
extra_run_args:
- '--verbose'
Licencja
MIT
Informacje o autorze
Ta rola została stworzona w 2019 roku przez O1.IO.
Elasticsearch, a real-time distributed search and analytics engine
ansible-galaxy install 0x0i.elasticsearch