Sunucu sayısı arttıkça “bu servis şu an nerede çalışıyor ve sağlıklı mı” sorusunu elle takip etmek mümkün olmaz. Consul bu soruyu merkezî bir kayıt ve sağlık kontrolü katmanıyla yanıtlar.
Consul; HashiCorp tarafından geliştirilen, servis keşfi, sağlık kontrolü, KV store ve service mesh yeteneklerini tek bir araçta birleştiren altyapı yazılımıdır. Mikroservis mimarilerinde “bu servis nerede çalışıyor?” sorusunu DNS veya HTTP API ile yanıtlar; servislerin sağlık durumunu izler ve trafiği yalnızca sağlıklı instance’lara yönlendirmeye yardımcı olur.
Consul Connect bileşeni, servisler arası iletişimi mTLS ile şifreler ve intention kurallarıyla hangi servisin hangisiyle konuşabileceğini tanımlar. Bu, geleneksel firewall kurallarına kıyasla çok daha dinamik ve uygulama-farkında bir güvenlik katmanı sağlar. Ancak bu, Consul’un her kurulumda mutlaka kullanılması gereken bir bileşen olduğu anlamına gelmez servis keşfi ve health check tek başına da değerli bir kullanım şeklidir.
Kim için uygun, kim için değil
- Uygun: sanal makine ve Kubernetes’in birlikte kullanıldığı, çok bölgeli servis keşfi ihtiyacı olan ekipler
- Uygun: belirli bir kritik servisi DC’ler arası DNS ve health check ile erişilebilir kılmak isteyenler. Consul’u her sunucuya kurmadan, sadece hedef sunucuya kurup firewall DNS forwarding ile
- Uygun değil: tamamen Kubernetes içinde kalan ve yerleşik servis keşfi yeterli olan ortamlar
- Uygun değil: lisans koşullarına hassas olup kaynağı görünür (BSL) modeli kabul etmeyen kurumlar
Maliyet kalemleri
- Consul’un kurulu olduğu sunucu(lar)ın bakımı ve health check tanımlarının güncel tutulması
- Firewall/DNS forwarder yapılandırmasının bakımı
- TLS, ACL operasyonu (kullanılıyorsa)
- Sürüm ve lisans değişikliklerinin izlenmesi
Resmi kaynaklar
Mono’nun yaklaşımı
Consul’u tüm altyapıya yayılan genel bir service mesh/discovery katmanı olarak değil, hedefe özel (targeted) servis keşfi için kullanıyoruz. Tipik senaryo: birden fazla DC’de (örneğin Ankara ve İstanbul) çalışan uygulamaların, o an hangi sunucuda ayakta olduğu değişebilen kritik bir servise DNS üzerinden, sağlık kontrolüyle birlikte erişebilmesi.
Mono’ya özel kullanım pratiği:
- Kurulum kapsamı: Consul agent’ı yalnızca ilgili kritik servisin çalıştığı sunucuya kurulur; bağlanacak taraflarda (uygulama sunucuları, k8s node’ları vb.) Consul çalıştırılmaz ve bunlar cluster’ın bir parçası değildir.
- Health check: Kritik servis için bağlantı/servis durumu health check ile izlenir; sağlıksız durumda DNS yanıtı buna göre güncellenir.
- Firewall DNS forwarding: Ankara/İstanbul gibi farklı lokasyonlardaki firewall’lar,
.consulalan adına giden DNS sorgularını Consul’un çalıştığı sunucudaki DNS arayüzüne (port 8600) yönlendirecek şekilde yapılandırılır. Böylece o taraftaki servisler<servis-adi>.service.consulgibi bir isim çözerek güncel ve sağlıklı adrese ulaşır; IP hardcode edilmez. - Kapsam dışı bırakılanlar: Bu kurulumda Consul KV store, Consul Connect (mTLS service mesh) veya WAN gossip ile tam multi-DC federation aktif olarak kullanılmaz ihtiyaç bu üçünü gerektirmediği sürece kapsam bilinçli olarak dar tutulur.
Tüm servisler için genel bir service mesh gerektiğinde (ör. hibrit VM + Kubernetes ortamında yaygın servisler arası mTLS ihtiyacı doğduğunda) Consul Connect ayrıca değerlendirilir; ama bu, varsayılan kurulum değil, ek bir karardır.
Sıkça sorulan sorular
Consul nedir, ne işe yarar?
Consul vs etcd vs Zookeeper farkı nedir?
Consul ücretsiz mi?
Service mesh için Consul mu Istio/Linkerd mi?
Consul'u her sunucuya mı kurmak gerekiyor?
.consul alan adına giden sorguları Consul’un DNS arayüzüne (port 8600) yönlendirmek yeterlidir. Bu, tam bir multi-DC Consul federation’ından çok daha az operasyonel yük getiren, hedefe özel (targeted) bir kullanım şeklidir.