Nên quản lý thế nào với máy chủ vận hành nhiều container Docker?

Có một máy chủ được hàng chục người cùng sử dụng.

Mỗi người đang phục vụ dự án của mình bằng container.

Khi phát sinh các sự cố như máy chủ bị khởi động lại, quản trị viên rất khó xử lý các container này.

Không rõ có nên yêu cầu mọi người nộp sẵn lệnh chạy container Docker hằng ngày để quản trị viên chạy lại từng cái,
hay nên tạo bằng Docker Compose rồi phải vào từng thư mục của từng dự án để compose up, v.v.

Mong được tư vấn về cách một quản trị viên nên quản lý nhiều container như vậy.

[selene]

Tôi cũng có suy nghĩ khá giống với bạn tujuc: tôi cho rằng việc tự mình triển khai k8s mà không có người nhiều kinh nghiệm, rồi vận hành ổn định lâu dài mà không xảy ra sự cố, có rủi ro khá lớn.

Tuy nhiên, vì bạn nói đây là tình huống 4 máy chủ được vài chục người dùng chung nên cũng hơi khó nói,
thay vì lấy số người liên quan làm tiêu chí, nếu số lượng chương trình máy chủ quá nhiều và tình huống quá phức tạp thì cũng đáng để cân nhắc học k8s.

Nếu tôi ở trong tình huống giống như bạn, có lẽ tôi sẽ cải thiện môi trường theo từng bước dưới đây.

1. Thực hiện các biện pháp để việc các chương trình máy chủ có thể tắt bất cứ lúc nào mà không gây vấn đề => bao gồm những việc như triển khai graceful shutdown, refactor để có thể chạy theo hướng stateless, v.v. (hoặc yêu cầu các kỹ sư thực hiện)
2. Container hóa và chuẩn hóa các chương trình máy chủ => viết Dockerfile và file docker compose cho từng dịch vụ để buộc chúng phải có thể khởi động được khi chạy bằng cùng một lệnh.
3. Quản lý để các kỹ sư khác ngoài quản trị viên không cần phải đăng nhập vào máy chủ => có thể xây dựng theo kiểu gần giống GitOps bằng cách dùng nền tảng CI/CD mà bạn muốn như Jenkins/GitHub Actions/AWS CodePipeline. Chỉ cần đạt được mức này thôi thì các kỹ sư cũng đã có thể kiểm soát đầy đủ việc triển khai lại/khởi động lại ở mức chạy lại pipeline.
4. Sau đó nâng cấp thêm như những người khác đã nói (triển khai K8s, ArgoCD, v.v.)

[chcv0313]

Cảm ơn tất cả mọi người đã trả lời. Có lẽ mục tiêu năm nay nên là triển khai Kubernetes.

[bungker]

Chỉ nhìn vào câu hỏi thì có vẻ có thể giải quyết bằng depend on, restart always hoặc unless stoped, nhưng có lẽ vẫn có những tình huống khó chưa được nêu trong câu hỏi. Tuy vậy, nếu quy mô đến mức vài chục người thì cuối cùng có lẽ bạn vẫn sẽ phải chuyển sang Kubernetes.

Cứ hỏi AI đúng nguyên văn câu hỏi đó thì có lẽ bạn cũng sẽ tìm được câu trả lời.

[tujuc]

1. Bạn đặt hạ tầng ở đâu? AWS? Tự vận hành hay hosting máy chủ? Azure?
2. Bạn đang tự quản lý một mình à?
3. Hiện tại bạn đã làm ở trạng thái nào, và bạn biết đến đâu rồi?

---

Nếu có những thông tin trên thì sẽ dễ trao đổi hơn.

Nếu chỉ trả lời dựa trên những gì bạn nói đơn giản thì....

Tôi không rõ vì sao lại cần command chạy container. Hãy yêu cầu tạo file Compose, và tốt nhất là cấu hình để có thể khởi chạy tất cả bằng cùng một command giống nhau (docker compose command) dựa trên đó.

:) Vì bạn là quản trị viên nên cứ yêu cầu làm như vậy đi, những người khác sẽ làm cho bạn thôi, cứ đẩy mạnh nhé :)

Cá nhân tôi thấy k8s là một giải pháp khá nặng nếu là môi trường do một người tự quản lý, nên tôi không khuyến nghị lắm.
Tôi luôn nghĩ rằng hạ tầng nên được cấu hình càng đơn giản càng tốt.

[chcv0313]

Máy chủ on-premises có 4 máy.
Một mình tôi phụ trách.
Docker mới được đưa vào công ty được 4 tháng sau khi vượt qua yêu cầu bảo mật, còn k8s thì tôi chỉ biết ở mức khái niệm. Việc triển khai HARBOR cho Docker cũng sắp do tôi thực hiện, và sau khi Harbor được triển khai thì Docker Hub dự kiến sẽ bị chặn. Có lẽ chỉ mình tôi được mở Docker Hub, rồi khi có yêu cầu thì tôi sẽ tự lấy image từ Docker Hub và đưa lên Harbor nội bộ của công ty.

Tôi thấy việc cứ đẩy bằng lệnh compose, rồi vào từng thư mục theo từng project để chạy compose up thủ công là không thực tế nên đã không làm như vậy; thay vào đó tôi yêu cầu dùng lệnh Docker với đường dẫn tuyệt đối, nhưng dạo gần đây tôi không thể xua đi suy nghĩ rằng đó là một cách tiếp cận sai.

[click]

Trong trường hợp này, nên dùng Kubernetes và cấp context riêng cho từng người dùng.
Ngoài ra cũng có thể giới hạn quyền để mỗi người dùng chỉ được phép sử dụng context tương ứng của mình.

[cafedead]

Dùng k8s.