Docker Compose dalam Homelab: organisasi, profil dan amalan terbaik

Informatec Digital » Sumber » Docker Compose dalam Homelab: organisasi, profil dan amalan terbaik

Menyediakan homelab moden dengan kontena telah menjadi hobi kegemaran ramai pakar teknologi. Docker Compose hampir sentiasa menjadi teras persediaan ini : tentukan perkhidmatan anda dalam YAML, versikannya dengan Git dan mulakan keseluruhan persekitaran anda dengan satu arahan.

Walau bagaimanapun, apabila anda mula berkembang, keadaan akan berubah: anda beralih daripada mempunyai dua atau tiga kontena kepada berpuluh-puluh perkhidmatan, rangkaian dalaman, proksi songsang, pangkalan data dan pelari CI . Ketika itulah persoalan besar timbul: satu contoh Docker Compose gergasi atau banyak fail kecil? Bagaimanakah saya boleh mengatur profil, rangkaian, sandaran, keselamatan dan di samping itu, memudahkan pemindahan?

Pendekatan dunia sebenar untuk menyediakan Docker Compose dalam makmal rumah

Dalam praktiknya, orang yang telah menggunakan Homelabs untuk seketika biasanya menggunakan tiga model organisasi Compose yang berbeza, setiap satunya dengan kelebihan dan kekurangannya sendiri. Memilih pendekatan yang betul menjimatkan banyak masalah semasa meningkatkan skala atau berhijrah ke mesin baharu.

Di satu pihak, terdapat mereka yang bermula dengan arahan Docker Run yang berdiri sendiri, kemudian beralih ke Portainer, dan akhirnya beralih ke Docker Compose . Ini senario biasa: Portainer menawarkan keterlihatan yang hebat, antara muka mesra pengguna, templat, dsb., tetapi akhirnya, mengedit parameter kompleks atau memindahkan konfigurasi menjadi menyusahkan jika anda tidak mempunyai apa-apa dalam fail.

Pada tahap yang bertentangan ialah pihak yang telah menggabungkan semuanya menjadi satu docker-compose.yml "mega" tunggal yang mampu menjalankan semua perkhidmatan homelab: proksi songsang, media, utiliti, pemantauan, LLM, pangkalan data... Semua dalam satu tindanan.

Di antara kedua-duanya, ramai pengguna menggunakan pendekatan campuran: beberapa fail docker-compose.yml kecil yang dikumpulkan mengikut konteks (cth., media, infrastruktur, produktiviti, pemantauan), semuanya di bawah repositori yang sama dan biasanya berkongsi pembolehubah persekitaran global.

Penyelesaian yang agak elegan menggabungkan kedua-dua dunia: docker-compose "root" yang merangkumi fail lain (setiap satu dalam subfolder aplikasi atau perkhidmatan). Dengan cara ini anda mengekalkan pandangan global homelab, tetapi tanpa perlu melalui fail YAML seribu baris yang mustahil untuk dibaca.

Profil, pengelompokan mengikut fungsi dan makmal rumah yang besar

Apabila homelab anda mula menghampiri 30, 40 atau 50 perkhidmatan (termasuk perkhidmatan sandaran seperti pangkalan data, cache atau pengindeks), adalah penting untuk mengaturnya. Di sinilah kedua-dua pengelompokan mengikut fungsi dan penggunaan profil Docker Compose memainkan peranan.

Satu corak yang sangat biasa adalah mengumpulkan semuanya ke dalam satu "projek" Compose, tetapi dibahagikan secara logik mengikut profil. Contohnya:

