Yazılım Dağıtımını Hızlandırma - Bir Docker Swarm Eğitimi

Bir nakliye konteynırının içinde yaşamıyorsanız, muhtemelen konteynırları duymuşsunuzdur. Endüstri, kalıcı altyapıdan geçici altyapıya belirgin bir geçiş yapıyor ve konteynerler bu hareketin tam ortasında duruyor. Nedeni oldukça basit: Kapsayıcılar kesinlikle geliştirme ekiplerinin hızlı bir şekilde çalışmaya başlamasına yardımcı olurken, operasyonların yüzünü tamamen değiştirme potansiyeli daha da fazla.

Ama bu tam olarak neye benziyor? Kapsayıcıları yerel olarak veya birkaç sunucuda manuel olarak çalıştırmaya başlamaya hazır olduğunuzda ne olur? İdeal bir dünyada, uygulamanızı bir sunucu kümesine atmak ve "çalıştırın!" demek istersiniz.

Neyse ki bugün bu durumdayız.

Bu yazıda, Docker Swarm'ın ne olduğunu ve sunduğu harika özelliklerden bazılarını keşfedeceğiz. Ardından, Swarm modunu kullanmanın ve bir sürüye konuşlandırmanın gerçekte neye benzediğine bir göz atacağız ve konuşlandırılmış bir sürü ile günlük operasyonların nasıl olduğuna dair bazı örneklerle bitireceğiz. Temel Docker ve kapsayıcı bilgisi kesinlikle önerilir, ancak kapsayıcılarda yeniyseniz, önce bu mükemmel blog gönderisine göz atabilirsiniz.

Docker Sürüsü Nedir?

İlk grubumuzu oluşturmaya ve dağıtmaya başlamadan önce, Docker Swarm'ın ne olduğu hakkında bir fikre sahip olmak faydalı olacaktır. Docker'ın kendisi yıllardır var ve bugün çoğu insan bunu bir konteyner çalışma zamanı olarak düşünüyor. Gerçekte, Docker, hepsi birlikte çalışan birçok farklı parçadan oluşur. Örneğin, bu kapsayıcı çalışma zamanı kısmı, runC ve kapsayıcı adı verilen daha küçük iki bileşen tarafından işlenir. Docker geliştikçe ve topluluğa geri döndükçe, bu daha küçük bileşenleri oluşturmanın büyümenin ve hızla özellik eklemenin en iyi yolu olduğunu keşfettiler. Bu nedenle, artık doğrudan Docker'da yerleşik olarak bulunan SwarmKit ve Swarm moduna sahibiz.

Docker Swarm bir konteyner düzenleme motorudur. Yüksek düzeyde, farklı ana bilgisayarlarda çalışan birden fazla Docker Motoru alır ve bunları birlikte kullanmanıza olanak tanır. Kullanımı basittir: uygulamalarınızı hizmet yığınları olarak ilan edin ve gerisini Docker'ın halletmesine izin verin. Hizmetler, uygulama örneklerinden veritabanlarına veya Redis veya RabbitMQ gibi yardımcı programlara kadar her şey olabilir. Geliştirme aşamasında docker-compose ile çalıştıysanız, tamamen aynı konsept olduğu için bu size tanıdık gelmelidir. Aslında, bir yığın bildirimi, kelimenin tam anlamıyla, sürüm 3.1 sözdizimine sahip bir docker-compose.yml dosyasıdır. Bu, geliştirme ve sürü dağıtımı için benzer (ve çoğu durumda aynı) bir oluşturma yapılandırması kullanabileceğiniz anlamına gelir, ancak burada kendimi biraz geçiyorum. Swarm modunda Docker örnekleriniz olduğunda ne olur?

Rafttan Düşmeyin

Swarm dünyasında iki tür düğümümüz (sunucumuz) vardır: yöneticiler ve çalışanlar. Yöneticilerin de birer işçi olduğunu akılda tutmak önemlidir, sadece işleri devam ettirmekle ilgili ek sorumlulukları vardır. Her sürü, lider olarak belirlenen bir yönetici düğümü ile başlar. Oradan, sürüye güvenli bir şekilde düğüm eklemek için tek bir komut çalıştırma meselesi.

