Traefik Proxy Temelleri

Bu yazıda, mikroservisler özelinde hazırlanmış olan Traefik ters vekil sunucunun temel kavramlarından bahsedeceğim. Traefik, Docker, Mesos, Consul, Kubernetes gibi birçok altyapı ile birlikte çalışabilen ve dinamik olarak servis ekleme/çıkarma olanağına sahip olarak tasarlanmış; yük dengeleme(load balancing) ve healthcheck işlemlerini gerçekleştirebilen, kendi tanımıyla bir modern HTTP ters vekil sunucusu ve yük dengeleyici olarak mikroservislerde işimizi kolaylaştırıyor. Benzer çözümlere göre baktığımızda şu an açık ara ilerde olduğunu söyleyebilirim(Haziran 2017).

Traefik vekil sunucusunun en güzel özelliklerinden biri, kurulumu düzgün bir şekilde tek seferlik yaptıktan sonra, artık üzerine hiçbir müdahalede bulunmadan, kendisi yokmuş gibi davranarak işlemleri yürütebiliyor olmamız. Bunun bize sağladığı fayda ise hem her backend servis değişikliğinde vekil sunucuya müdahale etmekten kaçınmak hem de yeni servis eklendiğinde yine vekil sunucuya müdahale etmeden, erişilebilirlikten de ödün vermeden süreci yönetebilmek.

Traefik üzerinde aynı zamanda SSL sonlandırma ve Let’s Encrypt desteği de var. Bu aslında oldukça işe yarar bir özellik, çünkü özellikle Let’s Encrypt kullanıyorsanız, sertifika alma ve yenileme işlemlerini otomatik olarak yapabiliyor. Yani bir kez ayarladıktan sonra sertifika ile uğraşmamıza bir daha hiç gerek kalmıyor. Aynı zamanda birden çok alan adı olduğu durumlarda da her alanadı için bu süreci otomatik olarak yönetebiliyor. Benzer şekilde, başka yerden imzalattığımız sertifikaları sunabiliyor veya Let’s Encrypt dışındaki sağlayıcılarla iletişime geçmesini istersek onu da yaparak yine sertifika sürecini otomatik olarak halledebiliyor. Özellikle şifrelenmiş veya dışarıya tamamen yalıtılmış ağlar kullanırken SSL sonlandırma aşamasını üstlenmesi, arka taraftaki servisler için oldukça kullanışlı bir hal alıyor.

Bu kadar bahsetmişken, bazı noktalarda dokümantasyon eksikliği veya örneklerin azlığı yaşanabilen sıkıntılar arasında. Aslında basit kısımlar için kendi dokümanları ve örnekleri son derece yeterli ancak işler karmaşıklaştıkça, ilk kurulumda veya müdahale gerektiğinde onun kavramlarına ve olduğunca hakim olmak gerekebiliyor. İşin güzel kısmı ise, Docker Swarm Mode üzerindeki servis tanımlamalarını otomatik ve dinamik olarak tanıyabilen çok az alternatif varken, bence şu an en iyi çalışanı Traefik. Bu yazıyı yazmamın sebebi de tam olarak bu paragrafta bahsettiklerim. Özelliklerden daha fazla bahsetmeden, temel kavramlarına geçeyim.

Traefik Proxy, kendisine gelen isteği arka tarafta ilgili servise yönlendirmeden önce 3 aşamadan geçiriyor. Bunların İngilizce karşılıkları Entrypoints, Frontends ve Backends olarak geçiyor. Bunları ara ara Türkçe kullanarak giriş noktaları, ön yüz ve arka yüz olarak anacağım. Türkçe karşılıkları konusunda önerileriniz varsa yorumlarda belirtirtebilirsiniz.

Entrypoints (Giriş noktaları)

Sunucuya gelen isteklerin ilk karşılandıkları yer giriş noktaları oluyor. Aslında ismiyle münhasır bir kavram. TLS sonlandırma, trafik yönlendirme(mesela HTTP’den gelenleri HTTPS’e zorlama), ya da daha önce denk geldiyseniz istemci tarafındaki TLS(client certificate authentication veya client side SSL olarak da karşımıza çıkar) gibi işlemler burada yapılır. Haliyle doğru yapılandırılması, ziyaretçilerin tarayıcılarındaki sertifika hatalarını önlemek için ve https yönlendirmesi için önem taşıyor.

Frontends (Ön yüzler)

