‫D yapmak gibi belirli bir sırada tutmak için konteynerlerinizi geciktirmek için en iyi strateji
‫nedir? B. Webb tavşanı ve benzeri.
‫Yani bir numaralı şey, bunun bir dağıtık bilgi işlem olayı olduğunu söyleyen bir geliştirici OP'si bile değil.
‫Docker compose gibi bir şeyle yerel geliştirme iş akışından değil, üretimden bahsettiğinizi
‫varsayıyorum.
‫Ancak üretimden bahsediyorsanız, tüm uygulamalarınızın başarısız olabilmesi veya yeniden deneyebilmesi gerekir.
‫Dolayısıyla, Docker'dan önce olsun ya da olmasın, temelde orada ne kullanıyorsanız kullanın, kendi
‫dışındaki diğer hizmetlerle konuşamamaktan bir şekilde kurtulması gerekir.
‫Bu da dağıtık bilişimin temel ilkelerinden biridir.
‫Aslında burada bir kaynağın ne olduğuna bakarsanız, 12 faktör on iki faktör nokta net, bulut yerel ve dağıtılmış bilgi işlem zihniyeti etrafında on
‫yıllık bir ilkeler dizisidir, bunlar iki farklı ama benzer türden şeylerdir, gerçekten
‫de bir grup sunucum veya sunucularımın konuşması gereken bir dizi şey varsa, bunların hepsinin mevcut olması
‫gerektiğinde nasıl kullanılabilir hale getirebilirim veya düzenleyebilirim.
‫Cevap ise başlangıçta kontrol edemeyeceğinizdir çünkü başlangıç sorunun sadece bir parçasıdır.
‫Bir konteyneri değiştirmek zorunda kaldığınızda, bir konteyner veya başka bir hizmet bir saniyeliğine çöktüğü için diğer
‫konteynerlerle bağlantı kesilirse, onu kullanan diğer tüm hizmetlerin kurtarılması
‫gerekir.
‫Tek bir sunucumuzun olduğu ve web sitesindeki veritabanını aynı sunucuya koyduğumuz
‫eski günlerin aksine, bu sunucu çökene kadar her zaman kullanılabilir ve çevrimiçiydi.
‫Ancak artık bu dünyada konteynerlerinizi ve tüm hizmetlerinizi dağıtık bilişimle sunuyoruz ve bunu göz önünde bulundurmanız
‫gerekiyor.
‫Bu yüzden ya yeniden denemeleri gerekir ki eğer geliştirme yapıyorsanız en çok üzülen siz olursunuz.
‫Çoğu veritabanı sürücüsü, Mongo D'de olduğu gibi yeniden denemeyi gerçekten deneyecek şekilde tasarlanmış yerleşik yeniden
‫denemeye sahiptir. B. ve düğüm. js'nin aslında bağlanamadığı durumlarda
‫veritabanının tekrar çevrimiçi olmasını beklemek için komutları bir süre tutacağı bir tampon protokolü bile vardır.
‫Geliştirdiğiniz dilin sürücüsünde yerleşik olarak bulunur, bu nedenle bunun gibi pek çok şey vardır.
‫Ve eğer uygulamanız böyle bir şey yapmazsa ve sadece başarısız olursa.
‫Konteyner orkestrasyonu kullanıyorsanız güzel olan şey, bu orkestratörün işinin bir parçası,
‫konteyner bir şeyden bağlantıyı kaybettiği için çökerse, orkestratör yeniden başlayacak ve temelde
‫başka bir yerde bunun yeni bir kopyasını başlatacaktır.
‫Bu da başarısızlıktan kurtulmanın bir yoludur.
‫Yeniden denemeleri sistemleriniz için biraz daha temiz ve daha az yorucudur, ancak Docker'da bunu yapmanın bir başka
‫yolu da uygulamalarınızın çökmesine izin vermektir ve ardından Docker ayarlarınıza göre onları yeniden başlatacaktır.
‫Bu yüzden bunun muhtemelen küçük tıklama düğmesi olmadığını biliyorum.
‫Çok cevap ver.
‫İnsanlar sadece Oh, doktor kompozisyonunuza yeniden deneme eklemeniz gerekiyor gibi bir cevap verebilirler,
‫ancak bu bir üretim çözümü değildir çünkü sadece orijinal başlangıçla ilgilidir ve hatta
‫Google'da Wait for it script gibi bir şey ararsanız, bunlar da tüm sorunu gerçekten çözmez çünkü Eğer konteynerleri
‫kullanmaya başlayacaksanız, onları daha sık güncelleyeceksiniz.
‫Bu, dev ops zihniyetini uygulamanın ilerlemesinin bir parçasıdır; işler geçmişte olduğundan daha sık güncellenecektir
‫çünkü dev ops'un temel ilkelerinden biri sürekli olarak gelişmek ve iyileştirmektir.
‫Yani bunu yapmaya başladığınızda, yapbozunuzun herhangi bir parçasının, yapbozun diğer parçalarının aşağı inmesini
‫kaldırabilmesi gerekir ve ne demek istediğimi anlıyorsanız, bunu başlangıç düzeniyle gerçekten yapamazsınız.
‫Umarım yardımı olur.
‫Eski uygulamalarla uğraşıyorsanız bu çözülmesi zor bir sorundur ancak bu bir sürekliliktir.
‫Uygulamalarınızın başarısızlıkla başa çıkma sürecini devam ettirmek için sürekli olarak çalışmanız gerekir.
‫Aslında bu kolay bir sorun değil.
‫Bu, içinden geçilmesi gereken bir süreç.