Genellikle bir geliştirici iş gereksinimlerini karşılamaya özen gösterir. Belirli bir yığın veya çerçevede uzmanlığa sahip olabilir. Ancak liman işçisini öğrenmek için çaba göstermeli ve çeşitli dağıtım yöntemleri (sürüsü, kube, mezos, vb.)?
Basitçe söylemek gerekirse bir geliştirici neden liman işçisine önem vermeli?
Not: Bu gönderinin ana sorusu, liman işçisini geliştirme ekibine tanıtmaktır
Yanıtlar:
Muhtemelen aradığınız cevap değil, yine de bir cevap :)
Liman işçisini ve dağıtım yöntemlerini öğrenmek, tıpkı kod dil (ler) i, sürüm kontrol sistemi, derleyiciler, test altyapısı vb. Gibi projenin veya ekip geliştirme ortamının bir parçası haline getirilerek iş gereksinimlerine dahil edilebilir. o takımda veya o projede, bunların hepsini bilmesi ve kullanması gerekir, "kendi takımınızı getiremez" (çoğu durumda).
"Bir geliştirici" ile aslında geliştirme ekibinin çoğunluğunu veya hatta tamamını kastediyorsanız, işler biraz daha karmaşıklaşır. Herhangi bir geliştiriciyi desteklemeden geliştirme ortamında bir aracı zorlamak gerçekten zor olacaktır. Önce ekibin teknik liderliğinden böyle bir destekçi oluşturmak için zaman harcayın.
Yan not: takımdaki her geliştiricinin liman işçiliği uzmanı olması da gerekli olmayabilir . Basit, hile sayfasına hazır komutlarla sarılmış önceden belirlenmiş kullanım tarifleri genellikle geliştiricilerin özellikle büyük ekiplerde oldukça kabul edilebilir olan iç işleri hakkında çok fazla şey bilmeden liman işçisi tabanlı çözümleri kullanmalarına izin verir. Tıpkı son ürünün nasıl inşa edildiğine dair tüm detayları bilmeden kodlara katkıda bulunabilmek gibi.
Sana bakış açımı vereceğim. Docker'ı kullanmak isteyen ve zaten bir uzmanlık geliştirmiş olan diğer geliştiriciler olduğu için geliştiriciler liman işçisine önem vermelidir. Geliştirici olmakla birlikte DevOps mühendisinin rollerini üstlenmeye hazırlar. DevOps'un Ops kısmı şu anda uzmanlık kazandıkları şey.
Bu günlerde, bu tam paketi izlemek ve tek başına üretime almak için testleri geliştirebilen, düzenleyen, otomatikleştiren, işleri otomatikleştiren ve araçlar oluşturabilen daha fazla adam bulacaksınız. Bunlar geliştirici topluluğu arasında liman işçisini ve diğer araçları iten çocuklar.
Ayrıca, pazarın gelgitleri sanallaştırma, otomatik ölçeklendirme, otomasyon, makine öğrenimi ve docker'ın hepsine uyar. Liman işçisini kullanmak çok zorunluluk haline geldi. İşletmeler, tüm bu sorumlulukları alan tek bir adam için 2x ödemeye hazırdır ve bu adamlara talep olduğunda, arz da başlayacaktır. Bu bir çalışan-işveren açısından.
Teknik olarak, çalıştığım organizasyonlarda, teslimatlar için çok yakın çalışmasına rağmen ayrı geliştirme ve DevOps ekipleri var. DevOps mühendisleri ve geliştiricileri burada beceri setlerinin büyük çoğunluğunu paylaşıyorlar ve bu nedenle bazen görevler müzakere ediliyor.
Bir geliştiricinin yapabileceği en düşük minimum ikili dosyalarını paylaşmaktır, ancak ikili dosyaların bir docker konteynerinin içinde çalıştırmak için kullanılacağını ve bunun için docker'ın nasıl çalıştığını anlaması gerekir. Kübeler, sürüler, mezolar vb. İçin, geliştirici ne kullanıldığını bile umursamayabilir, ancak docker'ın temelleri geliştirici tarafından çok iyi anlaşılmalı ve yeniden kullanım için gevşek bağlanmış uygulamayı oluşturmak için baştan bir zihniyet bulunmalıdır. mikro hizmetleri. Uygulama bu zihniyetten oluşturulmuşsa (liman işçisinin temellerini gerektirir), DevOps mühendisleri otomatik ölçeklendirme, düzenleme, test etme, dağıtma ve izleme için oradan alabilirler.
Ayrıca, çoğu zaman tek bir beden her şeye uyar. Bir geliştirici, bir liman işçisi dostu uygulamanın nasıl oluşturulacağını açıkça bilmez ve bir DevOps mühendisi, uygulama oluşturma sürecinin iç kısımlarını tam olarak bilmez. Bu nedenle, organizasyonlar çoğu zaman işleri hızlandırmak için her iki görevi de aynı adama vermeyi tercih eder. Ayrı şeyler varsa, uygulamaları daha fütüristik ve docker / bulut / ölçeklendirmeyi hazır hale getirmek için DevOps ekibinden dev ekibine sürekli bir geri bildirim mekanizması gerekir.
Bu, Docker veya dışarıdaki diğer konteyner teknolojileri ile ilgili değil.
Docker, rkt vb. Gibi kaplar, uygulamanızı statik ikililere benzer şekilde sunmanın bir yoludur. Dağıtımınızı, içeride ve son kullanıcının çalışma zamanından başka bir şeye ihtiyacı olmadığı her şeyi içerdiği şekilde oluşturuyorsunuz.
Bu çözümler, Java'daki şişman JAR'lara benzer, burada (teoride) ihtiyacınız olan her şey sadece çalışma zamanı (JRE) önceden yüklenmiş ve her şey Just Works ™.
Geliştiricilerin anlaması gerekmesinin nedeni (böyle bir aracın nasıl kullanılacağını öğrenmek zorunda değiller, sadece bunun neden gerekli olduğunu) düzenleme araçları, bunun "geleneksel" konuşlandırmaya göre bazı avantajlara sahip olmanıza izin vermesidir.
EngineYard bu konuda iyi makaleler yazdı. Bütün mesele, sunucunuz öldüğünde, omuz silkip yeni görünecek şekilde beklemenizdir. Onlara sığır muamelesi yapıyorsunuz, onlarca, yüzlerce, binlerce insan var ve biri aşağı indiğinde siz ya da müşterileriniz bunun farkında olmamalı.
Düzenleme araçları, kümedeki tüm uygulamaların (bölmeler / işler, ne olursa olsun) durumunu izleyerek ve sunuculardan birinin yanıt vermeyi durdurduğunu (aşağı gittiğini) gördüğünde, o sunucuda çalışan tüm uygulamaları otomatik olarak başka bir yere taşır.
Düzenleme sayesinde bir sunucuda birden fazla uygulama çalıştırabilirsiniz ve orkestratör kaynakları sizin için izler. Gerektiğinde uygulamaları yeniden düzenleyecektir.
Orkestratörlerdeki otomatik yük devretme yönetimi sayesinde özel görüntülerinizi bulutta olduğu gibi çalıştırabilirsiniz. Güncellemeye ihtiyaç duyacağınız zaman, sadece yeni bir görüntü oluşturursunuz, Başlat Yapılandırmanızı bu görüntüyü şimdi kullanacak şekilde ayarlayın ve sadece yuvarlayın. Her şey sizin için halledilecek:
TL; DR Bütün mesele Docker değil, düzenleme ile ilgili. Docker, uygun düzenleme için gerekli olan tarball / fat JAR'ların genişletilmiş bir sürümüdür.
Örneğin, 2014 yılında yayınlanan ve cevabınıza oldukça uygun şekilde başlıklandırılmış bir blog yayınından bazı argümanlar:
- Yeni teknolojilerin çevreye çok daha esnek enjeksiyonu
- test edilen son kodun teslim edilmesi ile son üretim sunucularında çalıştırılması arasında hala büyük bir acı noktası vardır. Docker, bu son adımı büyük ölçüde basitleştiriyor
- Docker, hangi Linux lezzetini kullanıyor olursanız olun eski işletim sistemini korumayı önemsiz kılar
Gönderen: https://thenewstack.io/why-you-should-care-about-docker/
Üretiminizi docker konteynerinde yürütüyorsanız, bu konteynerin, üzerinde çalışan uygulamayı oluşturan aynı geliştiriciler tarafından yapılması çok önemlidir. Hangi dış bağımlılığın gerekli olduğunu bilmek için başka kim daha iyi bir yer ...
Ayrıca boru hattı, özellikle docker görüntü oluşturma adımı olduğunda, bazen eksik olan bir dosya veya gereken bir lib olduğunda, CD sırasında herhangi bir adımda başarısız olabilir.
İş yerinde tüm geliştiricileri, uygulamalarına hizmet etmek için dockerfile'ı oluşturmak için temel bilgileri açıklayan tüm geliştiricileri tanıttık, ayrıca yalnızca bir ad ve bir dockerfile ekleyebilmek ve uygulaması otomatik olarak bir sonraki itme, onu çalıştıran teknolojiden bağımsız olarak
Docker hızlı başlatma, devOps ekibinin dağıtım seçiminde geliştiriciye rehberlik ettikten sonra (birçoğu gibi şeyleri bilmiyor alpine) bunu yapmak için gerçekten harika bir giriş .
Bizim işimiz onlara araçlara kolay erişim sağlamaktır, gerisini onlar bir şey yanlış olduğunda düzeltebilirler. Docker gerçekten geliştirme sürecinin bir parçası ve devOps ekibi onlara ihtiyaçlarımızla eşleşen ve yeterince kolay olan docker görüntüleri sağlıyor, bu nedenle yeni bir uygulama oluşturmak ve yardım almadan dağıtmak sadece birkaç dakika sürüyor.
Docker, geliştiricilerin onu kullanmaya ilgi duymasına yol açan birçok basın ve blog sözü alıyor. Bazı insanlar için yeni bir teknoloji ile oynamak ya da işlerin nasıl yürüdüğünü anlamak ilgi çekicidir. Diğerleri için, özgeçmişlerine anahtar kelimeler ekleme arzusu. Her iki durumda da, daha fazla geliştirici, işlerin nasıl çalıştığını ve nasıl dağıtıldığını daha sonra ne kadar az şaşırdıklarını bilir. Gördüğüm kadarıyla, buna önceden mevcut olan iyi bir ilgi var, bu yüzden daha fazla teşvik etmek o kadar zor olmamalı.
Test için VM'ler kullandıysanız, kapları kullanmayı deneyebilirsiniz ve docker aslında test için harika bir şeydir ve LXC yerine kullanımı çok daha basittir :)