Có bất kỳ nhược điểm nào của việc sử dụng gói gỡ lỗi như thể nó là một thùng chứa để triển khai một ứng dụng không?


15

Nhóm của tôi hiện đang cố gắng quyết định xem chúng tôi có nên triển khai ứng dụng Nodejs của mình dưới dạng gói gỡ lỗi hay không thay vì cố chạy nó trong một thùng chứa như Docker.

Tôi có ý tưởng này từ việc đọc blog này ở đây , điều này tạo ra một số lập luận tốt cho việc sử dụng gói gỡ lỗi cho ứng dụng python có sẵn. Điểm chính từ blog này hấp dẫn chúng tôi là vấn đề duy trì hệ sinh thái Docker (chia sẻ cổng, quyền, lưu trữ của Docker Images, v.v.)

Có vẻ như "dep-pack như các container ban đầu" rất có ý nghĩa đối với các dịch vụ nhỏ, nơi không có mối quan tâm về xung đột cổng và nơi tất cả các phụ thuộc được duy trì trong một môi trường ảo.

Tuy nhiên, ruột của tôi đang nói với tôi rằng nếu các gói deb phù hợp, nó sẽ phổ biến hơn và docker sẽ được quảng cáo là một giải pháp cụ thể hơn về ngôn ngữ. Có bất kỳ nhược điểm nào của việc sử dụng một cái gì đó như các gói gỡ lỗi để triển khai các dịch vụ của chúng tôi, thay vì sử dụng một hệ thống đầy đủ như docker không?


1
Chúng không loại trừ lẫn nhau, bạn có thể triển khai gói gỡ lỗi của mình trong bộ chứa Docker. Có lẽ bạn nên hỏi về microservice vs Virtual Machines?
Chris

Hmm, không có gì đặc biệt về việc sử dụng gói gỡ lỗi thay vì bộ chứa docker. Tôi sẽ thêm thông tin từ blog vào câu hỏi.
avi

3
"chúng tôi cảm thấy rằng việc nâng cấp kernel chỉ để gửi mã nhanh hơn là một giải pháp quá mức cần thiết." Điều này nghe có vẻ sai đối với tôi. Điều gì có thể quan trọng hơn mã vận chuyển nhanh hơn?
Assaf Lavie

Câu trả lời:


16

Đầu tiên, trong khi Docker đôi khi được nhìn thấy và sử dụng như một hệ thống đóng gói đặc biệt , nó thực sự giải quyết một vấn đề hoàn toàn khác: Docker là về việc chạy các chương trình. Các Docker hệ thống cho phép để mô tả dịch vụ, có thể được thu nhỏ lại theo ý thích và để kiểm soát bầy của container. Các gói Debian dùng để cài đặt chương trình và chúng có thể xử lý các phụ thuộc giữa các phiên bản phần mềm. Docker chắc chắn không đủ điều kiện là một hệ thống đóng gói gốc: mỗi gói Gói chỉ có thể có một phụ thuộc, hệ thống không có tùy chọn xây dựng đệ quy và không hỗ trợ các ràng buộc phiên bản phức tạp!

Một câu trả lời có thể là, nếu bạn sẵn sàng viết gói Debian cho ứng dụng của mình, bạn cũng có thể sử dụng Docker để triển khai ứng dụng của mình. Điều này có thể đạt được với một kịch bản cấu hình apt_setup.shtrông giống như

apt-key add - <<EOF
-----BEGIN PGP PUBLIC KEY BLOCK-----
<YOUR RELEASE OFFICER PGP KEY GOES HERE>
EOF

cat >> /etc/apt/sources.list <<EOF
deb https://my.organisation.org/repo debian-jessie main
apt-get update -y
apt-get upgrade -y
EOF

Dockerfiledọc theo dòng

ADD apt_setup.sh /root
RUN sh -ex /root/apt_setup.sh && rm /root/apt_setup.sh
RUN apt-get install -y my-node-js-package

(Trong tình huống cụ thể của bạn, việc apt_setup.shnày sẽ phức tạp hơn, thêm các kho lưu trữ nút nguồn và một số gói trợ giúp như apt-Transport-https .)

Do đó, thực sự có thể sử dụng các gói DebianDocker cùng một lúc, tuy nhiên

Ruột [tôi] đang nói với tôi rằng nếu các gói deb phù hợp thì nó sẽ phổ biến hơn

Đây là một trở ngại chính xác khiến chúng ta phải tự hỏi tại sao Docker chứng tỏ là phổ biến như một hệ thống đóng gói ad hoc , trong khi nó không có ý định là một. (Xem ở trên.)

