Docker Compose в домашней лаборатории: организация, профили и лучшие практики.

Информатек Диджитал » Ресурсы » Docker Compose в домашней лаборатории: организация, профили и лучшие практики.

Создание современной домашней лаборатории из морских контейнеров стало любимым хобби многих специалистов в области технологий. В основе такой настройки почти всегда лежит Docker Compose.Определите свои сервисы в формате YAML, используйте Git для управления версиями, и вы сможете запустить всю свою среду одной командой.

Теперь, когда вы начинаете расти, происходят разные вещи: у вас появляется не два-три контейнера, а несколько других. Десятки сервисов, внутренние сети, обратные прокси-серверы, базы данных и средства непрерывной интеграции.И тут возникает главный вопрос: один гигантский Docker Compose или множество маленьких файлов? Как организовать профили, сети, резервные копии, безопасность и, кроме того, упростить миграцию?

Практические подходы к настройке Docker Compose в домашней лаборатории

На практике люди, которые уже некоторое время используют Homelabs, обычно работают в рамках трех организационных моделей Compose, каждая из которых имеет свои преимущества и недостатки. Правильный подход позволит избежать множества проблем при развитии или переносе оборудования..

С одной стороны находится тот, кто начал с Docker Run начинался как простой инструмент, затем перешёл на Portainer, а в итоге — на Docker Compose.Это типично: Portainer предлагает отличную наглядность, удобный интерфейс, шаблоны и т. д., но в конечном итоге редактирование сложных параметров или перенос конфигураций становится проблемой, если у вас ничего нет в файлах.

На противоположном полюсе находятся те, кто объединил все в один «мега» файл docker-compose.yml. Способен запускать абсолютно все сервисы для домашней лаборатории: обратный прокси, медиафайлы, утилиты, мониторинг, LLM-ы, базы данных… Все в одном стеке.

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

Довольно элегантное решение объединяет оба мира: корневой файл docker-compose, включающий другие файлы. (каждый файл находится в подпапке приложений или служб). Таким образом, вы сохраняете глобальное представление о домашней лаборатории, но без необходимости разбираться в тысячестрочном YAML-файле, который невозможно прочитать.

Профили, группировка по функциям и большие домашние лаборатории.

Когда ваша домашняя лаборатория начинает приближаться к... 30, 40 или 50 услуг (включая службы резервного копирования, такие как базы данных, кэши или индексаторы) крайне важно навести в этом порядок. Именно здесь и возникает вопрос о том, что именно необходимо сделать. группировка по функциям как использование Профили Docker Compose.

Очень распространенный подход — группировать все в один «проект» Compose, но логически разделенный по профилям. Например:

• Основной профиль: ядро ​​домашней лаборатории, использующее Traefik в качестве обратного прокси и поставщика идентификации (например, OAuth или Authentik) для аутентификации всех приложений в одном домене по протоколу HTTPS.
• Медиа-профильТакие сервисы, как Plex, Sonarr, Radarr, Ombi, SABnzbd или qBittorrent, отвечают за подбор, загрузку и распространение мультимедийного контента.
• Профиль коммунальных услугДля управления контейнерами и мониторинга обновлений можно использовать такие инструменты, как Portainer, Watchtower (если используется), Diun, dockcheck или аналогичные.
• Профиль инфраструктуры/мониторингаTraefik, cAdvisor, Prometheus, Grafana, Uptime Kuma, Dozzle и все, что связано с мониторингом и логированием.
• Экспериментальные профили или LLM: специальные стеки для LLM-программ или необычных приложений (ChatGPT Next Web local, LibreOffice Online и т. д.), которые обычно отключены по умолчанию.

Прелесть профилей в том, что Вы можете запустить только часть инфраструктуры. Всё зависит от ваших потребностей. Например, вы можете запустить только профиль "ядро + инфраструктура" на маломощном мини-ПК, а профиль "медиа" — только на большом сервере с большим количеством дисков и графических процессоров.

