a

Câu hỏi Docker khác với máy ảo như thế nào?


Tôi tiếp tục đọc lại tài liệu Docker để cố gắng hiểu sự khác biệt giữa Docker và một máy ảo đầy đủ. Làm thế nào để nó quản lý để cung cấp một hệ thống tập tin đầy đủ, môi trường mạng bị cô lập, vv mà không bị nặng?

Tại sao triển khai phần mềm vào một hình ảnh docker (nếu đó là thuật ngữ đúng) dễ dàng hơn việc triển khai một môi trường sản xuất nhất quán?


2921
2018-04-16 21:19


gốc


Docker vs KVM phân tích hiệu suất: bodenr.blogspot.com/2014/05/… - HDave
Nếu bạn đang tìm kiếm sự khác biệt giữa hình ảnh của họ - stackoverflow.com/questions/29096967/… - devesh-ahuja
Docker không phải là một máy ảo - nó là một công cụ quản lý cấu hình. - aaa90210
@ JagatveerSingh Tôi nghĩ rằng đó là một liên kết quay lại câu hỏi này. - Dan Nissenbaum
Stack Overflow là một trang web cho các câu hỏi lập trình và phát triển. Câu hỏi này dường như không có chủ đề vì nó không phải là về lập trình hay phát triển. Xem Tôi có thể hỏi những chủ đề nào ở đây trong Trung tâm trợ giúp. Có lẽ Siêu người dùng hoặc là Trao đổi ngăn xếp Unix & Linux sẽ là một nơi tốt hơn để hỏi. - jww


Các câu trả lời:


Docker ban đầu được sử dụng Thùng chứa LinuX (LXC), nhưng sau đó chuyển sang runC (được biết đến trước đây như libcontainer), chạy trong cùng hệ điều hành với máy chủ của nó. Điều này cho phép nó chia sẻ rất nhiều tài nguyên hệ điều hành máy chủ. Ngoài ra, nó sử dụng một hệ thống tập tin lớp (AuFS) và quản lý mạng.

AuFS là một hệ thống tệp lớp, vì vậy bạn có thể có một phần chỉ đọc và một phần ghi được hợp nhất với nhau. Người ta có thể có các phần phổ biến của hệ điều hành là chỉ đọc (và được chia sẻ giữa tất cả các vùng chứa của bạn) và sau đó cung cấp cho mỗi vùng chứa gắn kết riêng của nó để viết.

Vì vậy, giả sử bạn có hình ảnh vùng chứa 1 GB; nếu bạn muốn sử dụng một máy ảo đầy đủ, bạn sẽ cần phải có 1 GB lần x số máy ảo mà bạn muốn. Với Docker và AuFS, bạn có thể chia sẻ số lượng lớn 1 GB giữa tất cả các vùng chứa và nếu bạn có 1000 vùng chứa, bạn vẫn có thể có ít hơn 1 GB dung lượng cho hệ điều hành vùng chứa (giả sử tất cả chúng đều chạy cùng một hình ảnh OS) .

Một hệ thống ảo hóa đầy đủ có bộ tài nguyên riêng được phân bổ cho nó và chia sẻ tối thiểu. Bạn sẽ bị cô lập nhiều hơn, nhưng nó nặng hơn nhiều (đòi hỏi nhiều tài nguyên hơn). Với Docker bạn nhận được ít cô lập, nhưng các container có trọng lượng nhẹ (yêu cầu ít tài nguyên hơn). Vì vậy, bạn có thể dễ dàng chạy hàng ngàn container trên một máy chủ, và nó thậm chí sẽ không chớp mắt. Hãy thử làm điều đó với Xen, và trừ khi bạn có một máy chủ thực sự lớn, tôi không nghĩ rằng nó là có thể.

Một hệ thống ảo hóa đầy đủ thường mất vài phút để bắt đầu, trong khi các thùng chứa Docker / LXC / runC mất vài giây và thậm chí ít hơn một giây.

Có ưu và nhược điểm cho từng loại hệ thống ảo hóa. Nếu bạn muốn cô lập hoàn toàn với các tài nguyên được bảo đảm, một VM đầy đủ là cách để đi. Nếu bạn chỉ muốn cô lập các quy trình với nhau và muốn chạy một tấn chúng trên một máy chủ có kích thước hợp lý, thì Docker / LXC / runC có vẻ là con đường để đi.

Để biết thêm thông tin, hãy xem tập hợp các bài đăng trên blog này làm tốt công việc giải thích cách LXC hoạt động.

Tại sao triển khai phần mềm vào một hình ảnh docker (nếu đó là thuật ngữ đúng) dễ dàng hơn việc triển khai một môi trường sản xuất nhất quán?

Triển khai một môi trường sản xuất nhất quán dễ nói hơn là thực hiện. Ngay cả khi bạn sử dụng các công cụ như Đầu bếp và Con rối, luôn có các cập nhật hệ điều hành và những thứ khác thay đổi giữa máy chủ và môi trường.

Docker cung cấp cho bạn khả năng chụp ảnh hệ điều hành thành một hình ảnh được chia sẻ, và làm cho nó dễ dàng triển khai trên các máy chủ Docker khác. Tại địa phương, dev, qa, prod, v.v.: tất cả cùng một hình ảnh. Chắc chắn bạn có thể làm điều này với các công cụ khác, nhưng không gần như dễ dàng hay nhanh chóng.

Điều này là rất tốt để thử nghiệm; giả sử bạn có hàng ngàn bài kiểm tra cần kết nối với cơ sở dữ liệu và mỗi bài kiểm tra cần bản sao nguyên sơ của cơ sở dữ liệu và sẽ thực hiện thay đổi đối với dữ liệu. Cách tiếp cận cổ điển này là đặt lại cơ sở dữ liệu sau mỗi lần kiểm tra hoặc bằng mã tùy chỉnh hoặc với các công cụ như Đường bay - điều này có thể rất tốn thời gian và có nghĩa là các bài kiểm tra phải được chạy một cách serially. Tuy nhiên, với Docker bạn có thể tạo ra một hình ảnh của cơ sở dữ liệu của bạn và chạy một cá thể cho mỗi kiểm thử, và sau đó chạy tất cả các thử nghiệm song song vì bạn biết tất cả chúng sẽ chạy trên cùng một ảnh chụp của cơ sở dữ liệu. Vì các thử nghiệm đang chạy song song và trong các thùng chứa Docker, chúng có thể chạy tất cả trên cùng một hộp cùng một lúc và sẽ kết thúc nhanh hơn nhiều. Hãy thử làm điều đó với một máy ảo đầy đủ.

Từ nhận xét ...

Hấp dẫn! Tôi cho rằng tôi vẫn còn bối rối bởi khái niệm "snapshot [ting] OS". Làm thế nào để làm điều đó mà không, tốt, làm cho một hình ảnh của hệ điều hành?

