Pertanyaan Bagaimana Docker berbeda dari mesin virtual?


Saya terus membaca ulang Dokumentasi Docker untuk mencoba memahami perbedaan antara Docker dan VM penuh. Bagaimana cara kerjanya untuk menyediakan filesystem lengkap, lingkungan jaringan yang terisolasi, dll. Tanpa menjadi berat?

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


2910
2018-04-16 21:19


asal


Jawaban:


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

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

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

Sebuah sistem virtualisasi penuh mendapatkan sumber dayanya sendiri yang dialokasikan untuknya, dan melakukan pembagian minimal. Anda mendapatkan lebih banyak isolasi, tetapi jauh lebih berat (membutuhkan lebih banyak sumber daya). Dengan Docker Anda mendapatkan 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 tidak berpikir itu mungkin.

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

Ada pro dan kontra untuk setiap jenis sistem virtualisasi. Jika Anda ingin isolasi penuh dengan sumber daya terjamin, VM lengkap adalah cara yang tepat. Jika Anda hanya ingin mengisolasi proses dari satu sama lain dan ingin menjalankan satu ton dari mereka pada host ukuran yang wajar, maka Docker / LXC / runC tampaknya menjadi cara untuk pergi.

Untuk informasi lebih lanjut, periksa kumpulan posting blog ini yang melakukan pekerjaan dengan baik menjelaskan bagaimana LXC bekerja.

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

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

Docker memberi Anda kemampuan untuk snapshot OS menjadi gambar bersama, dan membuatnya mudah untuk diterapkan pada host Docker lainnya. Secara lokal, dev, qa, prod, dll: semua gambar yang sama. Tentu Anda dapat 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 murni dari database dan akan membuat perubahan pada data. Pendekatan klasik untuk ini adalah untuk me-reset database setelah setiap tes baik dengan kode kustom atau dengan alat-alat seperti Jalur Terbang - ini bisa sangat memakan waktu dan berarti tes harus dijalankan secara serial. Namun, dengan Docker Anda dapat membuat gambar dari database Anda dan menjalankan satu contoh per pengujian, dan kemudian menjalankan semua tes secara paralel karena Anda tahu mereka semua akan berjalan terhadap snapshot yang sama dari database. Karena pengujian berjalan secara paralel dan dalam kontainer Docker mereka dapat menjalankan semuanya pada kotak yang sama pada saat yang bersamaan dan akan selesai lebih cepat. Coba lakukan itu dengan VM lengkap.

Dari komentar ...

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

Baiklah, mari kita lihat apakah saya bisa menjelaskan. Anda mulai dengan gambar dasar, lalu buat perubahan Anda, dan lakukan perubahan tersebut menggunakan buruh pelabuhan, dan itu menciptakan gambar. Gambar ini hanya berisi perbedaan dari basis. Ketika Anda ingin menjalankan gambar Anda, Anda juga perlu basis, dan layer gambar Anda di atas basis menggunakan sistem file berlapis: seperti yang disebutkan di atas, Docker menggunakan AUFS. AUFS menggabungkan lapisan yang berbeda bersama dan Anda mendapatkan apa yang Anda inginkan; Anda hanya perlu menjalankannya. Anda dapat terus menambahkan lebih banyak gambar (lapisan) dan itu akan terus hanya menyimpan diffs. Karena Docker biasanya dibangun di atas gambar siap pakai dari registri, Anda jarang harus "snapshot" seluruh OS sendiri.


2807
2018-04-16 22:35



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

enter image description here

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


338
2017-10-14 18:02



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

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

Bagaimana virtualisasi bekerja pada level rendah?

Dalam hal ini manajer VM mengambil alih cincin CPU 0 (atau "mode root" di CPU yang lebih baru) dan memotong semua panggilan istimewa yang dibuat oleh OS tamu untuk menciptakan ilusi bahwa OS tamu memiliki perangkat kerasnya sendiri. Fakta menarik: Sebelum tahun 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 bahwa virtualisasi memungkinkan Anda menjalankan dua OS yang sama sekali berbeda pada perangkat keras yang sama. Setiap OS tamu menjalani semua proses bootstrap, memuat kernel, dll. Anda dapat memiliki keamanan yang sangat ketat, misalnya, OS tamu tidak dapat memperoleh akses penuh ke host OS atau tamu lain dan mengacaukan segalanya.

