Як розгорнути Meilisearch на власній інфраструктурі у 2026 році: master keys, індекси та dumps

Розгортання Meilisearch на власній інфраструктурі стає по-справжньому важливим під час першого повторного розгортання, а не після першого docker run. Якщо MEILI_ENV залишається development або data volume втрачається під час повторного розгортання, Docker усе одно може повідомляти про повністю справний процес. Наведене нижче розгортання побудоване навколо спостережуваної поведінки: створити індекс, імпортувати документи, налаштувати filterable attributes і перевірити, що typo-tolerant запит і фільтр повертають очікувані записи.

Призначення Meilisearch чітко визначене: повнотекстовий пошук із підтримкою помилок у словах через швидкий HTTP API. Цей опис показує, що має залишатися публічним, що слід тримати приватним і що саме має відновлювати backup.

Вивчіть Meilisearch перед тим, як торкатися Docker

Розділіть чотири аспекти Meilisearch: ingress, listener на 7700, durable state і supporting services або локальні ресурси. Локальна вимога до runtime — диск, розрахований на індекси, із запасом для rebuilds і dumps. Явно визначте його життєвий цикл, щоб перенесення Meilisearch між хостами непомітно не змінило поведінку.

Виконайте відому робочу транзакцію — створіть індекс, імпортуйте документи, налаштуйте filterable attributes і перевірте, що typo-tolerant запит і фільтр повертають очікувані записи, — перш ніж вважати це розділення завершеним. Виміряйте memory для batch indexing, тимчасовий disk під час index builds, кількість документів і concurrent search traffic та збережіть результат разом із записом про розгортання. Це дає і критерій приймання, і перший baseline продуктивності.

Зробіть запуск Meilisearch відтворюваним

Використовуйте команду, яка явно задає всі важливі параметри. Цей baseline прив’язує Meilisearch до loopback хоста, додає відомі data mounts і передає перше обов’язкове налаштування. Підтвердьте локальну вимогу до доступу: диск, розрахований на індекси, із запасом для rebuilds і dumps.

docker run -d \
  --name meilisearch \
  --restart unless-stopped \
  -p 127.0.0.1:7700:7700 \
  -v meilisearch-data:/meili_data \
  -e MEILI_MASTER_KEY=replace-with-a-long-random-value \
  getmeili/meilisearch:latest

Замініть floating tags на перевірену версію або digest. Після запуску перегляньте docker logs --tail 200 meilisearch і переконайтеся, що процес слухає порт 7700. Потім виконайте acceptance action для Meilisearch; відповідь root page не може підтвердити успішність усього сценарію: створіть індекс, імпортуйте документи, налаштуйте filterable attributes і перевірте, що typo-tolerant запит і фільтр повертають очікувані записи.

Задайте для Meilisearch одну canonical address

Розглядайте зовнішню URL-адресу Meilisearch як конфігурацію, яка має зберігатися після повторних розгортань. Спочатку надайте HTTP API через один authenticated HTTPS origin, а потім маршрутизуйте hostname на порт 7700, зберігаючи початкові host і scheme.

Checklist перевірки доступності розгортання допоможе підтвердити, що запити потрапляють у контейнер. Після цього відому проблему — MEILI_ENV залишається development або data volume втрачається під час повторного розгортання — слід досліджувати в Meilisearch, його state або workload, а не в автоматизації сертифікатів.

Відновіть Meilisearch на порожньому хості

Набір даних для надійного відновлення складається із запланованих dumps або snapshots і persistent data directory. Підключіть /meili_data до bootstrap, запишіть безпечні тестові дані й замініть контейнер, щоб перевірити, що цей шлях справді persistent. Volume захищає дані від заміни контейнера, але не від втрати хоста, випадкового видалення або corruption на рівні застосунку.

Створюйте backups із урахуванням джерела даних: за потреби використовуйте logical dumps для live databases, а файли копіюйте лише зі consistent state. Зберігайте одну encrypted копію окремо від хоста Meilisearch. Критерій приймання для restore має бути конкретним: dump імпортується на чистий сервер із тими самими settings, кількістю документів і representative ranking. У посібнику з backup, перевіреного відновленням пояснюється, чому одного лише успішного завершення job недостатньо.

Захистіть цінну частину Meilisearch

Не переносьте security assumptions із локального tutorial. Специфічна проблема Meilisearch — запуск production без master key. Тому в production master key слід використовувати для адміністративних операцій, а клієнтам браузерного пошуку надавати restricted search keys.

Поводьтеся з MEILI_MASTER_KEY відповідно до його ролі в Meilisearch: не зберігайте sensitive values у Git, документуйте наслідки rotation і ніколи не підставляйте public example у production. Обмежте filesystem і network access, захистіть setup endpoints і визначте upload, request або execution limits для memory під час batch indexing, тимчасового disk під час index builds, кількості документів і concurrent search traffic.

