Проверка начальной загрузки

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

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

Существуют некоторые проверки начальной загрузки, которые всегда применяются, чтобы предотвратить запуск Elasticsearch с несовместимыми настройками. Эти проверки документированы отдельно.

По умолчанию Elasticsearch привязывается к адресам петли обратной связи для HTTP и транспортной (внутренней) связи. Это подходит для скачивания и работы с Elasticsearch, а также для повседневной разработки, но бесполезно для систем производства. Для присоединения к кластеру узел Elasticsearch должен быть доступен через транспортную связь. Для присоединения к кластеру по адресу, не являющемуся адресом петли обратной связи, узел должен привязать транспорт к адресу, не являющемуся адресом петли обратной связи, и не использовать обнаружение одного узла. Таким образом, мы считаем узел Elasticsearch находящимся в режиме разработки, если он не может сформировать кластер с другой машиной по адресу, не являющемуся адресом петли обратной связи, и в противном случае в режиме производства, если он может присоединиться к кластеру по адресам, не являющимся адресами петли обратной связи.

Обратите внимание, что HTTP и транспорт можно настроить независимо с помощью http.host и transport.host; это может быть полезно для настройки отдельного узла, доступного по HTTP для целей тестирования без запуска режима производства.

Мы понимаем, что некоторым пользователям необходимо привязать транспорт к внешнему интерфейсу для тестирования конфигурации удалённого кластера. Для этой ситуации мы предоставляем тип обнаружения single-node (настройте его, установив discovery.type на single-node); в этой ситуации узел выберет себя мастером и не присоединится к кластеру ни с каким другим узлом.

Если вы работаете с одним узлом в режиме производства, вы можете обойти проверки начальной загрузки (либо не привязывая транспорт к внешнему интерфейсу, либо привязав транспорт к внешнему интерфейсу и установив тип обнаружения на single-node). В этой ситуации вы можете принудительно выполнить проверки начальной загрузки, установив системную переменную es.enforce.bootstrap.checks на true в параметрах JVM. Мы настоятельно рекомендуем сделать это, если вы находитесь в этой конкретной ситуации. Эта системная переменная может использоваться для принудительного выполнения проверок начальной загрузки независимо от конфигурации узла.