Konteyner olmadan da dikkate değer bir Traefik reverse proxy ve load balancer

• Traefik konteyner ortamlarında ünlü olsa da, tek bir Go çalıştırılabilir dosyası olarak dağıtılabildiği için konteyner motoru olmadan da reverse proxy olarak çalıştırılabilir
• Dosyaları doğrudan sunan nginx/caddy/apache2 türünden çok, HAProxy’ye daha yakın bir proxy olup istek iletimi, yanıt döndürme ve header düzenlemeye odaklanır
• Docker label’ları kullanılmasa bile yapılandırma dosyası provider ile kurulabilir; statik ve dinamik yapılandırmayı ayırarak router, service ve middleware yönetir
• TLS Passthrough ile HAProxy’nin PROXY protocol giriş/çıkışını destekler; ancak PROXY protocol için hedef servisin de destek vermesi gerekir ve apache2 ile nginx bunu destekler
• Kimlik doğrulama entegrasyonu ile kullanıcı aracısı ve IP engellemede temel özellikler yetersiz kalabilir; bu yüzden ForwardAuth, oauth2-proxy ve üçüncü taraf eklentilerin yönetim yükü de birlikte değerlendirilmelidir

---

Konteyner dışında da kullanılabilen Traefik

• Traefik son birkaç yılda home-lab YouTube alanında popülerlik kazandı ve çoğunlukla Docker ya da Kubernetes gibi konteyner altyapıları ile birlikte tanıtıldı
• İşlev karakteri nginx/caddy/apache2’den çok HAProxy’ye yakındır
  • İstekleri servislere iletir ve yanıtları geri döndürür
  • Header’ları ve istek/yanıtın bazı kısımlarını değiştirebilir
  • Dosya sunmayı desteklemez
• Konteyner ortamında Traefik de konteyner olarak çalıştırılabilir ve Docker soketi mount edilerek diğer konteynerleri otomatik algılayabilir
  • Proxy davranışı konteynerlerin Docker label’larıyla yapılandırılabilir
  • Yeni konteyner algılandığında Let’s Encrypt TLS sertifikasını otomatik isteyip servisi yayımlayabilir

Tek binary ve systemd dağıtımı

• Traefik Go ile yazılmıştır ve tek bir çalıştırılabilir dosya olarak derlenir
• Binary dağıtımı Traefik kurulum belgelerinde alınabilir
• Konteyner motoru olmadan hem Traefik’in kendisi hem de hedef servisler çalıştırılabilir
• systemd servis birimi örneği Traefik deposunda bulunur
• Gerçek kullanımda yapılandırma dosyasına ek olarak ayrı bir kullanıcı oluşturma ve yapılandırma dosyası izinlerini ayarlama da gerekir

Yapılandırma dosyası tabanlı kurulum

• Konteyner kullanılmazsa Docker label’ları kullanılamaz; ancak Traefik file provider ile yapılandırılabilir
• Yapılandırma büyük ölçüde iki bölüme ayrılır
  • Statik yapılandırma: Let’s Encrypt gibi sertifika sağlayıcısı ile Traefik’in dinlediği portlar olan entrypoint’ler burada yer alır
  • Dinamik yapılandırma: router, service ve middleware burada yer alır
• Traefik dosya sistemi olaylarını algılayarak dinamik yapılandırmayı hot reload edebilir
• Belgeler, temel kavramları ve yapılandırma örneklerini her yönteme uygun şekilde sunar
• certificate provider, entrypoint, router, service, middleware gibi terimler Traefik belgelerinde hızlıca incelenebilir

Yapılandırma sonrası davranış ve hata ayıklama

• Yapılandırma uygun olmadığında Traefik uyarı gösterir
• Varsayılan log’lar çok ayrıntılı olmasa da, isteklerin hangi yolu izlediğini anlamak kolaydır
• İlk kurulum hızlı tamamlanmış ve rastgele bir sorun yaşanmadığı yönünde bir kullanıcı deneyimi vardır

TLS Passthrough ve PROXY protocol