Vâng, chúng ta hãy xem nếu tôi có thể giải thích. Bạn bắt đầu với một hình ảnh cơ sở, và sau đó thực hiện thay đổi của bạn, và cam kết những thay đổi bằng cách sử dụng docker, và nó tạo ra một hình ảnh. Hình ảnh này chỉ chứa sự khác biệt từ cơ sở. Khi bạn muốn chạy hình ảnh của bạn, bạn cũng cần cơ sở, và nó lớp hình ảnh của bạn trên đầu trang của cơ sở bằng cách sử dụng một hệ thống tập tin lớp: như đã đề cập ở trên, Docker sử dụng AUFS. AUFS kết hợp các lớp khác nhau với nhau và bạn có được những gì bạn muốn; bạn chỉ cần chạy nó. Bạn có thể tiếp tục thêm ngày càng nhiều hình ảnh (lớp) và nó sẽ tiếp tục chỉ lưu các khác biệt. Vì Docker thường xây dựng trên đầu các ảnh được tạo sẵn từ đăng ký, bạn hiếm khi phải "chụp nhanh" toàn bộ hệ điều hành.


2817
2018-04-16 22:35



Ken, ở một số nơi bạn sẽ liên kết hệ điều hành với hạt nhân. Tất cả các thùng chứa trên một máy chủ chạy dưới cùng một hạt nhân, nhưng phần còn lại của các tệp hệ điều hành có thể là duy nhất cho mỗi vùng chứa. - Andy
Hấp dẫn! Tôi cho rằng tôi vẫn còn bối rối bởi khái niệm "snapshot [ting] OS". Làm thế nào để làm điều đó mà không, tốt, làm cho một hình ảnh của hệ điều hành? - zslayton
@ murtaza52 họ đang thêm hỗ trợ cho các hệ thống tập tin khác nhau để Aufs đi xa không phải là một vấn đề. Không chắc chắn khi nào hỗ trợ 32 bit sẽ được thêm vào, đừng nghĩ rằng đã có nhu cầu mạnh mẽ, vì vậy nó thấp trong danh sách ưu tiên, nhưng tôi có thể sai. - Ken Cochrane
@Mike: ... không nghi ngờ gì đã được truyền cảm hứng bởi FreeBSD jails  HISTORY The jail utility appeared in FreeBSD 4.0. - Stefan Paletta
Đối với những người tự hỏi những gì bình luận của @ Mike của chúng tôi đang trả lời vì nó dường như đã bị xóa, nó là: <Một điều đó là mất tích là một tham chiếu đến thực tế là Linux Containers là một bản sao của nguồn cảm hứng thực sự : Solaris Containers. Quay trở lại năm 2004 ... Đây là một khái niệm mang tính cách mạng và một cách tuyệt vời, tuyệt vời để thực hiện các máy ảo giá cả phải chăng, được lưu trữ thực sự. Joyent là người đầu tiên tôi biết ...> - Jeffrey 'jf' Lim


Câu trả lời hay. Chỉ cần để có được một đại diện hình ảnh của container vs VM, có một cái nhìn ở dưới đây.

enter image description here

Nguồn: https://www.docker.com/what-container#/package_software


342
2017-10-14 18:02



<strike> Theo như tôi hiểu, phía trên "công cụ docker" cần có một hạt nhân Linux được chia sẻ. Sau đó, thường có chung thùng / libs. Đầu tiên sau đó đến các thùng / libs và các ứng dụng cụ thể cho mỗi vùng chứa. Hãy sửa tôi nếu tôi sai. </ Strike> Tôi đã sai. Hình ảnh Docker chia sẻ hạt nhân với máy chủ, xem superuser.com/questions/889472/…. Tuy nhiên, để minh họa hệ thống tệp công đoàn của các thùng chứa, có thể có một lớp libs / thùng được chia sẻ trực tiếp phía trên công cụ docker. - Betamos
Tôi có một vấn đề với hình trên, bởi vì Hypervisor có thể được cài đặt trên kim loại trần / cơ sở hạ tầng nhưng Docket không thể (chưa) - reza
@reza, Tôi đồng ý Hypervisor có thể được cài đặt trên kim loại trần, nhưng điểm là Docker được khuyến khích cho việc chứa các ứng dụng và cách giới hạn hoặc tránh ảo hóa không cần thiết / áp dụng cho một số tình huống. Ken Cochrane giải thích chi tiết hơn stackoverflow.com/a/16048358/2478933 - manu97
Điều này không làm rõ điều gì Docker Engine. Hình ảnh rất trừu tượng. - kyb
Không có lớp "Docker Engine" giữa container và kernel, container chỉ là một tiến trình với các thiết lập đặc biệt trong kernel (namespaces, cgroups, v.v.) - Paweł Prażak


Có thể hữu ích khi hiểu cách ảo hóa và vùng chứa hoạt động ở mức thấp. Điều đó sẽ làm sáng tỏ rất nhiều thứ.

Lưu ý: Tôi đang đơn giản hóa một chút trong mô tả dưới đây. Xem tài liệu tham khảo để biết thêm thông tin.

Cách ảo hóa hoạt động ở mức thấp?

Trong trường hợp này, trình quản lý VM sẽ vượt qua vòng CPU 0 (hoặc "chế độ gốc" trong các CPU mới hơn) và chặn tất cả các cuộc gọi đặc quyền được thực hiện bởi hệ điều hành khách để tạo ảo tưởng rằng hệ điều hành khách có phần cứng riêng. Thực tế thú vị: Trước năm 1998 người ta cho rằng không thể đạt được điều này trong kiến ​​trúc x86 vì không có cách nào để thực hiện kiểu đánh chặn này. Những người ở VMWare là người đầu tiên người có ý tưởng viết lại các byte thực thi trong bộ nhớ cho các cuộc gọi đặc quyền của hệ điều hành khách để đạt được điều này.

Hiệu ứng ròng là ảo hóa cho phép bạn chạy hai hệ điều hành hoàn toàn khác nhau trên cùng một phần cứng. Mỗi hệ điều hành khách đi qua tất cả các quá trình bootstrapping, tải kernel vv Bạn có thể có bảo mật rất chặt chẽ, ví dụ, hệ điều hành khách không thể truy cập đầy đủ vào hệ điều hành máy chủ hoặc các khách khác và những thứ lộn xộn.

Thùng chứa hoạt động ở mức độ thấp như thế nào?

