2016-11-23 16 views
5

Tôi đang thiết lập một máy chủ web Flask/uswgi. Tôi vẫn băn khoăn về kiến ​​trúc dịch vụ vi mô:Dockerizing nginx và Flask

Tôi có nên đặt cả nginx và Flask với uwsgi trong một thùng chứa hay tôi đặt chúng trong hai thùng chứa khác nhau và liên kết chúng?

Tôi định chạy các dịch vụ này trong cụm Kubernetes.

Cảm ơn

+0

[this-> tất cả trong một thùng chứa] (https://github.com/tiangolo/uwsgi-nginx-flask-docker) so với [this -> Bình một uwsgi trong một thùng riêng biệt] (http://louistiao.me/posts/re-implementing-the-kubernetes-guestbook-example-with-flask-and-nginx/) – Navid

Trả lời

4

Câu trả lời ngắn:

tôi sẽ triển khai nginx và uwsgi/ứng dụng bình như container riêng biệt. Điều này mang lại cho bạn một kiến ​​trúc linh hoạt hơn, cho phép bạn liên kết nhiều thùng chứa microservices với thể hiện nginx, vì các yêu cầu của bạn cho nhiều dịch vụ tăng lên.

Giải thích:

Với Docker chiến lược thông thường là để phân chia các dịch vụ nginx và dịch vụ uwsgi/bình vào hai container riêng biệt. Sau đó, bạn có thể liên kết cả hai người trong số họ bằng liên kết. Đây là một triết lý kiến ​​trúc chung trong thế giới docker.Các công cụ như docker-compose đơn giản hóa việc quản lý chạy nhiều thùng chứa và tạo liên kết giữa chúng. Các tập tin cấu hình Docker-soạn sau đây cho thấy một ví dụ về điều này:

version: '2' 
services: 

    app: 
    image: flask_app:latest 
    volumes: 
     - /etc/app.cfg:/etc/app.cfg:ro 
    expose: 
     - "8090" 

    http_proxy: 
    image: "nginx:stable" 
    expose: 
     - "80" 
    ports: 
     - "80:8090" 
    volumes: 
     - /etc/app_nginx/conf.d/:/etc/nginx/conf.d/:ro 
    links: 
     - app:app 

Điều này có nghĩa rằng nếu bạn muốn thêm các thùng chứa ứng dụng hơn, bạn có thể đính kèm chúng vào proxy ngnix cùng dễ dàng bằng cách liên kết chúng. Hơn nữa, nếu bạn muốn nâng cấp một phần cơ sở hạ tầng của mình, hãy nói nâng cấp nginx hoặc chuyển từ apache sang nginx, bạn chỉ đang xây dựng lại vùng chứa có liên quan và để mọi thứ còn lại tại chỗ.

Nếu bạn thêm cả hai dịch vụ vào một vùng chứa (ví dụ bằng cách khởi chạy quá trình giám sát từ Dockerfile ENTRYPOINT), điều đó sẽ cho phép bạn chọn dễ dàng hơn để liên lạc giữa quá trình nginx và uwsgi bằng tệp vớ, thay vì bởi IP, nhưng tôi không nghĩ rằng điều này trong nó tự là một lý do đủ mạnh để đặt cả hai trong cùng một container.

Ngoài ra, hãy xem xét nếu cuối cùng bạn kết thúc chạy hai microservices và từng chạy từng dụ nginx của riêng mình, điều đó có nghĩa là bạn có hai mươi log nginx (access.log/error.log) để theo dõi trên hai mươi container.

Nếu bạn đang sử dụng kiến ​​trúc "microservices", điều đó ngụ ý rằng với thời gian bạn sẽ bổ sung thêm nhiều thùng chứa hơn. Trong một hệ sinh thái như vậy, chạy nginx như một quá trình docker riêng biệt và liên kết các microservices với nó làm cho nó dễ dàng hơn để phát triển phù hợp với các yêu cầu mở rộng của bạn.

Một lưu ý về phát hiện dịch vụ

Nếu container đang chạy trong cùng một máy chủ sau đó liên kết tất cả các container là dễ dàng. Nếu các thùng chứa đang chạy trên nhiều máy chủ, sử dụng Kubernetes hoặc Docker, mọi thứ có thể trở nên phức tạp hơn một chút, vì bạn (hoặc khung công tác cụm của bạn) cần có khả năng liên kết địa chỉ DNS của bạn với cá thể nginx của bạn. cần phải có khả năng 'tìm thấy' nhau - điều này bổ sung thêm một chút chi phí khái niệm. Kubernetes giúp bạn đạt được điều này bằng cách nhóm các thùng chứa thành các nhóm, xác định các dịch vụ, v.v.

+0

Bạn có lẽ nên cân nhắc việc sử dụng mạng thay thế các liên kết ngay bây giờ. Nhưng điều này vẫn tuyệt vời :) Tôi đồng ý! – user2662833

1

Triết lý của Docker đang sử dụng microservices trong container. Thuật ngữ "Microservice Architecture" đã nổi lên trong vài năm qua để mô tả một cách cụ thể trong việc thiết kế các ứng dụng phần mềm như các dãy số independently deployable services.

Điều này được cho biết bạn có thể triển khai uwcgi trong một vùng chứa riêng biệt và hưởng lợi từ microservices architecture.

Một số ưu điểm của microservices architecture là:

  • Cải thiện cách ly lỗi
  • Loại bỏ cam kết lâu dài để một chồng công nghệ đơn
  • Làm cho nó dễ dàng hơn cho một nhà phát triển mới để hiểu các chức năng của một dịch vụ
  • Quản lý nâng cấp dễ dàng hơn
1

Nếu bạn đang sử dụng Ngi nx trước máy chủ Flask/uwsgi của bạn, bạn đang sử dụng Nginx như một proxy: nó sẽ chăm sóc chuyển tiếp lưu lượng đến máy chủ, cuối cùng ... Điện thoại

Điểm sử dụng một proxy như Nginx là để có thể cân bằng tải lưu lượng truy cập đến (các) máy chủ: proxy Nginx nhận các yêu cầu và phân phối tải giữa nhiều máy chủ.

Điều này có nghĩa là bạn cần một phiên bản Nginx và một hoặc nhiều phiên bản của máy chủ Flask/usqgi làm máy chủ 'ngược dòng'.

Để đạt được điều này, cách duy nhất là sử dụng các vùng chứa riêng biệt. Lưu ý rằng nếu bạn đang ở trên một nhà cung cấp đám mây như AWS hoặc GKE, cung cấp bộ cân bằng tải để mang lưu lượng truy cập bên ngoài vào cụm Kubernetes của bạn và nếu bạn chỉ sử dụng Nginx để chuyển tiếp lưu lượng truy cập (tức là không sử dụng nó cho TLS hoặc auth) sau đó bạn có thể thậm chí không cần proxy Nginx nhưng có thể sử dụng một dịch vụ mà các proxying cho bạn. Việc thêm Nginx chỉ cho phép bạn kiểm soát nhiều hơn.