Bagaimana cara kerja kontainer pada level rendah?

Sekitar 2006, orang-orang termasuk beberapa karyawan di Google menerapkan fitur tingkat kernel baru yang disebut ruang nama (Namun ide itu panjang sebelum ada di FreeBSD). Salah satu fungsi dari 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 hanya dapat dilihat oleh proses yang berjalan di ruang nama yang sama? Katakanlah, Anda bisa mendapatkan sepotong disk dan memasukkannya ke dalam namespace X dan kemudian proses yang berjalan di namespace Y tidak dapat melihat atau mengaksesnya. Demikian pula, proses dalam namespace X tidak dapat mengakses apa pun dalam memori yang dialokasikan untuk namespace Y. Tentu saja, proses di X tidak dapat melihat atau berbicara dengan proses dalam namespace Y. Ini menyediakan semacam virtualisasi dan isolasi untuk sumber daya global. Ini adalah cara kerja buruh pelabuhan: Setiap kontainer berjalan di ruang namanya sendiri tetapi menggunakan persis sama kernel sebagai semua kontainer lainnya. Isolasi terjadi karena kernel tahu namespace yang ditugaskan untuk proses dan selama API memanggil itu memastikan bahwa proses hanya dapat mengakses sumber daya di namespace sendiri.

Keterbatasan kontainer vs VM harus jelas sekarang: Anda tidak dapat menjalankan OS yang benar-benar berbeda dalam wadah seperti di VM. Bagaimanapun kamu bisa menjalankan distro Linux yang berbeda karena mereka berbagi kernel yang sama. Tingkat isolasi tidak sekuat pada VM. Bahkan, ada cara untuk "tamu" kontainer untuk mengambil alih host dalam implementasi awal. Anda juga dapat melihat bahwa ketika Anda memuat kontainer baru, seluruh salinan OS yang baru tidak mulai seperti yang dilakukannya di VM. Semua kontainer berbagi kernel yang sama. Inilah mengapa kontainer ringan. Juga tidak seperti VM, Anda tidak harus mengalokasikan sebagian besar memori ke penampung karena kami tidak menjalankan salinan OS yang baru. Hal ini memungkinkan untuk menjalankan ribuan kontainer di satu OS saat melakukan sandboxing yang mungkin tidak dapat dilakukan jika kami menjalankan salinan OS yang terpisah di VM-nya sendiri.


294
2018-01-13 01:49



Saya suka jawaban Ken Cochrane.

Tetapi saya ingin menambahkan sudut pandang tambahan, tidak tercakup secara rinci di sini. Menurut pendapat saya Docker juga berbeda dalam seluruh proses. Berbeda dengan VM, Docker tidak (hanya) berbagi sumber daya perangkat keras secara optimal, apalagi ia menyediakan "sistem" untuk aplikasi pengemasan (Lebih disukai tetapi bukan keharusan, sebagai serangkaian Layanan-Layanan).

Bagi saya itu cocok di celah antara alat-alat Berorientasi Pengembang seperti rpm, paket debian, maven, npm + git di satu sisi dan alat Ops seperti Wayang, VMWare, Xen apa saja ...

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

Pertanyaan Anda mengasumsikan lingkungan produksi yang konsisten. Tetapi bagaimana menjaganya tetap konsisten?  Pertimbangkan beberapa jumlah (> 10) server dan aplikasi, tahapan dalam pipa. Untuk menjaga ini tetap sinkron Anda akan mulai menggunakan sesuatu seperti Puppet, Chef atau skrip Anda sendiri, aturan yang tidak diterbitkan dan / atau banyak dokumentasi ... Dalam server teori dapat berjalan tanpa batas, dan dijaga sepenuhnya konsisten dan up to date. Praktik gagal untuk mengelola konfigurasi server sepenuhnya, jadi ada cakupan yang cukup besar untuk konfigurasi drift, dan perubahan tak terduga pada server yang sedang berjalan.