Xung quanh 2006, mọi người bao gồm một số nhân viên tại Google đã triển khai tính năng cấp hạt nhân mới được gọi là không gian tên (tuy nhiên ý tưởng Dài trước tồn tại trong FreeBSD). Một chức năng của hệ điều hành là cho phép chia sẻ các tài nguyên toàn cầu như mạng và đĩa cho các quá trình. Điều gì sẽ xảy ra nếu các tài nguyên toàn cầu này được bao bọc trong các không gian tên để chúng chỉ hiển thị với các tiến trình chạy trong cùng một không gian tên? Giả sử, bạn có thể lấy một đoạn đĩa và đặt vào trong không gian tên X và sau đó các tiến trình đang chạy trong không gian tên Y không thể nhìn thấy hoặc truy cập nó. Tương tự, các tiến trình trong không gian tên X không thể truy cập vào bất cứ thứ gì trong bộ nhớ được cấp phát cho không gian tên Y. Tất nhiên, các tiến trình trong X không thể thấy hoặc nói chuyện với các tiến trình trong không gian tên Y. Điều này cung cấp loại ảo hóa và cách ly cho các tài nguyên toàn cầu. Đây là cách docker hoạt động: Mỗi container chạy trong không gian tên riêng của nó nhưng sử dụng chính xác tương tự hạt nhân như tất cả các vùng chứa khác. Sự cô lập xảy ra vì hạt nhân biết không gian tên đã được gán cho tiến trình và trong các cuộc gọi API, nó đảm bảo rằng quy trình chỉ có thể truy cập tài nguyên trong không gian tên riêng của nó.

Những hạn chế của container vs VM nên được rõ ràng bây giờ: Bạn không thể chạy hệ điều hành hoàn toàn khác nhau trong container như trong máy ảo. Tuy nhiên bạn có thể chạy các bản phân phối Linux khác nhau vì chúng chia sẻ cùng một hạt nhân. Mức cô lập không mạnh bằng VM. Trên thực tế, đã có một cách để thùng chứa "khách" tiếp quản máy chủ trong các triển khai sớm. Ngoài ra, bạn có thể thấy rằng khi bạn tải vùng chứa mới, toàn bộ bản sao hệ điều hành mới không bắt đầu giống như trong VM. Tất cả các vùng chứa chia sẻ cùng một hạt nhân. Đây là lý do tại sao container có trọng lượng nhẹ. Cũng giống như VM, bạn không phải phân bổ trước bộ nhớ đáng kể cho các thùng chứa vì chúng tôi không chạy bản sao mới của hệ điều hành. Điều này cho phép chạy hàng nghìn vùng chứa trên một hệ điều hành trong khi sandbox chúng có thể không thực hiện được nếu chúng ta đang chạy bản sao riêng của hệ điều hành trong máy ảo của riêng nó.


298
2018-01-13 01:49



Wow, cảm ơn lời giải thích cấp thấp tuyệt vời (và các sự kiện lịch sử). Tôi đã tìm kiếm điều đó và không tìm thấy ở trên. Ý của bạn là gì "bạn có thể chạy các bản phân phối Linux khác nhau vì chúng chia sẻ cùng một hạt nhân".? Bạn có nói rằng một thùng chứa khách phải có cùng một phiên bản hạt nhân Linux hoặc nó không quan trọng? Nếu nó không quan trọng nếu tôi gọi một lệnh hệ điều hành trên máy khách nhưng chỉ được hỗ trợ trong nhân khách. Hoặc ví dụ một lỗi cố định trong nhân khách nhưng không phải trong hạt nhân chủ. Tất cả các khách sẽ biểu hiện lỗi, đúng không? Mặc dù khách đã được vá. - Jeach
@Jeach: các thùng chứa không có hạt nhân riêng của họ, họ đang chia sẻ / sử dụng một trong các máy chủ lưu trữ. Vì vậy, bạn không thể chạy các container cần các hạt nhân khác nhau trên cùng một máy tính / VM. - user276648
Câu hỏi: Bạn viết rằng một số nhân viên của Google đã tham gia vào tính năng hạt nhân không gian tên vào khoảng năm 1996 - nhưng Google không được thành lập cho đến năm 1998. Ý của bạn là 'những người sau này sẽ trở thành nhân viên của Google'? - Martin Gjaldbaek
@martin - cảm ơn vì đã chú ý đến năm 2006. Ngoài ra tôi nên đề cập đến các kiểu không gian tên khác nhau đã tồn tại trong Linux từ năm 2002 nhưng đó là công việc trong năm 2006 đặt nền tảng cho việc container. Tôi đã cập nhật câu trả lời với tham chiếu. - ShitalShah
+1 Đây sẽ là câu trả lời được đánh dấu, trong khi các câu trả lời khác cung cấp một số làm rõ, chỉ có một lời giải thích mức thấp ở dưới có thể làm rõ cách thức hoạt động của công nghệ này, 'các quá trình được nhóm lại trong không gian tên = vùng chứa riêng của chúng'. Cảm ơn bạn rất nhiều, tôi nhận được nó ngay bây giờ. - Tino Mclaren


Tôi thích câu trả lời của Ken Cochrane.

Nhưng tôi muốn thêm điểm bổ sung, không được đề cập chi tiết ở đây. Theo tôi Docker cũng khác trong toàn bộ quá trình. Ngược lại với máy ảo, Docker không phải là (chỉ) về chia sẻ tài nguyên tối ưu của phần cứng, hơn nữa nó cung cấp một "hệ thống" cho ứng dụng đóng gói (Ưu tiên nhưng không phải là, phải là một tập hợp các Microservices).

Với tôi nó phù hợp với khoảng cách giữa các công cụ dành cho nhà phát triển theo định hướng như rpm, gói debian, maven, npm + git ở một bên và các công cụ Ops như Puppet, VMWare, Xen bạn đặt tên cho nó ...

Tại sao triển khai phần mềm vào một hình ảnh docker (nếu đó là thuật ngữ đúng) dễ dàng hơn việc triển khai một môi trường sản xuất nhất quán?

Câu hỏi của bạn giả định một số môi trường sản xuất nhất quán. Nhưng làm thế nào để giữ cho nó phù hợp?  Xem xét một số lượng (> 10) máy chủ và ứng dụng, các giai đoạn trong đường ống. Để đồng bộ hóa, bạn sẽ bắt đầu sử dụng một cái gì đó như Puppet, Chef hoặc kịch bản cung cấp của riêng bạn, các quy tắc chưa xuất bản và / hoặc nhiều tài liệu ... Trong các máy chủ lý thuyết có thể chạy vô thời hạn và được giữ hoàn toàn nhất quán và cập nhật. Thực hành không quản lý được cấu hình của máy chủ hoàn toàn, vì vậy có phạm vi đáng kể cho việc định cấu hình trôi dạt và những thay đổi bất ngờ đối với máy chủ đang chạy.

Vì vậy, có một mô hình đã biết để tránh điều này, cái gọi là Máy chủ không thể thay đổi. Nhưng mẫu máy chủ bất biến không được yêu thích. Chủ yếu là do những hạn chế của VM của nó đã được sử dụng trước khi Docker. Đối phó với một số hình ảnh lớn Gigabyte, di chuyển những hình ảnh lớn xung quanh, chỉ để thay đổi một số lĩnh vực trong ứng dụng, đã rất rất mất thời gian. Có thể hiểu được...

Với hệ sinh thái Docker, bạn sẽ không bao giờ cần di chuyển xung quanh Gigabyte trên "những thay đổi nhỏ" (Thanks aufs and Registry) và bạn không cần phải lo lắng về việc mất hiệu năng bằng cách đóng gói ứng dụng vào thùng chứa Docker khi chạy. Bạn không cần phải lo lắng về các phiên bản của hình ảnh đó. Và cuối cùng bạn thậm chí sẽ thường xuyên có thể tái tạo môi trường sản xuất phức tạp ngay cả trên máy tính xách tay Linux của bạn (không gọi cho tôi nếu không hoạt động trong trường hợp của bạn;))

