Docker'ın sanal bir makineden farkı nedir?

Docker ile tam bir VM arasındaki farkı anlamaya çalışmak için Docker belgelerini tekrar okumaya devam ediyorum . Ağır olmadan tam bir dosya sistemi, yalıtılmış ağ ortamı vb. Sağlamayı nasıl başarıyor?

Yazılımı bir Docker görüntüsüne dağıtmak (doğru terim ise) neden tutarlı bir üretim ortamına dağıtmaktan daha kolaydır?

Docker başlangıçta LinuX Konteynerleri (LXC) kullandı, ancak daha sonra ana bilgisayarla aynı işletim sisteminde çalışan runC'ye (eski adıyla libcontainer olarak biliniyordu ) geçti. Bu, birçok ana bilgisayar işletim sistemi kaynağını paylaşmasına olanak tanır. Ayrıca, katmanlı bir dosya sistemi ( AuFS ) kullanır ve ağı yönetir.

AuFS katmanlı bir dosya sistemidir, bu nedenle bir araya getirilen salt okunur ve yazma bölümlerine sahip olabilirsiniz. Biri, işletim sisteminin ortak bölümlerini salt okunur olarak (ve tüm kaplarınız arasında paylaşılan) olabilir ve daha sonra her kapsayıcıya yazma için kendi montajını verebilir.

Diyelim ki 1 GB'lık bir konteyner resminiz var; tam bir VM kullanmak istiyorsanız, istediğiniz 1 GB x sayıda VM'ye sahip olmanız gerekir. Docker ve AuFS ile 1 GB'ın büyük bölümünü tüm kaplar arasında paylaşabilirsiniz ve 1000 kapınız varsa, kap işletim sistemi için hala 1 GB'ın biraz üzerinde alanınız olabilir (hepsinin aynı işletim sistemi görüntüsünü çalıştırdığı varsayılarak) .

Tam bir sanallaştırılmış sistem, kendisine tahsis edilen kendi kaynak kümesini alır ve en az paylaşımı yapar. Daha fazla izolasyon elde edersiniz, ancak çok daha ağırdır (daha fazla kaynak gerektirir). Docker ile daha az izolasyon elde edersiniz, ancak kaplar hafiftir (daha az kaynak gerektirir). Böylece, bir ana bilgisayarda binlerce kapsayıcıyı kolayca çalıştırabilirsiniz ve hatta yanıp sönmez. Bunu Xen ile yapmayı deneyin ve gerçekten büyük bir ev sahibi yoksa, bunun mümkün olduğunu düşünmüyorum.

Tam bir sanallaştırılmış sistemin başlatılması genellikle dakikalar alırken, Docker / LXC / runC kapları saniyeler alır ve çoğu zaman bir saniyeden daha kısa sürer.

Her sanallaştırılmış sistem türü için artıları ve eksileri vardır. Garantili kaynaklarla tam izolasyon istiyorsanız, tam bir VM gitmenin yoludur. İşlemleri birbirinden ayırmak ve makul büyüklükte bir ana bilgisayarda bir ton çalıştırmak istiyorsanız, Docker / LXC / runC gitmenin yolu gibi görünüyor.

Daha fazla bilgi için, LXC'nin nasıl çalıştığını açıklamada iyi bir iş çıkaran bu blog gönderileri grubuna göz atın.

Yazılımı bir docker görüntüsüne dağıtmak (doğru terim ise) neden tutarlı bir üretim ortamına dağıtmaktan daha kolaydır?

Tutarlı bir üretim ortamının konuşlandırılması yapmaktan daha kolaydır. Şef ve Kukla gibi araçlar kullansanız bile , 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 sistemini paylaşılan bir görüntüye anlık görüntü alma olanağı sunar ve diğer Docker ana bilgisayarlarına dağıtımını kolaylaştırır. Yerel olarak, dev, qa, prod, vb .: hepsi aynı görüntü. Elbette bunu diğer araçlarla yapabilirsiniz, ancak neredeyse kolay veya hızlı değil.

Bu test için harikadır; bir veritabanına bağlanması gereken binlerce testiniz olduğunu ve her testin veritabanının bozulmamış bir kopyasına ihtiyacı olduğunu ve verilerde değişiklikler yapacağını varsayalım. Bunun klasik yaklaşımı, her testten sonra veritabanını özel kodla veya Flyway gibi araçlarla sıfırlamaktır - bu çok zaman alıcı olabilir ve testlerin seri olarak yapılması gerektiği anlamına gelir. Ancak, Docker ile veritabanınızın bir görüntüsünü oluşturabilir ve her test için bir örnek çalıştırabilir ve daha sonra tüm testleri paralel olarak çalıştırabilirsiniz; Testler paralel ve Docker kapsayıcılarında çalıştığından, hepsi aynı kutuda aynı anda çalışabilir ve çok daha hızlı bitirilmelidir. Bunu tam bir VM ile yapmayı deneyin.

Yorumlardan ...

İlginç! Sanırım hala "anlık görüntü [OS]" kavramıyla kafam karıştı. İşletim sistemi imajı olmadan bunu nasıl yapabiliriz?

Bakalım açıklayayım. Temel bir görüntü ile başlar ve sonra değişikliklerinizi yapar ve bu değişiklikleri docker kullanarak taahhüt edersiniz ve bir görüntü oluşturur. Bu görüntü yalnızca tabandan farklılıkları içerir. Görüntünüzü çalıştırmak istediğinizde, tabana da ihtiyacınız vardır ve görüntünüzü katmanlı bir dosya sistemi kullanarak tabanın üstüne katmanlar: yukarıda belirtildiği gibi Docker, AuFS kullanır. AuFS farklı katmanları birleştirir ve istediğinizi elde edersiniz; Sadece çalıştırman gerek. Daha fazla görüntü (katman) eklemeye devam edebilirsiniz ve bu yalnızca diffs'leri kaydetmeye devam edecektir. Docker genellikle bir kayıt defterinden hazır görüntüler üzerine inşa edildiğinden , nadiren tüm işletim sistemini kendiniz "anlık olarak görüntülemeniz" gerekir.

İyi cevaplar. Kapsayıcıya karşı VM'nin görsel bir temsilini almak için aşağıdakine bir göz atın.

Kaynak

Sanallaştırmanın ve kapsayıcıların düşük düzeyde nasıl çalıştığını anlamak yararlı olabilir. Bu birçok şeyi temizleyecektir.

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

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

