В данном примере будет установлен OpenSearch используя официальную роль Ansible
Теорию и многое другое доступно описываю в твоём ТГ канале.
Там же отвечаю на вопросы и обновляю инструкции при необходимости.
Присоединяйся
Требования
Установленный сервер управления - Ansible.
Настроенный пользователь для подключение ansible к хостам без пароля, с правами root.
Ресурсы нод:
- CPU: 2
- RAM: 8 gb
- SSD: 100 gb
- OS: Ubuntu
Установка
Клонируем роль:
1
| git clone https://github.com/opensearch-project/ansible-playbook.git
|
Заходим:
Добавляем хосты:
1
| nano inventories/opensearch/hosts
|
В официальной документации 5 хостов, в примере 3:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
| os-node-1 ansible_host=10.0.1.1 ansible_user=root ip=10.0.1.1 roles=data,master
os-node-2 ansible_host=10.0.1.2 ansible_user=root ip=10.0.1.2 roles=data,master
os-node-3 ansible_host=10.0.1.3 ansible_user=root ip=10.0.1.3 roles=data,master
os-node-web ansible_host=10.0.1.4 ansible_user=root ip=10.0.1.4
# List all the nodes in the os cluster
[os-cluster]
os-node-1
os-node-2
os-node-3
# List all the Master eligible nodes under this group
[master]
os-node-1
os-node-2
os-node-3
[dashboards]
os-node-web
|
Открываем на редактирование:
1
| nano inventories/opensearch/group_vars/all/all.yml
|
Далее изменяем переменные на свои:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
| # Имя кластера
os_cluster_name: my-cluster
# На момент выхода заметки актуальная версия 3.0.0. Можно посмотреть на сайте opensearch
os_version: "3.0.0"
os_dashboards_version: "3.0.0"
# Доменное имя
domain_name: itzm.tech
# Память в ГБ выделяемая Java для работы OpenSearch
xms_value: 2
xmx_value: 2
# Если всего серверов в кластере 1, то параметр заменить на cluster_type: single-node
cluster_type: multi-node
# Включить, если в будущем планируется управлять кластером с помощью этой ansible-роли.
# Чтобы не пересоздавать сертификаты каждый раз при запуске плейбука, данный параметр создаст их один раз и не будет изменять.
# Полезно, так как в проде пересоздание сертификатов для Opensearch может повалить tls и весь кластер.
iac_enable: yes
|
Команда для запуска. Прежде чем запускать читаем описание.
1
| ansible-playbook -i inventories/opensearch/hosts opensearch.yml --extra-vars "admin_password=Test@123 kibanaserver_password=Test@6789 logstash_password=Test@456" --become
|
Для admin требуется надёжный пароль, например myStrongPassword123!
Кластер не запустится со слабым паролем (например, admin) или без пароля.
Что это за пароли и пользователи?
admin_password - главный пользователь, имеет полный доступ в веб-интерфейсе OpenSearch Dashboards и по API.kibanaserver_password - используется внутренним сервисом OpenSearch Dashboards (вход от имени kibanaserver) для общения с OpenSearch. Не для пользователей.logstash_password - используется Logstash (или другое приложение, которое ты будешь подключать) для отправки логов в OpenSearch.
Можно использовать дефолтную роль admin для поключения приложений типа Logstash. Но не забывайте про риски:
- Нарушается принцип наименьших привилегий. Logstash получает доступ ко всему (в т.ч. и системным индексам, снапшотам, логам).
- Риск компрометации. Если Logstash будет взломан, злоумышленник получит полный доступ к OpenSearch.
- Сложнее отследить, кто именно выполняет действия, так как всё будет от имени admin.
Теперь меняем пароли в команде запуска плейбука на свои, запускаем и начинаем установку.
Заходим в веб-интерфейс
После всех действий попадаем на страницу dashboards.
IP-dasboard:5600
В моём случае 10.0.1.4:5600
Проверяем состояние кластера в DevTools командой:
Балансировка нагрузки
Хорошей практикой является настройка балансировки нагрузки и повышение отказоустойчивости при выходе ноды из строя.
Для этого я установлю единую точку входа в лице Nginx. Делать это я буду на сервере с dashboards.
Конфигурация nginx.conf:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
| events {
worker_connections 1024;
}
http {
upstream backend {
server os-node-1.itzm.tech:9200;
server os-node-2.itzm.tech:9200;
server os-node-3.itzm.tech:9200;
keepalive 15;
}
server {
listen 9200 ssl;
server_name os-node-web.itzm.tech;
client_max_body_size 100M;
ssl_certificate /etc/nginx/ssl/os-cert.crt;
ssl_certificate_key /etc/nginx/ssl/os-key.key;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
location / {
proxy_pass http://backend;
proxy_read_timeout 5m;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
}
|
Создать сертификаты. Самоподписанные или ЦА в директории /etc/nginx/ssl с именами os-cert.crt, os-key.key.
Если используется авторизация по сертификатам внутри OpenSearch, то конфиг такой:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
| events {
worker_connections 1024;
}
http {
upstream os-node-web.itzm.tech {
server os-node-1.itzm.tech:9200;
server os-node-2.itzm.tech:9200;
server os-node-3.itzm.tech:9200;
keepalive 15;
}
server {
listen 9200 ssl;
server_name os-node-web.itzm.tech;
client_max_body_size 100M;
ssl_certificate /etc/nginx/ssl/os-cert.crt;
ssl_certificate_key /etc/nginx/ssl/os-key.key;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
location / {
proxy_pass https://os-node-web.itzm.tech;
proxy_ssl_certificate /etc/nginx/ssl/cert.pem;
proxy_ssl_certificate_key /etc/nginx/ssl/certkey.key;
proxy_ssl_trusted_certificate /etc/nginx/ssl/root-ca.crt;
proxy_read_timeout 5m;
proxy_ssl_verify on;
proxy_ssl_server_name off;
proxy_ssl_verify_depth 2;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
}
|
Перезапускаем nginx и пользуемся:
1
| systemctl restart nginx.service
|