Và tất nhiên bạn có thể bắt đầu các thùng chứa docker trong máy ảo (đó là một ý tưởng hay). Giảm cấp phép máy chủ của bạn trên cấp VM. Tất cả những điều trên có thể được quản lý bởi Docker.

P.S. Trong khi đó Docker sử dụng "libcontainer" thực hiện riêng của mình thay vì LXC. Nhưng LXC vẫn có thể sử dụng được.


280
2017-09-19 16:21



Có vẻ kỳ quặc bao gồm git trong một nhóm các công cụ như rpm và dpkg. Tôi đề cập đến điều này vì tôi thấy những nỗ lực sử dụng các hệ thống kiểm soát phiên bản như git như một công cụ phân phối / đóng gói là một nguồn gây nhầm lẫn nhiều. - blitzen9872
anh ta không sai mặc dù, git có thể được sử dụng để quản lý gói, bower ví dụ là nội bộ về cơ bản một cli ưa thích để tải về các thẻ git. - roo2
các ứng dụng đóng gói trong các thùng chứa là một cách tiếp cận thú vị và hợp lệ. Tuy nhiên nếu bạn đóng gói nó trong docker này sẽ là quá mức cần thiết, vì sẽ không có sự hỗ trợ đơn giản cho các phụ thuộc hoặc bất kỳ thư viện chia sẻ nào. Đây chính xác là công nghệ đóng gói mới như Ubuntu Snap và Flatpak cho Redhat đang cố gắng đạt được. Theo tôi, một trong những công nghệ đóng gói này sẽ giành chiến thắng và trở thành tương lai của bao bì trong linux. - yosefrow


Docker không phải là một phương pháp ảo hóa. Nó dựa trên các công cụ khác thực sự triển khai ảo hóa cấp hệ điều hành hoặc ảo hóa dựa trên vùng chứa. Cho rằng, Docker ban đầu được sử dụng trình điều khiển LXC, sau đó chuyển đến libcontainer mà bây giờ được đổi tên thành runc. Docker chủ yếu tập trung vào việc tự động hóa việc triển khai các ứng dụng bên trong các thùng chứa ứng dụng. Các thùng chứa ứng dụng được thiết kế để đóng gói và chạy một dịch vụ duy nhất, trong khi các thùng chứa hệ thống được thiết kế để chạy nhiều tiến trình, như các máy ảo. Vì vậy, Docker được coi là một công cụ quản lý container hoặc triển khai ứng dụng trên các hệ thống container.

Để biết làm thế nào nó khác với ảo hóa khác, chúng ta hãy đi qua ảo hóa và các loại của nó. Sau đó, nó sẽ dễ dàng hơn để hiểu sự khác biệt ở đó là gì.

Ảo hóa

Trong hình thức được hình thành của nó, nó được coi là một phương pháp phân chia các khung hình chính để cho phép nhiều ứng dụng chạy đồng thời. Tuy nhiên, kịch bản này đã thay đổi đáng kể khi các công ty và cộng đồng nguồn mở có thể cung cấp một phương thức xử lý các hướng dẫn đặc quyền theo cách này hay cách khác và cho phép nhiều hệ điều hành được chạy đồng thời trên một hệ thống dựa trên x86 đơn lẻ.

Hypervisor

Các hypervisor xử lý việc tạo ra môi trường ảo mà trên đó các máy khách ảo hoạt động. Nó giám sát các hệ thống khách và đảm bảo rằng các nguồn lực được phân bổ cho khách khi cần thiết. Trình siêu giám sát nằm giữa máy vật lý và các máy ảo và cung cấp các dịch vụ ảo hóa cho các máy ảo. Để nhận ra nó, nó chặn các hoạt động của hệ điều hành khách trên các máy ảo và mô phỏng hoạt động trên hệ điều hành của máy chủ.

Sự phát triển nhanh chóng của công nghệ ảo hóa, chủ yếu trong đám mây, đã thúc đẩy việc sử dụng ảo hóa hơn nữa bằng cách cho phép nhiều máy chủ ảo được tạo trên một máy chủ vật lý với sự trợ giúp của các siêu giám sát, như Xen, VMware Player, KVM, v.v. kết hợp hỗ trợ phần cứng trong các bộ xử lý hàng hóa, chẳng hạn như Intel VT và AMD-V.

Các loại ảo hóa

Phương pháp ảo hóa có thể được phân loại dựa trên cách nó bắt chước phần cứng với hệ điều hành khách và mô phỏng môi trường hoạt động của khách. Chủ yếu, có ba loại ảo hóa:

  • Thi đua
  • Paravirtualization
  • Ảo hóa dựa trên vùng chứa

Thi đua

Thi đua, còn được gọi là ảo hóa đầy đủ chạy hạt nhân hệ điều hành ảo hoàn toàn bằng phần mềm. Các hypervisor được sử dụng trong loại này được gọi là loại 2 hypervisor. Nó được cài đặt ở trên cùng của hệ điều hành máy chủ có trách nhiệm dịch mã hạt nhân hệ điều hành khách sang hướng dẫn phần mềm. Bản dịch được thực hiện hoàn toàn bằng phần mềm và không yêu cầu sự tham gia của phần cứng. Thi đua làm cho nó có thể chạy bất kỳ hệ điều hành không sửa đổi nào hỗ trợ môi trường được mô phỏng. Nhược điểm của loại ảo hóa này là chi phí tài nguyên hệ thống bổ sung dẫn đến giảm hiệu suất so với các loại ảo hóa khác.

Emulation

Các ví dụ trong danh mục này bao gồm VMware Player, VirtualBox, QEMU, Bochs, Parallels, v.v.

Paravirtualization

Paravirtualization, còn được gọi là hypervisor Type 1, chạy trực tiếp trên phần cứng, hoặc “bare-metal”, và cung cấp các dịch vụ ảo hóa trực tiếp đến các máy ảo đang chạy trên nó. Nó giúp hệ điều hành, phần cứng ảo hóa và phần cứng thực sự hợp tác để đạt được hiệu suất tối ưu. Những hypervisors này thường có một dấu chân khá nhỏ và không, bản thân họ, đòi hỏi nguồn tài nguyên phong phú.

Các ví dụ trong danh mục này bao gồm Xen, KVM, v.v.

Paravirtualization

Ảo hóa dựa trên vùng chứa

Ảo hóa dựa trên vùng chứa, còn được gọi là ảo hóa cấp hệ điều hành, cho phép thực thi nhiều lần được cô lập trong một hạt nhân hệ điều hành duy nhất. Nó có hiệu suất và mật độ tốt nhất có thể và tính năng quản lý tài nguyên động. Môi trường thực thi ảo được cô lập được cung cấp bởi loại ảo hóa này được gọi là vùng chứa và có thể được xem như là một nhóm các tiến trình được truy tìm.

