Docker giúp đội phát triển đóng gói ứng dụng, dependency và cấu hình chạy theo một cách nhất quán hơn. Thay vì cài từng thành phần trực tiếp lên server, bạn có thể mô tả chúng trong Dockerfile và Docker Compose, sau đó tạo lại môi trường khi cần.
Lợi ích đó rất rõ. Tuy nhiên, ứng dụng chạy trong container vẫn sử dụng CPU, RAM, ổ đĩa, network và dữ liệu thật. Khi production gặp sự cố, Docker không tự quyết định bản backup nào nên dùng, có được phép restart database hay phải quay lại phiên bản nào.
Nói ngắn gọn: Docker cải thiện cách đóng gói và triển khai. Vận hành là công việc giữ cho toàn bộ dịch vụ hoạt động ổn định sau khi đã triển khai.
Docker giải quyết tốt những việc nào?
Với một ứng dụng web thông thường, Docker có thể giúp:
- Cố định phiên bản runtime và dependency cần thiết.
- Giảm khác biệt giữa máy developer, staging và production.
- Tạo lại container từ cấu hình đã lưu thay vì cài đặt thủ công.
- Tách các thành phần như web, worker, database và cache thành dịch vụ riêng.
- Kiểm soát phiên bản image để triển khai hoặc quay lại bản trước thuận tiện hơn.
- Hỗ trợ tự động hóa build và release trong CI/CD.
Những việc này làm giảm lỗi do môi trường không đồng nhất. Khi một container hỏng, việc tạo container mới cũng nhanh hơn so với dựng lại server từ đầu.
Nhưng “tạo lại được container” không đồng nghĩa “khôi phục được hệ thống”. Dữ liệu, secret, DNS, SSL, firewall và nhiều thành phần khác nằm ngoài image.
Những phần Docker không tự quản lý
Tài nguyên của VPS
Container không tạo thêm CPU, RAM hay dung lượng. Một container bị rò rỉ bộ nhớ vẫn có thể làm ảnh hưởng các dịch vụ khác. Log tăng không kiểm soát, image cũ và build cache vẫn có thể làm đầy ổ đĩa.
Vì vậy, server vẫn cần được theo dõi CPU, RAM, swap, dung lượng, inode và tải hệ thống. Các giới hạn tài nguyên cho container cũng cần được đặt dựa trên tải thực tế, không nên chọn tùy ý.
Dữ liệu và volume
Container thường có vòng đời ngắn, còn dữ liệu phải tồn tại lâu dài. Database, file upload và các volume cần được xác định rõ vị trí, quyền truy cập và chính sách backup.
Một lỗi khá phổ biến là backup file Compose nhưng bỏ quên dữ liệu trong volume. Trường hợp ngược lại cũng xảy ra: có dump database nhưng thiếu secret và cấu hình cần để ứng dụng chạy lại. Bài Có backup chưa đủ: vì sao cần thử khôi phục giải thích kỹ hơn cách kiểm chứng phần này.
Secret và quyền truy cập
Password, API key và private key không nên được ghi trực tiếp vào Dockerfile, image hoặc repository. Production cần có cách cấp secret riêng, giới hạn người được xem và quy trình xoay secret khi nhân sự hoặc nhà cung cấp thay đổi.
Docker socket cũng là quyền nhạy cảm. Người hoặc container có quyền điều khiển Docker thường có thể tác động rất lớn lên máy chủ. Không nên mount socket cho một công cụ chỉ vì cấu hình đó tiện.
Network, domain và SSL
Ứng dụng có thể hoạt động tốt trong network nội bộ của Docker nhưng vẫn không truy cập được từ Internet vì DNS, reverse proxy, firewall hoặc chứng chỉ SSL. Đây là những lớp phải được kiểm tra riêng.
Monitoring từ bên ngoài và bên trong giúp giảm điểm mù này. Bạn có thể xem sự khác nhau trong bài Monitoring website khác monitoring server như thế nào?.
Một ví dụ với Docker Compose trên VPS
Giả sử hệ thống gồm Nginx, ứng dụng, PostgreSQL và Redis. File Compose có thể giúp khởi động đúng bốn dịch vụ và nối chúng vào network phù hợp. Nhưng trước khi đưa lên production, vẫn cần trả lời các câu hỏi:
- Image được build từ commit nào và lưu ở đâu?
- Database nằm trong volume nào, được backup theo lịch nào?
- Nếu migration lỗi, có thể chạy lại phiên bản cũ hay không?
- Secret production được cấp bằng cách nào?
- Nginx và SSL do container hay host quản lý?
- Log được giữ bao lâu và ai nhận cảnh báo?
- Khi VPS reboot, các dịch vụ có tự lên đúng thứ tự không?
- Nếu registry không truy cập được, phiên bản đang chạy có thể khôi phục không?
File Compose không thể tự trả lời những câu hỏi này. Chúng thuộc về thiết kế vận hành và quy trình của đội phụ trách hệ thống.
Checklist trước mỗi lần triển khai
- ☐ Image gắn với một phiên bản source xác định và đã qua kiểm thử.
- ☐ Biến môi trường, secret và cấu hình production đã được kiểm tra.
- ☐ Có đủ dung lượng để pull image, build và lưu phiên bản cần rollback.
- ☐ Database migration đã được đánh giá khả năng tương thích ngược.
- ☐ Backup gần nhất đã hoàn thành và có giá trị sử dụng.
- ☐ Có phương án quay lại phiên bản trước nếu health check thất bại.
- ☐ Người có thẩm quyền đã xác nhận thời điểm triển khai.
Sau khi triển khai, cần kiểm tra nhiều hơn việc container đang ở trạng thái running. Hãy thử endpoint chính, đăng nhập, thao tác có đọc ghi database, job nền và log lỗi mới phát sinh. Theo dõi thêm một khoảng thời gian phù hợp trước khi coi release đã hoàn tất.
Chia trách nhiệm giữa developer và người vận hành
Không có một cách chia duy nhất cho mọi doanh nghiệp. Với đội nhỏ, developer và người vận hành có thể phối hợp như sau:
Developer chịu trách nhiệm source code, dependency, migration, kiểm thử chức năng và mô tả điều kiện để ứng dụng chạy đúng.
Người vận hành chịu trách nhiệm VPS, Docker Engine, reverse proxy, SSL, monitoring, backup, quyền truy cập và cách thực hiện thay đổi trên production.
Hai bên cùng thống nhất quy trình release, health check và rollback. Ranh giới này không nhằm đẩy trách nhiệm cho nhau. Nó giúp khi có sự cố, mọi người biết nên kiểm tra lớp nào trước và ai có quyền quyết định.
Khi nào Docker Compose là đủ?
Một hoặc vài VPS chạy Docker Compose có thể phục vụ tốt nhiều ứng dụng doanh nghiệp nhỏ nếu tải, mức độ quan trọng và cách vận hành phù hợp. Không nhất thiết phải chuyển sang Kubernetes chỉ để có cảm giác hệ thống chuyên nghiệp hơn.
Điều đáng quan tâm là cấu hình có được lưu lại, dữ liệu có thể khôi phục, cảnh báo có người nhận và deployment có cách quay lui hay không. Khi những nền tảng này chưa ổn, thêm một lớp điều phối phức tạp thường chỉ tạo thêm việc phải quản trị.
Nếu developer của bạn đang dành nhiều thời gian cho Docker, reverse proxy, SSL và xử lý incident hạ tầng, Application Ops là một cách để tách phần vận hành khỏi công việc phát triển sản phẩm mà vẫn giữ sự phối hợp cần thiết.