Docker có phù hợp với trường hợp sử dụng của tôi không?

Công ty của tôi có một hệ thống mà chúng tôi bán bao gồm về cơ bản là một "Smartbox" máy tính mini đang chạy Ubuntu 12.04. Hộp này chạy một ứng dụng Django cộng với một số quy trình khởi động khác nhau liên quan đến nó. Không nhiều lắm. Chúng tôi có hàng ngàn hộp này trên sân. Chúng tôi quản lý các phụ thuộc gói, đăng ký quy trình, vv thông qua gói gỡ lỗi với mức độ thành công khác nhau.

Chúng tôi cần một cách để đẩy các bản cập nhật ra cho người dùng của mình một cách hiệu quả và mạnh mẽ. Chúng tôi cũng cần một cái gì đó khi chúng tôi nâng cấp HĐH (chúng tôi đã quá hạn cho việc nâng cấp Ubuntu như bạn có thể nói), chúng tôi có thể cảm thấy tương đối an toàn về các gói của chúng tôi "chỉ hoạt động".

Tôi không biết nhiều về Docker, nhưng khi tôi mới nghe về vấn đề của chúng tôi (tôi là một người thuê mới), Docker là suy nghĩ đầu tiên của tôi. Nhưng tôi càng nghĩ về nó, tôi cảm thấy có lẽ không phải vậy, vì những chiếc hộp này là của chúng tôi, chúng tôi điều khiển HĐH trên đó, đây là một phần quan trọng trong đề xuất giá trị của Docker, hoặc tôi hiểu. Vì vậy, nếu chúng ta BIẾT các hộp của mình sẽ luôn là Ubuntu và về cơ bản chúng ta chỉ có một ứng dụng Django cộng với một số quy trình để chạy, Docker có tốt hơn gói gỡ lỗi không?

TL; DR: Docker so với các gói deb cho một thiết bị phân tán sẽ luôn chạy Ubuntu nên tính độc lập của nền tảng không phải là điều quan trọng.

Tôi không chắc chắn 100% tôi hiểu từ câu hỏi, nhưng có vẻ như giải pháp Docker sẽ đi từ việc có một thiết bị (vật lý?) Có HĐH và ứng dụng của bạn được cài đặt trên đó, để có một thiết bị có HĐH và Docker trên nó, chạy một container với ứng dụng của bạn trong đó. Điều đó không làm giảm nhu cầu cập nhật HĐH trong máy chủ và nó thêm một lớp phức tạp (và nhiều cập nhật khác để giải quyết, vì giờ đây bạn sẽ phải giữ Docker và HĐH được vá) mà không có lợi ích rõ ràng theo như các lĩnh vực cụ thể được đề cập trong câu hỏi có liên quan.

Tuy nhiên, nếu bạn đang nói về việc chuyển từ thiết bị ảo sang bộ chứa Docker, điều đó có khả năng giúp bạn giải quyết mọi thứ, nhưng nó cũng thêm Docker như một sự phụ thuộc cho sản phẩm của bạn; bạn sẽ loại bỏ bất cứ ai không sử dụng Docker và không muốn thêm nó vào ngăn xếp của họ chỉ để sử dụng sản phẩm của bạn. Bạn có thể tiếp tục hỗ trợ những người không / không sử dụng Docker bằng cách tiếp tục gửi thiết bị ảo (bây giờ là "di sản") như trước đây, nhưng giờ bạn đã tăng gấp đôi khối lượng công việc của mình vì bạn có hai bản phân phối để hỗ trợ thay vì một.

Tôi đã làm việc với Docker một thời gian dài. Tính độc lập của nền tảng là tốt, nhưng đó không phải là điều tôi cho là hữu ích nhất về Docker.

Đầu tiên và quan trọng nhất, bạn có được độ lặp lại. Bạn có thể tạo Dockerfile, gỡ lỗi trong vùng chứa trên máy phát triển của mình, chạy thử nghiệm trên máy chủ tích hợp liên tục và sau đó trong sản phẩm cuối cùng của bạn và bạn biết rằng nó sẽ hoạt động giống nhau trong tất cả các môi trường đó. Không quên một phụ thuộc mà nhà phát triển đã cài đặt trên máy của họ. Ngoài ra, các nhà phát triển của bạn không phải sử dụng Ubuntu tại bàn của họ. Quan trọng để giữ cho chúng tôi người dùng Arch Linux hạnh phúc :-)

Thứ hai, đối với kịch bản nâng cấp của bạn, bạn có thể có nhiều phiên bản được kéo vào máy cùng một lúc. Nếu bạn làm một docker pull myapp:2.0lúc 1.0đang chạy, bạn có thể trao đổi 2.0cực kỳ nhanh chóng. Nhanh hơn nhiều so với việc nâng cấp hệ điều hành đầy đủ thường sẽ mất. Nếu bạn sử dụng một dàn nhạc với nhiều phiên bản microservice, bạn thậm chí có thể thực hiện nâng cấp mà không làm gián đoạn dịch vụ.

