docker system prune --volumes
ВНИМАНИЕ! Это удалит:
- все остановленные контейнеры
- все сети, не используемые хотя бы одним контейнером
- все тома, не используемые хотя бы одним контейнером
- все «висячие» образы
- весь «висячий» кэш сборки
Вы уверены, что хотите продолжить? [y/N] y
Всего освобождено места: 0Б
root@DO-Discourse:/#
Не совсем. Это довольно показательно, что пространство занимает Docker для ваших контейнеров(ов). После очистки мои показатели очень похожи на ваши, что, возможно (но не обязательно), указывает на то, что это просто тот объем, который он использует.
У меня действительно были проблемы с Linode на 25 ГБ, однако это было связано с резервными копиями объемом более 500 МБ. Удаление двух-трех резервных копий дало мне достаточно места для восстановления. Я решил перейти на следующий уровень с 50 ГБ, потому что ситуация только становилась более ограничительной, и я хотел восстанавливать систему по ежемесячному плану (cron job).
Это было до перехода на Ember CLI, неужели это могло значительно увеличить размер?
Похоже, проблема в этом оверлее размером 9 ГБ. Но я только что проверил другой экземпляр с оверлеем примерно такого же размера. С 25 ГБ всегда было непросто. Рекомендую решиться и добавить больше места на SSD. Следующий шаг — проверить, можно ли удалить что-то на уровне ОС: логи, ненужные программы, индексы от find и так далее.
Другая идея — просто запустить новую виртуальную машину на 25 ГБ и перенестись туда, надеясь, что то, что заполнило старую, не станет проблемой в этот раз.
Ни один из этих вариантов не кажется особенно удовлетворительным. На прошлой неделе или две я сильно повозился с дроплетом на 25 ГБ на одном или двух экземплярах, которые помогаю администрировать, но мне кажется, что вы уже сделали всё, что сделал я.
Я так не думаю
после полной загрузки резервной копии можно выполнить snap list, чтобы проверить установленные snap-пакеты, и если их нет — sudo apt purge snapd
Привет, Энди, извини за задержку.
На данном этапе имей в виду, что без понимания твоей хост-системы легко увести тебя к обрыву, поэтому сделай резервную копию/снимок и т.д. (или даже создай резервную копию, разверни новый экземпляр и протестируй процесс восстановления — для меня это было хорошей практикой).
Если LXD тебе не нужен (lxc list должен показать установленные контейнеры), выполни snap remove lxd (а затем core18 и core20).
Спасибо за вашу помощь. Да, я очень мало знаю о 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#
Я думаю, что можно безопасно удалить все эти изображения. Если они вам понадобятся, они будут восстановлены при пересборке.
Создание снимка — неплохая идея.
Я бы просто запустил новый экземпляр: это самый безопасный и, вероятно, более быстрый способ по сравнению со снимком. Но если вам не интересно или не полезно разбираться в этом процессе, то ваш вариант тоже подходит.