Gặp gỡ Nguyễn Phúc Bảo Lâm – Chuyên Gia Vô Địch Lightest Frontend Image Dockerfile Contest 2025

Sự kiện Dockerfile Contest 2025 do DevOps VietNam tổ chức đã khép lại một cách thành công rực rỡ. Cuộc thi không chỉ là nơi so tài kỹ thuật mà còn là diễn đàn để các chuyên gia chia sẻ những tư duy kiến trúc container tân tiến nhất. Đặc biệt, thách thức tối ưu hóa cho frontend static đã chứng kiến một kỷ lục Docker Image có kích thước ấn tượng.

Chúng tôi hân hạnh có cuộc phỏng vấn độc quyền với anh Nguyễn Phúc Bảo Lâm, người đã xuất sắc giành vị trí TOP 1 LIGHTEST FRONTEND IMAGE. Giải pháp của anh Lâm đã minh chứng cho khả năng cô đọng một ứng dụng web hiện đại vào kích thước tối thiểu, đặt ra một cách về hiệu quả tài nguyên. Hãy cùng lắng nghe những chia sẻ sâu sắc từ chuyên gia về hành trình chinh phục thử thách Dockerfile contest 2025 và những bài học quý giá để áp dụng vào thực tế.

Xin chúc mừng anh Lâm. Anh có thể chia sẻ đôi nét về kinh nghiệm của mình? Khi tham gia cuộc thi với mục tiêu đạt kích thước Image nhẹ nhất, Anh đã đặt ra mục tiêu chiến lược nào? Anh nhận thấy đâu là rào cản lớn nhất khi tối ưu hóa kích thước Image cho một ứng dụng Frontend hiện đại?

Mình làm dev được 2 năm rồi, chủ yếu trong lĩnh vực web game và có một thời gian gắn bó làm ứng dụng AI.

Chiến lược ban đầu của mình cũng đơn giản lắm: chọn một Base Image với web server nhỏ nhất có thể và khiến cho build files nhỏ lại là được. Nếu không tìm được base image vừa ý, mình sẵn sàng tự viết một cái web server from scratch, nhưng may mắn là mình tìm được.

Mình nghĩ một ứng dụng web hiện đại sẽ có hai kiểu: một là static files như đề bài, hai là server-side rendering (SSR) để viết ứng dụng demo ăn liền như dùng NextJS chẳng hạn. Với Static files, kích thước image nhỏ rất dễ. Nhưng với SSR viết bằng NextJS hoặc framework dựa trên NodeJS, tối ưu kích thước là chuyện rất khó vì bản chất là mình phải mở một cái server NodeJS, thứ ăn tài nguyên dung lượng ổ cứng rất nhiều, vì vậy không gian để tối ưu hóa kích thước những ứng dụng như vậy rất hạn chế.

Giải pháp của Anh không tự xây dựng Base Image Runtime mà sử dụng Base Image lipanski/docker-static-website đã được tối giản hóa triệt để. Tư duy Kiến trúc nào đã dẫn đến quyết định này? Theo Anh, việc sử dụng một Base Image chuyên biệt, đã được tối ưu sẵn mang lại lợi ích chiến lược gì so với việc tự build từ scratch hay alpine cho các ứng dụng Frontend static?

Theo mình, muốn viết một web server nhỏ hơn nữa để cho vào from scratch cũng được nhưng mà như vậy mình phải maintain thêm một project, thêm công việc khá nhiều so với lợi ích nó đem lại. Trong thực tế, người khác muốn maintain project này phải đọc code nữa thì không hay.

Một ứng dụng frontend static là một trường hợp khá phổ biến hiện nay nên cũng có rất nhiều lựa chọn làm base image viết sẵn cho từng nhu cầu của dự án. Nếu chỉ cần nhẹ nhất có thể thì mọi người có thể dùng image lipanski/docker-static-website. Còn cần độ phổ biến, ổn định, hiệu năng cao thì cứ nginx hay HAproxy mà dùng.

Trong Stage Build, Anh đã tận dụng các công cụ hiện đại (như pnpm) và kỹ thuật Layer Caching cho việc cài đặt dependencies. Anh có thể chia sẻ nguyên tắc vàng của mình khi tổ chức Docker Layer để đảm bảo tốc độ build nhanh nhất cho các dự án Frontend? Việc này quan trọng như thế nào đối với hiệu quả CI/CD của đội nhóm?

