Dev container: môi trường giống nhau cho cả đội

Trả lời nhanh: Devcontainer là cách mô tả môi trường lập trình bằng một file cấu hình nằm trong repo, để ai mở dự án lên cũng có đúng phiên bản ngôn ngữ, đúng công cụ và đúng tiện ích như nhau. Nó xóa được câu nói kinh điển máy tôi chạy được mà. Đổi lại có hai cái giá: lần khởi tạo đầu tiên chậm vì phải dựng ảnh, và máy chạy cần đủ tài nguyên cho container, nên nhiều đội đặt hẳn trên máy chủ thay vì trên laptop.

Người mới vào đội mất một ngày để cài đủ thứ, rồi vẫn gặp lỗi lạ vì bản Node lệch một số. Ai làm việc nhóm cũng gặp cảnh này. Devcontainer giải quyết bằng cách coi môi trường làm việc là một phần của mã nguồn: nó nằm trong repo, thay đổi qua pull request, và ai cũng dùng chung một bản.

File cấu hình trông như thế nào

Toàn bộ mô tả nằm trong .devcontainer/devcontainer.json:

{  "name": "api-noi-bo",  "image": "mcr.microsoft.com/devcontainers/typescript-node:22",  "features": {    "ghcr.io/devcontainers/features/docker-in-docker:2": {},    "ghcr.io/devcontainers/features/github-cli:1": {}  },  "forwardPorts": [3000, 5432],  "postCreateCommand": "npm ci",  "customizations": {    "vscode": {      "extensions": ["dbaeumer.vscode-eslint", "esbenp.prettier-vscode"]    }  }}

Bốn phần đáng chú ý: image chọn nền có sẵn ngôn ngữ bạn cần, features thêm công cụ mà không phải tự viết Dockerfile, postCreateCommand chạy đúng một lần sau khi dựng xong để cài thư viện, và extensions đảm bảo mọi người có cùng bộ tiện ích, tức là cùng quy tắc định dạng code.

Khi cần nhiều dịch vụ cùng lúc, ví dụ ứng dụng cộng database cộng bộ nhớ đệm, bạn trỏ devcontainer sang một file Docker Compose thay vì khai báo một ảnh. Cách viết file đó nằm ở bài Docker Compose.

Chạy trên máy cá nhân hay trên máy chủ

Trên máy cá nhân là cách phổ biến: cài Docker, mở dự án bằng trình soạn thảo có hỗ trợ, nó tự dựng container và gắn vào. Ưu điểm là làm việc được cả khi mất mạng. Nhược điểm là container ăn RAM của chính máy bạn, và với laptop 8GB chạy thêm trình duyệt thì cảm nhận rất rõ.

Trên VPS hợp khi máy cá nhân yếu hoặc khi bạn muốn môi trường luôn sẵn sàng ở mọi nơi. Dựng container trên máy chủ rồi nối vào bằng Remote SSH như trong bài máy dev từ xa, hoặc mở qua trình duyệt bằng code-server. Cách này còn một cái lợi ít người nhắc: bản dựng và test chạy trên đường mạng của máy chủ, thường nhanh hơn nhiều so với mạng nhà.

Những gì devcontainer làm tốt

• Người mới vào việc trong một giờ thay vì một ngày. Clone repo, mở lên, chờ dựng xong là code được.
• Không còn lệch phiên bản. Bản ngôn ngữ, bản công cụ, bản thư viện hệ thống đều ghi trong cấu hình.
• Thay đổi môi trường đi qua pull request. Nâng bản Node là một dòng sửa trong file, cả đội nhận cùng lúc khi kéo code về.
• Tách bạch giữa các dự án. Hai dự án cần hai bản ngôn ngữ khác nhau vẫn sống chung hòa bình trên một máy, không phải cài trình quản lý phiên bản.

Riêng điểm cuối cũng chính là lý do nhiều người dùng devcontainer dù làm việc một mình.

Những gì nó không làm được

Nói thẳng để tránh kỳ vọng sai:

Không phải môi trường chạy thật. Devcontainer để lập trình, còn khi triển khai bạn vẫn cần cấu hình riêng cho máy chủ thật. Đừng lấy ảnh dev đem chạy production, nó chứa nhiều công cụ không cần thiết và thường chạy với quyền cao.

Chậm ở lần đầu. Dựng ảnh và cài thư viện có thể mất vài phút tới hơn chục phút tùy dự án. Những lần sau nhanh, nhưng người mới lần đầu mở dự án cần được báo trước để khỏi tưởng hỏng.

Đọc ghi file có thể chậm hơn. Tùy hệ điều hành và cách gắn thư mục, thao tác với hàng nghìn file nhỏ trong container chậm hơn chạy thẳng trên máy. Với dự án nhiều phụ thuộc, hãy để thư mục thư viện nằm trong ổ dữ liệu của container thay vì gắn từ ngoài vào.

Bắt đầu thế nào cho gọn

Đừng viết cấu hình phức tạp ngay từ đầu. Trình tự hợp lý:

1. Chọn một ảnh nền chính thức đúng ngôn ngữ dự án, chưa thêm gì cả.
2. Thêm lệnh cài thư viện vào postCreateCommand.
3. Chạy thử, thiếu công cụ nào thì thêm qua features, đừng vội tự viết Dockerfile.
4. Khi cấu hình đã ổn định, chốt phiên bản ảnh thay vì để nhãn mới nhất, để môi trường không tự đổi dưới chân bạn.

Bước cuối quan trọng với đội đông người: để nhãn mới nhất nghĩa là hai người dựng cách nhau một tháng sẽ có hai môi trường khác nhau, đúng thứ mà devcontainer sinh ra để tránh.

Nó làm tốt gì và không làm được gì

Lợi ích lớn nhất và ít được nói tới: người mới vào đội chạy được dự án ngay ngày đầu thay vì mất hai ngày cài môi trường. Với đội hay tuyển thêm người, đây là khoản tiết kiệm thật.

Ưu và nhược của từng nơi đặt

• Trên máy cá nhân: tiện, không tốn thêm tiền, nhưng chiếm tài nguyên máy và chậm hơn khi dự án lớn.
• Trên máy chủ: máy cá nhân mát và im, việc dài chạy tiếp khi bạn tắt máy, và cả đội dùng chung một cấu hình.
• Cách kết hợp thường tốt: giao diện ở máy cá nhân, phần chạy ở máy chủ.
• Với đội trên ba người, một máy chủ chung thường rẻ hơn nhiều so với nâng cấp máy cá nhân cho từng người.

Bắt đầu từ ảnh có sẵn, đừng viết từ đầu

# 1. Bat dau bang mot anh co san dung ngon ngu cua du an,#    dung tu viet tu dau # 2. Chi them thu that su can, moi lan mot thu#    Cau hinh phinh to la nguyen nhan chinh khien no cham # 3. Gan thu muc bo nho dem ra ngoai container#    Neu khong, moi lan dung lai la tai lai toan bo thu vien # 4. Do thoi gian khoi dong va thoi gian dungtime docker compose up -dtime npm run build # 5. Don dinh ky, anh cu chiem rat nhieu chodocker system dfdocker system prune -a --volumes --filter "until=168h"

Việc thứ ba là việc quyết định trải nghiệm: không gắn bộ nhớ đệm ra ngoài thì mỗi lần dựng lại môi trường là tải lại toàn bộ thư viện, và cả đội sẽ bỏ dùng sau một tuần.