Container-based virtualization

Khái niệm về một thùng chứa có thể được thực hiện bởi các tính năng không gian tên được thêm vào phiên bản hạt nhân Linux 2.6.24. Vùng chứa thêm ID của nó vào mọi quy trình và thêm kiểm tra kiểm soát truy cập mới vào mọi cuộc gọi hệ thống. Nó được truy cập bởi clone () gọi hệ thống cho phép tạo các phiên bản riêng biệt của các không gian tên trước đây trên toàn cầu.

Không gian tên có thể được sử dụng theo nhiều cách khác nhau, nhưng cách tiếp cận phổ biến nhất là tạo một thùng chứa bị cô lập không có khả năng hiển thị hoặc truy cập vào các đối tượng bên ngoài vùng chứa. Các tiến trình chạy bên trong thùng chứa có vẻ như đang chạy trên một hệ thống Linux bình thường mặc dù chúng đang chia sẻ hạt nhân cơ bản với các tiến trình nằm trong các không gian tên khác, tương tự cho các loại đối tượng khác. Ví dụ, khi sử dụng không gian tên, người dùng root bên trong thùng chứa không được coi là gốc bên ngoài vùng chứa, thêm bảo mật bổ sung.

Hệ thống con Nhóm điều khiển Linux (cgroups), thành phần chính tiếp theo để bật ảo hóa vùng chứa, được sử dụng để nhóm các quy trình và quản lý mức tiêu thụ tài nguyên tổng hợp của chúng. Nó thường được sử dụng để hạn chế bộ nhớ và tiêu thụ CPU của container. Kể từ khi một hệ thống Linux container chỉ có một hạt nhân và hạt nhân có khả năng hiển thị đầy đủ vào các thùng chứa, chỉ có một cấp phân bổ nguồn lực và lập kế hoạch.

Một số công cụ quản lý có sẵn cho các thùng chứa Linux, bao gồm LXC, LXD, systemd-nspawn, lmctfy, Warden, Linux-VServer, OpenVZ, Docker, v.v.

Vùng chứa vs máy ảo

Không giống như một máy ảo, một thùng chứa không cần phải khởi động hạt nhân của hệ điều hành, vì vậy các thùng chứa có thể được tạo ra trong chưa đầy một giây. Tính năng này làm cho việc ảo hóa dựa trên vùng chứa trở nên độc đáo và mong muốn hơn các phương pháp ảo hóa khác.

Vì ảo hóa dựa trên vùng chứa bổ sung rất ít hoặc không có chi phí cho máy chủ, ảo hóa dựa trên vùng chứa có hiệu suất gần giống với gốc

Đối với ảo hóa dựa trên vùng chứa, không cần phần mềm bổ sung, không giống như các ảo hóa khác.

Tất cả các thùng chứa trên máy chủ chia sẻ bộ lập lịch của máy chủ lưu trữ cần thêm tài nguyên.

Trạng thái vùng chứa (hình ảnh Docker hoặc LXC) có kích thước nhỏ so với hình ảnh máy ảo, vì vậy hình ảnh vùng chứa rất dễ phân phối.

Quản lý tài nguyên trong các thùng chứa được thực hiện thông qua các nhóm. Các nhóm không cho phép các thùng chứa tiêu thụ nhiều tài nguyên hơn phân bổ cho chúng. Tuy nhiên, hiện tại, tất cả các tài nguyên của máy chủ đều có thể nhìn thấy trong các máy ảo, nhưng không thể sử dụng được. Điều này có thể được thực hiện bằng cách chạy top hoặc là htop trên các thùng chứa và máy chủ cùng một lúc. Đầu ra trên tất cả các môi trường sẽ trông giống nhau.


124
2018-04-02 00:55



Câu trả lời rất hay. Tôi có thể hỏi, bạn lấy những sơ đồ đó từ đâu không? Các bài báo / cuốn sách ban đầu, đó là. - Harry
Tôi đã tạo các sơ đồ đó bằng Google Bản vẽ. Tôi vẫn có những người trong tài khoản Google Bản vẽ của mình. - Ashish Bista
Và văn bản? Nguồn gốc của văn bản cho câu trả lời này là gì? - L0j1k
@Sheljohn Phiên bản đầu tiên của câu trả lời này được sao chép từ một nguyên văn nguồn khác không có ghi nhận tác giả. - L0j1k
@AshishBista Bạn cần phải thuộc tính / liên kết nguồn nếu bạn đang sử dụng văn bản lấy nguyên văn từ một nơi khác. - L0j1k


Qua bài này, chúng ta sẽ vẽ một số dòng khác nhau giữa các máy ảo và LXC. Trước tiên hãy định nghĩa chúng.

VM:

Một máy ảo mô phỏng một môi trường máy tính vật lý, nhưng các yêu cầu về CPU, bộ nhớ, đĩa cứng, mạng và các tài nguyên phần cứng khác được quản lý bởi một lớp ảo hóa, dịch các yêu cầu này đến phần cứng vật lý cơ bản.

Trong bối cảnh này, VM được gọi là Guest trong khi môi trường mà nó chạy trên được gọi là host.

LXCS:

Linux Containers (LXC) đang vận hành các khả năng ở mức hệ thống để có thể chạy nhiều thùng chứa Linux bị cô lập, trên một máy chủ điều khiển (máy chủ LXC). Linux Containers đóng vai trò như một giải pháp thay thế nhẹ cho các máy ảo vì chúng không yêu cầu các trình siêu giám sát. Virtualbox, KVM, Xen, v.v.

Bây giờ, trừ khi bạn bị Alan (Zach Galifianakis- từ loạt Hangover) đánh cắp và đã ở Vegas năm ngoái, bạn sẽ nhận thức rõ về sự quan tâm to lớn của công nghệ container Linux, và nếu tôi là một container cụ thể Dự án đã tạo ra tiếng vang trên toàn thế giới trong vài tháng qua - Docker dẫn đến một số ý kiến ​​lặp lại rằng môi trường điện toán đám mây nên từ bỏ máy ảo (VM) và thay thế chúng bằng container do chi phí thấp hơn và hiệu năng tốt hơn.

Nhưng câu hỏi lớn là, nó có khả thi không ?, liệu nó có hợp lý không?

a. LXC được scoped đến một thể hiện của Linux. Nó có thể là các hương vị khác nhau của Linux (ví dụ như một thùng chứa Ubuntu trên một máy chủ CentOS nhưng nó vẫn là Linux.) Tương tự, các thùng chứa dựa trên Windows được scoped đến một thể hiện của Windows ngay bây giờ nếu chúng ta nhìn vào các máy ảo mà chúng có phạm vi rộng hơn và sử dụng hypervisors bạn không bị giới hạn trong các hệ điều hành Linux hoặc Windows.

