Tôi mới bắt đầu làm việc với Docker và Kubernetes và tôi đã xem rất nhiều ngăn xếp, trong đó một số người xây dựng nginx + php trong một hình ảnh duy nhất và một số xây dựng một hình ảnh với nginx và một hình ảnh khác với php (gắn cùng một đường dẫn và bao quanh cả hai container trong cùng một triển khai trong Kubernetes).
Điều gì sẽ là lợi thế của việc xây dựng hai hình ảnh docker thay vì cài đặt cả nginx + php trong cùng một?
Câu trả lời:
PHP với nginx thường được thực hiện bằng cách sử dụng php-fpm, đây là một tiến trình riêng biệt.
Giữ ý tưởng cốt lõi về docker của một quy trình (xem phần cuối của câu trả lời để biết thêm chi tiết về điểm này) cho mỗi container, điều này có ý nghĩa để có quy trình nginx và quy trình php-fpm trong các container riêng biệt.
Khi giao tiếp giữa nginx và php-fpm phát sinh thông qua fastcgi, bộ chứa php-fpm cũng có thể nằm trên một máy chủ riêng biệt và điều này cho phép sử dụng một cụm các thùng chứa php-fpm phía sau nginx.
Sau bức tường bình luận ở đây có thêm một chút nền tảng, tài liệu về docker có đoạn về ý tưởng rằng một container chỉ nên có một mối quan tâm .
Ý tưởng chính của một thùng chứa linux ( lxc ) là để chạy một tiến trình trong một không gian tên bị cô lập ở cấp độ cpu và bộ nhớ, docker thêm vào trên một sự cô lập ở cấp độ hệ thống tập tin.
Ưu điểm là sự thỏa hiệp của một quy trình trong không gian tên này sẽ không cho phép đọc bộ nhớ của các quy trình khác và do đó sẽ ngăn chặn sự thỏa hiệp khác trên máy chủ.
Trong khi nói về nginx và php-fpm, chúng hoạt động theo cặp nhưng mỗi người có một mối quan tâm riêng, nginx sẽ thực hiện phần HTTP, định tuyến, xác thực tiêu đề, v.v. và php-fpm sẽ thực hiện giải thích mã và trả lại phần html cho nginx . Mặc dù thông thường có cả hai cùng nhau phục vụ một ứng dụng duy nhất không bắt buộc.
Tùy thuộc vào ngữ cảnh, có thể có một thùng chứa bao gồm cả ngăn xếp cho một ứng dụng, trên một máy trạm dành cho nhà phát triển có thể dễ dàng hơn. Nhưng lý tưởng cho việc sử dụng sản xuất, cố gắng giữ ít tương tác bên trong container hơn, việc tách các quy trình trong cùng một container với giám sát viên mang đến một phần vấn đề về quy trình zombie và xử lý nhật ký (ví dụ câu chuyện ở đây chỉ nhằm mục đích minh họa).
Vì vậy, cuối cùng tôi sẽ trích dẫn trang docker với một số điểm nhấn:
Trong khi một quy trình trên mỗi container thì thường là một quy tắc tốt, nhưng đó không phải là quy tắc khó và nhanh. Sử dụng phán đoán tốt nhất của bạn để giữ cho container càng sạch sẽ và mô-đun càng tốt .
Không có "quy tắc viên đạn bạc" áp dụng cho mọi thứ, đó luôn là sự cân bằng giữa sự phức tạp trong container và sự phức tạp trong việc tự sắp xếp các container.
Trên thực tế, một điểm còn thiếu ở đây là khả năng mở rộng theo chiều ngang. Có một bài viết từ Jamie Alquiza từ lâu đã đề cập đến điều này:
Nói tóm lại, bạn mở rộng quy mô php-fpm theo chiều ngang để đạt hiệu suất cao hơn. Chia tỷ lệ Nginx + php-fpm với nhau không mang lại cho bạn bất kỳ lợi ích nào. Tôi khuyến khích bạn thực hiện một số thử nghiệm căng thẳng (ví dụ: Tsung, Gatling, v.v.; Xin vui lòng không làm Apache ab, đó là một món đồ chơi rất cũ) để xác minh những gì bài báo đã nêu. Cá nhân tôi có một số kinh nghiệm trong thế giới thực đã chứng minh bài báo nói chung là đúng.
Nhưng có hai nhược điểm (có thể không phải với Kubernetes) đối với máy / máy ảo kim loại trần:
EDITED: Bây giờ đã gần một nửa năm 2019. Mô hình cũ, php-fpm + nginx trong cùng một nhóm, có cách sử dụng khác nhau. Nếu bạn quen thuộc với lưới dịch vụ, thì nginx (hay còn gọi là Nginmesh) sẽ đóng vai trò là một bên để xử lý lưu lượng truy cập theo hướng đông tây. Lưu lượng truy cập giới hạn đông tây chủ yếu được sử dụng để xác thực giữa các dịch vụ hoặc các chức năng ưa thích khác, trong khi php-fpm thuần túy không thể làm điều đó cùng.
Không có lợi ích có ý nghĩa nào vượt trội hơn việc phải quản lý hai container. Miễn là bạn có mối quan hệ 1: 1 giữa các quy trình và chúng phục vụ một mục đích duy nhất, hãy đặt chúng vào cùng một thùng chứa.