opensearch

• 1: Введение в Opensearch
• 1.1: Быстрый старт установки
• 1.2: Взаимодействие с OpenSearch
• 1.3: Загрузка данных в OpenSearch
• 1.4: Поиск данных в OpenSearch
• 1.5: Начало работы с безопасностью в OpenSearch
• 1.6: Основные концепции OpenSearch
• 2: Install and upgrade OpenSearch
• 2.1: Установка OpenSearch
• 2.1.1: Docker
• 2.1.2: Установка OpenSearch на Debian
• 2.2: Установка OpenSearch Dashboards
• 2.2.1: Запуск OpenSearch Dashboards с использованием Docker
• 2.2.2: Установка OpenSearch Dashboards (Debian)
• 2.2.3: Настройка TLS для OpenSearch Dashboards
• 2.3: configuring opensearch
• 2.3.1: Настройки доступности и восстановления
• 2.3.2: Конфигурация и системные настройки
• 2.3.3: Сетевые настройки
• 2.3.4: Настройки обнаружения и шлюза
• 2.3.5: Настройки безопасности
• 2.3.6: Настройки предохранителей
• 2.3.7: Настройка кластера
• 2.3.8: Настройка индекса
• 2.3.9: Настройки поиска
• 2.3.10: Настройки плагинов
• 2.3.11: Экспериментальные флаги функций
• 2.3.12: Logs
• 2.4: Сравнение ОС
• 2.5: Настройка OpenSearch Dashboards
• 2.6: Upgrading OpenSearch
• 2.6.1: Приложение по обновлениям
• 2.6.2: Постепенное обновление
• 2.6.3: Лаборатория последовательного обновления
• 2.7: Установка плагинов
• 2.7.1: Дополнительные плагины
• 2.7.2: mapper-size
• 2.7.3: ingest-attachment
• 2.8: Управление плагинами OpenSearch Dashboards
• 3: Query DSL - язык запросов OpenSearch
• 3.1: Контекст запроса и фильтра
• 3.2: Сравнение термовых и полнотекстовых запросов
• 3.3: Термино-уровневые запросы
• 3.3.1: exists
• 3.3.2: fuzzy
• 3.3.3: ids
• 3.3.4: prefix
• 3.3.5: range
• 3.3.6: regexp
• 3.3.7: term
• 3.3.8: terms
• 3.3.9: terms set
• 3.3.10: wildcard
• 3.4: full_text
• 3.4.1: match
• 3.4.2: match-bool-prefix
• 3.4.3: match-phrase
• 3.4.4: match-phrase-prefix
• 3.4.5: multi-match
• 3.4.6: query-string
• 3.4.7: simple-query-string
• 3.4.8: intervals query
• 3.5: compound queries
• 3.5.1: boolean query
• 3.5.2: boosting query
• 3.5.3: constant_score
• 3.5.4: disjunction_max
• 3.5.5: function_score
• 3.5.6: hibrid
• 3.6: geographic and xy query
• 3.6.1: Запрос по гео-ограничивающему прямоугольнику
• 3.6.2: Запрос по гео-расстоянию
• 3.6.3: Запрос по гео-многоугольнику
• 3.6.4: Запрос по гео-форме
• 3.6.5: xy запрос
• 3.7: Объединение запросов
• 3.7.1: Запрос has_child
• 3.7.2: Запрос has_parent
• 3.7.3: Вложенный запрос
• 3.7.4: Запрос по идентификатору родителя
• 3.8: Запросы Span
• 3.8.1: Запрос Span containing
• 3.8.2: Запрос Span field masking
• 3.8.3: Запрос Span first
• 3.8.4: Запрос Span multi-term
• 3.8.5: Запрос Span near
• 3.8.6: span_not
• 3.8.7: Запрос Span or
• 3.8.8: Запрос Span term
• 3.8.9: Запрос Span within
• 3.9: Запрос Match all
• 3.10: Специализированные запросы
• 3.10.1: distance_feature
• 3.10.2: k-NN
• 3.10.3: k-NN explain
• 3.10.4: neural
• 3.10.5: Нейронный разреженный запрос
• 3.10.6: Перколяция
• 3.10.7: script query
• 3.10.8: Запрос с оценкой скрипта
• 3.10.9: Запрос шаблона
• 3.10.10: Обертка
• 3.11: Minimum should match (Минимальное соответствие)
• 3.12: Синтаксис регулярных выражений
• 4: goclient

1 - Введение в Opensearch

Введение в OpenSearch

Термин распределённая означает, что OpenSearch можно запускать на нескольких компьютерах. Поиск и аналитика подразумевают, что после загрузки данных в OpenSearch их можно искать и анализировать. Независимо от типа данных, их можно хранить и исследовать с помощью OpenSearch.

Документ

Документ — это единица хранения информации (текстовой или структурированной). В OpenSearch документы хранятся в формате JSON.

Документ можно представить несколькими способами:

• В базе данных студентов документ может представлять одного учащегося.
• При поиске информации OpenSearch возвращает документы, соответствующие запросу.
• Документ аналогичен строке в традиционной реляционной базе данных.

Например, в школьной базе данных документ может представлять студента и содержать следующие данные:

Вот как этот документ выглядит в формате JSON:

{
  "name": "John Doe",
  "gpa": 3.89,
  "grad_year": 2022
}

Вы узнаете, как назначаются идентификаторы документов, в разделе Индексация документов.

Индекс

Индекс — это коллекция документов.

Индекс можно рассматривать несколькими способами:

• В базе данных студентов индекс представляет всех учащихся в базе.
• При поиске информации запрос выполняется к данным внутри индекса.
• Индекс соответствует таблице в традиционной реляционной базе данных.

Например, в школьной базе данных индекс может содержать всех студентов школы:

Кластеры и узлы

OpenSearch разработан как распределённая поисковая система, что означает возможность работы на одном или нескольких узлах — серверах, хранящих данные и обрабатывающих поисковые запросы. Кластер OpenSearch — это совокупность таких узлов.

Вы можете запустить OpenSearch локально на ноутбуке (системные требования минимальны), но также можно масштабировать кластер до сотен мощных серверов в дата-центре.

В одноузловом кластере (например, развёрнутом на ноутбуке) одна машина выполняет все задачи:

• управляет состоянием кластера,
• индексирует данные и обрабатывает поисковые запросы,
• выполняет предварительную обработку данных перед индексацией.

Однако по мере роста кластера обязанности можно распределить:

• Узлы с быстрыми дисками и большим объёмом ОЗУ подходят для индексации и поиска.
• Узлы с мощными CPU, но малым дисковым пространством, могут управлять состоянием кластера.

В каждом кластере выбирается главный узел (cluster manager node), который координирует операции на уровне кластера (например, создание индекса). Узлы взаимодействуют между собой: если запрос направлен к одному узлу, он может запрашивать данные у других узлов, агрегировать их ответы и возвращать итоговый результат.

Подробнее о других типах узлов см. в разделе Формирование кластера.

Шарды (Shards)

OpenSearch разделяет индексы на шарды. Каждый шард хранит подмножество всех документов индекса, как показано на следующей диаграмме:

Шарды используются для равномерного распределения данных между узлами кластера. Например:

• Индекс размером 400 ГБ может быть слишком большим для обработки на одном узле
• Если разделить его на 10 шардов по 40 ГБ каждый, OpenSearch сможет распределить их между 10 узлами
• Каждый шард будет обрабатываться независимо

Рассмотрим кластер с двумя индексами:

• Индекс 1 разделён на 2 шарда
• Индекс 2 разделён на 4 шарда

Эти шарды распределены между двумя узлами, как показано на схеме:

Хотя каждый шард является частью индекса OpenSearch, технически он представляет собой полноценный индекс Lucene. Это важно учитывать, потому что:

• Каждый экземпляр Lucene - это отдельный процесс
• Каждый процесс потребляет ресурсы CPU и памяти
• Слишком большое количество шардов может перегрузить кластер

Рекомендации по работе с шардами:

• Не стоит разделять индекс на чрезмерное количество шардов
• Например, деление индекса 400 ГБ на 1000 шардов создаст ненужную нагрузку
• Оптимальный размер шарда - от 10 до 50 ГБ

Первичные и реплицированные шарды

В OpenSearch шарды могут быть двух типов:

1. Первичные (primary) - оригинальные шарды
2. Реплики (replica) - копии шардов

По умолчанию OpenSearch создаёт по одной реплике для каждого первичного шарда. Таким образом:

• Если индекс разделён на 10 шардов, будет создано 10 реплик
• В примере из предыдущего раздела (2 индекса):
  • Индекс 1: 2 шарда + 2 реплики
  • Индекс 2: 4 шарда + 4 реплики

Функции реплик:

1. Резервное копирование на случай сбоя узла
   • Реплики размещаются на разных узлах от первичных шардов
2. Ускорение обработки поисковых запросов
   • Для нагрузок с интенсивным поиском можно создать несколько реплик

Инвертированный индекс

OpenSearch использует структуру данных под названием инвертированный индекс, которая:

• Сопоставляет слова с документами, где они встречаются
• Пример для двух документов:
  • Документ 1: “Красота в глазах смотрящего”
  • Документ 2: “Красавица и чудовище”

Инвертированный индекс будет выглядеть так:

Дополнительно OpenSearch хранит:

• Позиции слов в документах
• Это позволяет выполнять поиск по фразам

Релевантность

При поиске OpenSearch:

1. Сопоставляет слова запроса с документами
2. Присваивает каждому документу оценку релевантности

Факторы оценки:

1. Частота термина (TF):
   • Чем чаще слово встречается в документе, тем выше оценка
2. Обратная частота документа (IDF):
   • Редкие слова имеют больший вес (например, “аксолотль” vs “синий”)
3. Нормализация по длине:
   • Более короткие документы получают преимущество

OpenSearch использует алгоритм BM25 для расчёта релевантности и сортировки результатов.

Следующие шаги

Узнайте, как быстро установить OpenSearch, в разделе Быстрый старт установки.

1.1 - Быстрый старт установки

Для быстрого запуска OpenSearch и OpenSearch Dashboards используйте контейнеры Docker. Полное руководство по установке доступно в разделе Установка и обновление OpenSearch.

Предварительные требования:

• Установите Docker и Docker Compose на локальную машину

Запуск кластера

1. Настройка системы
   Перед запуском рекомендуется:

   • Отключить подкачку памяти для повышения производительности:

     sudo swapoff -a
     

   • Увеличить максимальное количество memory maps:

     sudo vi /etc/sysctl.conf
     

     Добавьте строку:

     vm.max_map_count=262144
     

     Примените изменения:

     sudo sysctl -p
     

2. Получение файла конфигурации
   Загрузите образец docker-compose.yml:

   • Через cURL:

     curl -O https://raw.githubusercontent.com/opensearch-project/documentation-website/3.1/assets/examples/docker-compose.yml
     

   • Через wget:

     wget https://raw.githubusercontent.com/opensearch-project/documentation-website/3.1/assets/examples/docker-compose.yml
     

3. Запуск кластера
   Перейдите в директорию с файлом и выполните:

   docker compose up -d
   

   Проверьте статус контейнеров:

   docker compose ps
   

   Ожидаемый вывод:

   NAME                    COMMAND                  SERVICE                 STATUS              PORTS
   opensearch-dashboards   "./opensearch-dashbo…"   opensearch-dashboards   running             0.0.0.0:5601->5601/tcp
   opensearch-node1        "./opensearch-docker…"   opensearch-node1        running             0.0.0.0:9200->9200/tcp, 9300/tcp, 0.0.0.0:9600->9600/tcp, 9650/tcp
   opensearch-node2        "./opensearch-docker…"   opensearch-node2        running             9200/tcp, 9300/tcp, 9600/tcp, 9650/tcp
   

4. Проверка работы
   Выполните тестовый запрос к API:

   curl https://localhost:9200 -ku admin:ВАШ_ПАРОЛЬ
   

   Успешный ответ:

   {
     "name": "opensearch-node1",
     "cluster_name": "opensearch-cluster",
     "version": {
       "distribution": "opensearch",
       "number": "2.6.0"
     },
     "tagline": "The OpenSearch Project: https://opensearch.org/"
   }
   

5. Доступ к Dashboards
   Откройте в браузере:
   http://localhost:5601/
   Логин: admin
   Пароль: указан в OPENSEARCH_INITIAL_ADMIN_PASSWORD файла docker-compose.yml

Примечания:

• Для безопасности отключается проверка хоста (-k) при использовании демо-сертификатов
• Все команды предполагают работу в Linux-окружении
• Пароль администратора задаётся при первом запуске

Распространённые проблемы

Рассмотрите эти типичные проблемы и способы их решения, если контейнеры не запускаются или завершаются неожиданно.

Необходимость прав sudo для Docker команд

Проблема:
Требуется использовать sudo для выполнения Docker команд.

Решение:
Добавьте пользователя в группу docker:

sudo usermod -aG docker $USER

Подробнее: Post-installation steps for Linux

Ошибка: “-bash: docker-compose: command not found”

Ситуация:
При использовании Docker Desktop.

Решение:
Используйте команду без дефиса:

docker compose

См. документацию Docker Compose

Ошибка: “docker: ‘compose’ is not a docker command”

Ситуация:
При использовании Docker Engine.

Решение:
Установите Docker Compose отдельно и используйте команду с дефисом:

docker-compose

Ошибка: “max virtual memory areas vm.max_map_count [65530] is too low”

Симптомы:
В логах сервиса появляется сообщение:

opensearch-node1 | ERROR: [1] bootstrap checks failed
opensearch-node1 | [1]: max virtual memory areas vm.max_map_count [65530] is too low...

Решение:
Увеличьте значение vm.max_map_count (см. раздел “Важные системные настройки”):

sudo sysctl -w vm.max_map_count=262144

Альтернативные способы установки

Помимо Docker, OpenSearch можно установить:

• На различные дистрибутивы Linux
• На Windows

Полные руководства: Установка и обновление OpenSearch

Дальнейшее изучение

После успешного развёртывания кластера рекомендуется изучить:

1. Плагин безопасности
2. Конфигурация OpenSearch
3. Установка плагинов

Следующие шаги

Ознакомьтесь с разделом Взаимодействие с OpenSearch, чтобы узнать как отправлять запросы в систему.

1.2 - Взаимодействие с OpenSearch

На этой странице рассматривается REST API. Список доступных клиентов для языков программирования вы найдёте в разделе Клиенты.

REST API OpenSearch

REST API предоставляет гибкий способ взаимодействия с кластерами OpenSearch. Через API вы можете:

• Изменять настройки OpenSearch
• Управлять индексами
• Проверять состояние кластера
• Получать статистику
• И многое другое

Для отправки запросов можно использовать:

• Командную строку (cURL)
• Консоль Dev Tools в OpenSearch Dashboards
• Любой язык программирования с поддержкой HTTP-запросов

Отправка запросов через терминал

Формат запросов зависит от использования плагина безопасности.

Без плагина безопасности:

curl -X GET "http://localhost:9200/_cluster/health"

С плагином безопасности (требуются учётные данные):

curl -X GET "https://localhost:9200/_cluster/health" -ku admin:ВАШ_ПАРОЛЬ

По умолчанию:

• Логин: admin
• Пароль: задаётся в параметре OPENSEARCH_INITIAL_ADMIN_PASSWORD файла docker-compose.yml

Форматирование ответа: Для удобочитаемого JSON добавьте параметр pretty:

curl -X GET "https://localhost:9200/_cluster/health?pretty"

Запросы с телом: Укажите заголовок Content-Type и передайте данные через параметр -d:

curl -X GET "https://localhost:9200/students/_search?pretty" \
  -H 'Content-Type: application/json' \
  -d '{
    "query": {
      "match_all": {}
    }
  }'

Отправка запросов через Dev Tools

Консоль Dev Tools в OpenSearch Dashboards использует упрощённый синтаксис:

1. Откройте Dashboards: https://localhost:5601/
2. Перейдите: Management > Dev Tools
3. Введите запрос (например):

   GET _cluster/health
   

4. Отправьте запрос:
   • Клик по иконке ▶
   • Ctrl+Enter (Cmd+Enter на Mac)

В документации OpenSearch запросы чаще всего приводятся в формате Dev Tools.

Дополнительно:

• Общие параметры REST
• Выполнение запросов в консоли

Индексация документов

Для добавления JSON-документа в индекс OpenSearch (индексации документа) отправьте HTTP-запрос со следующим форматом:

PUT https://<хост>:<порт>/<имя-индекса>/_doc/<идентификатор-документа>

Пример индексации документа о студенте:

PUT /students/_doc/1
{
  "name": "Иван Иванов",
  "gpa": 4.5,
  "grad_year": 2023
}

После выполнения запроса:

• OpenSearch создаст индекс students (если не существует)
• Сохранит документ с указанным ID (1)
• Если ID не указан - сгенерирует его автоматически

Динамическое маппинг

OpenSearch автоматически определяет типы полей на основе JSON-структуры документа.

Просмотр схемы полей:

GET /students/_mapping

Пример ответа:

{
  "students": {
    "mappings": {
      "properties": {
        "gpa": {"type": "float"},
        "grad_year": {"type": "long"},
        "name": {
          "type": "text",
          "fields": {
            "keyword": {
              "type": "keyword", 
              "ignore_above": 256
            }
          }
        }
      }
    }
  }
}

Особенности типов:

• Числовые значения: float, long
• Текстовые поля:
  • Основное поле (text): для полнотекстового поиска (с анализом)
  • Подполе (keyword): для точного поиска по терминам

Важно: Для изменения типов (например, преобразования grad_year в дату) требуется пересоздание индекса с явным указанием маппинга.

Поиск документов

Базовый запрос (возвращает все документы):

GET /students/_search
{
  "query": {
    "match_all": {}
  }
}