Jadi ada pola yang diketahui untuk menghindari ini, yang disebut Server Tidak Bergerak. Tapi pola server yang tidak berubah itu tidak dicintai. Sebagian besar karena keterbatasan VM itu digunakan sebelum Docker. Berurusan dengan beberapa gambar besar Gigabytes, memindahkan gambar-gambar besar di sekitar, hanya untuk mengubah beberapa bidang dalam aplikasi, sangat sangat melelahkan. Bisa dimengerti ...

Dengan ekosistem Docker, Anda tidak akan perlu bergerak di sekitar Gigabytes pada "perubahan kecil" (Terima kasih aufs dan Registry) dan Anda tidak perlu khawatir tentang kehilangan kinerja dengan aplikasi kemasan ke dalam wadah Docker pada saat runtime. Anda tidak perlu khawatir tentang versi gambar itu. Dan akhirnya Anda bahkan akan sering dapat mereproduksi lingkungan produksi yang kompleks bahkan di laptop linux Anda (jangan panggil saya jika tidak berhasil dalam kasus Anda;))

Dan tentu saja Anda dapat memulai kontainer buruh pelabuhan di VM (ini ide yang bagus). Kurangi penyediaan server Anda di tingkat VM. Semua hal di atas dapat dikelola oleh Docker.

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


279
2017-09-19 16:21



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

Untuk mengetahui bagaimana hal itu berbeda dari virtualisasi lainnya, mari melalui virtualisasi dan jenisnya. Maka, akan lebih mudah untuk memahami apa bedanya di sana.

Virtualisasi

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

Hypervisor

Hypervisor menangani pembuatan lingkungan virtual tempat mesin virtual tamu beroperasi. Ini 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 mewujudkannya, ia memotong 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 untuk dibuat pada server fisik tunggal 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 untuk sistem operasi tamu dan mengemulasi lingkungan operasi tamu. Terutama, ada tiga jenis virtualisasi:

  • Emulasi
  • Paravirtualization
  • Virtualisasi berbasis kontainer

Emulasi

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

Emulation

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

Paravirtualization

Paravirtualization, juga dikenal sebagai Tipe 1 hypervisor, 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 yang nyata untuk berkolaborasi untuk mencapai kinerja yang optimal. Hypervisors ini biasanya memiliki jejak yang agak kecil dan tidak, sendiri, membutuhkan sumber daya yang luas.

Contoh dalam kategori ini termasuk Xen, KVM, dll.

Paravirtualization

Virtualisasi berbasis Container

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

Container-based virtualization

Konsep wadah dimungkinkan oleh fitur ruang nama ditambahkan ke kernel Linux versi 2.6.24. Penampung menambahkan ID-nya ke setiap proses dan menambahkan pemeriksaan kontrol akses baru ke setiap panggilan sistem. Ini diakses oleh klon() panggilan sistem yang memungkinkan pembuatan instance terpisah dari ruang nama global sebelumnya.

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

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

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

Wadah vs Mesin Virtual

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

Karena virtualisasi berbasis wadah menambahkan sedikit atau tidak ada biaya overhead ke mesin host, virtualisasi berbasis kontainer memiliki kinerja mendekati-pribumi

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

Semua kontainer pada mesin host berbagi penjadwal kebutuhan penghematan mesin host dari 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. Cgroup tidak mengizinkan kontainer untuk mengkonsumsi lebih banyak sumber daya daripada yang dialokasikan untuk mereka. Namun, seperti sekarang, semua sumber daya mesin host terlihat di mesin virtual, tetapi tidak dapat digunakan. Ini bisa diwujudkan dengan berlari top atau htop pada kontainer dan mesin host pada saat bersamaan. Output di semua lingkungan akan terlihat serupa.


121
2018-04-02 00:55



