Tweet
DevSecOps (Phần 11): Port Binding – Vì sao ứng dụng hiện đại phải tự "mở cổng" thay vì phụ thuộc vào Web Server?
Ngày trước, khi triển khai một ứng dụng web, quy trình thường diễn ra như sau:
Nói cách khác, Web Server là trung tâm, còn ứng dụng chỉ là "khách" chạy bên trong nó.
Nhưng với 12-Factor App, cách tiếp cận này đã thay đổi.
Port Binding là gì?
Yếu tố thứ 7 của 12-Factor App yêu cầu ứng dụng phải tự bind vào một cổng (port) và lắng nghe các kết nối đến, thay vì phụ thuộc vào việc môi trường chạy sẽ "nhúng" (inject) một web server vào lúc triển khai.
Điều đó có nghĩa là:
Web Server không còn là thành phần bắt buộc để ứng dụng có thể hoạt động. Ứng dụng trở thành một dịch vụ độc lập, sẵn sàng được triển khai ở bất kỳ môi trường nào.
Mô hình truyền thống
Trong mô hình cũ:
Browser
│
▼
Apache / NGINX / IIS
│
▼
Application
Ứng dụng phụ thuộc vào Web Server.
Muốn triển khai sang môi trường khác thường phải:
Việc di chuyển giữa các môi trường trở nên phức tạp hơn.
Mô hình của 12-Factor App
Theo 12-Factor App:
Browser
│
▼
Application
(Listen Port 8080)
Ứng dụng tự mở cổng mạng và trực tiếp phục vụ yêu cầu.
Ví dụ:
Chỉ cần chạy ứng dụng là dịch vụ đã sẵn sàng tiếp nhận kết nối. Không cần phụ thuộc vào việc có Apache, NGINX hay IIS cài sẵn trong môi trường thực thi.
Web Server trở thành một thư viện
Thay vì dựa vào Web Server bên ngoài, ứng dụng sẽ khai báo các thư viện cần thiết ngay trong project.
Ví dụ:
Các thư viện này trở thành dependency của ứng dụng, giúp ứng dụng tự đảm nhiệm việc lắng nghe kết nối HTTP và xử lý yêu cầu.
Cùng một ứng dụng, nhiều môi trường
Một trong những lợi ích lớn nhất của Port Binding là không cần sửa mã nguồn khi thay đổi môi trường triển khai.
Ví dụ:
Máy phát triển:
Máy Staging:
Môi trường Production:
Điểm khác biệt chỉ là cấu hình cổng hoặc DNS.
Source code và Build Artifact vẫn giữ nguyên. Ứng dụng chỉ cần bind vào cổng được cấu hình khi khởi động.
Port Binding không chỉ dành cho HTTP
Nhiều người nghĩ Port Binding chỉ áp dụng cho Website.
Thực tế, bất kỳ dịch vụ mạng nào cũng hoạt động theo nguyên tắc này.
Ví dụ:
Chỉ cần một tiến trình lắng nghe trên một cổng và chờ yêu cầu từ bên ngoài thì đó chính là Port Binding.
Một ứng dụng cũng có thể trở thành Backing Service
Ở bài trước, chúng ta đã nói về Backing Services như MySQL, Redis hay SMTP.
Điều thú vị là khi một ứng dụng tự bind vào một cổng và cung cấp dịch vụ, nó cũng có thể trở thành Backing Service cho các ứng dụng khác.
Ví dụ:
Application A
│
REST API
▼
Application B
Hoặc:
Frontend
│
HTTP
▼
Authentication Service
Nhờ Port Binding, mỗi ứng dụng đều có thể hoạt động như một dịch vụ độc lập, giao tiếp với nhau qua mạng mà không cần phụ thuộc vào cùng một máy chủ hay cùng một tiến trình.
Port Binding và Cloud Native
Port Binding là nền tảng của các kiến trúc hiện đại như:
Container chỉ cần chạy ứng dụng và mở cổng nội bộ. Hệ thống điều phối sẽ chịu trách nhiệm ánh xạ (mapping) cổng này ra bên ngoài hoặc định tuyến lưu lượng đến đúng dịch vụ.
Điều này giúp cùng một ứng dụng có thể triển khai trên máy phát triển, môi trường kiểm thử hoặc Production mà không cần thay đổi mã nguồn.
DevSecOps và Port Binding
Port Binding giúp ứng dụng trở thành một thành phần độc lập, tự chứa (self-contained) và dễ triển khai. Khi kết hợp với các nguyên tắc trước của 12-Factor App như Configuration, Backing Services và Build–Release–Run, doanh nghiệp có thể xây dựng các ứng dụng Build Once, Deploy Anywhere.
Đó cũng là nền tảng của DevSecOps và Cloud Native: mỗi dịch vụ tự vận hành, giao tiếp qua các cổng mạng được cấu hình từ môi trường, giảm phụ thuộc vào hạ tầng và sẵn sàng mở rộng hoặc di chuyển giữa các nền tảng một cách linh hoạt.
Ngày trước, khi triển khai một ứng dụng web, quy trình thường diễn ra như sau:
- Cài Apache hoặc NGINX.
- Cấu hình Virtual Host.
- Deploy ứng dụng vào Web Server.
- Khởi động dịch vụ.
Nói cách khác, Web Server là trung tâm, còn ứng dụng chỉ là "khách" chạy bên trong nó.
Nhưng với 12-Factor App, cách tiếp cận này đã thay đổi.
Ứng dụng phải tự cung cấp dịch vụ của mình thông qua Port Binding.
Port Binding là gì?
Yếu tố thứ 7 của 12-Factor App yêu cầu ứng dụng phải tự bind vào một cổng (port) và lắng nghe các kết nối đến, thay vì phụ thuộc vào việc môi trường chạy sẽ "nhúng" (inject) một web server vào lúc triển khai.
Điều đó có nghĩa là:
- Ứng dụng tự khởi động.
- Tự mở cổng mạng.
- Tự nhận và xử lý các yêu cầu từ client.
Web Server không còn là thành phần bắt buộc để ứng dụng có thể hoạt động. Ứng dụng trở thành một dịch vụ độc lập, sẵn sàng được triển khai ở bất kỳ môi trường nào.
Mô hình truyền thống
Trong mô hình cũ:
Browser
│
▼
Apache / NGINX / IIS
│
▼
Application
Ứng dụng phụ thuộc vào Web Server.
Muốn triển khai sang môi trường khác thường phải:
- Cài Web Server.
- Cấu hình lại Virtual Host.
- Thiết lập Module.
- Chỉnh sửa cấu hình.
Việc di chuyển giữa các môi trường trở nên phức tạp hơn.
Mô hình của 12-Factor App
Theo 12-Factor App:
Browser
│
▼
Application
(Listen Port 8080)
Ứng dụng tự mở cổng mạng và trực tiếp phục vụ yêu cầu.
Ví dụ:
Chỉ cần chạy ứng dụng là dịch vụ đã sẵn sàng tiếp nhận kết nối. Không cần phụ thuộc vào việc có Apache, NGINX hay IIS cài sẵn trong môi trường thực thi.
Web Server trở thành một thư viện
Thay vì dựa vào Web Server bên ngoài, ứng dụng sẽ khai báo các thư viện cần thiết ngay trong project.
Ví dụ:
- Python có thể sử dụng Tornado.
- Java có thể sử dụng Jetty.
Các thư viện này trở thành dependency của ứng dụng, giúp ứng dụng tự đảm nhiệm việc lắng nghe kết nối HTTP và xử lý yêu cầu.
Cùng một ứng dụng, nhiều môi trường
Một trong những lợi ích lớn nhất của Port Binding là không cần sửa mã nguồn khi thay đổi môi trường triển khai.
Ví dụ:
Máy phát triển:
Máy Staging:
Môi trường Production:
Điểm khác biệt chỉ là cấu hình cổng hoặc DNS.
Source code và Build Artifact vẫn giữ nguyên. Ứng dụng chỉ cần bind vào cổng được cấu hình khi khởi động.
Port Binding không chỉ dành cho HTTP
Nhiều người nghĩ Port Binding chỉ áp dụng cho Website.
Thực tế, bất kỳ dịch vụ mạng nào cũng hoạt động theo nguyên tắc này.
Ví dụ:
- HTTP
- HTTPS
- REST API
- gRPC
- TCP Server
- WebSocket
- Các dịch vụ nội bộ giữa Microservices
Chỉ cần một tiến trình lắng nghe trên một cổng và chờ yêu cầu từ bên ngoài thì đó chính là Port Binding.
Một ứng dụng cũng có thể trở thành Backing Service
Ở bài trước, chúng ta đã nói về Backing Services như MySQL, Redis hay SMTP.
Điều thú vị là khi một ứng dụng tự bind vào một cổng và cung cấp dịch vụ, nó cũng có thể trở thành Backing Service cho các ứng dụng khác.
Ví dụ:
Application A
│
REST API
▼
Application B
Hoặc:
Frontend
│
HTTP
▼
Authentication Service
Nhờ Port Binding, mỗi ứng dụng đều có thể hoạt động như một dịch vụ độc lập, giao tiếp với nhau qua mạng mà không cần phụ thuộc vào cùng một máy chủ hay cùng một tiến trình.
Port Binding và Cloud Native
Port Binding là nền tảng của các kiến trúc hiện đại như:
- Docker
- Kubernetes
- Microservices
Container chỉ cần chạy ứng dụng và mở cổng nội bộ. Hệ thống điều phối sẽ chịu trách nhiệm ánh xạ (mapping) cổng này ra bên ngoài hoặc định tuyến lưu lượng đến đúng dịch vụ.
Điều này giúp cùng một ứng dụng có thể triển khai trên máy phát triển, môi trường kiểm thử hoặc Production mà không cần thay đổi mã nguồn.
DevSecOps và Port Binding
Port Binding giúp ứng dụng trở thành một thành phần độc lập, tự chứa (self-contained) và dễ triển khai. Khi kết hợp với các nguyên tắc trước của 12-Factor App như Configuration, Backing Services và Build–Release–Run, doanh nghiệp có thể xây dựng các ứng dụng Build Once, Deploy Anywhere.
Đó cũng là nền tảng của DevSecOps và Cloud Native: mỗi dịch vụ tự vận hành, giao tiếp qua các cổng mạng được cấu hình từ môi trường, giảm phụ thuộc vào hạ tầng và sẵn sàng mở rộng hoặc di chuyển giữa các nền tảng một cách linh hoạt.
Attached Files