it-swarm.dev

Bagaimana Docker berbeda dari mesin virtual?

Saya terus membaca ulang dokumentasi Docker untuk mencoba memahami perbedaan antara Docker dan VM penuh. Bagaimana cara mengatur untuk menyediakan sistem file penuh, lingkungan jaringan yang terisolasi, dll tanpa menjadi berat?

Mengapa menggunakan perangkat lunak untuk gambar Docker (jika itu istilah yang tepat) lebih mudah daripada hanya menggunakan untuk lingkungan produksi yang konsisten?

3325
zslayton

Docker awalnya menggunakan LinuX Containers (LXC), tetapi kemudian beralih ke runC (sebelumnya dikenal sebagai libcontainer ), yang berjalan dalam sistem operasi yang sama dengan Host-nya. Ini memungkinkannya untuk berbagi banyak sumber daya sistem operasi Host. Juga, ia menggunakan sistem file berlapis ( AuFS ) dan mengelola jaringan.

AuFS adalah sistem file berlapis, sehingga Anda dapat memiliki bagian hanya baca dan bagian tulis yang digabungkan. Seseorang dapat memiliki bagian umum dari sistem operasi sebagai hanya baca (dan dibagi di antara semua wadah Anda) dan kemudian memberikan masing-masing wadah mount sendiri untuk ditulis.

Jadi, katakanlah Anda memiliki gambar kontainer 1 GB; jika Anda ingin menggunakan VM penuh, Anda harus memiliki 1 GB x jumlah VM yang Anda inginkan. Dengan Docker dan AuFS Anda dapat berbagi sebagian besar 1 GB di antara semua wadah dan jika Anda memiliki 1000 kontainer Anda masih mungkin hanya memiliki sedikit lebih dari 1 GB ruang untuk wadah OS (dengan asumsi mereka semua menjalankan gambar OS yang sama) .

Sistem tervirtualisasi lengkap mendapatkan set sumber daya sendiri yang dialokasikan untuk itu, dan melakukan pembagian minimal. Anda mendapatkan lebih banyak isolasi, tetapi jauh lebih berat (membutuhkan lebih banyak sumber daya). Dengan Docker Anda mendapatkan lebih sedikit isolasi, tetapi wadahnya ringan (membutuhkan lebih sedikit sumber daya). Jadi Anda dapat dengan mudah menjalankan ribuan kontainer pada Host, dan itu bahkan tidak akan berkedip. Coba lakukan itu dengan Xen, dan kecuali Anda memiliki Host yang sangat besar, saya rasa itu tidak mungkin.

Sistem virtualisasi penuh biasanya membutuhkan waktu beberapa menit untuk memulai, sedangkan wadah Docker/LXC/runC membutuhkan waktu beberapa detik, dan seringkali bahkan kurang dari satu detik.

Ada pro dan kontra untuk setiap jenis sistem tervirtualisasi. Jika Anda ingin isolasi penuh dengan sumber daya yang dijamin, _ VM yang lengkap adalah cara untuk melakukannya. Jika Anda hanya ingin mengisolasi proses dari satu sama lain dan ingin menjalankan satu ton dari mereka pada Host berukuran cukup, maka Docker/LXC/runC tampaknya menjadi cara untuk pergi.

Untuk informasi lebih lanjut, lihat set posting blog ini yang melakukan pekerjaan dengan baik untuk menjelaskan cara kerja LXC.

Mengapa menyebarkan perangkat lunak ke gambar buruh pelabuhan (jika itu istilah yang tepat) lebih mudah daripada hanya menggunakan lingkungan produksi yang konsisten?

Menyebarkan lingkungan produksi yang konsisten lebih mudah diucapkan daripada dilakukan. Bahkan jika Anda menggunakan alat seperti Chef dan Wayang , selalu ada pembaruan OS dan hal-hal lain yang berubah antara host dan lingkungan.

Docker memberi Anda kemampuan untuk memotret OS menjadi gambar yang dibagikan, dan membuatnya mudah untuk digunakan pada host Docker lainnya. Secara lokal, dev, qa, prod, dll .: semua gambar yang sama. Tentu Anda bisa melakukan ini dengan alat lain, tetapi tidak semudah atau cepat.

Ini bagus untuk pengujian; katakanlah Anda memiliki ribuan tes yang perlu terhubung ke database, dan setiap tes membutuhkan salinan asli dari database dan akan membuat perubahan pada data. Pendekatan klasik untuk ini adalah mereset basis data setelah setiap pengujian baik dengan kode khusus atau dengan alat seperti Flyway - ini bisa sangat memakan waktu dan berarti tes harus dijalankan secara seri. Namun, dengan Docker Anda bisa membuat gambar dari database Anda dan menjalankan satu contoh per tes, dan kemudian menjalankan semua tes secara paralel karena Anda tahu mereka semua akan berjalan melawan snapshot yang sama dari database. Karena tes berjalan secara paralel dan dalam wadah Docker, mereka dapat menjalankan semua pada kotak yang sama pada waktu yang sama dan harus menyelesaikan lebih cepat. Coba lakukan itu dengan VM penuh.

Dari komentar ...

Menarik! Saya kira saya masih bingung dengan gagasan "snapshot [ting] OS". Bagaimana seseorang melakukannya tanpa, membuat gambar OS?

Baiklah, mari kita lihat apakah saya bisa menjelaskan. Anda mulai dengan gambar dasar, dan kemudian membuat perubahan Anda, dan melakukan perubahan itu menggunakan buruh pelabuhan, dan itu membuat gambar. Gambar ini hanya berisi perbedaan dari pangkalan. Ketika Anda ingin menjalankan gambar Anda, Anda juga membutuhkan basis, dan lapisan gambar Anda di atas basis menggunakan sistem file berlapis: seperti yang disebutkan di atas, Docker menggunakan AUFS. AUFS menggabungkan lapisan yang berbeda bersama-sama dan Anda mendapatkan apa yang Anda inginkan; Anda hanya perlu menjalankannya. Anda dapat terus menambahkan lebih banyak gambar (lapisan) dan itu akan terus menyimpan hanya diff. Karena Docker biasanya membangun di atas gambar yang sudah jadi dari registry , Anda jarang harus "memotret" sendiri seluruh OS.

3145
Ken Cochrane

Jawaban yang bagus Hanya untuk mendapatkan representasi gambar dari wadah vs VM, lihat yang di bawah ini.

 enter image description here

Sumber

463
manu97

Mungkin bermanfaat untuk memahami bagaimana virtualisasi dan wadah bekerja pada level rendah. Itu akan menjernihkan banyak hal.

Catatan: Saya sedikit menyederhanakan dalam menjelaskan di bawah ini. Lihat referensi untuk informasi lebih lanjut.

Bagaimana virtualisasi bekerja di level rendah?