• Traefik TLS Passthrough destekler
  • TLS’i proxy üzerinde sonlandırmadan, kendi TLS sertifikasını sunan web servisine trafiği iletebilir
  • Servisin Traefik üzerinden geçip Let’s Encrypt sertifikasını doğrudan istemesi de mümkündür
  • Proxy iletilen içeriği göremez
• Normalde sanal host seçimi HTTP Host header’ı ile yapılır; ancak TLS Passthrough’da bu header şifrelenmiş içerikte bulunduğu için kullanılamaz
• Hedef host, TLS’in SNI(Server Name Indication) bilgisiyle seçilir; Traefik ile birçok web sunucusu ve proxy bu yöntemi kullanır
• HAProxy’nin PROXY protocol giriş/çıkışı da desteklenir
  • Kullanıcının önce proxy’ye ulaşırken kaybolan bilgileri hedef servise aktarma yöntemidir
  • Mevcut X-Forwarded-... header’larına göre güvenlik açısından daha kolay yönetildiği değerlendirilir
  • Hedef servis de PROXY protocol desteklemelidir
  • apache2 ve nginx destekler; destekleyen servislerin listesi de büyümektedir

Kimlik doğrulama entegrasyonunda kalan eksikler

• nginx üzerinde Vouch Proxy kullanılarak bazı servisleri Azure AD, yani bugünkü Microsoft Entra kimlik doğrulaması ile korumak mümkündür
• Traefik, nginx’in kimlik doğrulama yöntemine benzer ForwardAuth desteği sunar
• Vouch Proxy henüz Traefik üzerinde çalışmıyor ve ilgili issue açık durumda
• Kendi Keycloak instance’ını işletip AAD ile entegre ederek ForwardAuth için kullanmak mümkün; ancak ilk kurulum ile güvenlik bakımı ve güncelleme yükü büyüktür
• traefik-forward-auth sık önerilse de son güncellemesi Haziran 2020’de yapılmış ve bağımlılık güncellemeleri gerektiği için kullanımı zor bulunuyor
• oauth2-proxy ile geçmiş deneyim iyi olmamış; ayrıca proxy’nin arkasına bir proxy daha koyulduğunda HTTP/2·HTTP/3, timeout, body boyutu ve WebSocket ayarlarının her ara proxy’de ayrıca uyarlanması gerektiğinden hata olasılığı artıyor
• 2024-05-06 güncellemesine göre oauth2-proxy, HTTP API üzerinden de entegre edilebiliyor
  • nginx’in auth_request özelliğini destekler
  • Traefik’in ForwardAuth desteğini sunar
  • Bu yöntem istenen kurulum için daha uygun bir seçenek gibi görünmektedir

Kullanıcı aracısı ve IP engelleme

• Dahili servislerin archive.org tarafından arşivlenmesinin istenmediği durumlar olabilir
• robots.txt ve benzeri header’lar Archive.org engellemede etkili değildir; crawler engelleme yöntemi archive.org_bot kullanıcı aracısını veya IP aralıklarını engellemektir
• Traefik’te kullanıcı aracısı ya da IP adresi engellemek için yerleşik özellik değil, üçüncü taraf eklenti gerekir
  • Kullanıcı aracısı engelleme eklentisi
  • deny IP eklentisi
• Üçüncü taraf eklentiler güncelleme sırasında ayrıca takip gerektirir ve güvenlik açığı oluşturabilir; bu yüzden tercih edilmez
• IPAllowList middleware ile engellenmek istenen IP’ler dışındakileri izinli sayma yaklaşımı mümkündür
  • IP aralığı hesaplaması da yapılabilir
  • Doğrudan engellemeye göre daha kötü olmasa da, geriye kalan subnet’lere bakarak hangi aralığın engellendiğini anlamak zor olduğundan zarif değildir

Yapılandırma örneği

