Docker Compose в Homelab: организация, профили и най-добри практики

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

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

Сега, когато започнете да растете, се случват нещата: преминавате от това да имате два или три контейнера към... Десетки услуги, вътрешни мрежи, обратни прокси сървъри, бази данни и CI runnersТогава възниква големият въпрос: един гигантски Docker Compose или много малки файлове? Как да организирам профили, мрежи, резервни копия, сигурност и освен това да улесня миграцията?

Реални подходи за настройване на Docker Compose в домашна лаборатория

На практика, хората, които използват Homelabs от известно време, обикновено работят в рамките на три организационни модела на Compose, всеки със своите предимства и недостатъци. Изборът на правилния подход ви спестява много проблеми при разрастването или мигрирането на машини..

От едната страна е този, който е започнал с Docker Run започна свободно, след това премина към Portainer и накрая скочи към Docker Compose.Типично е: Portainer предлага отлична видимост, лесен за ползване интерфейс, шаблони и т.н., но в крайна сметка редактирането на сложни параметри или мигрирането на конфигурации се превръща в досадно, ако нямате нищо във файловете.

В противоположната крайност са тези, които е консолидирало всичко в един „мега“ docker-compose.yml файл способен да изпълнява абсолютно всички услуги на домашна лаборатория: обратен прокси, медия, помощни програми, мониторинг, LLM, бази данни… Всичко в един стек.

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

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

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

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

Много често срещан модел е всичко да се групира в един Compose „проект“, но логически разделен по профили. Например:

• Основен профил: ядро ​​на homelab, с 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“, който изтегля include-и към отделни файлове в папка 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

С това всеки контейнер се нарича нещо подобно приложение-за-книжни-стакове-1 o traefik-обратен-прокси-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... коя мрежа трябва да се използва за маршрутизиране на трафика.

Когато един стек включва backend услуги (например уеб контейнер и неговата база данни), можете Свържете ги към споделена мрежа по подразбиране и дайте на уеб контейнера достъп само до мрежата Traefik.Базата данни ще има етикет traefik.enable=false, така че Traefik да го игнорира.

Този тип настройка ви дава две ключови предимства: изолация между услугите и контролирано излаганеСамо контейнерите, които маркирате с етикети на Traefik и които са в прокси мрежата, стават достъпни отвън.

Съхранение на данни, обеми и структура на диска

Домашна лаборатория без постоянни данни не е много полезна: бази данни, конфигурации, медии, документи... всичко трябва да оцелее след композиране на Docker. Томовете и свързващите елементи са вашата животозастраховка.

Много хора организират съхранението си, използвайки структура като тази:

/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 могат да свързват изтеглени файлове, за да поддържат „sieding“ (зареждане), без да дублират дисково пространство. Дизайнът на директориите, предложен от ръководства като TRaSHGuides, се основава именно на това.

Автоматизиране на внедряванията с GitHub Actions и локални runners

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

Механизмът е прост: всеки път, когато изпращате промени към главния клон на вашето хранилище Homelab, Стартира се работен процес с действия в GitHub, който изпълнява тестове, линтери и, ако всичко върви добре, внедрява промените на сървъра..

Типичният работен процес включва стъпки като:

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

Предимства: допълнителна сигурност (контролирате изтичането на тайни), по-добро качество на кода и повтарящи се внедрявания с едно натисканеИ тъй като използвате локален runner, изображенията и томовете не напускат вашата мрежа; просто използвате интерфейса на GitHub, за да визуализирате каналите.

Защо Docker Compose прави живота в домашна лаборатория толкова по-лесен

Много хора са прекарали години, разчитайки на Docker Run и Portainer докато, в резултат на инцидент или миграция, не е принуден да преоцени подхода си. Когато загубите хост или се наложи да преместите услуги на друга машина, Да се ​​разчита само на изолирани команди или конфигурации в Portainer е капан.

Голямата разлика, когато преминете към Compose, е, че Цялото определение на услугата става текст.Томове, портове, мрежи, етикети, променливи… Всичко това в YAML, който можете да копирате, споделяте, версиирате и използвате повторно.

Редактирането на услуга вече не е свързано с „ръчно изграждане на контейнер“ и става Променете ред във файл, запазете го и изпълнете docker compose up -dНе е нужно да помните оригиналната команда или да кликвате през множество екрани на Portainer.