В хорошо спроектированных репозиториях обычно присутствует docker-compose.yml со значением «master», которое добавляет включаемые файлы в отдельные папки apps/ или services/.Кроме того, почти все сервисы настраиваются через один файл. Глобальная переменная окружения .env и некоторые секреты в каталоге secrets/что значительно упрощает первоначальную настройку.

Следуя этой схеме, управление домашней лабораторией в основном сводится к следующему: Отредактируйте файл .env и секретные данные, включите или отключите профили и выберите, какие службы запускать на каждом хосте.Идеально подходит, если вы собираетесь развернуть один и тот же набор приложений на нескольких компьютерах.

Один большой файл docker-compose вместо нескольких маленьких файлов

Это вечный спор: Один файл docker-compose.yml, содержащий всё необходимое, или несколько файлов для каждого сервиса/стека? На самом деле ответ обычно звучит так: «Это зависит от того, чему вы отдаете приоритет: простоте миграции или ясности в отношении каждой услуги».

Кто защищает единый главный файл Обычно в нем выделяют несколько преимуществ:

• Перенести хостинг очень просто.Вы клонируете репозиторий, копируете файл .env и секреты, монтируете тома и запускаете `docker compose up -d`. Нет необходимости переходить по каталогам.
• Инфраструктура как свод законов истиныВся топология домашней лаборатории (сервисы, сети, тома, зависимости) находится в одном месте.
• Централизованные обновленияВы меняете версию образа, политику перезагрузки или какие-либо параметры ведения журналов, и точно знаете, куда нужно внести изменения.

Но у этого подхода есть и явные недостатки: огромный YAML-файл сложнее поддерживать. Конфликты из-за слияний участились. Когда дело доходит до отладки конкретной проблемы, вы обнаруживаете, что вам приходится работать с огромным массивом кода, насчитывающим сотни строк. Нередко, когда все становится слишком громоздким, возникает чувство сожаления.

Другой подход заключается в том, чтобы иметь один файл docker-compose.yml на каждое приложение или на каждый логический стекв рамках такой структуры, как:

docker/
├── bookstack/
│   └── docker-compose.yml
├── dashy/
│   └── docker-compose.yml
└── traefik/
    └── docker-compose.yml

Таким образом, каждый контейнер называется примерно так: bookstack-app-1 o traefik-reverse-proxy-1Это помогает быстро находить проблемы: если контейнер bookstack-app-1 аварийно завершает работу, вы точно знаете, в какой папке искать.

Визуально это гораздо чище и Это позволяет управлять каждой службой независимо. (запуск, остановка или обновление без влияния на остальные процессы). Кроме того, существуют такие приложения, как Dozzle, которые используют преимущества отдельных стеков для лучшей организации журналов.

Компромисс в том, что Если всё слишком сильно разделить, координация между общими сервисами (такими как Traefik или общие сети) потребует немного больше внимания.Внешние сети должны быть объявлены, должны использоваться специальные метки Traefik, и необходимо помнить номенклатуру сетей, созданных другими командами docker-compose.

Рекомендации по работе с файлами .env, переопределениями и системами контроля версий.

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

DB_USERNAME=myuser
DB_PASSWORD=secretpassword

А затем в файле YAML на них ссылаются следующим образом: ${DB_USERNAME} o ${DB_PASSWORD}Это позволяет быстро прочитать текст, что дает вам возможность совместное использование переменных в нескольких сервисах И самое главное, храните пароли в отдельном файле (который можно исключить из Git).

Это очень полезно для различных сред (производственная, тестовая, среда разработки). воспользуйтесь файлом docker-compose.override.ymlИдея состоит в том, чтобы иметь базовый файл docker-compose.yml и в настройках переопределения перезаписывать только то, что изменяется: порты, пути, флаги отладки…