Bu durumda VM yöneticisi CPU halkasını 0 (veya daha yeni CPU'larda "kök modu") devralır ve konuk işletim sisteminin kendi donanımına sahip olduğu yanılsamasını yaratmak için konuk işletim sistemi tarafından yapılan tüm ayrıcalıklı çağrıları durdurur. Eğlenceli gerçek: 1998'den önce bunu x86 mimarisinde başarmanın imkansız olduğu düşünülüyordu, çünkü bu tür bir müdahaleyi yapmanın bir yolu yoktu. VMWare'deki kişiler, bunu gerçekleştirmek için konuk işletim sisteminin ayrıcalıklı çağrıları için bellekteki yürütülebilir baytları yeniden yazma fikri olan ilk kişilerdi.

Net etki, sanallaştırmanın aynı donanım üzerinde tamamen farklı iki işletim sistemi çalıştırmanıza izin vermesidir. Her bir konuk işletim sistemi, önyükleme, yükleme çekirdeği vb. Tüm süreçlerden geçer. Çok sıkı bir güvenliğe sahip olabilirsiniz, örneğin konuk işletim sistemi, ana bilgisayar işletim sistemine veya diğer konuklara tam erişim sağlayamaz ve işleri karıştırır.

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

Yaklaşık 2006 , Google'da çalışanların bazılarının da dahil insanlar yeni kernel düzeyi özelliği olarak adlandırılan uygulanan ad alanlarını (ancak fikri uzun öncesinde FreeBSD var olan). İşletim sisteminin bir işlevi, ağ ve disk gibi küresel kaynakların süreçlere paylaşılmasına izin vermektir. Bu global kaynaklar, yalnızca aynı ad alanında çalışan işlemler tarafından görülebilir olacak şekilde ad alanlarına sarılmışsa ne olur? Diyelim ki, bir disk yığını alıp bunu X ad alanına koyabilirsiniz ve daha sonra Y ad alanında çalışan işlemler onu göremez veya erişemez. Benzer şekilde, X isim alanındaki işlemler Y alanındaki isim alanına tahsis edilen hiçbir şeye erişemez. Elbette X'teki işlemler Y alanındaki işlemleri göremez veya konuşamaz. Bu, global kaynaklar için bir tür sanallaştırma ve izolasyon sağlar. Docker şu şekilde çalışır: Her kap kendi ad alanında çalışır, ancak tam olarak aynı şeyi kullanırçekirdek diğer tüm kaplar gibi. Yalıtım, çekirdeğin işleme atanan ad alanını bildiği ve API çağrıları sırasında işlemin yalnızca kendi ad alanındaki kaynaklara erişebildiğinden emin olmasından kaynaklanır.

Kapsayıcıların VM'ye karşı kısıtlamaları artık açık olmalıdır: Sanal makinelerde olduğu gibi kaplarda tamamen farklı işletim sistemleri çalıştıramazsınız. Ancak yapabilirsiniz aynı çekirdek paylaşan çünkü Linux farklı dağıtımlar çalıştırın. İzolasyon seviyesi VM'deki kadar güçlü değildir. Aslında, "misafir" konteyner erken uygulamalarda ev sahibi devralmak için bir yol vardı. Ayrıca, yeni bir kap yüklediğinizde, OS'nin tüm yeni kopyasının VM'de olduğu gibi başlamadığını görebilirsiniz. Tüm kaplar aynı çekirdeği paylaşır. Bu yüzden kaplar hafiftir. Ayrıca VM'den farklı olarak, işletim sisteminin yeni bir kopyasını çalıştırmadığımız için kapsayıcılara önemli miktarda bellek ayırmanız gerekmez. Bu, korumalı alan oluştururken binlerce kapsayıcıyı bir işletim sisteminde çalıştırmayı mümkün kılar; bu, kendi VM'sinde ayrı bir OS kopyası çalıştırmamız durumunda mümkün olmayabilir.

Ken Cochrane'nin cevabını seviyorum.

Ancak burada ayrıntılı olarak ele alınmayan ek bir bakış açısı eklemek istiyorum. Bence Docker tüm süreçte farklı. VM'lerin aksine, Docker (yalnızca) donanımın optimum kaynak paylaşımı ile ilgili değildir, ayrıca paketleme uygulaması için bir "sistem" sağlar (bir mikro hizmet seti olarak tercih edilir, ancak bir zorunluluk değildir).

Bana göre rpm, Debian paketleri, Maven , npm + Git gibi geliştirici odaklı araçlar ve bir taraftaki Kukla , VMware, Xen gibi ops araçları arasındaki boşluğa uyuyor ...

Yazılımı bir docker görüntüsüne dağıtmak (doğru terim ise) neden tutarlı bir üretim ortamına dağıtmaktan daha kolaydır?

Sorunuz tutarlı bir üretim ortamı olduğunu varsayar. Ama nasıl tutarlı tutulur? Boru hattındaki aşamaları (> 10) bir miktar sunucu ve uygulama düşünün.

Bunu senkronize tutmak için Kukla, Şef veya kendi hazırlık komut dosyalarınız, yayınlanmamış kurallar ve / veya çok sayıda dokümantasyon kullanmaya başlayacaksınız ... Teorik olarak sunucular süresiz olarak çalışabilir ve tamamen tutarlı ve güncel tutulabilir. Uygulama bir sunucunun yapılandırmasını tamamen yönetemez, bu nedenle yapılandırma sapması ve çalışan sunucularda beklenmedik değişiklikler için önemli bir kapsam vardır.

Yani bundan kaçınmak için bilinen bir model var, bu değişmez sunucu . Ancak değişmez sunucu modeli sevilmiyordu. Çoğunlukla Docker'dan önce kullanılan VM'lerin sınırlamaları nedeniyle. Birkaç gigabayt büyük görüntü ile uğraşmak, bu büyük görüntüleri hareket ettirmek, sadece uygulamadaki bazı alanları değiştirmek için çok zahmetli. Anlaşılabilir ...

Docker ekosistemi ile, "küçük değişiklikler" (teşekkürler aufs ve Registry) sayesinde asla gigabaytlar arasında dolaşmanıza gerek kalmayacak ve uygulamaları bir Docker kapsayıcısına zamanında paketleyerek performansı kaybetme konusunda endişelenmenize gerek yok. Bu görüntünün sürümleri hakkında endişelenmenize gerek yok.

Son olarak, Linux dizüstü bilgisayarınızda bile karmaşık üretim ortamlarını çoğaltabileceksiniz (durumunuzda çalışmazsa beni arama;))

Ve elbette VM'lerde Docker kapsayıcılarını başlatabilirsiniz (bu iyi bir fikir). VM düzeyinde sunucu provizyonunuzu azaltın. Yukarıdakilerin tümü Docker tarafından yönetilebilir.

PS Bu arada Docker, LXC yerine kendi "libcontainer" uygulamasını kullanır. Ancak LXC hala kullanılabilir.

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

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

sanallaştırma

Tasarlanan formunda, birden fazla uygulamanın aynı anda çalışmasına izin vermek için ana çerçeveleri mantıksal olarak bölme yöntemi olarak kabul edildi. Bununla birlikte, şirketler ve açık kaynak toplulukları ayrıcalıklı yönergeleri bir şekilde ele alma yöntemi sağlayabildiğinde ve birden çok işletim sisteminin tek bir x86 tabanlı sistemde aynı anda çalışmasına izin verdiğinde senaryo büyük ölçüde değişti.