Dalam hal ini manajer VM mengambil alih cincin CPU 0 (atau "mode root" pada CPU yang lebih baru) dan memotong semua panggilan istimewa yang dibuat oleh OS tamu untuk membuat ilusi bahwa OS tamu memiliki perangkat kerasnya sendiri. Fakta menyenangkan: Sebelum 1998 dianggap mustahil untuk mencapai hal ini dalam arsitektur x86 karena tidak ada cara untuk melakukan intersepsi semacam ini. Orang-orang di VMWare adalah yang pertama yang memiliki ide untuk menulis ulang byte yang dapat dieksekusi dalam memori untuk panggilan istimewa OS tamu untuk mencapai ini.

Efek bersihnya adalah virtualisasi memungkinkan Anda menjalankan dua OS yang sama sekali berbeda pada perangkat keras yang sama. Setiap OS tamu melewati semua proses bootstrap, memuat kernel dll. Anda dapat memiliki keamanan yang sangat ketat, misalnya, OS tamu tidak bisa mendapatkan akses penuh ke OS Host atau tamu lain dan mengacaukan semuanya.

Bagaimana wadah bekerja di level rendah?

Sekitar 2006 , orang-orang termasuk beberapa karyawan di Google menerapkan fitur level kernel baru yang disebut namespaces (namun gagasan long sebelum ada di FreeBSD ). Salah satu fungsi OS adalah untuk memungkinkan berbagi sumber daya global seperti jaringan dan disk ke proses. Bagaimana jika sumber daya global ini dibungkus dalam ruang nama sehingga mereka hanya dapat dilihat oleh proses yang berjalan di ruang nama yang sama? Katakanlah, Anda bisa mendapatkan potongan disk dan meletakkannya di namespace X dan kemudian proses yang berjalan di namespace Y tidak bisa melihat atau mengaksesnya. Demikian pula, proses dalam namespace X tidak dapat mengakses apa pun dalam memori yang dialokasikan ke namespace Y. Tentu saja, proses di X tidak dapat melihat atau berbicara dengan proses di namespace Y. Ini menyediakan semacam virtualisasi dan isolasi untuk sumber daya global. Beginilah cara buruh pelabuhan bekerja: Setiap kontainer berjalan di namespace-nya sendiri tetapi menggunakan kernel sama persis seperti semua kontainer lainnya. Isolasi terjadi karena kernel mengetahui namespace yang ditugaskan untuk proses dan selama panggilan API memastikan bahwa proses hanya dapat mengakses sumber daya di namespace sendiri.

Keterbatasan wadah vs VM seharusnya sudah jelas sekarang: Anda tidak dapat menjalankan OS yang sama sekali berbeda dalam wadah seperti di VM. Namun Anda bisa menjalankan berbagai distro Linux karena mereka berbagi kernel yang sama. Level isolasi tidak sekuat di VM. Bahkan, ada cara untuk wadah "tamu" untuk mengambil alih Host dalam implementasi awal. Anda juga dapat melihat bahwa ketika Anda memuat wadah baru, seluruh salinan baru OS tidak mulai seperti di VM. Semua wadah bagikan kernel yang sama . Inilah sebabnya mengapa wadah itu ringan. Juga tidak seperti VM, Anda tidak perlu mengalokasikan banyak memori ke wadah karena kami tidak menjalankan salinan OS yang baru. Hal ini memungkinkan untuk menjalankan ribuan kontainer pada satu OS sambil mem-sandbox mereka yang mungkin tidak dapat dilakukan jika kami menjalankan salinan OS yang terpisah di VM-nya sendiri.

408
Shital Shah

Saya suka jawaban Ken Cochrane.

Tapi saya ingin menambahkan sudut pandang tambahan, tidak dibahas secara rinci di sini. Menurut saya Docker juga berbeda dalam seluruh proses. Berbeda dengan VMs, Docker tidak (hanya) tentang berbagi sumber daya yang optimal dari perangkat keras, apalagi ia menyediakan "sistem" untuk aplikasi pengemasan (lebih disukai, tetapi bukan keharusan, sebagai seperangkat layanan microsoft).

Bagi saya itu cocok di celah antara alat berorientasi pengembang seperti rpm, Debian paket, Maven , npm + Git di satu sisi dan alat ops seperti Wayang , VMware, Xen, sebutkan saya t...

Mengapa menyebarkan perangkat lunak ke gambar buruh pelabuhan (jika itu istilah yang tepat) lebih mudah daripada hanya menggunakan lingkungan produksi yang konsisten?

Pertanyaan Anda mengasumsikan beberapa lingkungan produksi yang konsisten. Tapi bagaimana cara membuatnya konsisten? Pertimbangkan beberapa server (dan 10), beberapa tahapan dalam pipeline.

Untuk menjaga sinkronisasi ini, Anda akan mulai menggunakan sesuatu seperti Puppet, Chef atau skrip provisi Anda sendiri, aturan yang tidak dipublikasikan, dan/atau banyak dokumentasi ... Dalam teori server dapat berjalan tanpa batas waktu, dan dijaga agar tetap konsisten dan konsisten terkini. Praktik gagal untuk mengelola konfigurasi server sepenuhnya, sehingga ada ruang yang cukup untuk penyimpangan konfigurasi, dan perubahan tak terduga untuk menjalankan server.

Jadi ada pola yang diketahui untuk menghindari ini, yang disebutserver tidak berubah. Tetapi pola server yang kekal tidak disukai. Sebagian besar karena keterbatasan VM yang digunakan sebelum Docker. Berurusan dengan beberapa gigabytes gambar besar, memindahkan gambar-gambar besar itu, hanya untuk mengubah beberapa bidang dalam aplikasi, sangat sangat melelahkan. Bisa dimengerti ...

Dengan ekosistem Docker, Anda tidak perlu berpindah-pindah gigabyte pada "perubahan kecil" (terima kasih aufs dan Registry) dan Anda tidak perlu khawatir kehilangan kinerja dengan mengemas aplikasi ke dalam wadah Docker saat runtime. Anda tidak perlu khawatir tentang versi gambar itu.

Dan akhirnya Anda bahkan akan sering dapat mereproduksi lingkungan produksi yang kompleks bahkan pada laptop Linux Anda (jangan panggil saya jika tidak berfungsi dalam kasus Anda;))

Dan tentu saja Anda dapat memulai wadah Docker di VM (itu ide yang bagus). Kurangi penyediaan server Anda pada tingkat VM. Semua hal di atas dapat dikelola oleh Docker.

P.S. Sementara itu Docker menggunakan implementasi sendiri "libcontainer" bukan LXC. Tapi LXC masih dapat digunakan.

312
aholbreich

Docker bukan metodologi virtualisasi. Ini bergantung pada alat lain yang benar-benar menerapkan virtualisasi berbasis wadah atau virtualisasi tingkat sistem operasi. Untuk itu, Docker awalnya menggunakan driver LXC, kemudian pindah ke libcontainer yang sekarang diganti namanya menjadi runc. Docker terutama berfokus pada mengotomatiskan penyebaran aplikasi di dalam wadah aplikasi. Wadah aplikasi dirancang untuk mengemas dan menjalankan layanan tunggal, sedangkan wadah sistem dirancang untuk menjalankan beberapa proses, seperti mesin virtual. Jadi, Docker dianggap sebagai manajemen wadah atau alat penyebaran aplikasi pada sistem kemas.