Swarm, Raft algoritmasının uygulanması sayesinde yüksek oranda erişilebilirdir. Raft hakkında çok fazla ayrıntıya girmeyeceğim çünkü nasıl çalıştığına dair harika bir öğretici zaten var, ancak genel fikir şu: Lider düğüm sürekli olarak diğer yönetici düğümlerini kontrol ediyor ve durumlarını senkronize ediyor. Bir durum değişikliğinin "kabul edilmesi" için, yönetici düğümleri fikir birliğine varır; bu, düğümlerin çoğunluğu durum değişikliğini kabul ettiğinde gerçekleşir.

Bunun güzelliği, yönetici düğümlerinin, sürünün fikir birliğinden ödün vermeden ara sıra düşebilmesidir. Bir durum değişikliği fikir birliğine varırsa, bunun yönetici düğümlerinin çoğunda var olmasının garanti edildiğini ve mevcut lider başarısız olsa bile devam edeceğini biliyoruz.

Diyelim ki A, B ve C adında üç yönetici düğümümüz var. Elbette A, korkusuz liderimiz. Bir gün geçici bir ağ hatası A'yı çevrimdışı duruma getirerek B ve C'yi yalnız bırakır. A'dan uzun süredir (birkaç yüz milisaniye) haber alamamış olan B ve C, seçime girmeden ve diğerine haber vermeden önce rastgele oluşturulmuş bir süre beklerler. Elbette seçime ilk giden bu durumda seçilecektir. Bu örnekte, B yeni lider olur ve bir yetersayı geri yüklenir. Ama sonra, olay örgüsü: A tekrar çevrimiçi olduğunda ne olur? Hala lider olduğunu düşünecek, değil mi? Her seçimin kendisiyle ilişkili bir terimi vardır, bu nedenle A aslında 1. dönemde seçildi. A tekrar çevrimiçi olup B ve C'yi sipariş etmeye başlar başlamaz, B'nin 2. dönemin lideri olduğunu bilmesini sağlarlar ve A inecek.

Aynı süreç elbette çok daha büyük bir ölçekte çalışır. Üçten fazla yönetici düğümünüz olabilir. Yine de bir kısa not daha ekleyeceğim. Her Swarm sadece belirli sayıda yönetici kaybı alabilir. Bir n yönetici düğümü sürüsü, yetersayı kaybetmeden (n-1)/2 yönetici kaybedebilir. Bu, üç yönetici sürüsü için bir, beş için iki kaybedebileceğiniz anlamına gelir, vb. Bunun altında yatan neden, çoğunluk fikir birliği fikrine geri döner ve üretime geçerken kesinlikle akılda tutulması gereken bir şeydir.

Görev Planlama ve Mutabakat

Şimdiye kadar, yöneticilerimizin senkronize olma konusunda gerçekten iyi olduklarını belirledik. Harika! Ama gerçekte ne yapıyorlar? Swarm'a bir yığın hizmet dağıttığınızı söylediğimi hatırlıyor musunuz? Hizmetlerinizi beyan ettiğinizde, Swarm'a hizmetlerinizin gerçekte nasıl yürütülmesini istediğiniz hakkında önemli bilgiler sağlarsınız. Bu, her hizmetten kaç kopya istediğiniz, kopyaların nasıl dağıtılacağı, yalnızca belirli düğümlerde çalıştırılıp çalıştırılmayacağı ve daha fazlası gibi parametreleri içerir.

Bir hizmet dağıtıldıktan sonra, belirlediğiniz tüm dağıtım gereksinimlerinin karşılanmaya devam etmesini sağlamak yöneticilerin işidir. Bir Nginx hizmeti dağıttığınızı ve üç kopya olması gerektiğini belirttiğinizi varsayalım. Yöneticiler hiçbir kapsayıcının çalışmadığını görecek ve üç kapsayıcıyı mevcut düğümler arasında eşit olarak dağıtacaktır.

Daha da havalı olan şey, bir kapsayıcının başarısız olması durumunda (veya tüm bir düğümün çevrimdışı olması durumunda), Swarm'ın farkı telafi etmek için kalan düğümlerde otomatik olarak kapsayıcıları oluşturmasıdır. Üç kapsayıcının çalışmasını istediğinizi söylerseniz, çalışan üç kapsayıcınız olur, Swarm ise tüm önemli ayrıntıları ele alır. Artı - ve bu büyük bir artı - ölçeği büyütmek veya küçültmek, Swarm'a yeni bir çoğaltma ayarı vermek kadar kolaydır.

Servis Keşfi ve Yük Dengeleme

