Сейчас вокруг ИИ складывается большой ажиотаж, многие считают, что наличие такого помощника обесценивает знания и опыт и позволяет даже начинающим сотрудникам выполнять работу старших товарищей, не напрягаясь и не вникая.
Ну да, вкалывают роботы – счастлив человек. Это мы слышали не раз и не два. Но любой, кто серьезно работал с ИИ понимает, что несмотря на весь достигнутый прогресс – это просто помощник: неутомимый, исполнительный, но туповатый, хотя и начитанный.
Это как? Да вот так, теория без практики мертва, практика без теории – сборник магических заклинаний, камланий и ритуалов. И только совмещение первого и второго дают устойчивый результат в виде экспертных знаний и навыков.
Сегодня мы провели небольшой эксперимент, задали трем сетям один провокационный вопрос, в «забеге» участвовали ChatGPT, Gemini и Qwen. А вопрос был простой:
IMAGE ID DISK USAGE CONTENT SIZE EXTRA
joplin/server:latest 5d9e7f9d31b4 4.46GB 554MB U
Почему Joplin при размере контейнера в 554 МБ развернулся в 4,46 ГБ?
Сетки начинают активно думать и строить предположения, в целом ход их мысли правильный и грамотный, что может усыпить бдительность вопрошающего. Они совершенно правильно предлагают выполнить внутри контейнера определенные команды, чтобы понять, кто занял все это место.
Но вывод делают абсолютно неправильный, только увидев, что это папка
/home/joplin сразу возникает гипотеза: Вот и виновник: 3.4 ГБ в папке /home.
В образе Joplin Server по умолчанию рабочая директория и данные пользователя находятся именно в /home/joplin. Поскольку база данных у тебя вынесена в отдельный контейнер Postgres, эти 3.4 ГБ — это не заметки, а скорее всего хранилище ресурсов (Resources/Attachments): картинки, PDF-файлы и другие вложения, которые ты синхронизировал.
Почему это плохо в текущем виде?
Риск потери данных: Если ты сделаешь docker compose down и удалишь контейнер (а не просто остановишь), всё, что не в базе и не в Volume, исчезнет навсегда.
В общем сразу нагнали жути, а дальше пошли ценные указания как подключить к контейнеру том и на горячую перенести в него данные, чтобы они бесследно не пропали при перезапуске.
Хорошо, демонстративно делаю:
docker compose down
docker compose up -d
И снова показываю размер образа, и поясняю, что все мои данные на месте. После чего ИИ выдвигает новую гипотезу, что это могут быть временные файлы, логи, кеши и сессии. А дальше идут новые рекомендации как это все оптимизировать, вынести, разнести и т.д. и т.п.
При этом все три сетки продолжают нагнетать жути:
Для Joplin на Postgres это обычно не критично (всё в БД), но если ты используешь FileSystem как хранилище для ресурсов (Storage Driver), то обязательно выноси эту папку на хост.
Вердикт: Если docker system prune не скинет эти 4ГБ, значит, Joplin хранит вложения или логи внутри себя. Для «чистого» сервера это ненормально, и лучше поправить маппинг папок в конфиге сейчас, пока ты не залил туда всю свою базу заметок.
Ладно, предлагаю им ознакомиться с образцом Compose-файла от самих разработчиков, где никаких томов к контейнеру Joplin не монтируется, но в ответ снова идут размышления, что там просто пример, а на практике может быть всякое.
Скажем честно, если бы мы заранее не знали правильный ответ, но возможно бы и повелись, больно все хорошо обосновано было.
Но в итоге мы при помощи тех же самых команд, что советовала сетка показали ей что на самом деле занимает место.
И что? А ничего, ИИ моментально переобулся на ходу (это он умеет):
Вот мы и нашли "жирок". Эти 3.4 ГБ — это исходный код и зависимости самого приложения Joplin.
Что происходит?
В образе Joplin Server разработчики упаковали всё дерево в /home/joplin/packages.
Это нормально: Это не мусор, а рабочие модули (парсеры, рендерер, сам сервер), без которых приложение не заведется.
На самом деле все просто, Joplin Server написан на Node.js, который отлично жмется, а в развернутом виде и составляет те самые 4,5 ГБ.