Untuk mengetahui perbedaannya dari virtualisasi lain, mari kita lihat virtualisasi dan tipenya. Maka, akan lebih mudah untuk memahami apa bedanya di sana.

Virtualisasi

Dalam bentuknya, itu dianggap sebagai metode membagi mainframe secara logis untuk memungkinkan beberapa aplikasi berjalan secara bersamaan. Namun, skenario berubah secara drastis ketika perusahaan dan komunitas open source mampu menyediakan metode penanganan instruksi khusus dengan satu dan lain cara dan memungkinkan beberapa sistem operasi dijalankan secara bersamaan pada sistem berbasis x86 tunggal.

Hypervisor

Pegangan hypervisor menciptakan lingkungan virtual tempat mesin virtual tamu beroperasi. Itu mengawasi sistem tamu dan memastikan bahwa sumber daya dialokasikan untuk para tamu seperlunya. Hypervisor berada di antara mesin fisik dan mesin virtual dan menyediakan layanan virtualisasi ke mesin virtual. Untuk merealisasikannya, ia mencegat operasi sistem operasi tamu pada mesin virtual dan mengemulasi operasi pada sistem operasi mesin Host.

Pesatnya perkembangan teknologi virtualisasi, terutama di cloud, telah mendorong penggunaan virtualisasi lebih lanjut dengan memungkinkan beberapa server virtual dibuat pada satu server fisik dengan bantuan hypervisor, seperti Xen, VMware Player, KVM, dll., Dan penggabungan dukungan perangkat keras dalam prosesor komoditas, seperti Intel VT dan AMD-V.

Jenis Virtualisasi

Metode virtualisasi dapat dikategorikan berdasarkan bagaimana meniru perangkat keras ke sistem operasi tamu dan mengemulasi lingkungan operasi tamu. Terutama, ada tiga jenis virtualisasi:

  • Persaingan
  • Paravirtualization
  • Virtualisasi berbasis wadah

Emulasi

Emulation, juga dikenal sebagai virtualisasi penuh menjalankan kernel OS mesin virtual sepenuhnya dalam perangkat lunak. Hypervisor yang digunakan dalam tipe ini dikenal sebagai hypervisor Tipe 2. Itu diinstal di bagian atas sistem operasi Host yang bertanggung jawab untuk menerjemahkan kode kernel OS tamu ke instruksi perangkat lunak. Terjemahan dilakukan sepenuhnya dalam perangkat lunak dan tidak memerlukan keterlibatan perangkat keras. Emulasi memungkinkan untuk menjalankan sistem operasi apa pun yang tidak dimodifikasi yang mendukung lingkungan yang ditiru. Kelemahan dari jenis virtualisasi ini adalah overhead sistem sumber daya tambahan yang mengarah pada penurunan kinerja dibandingkan dengan jenis virtualisasi lainnya.

 Emulation

Contoh dalam kategori ini termasuk VMware Player, VirtualBox, QEMU, Bochs, Parallels, dll.

Paravirtualization

Paravirtualization, juga dikenal sebagai hypervisor Tipe 1, berjalan langsung pada perangkat keras, atau "bare-metal", dan menyediakan layanan virtualisasi langsung ke mesin virtual yang berjalan di atasnya. Ini membantu sistem operasi, perangkat keras virtual, dan perangkat keras nyata untuk berkolaborasi untuk mencapai kinerja yang optimal. Hypervisor ini biasanya memiliki tapak yang agak kecil dan tidak membutuhkan sumber daya yang luas.

Contoh dalam kategori ini termasuk Xen, KVM, dll.

 Paravirtualization

Virtualisasi berbasis wadah

Virtualisasi berbasis kontainer, juga dikenal sebagai virtualisasi tingkat sistem operasi, memungkinkan beberapa eksekusi terisolasi dalam satu kernel sistem operasi. Ini memiliki kinerja dan kepadatan terbaik dan fitur manajemen sumber daya yang dinamis. Lingkungan eksekusi virtual terisolasi yang disediakan oleh jenis virtualisasi ini disebut wadah dan dapat dilihat sebagai sekelompok proses yang dilacak.

 Container-based virtualization

Konsep sebuah wadah dimungkinkan oleh fitur namespaces yang ditambahkan ke kernel Linux versi 2.6.24. Kontainer menambahkan ID-nya ke setiap proses dan menambahkan pemeriksaan kontrol akses baru untuk setiap panggilan sistem. Itu diakses oleh panggilan sistem clone () yang memungkinkan membuat instance terpisah dari ruang nama yang sebelumnya global.

Ruang nama dapat digunakan dalam banyak cara berbeda, tetapi pendekatan yang paling umum adalah membuat wadah terisolasi yang tidak memiliki visibilitas atau akses ke objek di luar wadah. Proses yang berjalan di dalam wadah tampaknya berjalan pada sistem Linux normal meskipun mereka berbagi kernel yang mendasarinya dengan proses yang terletak di ruang nama lain, sama untuk jenis objek lainnya. Misalnya, saat menggunakan ruang nama, pengguna root di dalam wadah tidak diperlakukan sebagai root di luar wadah, menambah keamanan tambahan.

Subsistem Linux Control Groups (cgroups), komponen utama berikutnya yang memungkinkan virtualisasi berbasis wadah, digunakan untuk mengelompokkan proses dan mengelola konsumsi sumber daya agregat mereka. Ini biasanya digunakan untuk membatasi konsumsi memori dan CPU dari wadah. Karena sistem Linux kemas hanya memiliki satu kernel dan kernel memiliki visibilitas penuh ke dalam wadah, hanya ada satu tingkat alokasi sumber daya dan penjadwalan.

Beberapa alat manajemen tersedia untuk wadah Linux, termasuk LXC, LXD, systemd-nspawn, lmctfy, Warden, Linux-VServer, OpenVZ, Docker, dll.

Kontainer vs Mesin Virtual

Tidak seperti mesin virtual, wadah tidak perlu mem-boot kernel sistem operasi, sehingga wadah dapat dibuat dalam waktu kurang dari satu detik. Fitur ini membuat virtualisasi berbasis wadah unik dan diinginkan daripada pendekatan virtualisasi lainnya.

Karena virtualisasi berbasis-kontainer menambah sedikit atau tidak ada overhead pada mesin Host, virtualisasi berbasis-kontainer memiliki kinerja yang hampir sama dengan aslinya

Untuk virtualisasi berbasis wadah, tidak diperlukan perangkat lunak tambahan, tidak seperti virtualisasi lainnya.

Semua kontainer pada mesin Host berbagi penjadwal dari mesin Host menghemat kebutuhan sumber daya tambahan.

Status kontainer (gambar Docker atau LXC) berukuran kecil dibandingkan dengan gambar mesin virtual, sehingga gambar kontainer mudah didistribusikan.

