Docker Compose dalam Homelab: organisasi, profil dan amalan terbaik

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

Membina makmal rumah moden dengan kontena perkapalan telah menjadi hobi kegemaran ramai orang teknologi. Docker Compose hampir sentiasa menjadi teras persediaan ituTentukan perkhidmatan anda dalam YAML, versikannya dengan Git, dan anda boleh memulakan seluruh persekitaran anda dengan satu arahan.

Sekarang, apabila anda mula membesar, perkara berlaku: anda beralih daripada mempunyai dua atau tiga bekas kepada Berpuluh-puluh perkhidmatan, rangkaian dalaman, proksi songsang, pangkalan data dan pelari CIKetika itulah persoalan besar timbul: satu 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 beroperasi dalam tiga model organisasi Compose, setiap satunya dengan kelebihan dan kekurangannya sendiri. Memilih pendekatan yang betul dapat menjimatkan banyak masalah semasa menanam atau memindahkan mesin..

Di satu pihak terdapat orang yang memulakan dengan Docker Run bermula longgar, kemudian beralih ke Portainer, dan akhirnya beralih ke Docker Compose.Ia tipikal: Portainer menawarkan keterlihatan yang hebat, antara muka mesra pengguna, templat, dan sebagainya, tetapi pada akhirnya, penyuntingan parameter kompleks atau pemindahan konfigurasi menjadi menyusahkan jika anda tidak mempunyai apa-apa dalam fail.

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

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

Penyelesaian yang agak elegan menggabungkan kedua-dua dunia: penyusun dok akar 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 makmal rumah anda mula hampir 30, 40 atau 50 perkhidmatan (termasuk perkhidmatan sandaran seperti pangkalan data, cache atau pengindeks) adalah penting untuk memastikan perkara ini teratur. Di sinilah kedua-dua pengelompokan mengikut fungsi seperti penggunaan Profil Docker Compose.

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 melancarkan sebahagian daripada infrastruktur Bergantung pada keperluan anda. Contohnya, anda hanya boleh menjalankan profil teras + infrastruktur pada PC mini berkuasa rendah dan hanya menjalankan profil media pada pelayan besar dengan lebih banyak cakera dan GPU.

Dalam repositori yang direka bentuk dengan baik, biasanya terdapat docker-compose.yml “master” yang menarik sertakan ke fail individu dalam folder apps/ atau services/Tambahan pula, hampir semua perkhidmatan dikonfigurasikan melalui satu fail. .env global dan beberapa rahsia dalam direktori secrets/, yang sangat memudahkan persediaan awal.

Mengikuti corak ini, pengurusan makmal di rumah pada asasnya dikurangkan kepada Edit fail dan rahsia .env, dayakan atau lumpuhkan profil dan tentukan perkhidmatan mana yang hendak dimulakan pada setiap hos.Ideal jika anda akan menggunakan set aplikasi yang sama pada berbilang komputer.

Satu fail penyusun docker tunggal gergasi berbanding beberapa fail kecil

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

Siapakah yang mempertahankan fail induk tunggal Ia biasanya menonjolkan 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 untuk diselenggara, Konflik penggabungan meningkat Apabila melibatkan penyahpepijatan masalah tertentu, anda mendapati diri anda sedang menavigasi ratusan baris yang rumit. Bukan sesuatu yang luar biasa untuk berasa sedikit menyesal apabila semuanya menjadi terlalu besar.

Pendekatan lain adalah dengan mempunyai satu docker-compose.yml setiap aplikasi atau setiap tindanan logik, dalam struktur seperti:

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

Dengan ini, setiap bekas dipanggil sesuatu seperti aplikasi-timbunan-buku-1 o proksi-terbalik-traefik-1yang membantu anda mencari masalah dengan cepat: jika bekas bookstack-app-1 ranap, anda tahu dengan tepat folder mana yang hendak dicari.

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

Tradeoff adalah bahawa Jika anda terlalu banyak mengasingkan semuanya, penyelarasan antara perkhidmatan biasa (seperti Traefik atau rangkaian kongsi) memerlukan sedikit lebih perhatian.: rangkaian luaran mesti diisytiharkan, label Traefik tertentu mesti digunakan dan tatanama rangkaian yang dicipta oleh docker-compose lain mesti diingati.

Amalan terbaik dengan .env, penggantian dan kawalan versi

Salah satu helah yang paling dipandang remeh ialah pusatkan konfigurasi dalam fail .envDaripada membanjiri docker-compose.yml anda dengan pembolehubah persekitaran, anda mentakrifkan sesuatu seperti ini:

DB_USERNAME=myuser
DB_PASSWORD=secretpassword