hipervizör

Hiper denetimci, konuk sanal makinelerin üzerinde çalıştığı sanal ortamı oluşturmayı ele alır. Konuk sistemlerini denetler ve misafirlere gerekli kaynakların tahsis edilmesini sağlar. Hiper yönetici, fiziksel makine ile sanal makineler arasında yer alır ve sanal makinelere sanallaştırma hizmetleri sağlar. Bunu gerçekleştirmek için, sanal makinelerde konuk işletim sistemi işlemlerini durdurur ve ana makinenin işletim sistemindeki işlemi taklit eder.

Sanallaştırma teknolojilerinin, özellikle bulutta, hızlı gelişimi, Xen, VMware Player, KVM gibi hipervizörlerin yardımıyla tek bir fiziksel sunucuda birden fazla sanal sunucunun oluşturulmasına izin vererek sanallaştırma kullanımını daha da ileriye taşımıştır ve Intel VT ve AMD-V gibi emtia işlemcilerinde donanım desteğinin dahil edilmesi.

Sanallaştırma Türleri

Sanallaştırma yöntemi, donanımı konuk işletim sistemine nasıl taklit ettiğine ve konuk işletim ortamına öykünmesine bağlı olarak kategorize edilebilir. Öncelikle, üç tür 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 emülasyon, sanal makine işletim sistemi çekirdeğini tamamen yazılımda çalıştırır. Bu tipte kullanılan hipervizör, Tip 2 hipervizör olarak bilinir. Konuk işletim sistemi çekirdek kodunu yazılım yönergelerine çevirmekten sorumlu olan ana bilgisayar işletim sisteminin en üstüne yüklenir. Çeviri tamamen yazılımda yapılır ve herhangi bir donanım katılımı gerektirmez. Emülasyon, taklit edilen ortamı destekleyen modifiye edilmemiş herhangi bir işletim sisteminin çalıştırılmasını mümkün kılar. Bu tür sanallaştırmanın olumsuz tarafı, diğer sanallaştırma türlerine kıyasla performansta bir azalmaya yol açan ek bir sistem kaynağı ek yüküdür.

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

sanallaştırma

Tip 1 hipervizör olarak da bilinen paravirtualization doğrudan donanım veya “çıplak metal” üzerinde çalışır ve doğrudan üzerinde çalışan sanal makinelere sanallaştırma hizmetleri sağlar. İşletim sisteminin, sanallaştırılmış donanımın ve gerçek donanımın en iyi performansı elde etmek için işbirliği yapmasına yardımcı olur. Bu hipervizörler tipik olarak oldukça az yer kaplar ve kendileri için kapsamlı kaynaklar gerektirmez.

Bu kategorideki örnekler Xen, KVM vb.

Kapsayıcı Tabanlı Sanallaştırma

İşletim sistemi düzeyinde sanallaştırma olarak da bilinen kap tabanlı sanallaştırma, tek bir işletim sistemi çekirdeğinde birden çok yalıtılmış yürütmeye olanak tanır. Mümkün olan en iyi performans 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ına kap adı verilir ve izlenen bir işlem grubu olarak görüntülenebilir.

Bir kap kavramı Linux çekirdek 2.6.24 sürümüne eklenen ad alanları özelliğiyle mümkün kılınmıştır. Kapsayıcı, kimliğini her işleme ekler ve her sistem çağrısına yeni erişim denetimi denetimleri ekler. Önceki global ad alanlarının ayrı örneklerinin oluşturulmasına izin veren clone () sistem çağrısı tarafından erişilir .

Ad alanları birçok farklı şekilde kullanılabilir, ancak en yaygın yaklaşım, kabın dışındaki nesnelere görünürlüğü veya erişimi olmayan yalıtılmış bir kap oluşturmaktır. Kapsayıcı içinde çalışan işlemler, temel çekirdeği diğer ad alanlarında bulunan ve diğer nesne türleri için aynı olan işlemlerle paylaşsalar da normal bir Linux sisteminde çalışıyor gibi görünmektedir. Örneğin, ad alanlarını kullanırken, kapsayıcı içindeki kök kullanıcı, kapsayıcı dışında kök olarak değerlendirilmez ve ek güvenlik ekler.

Kapsayıcı tabanlı sanallaştırmayı etkinleştirmenin bir sonraki ana bileşeni olan Linux Kontrol Grupları (cgroups) alt sistemi, süreçleri gruplandırmak ve toplam 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. Kapsayıcı bir Linux sistemi yalnızca bir çekirdeğe sahip olduğundan ve çekirdek kaplarda tam görünürlüğe sahip olduğundan, yalnızca bir düzeyde kaynak ayırma ve zamanlama vardır.

LXC, LXD, systemd-nspawn, lmctfy, Warden, Linux-VServer, OpenVZ, Docker vb. Gibi Linux kapsayıcıları için çeşitli yönetim araçları mevcuttur.

Kaplar ve Sanal Makineler

Sanal bir 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ı tabanlı sanallaştırmayı diğer sanallaştırma yaklaşımlarından daha benzersiz ve cazip hale getirir.

Kapsayıcı tabanlı sanallaştırma ana makineye çok az ek yük eklediğinden veya ek yük getirmediğinden, kapsayıcı tabanlı sanallaştırma yerel performansa yakın bir performansa sahiptir

Kapsayıcı tabanlı sanallaştırma için, diğer sanallaştırmaların aksine ek yazılım gerekmez.

Bir ana makine üzerindeki tüm kaplar, ana makine zamanlayıcısını paylaşarak ekstra kaynak ihtiyacından tasarruf eder.

Kap durumları (Docker veya LXC görüntüleri) sanal makine görüntülerine kıyasla küçük boyuttadır, bu nedenle kap görüntülerinin dağıtılması kolaydır.

Kapsayıcılardaki kaynak yönetimi, gruplar halinde sağlanır. Cgroups, kapların kendilerine tahsis edilenden daha fazla kaynak tüketmesine izin vermez. Ancak, şu an itibariyle, ana makinenin tüm kaynakları sanal makinelerde görülebilir, ancak kullanılamaz. Bu, konteynerler ve ana makine üzerinde aynı anda çalıştırılarak topveya gerçekleştirilerek gerçekleştirilebilir htop. Tüm ortamlardaki çıktı benzer görünecektir.

Güncelleme:

Docker, Linux dışı sistemlerde kapsayıcıları nasıl çalıştırır?

Linux çekirdeğindeki özellikler nedeniyle kapsayıcılar mümkünse, Linux ile ilgili olmayan sistemlerin kapsayıcıları nasıl çalıştırdığı açıktır. Hem Mac için Docker hem de Windows kapsayıcıları çalıştırmak için Linux VM'lerini kullanır. Sanal Kutu VM'lerinde kapsayıcıları çalıştırmak için kullanılan Docker Toolbox. Ancak, en son Docker, Windows'ta Hyper-V ve Mac'te Hypervisor.framework kullanıyor.