• Örnek, /etc/traefik/traefik.yml ile /etc/traefik/dynamic.yml olarak ikiye ayrılır
• Statik yapılandırma şunları kurar
  • :80 ve :443 entrypoint’leri
  • HTTP endpoint’lerini istisnasız HTTPS’e yönlendirme
  • TLS challenge kullanan Let’s Encrypt sertifika alımı
  • /etc/traefik/dynamic.yml dinamik yapılandırma dosyasını izleme
• Dinamik yapılandırma şu bileşenleri içerir
  • cloud.xx.xyz için TLS Passthrough TCP yönlendirmesi
  • Başka bir host üzerindeki 10.33.1.2:4433 servisine iletim
  • PROXY protocol version 2 etkinleştirme
  • git.xx.xyz için TLS sonlandırıp yerel http://127.0.0.1:3000 adresine proxy etme
  • https://xx.xyz/redirmepls adresini https://google.com adresine yönlendiren middleware
  • X-Robots-Tag: noindex, nofollow, nosnippet, noarchive header’ını ekleyen middleware

[GN⁺]

Hacker News yorumları

• Traefik oldukça iyi, ancak Ansible ile aynı berbat sorundan muzdarip: çok fazla doküman ve yazı var ama ihtiyacınız olan şeyi bulamıyorsunuz.
  v1’den beri kullanıyor olmama rağmen dokümanlarda sık sık yolumu kaybediyor ve ciddi şekilde sinirleniyorum. Küçük projelerde Caddy kullanmayı tercih ediyorum; çünkü dokümantasyonu Traefik’inki kadar kötü değil.
  Teknik dokümantasyon yazarlarına söylemek gerekirse, örnek odaklı dokümantasyon yalnızca göz gezdiren yeni başlayanlar için iyidir. Ürüne aşina olan kişilerin, 10 eğitim sayfasına dağılmış alan açıklamalarına değil, referans dokümanlarına ve eksiksiz listelere ihtiyacı vardır. Yalnızca onboarding sürecine odaklanmayın; ürünü her gün kullanan kişilere göre de yazmalısınız.
  Beni en çok rahatsız eden kısım bu; Ansible’dan bu kadar nefret etmemin nedeni de bu, Traefik de daha hafif ölçekte benzer.

  • Katılıyorum. https://diataxis.fr gibi dokümantasyon çerçevelerinin daha yaygın bilinmesinin herkese faydası olacağını düşünüyorum.
  • Bu kategoride son zamanlarda beni sinirlendiren şey OpenTelemetry oldu. Binlerce sayfa var, ama temel ve yaygın iş akışlarını gerçekten nasıl gerçekleştireceğinizi anlatan neredeyse hiçbir şey yok.
  • YAML yorumlayıcısı ailesinden diller diyebileceğimiz şeylerin sorunlarından biri, YAML’in kendisinin bir dil olması; yorumlayıcı dokümanları ise genelde bu kısmı belgelemiyor.
    Çok basit işleri yalnızca çok düz veri yapıları üzerinde yapacağınız varsayılıyor, oysa gerçek dünyanın çoğu böyle değil. Bu dilleri düzgün kullanmak için YAML’i nasıl kullanmanız gerektiğine dair tüm örtük kuralları anlamanız gerekiyor, ama dokümanlar buna neredeyse hiç değinmiyor.
    Her modülün kendine özgü yapılandırma dokümanları var, ancak standart yapılandırmanın nasıl kullanılacağı, dönen verilerin nasıl ele alınacağı ya da biraz daha karmaşık bir şeyle nasıl birleştirileceği pek açık değil. Her öğe için birer paragraflık bir düzine örneği malzeme yığını gibi önünüze atıp sizden pasta yapmanızı istemek gibi.
    Kullandığım çeşitli YAML yorumlayıcı sistemlerinde neredeyse hep aynı deneyimi yaşadım; yüz binlerce satır YAML’den sonra işleri halledebilir hale geldim, ama dokümanların yapılandırma listelerinin ötesinde pek değeri yoktu.
  • Ansible kesinlikle sizi sürekli doküman aramaya zorluyor.
    Yine de ansible-doc kullanarak oldukça iyi bir iş akışı buldum; sık kullandığım alias’lar alias adl='ansible-doc --list', alias adls='ansible-doc --list | less -S', alias ad='ansible-doc'.
    Önce adls ile ilgili komutları hızlıca arıyorum, ad ile dokümana bakıyorum, ardından neredeyse her zaman doğrudan sona atlayıp (G) örneklere bakıyorum. Genellikle ihtiyacım olan cevap tam orada oluyor.
    Ansible betikleri yazmak dokümanlara çok bağımlı olduğundan, varsayılan durumda bile bu arama sürecini daha iyi desteklemesi ve bir sürü alias oluşturmadan hızlıca bulmayı sağlayan bir arayüz sunması gerektiğini düşünüyorum.
  • Pydantic de benim için bu kategoriye giriyor. Bakımcısı tek bir bilgi kaynağı olması gerektiğini düşünüyor ve API referans dokümanı oluşturmayı reddediyor.
    Elbette kendi projesi, ama bir nesnenin tek bir metodunu bulmak için her seferinde uzun düzyazı sayfalarını karıştırmak gerekiyor. Bazen sadece kaynak kodunu okumak daha kolay oluyor.