b. LXC có chi phí thấp và có hiệu suất tốt hơn so với máy ảo. Công cụ viz. Docker được xây dựng trên vai của công nghệ LXC đã cung cấp cho các nhà phát triển một nền tảng để chạy các ứng dụng của họ và đồng thời trao quyền cho những người hoạt động với công cụ cho phép họ triển khai cùng một vùng chứa trên các máy chủ sản xuất hoặc trung tâm dữ liệu. Nó cố gắng làm cho trải nghiệm giữa một nhà phát triển chạy một ứng dụng, khởi động và thử nghiệm một ứng dụng và một người vận hành triển khai ứng dụng đó liền mạch, bởi vì đây là nơi mà tất cả ma sát nằm trong và mục đích của DevOps là phá vỡ các silo đó.

Vì vậy, cách tiếp cận tốt nhất là các nhà cung cấp cơ sở hạ tầng điện toán đám mây nên ủng hộ việc sử dụng thích hợp các máy ảo và LXC, vì chúng phù hợp để xử lý các khối lượng công việc và kịch bản cụ thể.

Bỏ qua các máy ảo không thực tế như bây giờ. Vì vậy, cả hai máy ảo và LXC đều có sự tồn tại và tầm quan trọng riêng.


118
2017-08-26 07:46



Phần của bạn "b" ở trên là chính xác những gì các Docker folks đã nói về công nghệ. Nó có nghĩa là để làm cho sự phát triển và nhiệm vụ triển khai dễ dàng hơn. Và dựa trên kinh nghiệm của tôi như là một dev và là một sysop, tôi phải đồng ý. - WineSoaked
Đó là câu trả lời khá trừu tượng. Chúng ta cần sử dụng các trường hợp khi sử dụng / không sử dụng Docker. Đó là câu hỏi. Mọi người đều có thể tìm thấy những gì Docker là như thế nhưng chỉ một số ít có thể giải thích về các tình huống thực tế. - Ivan Voroshilin
bạn có thể làm rõ phần "a" được không. Ngôn ngữ không rõ ràng. - aamir
docker đang được đưa vào thế giới windows ngay bây giờ, vì nó không còn phụ thuộc vào LXC: blogs.msdn.com/b/nzdev/archive/2015/06/02/… hãy sửa tôi nếu tôi hiểu sai câu trả lời ở đây - bubakazouba
Tôi có một thời gian khó hiểu "(ví dụ: thùng chứa Ubuntu trên máy chủ Centos nhưng vẫn là Linux)" một phần của các thùng chứa. Cách tôi hiểu nó, là các thùng chứa chia sẻ hạt nhân chủ. Nếu tôi có một máy chủ lưu trữ chạy Linux kernel 4.6 ví dụ, có một số máy ảo của khách chạy nhân Linux 2.4, 2.6, 3.2, 4.1 và 4.4. Nếu tôi thực hiện các lệnh cụ thể cho hạt nhân đó, tôi sẽ nhận được hành vi của nhân khách (và không phải là máy chủ). Nhưng nếu máy khách của tôi là các thùng chứa ngay bây giờ, lệnh được thực hiện có được xác định bởi hạt nhân chủ không? - Jeach


Hầu hết các câu trả lời ở đây đều nói về các máy ảo. Tôi sẽ cung cấp cho bạn một câu trả lời một lớp cho câu hỏi này đã giúp tôi nhiều nhất trong vài năm qua sử dụng Docker. Đó là điều này:

Docker chỉ là một cách ưa thích để chạy một tiến trình chứ không phải một máy ảo.

Bây giờ, hãy để tôi giải thích thêm một chút về ý nghĩa của nó. Máy ảo là con thú của riêng họ. Tôi cảm thấy thích giải thích những gì Docker sẽ giúp bạn hiểu điều này hơn là giải thích máy ảo là gì. Đặc biệt là bởi vì có nhiều câu trả lời tốt ở đây cho bạn biết chính xác những gì ai đó có nghĩa là khi họ nói "máy ảo". Vì thế...

Thùng chứa Docker chỉ là một quá trình (và các con của nó) được phân chia bằng cách sử dụng cgroups bên trong hạt nhân của hệ thống máy chủ từ phần còn lại của các quy trình. Bạn thực sự có thể thấy các quy trình vùng chứa Docker của mình bằng cách chạy ps aux trên máy chủ. Ví dụ: bắt đầu apache2 "trong một container" chỉ mới bắt đầu apache2 như một quá trình đặc biệt trên máy chủ. Nó chỉ được ngăn cách từ các quy trình khác trên máy. Điều quan trọng cần lưu ý là các thùng chứa của bạn không tồn tại bên ngoài thời gian tồn tại của quá trình được container của bạn. Khi quá trình của bạn chết, vùng chứa của bạn sẽ chết. Đó là vì Docker thay thế pid 1 bên trong vùng chứa của bạn với ứng dụng của bạn (pid 1 thường là hệ thống init). Điểm cuối cùng về pid 1 là rất quan trọng.

Theo như hệ thống tập tin được sử dụng bởi mỗi quá trình chứa, Docker sử dụng UnionFShình ảnh ngược, đó là những gì bạn đang tải xuống khi bạn thực hiện docker pull ubuntu. Mỗi "hình ảnh" chỉ là một loạt các lớp và siêu dữ liệu có liên quan. Khái niệm phân lớp là rất quan trọng ở đây. Mỗi lớp chỉ là một sự thay đổi từ lớp bên dưới nó. Ví dụ, khi bạn xóa một tập tin trong Dockerfile của bạn trong khi xây dựng một container Docker, bạn đang thực sự chỉ cần tạo một lớp trên đầu trang của lớp cuối cùng mà nói "tập tin này đã bị xóa". Ngẫu nhiên, đây là lý do tại sao bạn có thể xóa một tập tin lớn từ hệ thống tập tin của bạn, nhưng hình ảnh vẫn chiếm cùng một lượng không gian đĩa. Các tập tin vẫn còn đó, trong các lớp bên dưới hiện tại. Bản thân các lớp chỉ là các tệp tarballs. Bạn có thể kiểm tra điều này với docker save --output /tmp/ubuntu.tar ubuntuvà sau đó cd /tmp && tar xvf ubuntu.tar. Sau đó, bạn có thể nhìn xung quanh. Tất cả những thư mục trông giống như băm dài thực sự là các lớp riêng lẻ. Mỗi cái chứa các tệp (layer.tar) và siêu dữ liệu (json) với thông tin về lớp cụ thể đó. Các lớp đó chỉ mô tả các thay đổi đối với hệ thống tệp được lưu dưới dạng lớp "trên đầu trang" trạng thái ban đầu của nó. Khi đọc dữ liệu "hiện tại", hệ thống tập tin đọc dữ liệu như thể nó chỉ nhìn vào các lớp thay đổi cao nhất. Đó là lý do tại sao các tập tin dường như bị xóa, mặc dù nó vẫn còn tồn tại trong các lớp "trước", bởi vì hệ thống tập tin chỉ nhìn vào các lớp trên cùng. Điều này cho phép các thùng chứa hoàn toàn khác nhau chia sẻ các lớp hệ thống tệp của chúng, mặc dù một số thay đổi quan trọng có thể xảy ra với hệ thống tệp trên các lớp trên cùng trong mỗi vùng chứa. Điều này có thể giúp bạn tiết kiệm rất nhiều không gian đĩa, khi các thùng chứa của bạn chia sẻ các lớp hình ảnh cơ bản của chúng. Tuy nhiên, khi bạn gắn các thư mục và tệp từ hệ thống máy chủ vào vùng chứa của bạn theo cách khối lượng, các ổ đĩa đó "bỏ qua" UnionFS, do đó các thay đổi không được lưu trữ trong các lớp.