Bu son örnekten önemli ama incelikli bir ayrıntıya dikkat çekmek istiyorum: Swarm akıllıca kendi seçtiği düğümlerde kapsayıcıları başlatıyorsa, bu kapsayıcıların nerede çalışacağını mutlaka bilemeyiz. Bu ilk başta korkutucu gelebilir, ancak aslında Swarm'ın en güçlü özelliklerinden biridir.

Aynı Nginx örneğine devam edersek, Docker'a bu kapsayıcıların 80 numaralı bağlantı noktasını göstermesi gerektiğini söylediğimizi hayal edin. Tarayıcınızı bu kapsayıcıyı 80 numaralı bağlantı noktasında çalıştıran bir düğüme yönlendirirseniz, o kapsayıcının içeriğini görürsünüz. Orada bir sürpriz yok. Şaşırtıcı olan şu ki, isteğinizi o kapsayıcıyı çalıştırmayan bir düğüme gönderirseniz, yine aynı içeriği göreceksiniz! Burada neler oluyor?

Swarm aslında isteğinizi o kapsayıcıyı çalıştıran uygun bir düğüme göndermek için bir giriş ağı kullanıyor ve aynı zamanda onu yük dengeliyor. Dolayısıyla, aynı düğüme üç istekte bulunursanız, büyük olasılıkla üç farklı kapsayıcıya ulaşacaksınız. Sürüdeki tek bir düğümün IP'sini bildiğiniz sürece, içinde çalışan her şeye erişebilirsiniz. Tersine, bu, neyin nerede çalıştığı konusunda endişelenmenize gerek kalmadan sürüdeki tüm düğümlere bir yük dengeleyici (ELB gibi) yöneltmenizi sağlar.

Dış bağlantılarda durmaz. Aynı yığın üzerinde çalışan hizmetler, birbirleriyle iletişim kurmalarını sağlayan bir yer paylaşımı ağına sahiptir. Kodunuzdaki IP adreslerini sabit kodlamak yerine, bağlanmak istediğiniz ana bilgisayar adı olarak hizmetin adını kullanabilirsiniz. Örneğin, uygulamanızın "redis" adlı bir Redis hizmetiyle iletişim kurması gerekiyorsa, ana bilgisayar adı olarak "redis"i kullanabilir ve Swarm, isteğini uygun kapsayıcıya yönlendirecektir. Ve bu, geliştirme aşamasında docker-compose ile ve üretimde Docker Swarm ile sorunsuz bir şekilde çalıştığından, uygulamanızı dağıtırken endişelenmeniz gereken bir şey daha azdır.

Sürekli Güncellemeler

Operasyondaysanız, bir üretim güncellemesi korkunç bir şekilde yanlış gittiğinde muhtemelen panik atak yaşadınız. Hatalı bir kod güncellemesi veya hatta yalnızca bir yapılandırma hatası olabilir, ancak aniden üretim durdu! Büyük ihtimalle patron her iki şekilde de ilgilenmeyecek. Sadece senin hatan olduğunu anlayacaklar. Endişelenme, Swarm bunda da senin arkanda.