• Traefik’i prodüksiyonda 2 yıldır kullanıyorum. Eskiden NGINX kullanıyorduk ama otomatik Let's Encrypt entegrasyonu yüzünden Traefik’e geçmeye karar verdik ve bu karardan pişmanım
  Traefik dokümantasyonu bana ve ekibime pek anlaşılır gelmiyor. Nazlı; düzgün log olmadan garip davranıyor
  Örneğin sertifikayı yeniden oluşturmaya çalışınca arada sırada başarısız olup prodüksiyonu ne zaman toparlanacağı belli olmayacak şekilde indiriyor. Yeniden NGINX’e dönüyoruz

  • Bu tür konularda NixOS gerçekten yardımcı oldu. configuration.nix içine birkaç satır ekleyerek ayarlayabiliyorsunuz; içeride lego(1) ve letsencrypt kullanıyor
    security.acme = { acceptTerms = true; defaults.email = "[e-mail]"; certs."mydomain.example.com" = { domain = "*.mydomain.example.com"; dnsProvider = "cloudflare"; environmentFile = "/path/to/cloudflare/password"; }; };
services.caddy.enable = true;
services.caddy.virtualHosts."subdomain1.mydomain.example.com" = { extraConfig = '' reverse_proxy 127.0.0.1:1234 ''; useACMEHost = "mydomain.example.com"; };
    nginx ile ayarlamak da muhtemelen epey benzer olur. https://github.com/go-acme/lego
  • Ben de DNS challenge ve wildcard sertifika için yerleşik destek yüzünden NGINX’ten Traefik’e geçtim. Şirkette kullandığımız domaine uygulamak için saatler harcadım; evde kusursuz çalışan aynı yapılandırmayı kullanmama rağmen pratikte hiçbir şey yapmadı
    Aynı domain kayıt kuruluşu, aynı API, aynı Docker ayarlarıydı; tüm logları da açmıştım ama sertifikanın neden oluşturulmadığına dair hiçbir bilgi yoktu. Denememiş gibi, oluşturulan varsayılan sertifikaya geri dönüyordu
    İki sorun giderme oturumu ve saatlerce aramadan sonra vazgeçip self-signed sertifika dosyası kullanmak zorunda kaldım. Neden çalışmadığına dair hiç bilgi olmaması, sessizce başarısız olup yedek davranışa geçmesi gerçekten sinir bozucu
    Genel olarak Traefik’in en büyük sorunu buydu. Çalıştığında harika ama çalışmadığında sorunu gidermek ya da dokümantasyonda gerekli bilgiyi bulmak her zaman zordu. Şirkette yıl sonuna doğru Traefik’i prodüksiyonda kullanmaya başlamayı planlıyoruz; o zamana kadar Traefik’e biraz daha alışmayı umuyorum
  • Bir API gateway gerekiyorsa şimdiye kadar doğrudan Go’nun yerleşik reverse proxy’sini kullandım. İstediğiniz şekle kolayca uyarlayabiliyorsunuz; CORS, rate limiting, retry gibi yaygın işler için kütüphane bulmak da kolay
    En iyi yanı, bir yapılandırma dili olmaması. Sadece Go kullanıyorsunuz
  • Zaten biliyor olabilirsiniz ya da size uymamış olabilir ama nginx Docker container’ları için Let's Encrypt sertifikalarını otomatikleştiren epey fazla Docker yardımcı container’ı var
  • Traefik’i ilk kullanırken benzer birçok sorun yaşadım. Örneğin TLS-01 doğrulaması kullanırken, ayar uygulanmadan önce DNS kayıtlarını hazırlamadıysanız ciddi stres yaratıyordu. Log miktarının yetersiz olması da aynı şekilde can sıkıcıydı
    Sonradan öğrendiğim şey, DNS düzgün ayarlanmadığında doğrulama denemelerinin N kez başarısız olmasının ardından Let's Encrypt’in bir süre TLS-01 doğrulamasını tekrar reddettiğiydi; sizin yaşadığınız sorun da o türden gibi geliyor
    DNS-01 doğrulamasına geçtikten sonra deneyim bir anda çok daha iyi hale geldi. Herkese açık şekilde expose edilmemiş servisler için de sertifika oluşturabiliyorsunuz ve TLS-01 yöntemine göre çok daha az orkestrasyon gerekiyor
    DNS sağlayıcınız düzgünse, bir sorun olduğunda da Let's Encrypt kaydı doğrulamadan önce API hatası alma olasılığınız yüksek; hata durumu Let's Encrypt’in denetim hatası backoff’una göre çok daha erken ortaya çıkıyor. Artık Traefik, Caddy, Nginx ya da başka bir reverse proxy kullansam da Let's Encrypt için neredeyse sadece DNS-01 tabanlı doğrulama kullanmaya karar verdim; TLS-01 kullanmam gerekiyorsa Staging API ile en baştan doğru ayarladığımdan mutlaka emin olurum
    Bu arada Traefik’te Let's Encrypt Staging sertifikası oluşturursanız, o sertifikayı geçersiz kılmanın iyi bir yolu yok. Sertifikayı kaldırmak için ACME JSON’ını elle düzenleyip değişikliğin uygulanması için Traefik’i yeniden başlatmanız gerekiyor. SIGHUP ile olur mu bilmiyorum, denemedim
    Genel olarak tuhaf sessiz başarısızlıklar ve davranışlar çok, ama en büyük acı bağımlı servis hatalarını opak hale getirmesi

