Як самостійно розгорнути Mealie у 2026 році: імпорт рецептів, користувачі та резервні копії
Практичний посібник із самостійного розгортання Mealie: Docker, порти, постійне зберігання даних, TLS, безпека, резервні копії та проблеми, що перешкоджають використанню в production. Покроково.
Найкоротша демонстрація Mealie доводить лише те, що процес прослуховує порт 9000. Для production потрібні переконливіші докази. Система має проходити такий сценарій навіть після заміни контейнера: імпортувати URL рецепта, перевірити його зображення, додати рецепт до плану харчування та створити список покупок із кількох рецептів.
Mealie розгортають із чіткою метою: зберігати рецепти, плани харчування та списки покупок. Найпоширеніша помилка під час розгортання полягає в тому, що зображення рецептів зникають, оскільки /app/data не є постійним сховищем. Тому обробці публічних URL і довговічному стану потрібно приділяти таку саму увагу, як і запуску образу.
Визначте межі середовища виконання Mealie
Найменша відповідальна топологія Mealie містить один приватний listener на порту 9000, маршрут ingress і чітко задокументовану межу зберігання стану. Мережевий контракт Mealie для production-розгортання з кількома користувачами передбачає Postgres, а для запрошень — SMTP. Приватні endpoint-и залишайте у внутрішньому DNS, дозволяйте лише необхідні вихідні з’єднання та надайте Mealie сервісні облікові дані з обмеженими правами.
Перевірте топологію, попросивши чистий клієнт імпортувати URL рецепта, перевірити його зображення, додати рецепт до плану харчування та створити список покупок із кількох рецептів. Під час виконання стежте за імпортом рецептів, зберіганням зображень, запитами до бази даних, фоновими завданнями та одночасною роботою користувачів із домогосподарства. Результат покаже, чи потрібне наступне вдосконалення пам’яті, сховищу, мережі або окремому worker-у, замість заохочення до довільного збільшення ресурсів контейнера.
Перевірки продуктивності та оновлення
Перевірка health мало що говорить про Mealie. Відстежуйте імпорт рецептів, зберігання зображень, запити до бази даних, фонові завдання та одночасну роботу користувачів із домогосподарства, а сповіщення налаштовуйте на симптом, який бачать користувачі: невдале виконання дії «імпортувати URL рецепта, перевірити його зображення, додати рецепт до плану харчування та створити список покупок із кількох рецептів». Liveness залишайте локальним і дешевим; readiness має повідомляти про міграції або ініціалізацію, не спричиняючи шторму перезапусків.
Ризикована частина оновлення полягає в тому, що міграції бази даних і зміни parser-а інгредієнтів можуть вплинути на збережені рецепти, тому перевіряйте імпорт і наявні записи. Ознайомтеся з нотатками до релізу, створіть snapshot стану, розгорніть цільову версію на відновленій копії та повторіть acceptance-тест. Якщо зображення рецептів зникають, оскільки /app/data не є постійним сховищем, зіставте запит клієнта з першим релевантним записом у журналі застосунку, а не видаляйте стан і не додавайте перенаправлення навмання.
Критерії випуску Mealie
Release candidate для Mealie отримує трафік лише після виконання фіксованого сценарію: імпортувати URL рецепта, перевірити його зображення, додати рецепт до плану харчування та створити список покупок із кількох рецептів. Зафіксуйте digest образу, ефективну конфігурацію без секретів, публічний origin і часові мітки цього сценарію. Тестові дані мають бути одноразовими, але достатньо реалістичними, щоб пройти тим самим шляхом, яким користуються користувачі.
Запустіть тест після заміни runtime, а потім відновіть сервіс із бази даних, зображень рецептів, assets і налаштувань застосунку. Відновлення вважається успішним, якщо повернулися рецепти, зображення, користувачі, плани харчування та списки покупок, а відомий рецепт коректно відображається. Порівняйте вимірювання ресурсів для імпорту рецептів, зберігання зображень, запитів до бази даних, фонових завдань і одночасної роботи користувачів із домогосподарства з попереднім релізом та дослідіть суттєві відхилення до promotion.
Нарешті, перевірте контрольовану відмову: тимчасово забороніть тестовій identity доступ до Postgres для production-розгортання з кількома користувачами та до SMTP для запрошень. Переконайтеся, що Mealie зрозуміло пояснює помилку, не пошкоджує наявний стан і відновлює роботу після повернення коректної умови. Збережіть знеособлений фрагмент журналу та час відновлення. Разом ці перевірки охоплюють поведінку, довговічність даних і придатність до експлуатації, а не лише доступність процесу.
Створіть контейнер Mealie, який можна замінити
Початковий запуск Mealie має бути достатньо відтворюваним, щоб його можна було перевірити в pull request.
docker run -d \
--name mealie \
--restart unless-stopped \
-p 127.0.0.1:9000:9000 \
-v mealie-data:/app/data \
-e BASE_URL=https://app.example.com \
ghcr.io/mealie-recipes/mealie:latest
Не покладайтеся на latest, коли в системі вже є реальні дані. Зафіксуйте робочий digest, користувача контейнера та права власника mount. Перегляньте журнал застосунку протягом повного тесту — імпортуйте URL рецепта, перевірте його зображення, додайте рецепт до плану харчування та створіть список покупок із кількох рецептів — і зафіксуйте всі міграції, перш ніж спрямовувати маршрут на production-трафік.
Знайдіть усі довговічні дані Mealie
Проведіть інвентаризацію всіх довговічних артефактів: бази даних, зображень рецептів, assets і налаштувань застосунку. Підключіть /app/data до bootstrap, запишіть нешкідливі тестові дані та замініть контейнер, щоб довести, що цей шлях справді постійний. Додайте до резервної копії конфігурацію, яка змінює спосіб інтерпретації збережених даних, а не лише найбільший каталог.
Визначте політику зберігання, копіюйте резервні копії за межі хоста та виконайте відновлення в чистому середовищі. Перевірка Mealie завершена, коли повернулися рецепти, зображення, користувачі, плани харчування та списки покупок, а відомий рецепт коректно відображається. Якщо в плані використовуються snapshots, скористайтеся рекомендаціями щодо PITR і snapshot, щоб задокументувати, що саме може відновити кожен механізм.
Маршрутизуйте Mealie без імітації HTTPS
Установіть BASE_URL як зовнішній HTTPS origin. Спрямуйте вибране ім’я хоста на порт контейнера 9000, передавайте оригінальні host і HTTPS scheme та не публікуйте додатковий прямий origin.
Перевірте Mealie із чистого зовнішнього клієнта. Відокремлюйте помилку ingress від відомої межі застосунку — зображення рецептів зникають, оскільки /app/data не є постійним сховищем. Помилка сертифіката, DNS або 502 належить до маршрутизації; запит, який доходить до Mealie, а потім завершується помилкою, належить до стану застосунку, продуктивності або його допоміжної вимоги. Першу групу описано в посібнику з TLS для custom domain.
Зменште повноваження Mealie
Після першого входу перевірте, що можуть робити анонімний відвідувач, звичайний користувач і адміністратор. Помилка, якої слід уникати в Mealie, — залишити відкритою реєстрацію або не змінити початковий пароль адміністратора. Передбачена політика: замінити початковий пароль адміністратора, закрити реєстрацію після завершення додавання користувачів і захистити приватні дані домогосподарства.
BASE_URL є конфігурацією, а не секретом; зберігайте його значення явним, захищаючи окремі облікові дані, які використовує Mealie. Розділяйте облікові записи залежностей і людей, за можливості забороняйте невикористовувані вихідні з’єднання та обмежуйте навантаження, спричинене імпортом рецептів, зберіганням зображень, запитами до бази даних, фоновими завданнями й одночасною роботою користувачів із домогосподарства.
Розгортання в Dockup все одно потребує acceptance-тесту Mealie
Маршрутизація, сертифікати, заміна сервісів і підключене сховище — цілком доречні цілі для автоматизації. Dockup обробляє їх для Mealie та може підготувати відповідну керовану базу даних або підключитися до сервісів на власному сервері клієнта.
Водночас Dockup не має вигадувати політику довіри Mealie. Після розгортання встановіть BASE_URL як зовнішній HTTPS origin, застосуйте цю межу — замініть початковий пароль адміністратора, закрийте реєстрацію після завершення додавання користувачів і захистіть приватні дані домогосподарства — та перевірте результат такого сценарію: імпортуйте URL рецепта, перевірте його зображення, додайте рецепт до плану харчування та створіть список покупок із кількох рецептів. У підсумку ви отримуєте інфраструктуру в один клік із acceptance-тестом, специфічним для застосунку.
Поширені запитання
Що потрібно Mealie для production-розгортання?
Маршрутизуйте контейнер Mealie через один HTTPS origin на порт 9000. Мережева вимога для залежностей — Postgres для production-розгортання з кількома користувачами та SMTP для запрошень. Не вважайте Mealie готовою, доки не зможете імпортувати URL рецепта, перевірити його зображення, додати рецепт до плану харчування та створити список покупок із кількох рецептів.
Які дані Mealie потрібно включати до резервної копії?
Зберігайте /app/data і додайте базу даних, зображення рецептів, assets та налаштування застосунку до одного recovery manifest. Чисте відновлення Mealie є успішним лише тоді, коли повернулися рецепти, зображення, користувачі, плани харчування та списки покупок, а відомий рецепт коректно відображається.
Чи потрібен Mealie HTTPS за reverse proxy?
Використовуйте HTTPS для публічного origin Mealie, а порт 9000 залишайте у внутрішньому маршруті. Правильно застосуйте налаштування Mealie: встановіть BASE_URL як зовнішній HTTPS origin. Для Mealie HTTPS захищає облікові дані або вміст користувачів під час передавання та забезпечує узгоджену поведінку клієнта, чутливу до origin.
Як тестувати оновлення Mealie?
Відновіть поточний стан Mealie в ізольованому розгортанні, застосуйте кандидатну версію та повторіть acceptance transaction. Приділіть особливу увагу тому, що міграції бази даних і зміни parser-а інгредієнтів можуть вплинути на збережені рецепти, тому перевіряйте імпорт і наявні записи. Зберігайте попередній образ Mealie, доки не зрозумієте межі міграції даних і rollback.