Şimdi, Mac için Docker'ın kapsayıcıları nasıl ayrıntılı olarak çalıştırdığını açıklayayım.

Mac için Docker , hiper yönetici yeteneklerini taklit etmek için https://github.com/moby/hyperkit kullanır ve Hyperkit çekirdeğinde hypervisor.framework kullanır. Hipervizör. Çerçeve Mac'in yerel hipervizör çözümüdür. Hyperkit ayrıca ağ ve dosya sistemini adlandırmak için VPNKit ve DataKit kullanır.

Docker'ın Mac'te çalıştırdığı Linux VM'si salt okunurdur. Ancak, bunu çalıştırarak bash yapabilirsiniz:

screen ~/Library/Containers/com.docker.docker/Data/vms/0/tty.

Şimdi, bu VM'nin Çekirdek sürümünü bile kontrol edebiliriz:

# uname -a Linux linuxkit-025000000001 4.9.93-linuxkit-aufs #1 SMP Wed Jun 6 16:86_64 Linux.

Tüm kapsayıcılar bu VM'nin içinde çalışır.

Hipervizörde bazı sınırlamalar vardır. Çerçeve. Bu nedenle Docker, docker0Mac'te ağ arayüzünü açığa çıkarmaz . Böylece, ana bilgisayardan kapsayıcılara erişemezsiniz. Şu an itibariyle docker0, yalnızca VM içinde kullanılabilir.

Hyper-v, Windows'daki yerel hipervizördür. Ayrıca Linux sistemlerini yerel olarak çalıştırmak için Windows 10'un yeteneklerinden yararlanmaya çalışıyorlar.

Bu yazı sayesinde VM'ler ve LXC'ler arasında bazı farklılıklar çizeceğiz. Önce bunları tanımlayalım.

VM :

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

Bu bağlamda, VM Konuk olarak, üzerinde çalıştığı ortama ise ana bilgisayar denir.

LXC ler:

Linux Kapsayıcılar (LXC), bir kontrol ana bilgisayarında (LXC ana bilgisayar) birden çok yalıtılmış Linux kapsayıcısının çalıştırılmasını mümkün kılan işletim sistemi düzeyindeki yeteneklerdir. Linux Kapsayıcıları, sanal makine denetleyicileri vizesini gerektirmedikleri için VM'lere hafif bir alternatif olarak hizmet eder. Virtualbox, KVM, Xen vb.

Şimdi Alan (Hangover serisinden Zach Galifianakis-) ve geçen yıl Vegas'ta olmadıkça, Linux kapsayıcı teknolojisi için muazzam ilgi duyduğundan çok haberdar olacaksınız ve eğer belirli bir kap olacaksam Son birkaç ay içinde dünya çapında bir vızıltı yaratan proje - Docker, bulut bilgi işlem ortamlarının sanal makineleri (VM) terk etmeleri ve daha düşük genel maliyetleri ve potansiyel olarak daha iyi performansları nedeniyle bunları konteynerlerle değiştirmeleri gerektiği konusunda yankılanan görüşlere yol açıyor.

Ama asıl soru şu, bu mümkün mü ?, mantıklı olacak mı?