• Traefik yerine Caddy kullanıyorum. Bana göre Caddyfile yönetmek Traefik’in YAML yapılandırmasından çok daha kolay; yerel, prodüksiyon ve on-premise dağıtımlar için ayrı Caddyfile’lar tutuyorum
  Harika eklentileri de var; biz Caddy için coraza WAF eklentisi kullanıyoruz ve iyi çalışıyor

  • Self-hosting kurulumumda Traefik’ten Caddy ve caddy-docker-proxy’ye geçtim
    İhtiyacım olan tüm özellikler var ve çok daha basit
    https://github.com/lucaslorentz/caddy-docker-proxy
  • Caddy’yi seviyorum ama prodüksiyon dağıtım dokümantasyonunun da daha iyi olmasını isterdim. Özellikle storage ve yapılandırma yönetimi konusunda en iyi uygulamalarla ilgili cevapsız çok fazla soru var
    Harici storage kullanırken yerel storage’a nasıl davranılacağı gibi konular. Stateless kabul edilebileceği söyleniyor ama belki de öyle değildir
    Sonunda ihtiyaç duyduğunuz modülü yazan kişinin işi gerçekten bildiğine dua etmek zorunda kalıyorsunuz. Çünkü o tarafta da dokümantasyon standardı yok. Yöneticilerin, temel işlev sağlayıp dokümantasyonu sıfır olan rastgele modüllere, örneğin S3 storage backend’i gibi şeylere, dur demesi gerekiyor
  • Service discovery veya autoscaling gibi karmaşık numaralara ihtiyacınız yoksa ya da bunları kendi script’lerinizle idare edebiliyorsanız, Traefik, Docker Swarm, Kubernetes vb. şeyleri gönül rahatlığıyla pas geçip sadece Caddy kullanabilirsiniz. Caddy gerçekten çoğu şeyi yapabiliyor ve iyi yapıyor

