Homelab'de Docker Compose: organizasyon, profiller ve en iyi uygulamalar

Informatec Dijital » Ücretsiz Destekler » Homelab'de Docker Compose: organizasyon, profiller ve en iyi uygulamalar

Nakliye konteynerleri kullanarak modern bir ev laboratuvarı kurmak, birçok teknoloji meraklısı için favori bir hobi haline geldi. Bu kurulumun merkezinde neredeyse her zaman Docker Compose yer alır.Hizmetlerinizi YAML'de tanımlayın, Git ile sürümlendirin ve tüm ortamınızı tek bir komutla başlatın.

Şimdi, büyümeye başladığınızda bazı şeyler olur: iki veya üç kabınız varken, birden fazla kabınız olur. Düzinelerce servis, dahili ağ, ters proxy, veritabanı ve CI çalıştırıcısıİşte o zaman büyük soru ortaya çıkıyor: Tek bir devasa Docker Compose dosyası mı yoksa birçok küçük dosya mı? Profilleri, ağları, yedeklemeleri, güvenliği nasıl organize edeceğim ve bunların da ötesinde, geçişi nasıl kolaylaştıracağım?

Ev ortamında Docker Compose kurulumuna yönelik gerçekçi yaklaşımlar

Pratikte, Homelabs'i bir süredir kullanan kişiler genellikle her birinin kendi avantaj ve dezavantajları olan üç Compose organizasyon modeli içinde çalışırlar. Makine yetiştirirken veya taşırken doğru yaklaşımı seçmek size birçok sıkıntıdan kurtarır..

Bir tarafta, işe başlayan kişi var. Docker Run önce bağımsız bir araç olarak başladı, ardından Portainer'a geçti ve sonunda Docker Compose'a atladı.Tipik bir durum: Portainer harika görünürlük, kullanıcı dostu arayüz, şablonlar vb. sunuyor, ancak sonuçta, dosyalarda hiçbir şeyiniz yoksa karmaşık parametreleri düzenlemek veya yapılandırmaları taşımak zahmetli bir iş haline geliyor.

Bunun tam tersi uçta ise şunlar yer almaktadır: her şeyi tek bir "mega" docker-compose.yml dosyasında birleştirdi. Ev laboratuvarı hizmetlerinin tamamını çalıştırabilecek kapasitede: ters proxy, medya, yardımcı programlar, izleme, LLM'ler, veritabanları... Hepsi tek bir yığında.

Bu ikisi arasında, birçok kullanıcı karma bir yaklaşımı tercih ediyor: Bağlama göre gruplandırılmış birkaç küçük docker-compose.yml dosyası (Örneğin, medya, altyapı, verimlilik, izleme), hepsi aynı depoda yer alır ve genellikle küresel ortam değişkenlerini paylaşır.

Oldukça zarif bir çözüm, iki dünyayı bir araya getiriyor: Diğer dosyaları da içeren bir kök docker-compose dosyası. (Her biri uygulamaların veya hizmetlerin alt klasörlerinde). Bu şekilde, okunması imkansız binlerce satırlık bir YAML dosyasıyla uğraşmadan ev laboratuvarınızın genel görünümünü koruyabilirsiniz.

Profiller, fonksiyona göre gruplandırma ve büyük ev laboratuvarları

Ev laboratuvarınız şu aşamaya yaklaşmaya başladığında... 30, 40 veya 50 hizmet (Veritabanları, önbellekler veya indeksleyiciler gibi yedekleme hizmetleri de dahil olmak üzere) buna düzen getirmek hayati önem taşır. İşte burada hem fonksiyona göre gruplandırma kullanımı gibi Docker Compose profilleri.

Çok yaygın bir yöntem, her şeyi tek bir Compose "projesi" altında gruplandırmak, ancak mantıksal olarak profillere göre bölmektir. Örneğin:

• Temel profil: Traefik'i ters proxy ve kimlik sağlayıcı (örneğin, OAuth veya Authentik) olarak kullanan, aynı alan adı altındaki tüm uygulamaların HTTPS ile kimlik doğrulamasını sağlayan bir homelab çekirdeği.
• Medya profiliPlex, Sonarr, Radarr, Ombi, SABnzbd veya qBittorrent gibi hizmetler, multimedya içeriğini derlemek, indirmek ve sunmakla sorumludur.
• Yardımcı Programlar ProfiliKonteynerleri ve güncellemeleri yönetmek ve izlemek için Portainer, Watchtower (kullanılıyorsa), Diun, dockcheck veya benzeri araçlar.
• Altyapı/izleme profiliTraefik, cAdvisor, Prometheus, Grafana, Uptime Kuma, Dozzle ve izleme ve kayıt tutma ile ilgili her şey.
• Deneysel profiller veya LLM: Genellikle varsayılan olarak devre dışı bırakılan, LLM'ler veya ilginç uygulamalar için özel yığınlar (ChatGPT Next Web local, LibreOffice Online, vb.).

