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, cuộc thi đã thu hút những chuyên gia không chỉ sở hữu tài năng vượt trội trong việc tinh chỉnh Dockerfile mà còn thể hiện tinh thần cộng đồng qua việc chia sẻ kiến thức. Các chuyên gia không chỉ so tài về khả năng tối ưu hóa Dockerfile, mà còn là nơi đặt ra ra các chuẩn mực mới về kích thước docker image, tốc độ build và bảo mật container.

Chúng tôi hân hạnh có cuộc phỏng vấn độc quyền với anh Ngô Tấn Tài, người đã xuất sắc giành vị trí Dockerfile TOP 2 PYTHON của dự án Python. 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 Tài. 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 mà khác biệt so với các phương pháp tối ưu thông thường?

Trước khi đến với cuộc thi Dockerfile, tôi có xuất phát điểm là dân An toàn thông tin, từng chinh chiến nhiều giải CTF (Capture The Flag) ở mảng Web Security. Tôi cũng tự mày mò dựng các node Proxmox trên máy tính cũ để deploy các dự án opensource, từ đó bén duyên và tìm hiểu sâu về cơ chế hoạt động của Docker.

Chính vì background đó, mục tiêu chiến lược của tôi không chỉ dừng lại ở việc làm image chạy được, mà là phải tạo ra một image an toàn tuyệt đối và không có lỗ hổng bảo mật. Trong tư duy bảo mật, việc giảm thiểu Attack Surface là sống còn, và điều này đi đôi với việc tối giản kích thước image.

Điểm khác biệt lớn nhất của tôi so với các phương pháp thông thường là triết lý Zero Trust Runtime. Thay vì chỉ xóa cache hay các file tạm, tôi chủ động loại bỏ mọi thành phần không cần thiết cho application runtime, kể cả các module có sẵn trong Python Standard Library nhưng không được sử dụng. Mỗi file thừa thãi, với tôi, đều là một rủi ro tiềm tàng.

Trong Dockerfile, anh đã thực hiện chiến lược Aggressive Cleanup bằng cách loại bỏ các thành phần không cần thiết. Triết lý cấp cao đằng sau việc can thiệp sâu vào cấu trúc này là gì? Anh chấp nhận những rủi ro Runtime nào để đạt được lợi ích về bảo mật và kích thước?

Triết lý cấp cao là Minimize Exposure. Nếu thứ gì không được dùng, nó không nên có mặt trong môi trường sản xuất. Với Python, tôi đã xóa thủ công các thư mục như test, tests trong thư viện được cài đặt, thậm chí xóa các module như unittest, distutils, và các tệp .pyc không cần thiết.

Rủi ro lớn nhất là lỗi Runtime Dependency. Nếu tôi xóa nhầm một thư viện mà ứng dụng cần gọi tới trong những trường hợp hiếm gặp (ví dụ: một module cho logging hoặc debug đặc biệt), ứng dụng sẽ crash. Để giảm thiểu rủi ro này, tôi đã thực hiện automated testing cực kỳ kỹ lưỡng sau mỗi bước tối giản hóa, mô phỏng tất cả các kịch bản sử dụng trước khi commit.

Cụ thể hơn về mặt kỹ thuật, anh đã áp dụng kỹ thuật nào để tinh giản kích thước image Python đến mức tối ưu nhất? Anh đánh giá thế nào về vai trò của các base image như Alpine và Distroless trong cuộc thi này?

Tôi đã sử dụng kết hợp ba kỹ thuật chính:

Multi-Stage Build: Để tách biệt hoàn toàn môi trường build gồm có trình biên dịch, công cụ và môi trường runtime chỉ có code và interpreter.

Sử dụng Base Image Tinh gọn: Tôi chọn các base image có sẵn ít thư viện nhất nhưng vẫn đảm bảo sự ổn định của Python Runtime, full-fat image. Alpine rất nhỏ, nhưng đôi khi gây ra vấn đề về Glibc, nên tôi cân nhắc sử dụng phiên bản slim của Debian hoặc các base image tương tự.

Tối ưu Cấu hình Python: Đảm bảo sử dụng biến môi trường như PIP_NO_CACHE_DIR=true trong giai đoạn build và tránh sử dụng pip trong giai đoạn runtime.