• Birkaç Docker host’u ve birkaç düzine konteyner gibi mütevazı bir ihtiyaç için Traefik’i nginx yerine kullanmanın sebebi ne olur, emin değilim. Ben https://github.com/NginxProxyManager/nginx-proxy-manager kullanıyorum; bu kadar küçük ölçekte Traefik bir avantaj sağlar mı?

  • Burada https://github.com/caddyserver en iyi seçenek bence. SSL sertifikalarını otomatik hallediyor, çok hafif ve yapılandırma söz dizimi çok net
  • Traefik’in hot reload özelliğini seviyorum. Servisleri, yani proxy’lenen uygulamaları gizlemek ya da yeni bir route, Traefik terimiyle router eklemek ya da temel kimlik doğrulama, HTTPS yönlendirmesi, header manipülasyonu gibi middleware eklemek istiyorsanız dosyayı bırakmanız yeterli; otomatik uygulanıyor. Traefik’i ya da ilgili sanal host’u yeniden yüklemek gerekmiyor
    Aslında nginx söz dizimini sevmemem ve Traefik’in daha parlak görünmesi de var. Let's Encrypt yenilemeleri ve konteynerler yüzünden girmiştim; yapılandırma biçimi yüzünden kullanmaya devam ettim
  • Mevcut kurulumun zaten iyi çalışıyorsa, değiştirerek elde edeceğin bir avantaj olduğunu sanmıyorum
    Traefik’in sunduğu ama Nginx’te olmayan bir özelliğe ihtiyaç duyduğum anda geçişi düşünürdüm
  • Ben de NginxProxyManager kullanıyorum ve 8 host’um var; caddyserver ya da traefik’in NPM’e göre ne avantaj sağladığını açıklayan bir yanıtı hâlâ görmedim
  • Katılıyorum. Nginx yapılandırması kolay ve bir kez ayarlayınca unutabiliyorsun. Zaten çoğu zaman elindeki başka bir yapılandırmadan kopyala-yapıştır yapılıyor
    Certbot her yerde var ve daha fazla senaryoyu destekliyor; bu yüzden otomatik Let's Encrypt’in bir satış noktası olması da biraz tuhaf. Traefik ve Caddy’nin satış noktaları, zaten yaygın desteklenen alternatiflerden daha kolay olmaları değil; bu yüzden bana pek hitap etmiyor

• Birkaç hafta önce reverse proxy seçiyordum ve sonunda basitliği nedeniyle Caddy’de karar kıldım. Yine de Traefik’in konteynerleri otomatik keşfetmesi ve label referansları epey iyi; Caddy’de de aynı işi yapan bir eklenti var
  Yazıyı okudum ama Traefik’in benim için Caddy’den daha iyi bir yanı olup olmadığından hâlâ emin değilim. Başkaları için olabilir, bu yüzden görüşleri duymak isterim

• Traefik’in varsayılan olarak K3s’te yapılandırılmış olması da dikkate değer. Bu sayede K3s, test amaçlı bir K8s cluster’ını en hızlı ayağa kaldırma yöntemi hâline geldi ve cluster’ları da cattle gibi ele almayı sağlıyor
  Deployment’ı ve ilgili servisleri NodePort olarak eklemeniz yeterli; ingress controller’ı dert etmeden uygulamaya erişebiliyorsunuz
  Ben bir shell script ile K3s cluster’ı ayağa kaldırıyor, konumsal argümanla belirttiğim uygulamayı gerektiğinde test ediyorum. Bu sırada ttl.sh’nin geçici konteyner registry’sinden yararlanıyorum. Aynı script bittiğinde cluster’ı da kaldırıyor

