Soru Docker nasıl bir sanal makineden farklı?


Tekrar okuyorum Docker belgeleri Docker ve tam bir VM arasındaki farkı anlamaya çalışmak. Tam dosya sistemi, izole ağ ortamı vb. Ağır olmaksızın nasıl yönetilir?

Yazılımı neden bir docker görüntüsüne yerleştiriyor (bu doğru bir terimse) sadece tutarlı bir üretim ortamına yayılmaktan daha kolay?


2921
2018-04-16 21:19


Menşei


Docker vs KVM performans analizi: bodenr.blogspot.com/2014/05/... - HDave
Görselleri arasında fark arıyorsanız - stackoverflow.com/questions/29096967/... - devesh-ahuja
Docker sanal bir makine değil - bir yapılandırma yönetim aracıdır. - aaa90210
@JagatveerSingh Düşünce, bu aynı soruya bir bağlantı olduğunu söylemeliyim. - Dan Nissenbaum
Yığın Taşması, programlama ve geliştirme soruları için bir sitedir. Bu soru konu dışı görünmektedir, çünkü programlama veya geliştirme ile ilgili değildir. Görmek Burada hangi konuları sorabilirim? Yardım Merkezi’nde belki Süper Kullanıcı veya Unix ve Linux Yığını Değişimi sormak için daha iyi bir yer olurdu. - jww


Cevaplar:


Docker aslında kullanılmış LinuX Konteynerler (LXC), ancak daha sonra runC (daha önce ... olarak bilinen libcontainer), ana bilgisayar ile aynı işletim sisteminde çalışır. Bu, çok sayıda ana işletim sistemi kaynağını paylaşmasına izin verir. Ayrıca, katmanlı bir dosya sistemi kullanır.aufs) ve ağları yönetir.

AuFS katmanlı bir dosya sistemidir, böylece birleştirilmiş salt okunur bir bölüm ve birleştirilen bir parça yazabilirsiniz. İşletim sisteminin ortak kısımları sadece okunabilir (ve tüm kaplarınız arasında paylaşılabilir) ve her konteynere yazma için kendi yuvasına verilebilir.

Yani, 1 GB konteyner resminizin olduğunu varsayalım; Tam bir VM kullanmak isteseniz, istediğiniz 1 GB kere x VM sayısına sahip olmanız gerekir. Docker ve AuFS ile 1 GB'lık büyüklüğü tüm kaplar arasında paylaşabilirsiniz ve 1000 konteyneriniz varsa, kapsayıcılar için yalnızca 1 GB'lık bir alanınız olabilir (hepsi aynı OS görüntüsünü çalıştırdıkları varsayılarak). .

Tam bir sanallaştırılmış sistem kendisine ayrılan kendi kaynak kümesini alır ve en az paylaşımı yapar. Daha fazla yalıtım elde edersiniz, ancak çok daha ağırdır (daha fazla kaynak gerektirir). Docker ile daha az yalıtım elde edersiniz, ancak konteynerler hafiftir (daha az kaynak gerektirir). Böylece bir kapsayıcıda binlerce kapsayıcıyı kolayca çalıştırabilirsiniz ve göz kırpmaz. Bunu Xen ile yapmayı deneyin, ve gerçekten büyük bir ev sahibi olmadığınız sürece, bunun mümkün olduğunu düşünmüyorum.

Tam sanallaştırılmış bir sistem genellikle başlamak için dakika sürer, Docker / LXC / runC kapsayıcılar saniyeler alır ve genellikle bir saniyeden daha az sürer.

Her bir sanallaştırılmış sistem türü için artıları ve eksileri vardır. Garantili kaynaklarla tam yalıtımı istiyorsanız, tam bir VM gitmek için yoldur. Sadece süreçleri birbirinden ayırmak ve makul bir büyüklükte bir ana bilgisayarda bir ton çalıştırmak istiyorsanız, o zaman Docker / LXC / runC gitmenin yolu gibi görünüyor.

Daha fazla bilgi için, check out bu blog gönderileri grubu LXC'nin nasıl çalıştığını açıklayan iyi bir iş.

Yazılımı neden bir docker görüntüsüne yerleştiriyor (bu doğru bir terimse) sadece tutarlı bir üretim ortamına yayılmaktan daha kolay?

Tutarlı bir üretim ortamının dağıtılması, yapıldığından daha kolay olduğu söylenir. Gibi araçlar kullanıyor olsanız bile Şef ve Kukla, her zaman işletim sistemi güncellemeleri ve ana bilgisayarlar ile ortamlar arasında değişen diğer şeyler vardır.

Docker, işletim sisteminizi paylaşılan bir görüntüye anlık görüntüleyebilmenizi sağlar ve diğer Docker ana bilgisayarlarına dağıtımı kolaylaştırır. Yerel olarak, dev, qa, prod, vb .: hepsi aynı görüntü. Bunu diğer araçlarla yapabilirsin, ama neredeyse kolay ya da hızlı değil.

Bu test için harika; Bir veritabanına bağlanmanız gereken binlerce testinizin olduğunu ve her bir testin veritabanının bozulmamış bir kopyasına ihtiyacı olduğunu ve verilerde değişiklik yapacağını varsayalım. Buna klasik yaklaşım, her testten sonra, özel kodla veya benzeri araçlarla veritabanının sıfırlanmasıdır. Uçuş yolu - Bu çok zaman alıcı olabilir ve testlerin seri olarak çalıştırılması gerektiği anlamına gelir. Bununla birlikte, Docker ile veritabanınızın bir görüntüsünü oluşturabilir ve her testte bir örnek çalıştırabilir ve tüm testleri paralel olarak çalıştırabilirsiniz, çünkü bunların hepsi veritabanının aynı anlık görüntüsüne karşı çalışacaklarını bilirsiniz. Testler paralel olarak ve Docker konteynerlerinde çalıştığı için, aynı kutuda aynı anda çalışabilir ve çok daha hızlı tamamlanabilir. Bunu tam bir VM ile yapmayı deneyin.

Yorumlardan ...

İlginç! Sanırım hala "işletim sistemi enstantane" kavramı ile kafam karıştı. Birisi, işletim sisteminin bir görüntüsünü oluşturmadan nasıl yapar?