Manajemen sumber daya dalam wadah dicapai melalui cgroup. Cgroups tidak memungkinkan kontainer mengkonsumsi lebih banyak sumber daya daripada yang dialokasikan untuk mereka. Namun, sampai sekarang, semua sumber daya mesin Host terlihat di mesin virtual, tetapi tidak dapat digunakan. Ini dapat diwujudkan dengan menjalankan top atau htop pada wadah dan mesin Host secara bersamaan. Output di semua lingkungan akan terlihat serupa.

Memperbarui:

Bagaimana Docker menjalankan kontainer di sistem non-Linux?

Jika kontainer dimungkinkan karena fitur yang tersedia di kernel Linux, maka pertanyaan yang jelas adalah bagaimana sistem non-Linux menjalankan kontainer. Docker untuk Mac dan Windows menggunakan VM Linux untuk menjalankan kontainer. Docker Toolbox digunakan untuk menjalankan kontainer di Virtual Box VMs. Tapi, Docker terbaru menggunakan Hyper-V di Windows dan Hypervisor.framework di Mac.

Sekarang, izinkan saya menjelaskan bagaimana Docker untuk Mac menjalankan kontainer secara detail.

Docker untuk Mac menggunakan https://github.com/moby/hyperkit untuk meniru kemampuan hypervisor dan Hyperkit menggunakan hypervisor.framework pada intinya. Hypervisor.framework adalah solusi hypervisor asli Mac. Hyperkit juga menggunakan VPNKit dan DataKit untuk masing-masing jaringan namespace dan sistem file.

Linux VM yang dijalankan Docker di Mac hanya-baca. Namun, Anda dapat menabraknya dengan menjalankan:

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

Sekarang, kita bahkan dapat memeriksa versi Kernel dari VM ini:

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

Semua kontainer dijalankan di dalam VM ini.

Ada beberapa batasan untuk hypervisor.framework. Karena itu Docker tidak mengekspos antarmuka jaringan docker0 di Mac. Jadi, Anda tidak dapat mengakses kontainer dari Host. Sampai sekarang, docker0 hanya tersedia di dalam VM.

Hyper-v adalah hypervisor asli di Windows. Mereka juga mencoba memanfaatkan kemampuan Windows 10 untuk menjalankan sistem Linux secara asli.

187
Ashish Bista

Melalui posting ini kita akan menggambar beberapa garis perbedaan antara VM dan LXC. Pertama-tama mari kita mendefinisikannya.

VM:

Mesin virtual mengemulasi lingkungan komputasi fisik, tetapi permintaan untuk CPU, memori, hard disk, jaringan, dan sumber daya perangkat keras lainnya dikelola oleh lapisan virtualisasi yang menerjemahkan permintaan ini ke perangkat keras fisik yang mendasarinya.

Dalam konteks ini VM disebut sebagai Tamu sementara lingkungan yang dijalankannya disebut Host.

LXCs:

Linux Containers (LXC) adalah kemampuan tingkat sistem operasi yang memungkinkan untuk menjalankan beberapa wadah Linux yang terisolasi, pada satu Host kontrol (Host LXC). Linux Containers berfungsi sebagai alternatif ringan untuk VM karena mereka tidak memerlukan hypervisor yaitu. Virtualbox, KVM, Xen, dll.

Sekarang, kecuali Anda dibius oleh Alan (Zach Galifianakis- dari seri Hangover) dan telah berada di Vegas selama setahun terakhir, Anda akan cukup sadar tentang lonjakan minat yang luar biasa untuk teknologi wadah Linux, dan jika saya akan spesifik satu wadah proyek yang telah membuat gebrakan di seluruh dunia dalam beberapa bulan terakhir adalah - Docker mengarah ke beberapa pendapat yang menggema bahwa lingkungan komputasi awan harus meninggalkan mesin virtual (VM) dan menggantinya dengan kontainer karena biaya overhead yang lebih rendah dan berpotensi kinerja yang lebih baik.

Tetapi pertanyaan besarnya adalah, apakah itu layak ?, apakah itu masuk akal?

sebuah. LXC adalah scoped ke instance dari Linux. Ini mungkin rasa yang berbeda dari Linux (misalnya wadah Ubuntu pada Host CentOS tetapi masih Linux.) Demikian pula, wadah berbasis Windows dicakup oleh contoh Windows sekarang jika kita melihat VMs mereka memiliki cakupan yang cukup luas dan menggunakan hypervisor Anda tidak terbatas pada sistem operasi Linux atau Windows.

b. LXC memiliki overhead yang rendah dan memiliki kinerja yang lebih baik dibandingkan dengan VM. Alat yaitu. Docker yang dibangun di atas bahu teknologi LXC telah menyediakan pengembang dengan platform untuk menjalankan aplikasi mereka dan pada saat yang sama telah memberdayakan orang-orang operasi dengan alat yang akan memungkinkan mereka untuk menyebarkan wadah yang sama di server produksi atau pusat data. Ia mencoba membuat pengalaman antara pengembang yang menjalankan aplikasi, mem-boot dan menguji aplikasi dan orang yang mengoperasikan aplikasi yang mulus, karena ini adalah di mana semua gesekan terletak dan tujuan DevOps adalah untuk memecah silo tersebut.

Jadi pendekatan terbaik adalah penyedia infrastruktur cloud harus mengadvokasi penggunaan VM dan LXC yang tepat, karena mereka masing-masing cocok untuk menangani beban kerja dan skenario tertentu.

Meninggalkan VM tidak praktis seperti sekarang. Jadi baik VM dan LXC memiliki keberadaan dan kepentingan masing-masing.

134
Pankaj Arora

Sebagian besar jawaban di sini berbicara tentang mesin virtual. Saya akan memberi Anda satu jawaban liner untuk pertanyaan ini yang telah membantu saya selama beberapa tahun terakhir menggunakan Docker. Ini:

Docker hanyalah cara mewah untuk menjalankan suatu proses, bukan mesin virtual.

Sekarang, izinkan saya menjelaskan sedikit lebih banyak tentang apa artinya itu. Mesin virtual adalah binatang mereka sendiri. Saya merasa ingin menjelaskan apa Docker adalah akan membantu Anda memahami ini lebih dari menjelaskan apa itu mesin virtual. Terutama karena ada banyak jawaban bagus di sini yang memberi tahu Anda secara tepat apa yang seseorang maksudkan ketika mereka mengatakan "mesin virtual". Begitu...

Wadah Docker hanyalah sebuah proses (dan anak-anaknya) yang dikelompokkan menggunakan cgroups di dalam kernel sistem Host dari sisa proses. Anda sebenarnya dapat melihat proses kontainer Docker Anda dengan menjalankan ps aux pada Host. Misalnya, memulai Apache2 "dalam sebuah wadah" hanya memulai Apache2 sebagai proses khusus pada Host. Itu baru saja dikotak-kotakkan dari proses lain pada mesin. Penting untuk dicatat bahwa wadah Anda tidak ada di luar masa proses kemas Anda. Ketika proses Anda mati, wadah Anda mati. Itu karena Docker mengganti pid 1 di dalam wadah Anda dengan aplikasi Anda (pid 1 biasanya adalah sistem init). Poin terakhir tentang pid 1 ini sangat penting.