Melalui posting ini kita akan menggambar beberapa garis perbedaan antara VMs dan LXCs. Pertama mari kita definisikan mereka.

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 sistem operasi tingkat kemampuan yang memungkinkan untuk menjalankan beberapa kontainer Linux yang terisolasi, pada satu host kontrol (host LXC). Linux Containers berfungsi sebagai alternatif yang ringan untuk VM karena mereka tidak memerlukan hypervisors 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 sangat sadar tentang dorongan luar biasa yang menarik bagi 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 menggemakan bahwa lingkungan komputasi awan harus meninggalkan mesin virtual (VM) dan menggantinya dengan kontainer karena overhead yang lebih rendah dan kinerja yang berpotensi lebih baik.

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

Sebuah. LXC scoped ke sebuah instance dari Linux. Ini mungkin rasa Linux yang berbeda (misalnya wadah Ubuntu pada host CentOS tapi masih Linux.) Demikian pula, kontainer berbasis Windows yang dicakupkan ke instance Windows sekarang jika kita melihat VMs mereka memiliki lingkup 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 VMs. Alat yaitu. Docker yang dibangun di atas bahu teknologi LXC telah menyediakan platform bagi pengembang untuk menjalankan aplikasi mereka dan pada saat yang sama telah memberdayakan operasi orang dengan alat yang akan memungkinkan mereka untuk menggunakan kontainer yang sama di server produksi atau pusat data. Ini mencoba untuk membuat pengalaman antara pengembang menjalankan aplikasi, mem-boot dan menguji aplikasi dan orang operasi menyebarkan aplikasi yang mulus, karena ini adalah tempat semua gesekan terletak pada dan tujuan DevOps adalah untuk memecah silo tersebut.

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

Meninggalkan VM tidak praktis seperti sekarang. Jadi baik VMs dan LXC memiliki eksistensi dan kepentingan individual mereka sendiri.


117
2017-08-26 07:46



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

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

Sekarang, mari saya jelaskan sedikit lebih banyak tentang apa artinya itu. Mesin virtual adalah hewan mereka sendiri. Saya merasa ingin menjelaskan apa Buruh pelabuhan akan membantu Anda memahami ini lebih dari sekadar menjelaskan apa itu mesin virtual. Terutama karena ada banyak jawaban yang bagus di sini yang memberi tahu Anda apa arti seseorang ketika mereka mengatakan "mesin virtual". Begitu...

Wadah Docker hanyalah sebuah proses (dan anak-anaknya) yang terkotak-kotak menggunakan cgroup di dalam kernel sistem host dari sisa proses. Anda benar-benar dapat melihat proses penampung Docker Anda dengan menjalankan ps aux pada tuan rumah. Misalnya, mulai apache2 "dalam wadah" baru dimulai apache2 sebagai proses khusus pada tuan rumah. Itu baru saja terkotak-kotak dari proses lain pada mesin. Penting untuk dicatat bahwa wadah Anda tidak ada di luar 'seumur hidup proses kemas Anda. Ketika proses Anda mati, penampung Anda akan mati. Itu karena Docker menggantikan pid 1 di dalam wadah Anda dengan aplikasi Anda (pid 1 biasanya adalah sistem init). Poin terakhir tentang ini pid 1 sangat penting.