Nếu bạn sử dụng mô hình microservice, Docker cũng cung cấp các hộp cát có thể hạn chế lượng sát thương mà kẻ tấn công có thể gây ra trong trường hợp khai thác. Thay vì giành quyền kiểm soát toàn bộ máy, họ chỉ giành quyền kiểm soát một container.

Nhược điểm chính là bạn cần hệ điều hành máy chủ và một số loại phối hợp. Có rất nhiều sự lựa chọn cho điều đó, nhưng đừng đánh giá thấp khối lượng công việc cần thiết để đánh giá một công việc, đưa nó vào vị trí và duy trì nó.

Mặc dù có một số Docker vùng chồng chéo nhỏ và các hệ thống đóng gói Debian về cơ bản giải quyết hai vấn đề rất khác nhau :

• Hệ thống đóng gói Debian được xây dựng để cài đặt phần mềm trên máy chủ và nâng cấp phần mềm dễ dàng nhất có thể. Nó có thể xử lý các mẫu phụ thuộc và ràng buộc phức tạp giữa các thành phần phần mềm, như phần mềm của X phiên bản A yêu cầu phần mềm Y với phiên bản B hoặc phần mềm X hoặc cài đặt mới hơn của phần mềm X không bao giờ được cài đặt với phần mềm Z phiên bản C.

• Hệ thống Docker được hình thành để dễ dàng mô tả và triển khai các dịch vụ, đặc biệt là các dịch vụ vi mô, có thể trên một số máy chủ - ví dụ: một Docker swarm hoặc cụm Kubernetes.

Hai vấn đề này về cơ bản là trực giao, có nghĩa là đưa ra vấn đề triển khai để giải quyết, người ta có thể sử dụng một trong số chúng, cả hai hoặc thậm chí không ai trong số chúng, như một phần của giải pháp. Khi sử dụng cả hai, gói Debian được sử dụng để sản xuất hình ảnh Docker và Dockerfile của bạn (công thức được sử dụng để chuẩn bị hình ảnh Docker mô tả hệ thống ảo hóa của Wap mà chạy trong một container) về cơ bản sẽ đăng ký kho lưu trữ Debian của bạn trong nguồn của hệ thống đóng gói Debian và cài đặt gói của bạn.

Với suy nghĩ này, dường như với tôi rằng những gì bạn đang thực sự tìm kiếm là triển khai mô hình máy chủ bất biến. Sự phát triển gần đây trong các công nghệ đám mây giúp nâng cấp phần mềm không phải bằng cách sử dụng hệ thống nâng cấp phần mềm cổ điển từ hệ thống gói phần mềm (như hệ thống đóng gói Debian) mà chỉ bằng cách thay thế toàn bộ máy chủ cùng một lúc. (Một số người đã làm điều này trước sự phát triển này bằng cách có ba hệ điều hành trên một máy chủ, hai người được sử dụng thay thế để chạy thiết bị và một hệ điều hành nhỏ dành riêng để thực hiện thay thế thiết bị. Mặc dù không quá phức tạp, nhưng điều này dường như vẫn luôn là một thích hợp.) Kỹ thuật này có thể khiến bạn quan tâm vì nếu bạn được sử dụng để nâng cấp phần mềm trên máy chủ của mình bằng trình quản lý gói, trạng thái cuối cùng của máy chủ phụ thuộc vào lịch sử nâng cấp của máy chủ - đặc biệt là nếu xảy ra lỗi trong quá trình nâng cấp. Sự không đồng nhất này là xấu,

Chúng tôi có hàng ngàn hộp này trên sân. Chúng tôi quản lý các phụ thuộc gói, đăng ký quy trình, vv thông qua gói gỡ lỗi với mức độ thành công khác nhau.

có thể liên quan đến điều này. Mẫu máy chủ bất biến xóa sạch nguồn lỗi này bằng cách phá hủy khái niệm về lịch sử nâng cấp của Cameron khỏi vấn đề.

Bây giờ có nhiều tùy chọn khác nhau để triển khai mẫu máy chủ không thay đổi, hai lựa chọn phổ biến là sử dụng hình ảnh Docker, hình ảnh hoặc sử dụng hình ảnh ví dụ chính chủ từ nhà cung cấp đám mây của bạn (chúng được gọi là AMI trong AWS và chỉ là Hình ảnh tùy chỉnh trong Google Compute Engine) . Trường hợp sử dụng của bạn cấm sử dụng các kỹ thuật dựa trên đám mây, do đó tôi sẽ coi hình ảnh Docker là lựa chọn đủ điều kiện duy nhất. (Để hoàn thành, chắc chắn có thể sử dụng các phương pháp khác, ví dụ như sử dụng Virtual Box hoặc giải pháp ảo hóa tương tự, như một giải pháp thay thế cho Docker.)