Sejauh sistem file yang digunakan oleh masing-masing proses wadah, Docker menggunakan gambar yang didukung UnionFS , yang merupakan apa yang Anda unduh saat Anda melakukan docker pull ubuntu. Setiap "gambar" hanyalah serangkaian lapisan dan metadata terkait. Konsep layering sangat penting di sini. Setiap lapisan hanyalah perubahan dari lapisan di bawahnya. Misalnya, ketika Anda menghapus file di Dockerfile Anda saat membangun wadah Docker, Anda sebenarnya hanya membuat layer di atas lapisan terakhir yang mengatakan "file ini telah dihapus". Kebetulan, inilah mengapa Anda dapat menghapus file besar dari sistem file Anda, tetapi gambar masih membutuhkan ruang disk yang sama. File tersebut masih ada, di lapisan di bawah yang sekarang. Lapisan itu sendiri hanyalah tarbal file. Anda dapat menguji ini dengan docker save --output /tmp/ubuntu.tar ubuntu dan kemudian cd /tmp && tar xvf ubuntu.tar. Maka Anda bisa melihat-lihat. Semua direktori yang terlihat seperti hash panjang sebenarnya adalah layer individual. Masing-masing berisi file (layer.tar) dan metadata (json) dengan informasi tentang lapisan tertentu. Lapisan-lapisan itu hanya menggambarkan perubahan pada sistem file yang disimpan sebagai lapisan "di atas" keadaan aslinya. Saat membaca data "saat ini", sistem file membaca data seolah-olah hanya melihat lapisan perubahan paling atas. Itu sebabnya file tersebut tampaknya dihapus, meskipun masih ada di lapisan "sebelumnya", karena sistem file hanya melihat lapisan paling atas. Ini memungkinkan wadah yang sama sekali berbeda untuk berbagi lapisan sistem file mereka, meskipun beberapa perubahan signifikan mungkin terjadi pada sistem file pada lapisan paling atas di setiap wadah. Ini dapat menghemat banyak ruang disk saat wadah Anda berbagi lapisan gambar dasarnya. Namun, ketika Anda memasang direktori dan file dari sistem Host ke wadah Anda dengan volume, volume itu "memotong" UnionFS, sehingga perubahan tidak disimpan dalam lapisan.

Jaringan di Docker dicapai dengan menggunakan jembatan ethernet (disebut docker0 pada Host), dan antarmuka virtual untuk setiap kontainer di Host. Ini menciptakan subnet virtual di docker0 untuk wadah Anda untuk berkomunikasi "antara" satu sama lain. Ada banyak opsi untuk jaringan di sini, termasuk membuat subnet khusus untuk wadah Anda, dan kemampuan untuk "berbagi" tumpukan jaringan Host Anda agar wadah Anda dapat mengakses secara langsung.

Docker bergerak sangat cepat. Dokumentasi adalah beberapa dokumentasi terbaik yang pernah saya lihat. Itu umumnya ditulis dengan baik, ringkas, dan akurat. Saya sarankan Anda memeriksa dokumentasi yang tersedia untuk informasi lebih lanjut, dan percaya pada dokumentasi atas hal lain yang Anda baca online, termasuk Stack Overflow. Jika Anda memiliki pertanyaan spesifik, saya sangat menyarankan untuk bergabung dengan #docker di Freenode IRC dan bertanya di sana (Anda bahkan dapat menggunakan webchat Freenode untuk itu!).

116
L0j1k

Docker merangkum aplikasi dengan semua dependensinya.

Virtualizer mengenkapsulasi OS yang dapat menjalankan aplikasi apa pun yang biasanya dapat dijalankan pada mesin logam kosong.

75

Keduanya sangat berbeda. Docker ringan dan menggunakan LXC/libcontainer (yang bergantung pada kernel namespacing dan cgroups) dan tidak memiliki emulasi mesin/perangkat keras seperti hypervisor, KVM. Xen yang berat.

Docker dan LXC lebih ditujukan untuk sandboxing, containerisasi, dan isolasi sumber daya. Ia menggunakan API klon Host OS (saat ini hanya kernel Linux) yang menyediakan penempatan nama untuk IPC, NS (mount), jaringan, PID, UTS, dll.