Bakalım açıklayabilir miyim. Temel bir görüntü ile başlar ve sonra değişikliklerinizi yapın ve bu değişiklikleri docker kullanarak gerçekleştirin ve bir görüntü oluşturur. Bu görüntü sadece tabandaki farklılıkları içerir. Görüntünüzü çalıştırmak istediğinizde, aynı zamanda tabana da gereksinim duyarsınız ve katmanınızı katmanlı bir dosya sistemi kullanarak tablonun üstüne katlar: Yukarıda belirtildiği gibi, Docker AUFS kullanır. AUFS farklı katmanları birleştirir ve istediğiniz şeyi alırsınız; Sadece onu çalıştırman gerek. Daha fazla resim (katman) eklemeye devam edebilirsiniz ve sadece farkları kaydetmeye devam edecektir. Docker genellikle hazır görüntülerden kayıtNadiren tüm işletim sistemini "anlık" olarak kaydetmeniz gerekiyor.


2817
2018-04-16 22:35



Ken, bazı yerlerde OS ile çekirdeği birleştirir. Bir ana bilgisayardaki tüm kapsayıcılar aynı çekirdek altında çalışır, ancak OS dosyalarının geri kalanı konteyner başına benzersiz olabilir. - Andy
İlginç! Sanırım hala "işletim sistemi enstantane" kavramı ile kafam karıştı. Birisi, işletim sisteminin bir görüntüsünü oluşturmadan nasıl yapar? - zslayton
@ murtaza52 farklı dosya sistemleri için destek ekliyorlar, böylece Auf'ların gitmesi bir sorun olmamalı. 32 bit desteği ekleneceğinden emin değilsiniz, güçlü bir talep olduğunu düşünmeyin, bu yüzden öncelik listesinde düşüktür, ancak yanılıyor olabilirim. - Ken Cochrane
@Mike: ... kuşkusuz esinlenerek FreeBSD hapishaneleri  HISTORY The jail utility appeared in FreeBSD 4.0. - Stefan Paletta
@ Mike'ın, silinmiş gibi göründüğünden beri yanıtladığımızı merak edenler için, şu şudur: <Eksik olan tek şey, Linux Containers'ın gerçek bir ilham kaynağının bir klonu olduğu gerçeğidir. : Solaris Konteynerleri. 2004'te geri dönüş ... Bu, devrim niteliğindeki bir kavramdır ve gerçekten performanslı olan, uygun fiyatlı, barındırılan sanal makineleri yapmak için harika ve harika bir yoldur. Joyent, farkında olduğum ilk oldu ... - Jeffrey 'jf' Lim


İyi cevaplar. Sadece VM'ye ait bir kapsayıcı görüntü temsili almak için, aşağıdaki şeye bir göz atın.

enter image description here

Kaynak: https://www.docker.com/what-container#/package_software


342
2017-10-14 18:02



<grev> Anladığım kadarıyla, "docker motoru" nun üstünde bir paylaşılan linux çekirdeği olmalı. Daha sonra ortak paylaşımlı kutuları / lib'leri bile vardır. İlk olarak, her bir konteynere özgü kutu / libs ve uygulamalar gelir. Yanılıyorsam lütfen beni düzeltin. </ Strike> Yanılmışım. Docker görüntüleri çekirdeği ana bilgisayarla paylaşır, bkz. superuser.com/questions/889472/.... Bununla birlikte, konteynerlerin sendika dosya sistemini göstermek için, docker motorunun hemen üzerinde paylaşılan bir libs / kutu katmanı olabilir. - Betamos
Yukarıdaki resim ile ilgili bir problemim var, çünkü Hipervizör çıplak metal / altyapı üzerine kurulabilir ancak Docket (henüz) yapamıyor - reza
@reza, Hypervisor'un Bare metal üzerine kurulabileceğini kabul ediyorum, ancak bu noktada Docker, uygulamaların kapsayıcılığı ve bazı senaryolar için gerekli olmayan / uygulanacak sanallaştırmanın nasıl sınırlandırılacağı veya önleneceği konusunda tavsiye edilir. Ken Cochrane bunu daha ayrıntılı olarak açıklıyor stackoverflow.com/a/16048358/2478933 - manu97
Bu ne olduğunu açıklığa kavuşturmuyor Docker Motoru. Çok soyut resimler. - kyb
Konteynır ile çekirdeği arasında "Docker Engine" tabakası yok, konteyner sadece çekirdeğindeki özel ayarlarla (isim alanları, gruplar, vb.) Oluşan bir süreçtir. - Paweł Prażak


Sanallaştırma ve kapların düşük seviyede nasıl çalıştığını anlamak yardımcı olabilir. Bu çok şeyleri temizleyecektir.

Not: Aşağıda açıklamanın birazını basitleştiriyorum. Daha fazla bilgi için referanslara bakın.

Sanallaştırma düşük seviyede nasıl çalışır?