Khi sử dụng kỹ thuật mẫu máy chủ bất biến, bạn giới thiệu một vật phẩm mới (hình ảnh Docker) đại diện cho máy chủ của bạn và vật phẩm này cũng có thể được kiểm tra, và rất dễ dàng để có được một thiết lập sao chép chính xác các cài đặt sản xuất của bạn - ngoài tải dịch vụ.

Bây giờ để xem xét vấn đề cụ thể mà bạn đã mô tả, hãy giả sử triển khai mẫu máy chủ bất biến với Docker thực sự là những gì bạn muốn. Vì hệ thống Docker và hệ thống đóng gói Debian là bổ sung thay vì loại trừ lẫn nhau (xem phần giới thiệu), chúng tôi vẫn phải giải quyết câu hỏi nếu bạn nên chuẩn bị gói Debian cho phần mềm của mình.

Sự liên quan của việc sử dụng gói Debian để cài đặt phần mềm của bạn (trong hình ảnh Docker hoặc trên máy chủ) nằm ở sự phức tạp của vấn đề phiên bản mà bạn phải giải quyết. Nếu bạn chạy cùng lúc một số phiên bản phần mềm của mình, đôi khi cần hạ cấp và có các yêu cầu phiên bản phức tạp mà bạn cần phải ghi chép cẩn thận, có một gói Debian là điều bắt buộc. Mặt khác, bước này có thể được bỏ qua - nhưng vì bạn đã nỗ lực để sản xuất và triển khai các gói này, nên không có giá trị thực sự nào để bỏ qua công việc của bạn. Do đó tôi sẽ đề nghị tiếp tục sản xuất các gói Debian của bạn.

Docker nghe có vẻ hợp lý với tôi, vì bạn có thể thực hiện và kiểm tra các thay đổi đối với container trong nhà, và sau đó tùy thuộc vào quá trình phát hành của bạn, hãy khởi động lại các container luôn kéo: mới nhất hoặc một cái gì đó tương tự sẽ cung cấp bản nâng cấp đã được thử nghiệm.

Cân nhắc bạn sẽ cần xử lý bao gồm lưu trữ dữ liệu vì các thùng chứa không giữ lại các thay đổi khi khởi động lại, vì vậy bạn sẽ muốn có một khối lượng dữ liệu. Có lẽ bạn sẽ có nhiều cân nhắc hơn nữa khi bạn tìm hiểu kỹ về nó. Hệ thống mà tôi hiện đang làm việc (tất cả dựa trên docker) đã được phát triển hơn một năm nay và chúng tôi vẫn đang tìm kiếm các khu vực mà chúng tôi cần thay đổi về bộ chứa, cấu hình, v.v.

Bởi và docker lớn cung cấp nhiều lợi thế cho cả nhà phát triển và nhân viên vận hành. Tôi sử dụng docker cho một số ứng dụng của mình và thấy nó là một cách tiếp cận rất đáng tin cậy và mạnh mẽ.

Vấn đề của tôi với bạn khi áp dụng docker là tôi không nghe thấy bạn hỏi đúng câu hỏi và bạn có thể khiến cuộc sống của bạn trở nên phức tạp hơn mà không giải quyết được các yêu cầu quan trọng nhất của bạn.

Câu hỏi đầu tiên bạn nên hỏi (bạn nói rằng bạn là người mới) là các bản cập nhật cho HĐH & ứng dụng được xử lý như thế nào bây giờ? Phương pháp hiện tại có hiệu quả với bạn (công ty của bạn) không? Những gì hoạt động tốt? Điều gì có thể được cải thiện? Bạn có thể thực hiện kiểm tra cấu hình vật lý trên các máy mục tiêu của mình trong trường để xác minh rằng chúng có các bản vá hệ điều hành chính xác, ứng dụng & có bất kỳ thay đổi trái phép nào không.

Tôi yêu docker, nhưng tôi sẽ không nhảy vào bandwagon mà không đánh giá trước bạn đang ở đâu bao gồm những gì hoạt động tốt và những gì cần được cải thiện.

Tôi nghĩ rằng nó có thể là một lựa chọn tốt (cần thử nghiệm thêm)

Bạn có thể cung cấp một URL với tất cả các thẻ / phiên bản của container bạn đã tạo và khách hàng sẽ đọc URL đó để xem liệu có phiên bản mới của container không.

Bạn có thể lưu trữ các tệp / cài đặt cá nhân trên cục bộ và bạn sẽ không bao giờ bị mất thông tin đó trong các bản nâng cấp và bạn sẽ đảm bảo rằng những gì bạn đã thực hiện và thử nghiệm sẽ hoạt động cho mọi người theo cùng một cách.

Thậm chí bạn có thể cung cấp cho người dùng khả năng chọn phiên bản nào có sẵn mà họ muốn sử dụng (nếu bạn muốn cung cấp khả năng đó).

Nó sẽ giống như "" chỉ nâng cấp một gói "", nói về việc chỉ lấy một phiên bản mới của container, tốt hơn nhiều là xử lý các gói debian;)