Пример ответа:

{
  "took": 12,
  "hits": {
    "total": {
      "value": 1,
      "relation": "eq"
    },
    "hits": [
      {
        "_index": "students",
        "_id": "1",
        "_score": 1,
        "_source": {
          "name": "Иван Иванов",
          "gpa": 4.5,
          "grad_year": 2023
        }
      }
    ]
  }
}

Ключевые элементы ответа:

• took: время выполнения (мс)
• hits.total: количество найденных документов
• hits.hits: массив результатов
• _score: релевантность документа

Дополнительные материалы:

• Управление индексами
• Динамическое маппинг
• Поиск по данным

Обновление документов

В OpenSearch документы неизменяемы, но их можно обновить, полностью заменив содержимое или изменив отдельные поля.

Полное обновление (переиндексация)

Используйте Index Document API для полного обновления:

PUT /students/_doc/1
{
  "name": "Иван Иванов",
  "gpa": 4.7,  // Обновлённое значение
  "grad_year": 2023,
  "address": "ул. Ленина, 123"  // Новое поле
}

Частичное обновление

Используйте Update Document API для изменения отдельных полей:

POST /students/_update/1/
{
  "doc": {
    "gpa": 4.7,
    "address": "ул. Ленина, 123"
  }
}

Удаление данных

Удаление документа

DELETE /students/_doc/1

Удаление индекса

DELETE /students

Настройка индексов

Маппинги и параметры

Индексы настраиваются через:

• Маппинги - определяют типы полей
• Параметры - настройки индекса (количество шардов и т.д.)

Пример создания индекса с явными настройками:

PUT /students
{
  "settings": {
    "index.number_of_shards": 1
  },
  "mappings": {
    "properties": {
      "name": {"type": "text"},
      "grad_year": {"type": "date"}
    }
  }
}

Проверка маппинга:

GET /students/_mapping

Важно:

• Типы полей нельзя изменить после создания
• Для изменения требуется пересоздание индекса

Дополнительные материалы

• Справочник по REST API
• Языковые клиенты
• Типы полей и маппинги
• Конфигурация OpenSearch

Следующие шаги

Ознакомьтесь с разделом Загрузка данных в OpenSearch для изучения способов импорта данных.

1.3 - Загрузка данных в OpenSearch

Существует несколько способов импорта данных:

1. Добавление отдельных документов
   См. раздел Индексация документов

2. Массовая загрузка документов
   См. раздел Пакетная индексация

3. Использование Data Prepper
   Серверного сборщика данных OpenSearch для обработки перед анализом

4. Другие инструменты
   См. Инструменты OpenSearch

Пакетная индексация

Для массовой загрузки используйте Bulk API:

POST _bulk
{ "create": { "_index": "students", "_id": "2" } }
{ "name": "Алексей Петров", "gpa": 4.2, "grad_year": 2025 }
{ "create": { "_index": "students", "_id": "3" } }
{ "name": "Мария Смирнова", "gpa": 4.8, "grad_year": 2024 }

Работа с тестовыми данными

OpenSearch предоставляет демонстрационный набор данных электронной коммерции.

Шаги для создания тестового индекса:

1. Скачайте файлы:

   # Маппинг полей
   curl -O https://raw.githubusercontent.com/.../ecommerce-field_mappings.json
   
   # Данные для загрузки
   curl -O https://raw.githubusercontent.com/.../ecommerce.ndjson
   

2. Примените схему полей:

   curl -H "Content-Type: application/json" -X PUT "https://localhost:9200/ecommerce" \
   -ku admin:ПАРОЛЬ --data-binary "@ecommerce-field_mappings.json"
   

3. Загрузите данные:

   curl -H "Content-Type: application/x-ndjson" -X POST "https://localhost:9200/ecommerce/_bulk" \
   -ku admin:ПАРОЛЬ --data-binary "@ecommerce.ndjson"
   

Пример поиска:

GET ecommerce/_search
{
  "query": {
    "match": {
      "customer_first_name": "Светлана"
    }
  }
}

Визуализация данных

Инструкции по работе с визуализациями см. в руководстве по OpenSearch Dashboards.

Дополнительные материалы

• Data Prepper
• Инструменты загрузки
• Bulk API

Следующие шаги

Изучите раздел Поиск по данным для получения информации о возможностях поиска.

1.4 - Поиск данных в OpenSearch

OpenSearch предлагает несколько методов поиска:

1. Query DSL - основной язык запросов для сложных поисковых сценариев
2. Query string - упрощённый синтаксис для параметров запроса
3. SQL - традиционный язык запросов для реляционных данных
4. PPL (Piped Processing Language) - язык для задач observability
5. DQL (Dashboards Query Language) - текстовый язык фильтрации в Dashboards

Подготовка данных

Перед началом загрузим тестовые данные о студентах:

POST _bulk
{ "create": { "_index": "students", "_id": "1" } }
{ "name": "Иван Петров", "gpa": 4.5, "grad_year": 2023}
{ "create": { "_index": "students", "_id": "2" } }
{ "name": "Алексей Смирнов", "gpa": 4.2, "grad_year": 2025 }
{ "create": { "_index": "students", "_id": "3" } }
{ "name": "Мария Иванова", "gpa": 4.8, "grad_year": 2024 }

Базовые запросы

Получение всех документов:

GET /students/_search

Эквивалентно:

GET /students/_search
{
  "query": { "match_all": {} }
}

Структура ответа:

• took - время выполнения (мс)
• timed_out - флаг превышения таймаута
• _shards - статистика по шардам
• hits - результаты поиска:
  • total - общее количество совпадений
  • max_score - максимальная релевантность
  • hits - массив документов с оценкой релевантности

Query string поиск

Пример поиска по имени:

GET /students/_search?q=name:john

вернет ответ:

{
  "took": 18,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 1,
      "relation": "eq"
    },
    "max_score": 0.9808291,
    "hits": [
      {
        "_index": "students",
        "_id": "1",
        "_score": 0.9808291,
        "_source": {
          "name": "John Doe",
          "grade": 12,
          "gpa": 3.89,
          "grad_year": 2022,
          "future_plans": "John plans to be a computer science major"
        }
      }
    ]
  }
}

Полнотекстовый поиск (Query DSL)

Поиск с анализом текста:

GET /students/_search
{
  "query": {
    "match": {
      "name": "иван"  # Найдёт "Иван Петров" и "Мария Иванова"
    }
  }
}

{
  "took": 13,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 1,
      "relation": "eq"
    },
    "max_score": 0.9808291,
    "hits": [
      {
        "_index": "students",
        "_id": "1",
        "_score": 0.9808291,
        "_source": {
          "name": "Иван Петров",
          "gpa": 3.89,
          "grad_year": 2022
        }
      }
    ]
  }
}

Поиск по ключевым словам

Точное совпадение (без анализа):

GET /students/_search
{
  "query": {
    "match": {
      "name.keyword": "john doe"  # Только полное совпадение
    }
  }
}

{
  "took": 19,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 1,
      "relation": "eq"
    },
    "max_score": 0.9808291,
    "hits": [
      {
        "_index": "students",
        "_id": "1",
        "_score": 0.9808291,
        "_source": {
          "name": "John Doe",
          "gpa": 3.89,
          "grad_year": 2022
        }
      }
    ]
  }
}

Фильтры

Точное значение:

GET students/_search
{
  "query": { 
    "bool": { 
      "filter": [ 
        { "term":  { "grad_year": 2023 }}
      ]
    }
  }
}

Диапазон значений:

GET students/_search
{
  "query": { 
    "bool": { 
      "filter": [ 
        { "range": { "gpa": { "gt": 4.0 }}}
      ]
    }
  }
}

Составные запросы

Комбинация условий:

GET students/_search
{
  "query": {
    "bool": {
      "must": [
        { "match": { "name": "иван" } },
        { "range": { "gpa": { "gte": 4.0 } } },
        { "term":  { "grad_year": 2023 }}
      ]
    }
  }
}

Расширенные возможности

OpenSearch поддерживает современные методы поиска:

• k-NN (поиск ближайших соседей)
• Семантический поиск
• Мультимодальный поиск
• Гибридный поиск

Дополнительные материалы

• Справочник Query DSL
• Методы поиска

1.5 - Начало работы с безопасностью в OpenSearch

Демонстрационная конфигурация безопасности

Наиболее простой способ начать работу с безопасностью OpenSearch - использовать демонстрационную конфигурацию. OpenSearch включает полезные скрипты, в том числе:

• install_demo_configuration.sh (для Linux/macOS)
• install_demo_configuration.bat (для Windows)

Расположение скрипта:
plugins/opensearch-security/tools/

Действия скрипта:

1. Создает демонстрационные сертификаты для TLS-шифрования на транспортном и REST-уровнях
2. Настраивает тестовых пользователей, роли и привязки ролей
3. Конфигурирует плагин безопасности для использования внутренней базы данных аутентификации
4. Обновляет opensearch.yml базовой конфигурацией для запуска кластера

Важно! Демонстрационные сертификаты и пароли по умолчанию не должны использоваться в production. Перед развертыванием в продакшене их необходимо заменить на собственные.

Настройка демонстрационной конфигурации

Перед запуском скрипта:

1. Установите переменную окружения с надежным паролем администратора:

   export OPENSEARCH_INITIAL_ADMIN_PASSWORD=<ваш_надежный_пароль>
   

2. Проверьте надежность пароля с помощью инструмента Zxcvbn

Запуск скрипта:

./plugins/opensearch-security/tools/install_demo_configuration.sh

Проверка конфигурации:

curl -k -XGET -u admin:<пароль> https://<ip-opensearch>:9200

Ожидаемый ответ:

{
  "name": "smoketestnode",
  "cluster_name": "opensearch",
  "version": {
    "distribution": "opensearch",
    "number": "2.13.0"
  },
  "tagline": "The OpenSearch Project: https://opensearch.org/"
}

Настройка OpenSearch Dashboards

Добавьте в opensearch_dashboards.yml следующую конфигурацию:

