Tại sao chỉ nên chạy một tiến trình trong một container?

Trong nhiều bài đăng trên blog và ý kiến ​​chung, có một câu nói rằng "một quy trình trên mỗi container".

Tại sao quy tắc này tồn tại? Tại sao không chạy ntp, nginx, uwsgi và nhiều quy trình hơn trong một container duy nhất cần có tất cả các quy trình để hoạt động?

bài đăng trên blog đề cập đến quy tắc này:

• "Single-process-per-container là mẫu thiết kế được đề xuất cho các ứng dụng Docker."
• "Docker chỉ để tạo các container đơn quy trình hoặc dịch vụ đơn."
• "tốt hơn để sử dụng một quy trình cho mỗi container"
• "Chạy một dịch vụ duy nhất như một container"
• "Một quy trình cho mỗi container"
• "một quy trình trên mỗi container"

Hãy quên đi những tranh luận về kiến ​​trúc và triết học cấp cao trong một lúc. Mặc dù có thể có một số trường hợp cạnh trong đó nhiều chức năng trong một container có thể có ý nghĩa, có những lý do rất thực tế tại sao bạn có thể muốn xem xét theo "một chức năng trên mỗi container" như một quy tắc chung:

• Chia tỷ lệ các container theo chiều ngang sẽ dễ dàng hơn nhiều nếu container được cách ly với một chức năng duy nhất. Cần một container apache? Xoay một cái lên một nơi khác. Tuy nhiên, nếu thùng chứa apache của tôi cũng có DB, cron và các phần khác của tôi bị khóa, điều này làm phức tạp mọi thứ.
• Có một chức năng duy nhất cho mỗi container cho phép container dễ dàng được sử dụng lại cho các dự án hoặc mục đích khác.
• Nó cũng làm cho nó dễ di chuyển hơn và có thể dự đoán được cho các nhà phát triển để kéo một thành phần từ sản xuất sang khắc phục sự cố cục bộ thay vì toàn bộ môi trường ứng dụng.
• Việc vá / nâng cấp (cả HĐH và ứng dụng) có thể được thực hiện theo cách cô lập và kiểm soát hơn. Việc tung nhiều bit và bobs trong thùng chứa của bạn không chỉ làm cho hình ảnh lớn hơn mà còn gắn kết các thành phần này lại với nhau. Tại sao phải tắt ứng dụng X và Y chỉ để nâng cấp Z?
  • Ở trên cũng đúng cho việc triển khai mã và rollback.
• Việc tách các chức năng ra nhiều container cho phép linh hoạt hơn từ góc độ bảo mật và cách ly. Bạn có thể muốn (hoặc yêu cầu) các dịch vụ được cách ly ở cấp độ mạng - về mặt vật lý hoặc trong các mạng lớp phủ - để duy trì một tư thế bảo mật mạnh mẽ hoặc tuân thủ những điều như PCI.
• Các yếu tố nhỏ khác như xử lý stdout / stderr và gửi nhật ký đến nhật ký container, giữ cho container càng nhanh chóng càng tốt, v.v.

Lưu ý rằng tôi đang nói chức năng, không xử lý. Ngôn ngữ đó đã lỗi thời. Tài liệu về docker chính thức đã chuyển từ nói "một quá trình" sang thay vào đó đề xuất "một mối quan tâm" cho mỗi container.

Đã giết một container "hai tiến trình" vài ngày trước, có một số điểm đau đối với tôi khiến tôi phải sử dụng hai container thay vì tập lệnh python bắt đầu hai tiến trình:

1. Docker là tốt trong việc nhận ra container bị rơi. Nó không thể làm điều đó khi quy trình chính có vẻ tốt, nhưng một số quy trình khác đã chết một cái chết khủng khiếp. Chắc chắn, bạn có thể theo dõi quá trình của mình bằng tay, nhưng tại sao lại thực hiện điều đó?
2. Nhật ký docker trở nên ít hữu ích hơn khi nhiều quá trình đang đưa nhật ký của chúng vào bàn điều khiển. Một lần nữa, bạn có thể viết tên quy trình vào nhật ký, nhưng docker cũng có thể làm điều đó.
3. Kiểm tra và lý luận về một container khó khăn hơn nhiều.

Đề xuất này xuất phát từ mục tiêu và thiết kế của ảo hóa cấp hệ điều hành

Các thùng chứa đã được thiết kế để cô lập một quy trình cho người khác bằng cách cung cấp cho nó không gian người dùng và hệ thống tệp của riêng nó .
Đây là sự phát triển logic trong chrootviệc cung cấp một hệ thống tệp bị cô lập, bước tiếp theo là cách ly các tiến trình với các hệ thống khác để tránh ghi đè lên bộ nhớ và cho phép sử dụng cùng một tài nguyên (ví dụ cổng Ie TCP 8080) từ nhiều tiến trình mà không có xung đột.