Например, в режиме разработки можно загрузить переопределение, где Вы открываете другой порт, активируете режим отладки (DEBUG) и монтируете локальный исходный код.Вы не изменяете основной YAML-файл, но адаптируете стек к среде, в которой он запускается.

Очевидно, что Для того чтобы ваша домашняя лаборатория была хоть сколько-нибудь серьёзной, необходимо использовать Git для версионирования всего.Обычно у вас что-то вроде:

homelab-docker/
├── docker-compose.yml
├── .env.example
├── services/
│   ├── media/
│   ├── infra/
│   └── ...
└── scripts/

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

Сети, Traefik и доступ к защищенным сервисам.

Та же комбинация встречается почти во всех домашних лабораториях среднего уровня сложности: Traefik как обратный прокси и централизованный поставщик идентификационных данных (Auth или Authentik).Это позволяет размещать множество приложений на поддоменах с использованием HTTPS и единого входа (SSO).

Классический подход заключается в создании выделенной сети Docker, например. обратный_прокси или аналогичный подход, при котором Traefik и все веб-сервисы, которые вы собираетесь обслуживать извне, подключены друг к другу. Остальные контейнеры (базы данных, кэши и т. д.) остаются в изолированных внутренних сетях.

Если вы используете Traefik и разделяете свои сервисы на разные контейнеры docker-compose, вам потребуется... определить общую внешнюю сетьЧто-то вроде этого:

services:
  bookstack:
    image: lscr.io/linuxserver/bookstack
    networks:
      - traefik-net
    labels:
      - "traefik.docker.network=traefik_default"

networks:
  traefik-net:
    name: traefik_default
    external: true

Здесь сеть traefik_default создается стеком Traefik, а другие сервисы добавляются к ней через внешнюю сеть под названием traefik-net. Теги указывают Traefik... Какую сеть следует использовать для маршрутизации трафика?.

Когда единый стек включает в себя серверные сервисы (например, веб-контейнер и его базу данных), вы можете Подключите их к общей сети по умолчанию и предоставьте веб-контейнеру доступ только к сети Traefik.В базе данных будет указана метка traefik.enable=false, чтобы Traefik её игнорировал.

Такая конфигурация дает два ключевых преимущества: изоляция между службами и контролируемое воздействиеДоступ извне получают только те контейнеры, которые вы помечаете метками Traefik и которые находятся в прокси-сети.

Сохранение данных, тома и структура дисков.

Домашняя лаборатория без постоянного хранения данных малополезна: базы данных, конфигурации, медиафайлы, документы... всё должно сохраниться после завершения процесса docker compose down. Тома и переплетные крепления — это ваша страховка жизни..

Многие организуют хранение данных, используя подобную структуру:

/mnt/storage/
├── downloads/
│   ├── movies/
│   └── tv/
├── media/
│   ├── movies/
│   ├── tv/
│   └── music/
└── srv/
    └── 

Идея заключается в том, что Программы для скачивания (qBittorrent, SABnzbd и др.) видят только папку загрузок.Менеджеры файлов, такие как Radarr/Sonarr, имеют доступ как к загрузкам, так и к медиафайлам (для перемещения/создания жестких ссылок), а серверы, такие как Plex или Jellyfin, видят только папку с медиафайлами.

Таким образом, вы применяете принцип минимальная привилегияКаждый контейнер обращается только к тому, что ему действительно необходимо. Такое четкое разделение также помогает при принятии решения о том, какие тома или пути следует резервно копировать в облако или на внешние диски.

Каталог srv обычно используется для хранения конфигураций приложений (например, /srv/jellyfin/config, /srv/traefik, /srv/paperless и т. д.). Как правило, он частично версионируется (шаблоны, Caddyfile и т. д.), исключая все критически важные или ресурсоемкие файлы.

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

Автоматизация развертывания с помощью GitHub Actions и локальных исполнителей.