Bu durumda VM yöneticisi, CPU ringini (veya daha yeni CPU'larda "root mode") devralmakta ve konuk OS'nin kendi donanımına sahip olduğu yanılsaması yaratmak için konuk OS tarafından yapılan tüm ayrıcalıklı çağrıları kesmektedir. Eğlenceli gerçek: 1998'den önce x86 mimarisinde bunu başarmanın imkansız olduğu düşünülüyordu, çünkü bu tür bir müdahalede bulunmanın bir yolu yoktu. VMWare'deki millet ilk vardı Bunu gerçekleştirmek için konuk işletim sisteminin ayrıcalıklı çağrıları için bellekte çalıştırılabilir baytları yeniden yazma fikri vardı.

Net etki, sanallaştırmanın aynı donanım üzerinde iki tamamen farklı işletim sistemi çalıştırmanıza izin vermesidir. Her konuk işletim sistemi tüm önyükleme, yükleme çekirdeği vb. İşlemlerini gerçekleştirir. Çok sıkı bir güvenliğe sahip olabilirsiniz. Örneğin, işletim sistemi işletim sistemi işletim sistemi işletim sistemine veya diğer konuklara tam erişim sağlayamaz ve karışıklık yaratamaz.

Kaplar düşük seviyede nasıl çalışır?

Etrafında 2006Google’daki bazı çalışanlar dahil olmak üzere insanlar, yeni çekirdek düzeyinde özellik deniyor ad (Ancak fikir uzun önce FreeBSD'de var). İşletim Sisteminin bir işlevi, ağ ve disk gibi global kaynakların işlemlere paylaşılmasına izin vermektir. Ya bu küresel kaynaklar ad alanlarına sarılmışlarsa, yalnızca aynı ad alanında çalışan süreçlere görünürlerse ne olur? Diyelim ki, bir disk parçası alabilir ve bunu X adında yazabilir ve sonra Y adında çalışan işlemleri göremez veya erişemez. Benzer şekilde, X ad alanındaki süreçler, ad alanı Y'ye ayrılan bellekte herhangi bir şeye erişemez. Elbette X'deki süreçler, ad alanı Y'deki işlemleri göremez veya konuşamaz. Bu, küresel kaynaklar için bir çeşit sanallaştırma ve yalıtım sağlar. Bu docker nasıl çalışır: Her konteyner kendi isim alanında çalışır ancak tam olarak kullanır aynı diğer tüm kaplar gibi çekirdek. Çekirdek, çekirdeğin sürece atanan ad alanını bilmesi ve API çağrıları sırasında işlemin yalnızca kendi ad alanındaki kaynakları erişebildiğinden emin olmasını sağlar.

Kapsayıcılar ve VM'nin sınırlamaları şu an açık olmalı: Sanal makinelerde olduğu gibi kaplarda tamamen farklı işletim sistemi çalıştıramazsınız. Sen yine de kutu Aynı çekirdeği paylaştıkları için Linux'un farklı dağıtımlarını yürütebilirler. İzolasyon seviyesi, VM'de olduğu kadar güçlü değildir. Aslında, erken uygulamalarda ana bilgisayarı devralmak için "misafir" konteynerinin bir yolu vardı. Ayrıca yeni kapsayıcıyı yüklediğinizde, işletim sisteminin tüm yeni kopyasının sanal makinede olduğu gibi başlayamadığını görebilirsiniz. Tüm kaplar aynı çekirdeği paylaş. Bu yüzden konteynerler hafiftir. Ayrıca, VM'den farklı olarak, işletim sisteminin yeni bir kopyasını çalıştırmıyor olmamız nedeniyle, önemli miktarda bellek kapsayıcısına önceden ayırmanız gerekmez. Bu, tek bir işletim sistemi üzerinde binlerce konteynerin çalıştırılmasını sağlarken, kendi VM'sinde ayrı bir işletim sistemi kopyasını çalıştırıyor olsaydı bunları yapmak mümkün olmayabilirdi.


298
2018-01-13 01:49



Vay, düşük seviye açıklama (ve tarihsel gerçekler) için teşekkürler. Onu arıyordum ve yukarıda bulunamadı. Ne demek istiyorsunuz "Linux'un farklı bölümlerini çalıştırabilirsiniz çünkü aynı çekirdeği paylaşıyorlar."? Bir misafir konteynerinin aynı Linux çekirdeği sürümüne sahip olması ya da önemli olmadığını mı söylüyorsunuz? Ne olursa olsun, bir OS komutunu konukta çağırırsam ancak sadece konuk çekirdeğinde desteklenirse fark etmez. Ya da örneğin konuk çekirdeğinde sabitlenen ancak ana bilgisayar çekirdeğinde bulunmayan bir hata. Bütün misafirler bu hatayı tezahür eder, değil mi? Konuklar yamalı olsalar bile. - Jeach
@Jeach: kapsayıcılar kendi çekirdeklerine sahip değiller, ana bilgisayarlardan birini paylaşıyorlar / kullanıyorlar. Yani aynı makinede / VM'de farklı çekirdeklere ihtiyaç duyan kapları çalıştıramazsınız. - user276648
Soru: Google'ın çalışanlarının bir kısmının, 1996 yıllında kernel özelliği olan ad alanında yer aldığını yazıyorsunuz. Ancak Google 1998'e kadar kurulmuş değil. Daha sonra Google çalışanları olmaya devam edecek insanlar mı demek istediniz? - Martin Gjaldbaek
@martin - 2006 yılının farkına vardığın için teşekkürler. Ayrıca, Linux'tan beri 2002'den beri farklı tipte isim alanlarının olduğunu söylemeliyim ama 2006'da kapsayıcılığa zemin hazırlayan bir işti. Yanıtı referansla güncelledim. - ShitalShah
+1 Bu, diğer cevaplar bir miktar açıklama sunarken, bu işaretin belirgin bir cevabı olmalı, sadece bu altta bulunan düşük seviyeli bir açıklama, bu tekniğin nasıl çalıştığını, 'kendi adlarında gruplandırılmış süreçler = kapsayıcı' olabilir. Çok teşekkür ederim, şimdi anladım. - Tino Mclaren


Ken Cochrane’nin cevabını seviyorum.

Ancak, burada ayrıntılı olarak ele alınmayan ek bir bakış açısı eklemek istiyorum. Benim görüşüme göre Docker bütün süreçte farklıdır. VM'lerin aksine, Docker, yalnızca donanımın en iyi kaynak paylaşımı hakkında değildir (ayrıca), paketleme uygulaması için bir "sistem" sağlar (bir Microservices kümesi olarak tercih edilir, ancak zorunlu değildir).

Bana göre, bir tarafta rpm, debian paketleri, maven, npm + git ve Kukla, VMWare, Xen gibi Ops araçları gibi Geliştirici Odaklı araçlar arasındaki boşluğa uyuyor ...

Yazılımı neden bir docker görüntüsüne yerleştiriyor (bu doğru bir terimse) sadece tutarlı bir üretim ortamına yayılmaktan daha kolay?

Sorunuz, tutarlı bir üretim ortamı varsayar. Ama tutarlı tutmak nasıl?  Sunucu ve uygulamaların bazı miktarlarını (> 10), boru hattındaki aşamaları düşünün. Bunu senkronize etmek için Kukla, Şef veya kendi yetkilendirme komut dosyalarınız, yayınlanmamış kurallarınız ve / veya belgeleriniz gibi bir şey kullanmaya başlayacaksınız ... Teorik olarak sunucular sonsuza dek çalışabilir ve tamamen tutarlı ve güncel tutulabilirler. Uygulama, bir sunucunun yapılandırmasını tamamen yönetemediğinden, yapılandırma sapması ve çalışan sunucularda beklenmedik değişiklikler için önemli bir kapsam vardır.

Yani bunu önlemek için bilinen bir model var, sözde Immutable Sunucu. Ancak değişmez sunucu modeli sevilmiyordu. Çoğunlukla VM'lerin sınırlamaları nedeniyle Docker'dan önce kullanıldı. Birkaç Gigabyte büyük resimle uğraşırken, bu büyük görüntüleri hareket ettirerek, sadece uygulamadaki bazı alanları değiştirmek için çok çok zahmetliydi. Anlaşılabilir ...

Bir Docker ekosistemi ile, "küçük değişiklikler" (Teşekkürler aufs ve Registry) üzerinde Gigabyte'lar arasında dolaşmanız gerekmeyecek ve uygulamaları çalışma zamanında bir Docker konteynerine paketleyerek performans kaybetme konusunda endişelenmenize gerek yok. Bu resmin sürümleri hakkında endişelenmenize gerek yok. Son olarak linux dizüstü bilgisayarınızda bile karmaşık üretim ortamlarını bile çoğaltabilirsiniz (durumunuzda çalışmazsa beni arama);)

Ve tabii ki, sanal makinelerde docker konteynerlerini başlatabilirsiniz (bu iyi bir fikir). Sunucu düzeyinde provizyonunuzu VM düzeyinde azaltın. Yukarıdakilerin hepsi Docker tarafından yönetilebilir.

Not; Bu arada Docker, LXC yerine kendi "libcontainer" uygulamasını kullanıyor. Ama LXC hala kullanılabilir.


280
2017-09-19 16:21



Git, rpm ve dpkg gibi bir araç grubuna gitmeyi tuhaf görünüyor. Bunu belirtiyorum çünkü sürüm kontrol sistemlerini git bir dağıtım / paketleme aracı olarak kullanmak gibi bir çok karışıklık kaynağı olarak görüyorum. - blitzen9872
o yanlış değil, git paket yönetimi için kullanılabilir, örneğin bower, temelde git etiketlerini indirmek için bir fantezi klibi. - roo2
Konteynerlerde ambalajlama uygulamaları ilginç ve geçerli bir yaklaşımdır. Ancak eğer bunu docker'da paketlediyseniz, bu bağımlılık veya paylaşılan kütüphaneler için doğrudan bir destek olmayacağından, bu durum aşırı olacaktır. Bu, tam olarak Ubuntu Snap ve Redhat gibi Flatpak gibi yeni ambalaj teknolojilerinin elde etmeye çalıştığı şey. Benim düşünceme göre, bu paketleme teknolojilerinden biri, Linux'ta paketlemenin geleceğini ve kazanacağını. - yosefrow


Docker bir sanallaştırma metodolojisi değildir. Kapsayıcı tabanlı sanallaştırma veya işletim sistemi düzeyinde sanallaştırmayı gerçekte uygulayan diğer araçlara dayanır. Bunun için Docker başlangıçta LXC sürücüsü kullanıyordu, daha sonra şimdi runc olarak adlandırılan libcontainer'a taşındı. Docker, öncelikle uygulama konteynerleri içindeki uygulamaların dağıtımını otomatikleştirmeye odaklanmaktadır. Uygulama kapları, tek bir hizmeti paketlemek ve çalıştırmak için tasarlanırken, sistem kapsayıcıları sanal makineler gibi birden çok işlemi çalıştırmak için tasarlanmıştır. Bu nedenle, Docker konteynerleştirilmiş sistemlerde bir konteyner yönetimi veya uygulama dağıtım aracı olarak kabul edilir.

Diğer sanallaştırmadan nasıl farklı olduğunu bilmek için sanallaştırma ve türlerini inceleyelim. O zaman, orada ne fark olduğunu anlamak daha kolay olurdu.

sanallaştırma

Tasarlanan biçiminde, çoklu uygulamaların aynı anda çalışmasına izin vermek için, mantıksal olarak ana çerçevelerin bölünmesi için bir yöntem olarak düşünülmüştür. Bununla birlikte, şirketler ve açık kaynak toplulukları, ayrıcalıklı talimatları bir şekilde ele alma ve tek bir x86 tabanlı sistem üzerinde birden fazla işletim sisteminin aynı anda çalıştırılmasına izin verebildikleri zaman, senaryo büyük ölçüde değişmiştir.

Hiper

Hiper yönetici, konuk sanal makinelerin çalıştığı sanal ortamı yaratmayı idare eder. Misafir sistemlerini denetler ve kaynakların gerektiğinde misafirlere tahsis edilmesini sağlar. Hiper yönetici, fiziksel makine ile sanal makineler arasında oturur ve sanal makinelere sanallaştırma hizmetleri sağlar. Bunu gerçekleştirmek için, konuk işletim sistemi işlemlerini sanal makinelerde engeller ve ana makinenin işletim sistemindeki işlemi öykünür.

Öncelikle bulutta sanallaştırma teknolojilerinin hızlı gelişimi, Xen, VMware Player, KVM, vb. Gibi hipervizörlerin yardımıyla tek bir fiziksel sunucu üzerinde birden fazla sanal sunucunun oluşturulmasına izin vererek sanallaştırma kullanımını daha da ileri götürdü. Intel VT ve AMD-V gibi emtia işlemcilerine donanım desteğinin dahil edilmesi.

Sanallaştırma Türleri

Sanallaştırma yöntemi, donanımın bir misafir işletim sistemine nasıl taklit edildiğine ve konuk işletim ortamını öykünmesine dayalı olarak kategorilere ayrılabilir. Öncelikle, üç tip sanallaştırma vardır:

  • emülasyon
  • sanallaştırma
  • Kapsayıcı tabanlı sanallaştırma

emülasyon

Tam sanallaştırma olarak da bilinen öykünme, sanal makine işletim sistemi çekirdeğini tamamen yazılım içinde çalıştırır. Bu tipte kullanılan hiper yönetici, Tip 2 hiper yönetici olarak bilinir. Konuk işletim sistemi çekirdek kodunu yazılım yönergelerine çevirmekten sorumlu ana bilgisayar işletim sisteminin üstüne kurulmuştur. Çeviri tamamen yazılımda yapılır ve donanım katılımı gerektirmez. Emülasyon, taklit edilen ortamı destekleyen herhangi bir değiştirilmemiş işletim sistemini çalıştırmayı mümkün kılar. Bu tür bir sanallaştırmanın olumsuz tarafı, diğer sanallaştırma türlerine kıyasla performansta düşüşe yol açan ek sistem kaynağı yüküdür.

Emulation

Bu kategorideki örnekler arasında VMware Player, VirtualBox, QEMU, Bochs, Parallels vb.

sanallaştırma

Tip 1 hiper yönetici olarak da bilinen paravirtualizasyon, doğrudan donanım veya “çıplak metal” üzerinde çalışır ve sanallaştırma hizmetlerini doğrudan üzerinde çalışan sanal makinelere sağlar. En iyi performansı elde etmek için işletim sisteminin, sanallaştırılmış donanımın ve gerçek donanımın birlikte çalışmasına yardımcı olur. Bu hipervizörler tipik olarak oldukça küçük bir ayak izine sahiptir ve kendi başlarına kapsamlı kaynaklar gerektirmez.

Bu kategorideki örnekler Xen, KVM vb.

Paravirtualization

Kapsayıcı tabanlı sanallaştırma

Kapsayıcı tabanlı sanallaştırma, işletim sistemi düzeyinde sanallaştırma olarak da bilinir, tek bir işletim sistemi çekirdeğinde birden çok yalıtılmış yürütme sağlar. Mümkün olan en iyi performansa ve yoğunluğa sahiptir ve dinamik kaynak yönetimine sahiptir. Bu tür bir sanallaştırma tarafından sağlanan yalıtılmış sanal yürütme ortamı konteynır olarak adlandırılır ve izlenen bir süreçler grubu olarak görülebilir.

Container-based virtualization

Bir kap kavramı, Linux çekirdeği sürüm 2.6.24'e eklenen ad alanları ile mümkün hale getirildi. Kap, kimliğini her işleme ekler ve her sistem çağrısına yeni erişim denetimi denetimleri ekler. Tarafından erişilir klon() Önceden global ad alanlarının ayrı örneklerini oluşturmaya izin veren sistem çağrısı.

Ad alanları birçok farklı şekilde kullanılabilir, ancak en yaygın yaklaşım, kapsayıcı dışındaki nesnelere görünürlük veya erişime sahip olmayan yalıtılmış bir kap oluşturmaktır. Konteynerin içinde çalışan süreçler, normal bir Linux sistemi üzerinde çalışıyor gibi görünmesine rağmen, diğer kuşaklar için olduğu gibi, diğer ad alanlarında yer alan süreçlerle altta yatan çekirdeği paylaşıyorlar. Örneğin, ad alanlarını kullanırken, kapsayıcının içindeki kök kullanıcı, ek güvenlik ekleyerek kapsayıcı dışındaki kök olarak ele alınmaz.

Konteynır tabanlı sanallaştırmayı etkinleştirmek için bir sonraki ana bileşen olan Linux Denetim Grupları (cgroups) alt sistemi, işlemleri gruplandırmak ve toplu kaynak tüketimini yönetmek için kullanılır. Genellikle, kapların bellek ve CPU tüketimini sınırlamak için kullanılır. Konteynerleştirilmiş bir Linux sistemi yalnızca bir çekirdeğe sahip olduğu ve çekirdeğin konteynırlara tam olarak görülebildiği için, yalnızca bir kaynak tahsisi ve çizelgeleme seviyesi vardır.

LXC, LXD, systemd-nspawn, lmctfy, Warden, Linux-VServer, OpenVZ, Docker gibi Linux konteynırları için çeşitli yönetim araçları mevcuttur.

Sanal Makineler vs Konteynerler

Bir sanal makineden farklı olarak, bir konteynerin işletim sistemi çekirdeğini önyüklemesi gerekmez, böylece kaplar bir saniyeden daha kısa sürede oluşturulabilir. Bu özellik, kapsayıcı sanallaştırmayı diğer sanallaştırma yaklaşımlarından benzersiz ve istenen hale getirir.

Konteynere dayalı sanallaştırma, ana makineye çok az miktarda ek yük getirdiğinden veya hiç bir ek yük getirmediğinden, kapsayıcı tabanlı sanallaştırmanın neredeyse yerel performansa sahip olması

Kapsayıcı sanallaştırma için, diğer sanallaştırmadan farklı olarak ek bir yazılıma gerek yoktur.

Bir ana makinedeki tüm kaplar, ana makinenin zamanlayıcısını, ekstra kaynak gereksinimini karşılar.

Kapsayıcı durumları (Docker veya LXC görüntüleri), sanal makine görüntüleri ile karşılaştırıldığında boyut bakımından küçüktür, bu nedenle kap görüntülerinin dağıtılması kolaydır.

Konteynerlerde kaynak yönetimi, gruplar halinde gerçekleştirilir. Gruplar, kapsayıcıların kendilerine ayrıldığından daha fazla kaynak kullanmasına izin vermez. Ancak, şu an itibariyle, ana makinenin tüm kaynakları sanal makinelerde görülebilir, ancak kullanılamaz. Bu koşarak gerçekleştirilebilir top veya htop konteynerler ve ana makinede aynı anda. Tüm ortamlardaki çıktı benzer görünecektir.


124
2018-04-02 00:55



Çok güzel cevap. Bu diyagramları nereden aldığınızı sorabilir miyim? Orijinal makale / kitap, yani. - Harry
Google Çizimler'i kullanarak bu diyagramları oluşturdum. Google Çizimlerim hesabımda hala var. - Ashish Bista
Ve metin? Bu cevap için metnin orijinal kaynağı nedir? - L0j1k
@Sheljohn Bu cevabın ilk versiyonu, herhangi bir atıfta bulunulmadan başka bir kaynak sözdiziminden kopyalandı. - L0j1k
@AshishBista Başka bir yerden verbatim alınan metni kullanacaksanız kaynağı öznitelirtmeniz / bağlamanız gerekir. - L0j1k


Bu yazı ile VM'ler ve LXC'ler arasında bazı farklar çizeceğiz. Önce onları tanımlayalım.

VM:

Bir sanal makine, fiziksel bir bilgi işlem ortamını öykünür, ancak CPU, bellek, sabit disk, ağ ve diğer donanım kaynaklarına yönelik talepler, bu istekleri temeldeki fiziksel donanıma çeviren bir sanallaştırma katmanı tarafından yönetilir.

Bu bağlamda VM, konuk olarak çalıştığı ortam konuk olarak adlandırılırken Misafir olarak adlandırılır.

LXCs:

Linux Containers (LXC), bir kontrol ana bilgisayarında (LXC ana bilgisayarı) birden fazla izole edilmiş Linux kapsayıcıyı çalıştırmayı mümkün kılan sistem düzeyi yetenekleridir. Linux Konteynerler, sanal makinelere gerek duymadıklarından sanal makinelere hafif bir alternatif olarak hizmet ederler. Virtualbox, KVM, Xen vb.

Şimdi Alan (Zach Galifianakis- Hangover serisinden) tarafından uyuşturulmadığı ve geçen sene Vegas'ta bulunmadığınız sürece, Linux konteynırları teknolojisine yönelik büyük bir fırsata karşı oldukça dikkatli olursunuz ve eğer belirli bir kapsayıcı olursam Son birkaç ay içinde dünya çapında bir vızıltı yaratan proje - Docker, bulut bilişim ortamlarının sanal makineleri (VM'ler) terk etmesi ve daha düşük performansları ve daha iyi performansları nedeniyle bunları kaplarla değiştirmesi gibi bazı yankı uyandıran fikirlere yol açıyor.

Ama büyük soru şu ki, bu mümkün mü?

a. LXC'ler bir Linux örneğine kadar uzanır. Linux'un farklı lezzetleri olabilir (örneğin CentOS ana bilgisayarında bir Ubuntu konteynırı, ama yine de Linux). Aynı şekilde, Windows tabanlı konteynırlar, sanal makinelere baktığımızda, daha geniş bir kapsama sahip olduklarından hipervizörler Linux veya Windows işletim sistemleriyle sınırlı değilsiniz.

b. LXC'ler düşük genel giderlere sahiptir ve VM'lere kıyasla daha iyi performansa sahiptir. Araçlar LXC teknolojisinin omuzları üzerine inşa edilen Docker, geliştiricilere uygulamalarını yürütmek için bir platform sağladı ve aynı zamanda, aynı kapsayıcıyı üretim kaplarına veya veri merkezlerine dağıtmasına olanak tanıyacak bir araçla insanları güçlendirdi. Bir uygulamayı çalıştıran bir geliştirici, bir uygulamayı önyükleme ve test etme ile bu uygulamayı sorunsuz bir şekilde çalıştıran bir operasyoncu kişi arasındaki deneyimi yaşatmaya çalışır, çünkü DevOps'un tüm sürtünmesinin yattığı ve amacı bu siloları parçalamaktır.

Bu nedenle en iyi yaklaşım, bulut altyapısı sağlayıcılarının VM'lerin ve LXC'nin uygun bir şekilde kullanılmasını savunmalarıdır, çünkü bunların her biri belirli iş yüklerini ve senaryoları ele almak için uygundur.

VM'leri terk etmek şu an itibariyle pratik değil. Dolayısıyla, hem VM'lerin hem de LXC'lerin kendi bireysel varoluşu ve önemleri vardır.


118
2017-08-26 07:46



Yukarıdaki "b" bölümünüz, Docker'ların teknolojiyle ilgili söylediklerinin aynısı. Bu gelişmeyi yapmak anlamına geliyor ve dağıtım görevleri daha kolay. Ve bir dev ve sysop olarak deneyimlerime dayanarak, kabul etmeliyim. - WineSoaked
Bu oldukça soyut bir cevap. Docker kullanıldığında / kullanılmadığında kullanım durumlarına ihtiyacımız var. Soru bu. Herkes Docker'ın neye benzediğini bulabilir, ancak gerçek senaryolarda sadece birkaçı açıklayabilir. - Ivan Voroshilin
lütfen "a" bölümünü netleştirebilir misiniz? Dil çok açık değil. - aamir
Docker artık LXC'ye bağımlı olmadığı için windows dünyasına getiriliyor: blogs.msdn.com/b/nzdev/archive/2015/06/02/... cevapları yanlış anlamış olursam lütfen beni düzeltin - bubakazouba
Anlamakta zorlanıyorum "(örneğin, bir Centos ana bilgisayarında bir Ubuntu konteyneri ama yine de Linux)" kapların bir kısmı. Anladığım şekilde, kapsayıcılar ana bilgisayar çekirdeğini paylaşıyor. Örneğin, Linux çekirdeği 4.6 çalıştıran bir ana makine sanal makinem varsa, birkaç konuk VM'nin Linux çekirdeği 2.4, 2.6, 3.2, 4.1 ve 4.4. Bu çekirdeğe özgü komutları yürütürsem, konuk çekirdeğinin davranışını (ve ana bilgisayarı değil) alırım. Ama eğer konuk VM'miz şimdi konteynırsa, çalıştırılan komut ana bilgisayar çekirdeği tarafından belirlenir mi? - Jeach


Buradaki cevapların çoğu sanal makineler hakkında konuşuyor. Bu soruya, Docker'ı kullanmanın son birkaç yılı boyunca bana en çok yardımcı olan bir cevap vereceğim. Bu:

Docker, sanal bir makine değil, bir süreci çalıştırmak için sadece bir fantezi yoludur.

Şimdi, bunun ne anlama geldiği hakkında biraz daha açıklayayım. Sanal makineler kendi canavarlarıdır. Ne olduğunu açıklamak istiyorum Liman işçisi Bunu, bir sanal makinenin ne olduğunu açıklamaktan daha fazlasını anlamanıza yardımcı olacak. Özellikle, burada "sanal makine" dediğinde tam olarak ne demek istediğini söyleyen çok iyi cevaplar olduğu için. Yani...

Bir Docker konteyneri sadece kullanarak bölümlendirilmiş bir süreçtir (ve çocukları) cgroups işlemlerin geri kalanından ana sistem sisteminin çekirdeği içinde. Docker konteyner işlemlerinizi çalıştırarak gerçekten görebilirsiniz. ps aux ana bilgisayarda. Örneğin, başlangıç apache2 "bir kapta" sadece yeni başlıyor apache2 ev sahibi üzerinde özel bir süreç olarak. Sadece makine üzerindeki diğer işlemlerden bölümlendirildi. Kaplarınızın konteynerize sürecinizin ömrü boyunca mevcut olmadığını unutmayın. İşleminiz öldüğünde, konteyneriniz ölür. Bunun nedeni Docker'ın yerini almasıdır. pid 1 Başvurunuzla birlikte kabınızın içindepid 1 normalde init sistemidir). Bu son nokta hakkında pid 1 çok önemli.

Bu konteyner işlemlerinin her biri tarafından kullanılan dosya sistemi kadarıyla, Docker kullanır unionfsgeri yüklenen görüntüler, docker pull ubuntu. Her "görüntü" yalnızca bir dizi katman ve ilgili meta verilerdir. Katman kavramı burada çok önemlidir. Her katman, altındaki katmanın bir değişimidir. Örneğin, Docker dosyanızda bir Docker kabı oluştururken bir dosyayı sildiğinizde, aslında "bu dosya silindi" yazan son katmanın üstünde bir katman yaratıyorsunuz. Bu arada, büyük bir dosyayı dosya sisteminizden silebilmeniz için bu sebepten dolayı, görüntü hala aynı miktarda disk alanı kaplıyor. Dosya hala mevcut olanın altındaki katmanlarda var. Katmanların kendileri sadece dosyaların tarlalarıdır. Bunu test edebilirsiniz docker save --output /tmp/ubuntu.tar ubuntuve sonra cd /tmp && tar xvf ubuntu.tar. Sonra etrafa bir göz atabilirsin. Uzun hashlar gibi görünen tüm dizinler aslında tek tek katmanlardır. Her biri dosya içerir (layer.tar) ve meta veriler (json) ilgili katman hakkında bilgi. Bu katmanlar, orijinal halinin "üstünde" bir katman olarak kaydedilen dosya sistemindeki değişiklikleri açıklar. "Mevcut" verileri okurken, dosya sistemi verileri en üstteki değişiklik katmanlarına bakıyormuş gibi okur. Bu yüzden dosya, "önceki" katmanlarda hala var olsa bile silinmiş gibi görünüyor, çünkü dosya sistemi yalnızca en üst katmanlara bakıyor. Bu, her kapsayıcının en üst katmanlarındaki dosya sistemine bazı önemli değişiklikler olmuş olsa bile, tamamen farklı kapların dosya sistemi katmanlarını paylaşmasına izin verir. Bu, kaplarınız kendi temel görüntü katmanlarını paylaştığında size bir ton disk alanı kazandırabilir. Ancak, ana bilgisayar sistemindeki dizinleri ve dosyaları kapsayıcılarınızla kapsayıcınıza bağladığınızda, bu birimler UnionFS'yi "baypas eder", böylece değişiklikler katmanlarda depolanmaz.

Docker'da ağ, bir ethernet köprüsü kullanılarak elde edilir ( docker0 ana bilgisayarda) ve ana bilgisayardaki her kapsayıcı için sanal arabirimler. Sanal bir alt ağ oluşturur. docker0 Konteyneriniz birbirleri arasında "birbirleriyle" iletişim kurarlar. Kapsayıcınız için özel alt ağlar oluşturma ve doğrudan erişim için kapsayıcınız için ana bilgisayar ağının yığınını "paylaşma" yeteneği dahil olmak üzere burada ağ oluşturmak için birçok seçenek vardır.

Docker çok hızlı hareket ediyor. Onun belgeleme Gördüğüm en iyi belgelerden bazıları. Genel olarak iyi yazılmış, özlü ve doğrudur. Daha fazla bilgi için mevcut belgeleri kontrol etmenizi ve çevrimiçi olarak okuduğunuz, Yığın Taşması dahil olmak üzere belgelere güvenmenizi tavsiye ederim. Belirli sorularınız varsa, katılmanızı öneririm #docker Freenode IRC üzerinde ve orada soran (hatta Freenode's kullanabilirsiniz webchat bunun için!).


91
2018-04-04 02:35



"Docker, sanal bir makine değil, bir süreci çalıştırmak için sadece süslü bir yoldur." Bu harika bir özet, teşekkürler! - mkorman
Teşekkürler! Bunun için kredi programmerq için dışarı gidiyor #docker Freenode IRC'de kanal. - L0j1k
Bu harika bir cevap. Ben benzetmeyi beğendim. - Teoman shipahi


Docker, bir uygulamayı tüm bağımlılıkları ile kapsülleyen bir sanallaştırıcı, bir O.S. Normalde bir çıplak metal makinede çalışabilen herhangi bir uygulamayı çalıştırabilir.


57
2017-08-27 18:25



LXC'yi öğreniyorum, yanılıyorsam düzeltin, ama bir çeşit virtualenv olabilir mi? ama açıkçası daha geniş, sadece söylemek için python için circunscripsc - NeoVe
Bu cevabı en çok beğendim. Bu basit ve doğrudan doğruya gider. Şimdi, WHAT LXC ve Virtualizer'ların yapabilecekleri temel bir anlayışa sahip olması, diğer okumalardan elde edilen detayların mantıklı olacaktır. - Phil
@Phil İlk önce ayrıntılı cevapları okuduktan sonra yaptı. - johnny


İkisi de çok farklı. Docker hafiftir ve LXC / libcontainer (çekirdek ad boşluğu ve gruplarına dayanır) kullanır ve hiper yönetici, KVM gibi makine / donanım emülasyonu yoktur. Xen ağır olan.

Docker ve LXC, kum havuzu, konteynerizasyon ve kaynak yalıtımı için daha fazla anlam ifade ediyor. IPC, NS (mount), network, PID, UTS, vb. İçin isim alanı sağlayan ana işletim sistemi (sadece Linux çekirdeği) klon API'sini kullanır.

Bellek, G / Ç, CPU vb. Hakkında ne düşünüyorsunuz? Bu, belirli kaynaklarla (CPU, bellek, vb.) Spesifikasyon / kısıtlama ile gruplar oluşturabileceğiniz ve süreçlerinizi oraya koyabileceğiniz grupların kullanımı ile kontrol edilir. LXC'nin üstünde, Docker bir depolama arka planı (http://www.projectatomic.io/docs/filesystems/Örneğin, katmanları ekleyebileceğiniz ve farklı montaj ad alanları arasında katmanları paylaşabileceğiniz sendika mount dosya sistemi.

Bu, temel görüntülerin tipik olarak salt okunur olduğu ve sadece kapsayıcıda bir şeyleri okuma-yazma bölümüne yazacak bir şey değiştirdiğinde (a.k.a. yazma üzerine kopya) güçlü bir özelliktir. Ayrıca kayıt ve görüntülerin versiyonlanması gibi birçok başka sarıcı sağlar.

Normal LXC ile bazı rootfs'larla gelmeniz veya rootfs'ları paylaşmanız ve paylaşmanız gerektiğinde ve değişikliklerin diğer kapsayıcılara yansıtılması gerekir. Bu eklenen özelliklerin çoğu nedeniyle, Docker LXC'den daha popüler. LXC, ağ ve UI gibi harici varlıklara maruz kalan işlemler etrafında güvenlik uygulamak için gömülü ortamlarda popülerdir. Docker, tutarlı üretim ortamının bekleneceği bulut çok kiracılı ortamlarda popülerdir.

Normal bir VM (örneğin, VirtualBox ve VMware) bir hiper yönetici kullanır ve ilgili teknolojiler ya ilk işletim sistemi (ana bilgisayar işletim sistemi veya konuk OS 0) için ilk katman olan ana bilgisayar yazılımı veya ana bilgisayar işletim sistemi üzerinde çalışan bir yazılım içerir. Konuk işletim sistemlerine CPU, USB / aksesuar, bellek, ağ, vb. donanım öykünmesi sağlar. VM'ler hala yüksek güvenlikli çok kiracılı ortamlarda popülerdir.

Docker / LXC, normal VM'lerin en az 2 GB bellek gereksinimine sahip olduğu gibi, herhangi bir ucuz donanımda (1 GB'den daha az bellek, daha yeni çekirdeğiniz olduğu sürece de) kullanılabilir. . Ancak, ana bilgisayar işletim sistemindeki Docker desteği, Windows gibi işletim sistemlerinde (Kasım 2014'ten itibaren) mevcut değildir; burada VM'lerin türleri Windows, Linux ve Mac'lerde çalışabilir.

İşte docker / rightscale bir pic: Here is a pic from rightscale


45
2017-11-03 17:44





1. Hafif

Bu, birçok docker öğrencisinin muhtemelen ilk izlenimidir.

İlk olarak, docker görüntüleri genellikle VM görüntülerinden daha küçüktür, oluşturulmasını, kopyalanmasını ve paylaşılmasını kolaylaştırır.

İkincisi, VM saniye içinde başlarken Docker konteynerleri birkaç milisaniyede başlayabilir.

2. Katmanlı Dosya Sistemi

Bu Docker'ın bir diğer önemli özelliği. Resimlerin katmanları vardır ve farklı görüntüler katmanları paylaşabilir, daha fazla yer tasarrufu ve daha hızlı bir şekilde oluşturulabilir.

Tüm kaplar Ubuntu'yu taban görüntüleri olarak kullanırsa, her görüntünün kendi dosya sistemi yoktur, ancak aynı alt çizgi ubuntu dosyalarını paylaşır ve yalnızca kendi uygulama verilerinde farklılık gösterir.

3. Paylaşılan işletim sistemi çekirdeği

Konteynerleri süreç olarak düşünün!

Bir ana bilgisayarda çalışan tüm kapsayıcılar gerçekten farklı dosya sistemlerine sahip bir grup işlemdir. Aynı işletim sistemi çekirdeğini paylaşırlar, sadece sistem kütüphanesini ve bağımlılıkları kapsar.

Bu çoğu vaka için iyidir (ekstra işletim sistemi çekirdeği kalmaz) ancak kaplar arasında sıkı yalıtımların gerekli olması durumunda bir sorun olabilir.

Neden önemli?

Bütün bunlar devrim değil, iyileştirmeler gibi görünüyor. İyi, niceliksel birikim, niteliksel dönüşüme yol açar.

Uygulama dağıtımını düşünün. Yeni bir yazılım (servis) dağıtmak veya yeni bir sürüm yükseltmek istiyorsak, yeni bir VM oluşturmak yerine yapılandırma dosyalarını ve süreçleri değiştirmek daha iyidir. Güncellenmiş bir hizmetle bir VM oluşturulduğundan, üretime (Dev & QA arasında paylaştır), üretime dağıtılmasının test edilmesi saatler hatta günler sürer. Bir şey ters giderse, daha fazla zaman harcayarak tekrar başlamanız gerekir. Bu yüzden, yeni yazılım yüklemek için konfigürasyon yönetim aracını (kukla, saltstack, şef vb.) Kullanın, yeni dosyaları indirin tercih edilir.

Docker söz konusu olduğunda, eski olanı değiştirmek için yeni oluşturulmuş bir docker kabını kullanmak imkansız. Bakım yapmak çok daha kolay! Yeni bir görüntü oluşturun, QA ile paylaşın, test edin, sadece birkaç dakika sürer (eğer her şey otomatikse), en kötü durumda saatler. Buna denir değişmez altyapı: yazılımı (yükseltme) korumaz, bunun yerine yeni bir tane oluşturun.

Hizmetlerin nasıl teslim edildiğini dönüştürür. Uygulamalar istiyoruz, ancak VM'leri korumalıyız (ki bu bir acıdır ve uygulamalarımızla pek ilgisi yoktur). Docker, uygulamalara odaklanmanızı sağlar ve her şeyi pürüzsüzleştirir.


23
2017-08-10 04:25



Bu cevap kabul edilmeli! - Sharan Duggirala


İle ilgili olarak:-

"Neden bir docker görüntüsüne yazılım dağıtmak kolay değil?   tutarlı bir üretim ortamına mı yayılıyor? "

Çoğu yazılım, genellikle aşağıdakilerden en az üçü olmak üzere birçok ortama dağıtılır:

  1. Bireysel geliştirici PC (ler)
  2. Paylaşılan geliştirici ortamı
  3. Bireysel test pc (ler)
  4. Paylaşılan test ortamı
  5. QA ortamı
  6. UAT ortamı
  7. Yük / performans testi
  8. Canlı evreleme
  9. Üretim
  10. Arşiv

Göz önünde bulundurulması gereken aşağıdaki faktörler de vardır:

  • Geliştiriciler ve gerçekten de test ediciler, işin doğası gereği, ya çok az ya da çok farklı PC konfigürasyonlarına sahip olacaklar.
  • Geliştiriciler, kurumsal veya iş standardizasyon kurallarının kontrolünün ötesinde bilgisayarlarda (örneğin, kendi makinelerinde (genellikle uzaktan) çalışan serbest çalışanlar veya bilgisayarlarını belirli bir şekilde yapılandırmak için “çalıştırılmamış” veya “sözleşmeli” olmayan açık kaynaklı projelere katkıda bulunan kişiler üzerinde gelişebilir. yön)
  • Bazı ortamlar, yük dengeli konfigürasyonda sabit sayıda birden fazla makineden oluşacaktır.
  • Birçok üretim ortamının, trafik düzeylerine bağlı olarak dinamik olarak (veya 'elastik olarak') oluşturulmuş ve yok edilen bulut tabanlı sunucuları olacaktır.

Bir kuruluş için tahmin edilen toplam sunucu sayısını nadiren tekil rakamlarla görebildiğiniz gibi, genellikle üçlü rakamlardadır ve yine de kolayca daha yüksek olabilir.

Tüm bunların anlamı, ilk etapta tutarlı ortamların yaratılmasının, sadece (yeşil alan senaryosunda bile) bir hacim nedeniyle yeterince zor olduğu anlamına gelir, fakat onları tutarlı tutmak imkansızdır. sunucu sayısının yüksek olması, yeni sunucuların (dinamik veya manuel) eklenmesi, o / s satıcılarından otomatik güncellemeler, anti virüs satıcıları, tarayıcı satıcıları ve benzerleri, manuel yazılım yüklemeleri veya geliştiriciler veya sunucu teknisyenleri tarafından yapılan yapılandırma değişiklikleri vb. Bunu tekrar edeyim - ortamları tutarlı tutmak neredeyse imkânsız (tamam değil), tamam, saflık için yapılabilir, ancak çok büyük bir zaman, çaba ve disiplin gerektirir, bu da tam olarak neden VM'ler ve kaplar? (örneğin Docker) ilk etapta tasarlandı).

Yani sorunuzu daha çok düşünün "Tüm ortamları tutarlı tutmanın aşırı zorluğu göz önünde bulundurulduğunda, öğrenme eğrisini hesaba katarken bile yazılımı bir docker görüntüsüne yerleştirmek daha mı kolay?". Bence cevabın her zaman "evet" olacağına inanıyorum - ama bu yeni soruyu Stack Overflow üzerine yayınlamanın sadece bir yolu var.


16
2017-10-15 11:25



Yani, docker resmimi tüm farklı OS / sürüm kombinasyonlarına sahip 15 farklı kutu ile dağıtırsam, tüm docker resimlerim aynı şekilde çalışır? - Teoman shipahi