a. LXC'ler bir Linux örneğine dahil edilir. Linux'un farklı lezzetleri olabilir (örneğin bir CentOS ana bilgisayarındaki bir Ubuntu kapsayıcısı ama yine de Linux'tur.) Benzer şekilde, VM'lere bakarsak, oldukça geniş bir kapsama sahip oldukları ve hipervizörler Linux veya Windows işletim sistemleri ile sınırlı değilsiniz.

b. LXC'lerin genel giderleri düşüktür ve VM'lere kıyasla daha iyi performans gösterir. Araçlar viz. LXC teknolojisinin omuzları üzerine inşa edilen Docker, geliştiricilere uygulamalarını çalıştırmak için bir platform sağladı ve aynı zamanda operasyonları insanlara aynı kapsayıcıyı üretim sunucularına veya veri merkezlerine dağıtmalarını sağlayacak bir araçla güçlendirdi. Bir uygulamayı çalıştıran, bir uygulamayı önyükleyen ve test eden bir geliştirici ile bu uygulamayı sorunsuz bir şekilde dağıtan bir operasyon görevlisi arasındaki deneyimi yaşatmaya çalışır, çünkü bu, tüm sürtünmenin yattığı yer ve DevOps'un amacı bu siloları parçalamaktır.

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

VM'leri bırakmak şu an için pratik değil. Dolayısıyla hem VM'lerin hem de LXC'lerin kendi bireysel varlıkları ve önemleri vardır.

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

Docker, sanal bir makine değil, bir işlemi yürütmenin sadece süslü bir yoludur.

Şimdi bunun ne anlama geldiğini biraz daha açıklayayım. Sanal makineler kendi canavarıdır. Docker'ın ne olduğunu açıklamak , bunu sanal bir makinenin ne olduğunu açıklamaktan daha fazla anlamanıza yardımcı olacaktır. Özellikle burada birisinin "sanal makine" derken tam olarak ne anlama geldiğini anlatan birçok iyi cevap olduğu için. Yani...

Docker kapsayıcısı, yalnızca işlemlerin geri kalanından ana bilgisayar sisteminin çekirdeğindeki gruplar kullanılarak bölümlere ayrılmış bir işlemdir (ve alt öğeleri) . Docker kapsayıcı işlemlerinizi ps auxana bilgisayarda çalıştırarak görebilirsiniz . Örneğin, apache2"bir kapta" başlatmak apache2, ana bilgisayarda özel bir işlem olarak başlar. Makine üzerindeki diğer işlemlerden sadece bölümlere ayrılmıştır. Kapsayıcılarınızın kapsayıcı işleminizin ömrünün dışında bulunmadığına dikkat etmek önemlidir. İşleminiz bittiğinde, konteyneriniz ölür. Bunun nedeni Docker'ın pid 1konteynerinizin içinde uygulamanızla değiştirilmesidir ( pid 1normalde init sistemidir). Bu son nokta pid 1çok önemlidir.

Bildiğim kadarıyla bu konteyner işlemlerin her tarafından kullanılan dosya sistemi, Docker kullanır unionfs Bir yaptığınızda neyi sen indirilmesi olan görüntüleri -backed docker pull ubuntu. Her bir "resim" yalnızca bir katmanlar dizisi ve ilgili meta verilerdir. Katmanlama kavramı burada çok önemlidir. Her katman, altındaki katmandan sadece bir değişikliktir. Örneğin, bir Docker kapsayıcısı oluştururken Dockerfile dosyanızdaki bir dosyayı sildiğinizde, aslında son katmanın üstünde "bu dosya silindi" yazan bir katman oluşturursunuz. Bu nedenle, dosya sisteminizden büyük bir dosyayı silebilirsiniz, ancak görüntü yine de aynı miktarda disk alanı kaplar. Dosya hala mevcut dosyanın altındaki katmanlarda. Katmanların kendileri sadece dosyaların tarball'larıdır. Bunu aşağıdakilerle test edebilirsiniz:docker save --output /tmp/ubuntu.tar ubuntuve sonra cd /tmp && tar xvf ubuntu.tar. Sonra etrafa bir göz atabilirsiniz. Uzun karmalar gibi görünen tüm dizinler aslında tek tek katmanlardır. Her biri dosya ( layer.tar) ve meta veri (json) söz konusu katman hakkında bilgi içerir. Bu katmanlar, dosya sisteminin orijinal durumunun "üstünde" katman olarak kaydedilen değişiklikleri açıklar. "Geçerli" verileri okurken, dosya sistemi verileri yalnızca en üstteki değişiklik katmanlarına bakıyormuş gibi okur. Dosya sistemi yalnızca en üstteki katmanlara baktığından, dosyanın "önceki" katmanlarda hala var olmasına rağmen silinmiş gibi görünmesinin nedeni budur. Bu, her kapta en üst katmanlardaki dosya sisteminde bazı önemli değişiklikler olsa da, tamamen farklı kapsayıcıların dosya sistemi katmanlarını paylaşmasına izin verir. Bu, kaplarınız temel görüntü katmanlarını paylaştığında size bir ton disk alanı kazandırabilir. Ancak,

Docker'da ağ docker0oluşturma, bir ana bilgisayar köprüsü ve ana bilgisayardaki her kapsayıcı için sanal arabirimler kullanılarak gerçekleştirilir. docker0Kapsayıcılarınızın birbirleriyle "iletişim kurması" için sanal bir alt ağ oluşturur . Burada, ağ kapsayıcılarınız için özel alt ağlar oluşturma ve ana makinenizin kapsayıcı ağınızın doğrudan erişmesi için ağ yığınını "paylaşma" yeteneği de dahil olmak üzere birçok ağ oluşturma seçeneği vardır.

Docker çok hızlı hareket ediyor. Onun belgeler şimdiye kadar gördüğüm en iyi belgelerin bir kısmı bu. Genellikle iyi yazılmış, özlü ve doğrudur. Daha fazla bilgi için mevcut belgelere bakmanızı ve Yığın Taşması da dahil olmak üzere çevrimiçi okuduğunuz her şeyin belgelerine güvenmenizi tavsiye ederim. Belirli sorularınız varsa #docker, Freenode IRC'ye katılmanızı ve orada sormanızı şiddetle tavsiye ederim (bunun için Freenode'un web sohbetini bile kullanabilirsiniz !).

Docker bir uygulamayı tüm bağımlılıklarıyla birlikte içine alır.

Bir sanallaştırıcı, normalde çıplak metal bir makinede çalıştırabileceği uygulamaları çalıştırabilen bir işletim sistemini içerir.

İkisi de çok farklı. Docker hafiftir ve LXC / libcontainer kullanır (çekirdek ad boşluğu ve gruplarına dayanır) ve hipervizör, KVM gibi makine / donanım öykünmesine sahip değildir. Ağır Xen.

Docker ve LXC daha çok korumalı alan, kapsayıcılık ve kaynak yalıtımı içindir. IPC, NS (mount), ağ, PID, UTS, vb. İçin ad alanı sağlayan ana bilgisayar işletim sisteminin (şu anda yalnızca Linux çekirdeği) klon API'sını kullanır.

Bellek, G / Ç, CPU vb. Bu, belirli kaynak (CPU, bellek, vb.) Spesifikasyonu / kısıtlaması olan gruplar oluşturabileceğiniz ve işlemlerinizi oraya koyabileceğiniz cgroups kullanılarak kontrol edilir. LXC'nin üstünde Docker, bir depolama arka ucu ( http://www.projectatomic.io/docs/filesystems/ ), ör. Katmanlar ekleyebileceğiniz ve farklı montaj ad alanları arasında katmanlar paylaşabileceğiniz birleşik montaj dosya sistemi sağlar.

Bu, temel görüntülerin tipik olarak salt okunur olduğu güçlü bir özelliktir ve yalnızca kap katmandaki bir şeyi değiştirdiğinde, okuma-yazma bölümüne (yazmada kopya olarak da bilinir) bir şeyler yazacaktır. Ayrıca, kayıt defteri ve görüntülerin sürümlendirilmesi gibi diğer birçok sarmalayıcı da sağlar.

Normal LXC ile bazı rootfs ile gelmeniz veya rootfs'i paylaşmanız ve paylaşmanız gerekir ve değişiklikler diğer kaplara yansıtılır. Eklenen bu özelliklerin çoğu nedeniyle Docker, LXC'den daha popüler. LXC, ağ ve UI gibi harici varlıklara maruz kalan işlemlerin etrafındaki güvenliği uygulamak için yerleşik ortamlarda popülerdir. Docker, tutarlı üretim ortamının beklendiği bulut çoklu kiracılık ortamında popülerdir.

Normal bir VM (örneğin, VirtualBox ve VMware) bir hipervizör kullanır ve ilgili teknolojiler ya ilk işletim sistemi (ana işletim sistemi veya konuk işletim sistemi 0) için ilk katman olan özel bir sabit yazılıma veya ana işletim sistemi üzerinde çalışan bir yazılıma sahiptir. konuk işletim sistemlerine CPU, USB / aksesuarlar, bellek, ağ vb. donanım emülasyonu sağlar. VM'ler (2015 itibariyle) yüksek güvenlikli çok kiracılı ortamda hala popülerdir.

Docker / LXC neredeyse herhangi bir ucuz donanımda çalıştırılabilir (daha yeni çekirdeğiniz olduğu sürece 1 GB'den az bellek de iyidir) ve normal VM'lerin anlamlı bir şey yapmak için en az 2 GB belleğe ihtiyacı vardır. . Ancak, ana bilgisayar işletim sistemindeki Docker desteği, Windows gibi (Kasım 2014'ten itibaren) işletim sistemlerinde kullanılamaz; burada VM türleri Windows, Linux ve Mac'lerde çalıştırılabilir.

İşte docker / rightscale'den bir resim:

1. Hafif

Bu muhtemelen birçok liman işçisi öğrencisinin ilk izlenimidir.

Birincisi, liman işçilerinin görüntüleri genellikle VM görüntülerinden daha küçüktür, oluşturmayı, kopyalamayı, paylaşmayı kolaylaştırır.

İkincisi, Docker kapsayıcıları birkaç milisaniyede başlayabilir, VM saniyeler içinde başlar.

2. Katmanlı Dosya Sistemi

Bu, Docker'ın bir başka önemli özelliğidir. Görüntülerin katmanları vardır ve farklı görüntüler katmanları paylaşabilir, daha fazla yer tasarrufu sağlar ve daha hızlı inşa edilebilir.

Tüm kapsayıcılar temel görüntüleri olarak Ubuntu kullanıyorsa, 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 İşletim Sistemi Çekirdeği

Kapları süreç olarak düşünün!

Bir ana bilgisayarda çalışan tüm kaplar, aslında farklı dosya sistemlerine sahip bir grup işlemdir. Aynı işletim sistemi çekirdeğini paylaşırlar, yalnızca sistem kitaplığını ve bağımlılıkları kapsarlar.

Bu çoğu durum için iyidir (ekstra işletim sistemi çekirdeği kalmaz), ancak kaplar arasında sıkı izolasyonlar gerekiyorsa sorun olabilir.

Neden önemli?

Bütün bunlar devrim değil iyileştirmeler gibi görünüyor. De, nicel birikimi açar dönüşümü nitel .

Uygulama dağıtımını düşünün. Yeni bir yazılım (hizmet) dağıtmak veya yükseltmek istiyorsak, yeni bir VM oluşturmak yerine yapılandırma dosyalarını ve işlemlerini değiştirmek daha iyidir. Güncellenmiş hizmet ile bir VM oluşturma, test etme (Dev & QA arasında paylaşma), üretime dağıtma saatler hatta günler sürebilir. Bir şeyler ters giderse, daha fazla zaman harcayarak tekrar başlamanız gerekir. Bu nedenle, yeni yazılım yüklemek için konfigürasyon yönetim aracını (kukla, tuz, şef vb.) Kullanın, yeni dosyaları indirmek tercih edilir.

Docker söz konusu olduğunda, eskisini değiştirmek için yeni oluşturulan bir docker konteyneri kullanmak imkansızdır. Yeni bir görüntü oluşturmak, KG ile paylaşmak, test etmek, dağıtmak en kötü durumda saatler sürer (her şey otomatikse). Buna değişmez altyapı denir : yazılımı korumayın (yükseltmeyin), bunun yerine yeni bir tane oluşturun.

Hizmetlerin sunumunu dönüştürür. Uygulamalar istiyoruz, ancak VM'leri korumak zorundayız (bu bir acıdır ve uygulamalarımızla çok az ilgisi vardır). Docker uygulamalara odaklanmanızı sağlar ve her şeyi düzeltir.

Docker, temelde kapsayıcılar, OS sanallaştırmasını destekler, yani uygulamanızın tam bir işletim sistemi örneği olduğunu düşünürken VM, donanım sanallaştırmasını destekler . Herhangi bir işletim sistemini önyükleyebileceğiniz fiziksel bir makine gibi hissediyorsunuz.

Docker'da, çalışan kapsayıcılar ana işletim sistemi çekirdeğini paylaşırken, VM'lerde kendi işletim sistemleri dosyaları vardır. Bir uygulamayı geliştirdiğiniz ortam (OS), "test" veya "üretim" gibi çeşitli sunum ortamlarına dağıtırken aynı olur.

Örneğin, bağlantı noktası 4000'de çalışan bir web sunucusu geliştirirseniz, "test" ortamınıza dağıttığınızda, bu bağlantı noktası başka bir program tarafından zaten kullanılır, bu nedenle çalışmayı durdurur. Konteynerlerde katmanlar vardır; işletim sisteminde yaptığınız tüm değişiklikler bir veya daha fazla katmana kaydedilir ve bu katmanlar görüntünün bir parçası olur, böylece görüntü nereye giderse gitsin bağımlılıklar da mevcut olur.

Aşağıda gösterilen örnekte, ana makine üç VM'ye sahiptir. VM'lerde uygulamalara tam bir yalıtım sağlamak için, her biri kendi işletim sistemi dosyalarının, kitaplıklarının ve uygulama kodunun bir kopyasının yanı sıra bir işletim sisteminin tam bellek içi örneğine sahiptir. Oysa aşağıdaki şekil konteynerlerle aynı senaryoyu göstermektedir. Burada kapsayıcılar, çekirdek ve kitaplıklar da dahil olmak üzere ana bilgisayar işletim sistemini paylaşır, böylece bir işletim sistemi önyükleme, kitaplık yükleme veya bu dosyalar için özel bir bellek maliyeti ödemeleri gerekmez. Aldıkları tek artımlı alan, uygulamanın kapta çalışması için gereken bellek ve disk alanıdır. Uygulamanın ortamı özel bir işletim sistemi gibi hissedilirken, uygulama da özel bir ana bilgisayara olduğu gibi dağıtılır. Kapsayıcı uygulama saniyeler içinde başlar ve uygulamanın birçok örneği VM durumuna göre makineye sığabilir.

Kaynak: https://azure.microsoft.com/en-us/blog/containers-docker-windows-and-trends/

Bir uygulamayı çalıştırmak için bir yığın sağlayan üç farklı kurulum vardır (Bu, bir kabın ne olduğunu ve onu diğer çözümlerden çok daha güçlü yapan şeyi tanımamıza yardımcı olacaktır):

1) Traditional Servers(bare metal)
2) Virtual machines (VMs)
3) Containers