Nguyên tắc là cái gì lâu thì mình cache và cache lâu nhất có thể.

Thường thì quá trình cài dependencies sẽ lâu và build dependencies cũng có thể lâu tùy dự án. Mình sẽ lưu cache những việc này lâu nhất có thể bằng cách copy và cài dependencies trước rồi sau đó copy code vào sau. Như vậy, thay đổi trong code không ảnh hưởng gì nhiều đến layer cache trên. Làm vậy thì CI/CD cũng sẽ nhanh hơn trong những thay đổi không đụng gì đến dependencies.

Anh đã tích hợp việc tiền nén pre-compression các static asset bằng Gzip ngay tại giai đoạn Build. Ý nghĩa chiến lược của việc này là gì so với việc để Web Server BusyBox httpd thực hiện nén tại Runtime? Việc này ảnh hưởng như thế nào đến tốc độ tải trang và hiệu suất tổng thể của ứng dụng?

Pre-compression giúp BusyBox không cần phải tự mình nén, tốn tài nguyên server tại runtime.

Làm vậy cũng cải thiện được phần nào throughput của hệ thống và giảm latency do web server phải nén tài nguyên trước khi gửi qua internet.

Để đạt được kích thước Image cực nhỏ, Anh đã giới hạn tối đa các công cụ và thư viện. Theo Anh, việc này đã giảm thiểu Rủi ro Bảo mật ở cấp độ nào? Và Anh làm thế nào để đảm bảo tính ổn định và khả năng phục hồi của ứng dụng trong môi trường Runtime siêu tối giản, nơi không có sẵn các công cụ Debugging?

Rủi ro bảo mật được giảm khá nhiều vì giảm thư viện đồng nghĩa với việc hạn chế CVE. Không có shell thì khó mà chạy script backdoor được.

Nếu trong quá trình sử dụng gặp vấn đề thì docker logs (dùng để xem logs của app) và docker debug dùng để attach shell, vim, nano, htop, curl vào để thao tác trong container vẫn sẽ là hai thứ chúng ta có thể dùng để kiểm tra nếu mọi người dùng Docker Engine để làm môi trường chạy ứng dụng. Những môi trường khác cũng có những công cụ tương tự.

Cuối cùng, với tư cách là chuyên gia có giải pháp đạt kích thước Image nhỏ nhất, Anh có Bài học quan trọng nhất nào muốn chia sẻ với cộng đồng về Tư duy Cấu trúc Image? Anh dự đoán xu hướng công nghệ nào sẽ tiếp tục định hình việc tối ưu kích thước Image Frontend trong những năm tới?

Theo mình thì cấu trúc image cũng chính là cấu trúc của Linux. Nếu mọi người muốn tối ưu Docker thì vẫn nên dùng Linux nhiều là đã có rất nhiều kiến thức về Docker rồi.

Nếu nói về tương lai vài năm tới thì có thể AVIF image format và ZSTD compression sẽ giúp ích khá nhiều trong việc tối ưu kích thước nói chung.

Chiến thắng của Nguyễn Phúc Bảo Lâm đã minh chứng cho sức mạnh của tư duy tối giản và việc áp dụng các kỹ thuật DevOps tiên tiến nhất: từ việc lựa chọn base image chuyên biệt để giảm thiểu tài nguyên, chiến lược Pre-compression chuyển gánh nặng hiệu năng từ runtime sang build time, đến việc quản lý layer cache thông minh để tăng tốc độ CI/CD.

Giải pháp đạt kích thước Image nhẹ nhất của anh Lâm không chỉ là một thành tích cá nhân mà còn là một đóng góp quan trọng, cung cấp mô hình lý tưởng cho các tổ chức đang tìm cách tối ưu hóa chi phí lưu trữ, tăng tốc độ Deployment và cải thiện hiệu suất tổng thể cho các ứng dụng Frontend static của mình.

Chúng tôi xin chân thành cảm ơn anh Nguyễn Phúc Bảo Lâm đã dành thời gian chia sẻ và chúc anh tiếp tục gặt hái nhiều thành công hơn nữa trong tương lai.

Tham khảo chi tiết Dockerfile của anh Lâm tại: Dockerfile Contest 2025