• Self-hosting için kullandığım reverse proxy’yi Traefik’e taşımayı düşünüyorum. Yazarın aksine ben Docker Compose ile konteynerleştirilmiş workload’lar çalıştırıyorum ve şu anda harika caddy-docker-proxy eklentisi ile Caddy kullanıyorum
  Şu an elde ettiklerim: Docker label tabanlı yapılandırmaya sahip reverse proxy, yeni workload’ların otomatik algılanması, TLS sertifikaları ve caddy-dynamicdns eklentisiyle otomatik DNS yapılandırması. ISP farklı bir IP verse bile erişimi kaybetmeyi pek dert etmiyorum
  Ancak her yeni workload eklendiğinde ya da yeniden başlatıldığında Caddy’nin tamamı yeniden başlıyor ve erişim kısa süreliğine kesiliyor. Caddy mevcut bağlantıları yeni instance’a devredemiyor
  Ayrıca wildcard sertifika kullanımı yeterince basit değil. Tüm workload’larımın sertifika şeffaflığı logları üzerinden dünyaya görünmesini istemediğim için wildcard sertifika kullanıyorum; ama o zaman her host adı için sertifika kullanan basit Caddyfile söz dizimini kullanamıyorum. Caddy’de bunun üzerinde çalışıldığını biliyorum ama şimdilik durum bu
  Her hâlükârda k8s ortamında Traefik kullandım ve epey iyiydi; kişisel kullanım için de denemeyi düşünüyorum. Bu sözlerim yüzünden Caddy’yi denememezlik etmeyin. Caddy de gerçekten çok iyi

  • Tek amaçlı host’lar gibi yerlerde Caddy kullanıyorum ama tarif ettiğin sorun için %100 Traefik’i seçerdim. Gerçekten de k8s cluster’ıma gelen trafiği karşılamak için kullanıyorum ve geliştirme ortamında host adıyla birlikte localtest.me kullanmak için çalıştırıyorum
    Denemeye değer. İkisi de farklı alanlarda harika
  • Ben rootless Docker Compose + Traefik kullanıyorum. Çünkü wildcard sertifika gerçekten sorunsuz oldu. Yalnız kendi DNS sunucumu kullanıyorum ve Let's Encrypt DNS challenge için RFC2136 DDNS kullanıyorum
    Aslında eklentiye gerek yok. Bunların hepsini bir VM’e kuran ve compose dosyası şablonu da üreten bir Ansible playbook’um var; bir de sunucudaki veri ve mount’lar dışında her şeyi kaldıran başka bir playbook’um var. Yedekleme için dosyaları ve çeşitli DB’leri birden fazla konuma yedekleyebilen özel bir script ile restic kullanıyorum
    Eskiden k3s dağıtıyordum ama self-hosting için fazla abartılı ve karmaşık olduğunu fark ettim. Ben sadece hızlıca dağıtım yapmak ve sertifikalarla doğrudan uğraşmamak istiyorum
  • Caddy’yi denemedim, Traefik kullanıyorum; yapılandırma ve TLS sertifikalarının otomatik yenilenmesi için Docker özelliklerini keşfedip kullanıyor. Dinamik DNS’i pek bilmiyorum ve Traefik’te kullanmıyorum. Hatırladığım kadarıyla konteyner ekleyip kaldırınca yeniden başlatma gerekmiyordu
  • Production’da caddy-docker-proxy kullandım; yeni yapılandırmayı yüklerken Caddy bağlantıları kesmedi
    Az önce yerelde kontrol ettim, düzgün çalışıyor
  • Bu çok büyük bir kısıt. Yapılandırmayı yenilemek için yeniden başlatırken bağlantıları kesmek zorunda olan bir reverse proxy’yi ilk kez duyuyorum. Genelde bu tür sunucu tasarımlarında ilk ve en temel ele alınan kısım budur