Mạng trong Docker đạt được bằng cách sử dụng cầu ethernet (được gọi là docker0 trên máy chủ) và giao diện ảo cho mỗi vùng chứa trên máy chủ lưu trữ. Nó tạo ra một mạng con ảo trong docker0 cho các thùng chứa của bạn để giao tiếp "giữa" với nhau. Có nhiều tùy chọn để kết nối mạng ở đây, bao gồm tạo mạng con tùy chỉnh cho vùng chứa của bạn và khả năng "chia sẻ" ngăn xếp mạng của máy chủ lưu trữ cho vùng chứa của bạn để truy cập trực tiếp.

Docker đang di chuyển rất nhanh. Nó là tài liệu là một số tài liệu hay nhất mà tôi từng thấy. Nó thường được viết tốt, súc tích và chính xác. Tôi khuyên bạn nên kiểm tra tài liệu có sẵn để biết thêm thông tin và tin tưởng tài liệu về bất kỳ tài liệu nào khác bạn đọc trực tuyến, bao gồm Stack Overflow. Nếu bạn có câu hỏi cụ thể, tôi khuyên bạn nên tham gia #docker trên Freenode IRC và hỏi ở đó (bạn thậm chí có thể sử dụng Freenode's web chat cho điều đó!).


91
2018-04-04 02:35



"Docker chỉ là một cách ưa thích để chạy một quá trình, không phải là một máy ảo." đây là một bản tóm tắt tuyệt vời, cảm ơn! - mkorman
Cảm ơn! Khoản tín dụng cho điều đó chuyển thành lập trình viên từ #docker kênh trên Freenode IRC. - L0j1k
Đây là một câu trả lời tuyệt vời. Tôi thích sự tương tự. - Teoman shipahi


Docker đóng gói một ứng dụng với tất cả các phụ thuộc của nó, một trình ảo hóa gói gọn một O.S. có thể chạy bất kỳ ứng dụng nào mà nó thường có thể chạy trên một máy kim loại trần.


57
2017-08-27 18:25



Tôi đang tìm hiểu về LXC, sửa tôi nếu tôi sai, nhưng nó có thể là một số loại virtualenv? nhưng rõ ràng là rộng hơn, chứ không chỉ được viết thành chuỗi để trăn trở - NeoVe
Tôi thích câu trả lời này là tốt nhất. Nó đơn giản và đi thẳng đến điểm. Bây giờ người ta đã hiểu cơ bản về WHAT LXC và Virtualizers có thể làm gì, các chi tiết từ việc đọc khác sẽ có ý nghĩa. - Phil
@Phil Nó đã làm sau khi tôi đọc các câu trả lời chi tiết ở trên nó đầu tiên. - johnny


Cả hai đều rất khác nhau. Docker có trọng lượng nhẹ và sử dụng LXC / libcontainer (dựa trên các vùng tên kernel và các nhóm) và không có mô phỏng máy / phần cứng như hypervisor, KVM. Xen nặng.

Docker và LXC có nghĩa là nhiều hơn cho sandboxing, container, và cô lập tài nguyên. Nó sử dụng API nhân bản của hệ điều hành máy chủ (hiện tại chỉ là nhân Linux), cung cấp không gian tên cho IPC, NS (gắn kết), mạng, PID, UTS, v.v.