Hệ thống đóng gói chính thức của NỀN TẢNG từ một bản phân phối nhất định chỉ là một khả năng trong số nhiều người khác để cài đặt phần mềm trong một số môi trường máy tính. Có nhiều nguồn khác có sẵn, như các trình quản lý gói dành riêng cho cộng đồng như npm hoặc opam, các cây cổng như pkgsrc và phân phối mã nguồn đơn giản. Từ quan điểm này, thật dễ hiểu cho sự thành công của Docker như một hệ thống đóng gói đặc biệt :

  • Thông số kỹ thuật của Docker rất gần với kịch bản shell và bất kể nguồn gốc nào, chúng tôi cài đặt phần mềm bằng shell.

  • Docker có một dịch vụ tích hợp (trả tiền) tích hợp trên mạng để lưu trữ các vật phẩm mà nó tạo ra, Docker Hub .

Bây giờ sức mạnh của các gói Debian so với hình ảnh Docker là một hệ thống gói là gì? Việc kiểm soát chặt chẽ các phụ thuộc lúc cài đặt. (Khả năng nâng cấp và hạ cấp cũng tồn tại nhưng không có tầm quan trọng thực tế nếu chúng ta đang triển khai mô hình .) Điều này dẫn đến

Phần kết luận

Nếu bạn chỉ có một sản phẩm được triển khai trong một phiên bản duy nhất (điển hình cho SaaS), thì nhu cầu quản lý phiên bản của bạn rất đơn giản và sử dụng Docker làm trình quản lý gói ad hoc không nên có bất kỳ nhược điểm khó khăn nào. Ngay khi bạn làm việc với một số phiên bản của một sản phẩm hoặc một số sản phẩm, sự phức tạp của vấn đề ràng buộc phiên bản bạn cần giải quyết tăng lên và bạn cần một công cụ thích hợp cho việc này, có thể là các gói Debian hoặc một số hệ thống quản lý cấu hình nếu bạn là phần mềm trộn từ các nguồn gốc khác nhau.


6

Vâng, có nhược điểm.

Với gói .deb, bạn sẽ không thể có hai phiên bản của cùng một ứng dụng trên cùng một máy chủ. Bạn sẽ phải dựa vào các gói phân phối có sẵn, ví dụ nếu ứng dụng của bạn dựa vào nodejs, bạn sẽ bị kẹt với phiên bản phân phối hoặc bạn sẽ phải cài đặt riêng.

Bây giờ khi bạn muốn lưu trữ nhiều ứng dụng trên cùng một máy chủ, bạn sẽ nhanh chóng chạm tường khi chúng phụ thuộc vào cùng một thứ (hãy giữ nodejs ở đây) trong hai phiên bản khác nhau.

Mục tiêu chính của docker là cô lập từng ứng dụng khỏi hệ thống lưu trữ và các ứng dụng khác trên cùng một máy chủ. Có hai lý do để thực hiện việc cách ly này: 1. để tránh sự xâm phạm của ứng dụng để có thể chiếm quyền điều khiển máy chủ hoặc tác động đến ứng dụng khác 2. cung cấp cho ứng dụng các phụ thuộc chính xác của nó và ngăn không cho nó bị ảnh hưởng bởi cập nhật hệ thống hoặc ứng dụng khác phụ thuộc.


Uh, không ai đề xuất sử dụng ruby, nút, python của phân phối, v.v. Bạn cũng tạo các gói của chúng và đặt chúng vào / opt. Gói của bạn sẽ phụ thuộc vào những. Bạn hoàn toàn có thể cài đặt nhiều phiên bản ứng dụng của mình với các gói gỡ lỗi, có rất nhiều ví dụ trong chính Debian. Trên thực tế, đó là cách tốt nhất để quản lý nhiều phiên bản. Câu trả lời này là hoàn toàn sai.
figtrap

1
@figtrap OK hãy thử sử dụng repo đàn hồi chính thức và cài đặt đồng thời elaticsearch v. 2.3 và v. 5.6. Những gì bạn đang mô tả là cài đặt hai gói khác nhau và tinh chỉnh nặng nếu bạn đang thực hiện các gói .deb thích hợp. Đó là một cơn ác mộng về sự phụ thuộc vào xây dựng cũng như bảo trì khi bạn cần hai phiên bản libc khác nhau ở đâu đó sâu trong ngăn xếp.
Tensibai

5

Gói Debian (hoặc RedHat) để cài đặt các ứng dụng đã được thực hiện tốt khi được thực hiện chính xác. Các gói được sử dụng cho mục đích triển khai các ứng dụng được thay đổi không thường xuyên. Các gói Debian liên quan đến một số chi phí chung, như quản lý phiên bản, quản lý phụ thuộc, tập lệnh trước & sau khi cài đặt, v.v ...