Dan kemudian dalam YAML mereka dirujuk sebagai ${DB_USERNAME} o ${DB_PASSWORD}Ini menjadikan karangan boleh dibaca sepintas lalu, membolehkan anda kongsi pembolehubah merentasi pelbagai perkhidmatan Dan yang paling penting, simpan kata laluan dalam fail berasingan (yang boleh anda kecualikan daripada Git).

Ia sangat berguna untuk persekitaran yang berbeza (pengeluaran, pengujian, pembangunan). manfaatkan docker-compose.override.ymlIdeanya adalah untuk mempunyai fail docker-compose.yml asas dan, dalam penggantian, hanya tulis ganti apa yang berubah: port, laluan, bendera debug…

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

Jelas sekali, Mengubah versi semuanya dengan Git adalah wajib jika anda mahu homelab anda menjadi jauh lebih serius.Anda biasanya mempunyai sesuatu seperti:

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

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

Rangkaian, Traefik dan pendedahan perkhidmatan selamat

Gabungan yang sama muncul dalam hampir semua makmal rumah yang sederhana maju: Traefik sebagai proksi terbalik dan penyedia identiti berpusat (Auth atau Authentik)Ini membolehkan anda mendedahkan banyak aplikasi di bawah subdomain dengan HTTPS dan SSO.

Corak klasik adalah untuk menyediakan rangkaian Docker khusus, contohnya proksi_terbalik atau yang serupa, di mana Traefik dan semua perkhidmatan web yang akan anda layani secara luaran disambungkan. Bekas yang lain (pangkalan data, cache, dll.) kekal pada rangkaian dalaman yang terpencil.

Jika anda menggunakan Traefik dan memisahkan perkhidmatan anda kepada docker-compose yang berbeza, anda perlu tentukan rangkaian luaran yang dikongsiSesuatu seperti itu:

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. Tag tersebut memberitahu Traefik... rangkaian yang manakah harus digunakan untuk menghalakan trafik.

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

Persediaan jenis ini memberi anda dua faedah utama: pengasingan antara perkhidmatan dan pendedahan terkawalHanya bekas yang anda tandakan dengan label Traefik dan yang berada pada rangkaian proksi boleh diakses dari luar.

Kegigihan data, isipadu dan struktur cakera

Homelab tanpa data berterusan tidak begitu berguna: pangkalan data, konfigurasi, media, dokumen... semuanya perlu bertahan daripada penyusunan docker. Jilid dan tempat pengikat adalah insurans hayat anda.

Ramai orang mengatur storan mereka menggunakan struktur seperti ini:

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

Ideanya adalah bahawa Pemuat turun (qBittorrent, SABnzbd, dll.) hanya melihat folder muat turunPengurus 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 mengaplikasikan prinsip keistimewaan minimumSetiap kontena hanya mengakses apa yang sebenarnya diperlukan. Dan pemisahan yang jelas ini juga membantu apabila menentukan volum atau laluan mana yang hendak disandarkan ke pemacu awan atau 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 beberapa kes, ia menarik untuk digunakan pautan keras Dalam rantaian muat turun: perkhidmatan seperti Radarr atau Sonarr boleh memautkan fail yang dimuat turun untuk mengekalkan pembenihan tanpa menduplikasi ruang cakera. Reka bentuk direktori yang dicadangkan oleh panduan seperti TRaSHGuides adalah berdasarkan perkara ini.

Mengautomasikan penggunaan dengan GitHub Actions dan pelari setempat

Jika anda ingin membawa sesuatu ke peringkat seterusnya, anda boleh melangkah lebih jauh dan Automatikkan kemas kini makmal rumah menggunakan CI/CDBeberapa pengguna telah menggantikan Jenkins dan alatan serupa dengan aliran kerja menggunakan GitHub Actions dan pelari yang dihoskan sendiri dalam homelab mereka sendiri.

Mekanismenya mudah: setiap kali anda tekan ke cawangan 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 tolakanDan memandangkan anda menggunakan pelari setempat, imej dan jilid tidak akan meninggalkan rangkaian anda; anda hanya menggunakan antara muka GitHub untuk menggambarkan saluran paip.

Mengapa Docker Compose menjadikan kehidupan lebih mudah di makmal rumah

Ramai orang telah bertahun-tahun bergantung pada Docker Run dan Portainer sehingga, akibat insiden atau migrasi, ia terpaksa menilai semula pendekatannya. Apabila anda kehilangan hos atau terpaksa memindahkan perkhidmatan ke mesin lain, Bergantung pada arahan atau konfigurasi terpencil hanya dalam Portainer adalah satu perangkap.