Điều gì về bộ nhớ, I / O, CPU, vv? Điều đó được kiểm soát bằng cách sử dụng các nhóm, nơi bạn có thể tạo các nhóm với đặc tả / hạn chế tài nguyên (CPU, bộ nhớ, vv) nhất định và đặt các quy trình của bạn vào đó. Trên đầu trang của LXC, Docker cung cấp một phụ trợ lưu trữ (http://www.projectatomic.io/docs/filesystems/) ví dụ: hệ thống tệp gắn kết công đoàn nơi bạn có thể thêm lớp và chia sẻ các lớp giữa các không gian tên gắn kết khác nhau.

Đây là một tính năng mạnh mẽ, nơi các hình ảnh cơ sở thường chỉ đọc và chỉ khi container sửa đổi một cái gì đó trong lớp nó sẽ viết một cái gì đó để đọc-ghi phân vùng (a.k.a. sao chép trên ghi). Nó cũng cung cấp nhiều trình bao bọc khác như đăng ký và phiên bản hình ảnh.

Với LXC bình thường, bạn cần phải đi kèm với một số rootfs hoặc chia sẻ rootfs và khi chia sẻ, và những thay đổi được phản ánh trên các container khác. Do nhiều tính năng được thêm vào này, Docker phổ biến hơn LXC. LXC là phổ biến trong môi trường nhúng để thực hiện bảo mật xung quanh các quy trình tiếp xúc với các thực thể bên ngoài như mạng và giao diện người dùng. Docker là phổ biến trong môi trường nhiều đám mây, nơi môi trường sản xuất phù hợp được mong đợi.

Một VM bình thường (ví dụ, VirtualBox và VMware) sử dụng hypervisor và các công nghệ liên quan có phần mềm chuyên dụng trở thành lớp đầu tiên cho hệ điều hành đầu tiên (hệ điều hành máy chủ hoặc hệ điều hành khách 0) hoặc phần mềm chạy trên hệ điều hành chủ. cung cấp mô phỏng phần cứng như CPU, USB / phụ kiện, bộ nhớ, mạng, v.v., cho hệ điều hành khách. Máy ảo vẫn còn (tính đến năm 2015) phổ biến trong môi trường nhiều người thuê bảo mật cao.

Docker / LXC gần như có thể chạy trên bất kỳ phần cứng rẻ nào (ít hơn 1 GB bộ nhớ cũng OK khi bạn có hạt nhân mới hơn) so với các máy ảo thông thường cần ít nhất 2 GB bộ nhớ, v.v., để làm bất cứ điều gì có ý nghĩa với nó . Nhưng Docker hỗ trợ trên hệ điều hành máy chủ không có sẵn trong hệ điều hành như Windows (tính đến tháng 11 năm 2014), nơi có thể chạy các loại máy ảo trên windows, Linux và Mac.

Đây là một pic từ docker / rightscale: Here is a pic from rightscale


45
2017-11-03 17:44





1. Nhẹ

Đây có lẽ là ấn tượng đầu tiên cho nhiều người học docker.

Đầu tiên, hình ảnh docker thường nhỏ hơn hình ảnh VM, giúp dễ dàng xây dựng, sao chép, chia sẻ.

Thứ hai, các vùng chứa Docker có thể bắt đầu trong vài mili giây, trong khi VM khởi động trong vài giây.

2. Hệ thống tệp lớp

Đây là một tính năng quan trọng khác của Docker. Hình ảnh có các lớp và các hình ảnh khác nhau có thể chia sẻ các lớp, giúp tiết kiệm không gian hơn và nhanh hơn.

Nếu tất cả các thùng chứa sử dụng Ubuntu làm hình ảnh cơ bản của chúng, thì không phải mọi hình ảnh đều có hệ thống tệp riêng, nhưng chia sẻ cùng một tệp ubuntu dưới dạng và chỉ khác trong dữ liệu ứng dụng của riêng chúng.

3. Hệ điều hành chia sẻ hạt nhân

Hãy suy nghĩ của container như các quá trình!

Tất cả các thùng chứa đang chạy trên một máy chủ thực sự là một loạt các quy trình với các hệ thống tệp khác nhau. Họ chia sẻ cùng một hạt nhân hệ điều hành, chỉ gói gọn thư viện hệ thống và các phụ thuộc.

Điều này là tốt cho hầu hết các trường hợp (không có hệ điều hành phụ hạt nhân duy trì) nhưng có thể là một vấn đề nếu cô lập nghiêm ngặt giữa các container.

Tại sao nó quan trọng?

Tất cả những điều này có vẻ như cải tiến, không phải cuộc cách mạng. Tốt, tích lũy định lượng dẫn đến chuyển đổi định tính.

Hãy suy nghĩ về triển khai ứng dụng. Nếu chúng ta muốn triển khai một phần mềm mới (dịch vụ) hoặc nâng cấp một phần mềm, tốt hơn là thay đổi các tập tin cấu hình và các quá trình thay vì tạo một máy ảo mới. Bởi vì Tạo một máy ảo với dịch vụ cập nhật, kiểm tra nó (chia sẻ giữa Dev & QA), triển khai để sản xuất mất nhiều giờ, thậm chí cả ngày. Nếu có gì sai, bạn phải bắt đầu lại, lãng phí nhiều thời gian hơn. Vì vậy, sử dụng công cụ quản lý cấu hình (con rối, saltstack, đầu bếp, vv) để cài đặt phần mềm mới, tải các tập tin mới được ưa thích.

Khi nói đến docker, nó không thể sử dụng một container docker mới được tạo ra để thay thế cái cũ. Việc xây dựng một hình ảnh mới, chia sẻ nó với QA, kiểm tra nó, triển khai nó chỉ mất vài phút (nếu mọi thứ được tự động hóa), giờ trong trường hợp xấu nhất. Cái này được gọi là cơ sở hạ tầng không thay đổi: không duy trì (nâng cấp) phần mềm, tạo một cái mới để thay thế.

Nó biến đổi cách dịch vụ được phân phối. Chúng tôi muốn các ứng dụng, nhưng phải duy trì máy ảo (đó là một nỗi đau và có rất ít để làm với các ứng dụng của chúng tôi). Docker giúp bạn tập trung vào các ứng dụng và làm mượt mọi thứ.


23
2017-08-10 04:25



Điều này nên được chấp nhận trả lời! - Sharan Duggirala


Liên quan đến:-

"Tại sao việc triển khai phần mềm vào một hình ảnh docker dễ dàng hơn là chỉ đơn giản là   triển khai cho một môi trường sản xuất nhất quán? "

Hầu hết phần mềm được triển khai cho nhiều môi trường, thường là tối thiểu ba trong số các phần sau:

  1. PC dành cho nhà phát triển cá nhân
  2. Môi trường nhà phát triển được chia sẻ
  3. PC thử nghiệm cá nhân
  4. Môi trường thử nghiệm được chia sẻ
  5. Môi trường QA
  6. Môi trường UAT
  7. Tải / kiểm tra hiệu suất
  8. Dàn dựng trực tiếp
  9. Sản xuất
  10. Lưu trữ

Ngoài ra còn có các yếu tố sau đây cần xem xét:

  • Các nhà phát triển, và những người thử nghiệm thực sự, tất cả đều có cấu hình PC tinh vi hoặc rất khác nhau, bởi bản chất của công việc
  • Các nhà phát triển thường có thể phát triển trên PC ngoài việc kiểm soát các quy tắc tiêu chuẩn hóa doanh nghiệp (ví dụ như dịch giả tự do phát triển trên máy tính của họ) (thường là từ xa) hoặc những người đóng góp cho các dự án nguồn mở không được 'thuê' hoặc 'hợp đồng' để cấu hình máy tính của họ đường)
  • Một số môi trường sẽ bao gồm một số cố định của nhiều máy trong một cấu hình cân bằng tải
  • Nhiều môi trường sản xuất sẽ có các máy chủ dựa trên đám mây động (hoặc 'đàn hồi') được tạo và phá hủy tùy thuộc vào mức lưu lượng truy cập

Như bạn có thể thấy tổng số máy chủ ngoại suy cho một tổ chức là hiếm khi trong các số liệu đơn, thường là trong các số liệu gấp ba và có thể dễ dàng cao hơn đáng kể.

Điều này có nghĩa là việc tạo ra môi trường phù hợp ngay từ đầu là đủ khó khăn chỉ vì khối lượng tuyệt đối (ngay cả trong trường hợp trường xanh), nhưng giữ chúng nhất quán là tất cả nhưng không thể với số lượng máy chủ cao, bổ sung máy chủ mới (tự động hoặc thủ công), cập nhật tự động từ nhà cung cấp o / s, nhà cung cấp chống vi-rút, nhà cung cấp trình duyệt và tương tự, cài đặt phần mềm thủ công hoặc thay đổi cấu hình được thực hiện bởi nhà phát triển hoặc kỹ thuật viên máy chủ, v.v. Hãy để tôi lặp lại điều đó - hầu như không có ý định (không có ý định chơi chữ) không thể giữ cho môi trường ổn định (được, cho thuần túy, nó có thể được thực hiện, nhưng nó liên quan đến một lượng lớn thời gian, công sức và kỷ luật. (ví dụ như Docker) đã được đưa ra ở nơi đầu tiên).

Vì vậy, hãy nghĩ về câu hỏi của bạn giống như thế này "Do khó khăn nhất trong việc giữ tất cả các môi trường nhất quán, có dễ dàng hơn khi triển khai phần mềm cho một hình ảnh docker, ngay cả khi xem xét đường cong học tập?". Tôi nghĩ bạn sẽ tìm thấy câu trả lời sẽ luôn là "có" - nhưng chỉ có một cách để tìm hiểu, đăng câu hỏi mới này lên Stack Overflow.


16
2017-10-15 11:25



Vì vậy, nếu tôi triển khai hình ảnh docker của tôi với 15 hộp khác nhau có tất cả các kết hợp hệ điều hành / phiên bản khác nhau, tất cả hình ảnh docker của tôi sẽ chạy giống nhau? - Teoman shipahi