Tôi đánh giá cao Distroless về mặt bảo mật vì nó gần như không có shell, nhưng nó lại quá khó để debug. Vì vậy, tôi đã xây dựng Dockerfile custom, cố gắng đạt đến độ tối giản của Distroless nhưng vẫn cho phép kiểm soát tốt hơn.

Việc chuyển đổi từ user root sang non-root user là một best practice quan trọng. Anh đã thực hiện việc chuyển đổi quyền hạn này như thế nào trong Dockerfile và anh có lưu ý gì về vấn đề permission khi chạy ứng dụng Python với user không phải là root?

Việc chuyển sang non-root user được thực hiện bằng lệnh USER sau khi đã tạo một user và group có UID/GID nhất định thường là 1000.

Thách thức lớn nhất với Python là write permission. Nếu ứng dụng Python cần tạo file log, lưu cache, hoặc thậm chí là tải dữ liệu tạm thời vào một thư mục nào đó, user non-root đó phải có write permission vào thư mục đó. Tôi giải quyết bằng cách:

Đảm bảo thư mục làm việc WORKDIR và thư mục chứa code (/app) được gán quyền sở hữu cho user non-root đó.

Đặt các thư mục chỉ dành cho ghi dữ liệu tạm thời (ví dụ: /tmp hoặc thư mục cache của ứng dụng) và đảm bảo user có quyền truy cập vào đó.

Sai lầm phổ biến là quên cấp quyền, dẫn đến lỗi Permission Denied khi application runtime.

Trong quá trình tối ưu hóa, chắc chắn sẽ gặp pain points, đặc biệt là khi tối giản quá mức. Anh đã sử dụng chiến lược và công cụ gì để Debug các lỗi Runtime?

Đây là phần quan trọng nhất khi áp dụng aggressive cleanup. Khi image bị tối giản quá mức, việc debug trở nên vô cùng khó khăn vì nó không còn bash hay các công cụ cơ bản.

Để đối phó, tôi xây dựng một Debug Image riêng biệt. Image này giống hệt production nhưng được cài thêm vim, strace, gdb hoặc các công cụ tương đương.

Khi gặp lỗi, tôi tái hiện nó trên Debug Image để điều tra nguyên nhân gốc rễ, ví dụ: dùng strace để xem thiếu file .so nào, sau đó quay lại fix ở Dockerfile chính. Ngoài ra, việc dùng công cụ dive để soi từng layer cũng giúp tôi phát hiện các file bị thiếu hoặc thừa một cách trực quan.

Cuối cù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 Container? Và anh đánh giá thế nào về tương lai của việc tối ưu hóa Python trong môi trường DevOps?

Bài học tâm đắc nhất tôi muốn chia sẻ là: Measure, Don’t Guess Hãy đo lường, đừng phỏng đoán.

Đừng tối ưu theo cảm tính. Hãy dùng số liệu từ dive, từ trivy để quét bảo mật để quyết định xóa file nào, nâng cấp gói nào. Một thay đổi nhỏ cũng cần được kiểm chứng bằng con số cụ thể.

Về tư duy kiến trúc, hãy coi container là immutable artifact. Một khi đã build, nó không nên bị thay đổi. Mọi thứ cần thiết phải được gói gọn bên trong, an toàn và tối giản ngay từ đầu.

Về tương lai, tôi tin rằng việc tối ưu hóa sẽ ngày càng được tự động hóa. Chúng ta sẽ sớm thấy các công cụ AI-Powered Optimizer có thể phân tích code và tự động generate ra Dockerfile tối ưu nhất, hay các hệ thống CI/CD hỗ trợ auto-patching. Vai trò của kỹ sư sẽ chuyển dịch từ việc tối ưu thủ công sang việc thiết lập và kiểm soát các hệ thống tối ưu hóa tự động đó.

Chiến thắng của anh Ngô Tấn Tài đã minh chứng cho sức mạnh của việc kết hợp các kỹ thuật tối ưu hóa hiện đại: từ việc lựa chọn base image phù hợp, áp dụng Multi-Stage Builds để giảm kích thước cuối cùng, đến việc quản lý dependencies hiệu quả và triển khai các biện pháp bảo mật cần thiết như sử dụng user không có đặc quyền root.

Đây là một đóng góp quan trọng, không chỉ cho cộng đồng DevOps Việt Nam mà còn cho bất kỳ tổ chức nào đ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 CI/CD cho các ứng dụng Python của mình.

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