Обновление Discourse не удалось из-за нехватки места на диске на Droplet 25G

18G /var

du -h -s /var/* | sort -h -r
14G     /var/lib
2.8G    /var/log
933M    /var/discourse
du -h -s /var/lib/* | sort -h -r
13G     /var/lib/docker
744M    /var/lib/snapd
root@DO-Discourse:/var/discourse# du -h -s /var/lib/docker/* | sort -h -r
13G     /var/lib/docker/overlay2
16M     /var/lib/docker/image
root@DO-Discourse:/var/discourse# du -h -s /var/lib/docker/overlay2/* | sort -h -r
8.7G    /var/lib/docker/overlay2/d319d95263d87c2a75a4bc9a9f03a25ea7f6eb1f7bac687e7ae7d45522939dc0
2.8G    /var/lib/docker/overlay2/79be56509f1588c272683332ef50abd54f0aeb06d0e2d13f8eea1bace3b3db46
873M    /var/lib/docker/overlay2/5b148cbbcca894be512c7407568104cd7b2e3d48ab7b7d74c6c0f731806cdddc

Есть ли смысл идти дальше?

Удалил 2,8 ГБ логов, что освободило лишь до 4,9 ГБ. У меня нет тестового экземпляра, чтобы попробовать ./launcher rebuild app --skip-prereqs.

Есть ещё какие-то предложения?

Разве теперь просто невозможно запустить экземпляр Discourse на Droplet с 25 ГБ?

Смотрите конец Prune unused Docker objects | Docker Docs

Я думаю, вам нужно выполнить очистку всего и очистку томов.

docker system prune --volumes
ВНИМАНИЕ! Это удалит:
  - все остановленные контейнеры
  - все сети, не используемые хотя бы одним контейнером
  - все тома, не используемые хотя бы одним контейнером
  - все «висячие» образы
  - весь «висячий» кэш сборки

Вы уверены, что хотите продолжить? [y/N] y
Всего освобождено места: 0Б
root@DO-Discourse:/# 

Есть ли какие-либо другие предложения?

Вам пригодится Snap?

Не совсем. Это довольно показательно, что пространство занимает Docker для ваших контейнеров(ов). После очистки мои показатели очень похожи на ваши, что, возможно (но не обязательно), указывает на то, что это просто тот объем, который он использует.

У меня действительно были проблемы с Linode на 25 ГБ, однако это было связано с резервными копиями объемом более 500 МБ. Удаление двух-трех резервных копий дало мне достаточно места для восстановления. Я решил перейти на следующий уровень с 50 ГБ, потому что ситуация только становилась более ограничительной, и я хотел восстанавливать систему по ежемесячному плану (cron job).

Это было до перехода на Ember CLI, неужели это могло значительно увеличить размер?

Похоже, проблема в этом оверлее размером 9 ГБ. Но я только что проверил другой экземпляр с оверлеем примерно такого же размера. С 25 ГБ всегда было непросто. Рекомендую решиться и добавить больше места на SSD. Следующий шаг — проверить, можно ли удалить что-то на уровне ОС: логи, ненужные программы, индексы от find и так далее.

Другая идея — просто запустить новую виртуальную машину на 25 ГБ и перенестись туда, надеясь, что то, что заполнило старую, не станет проблемой в этот раз.

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

Не уверен. Нужен ли он для установки только Discourse? И если нет, как его удалить?

Я так не думаю :thinking:
после полной загрузки резервной копии можно выполнить snap list, чтобы проверить установленные snap-пакеты, и если их нет — sudo apt purge snapd

root@DO-Discourse:/var/discourse# snap list
Имя           Версия        Рев.     Канал отслеживания   Издатель      Примечания
core18        20220309      2344     latest/stable        canonical✓    base
core20        20220304      1376     latest/stable        canonical✓    base
lxd           4.0.9-8e2046b 22753    4.0/stable/…         canonical✓    -
snapd         2.54.4        15177    latest/stable        canonical✓    snapd
root@DO-Discourse:/var/discourse# 

Что это за оверлеи? Я могу их удалить?

Привет, Энди, извини за задержку.
На данном этапе имей в виду, что без понимания твоей хост-системы легко увести тебя к обрыву, поэтому сделай резервную копию/снимок и т.д. (или даже создай резервную копию, разверни новый экземпляр и протестируй процесс восстановления — для меня это было хорошей практикой).
Если LXD тебе не нужен (lxc list должен показать установленные контейнеры), выполни snap remove lxd (а затем core18 и core20).

Можете ли вы предоставить вывод команд docker images и docker ps -a?

Спасибо за вашу помощь. Да, я очень мало знаю о Linux, поэтому полностью поддерживаю совет делать резервные копии. У меня настроены автоматические снимки, и я также делаю ручные, когда занимаюсь какими-то изменениями, как сейчас.

Не имею понятия, что такое lxd. Мне ничего не нужно на этом droplet, кроме того, что требуется для discourse/docker, так как это исключительно droplet для discourse.

root@DO-Discourse:/var/discourse# docker images
РЕПОЗИТОРИЙ            ТЕГ       ID ОБРАЗА       СОЗДАН         РАЗМЕР
local_discourse/app   latest    3dac608caa92   4 месяца назад   3.17 ГБ
root@DO-Discourse:/var/discourse#
root@DO-Discourse:/var/discourse# docker ps -a
ID КОНТЕЙНЕРА   ОБРАЗЕЦ                 КОМАНДА        СОЗДАН         СТАТУС        ПОРТЫ                                      ИМЯ
9abaf4517b7e   local_discourse/app   "/sbin/boot"   4 месяца назад   Работает 4 месяца   0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp   app
root@DO-Discourse:/var/discourse#

Учитывая

и

похоже, что у вас есть «висячие» слои в папке overlay2.

Обратитесь к этому ответу на StackOverflow за рекомендациями:

Спасибо. Это немного выше моего понимания. Было бы безопасно просто сделать снимок, затем удалить их и посмотреть, что произойдет?

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

Создание снимка — неплохая идея.

Я бы просто запустил новый экземпляр: это самый безопасный и, вероятно, более быстрый способ по сравнению со снимком. Но если вам не интересно или не полезно разбираться в этом процессе, то ваш вариант тоже подходит.

Удалил одно из изображений, и это помогло!

Спасибо всем за помощь.