Как выглядит типичная модель развертывания ElasticSearch / Logstash / Kibana

Будучи новичком в мире докеров / эластичного поиска, я пытаюсь построить модель развертывания с использованием эластичного поиска через контейнеры в одном из моих проектов. У меня несколько серверов приложений, на каждом из которых есть журналы. Я хотел бы, чтобы все эти журналы были в одном месте. Ниже то, что у меня на уме.

Все серверы приложений устанавливают filebeat для отправки данных на сервер Logstash (в образе докера). Этот сервер LogStash пересылает эти журналы в образ докера elasticsearch, который также имеет кибану.

Имеет ли это смысл? Можно ли иметь logstash в одном образе, а ElasticSearch / Kibana - в другом? Есть ли у такого подхода плюсы / минусы? Какие могут быть альтернативные подходы к этому?


docker filebeat kibana
person BKS    schedule 12.02.2018    source источник
comment
У нас есть пример запуска и работы всего стека Elastic с Docker здесь github.com/elastic/stack- докер   -  person Tyler Smalley    schedule 13.02.2018

Ответы (1)


arrow_upward
2
arrow_downward

Политика Docker заключается в том, что 1 контейнер делает 1 вещь и 1 вещь хорошо. Поэтому я бы выбрал образ докера для ElasticSearch, 1 для Kibana и один для LogStash. Добавьте их вместе с помощью docker compose.

https://docs.docker.com/v17.09/engine/userguide/eng-image/dockerfile_best-practices/#use-multi-stage-builds

У каждого контейнера должна быть только одна проблема

Разделение приложений на несколько контейнеров значительно упрощает горизонтальное масштабирование и повторное использование контейнеров. Например, стек веб-приложения может состоять из трех отдельных контейнеров, каждый со своим уникальным изображением, для независимого управления веб-приложением, базой данных и кешем в памяти.

Возможно, вы слышали, что на контейнер должен быть «один процесс». Хотя у этой мантры есть добрые намерения, это не обязательно верно, что в каждом контейнере должен быть только один процесс операционной системы. В дополнение к тому факту, что контейнеры теперь могут быть созданы с помощью процесса инициализации, некоторые программы могут порождать дополнительные процессы сами по себе. Например, Celery может порождать несколько рабочих процессов, или Apache может создавать процесс для каждого запроса. Хотя «один процесс на контейнер» часто является хорошим практическим правилом, это не жесткое и быстрое правило. Следите за тем, чтобы контейнеры были чистыми и имели модульную конструкцию, насколько это возможно.

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

person Ivonet    schedule 12.02.2018
comment
Отредактировал свой ответ, чтобы добавить ссылку на одну проблему - person Ivonet; 12.02.2018