Traefik 3.7 service middleware'ları: duyurudaki örnek çalışmıyor, doğru sözdizimi doğrulandı

Traefik'in kendi duyurusundaki örnek parse edilemiyor

"Langres" kod adlı Traefik 3.7, ana özelliği olarak service middleware'larla geldi: bir middleware'ı bir servise — weighted bir servisin tek bir child'ına bile — ekleyebilme, böylece load balancer bir backend seçtikten sonra çalışma imkânı. Ancak dev.to'daki uygulamalı bir yazıya göre Traefik'in duyuru gönderisindeki örnek YAML çalışmıyor. 3.7.14 çalıştıran bir container, konfigürasyonu başlangıçta field not found, node: middlewares hatasıyla reddediyor.

Sorun yerleşimde. Duyuru, middlewares anahtarını loadBalancer içine, servers ile aynı düzeye yerleştiriyor. Yazar, konfigürasyonu file provider üzerinden gerçek bir Traefik 3.7.14 container'ında test etti ve o sürümün Go kaynak kodunu da inceledi: Service struct'ında bir Middlewares []string alanı varken ServersLoadBalancer'da böyle bir alan hiç yok. Anahtar bir seviye yukarıda, service üzerinde loadBalancer'ın kardeşi olarak durmalıdır. Oraya taşınınca aynı container sorunsuz başladı.

Özelliğin kendisi çalışıyor

Sözdizimi düzeltildikten sonra dev.to yazısı temel iddiayı doğrulamaya koyuldu: bir service middleware'ın weighted bir servisin tek bir branch'ini hedefleyebildiği. Test, stabil bir backend ile bir canary arasında 9:1'lik weighted bir bölme ve yalnızca canary servisine eklenmiş X-Canary: true ayarlayan bir middleware ile yapıldı.

Sonuçlar tam isabetliydi. 200 sıralı istek boyunca 180'i stabil backend'e, 20'si canary'e gitti — kusursuz bir 90/10 eşleşmesi — ve header 20 canary yanıtının tamamında, 180 stabil yanıtın hiçbirinde görünmedi. İkinci bir koşuda, bir seferde 50 istek gönderen toplam 500 istek aynı bölmeyi ve aynı izolasyonu üretti; bu da eşzamanlılık altında branch seçimi ile middleware çalıştırılması arasında bir yarış durumunu dışladı.

Ham istek dizisinden operasyonel bir nüans ortaya çıktı: ağırlıklandırma rastgele örnekleme değil, belirleyicidir; sabit bir düzende kabaca her on istekte bir canary isteği gelir. Canary'yi elle, birkaç istekle test eden biri ona hiç denk gelmeyebilir ya da bir döngüdeki sabit yuvalı bir dalı olasılık sanabilir.

Sıralama ve inline sınırlaması

Yazı ayrıca belgelenmiş sıralama iddiasını — router middleware'ları service middleware'lardan önce çalışır — aynı X-Trace header'ını ayarlayan bir router seviyesi ve bir service seviyesi middleware ile katmanlayarak kontrol etti. Service middleware, 500 canary isteğinin her birinde router'ın değerinin üzerine yazdı; stabil branch ise yalnızca router'ın değerini gördü. Belgelenmiş sıra geçerliydi.

Duyurudaki, weighted veya mirrored child'ların inline middleware taşıyamayacağı sınırlaması da geçerli ama bir dikenle birlikte: buna rağmen denemek aynı field not found hatasını üretir, çünkü WRRService struct'ında da Middlewares alanı yoktur. Ve hata tüm file provider konfigürasyonunu geçersiz kıldığından, weighted bir child'daki tek bir başıboş middlewares: satırı, o provider'ın yönettiği her router'ın — yalnızca düzenlenen router'ın değil — güncellenmesini durdurur.

Eski sürümler ve bir API körlüğü

Aynı dinamik konfigürasyonun değiştirilmeden "ramequin" kod adlı Traefik 3.6.25 üzerinde çalıştırılması, yazıya göre aynı hatayı üretir: kısmi bir destek yoktur ve file provider'ın tamamı yüklenmeyi reddeder. Sürümler arasında konfigürasyon paylaşan ekipler, 3.6'nın yeni alanı sessizce yok sayıp yoluna devam etmeyeceğini bilmeli.

dev.to yazarı ayrıca Traefik'in API'sinin gerçeğe aykırı davrandığını buldu: canary header middleware'ı açıkça canlıydı ve gerçek trafiği değiştirirken /api/http/middlewares endpoint'i onun için usedBy: None bildiriyordu. Bir middleware'ın silinmesinin güvenli olup olmadığını judgede kullanmak isteyen herkes, service'e ekli middleware'lar için yanıltıcı bir yanıt alır.

Neden önemli

Service middleware'lar birçok ops ekibinin 3.7'ye yükselme nedeni, ancak duyurunun kendi örneği bir uyarı yerine sert bir başlangıç hatası üretecek şekilde başarısız oluyor. Etki alanı da göründüğünden daha geniş: tek bir yanlış yerleştirilmiş anahtar, birçok dosyadaki düzinelerce ilgisiz router dahil tüm file provider'ı devre dışı bırakabilir. Service seviyesindeki eklemeleri yansıtmayan bir usedBy alanıyla birleşince, yükselen ekipler dağıtımdan önce konfigürasyonları doğrulamalı, middlewares anahtarını service seviyesinde tutmalı ve bu yeni eklemelerin etki analizi için API'ye güvenmemelidir. Testlerle doğrulanan artı taraf ise şu: doğru sözdizimi kullanıldığında temel özellik — weighted servislerde branch başına middleware izolasyonu — tam olarak vadedildiği gibi çalışıyor.