• Traefik’i çok kullandım ama sırf bir reverse proxy koymak için docker-compose label’ları, katmanlar ve sayısız satırla uğraşmaktan yoruldum. Sonra Caddy’yi keşfettim ve bir daha arkama bakmadım
  Muhtemelen Traefik’in hedef kullanıcısı ben değildim. İhtiyacım olan şey HTTPS açık bir reverse proxy ya da temel kimlik doğrulama katmanı gibi bir şey. Caddy’de ikisi de tek satırla oluyor, çok öz ve hâlâ anlamadığım katmanlar da yok

• Birkaç yıldır self-host ettiğim her şeyde Traefik kullanıyorum.
  Ancak dinamik keşif ve Docker label özellikleri fazla zahmetliydi, debug etmek de sinir bozucuydu; bu yüzden bıraktım.
  Bunun yerine bir template engine ile statik yapılandırma dosyaları üretiyorum. Neredeyse tüm servisler host/target/port kombinasyonundan ibaret olduğu için ilgili bölümleri oluşturmak çok kolay; TLS işleme dışında karmaşık middleware de yok. Link verilen yazının yazarı da aynı yolu seçmiş gibi görünüyor.
  Yapılandırmayı Ansible script’iyle üretip Traefik’in çalıştığı makineye kopyalıyorum; Traefik de dosyanın bulunduğu dizini izleyip değişiklik olduğunda otomatik olarak yeniden yüklüyor. Şimdiye kadar gayet iyi çalıştı.

• Production’da Traefik’i container’larla birlikte kullanıyoruz ve en sevdiğim yanı yapılandırmanın container label’ları üzerinden taşınması. Bu yüzden Traefik yapılandırmasının kendisini neredeyse hiç değiştirmem gerekmiyor.
  En büyük dezavantajı, adının nasıl telaffuz edildiğini çözmek. Sanırım sıradan “traffic” gibi okunuyor ama insan sürekli “trey-feek” gibi söylemek istiyor.

  • Label yaklaşımına kesinlikle katılıyorum. İlk yazarken escape karakterleri ve uzunluğu yüzünden biraz daha zor, ama takip edilmesi gereken alanı inanılmaz azaltıyor.
    Traefik + Docker Compose kombinasyonunun, küçük ölçekli self-hosting’in k8s’e geçecek kadar büyümeden önceki iyi denge noktası olduğunu düşünüyorum; özellikle de k8s’in yüksek erişilebilirlikli control plane’inin kullandığından daha az sunucuya sahip durumlarda.
  • Biz de production’da kullanıyoruz. İnsanlar gülebilir ama kâğıt üzerinde havalı ve özgün görünse de pratikte berbat bir isim koymak ciddi bir dezavantaj.
    İş arkadaşlarımdan aldığım yüz ekşitme ve kahkaha miktarı inanılmazdı; ürünün benimsenmesini ve kullanılmasını engelledi.
    Biz “tray-feek” diyorduk ve nispeten kabul edilebilirdi; ama resmi destekle konuşunca normal “traffic” ile tamamen aynı telaffuz edildiğini söylediler. Bu yüzden o proxy’den bahsettiğimiz her seferinde “public load balancer olarak traffic alıyoruz, traffic’in native load balancing’i traffic’i traffic’in pod’una gönderiyor” gibi cümleler kuruluyor. Aptalca geliyor; gerçekten de aptalca.
  • Ben doğrudan “traffic” diye telaffuz ediyorum. Onların lanet akıl oyunlarına katılmayacağım.
  • Bence en büyük dezavantaj, container yoksa veya çalışmıyorsa Traefik’in o container’dan ya da label’larından haberdar olmaması.
    Öyle olmasaydı bakım sayfası göstermek, pasif durumdan sonra ilk istekte container’ı ayağa kaldırmak gibi güzel işleri daha kolay yapabilirdik.
    Bu yüzden compose dosyasının nerede saklandığını bilen ve oradan doğrudan okuyabilen bir plugin yazmayı düşünüyorum.
  • ae, y ya da hi sesine en yakın. Bu yüzden tahminim Tryfik; değilse Trayfik. Avrupa tarzı fik ise feek de olabilir.