Docker Swarm, Kubernetes ve Mesos en popüler konteyner düzenleme çerçeveleridir. Arun Gupta konuşmasında Docker, Swarm ve Kubernetes'in aşağıdaki yönlerini karşılaştırıyor:
- Yerel kalkınma.
- Dağıtım işlevleri.
- Çok konteynerli uygulamalar.
- Hizmet keşfi.
- Hizmeti ölçeklendirmek.
- Bir kez çalıştırılan görevler.
- Maven'le entegrasyon.
- "Yuvarlanan" güncelleme.
- Couchbase veritabanı kümesi oluşturma.
Sonuç olarak, her bir düzenleme aracının neler sunabileceğini net bir şekilde anlayacak ve bu platformları etkili bir şekilde nasıl kullanacağınızı öğreneceksiniz.
Arun Gupta, 10 yılı aşkın bir süredir Sun, Oracle, Red Hat ve Couchbase geliştirici topluluklarını geliştiren Amazon Web Services'te açık kaynaklı ürünlerden sorumlu baş teknoloji uzmanıdır. Pazarlama kampanyaları ve programları için strateji geliştiren ve uygulayan çapraz fonksiyonlu ekiplere liderlik etme konusunda geniş deneyime sahiptir. Sun mühendislerinden oluşan ekipleri yönetti, Java EE ekibinin kurucularından biri ve Devoxx4Kids'in ABD şubesinin yaratıcısıdır. Arun Gupta, BT bloglarında 2 binden fazla gönderinin yazarıdır ve 40'tan fazla ülkede konuşmalar yapmıştır.
55. satır, yine Kubernetes yapılandırma dosyası kullanılarak oluşturulan bu veritabanı hizmetine işaret eden bir COUCHBASE_URI içerir. 2. satıra bakarsanız, şunu görebilirsiniz: Hizmet, oluşturduğum couchbase-service adlı hizmettir ve aynı ad 4. satırda listelenmiştir. Aşağıda bazı bağlantı noktaları verilmiştir.
Anahtar satırlar 6 ve 7'dir. Serviste "Hey, bunlar aradığım etiketler!" diyorum ve bu etiketler değişken çift adlarından başka bir şey değil ve 7. satır benim couchbase-rs-pod'umu işaret ediyor başvuru. Aşağıda aynı etiketlere erişim sağlayan bağlantı noktaları verilmiştir.
19. satırda yeni bir ReplicaSet türü oluşturuyorum, 31. satır görüntünün adını içeriyor ve 24-27. satırlar bölmemle ilişkili meta verilere işaret ediyor. Hizmetin aradığı ve bağlantının yapılması gereken şey tam olarak budur. Dosyanın sonunda 55-56 ve 4. satırlar arasında "bu hizmeti kullan!" diyen bir tür bağlantı var.
Yani hizmetimi bir replika seti olduğunda başlatıyorum ve her replika setinin ilgili etikete sahip kendi portu olduğundan servise dahil oluyor. Bir geliştiricinin bakış açısından, hizmeti aramanız yeterlidir; hizmet daha sonra ihtiyacınız olan kopya setini kullanır.
Sonuç olarak, Couchbase Hizmeti aracılığıyla veritabanı arka ucuyla iletişim kuran bir WildFly kapsülüm var. Ön ucu, couchbase hizmeti aracılığıyla couchbase arka ucuyla da iletişim kuran birkaç WildFly bölmesiyle kullanabilirim.
Daha sonra, küme dışında bulunan bir hizmetin, kendi IP adresi aracılığıyla, kümenin içinde yer alan ve dahili bir IP adresine sahip olan öğelerle nasıl iletişim kurduğuna bakacağız.
Yani durum bilgisi olmayan kaplar harikadır, ancak durum bilgisi olan kapları kullanmak ne kadar iyidir? Durum bilgisi olan veya kalıcı kapsayıcılar için sistem ayarlarına bakalım. Docker'da veri depolama düzeni konusunda dikkat etmeniz gereken 4 farklı yaklaşım bulunmaktadır. Bunlardan ilki, Kapsayıcı Başına Örtülüdür; bu, couchbase, MySQL veya MyDB satateful kapsayıcılarını kullanırken hepsinin varsayılan Sandbox ile başladığı anlamına gelir. Yani veritabanında saklanan her şey kabın kendisinde saklanır. Kapsayıcı kaybolursa veriler de onunla birlikte kaybolur.
İkincisi, docker birimi oluşturma komutuyla belirli bir depolama alanı oluşturduğunuzda ve verileri burada depoladığınızda, Konteyner Başına Açık'tır. Üçüncü Ana Bilgisayar Başına yaklaşım, kapta depolanan her şeyin aynı anda ana bilgisayarda kopyalandığı depolama eşlemeyle ilişkilidir. Konteyner arızalanırsa veriler ana bilgisayarda kalacaktır. İkincisi, çeşitli çözümlerin üretim aşamasında tavsiye edilen birkaç Çoklu Ana Bilgisayar ana bilgisayarının kullanılmasıdır. Diyelim ki uygulamalarınızın bulunduğu konteynerleriniz ana bilgisayarda çalışıyor, ancak verilerinizi internette bir yerde depolamak istiyorsunuz ve bunun için dağıtılmış sistemler için otomatik eşlemeyi kullanıyorsunuz.
Bu yöntemlerin her biri belirli bir depolama konumu kullanır. Kapsayıcı Başına Örtülü ve Açık, verileri ana makinede /var/lib/docker/volumes konumunda depolar. Ana Bilgisayar Başına yöntemini kullanırken, depolama konteynerin içine monte edilir ve konteynerin kendisi de ana bilgisayara monte edilir. Çoklu hostlar için Ceph, ClusterFS, NFS vb. çözümler kullanılabilir.
Kalıcı bir kapsayıcı arızalanırsa, ilk iki durumda depolama dizinine erişilemez hale gelir, ancak son iki durumda erişim korunur. Ancak ilk durumda, depoya sanal makine üzerinde çalışan bir Docker ana bilgisayarı aracılığıyla erişebilirsiniz. İkinci durumda, Açık depolama alanı oluşturduğunuz için veriler de kaybolmayacaktır.
Ana bilgisayar arızalanırsa, ilk üç durumda depolama dizini kullanılamaz; son durumda, depolama ile bağlantı kesilmez. Son olarak, paylaşılan işlev ilk durumda depolama için tamamen hariç tutulur ve geri kalanında mümkündür. İkinci durumda veritabanınızın dağıtılmış depolamayı destekleyip desteklememesine bağlı olarak depolamayı paylaşabilirsiniz. Ana Bilgisayar Başına durumunda, veri dağıtımı yalnızca belirli bir ana bilgisayarda mümkündür ve çoklu ana bilgisayar için bu, küme genişletmeyle sağlanır.
Durum bilgisi olan kaplar oluştururken bu dikkate alınmalıdır. Bir diğer kullanışlı Docker aracı ise “piller mevcut ancak değiştirilmesi gerekiyor” prensibiyle çalışan Volume eklentisidir. Bir Docker kapsayıcısını başlattığınızda, "Hey, veritabanıyla bir kapsayıcı başlattığınızda verilerinizi bu kapsayıcıda saklayabilirsiniz!" Bu varsayılan özelliktir, ancak değiştirebilirsiniz. Bu eklenti, konteyner veritabanı yerine bir ağ sürücüsü veya benzeri bir şey kullanmanıza olanak tanır. Ana bilgisayar tabanlı depolama için varsayılan bir sürücü içerir ve Amazon EBS, Azure Storage ve GCE Persistent diskleri gibi harici depolama sistemleriyle konteyner entegrasyonuna olanak tanır.
Bir sonraki slayt Docker Volume eklentisinin mimarisini göstermektedir.
Mavi renk, size veri depolamak için kapsayıcılar sağlayan bir Yerel depolama motoruna sahip olan mavi Docker ana bilgisayarıyla ilişkili Docker istemcisini temsil eder. Yeşil, aynı zamanda ana bilgisayara bağlı olan Plugin Client ve Plugin Daemon'u belirtir. Verileri ihtiyacınız olan Depolama Arka Uç tipinin ağ depolama alanında depolama olanağı sağlarlar.
Docker Volume eklentisi Portworx depolama ile kullanılabilir. PX-Dev modülü aslında çalıştırdığınız, Docker ana makinenize bağlanan ve verileri Amazon EBS'de kolayca depolamanıza olanak tanıyan bir konteynerdir.
Portworx istemcisi, ana makinenize bağlı çeşitli depolama kaplarının durumunu izlemenize olanak tanır. Blogumu ziyaret ederseniz Docker ile Portworx'tan en iyi şekilde nasıl yararlanabileceğinizi okuyabilirsiniz.
Kubernetes'teki depolama kavramı Docker'a benzer ve bir bölmedeki kapsayıcınızın erişebildiği dizinlerle temsil edilir. Herhangi bir konteynerin ömründen bağımsızdırlar. Mevcut en yaygın depolama türleri hostPath, nfs, awsElasticBlockStore ve gsePersistentDisk'tir. Bu mağazaların Kubernetes'te nasıl çalıştığına bir göz atalım. Tipik olarak, bunları bağlama işlemi 3 adımdan oluşur.
Birincisi, ağ tarafındaki birinin, genellikle yöneticinin, size kalıcı depolama sağlamasıdır. Buna karşılık gelen bir PersistentVolume yapılandırma dosyası vardır. Daha sonra, uygulama geliştiricisi PersistentVolumeClaim adlı bir yapılandırma dosyası veya bir PVC depolama isteği yazar ve şunu yazar: "50 GB dağıtılmış depolama alanım var, ancak diğer kişilerin de bu kapasiteyi kullanabilmesi için bu PVC'ye şu anda sahip olduğumu söylüyorum yalnızca 10 GB'a ihtiyacınız var". Son olarak üçüncü adım, isteğinizin depolama olarak bağlanması ve pod, replika seti veya benzeri bir şeyin bulunduğu uygulamanın onu kullanmaya başlamasıdır. Bu sürecin bahsedilen 3 adımdan oluştuğunu ve ölçeklenebilir olduğunu unutmamak gerekiyor.
Sonraki slaytta AWS mimarisinin Kubernetes Persistence Container'ı gösterilmektedir.
Kubernetes kümesini temsil eden kahverengi dikdörtgenin içinde sarı renkle gösterilen bir ana düğüm ve iki çalışan düğüm bulunur. Çalışan düğümlerden biri turuncu bir bölme, depolama, bir kopya denetleyici ve yeşil bir Docker Couchbase kapsayıcısı içerir. Kümenin içinde, düğümlerin üzerinde bulunan mor bir dikdörtgen, Hizmetin dışarıdan erişilebildiğini gösterir. Bu mimari, verileri cihazın kendisinde depolamak için önerilir. Gerekirse bir sonraki slaytta gösterildiği gibi verilerimi Cluster dışında EBS'de saklayabilirim. Bu tipik bir ölçeklendirme modelidir, ancak bunu kullanırken göz önünde bulundurulması gereken mali bir husus vardır; verileri ağ üzerinde bir yerde depolamak, bir ana bilgisayara kıyasla daha pahalı olabilir. Konteynerizasyon çözümlerini seçerken bu en önemli argümanlardan biridir.
Docker'da olduğu gibi Portworx'ta da kalıcı Kubernetes konteynerlerini kullanabilirsiniz.
Bu, mevcut Kubernetes 1.6 terminolojisinde "StatefulSet" olarak adlandırılan şeydir; Pod'un durdurulması ve Kademeli Kapatma işleminin gerçekleştirilmesi ile ilgili olayları işleyen Durum bilgisi olan uygulamalarla çalışmanın bir yoludur. Bizim durumumuzda bu tür uygulamalar veritabanlarıdır. Blogumda Portworx kullanarak Kubernetes'te StatefulSet'in nasıl oluşturulacağını okuyabilirsiniz.
Gelelim işin gelişim yönüne. Dediğim gibi Docker'ın 2 sürümü var - CE ve EE, ilk durumda EE'nin aylık olarak güncellenen sürümünün aksine, Topluluk Sürümü'nün her 3 ayda bir güncellenen kararlı bir sürümünden bahsediyoruz. Docker'ı Mac, Linux veya Windows için indirebilirsiniz. Docker kurulduktan sonra otomatik olarak güncellenecektir ve başlamak çok kolaydır.
Kubernetes için Minikube sürümünü tercih ediyorum; bu, tek bir düğümde küme oluşturarak platforma başlamanın iyi bir yoludur. Birkaç düğümden oluşan kümeler oluşturmak için sürüm seçimi daha geniştir: bunlar kops, kube-aws (CoreOS+AWS), kube-up (modası geçmiş). AWS tabanlı Kubernetes'i kullanmak istiyorsanız her Cuma çevrimiçi olarak toplanan ve AWS Kubernetes ile çalışmaya ilişkin çeşitli ilgi çekici materyaller yayınlayan AWS SIG'ye katılmanızı öneririm.
Bu platformlarda Rolling Update'in nasıl yapıldığına bakalım. Birkaç düğümden oluşan bir küme varsa görüntünün belirli bir sürümünü kullanır; örneğin WildFly:1. Sürekli güncelleme, görüntü sürümünün her düğümde birbiri ardına yenisiyle değiştirildiği anlamına gelir.
Bunun için WildFly:2 imajının yeni versiyonunu ve update-parallelism 2 güncelleme metodunu belirttiğim docker service update (service name) komutunu kullanıyorum. 2 rakamı sistemin 2 uygulama imajını güncelleyeceği anlamına geliyor aynı zamanda, 10 saniyelik bir güncelleme gecikmesi 10 saniye, ardından sonraki 2 görüntü 2 düğümde daha güncellenecektir, vb. Bu basit sürekli güncelleme mekanizması size Docker'ın bir parçası olarak sunulmaktadır.
Kubernetes'te sürekli güncelleme şu şekilde çalışır. Çoğaltma denetleyicisi rc, aynı sürümün bir dizi kopyasını oluşturur ve bu webapp-rc'deki her bölme, etcd'de bulunan bir etiketle sağlanır. Bir bölmeye ihtiyacım olduğunda, bana belirtilen etiketi kullanarak bölmeyi sağlayan etcd deposuna erişmek için Uygulama Hizmetini kullanırım.
Bu durumda WildFly version 3 uygulamasını çalıştıran Replication Controller'da 1 pod'umuz var.Arka planda güncelleme yaparken - - xxxxx sonunda aynı isimde ve indekste başka bir replikasyon denetleyicisi oluşturulur, burada x rastgele sayılardır ve aynı etiketlerle. Artık Uygulama Hizmeti, yeni Çoğaltma denetleyicisinde uygulamanın eski sürümünün bulunduğu üç bölmeye ve yeni sürümün bulunduğu üç bölmeye sahiptir. Bundan sonra eski bölmeler silinir, yeni bölmelere sahip çoğaltma denetleyicisi yeniden adlandırılarak devreye alınır.
İzlemeye geçelim. Docker'ın birçok yerleşik izleme komutu vardır. Örneğin, liman işçisi konteyner istatistikleri komut satırı arayüzü, konteynerlerin durumu hakkındaki bilgileri her saniye konsolda görüntülemenize olanak tanır - işlemci kullanımı, disk kullanımı, ağ yükü. Docker Remote API aracı, istemcinin sunucuyla nasıl iletişim kurduğuna ilişkin veriler sağlar. Basit komutlar kullanır ancak Docker REST API'sini temel alır. Bu durumda REST, Flash, Remote kelimeleri aynı anlama gelmektedir. Ana makineyle iletişim kurduğunuzda bu bir REST API'sidir. Docker Remote API, konteynerlerin çalıştırılması hakkında daha fazla bilgi almanızı sağlar. Blogum bu izlemeyi Windows Server ile kullanmanın ayrıntılarını özetlemektedir.
Çok ana bilgisayarlı bir kümeyi çalıştırırken liman işçisi sistemi olaylarını izlemek, belirli bir ana bilgisayardaki ana bilgisayar çökmesi veya konteyner çökmesi, hizmetleri ölçeklendirme ve benzeri hakkında veri elde etmeyi mümkün kılar. Docker 1.20'den başlayarak, uç noktaları mevcut uygulamalara yerleştiren Prometheus'u içerir. Bu, metrikleri HTTP aracılığıyla almanıza ve bunları kontrol panellerinde görüntülemenize olanak tanır.
Başka bir izleme özelliği cAdvisor'dur (konteyner danışmanının kısaltması). Çalışan konteynerlerden kaynak kullanımı ve performans verilerini analiz edip sağlar ve Prometheus ölçümlerini kutudan çıktığı anda sağlar. Bu aracın özelliği yalnızca son 60 saniyeye ait verileri sağlamasıdır. Dolayısıyla uzun vadeli bir süreci izleyebilmeniz için bu verileri toplayıp bir veri tabanına koyabilmeniz gerekiyor. Ayrıca Grafana veya Kibana kullanılarak gösterge tablosu ölçümlerini grafiksel olarak görüntülemek için de kullanılabilir. Blogumda, Kibana kontrol panelini kullanarak kapsayıcıları izlemek için cAdvisor'ın nasıl kullanılacağına ilişkin ayrıntılı bir açıklama bulunmaktadır.
Sonraki slaytta Prometheus uç nokta çıktısının neye benzediği ve görüntülenebilecek ölçümler gösterilmektedir.
Sol altta HTTP istekleri, yanıtları vb. için ölçümleri görüyorsunuz, sağda ise bunların grafiksel gösterimi var.
Kubernetes ayrıca yerleşik izleme araçlarını da içerir. Bu slaytta bir ana ve üç çalışan düğüm içeren tipik bir küme gösterilmektedir.
Çalışan düğümlerin her biri otomatik olarak başlatılan bir cAdvisor içerir. Ayrıca Kubernetes sürüm 1.0.6 ve üzeri ile uyumlu bir performans izleme ve ölçüm toplama sistemi olan Heapster da bulunmaktadır. Heapster yalnızca iş yüklerinin, bölmelerin ve kapsayıcıların performans ölçümlerini değil, aynı zamanda kümenin tamamı tarafından oluşturulan olayları ve diğer sinyalleri de toplamanıza olanak tanır. Veri toplamak için her bir bölmenin Kubelet'iyle konuşur, bilgileri InfluxDB veritabanında otomatik olarak saklar ve bunu Grafana kontrol paneline metrik olarak gönderir. Ancak miniKube kullanıyorsanız bu özelliğin varsayılan olarak mevcut olmadığını, dolayısıyla izleme için eklentileri kullanmanız gerekeceğini unutmayın. Dolayısıyla her şey, konteynerleri nerede çalıştırdığınıza, varsayılan olarak hangi izleme araçlarını kullanabileceğinize ve hangilerini ayrı eklentiler olarak yüklemeniz gerektiğine bağlıdır.
Sonraki slaytta konteynerlerimin çalışma durumunu gösteren Grafana kontrol panelleri gösteriliyor. Burada oldukça ilginç veriler var. Elbette SysDig, DataDog, NewRelic gibi birçok ticari Docker ve Kubernetes süreç izleme aracı mevcut. Bazılarının 30 yıllık ücretsiz deneme süresi vardır, böylece kendinize en uygun olanı deneyebilir ve bulabilirsiniz. Şahsen ben Kubernetes ile iyi entegre olan SysDig ve NewRelic'i kullanmayı tercih ediyorum. Hem Docker hem de Kubernetes platformlarına eşit derecede iyi entegre olan araçlar var.
Bazı reklamlar 🙂
Bizimle kaldığın için teşekkürler. Yazılarımızı beğeniyor musunuz? Daha ilginç içerik görmek ister misiniz? Sipariş vererek veya arkadaşlarınıza tavsiye ederek bize destek olun, , sizin için bizim tarafımızdan icat edilen benzersiz bir giriş seviyesi sunucu analoğu: (RAID1 ve RAID10, 24 adede kadar çekirdek ve 40 GB'a kadar DDR4 ile mevcuttur).
Amsterdam'daki Equinix Tier IV veri merkezinde Dell R730xd 2 kat daha mı ucuz? Sadece burada Hollanda'da! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99$'dan! Hakkında oku
Kaynak: habr.com