• Profil teras: teras homelab, dengan Traefik sebagai proksi songsang dan pembekal identiti (cth., OAuth atau Authentik) untuk mengesahkan semua aplikasi di bawah domain yang sama dengan HTTPS.
• Profil mediaPerkhidmatan seperti Plex, Sonarr, Radarr, Ombi, SABnzbd atau qBittorrent, bertanggungjawab untuk mengurus, memuat turun dan menayangkan kandungan multimedia.
• Profil UtilitiAlatan seperti Portainer, Watchtower (jika digunakan), Diun, dockcheck atau yang serupa untuk mengurus dan memantau kontena dan kemas kini.
• Profil infrastruktur/pemantauan: Traefik, cAdvisor, Prometheus, Grafana, Uptime Kuma, Dozzle dan semua yang berkaitan dengan pemantauan dan pembalakan.
• Profil eksperimen atau LLM: tindanan khusus untuk LLM atau aplikasi yang ingin tahu (ChatGPT Next Web local, LibreOffice Online, dsb.) yang biasanya dinyahdayakan secara lalai.

Keindahan profil ialah anda hanya boleh menggunakan sebahagian daripada infrastruktur mengikut keperluan. Contohnya, anda hanya boleh menjalankan profil teras + infrastruktur pada PC mini berkuasa rendah dan hanya menggunakan profil media pada pelayan besar dengan lebih banyak cakera dan GPU.

Dalam repositori yang direka bentuk dengan baik, biasanya terdapat fail "master" docker-compose.yml pada root yang menggunakan include untuk menolak fail individu ke dalam folder apps/ atau services/ . Di samping itu, hampir semua perkhidmatan dikonfigurasikan melalui fail .env global tunggal, dan beberapa rahsia disimpan dalam direktori secrets/ , yang sangat memudahkan persediaan awal.

Mengikuti corak ini, mengurus homelab pada asasnya bermuara pada penyuntingan fail dan rahsia .env, mendayakan atau melumpuhkan profil dan memutuskan perkhidmatan mana yang hendak dimulakan pada setiap hos . Ini sesuai jika anda akan menggunakan set aplikasi yang sama merentasi berbilang mesin.

Satu fail penyusun docker tunggal gergasi berbanding beberapa fail kecil

Ini perdebatan abadi: satu fail docker-compose.yml yang mengandungi semuanya, atau berbilang fail setiap perkhidmatan/tindanan? Jawapan sebenar biasanya "ia bergantung pada apa yang anda ingin utamakan: kesederhanaan migrasi atau kejelasan setiap perkhidmatan."

Mereka yang menyokong fail induk tunggal biasanya mengetengahkan beberapa kelebihan:

• Migrasi hos sangat mudahAnda mengklon repositori, menyalin fail .env dan rahsia, memasang jilid dan menjalankan `docker compose up -d`. Tidak perlu pergi ke direktori demi direktori.
• Infrastruktur sebagai kod kebenaran: keseluruhan topologi homelab (perkhidmatan, rangkaian, isipadu, kebergantungan) berada di satu tempat.
• Kemas kini berpusat: anda menukar versi imej, dasar but semula atau beberapa pembalakan dan anda tahu dengan tepat di mana hendak disentuh.

Tetapi ia juga mempunyai kelemahan yang jelas: fail YAML yang besar lebih sukar diselenggara, konflik penggabungan meningkat, dan apabila menyahpepijat masalah tertentu, anda mendapati diri anda menavigasi ratusan baris yang besar. Bukan sesuatu yang luar biasa untuk berasa sedikit menyesal apabila semuanya menjadi terlalu besar.

Pendekatan lain adalah untuk mempunyai fail docker-compose.yml setiap aplikasi atau setiap susunan logik , dalam struktur seperti ini:

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

Dengan ini, setiap bekas dinamakan seperti bookstack-app-1 atau traefik-reverse-proxy-1 , yang membantu anda mencari masalah dengan cepat: jika bekas bookstack-app-1 ranap, anda tahu dengan tepat folder mana yang hendak dicari.

Secara visual, ia jauh lebih bersih dan membolehkan anda mengurus setiap perkhidmatan secara bebas (memulakan, menghentikan atau mengemas kininya tanpa menjejaskan yang lain). Tambahan pula, aplikasi seperti Dozzle memanfaatkan tindanan berasingan untuk mengatur log dengan lebih baik.