Profil oluşturmanın güzelliği şudur ki... Altyapının yalnızca bir bölümünü devreye alabilirsiniz. İhtiyaçlarınıza bağlı olarak. Örneğin, düşük güç tüketimli bir mini bilgisayarda yalnızca çekirdek + altyapı profilini, daha fazla disk ve GPU'ya sahip büyük sunucuda ise yalnızca medya profilini çalıştırabilirsiniz.

İyi tasarlanmış depolarda genellikle bir docker-compose.yml dosyası, apps/ veya services/ klasöründeki ayrı dosyalara include dosyalarını çeken "master" komutudur.Ayrıca, neredeyse tüm hizmetler tek bir dosya üzerinden yapılandırılıyor. .env global dosyası ve secrets/ dizinindeki bazı gizli bilgiler.Bu da ilk kurulumu büyük ölçüde basitleştirir.

Bu modele göre, ev laboratuvarı yönetimi temelde şuna indirgenir: .env dosyasını ve gizli bilgileri düzenleyin, profilleri etkinleştirin veya devre dışı bırakın ve her sunucuda hangi hizmetlerin başlatılacağına karar verin.Birden fazla bilgisayara aynı uygulama setini kurmayı planlıyorsanız idealdir.

Tek bir devasa docker-compose dosyası mı yoksa birkaç küçük dosya mı?

Bu, ebedi bir tartışma: Her şeyi içeren tek bir docker-compose.yml dosyası mı, yoksa her servis/yığın için birden fazla dosya mı? Gerçek cevap genellikle "önceliği neye vermek istediğinize bağlıdır: geçişin basitliği mi yoksa her hizmet için netlik mi?" şeklindedir.

Kim savunuyor? tek ana dosya Genellikle çeşitli avantajları vurgular:

• Sunucu değiştirmek çok kolay.Depoyu klonlayın, .env dosyasını ve gizli bilgileri kopyalayın, birimleri bağlayın ve `docker compose up -d` komutunu çalıştırın. Dizin dizin dolaşmanıza gerek yok.
• Altyapı, doğruluk kodu olarakEv laboratuvarının tüm topolojisi (hizmetler, ağlar, disk birimleri, bağımlılıklar) tek bir yerde bulunur.
• Merkezi güncellemelerBir imaj sürümünü, yeniden başlatma politikasını veya bazı günlük kayıtlarını değiştirdiğinizde, tam olarak nereye dokunmanız gerektiğini bilirsiniz.

Ancak bunun da belirgin dezavantajları var: büyük bir YAML dosyasının bakımı daha zordur, Birleştirme çatışmaları artıyor Belirli bir sorunu gidermeye gelince, kendinizi yüzlerce satırdan oluşan bir canavarın içinde bulursunuz. Her şey çok büyüdüğünde biraz pişmanlık duymak hiç de alışılmadık bir durum değil.

Diğer yaklaşım ise şunlara sahip olmaktır: Her uygulama veya her mantıksal yığın için bir docker-compose.yml dosyası.Şuna benzer bir yapı içinde:

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

Bu sayede her bir konteynere şu şekilde bir isim veriliyor: kitap yığını uygulaması 1 o traefik-ters-proxy-1Bu da sorunları hızlıca bulmanıza yardımcı olur: bookstack-app-1 konteyneri çökerse, hangi klasöre bakmanız gerektiğini tam olarak bilirsiniz.

Görsel olarak çok daha temiz ve Bu, her hizmeti bağımsız olarak yönetmenize olanak tanır. (Diğerlerini etkilemeden başlatma, durdurma veya güncelleme). Ayrıca, logları daha iyi organize etmek için ayrı yığınlara sahip olmanın avantajından yararlanan Dozzle gibi uygulamalar da mevcuttur.