1) Geleneksel sunucu yığını, işletim sistemi ve uygulamanızı çalıştıran fiziksel bir sunucudan oluşur.

Avantajları:

• Ham kaynakların kullanımı

• İzolasyon

Dezavantajları:

• Çok yavaş dağıtım süresi
• Pahalı
• Boşa giden kaynaklar
• Ölçeklendirilmesi zor
• Taşınması zor
• Karmaşık konfigürasyon

2) VM yığını , bir işletim sistemi çalıştıran fiziksel bir sunucu ve sanal makinenizi, paylaşılan kaynakları ve ağ arayüzünü yöneten bir hipervizörden oluşur. Her Vm bir Konuk İşletim Sistemi, bir uygulama veya bir dizi uygulama çalıştırır.

Avantajları:

• Kaynakların iyi kullanımı
• Ölçeklendirmesi kolay
• Kolay yedekleme ve taşıma
• Maliyet verimliliği
• Esneklik

Dezavantajları:

• Kaynak tahsisi sorunlu
• Satıcı kilitleme
• Karmaşık konfigürasyon

3) Kapsayıcı Kurulumu , diğer yığın ile önemli fark kap tabanlı sanallaştırma, birden çok izole konuk örneğini rum için ana bilgisayar işletim sisteminin çekirdeğini kullanır. Bu konuk örneklerine kapsayıcı denir. Ana bilgisayar, fiziksel bir sunucu veya VM olabilir.

Avantajları:

• İzolasyon
• Hafif
• Kaynak etkili
• Taşınması kolay
• Güvenlik
• Düşük havai
• Ayna üretim ve geliştirme ortamı

Dezavantajları:

• Aynı Mimari
• Kaynak ağır uygulamaları
• Ağ ve güvenlik sorunları.

