Аварийное резервное копирование — прямая связь с командной строкой контейнера

Поддержка Самостоятельное хостинг
1

Я узнал кое-что, что может помочь другим.

Предпосылки: Как подробно описано здесь, моя установка Discourse размещалась на VPS, где дискового пространства было недостаточно для завершения обновления. Сначала я нажал кнопку «Обновить» в панели администратора. Обновление не удалось, и графический интерфейс больше никогда не работал. После этого я зашел в консоль своего VPS и ввел известную команду ./launcher rebuild app. Она тоже не завершилась: у меня полностью закончилось дисковое пространство. Чтобы получить больше места и уложиться в бюджет, я решил перенести всю свою установку на новый VPS у другого хостинг-провайдера. Сохранение ценных данных сайта было приоритетом.

Неудачи: Два самых очевидных способа создания резервной копии не сработали:

  • моя первоначальная попытка обновления сломала веб-интерфейс, поэтому не было возможности попасть в панель администратора и запустить резервное копирование оттуда; и
  • попытка зайти внутрь контейнера Docker и выполнить там команды оболочки тоже не удалась. Рекомендуемая для этого команда — /var/discourse/launcher enter app. Но, по крайней мере в моем случае, скрипт launcher пытался пересобрать приложение перед тем, как позволить мне войти в него, а пересборки постоянно не удавались, поэтому эта команда даже не давала мне доступа к контейнеру, не говоря уже о оболочке внутри него.

Успех: Я уже собирался сдаться, когда получил приятный сюрприз. Работая в командной строке моей небольшой виртуальной машины, я ввел docker ps и узнал, что есть активный контейнер с именем app. У Docker есть прямой способ зайти в работающий контейнер: команда docker exec -it app bash.

Внутри контейнера я смог продвинуться вперёд: я выполнил команду discourse backup, подождал несколько минут, а затем скопировал файл <backup>.tar.gz в безопасное новое место. С актуальной резервной копией на руках стало возможным завершить миграцию моей установки на новое место. (На этих форумах есть другие темы, показывающие, как это сделать.)

Ключевой момент здесь в том, что вышеуказанная команда docker для входа в контейнер сработала, даже когда специфичная для Discourse команда ./launcher не сработала.

Спасибо создателям и сопровождающим этот отличный продукт.

2

Вы пробовали

./launcher cleanup

Или удалить некоторые резервные копии?

3

Спасибо за вопрос.

В те дни, когда я пытался настроить свою первоначальную конфигурацию, я думал, что сделал всё возможное для освобождения места, включая не только ./launcher cleanup, но и многое другое: удаление старых ядер, очистку кэша apt, отказ от необязательного программного обеспечения и так далее.

После того как я принял решение перенести весь свой сайт и потратил на этот процесс много времени, я задумался, не мог ли я сделать ещё что-то… но к тому моменту у меня уже не осталось желания углубляться в исследование (см. «ошибку невозвратных затрат»). Если быть конкретным, VPS, которую я вот-вот собираюсь покинуть, имела номинальный размер диска 25 ГБ. Около 19 ГБ из них было занято каталогом /var/lib/docker/overlay2. При этом я запускал только два Docker-контейнера: Discourse и связанный с ним почтовый получатель. Опыт подсказывает, что Discourse, несмотря на свою мощь, должен работать с гораздо меньшим объёмом диска, чем 19 ГБ. Однако поиск в интернете указывал на то, что внесение изменений внутри каталога overlay2 небезопасно, поэтому я остановился на этом этапе.

В моей новой конфигурации каталог /var/lib/docker/overlay2 занимает 13 ГБ. Всё ещё огромно.

Я выбрал Discourse для работы форума на своём небольшом хобби-сайте в надежде, что он «просто заработает» — то есть что его будет супер-просто администрировать, не изучая кучу новых вещей. Это, кажется, в основном верно, если у вас есть достаточные (избыточные?) ресурсы для выделения.

Мой новый план — слепо надеяться, что каталог overlay2 не будет расти со временем и не заполнит весь диск объёмом 50 ГБ на моём новом VPS. Если вы (или кто-то ещё) знаете, как держать размер связки Docker и Discourse под контролем, я с радостью хотел бы об этом услышать. Это стало бы отличным завершением всего того, что я изучил в последние дни. Ещё раз спасибо.

4

Рад, что вам удалось восстановиться самостоятельно. Я администрирую два небольших форума: один на 20 ГБ хранилища, другой — на 25 ГБ. Иногда приходится тратить немало времени и проявлять изобретательность, чтобы всё работало. Однако, похоже, я постоянно использую (и публикую сообщения о) один и тот же набор тактик. См. ниже.

Разработка Discourse оптимизирована под другие задачи, а не под работу на оборудовании с минимальными затратами, хотя в моём ограниченном окружении оно всё же продолжает работать. Пусть так и будет.

Ключ к работе в условиях малого объёма хранилища — измерение того, что происходит. Слишком часто я вижу, как люди гадают, что именно происходит. Мой подход всегда начинается с

Для получения дополнительной информации, возможно, стоит поискать мои сообщения по запросам prune, journalctl и kernel.