Sự kiện Dockerfile Contest 2025 do DevOps Việt Nam tổ chức đã là nơi minh chứng cho sự sáng tạo kỹ thuật không giới hạn, đặc biệt trong việc container hóa ứng dụng Frontend. Khác với Backend, việc tối ưu hóa container cho ứng dụng Static Web đòi hỏi một triết lý triệt để hơn về sự tinh gọn, bảo mật và tốc độ phân phối nội dung.

Trong hạng mục ReactJS, anh Nguyễn Hữu Phương đã xuất sắc giành vị trí TOP 1 REACTJS với một Dockerfile được ví von là đỉnh cao của sự tối giản. Chiến lược đột phá của anh là xây dựng image từ FROM SCRATCH và tự biên dịch một Web Server tĩnh, siêu nhỏ. Đây không chỉ là chiến thắng về kích thước image mà còn là thắng lợi về tư duy kiến trúc. Chúng tôi hân hạnh mang đến cuộc phỏng vấn độc quyền với anh Phương để khám phá những bí quyết kỹ thuật đằng sau Dockerfile Zero này.

Bài phỏng vấn độc quyền này sẽ đi sâu vào triết lý tối giản triệt để của anh Phương, hé lộ cách anh tự biên dịch Web Server tĩnh, áp dụng chiến lược nén kép ngay tại giai đoạn build, và tổ chức Docker Layer một cách khoa học để thiết lập một kỷ lục mới về triển khai ứng dụng Frontend hiệu suất cao.

Trước hết, Anh có thể chia sẻ đôi nét về kinh nghiệm của mình trong lĩnh vực tối ưu hóa Frontend Deployment? Và điều gì đã thúc đẩy Anh xây dựng image cuối cùng FROM SCRATCH, không dựa trên bất kỳ base image nào? Tư duy kiến trúc nào đã dẫn đến quyết định tối giản này?

Trước đây, mình cũng triển khai Frontend theo cách phổ biến, chủ yếu dựa vào các base image sẵn có. Tuy nhiên, khi tham gia cuộc thi, mình có dịp phân tích kỹ lưỡng toàn bộ quy trình từ build đến lúc server phục vụ file tĩnh.

Khi xem xét từng bước, mình nhận ra một sự thật: phần lớn nội dung trong các base image thực tế không được sử dụng. Thứ chúng ta thực sự cần chỉ là một web server tối giản và các file đã được build. Từ đó, câu hỏi được đặt ra: nếu không cần hệ điều hành hay các công cụ bổ trợ, tại sao phải mang chúng theo?

Quyết định chuyển sang FROM SCRATCH trở nên hoàn toàn hợp lý. Kết quả là image nhỏ hơn đáng kể, giảm bề mặt tấn công và thời gian khởi chạy nhanh hơn. Quan trọng hơn, nó buộc mình phải hiểu rõ bản chất của từng bước trong quá trình triển khai.

Thay vì sử dụng base image Web Server có sẵn, Anh đã tự biên dịch một Binary Web Server tĩnh, siêu nhỏ và tối ưu. Mục tiêu chiến lược của việc tự biên dịch này là gì? Anh đã vượt qua những thách thức kỹ thuật nào để đạt được lợi ích mà Web Server sẵn có không thể mang lại?

Khi đã chọn FROM SCRATCH, thách thức lớn nhất là không có các thư viện hệ thống nào đi kèm. Các web server phổ biến như Nginx thường cần nhiều thư viện phụ thuộc. Do đó, cách duy nhất là tự biên dịch một phiên bản Nginx có thể đứng độc lập, nghĩa là toàn bộ phần phụ thuộc được nhúng trực tiếp vào bên trong binary.

Một khi đã đi theo hướng tự biên dịch, mình tiếp tục tối ưu bằng cách loại bỏ toàn bộ module không cần thiết như proxy, SSL hay rewrite, những thứ không phục vụ cho mục tiêu duy nhất là cung cấp file tĩnh. Phần còn lại chỉ tập trung vào đọc file và nén dữ liệu. Dù cần thử nghiệm lặp lại, binary thu được nhỏ hơn, an toàn hơn và hiệu năng vẫn ổn định. Ít thành phần hơn luôn đồng nghĩa với ít rủi ro hơn.

Anh xây dựng một Stage riêng để nén kép (Gzip + Brotli) toàn bộ asset ngay tại Build. Việc đưa nén vào Build Pipeline thay vì Runtime mang lại ý nghĩa chiến lược gì?

Nén trước từ giai đoạn build mang lại ý nghĩa chiến lược là giảm tải đáng kể cho server. Nếu để server thực hiện nén khi có request, mỗi lượt truy cập sẽ tạo thêm áp lực lên CPU, đặc biệt khi lưu lượng người dùng tăng cao.

