Comments 24
Полезно, спасибо, сохраню
Docker-compose хорошо ДО переезда на сервер. Если локальные вещи тянуть на прод, это будет очень красивый техдолг.
Пока ограничения компоуза не мешают это намного проще чем почти любая альтернатива, не всегда есть смысл усложнять развёртку раньше времени
Проблема в том, что да, вроде устраивает. Потом это разрастается и никто не будет переделывать уже под серьёзную нагрузку. Сам видел как у людей тучка сервисов ложится каждую ночь (docker-compose down), чтобы сделать бэкап и потом снова композ запускает всё и вся. Просто потому что изначально так было сделано и "зачем переделывать, если работает". В итоге час простоя каждый раз. И после запуска реиндекс вдобавок. Мониторинг тормозиться ради этого так же. Один техдолг породил следующий. "Болезнь роста."
Тот случай, когда лучше отдельно сервисы в том же docker/podman и т.д. запускали сервисами и делали бэкап более адекватными методами, чем взять за правило то, что написано у поставщика на сайте и игнорировать, что вариант для демо стенда точно не подходит для production.
Сказки венского леса от адептов кубернетеса) Половина интернета крутится на компоузе и одиночных впсках, принося владельцам реальные деньги
Большое спасибо нейронке за подсказки. Но зачем в хабре размещать то, что может простой промпт сделать?
Автору спасибо, тоже сохранил
Для бекапов volumes с небес ниспослан Restic.
Я ни разу за 3 года не использовал docker compose stop, только через down/up
Лимиты памяти в компоузе работают нормально, только если само приложение умеет жить в этих рамках. Ограничить джава-машину или ноду через cgroups мало, они просто упадут с OOM внутри контейнера
А какой смысл использовать named volume если можно обычную директорию подключить? У меня тут на поддержке один такой "продукт", который при обновлении потребовал переход на named, по итогу я проверил что работает одинаково и так и так, но, по мне, потерять данные из named volume сильно легче, чем из лежащей рядом с compose директории...
"Директория рядом" создает чувство надежности, но порочная практика т.к. в named volume докер сам управляет UID/GUID без неожиданных Permission Denied и при первом монтировании named volume автоматически скопирует в него файлы, которые уже лежат по этому пути внутри образа (например, дефолтные конфиги образа). Директория рядом просто создаст пустой каталог внутри образа и все упадет если это не обработано
Выскажу свое мнение, размещать скрипт бэкапа БД в самом контейнере postgres:16-alpine это мягко говоря тупо. По правилам, система архивации данных должна быть независима от самой системы которую она бэкапит. А у вас получается все в одной куче, причем выполнение скрипта никак не контролируется. В данном случае, бэкап лучше сделать внешней cron задачей.
Все ваши советы можно свести к одному, если вам нужны деньги, то работайте больше. Вроде бы озвучили проблемы, но решений нет. Когда формулируете промпт к ИИ, дописывайте фразу "и напиши подробно способы решения для малых VPS с минимальными ресурсами".
Для бэкапа сделал простой bash скрипт который можно запускать по расписанию, подойдет как раз для тех задач, которые вы и написали Простое резервное копирование VPS сервера на Linux с помощью bash-скрипта.
Bash-скрипт рассчитан на запуск в ОС Ubuntu, позволяет создавать резервные копии следующих типов данных
Файлов;
Папок;
Отдельных volume (том) Docker контейнеров на горячую (без остановки работы самих контейнеров);
Отдельных volume (том) Docker контейнеров с остановкой самих контейнеров (когда может быть нарушена целостность данных, например базы данных);
Базы данных MariaDB и PostgreSQL;
Список cron-задач;
Настройки UFW;
Настройки Fail2ban.
Еще кстати периодически запускаю (на ARM серверах тоже работает) Очистка дискового пространства в Ubuntu
Независимость независимости рознь, не?
Независимость по хранению данных - несомненно. А вот независимость по запуску - я бы поспорил. Забыли включить бэкап в кроне после обслуживания, или кто-то несвязанный напортачил в crontab - и привет. В этом плане докер не менее надёжен, но более управляем.
А если система в таком состоянии, что бэкап скрипт не может отработать - то стоит ли её бэкапить-то? Может, сначала в порядок привести?
Насчёт контроля выполнения (и читаемости!) бэкапов - согласен, без этого только иллюзия безопасности.
Если в образе нет curl (alpine‑образы часто без него):
то и wget там далеко не факт что будет)))))
Named Volumes использовать вместо внешних (external: true, монтирования директорий или любой другой заведомо предсказуемый вариант) - это надо очень хотеть продолбать важные данные, чтобы потом с пеной у рта доказывать какие доцкеры плохие все.
Бэкап-скрипт - ну, прикольно, ровно настолько же как хранить бэкапы на том же сервере который отлетит.
Как уже тут правильно заметили бэкап лучше в cron запихнуть и бэкапить хотя бы на отдельно примонтированный диск. Так же в cron можно добавить задачу для restic чтобы этот бэкап отправить в s3. Это как минимум, а в идеале использовать еще какой-нибудь инструмент, который будет мониторить всё это дело. В свое время airflow для этого приспособить удалось, но есть и более специализированные инструменты под это дело. Я бы ещё добавил, что docker-compose.yml должен быть универсальным, и запускаться как на новых ОС так и на старых, и многие забывают о самой первой строке version.
Ваш docker‑compose.yml сломается: 5 настроек, которые все забывают