Bagaimana dengan memori, I/O, CPU, dll? Itu dikontrol menggunakan cgroups di mana Anda dapat membuat grup dengan spesifikasi/pembatasan sumber daya (CPU, memori, dll) dan menempatkan proses Anda di sana. Di atas LXC, Docker menyediakan backend penyimpanan ( http://www.projectatomic.io/docs/filesystems/ ) mis., Union mount filesystem tempat Anda dapat menambahkan lapisan dan berbagi lapisan di antara ruang nama mount yang berbeda.

Ini adalah fitur yang kuat di mana gambar dasar biasanya hanya dapat dibaca dan hanya ketika wadah memodifikasi sesuatu di lapisan itu akan menulis sesuatu untuk partisi baca-tulis (a.k.a. salin saat menulis). Ini juga menyediakan banyak pembungkus lain seperti registri dan versi gambar.

Dengan LXC normal Anda harus datang dengan beberapa rootfs atau berbagi rootfs dan ketika dibagikan, dan perubahannya tercermin pada wadah lain. Karena banyak fitur yang ditambahkan ini, Docker lebih populer daripada LXC. LXC populer di lingkungan tertanam untuk menerapkan keamanan di sekitar proses yang terpapar ke entitas eksternal seperti jaringan dan UI. Docker populer di lingkungan cloud multi-tenancy di mana lingkungan produksi yang konsisten diharapkan.

VM yang normal (misalnya, VirtualBox dan VMware) menggunakan hypervisor, dan teknologi terkait telah mendedikasikan firmware yang menjadi lapisan pertama untuk OS pertama (Host OS, atau guest OS 0) atau perangkat lunak yang berjalan pada OS Host untuk memberikan emulasi perangkat keras seperti CPU, USB/aksesori, memori, jaringan, dll., ke OS tamu. VM masih (hingga 2015) populer di lingkungan multi-tenant dengan keamanan tinggi.

Docker/LXC hampir dapat dijalankan pada perangkat keras apa pun yang murah (memori kurang dari 1 GB juga OK selama Anda memiliki kernel yang lebih baru) vs. VM normal membutuhkan setidaknya 2 GB memori, dll., Untuk melakukan sesuatu yang berarti dengannya . Tetapi dukungan Docker pada OS Host tidak tersedia di OS seperti Windows (per November 2014) di mana jenis VM dapat dijalankan di windows, Linux, dan Mac.

Berikut ini foto dari buruh pelabuhan/rightscale:  Here is a pic from rightscale

56
resultsway

1. Ringan

Ini mungkin kesan pertama bagi banyak pelajar buruh pelabuhan.

Pertama, gambar buruh pelabuhan biasanya lebih kecil dari gambar VM, membuatnya mudah untuk dibuat, disalin, dibagikan.

Kedua, wadah Docker dapat dimulai dalam beberapa milidetik, sementara VM dimulai dalam hitungan detik.

2. Sistem File Berlapis

Ini adalah fitur kunci lain dari Docker. Gambar memiliki lapisan, dan gambar yang berbeda dapat berbagi lapisan, menjadikannya lebih hemat ruang dan lebih cepat untuk dibuat.

Jika semua wadah menggunakan Ubuntu sebagai gambar dasarnya, tidak setiap gambar memiliki sistem file sendiri, tetapi berbagi file ubuntu bergaris bawah yang sama, dan hanya berbeda dalam data aplikasi mereka sendiri.

3. Kernel OS yang Dibagikan

Pikirkan wadah sebagai proses!

Semua kontainer yang berjalan di Host memang sekelompok proses dengan sistem file yang berbeda. Mereka berbagi kernel OS yang sama, hanya merangkum perpustakaan sistem dan dependensi.

Ini bagus untuk sebagian besar kasus (tidak ada kernel OS tambahan yang dipertahankan) tetapi bisa menjadi masalah jika diperlukan isolasi yang ketat antar wadah.

Mengapa itu penting?

Semua ini tampak seperti perbaikan, bukan revolusi. Nah, akumulasi kuantitatif mengarah ke transformasi kualitatif .

Pikirkan tentang penyebaran aplikasi. Jika kami ingin menggunakan perangkat lunak (layanan) baru atau memutakhirkannya, lebih baik mengubah file dan proses konfigurasi daripada membuat VM baru. Karena Membuat VM dengan layanan yang diperbarui, mengujinya (berbagi antara Dev & QA), menggunakan untuk produksi membutuhkan waktu berjam-jam, bahkan berhari-hari. Jika ada yang salah, Anda harus mulai lagi, membuang lebih banyak waktu. Jadi, gunakan alat manajemen konfigurasi (boneka, saltstack, chef, dll.) Untuk menginstal perangkat lunak baru, lebih baik unduh file baru.

Ketika datang ke buruh pelabuhan, tidak mungkin untuk menggunakan wadah buruh pelabuhan yang baru dibuat untuk menggantikan yang lama. Maintainance jauh lebih mudah! Membangun gambar baru, membaginya dengan QA, mengujinya, menggunakannya hanya membutuhkan waktu beberapa menit (jika semuanya otomatis), berjam-jam dalam kasus terburuk. Ini disebut infrastruktur tidak berubah : jangan memelihara (meningkatkan) perangkat lunak, buat yang baru.

Ini mengubah cara layanan disampaikan. Kami menginginkan aplikasi, tetapi harus mempertahankan VM (yang menyulitkan dan tidak ada hubungannya dengan aplikasi kami). Docker membuat Anda fokus pada aplikasi dan menghaluskan segalanya.

29
cizixs

Docker, pada dasarnya wadah, mendukung virtualisasi OS i.e. aplikasi Anda merasa memiliki instans lengkap OS sedangkan VM mendukung virtualisasi perangkat keras . Anda merasa seperti itu adalah mesin fisik di mana Anda dapat mem-boot OS apa pun.

Di Docker, wadah yang menjalankan berbagi kernel OS Host, sedangkan di VM mereka memiliki file OS mereka sendiri. Lingkungan (OS) tempat Anda mengembangkan aplikasi akan sama ketika Anda menyebarkannya ke berbagai lingkungan penyajian, seperti "pengujian" atau "produksi".

Misalnya, jika Anda mengembangkan server web yang berjalan pada port 4000, ketika Anda menyebarkannya ke lingkungan "pengujian" Anda, port tersebut sudah digunakan oleh beberapa program lain, sehingga berhenti bekerja. Dalam wadah ada lapisan; semua perubahan yang Anda buat pada OS akan disimpan dalam satu atau lebih lapisan dan lapisan-lapisan itu akan menjadi bagian dari gambar, sehingga ke mana pun gambar bergerak, dependensi juga akan hadir.

Pada contoh di bawah ini, mesin Host memiliki tiga VM. Untuk menyediakan aplikasi dalam isolasi lengkap VM, mereka masing-masing memiliki salinan sendiri file OS, perpustakaan dan kode aplikasi, bersama dengan instance penuh-memori dari OS.  Without Containers Sedangkan gambar di bawah ini menunjukkan skenario yang sama dengan wadah. Di sini, wadah hanya berbagi sistem operasi Host, termasuk kernel dan pustaka, sehingga mereka tidak perlu mem-boot OS, memuat pustaka atau membayar biaya memori pribadi untuk file-file itu. Satu-satunya ruang tambahan yang mereka ambil adalah setiap memori dan ruang disk yang diperlukan untuk menjalankan aplikasi dalam wadah. Meskipun lingkungan aplikasi terasa seperti OS khusus, aplikasi tersebut menerapkannya seperti layaknya ke Host khusus. Aplikasi kemas dimulai dalam hitungan detik dan lebih banyak contoh aplikasi dapat masuk ke mesin daripada dalam kasus VM.  enter image description here

Sumber: https://Azure.Microsoft.com/en-us/blog/containers-docker-windows-and-trends/

22
Ali Kahoot

Ada banyak jawaban yang menjelaskan lebih rinci perbedaannya, tetapi inilah penjelasan singkat saya.

Satu perbedaan penting adalah bahwa VM menggunakan kernel terpisah untuk menjalankan OS . Itulah alasannya berat dan membutuhkan waktu untuk boot, menghabiskan lebih banyak sumber daya sistem.

Di Docker, wadah berbagi kernel dengan Host; karenanya ringan dan dapat memulai dan berhenti dengan cepat.

Dalam Virtualisasi, sumber daya dialokasikan pada awal pengaturan dan karenanya sumber daya tidak sepenuhnya digunakan ketika mesin virtual menganggur selama banyak waktu. Dalam Docker, kontainer tidak dialokasikan dengan jumlah sumber daya perangkat keras yang tetap dan bebas untuk menggunakan sumber daya tergantung pada persyaratan dan karenanya sangat skalabel.

Docker menggunakan UNION sistem file .. Docker menggunakan teknologi copy-on-write untuk mengurangi ruang memori yang dikonsumsi oleh kontainer. Baca lebih lanjut di sini

18
Jayabalan Bala

Ada tiga pengaturan berbeda yang menyediakan tumpukan untuk menjalankan aplikasi (Ini akan membantu kita mengenali apa itu wadah dan apa yang membuatnya jauh lebih kuat daripada solusi lain):

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

1) Server tradisional stack terdiri dari server fisik yang menjalankan sistem operasi dan aplikasi Anda.

Keuntungan:

  • Pemanfaatan sumber daya mentah

  • Isolasi

Kekurangan:

  • Waktu penyebaran sangat lambat
  • Mahal
  • Sumber daya terbuang
  • Sulit untuk skala
  • Sulit untuk bermigrasi
  • Konfigurasi yang kompleks

2) VM stack terdiri dari server fisik yang menjalankan sistem operasi dan hypervisor yang mengelola mesin virtual Anda, sumber daya bersama, dan antarmuka jaringan. Setiap Vm menjalankan Sistem Operasi Tamu, aplikasi atau serangkaian aplikasi.

