Глава 3.1: Масштабирование экосистемы.

Вы успешно запустили свой первый стек с BookStack. Но прелесть Docker Ecosystem в том, что ваш сервер не должен ограничиваться одной задачей. Завтра вы захотите поднять личное облако Nextcloud, систему умного дома Home Assistant, парольный менеджер Vaultwarden или медиасервер.

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

1. Золотое правило: Один сервис — один стек (одна папка)

У новичков часто возникает соблазн пихать вообще все новые контейнеры в один единственный файл docker-compose.yml, который мы создали для BookStack. Никогда так не делайте. Через пару недель ваш конфиг превратится в нечитаемую простыню на 500 строк, а ради обновления или перезапуска одного сервиса вам придется дергать весь сервер.

Правильный подход: Модульность.
Каждое независимое приложение должно лежать в своей собственной подпапке внутри каталога /stacks и иметь свой собственный, изолированный файл docker-compose.yml и .env.

Давайте посмотрим, как будет выглядеть файловая структура масштабируемого сервера:

/stacks/
├── bookstack/
│   ├── docker-compose.yml
│   ├── .env
│   ├── app_data/
│   └── db_data/
├── nextcloud/            # Новый независимый сервис
│   ├── docker-compose.yml
│   ├── .env
│   └── cloud_data/
└── home-assistant/       # Еще один новый сервис
    ├── docker-compose.yml
    └── ha_config/

2. Стратегия распределения внешних портов

Когда вы запускаете новый сервис, вам нужно назначить ему уникальный внешний порт на сервере Debian, чтобы избежать конфликтов.

Вспомним наш конфиг BookStack. Там мы написали:

ports:
  - "8080:80" # Порт 8080 на сервере теперь занят под BookStack

Если вы в конфиге Nextcloud тоже напишете "8080:80", Docker выдаст ошибку "port is already allocated" (порт уже занят) и откажется запускаться. Заведите себе простое правило — вести мысленный или задокументированный реестр портов вашего сервера, просто инкрементируя (увеличивая) их:

8080 — BookStack
8081 — Nextcloud
8082 — Home Assistant
8083 — Portainer (веб-панель)

При этом внутри своих контейнеров все эти приложения могут одновременно работать на стандартном 80 порту — Docker без проблем разрулит это, так как внутренние порты изолированы друг от друга.

3. Почему вам больше не нужно трогать роутер?

Вспомните вводную страницу и наш глобальный план. Новичкам кажется, что для каждого нового сайта (например, cloud.myserver.ru) нужно заходить в настройки роутера и делать новый Port Forwarding (проброс портов). Это не так.

Вы делаете проброс портов 80 и 443 на роутере строго один раз в жизни — на IP-адрес вашего сервера Debian.

Когда запрос из интернета приходит на сервер, его встречает ваш единый Обратный Прокси (Nginx). Именно он выступает в роли "регулировщика" на перекрестке:

Nginx видит запрос к домену wiki.myserver.ru ➔ и перенаправляет трафик локально на порт 8080 (в BookStack).
Nginx видит запрос к домену cloud.myserver.ru ➔ и перенаправляет трафик локально на порт 8081 (в Nextcloud).

Таким образом, всё масштабирование в будущем сводится к двум простым шагам на самом сервере: запустить новый контейнер на новом порту (например, 8081) и добавить пару строчек в конфигурацию Nginx. Никаких перезагрузок роутера, никаких сложных манипуляций с сетью провайдера.

4. Объединение контейнеров из разных папок (Внешние сети)

В прошлой главе мы говорили, что Docker Compose создает изолированную сеть для каждой папки. Но как быть, если нашему будущему Nginx Proxy нужно достучаться до контейнера BookStack, который лежит в другой папке?

Для этого в Docker существует концепция внешних сетей (External Networks). Мы можем создать одну общую сеть (назовем её, например, main-proxy-net) и разрешить контейнерам из разных папок подключаться к ней.

Создадим такую общую глобальную сеть через терминал:

docker network create main-proxy-net

Теперь в любом docker-compose.yml на сервере мы сможем в самом низу дописать блок, подключающий сервис к этой общей сети, позволяя прокси-серверу беспрепятственно видеть наше приложение.

📌 Архитектурный взгляд в будущее:
Поздравляю! Теперь вы понимаете, как мыслят системные архитекторы. Мы ушли от хаотичного нагромождения программ к стройной, модульной системе блоков.

Управлять десятком таких папок через консоль по SSH со временем может стать скучно. Поэтому в следующей Главе 3.2 мы установим мощный и красивый веб-интерфейс Portainer, чтобы вы могли управлять всей этой экосистемой, кликая мышкой в браузере.