Nén sẵn cho phép chúng ta dùng mức nén tối đa mà không ảnh hưởng đến thời gian phản hồi ở runtime. Khi ứng dụng chạy, server chỉ việc gửi file đã nén, không cần xử lý gì thêm. Điều này cải thiện trực tiếp time to first byte, một yếu tố cực kỳ quan trọng trong trải nghiệm người dùng, đặc biệt với các dịch vụ toàn cầu.

Anh lựa chọn pnpm và tận dụng External Cache trong Docker. Nguyên tắc vàng khi tổ chức Docker Layer để tối ưu tốc độ build và CI/CD là gì?

pnpm có khả năng chia sẻ package rất hiệu quả. Khi kết hợp với cách Docker lưu cache theo từng layer, lợi ích thể hiện rõ ràng.

Nguyên tắc tổ chức Docker layer mà mình luôn áp dụng là tách phần ít thay đổi lên trên và phần thay đổi thường xuyên xuống dưới. Dependencies thường ổn định, trong khi source code thay đổi liên tục. Vì vậy, mình cài dependencies trước, sau đó mới copy code vào. Nhờ đó, khi chỉ sửa code, Docker không phải cài lại dependencies, giúp thời gian build giảm mạnh. Việc kết hợp thêm external cache cho phép tái sử dụng cache giữa nhiều môi trường CI, giúp thời gian build có thể rút xuống chỉ còn vài chục giây khi có thay đổi nhỏ.

Image cuối cùng chạy dưới non-root user với phân quyền chặt chẽ. Triết lý bảo mật của Anh trong việc thiết lập cấu hình này là gì?

Việc không chạy container bằng quyền root là nguyên tắc bảo mật được khuyến nghị rộng rãi. Triết lý cốt lõi ở đây là chỉ cấp đúng mức quyền cần thiết để làm việc.Với web server phục vụ file tĩnh, quyền cần thiết chỉ là đọc file, không cần quyền ghi, xóa hay truy cập sâu vào hệ thống. mình tạo một user riêng với quyền tối thiểu và để server chạy bằng user đó. Nếu có lỗ hổng bị khai thác, kẻ tấn công cũng chỉ hoạt động trong phạm vi rất hạn chế, giảm thiểu nguy cơ leo thang đặc quyền. Đây là lớp bảo vệ quan trọng trong các môi trường Internet công khai.

Cuối cùng, Anh có bài học quan trọng nào muốn chia sẻ về tối ưu container cho ứng dụng web tĩnh? Và Anh đánh giá thế nào về tương lai Frontend: WebAssembly, Edge Computing?

Bài học lớn nhất mình rút ra là: hãy chuyển toàn bộ phần việc nặng sang giai đoạn build, để runtime nhẹ nhất có thể. Build có thể tốn thời gian hay tài nguyên, nhưng đổi lại người dùng sẽ nhận được trải nghiệm nhanh và ổn định hơn rất nhiều. Tối ưu muốn hiệu quả phải toàn diện: image nhẹ, cache tốt, nén sẵn, bảo mật chặt chẽ; tất cả cần kết hợp với nhau chứ không thể tách rời.

Về tương lai, mình tin WebAssembly và Edge Computing sẽ tạo ra thay đổi lớn. WebAssembly cho phép xử lý phức tạp ngay trên trình duyệt, còn Edge giúp đưa nội dung đến gần người dùng nhất có thể. Khi hai yếu tố này kết hợp, chúng ta có thể xây dựng các ứng dụng rất nhanh, độ trễ thấp, và các kinh nghiệm tối ưu container hiện tại vẫn giữ vai trò quan trọng trong bối cảnh đó.

Thành công của anh Nguyễn Hữu Phương đã thiết lập một tiêu chuẩn mới cho việc triển khai ứng dụng Web tĩnh. Chiến lược cốt lõi của anh, chuyển toàn bộ phần việc nặng sang giai đoạn build, để runtime nhẹ nhất có thể , đã được chứng minh qua việc nén kép (Gzip + Brotli) ngay trong pipeline, tối ưu Layer Caching bằng pnpm, và xây dựng một image từ SCRATCH với binary Web Server tự biên dịch

Những chia sẻ của anh Phương nhấn mạnh tầm quan trọng của việc tối ưu toàn diện và áp dụng triết lý bảo mật non-root user cho môi trường công khai. Kinh nghiệm này là vô giá cho bất kỳ ai làm việc với Frontend Deployment và CI/CD. Anh cũng đưa ra đánh giá đầy triển vọng về tương lai của WebAssembly và Edge Computing, nơi kinh nghiệm tối ưu container hiện tại vẫn giữ vai trò then chốt.

Chúng tôi xin chân thành cảm ơn anh Nguyễn Hữu Phương đã 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 lĩnh vực DevOps và Frontend.

Tham khảo chi tiết Dockerfile của anh Phương tại: Dockerfile Contest 2025