Keuntungan:

  • Penggunaan sumber daya yang baik
  • Mudah diukur
  • Mudah dicadangkan dan dimigrasi
  • Penghematan biaya
  • Fleksibilitas

Kekurangan:

  • Alokasi sumber daya bermasalah
  • Vendor lockin
  • Konfigurasi yang kompleks

3) Pengaturan Container , perbedaan utama dengan stack lainnya adalah virtualisasi berbasis kontainer menggunakan kernel dari OS Host untuk rum beberapa instance tamu yang terisolasi. Mesin virtual tamu ini disebut sebagai wadah. Host dapat berupa server fisik atau VM.

Keuntungan:

  • Isolasi
  • Ringan
  • Sumberdaya efektif
  • Mudah dimigrasi
  • Keamanan
  • Overhead rendah
  • Produksi cermin dan lingkungan pengembangan

Kekurangan:

  • Arsitektur yang Sama
  • Aplikasi sumber daya berat
  • Masalah jaringan dan keamanan.

Dengan membandingkan pengaturan wadah dengan pendahulunya, kita dapat menyimpulkan bahwa kontainerisasi adalah pengaturan tercepat, paling efektif sumber daya, dan paling aman yang kita ketahui sampai saat ini. Wadah adalah contoh terisolasi yang menjalankan aplikasi Anda. Docker memutar wadah dengan cara, lapisan dapat menjalankan memori waktu dengan driver penyimpanan default (driver overlay) yang berjalan dalam hitungan detik dan lapisan copy-on-write dibuat di atasnya setelah kita masukkan ke dalam wadah, yang memberi daya pada pelaksanaan kontainer. Dalam kasus VM yang akan memakan waktu sekitar satu menit untuk memuat semuanya ke lingkungan virtualisasi. Mesin virtual ringan ini dapat diganti, dibangun kembali, dan dipindah-pindahkan dengan mudah. Ini memungkinkan kita untuk mencerminkan lingkungan produksi dan pengembangan dan sangat membantu dalam proses CI/CD. Keuntungan yang dapat diberikan kontainer sangat menarik sehingga mereka pasti ada di sini untuk menginap.

18
mohan08p

Berhubungan dengan:-

"Mengapa menyebarkan perangkat lunak ke gambar buruh pelabuhan lebih mudah daripada hanya menggunakan lingkungan produksi yang konsisten?"

Sebagian besar perangkat lunak digunakan untuk berbagai lingkungan, biasanya minimal tiga dari yang berikut:

  1. PC pengembang individu
  2. Lingkungan pengembang bersama
  3. PC penguji individual
  4. Lingkungan pengujian bersama
  5. Lingkungan QA
  6. Lingkungan UAT
  7. Pengujian beban/kinerja
  8. Pementasan langsung
  9. Produksi
  10. Arsipkan

Ada juga faktor-faktor berikut yang perlu dipertimbangkan:

  • Pengembang, dan tentu saja penguji, semuanya akan memiliki konfigurasi PC yang sangat berbeda atau sangat berbeda, sesuai dengan sifat pekerjaannya.
  • Pengembang sering dapat mengembangkan pada PC di luar kendali aturan standardisasi perusahaan atau bisnis (mis. Freelancer yang mengembangkan pada mesin mereka sendiri (sering jarak jauh) atau kontributor untuk proyek sumber terbuka yang tidak 'dipekerjakan' atau 'dikontrak' untuk mengkonfigurasi PC mereka dengan cara tertentu. cara)
  • Beberapa lingkungan akan terdiri dari sejumlah mesin tetap dalam konfigurasi beban seimbang
  • Banyak lingkungan produksi akan membuat server berbasis cloud secara dinamis (atau 'elastis') dibuat dan dimusnahkan tergantung pada tingkat lalu lintas

Seperti yang Anda lihat, jumlah total server yang diekstrapolasi jarang dalam angka tunggal, sangat sering dalam angka tripel dan masih dapat secara signifikan lebih tinggi lagi.

Ini semua berarti bahwa menciptakan lingkungan yang konsisten di tempat pertama cukup sulit hanya karena volume semata (bahkan dalam skenario lapangan hijau), tetapi menjaga mereka tetap konsisten adalah tidak mungkin mengingat banyaknya server, penambahan server baru server (secara dinamis atau manual), pembaruan otomatis dari vendor/vendor, vendor anti-virus, vendor browser dan sejenisnya, instalasi perangkat lunak manual atau perubahan konfigurasi yang dilakukan oleh pengembang atau teknisi server, dll. Saya ulangi - itu sebenarnya (tidak ada pun intended) tidak mungkin untuk menjaga lingkungan yang konsisten (oke, bagi purist, itu bisa dilakukan, tetapi itu melibatkan sejumlah besar waktu, usaha dan disiplin, itulah sebabnya mengapa VM dan wadah (misalnya Docker) dirancang pada awalnya ).

Jadi pikirkan pertanyaan Anda lebih seperti ini "Mengingat kesulitan ekstrim menjaga semua lingkungan konsisten, apakah lebih mudah untuk menggunakan perangkat lunak ke gambar buruh pelabuhan, bahkan ketika memperhitungkan kurva pembelajaran?" . Saya pikir Anda akan menemukan jawabannya akan selalu "ya" - tetapi hanya ada satu cara untuk mengetahuinya, posting pertanyaan baru ini pada Stack Overflow.

17
Greg Trevellick

Dengan mesin virtual , kami memiliki server, kami memiliki sistem operasi Host di server itu, dan kemudian kami memiliki hypervisor. Dan kemudian berjalan di atas hypervisor itu, kami memiliki sejumlah sistem operasi tamu dengan aplikasi dan binari yang bergantung padanya, dan pustaka pada server itu. Ini membawa sistem operasi seluruh tamu dengan itu. Ini kelas berat. Juga ada batasan berapa banyak Anda benar-benar dapat memakai setiap mesin fisik.

 Enter image description here

Kontainer Docker di sisi lain, sedikit berbeda. Kami memiliki server. Kami memiliki sistem operasi Host. Tapi bukan hypervisor , kami memiliki mesin Docker , dalam hal ini. Dalam hal ini, kami tidak membawa seluruh sistem operasi tamu. Kami membawa lapisan yang sangat tipis dari sistem operasi , dan wadah dapat berbicara ke dalam OS Host untuk mendapatkan fungsionalitas kernel di sana. Dan itu memungkinkan kita untuk memiliki wadah yang sangat ringan.

Semua yang ada di sana adalah kode aplikasi dan semua binari dan perpustakaan yang diperlukannya. Dan binari dan pustaka tersebut sebenarnya dapat dibagikan di berbagai wadah jika Anda menginginkannya juga. Dan hal ini memungkinkan kita untuk melakukan, adalah sejumlah hal. Mereka memiliki waktu startup lebih cepat . Anda tidak dapat berdiri satu pun VM dalam beberapa detik seperti itu. Dan sama-sama, menurunkannya dengan cepat .. sehingga kita dapat naik turun dengan sangat cepat dan kita akan melihatnya nanti.

 Enter image description here