Если вы хотите вывести всё на новый уровень, вы можете пойти ещё дальше и Автоматизация обновлений домашней лаборатории с помощью CI/CDНекоторые пользователи заменили Jenkins и аналогичные инструменты рабочим процессом с использованием GitHub Actions и самостоятельно размещенного средства запуска в своей домашней лаборатории.

Механизм прост: каждый раз, когда вы отправляете изменения в основную ветку вашего репозитория Homelab, Запускается рабочий процесс GitHub Actions, который выполняет тесты, линтеры и, если все пройдет успешно, развертывает изменения на сервере..

Типичный рабочий процесс включает в себя такие этапы, как:

• Секретный сканер типа Gitleaks: на случай, если вы случайно загрузили пароли или токены в репозиторий.
• пыление в формате YAML или в коде инфраструктуры, для поддержания читаемого и согласованного формата.
• Обновление репозитория непосредственно в домашней лаборатории.: выполните команду `git pull` на целевом сервере.
• Контролируемое воссоздание контейнеровОстановите старые программы, запустите новые и проверьте их состояние.

Преимущества: дополнительная безопасность (вы контролируете утечки секретов), лучшее качество кода и Повторяемые развертывания с помощью одной отправкиА поскольку вы используете локальный раннер, образы и тома не покидают вашу сеть; вы просто используете интерфейс GitHub для визуализации конвейеров.

Почему Docker Compose так упрощает жизнь в домашней лаборатории

Многие люди годами полагались на Docker Run и Portainer до тех пор, пока в результате инцидента или миграции не будет вынуждена пересмотреть свой подход. Когда вы теряете хост или вынуждены переносить службы на другую машину, Использование только отдельных команд или конфигураций в Portainer — это ловушка..

Главное отличие при переходе на Compose заключается в том, что Всё описание услуги преобразуется в текст.Тома, порты, сети, метки, переменные… Все это в формате YAML, который можно копировать, совместно использовать, версионировать и повторно применять.

Редактирование сервиса больше не сводится к «пересозданию контейнера вручную» и становится Измените строку в файле, сохраните и запустите команду `docker compose up -d`.Вам не нужно запоминать исходную команду или пролистывать множество экранов Portainer.

Кроме того, если вы работаете с несколькими серверами (мини-ПК, NAS, настольные компьютеры), возможность иметь такие серверы крайне удобна. Скопируйте тот же файл compose на другую машину, измените четыре пути и запустите тот же стек на другом оборудовании.На самом деле, многие признают, что после неприятных ситуаций, связанных с потерей данных или хаотичной миграцией, Compose сэкономил им много времени в последующих случаях.

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

Оптимизация: контекст сборки, многоэтапные сборки и ресурсы.

Хотя многие контейнеры Homelab берутся из общедоступных образов, в некоторых случаях вам придётся компилировать собственные образы. В таких случаях важно проявлять осторожность. контекст сборкиНе отправляйте весь репозиторий без фильтрации, а ограничьтесь папкой проекта (с хорошим файлом .dockerignore), чтобы сборки были быстрыми и легковесными.

Ещё один очень полезный метод — это использование многоэтапные сборки В ваших Dockerfile: на первом этапе вы устанавливаете зависимости и компилируете, а на втором этапе копируете только необходимые артефакты в небольшой базовый образ. Результат: итоговые образы. намного меньше и безопаснеепотому что они не переносят цепочки инструментов или дополнительные библиотеки.

В разделе «Составление» у вас есть возможность определить Ограничения ЦП и ОЗУ (особенно в средах Swarm или когда Docker учитывает эти параметры), чтобы предотвратить монополизацию ресурсов ресурсоемким приложением. В домашних лабораториях это помогает предотвратить сбой в работе остальной системы из-за неправильно настроенной службы.