Kelemahannya ialah jika anda terlalu banyak mengasingkan semuanya, penyelarasan antara perkhidmatan biasa (seperti Traefik atau rangkaian kongsi) memerlukan sedikit lebih perhatian : anda perlu mengisytiharkan rangkaian luaran, label Traefik tertentu dan mengingati tatanama rangkaian yang dicipta oleh docker-compose lain.

Amalan terbaik dengan .env, penggantian dan kawalan versi

Salah satu helah yang paling dipandang rendah ialah memusatkan konfigurasi dalam fail .env . Daripada membanjiri docker-compose.yml anda dengan pembolehubah persekitaran, anda mentakrifkan sesuatu seperti ini:

DB_USERNAME=myuser
DB_PASSWORD=secretpassword

Dan kemudian dalam YAML, ia dirujuk sebagai ${DB_USERNAME} atau ${DB_PASSWORD} . Ini menjadikan Compose boleh dibaca sepintas lalu, membolehkan anda berkongsi pembolehubah antara berbilang perkhidmatan dan, yang paling penting, menyimpan kata laluan dalam fail berasingan (yang boleh anda kecualikan daripada Git).

Untuk persekitaran yang berbeza (pengeluaran, pengujian, pembangunan), adalah sangat berguna untuk memanfaatkan docker-compose.override.yml . Ideanya adalah untuk mempunyai fail docker-compose.yml asas dan, dalam penggantian, hanya penggantian apa yang berubah: port, laluan, bendera debug, dsb.

Contohnya, dalam pembangunan, anda boleh memuatkan penggantian di mana anda mendedahkan port yang berbeza, mendayakan penyahpepijatan dan memasang kod sumber setempat . Anda tidak menyentuh YAML utama tetapi anda menyesuaikan tindanan dengan persekitaran tempat anda menjalankannya.

Jelas sekali, pemformatan semuanya dengan Git adalah wajib jika anda mahu homelab anda menjadi profesional . Anda biasanya akan mempunyai sesuatu seperti ini:

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

Dari situ, anda memulakan repositori, melakukan perubahan infrastruktur dan jika ada masalah, anda boleh kembali kepada versi Compose anda yang sebelumnya dalam beberapa saat . Untuk homelab yang bercita-cita tinggi, ini bukan sekadar pilihan; ia satu-satunya cara untuk mengelakkan daripada menjadi gila.

Rangkaian, Traefik dan pendedahan perkhidmatan selamat

Dalam hampir semua homelab yang sederhana maju, kombinasi yang sama muncul: Traefik sebagai proksi songsang dan penyedia identiti berpusat (Auth atau Authentik) . Ini membolehkan pendedahan banyak aplikasi di bawah subdomain dengan HTTPS dan SSO.

Pendekatan klasik adalah dengan menyediakan rangkaian Docker khusus, seperti reverse_proxy atau yang serupa, di mana Traefik dan semua perkhidmatan web yang akan anda layani secara luaran disambungkan. Bekas yang tinggal (pangkalan data, cache, dll.) kekal pada rangkaian dalaman yang terpencil.

Jika anda menggunakan Traefik dan mengasingkan perkhidmatan anda kepada contoh Docker Compose yang berbeza, anda perlu mentakrifkan rangkaian luaran yang dikongsi . Sesuatu seperti ini:

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

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

Di sini, rangkaian traefik_default dicipta oleh tindanan Traefik dan perkhidmatan lain ditambah kepadanya melalui rangkaian luaran yang dipanggil traefik-net. Label memberitahu Traefik rangkaian mana yang hendak digunakan untuk penghalaan trafik.

Apabila satu tindanan merangkumi perkhidmatan backend (contohnya, bekas web dan pangkalan datanya), anda boleh menyambungkannya ke rangkaian lalai yang dikongsi dan hanya memberikan akses kepada bekas web tersebut kepada rangkaian Traefik . Pangkalan data akan mempunyai label yang ditetapkan kepada `traefik.enable=false` supaya Traefik mengabaikannya.