Setiap kontainer berpikir bahwa itu berjalan pada salinan sistem operasinya sendiri. Itu punya sistem file sendiri, registry sendiri, dll yang merupakan semacam kebohongan. Ini sebenarnya sedang divirtualisasi.

12
Nedzad G

Saya telah menggunakan Docker di lingkungan produksi dan pementasan sangat banyak. Ketika Anda terbiasa, Anda akan menemukannya sangat kuat untuk membangun wadah multi dan lingkungan yang terisolasi.

Docker telah dikembangkan berdasarkan LXC (Linux Container) dan berfungsi dengan baik di banyak distribusi Linux, terutama Ubuntu.

Wadah buruh pelabuhan adalah lingkungan yang terisolasi. Anda dapat melihatnya saat Anda mengeluarkan perintah top dalam wadah Docker yang telah dibuat dari gambar Docker.

Selain itu, mereka sangat ringan dan fleksibel berkat konfigurasi dockerFile.

Sebagai contoh, Anda dapat membuat gambar Docker dan mengkonfigurasi DockerFile dan memberi tahu bahwa misalnya ketika sedang berjalan lalu wget 'this', apt-get 'that', jalankan 'some script Shell', setel variabel lingkungan dan sebagainya.

Dalam proyek layanan mikro dan arsitektur Docker adalah aset yang sangat layak. Anda dapat mencapai skalabilitas, ketahanan, dan elastisitas dengan Docker, Docker swarm, Kubernetes dan Docker Compose.

Masalah penting lainnya tentang Docker adalah Docker Hub dan komunitasnya. Sebagai contoh, saya menerapkan ekosistem untuk memantau kafka menggunakan Prometheus, Grafana, Prometheus-JMX-Eksportir, dan Dokcer.

Untuk melakukan itu saya mengunduh wadah Docker yang dikonfigurasi untuk zookeeper, kafka, Prometheus, Grafana dan jmx-collector kemudian memasang konfigurasi saya sendiri untuk beberapa di antaranya menggunakan file yml atau yang lain, saya mengubah beberapa file dan konfigurasi dalam wadah Docker dan saya membangun keseluruhan sistem untuk memantau kafka menggunakan Dockers multi-kontainer pada satu mesin dengan isolasi dan skalabilitas dan ketahanan yang arsitektur ini dapat dengan mudah dipindahkan ke beberapa server.

Selain situs Docker Hub ada situs lain bernama quay.io yang dapat Anda gunakan untuk memiliki dashboard gambar Docker Anda sendiri di sana dan tarik/Push ke/dari sana. Anda bahkan dapat mengimpor gambar Docker dari Docker Hub ke dermaga lalu menjalankannya dari dermaga di mesin Anda sendiri.

Catatan: Mempelajari Docker di tempat pertama tampaknya rumit dan sulit, tetapi ketika Anda terbiasa maka Anda tidak dapat bekerja tanpanya.

Saya ingat hari-hari pertama bekerja dengan Docker ketika saya mengeluarkan perintah yang salah atau menghapus kontainer saya dan semua data dan konfigurasi salah.

9
Touraj Ebrahimi

Difference between how apps in VM use cpu vs containers

Sumber: Kubernetes in Action.

6
TastyCode

Ini adalah bagaimana Docker memperkenalkan dirinya:

Docker adalah perusahaan yang menggerakkan pergerakan wadah dan satu-satunya penyedia platform wadah untuk menangani setiap aplikasi di cloud hybrid. Bisnis saat ini berada di bawah tekanan untuk mentransformasi secara digital tetapi dibatasi oleh aplikasi dan infrastruktur yang ada sambil merasionalisasi portofolio awan, pusat data, dan arsitektur aplikasi yang semakin beragam. Docker memungkinkan kemandirian sejati antara aplikasi dan infrastruktur dan pengembang dan operasi TI untuk membuka potensi mereka dan menciptakan model kolaborasi dan inovasi yang lebih baik.

Jadi Docker berbasis wadah, artinya Anda memiliki gambar dan wadah yang dapat dijalankan pada mesin Anda saat ini. Ini tidak termasuk sistem operasi sepertiVMs, tetapi seperti paket paket kerja yang berbeda seperti Java, Tomcat, dll.

Jika Anda memahami wadah, Anda mendapatkan apa itu Docker dan apa bedanya denganVMs ...

Jadi, apa itu wadah?

Gambar kontainer adalah paket perangkat lunak yang ringan, berdiri sendiri, dapat dieksekusi yang mencakup semua yang diperlukan untuk menjalankannya: kode, runtime, alat sistem, pustaka sistem, pengaturan. Tersedia untuk aplikasi berbasis Linux dan Windows, perangkat lunak kemas akan selalu berjalan sama, apa pun lingkungannya. Wadah mengisolasi perangkat lunak dari lingkungannya, misalnya perbedaan antara pengembangan dan lingkungan pementasan dan membantu mengurangi konflik antara tim yang menjalankan perangkat lunak berbeda pada infrastruktur yang sama.

 Docker

Jadi seperti yang Anda lihat pada gambar di bawah ini, setiap wadah memiliki paket terpisah dan berjalan pada satu mesin berbagi sistem operasi mesin ... Mereka aman dan mudah untuk dikirim ...

5
Alireza

Ada banyak jawaban teknis yang bagus di sini yang dengan jelas membahas perbedaan antara VM dan wadah serta asal-usul Docker.

Bagi saya perbedaan mendasar antara VM dan Docker adalah bagaimana Anda mengelola promosi aplikasi Anda.

Dengan VM, Anda mempromosikan aplikasi dan ketergantungannya dari satu VM ke DEV berikutnya menjadi UAT hingga PRD.

  1. Seringkali VM ini memiliki patch dan pustaka yang berbeda.
  2. Tidak jarang banyak aplikasi berbagi VM. Ini memerlukan pengelolaan konfigurasi dan dependensi untuk semua aplikasi.
  3. Backout membutuhkan pembatalan perubahan di VM. Atau mengembalikannya jika memungkinkan.

Dengan Docker idenya adalah bahwa Anda menggabungkan aplikasi Anda di dalam wadahnya sendiri bersama dengan perpustakaan yang dibutuhkannya dan kemudian mempromosikan wadah seluruh sebagai satu kesatuan.

  1. Kecuali untuk kernel, tambalan dan pustaka identik.
  2. Sebagai aturan umum, hanya ada satu aplikasi per kontainer yang menyederhanakan konfigurasi.
  3. Backout terdiri dari menghentikan dan menghapus wadah.

Jadi pada level paling mendasar dengan VM Anda mempromosikan aplikasi dan dependensinya sebagai komponen diskrit sedangkan dengan Docker Anda mempromosikan semuanya dalam satu pukulan.

Dan ya ada masalah dengan kontainer termasuk mengelola mereka meskipun alat seperti Kubernetes atau Docker Swarm sangat menyederhanakan tugas.

4
TJA