Takas şudur Her şeyi çok fazla birbirinden ayırırsanız, ortak hizmetler (Traefik veya paylaşımlı ağlar gibi) arasındaki koordinasyon biraz daha dikkat gerektirir.Harici ağlar mutlaka belirtilmeli, belirli Traefik etiketleri kullanılmalı ve diğer docker-compose dosyaları tarafından oluşturulan ağların adlandırma kuralları hatırlanmalıdır.

.env dosyaları, geçersiz kılmalar ve sürüm kontrolü ile ilgili en iyi uygulamalar

En az değer verilen numaralardan biri şudur: yapılandırmayı .env dosyalarında merkezileştirinDocker-compose.yml dosyanızı ortam değişkenleriyle doldurmak yerine, şöyle bir şey tanımlayabilirsiniz:

DB_USERNAME=myuser
DB_PASSWORD=secretpassword

Ve daha sonra YAML dosyasında bunlara şu şekilde atıfta bulunulur: ${DB_USERNAME} o ${DB_ŞİFRESİ}Bu, metni bir bakışta okunabilir hale getirir ve size şu olanakları sağlar: birden fazla hizmette değişkenleri paylaşın Ve her şeyden önemlisi, şifreleri ayrı bir dosyada saklayın (bu dosyayı Git'ten hariç tutabilirsiniz).

Farklı ortamlar (üretim, test, geliştirme) için çok kullanışlıdır. docker-compose.override.yml dosyasından yararlanın.Buradaki fikir, temel bir docker-compose.yml dosyasına sahip olmak ve geçersiz kılma yönteminde yalnızca değişen şeyleri (portlar, yollar, hata ayıklama bayrakları vb.) geçersiz kılmaktır.

Örneğin, geliştirme aşamasında bir geçersiz kılma dosyası yükleyebilirsiniz. Farklı bir portu açığa çıkarırsınız, DEBUG'ı etkinleştirirsiniz ve yerel kaynak kodunu bağlarsınız.Ana YAML dosyasına dokunmuyorsunuz, ancak yığını çalıştırdığınız ortama uyarlıyorsunuz.

Açıkçası, Ev laboratuvarınızın az da olsa ciddi olmasını istiyorsanız, her şeyi Git ile sürümlendirmek şarttır.Genellikle şöyle bir şeyiniz olur:

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

Oradan itibaren depoyu başlatırsınız, altyapı değişikliklerini kaydedersiniz ve bir şey bozulursa, Compose'unuzun önceki bir sürümüne saniyeler içinde geri dönebilirsiniz.Biraz iddialı ev laboratuvarları için bu sadece bir seçenek değil, delirmenin önüne geçmenin tek yolu.

Ağlar, Traefik ve güvenli hizmetin ifşası

Aynı kombinasyon, orta düzeyde gelişmiş neredeyse tüm ev laboratuvarlarında karşımıza çıkıyor: Traefik, ters proxy ve merkezi kimlik sağlayıcı (Auth veya Authentik) olarak işlev görüyor.Bu sayede HTTPS ve SSO ile alt alan adları altında birçok uygulamayı kullanıma sunabilirsiniz.

Klasik bir yöntem, örneğin özel bir Docker ağı kurmaktır. ters proxy Ya da benzer bir yapıda, Traefik ve dışarıya sunacağınız tüm web servisleri birbirine bağlanır. Geri kalan konteynerler (veritabanları, önbellekler vb.) ise izole edilmiş iç ağlarda kalır.

Traefik kullanıyorsanız ve servislerinizi farklı docker-compose dosyalarına ayırıyorsanız, şunlara ihtiyacınız var: paylaşılan harici bir ağı tanımlayınBuna benzer bir şey:

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

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

Burada, traefik_default ağı Traefik yığını tarafından oluşturulur ve diğer hizmetler traefik-net adlı harici bir ağ aracılığıyla ona eklenir. Etiketler Traefik'e bilgi verir... Trafiği yönlendirmek için hangi ağ kullanılmalıdır?.

Tek bir yığın, arka uç hizmetlerini (örneğin, bir web kapsayıcısı ve veritabanı) içerdiğinde şunları yapabilirsiniz: Bunları paylaşılan varsayılan bir ağa bağlayın ve yalnızca web kapsayıcısına Traefik ağına erişim izni verin.Veritabanı, Traefik'in onu yok sayması için traefik.enable=false etiketine sahip olacaktır.

Bu tür bir kurulum size iki önemli avantaj sağlar: Hizmetler arası izolasyon ve kontrollü maruz kalmaYalnızca Traefik etiketleriyle işaretlediğiniz ve proxy ağında bulunan konteynerlere dışarıdan erişim sağlanabilir.

Veri kalıcılığı, disk hacimleri ve disk yapısı

Kalıcı veri içermeyen bir ev laboratuvarı pek kullanışlı değildir: veritabanları, yapılandırmalar, medya, belgeler... her şey bir docker compose down işleminden sonra da çalışmaya devam etmelidir. Kitap ciltleri ve cilt kapakları sizin hayat sigortanızdır..

Birçok insan depolama alanını buna benzer bir yapı kullanarak düzenler:

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

Fikir şu ki İndirme programları (qBittorrent, SABnzbd, vb.) yalnızca indirme klasörünü görür.Radarr/Sonarr gibi yöneticiler hem indirmelere hem de medyaya (sabit bağlantılar oluşturmak/taşımak için) erişebilirken, Plex veya Jellyfin gibi sunucular yalnızca medya klasörünü görebilir.

Bu şekilde şu ilkeyi uyguluyorsunuz: en az ayrıcalıkHer bir konteyner yalnızca gerçekten ihtiyaç duyduğu verilere erişir. Bu net ayrım, buluta veya harici sürücülere hangi birimlerin veya yolların yedekleneceğine karar verirken de yardımcı olur.

`srv` dizini genellikle uygulama yapılandırmalarını depolamak için kullanılır (örneğin, `/srv/jellyfin/config`, `/srv/traefik`, `/srv/paperless`, vb.). Bu genellikle kısmen sürümlendirilir (şablonlar, Caddyfile, vb.), kritik veya kaynak yoğun olan her şey dışarıda bırakılır.

Bazı durumlarda kullanmak ilginçtir. sabit bağlantılar İndirme zincirinde: Radarr veya Sonarr gibi servisler, disk alanını çoğaltmadan dosya paylaşımını sürdürmek için indirilen dosyaları birbirine bağlayabilir. TRaSHGuides gibi kılavuzların önerdiği dizin tasarımı tam olarak buna dayanmaktadır.

GitHub Actions ve yerel çalıştırıcılar kullanarak dağıtımları otomatikleştirme

Eğer işleri bir üst seviyeye taşımayı seviyorsanız, bir adım daha ileri gidebilirsiniz ve CI/CD kullanarak ev laboratuvarı güncellemelerini otomatikleştirin.Birçok kullanıcı, Jenkins ve benzeri araçların yerine GitHub Actions ve kendi ev laboratuvarlarında barındırdıkları bir çalıştırıcı kullanan bir iş akışı kullanmaya başladı.

Mekanizma basit: Homelab deponuzun ana dalına her push işlemi yaptığınızda, GitHub Actions iş akışı başlatılır; bu iş akışı testleri çalıştırır, kod denetimi yapar ve her şey yolunda giderse değişiklikleri sunucuya dağıtır..

Tipik bir iş akışı şu adımları içerir:

• Gitleaks benzeri gizli tarayıcıBu, şifrelerinizi veya token'larınızı yanlışlıkla depoya yüklemeniz durumunda geçerlidir.
• Hav bırakma YAML veya altyapı kodunun okunabilir ve tutarlı bir formatta tutulması için.
• Ev laboratuvarı içindeki depoyu güncellemeHedef sunucuda git pull komutunu çalıştırın.
• Konteynerlerin kontrollü yeniden oluşturulmasıEski işlemleri durdurun, yeni işlemleri başlatın ve durumlarını kontrol edin.

Avantajları: ek güvenlik (gizli bilgilerin sızmasını kontrol edersiniz), daha iyi kod kalitesi ve Tek bir itme ile tekrarlanabilir dağıtımlarYerel bir çalıştırıcı kullandığınız için, görüntüler ve disk birimleri ağınızdan ayrılmıyor; yalnızca GitHub arayüzünü kullanarak işlem hatlarını görselleştiriyorsunuz.

Docker Compose ev laboratuvarında hayatı neden bu kadar kolaylaştırıyor?

Birçok insan yıllarca şuna güvenerek yaşadı: Docker Run ve Portainer Bir olay veya geçiş sonucu yaklaşımını yeniden değerlendirmek zorunda kalana kadar. Bir sunucuyu kaybettiğinizde veya hizmetleri başka bir makineye taşımak zorunda kaldığınızda, Portainer'da yalnızca izole komutlara veya yapılandırmalara güvenmek bir tuzaktır..

Compose'a geçtiğinizde en büyük fark şudur: Hizmet tanımının tamamı metne dönüşür.Birimler, portlar, ağlar, etiketler, değişkenler… Hepsi kopyalayabileceğiniz, paylaşabileceğiniz, sürümleyebileceğiniz ve yeniden kullanabileceğiniz bir YAML dosyasında.

Bir hizmeti düzenlemek artık "bir konteyneri elle yeniden oluşturmak" anlamına gelmiyor ve bambaşka bir boyuta dönüşüyor. Dosyadaki bir satırı değiştirin, kaydedin ve `docker compose up -d` komutunu çalıştırın.Orijinal komutu hatırlamanıza veya birden fazla Portainer ekranına tıklamanıza gerek yok.

Ayrıca, birden fazla sunucuyla (mini PC'ler, NAS, masaüstü bilgisayarlar) çalışıyorsanız, bunlara erişebilmek son derece kullanışlıdır. Aynı compose dosyasını başka bir makineye kopyalayın, dört yolu değiştirin ve aynı yığını farklı donanımla çalıştırın.Aslında birçok kişi, veri kaybı veya kaotik geçişlerle ilgili bir korku yaşadıktan sonra Compose'un sonraki olaylarda kendilerine çok zaman kazandırdığını kabul ediyor.

Ek bir avantaj olarak, eski hizmetlerden yeni hizmetler oluşturmak çok kolay hale geliyor: örneğin, Jellyfin'i bağlamak için Plex yapılandırmasını kopyalayın. Aynı medya yollarını ve dönüştürme aygıtlarını yeniden kullanmak, YAML bloklarını kopyalayarak yapıldığında yalnızca birkaç dakika sürer.

Optimizasyon: derleme bağlamı, çok aşamalı derlemeler ve kaynaklar

Homelab konteynerlerinin çoğu halka açık imajlardan gelse de, bazı durumlarda kendi imajlarınızı derleyeceksiniz. Bu durumlarda dikkatli olmak önemlidir. bağlam oluşturmak: Tüm depoyu filtrelenmemiş olarak göndermeyin, bunun yerine yalnızca proje klasörünü (iyi bir .dockerignore dosyasıyla) gönderin, böylece derlemeler hızlı ve hafif olur.

Bir diğer çok faydalı teknik ise şuna başvurmaktır: çok aşamalı yapılar Dockerfile dosyalarınızda: ilk aşamada bağımlılıkları kurup derleme işlemini gerçekleştirirsiniz, ikinci aşamada ise yalnızca gerekli dosyaları küçük bir temel imaja kopyalarsınız. Sonuç: nihai imajlar. çok daha küçük ve daha güvenliÇünkü bunlar, araç zincirlerini veya ek kütüphaneleri aktarmazlar.

Oluşturma tarafında, tanımlama seçeneğiniz mevcuttur. CPU ve RAM sınırları (Özellikle Swarm ortamlarında veya Docker bu parametrelere uyduğunda) kaynak yoğun bir uygulamanın kaynakları tekeline almasını önlemek için. Ev laboratuvarlarında bu, yanlış yapılandırılmış bir hizmetin sistemin geri kalanını felç etmesini önlemeye yardımcı olur.

Unutma yeniden başlatma politikaları (yeniden başlat: her zaman, durdurulmadığı sürece, arıza durumunda): Bu seçeneklerle, kritik hizmetlerin (ters proxy, VPN, anahtar veritabanları) yeniden başlatma veya tek seferlik bir arıza sonrasında otomatik olarak yeniden başlatılmasını sağlarsınız.

Son olarak, aşağıdaki gibi komutlar kullanarak düzenli temizlik görevlerini planlamak iyi bir fikirdir. docker imaj temizleme, docker konteyner temizleme ve docker volume temizleme Eski derlemelerin kalıntılarını, durdurulmuş konteynerleri veya sahipsiz birimleri ortadan kaldırarak disk alanını geri kazanmak.

Sağlık hizmetleri, kayıt tutma ve izleme

Ev laboratuvarınızın bir kara kutu olmaması için üç temel husus üzerinde çalışmanız önemlidir: sağlık kontrolleri, kontrollü kayıt ve izlemeDocker Compose, bir konteynerin sağlıklı olup olmadığını belirlemek için (curl -f http://localhost gibi komutlar veya belirli komut dosyaları kullanarak) her servis için sağlık kontrolleri tanımlamanıza olanak tanır.

Bununla şunu sağlayabilirsiniz: Yalnızca "sağlıklı" konteynerlere trafik gönderilir. (örneğin, Traefik aracılığıyla) ve yanıt vermeyi bıraktıklarında yapılandırılmış politikaya göre yeniden başlatılmaları sağlanır. Bu, minimum çabayla dayanıklılığı önemli ölçüde artırır.

Günlük kayıtlarıyla ilgili olarak, sürücü JSON dosyasını aşağıdaki sınırlar dahilinde ayarlayın. maksimum boyut ve maksimum dosya Bu, disk alanınızın gigabaytlarca unutulmuş günlük dosyasıyla dolmasını önler. Dozzle gibi web araçları, tüm konteynerlerin günlük dosyalarına bir tarayıcıdan göz atmanıza yardımcı olur; bu da belirli hizmetlerde hata ayıklama için çok kullanışlıdır.

Ölçümleme ve sürekli izleme söz konusu olduğunda, klasik kombinasyon şöyledir: c Danışman + Prometheus + GrafanacAdvisor, her bir konteyner için CPU, bellek, disk ve ağ kullanım istatistiklerini ortaya koyar; Prometheus bunları periyodik olarak toplar ve Grafana, bir şeyde ani bir artış olması durumunda uyarılarla birlikte bunları çekici gösterge panolarında görüntüler.

İyi kurulmuş bir ev laboratuvarı genellikle şunları da içerir: Kuma'nın kullanılabilirlik kontrolleri için çalışma süresi (HTTP, ICMP, TCP…) ve kritik verileri diğer disklere veya buluta kopyalamak için Duplicati gibi otomatik bir yedekleme sistemi. Bu sayede neler olup bittiğini bilirsiniz ve bir sorun çıkarsa önemli olan verilerinizi kaybetmezsiniz.

Ev laboratuvarına güvenlik ve uzaktan erişim

Kurulum ne kadar ev yapımı olursa olsun, güvenlik isteğe bağlı değildir. Birçok kişi bunu tercih eder. NAS cihazınızı veya hizmetlerini doğrudan dış dünyaya ifşa etmeyin.VPN üzerinden uzaktan erişimi sınırlandırmak (WireGuard, performansı ve basitliği nedeniyle çok popüler bir seçenektir).

Bu modelde, yönlendirici bir ağ geçidi görevi görür: VPN sunucusuna yalnızca rastgele bir port açılır ve bağlantı kurulduktan sonra, Dahili hizmetlere yapılan tüm istekler şifrelenmiş bir tünel üzerinden geçer.Traefik veya uygulamaları, önceden yapılan bu filtreleme olmadan internete doğrudan erişime açık değildir.

Kendi VPN'lerini yönetmek istemeyenler bazen şu yöntemlere başvururlar: Cloudflare Tüneli veya Tailscale Portları açmadan ev laboratuvarına erişmek için. Bunlar kullanışlı alternatiflerdir, ancak mutlak önceliğiniz gizlilik ise, bu üçüncü tarafların hangi meta verileri toplayabileceğini göz önünde bulundurmanız gerekecektir.

Bir diğer iyi uygulama ise Sunucu ve NAS disklerini şifreleyin.Yamaları düzenli olarak uygulayın ve otomatik güncellemeleri sınırlayın (çoğu kişi Watchtower yerine kontrollü manuel güncellemeleri tercih eder). Kontrol etmediğiniz bir güncelleme yüzünden Homelab'ın yarısını bozmaktansa, biraz geride kalmak ama kontrolü elinizde tutmak daha iyidir.

Gördüğünüz gibi, "kurumsal" bir seviyeye ulaşmanıza gerek yok, ancak Evet, asgari güvenlik ve disiplin standartlarının belirlenmesi tavsiye edilir. Böylece ev laboratuvarınız bir elek gibi olmasın veya sürekli bir korku kaynağı olmasın.

Sonuç olarak, Docker Compose ile ciddi bir ev laboratuvarı kurmak, organizasyon, sağduyu ve deneme yanılma isteğinin bir karışımıdır: servisleri gruplandırır, ağları iyi tanımlar, Git'te belgeler ve biraz otomasyon eklerseniz, tek bir komutla başlatabileceğiniz, kolayca başka bir makineye taşıyabileceğiniz ve kontrol edilemez bir karmaşaya dönüşmeden yavaş yavaş genişletebileceğiniz bir ortam elde edersiniz.