Bu kavram başlangıçta aklımıza gelenden biraz farklı. Yani sitenin frontend yazılımındaki kavramla bir alakası yok gibi. Entrypoints’den gelen istekler bu kısma yönlendirilir. Bu kısımda, gelen isteklerin kontrolü yapılarak bu istek tanımlandırmaya çalışılır. Frontend’ler aslında kurallardan oluşuyor. Gelen isteği Host, Header veya Path alanlarına göre tanımlamak mümkün. Bu alanlarda da düzenli ifadeler kullanabiliyoruz. Haliyle gelen isteği örneğin API sürümüne göre, geldiği alan adına göre, alt alan adına göre veya bunların kombinasyonu şeklinde farklı servislere yönlendirme işlemini bu kısımda halletmemiz gerekiyor. Burda yanlışlık yaparsak eşleşme olmayabilir ve istekler hata ile sonuçlanabilir.

Backends (Arka yüzler)

Frontend, gelen isteği tanımladıktan sonra artık backends tarafına gönderir. Burda artık yük dengeleme işlemi ve hangi servisler/sunucular var gibi tanımlamalar bulunur. Örneğin yetkilendirme servisi veya kimlik doğrulama servislerinin bulunduğu iki makineden biri diğerinin 2 katı sorguya cevap verecek nitelikteyse, ağırlıklı Round Robin (weighted round robin, WRR) yük dengeleme yöntemi bu aşamada gerçekleştirilerek, güçlü olan sunucuya 2 kat fazla isteğin gitmesi sağlanabilir. CircuitBreaker kullanılıyorsa o da bu bölümde, arka taraftaki servislerin verdiği cevapların istatistiklerini gözlemleyerek istenen aksiyonları alması sağlanabilir.

Bonus: Traefik’in aynı zamanda dinamik Round Bobin (DRR) desteği ile, arka taraftaki servisler/sunucular arasında cevap verme süresine göre yük dengeleme canlı bir şekilde gerçekleştirilebilir.

Bu üç aşamadan sonra artık istek, ilgili servise yönlendirilerek cevabı kullanıcıya iletilir. Ayrıca, sticky session (yapışkan oturum) desteğini de (mikroservis dünyasında ihtiyacımız pek olmasa da) kullanıcılardan gelen sonraki isteklerin aynı servis örneği üzerine aktarılmasını sağlayabilirsiniz.

Docker Swarm Mode için özel not:

Docker Swarm Mode, daha özelinde SwarmKit, içerisinde bulundurduğu network altyapısında varsayılanda IPVS ile yük dengeleme yapar. IPVS, Linux çekirdeğinde uzun zamandır bulunan bir yük dengeleme yöntemi. Docker dışında da uzun zamandır yüksek verimlilikle yük dengelemek için birçok yerde production ortamında kullanılıyor. Sadece RR, WRR değil, source caching, destination hashing gibi ücretli/ücretsiz birçok çözümün sağlamadığı yük dengeleme yöntemlerini destekliyor. IPVS üzerinde, istek tek bir IP adresine geliyor ve Linux çekirdeği arkadaki mikroservislere verdiği IP adresleri arasında bunu dağıtıyor. Yalnız her serviste IPVS’in tek olan IP’si de ekli halde duruyor ve bu şekilde source IP’ye bunu yazarak, doğrudan isteği ileten istemciye cevap veriyorlar. Bu yöntem load balancer üzerindeki trafiği %50 azalttığı için aslında oldukça verimli çalışıyor. İsterseniz eski usul takılıp Round Robin olacak şekilde network oluştururken yük dengeleme yöntemini söyleyebiliyorsunuz. Bu şekilde işlem yaptığınızda da istemci her istek yaptığında bir sonraki mikroservis örneğine ait IP adresini alıyor.

Kısaca bahsettiğim bu bilgilerde bizi ilgilendiren kısım, IPVS kullandığımızda, arkadaki konteynırların kendi IP adreslerini(IPVS’e ait olan ortak adres değil) alıp, istekleri doğrudan onlara yönlendiriyor. Yani aslında IPVS’i servisler arasında kullanmaya devam ederken diğer taraftan Traefik üzerinden gidenlerin yük dengelemesinden yine Traefik sorumlu oluyor. Yukarıda bahsettiğim özellikleri de bu şekilde kullanmış oluyoruz. Bu kavramsal olarak biraz daha detaylı olduğu için başka bir yazıda uzun uzun bahsederim.