# Dockerfile và CI taste - Sử dụng quy trình dựng đa giai đoạn (multi-stage builds) và chỉ đưa các hiện vật thực thi (runtime artifacts) vào giai đoạn cuối cùng. Độ tin cậy: 0.95 - Ghim cố định ảnh cơ sở (base images) vào một thẻ phiên bản cụ thể, và ghim vào mã băm (digest) đối với môi trường sản xuất (production). Độ tin cậy: 0.90 - Ưu tiên các ảnh cuối cùng dạng rút gọn (slim) hoặc distroless hơn là ảnh hệ điều hành đầy đủ. Độ tin cậy: 0.85 - Chạy container dưới quyền người dùng không phải root (non-root user). Độ tin cậy: 0.95 - Sắp xếp thứ tự các lớp (layers) sao cho tệp khai báo thư viện phụ thuộc (dependency manifests) được sao chép và cài đặt trước mã nguồn. Độ tin cậy: 0.95 - Luôn duy trì tệp .dockerignore loại trừ node_modules, .git và các tệp biến môi trường cục bộ. Độ tin cậy: 0.95 - Thêm chỉ thị HEALTHCHECK hoặc cơ chế kiểm tra trạng thái sẵn sàng (readiness probe) tương đương. Độ tin cậy: 0.80 - Sử dụng tính năng gắn bộ nhớ đệm (cache mounts) của BuildKit cho bộ nhớ đệm của trình quản lý gói. Độ tin cậy: 0.80 - Tuyệt đối không nhúng cứng thông tin bí mật (secrets) vào trong ảnh; hãy truyền chúng vào lúc chạy (runtime) hoặc sử dụng build secrets. Độ tin cậy: 0.95 - Sử dụng CMD ở dạng thực thi (exec-form) để tiến trình nhận tín hiệu hệ thống một cách chính xác. Độ tin cậy: 0.90 - Quét ảnh bằng Trivy trong CI và đánh trượt (fail) nếu phát hiện lỗ hổng bảo mật nghiêm trọng (critical). Độ tin cậy: 0.80 - Lưu bộ nhớ đệm (cache) cho các thư viện phụ thuộc trong GitHub Actions dựa trên khóa là mã băm của tệp khóa (lockfile hash). Độ tin cậy: 0.85 - Chạy kiểm tra mã nguồn (lint), kiểm tra kiểu (type check) và kiểm thử (tests) thành các tác vụ (jobs) CI song song tách biệt. Độ tin cậy: 0.80 - Gắn thẻ (tag) ảnh bằng mã git SHA và tuyệt đối không dựa vào thẻ latest khi triển khai (deploy). Độ tin cậy: 0.90 - Giữ cho các luồng công việc (workflows) ngắn gọn và tách các bước lặp lại sang các luồng công việc tái sử dụng được (reusable workflows). Độ tin cậy: 0.70
Đánh giá các tệp YAML luồng công việc của GitHub Actions nhằm phát hiện rủi ro chuỗi cung ứng và chèn mã (injection): sử dụng pull_request_target kèm checkout mã nguồn PR, văn bản github.event không đáng tin cậy trong các bước run, các action được ghim theo tag hoặc nhánh thay vì mã băm commit SHA, thiếu cấu hình quyền hoặc cấp quyền write-all, lộ bí mật (secrets) trong các lệnh shell, lệnh dạng curl | bash, sử dụng self-hosted runner cho PR, và thiếu cấu hình thời gian chờ tối đa (timeout). Sử dụng trước khi gộp (merge) các thay đổi CI hoặc khi kiểm toán kho mã nguồn. Bao gồm một công cụ kiểm tra (linter) bằng Python dùng thư viện chuẩn với tùy chọn --self-test.
Tìm các bài kiểm thử chập chờn (flaky test) từ các lần chạy CI lặp đi lặp lại: phân tích cú pháp tệp JUnit XML hoặc lịch sử chạy dạng CSV, gắn cờ các bài kiểm thử lúc đạt lúc trượt (được xác nhận khi xảy ra trên cùng một commit), xếp hạng chúng theo tỷ lệ đảo chiều và tỷ lệ lỗi, đồng thời đề xuất nguyên nhân có thể xảy ra và cách khắc phục. Sử dụng khi CI "báo đỏ ngẫu nhiên", trước khi thêm cơ chế chạy lại (retry), hoặc khi phân loại danh sách cách ly (quarantine). Bao gồm công cụ phát hiện bằng thư viện chuẩn Python với cờ --self-test.
Đánh giá Dockerfile về bảo mật, dung lượng image, bộ nhớ đệm bản dựng (build cache) và độ tin cậy khi chạy (runtime): bí mật (secrets) bị gắn cứng vào các lớp (layers), chạy dưới quyền root, base image chưa ghim phiên bản, lệnh curl truyền thẳng qua pipe vào shell, sử dụng sai lệnh ADD, bộ nhớ đệm apt và pip còn sót lại, cài đặt gói phụ thuộc làm hỏng cache, lệnh CMD dạng shell, và thiếu bản dựng đa giai đoạn (multi-stage builds) hoặc kiểm tra sức khỏe (health checks), sau đó viết lại một Dockerfile đã sửa lỗi và tệp .dockerignore. Sử dụng khi người dùng chia sẻ một Dockerfile và hỏi "hãy đánh giá Dockerfile của tôi", "tại sao image của tôi lại nặng như vậy?", hoặc "container này có an toàn không?".
Tối ưu hóa đúng định mức (rightsize) các thông số requests và limits cho CPU và bộ nhớ trong Kubernetes dựa trên mức sử dụng thực tế (p50, p95 và max trên từng container). Đề xuất mức requests tại ngưỡng p95 cộng thêm khoảng dự phòng (headroom), giới hạn bộ nhớ (memory limits) cao hơn mức đỉnh và loại bỏ giới hạn CPU (CPU limits), đồng thời ước tính số lõi (cores), dung lượng GiB và chi phí tiết kiệm được. Cảnh báo các lỗi OOM kill, mức dùng bộ nhớ vượt quá request, hiện tượng bóp băng thông CPU (CPU throttling), thiếu thông số requests hoặc memory limits, cấp phát dư thừa (overprovisioning) và khoảng thời gian thu thập dữ liệu quá ngắn. Bao gồm một công cụ tính toán bằng thư viện chuẩn Python có hỗ trợ cờ --self-test.