Persediaan jenis ini menawarkan dua faedah utama: pengasingan antara perkhidmatan dan pendedahan terkawal . Hanya bekas yang anda labelkan dengan label Traefik dan yang berada pada rangkaian proksi boleh diakses dari luar.

Kegigihan data, isipadu dan struktur cakera

Sebuah makmal rumah tanpa data berterusan tidak begitu berguna: pangkalan data, konfigurasi, media, dokumen… semuanya perlu bertahan daripada Docker Compose Down. Volume dan bind mount adalah talian hayat anda.

Ramai orang mengatur storan mereka menggunakan struktur seperti ini:

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

Ideanya ialah pemuat turun (qBittorrent, SABnzbd, dll.) hanya melihat folder muat turun , pengurus seperti Radarr/Sonarr mempunyai akses kepada muat turun dan media (untuk memindahkan/mencipta pautan keras), dan pelayan seperti Plex atau Jellyfin hanya melihat folder media.

Dengan cara ini anda menggunakan prinsip keistimewaan paling rendah : setiap bekas hanya mengakses apa yang sebenarnya diperlukan. Dan pemisahan yang jelas juga membantu apabila menentukan volum atau laluan mana yang hendak disandarkan ke awan atau pemacu luaran.

Direktori srv biasanya digunakan untuk menyimpan konfigurasi aplikasi (contohnya, /srv/jellyfin/config, /srv/traefik, /srv/paperless, dll.). Ini biasanya sebahagiannya diversikan (templat, Caddyfile, dll.), meninggalkan apa-apa yang penting atau memerlukan sumber yang banyak.

Dalam sesetengah kes, adalah berguna untuk menggunakan pautan keras dalam rantaian muat turun: perkhidmatan seperti Radarr atau Sonarr boleh memautkan fail yang dimuat turun untuk mengekalkan pembenihan tanpa menduplikasi ruang cakera. Struktur direktori yang dicadangkan oleh panduan seperti TRaSHGuides adalah berdasarkan prinsip ini.

Mengautomasikan penggunaan dengan GitHub Actions dan pelari setempat

Jika anda ingin melangkah lebih jauh, anda boleh mengautomasikan kemas kini homelab dengan CI/CD . Beberapa pengguna telah menggantikan Jenkins dan alatan serupa dengan aliran kerja menggunakan GitHub Actions dan pelari yang dihoskan sendiri dalam homelab itu sendiri.

Mekanismenya mudah: setiap kali anda menekan ke cabang utama repo homelab anda, aliran kerja GitHub Actions dilancarkan yang menjalankan ujian, melakukan lintering dan, jika semuanya berjalan lancar, akan menggunakan perubahan pada pelayan.

Aliran kerja biasa merangkumi langkah-langkah seperti:

• Pengimbas rahsia jenis Gitleaks: sekiranya anda telah memuat naik kata laluan atau token secara tidak sengaja ke repo.
• lapisan YAML atau kod infrastruktur, untuk mengekalkan format yang boleh dibaca dan konsisten.
• Mengemas kini repositori dalam homelab itu sendiri: git tarik pada pelayan sasaran.
• Pengubahsuaian kontena yang terkawal: hentikan yang lama, lancarkan yang baharu dan semak statusnya.

Kelebihan: keselamatan tambahan (anda mengawal kebocoran rahsia), kualiti kod yang lebih baik dan penggunaan berulang dengan satu tekan . Dan memandangkan anda menggunakan pelari setempat, imej dan jilid tidak meninggalkan rangkaian anda; anda hanya memanfaatkan antara muka GitHub untuk menggambarkan saluran paip.

Mengapa Docker Compose menjadikan kehidupan lebih mudah di makmal rumah

Ramai orang telah menghabiskan masa bertahun-tahun bergantung pada Docker Run dan Portainer sehingga, selepas insiden atau migrasi, mereka terpaksa menilai semula pendekatan mereka. Apabila anda kehilangan hos atau terpaksa memindahkan perkhidmatan ke mesin lain, bergantung pada arahan atau konfigurasi terpencil semata-mata dalam Portainer adalah satu perangkap.

