‫Donatör Sağlık Kontrol komutu. 1'de eklenen yeni bir özellikti. 12, yani Swarm Kit ve Swarm
‫Mode'un Docker'da mevcut olduğu 2016 yılının ortasında çıktı. Bu araç setinin bir parçası olarak gerçekten
‫eklendi, ancak Dockerfile, Oluştur dosyası, liman işletmeciliği komutu onu kullanan Yığın dosyaları destekleyen servis
‫güncelleme ve servis oluşturma komutu gibi tüm farklı dosyalarda hala çalışıyor
‫.
‫O heryerde.
‫Üretim yapmaya başladığınızda, bu sağlık kontrolü komutu için test seçeneklerine girmenizi
‫öneririm.
‫Bir exec ile kutudan çıkıp çalışacak.
‫Bu komutu, kendi exec komutunu çalıştırıyormuş gibi konteynerin içinde
‫yürütür.
‫Yani, kabın dışından çalıştırmak değil; sadece içeride çalıştırıyor olması, portları
‫bulunmayan basit işçilerin bile, iyi bir veriyi döndürüp döndürmediklerini doğrulamak için basit
‫bir komut çalıştırabileceği anlamına gelir.
‫Basit bir komut yürütme işlemidir, bu da basit bir geri dönüş anlamına gelir. 0 veya 1 bekliyor.
‫Linux ve Windows'ta, komutlardan çıkış kodları vardır ve 0 iyi bir şeydir.
‫Her şeyin yolunda olduğu anlamına gelir.
‫Çoğu uygulamada 0'dan başka herhangi bir şey bir hata olacaktır.
‫Ama Docker'da, 1'den özel olarak çıkmak için o uygulamaya ihtiyacımız var. Bunu nasıl yaptığınızı bir dakika
‫içinde göstereceğiz.
‫Docker'da bir sağlık kontrolüne yalnızca üç devlet var. Başlamakla başlar. Başlangıçta ilk 30 saniyedir,
‫varsayılan olarak sağlık kontrolü komutunu çalıştırmadığı yerdir.
‫Sonra bir tane geçecek.
‫Bu 0 döndürürse sağlıklı ile başlar. Sağlıklı seçeneğe değişecek.
‫Bu komutu kullanacak ve varsayılan olarak her 30 saniyede bir tekrar çalışacaktır. Bir çıkış 1 gibi sağlıksız bir
‫dönüş elde ederse, sağlıksız bir konteyner olarak işaretler.
‫Yeniden denemeler de dahil olmak üzere tüm bunları kontrol etme seçeneklerimiz var.
‫Bunu bir dakika içinde göreceğiz.
‫Bu geçmişte yaşadığımızdan daha iyi bir seçenek çünkü Docker, şimdiye kadar sadece uygulamanın
‫hala çalışıyor olduğundan emin oluyordu.
‫Bu uygulamanın gerekenden ötürü olup olmadığını anlama konusunda herhangi bir fikri yoktu.
‫Şimdi bunu Docker kabının içinde yapabiliriz.
‫Ancak bu, üçüncü taraf izleme çözümü yerine geçmez.
‫Bu, size zamanla grafikler veya durum bilgisi ya da bir izleme çözümü dışında bekleyeceğiniz üçüncü
‫parti araç türleri sunmamaktadır.
‫Konteynerin kendisinin temel seviyede sağlıklı olup olmadığını Docker anlayışı ile ilgilidir.
‫Bu nedenle, bir Nginx'te, kök dizin dosyasının bir yerelhostunu döndürebilir. 200 ya da 300'lük bir geri dönüş iyidir ve ona
‫0 çıkış kodu verir ve sağlıklı olduğunu düşünür.
‫Bu süper gelişmiş değil, biliyorsun, izleme aracı.
‫veya 500 hata döndürürse, sağlıksız olduğunu düşünür ve bu konuda bir şeyler yapabiliriz.
‫Ancak, 404
‫Bu Docker sağlık kontrolünü nereden GUI'de göreceğiz?
‫Birincisi konteyner ls'de.
‫Bunu sadece bu yeni seçenek olarak görür.
‫Ortada. Bir saniye, sağlık kontrolü çalışıyorsa bize üç eyaletten birini
‫göstereceğini göreceğiz ve aslında sağlık kontrolünün olduğunu nereden biliyoruz.
‫En azından bunu öğrenmenin en kolay yolu. O sağlık kontrolünün son beşini
‫içeren konteynerin konteynerin muayenesinde olduğunu göreceğiz. Ve orada zamanla bazı temel trendleri görebiliriz.
‫Fakat liman işletmeciliği komutu sağlıksız bir konteyner üzerinde harekete geçmez.
‫Sağlık denetimi bir kabın sağlıksız olduğunu düşündüğünde, liman işletmesi sadece ls komutunda ve
‫teftişte belirtmek için gidiyor ancak harekete geçmeyecektir.
‫Swarm Services'ın bu konuda harekete geçmesini bekliyoruz.
‫Böylece yığınlar ve hizmetler, muhtemelen zamanlayıcıya bağlı olarak, yeni bir ana bilgisayarda bu kapsayıcıyı yeni
‫bir görevle değiştirecektir.
‫dahi, sağlık kontrollerini kullanarak biraz ekstra bonus görüyoruz, çünkü güncellemeler sağlık
‫kontağını konteynerin gitmeden önce değiştirmeye hazır olduğunun bir parçası olarak görüyor.
‫Güncelleme komutunda
‫Bir konteyner çıkarsa, ancak sağlık kontrolünden geçmezse, servis güncellemesi
‫bir sonraki kontrole gitmez. Veya verdiğiniz değişiklikler temel alınarak harekete geçecektir.
‫Komut satırına gitmeden önce birkaç örneğe göz atalım.
‫Liman işletmecisinde kullandığımız bu.
‫Bu, içinde sağlık kontrolü olmayan mevcut bir görüntüyü kullanmamızı sağlar ve
‫çalışma zamanında sağlık kontrolü ekliyoruz.
‫Bu durumda, Elasticsearch görüntüsünü kullanıyoruz. olan bir cURL localhost 9200'dür görebilirsiniz.
‫Komut, Elasticsearch'in kapsayıcı içinde, yayınlanmış olan bağlantı noktası değil, ancak kapsayıcı içinde
‫çalıştığı bağlantı noktası Elasticsearch için
‫gerçek bir sağlık URL'si var.
‫Yani, burada kullanabiliriz.
‫Bu komutun sonunda iki boruyu yanlışla görürsünüz.
‫Ve cURL veya 1'den
‫farklı bir hata kodu gönderecek başka bir araç gibi bir şey kullanırsanız oldukça yaygınlaşacaktır.
‫Hatırladığım zaman bunu bir süre önce mi bahsettiniz? Bir sorun varsa 1 ile çıkmamız lazım. hata kodu budur.
‫Çünkü Docker'ın bir şeyler yapacağı tek bir
‫Bu durumda, bir kabuk 0'dan başka bir şey çıkarsa, bir kabuğun her zaman
‫yanlış 1 çıkış kodunu döndürmesini sağlamamız gerekir.
‫Bu sorunun üstesinden gelmenin güzel bir yolu.
‫Sadece cURL ile olur, cURL diğer olası hata kodlarını verir ve bunu
‫yapmak istemiyoruz.
‫Gerçek Docker dosyalarında aynı komutu ekleyebiliriz. Biçim biraz farklı. Ancak gördüğünüz gibi,
‫burada bu seçeneklerimiz var. Aralık, zaman aşımı, başlangıç ​​periyodu (yeni) var ve denemeler.
‫Aralığı, ne düşündüğünüzdür. Varsayılan olarak her 30 saniyedir.
‫Bu sağlık kontrolünü ne sıklıkla gerçekleştirecek. Zaman aşımına uğrama, hatalar öncesi ne kadar süre
‫bekleyecek ve kötü bir kod döndürür, belki de uygulama yavaştır. Başlangıç ​​dönemi, 17 yaşında şimdi bize sağlık kontrolünü başlatmadan önceki
‫izin veren yeni bir özelliktir. 09 ve daha yeni, süre ilk 30 saniyeden daha uzun bir bekleme süresi vermek için. Önceden, uzun Ancak belki bir Java uygulaması veya veritabanı ya da başlatmak için daha uzun süren bir şey var.
‫süre beklerdi. aralık süresi. Belki de beş dakika sürer.
‫O başlangıç ​​periyodunu oraya ekleyebilirsiniz. Hala sağlık kontrolü yapacaktır. Ancak ne yapacağı, o zamana kadar sağlıksız bir kontrol
‫alarmı vermeyecek olmasıdır.
‫işaretini geçtikten sonra sağlıksız olduğunu düşünür.
‫Dolayısıyla orada iki dakika ayarlarsanız, her 30 saniyede bir sağlık kontrolü yapıyor olsa da, iki dakika Sonuncusu, denemeler, sağlık kontrolünü x
‫denedikten sonra sağlıksız olduğumuz anlamına gelmektedir.
‫Bu, belki potansiyel olarak dengesiz bir uygulamaya, sağlıklı
‫bir şekilde geri dönme şansını verir ve bunu gerçekten sağlıksız bir konteyner düşünmeden kendi başına iyileşir.
‫Bir Docker dosyasında kullanacağınız temel sağlık kontrolü komutuna
‫HEALTHCHECK, tüm büyük harfler var. Aynı biçim, yalnızca localhost'un basit bir
‫cURL'sini yapıyor olsaydık, belki PHP uygulamasıdır. Bunu yapabiliriz.
‫budur, böylece zaman aşımı aralığını ve komutun kendisinden önceki denemeleri nasıl eklediğimi göreceksiniz.
‫Tüm bu seçenekleri bir Docker dosyasına nasıl ekleyeceğiniz
‫İlk komut için ilk komut var, komutun çalıştırılmasına
‫izin veriyorsam bir CMD koymam gerekmiyor dikkat edin. Ancak seçenekleri göstermek istersem, zaman aşımı ve benzeri gibi
‫kutudan özel seçenekler vermek istiyorsanız, hangisinin komut olduğunu belirtmek zorundayım.
‫Şimdi bunlar iki farklı çizgi değil.
‫Orada ilk satırın sonundaki eğik çizgiye dikkat edin.
‫Sakın anlamazsın.
‫statik bir uygulamanız olmasının nasıl bir şey olabileceğine dair basit bir örneğimiz var.
‫Burada, bir Nginx sunucusu içinde çalışan
‫Aralık ve süreyi Docker dosyanızdan ayarlayabilirsiniz ve yalnızca localhost üzerinde bir cURL
‫komutu yapmanız yeterlidir.
‫200 ya da 300'ü geri verirse, para cezası kabul eder. 4 veya 5 veya başka bir şey döndürürse,
‫bir hata olduğunu düşünür.
‫Burada bir yanlış 1 ile aynı şey olduğunu, bir çıkış 1 var fark ettiniz.
‫Bunu sadece İnternetteki bazı örneklerin sahte olacağını göstermek için yaptım. Bazı
‫örneklerde 1 çıkış olacaktır.
‫İkisi de aynı şeyi yapar.
‫İşte biraz daha gelişmiş örnek.
‫Bu durumda, Nginx ile birleştirilmiş bir PHP uygulaması kullanıyoruz.
‫Yaptığım şey, kaynaklarda bu PHP örneğine bir bağlantı bulacaksınız. Nginx ve PHP-FPM durum
‫URL'lerini kullanan özel bir Nginx yapılandırma dosyasına ekledim.
‫Bu iki uygulamanın da kendi durum sayfası ve bir sağlık tarama ping URL'si türü vardır.
‫PHP veya Nginx kullanıyorsanız bunları uygulamalarınızda kullanabilirsiniz. İki farklı URL vardır, ancak her
‫ikisini birden aynı sağlık taramasında kullanabilirsiniz.
‫Bu durumda, sadece bunlardan birini
‫kullanıyoruz ve aslında bir PHP-FPM durum
‫komutu olan localhost / ping'e atıyoruz ancak bunu PHP-FPM'nizde etkinleştirmeniz gerekiyor. Yine, bu dersin kaynaklarına PHP Docker İyi Varsayılanları
‫bağlantısı var.
‫Bu örnekte biraz daha ayrıntılı olarak gösterdiğim bir GitHub'da bunu kontrol edebilirsiniz.
‫Sonra Postgres örneğimiz var, böylece Docker dosyasında farklı bir URL kullanabiliyorum.
‫Burada sağlık kontrolü komutunda pg isready komutunu kullandığım Postgres uygulaması var.
‫Şimdi, farklı uygulamalarla farklı araçlar var. olan bağlantıyı çok basit bir şekilde test eder.
‫Postgres ile, yerleşik bir araçla birlikte gelir; bu, Postgres sunucusuyla
‫İyi verilerinizin olup olmadığını veya veritabanınızın düzgün şekilde monte edildiğini doğrulamaz. Basitçe, 'Bu veritabanı
‫sunucusu bağlantılara izin veriyor mu? Evet veya Hayır? 'Kutudan çıkarıp yapabileceğiniz temiz
‫bir ürün.
‫İşte bir besteci / yığın dosyasında nasıl göründüğü.
‫Çok benzer.
‫Aşağıdaki başlangıç ​​periyodunun farklı bir sürümü gerektirdiğini fark edeceksiniz.
‫Sağlık kontrolü komutu 1'den beri çıktı. 12, aslında 2'de desteklendi. 1'i.
‫Bu Oluşturma dosyasının
‫Ancak, başlangıç ​​dönemini kullanacaksanız, Oluşturma dosyanızı sürüm 3'e
‫güncellemeniz gerekir. Bunu desteklemek için 4. Başlangıç
‫​​periyodu sağlık kontrolü komutundan sonra bir yıl sonra ortaya çıktı.
‫Bazı basit çalıştırma komutlarıyla başlayalım.
‫Burada yapacağımız şey, sağlık kontrolü olmadan bir Postgres
‫veritabanı sunucusuna başlayacağımızdan, varsayılan olarak, bununla birlikte gelmiyor.
‫olan manuel sağlık kontrolü komutuyla tekrar çalıştıracağız ve farkı göreceğiz.
‫Ardından, komut satırına ekleyecek
‫Burada, sadece birincisini p1 diyeceğiz. Resmi Postgres
‫imajından koparacağız.
‫Bir rıhtım konteyneri yaparsam, burada bir sağlık kontrolünü gösteren hiçbir şey olmadığını göreceksin.
‫Aynı komutu tekrar yaparsak ve bu kez p2 diyebilirsek, bir sağlık komutu ekleyeceğiz.
‫Bu sefer, bağlantıları bu Postgres sunucusunda mevcut
‫olduğunu test etmek için daha önce bahsettiğimiz pg isready'yi kullanacağız. İhtiyacımız olan kullanıcının postgres kullanıcısı
‫olduğunu söyleyeceğiz. Aslında ona bir şifre vermek zorunda değiliz. yapmaya çalışmayacak.
‫Giriş Sadece doğrulamaya çalışacağız. Postgres görüntüsünü kullanacağız.
‫Şimdi, liman liman kabı ls yaparsak,
‫biraz uzaklaştıracağımızı görürsünüz, '4 saniyelik sağlık başlar.' 'Şimdi bu
‫ek özelliği bizim ls komutu durumumuzda alıyoruz. İlk kez sağlık kontrolü komutunu çalıştırana kadar varsayılan 30 saniye
‫boyunca
‫başlangıç ​​durumunda kalır.
‫30 saniye içinde beklediğimize göre, sağlıklı bir duruma dönüştüğünü görürsünüz.
‫yeni sağlık durumu seçeneğinin bulunduğu görürüz.
‫Bu p2'yi inceleyen bir liman köprüsü konteyneri yaparsak, bunun en üstünde Bu durumda, yalnızca iki kere çalıştırdım.
‫Çıktının orada olduğunu, bağlantıları kabul ettiğini gösteriyor.
‫Tamam. Aynı veritabanı için, aynı test sağlık kontrolünde komutlar oluşturmak için bazı servisler yapalım.
‫Bunu yaptığımızda burada göreceğimiz şey, bir servisin başlatılmasıyla ilgili
‫üç farklı durumun olmasıdır.
‫Hazırlanıyor, bu da genellikle resmi indiriyor demektir. Başlıyor, yani kabın icrası ve kaldırılması anlamına
‫geliyor. Sonra koşuyor.
‫Sağlık kontrolü komutu olmadan, çalıştırma ve çalıştırma çok hızlıdır. Neredeyse ani oluyorlar.
‫Burada liman hizmeti ile ad p1 postgres oluşturduğunu göreceğiz.
‫Görüntüyü indirerek hazırlandığında,
‫sağlık kontrolünün olmaması nedeniyle derhal çalışmaya başlayacağını göreceksiniz. Konteynerin çalıştırılmasından başka yapılması gereken başka
‫bir şey yok ve 'Evet. İkili çalışıyor. 'Fakat aynı komutu yerine getirirsem, rıhtım hizmeti yaratır ve p2'yi daha önce
‫olduğu gibi yaratır ve aynı sağlık
‫komutunu verir.
‫Bu hizmeti, yerleşik sağlık kontrolü komutuyla başlatıyoruz.
‫başlangıç ​​durumuna oturacağıdır.
‫Göreceğimiz şey, hazırlık aşamasından başlayacağına ve ilk sağlık kontrolü çalışıncaya kadar varsayılan 30 saniye boyunca
‫Bu, şu anda bu servisin tamamen çalıştığı kanaatine varmadan
‫sağlıklı bir durum bekleyen Donör Hizmetidir. 30 saniye bittiğinde, çalışma durumuna geçeceğiz. O zaman, sonuncuyu orada doğrulamış
‫oluruz, sadece kararlı olduğu düşünülür ve işimiz biter.
‫Bu komutları elimizden geldiğince kullanırsak, hizmetlerle birlikte
‫ve servis güncellemeleriyle birlikte bu sağlık konseptinin fazladan bonusunu alacağız zaten kutudan görebilirsiniz.
‫