Слідкуйте за workload, а не лише за контейнером

Capacity tests мають перевіряти memory для batch indexing, тимчасовий disk під час index builds, кількість документів і concurrent search traffic, а не повторюваний запит до /. Виконайте сценарій «створити індекс, імпортувати документи, налаштувати filterable attributes і перевірити, що typo-tolerant запит і фільтр повертають очікувані записи» за реалістичної concurrency та зафіксуйте latency, error rate і зростання storage.

Під час планування оновлень потрібно врахувати такий ризик: перед зміною версій необхідно перевірити dump compatibility Meilisearch і вимоги до index rebuild. Протестуйте новий release на representative input, потім повторіть acceptance transaction і порівняйте результат. Якщо MEILI_ENV залишається development або data volume втрачається під час повторного розгортання, зафіксуйте транзакцію, що завершується помилкою, і перевірте першу залучену boundary, замість того щоб припускати, що проблема в ingress.

Перетворіть smoke test Meilisearch на release check

Для Meilisearch визначте відому робочу транзакцію до запуску: створіть індекс, імпортуйте документи, налаштуйте filterable attributes і перевірте, що typo-tolerant запит і фільтр повертають очікувані записи. Збережіть її prerequisites, очікувану response і кроки cleanup у version control без secret values. Зафіксуйте image, використаний для формування цього reference.

Використовуйте транзакцію для перевірки заміни та незалежного restore. Відновлений сервіс є прийнятним лише тоді, коли dump імпортується на чистий сервер із тими самими settings, кількістю документів і representative ranking. Водночас спостерігайте за memory під час batch indexing, тимчасовим disk під час index builds, кількістю документів і concurrent search traffic та перетворіть найповільнішу або найбільш обмежену частину на service-level alert.

Gate також має містити negative case: передайте безпечні тестові дані поблизу resource або format limit, пов’язаного з цією boundary: MEILI_ENV залишається development або data volume втрачається під час повторного розгортання. Переконайтеся, що Meilisearch генерує actionable error, зберігаючи дані, відновіть коректний стан і повторіть відому робочу транзакцію. Збереження обох результатів не дає поверхневому health endpoint стати єдиним production evidence.

Зберігайте конфігурацію Meilisearch явною, а маршрутизацію доручіть Dockup

One-click розгортання Meilisearch у Dockup має робити заміну безпечною: route і далі має вести на 7700, secrets не повинні бути вбудовані в image, а persistent paths мають з’являтися в новому контейнері. Те саме розгортання може працювати на Dockup compute або на підключеній машині.

Завершіть роботу, специфічну для застосунку, підтвердженням локальної вимоги — диска, розрахованого на індекси, із запасом для rebuilds і dumps, застосуванням canonical public address і виконанням цієї acceptance check: створіть індекс, імпортуйте документи, налаштуйте filterable attributes і перевірте, що typo-tolerant запит і фільтр повертають очікувані записи. Додайте результат restore до runbook до того, як з’являться реальні користувачі.

Поширені запитання

Що потрібно Meilisearch для production deployment?

Маршрутизуйте контейнер Meilisearch на порту 7700 через один HTTPS origin. Локальна вимога до runtime — диск, розрахований на індекси, із запасом для rebuilds і dumps. Не вважайте Meilisearch готовим, доки не зможете створити індекс, імпортувати документи, налаштувати filterable attributes і перевірити, що typo-tolerant запит і фільтр повертають очікувані записи.

Які дані Meilisearch мають входити до backup?

Зберігайте /meili_data і включайте scheduled dumps або snapshots разом із persistent data directory до одного recovery manifest. Чистий restore Meilisearch вважається успішним лише тоді, коли dump імпортується на чистий сервер із тими самими settings, кількістю документів і representative ranking.

Чи потрібен Meilisearch HTTPS за reverse proxy?

Використовуйте HTTPS для public Meilisearch origin, а порт 7700 залишайте у внутрішньому route. Правильно застосуйте налаштування Meilisearch: надавайте HTTP API через один authenticated HTTPS origin. Для Meilisearch HTTPS захищає credentials або user content під час передавання та забезпечує узгоджену поведінку клієнта, чутливу до origin.

Як тестувати оновлення Meilisearch?

Відновіть поточний state Meilisearch в isolated deployment, застосуйте candidate version і повторіть його acceptance transaction. Зверніть особливу увагу на те, що перед зміною версій необхідно перевірити dump compatibility Meilisearch і вимоги до index rebuild. Зберігайте попередній image Meilisearch, доки не буде зрозумілою boundary міграції даних і rollback.