Sự quan tâm chính trong một thùng chứa nó để đóng gói thư viện cần thiết cho quá trình mà không phải lo lắng về xung đột phiên bản. Nếu bạn chạy nhiều quy trình cần hai phiên bản của cùng một thư viện trong cùng một không gian người dùng và hệ thống tệp, bạn sẽ phải điều chỉnh ít nhất LDPATH cho mỗi quy trình để thư viện phù hợp được tìm thấy trước và một số thư viện không thể được điều chỉnh theo cách này, bởi vì đường dẫn của chúng được mã hóa cứng trong tệp thực thi tại thời điểm biên dịch, hãy xem câu hỏi SO này để biết thêm chi tiết.
Ở cấp độ mạng, bạn sẽ phải định cấu hình từng quy trình để tránh sử dụng cùng một cổng.

Chạy nhiều tiến trình trong cùng một vùng chứa yêu cầu một số điều chỉnh lớn và vào cuối ngày sẽ đánh bại mục đích cách ly, nếu bạn có thể chạy nhiều tiến trình trong cùng một không gian người dùng, chia sẻ cùng một tài nguyên tệp và mạng, thì tại sao không chạy chúng trên máy chủ?

Dưới đây là danh sách không đầy đủ về các điều chỉnh / cạm bẫy nặng nề mà tôi có thể nghĩ ra:

• Xử lý nhật ký

  Hoặc là với một khối lượng gắn kết hoặc xen kẽ trên thiết bị xuất chuẩn này mang lại một số quản lý. Nếu sử dụng một khối lượng được gắn kết, container của bạn sẽ có "địa điểm" riêng trên máy chủ hoặc hai container giống nhau sẽ chiến đấu cho cùng một tài nguyên. Khi xen kẽ vào thiết bị xuất chuẩn để tận dụng lợi thế của docker logsnó có thể trở thành cơn ác mộng để phân tích nếu các nguồn không thể được xác định dễ dàng.

• Coi chừng quá trình zombie

  Nếu một trong các quá trình của bạn trong một vụ tai nạn container, giám sát viên có thể không thể dọn sạch những đứa trẻ trong trạng thái zombie, và chủ nhà sẽ không bao giờ thừa kế chúng. Một khi bạn sử dụng hết số lượng pids có sẵn (2 ^ 22, khoảng 4 triệu), một loạt các thứ sẽ thất bại.

• Tách biệt mối quan tâm

  Nếu bạn chạy hai thứ riêng biệt, như một máy chủ apache và logstash trong cùng một container, điều đó có thể dễ dàng xử lý nhật ký, nhưng bạn phải tắt apache để cập nhật logstash. (Trong thực tế, bạn nên sử dụng trình điều khiển đăng nhập của Docker) Nó sẽ là một điểm dừng duyên dáng chờ đợi các phiên hiện tại kết thúc hay không? Nếu đó là một điểm dừng duyên dáng, đôi khi có thể mất nhiều thời gian và trở nên dài hơn để tung ra phiên bản mới. Nếu bạn giết, bạn sẽ tác động đến người dùng cho một người gửi nhật ký và điều đó nên tránh IMHO.

Cuối cùng, khi bạn có nhiều quy trình, bạn đang tạo lại một HĐH và trong trường hợp này, việc sử dụng ảo hóa phần cứng có vẻ phù hợp hơn với nhu cầu này.

Như trong hầu hết các trường hợp, nó không phải là tất cả hoặc không có gì. Hướng dẫn của "một quy trình trên mỗi container" xuất phát từ ý tưởng rằng các container nên phục vụ một mục đích riêng biệt. Ví dụ, một container không nên là cả ứng dụng web và máy chủ Redis.

Có những trường hợp hợp lý khi chạy nhiều tiến trình trong một container, miễn là cả hai tiến trình đều hỗ trợ một chức năng mô-đun duy nhất.

Quá trình tôi sẽ gọi là dịch vụ tại đây, 1 container ~ 1 dịch vụ , nếu bất kỳ dịch vụ nào của tôi bị lỗi thì tôi sẽ chỉ quay lên container tương ứng đó và trong vài giây nữa mọi thứ sẽ hoạt động trở lại. Vì vậy, sẽ không có bất kỳ sự phụ thuộc giữa các dịch vụ. Cách tốt nhất là giữ kích thước vùng chứa của bạn dưới 200 MB và tối đa 500 MB (ngoại trừ các thùng chứa riêng của windows lớn hơn 2 GB), nếu không, nó sẽ tương tự như máy ảo, không chính xác, nhưng hiệu suất đủ. Ngoài ra, hãy xem xét một vài tham số như chia tỷ lệ, làm cách nào tôi có thể làm cho dịch vụ của mình trở nên linh hoạt, tự động triển khai, v.v.

Và, đó hoàn toàn là cuộc gọi của bạn, bạn cần tạo ra các mẫu kiến ​​trúc như dịch vụ vi mô trong môi trường đa giác bằng cách sử dụng công nghệ container phù hợp nhất với môi trường của bạn và sẽ tự động hóa mọi thứ cho bạn.