opensearch.hosts: [https://localhost:9200]
opensearch.ssl.verificationMode: none
opensearch.username: kibanaserver
opensearch.password: kibanaserver
opensearch.requestHeadersWhitelist: [authorization, securitytenant]

opensearch_security.multitenancy.enabled: true
opensearch_security.multitenancy.tenants.preferred: [Private, Global]
opensearch_security.readonly_mode.roles: [kibana_read_only]
opensearch_security.cookie.secure: false  # Отключено для HTTP

Запуск Dashboards:

yarn start --no-base-path

После запуска в логах появятся строки:

[info][listening] Server running at http://localhost:5601
[info][server][OpenSearchDashboards][http] http server running at http://localhost:5601

Доступ через браузер: http://localhost:5601
Логин: admin
Пароль: значение из OPENSEARCH_INITIAL_ADMIN_PASSWORD

Управление пользователями и ролями

1. Добавление пользователей

Способы:

• Редактирование internal_users.yml
• Использование API
• Через интерфейс OpenSearch Dashboards

Пример добавления пользователя в internal_users.yml:

test-user:
  hash: "$2y$12$CkxFoTAJKsZaWv/m8VoZ6ePG3DBeBTAvoo4xA2P21VCS9w2RYumsG"
  backend_roles:
    - "test-backend-role"
    - "kibanauser"
  description: "Тестовый пользователь"

Генерация хеша пароля:

./plugins/opensearch-security/tools/hash.sh

Введите пароль (например, secretpassword), скопируйте полученный хеш.

2. Создание ролей

Формат roles.yml:

<имя_роли>:
  cluster_permissions:
    - <разрешение_кластера>
  index_permissions:
    - index_patterns:
        - <шаблон_индекса>
      allowed_actions:
        - <разрешения_индекса>

Пример роли для доступа к индексу:

human_resources:
  index_permissions:
    - index_patterns:
        - "humanresources"
      allowed_actions:
        - "READ"

3. Привязка пользователей к ролям

Формат roles_mapping.yml:

<имя_роли>:
  users:
    - <имя_пользователя>
  backend_roles:
    - <имя_роли>

Пример привязки:

human_resources:
  backend_roles:
    - "test-backend-role"

kibana_user:
  backend_roles:
    - "kibanauser"

Применение изменений конфигурации

После изменения файлов необходимо загрузить конфигурацию в security index:

./plugins/opensearch-security/tools/securityadmin.sh \
  -cd "config/opensearch-security" \
  -icl \
  -key "../kirk-key.pem" \
  -cert "../kirk.pem" \
  -cacert "../root-ca.pem" \
  -nhnv

Дальнейшие шаги

1. Ознакомьтесь с Рекомендациями по безопасности OpenSearch
2. Изучите Обзор конфигурации безопасности для кастомизации под ваши задачи

Примечания:

• Все команды предполагают выполнение из корневой директории OpenSearch
• Для production-окружений обязательно замените демонстрационные сертификаты
• Регулярно обновляйте пароли администраторов

1.6 - Основные концепции OpenSearch

Базовые понятия

Документ
Базовая единица информации в OpenSearch, хранимая в формате JSON. Представляет собой структурированные данные в виде пар “ключ-значение”.

Индекс
Коллекция логически связанных документов. Аналог таблицы в реляционных БД.

JSON (JavaScript Object Notation)
Текстовый формат для хранения данных, использующий структуру ключ-значение. Основной формат представления данных в OpenSearch.

Маппинг
Схема индекса, определяющая:

• Типы полей документов
• Способы индексации и хранения
• Параметры анализа текста

Архитектура кластера

Узел (Node)
Отдельный сервер, являющийся частью кластера OpenSearch.

Кластер
Совокупность узлов, работающих как единая система.

Управляющий узел (Cluster Manager)
Специальный узел, координирующий кластерные операции:

• Создание/удаление индексов
• Балансировка нагрузки
• Мониторинг состояния узлов

Шард (Shard)
Часть индекса, содержащая подмножество его данных. Индексы разделяются на шарды для:

• Горизонтального масштабирования
• Распределения нагрузки

Типы шардов:

• Первичный (Primary) - основной шард с данными
• Реплика (Replica) - копия первичного шарда для:
  • Отказоустойчивости
  • Повышения производительности поиска

Структуры данных и хранение

Doc Values
Оптимизированная on-disk структура для:

• Сортировки
• Агрегации
• Доступа к значениям полей

Инвертированный индекс
Структура данных, отображающая термины на документы, которые их содержат. Основа полнотекстового поиска.

Lucene
Библиотека поиска, лежащая в основе OpenSearch. Отвечает за:

• Индексацию
• Хранение
• Поиск данных

Сегмент (Segment)
Неизменяемая единица хранения данных внутри шарда. Особенности:

• Создается при операции refresh
• Объединяется в процессе merge
• Оптимизирован для быстрого поиска

Операции с данными

Ингestion
Процесс добавления данных в OpenSearch. Включает:

• Прием данных
• Парсинг
• Подготовку к индексации

Индексация
Процесс организации данных для эффективного поиска:

• Анализ текста
• Построение инвертированного индекса
• Хранение документов

Пакетная индексация
Массовая загрузка документов через Bulk API:

• Высокая производительность
• Минимизация сетевых издержек
• Атомарность операций

Анализ текста

Текстовый анализ
Процесс преобразования неструктурированного текста в последовательность терминов для индексации.

Компоненты анализатора:

1. Character Filter
   Обрабатывает сырой текст:

   • Удаление/замена символов
   • HTML-разметка

2. Tokenizer
   Разбивает текст на токены (слова) с метаданными:

   • Позиция
   • Длина
   • Смещение

3. Token Filter
   Модифицирует токены:

   • Приведение к нижнему регистру
   • Удаление стоп-слов
   • Добавление синонимов
   • Стемминг

Типы анализаторов:

• Analyzer
  Полный конвейер обработки (character filter → tokenizer → token filter)

• Normalizer
  Только character filter (без токенизации)

Стемминг
Приведение слов к базовой форме (например: “running” → “run”)

Поиск и запросы

Типы запросов:

• Query DSL - основной язык сложных запросов
• Query String - упрощенный синтаксис для URL
• DQL - язык фильтрации в Dashboards
• PPL - язык для observability с pipe-синтаксисом

Контексты выполнения:

• Query Context
  Оценивает релевантность (как хорошо документ соответствует запросу)

• Filter Context
  Проверяет точное соответствие (да/нет) без расчета релевантности

Типы поиска:

• Полнотекстовый
  С учетом морфологии и вариаций слов

• По ключевым словам
  Точное совпадение (без анализа)

Агрегации
Механизм анализа и суммирования данных:

• Метрики (avg, sum)
• Бакетизация (histogram, date_histogram)
• Вложенные агрегации

Жизненный цикл обновлений

1. Транзакционный лог (translog)

   • Операция записывается в translog
   • Гарантия durability через fsync
   • Подтверждение клиенту

2. In-memory буфер

   • Данные добавляются в буфер Lucene
   • Еще не видны для поиска

3. Refresh

   • Сброс буфера в сегменты
   • Данные становятся видимыми для поиска
   • Без гарантии durability

4. Flush

   • Запись сегментов на диск (fsync)
   • Очистка translog
   • Гарантия сохранности данных

5. Merge

   • Объединение мелких сегментов
   • Оптимизация:
     • Уменьшение количества файлов
     • Освобождение места
     • Улучшение производительности

Критические операции

Translog
Журнал операций для гарантии сохранности данных. Особенности:

• Записывается синхронно перед подтверждением
• Ограничен по размеру
• Очищается после flush

Refresh
Периодическая операция (по умолчанию каждые 1с):

• Делает данные доступными для поиска
• Создает новые сегменты
• Не гарантирует сохранность при сбое

Flush
Операция записи на диск:

• Обеспечивает durability
• Выполняется автоматически при:
  • Достижении лимита translog
  • Плановом обслуживании

Merge
Фоновая оптимизация:

• Управляется политикой слияния
• Регулирует:
  • Частоту слияний
  • Максимальный размер сегментов
  • Параллелизм операций

2 - Install and upgrade OpenSearch

OpenSearch и OpenSearch Dashboards доступны на любом совместимом хосте, который поддерживает Docker (таких как Linux, MacOS или Windows). Кроме того, вы можете установить оба продукта на различных дистрибутивах Linux и на Windows.

Скачайте OpenSearch для вашей предпочтительной платформы, а затем выберите один из следующих руководств по установке.

После установки OpenSearch ознакомьтесь с его настройкой для вашего развертывания.

Для получения дополнительной информации об обновлении вашего кластера OpenSearch смотрите руководство по обновлению.

Для информации об инструментах обновления смотрите инструменты обновления, миграции и сравнения OpenSearch.

Для установки плагинов смотрите раздел Установка плагинов.

2.1 - Установка OpenSearch

Рекомендации по файловой системе

Избегайте использования сетевой файловой системы для хранения узлов в рабочем процессе в производственной среде. Использование сетевой файловой системы для хранения узлов может вызвать проблемы с производительностью в вашем кластере из-за таких факторов, как условия сети (например, задержка или ограниченная пропускная способность) или скорости чтения/записи. Вам следует использовать твердотельные накопители (SSD), установленные на хосте, для хранения узлов, где это возможно.

Совместимость с Java

Распределение OpenSearch для Linux поставляется с совместимой версией JDK Adoptium Java в каталоге jdk. Чтобы узнать версию JDK, выполните команду ./jdk/bin/java -version. Например, архив OpenSearch 1.0.0 поставляется с Java 15.0.1+9 (не LTS), OpenSearch 1.3.0 поставляется с Java 11.0.14.1+1 (LTS), а OpenSearch 2.0.0 поставляется с Java 17.0.2+8 (LTS). OpenSearch тестируется со всеми совместимыми версиями Java.

Чтобы использовать другую установку Java, установите переменную окружения OPENSEARCH_JAVA_HOME или JAVA_HOME на расположение установки Java. Например:

export OPENSEARCH_JAVA_HOME=/path/to/opensearch-3.1.0/jdk

Сетевые требования

Следующие порты необходимо открыть для компонентов OpenSearch.

Важные настройки

Для рабочих нагрузок в производственной среде убедитесь, что настройка Linux vm.max_map_count установлена как минимум на 262144. Даже если вы используете образ Docker, установите это значение на хост-машине. Чтобы проверить текущее значение, выполните следующую команду:

cat /proc/sys/vm/max_map_count

Чтобы увеличить значение, добавьте следующую строку в файл /etc/sysctl.conf:

vm.max_map_count=262144

Затем выполните команду sudo sysctl -p, чтобы перезагрузить настройки.

Для рабочих нагрузок Windows вы можете установить vm.max_map_count, выполнив следующие команды:

wsl -d docker-desktop
sysctl -w vm.max_map_count=262144

Пример файла docker-compose.yml

Файл docker-compose.yml также содержит несколько ключевых настроек:

bootstrap.memory_lock: true

Эта настройка отключает свопинг (вместе с memlock). Свопинг может значительно снизить производительность и стабильность, поэтому вы должны убедиться, что он отключен на производственных кластерах.

Включение настройки bootstrap.memory_lock заставит JVM зарезервировать всю необходимую память. Руководство по настройке сборки мусора Java SE Hotspot VM документирует резервирование 1 гигабайта (ГБ) нативной памяти для метаданных классов по умолчанию. В сочетании с кучей Java это может привести к ошибке из-за нехватки нативной памяти на ВМ с меньшим объемом памяти, чем эти требования. Чтобы предотвратить ошибки, ограничьте размер резервируемой памяти с помощью -XX:CompressedClassSpaceSize или -XX:MaxMetaspaceSize и установите размер кучи Java, чтобы убедиться, что у вас достаточно системной памяти.

OPENSEARCH_JAVA_OPTS: -Xms512m -Xmx512m

Эта настройка устанавливает размер кучи Java (рекомендуем использовать половину системной ОЗУ).

OpenSearch по умолчанию использует -Xms1g -Xmx1g для выделения памяти кучи, что имеет приоритет над конфигурациями, указанными с использованием процентной нотации (-XX:MinRAMPercentage, -XX:MaxRAMPercentage). Например, если вы установите OPENSEARCH_JAVA_OPTS=-XX:MinRAMPercentage=30 -XX:MaxRAMPercentage=70, предустановленные значения -Xms1g -Xmx1g переопределят эти настройки. При использовании OPENSEARCH_JAVA_OPTS для определения выделения памяти убедитесь, что вы используете нотацию -Xms и -Xmx.

nofile: 65536

Эта настройка устанавливает лимит в 65536 открытых файлов для пользователя OpenSearch.

port: 9600

Эта настройка позволяет вам получить доступ к Анализатору производительности на порту 9600.

Не объявляйте одни и те же параметры JVM в нескольких местах, так как это может привести к непредсказуемому поведению или сбою запуска службы OpenSearch. Если вы объявляете параметры JVM с помощью переменной окружения, такой как OPENSEARCH_JAVA_OPTS=-Xms3g -Xmx3g, то вам следует закомментировать любые ссылки на этот параметр JVM в config/jvm.options. Напротив, если вы определяете параметры JVM в config/jvm.options, то не следует определять эти параметры JVM с помощью переменных окружения.

Важные системные свойства

OpenSearch имеет ряд системных свойств, перечисленных в следующей таблице, которые вы можете указать в файле config/jvm.options или в переменной OPENSEARCH_JAVA_OPTS, используя нотацию аргументов командной строки -D.

2.1.1 - Docker

Docker значительно упрощает процесс настройки и управления вашими кластерами OpenSearch. Вы можете загружать официальные образы из Docker Hub или Amazon Elastic Container Registry (Amazon ECR) и быстро развернуть кластер, используя Docker Compose и любой из примеров файлов Docker Compose, включенных в этот гид. Опытные пользователи OpenSearch могут дополнительно настроить свое развертывание, создав собственный файл Docker Compose.

Контейнеры Docker являются портативными и будут работать на любом совместимом хосте, который поддерживает Docker (таких как Linux, MacOS или Windows). Портативность контейнера Docker предлагает гибкость по сравнению с другими методами установки, такими как RPM или ручная установка из Tarball, которые требуют дополнительной конфигурации после загрузки и распаковки.

Этот гид предполагает, что вы уверенно работаете с интерфейсом командной строки (CLI) Linux. Вы должны понимать, как вводить команды, перемещаться между директориями и редактировать текстовые файлы. Для получения помощи по Docker или Docker Compose обратитесь к официальной документации на их веб-сайтах.

Установка Docker и Docker Compose

Посетите страницу Get Docker для получения рекомендаций по установке и настройке Docker для вашей среды. Если вы устанавливаете Docker Engine с помощью CLI, то по умолчанию Docker не будет иметь никаких ограничений на доступные ресурсы хоста. В зависимости от вашей среды вы можете настроить ограничения ресурсов в Docker. См. раздел Runtime options with Memory, CPUs, and GPUs для получения информации.

Пользователи Docker Desktop должны установить использование памяти хоста на минимум 4 ГБ, открыв Docker Desktop и выбрав Settings → Resources.

Docker Compose — это утилита, которая позволяет пользователям запускать несколько контейнеров с одной командой. Вы передаете файл Docker Compose при его вызове. Docker Compose читает эти настройки и запускает запрашиваемые контейнеры. Docker Compose устанавливается автоматически с Docker Desktop, но пользователи, работающие в командной строке, должны установить Docker Compose вручную. Вы можете найти информацию о установке Docker Compose на официальной странице Docker Compose GitHub.

Если вам нужно установить Docker Compose вручную и ваш хост поддерживает Python, вы можете использовать pip для автоматической установки пакета Docker Compose.

Настройка важных параметров хоста

Перед установкой OpenSearch с использованием Docker настройте следующие параметры. Это самые важные настройки, которые могут повлиять на производительность ваших сервисов, но для дополнительной информации смотрите раздел о важных системных настройках.

Настройки для Linux

Для среды Linux выполните следующие команды:

1. Отключите производительность памяти с помощью свопинга для улучшения производительности:

   sudo swapoff -a
   

2. Увеличьте количество доступных для OpenSearch карт памяти:

   # Отредактируйте файл конфигурации sysctl
   sudo vi /etc/sysctl.conf
   
   # Добавьте строку для определения желаемого значения
   # или измените значение, если ключ существует,
   # а затем сохраните изменения.
   vm.max_map_count=262144
   
   # Перезагрузите параметры ядра с помощью sysctl
   sudo sysctl -p
   
   # Проверьте, что изменение было применено, проверив значение
   cat /proc/sys/vm/max_map_count
   

Настройки для Windows

Для рабочих нагрузок Windows, использующих WSL через Docker Desktop, выполните следующие команды в терминале, чтобы установить vm.max_map_count:

wsl -d docker-desktop
sysctl -w vm.max_map_count=262144

Запуск OpenSearch в контейнере Docker

Официальные образы OpenSearch размещены на Docker Hub и Amazon ECR. Если вы хотите просмотреть образы, вы можете загружать их по отдельности, используя команду docker pull, как в следующих примерах.

Docker Hub:

docker pull opensearchproject/opensearch:3
docker pull opensearchproject/opensearch-dashboards:3

Amazon ECR:

docker pull public.ecr.aws/opensearchproject/opensearch:3
docker pull public.ecr.aws/opensearchproject/opensearch-dashboards:3

Чтобы загрузить конкретную версию OpenSearch или OpenSearch Dashboards, отличную от последней доступной версии, измените тег образа, где он упоминается (либо в командной строке, либо в файле Docker Compose). Например, opensearchproject/opensearch:3.1.0 загрузит версию OpenSearch 3.1.0. Чтобы загрузить последнюю версию, используйте opensearchproject/opensearch:latest. Обратитесь к официальным репозиториям образов для доступных версий.

Перед тем как продолжить, вы должны убедиться, что Docker работает корректно, развернув OpenSearch в одном контейнере.

Запуск OpenSearch в контейнере Docker

1. Выполните следующую команду:

# Эта команда сопоставляет порты 9200 и 9600, устанавливает тип обнаружения на "single-node" и запрашивает самый новый образ OpenSearch
docker run -d -p 9200:9200 -p 9600:9600 -e "discovery.type=single-node" opensearchproject/opensearch:latest

Для OpenSearch версии 2.12 или выше установите новый пользовательский пароль администратора перед установкой, используя следующую команду:

docker run -d -p 9200:9200 -p 9600:9600 -e "discovery.type=single-node" -e "OPENSEARCH_INITIAL_ADMIN_PASSWORD=<custom-admin-password>" opensearchproject/opensearch:latest

2. Отправьте запрос на порт 9200. Имя пользователя и пароль по умолчанию — admin.

curl https://localhost:9200 -ku admin:<custom-admin-password>

Вы должны получить ответ, который выглядит следующим образом:

{
  "name" : "a937e018cee5",
  "cluster_name" : "docker-cluster",
  "cluster_uuid" : "GLAjAG6bTeWErFUy_d-CLw",
  "version" : {
    "distribution" : "opensearch",
    "number" : "<version>",
    "build_type" : "<build-type>",
    "build_hash" : "<build-hash>",
    "build_date" : "<build-date>",
    "build_snapshot" : false,
    "lucene_version" : "<lucene-version>",
    "minimum_wire_compatibility_version" : "7.10.0",
    "minimum_index_compatibility_version" : "7.0.0"
  },
  "tagline" : "The OpenSearch Project: https://opensearch.org/"
}

3. Перед остановкой работающего контейнера отобразите список всех работающих контейнеров и скопируйте идентификатор контейнера для узла OpenSearch, который вы тестируете. В следующем примере идентификатор контейнера — a937e018cee5:

$ docker container ls
CONTAINER ID   IMAGE                                 COMMAND                  CREATED          STATUS          PORTS                                                                NAMES
a937e018cee5   opensearchproject/opensearch:latest   "./opensearch-docker…"   19 minutes ago   Up 19 minutes   0.0.0.0:9200->9200/tcp, 9300/tcp, 0.0.0.0:9600->9600/tcp, 9650/tcp   wonderful_boyd

4. Остановите работающий контейнер, передав идентификатор контейнера в команду docker stop.

docker stop <containerId>

Помните, что команда docker container ls не отображает остановленные контейнеры. Если вы хотите просмотреть остановленные контейнеры, используйте команду docker container ls -a. Вы можете удалить ненужные контейнеры вручную с помощью команды docker container rm <containerId_1> <containerId_2> <containerId_3> [...] (укажите все идентификаторы контейнеров, которые вы хотите остановить, разделенные пробелами), или, если вы хотите удалить все остановленные контейнеры, вы можете использовать более короткую команду docker container prune.

Развертывание кластера OpenSearch с использованием Docker Compose

Хотя технически возможно создать кластер OpenSearch, создавая контейнеры по одной команде за раз, гораздо проще определить вашу среду в YAML-файле и позволить Docker Compose управлять кластером. В следующем разделе содержатся примеры YAML-файлов, которые вы можете использовать для запуска предопределенного кластера с OpenSearch и OpenSearch Dashboards. Эти примеры полезны для тестирования и разработки, но не подходят для производственной среды. Если у вас нет опыта работы с Docker Compose, вам может быть полезно ознакомиться со спецификацией Docker Compose для получения рекомендаций по синтаксису и форматированию перед внесением изменений в структуры словарей в примерах.

Файл YAML, который определяет среду, называется файлом Docker Compose. По умолчанию команды docker-compose сначала проверяют вашу текущую директорию на наличие файла, который соответствует любому из следующих имен:

• docker-compose.yml
• docker-compose.yaml
• compose.yml
• compose.yaml

Если ни один из этих файлов не существует в вашей текущей директории, команда docker-compose завершится с ошибкой.

Вы можете указать пользовательское местоположение и имя файла при вызове docker-compose с помощью флага -f:

# Используйте относительный или абсолютный путь к файлу.
docker compose -f /path/to/your-file.yml up

Если вы впервые запускаете кластер OpenSearch с использованием Docker Compose, используйте следующий пример файла docker-compose.yml. Сохраните его в домашнем каталоге вашего хоста и назовите его docker-compose.yml. Этот файл создает кластер, который содержит три контейнера: два контейнера, работающих с сервисом OpenSearch, и один контейнер, работающий с OpenSearch Dashboards. Эти контейнеры общаются через мостовую сеть под названием opensearch-net и используют два тома, по одному для каждого узла OpenSearch. Поскольку этот файл явно не отключает демонстрационную конфигурацию безопасности, устанавливаются самоподписанные TLS-сертификаты, и создаются внутренние пользователи с именами и паролями по умолчанию.

Установка пользовательского пароля администратора

Начиная с OpenSearch 2.12, для настройки демонстрационной конфигурации безопасности требуется пользовательский пароль администратора. Выполните одно из следующих действий:

1. Перед запуском docker-compose.yml установите новый пользовательский пароль администратора, используя следующую команду:

   export OPENSEARCH_INITIAL_ADMIN_PASSWORD=<custom-admin-password>
   

2. Создайте файл .env в той же папке, что и ваш файл docker-compose.yml, с переменной OPENSEARCH_INITIAL_ADMIN_PASSWORD и значением надежного пароля.

Требования к паролям

OpenSearch по умолчанию обеспечивает высокую безопасность паролей, используя библиотеку оценки прочности паролей zxcvbn, разработанную компанией Dropbox.

Эта библиотека оценивает пароли на основе энтропии, а не жестких правил сложности, используя следующие рекомендации:

1. Сосредоточьтесь на энтропии, а не только на правилах: Вместо того чтобы просто добавлять цифры или специальные символы, придавайте приоритет общей непредсказуемости. Длинные пароли, состоящие из случайных слов или символов, обеспечивают более высокую энтропию, что делает их более безопасными, чем короткие пароли, соответствующие традиционным правилам сложности.

2. Избегайте общих шаблонов и слов из словаря: Библиотека zxcvbn обнаруживает распространенные шаблоны и слова из словаря, что помогает предотвратить использование легко угадываемых паролей.

Следуя этим рекомендациям, вы сможете создать более надежные пароли, которые обеспечат лучшую защиту ваших учетных записей и данных в OpenSearch.

Sample docker-compose.yml

services:
  opensearch-node1: # This is also the hostname of the container within the Docker network (i.e. https://opensearch-node1/)
    image: opensearchproject/opensearch:latest # Specifying the latest available image - modify if you want a specific version
    container_name: opensearch-node1
    environment:
      - cluster.name=opensearch-cluster # Name the cluster
      - node.name=opensearch-node1 # Name the node that will run in this container
      - discovery.seed_hosts=opensearch-node1,opensearch-node2 # Nodes to look for when discovering the cluster
      - cluster.initial_cluster_manager_nodes=opensearch-node1,opensearch-node2 # Nodes eligible to serve as cluster manager
      - bootstrap.memory_lock=true # Disable JVM heap memory swapping
      - "OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m" # Set min and max JVM heap sizes to at least 50% of system RAM
      - OPENSEARCH_INITIAL_ADMIN_PASSWORD=${OPENSEARCH_INITIAL_ADMIN_PASSWORD}    # Sets the demo admin user password when using demo configuration, required for OpenSearch 2.12 and later
    ulimits:
      memlock:
        soft: -1 # Set memlock to unlimited (no soft or hard limit)
        hard: -1
      nofile:
        soft: 65536 # Maximum number of open files for the opensearch user - set to at least 65536
        hard: 65536
    volumes:
      - opensearch-data1:/usr/share/opensearch/data # Creates volume called opensearch-data1 and mounts it to the container
    ports:
      - 9200:9200 # REST API
      - 9600:9600 # Performance Analyzer
    networks:
      - opensearch-net # All of the containers will join the same Docker bridge network
  opensearch-node2:
    image: opensearchproject/opensearch:latest # This should be the same image used for opensearch-node1 to avoid issues
    container_name: opensearch-node2
    environment:
      - cluster.name=opensearch-cluster
      - node.name=opensearch-node2
      - discovery.seed_hosts=opensearch-node1,opensearch-node2
      - cluster.initial_cluster_manager_nodes=opensearch-node1,opensearch-node2
      - bootstrap.memory_lock=true
      - "OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m"
      - OPENSEARCH_INITIAL_ADMIN_PASSWORD=${OPENSEARCH_INITIAL_ADMIN_PASSWORD}
    ulimits:
      memlock:
        soft: -1
        hard: -1
      nofile:
        soft: 65536
        hard: 65536
    volumes:
      - opensearch-data2:/usr/share/opensearch/data
    networks:
      - opensearch-net
  opensearch-dashboards:
    image: opensearchproject/opensearch-dashboards:latest # Make sure the version of opensearch-dashboards matches the version of opensearch installed on other nodes
    container_name: opensearch-dashboards
    ports:
      - 5601:5601 # Map host port 5601 to container port 5601
    expose:
      - "5601" # Expose port 5601 for web access to OpenSearch Dashboards
    environment:
      OPENSEARCH_HOSTS: '["https://opensearch-node1:9200","https://opensearch-node2:9200"]' # Define the OpenSearch nodes that OpenSearch Dashboards will query
    networks:
      - opensearch-net

volumes:
  opensearch-data1:
  opensearch-data2:

networks:
  opensearch-net:

Если вы переопределяете настройки opensearch_dashboards.yml, используя переменные окружения в вашем файле Compose, используйте все заглавные буквы и заменяйте точки на подчеркивания. Например, для opensearch.hosts используйте OPENSEARCH_HOSTS.

Это поведение отличается от переопределения настроек opensearch.yml, где преобразование заключается только в изменении оператора присваивания. Например, discovery.type: single-node в opensearch.yml определяется как discovery.type=single-node в docker-compose.yml.

Запуск и управление контейнерами OpenSearch с использованием Docker Compose

1. Создайте и запустите контейнеры в фоновом режиме из домашнего каталога вашего хоста (содержащего docker-compose.yml):

   docker compose up -d
   

2. Проверьте, что сервисные контейнеры запустились корректно:

   docker compose ps
   

3. Если контейнер не удалось запустить, вы можете просмотреть логи сервиса:

   # Если вы не укажете имя сервиса, docker compose покажет логи всех узлов
   docker compose logs <serviceName>
   

4. Проверьте доступ к OpenSearch Dashboards, подключившись к http://localhost:5601 из браузера. Для OpenSearch версии 2.12 и выше вы должны использовать ваш настроенный логин и пароль. Для более ранних версий логин и пароль по умолчанию — admin. Мы не рекомендуем использовать эту конфигурацию на хостах, доступных из публичного интернета, пока вы не настроите конфигурацию безопасности вашего развертывания.

   Помните, что localhost не может быть доступен удаленно. Если вы развертываете эти контейнеры на удаленном хосте, вам нужно установить сетевое соединение и заменить localhost на IP-адрес или DNS-запись, соответствующую хосту.

5. Остановите работающие контейнеры в вашем кластере:

   docker compose down
   

Команда docker compose down остановит работающие контейнеры, но не удалит Docker-тома, которые существуют на хосте. Если вам не важны содержимое этих томов, используйте опцию -v, чтобы удалить все тома, например:

docker compose down -v

Настройка OpenSearch

В отличие от RPM-распределения OpenSearch, которое требует значительного объема конфигурации после установки, запуск кластеров OpenSearch с помощью Docker позволяет вам определить среду еще до создания контейнеров. Это возможно как при использовании Docker, так и при использовании Docker Compose.

Пример команды Docker

Рассмотрим следующую команду:

docker run \
  -p 9200:9200 -p 9600:9600 \
  -e "discovery.type=single-node" \
  -v /path/to/custom-opensearch.yml:/usr/share/opensearch/config/opensearch.yml \
  opensearchproject/opensearch:latest

Разберем каждую часть команды:

• Сопоставляет порты 9200 и 9600 (HOST_PORT:CONTAINER_PORT).
• Устанавливает discovery.type в single-node, чтобы проверки загрузки не завершились неудачей для этого развертывания с одним узлом.
• Использует флаг -v, чтобы передать локальный файл с именем custom-opensearch.yml в контейнер, заменяя файл opensearch.yml, включенный в образ.
• Запрашивает образ opensearchproject/opensearch:latest из Docker Hub.
• Запускает контейнер.

Если вы сравните эту команду с примером файла docker-compose.yml, вы можете заметить некоторые общие настройки, такие как сопоставление портов и ссылка на образ. Однако эта команда только развертывает один контейнер, работающий с OpenSearch, и не создает контейнер для OpenSearch Dashboards. Более того, если вы хотите использовать пользовательские TLS-сертификаты, пользователей или роли, или определить дополнительные тома и сети, то эта “однострочная” команда быстро становится непрактичной. Вот где полезность Docker Compose становится очевидной.

Использование Docker Compose

Когда вы строите свой кластер OpenSearch с помощью Docker Compose, вам может быть проще передавать пользовательские файлы конфигурации с вашего хоста в контейнер, вместо того чтобы перечислять каждую отдельную настройку в docker-compose.yml. Аналогично тому, как в примере команды docker run был смонтирован том с хоста в контейнер с помощью флага -v, файлы Compose могут указывать тома для монтирования как подопцию для соответствующей службы. Следующий сокращенный YAML-файл демонстрирует, как смонтировать файл или директорию в контейнер:

services:
  opensearch-node1:
    volumes:
      - opensearch-data1:/usr/share/opensearch/data
      - ./custom-opensearch.yml:/usr/share/opensearch/config/opensearch.yml
  opensearch-node2:
    volumes:
      - opensearch-data2:/usr/share/opensearch/data
      - ./custom-opensearch.yml:/usr/share/opensearch/config/opensearch.yml
  opensearch-dashboards:
    volumes:
      - ./custom-opensearch_dashboards.yml:/usr/share/opensearch-dashboards/config/opensearch_dashboards.yml

Обратите внимание, что в этом примере каждый узел OpenSearch использует один и тот же файл конфигурации, что упрощает управление настройками. Для получения более подробной информации о использовании томов и синтаксисе обратитесь к официальной документации Docker по томам.

Пример файла Docker Compose для разработки

Если вы хотите создать свой собственный файл compose на основе примера, ознакомьтесь с следующим образцом файла docker-compose.yml. Этот образец создает два узла OpenSearch и один узел OpenSearch Dashboards с отключенным плагином безопасности. Вы можете использовать этот образец в качестве отправной точки, просматривая Настройка основных параметров безопасности.

services:
  opensearch-node1:
    image: opensearchproject/opensearch:latest
    container_name: opensearch-node1
    environment:
      - cluster.name=opensearch-cluster # Название кластера
      - node.name=opensearch-node1 # Название узла, который будет работать в этом контейнере
      - discovery.seed_hosts=opensearch-node1,opensearch-node2 # Узлы, которые будут использоваться для обнаружения кластера
      - cluster.initial_cluster_manager_nodes=opensearch-node1,opensearch-node2 # Узлы, которые могут служить менеджерами кластера
      - bootstrap.memory_lock=true # Отключить свопинг памяти кучи JVM
      - "OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m" # Установить минимальный и максимальный размеры кучи JVM не менее 50% от системной оперативной памяти
      - "DISABLE_INSTALL_DEMO_CONFIG=true" # Предотвращает выполнение встроенного демо-скрипта, который устанавливает демо-сертификаты и конфигурации безопасности в OpenSearch
      - "DISABLE_SECURITY_PLUGIN=true" # Отключает плагин безопасности
    ulimits:
      memlock:
        soft: -1 # Установить memlock на неограниченное (без мягкого или жесткого ограничения)
        hard: -1
      nofile:
        soft: 65536 # Максимальное количество открытых файлов для пользователя opensearch - установить не менее 65536
        hard: 65536
    volumes:
      - opensearch-data1:/usr/share/opensearch/data # Создает том с именем opensearch-data1 и монтирует его в контейнер
    ports:
      - 9200:9200 # REST API
      - 9600:9600 # Анализатор производительности
    networks:
      - opensearch-net # Все контейнеры будут присоединены к одной и той же сети Docker bridge
  opensearch-node2:
    image: opensearchproject/opensearch:latest
    container_name: opensearch-node2
    environment:
      - cluster.name=opensearch-cluster # Название кластера
      - node.name=opensearch-node2 # Название узла, который будет работать в этом контейнере
      - discovery.seed_hosts=opensearch-node1,opensearch-node2 # Узлы, которые будут использоваться для обнаружения кластера
      - cluster.initial_cluster_manager_nodes=opensearch-node1,opensearch-node2 # Узлы, которые могут служить менеджерами кластера
      - bootstrap.memory_lock=true # Отключить свопинг памяти кучи JVM
      - "OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m" # Установить минимальный и максимальный размеры кучи JVM не менее 50% от системной оперативной памяти
      - "DISABLE_INSTALL_DEMO_CONFIG=true" # Предотвращает выполнение встроенного демо-скрипта, который устанавливает демо-сертификаты и конфигурации безопасности в OpenSearch
      - "DISABLE_SECURITY_PLUGIN=true" # Отключает плагин безопасности
    ulimits:
      memlock:
        soft: -1 # Установить memlock на неограниченное (без мягкого или жесткого ограничения)
        hard: -1
      nofile:
        soft: 65536 # Максимальное количество открытых файлов для пользователя opensearch - установить не менее 65536
        hard: 65536
    volumes:
      - opensearch-data2:/usr/share/opensearch/data # Создает том с именем opensearch-data2 и монтирует его в контейнер
    networks:
      - opensearch-net # Все контейнеры будут присоединены к одной и той же сети Docker bridge
  opensearch-dashboards:
    image: opensearchproject/opensearch-dashboards:latest
    container_name: opensearch-dashboards
    ports:
      - 5601:5601 # Привязка порта хоста 5601 к порту контейнера 5601
    expose:
      - "5601" # Открыть порт 5601 для веб-доступа к OpenSearch Dashboards
    environment:
      - 'OPENSEARCH_HOSTS=["http://opensearch-node1:9200","http://opensearch-node2:9200"]' # Указать узлы OpenSearch для Dashboards
      - "DISABLE_SECURITY_DASHBOARDS_PLUGIN=true" # Отключает плагин безопасности в OpenSearch Dashboards
    networks:
      - opensearch-net

volumes:
  opensearch-data1: {} # Создает том opensearch-data1
  opensearch-data2: {} # Создает том opensearch-data2

networks:
  opensearch-net: {} # Создает сеть opensearch-net

Настройка основных параметров безопасности

Перед тем как сделать ваш кластер OpenSearch доступным для внешних хостов, рекомендуется ознакомиться с конфигурацией безопасности развертывания. Вы можете вспомнить из первого примера файла docker-compose.yml, что, если не отключить плагин безопасности, установив DISABLE_SECURITY_PLUGIN=true, встроенный скрипт применит стандартную демо-конфигурацию безопасности к узлам в кластере. Поскольку эта конфигурация используется для демонстрационных целей, стандартные имена пользователей и пароли известны. Поэтому мы рекомендуем создать собственные файлы конфигурации безопасности и использовать тома для передачи этих файлов в контейнеры. Для получения конкретных рекомендаций по настройке безопасности OpenSearch смотрите Конфигурация безопасности.

Чтобы использовать свои собственные сертификаты в конфигурации, добавьте все необходимые сертификаты в раздел томов файла compose:

volumes:
  - ./root-ca.pem:/usr/share/opensearch/config/root-ca.pem
  - ./admin.pem:/usr/share/opensearch/config/admin.pem
  - ./admin-key.pem:/usr/share/opensearch/config/admin-key.pem
  - ./node1.pem:/usr/share/opensearch/config/node1.pem
  - ./node1-key.pem:/usr/share/opensearch/config/node1-key.pem

Когда вы добавляете сертификаты TLS к узлам OpenSearch с помощью томов Docker Compose, вы также должны включить пользовательский файл opensearch.yml, который определяет эти сертификаты. Например:

volumes:
  - ./root-ca.pem:/usr/share/opensearch/config/root-ca.pem
  - ./admin.pem:/usr/share/opensearch/config/admin.pem
  - ./admin-key.pem:/usr/share/opensearch/config/admin-key.pem
  - ./node1.pem:/usr/share/opensearch/config/node1.pem
  - ./node1-key.pem:/usr/share/opensearch/config/node1-key.pem
  - ./custom-opensearch.yml:/usr/share/opensearch/config/opensearch.yml

Помните, что сертификаты, которые вы указываете в файле compose, должны совпадать с сертификатами, определенными в вашем пользовательском файле opensearch.yml. Вам следует заменить корневые, администраторские и узловые сертификаты на свои собственные. Для получения дополнительной информации смотрите Настройка сертификатов TLS.

Пример конфигурации в вашем пользовательском файле opensearch.yml может выглядеть следующим образом, добавляя сертификаты TLS и отличительное имя (DN) сертификата администратора, определяя несколько разрешений и включая подробное аудиторское логирование:

plugins.security.ssl.transport.pemcert_filepath: node1.pem
plugins.security.ssl.transport.pemkey_filepath: node1-key.pem
plugins.security.ssl.transport.pemtrustedcas_filepath: root-ca.pem
plugins.security.ssl.transport.enforce_hostname_verification: false
plugins.security.ssl.http.enabled: true
plugins.security.ssl.http.pemcert_filepath: node1.pem
plugins.security.ssl.http.pemkey_filepath: node1-key.pem
plugins.security.ssl.http.pemtrustedcas_filepath: root-ca.pem
plugins.security.allow_default_init_securityindex: true
plugins.security.authcz.admin_dn:
  - CN=A,OU=UNIT,O=ORG,L=TORONTO,ST=ONTARIO,C=CA
plugins.security.nodes_dn:
  - 'CN=N,OU=UNIT,O=ORG,L=TORONTO,ST=ONTARIO,C=CA'
plugins.security.audit.type: internal_opensearch
plugins.security.enable_snapshot_restore_privilege: true
plugins.security.check_snapshot_restore_write_privileges: true
plugins.security.restapi.roles_enabled: ["all_access", "security_rest_api_access"]
cluster.routing.allocation.disk.threshold_enabled: false
opendistro_security.audit.config.disabled_rest_categories: NONE
opendistro_security.audit.config.disabled_transport_categories: NONE

Полный список настроек

Для получения полного списка настроек смотрите Безопасность.

Используйте тот же процесс для указания конфигурации Backend в файле /usr/share/opensearch/config/opensearch-security/config.yml, а также для создания новых внутренних пользователей, ролей, сопоставлений, групп действий и арендаторов в соответствующих YAML-файлах.

После замены сертификатов и создания собственных внутренних пользователей, ролей, сопоставлений, групп действий и арендаторов, используйте Docker Compose для запуска кластера:

docker compose up -d

Работа с плагинами

Чтобы использовать образ OpenSearch с пользовательским плагином, вам сначала нужно создать Dockerfile. Ознакомьтесь с официальной документацией Docker для получения информации о создании Dockerfile.

FROM opensearchproject/opensearch:latest
RUN /usr/share/opensearch/bin/opensearch-plugin install --batch <pluginId>

Затем выполните следующие команды:

# Создание образа из Dockerfile
docker build --tag=opensearch-custom-plugin .
# Запуск контейнера из пользовательского образа
docker run -p 9200:9200 -p 9600:9600 -v /usr/share/opensearch/data opensearch-custom-plugin

В качестве альтернативы, вы можете удалить плагин из образа перед его развертыванием. Этот пример Dockerfile удаляет плагин безопасности:

FROM opensearchproject/opensearch:latest
RUN /usr/share/opensearch/bin/opensearch-plugin remove opensearch-security

Вы также можете использовать Dockerfile для передачи своих собственных сертификатов для использования с плагином безопасности:

FROM opensearchproject/opensearch:latest
COPY --chown=opensearch:opensearch opensearch.yml /usr/share/opensearch/config/
COPY --chown=opensearch:opensearch my-key-file.pem /usr/share/opensearch/config/
COPY --chown=opensearch:opensearch my-certificate-chain.pem /usr/share/opensearch/config/
COPY --chown=opensearch:opensearch my-root-cas.pem /usr/share/opensearch/config/

2.1.2 - Установка OpenSearch на Debian

Установка OpenSearch с использованием менеджера пакетов Advanced Packaging Tool (APT) значительно упрощает процесс по сравнению с методом Tarball. Несколько технических аспектов, таких как путь установки, расположение конфигурационных файлов и создание службы, управляемой systemd, обрабатываются автоматически менеджером пакетов.

В общем, установка OpenSearch из дистрибутива Debian может быть разбита на несколько шагов:

1. Скачать и установить OpenSearch.
2. Установить вручную из Debian-пакета или из APT-репозитория.
3. (Необязательно) Протестировать OpenSearch.
   • Подтвердите, что OpenSearch может работать, прежде чем применять какую-либо пользовательскую конфигурацию.
   • Это можно сделать без какой-либо безопасности (без пароля, без сертификатов) или с демо-конфигурацией безопасности, которая может быть применена с помощью упакованного скрипта.
4. Настроить OpenSearch для вашей среды.
   • Примените основные настройки к OpenSearch и начните использовать его в вашей среде.

Дистрибутив Debian предоставляет все необходимое для запуска OpenSearch внутри дистрибутивов Linux на базе Debian, таких как Ubuntu.

Этот гид предполагает, что вы уверенно работаете с интерфейсом командной строки (CLI) Linux. Вы должны понимать, как вводить команды, перемещаться между директориями и редактировать текстовые файлы. Некоторые примеры команд ссылаются на текстовый редактор vi, но вы можете использовать любой доступный текстовый редактор.

Шаг 1: Скачивание и установка OpenSearch

Установка OpenSearch из пакета

Скачайте Debian-пакет для желаемой версии непосредственно с страницы загрузок OpenSearch. Debian-пакет можно скачать как для архитектуры x64, так и для arm64.

Из командной строки установите пакет с помощью dpkg:

Для новых установок OpenSearch 2.12 и более поздних версий необходимо определить пользовательский пароль администратора для настройки демо-конфигурации безопасности. Используйте одну из следующих команд для определения пользовательского пароля администратора:

# x64
sudo env OPENSEARCH_INITIAL_ADMIN_PASSWORD=<custom-admin-password> dpkg -i opensearch-3.1.0-linux-x64.deb

# arm64
sudo env OPENSEARCH_INITIAL_ADMIN_PASSWORD=<custom-admin-password> dpkg -i opensearch-3.1.0-linux-arm64.deb

Используйте следующую команду для версий OpenSearch 2.11 и более ранних:

# x64
sudo dpkg -i opensearch-3.1.0-linux-x64.deb

# arm64
sudo dpkg -i opensearch-3.1.0-linux-arm64.deb

После успешной установки включите OpenSearch как службу:

sudo systemctl enable opensearch

Запустите службу OpenSearch:

sudo systemctl start opensearch

Проверьте, что OpenSearch запустился корректно:

sudo systemctl status opensearch

Проверка отпечатка

Debian-пакет не подписан. Если вы хотите проверить отпечаток, проект OpenSearch предоставляет файл .sig, а также пакет .deb для использования с GNU Privacy Guard (GPG).

Скачайте желаемый Debian-пакет:

curl -SLO https://artifacts.opensearch.org/releases/bundle/opensearch/3.1.0/opensearch-3.1.0-linux-x64.deb

Скачайте соответствующий файл подписи:

curl -SLO https://artifacts.opensearch.org/releases/bundle/opensearch/3.1.0/opensearch-3.1.0-linux-x64.deb.sig

Скачайте и импортируйте GPG-ключ:

curl -o- https://artifacts.opensearch.org/publickeys/opensearch-release.pgp | gpg --import -

Проверьте подпись:

gpg --verify opensearch-3.1.0-linux-x64.deb.sig opensearch-3.1.0-linux-x64.deb

Установка OpenSearch из APT-репозитория

APT, основной инструмент управления пакетами для операционных систем на базе Debian, позволяет загружать и устанавливать Debian-пакет из APT-репозитория.

1. Установите необходимые пакеты:

sudo apt-get update && sudo apt-get -y install lsb-release ca-certificates curl gnupg2

2. Импортируйте публичный GPG-ключ. Этот ключ используется для проверки подписи APT-репозитория:

curl -o- https://artifacts.opensearch.org/publickeys/opensearch-release.pgp | sudo gpg --dearmor --batch --yes -o /usr/share/keyrings/opensearch-release-keyring

3. Создайте APT-репозиторий для OpenSearch:

echo "deb [signed-by=/usr/share/keyrings/opensearch-release-keyring] https://artifacts.opensearch.org/releases/bundle/opensearch/3.x/apt stable main" | sudo tee /etc/apt/sources.list.d/opensearch-3.x.list

4. Проверьте, что репозиторий был успешно создан:

sudo apt-get update

5. С добавленной информацией о репозитории перечислите все доступные версии OpenSearch:

sudo apt list -a opensearch

6. Выбор версии OpenSearch для установки

• Если не указано иное, будет установлена последняя доступная версия OpenSearch.

# Для новых установок OpenSearch 2.12 и более поздних версий необходимо определить пользовательский пароль администратора для настройки демо-конфигурации безопасности. 
# Используйте одну из следующих команд для определения пользовательского пароля:

sudo env OPENSEARCH_INITIAL_ADMIN_PASSWORD=<custom-admin-password> apt-get install opensearch

# Для версий OpenSearch 2.11 и более ранних используйте следующую команду:

sudo apt-get install opensearch

• Установка конкретной версии OpenSearch

# Чтобы установить конкретную версию OpenSearch, укажите версию вручную, используя `opensearch=<version>`:

# Для новых установок OpenSearch 2.12 и более поздних версий:

sudo env OPENSEARCH_INITIAL_ADMIN_PASSWORD=<custom-admin-password> apt-get install opensearch=3.1.0

# Для версий OpenSearch 2.11 и более ранних:

sudo apt-get install opensearch=3.1.0

7. Во время установки установщик предоставит вам отпечаток GPG-ключа. Убедитесь, что информация совпадает с указанной ниже:

Fingerprint: c5b7 4989 65ef d1c2 924b a9d5 39d3 1987 9310 d3fc

8. Проверьте, что отпечаток ключа соответствует ожидаемому значению, чтобы гарантировать целостность и подлинность пакета.

sudo systemctl enable opensearch

9. Запуск OpenSearch

Чтобы запустить OpenSearch, выполните следующую команду:

sudo systemctl start opensearch

10. Проверка статуса OpenSearch

После запуска проверьте, что OpenSearch запустился корректно, с помощью следующей команды:

sudo systemctl status opensearch

Шаг 2: (Необязательно) Тестирование OpenSearch

Перед тем как продолжить с любой конфигурацией, рекомендуется протестировать вашу установку OpenSearch. В противном случае может быть сложно определить, связаны ли будущие проблемы с установочными ошибками или с пользовательскими настройками, которые вы применили после установки.

Когда OpenSearch установлен с использованием Debian-пакета, некоторые демо-настройки безопасности автоматически применяются. Это включает в себя самоподписанные TLS-сертификаты и несколько пользователей и ролей. Если вы хотите настроить их самостоятельно, смотрите раздел Настройка OpenSearch в вашей среде.

Узел OpenSearch в своей стандартной конфигурации (с демо-сертификатами и пользователями с стандартными паролями) не подходит для производственной среды. Если вы планируете использовать узел в производственной среде, вам следует, как минимум, заменить демо TLS-сертификаты на ваши собственные и обновить список внутренних пользователей и паролей. Смотрите Конфигурация безопасности для получения дополнительной информации, чтобы убедиться, что ваши узлы настроены в соответствии с вашими требованиями безопасности.

Отправка запросов на сервер

Отправьте запросы на сервер, чтобы проверить, что OpenSearch работает. Обратите внимание на использование флага --insecure, который необходим, поскольку TLS-сертификаты самоподписаны.

Отправьте запрос на порт 9200:

curl -X GET https://localhost:9200 -u 'admin:<custom-admin-password>' --insecure

Ожидаемый ответ

Вы должны получить ответ, который выглядит примерно так:

{
    "name": "hostname",
    "cluster_name": "opensearch",
    "cluster_uuid": "QqgpHCbnSRKcPAizqjvoOw",
    "version": {
        "distribution": "opensearch",
        "number": <version>,
        "build_type": <build-type>,
        "build_hash": <build-hash>,
        "build_date": <build-date>,
        "build_snapshot": false,
        "lucene_version": <lucene-version>,
        "minimum_wire_compatibility_version": "7.10.0",
        "minimum_index_compatibility_version": "7.0.0"
    },
    "tagline": "The OpenSearch Project: https://opensearch.org/"
}

Запрос к конечной точке плагинов

Запросите конечную точку плагинов:

curl -X GET https://localhost:9200/_cat/plugins?v -u 'admin:<custom-admin-password>' --insecure

Этот запрос вернет список установленных плагинов, что также подтвердит, что OpenSearch работает корректно.

Ожидаемый ответ для запроса к конечной точке плагинов

Шаг 3: Настройка OpenSearch в вашей среде

Пользователи, не имеющие предварительного опыта работы с OpenSearch, могут захотеть получить список рекомендуемых настроек для начала работы с сервисом. По умолчанию OpenSearch не привязан к сетевому интерфейсу и не может быть доступен внешними хостами. Кроме того, настройки безопасности заполняются стандартными именами пользователей и паролями. Следующие рекомендации позволят пользователю привязать OpenSearch к сетевому интерфейсу, создать и подписать TLS-сертификаты, а также настроить базовую аутентификацию.

Рекомендуемые настройки

Следующие настройки позволят вам:

• Привязать OpenSearch к IP-адресу или сетевому интерфейсу на хосте.
• Установить начальные и максимальные размеры кучи JVM.
• Определить переменную окружения, указывающую на встроенный JDK.
• Настроить собственные TLS-сертификаты — сторонний центр сертификации (CA) не требуется.
• Создать администратора с пользовательским паролем.

Если вы запускали демо-скрипт безопасности, вам нужно будет вручную перенастроить настройки, которые были изменены. Обратитесь к Конфигурации безопасности для получения рекомендаций перед продолжением.

Перед внесением каких-либо изменений в конфигурационные файлы всегда полезно сохранить резервную копию. Резервный файл можно использовать для устранения любых проблем, вызванных неправильной конфигурацией.

1. Открытие файла opensearch.yml

Откройте файл opensearch.yml:

sudo vi /etc/opensearch/opensearch.yml

2. Добавление следующих строк

Добавьте следующие строки в файл:

# Привязать OpenSearch к правильному сетевому интерфейсу. Используйте 0.0.0.0
# для включения всех доступных интерфейсов или укажите IP-адрес,
# назначенный конкретному интерфейсу.
network.host: 0.0.0.0

# Если вы еще не настроили кластер, установите
# discovery.type в single-node, иначе проверки загрузки
# не пройдут, когда вы попытаетесь запустить службу.
discovery.type: single-node

# Если вы ранее отключили плагин безопасности в opensearch.yml,
# обязательно включите его снова. В противном случае вы можете пропустить эту настройку.
plugins.security.disabled: false

3. Сохраните изменения и закройте файл

4. Укажите начальные и максимальные размеры кучи JVM

• Откройте файл jvm.options:

vi /etc/opensearch/jvm.options

• Измените значения для начального и максимального размеров кучи. В качестве отправной точки вы должны установить эти значения на половину доступной системной памяти. Для выделенных хостов это значение можно увеличить в зависимости от ваших рабочих требований.

• Например, если у хост-машины 8 ГБ памяти, вы можете установить начальные и максимальные размеры кучи на 4 ГБ:

-Xms4g
-Xmx4g

• Сохраните изменения и закройте файл.

Настройка TLS

Сертификаты TLS обеспечивают дополнительную безопасность для вашего кластера, позволяя клиентам подтверждать личность хостов и шифровать трафик между клиентом и хостом. Для получения дополнительной информации обратитесь к разделам “Настройка сертификатов TLS” и “Генерация сертификатов”, которые включены в документацию по плагину безопасности. Для работы в среде разработки обычно достаточно самоподписанных сертификатов. Этот раздел проведет вас через основные шаги, необходимые для генерации собственных сертификатов TLS и их применения к вашему хосту OpenSearch.

1. Перейдите в директорию, где будут храниться сертификаты

cd /etc/opensearch

2. Удалите демонстрационные сертификаты

sudo rm -f *pem

3. Сгенерируйте корневой сертификат

Это то, что вы будете использовать для подписания других сертификатов.

# Создайте закрытый ключ для корневого сертификата
sudo openssl genrsa -out root-ca-key.pem 2048

# Используйте закрытый ключ для создания самоподписанного корневого сертификата. Обязательно
# замените аргументы, переданные в -subj, чтобы они отражали ваш конкретный хост.
sudo openssl req -new -x509 -sha256 -key root-ca-key.pem -subj "/C=CA/ST=ONTARIO/L=TORONTO/O=ORG/OU=UNIT/CN=ROOT" -out root-ca.pem -days 730

4. Создайте сертификат администратора

Этот сертификат используется для получения повышенных прав для выполнения административных задач, связанных с плагином безопасности.

# Создайте закрытый ключ для сертификата администратора
sudo openssl genrsa -out admin-key-temp.pem 2048

# Преобразуйте закрытый ключ в PKCS#8
sudo openssl pkcs8 -inform PEM -outform PEM -in admin-key-temp.pem -topk8 -nocrypt -v1 PBE-SHA1-3DES -out admin-key.pem

# Создайте запрос на подпись сертификата (CSR). Общим именем (CN) "A" можно пользоваться, так как этот сертификат
# используется для аутентификации повышенного доступа и не привязан к хосту.
sudo openssl req -new -key admin-key.pem -subj "/C=CA/ST=ONTARIO/L=TORONTO/O=ORG/OU=UNIT/CN=A" -out admin.csr

# Подпишите сертификат администратора с помощью корневого сертификата и закрытого ключа, которые вы создали ранее.
sudo openssl x509 -req -in admin.csr -CA root-ca.pem -CAkey root-ca-key.pem -CAcreateserial -sha256 -out admin.pem -days 730

5. Создайте закрытый ключ для сертификата узла

sudo openssl genrsa -out node1-key-temp.pem 2048

# Преобразуйте закрытый ключ в PKCS#8

sudo openssl pkcs8 -inform PEM -outform PEM -in node1-key-temp.pem -topk8 -nocrypt -v1 PBE-SHA1-3DES -out node1-key.pem

# Создайте CSR и замените аргументы, переданные в -subj, чтобы они отражали ваш конкретный хост

# Обратите внимание, что CN должен соответствовать DNS A записи для хоста — не используйте имя хоста.

sudo openssl req -new -key node1-key.pem -subj "/C=CA/ST=ONTARIO/L=TORONTO/O=ORG/OU=UNIT/CN=node1.dns.a-record" -out node1.csr

# Создайте файл расширений, который определяет SAN DNS имя для хоста

# Этот файл должен соответствовать DNS A записи хоста.

sudo sh -c 'echo subjectAltName=DNS:node1.dns.a-record > node1.ext'

# Подпишите сертификат узла с помощью корневого сертификата и закрытого ключа, которые вы создали ранее

sudo openssl x509 -req -in node1.csr -CA root-ca.pem -CAkey root-ca-key.pem -CAcreateserial -sha256 -out node1.pem -days 730 -extfile node1.ext

6. Удалите временные файлы, которые больше не нужны

sudo rm -f *temp.pem *csr *ext

7. Убедитесь, что оставшиеся сертификаты принадлежат пользователю opensearch

sudo chown opensearch:opensearch admin-key.pem admin.pem node1-key.pem node1.pem root-ca-key.pem root-ca.pem root-ca.srl

8. Добавьте эти сертификаты в opensearch.yml

Как описано в разделе “Генерация сертификатов”. Продвинутые пользователи также могут выбрать добавление настроек с помощью скрипта.

#! /bin/bash

# Before running this script, make sure to replace the CN in the 
# node's distinguished name with a real DNS A record.

echo "plugins.security.ssl.transport.pemcert_filepath: /etc/opensearch/node1.pem" | sudo tee -a /etc/opensearch/opensearch.yml
echo "plugins.security.ssl.transport.pemkey_filepath: /etc/opensearch/node1-key.pem" | sudo tee -a /etc/opensearch/opensearch.yml
echo "plugins.security.ssl.transport.pemtrustedcas_filepath: /etc/opensearch/root-ca.pem" | sudo tee -a /etc/opensearch/opensearch.yml
echo "plugins.security.ssl.http.enabled: true" | sudo tee -a /etc/opensearch/opensearch.yml
echo "plugins.security.ssl.http.pemcert_filepath: /etc/opensearch/node1.pem" | sudo tee -a /etc/opensearch/opensearch.yml
echo "plugins.security.ssl.http.pemkey_filepath: /etc/opensearch/node1-key.pem" | sudo tee -a /etc/opensearch/opensearch.yml
echo "plugins.security.ssl.http.pemtrustedcas_filepath: /etc/opensearch/root-ca.pem" | sudo tee -a /etc/opensearch/opensearch.yml
echo "plugins.security.allow_default_init_securityindex: true" | sudo tee -a /etc/opensearch/opensearch.yml
echo "plugins.security.authcz.admin_dn:" | sudo tee -a /etc/opensearch/opensearch.yml
echo "  - 'CN=A,OU=UNIT,O=ORG,L=TORONTO,ST=ONTARIO,C=CA'" | sudo tee -a /etc/opensearch/opensearch.yml
echo "plugins.security.nodes_dn:" | sudo tee -a /etc/opensearch/opensearch.yml
echo "  - 'CN=node1.dns.a-record,OU=UNIT,O=ORG,L=TORONTO,ST=ONTARIO,C=CA'" | sudo tee -a /etc/opensearch/opensearch.yml
echo "plugins.security.audit.type: internal_opensearch" | sudo tee -a /etc/opensearch/opensearch.yml
echo "plugins.security.enable_snapshot_restore_privilege: true" | sudo tee -a /etc/opensearch/opensearch.yml
echo "plugins.security.check_snapshot_restore_write_privileges: true" | sudo tee -a /etc/opensearch/opensearch.yml
echo "plugins.security.restapi.roles_enabled: [\"all_access\", \"security_rest_api_access\"]" | sudo tee -a /etc/opensearch/opensearch.yml

9. (Необязательно) Добавление доверия к самоподписанному корневому сертификату

# Скопируйте корневой сертификат в правильную директорию

sudo cp /etc/opensearch/root-ca.pem /etc/pki/ca-trust/source/anchors/

# Добавьте доверие

sudo update-ca-trust

Настройка пользователя

Пользователи определяются и аутентифицируются OpenSearch различными способами. Один из методов, который не требует дополнительной инфраструктуры на стороне сервера, — это ручная настройка пользователей в файле internal_users.yml. В следующих шагах объясняется, как добавить нового внутреннего пользователя и как заменить пароль по умолчанию для администратора с помощью скрипта.

1. Перейдите в директорию инструментов плагина безопасности

cd /usr/share/opensearch/plugins/opensearch-security/tools

2. Запустите hash.sh для генерации нового пароля

• Этот скрипт завершится с ошибкой, если путь к JDK не был определен.

# Пример вывода, если JDK не найден...
$ ./hash.sh
**************************************************************************
** Этот инструмент будет устаревшим в следующем крупном релизе OpenSearch **
** https://github.com/opensearch-project/security/issues/1755           **
**************************************************************************
which: no java in (/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/user/.local/bin:/home/user/bin)
WARNING: nor OPENSEARCH_JAVA_HOME nor JAVA_HOME is set, will use 
./hash.sh: line 35: java: command not found

• Объявите переменную окружения при вызове скрипта, чтобы избежать проблем

OPENSEARCH_JAVA_HOME=/usr/share/opensearch/jdk ./hash.sh

• Введите желаемый пароль на запросе и запомните хэш, который будет выведен

3. Откройте файл internal_users.yml

sudo vi /etc/opensearch/opensearch-security/internal_users.yml

4. Добавьте нового внутреннего пользователя и замените хэш внутри internal_users.yml на вывод, предоставленный hash.sh на шаге 2

Файл должен выглядеть примерно так:

---
# This is the internal user database
# The hash value is a bcrypt hash and can be generated with plugin/tools/hash.sh

_meta:
   type: "internalusers"
   config_version: 2

# Define your internal users here

admin:
   hash: "$2y$1EXAMPLEQqwS8TUcoEXAMPLEeZ3lEHvkEXAMPLERqjyh1icEXAMPLE."
   reserved: true
   backend_roles:
   - "admin"
   description: "Admin user"

user1:
   hash: "$2y$12$zoHpvTCRjjQr6h0PEaabueCaGam3/LDvT6rZZGDGMusD7oehQjw/O"
   reserved: false
   backend_roles: []
   description: "New internal user"

# Other users 
...

Применение изменений

Теперь, когда сертификаты TLS установлены, а демонстрационные пользователи были удалены или им были назначены новые пароли, последний шаг — применить изменения конфигурации. Этот последний шаг конфигурации требует вызова securityadmin.sh, пока OpenSearch работает на хосте.

Убедитесь, что OpenSearch запущен

OpenSearch должен быть запущен, чтобы securityadmin.sh мог применить изменения. Если вы внесли изменения в opensearch.yml, перезапустите OpenSearch:

sudo systemctl restart opensearch

Откройте отдельную сессию терминала на хосте и перейдите в директорию, содержащую securityadmin.sh

# Перейдите в правильную директорию
cd /usr/share/opensearch/plugins/opensearch-security/tools

Вызовите скрипт

Смотрите раздел “Применение изменений с помощью securityadmin.sh” для определения аргументов, которые вы должны передать.

# Вы можете опустить переменную окружения, если вы объявили ее в вашем $PATH.
OPENSEARCH_JAVA_HOME=/usr/share/opensearch/jdk ./securityadmin.sh -cd /etc/opensearch/opensearch-security/ -cacert /etc/opensearch/root-ca.pem -cert /etc/opensearch/admin.pem -key /etc/opensearch/admin-key.pem -icl -nhnv

Параметры скрипта:

• -cd: указывает директорию конфигурации.
• -cacert: указывает путь к корневому сертификату.
• -cert: указывает путь к сертификату администратора.
• -key: указывает путь к закрытому ключу администратора.
• -icl: включает режим конфигурации.
• -nhnv: отключает проверку хоста и не выводит информацию о версии.

Проверка работы сервиса

OpenSearch теперь работает на вашем хосте с пользовательскими сертификатами TLS и безопасным пользователем для базовой аутентификации. Вы можете проверить внешнюю доступность, отправив API-запрос к вашему узлу OpenSearch с другого хоста.

Во время предыдущего теста вы направляли запросы на localhost. Теперь, когда сертификаты TLS были применены и новые сертификаты ссылаются на фактическую DNS-запись вашего хоста, запросы к localhost не пройдут проверку CN, и сертификат будет считаться недействительным. Вместо этого запросы должны быть отправлены на адрес, который вы указали при генерации сертификата.

Перед отправкой запросов вы должны добавить доверие к корневому сертификату на вашем клиенте. Если вы не добавите доверие, вам нужно будет использовать опцию -k, чтобы cURL игнорировал проверку CN и корневого сертификата.

$ curl https://your.host.address:9200 -u admin:yournewpassword -k
{
   "name":"hostname",
   "cluster_name":"opensearch",
   "cluster_uuid":"QqgpHCbnSRKcPAizqjvoOw",
   "version":{
      "distribution":"opensearch",
      "number":<version>,
      "build_type":<build-type>,
      "build_hash":<build-hash>,
      "build_date":<build-date>,
      "build_snapshot":false,
      "lucene_version":<lucene-version>,
      "minimum_wire_compatibility_version":"7.10.0",
      "minimum_index_compatibility_version":"7.0.0"
   },
   "tagline":"The OpenSearch Project: https://opensearch.org/"
}

Обновление до новой версии

Экземпляры OpenSearch, установленные с помощью dpkg или apt-get, можно легко обновить до более новой версии.

Ручное обновление с помощью DPKG

Скачайте Debian-пакет для желаемой версии обновления непосредственно со страницы загрузок OpenSearch Project.

Перейдите в директорию, содержащую дистрибутив, и выполните следующую команду:

sudo dpkg -i opensearch-3.1.0-linux-x64.deb

Обновление с помощью APT-GET

Чтобы обновить до последней версии OpenSearch с помощью apt-get, выполните:

sudo apt-get upgrade opensearch

Вы также можете обновить до конкретной версии OpenSearch:

sudo apt-get upgrade opensearch=<version>

Автоматическая перезагрузка сервиса после обновления пакета (2.13.0+)

Чтобы автоматически перезапустить OpenSearch после обновления пакета, включите opensearch.service через systemd:

sudo systemctl enable opensearch.service

2.2 - Установка OpenSearch Dashboards

OpenSearch Dashboards предоставляет полностью интегрированное решение для визуального изучения, обнаружения и запроса ваших данных наблюдаемости. Вы можете установить OpenSearch Dashboards с помощью одного из следующих вариантов:

• Docker
• Tarball
• RPM
• Debian
• Helm
• Windows

Совместимость с браузерами

OpenSearch Dashboards поддерживает следующие веб-браузеры:

• Chrome
• Firefox
• Safari
• Edge (Chromium)

Другие браузеры на основе Chromium также могут работать. Internet Explorer и Microsoft Edge Legacy не поддерживаются.

Совместимость с Node.js

OpenSearch Dashboards требует бинарный файл среды выполнения Node.js для работы. Один из них включен в дистрибутивные пакеты, доступные на странице загрузок OpenSearch.

OpenSearch Dashboards версии 2.8.0 и новее могут использовать версии Node.js 14, 16 и 18. Дистрибутивные пакеты для OpenSearch Dashboards версии 2.10.0 и новее включают Node.js 18 и 14 (для обратной совместимости).

Чтобы использовать бинарный файл среды выполнения Node.js, отличный от включенных в дистрибутивные пакеты, выполните следующие шаги:

1. Скачайте и установите Node.js; совместимые версии: >=14.20.1 <19.

2. Установите путь установки в переменные окружения NODE_HOME или NODE_OSD_HOME.

   • На UNIX, если Node.js установлен в /usr/local/nodejs, а бинарный файл среды выполнения находится по пути /usr/local/nodejs/bin/node:

     export NODE_HOME=/usr/local/nodejs
     

   • Если Node.js установлен с помощью NVM, а бинарный файл среды выполнения находится по пути /Users/user/.nvm/versions/node/v18.19.0/bin/node:

     export NODE_HOME=/Users/user/.nvm/versions/node/v18.19.0
     # или, если NODE_HOME используется для чего-то другого:
     export NODE_OSD_HOME=/Users/user/.nvm/versions/node/v18.19.0
     

   • На Windows, если Node.js установлен в C:\Program Files\nodejs, а бинарный файл среды выполнения находится по пути C:\Program Files\nodejs\node.exe:

     set "NODE_HOME=C:\Program Files\nodejs"
     # или с использованием PowerShell:
     $Env:NODE_HOME = 'C:\Program Files\nodejs'
     

3. Ознакомьтесь с документацией вашей операционной системы, чтобы внести постоянные изменения в переменные окружения.

Скрипт запуска OpenSearch Dashboards, bin/opensearch-dashboards, ищет бинарный файл среды выполнения Node.js, используя NODE_OSD_HOME, затем NODE_HOME, прежде чем использовать бинарные файлы, включенные в дистрибутивные пакеты. Если подходящий бинарный файл среды выполнения Node.js не найден, скрипт запуска попытается найти его в системном PATH, прежде чем завершить работу с ошибкой.

Конфигурация

Чтобы узнать, как настроить TLS для OpenSearch Dashboards, смотрите раздел Настройка TLS.

2.2.1 - Запуск OpenSearch Dashboards с использованием Docker

1. Выполните команду для загрузки образа OpenSearch Dashboards:

   docker pull opensearchproject/opensearch-dashboards:2
   

2. Создайте файл docker-compose.yml, соответствующий вашей среде. Пример файла, который включает OpenSearch Dashboards, доступен на странице установки OpenSearch Docker.

3. Так же, как и для opensearch.yml, вы можете передать пользовательский файл opensearch_dashboards.yml в контейнер в файле Docker Compose.

4. Запустите команду:

   docker compose up
   

5. Подождите, пока контейнеры запустятся. Затем ознакомьтесь с документацией OpenSearch Dashboards.

6. Когда закончите, выполните команду:

   docker compose down
   

2.2.2 - Установка OpenSearch Dashboards (Debian)

Установка OpenSearch Dashboards с использованием менеджера пакетов Advanced Packaging Tool (APT) значительно упрощает процесс по сравнению с методом Tarball. Например, менеджер пакетов обрабатывает несколько технических аспектов, таких как путь установки, расположение конфигурационных файлов и создание службы, управляемой systemd.

Перед установкой OpenSearch Dashboards необходимо настроить кластер OpenSearch. Обратитесь к руководству по установке OpenSearch для Debian для получения инструкций.

Данное руководство предполагает, что вы уверенно работаете с интерфейсом командной строки (CLI) Linux. Вы должны понимать, как вводить команды, перемещаться между директориями и редактировать текстовые файлы. Некоторые примеры команд ссылаются на текстовый редактор vi, но вы можете использовать любой доступный текстовый редактор.

Установка OpenSearch Dashboards из пакета

1. Скачайте пакет Debian для нужной версии непосредственно с страницы загрузок OpenSearch. Пакет Debian доступен для архитектур x64 и arm64.

2. Установите пакет с помощью dpkg из командной строки:

   • Для x64:

     sudo dpkg -i opensearch-dashboards-3.1.0-linux-x64.deb
     

   • Для arm64:

     sudo dpkg -i opensearch-dashboards-3.1.0-linux-arm64.deb
     

3. После завершения установки перезагрузите конфигурацию менеджера systemd:

   sudo systemctl daemon-reload
   

4. Включите OpenSearch как службу:

   sudo systemctl enable opensearch-dashboards
   

5. Запустите службу OpenSearch:

   sudo systemctl start opensearch-dashboards
   

6. Проверьте, что OpenSearch запустился корректно:

   sudo systemctl status opensearch-dashboards
   

Проверка подписи

Пакет Debian не подписан. Если вы хотите проверить подпись, проект OpenSearch предоставляет файл .sig, а также .deb пакет для использования с GNU Privacy Guard (GPG).

1. Скачайте нужный пакет Debian:

   curl -SLO https://artifacts.opensearch.org/releases/bundle/opensearch-dashboards/3.1.0/opensearch-dashboards-3.1.0-linux-x64.deb
   

2. Скачайте соответствующий файл подписи:

   curl -SLO https://artifacts.opensearch.org/releases/bundle/opensearch-dashboards/3.1.0/opensearch-dashboards-3.1.0-linux-x64.deb.sig
   

3. Скачайте и импортируйте GPG-ключ:

   curl -o- https://artifacts.opensearch.org/publickeys/opensearch-release.pgp | gpg --import -
   

4. Проверьте подпись:

   gpg --verify opensearch-dashboards-3.1.0-linux-x64.deb.sig opensearch-dashboards-3.1.0-linux-x64.deb
   

Установка OpenSearch Dashboards из репозитория APT

APT, основной инструмент управления пакетами для операционных систем на базе Debian, позволяет загружать и устанавливать пакет Debian из репозитория APT.

1. Установите необходимые пакеты:

   sudo apt-get update && sudo apt-get -y install lsb-release ca-certificates curl gnupg2
   

2. Импортируйте публичный GPG-ключ. Этот ключ используется для проверки подписи репозитория APT:

   curl -o- https://artifacts.opensearch.org/publickeys/opensearch-release.pgp | sudo gpg --dearmor --batch --yes -o /usr/share/keyrings/opensearch-release-keyring
   

3. Создайте репозиторий APT для OpenSearch:

   echo "deb [signed-by=/usr/share/keyrings/opensearch-release-keyring] https://artifacts.opensearch.org/releases/bundle/opensearch-dashboards/3.x/apt stable main" | sudo tee /etc/apt/sources.list.d/opensearch-dashboards-3.x.list
   

4. Проверьте, что репозиторий был успешно создан:

   sudo apt-get update
   

5. С добавленной информацией о репозитории, перечислите все доступные версии OpenSearch:

   sudo apt list -a opensearch-dashboards
   

6. Выберите версию OpenSearch, которую хотите установить:

   • Если не указано иное, будет установлена последняя доступная версия OpenSearch:

     sudo apt-get install opensearch-dashboards
     

   • Чтобы установить конкретную версию OpenSearch Dashboards, укажите номер версии после имени пакета:

     # Укажите версию вручную с помощью opensearch=<version>
     sudo apt-get install opensearch-dashboards=3.1.0
     

7. После завершения установки включите OpenSearch:

   sudo systemctl enable opensearch-dashboards
   

8. Запустите OpenSearch:

   sudo systemctl start opensearch-dashboards
   

9. Проверьте, что OpenSearch запустился корректно:

   sudo systemctl status opensearch-dashboards
   

Изучение OpenSearch Dashboards

По умолчанию OpenSearch Dashboards, как и OpenSearch, связывается с localhost при первоначальной установке. В результате OpenSearch Dashboards недоступен с удаленного хоста, если конфигурация не обновлена.

1. Откройте файл opensearch_dashboards.yml:

   sudo vi /etc/opensearch-dashboards/opensearch_dashboards.yml
   

2. Укажите сетевой интерфейс, к которому должен связываться OpenSearch Dashboards:

   # Используйте 0.0.0.0, чтобы связаться с любым доступным интерфейсом.
   server.host: 0.0.0.0
   

3. Сохраните изменения и выйдите из редактора.

4. Перезапустите OpenSearch Dashboards, чтобы применить изменения конфигурации:

   sudo systemctl restart opensearch-dashboards
   

5. В веб-браузере перейдите к OpenSearch Dashboards. Порт по умолчанию — 5601.

6. Войдите с использованием имени пользователя admin и пароля admin. (Для OpenSearch 2.12 и новее пароль должен быть пользовательским паролем администратора.)

7. Посетите раздел “Начало работы с OpenSearch Dashboards”, чтобы узнать больше.

Обновление до новой версии

Экземпляры OpenSearch Dashboards, установленные с помощью dpkg или apt-get, можно легко обновить до новой версии.

Ручное обновление с помощью DPKG

1. Скачайте пакет Debian для желаемой версии обновления непосредственно со страницы загрузок проекта OpenSearch.

2. Перейдите в директорию, содержащую дистрибутив, и выполните следующую команду:

   sudo dpkg -i opensearch-dashboards-3.1.0-linux-x64.deb
   

Обновление с помощью APT-GET

Чтобы обновить до последней версии OpenSearch Dashboards с помощью apt-get, выполните следующую команду:

sudo apt-get upgrade opensearch-dashboards

Вы также можете обновить до конкретной версии OpenSearch Dashboards, указав номер версии:

sudo apt-get upgrade opensearch-dashboards=<version>

Автоматический перезапуск службы после обновления пакета (2.13.0+)

Чтобы автоматически перезапустить OpenSearch Dashboards после обновления пакета, включите службу opensearch-dashboards.service через systemd:

sudo systemctl enable opensearch-dashboards.service

2.2.3 - Настройка TLS для OpenSearch Dashboards

Пример конфигурации opensearch_dashboards.yml

Следующая конфигурация opensearch_dashboards.yml показывает, как OpenSearch и OpenSearch Dashboards могут работать на одной машине с демонстрационной конфигурацией:

server.host: '0.0.0.0'
server.ssl.enabled: true
server.ssl.certificate: /usr/share/opensearch-dashboards/config/client-cert.pem
server.ssl.key: /usr/share/opensearch-dashboards/config/client-cert-key.pem
opensearch.hosts: ["https://localhost:9200"]
opensearch.ssl.verificationMode: full
opensearch.ssl.certificateAuthorities: [ "/usr/share/opensearch-dashboards/config/root-ca.pem", "/usr/share/opensearch-dashboards/config/intermediate-ca.pem" ]
opensearch.username: "kibanaserver"
opensearch.password: "kibanaserver"
opensearch.requestHeadersAllowlist: [ authorization,securitytenant ]
opensearch_security.multitenancy.enabled: true
opensearch_security.multitenancy.tenants.preferred: ["Private", "Global"]
opensearch_security.readonly_mode.roles: ["kibana_read_only"]
opensearch_security.cookie.secure: true

Если вы используете опцию установки через Docker, вы можете передать пользовательский файл opensearch_dashboards.yml в контейнер. Чтобы узнать больше, посетите страницу установки Docker.

После включения этих настроек и запуска приложения вы можете подключиться к OpenSearch Dashboards по адресу https://localhost:5601. Возможно, вам потребуется подтвердить предупреждение браузера, если ваши сертификаты самоподписанные. Чтобы избежать такого предупреждения (или полной несовместимости с браузером), рекомендуется использовать сертификаты от доверенного центра сертификации (CA).

2.3 - configuring opensearch

Динамические настройки

Динамические настройки индекса — это настройки, которые вы можете обновлять в любое время. Вы можете настраивать динамические параметры OpenSearch через API настроек кластера. Для получения подробной информации смотрите раздел Обновление настроек кластера с помощью API.

При возможности используйте API настроек кластера; файл opensearch.yml локален для каждого узла, в то время как API применяет настройки ко всем узлам в кластере.

Статические настройки

Некоторые операции являются статическими и требуют изменения конфигурационного файла opensearch.yml и перезапуска кластера. В общем, эти настройки относятся к сетевым параметрам, формированию кластера и локальной файловой системе. Чтобы узнать больше, смотрите раздел Формирование кластера.

Указание настроек в виде переменных окружения

Вы можете указывать переменные окружения следующими способами:

Аргументы при запуске

Вы можете указать переменные окружения в качестве аргументов, используя -E при запуске OpenSearch:

./opensearch -Ecluster.name=opensearch-cluster -Enode.name=opensearch-node1 -Ehttp.host=0.0.0.0 -Ediscovery.type=single-node

Непосредственно в среде оболочки

Вы можете настроить переменные окружения непосредственно в среде оболочки перед запуском OpenSearch, как показано в следующем примере:

export OPENSEARCH_JAVA_OPTS="-Xms2g -Xmx2g"
export OPENSEARCH_PATH_CONF="/etc/opensearch"
./opensearch

Файл службы systemd

При запуске OpenSearch как службы, управляемой systemd, вы можете указать переменные окружения в файле службы, как показано в следующем примере:

# /etc/systemd/system/opensearch.service.d/override.conf
[Service]
Environment="OPENSEARCH_JAVA_OPTS=-Xms2g -Xmx2g"
Environment="OPENSEARCH_PATH_CONF=/etc/opensearch"

После создания или изменения файла перезагрузите конфигурацию systemd и перезапустите службу с помощью следующих команд:

sudo systemctl daemon-reload
sudo systemctl restart opensearch

Переменные окружения Docker

При запуске OpenSearch в Docker вы можете указать переменные окружения, используя опцию -e с командой docker run, как показано в следующей команде:

docker run -e "OPENSEARCH_JAVA_OPTS=-Xms2g -Xmx2g" -e "OPENSEARCH_PATH_CONF=/usr/share/opensearch/config" opensearchproject/opensearch:latest

Обновление настроек кластера с помощью API

Первый шаг в изменении настройки — это просмотр текущих настроек, отправив следующий запрос:

GET _cluster/settings?include_defaults=true

Для более краткого резюме нестандартных настроек отправьте следующий запрос:

GET _cluster/settings

В API настроек кластера существуют три категории настроек: постоянные, временные и стандартные. Постоянные настройки сохраняются после перезапуска кластера. После перезапуска OpenSearch очищает временные настройки.

Если вы указываете одну и ту же настройку в нескольких местах, OpenSearch использует следующий порядок приоритета:

1. Временные настройки
2. Постоянные настройки
3. Настройки из opensearch.yml
4. Стандартные настройки

Чтобы изменить настройку, используйте API настроек кластера и укажите новое значение как постоянное или временное. Этот пример показывает форму плоских настроек:

PUT _cluster/settings
{
  "persistent" : {
    "action.auto_create_index" : false
  }
}

Вы также можете использовать расширенную форму, которая позволяет вам копировать и вставлять из ответа GET и изменять существующие значения:

PUT _cluster/settings
{
  "persistent": {
    "action": {
      "auto_create_index": false
    }
  }
}

Конфигурационный файл

Вы можете найти файл opensearch.yml по следующему пути:

• Для Docker: /usr/share/opensearch/config/opensearch.yml
• Для большинства дистрибутивов Linux: /etc/opensearch/opensearch.yml

Вы можете отредактировать переменную OPENSEARCH_PATH_CONF=/etc/opensearch, чтобы изменить расположение каталога конфигурации. Эта переменная берется из /etc/default/opensearch (для Debian-пакета) и /etc/sysconfig/opensearch (для RPM-пакета).

Если вы установите свою пользовательскую переменную OPENSEARCH_PATH_CONF, имейте в виду, что другие стандартные переменные окружения не будут загружены.

В файле opensearch.yml вы не помечаете настройки как постоянные или временные, и настройки используют плоскую форму:

cluster.name: my-application
action.auto_create_index: true
compatibility.override_main_response_version: true

Демонстрационная конфигурация включает в себя ряд настроек для плагина безопасности, которые вы должны изменить перед использованием OpenSearch для производственной нагрузки. Чтобы узнать больше, смотрите раздел Безопасность.

(Необязательно) Конфигурация заголовков CORS

Если вы работаете над клиентским приложением, которое взаимодействует с кластером OpenSearch на другом домене, вы можете настроить заголовки в opensearch.yml, чтобы разрешить разработку локального приложения на той же машине. Используйте механизм Cross Origin Resource Sharing (CORS), чтобы ваше приложение могло делать вызовы к API OpenSearch, работающему локально. Добавьте следующие строки в ваш файл custom-opensearch.yml (обратите внимание, что символ “-” должен быть первым символом в каждой строке):

- http.host: 0.0.0.0
- http.port: 9200
- http.cors.allow-origin: "http://localhost"
- http.cors.enabled: true
- http.cors.allow-headers: X-Requested-With,X-Auth-Token,Content-Type,Content-Length,Authorization
- http.cors.allow-credentials: true

2.3.1 - Настройки доступности и восстановления

• Снимки
• Ограничение задач менеджера кластера
• Хранение с удаленной поддержкой
• Обратное давление при поиске
• Обратное давление при индексации шардов
• Репликация сегментов
• Репликация между кластерами

Чтобы узнать больше о статических и динамических настройках, см. Настройка OpenSearch.

Настройки снимков

OpenSearch поддерживает следующие настройки снимков:

• snapshot.max_concurrent_operations (Динамическое, целое число): Максимальное количество одновременных операций снимков. По умолчанию 1000.

Настройки снимков, связанные с безопасностью

Для настроек снимков, связанных с безопасностью, см. Настройки безопасности.

Настройки файловой системы

Для получения информации о настройках файловой системы см. Общая файловая система.

Настройки Amazon S3

Для получения информации о настройках репозитория Amazon S3 см. Amazon S3.

Настройки ограничения задач менеджера кластера

Для получения информации о настройках ограничения задач менеджера кластера см. Установка пределов ограничения.

Настройки хранения с удаленной поддержкой

OpenSearch поддерживает следующие настройки хранения с удаленной поддержкой на уровне кластера:

• cluster.remote_store.translog.buffer_interval (Динамическое, единица времени): Значение по умолчанию для интервала буфера транзакционного лога, используемого при выполнении периодических обновлений транзакционного лога. Эта настройка эффективна только в том случае, если настройка индекса index.remote_store.translog.buffer_interval отсутствует.

• remote_store.moving_average_window_size (Динамическое, целое число): Размер окна скользящего среднего, используемый для расчета значений скользящей статистики, доступных через API статистики удаленного хранилища. По умолчанию 20. Минимально допустимое значение - 5.

Для получения дополнительной информации о настройках хранения с удаленной поддержкой см. Хранение с удаленной поддержкой и Настройка хранения с удаленной поддержкой.

Для получения информации о настройках обратного давления сегментов см. Настройки обратного давления сегментов.

Настройки обратного давления при поиске

Обратное давление при поиске - это механизм, используемый для выявления ресурсоемких запросов на поиск и их отмены, когда узел испытывает нагрузку. Для получения дополнительной информации см. Настройки обратного давления при поиске.

Настройки обратного давления при индексации шардов

Обратное давление при индексации шардов - это механизм умного отклонения на уровне шардов, который динамически отклоняет запросы на индексацию, когда ваш кластер испытывает нагрузку. Для получения дополнительной информации см. Настройки обратного давления при индексации шардов.

Настройки репликации сегментов

Для получения информации о настройках репликации сегментов см. Репликация сегментов.

Для получения информации о настройках обратного давления репликации сегментов см. Обратное давление репликации сегментов.

Настройки репликации между кластерами

Для получения информации о настройках репликации между кластерами см. Настройки репликации.

2.3.2 - Конфигурация и системные настройки

Для получения обзора создания кластера OpenSearch и примеров настроек конфигурации см. раздел Создание кластера. Чтобы узнать больше о статических и динамических настройках, см. раздел Настройка OpenSearch.

OpenSearch поддерживает следующие системные настройки:

• cluster.name (Статическая, строка): Имя кластера.

• node.name (Статическая, строка): Описательное имя для узла.

• node.roles (Статическая, список): Определяет одну или несколько ролей для узла OpenSearch. Допустимые значения: cluster_manager, data, ingest, search, ml, remote_cluster_client и coordinating_only.

• path.data (Статическая, строка): Путь к директории, где хранятся ваши данные. Разделяйте несколько местоположений запятыми.

• path.logs (Статическая, строка): Путь к файлам журналов.

• bootstrap.memory_lock (Статическая, логическое): Блокирует память при запуске. Рекомендуется установить размер кучи примерно на половину доступной памяти в системе и убедиться, что владелец процесса имеет право использовать этот лимит. OpenSearch работает неэффективно, когда система использует свопинг памяти.

2.3.3 - Сетевые настройки

Чтобы узнать больше о статических и динамических настройках, см. раздел Настройка OpenSearch.

OpenSearch поддерживает следующие общие сетевые настройки:

• network.host (Статическая, список): Привязывает узел OpenSearch к адресу. Используйте 0.0.0.0, чтобы включить все доступные сетевые интерфейсы, или укажите IP-адрес, назначенный конкретному интерфейсу. Настройка network.host является комбинацией network.bind_host и network.publish_host, если они имеют одинаковое значение. Альтернативой network.host является отдельная настройка network.bind_host и network.publish_host по мере необходимости. См. раздел Расширенные сетевые настройки.

• http.port (Статическая, одно значение или диапазон): Привязывает узел OpenSearch к пользовательскому порту или диапазону портов для HTTP-связи. Вы можете указать адрес или диапазон адресов. По умолчанию — 9200-9300.

• transport.port (Статическая, одно значение или диапазон): Привязывает узел OpenSearch к пользовательскому порту для связи между узлами. Вы можете указать адрес или диапазон адресов. По умолчанию — 9300-9400.

Расширенные сетевые настройки

OpenSearch поддерживает следующие расширенные сетевые настройки:

• network.bind_host (Статическая, список): Привязывает узел OpenSearch к адресу или адресам для входящих соединений. По умолчанию — значение из network.host.

• network.publish_host (Статическая, список): Указывает адрес или адреса, которые узел OpenSearch публикует для других узлов в кластере, чтобы они могли подключиться к нему.

Расширенные HTTP-настройки

OpenSearch поддерживает следующие расширенные сетевые настройки для HTTP-связи:

• http.host (Статическая, список): Устанавливает адрес узла OpenSearch для HTTP-связи. Настройка http.host является комбинацией http.bind_host и http.publish_host, если они имеют одинаковое значение. Альтернативой http.host является отдельная настройка http.bind_host и http.publish_host по мере необходимости.

• http.bind_host (Статическая, список): Указывает адрес или адреса, к которым узел OpenSearch привязывается для прослушивания входящих HTTP-соединений.

• http.publish_host (Статическая, список): Указывает адрес или адреса, которые узел OpenSearch публикует для других узлов для HTTP-связи.

• http.compression (Статическая, логическое): Включает поддержку сжатия с использованием Accept-Encoding, когда это применимо. Когда включен HTTPS, по умолчанию — false, в противном случае — true. Отключение сжатия для HTTPS помогает снизить потенциальные риски безопасности, такие как атаки BREACH. Чтобы включить сжатие для HTTPS-трафика, явно установите http.compression в true.

• http.max_header_size (Статическая, строка): Максимальный общий размер всех HTTP-заголовков, разрешенный в запросе. По умолчанию — 16KB.

Расширенные транспортные настройки

OpenSearch поддерживает следующие расширенные сетевые настройки для транспортной связи:

• transport.host (Статическая, список): Устанавливает адрес узла OpenSearch для транспортной связи. Настройка transport.host является комбинацией transport.bind_host и transport.publish_host, если они имеют одинаковое значение. Альтернативой transport.host является отдельная настройка transport.bind_host и transport.publish_host по мере необходимости.

• transport.bind_host (Статическая, список): Указывает адрес или адреса, к которым узел OpenSearch привязывается для прослушивания входящих транспортных соединений.

• transport.publish_host (Статическая, список): Указывает адрес или адреса, которые узел OpenSearch публикует для других узлов для транспортной связи.OpenSearch использует настройки HTTP для конфигурации связи с внешними клиентами через REST API и транспортные настройки для внутренней связи между узлами в OpenSearch.

Выбор транспорта

По умолчанию OpenSearch использует транспорт, предоставляемый модулем transport-netty4, который использует движок Netty 4 как для внутренней TCP-связи между узлами в кластере, так и для внешней HTTP-связи с клиентами. Эта связь полностью асинхронна и неблокирующая. В следующей таблице перечислены другие доступные плагины транспорта, которые могут использоваться взаимозаменяемо.

Установка

./bin/opensearch-plugin install transport-reactor-netty4

Конфигурация (с использованием opensearch.yml)

http.type: reactor-netty4
http.type: reactor-netty4-secure

2.3.4 - Настройки обнаружения и шлюза

Чтобы узнать больше о статических и динамических настройках, см. раздел Настройка OpenSearch.

Настройки обнаружения

Процесс обнаружения используется при формировании кластера. Он включает в себя обнаружение узлов и выбор узла-менеджера кластера. OpenSearch поддерживает следующие настройки обнаружения:

• discovery.seed_hosts (Статическая, список): Список хостов, которые выполняют обнаружение при запуске узла. По умолчанию список хостов: ["127.0.0.1", "[::1]"].

• discovery.seed_providers (Статическая, список): Указывает типы провайдеров начальных хостов, которые будут использоваться для получения адресов начальных узлов с целью запуска процесса обнаружения.

• discovery.type (Статическая, строка): По умолчанию OpenSearch формирует кластер с несколькими узлами. Установите discovery.type в single-node, чтобы сформировать кластер с одним узлом.

• cluster.initial_cluster_manager_nodes (Статическая, список): Список узлов, имеющих право быть узлами-менеджерами кластера, используемых для начальной загрузки кластера.

Настройки шлюза

Локальный шлюз хранит состояние кластера и данные шардов, которые используются при перезапуске кластера. OpenSearch поддерживает следующие настройки локального шлюза:

• gateway.recover_after_nodes (Статическая, целое число): После полного перезапуска кластера количество узлов, которые должны присоединиться к кластеру, прежде чем может начаться восстановление.

• gateway.recover_after_data_nodes (Статическая, целое число): После полного перезапуска кластера количество узлов данных, которые должны присоединиться к кластеру, прежде чем может начаться восстановление.

• gateway.expected_data_nodes (Статическая, целое число): Ожидаемое количество узлов данных, которые должны существовать в кластере. После того как ожидаемое количество узлов присоединится к кластеру, может начаться восстановление локальных шардов.

• gateway.recover_after_time (Статическая, значение времени): Количество времени, которое нужно подождать перед началом восстановления, если количество узлов данных меньше ожидаемого количества узлов данных.

2.3.5 - Настройки безопасности

Для полного списка файлов конфигурации плагина безопасности см. раздел Изменение файлов YAML.

Следующие разделы описывают настройки, связанные с безопасностью, в файле opensearch.yml. Вы можете найти opensearch.yml в <OPENSEARCH_HOME>/config/opensearch.yml. Чтобы узнать больше о статических и динамических настройках, см. раздел Настройка OpenSearch.

Общие настройки

Плагин безопасности поддерживает следующие общие настройки:

• plugins.security.nodes_dn (Статическая): Указывает список отличительных имен (DN), обозначающих другие узлы в кластере. Эта настройка поддерживает подстановочные знаки и регулярные выражения. Список DN также считывается из индекса безопасности, помимо конфигурации YAML, когда plugins.security.nodes_dn_dynamic_config_enabled установлено в true. Если эта настройка не настроена правильно, кластер не сможет сформироваться, так как узлы не смогут доверять друг другу, что приведет к следующей ошибке: “Аутентификация транспортного клиента больше не поддерживается”.

• plugins.security.nodes_dn_dynamic_config_enabled (Статическая): Актуально для сценариев использования кросс-кластера, где необходимо управлять разрешенными узлами DN без необходимости перезапускать узлы каждый раз, когда настраивается новый удаленный кросс-кластер. Установка nodes_dn_dynamic_config_enabled в true включает доступные для супер-администратора API для отличительных имен, которые предоставляют средства для динамического обновления или получения узлов DN. Эта настройка имеет эффект только если plugins.security.cert.intercluster_request_evaluator_class не установлено. По умолчанию — false.

• plugins.security.authcz.admin_dn (Статическая): Определяет DN сертификатов, к которым должны быть назначены административные привилегии. Обязательно.

• plugins.security.roles_mapping_resolution (Статическая): Определяет, как бэкенд-ролям сопоставляются роли безопасности. Поддерживаются следующие значения:

  • MAPPING_ONLY (По умолчанию): Сопоставления должны быть явно настроены в roles_mapping.yml.
  • BACKENDROLES_ONLY: Бэкенд-роли сопоставляются с ролями безопасности напрямую. Настройки в roles_mapping.yml не имеют эффекта.
  • BOTH: Бэкенд-роли сопоставляются с ролями безопасности как напрямую, так и через roles_mapping.yml.

• plugins.security.dls.mode (Статическая): Устанавливает режим оценки безопасности на уровне документа (DLS). По умолчанию — адаптивный. См. раздел Как установить режим оценки DLS.

• plugins.security.compliance.salt (Статическая): Соль, используемая при генерации хеш-значения для маскирования полей. Должна содержать не менее 32 символов. Разрешены только ASCII-символы. Необязательно.

• plugins.security.compliance.immutable_indices (Статическая): Документы в индексах, помеченных как неизменяемые, следуют парадигме “запись один раз, чтение много раз”. Документы, созданные в этих индексах, не могут быть изменены и, следовательно, являются неизменяемыми.

• config.dynamic.http.anonymous_auth_enabled (Статическая): Включает анонимную аутентификацию. Это приведет к тому, что все HTTP-аутентификаторы не будут вызывать запросы на аутентификацию. По умолчанию — false.

• http.detailed_errors.enabled (Статическая): Включает подробное сообщение об ошибке для REST-вызовов, выполненных против кластера OpenSearch. Если установлено в true, предоставляет root_cause вместе с кодом ошибки. По умолчанию — true.

Настройки API управления REST

Плагин безопасности поддерживает следующие настройки API управления REST:

• plugins.security.restapi.roles_enabled (Статическая): Включает доступ к API управления REST на основе ролей для указанных ролей. Роли разделяются запятой. По умолчанию — пустой список (ни одна роль не имеет доступа к API управления REST). См. раздел Контроль доступа для API.

• plugins.security.restapi.endpoints_disabled.. (Статическая): Отключает конкретные конечные точки и их HTTP-методы для ролей. Значения для этой настройки составляют массив HTTP-методов. Например: plugins.security.restapi.endpoints_disabled.all_access.ACTIONGROUPS: ["PUT","POST","DELETE"]. По умолчанию все конечные точки и методы разрешены. Существующие конечные точки включают ACTIONGROUPS, CACHE, CONFIG, ROLES, ROLESMAPPING, INTERNALUSERS, SYSTEMINFO, PERMISSIONSINFO и LICENSE. См. раздел Контроль доступа для API.

• plugins.security.restapi.password_validation_regex (Статическая): Указывает регулярное выражение для задания критериев для пароля при входе. Для получения дополнительной информации см. раздел Настройки пароля.

• plugins.security.restapi.password_validation_error_message (Статическая): Указывает сообщение об ошибке, которое отображается, когда пароль не проходит проверку. Эта настройка используется вместе с plugins.security.restapi.password_validation_regex.

• plugins.security.restapi.password_min_length (Статическая): Устанавливает минимальное количество символов для длины пароля при использовании оценщика силы пароля на основе баллов. По умолчанию — 8. Это также является минимальным значением. Для получения дополнительной информации см. раздел Настройки пароля.

• plugins.security.restapi.password_score_based_validation_strength (Статическая): Устанавливает порог для определения, является ли пароль сильным или слабым. Допустимые значения: fair, good, strong и very_strong. Эта настройка используется вместе с plugins.security.restapi.password_min_length.

• plugins.security.unsupported.restapi.allow_securityconfig_modification (Статическая): Включает использование методов PUT и PATCH для API конфигурации.

Расширенные настройки

Плагин безопасности поддерживает следующие расширенные настройки:

• plugins.security.authcz.impersonation_dn (Статическая): Включает подмену на уровне транспортного слоя. Это позволяет DN выдавать себя за других пользователей. См. раздел Подмена пользователей.

• plugins.security.authcz.rest_impersonation_user (Статическая): Включает подмену на уровне REST. Это позволяет пользователям выдавать себя за других пользователей. См. раздел Подмена пользователей.

• plugins.security.allow_default_init_securityindex (Статическая): При установке в true OpenSearch Security автоматически инициализирует индекс конфигурации с файлами из директории /config, если индекс не существует.

  Это будет использовать известные стандартные пароли. Используйте только в частной сети/окружении.

• plugins.security.allow_unsafe_democertificates (Статическая): При установке в true OpenSearch запускается с демонстрационными сертификатами. Эти сертификаты выданы только для демонстрационных целей.

  Эти сертификаты хорошо известны и, следовательно, небезопасны для использования в производственной среде. Используйте только в частной сети/окружении.

• plugins.security.system_indices.permission.enabled (Статическая): Включает функцию разрешений для системных индексов. При установке в true функция включена, и пользователи с разрешением на изменение ролей могут создавать роли, которые включают разрешения, предоставляющие доступ к системным индексам. При установке в false разрешение отключено, и только администраторы с административным сертификатом могут вносить изменения в системные индексы. По умолчанию разрешение установлено в false в новом кластере.

Настройки уровня эксперта

Настройки уровня эксперта должны настраиваться и развертываться только администратором, который полностью понимает данную функцию. Неправильное понимание функции может привести к рискам безопасности, неправильной работе плагина безопасности или потере данных.

Плагин безопасности поддерживает следующие настройки уровня эксперта:

• plugins.security.config_index_name (Статическая): Имя индекса, в котором .opendistro_security хранит свою конфигурацию.

• plugins.security.cert.oid (Статическая): Определяет идентификатор объекта (OID) сертификатов узлов сервера.

• plugins.security.cert.intercluster_request_evaluator_class (Статическая): Указывает реализацию org.opensearch.security.transport.InterClusterRequestEvaluator, которая используется для оценки межкластерных запросов. Экземпляры org.opensearch.security.transport.InterClusterRequestEvaluator должны реализовывать конструктор с одним аргументом, принимающим объект org.opensearch.common.settings.Settings.

• plugins.security.enable_snapshot_restore_privilege (Статическая): При установке в false эта настройка отключает восстановление снимков для обычных пользователей. В этом случае принимаются только запросы на восстановление снимков, подписанные административным TLS-сертификатом. При установке в true (по умолчанию) обычные пользователи могут восстанавливать снимки, если у них есть привилегии cluster:admin/snapshot/restore, indices:admin/create и indices:data/write/index.

  Снимок можно восстановить только в том случае, если он не содержит глобального состояния и не восстанавливает индекс .opendistro_security.

• plugins.security.check_snapshot_restore_write_privileges (Статическая): При установке в false дополнительные проверки индекса пропускаются. При установке по умолчанию в true попытки восстановить снимки оцениваются на наличие привилегий indices:admin/create и indices:data/write/index.

• plugins.security.cache.ttl_minutes (Статическая): Определяет, как долго кэш аутентификации будет действителен. Кэш аутентификации помогает ускорить аутентификацию, временно храня объекты пользователей, возвращаемые из бэкенда, чтобы плагин безопасности не требовал повторных запросов к ним. Установите значение в минутах. По умолчанию — 60. Отключите кэширование, установив значение в 0.

• plugins.security.disabled (Статическая): Отключает OpenSearch Security.

  Отключение этого плагина может подвергнуть вашу конфигурацию (включая пароли) публичному доступу.

• plugins.security.protected_indices.enabled (Статическая): Если установлено в true, включает защищенные индексы. Защищенные индексы более безопасны, чем обычные индексы. Эти индексы требуют роли для доступа, как и любой другой традиционный индекс, и требуют дополнительной роли для видимости. Эта настройка используется вместе с настройками plugins.security.protected_indices.roles и plugins.security.protected_indices.indices.

• plugins.security.protected_indices.roles (Статическая): Указывает список ролей, к которым пользователь должен быть сопоставлен для доступа к защищенным индексам.

• plugins.security.protected_indices.indices (Статическая): Указывает список индексов, которые следует пометить как защищенные. Эти индексы будут видны только пользователям, сопоставленным с ролями, указанными в plugins.security.protected_indices.roles. После выполнения этого требования пользователю все равно потребуется быть сопоставленным с традиционной ролью, используемой для предоставления разрешения на доступ к индексу.

• plugins.security.system_indices.enabled (Статическая): Если установлено в true, включает системные индексы. Системные индексы аналогичны индексу безопасности, за исключением того, что их содержимое не зашифровано. Индексы, настроенные как системные индексы, могут быть доступны либо супер-администратором, либо пользователем с ролью, включающей разрешение на системный индекс. Для получения дополнительной информации о системных индексах см. раздел Системные индексы.

• plugins.security.system_indices.indices (Статическая): Список индексов, которые будут использоваться как системные индексы. Эта настройка контролируется настройкой plugins.security.system_indices.enabled.

• plugins.security.allow_default_init_securityindex (Статическая): При установке в true устанавливает плагин безопасности в его стандартные настройки безопасности, если попытка создать индекс безопасности завершается неудачей при запуске OpenSearch. Стандартные настройки безопасности хранятся в YAML-файлах, находящихся в директории opensearch-project/security/config. По умолчанию — false.

• plugins.security.cert.intercluster_request_evaluator_class (Статическая): Класс, который будет использоваться для оценки межкластерной связи.

• plugins.security.enable_snapshot_restore_privilege (Статическая): Включает предоставление привилегии восстановления снимков. Необязательно. По умолчанию — true.

• plugins.security.check_snapshot_restore_write_privileges (Статическая): Обеспечивает оценку привилегий записи при создании снимков. По умолчанию — true.

Если вы измените любое из следующих свойств хеширования паролей, вам необходимо повторно хешировать все внутренние пароли для обеспечения совместимости и безопасности.

• plugins.security.password.hashing.algorithm (Статическая): Указывает алгоритм хеширования паролей, который следует использовать. Поддерживаются следующие значения:

  • BCrypt (По умолчанию)
  • PBKDF2
  • Argon2

• plugins.security.password.hashing.bcrypt.rounds (Статическая): Указывает количество раундов, используемых для хеширования паролей с помощью BCrypt. Допустимые значения находятся в диапазоне от 4 до 31, включая. По умолчанию — 12.

• plugins.security.password.hashing.bcrypt.minor (Статическая): Указывает минорную версию алгоритма BCrypt, используемую для хеширования паролей. Поддерживаются следующие значения:

  • A
  • B
  • Y (По умолчанию)

• plugins.security.password.hashing.pbkdf2.function (Статическая): Указывает псевдослучайную функцию, применяемую к паролю. Поддерживаются следующие значения:

  • SHA1
  • SHA224
  • SHA256 (По умолчанию)
  • SHA384
  • SHA512

• plugins.security.password.hashing.pbkdf2.iterations (Статическая): Указывает количество раз, которое псевдослучайная функция применяется к паролю. По умолчанию — 600,000.

• plugins.security.password.hashing.pbkdf2.length (Статическая): Указывает желаемую длину окончательного производного ключа. По умолчанию — 256.

• plugins.security.password.hashing.argon2.iterations (Статическая): Указывает количество проходов по памяти, которые выполняет алгоритм. Увеличение этого значения увеличивает время вычислений на ЦП и улучшает устойчивость к атакам грубой силы. По умолчанию — 3.

• plugins.security.password.hashing.argon2.memory (Статическая): Указывает количество памяти (в кибибайтах), используемой во время хеширования. По умолчанию — 65536 (64 МиБ).

• plugins.security.password.hashing.argon2.parallelism (Статическая): Указывает количество параллельных потоков, используемых для вычислений. По умолчанию — 1.

• plugins.security.password.hashing.argon2.length (Статическая): Указывает длину (в байтах) результирующего хеш-выхода. По умолчанию — 32.

• plugins.security.password.hashing.argon2.type (Статическая): Указывает, какой вариант Argon2 использовать. Поддерживаются следующие значения:

  • Argon2i
  • Argon2d
  • Argon2id (по умолчанию)

• plugins.security.password.hashing.argon2.version (Статическая): Указывает, какую версию Argon2 использовать. Поддерживаются следующие значения:

  • 16
  • 19 (по умолчанию)

Настройки журнала аудита

Плагин безопасности поддерживает следующие настройки журнала аудита:

• plugins.security.audit.enable_rest (Динамическая): Включает или отключает ведение журнала REST-запросов. По умолчанию установлено в true (включено).

• plugins.security.audit.enable_transport (Динамическая): Включает или отключает ведение журнала запросов на уровне транспорта. По умолчанию установлено в false (выключено).

• plugins.security.audit.resolve_bulk_requests (Динамическая): Включает или отключает ведение журнала пакетных запросов. При включении все подзапросы в пакетных запросах также записываются в журнал. По умолчанию установлено в false (выключено).

• plugins.security.audit.config.disabled_categories (Динамическая): Отключает указанные категории событий.

• plugins.security.audit.ignore_requests (Динамическая): Исключает указанные запросы из ведения журнала. Поддерживает подстановочные знаки и регулярные выражения, содержащие действия или пути REST-запросов.

• plugins.security.audit.threadpool.size (Статическая): Определяет количество потоков в пуле потоков, используемом для ведения журнала событий. По умолчанию установлено в 10. Установка этого значения в 0 отключает пул потоков, что означает, что плагин ведет журнал событий синхронно.

• plugins.security.audit.threadpool.max_queue_len (Статическая): Устанавливает максимальную длину очереди на поток. По умолчанию установлено в 100000.

• plugins.security.audit.ignore_users (Динамическая): Массив пользователей. Запросы аудита от пользователей в списке не будут записываться в журнал.

• plugins.security.audit.type (Статическая): Назначение событий журнала аудита. Допустимые значения: internal_opensearch, external_opensearch, debug и webhook.

• plugins.security.audit.config.http_endpoints (Статическая): Список конечных точек для localhost.

• plugins.security.audit.config.index (Статическая): Индекс журнала аудита. По умолчанию установлен auditlog6. Индекс может быть статическим или индексом, который включает дату, чтобы он вращался ежедневно, например, “‘auditlog6-‘YYYY.MM.dd”. В любом случае убедитесь, что индекс защищен должным образом.

• plugins.security.audit.config.type (Статическая): Укажите тип журнала аудита как auditlog.

• plugins.security.audit.config.username (Статическая): Имя пользователя для конфигурации журнала аудита.

• plugins.security.audit.config.password (Статическая): Пароль для конфигурации журнала аудита.

• plugins.security.audit.config.enable_ssl (Статическая): Включает или отключает SSL для ведения журнала аудита.

• plugins.security.audit.config.verify_hostnames (Статическая): Включает или отключает проверку имени хоста для SSL/TLS сертификатов. По умолчанию установлено в true (включено).

• plugins.security.audit.config.enable_ssl_client_auth (Статическая): Включает или отключает аутентификацию клиента SSL/TLS. По умолчанию установлено в false (выключено).

• plugins.security.audit.config.cert_alias (Статическая): Псевдоним для сертификата, используемого для доступа к журналу аудита.

• plugins.security.audit.config.pemkey_filepath (Статическая): Относительный путь к файлу ключа Privacy Enhanced Mail (PEM), используемого для ведения журнала аудита.

• plugins.security.audit.config.pemkey_content (Статическая): Содержимое PEM-ключа, закодированное в base64, используемого для ведения журнала аудита. Это альтернатива …config.pemkey_filepath.

• plugins.security.audit.config.pemkey_password (Статическая): Пароль для частного ключа в формате PEM, используемого клиентом.

• plugins.security.audit.config.pemcert_filepath (Статическая): Относительный путь к файлу PEM-сертификата, используемого для ведения журнала аудита.

• plugins.security.audit.config.pemcert_content (Статическая): Содержимое PEM-сертификата, закодированное в base64, используемого для ведения журнала аудита. Это альтернатива указанию пути к файлу с помощью …config.pemcert_filepath.

• plugins.security.audit.config.pemtrustedcas_filepath (Статическая): Относительный путь к файлу доверенного корневого центра сертификации.

• plugins.security.audit.config.pemtrustedcas_content (Статическая): Содержимое корневого центра сертификации, закодированное в base64. Это альтернатива …config.pemtrustedcas_filepath.

• plugins.security.audit.config.webhook.url (Статическая): URL вебхука.

• plugins.security.audit.config.webhook.format (Статическая): Формат, используемый для вебхука. Допустимые значения: URL_PARAMETER_GET, URL_PARAMETER_POST, TEXT, JSON и SLACK.

• plugins.security.audit.config.webhook.ssl.verify (Статическая): Включает или отключает проверку любых SSL/TLS сертификатов, отправленных с любым запросом вебхука. По умолчанию установлено в true (включено).

• plugins.security.audit.config.webhook.ssl.pemtrustedcas_filepath (Статическая): Относительный путь к файлу доверенного центра сертификации, против которого проверяются запросы вебхука.

• plugins.security.audit.config.webhook.ssl.pemtrustedcas_content (Статическая): Содержимое центра сертификации, используемого для проверки запросов вебхука, закодированное в base64. Это альтернатива …config.pemtrustedcas_filepath.

• plugins.security.audit.config.log4j.logger_name (Статическая): Пользовательское имя для логгера Log4j.

• plugins.security.audit.config.log4j.level (Статическая): Устанавливает уровень журнала по умолчанию для логгера Log4j. Допустимые значения: OFF, FATAL, ERROR, WARN, INFO, DEBUG, TRACE и ALL. По умолчанию установлено в INFO.

• opendistro_security.audit.config.disabled_rest_categories (Динамическая): Список категорий REST, которые будут игнорироваться логгером. Допустимые значения: AUTHENTICATED и GRANTED_PRIVILEGES.

• opendistro_security.audit.config.disabled_transport_categories (Динамическая): Список категорий на транспортном уровне, которые будут игнорироваться логгером. Допустимые значения: AUTHENTICATED и GRANTED_PRIVILEGES.