Perbezaan besar apabila anda bertukar kepada Compose ialah Keseluruhan definisi perkhidmatan menjadi teks.Isipadu, port, rangkaian, label, pembolehubah… Semuanya dalam YAML yang boleh anda salin, kongsi, versi dan guna semula.

Mengedit perkhidmatan bukan lagi tentang "membina semula bekas dengan tangan" dan menjadi ubah suai baris dalam fail, simpan dan jalankan docker compose up -dAnda tidak perlu mengingati arahan asal atau mengklik berbilang skrin Portainer.

Tambahan pula, jika anda bekerja dengan berbilang pelayan (mini PC, NAS, desktop), ia sangat mudah untuk dapat Salin fail karang yang sama ke mesin lain, laraskan empat laluan dan lancarkan tindanan yang sama dengan 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 acara-acara berikutnya.

Sebagai bonus tambahan, mewujudkan perkhidmatan baharu daripada perkhidmatan lama menjadi mudah: contohnya, klon konfigurasi Plex untuk memasang Jellyfin Menggunakan semula laluan media dan peranti transkoding yang sama 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 akan menyusun imej anda sendiri. Dalam kes tersebut, adalah penting untuk berhati-hati. bina konteksJangan hantar keseluruhan repositori tanpa penapis, tetapi hadkan diri anda kepada folder projek (dengan .dockerignore yang baik) supaya binaan pantas dan ringan.

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

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

Jangan lupa tentang mulakan semula dasar (mulakan semula: sentiasa, melainkan dihentikan, semasa kegagalan): dengan ini 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 idea yang baik untuk menjadualkan tugas pembersihan tetap menggunakan arahan seperti imej docker prun, prun bekas docker dan prun isipadu docker untuk menghapuskan sisa-sisa binaan lama, bekas yang dihentikan atau jilid yatim piatu dan dengan itu memulihkan ruang cakera.

Perkhidmatan kesihatan, pembalakan dan pemantauan

Untuk memastikan makmal rumah anda bukan kotak hitam, adalah penting untuk menangani tiga aspek utama: pemeriksaan kesihatan, pembalakan dan pemantauan terkawalDocker Compose membolehkan anda mengisytiharkan pemeriksaan kesihatan setiap perkhidmatan (menggunakan arahan seperti curl -f http://localhost atau skrip tertentu) yang menentukan sama ada bekas dianggap sihat.

Dengan ini anda boleh membuatnya supaya Hanya kontena "sihat" yang menerima trafik (contohnya, melalui Traefik) dan jika mereka berhenti bertindak balas, mereka akan memulakan semula mengikut dasar yang dikonfigurasikan. Ini meningkatkan daya tahan dengan ketara dengan usaha yang minimum.

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

Berkenaan metrik dan pemantauan berterusan, kombinasi klasiknya ialah cAdvisor + Prometheus + GrafanacAdvisor mendedahkan statistik penggunaan CPU, memori, cakera dan rangkaian bagi setiap kontena; Prometheus mengumpulnya secara berkala dan Grafana memaparkannya dalam papan pemuka yang menarik, dengan amaran jika sesuatu berlaku secara mendadak.

Makmal rumah yang disediakan dengan baik biasanya juga merangkumi Waktu operasi Kuma untuk semakan ketersediaan (HTTP, ICMP, TCP…) dan sistem sandaran automatik seperti Duplicati untuk menyalin data kritikal 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 itu dibuat sendiri, keselamatan bukanlah pilihan. Ramai orang memilih untuk Jangan dedahkan NAS atau perkhidmatannya secara langsung kepada dunia luar.mengehadkan akses 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 kepada perkhidmatan dalaman melalui terowong yang disulitkan.Traefik mahupun aplikasi tidak akan terdedah kepada Internet tanpa penapis terdahulu itu.

Mereka yang lebih suka tidak menguruskan VPN mereka sendiri kadangkala menggunakan Terowong atau Skala Tail Cloudflare untuk mengakses homelab tanpa membuka port. Ini adalah alternatif yang mudah, walaupun jika keutamaan mutlak anda adalah privasi, anda perlu mempertimbangkan metadata yang mungkin dikumpul oleh pihak ketiga ini.

Satu lagi amalan yang baik ialah Sulitkan pelayan dan cakera NASGunakan tampalan secara berkala dan hadkan kemas kini automatik (ramai yang mengelakkan Watchtower dan memilih kemas kini manual terkawal). Lebih baik ketinggalan sedikit tetapi terkawal daripada merosakkan separuh daripada Homelab kerana kemas kini yang belum anda semak.

Seperti yang anda lihat, anda tidak perlu mencapai tahap "perusahaan", tetapi Ya, adalah dinasihatkan untuk menetapkan piawaian keselamatan dan disiplin minimum. supaya makmal rumah anda bukan 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.