‫Bu yüzden sihirin küçük bir kısmı aslında büyü yapmadı. Yönlendirme Örgütü oldu. Yönlendirme Meşesi, hizmetimiz
‫için paketleri servisin görevlerine dağıtan gelen veya giren bir ağdır, çünkü
‫birden fazla görev alabiliriz.
‫Bu aslında bütün düğümleri kapsar ve aslında IPVS olarak adlandırılan bir süre civarında olan Bu yüzden bazı fantezi yeni servis hakkında konuşmuyoruz. Gerçekten sadece Linux çekirdeğinin çekirdek özellikleri
‫Çekirdek temel öğelerini kullanıyor. hakkında konuşuyoruz. Gerçekten burada ne yapıyor, tüm düğümlerde
‫yük dengelemek ve trafik için tüm düğümleri dinlemek.
‫Bunun nasıl işlediği hakkında konuşabileceğimiz birkaç yol var.
‫İlk örnek, bir kaptan diğerine.
‫Arka uç sistemimiz, örneğin
‫veritabanları söyleyince, iki kopyaya yükseltilirse, arka
‫uçlarla konuşan ön uçlar, doğrudan kendi IP adresiyle doğrudan konuşmazlar.
‫Aslında, Swarm'ın tüm hizmetlerin
‫önüne koyduğu VIP veya Sanal IP adı verilen bir şeyle konuşurlardı.
‫Bu Swarm sanal ağında özel bir IP'dir ve yükün bir hizmet için tüm görevler
‫arasında dağıtılmasını sağlar.
‫olup olmadığını ve 10 farklı konteyneriniz olduğunu hayal edebiliyorsanız, bunun önüne bir yük dengeleyici koymanız gerekmez.
‫Dolayısıyla uygulamanızda bir işçi rolünüz
‫Bu senin için yapar.
‫Sanal ağınızdaki bir hizmetin trafiğinden bahsederken, sanal
‫ağınızdaki başka bir servisle konuşurken.
‫Yönlendirme kafesinin nasıl çalıştığının ikinci örneği, sürüşünüze gelen harici trafik aslında sürüdünüzdeki düğümlerden herhangi
‫birini vurmayı seçebilir.
‫İşçi düğümlerinden herhangi biri, yayınlanan bağlantı noktasını açık tutacak ve bu kapsayıcının trafiğini dinleyecek ve
‫sonra bu trafiği, yük dengelemesine dayanarak uygun konteynere yönlendirecektir.
‫Bunun anlamı, konteynerleri bir sürü içinde konuşlandırdığınızda, taşıdığı için
‫sunucunun ne olduğu konusunda önemsemeniz gerekmiyor, değil mi?
‫Bir konteyner başarısız olursa ve görev sürü tarafından yeniden oluşturulursa, onu farklı bir düğüme koyabilir. Ayrıca, kabın tekrar çalışması için firewall'ınızı veya
‫DNS ayarlarınızı değiştirmek zorunda
‫kalmayı kesinlikle istemezsiniz.
‫Yönlendirme kafesi, port 80'deki Drupal web sitemizin sürüdeki herhangi bir düğümden erişilebilmesini sağlayarak bu
‫sorunları birçoğunu çözer. Ve arka
‫planda, o sunucudan gelen paketleri alıyor ve daha sonra bunları kapsayıcıya yönlendiriyor. ise, sanal ağlar üzerinden yönlendirir.
‫Farklı bir düğümde
‫Aynı düğümde bulunuyorsa, onu yalnızca bu kapsayıcının bağlantı noktasına yönlendirecek.
‫Ve bunu sağlamak için herhangi bir şey yapmak zorunda kalmadık.
‫Hepsi kutudan çıktı.
‫Bunun nasıl işleyebileceğinin bir diyagramını görelim.
‫Eğer bir haber forumu hizmeti oluştursaydım ve ona üç kopyası olması gerektiğini söyledim. Ve üç düğüm üzerinde üç
‫konteynerle üç görev yarattı. Bu yer paylaşım ağının içinde, aslında
‫hizmetin DNS adına eşlenmiş sanal bir IP oluşturuyor değil mi? hizmeti, hizmetin adıdır.
‫Varsayılan olarak, DNS adı
‫Bu durumda, my-web adı verilen bir servis oluşturdum
‫ve
‫bindirmeli ağlarımdaki diğer konteynırlar, bu servisle konuşmak zorunda kaldım, yalnızca web DNS'mizi kullanmayı düşünmek zorunda kaldılar. Sanal IP düzgün yük, o hizmetteki tüm
‫görevler arasında trafiğe zıplamaktadır.
‫Bu aslında DNS Round Robin değil. Aslında biraz farklı bir konfigürasyon. Bunu istersek
‫de bunu sağlayabiliriz. Aslında DNS Round Robin'i kullanmak için bir seçenek var.
‫yükü düzgün şekilde dağıtmamızı engelleyen birçok zaman olmasıdır.
‫Round Robin'e kıyasla VIP'lerin faydaları, uygulamalarımızdaki DNS önbelleklerinin
‫DNS yapılandırmasında DNS istemcileriyle mücadele etmek yerine, sadece VIP'e güveniyoruz; özel bir donanım yük dengeleyicisi satın aldıysanız,
‫sahip olduğunuz gibi VIP'e güveniyoruz.
‫İkinci örnekte, bu, aslında gelen
‫harici trafikle nasıl olacağını gösteriyor.
‫Bu, sadece sarı kutuları oluşturduğumda, web olarak adlandırılan bir servis oluşturarak Drupal ile yaptığımız şeylere
‫benzer
‫ve iki görev oluşturup bunları iki farklı düğüme uyguladı; bu düğümlerin her biri yerleşik Harici IP adresinde yük dengeleyici. DigitalOcean'un bana verdiği IP adresi.
‫Benim için, DigitalOcean kullanıyorum, bu IP adresi -p'yi kullanıp bir bağlantı noktasında yayımladığımda, bu örnekte 80:80 bağlantı noktasını kullanıyor, bu üç düğümden
‫herhangi birine gelen herhangi bir trafik, bağlantı
‫noktası dengeleyicisini 80: 80 bağlantı noktasına vuruyor. Yük dengeleyici, hangisinin trafiği alması ve
‫bu trafiğin yerel düğümde olup olmadığına karar verir veya trafiği ağ
‫üzerinden farklı bir düğüme göndermeye ihtiyacı vardır.
‫Yine, aslında hepsi arka planda bizim için herhangi bir çaba sarf etmeden gerçekleşiyor.
‫Tamam. Bu Yönlendirme Meşesini harekete geçirelim.
‫Drupal örneğini gördük ve üç düğümde nasıl dinlediğini gördük.
‫Ancak, yük dengeleyicisinin çalıştığını gören birden fazla görevimiz olsaydı ne olurdu.
‫Bir rıhtım servisini yaratırsak,
‫ne yapacağımız Elasticsearch kapsayıcısını kullanacağız. Aramayı arayacağız ve ona
‫üç kopya verelim. Varsayılan bağlantı noktası olan 9200 numaralı bağlantı noktasına yayınlamak istiyorsunuz.
‫Bu durumda kesinlikle şunu istiyoruz: 2 orada, şu
‫anda dağıtmanın en kolay sürümüdür. Oluşturulmaya devam ederken, Elasticsearch'in aslında bir
‫JSON web API'si aracılığıyla erişilebilen bir arama veritabanı olduğunu
‫belirtmek isterim.
‫Dolayısıyla, bukle ile vurmak gerçekten kolay ve bunun bize nasıl çalıştığına dair güzel örnekler verin.
‫Bir rıhtım servis ps araması yapıyorum, her görevi farklı bir düğümde akıllıca yarattığını görebiliriz.
‫Yalnızca yerel ağ bağdaştırıcımda, bu bağlantı noktasını yayınladığım
‫için 9200 numaralı bağlantı noktasındaki düğüm noktasında bir kıvrım yaparsam, Elasticsearch temel bilgilerini geri alacağım. Bunun bir parçası aslında
‫rasgele bir isim yaratacaktır.
‫Elasticsearch sadece bir özelliktir.
‫görürsün
‫ve kendini böyle gibi tekrarlamaya başlar.
‫Bunu birden çok kez kıvırırsam, bu resimde Patch, Yama sunucusu ve sonra üçüncü kez Jane Foster
‫Aslında bir
‫yük dengeleyici olarak davranan ve yükümü üç görev arasında dağıtan sanal IP budur.
‫Yönlendirme kafesiyle ilgili birkaç not daha. 17'de. 03, size göstermek istediğim sürüm, yönlendirme kafesi ve yük dengeleme şu anda stateless
‫yük dengeleyici.
‫Şimdiye kadar Amazon'un klasik yük dengeleyici veya diğer
‫yük dengeleyici teknolojileri ile ilgili olarak uğraştıysanız, bunun ne hakkında olduğunu biliyorsunuzdur.
‫ile konuşmasını beklerse, o zaman bu sorunu çözmek için başka şeyler eklemeniz gerekebilir demektir.
‫Bu, temel olarak, uygulamanızda
‫oturum tanımlama bilgilerini kullanmak zorunda kalırsanız veya tutarlı bir kapsayıcının tutarlı bir istemci
‫Kutudan çıktığınızda, bir servise birden çok işle uğradığınızda, potansiyel olarak farklı bir
‫sonuç verecektir.
‫Ayrıca, ayrıntılara girerseniz aslında katman-3 yük dengeleyici ve aslında IP ve port
‫katında çalışıyor.
‫Aslında DNS katmanında çalışmaz.
‫web sitesi çalıştırdıysanız, bunu henüz yapmayacaksınız.
‫Aynı bağlantı noktasında, aynı sunucuda birden fazla
‫Aslında aynı bağlantı noktasında, aynı grupta birden fazla web sitesi çalıştırmak istiyor iseniz, bulmaca başka bir parçasına ihtiyacınız
‫olacak.
‫Neyse ki, bu oldukça yaygın bir taleptir
‫ve bu sorunların her ikisini de çözmek için yapabileceğiniz birkaç seçenek bulunmaktadır.
‫Bunlardan biri Nginx veya HAProxy kullanmaktır; burada yönlendirme kafesinin önünde oturacak ve aslında durum dengeli bir
‫yük dengeleyicisi veya
‫yük dengeleyici için bir katman görevi gören ve ayrıca önbelleğe alma işlemi gerçekleştirebilecek kaplar arasında oldukça iyi örnekler bulunmaktadır ve diğer birçok şey. kaynaklarından bazılarını kontrol etmek isteyebilirsiniz.
‫Buna ihtiyacınız varsa, bu bölümün
‫Ayrıca, Docker Enterprise sürümünün bir aboneliği için ödeme yapacaksanız, bir web
‫arayüzü olan UCP veya Docker Veri Merkezi denilen bir şey geldiğinde söz etmeliyim. Ancak, Docker Enterprise sürümünden bahsetmeliyiz, eğer
‫grubun düğümleri için üye olursanız, aslında web sunucusu için katmanlı
‫hizmetlerinizin web yapılandırmasında DNS adları atmanıza
‫izin veren dahili bir katmanla gelir ve her şey yolunda.
‫