Глава 2.2: Постоянство данных, тома и гигиена прав (PUID/PGID).

В этой главе мы разберем два критически важных вопроса селф-хостинга: где физически хранятся данные ваших сайтов и как Docker распределяет права доступа к файлам внутри системы Linux.

1. Жизненный цикл данных: Куда всё пропадает?

По умолчанию любой контейнер Docker внутри себя абсолютно эфемерен (временен). Если вы запустите BookStack, напишете туда десяток статей, а затем выполните команду docker compose down (уничтожить стек) — все ваши статьи сотрутся навсегда вместе с контейнером.

Чтобы этого не происходило, данные из изолированного контейнера нужно «пробросить» на жесткий диск нашего реального сервера. В Docker для этого есть два основных механизма:

Volumes (Тома Docker): Это изолированные папки, которыми полностью управляет сам Docker. Они хранятся в глубоких системных директориях (/var/lib/docker/volumes/). Обычному пользователю туда лазить неудобно, но для баз данных это идеальный, самый быстрый и безопасный вариант.
Bind Mounts (Прямое монтирование папок): Это когда вы жестко связываете конкретную папку на сервере (например, /stacks/bookstack/app_data) с папкой внутри контейнера. Это идеальный выбор для новичка: вы всегда видите файлы конфигурации, можете легко отредактировать их через nano, закинуть туда картинки или сделать бэкап.

В нашем конфиге из прошлой главы мы использовали именно Bind Mounts, указав относительные пути:

volumes:
  - ./app_data:/config   # Папка app_data создастся прямо в текущем каталоге

2. Проблема прав и магия PUID и PGID

Когда контейнер создает файлы на вашем реальном сервере в папке app_data, он делает это от лица того пользователя, который запущен внутри контейнера. Очень часто внутри контейнеров все процессы работают от пользователя root.

В итоге получается неприятная ситуация: контейнер создал файлы конфигурации, вы хотите зайти на сервер под своим обычным пользователем и отредактировать конфиг через nano, но система выдает ошибку: Permission Denied (Доступ запрещен). Файлы принадлежат суперпользователю контейнера, и обычный юзер сервера не имеет права к ним прикасаться.

Для решения этого хаоса разработчики из LinuxServer.io внедрили в свои образы гениальный механизм — переменные окружения PUID (User ID) и PGID (Group ID).

Эти параметры говорят контейнеру: «Эй, внутри себя ты можешь работать как угодно, но когда ты записываешь файлы на реальный жесткий диск сервера, делай это с правами конкретного пользователя и группы из реальной системы».

Шаг практики: Как узнать свои PUID и PGID?

Чтобы ваш сервис без проблем читал и записывал файлы, вам нужно передать ему ID вашего текущего пользователя. Узнать их очень просто. Введите в терминале вашего сервера Debian команду:

id

Система выведет текст, похожий на этот:

uid=1000(sergey) gid=1000(sergey) groups=1000(sergey),27(sudo),998(docker)

Отсюда мы видим, что для пользователя sergey:

uid (он же PUID) = 1000
gid (он же PGID) = 1000

Именно эти цифры (обычно у первого созданного пользователя в Linux это всегда 1000) мы и прописали в блоке environment нашего файла docker-compose.yml.

Что делать, если ошибка Permission Denied уже случилась?

Если вы запустили какой-то чужой контейнер без PUID/PGID, и он "зарейдил" ваши папки, сделав их root-зависимыми, вы не сможете их даже удалить без sudo. Вернуть права вашему пользователю на всю папку со стеком можно одной простой командой Linux:

# Сила утилиты chown (change owner)
sudo chown -R 1000:1000 /stacks/bookstack

Флаг -R означает «рекурсивно» — команда пройдет по всем вложенным папкам и файлам, мгновенно вернув вам власть над ними.

💡 Правило гигиены сисадмина:
Каждый раз, разворачивая новый сервис через Docker Compose, проверяйте документацию образа на наличие параметров PUID/PGID. Всегда указывайте идентификаторы своего пользователя (1000). Это сэкономит вам сотни нервных клеток, а ваши бэкапы всегда будут копироваться без спотыкания о системные запреты.

Теперь, когда мы разобрались с физическим хранением файлов и правами на диске, пришло время понять, как наши контейнеры общаются друг с другом по сети внутри сервера. Переходим к Главе 2.3: Сети Docker.