Освен това, ако работите с множество сървъри (мини компютри, NAS, настолни компютри), е изключително удобно да можете Копирайте същия файл за композиране на друга машина, коригирайте четири пътя и стартирайте същия стек с различен хардуер.Всъщност много хора признават, че след инцидент, свързан със загуба на данни или хаотични миграции, Compose им е спестил много време при последващи събития.

Като допълнителен бонус, създаването на нови услуги от стари става тривиално: например, клонирайте конфигурацията на Plex, за да монтирате Jellyfin Повторното използване на едни и същи медийни пътища и устройства за транскодиране отнема само няколко минути, ако го направите чрез копиране на YAML блокове.

Оптимизация: контекст на изграждане, многоетапни компилации и ресурси

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

Друга много полезна техника е да се прибегне до многоетапни конструкции Във вашите Dockerfiles: в първата фаза инсталирате зависимости и компилирате, а във втората фаза копирате само необходимите артефакти в малък базов образ. Резултат: финални изображения много по-малък и по-безопасензащото не пренасят набори от инструменти или допълнителни библиотеки.

От страната на писането имате възможност да дефинирате Ограничения на процесора и RAM паметта (особено в Swarm среди или когато Docker спазва тези параметри), за да се предотврати монополизирането на ресурси от приложение, изискващо много ресурси. В Homelabs това помага да се предотврати осакатяването на останалата част от системата от неправилно конфигурирана услуга.

Не забравяйте за правила за рестартиране (рестартиране: винаги, освен ако не е спряно, при повреда): с тях гарантирате, че критичните услуги (обратен прокси, VPN, ключови бази данни) се рестартират автоматично след рестартиране или еднократна повреда.

И накрая, добра идея е да планирате редовни задачи за почистване, като използвате команди като Подрязване на изображението на Docker, подрязване на контейнера на Docker и подрязване на тома на Docker за да се елиминират остатъци от стари компилации, спрени контейнери или осиротели томове и по този начин да се освободи дисково пространство.

Здравни услуги, регистриране и мониторинг

За да сте сигурни, че домашната ви лаборатория не е черна кутия, е важно да работите върху три ключови аспекта: проверки на състоянието, контролирано регистриране и наблюдениеDocker Compose ви позволява да декларирате проверки на състоянието (healthchecks) за всяка услуга (използвайки команди като curl -f http://localhost или специфични скриптове), които определят дали даден контейнер се счита за здрав.

С това можете да го направите така, че Само „здрави“ контейнери получават трафик (например чрез Traefik) и че ако спрат да отговарят, се рестартират според конфигурираната политика. Това значително увеличава устойчивостта с минимални усилия.

Относно лог файловете, коригирайте json-файла на драйвера с ограничения на максимален размер и максимален файл Това предотвратява запълването на диска ви с гигабайти забравени лог файлове. Уеб инструменти като Dozzle ви помагат да преглеждате лог файловете на всички контейнери от браузър, което е много удобно за отстраняване на грешки в специфични услуги.

Що се отнася до показателите и непрекъснатото наблюдение, класическата комбинация е cAdvisor + Prometheus + GrafanacAdvisor предоставя статистика за използването на процесора, паметта, диска и мрежата за всеки контейнер; Prometheus ги събира периодично, а Grafana ги показва в атрактивни табла за управление, с предупреждения, ако нещо се повиши.

Добре организираната домашна лаборатория обикновено включва и Kuma ъптайм за проверки на наличността (HTTP, ICMP, TCP…) и автоматизирана система за архивиране като Duplicati за копиране на критични данни на други дискове или в облака. По този начин знаете какво се случва и ако нещо се обърка, не губите това, което е важно.

Сигурност и отдалечен достъп до домашната лаборатория

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

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

Тези, които предпочитат да не управляват собствената си VPN, понякога прибягват до Тунел или скала на Cloudflare за достъп до домашната лаборатория без отваряне на портове. Това са удобни алтернативи, въпреки че ако вашият абсолютен приоритет е поверителността, ще трябва да вземете предвид какви метаданни могат да събират тези трети страни.

Друга добра практика е Криптирайте сървъра и NAS дисковетеПрилагайте редовно корекции и ограничете автоматичните актуализации (мнозина избягват Watchtower в полза на контролирани ръчни актуализации). По-добре е да сте малко назад, но с контрол, отколкото да разбиете половината Homelab заради актуализация, която не сте проверили.

Както виждате, не е нужно да достигате ниво „корпорация“, но Да, препоръчително е да се установят минимални стандарти за безопасност и дисциплина. така че домашната ви лаборатория да не е сито или постоянен източник на страхове.

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