Trong nhiều trường hợp, việc nâng cấp từ một số phiên bản cũ lên phiên bản mới đòi hỏi phải viết kịch bản cẩn thận, chú ý đến các chi tiết trong phiên bản, v.v ... Bởi vì việc thay đổi trạng thái hiện tại là khó khăn. Nó sẽ dễ dàng hơn nhiều để thay thế hoàn toàn trạng thái hiện tại bằng một trạng thái mới, mà không làm thay đổi bất cứ điều gì.

Khi bạn quyết định thay thế hoàn toàn cấu hình hoặc phụ thuộc hoặc ứng dụng của mình trên mỗi lần triển khai vì nó dễ dàng hơn và ít bị lỗi hơn. Hầu hết các tổ chức (đã từng) chuyển sang một thể hiện VM hoặc đám mây hoàn toàn mới. Điều đó có nghĩa là việc cài đặt gói sẽ được thực hiện trên máy chủ "sạch" và việc thay đổi các tệp và cấu hình trên máy chủ không còn là vấn đề nữa.

Những nhà phát triển đã tạo ra các gói và không hiểu được sai lầm và sự phức tạp trong các đột biến phải chịu khá nhiều khó khăn.

Thay thế máy ảo là tối ưu phụ khi tất cả những gì bạn cần là thay thế một ứng dụng, đó là lý do tại sao các thùng chứa nhẹ được giới thiệu như một câu trả lời. Sử dụng Docker (hoặc LWC khác), bạn có thể thay thế cơ sở người dùng, bao gồm tất cả các phụ thuộc, mà không cần thay thế chính máy chủ. Bạn cũng có thể lưu trữ nhiều phiên bản của cùng một ứng dụng, với các phụ thuộc khác nhau, trên cùng một máy chủ và chỉ chuyển đổi lưu lượng mạng đến khi nâng cấp. Cũng như chuyển đổi lưu lượng truy cập mạng trở lại trên rollback (xanh lam), một điều rất khó khăn trong trường hợp quản lý triển khai thông qua các gói.

Các container giới thiệu một cách để bó tất cả mã ứng dụng, và các phụ thuộc và cấu hình vào một hình ảnh. Hình ảnh này có nhiều thuộc tính làm cho nó tốt hơn nhiều so với các gói hệ điều hành truyền thống. Ví dụ, nó có các thẻ cho phép tạo phiên bản, nhưng nó cũng có các lớp, cho phép tiết kiệm không gian. Nó cho phép một cách dễ dàng để gửi những hình ảnh này đến các máy chủ và môi trường phát triển, bằng cách sử dụng sổ đăng ký. Và những hình ảnh này có thể được thực thi như các thùng chứa trong bất kỳ môi trường và bất kỳ máy chủ nào, gần như giống hệt nhau. Điều này bao gồm máy tính xách tay của nhà phát triển cũng như môi trường sản xuất. Một lần nữa, điều gì đó khó thực hiện hơn nhiều với VM và / hoặc với các phiên bản phần mềm dựa trên gói. Việc thử nghiệm cùng một hình ảnh trên máy tính xách tay của nhà phát triển và việc giữ nguyên các bit và byte trong sản xuất sẽ loại bỏ rất nhiều "


Cho đến nay tôi đang tìm thấy nó thay thế "hoạt động trên máy của tôi" bằng "hoạt động trên máy của tôi, nhưng hoạt động kỳ lạ trong Docker".
Matt Moran

1

Nói cụ thể về phần đóng gói hình ảnh của Docker, không phải thời gian chạy container có một vài bit nhỏ. Điểm lớn nhất là hình ảnh Docker giống như một chiếc chroot, điều đó có nghĩa là bạn bị vô tình tùy thuộc vào trạng thái hệ thống được chia sẻ vì mọi tệp đang sử dụng phải được đưa vào hình ảnh một cách rõ ràng trong khi gói hệ thống có thể nhận các liên kết động mà bạn không mong đợi hoặc có được nhiều hơn đan xen với các gói khác. Điều này có thể đi kèm với các phụ thuộc C phức tạp được tải mà bạn không biết, ví dụ OpenSSL. Ngoài ra, sử dụng các gói gỡ lỗi không sao chép các bit được chia sẻ trong hệ thống lưu trữ của Docker. Đối với một số điều này có thể là một điều tốt, hiệu suất I / O tốt hơn và ít phần chuyển động hơn, nhưng đối với những người khác, nó có thể là một vấn đề.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.