Kapsayıcı kurulumunu öncekilerle karşılaştırarak, kapsayıcılığın bugüne kadar bildiğimiz en hızlı, en etkili ve en güvenli kurulum olduğu sonucuna varabiliriz. Kapsayıcılar, uygulamanızı çalıştıran yalıtılmış örneklerdir. Docker kapsayıcıyı bir şekilde döndürür, katmanlar saniyeler içinde çalışan varsayılan depolama sürücüleri (Overlay sürücüleri) ve konteynere girdiğimizde üstüne oluşturulan yazma üzerine kopyalama katmanı ile yürütme gücünü güçlendiren çalışma zamanı belleği alır konteynerler.Sanallaştırma ortamına her şeyin yüklenmesi yaklaşık bir dakika sürecek VM'lerde. Bu hafif örnekler kolayca değiştirilebilir, yeniden oluşturulabilir ve taşınabilir. Bu, üretim ve geliştirme ortamını yansıtmamızı sağlar ve CI / CD süreçlerinde muazzam bir yardımcıdır. Konteynerlerin sağlayabileceği avantajlar o kadar ilgi çekicidir ki, kesinlikle burada kalmak için buradalar.

İle ilgili olarak:-

"Yazılımı bir docker görüntüsüne dağıtmak neden tutarlı bir üretim ortamına dağıtmaktan daha kolay?"

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

1. Bireysel geliştirici PC'ler
2. Paylaşılan geliştirici ortamı
3. Bireysel test PC'leri
4. Paylaşılan test ortamı
5. KG ortamı
6. UAT ortamı
7. Yük / performans testi
8. Canlı sahneleme
9. Üretim
10. Arşiv

Dikkate alınması gereken aşağıdaki faktörler de vardır:

• Geliştiriciler ve gerçekten de test kullanıcıları, işin doğası gereği, ya ince ya da çok farklı PC yapılandırmalarına sahip olacak
• Geliştiriciler genellikle kurumsal veya iş standardizasyonu kurallarının (örneğin kendi makinelerinde geliştirilen (genellikle uzaktan) serbest çalışanlar) veya bilgisayarlarını belirli bir şekilde yapılandırmak için 'istihdam edilmeyen' veya 'sözleşmeli' olmayan açık kaynak projelerine katkıda bulunanlar dışındaki bilgisayarlarda gelişebilirler. yön)
• Bazı ortamlar, yük dengeli bir konfigürasyonda sabit sayıda birden fazla makineden oluşur
• Birçok üretim ortamında trafik düzeylerine bağlı olarak dinamik olarak bulut tabanlı sunucular (veya 'esnek') oluşturulacak ve yok edilecektir

Gördüğünüz gibi, bir kuruluş için ekstrapole edilmiş toplam sunucu sayısı nadiren tek rakamlıdır, genellikle üç rakamlıdır ve yine de kolayca daha yüksek olabilir.