Perbezaan besar apabila anda bertukar kepada Compose ialah keseluruhan definisi perkhidmatan menjadi teks : jilid, port, rangkaian, label, pembolehubah… Semua dalam fail YAML yang boleh anda salin, kongsi, versi dan guna semula.

Mengedit perkhidmatan bukan lagi tentang "membina semula bekas dengan tangan"; ia kini tentang mengubah suai baris dalam fail, menyimpan dan menjalankan `docker compose up -d` . Anda tidak perlu mengingati arahan asal atau mengklik berbilang skrin Portainer.

Tambahan pula, jika anda bekerja dengan berbilang pelayan (mini PC, NAS, desktop), adalah sangat mudah untuk menyalin fail Compose yang sama ke mesin lain, melaraskan empat laluan dan menjalankan tindanan yang sama pada perkakasan yang berbeza . Malah, ramai orang mengakui bahawa, selepas ketakutan yang melibatkan kehilangan data atau migrasi yang huru-hara, Compose telah menjimatkan banyak masa mereka dalam peristiwa berikutnya.

Sebagai bonus tambahan, membina perkhidmatan baharu daripada perkhidmatan lama menjadi mudah: contohnya, pengklonan konfigurasi Plex untuk menyediakan Jellyfin dengan menggunakan semula laluan media yang sama dan peranti transkoding hanya mengambil masa beberapa minit jika anda melakukannya dengan menyalin blok YAML.

Pengoptimuman: konteks binaan, binaan berbilang peringkat dan sumber

Walaupun banyak kontena Homelab datang daripada imej awam, dalam beberapa kes anda perlu mengkompilasi sendiri. Dalam keadaan ini, adalah penting untuk mengurus konteks binaan anda : jangan muat naik keseluruhan repositori tanpa ditapis, sebaliknya hadkan diri anda pada folder projek anda (menggunakan arahan `.dockerignore` yang kuat) untuk memastikan binaan yang pantas dan ringan.

Satu lagi teknik yang sangat berguna adalah dengan menggunakan binaan berbilang peringkat dalam Dockerfiles anda: pada peringkat pertama anda memasang kebergantungan dan mengkompilasi, dan pada peringkat kedua anda hanya menyalin artifak yang diperlukan ke imej asas yang kecil. Hasilnya: imej akhir yang jauh lebih kecil dan lebih selamat , kerana ia tidak membawa rantai alat atau pustaka yang tidak diperlukan.

Di bahagian Compose, anda mempunyai pilihan untuk menentukan had CPU dan RAM (terutamanya dalam persekitaran Swarm atau apabila Docker mematuhi parameter tersebut) untuk mengelakkan aplikasi intensif sumber daripada memonopoli sumber. Dalam Homelabs, ini membantu mencegah perkhidmatan yang salah konfigurasi daripada melumpuhkan seluruh sistem.

Jangan lupa dasar mula semula (mulakan semula: sentiasa, melainkan-dihentikan, semasa-gagal): dengannya anda memastikan bahawa perkhidmatan kritikal (proksi songsang, VPN, pangkalan data utama) dimulakan semula secara automatik selepas but semula atau kegagalan sekali sahaja.

Akhir sekali, adalah dinasihatkan untuk menjadualkan tugas pembersihan berkala dengan arahan seperti docker image prune, docker container prune dan docker volume prune untuk mengalih keluar sisa-sisa binaan lama, bekas yang dihentikan atau jilid yatim piatu dan dengan itu memulihkan ruang cakera.

Perkhidmatan kesihatan, pembalakan dan pemantauan

Untuk mengelakkan homelab anda daripada menjadi kotak hitam, adalah penting untuk mengendalikan tiga aspek utama: pemeriksaan kesihatan, pembalakan terkawal dan pemantauan . Docker Compose membolehkan anda mengisytiharkan pemeriksaan kesihatan setiap perkhidmatan (menggunakan arahan seperti `curl -f http://localhost` atau skrip tertentu) yang menentukan sama ada sesuatu bekas itu sihat.

