Sự kiện Dockerfile Contest 2025 do DevOps VietNam tổ chức đã khép lại với những màn trình diễn kỹ thuật ấn tượng, đặc biệt là ở hạng mục Java. Cuộc thi đã chứng kiến một bước tiến vượt bậc trong việc tự động hóa bảo mật, nơi Dockerfile không chỉ là công cụ build mà còn là một Security Control Point.

Chúng tôi hân hạnh có cuộc phỏng vấn độc quyền với anh Trịnh Thế Long, người đã xuất sắc giành vị trí TOP 2 JAVA. Giải pháp của anh Long là hình mẫu của một Pipeline Self-Patching. 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 này.

Xin chào anh Long. Anh có thể chia sẻ đôi nét về kinh nghiệm của mình? Khi tham gia cuộc thi, Anh đã đặt ra mục tiêu chiến lược nào cho Dockerfile của mình? Giải pháp của Anh tập trung mạnh vào Tự động hóa Bảo mật. Anh nhìn nhận vai trò của DevOps trong việc đảm bảo Image Tự vá lỗi như thế nào?

Kinh nghiệm về DevOps của tôi tập trung triển khai Testing as Infrastructure cho doanh nghiệp Enterprise level. Chung nhất, tôi triển khai infrastructure theo 5 tiêu chí bảo mật, ổn định, nhanh gọn, đơn giản, dễ dàng mở rộng.

Khi tiếp cận đề bài, tôi luôn ưu tiên những lợi ích tốt nhất mang lại cho doanh nghiệp thay vì đầu tư quá nhiều vào kỹ thuật khiến giá trị mang lại không phù hợp. Trong ngành công nghệ luôn tồn tại khái niệm ROI (Return On Invest), tôi luôn đánh giá kết quả nhận được có nhiều hơn ‘chi phí’ bỏ ra không.

Với tôi, DevOps giữ vai trò, trách nhiệm đảm bảo Image tự vá lỗi rất quan trọng. Tự vá lỗi thực tế không phải là image tự sửa, mà là pipeline được thiết kế để tự sửa. Vai trò của DevOps là Thiết kế một hệ thống pipeline có khả năng tự phát hiện lỗi, tự sửa lỗi, tự build lại image sạch, và tự Release. Ngay cả khi tự vá lỗi, DevOps cũng cần phải đảm bảo API không bị lỗi, kết quả test passed, ứng dụng hoạt động bình thường, bản vá không tạo thêm CVE khác.

Trong Stage Build, Anh đã xây dựng một cơ chế tự động để kiểm tra, phân tích và cập nhật phiên bản dependencies (plugins, ext, và packages) ngay trong quá trình build. Tư duy cốt lõi đằng sau việc tích hợp logic này vào Dockerfile là gì? Chiến lược này mang lại lợi ích gì về tốc độ phản ứng với các lỗ hổng bảo mật so với các phương pháp quét bảo mật truyền thống?

Tư duy cốt lõi của tôi là giúp build không chỉ tạo artifact mà còn đảm bảo an toàn của chính artifact đó. Khi đó Dockerfile trở thành 1 security control point, không cho phép tạo image bẩn.

Chiến lược này mang lại 3 lợi ích cốt lõi so với việc quét bảo mật truyền thống Scan sau khi build:

Thứ nhất, thay đổi quy trình thành Scan ngay khi build Đưa logic kiểm tra phiên bản/dep updates ngay vào giai đoạn build image, biến quá trình build thành một security feedback loop.

Thứ hai, Dockerfile thành một chốt chặn security Dockerfile giờ đóng vai trò phân tích dependency và enforce policy fail nếu CVE > severity High. Nó chủ động scan cả application dependencies, loại bỏ các blind spot.

Thứ ba, không phụ thuộc vào database scanner Bằng cách dùng trực tiếp dependency version checker trong build, Dockerfile có thể tự cập nhật dependency đã lỗi thời, không cần chờ registry scanner cập nhật database.

Thay vì sử dụng các công cụ bên ngoài như wget hay curl cho Healthcheck, Anh đã lựa chọn tự biên dịch một Healthcheck class bằng Java. Ý nghĩa chiến lược của việc này là gì? Việc này giúp tối ưu hóa image cuối cùng như thế nào ví dụ: về kích thước, bảo mật, hoặc thời gian khởi động?

Với tôi, đây là chiến lược minimal, distroless, làm cho chi phí bảo trì CVE gần như bằng 0.

Việc tự viết Healthcheck bằng Java cho phép tôi loại bỏ hoàn toàn các công cụ OS như curl/wget, giữ image ở trạng thái tối giản và không kéo theo bất kỳ CVE từ OS layer. Healthcheck chạy trực tiếp trong JVM giúp kiểm tra chính xác hơn trạng thái nội bộ của ứng dụng, phản hồi nhanh hơn và không tốn overhead tạo process mới.