Bir hizmeti güncellerken, bir seferde kaç kapsayıcının güncellenmesi gerektiğini ve yeni kapsayıcıların arızalanmaya başlaması durumunda ne olacağını tanımlayabilirsiniz. Belirli bir eşikten sonra Swarm, güncellemeyi durdurabilir veya (Docker 17.04'ten itibaren) kapsayıcıları önceki görüntü ve ayarlara geri alabilir. Yarın sabah patronunuza bir kahve getirmek zorunda kalma konusunda endişelenmeyin.

Güvenlik

Son olarak, Docker Swarm kutudan çıktığı gibi harika güvenlik özellikleriyle birlikte gelir. Bir düğüm sürüye katıldığında, yalnızca kendini doğrulamakla kalmayıp aynı zamanda olduğunu düşündüğünüz sürüye katıldığını da doğrulayan bir belirteç kullanır. O andan itibaren, düğümler arasındaki tüm iletişim karşılıklı TLS şifrelemesi kullanılarak gerçekleşir. Bu şifrelemenin tamamı Swarm tarafından otomatik olarak sağlanır ve yönetilir, bu nedenle sertifikaları yenileme ve diğer tipik güvenlik sorunları konusunda asla endişelenmenize gerek kalmaz. Ve elbette, bir anahtar döndürmeyi zorlamak istiyorsanız, bunun için bir komut var.

Docker Swarm'ın en son sürümü ayrıca yerleşik sır yönetimi ile birlikte gelir. Bu, anahtarlar ve parolalar gibi sırları, bunlara ihtiyaç duyan hizmetlere ve yalnızca bunlara ihtiyaç duyan hizmetlere güvenli bir şekilde dağıtmanıza olanak tanır. Gizli anahtarı olan bir hizmet sağladığınızda, bu hizmetin kapsayıcıları, dosya sistemlerine gizli anahtarın değerini içeren özel bir dosya monte eder. Söylemeye gerek yok ama bu, geleneksel yaklaşım olan ortam değişkenlerini kullanmaktan çok daha güvenli.

Sürüye Dalmak

Benim gibiyseniz, atlamak ve tüm bu özellikleri bir tur atmak için can atıyorsunuz! O halde lafı daha fazla uzatmadan konuya girelim!

Docker Swarm Örnek Uygulaması

Docker Swarm'ı kullanmanın gücünü ve kolaylığını göstermek için çok ilkel bir Flask uygulaması oluşturdum. Web uygulaması, yalnızca isteğinize hangi kapsayıcının hizmet ettiğini, toplam kaç isteğin sunulduğunu ve "gizli" veritabanı parolasının ne olduğunu söyleyen bir sayfa görüntüler.

Üç hizmete bölünmüştür: gerçek Flask uygulaması, bir Nginx ters proxy ve bir Redis anahtar deposu. Her istekte, uygulama num_requests anahtarını artırır, böylece hangi Flask örneğine ulaştığınızdan bağımsız olarak, doğru sayıda isteğin yansıtıldığını görürsünüz.

Neler olup bittiğini "kontrol etmek" istiyorsanız, tüm kaynak kodu GitHub'da mevcuttur.

Docker ile oynayın!

Bu öğreticiyi incelerken kendi sunucularınızı kullanmaktan çekinmeyin, ancak sadece atlamak istiyorsanız play-with-docker.com'u kullanmanızı şiddetle tavsiye ederim. Bu, birkaç Docker geliştiricisi tarafından işletilen ve birkaç ağa bağlı olan bir siteyi döndürmenize izin veren bir sitedir. Docker'ın önceden yüklenmiş olduğu düğümler. Dört saat sonra kapatılacaklar, ancak bu örnek için bu kadarı yeter!

Bir Sürü Yaratmak

Pekala, başlıyoruz! Devam edin ve PWD'de (docker ile oyna) üç örnek oluşturun veya en sevdiğiniz VPS (sanal özel sunucu) hizmetinde üç sunucuyu döndürün ve hepsine Docker motorunu yükleyin. Her zaman bir görüntü oluşturabileceğinizi ve gelecekte düğüm eklerken bunu yeniden kullanabileceğinizi unutmayın. Bir yönetici düğümü ve bir çalışan düğümü arasında yazılım açısından hiçbir fark yoktur, bu nedenle iki farklı görüntüyü korumanız gerekmez.

Hala dönüyor mu? Merak etme, bekleyeceğim. Tamam, şimdi ilk yönetici ve lider düğümümüzü oluşturacağız. İlk örneğinizde bir sürü başlatın:

 docker swarm init --advertise-addr <node ip here>

<node_ip_here> düğümünüzün IP adresiyle değiştirin. PWD'de IP adresi en üstte görüntülenir ve kendi VPS'nizi kullanıyorsanız, ağınızdaki diğer düğümlerden erişilebilir olduğu sürece sunucunuzun özel IP adresini kullanmaktan çekinmeyin.

Artık bir sürünüz var! Yine de oldukça sıkıcı bir sürü, çünkü yalnızca bir düğümü var. Devam edelim ve diğer düğümleri ekleyelim. init çalıştırdığınızda, birleştirme belirtecinin nasıl kullanılacağını açıklayan uzun bir mesaj görüntülendiğini fark edeceksiniz. Bunu kullanmayacağız çünkü diğer düğümleri işçi yapacak ve onların yönetici olmalarını istiyoruz. Bunu ilk düğümde çalıştırarak bir yönetici için birleştirme belirtecini alalım:

 docker swarm join-token manager

Ortaya çıkan komutu kopyalayın ve ikinci ve üçüncü düğümlerinizde çalıştırın. İşte, üç düğümlü bir sürü! Tüm düğümlerimizin gerçekten var olduğunu doğrulayalım. docker node ls komutu, grubumuzdaki tüm düğümleri listeleyecektir. Bunun gibi bir şey görmelisiniz:

 $ docker node ls ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS su1bgh1uxqsikf1129tjhg5r8 * node1 Ready Active Leader t1tgnq38wb0cehsry2pdku10h node3 Ready Active Reachable wxie5wf65akdug7sfr9uuleui node2 Ready Active Reachable

İlk düğümümüzün kimliğin yanında nasıl bir yıldız işareti olduğuna dikkat edin. Bu bize şu anda bağlı olduğumuz düğümün bu olduğunu söylüyor. Ayrıca bu düğümün şu anda Lider olduğunu ve kendisine bir şey olursa diğer düğümlerin Ulaşılabilir olduğunu görebiliriz.

Bunun ne kadar kolay olduğunu anlamak için bir dakikanızı ayırın ve ilk uygulamamızı dağıtalım!

Onu yükle!

Bu sırada, iş geliştirme ekibi bir müşteriye yeni uygulamalarının bir saat içinde dağıtılacağına ve hazır olacağına söz verdi! Tipik, biliyorum. Ama korkmayın, Docker kullanılarak oluşturulduğu için neredeyse o kadar zamana ihtiyacımız olmayacak! Geliştiriciler bize docker-compose dosyalarını ödünç verme nezaketini gösterdiler:

 version: '3.1' services: web: image: lsapan/docker-swarm-demo-web command: gunicorn --bind 0.0.0.0:5000 wsgi:app deploy: replicas: 2 secrets: - db_password nginx: image: lsapan/docker-swarm-demo-nginx ports: - 8000:80 deploy: mode: global redis: image: redis deploy: replicas: 1 secrets: db_password: external: true

Birazdan kıracağız, ama bunun için henüz zaman yok. Hadi konuşlandıralım! Devam edin ve ilk düğümünüzde docker-compose.yml adlı bir dosya oluşturun ve onu yukarıdaki yapılandırmayla doldurun. Bunu echo "<pasted contents here>" > docker-compose.yml ile kolayca yapabilirsiniz.

Normalde bunu konuşlandırabiliriz, ancak konfigürasyonumuz db_password adında bir sır kullandığımızdan bahseder, o yüzden hemen bu sırrı oluşturalım:

 echo "supersecretpassword" | docker secret create db_password -

Harika! Şimdi tek yapmamız gereken Docker'a yapılandırmamızı kullanmasını söylemek:

 docker stack deploy -c docker-compose.yml demo

Bu komutu çalıştırdığınızda, Docker'ın tanımladığımız üç hizmeti oluşturduğunu göreceksiniz: web , nginx ve redis . Ancak, yığın demomuzu adlandırdığımız için hizmetlerimiz aslında demo_web , demo_nginx ve demo_redis olarak adlandırılır. Şuna benzer bir şey göstermesi gereken docker service ls komutunu çalıştırarak çalışan hizmetlerimize bakabiliriz:

 $ docker service ls ID NAME MODE REPLICAS IMAGE PORTS cih6u1t88vx7 demo_web replicated 2/2 lsapan/docker-swarm-demo-web:latest u0p1gd6tykvu demo_nginx global 3/3 lsapan/docker-swarm-demo-nginx:latest *:8000->80/ tcp wa1gz80ker2g demo_redis replicated 1/1 redis:latest

işte! Docker, görüntülerimizi uygun düğümlere indirdi ve hizmetlerimiz için kapsayıcılar oluşturdu. Replikalarınız henüz tam kapasitede değilse, biraz bekleyin ve tekrar kontrol edin. Docker muhtemelen hala görüntüleri indiriyor.

Görmek inanmaktır

Yine de benim sözüme (veya Docker'ın sözüne) inanmayın. Uygulamamıza bağlanmayı deneyelim. Hizmet yapılandırmamız Docker'a NGINX'i 8000 numaralı bağlantı noktasında göstermesini söyler. PWD kullanıyorsanız, sayfanın üstünde “8000” yazan mavi bir bağlantı olmalıdır. PWD aslında o bağlantı noktasında çalışan bir hizmetimizin olduğunu otomatik olarak algıladı! Bunu tıkladığınızda, sizi 8000 numaralı bağlantı noktasındaki seçili düğüme yönlendirecektir. Kendi sunucularınızı yuvarladıysanız, yalnızca 8000 numaralı bağlantı noktasındaki sunucularınızın IP'lerinden birine gidin.

Size bazı temel bilgileri veren güzel bir tarza sahip bir ekranla karşılaşacaksınız:

İsteğinize hangi kapsayıcının hizmet ettiğini not edin ve ardından sayfayı yenileyin. Büyük ihtimalle değişti. Ama neden? Docker'a Flask uygulamamızın iki kopyasını oluşturmasını söyledik ve istekleri bu örneklerin her ikisine de dağıtıyor. Az önce ikinci kez diğer konteynere çarptın. Her iki Flask kapsayıcısının belirttiğimiz tek Redis örneğiyle iletişim kurması nedeniyle istek sayısının arttığını da fark edeceksiniz.

Herhangi bir düğümden 8000 numaralı bağlantı noktasına ulaşmayı denemekten çekinmeyin. Yine de uygulamaya doğru şekilde yönlendirileceksiniz.

Büyünün gizemini çözmek

Bu noktada, her şey çalışıyor ve umarım, süreci ağrısız buldunuz! Bu docker-compose.yml dosyasına daha yakından bakalım ve Docker'a gerçekte ne söylediğimizi görelim. Yüksek düzeyde, üç hizmet tanımladığımızı görüyoruz: web , nginx ve redis . Normal bir oluşturma dosyası gibi, Docker'a her hizmet için kullanılacak bir görüntünün yanı sıra çalıştırılacak bir komut sağladık. nginx durumunda, ana bilgisayardaki 8000 numaralı bağlantı noktasının kapsayıcıdaki 80 numaralı bağlantı noktasıyla eşleşmesi gerektiğini de belirttik. Bunların hepsi şu ana kadar standart oluşturma sözdizimidir.

Buradaki yenilikler, konuşlandırma ve gizli anahtarlardır. Bu anahtarlar docker-compose tarafından yoksayılır, bu nedenle geliştirme ortamınızı etkilemezler, ancak docker stack tarafından kullanılırlar. Web servisine bakalım. Yeterince basit, Docker'a Flask uygulamamızın iki kopyasını çalıştırmak istediğimizi söylüyoruz. Ayrıca Docker'ın web hizmetinin db_password sırrını gerektirdiğini bilmesini sağlıyoruz. Bu, kapsayıcının /run/secrets/db_password adında, sırrın değerini içeren bir dosyaya sahip olmasını sağlayan şeydir.

Nginx'e geçerken, dağıtım modunun global olarak ayarlandığını görebiliriz. Varsayılan değer (web'de örtük olarak kullanılır) replicated , bu da kaç kopya istediğimizi belirleyeceğimiz anlamına gelir. global belirttiğimizde, Docker'a sürüdeki her düğümün hizmetin tam olarak bir örneğini çalıştırması gerektiğini söyler. docker service ls tekrar çalıştırın, nginx her düğüm için bir tane olmak üzere üç kopyası olduğunu fark edeceksiniz.

Son olarak, Docker'a sürünün herhangi bir yerinde tek bir Redis örneğini çalıştırması talimatını verdik. Web kapsayıcılarımız Redis ana bilgisayarını istediklerinde otomatik olarak oraya yönlendirildiğinden, nerede olduğu önemli değildir.

Swarm'ı Günden Güne Kullanma

İlk uygulamanızı bir Docker Swarm'a dağıttığınız için tebrikler! Şimdi kullanacağınız birkaç genel komutu gözden geçirmek için biraz zaman ayıralım.

Sürünüzü İncelemek

Hizmetlerinizi kontrol etmeniz mi gerekiyor? docker service ls ve docker service ps <service name> deneyin. İlki size her bir hizmetin üst düzey bir genel görünümünü gösterir ve ikincisi, belirtilen hizmet için çalışan her bir kapsayıcı hakkında size bilgi verir. Bu, özellikle hangi düğümlerin bir hizmeti çalıştırdığını görmek istediğinizde yararlıdır.

Sürekli Güncellemeler

Bir uygulamayı güncellemeye hazır olduğunuzda ne olacak? docker stack deploy en güzel yanı, güncellemeleri aslında mevcut bir yığına da uygulayacak olmasıdır. Deponuza yeni bir Docker görüntüsü yüklediğinizi varsayalım. Aslında sadece ilk kez kullandığınız aynı konuşlandırma komutunu çalıştırabilirsiniz ve sürünüz yeni imajı indirecek ve konuşlandıracaktır.

Elbette yığınınızdaki her hizmeti her zaman güncellemek istemeyebilirsiniz. Servis düzeyinde de güncellemeler yapabiliriz. Son zamanlarda web hizmetim için resmi güncellediğimi varsayalım. Tüm web kapsayıcılarımı güncellemek için bu komutu verebilirim:

 docker service update \ --image lsapan/docker-swarm-demo-web:latest \ demo_web

Bu komutun ek bir avantajı, orijinal yapılandırmanızda olması gerektiğini belirttiyseniz, sürekli güncelleme uygulayacak olmasıdır. Ve yapmamış olsanız bile, güncellemeye aşağıdaki gibi sürekli bir güncelleme yapmasını söyleyen bayrakları iletebilirsiniz:

 docker service update \ --image lsapan/docker-swarm-demo-web:latest \ --update-parallelism 1 --update-delay 30s \ demo_web

Bu, güncellemeler arasında 30 saniye bekleyerek her seferinde bir kapsayıcıyı güncelleyecektir.

Hizmetleri Yukarı veya Aşağı Ölçeklendirme

İki web kapsayıcısına sahip olmak harika, ancak daha iyi olan ne biliyor musunuz? 10 tane var! Bir sürüde hizmetleri yukarı ve aşağı ölçeklendirmek şu kadar kolaydır:

 docker service scale demo_web=10

Bu komutu çalıştırın ve docker service ps demo_web çıktısını kontrol edin. Şimdi on konteynırımız olduğunu ve bunlardan sekizinin az önce başlatıldığını göreceksiniz. İlgileniyorsanız, web uygulamasına geri dönebilir ve şimdi orijinal iki kapsayıcı kimliğinden daha fazlasını aldığınızı görmek için sayfayı birkaç kez yenileyebilirsiniz.

Yığınları ve Hizmetleri Kaldırma

Yığınlarınız ve hizmetleriniz dağıtıldı ve ölçeklendi, harika! Ama şimdi onları çevrimdışına almak istiyorsun. Bu, ilgili rm komutuyla yapılabilir. Demo yığınımızı kaldırmak için şu komutu çalıştırın:

 docker stack rm demo

Veya tek bir hizmeti kaldırmayı tercih ederseniz, şunu kullanın:

 docker service rm demo_web

Boşaltma Düğümleri

docker node ls kontrol etmek için daha önce liman işçisi düğümünü çalıştırdığımız zamanı hatırlıyor musunuz? Kullanılabilirliği de dahil olmak üzere her düğüm hakkında bir sürü bilgi sağladı. Varsayılan olarak, düğümler Active'dir ; bu, kapsayıcıları çalıştırmak için adil bir oyun oldukları anlamına gelir. Ancak, bakım gerçekleştirmek için bir düğümü geçici olarak çevrimdışı duruma getirmeniz gereken zamanlar olabilir. Elbette, onu kapatabilir ve sürü iyileşebilir, ancak Moby'ye (Docker balinası) biraz haber vermek güzel.

Drenaj düğümlerinin devreye girdiği yer burasıdır. Bir düğümü Drain olarak işaretlediğinizde, Docker Swarm, üzerinde çalışan tüm kapsayıcıları diğer düğümlere devreder ve siz onun kullanılabilirliğini tekrar Active olarak değiştirene kadar düğümde herhangi bir kapsayıcı başlatmaz.

Diyelim ki node1 boşaltmak istiyoruz. Çalıştırabiliriz:

 docker node update --availability drain node1

Kolay! İşe geri döndürmeye hazır olduğunuzda:

 docker node update --availability active node1

Toplama

Gördüğümüz gibi Docker, Swarm moduyla birleştiğinde uygulamaları her zamankinden daha verimli ve güvenilir bir şekilde dağıtmamızı sağlıyor. Docker Swarm'ın oradaki tek konteyner düzenleme motoru olmadığını belirtmekte fayda var. Aslında, daha genç olanlardan biri. Kubernetes daha uzun süredir var ve kesinlikle daha fazla üretim uygulamasında kullanılıyor. Bununla birlikte, Swarm, Docker tarafından resmi olarak geliştirilen ve her gün daha fazla özellik eklemek için çalışıyorlar. Hangisini kullanmayı seçerseniz seçin, saklamaya devam edin!