Docker Compose yeterli değil

• docker-compose, Docker konteynerlerini yönetmek için kullanılan bir araçtır; karmaşık uygulama dağıtım sorunlarını çözer, ancak kitlesel pazar için basit self-hosting senaryolarında yeterli değildir.
• SQL veritabanları, yerel önbellek, kalıcı depolama, servis keşfi ve kaynak yönetimi kavramlarını içeren daha yüksek seviyeli soyutlamalara ihtiyaç vardır.

Docker'ın rolü

• Docker, konteynerleştirmeyi yaygınlaştıran bir araçtır ve ana sistem bir gemiye benzetilebilir.
• Donanım, işletim sistemi ve konteyner çalışma zamanı vardır; konteynerler çalışma zamanı içinde çalışır ve veritabanı ya da web sunucusu gibi diğer servislerle iletişim kurar.

Docker-compose'un rolü

• docker-compose, birlikte çalışan konteyner gruplarını tanımlayan bir araçtır ve self-hosting uygulamalarının dağıtımını kolaylaştırır.
• Ancak standartlaştırılmış arayüzleri bozar ve konteynerlerin başlangıçta çözmeye çalıştığı sorunları yeniden üretir.
• Örnek: Pihole
  • Pihole bir DNS sunucusudur ve karmaşık bir docker-compose dosyası gerektirir.
  • Konteyner adları, imajlar, portlar, ortam değişkenleri, volume'lar, ek özellikler, yeniden başlatma politikaları vb. ayarlanmalıdır.
  • Karmaşık yapılandırmanın kullanıcı tarafından doğrudan yönetilmesi gerekir; bu da Docker Compose'un zayıf yanıdır.
• Örnek: Jitsi Meet
  • Jitsi Meet karmaşık bir yazılımdır ve 4 konteyner, 7 volume, 9 port ve 200'den fazla ortam ayarı içeren bir docker-compose yapılandırması üretir.
• Örnek: diğer popüler self-hosting uygulamaları da benzer sorunlar yaşar
  • Authentik, Nextcloud, Immich, Jellyfin, Paperless NGX gibi çeşitli uygulamalar vardır ve her birinin docker-compose yapılandırması onlarca ila yüzlerce docker komutunun yerini alır.
  • Her uygulama kendi veritabanını, önbelleğini ve HTTP işleyicisini içerebilir; bu da yinelenen kaynak kullanımına yol açar.

Sorunlar

• docker-compose fazla esnek, fazla ayrıntılıdır ve yanlış soyutlama katmanında çalışır.
• Her uygulamanın bir HTTP işleme süreci, önbelleği veya veritabanı vardır. Veritabanı yedekleme işi sistem operatörüne kalır.
• Örnek: Reverse HTTP proxy
  • Reverse HTTP proxy, gelen HTTP isteklerini başka programlara ileten bir programdır. Her program bir web sunucusu içerip içermeyeceğine kendisi karar vermek zorundadır.
  • Web sunucusu dahil etmek
    • Web sunucusu dahil edilirse program çalışır, ancak yalnızca belirli bir portta çalışır; birden fazla konteyner varsa portların yeniden eşlenmesi gerekir.
  • Web sunucusu dahil etmemek
    • Web sunucusu dahil edilmezse kaynak israfı önlenir, ancak uygulama yönetim arayüzü olmadan yapılandırılmak zorunda kalır.
  • DNS
    • Web arayüzünün bir adresi vardır ve TLS isteniyorsa bir ada ihtiyaç duyar. Birden fazla servis tek bir host üzerinde çalışıyorsa, istekler alan adı ya da yol üzerinden yönlendirilmelidir.
  • Portlar
    • docker-compose port açmayı ve yeniden eşlemeyi mümkün kılar, ancak gerçekte daha karmaşık ağ yapılandırmalarını desteklemek gerekir.
• Örnek: veritabanı
  • Bir veritabanı konteyneri silindiğinde, dosyalardaki tüm değişiklikler de silinir. Veritabanı içeriğini saklamak için veritabanı konteynerine volume eklenmelidir.
  • N+1=2 veya daha fazlası
    • Veritabanını yedeklemek için site dışı yedekleme gerekir. Her servis ayrı bir veritabanı sunucu sürecini paketliyorsa, bu hesaplama kaynaklarının israfına neden olur.

Çözüm

• Daha yüksek bir soyutlama katmanına geçilerek veritabanı, reverse web proxy, önbellek, statik web varlıkları gibi konteyner türlerini ayırt eden semantik eklenir.
• Semantik örneği
  • Uygulama adı, build, HTTPS reverse proxy ve önbellek servisini tanımlayan yeni bir yapılandırma biçimi sunulur.
• Çözüm #1
  • Her program reverse proxy talep eder; böylece tekrar ve israf önlenir. Reverse proxy, DNS adı sağlar ve tüm yolları programa iletir.
• Çözüm #1.5
  • SQL standardına uyan bir veritabanı talep etmek için bir veritabanı bölümü eklenir ve programın "tam" yetki beklediği varsayılır.