Ini membolehkan anda memastikan bahawa hanya kontena "sihat" yang menerima trafik (contohnya, melalui Traefik) dan jika ia berhenti bertindak balas, ia akan dimulakan semula mengikut dasar yang dikonfigurasikan. Ini meningkatkan daya tahan dengan ketara dengan usaha yang minimum.

Berkenaan log, melaraskan pemacu fail json dengan had saiz maksimum dan fail maksimum menghalang cakera daripada dipenuhi dengan gigabait log yang dilupakan. Alatan web seperti Dozzle membantu anda menyemak imbas log semua bekas daripada pelayar, yang sangat mudah untuk menyahpepijat perkhidmatan tertentu.

Untuk metrik dan pemantauan berterusan, kombinasi klasik ialah cAdvisor + Prometheus + Grafana . cAdvisor mendedahkan statistik penggunaan CPU, memori, cakera dan rangkaian bagi setiap bekas; Prometheus mengumpulnya secara berkala dan Grafana memaparkannya dalam papan pemuka yang menarik, dengan makluman jika ada lonjakan.

Homelab yang disediakan dengan baik biasanya merangkumi Uptime Kuma untuk semakan ketersediaan (HTTP, ICMP, TCP, dll.) dan sistem sandaran automatik seperti Duplicati untuk menyalin data penting ke cakera lain atau awan. Dengan cara ini, anda tahu apa yang berlaku dan jika berlaku sesuatu yang tidak kena, anda tidak akan kehilangan apa yang penting.

Keselamatan dan akses jarak jauh ke makmal rumah

Walau bagaimanapun, persediaan DIY, keselamatan bukanlah pilihan. Ramai orang memilih untuk tidak mendedahkan NAS atau perkhidmatannya secara langsung kepada dunia luar , mengehadkan akses jarak jauh melalui VPN (WireGuard ialah pilihan yang sangat popular kerana prestasi dan kesederhanaannya).

Dalam model ini, penghala bertindak sebagai pintu masuk: hanya port rawak yang dibuka ke pelayan VPN dan setelah disambungkan, semua permintaan ke perkhidmatan dalaman melalui terowong yang disulitkan . Traefik mahupun aplikasi tidak didedahkan ke internet tanpa penapisan terlebih dahulu ini.

Mereka yang lebih suka tidak mengurus VPN mereka sendiri kadangkala menggunakan Cloudflare Tunnel atau Tailscale untuk mengakses makmal rumah mereka tanpa membuka port. Ini adalah alternatif yang mudah, walaupun jika privasi adalah keutamaan utama anda, anda perlu mempertimbangkan metadata yang mungkin dikumpul oleh pihak ketiga ini.

Satu lagi amalan yang baik adalah dengan menyulitkan pelayan dan cakera NAS , menggunakan tampalan secara berkala dan mengehadkan kemas kini automatik (ramai yang mengelakkan Watchtower dan memilih kemas kini manual terkawal). Lebih baik ketinggalan sedikit tetapi mempunyai kawalan daripada merosakkan separuh daripada Homelab kerana kemas kini yang belum anda semak.

Seperti yang anda lihat, anda tidak perlu mencapai tahap "perusahaan", tetapi adalah dinasihatkan untuk menetapkan tahap keselamatan dan disiplin minimum supaya makmal rumah anda bukan tempat penapis atau sumber ketakutan yang berterusan.

Akhirnya, menyediakan homelab yang serius dengan Docker Compose adalah gabungan organisasi, akal sehat, dan kesediaan untuk mengubah suai: jika anda mengumpulkan perkhidmatan, menentukan rangkaian dengan baik, mendokumentasikan dalam Git, dan mengautomasikan sedikit, anda akan mendapat persekitaran yang boleh anda mulakan dengan satu arahan, berhijrah ke mesin lain dengan mudah, dan mengembangkan sedikit demi sedikit tanpa ia menjadi hutan yang tidak terkawal.