Не забывайте про политики перезапуска (restart: always, unless-stopped, on-failure): с помощью этих параметров вы гарантируете автоматический перезапуск критически важных служб (обратный прокси, VPN, базы данных ключей) после перезагрузки или однократного сбоя.

Наконец, неплохо было бы запланировать регулярную уборку с помощью таких команд, как... docker image prune, docker container prune и docker volume prune для удаления остатков старых сборок, остановленных контейнеров или "осиротевших" томов и, таким образом, освобождения дискового пространства.

Медицинские услуги, ведение учета и мониторинг

Чтобы ваша домашняя лаборатория не оказалась «чёрным ящиком», важно уделить внимание трём ключевым аспектам: проверки состояния здоровья, контролируемое ведение журналов и мониторингDocker Compose позволяет объявлять проверки работоспособности для каждой службы (используя команды типа curl -f http://localhost или специальные скрипты), которые определяют, считается ли контейнер работоспособным.

С помощью этого можно добиться того, чтобы Только "здоровые" контейнеры принимают транспорт. (например, через Traefik) и что, если они перестанут отвечать, они перезапустятся в соответствии с настроенной политикой. Это значительно повышает отказоустойчивость при минимальных усилиях.

Что касается логов, отредактируйте JSON-файл драйвера, указав ограничения. максимальный размер и максимальный размер файла Это предотвращает заполнение вашего диска гигабайтами забытых логов. Веб-инструменты, такие как Dozzle, позволяют просматривать логи всех контейнеров из браузера, что очень удобно для отладки конкретных служб.

Что касается метрик и непрерывного мониторинга, классическое сочетание выглядит следующим образом: cAdvisor + Прометей + ГрафанаcAdvisor предоставляет статистику использования ЦП, памяти, диска и сети для каждого контейнера; Prometheus собирает эти данные периодически, а Grafana отображает их в привлекательных панелях мониторинга с оповещениями в случае резкого увеличения нагрузки.

Хорошо оборудованная домашняя лаборатория обычно также включает в себя Kuma uptime для проверок доступности (HTTP, ICMP, TCP…) и автоматизированная система резервного копирования, такая как Duplicati, для копирования важных данных на другие диски или в облако. Таким образом, вы будете знать, что происходит, и, если что-то пойдет не так, вы не потеряете то, что важно.

Безопасность и удалённый доступ к домашней лаборатории

Каким бы самодельным ни было устройство, безопасность не является чем-то второстепенным. Многие люди выбирают... Не предоставляйте доступ к вашему сетевому хранилищу (NAS) или его службам напрямую извне.Ограничение удаленного доступа через VPN (WireGuard — очень популярный вариант благодаря своей производительности и простоте).

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

Те, кто предпочитает не управлять своим VPN самостоятельно, иногда прибегают к следующему способу: Туннель Cloudflare или Хвостовая чешуя Это удобные альтернативы, хотя, если для вас первостепенное значение имеет конфиденциальность, вам придется подумать, какие метаданные могут собирать эти третьи стороны.

Еще одна хорошая практика – Зашифруйте диски сервера и NAS.Регулярно устанавливайте патчи и ограничивайте автоматические обновления (многие избегают Watchtower, предпочитая контролируемые ручные обновления). Лучше немного отстать, но контролировать ситуацию, чем сломать половину Homelab из-за обновления, которое вы не проверили.

Как видите, вам не нужно достигать уровня «предприятия», но Да, целесообразно установить минимальные стандарты безопасности и дисциплины. чтобы ваша домашняя лаборатория не превратилась в решето или постоянный источник паники.

В конечном итоге, создание серьезной домашней лаборатории с помощью Docker Compose — это сочетание организованности, здравого смысла и готовности к экспериментам: если вы сгруппируете сервисы, хорошо определите сети, задокументируете все в Git и немного автоматизируете процесс, вы получите среду, которую можно запустить одной командой, легко перенести на другую машину и постепенно расширять, не превращая ее в неуправляемые джунгли.