• Portlar için çözüm
  • Her program kendi IPv6 adresini alır ve standart port numaralarını kullanabilir. Güvenlik için yalnızca reverse proxy'nin portlara erişebilmesi amacıyla firewall kullanılır.

Tealok - yeni bir konteyner çalışma zamanı

• Tealok, daha yüksek soyutlama ve standartlaştırılmış arayüzler sunan yeni bir konteyner çalışma zamanıdır.
  • TLS sertifikaları, reverse proxy yapılandırması, DNS kayıtları ve yedekleme yönetimi gibi işleri otomatik olarak ele alır.
  • IPv6 kullanarak her konteynerin bağımsız bir IP adresine sahip olmasını sağlar ve standart port numaralarının kullanılmasına imkan verir.
  • Uygulama geliştiricileri, karmaşık yapılandırmalar olmadan standart arayüzler üzerinden uygulama dağıtabilir.
• Operatörler için tutarlı en iyi uygulamalar sunar, kaynak israfını azaltır ve yönetim yükünü hafifletir.
• Geliştiriciler için dağıtım yöntemini basitleştirir ve karar verme yükünü azaltır.
• Kullanıcılar için veri sahipliği ve bulut bilişimden bağımsızlık güvence altına alınabilir.

[luminance]

tealok'a girip baktım ama alternatif olabilecek durumda değil gibi görünüyor?

[savvykang]

Keşke çalışma zamanını da kaldırsalardı.

[tujuc]

Hâlâ docker-compose kullanarak operasyon ortamını kurup içine girmenin gerekli olduğunu düşünüyorum ama...

Kendi özel ortamındaki deneyime dayanarak bunun yanlış olduğunu söyleyip yeni bir şey yaptık demek... buna katılmak zor gerçekten.. haha

Kolayca yanlış anlaşılabilecek bir içerik olmuş haha...

Ben de sadece başlığa bakıp "Aa, geliştirme ortamında kullanılması gerçekten hiç hoş değil..." diye düşünmüştüm.. haha

[ilbanin00]

docker composeu metindeki amaçla kullanmaya çalışmanın en baştan yanlış bir yaklaşım olduğunu düşünüyorum

[tujuc]

Kısmen katılıyorum, ancak yaklaşımın yanlış olduğunu düşünmüyorum.
Onların yapabildiği koşullarda muhtemelen ellerinden gelenin en iyisiydi :)

[GN⁺]

Hacker News görüşleri

• Port eşleme ve veri volume yedekleme sorunları için basit çözümler mevcut

  • Geliştirme ortamı için ayrı bir docker-compose dosyası kullanılarak ortama göre farklı yapılandırmalar tanımlanabilir
  • Yedekleme için basit bir Bash betiği yazılıp S3'e yükleme yapılabilir

• Kişisel sunucusunda Docker kullanarak self-hosting yapan biri olarak, Docker yapılandırmasının sunduğu esnekliği olumlu değerlendiriyor

  • İlk kurulum zaman aldı, ancak sonrasında yönetimi kolaylaştı
  • Yeni bir servis eklemek neredeyse hiç zaman almıyor ve güvenlik için her servis adına root olmayan kullanıcılar oluşturuyor
  • macvlan ağı kullanarak her container'a benzersiz bir IP ve MAC adresi atıyor
  • Nginx Proxy Manager ile reverse proxy'yi yönetiyor ve veritabanı olarak birden fazla instance çalıştırsa da sorun yaşamıyor

• docker-compose çoğunlukla geliştirme veya kişisel kullanım için kullanılır; V2 ise V1'den farklı olarak Docker'a entegre bir eklentidir

• Prodüksiyon ortamında Kubernetes kullanmak daha uygundur, docker-compose ise yerel geliştirme için uygundur

• docker-compose, küçük ölçekli self-hosting için, teknik geçmişi olmayan kişileri hedefleyen bir üründür

  • TOML'a geçmenin self-hosting'i kolaylaştıracağı konusunda şüpheli

• Docker'ı kontrol eden bir program yazmak sanıldığından daha kolaydır; Python betiğiyle sorunlar çözülebilir

• canine.sh kullanarak Kubernetes cluster'ını Heroku kadar kolay kullanılabilir hale getirmek için geliştirme yapıyor

  • Bunu kişisel projelerinde kullanıyor ve düşük maliyetle birden fazla uygulama barındırabiliyor

• Tealok'un docker-compose için bir alternatif geliştiriyor olması ilginç bulunuyor

• docker-compose, Kubernetes ve Helm'in yanlış soyutlama katmanları olduğu düşünülüyor

  • Container'ları çalıştırmak ve aralarında iletişim kurdurmak için farklı yöntemler geliştirmeye yönelik birçok girişim var

• docker-compose'un yanlış soyutlama katmanı olduğu iddiası kafa karıştırıcı bulunuyor

  • Belirli sorunları çözmek için daha yüksek seviyeli bir arayüz beklendiği anlaşılıyor
  • Yinelenen instance oluşturma sorunu çoğu uygulamada büyük bir problem değil
  • Uygulamaları belirli bir şekilde tasarlamaya zorlamak yalnızca bazı özel durumlarda iyi sonuç verir