Sejauh filesystem yang digunakan oleh masing-masing proses kontainer, Docker menggunakan UnionFSgambar-balik, yang Anda unduh ketika Anda melakukan docker pull ubuntu. Setiap "gambar" hanyalah serangkaian lapisan dan metadata yang terkait. Konsep pelapisan 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 lapisan di atas lapisan terakhir yang mengatakan "file ini telah dihapus". Kebetulan, inilah sebabnya Anda dapat menghapus file besar dari sistem file Anda, tetapi gambar masih mengambil jumlah ruang disk yang sama. File tersebut masih ada, di lapisan di bawah yang sekarang. Lapisan itu sendiri hanyalah berkas tarballs. Anda dapat menguji ini dengan docker save --output /tmp/ubuntu.tar ubuntulalu cd /tmp && tar xvf ubuntu.tar. Kemudian Anda bisa melihat-lihat. Semua direktori yang terlihat seperti hash panjang sebenarnya adalah lapisan individu. Masing-masing berisi file (layer.tar) dan metadata (json) dengan informasi tentang lapisan tertentu itu. Lapisan-lapisan itu hanya menggambarkan perubahan pada sistem berkas yang disimpan sebagai lapisan "di atas" negara asalnya. Ketika 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 filesystem hanya melihat lapisan paling atas. Hal ini memungkinkan wadah yang benar-benar berbeda untuk berbagi lapisan sistem file mereka, meskipun beberapa perubahan signifikan mungkin telah terjadi pada sistem berkas pada lapisan paling atas di setiap penampung. Ini dapat menghemat banyak ruang disk, ketika wadah Anda berbagi lapisan gambar dasarnya. Namun, ketika Anda me-mount direktori dan file dari sistem host ke dalam wadah Anda melalui volume, volume tersebut "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 pada host. Ini menciptakan subnet virtual di docker0 untuk wadah Anda untuk berkomunikasi "antara" satu sama lain. Ada banyak pilihan untuk jaringan di sini, termasuk membuat subnet khusus untuk penampung Anda, dan kemampuan untuk "membagikan" tumpukan jaringan host Anda untuk penampung Anda untuk mengakses secara langsung.

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


89
2018-04-04 02:35



Docker merangkum aplikasi dengan semua dependensinya, sebuah virtualizer merangkum sebuah O.S. yang dapat menjalankan aplikasi apa pun yang biasanya dapat dijalankan pada mesin logam telanjang.


57
2017-08-27 18:25



Mereka berdua sangat berbeda. Docker ringan dan menggunakan LXC / libcontainer (yang bergantung pada ruang nama kernel dan cgroup) dan tidak memiliki emulasi mesin / perangkat keras seperti hypervisor, KVM. Xen yang berat.

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