Anh đã thực hiện các lệnh COPY và RUN ./gradlew --no-daemon help rất sớm trong quá trình build. Anh có thể chia sẻ nguyên tắc vàng của mình khi tổ chức các tầng (layers) trong Dockerfile Java/Gradle? Việc tối ưu Layer Caching quan trọng như thế nào đối với hiệu quả của chu trình CI/CD trong các dự án Java lớn?

Tôi tổ chức Dockerfile theo nguyên tắc stable before volatile: tất cả file ít thay đổi như Gradle Wrapper, scripts và build.gradle được đưa lên đầu Dockerfile.

Sau đó tôi chạy gradlew help để tạo một layer cache chứa toàn bộ dependencies và plugin. Layer này được Docker cache lại và chỉ rebuild khi build.gradle thay đổi. Khi source code thay đổi, chỉ những layer cuối bị rebuild, giúp CI/CD rút ngắn thời gian build từ hàng chục phút xuống vài phút. Đây là yếu tố cực kỳ quan trọng với dự án Java/Gradle lớn vì phần dependency resolution nặng và tốn thời gian nhất lại được tái sử dụng gần như 100%.

Việc sử dụng Base Image Distroless (do HMCTS cung cấp) cho thấy sự ưu tiên về bảo mật. Anh đánh giá thế nào về việc sử dụng các Base Image tinh gọn chuyên biệt này? Theo kinh nghiệm của Anh, đâu là thử thách lớn nhất khi đảm bảo tính tương thích và ổn định cho ứng dụng Spring Boot trong môi trường Runtime tối giản?

Tôi đánh giá rất cao việc sử dụng các Base Image distroless hoặc minimal như của HMCTS (một tổ chức uy tín UK Government), vì chúng loại bỏ gần như toàn bộ bề mặt tấn công và làm giảm đáng kể số lượng CVE trong container. Đây là hướng đi rất đúng với kiến trúc cloud-native và DevSecOps.

Thử thách lớn nhất khi chạy ứng dụng Spring Boot trên runtime tối giản là vấn đề tương thích và khả năng vận hành: không có shell, thiếu công cụ debug, thiếu thư viện hệ thống và yêu cầu ứng dụng phải tự xử lý healthcheck, logging, temp directory và certificates. Điều này đòi hỏi một quy trình build rất chặt chẽ và tư duy no-OS, zero-shell rõ ràng.

Cuối cùng, với tư cách là chuyên gia có giải pháp tối ưu hóa và tự động hóa bảo mật ấn tượng, 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 Kiến trúc khi làm DevOps? Và Anh đánh giá thế nào về tương lai của việc tự động hóa bảo mật trong Build Pipeline?

Bài học lớn nhất tôi rút ra là: DevOps không hẳn là automation trong mọi thứ mà là tư duy kiến trúc về giá trị đem lại cho doanh nghiệp.

Khi chúng ta hiểu rõ luồng giá trị từ code, build, deploy, runtime, chúng ta sẽ tự biết phải chuẩn hóa đâu, tự động hóa đâu, kiểm soát rủi ro ở đâu, và tối ưu build time, cost ở đâu thay vì cố gắng làm mọi thứ tốt nhất về technical. DevOps thường không cố đẩy thêm tool vào pipeline, mà luôn tìm cách kết hợp bảo mật, hiệu năng, khả năng vận hành và tự động hóa thành một hệ thống đơn giản, độ tin cậy cao. Nói cách khác: DevOps không phải là chạy nhanh mà là chạy nhanh khi không phải dừng lại.

Về tương lai gần nhất, tôi đánh giá DevOps sẽ kết hợp thêm với AI. Khi đó, build pipeline trở thành hệ thống có khả năng tự đưa ra quyết định bảo mật policy-driven, AI-assisted cũng như có thể tự đưa ra và tìm cách tự fix. Việc của DevOps dần sẽ chuyển dịch qua monitor các hoạt động AI-based đó update dependencies, patching vulnerabilities, auto-healing… thay vì monitor system truyền thống.

Chiến thắng của Trịnh Thế Long đã minh chứng cho sức mạnh của việc kết hợp các kỹ thuật DevSecOps đột phá: từ việc biến Dockerfile thành Security Control Point để chủ động cập nhật và kiểm tra dependencies, áp dụng nguyên tắc ‘stable before volatile’ để tối ưu Layer Caching, đến việc sử dụng kiến trúc Distroless và Healthcheck Class tự viết để đạt được bảo mật tuyệt đối với chi phí bảo trì CVE bằng không.

Giải pháp đạt TOP 2 JAVA của anh Long không chỉ là một thành tích cá nhân mà còn là một mô hình lý tưởng cho các doanh nghiệp Enterprise level, nơi mà DevOps là tư duy kiến trúc về giá trị và Bảo mật được nhúng sâu vào quy trình Shift Left.

Chúng tôi xin chân thành cảm ơn anh Trịnh Thế Long đã 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 Long tại: Dockerfile Contest 2025