Tüm bunlar, ilk etapta tutarlı ortamlar yaratmanın, sadece büyük hacimden (yeşil alan senaryosunda bile) dolayı yeterince zor olduğu anlamına gelir, ancak bunları tutarlı tutmak imkansızdır. dinamik (yeni sunucuların eklenmesi sunucuların yüksek sayıda verilen veya manuel), o / s satıcılarından, anti-virüs satıcılarından, tarayıcı satıcılarından ve benzerlerinden gelen otomatik güncellemeler, manuel yazılım yüklemeleri veya geliştiriciler veya sunucu teknisyenleri tarafından yapılan yapılandırma değişiklikleri vb. Bunu tekrarlayayım - neredeyse (punta amaçlı değil) imkansız ortamları tutarlı tutmak için (tamam, saflık için yapılabilir, ancak büyük miktarda zaman, çaba ve disiplin içerir, bu yüzden VM'lerin ve konteynerlerin (örn. Docker) ilk etapta tasarlanmasının nedeni budur).

Sorunuzu daha çok şöyle düşünün: "Tüm ortamları tutarlı tutmanın aşırı zorluğu düşünüldüğünde, öğrenme eğrisini dikkate alırken bile yazılımı bir docker görüntüsüne dağıtmak daha mı kolay?" . Sanırım cevabın her zaman "evet" olacağını göreceksiniz - ancak bu yeni soruyu Stack Overflow'da yayınlamanın tek bir yolu var.

Farklılıklar hakkında daha ayrıntılı açıklayan birçok cevap var, ama işte benim çok kısa bir açıklamam.

Önemli bir fark, VM'lerin işletim sistemini çalıştırmak için ayrı bir çekirdek kullanmasıdır . Bu yüzden ağırdır ve önyükleme yapmak daha fazla sistem kaynağı tüketir.

Docker'da, kaplar çekirdeği ana bilgisayarla paylaşır ; dolayısıyla hafiftir ve çabucak başlayıp durabilir.

Sanallaştırmada, kaynaklar kurulumun başlangıcında tahsis edilir ve bu nedenle sanal makine çoğu zaman boşta kaldığında kaynaklar tam olarak kullanılmaz. Docker'da, konteynırlara sabit miktarda donanım kaynağı tahsis edilmez ve gereksinimlere bağlı olarak kaynakları kullanmakta serbesttir ve bu nedenle yüksek oranda ölçeklendirilebilir.

Docker, UNION Dosya sistemini kullanır. Docker, kaplar tarafından tüketilen bellek alanını azaltmak için yazma üzerine kopyalama teknolojisini kullanır. Buradan daha fazlasını okuyun

Sanal bir makine ile bir sunucumuz var, o sunucuda bir ana bilgisayar işletim sistemimiz var ve sonra bir hipervizörümüz var. Ve sonra bu hipervizörün üstünde çalışarak, bir uygulama ve bağımlı ikili dosyaları ve bu sunucudaki kitaplıkları olan çok sayıda konuk işletim sistemimiz var. Yanında bütün bir konuk işletim sistemi getiriyor. Oldukça ağır. Ayrıca her bir fiziksel makineye gerçekte ne kadar koyabileceğiniz konusunda bir sınır vardır.

Docker konteynırları ise biraz farklıdır. Sunucumuz var. Ana bilgisayar işletim sistemine sahibiz. Ama bunun yerine bir hipervizör , bu durumda Docker motorumuz var . Bu durumda, yanımızda bütün bir konuk işletim sistemini getirmiyoruz. İşletim sisteminin çok ince bir katmanını getiriyoruz ve buradaki çekirdek işlevselliğine ulaşmak için kapsayıcı ana işletim sistemine konuşabilir. Bu da çok hafif bir konteynere sahip olmamızı sağlıyor.

Tüm sahip olduğu uygulama kodu ve ihtiyaç duyduğu ikili dosyalar ve kütüphaneler. Ve bu ikili dosyalar ve kütüphaneler, farklı konteynerlerde de paylaşılabilir. Ve bunun bizim yapmamızı sağlayan şey, bir takım şeyler. Çok daha hızlı başlatma süreleri vardır . Bunun gibi birkaç saniye içinde tek bir sanal makineye dayanamazsınız. Ve aynı şekilde, onları hızlı bir şekilde indirerek .. böylece çok hızlı bir şekilde ölçeklendirip küçültebiliriz ve daha sonra buna bakacağız.

Her kap, işletim sisteminin kendi kopyası üzerinde çalıştığını düşünür. Bir tür yalan, kendi dosya sistemi, kendi kayıt defteri, vb var. Aslında sanallaştırılıyor.

Kaynak: Kubernetes Eylemde.

Docker'ı üretim ortamlarında ve sahnelemede çok kullandım. Buna alıştığınızda, çok kaplı ve izole edilmiş ortamlar oluşturmak için çok güçlü bulacaksınız.

Docker, LXC'ye (Linux Container) dayalı olarak geliştirilmiştir ve özellikle Ubuntu olmak üzere birçok Linux dağıtımında mükemmel çalışır.

Docker kapları yalıtılmış ortamlardır. topKomutu, bir Docker görüntüsünden oluşturulan bir Docker kapsayıcısında yayınladığınızda görebilirsiniz .

Bunun yanı sıra, dockerFile yapılandırması sayesinde çok hafif ve esnektirler.

Örneğin, bir Docker görüntüsü oluşturabilir ve bir DockerFile yapılandırabilir ve örneğin çalıştığında 'this', wpt-get 'that', 'bazı kabuk betiği' çalıştırabilir, ortam değişkenlerini ayarlayabilir vb.

Mikro hizmetler projelerinde ve mimaride Docker çok uygulanabilir bir varlıktır. Docker, Docker sürüsü, Kubernetes ve Docker Compose ile ölçeklenebilirlik, esneklik ve esneklik elde edebilirsiniz.

Docker ile ilgili bir diğer önemli konu Docker Hub ve topluluğudur. Örneğin, Prometheus, Grafana, Prometheus-JMX-İhracatçı ve Docker kullanarak kafkaları izlemek için bir ekosistem uyguladım.

Bunu yapmak için, zookeeper, kafka, Prometheus, Grafana ve jmx-toplayıcı için yapılandırılmış Docker kaplarını indirdim, sonra bazıları için YAML dosyaları kullanarak kendi yapılandırmamı kurdum veya diğerleri için Docker kapsayıcısındaki bazı dosyaları ve yapılandırmayı değiştirdim ve I Bu mimarinin kolayca birden çok sunucuya taşınabileceği izolasyonu ve ölçeklenebilirliği ve esnekliği ile tek bir makinede çok konteynerli Dockers kullanarak kafka izlemek için bütün bir sistem kurmak.

Docker Hub sitesinin yanı sıra, kendi Docker resimlerinizin gösterge tablosuna sahip olabilmeniz ve çekip / kendisinden çekebileceğiniz quay.io adlı başka bir site daha var. Docker görüntülerini rıhtım için Docker Hub'dan içe aktarabilir ve ardından kendi makinenizdeki rıhtımdan çalıştırabilirsiniz.

Not: Docker'ı ilk etapta öğrenmek karmaşık ve zor görünüyor, ancak buna alıştığınızda onsuz çalışamazsınız.

Docker ile çalıştığım ilk günleri yanlış komutlar verdiğimde veya kaplarımı ve tüm veri ve yapılandırmaları yanlışlıkla kaldırdığımda hatırlıyorum.

Docker şu şekilde kendini tanıtmaktadır:

Docker, konteyner hareketini yönlendiren ve hibrit bulut üzerindeki her uygulamayı ele alan tek konteyner platformu sağlayıcısıdır. Günümüzde işletmeler dijital dönüşüm için baskı altındadır, ancak giderek farklılaşan bulut, veri merkezi ve uygulama mimarisi portföyünü rasyonelleştirirken mevcut uygulamalar ve altyapı tarafından kısıtlanmaktadır. Docker, uygulamalar ve altyapı ile geliştiriciler ve BT operasyonları arasında gerçek bağımsızlığın potansiyelini ortaya çıkarmasını sağlar ve daha iyi işbirliği ve yenilik için bir model oluşturur.

Yani Docker konteyner görüntüleri ve mevcut makinede çalıştırılabilir kapları var, yani dayanır. VM'ler gibi işletim sistemini içermez , ancak Java, Tomcat vb.Gibi farklı çalışma paketleri gibi.

Eğer konteyner anlıyorsanız Docker ne olsun ve nasıl farklıdır VM s ...

Peki, konteyner nedir?

Kapsayıcı görüntüsü, çalıştırmak için gereken her şeyi içeren hafif, bağımsız, yürütülebilir bir yazılım paketidir: kod, çalışma zamanı, sistem araçları, sistem kitaplıkları, ayarlar. Hem Linux hem de Windows tabanlı uygulamalar için mevcut olan kapsayıcı yazılım, ortamdan bağımsız olarak her zaman aynı şekilde çalışır. Kapsayıcılar yazılımı, örneğin geliştirme ve hazırlama ortamları arasındaki farkları izole eder ve aynı altyapı üzerinde farklı yazılımlar çalıştıran takımlar arasındaki çatışmaları azaltmaya yardımcı olur.

Aşağıdaki resimde gördüğünüz gibi, her konteynerin ayrı bir paketi vardır ve o makinenin işletim sistemini tek bir makine paylaşımında çalışır ... Güvenli ve gönderilmesi kolaydır ...

Burada VM'ler ve kapsayıcılar arasındaki farkları ve Docker'ın kökenlerini açıkça tartışan birçok güzel teknik cevap var.

Benim için VM'ler ve Docker arasındaki temel fark, uygulamanızın tanıtımını nasıl yönettiğinizdir.

VM'ler ile uygulamanızı ve bağımlılıklarını bir VM'den bir sonraki DEV'ye, PR'dan UAT'a PRD'ye yükseltirsiniz.

1. Genellikle bu VM'lerin farklı yamaları ve kütüphaneleri olacaktır.
2. Birden fazla uygulamanın bir VM'yi paylaşması nadir değildir. Bu, tüm uygulamalar için yapılandırma ve bağımlılıkları yönetmeyi gerektirir.
3. Geri çekme, VM'de değişikliklerin geri alınmasını gerektirir. Veya mümkünse geri yükleme.

Docker ile fikir, uygulamanızı ihtiyaç duyduğu kütüphanelerle birlikte kendi kabının içinde paketlemeniz ve ardından tüm kabı tek bir birim olarak tanıtmanızdır .

1. Çekirdek dışında yamalar ve kütüphaneler aynıdır.
2. Genel bir kural olarak, konteyner başına yapılandırmayı basitleştiren yalnızca bir uygulama vardır.
3. Geri çekme, kabın durdurulması ve silinmesinden oluşur.

Böylece VM'lerle en temel düzeyde uygulamayı ve bağımsız bileşenler olarak bağımlılıklarını tanıtırken Docker ile her şeyi tek bir vuruşta tanıtabilirsiniz.

Ve evet, Kubernetes veya Docker Swarm gibi araçlar görevi büyük ölçüde basitleştirmesine rağmen, bunları yönetmek de dahil olmak üzere kaplarla ilgili sorunlar var.