Bagaimana dengan memori, I / O, CPU, dll? Itu dikendalikan menggunakan cgroup di mana Anda dapat membuat grup dengan spesifikasi / pembatasan sumber daya tertentu (CPU, memori, dll.) Dan menempatkan proses Anda di sana. Di atas LXC, Docker menyediakan backend penyimpanan (http://www.projectatomic.io/docs/filesystems/) misalnya, menyatukan sistem file tempat Anda dapat menambahkan lapisan dan membagikan lapisan di antara ruang nama pemasangan yang berbeda.

Ini adalah fitur yang kuat di mana gambar dasar biasanya hanya bisa dibaca dan hanya ketika kontainer memodifikasi sesuatu di lapisan itu akan menulis sesuatu ke partisi baca-tulis (a.k.a. copy on write). Ini juga menyediakan banyak pembungkus lain seperti registry dan versi gambar.

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

VM normal (misalnya, VirtualBox dan VMware) menggunakan hypervisor, dan teknologi yang terkait baik memiliki firmware khusus yang menjadi lapisan pertama untuk OS pertama (host OS, atau guest OS 0) atau perangkat lunak yang berjalan di host OS untuk memberikan emulasi perangkat keras seperti CPU, USB / aksesoris, memori, jaringan, dll., ke OS tamu. VM masih (pada 2015) populer di lingkungan multi-penyewa keamanan tinggi.

Docker / LXC hampir dapat dijalankan pada perangkat keras yang murah (kurang dari 1 GB memori juga OK asalkan Anda memiliki kernel yang lebih baru) vs VMs normal membutuhkan setidaknya 2 GB memori, dll, untuk melakukan sesuatu yang berarti dengan itu . Tetapi dukungan Docker pada OS host tidak tersedia di OS seperti Windows (pada Nov 2014) dimana jenis VM dapat dijalankan di windows, Linux, dan Mac.

Ini adalah pic dari buruh pelabuhan / hak cipta: Here is a pic from rightscale


45
2017-11-03 17:44



1. Ringan

Ini mungkin kesan pertama bagi banyak pelajar docker.

Pertama, gambar buruh pelabuhan biasanya lebih kecil dari gambar VM, membuatnya mudah untuk membangun, menyalin, berbagi.

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

2. Sistem Berkas Berlapis

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

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

3. Shared OS Kernel

Pikirkan wadah sebagai proses!

Semua kontainer yang dijalankan pada host memang sekelompok proses dengan sistem file yang berbeda. Mereka berbagi kernel OS yang sama, hanya mengenkapsulasi pustaka dan dependensi sistem.

Ini bagus untuk kebanyakan kasus (tidak ada kernel OS tambahan yang dipertahankan) tetapi bisa menjadi masalah jika isolasi ketat diperlukan di antara kontainer.

Mengapa itu penting?

Semua ini tampak seperti perbaikan, bukan revolusi. Baik, akumulasi kuantitatif mengarah pada transformasi kualitatif.

Pikirkan tentang penyebaran aplikasi. Jika kita ingin menggunakan perangkat lunak baru (layanan) atau meng-upgrade satu, lebih baik untuk mengubah file konfigurasi dan proses daripada membuat VM baru. Karena Membuat VM dengan layanan terbaru, mengujinya (berbagi antara Dev & QA), penerapan ke produksi membutuhkan waktu berjam-jam, bahkan berhari-hari. Jika ada yang salah, Anda harus mulai lagi, membuang-buang lebih banyak waktu. Jadi, gunakan alat manajemen konfigurasi (boneka, tumpukan garam, koki dll.) Untuk menginstal perangkat lunak baru, mengunduh file baru lebih disukai.

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

Ini mengubah cara layanan dikirimkan. Kami menginginkan aplikasi, tetapi harus mempertahankan VM (yang merupakan rasa sakit dan tidak ada hubungannya dengan aplikasi kami). Docker membuat Anda fokus pada aplikasi dan menghaluskan semuanya.


23
2017-08-10 04:25



Berhubungan dengan:-

"Mengapa menyebarkan perangkat lunak ke gambar buruh pelabuhan lebih mudah dari sekadar   menyebarkan ke lingkungan produksi yang konsisten? "

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

  1. PC pengembang individu (s)
  2. Lingkungan pengembang bersama
  3. PC penguji individual (s)
  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 memang penguji, semua akan memiliki konfigurasi PC yang sangat berbeda atau sangat berbeda, karena sifat pekerjaannya
  • Pengembang sering dapat mengembangkan pada PC di luar kendali aturan standarisasi perusahaan atau bisnis (misalnya freelancer yang mengembangkan pada mesin mereka sendiri (sering jarak jauh) atau kontributor untuk proyek open source yang tidak 'dipekerjakan' atau 'dikontrak' untuk mengkonfigurasi PC mereka tertentu cara)
  • Beberapa lingkungan akan terdiri dari sejumlah tetap beberapa mesin dalam konfigurasi seimbang beban
  • Banyak lingkungan produksi akan memiliki server berbasis cloud yang secara dinamis (atau 'elastically') dibuat dan dihancurkan tergantung pada tingkat lalu lintas

Seperti yang Anda lihat jumlah total server yang diekstrapolasikan untuk organisasi jarang dalam angka tunggal, sangat sering dalam angka tiga kali lipat dan dapat dengan mudah tetap lebih tinggi secara signifikan.

Ini semua berarti bahwa menciptakan lingkungan yang konsisten di tempat pertama cukup sulit hanya karena volume tipis (bahkan dalam skenario lapangan hijau), tetapi menjaga mereka tetap konsisten adalah tidak mungkin mengingat banyaknya server, penambahan server baru (secara dinamis atau manual), pembaruan otomatis dari vendor o / s, vendor anti-virus, vendor browser dan sejenisnya, pemasangan perangkat lunak manual atau perubahan konfigurasi yang dilakukan oleh pengembang atau teknisi server, dll Biarkan saya mengulangi itu - itu hampir (tidak ada maksudnya) tidak mungkin untuk menjaga lingkungan tetap konsisten (oke, untuk yang purist, itu bisa dilakukan, tetapi ini melibatkan sejumlah besar waktu, usaha dan disiplin, yang justru mengapa VM dan kontainer (misalnya Docker) diciptakan di tempat pertama).

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


16
2017-10-15 11:25