Alexander Sigachev'in Consul'u örnek alarak dağıtılmış sistemlerde Hizmet Keşfi raporunun metnini okumanızı öneririm.
Service Discovery, yeni bir uygulamayı mevcut ortamımıza minimum maliyetle bağlayabilmeniz için oluşturuldu. Hizmet Keşfi'ni kullanarak, bir docker konteynerini veya bir sanal hizmeti çalıştığı ortamdan maksimum düzeyde ayırabiliriz.
Herkese hoş geldiniz diyorum! Ben Alexander Sigachev, Inventos'ta çalışıyorum. Ve bugün sizi Hizmet Keşfi gibi bir kavramla tanıştıracağım. Örnek olarak Consul'u kullanarak Service Discovery'ye bakalım.
Service Discovery hangi sorunları çözer? Service Discovery, yeni bir uygulamayı mevcut ortamımıza minimum maliyetle bağlayabilmeniz için oluşturuldu. Hizmet Keşfi'ni kullanarak, bir docker konteynerini veya bir sanal hizmeti çalıştığı ortamdan maksimum düzeyde ayırabiliriz.
Nasıl görünüyor? Webdeki klasik bir örnekte bu, kullanıcının isteğini kabul eden ön uçtur. Daha sonra onu arka uca yönlendirir. Bu örnekte, bu yük dengeleyici iki arka ucu dengeler.
Burada uygulamanın üçüncü örneğini başlattığımızı görüyoruz. Buna göre uygulama başlatıldığında Service Discovery’ye kaydolur. Service Discovery, yük dengeleyiciye bildirimde bulunur. Yük dengeleyici, yapılandırmasını otomatik olarak değiştirir ve yeni arka uç devreye alınır. Bu şekilde arka uçlar eklenebilir veya tam tersine işten çıkarılabilir.
Hizmet Keşfi ile başka neler yapılabilir? Service Discovery, nginx yapılandırmalarını, sertifikalarını ve etkin arka uç sunucularının bir listesini depolayabilir.
Service Discovery ayrıca arızaları tespit etmenize ve arızaları tespit etmenize olanak tanır. Arızaları tespit etmek için olası şemalar nelerdir?
- Geliştirdiğimiz bu uygulama, Service Discovery'ye otomatik olarak hala çalışır durumda olduğunu bildirir.
- Service Discovery ise uygulamanın kullanılabilirliğini araştırır.
- Veya uygulamamızın kullanılabilirliğini kontrol eden ve Hizmet Keşfetme'ye her şeyin yolunda olduğunu ve çalışabileceğini bildiren veya tam tersine her şeyin kötü olduğunu ve uygulamanın bu örneğinin dengeleme dışında bırakılması gerektiğini bildiren bir üçüncü taraf komut dosyası veya uygulaması kullanırız.
Kullandığımız yazılıma bağlı olarak şemaların her biri kullanılabilir. Örneğin yeni bir proje geliştirmeye başladık, sonrasında uygulamamız Service Discovery’ye bildirimde bulunduğunda kolaylıkla bir şema sağlayabiliyoruz. Veya Service Discovery'nin kontrol ettiğini bağlayabiliriz.
Uygulamayı devraldıysak veya başka biri tarafından geliştirildiyse, işleyiciyi yazarken üçüncü seçenek uygundur ve tüm bunlar otomatik olarak işimize gelir.
Bu bir örnek. Nginx biçimindeki yük dengeleyici yeniden başlatıldı. Bu, Consul ile birlikte sağlanan isteğe bağlı bir yardımcı programdır. Bu konsolosluk şablonudur. Kuralı açıklıyoruz. Bir şablon (Golang Şablon Motoru) kullandığımızı söylüyoruz. Olaylar meydana geldiğinde, değişiklik oluştuğuna dair bildirimler geldiğinde yeniden oluşturulur ve Service Discovery'ye “yeniden yükle” komutu gönderilir. En basit örnek, nginx'in bir olay tarafından yeniden yapılandırılması ve yeniden başlatılmasıdır.
Konsolos nedir?
-
Her şeyden önce bu Hizmet Keşfidir.
-
Bir kullanılabilirlik kontrol mekanizması vardır - Sağlık Kontrolü.
-
Aynı zamanda bir KV Mağazası da var.
-
Ve Multi Datacenter kullanma yeteneğine dayanmaktadır.
Bütün bunlar ne için kullanılabilir? KV Mağazasında örnek yapılandırmaları saklayabiliriz. Sağlık Kontrolü yerel hizmeti kontrol edebilir ve bildirimde bulunabiliriz. Servis haritasının oluşturulabilmesi için Multi Datacenter kullanılmaktadır. Örneğin Amazon'un çeşitli bölgeleri vardır ve trafiği en uygun şekilde yönlendirir, böylece yerel trafikten ayrı olarak ücretlendirilen ve dolayısıyla daha az gecikmeye sahip olan veri merkezleri arasında gereksiz istekler olmaz.
Consul'da kullanılan terimleri biraz anlayalım.
- Consul, Go'da yazılmış bir hizmettir. Go programının avantajlarından biri, indirdiğiniz 1 ikili dosyadır. Her yerden başlatılır ve herhangi bir bağımlılığınız yoktur.
- Daha sonra tuşları kullanarak bu hizmeti istemci modunda veya sunucu modunda başlatabiliriz.
- Ayrıca “datacenter” özelliği bu sunucunun hangi veri merkezine ait olduğuna dair bir bayrak belirlemenizi sağlar.
- Konsensus – sal protokolüne dayanmaktadır. İlgilenen varsa, bu konuda daha fazla bilgiyi Consul'un web sitesinde okuyabilirsiniz. Bu, lideri belirlemenize ve hangi paranın geçerli ve erişilebilir kabul edildiğini belirlemenize olanak tanıyan bir protokoldür.
- Dedikodu, düğümler arasında etkileşimi sağlayan bir protokoldür. Üstelik bu sistem merkezi değildir. Bir veri merkezinde tüm düğümler komşularıyla iletişim kurar. Ve buna göre mevcut duruma ilişkin bilgiler birbirlerine iletilir. Bunun komşular arasındaki dedikodu olduğunu söyleyebiliriz.
- LAN Dedikodu – aynı veri merkezi içindeki komşular arasında yerel veri alışverişi.
- WAN Dedikodu - iki veri merkezi arasındaki bilgileri senkronize etmemiz gerektiğinde kullanılır. Sunucu olarak işaretlenen düğümler arasında bilgi akışı sağlanır.
- RPC – istekleri sunucudaki bir istemci aracılığıyla yürütmenize olanak tanır.
RPC'nin açıklaması. Diyelim ki Consul bir sanal makine veya fiziksel sunucu üzerinde istemci olarak çalışıyor. Kendisiyle yerel olarak iletişime geçiyoruz. Daha sonra yerel istemci sunucudan bilgi ister ve senkronize edilir. Ayarlara bağlı olarak bilgiler yerel önbellekten alınabilir veya liderle, sunucu yöneticisiyle senkronize edilebilir.
Bu iki programın hem artıları hem de eksileri var. Yerel bir önbellekle çalışırsak hızlıdır. Sunucuda depolanan verilerle çalışırsak bu daha uzun sürer ancak daha alakalı bilgiler alırız.
Bunu grafiksel olarak tasvir ederseniz, bu sitenin resmidir. Üç ustamızın çalıştığını görüyoruz. Biri lider olarak yıldız işaretiyle işaretlenmiştir. Bu örnekte, UDP/TCP aracılığıyla birbirleriyle yerel olarak bilgi alışverişinde bulunan üç istemci bulunmaktadır. Veri merkezleri arasındaki bilgiler de sunucular arasında aktarılır. Burada müşteriler birbirleriyle yerel olarak etkileşime girer.
Consul hangi API'yi sağlıyor? Bilgi elde etmek için Consul'un iki tür API'si vardır.
Bu DNS API'sidir. Consul varsayılan olarak 8600 numaralı bağlantı noktasında çalışır. İstek proxy'sini yapılandırabilir ve yerel DNS aracılığıyla yerel çözümleme yoluyla erişim sağlayabiliriz. Etki alanına göre sorgulama yapabilir ve yanıt olarak IP adresi bilgilerini alabiliriz.
HTTP API - veya 8500 numaralı bağlantı noktasındaki belirli bir hizmet hakkında yerel olarak bilgi talep edebilir ve bir JSON yanıtı, sunucunun hangi IP'ye sahip olduğu, hangi ana bilgisayarın, hangi bağlantı noktasının kayıtlı olduğunu alabiliriz. Ve ek bilgiler jeton aracılığıyla iletilebilir.
Konsolosluğu çalıştırmak için neye ihtiyacınız var?
İlk seçenekte geliştirici modunda bunun geliştirici modu olduğunu belirten bayrağı belirtiyoruz. Aracı bir sunucu olarak başlar. Ve tüm işlevi bağımsız olarak tek bir makinede gerçekleştirir. Kullanışlı, hızlı ve pratik olarak ilk çalıştırma için hiçbir ek ayar gerekmez.
İkinci mod üretimde lansmandır. İşte bu noktada başlangıç biraz karmaşıklaşıyor. Eğer consul'un herhangi bir versiyonu yoksa, o zaman ilk makineyi, yani liderin sorumluluklarını üstlenecek olan bu makineyi bootstrap'e getirmeliyiz. Onu yükseltiyoruz, ardından sunucunun ikinci örneğini yükselterek, ustamızın bulunduğu yere bilgi aktarıyoruz. Üçüncüyü yükseltiyoruz. Üç makinemiz açıldıktan sonra, çalışan önyüklemeden ilk makinede normal modda yeniden başlatıyoruz. Veriler senkronize edilmiştir ve ilk küme zaten çalışır durumdadır.
Sunucu modunda üç ila yedi örneğin çalıştırılması önerilir. Bunun nedeni, sunucu sayısı arttıkça aralarında bilgi senkronizasyonu süresinin artmasıdır. Yeter sayının sağlanması için düğüm sayısının tek olması gerekir.
Sağlık Kontrolleri Nasıl Sağlanıyor? Consul konfigürasyon dizinine Json formatında bir doğrulama kuralı yazıyoruz. Bu örnekte ilk seçenek google.com alan adının kullanılabilirliğidir. Biz de bu kontrolün 30 saniye aralıklarla yapılması gerektiğini söylüyoruz. Bu şekilde düğümümüzün harici ağa erişimi olup olmadığını kontrol ediyoruz.
İkinci seçenek ise kendinizi kontrol etmektir. Belirtilen bağlantı noktasında localhost'u 10 saniyelik aralıklarla çağırmak için normal kıvrılmayı kullanırız.
Bu kontroller özetlenir ve Service Discovery'ye gönderilir. Kullanılabilirliğe bağlı olarak bu düğümler ya hariç tutulur ya da kullanılabilir ve doğru şekilde çalışan makineler listesinde görünür.
Consul ayrıca ayrı bir bayrakla başlatılan ve makinede mevcut olacak bir kullanıcı arayüzü arayüzü de sağlıyor. Bu, bilgileri görüntülemenize olanak tanır ve ayrıca bazı değişiklikler yapabilirsiniz.
Bu örnekte “Servis” sekmesi açıktır. Biri Konsolos olmak üzere üç hizmetin çalıştığı görülüyor. Gerçekleştirilen kontrol sayısı. Ve makinelerin bulunduğu üç veri merkezi var.
Bu, Düğümler sekmesinin bir örneğidir. Veri merkezlerini kapsayan bileşik isimlerinin olduğunu görüyoruz. Ayrıca hangi hizmetlerin çalıştığını da gösterir; yani hiçbir etiketin ayarlanmadığını görüyoruz. Bu ek etiketler, geliştiricinin ek parametreleri belirtmek için kullanabileceği bazı bilgiler sağlayabilir.
Disklerin durumu ve ortalama yük hakkında da Konsolos'a bilgi iletebilirsiniz.
sorular
Soru: Docker Container'ımız var, Consul ile nasıl kullanabiliriz?
Cevap: Liman konteyneri için çeşitli yaklaşımlar vardır. En yaygın olanlardan biri, kayıttan sorumlu üçüncü taraf liman işçisi konteynerini kullanmaktır. Başlangıçta ona bir docker soketi iletilir. Tüm kapsayıcı kayıt ve yayından kaldırma olayları Consul'da kaydedilir.
Soru: Yani Docker konteynerini Consul kendisi mi başlatıyor?
Cevap: Hayır. Bir liman konteyneri çalıştırıyoruz. Ve yapılandırırken şunu belirtiyoruz - falan filan soketi dinleyin. Bu, nerede ve neye sahip olduğumuza dair bilgileri yüklediğimizde, bir sertifikayla çalışma şeklimizle yaklaşık olarak aynıdır.
Soru: Service Discovery'ye bağlanmaya çalıştığımız Docker konteynerinin içinde Consul'a veri gönderebilecek bir tür mantığın olması gerektiği ortaya çıktı.
Cevap: Gerçekten değil. Başladığında değişkenleri ortam değişkeninden geçiririz. Servis adı, servis portu diyelim. Kayıt defteri bu bilgiyi dinler ve Konsolos'a girer.
Soru: Kullanıcı arayüzüyle ilgili başka bir sorum daha var. Kullanıcı arayüzünü örneğin bir üretim sunucusuna yerleştirdik. Peki ya güvenlik? Veriler nerede saklanıyor? Bir şekilde veri biriktirmek mümkün mü?
Cevap: Kullanıcı arayüzünde veritabanından ve Hizmet Keşfinden veriler bulunur. Ayarlarda şifreleri kendimiz belirliyoruz.
Soru: Bu internette yayınlanabilir mi?
Cevap: Varsayılan olarak Consul localhost'ta başlar. İnternette yayınlamak için bir tür proxy yüklemeniz gerekecektir. Kendi güvenlik kurallarımızdan biz sorumluyuz.
Soru: Kutunun dışında tarihsel veriler sağlıyor mu? Sağlık Kontrolleri ile ilgili istatistiklere bakmak ilginç. Sunucunun sıklıkla arızalanması durumunda da sorunları teşhis edebilirsiniz.
Cevap: Orada çeklerin ayrıntılarının olduğundan emin değilim.
Soru: Mevcut durum dinamikler kadar önemli değil.
Cevap: Analiz için – evet.
Soru: Consul liman işçisi için Service Discovery'yi kullanmamak daha mı iyi?
Cevap: Kullanmanızı tavsiye etmem. Raporun amacı böyle bir kavramın ne olduğunu ortaya koymaktır. Tarihsel olarak bana göre 1. versiyona kadar yol almıştır. Artık tüm bunları kapsayan Kubernetes gibi daha eksiksiz çözümler var. Kubernetes'in bir parçası olarak Service Discovery, Etcd'den daha düşüktür. Ama buna Konsolos kadar aşina değilim. Bu nedenle Consul'u örnek alarak Service Discovery yapmaya karar verdim.
Soru: Lider sunuculu şema uygulamanın bir bütün olarak başlatılmasını yavaşlatmıyor mu? Peki eğer yalan söylüyorsa Konsolos yeni lideri nasıl belirleyecek?
Cevap: Açıklanmış bütün bir protokolleri var. İlginizi çekiyorsa okuyabilirsiniz.
Soru: Consul bizim için tam teşekküllü bir sunucu görevi görüyor ve tüm talepler bunun üzerinden mi uçuyor?
Cevap: Tam teşekküllü bir sunucu görevi görmez, belirli bir bölgeyi devralır. Genellikle service.consul ile biter. Daha sonra mantıksal olarak devam ederiz. Üretimde alan adlarını kullanmıyoruz, bunun yerine DNS kullanarak çalışıyorsak genellikle sunucu önbelleğinin arkasına gizlenen dahili altyapıyı kullanıyoruz.
Soru: Yani, eğer bir veritabanına erişmek istiyorsak, o zaman her halükarda önce bu veritabanını bulmak için Consul'u çekeceğiz, değil mi?
Cevap: Evet. DNS kullanarak çalışıyorsak, DNS adlarını kullandığımızda Consul olmadan da aynı şekilde çalışır. Genellikle modern uygulamalar her istekte alan adını çekmez, çünkü connect'i kurduk, her şey çalışıyor ve yakın gelecekte pratik olarak onu kullanmıyoruz. Bağlantı kesilirse evet, üssümüzün nerede olduğunu tekrar sorup ona gidiyoruz.
— Hashicorp kullanıcı sohbeti: Consul, Nomad, Terraform
PS Sağlık kontrolleriyle ilgili. Consul, Kubernetes gibi, bir hizmetin hayatta kalma durumunu kod durumuna göre kontrol etmek için aynı sistemi kullanır.
200 OK for healthy
503 Service Unavailable for unhealthyKaynaklar:
Kaynak: habr.com