Viblo CTF
+1

Các vấn đề về Docker trên Production

1. Không thể xoá các image cũ

Có lẽ yêu cầu cần nhiều nhất và các tính năng còn thiếu trong Docker là một lệnh để xoá các image cũ (lớn hơn X ngày hoặc không được sử dụng trong vòng X ngày,hay bất cứ điều gì tương tự như thế). Dung lượng ổ cứng là một vấn đề quan trọng cho rằng hình ảnh được đổi mới thường xuyên và họ có thể mất nhiều hơn 1GB mỗi.

Cách duy nhất để giải phóng lưu lượng đĩa cứng là chạy câu lệnh này, đặt cron cho chạy định kỳ trong 1 khoảng thời gian, với tôi thì 2 tuần hoặc 1 tháng :

docker rmi $(docker images -q -a)

Câu lệnh trên sẽ liệt kê tất cả các hình ảnh và xoá. Các bạn sẽ thấy có lỗi với các image đang được sử dụng bởi các container đang chạy. Tuy output không được đẹp cho lắm nhưng ít ra thì nó cũng chạy chính xác được 1 phần nào đó 😃 .

Thực ra tôi cũng đã tìm kiếm khá nhiều trên internet nhưng không có giải pháp nào cho những gì tôi suy nghĩ. Không có API để liệt kê các images theo ngày, có 1 giải pháp có nhưng mà chỉ được trong 1 khoảng thời gian nhất định. Nhìn chung các cách làm đều là đọc thuộc tính ngày tháng từ image và sau đó là gọi lệnh 'docker rmi', nhưng sẽ bị fail nếu tên image bị thay đổi. Một cách khác cũng khá giống với cách trên đó là đọc ngày tháng sau đó thì xoá ngay lập tức nhưng cách này không hoàn hảo.

2. Docker Issue: hỗ trợ kernel

Có vô số nhưng vấn đề liên quan đến sự tương tác giữa các kernel, bản phân phối Docker và hệ thống tập tin.

Screenshot at Dec 26 17-21-33.png

Ví dụ với Debian bản stable, như các bạn đã từng cài docker chắc hẳn đã biết docker yêu cầu kernel 3.10 trở lên. Trên Debian Jessie 3.16.7-ckt20-1 (phát hành tháng 11 năm 2015). Có vấn đề đó là host hay bị crash, trung bình chỉ chạy được khoảng vài giờ, việc này cũng đã được phần lớn cộng đồng report.

_Linux 3.x: storage driver không ổn định_

Docker có trình điều khiển lưu trữ khác nhau. Và duy nhất (được khuyến cáo) được hỗ trợ tốt đó là AUFS. Nhưng drive AUFS lại không ổn định. Nó bị lỗi nghiêm trọng làm kernel panic và làm hư dữ liệu. Và vấn đề đó ít nhất xảy ra với tất cả kernel "linux-3.16.x". Vô phương cứu chữa.

Sau đó tôi cũng đã thử làm theo Debian cập nhật kernel mới nhất. Debian công bố bản vá đặc biệt bên ngoài chu kỳ release thường xuyên của họ. Có một bugfix lớn để vá lỗi AUFS khoảng tháng ba năm 2016. Sau đó có vẻ vấn đề AUFS đã được giải quyết nhưng lại kernel panic, reboot liên tục liên tục. Có nhiều bản sửa lỗi cho AUFS xuất bản cùng năm 2016. Có một số lỗi được khắc phục khi update kernel nhưng sau đó lại có những lỗi mới. Mình xin tổng hợp lại cũng như cách khắc phục như sau :

  • Debian stable chạy không ổ định trên kernel 3.16, có thể chuyển sang dùng kernel 4 để fix lỗi tạm thời.
  • RHEL / CentOS-6 là trên kernel 2.x và RHEL/CentOS-7 là trên kernel 3.10, theo mình nên sử dụng Redhat hoặc CentOS 7 sẽ ổn định hơn là upgrade kernel trên CentOS hoặc Redhat 6.
  • Sử dụng ubuntu, qua một thời gian sử dụng docker mình thấy ubuntu mặc dù vẫn có lỗi khó hiểu xảy ra nhưng có vẻ nó là distro ổn định nhất với docker tính tới thời điểm này.

Linux 4.x: Kernel 4.0 official đã không hỗ trợ còn hỗ trợ docker Đó là điều mình muốn chia sẻ với các bạn, đó là những vấn đề về AUFS sẽ được kết thúc bởi vì kernel 4.0 sẽ ko support AUFS nữa.

Không có bản vá chính thức hỗ trợ, không có mô-đun tùy chọn. AUFS là hoàn toàn biến mất. Chắc là những người phát triển kernel cũng phải quỳ gối trước ông AUFS này rồi 😃.

Vậy thì lại có 1 câu hỏi ở đấy đó là nếu Docker không có AUFS thì nó sẽ hoạt động như thế nào ? Có lẽ chính những nhà phát triển docker cũng nhận ra được vấn đề của chính mình vì vậy họ đã viết 1 hệ thống tập tin mới gọi là OverlayFS.

OverlayFS là một filesystem hiện đại tương tự như AUFS. So với AUFS, OverlayFS có một thiết kế đơn giản, nhanh hơn và được sử dụng từ bản kernel 3.18. Mới đây thì phiên bản OverlayFS 2 cũng đã ra mắt trên docker 1.12, nó khắc phục được điểm yếu của overlayfs đó chạy được trên kernel 4.

3. Docker Registry : Bị phụ thuộc

Là nơi lưu trữ và phân phối các image của dockerdocker

Automatic CI build  ===> (on success) push the image to ===> docker registry
Deploy command <=== pull the image from <=== docker registry

Public registry được vận hành bởi Docker đó là Docker Hub. Với cá nhân hoặc công ty riêng nếu bạn ko muốn bỏ tiền thì hoàn toàn có thể tạo 1 registry riêng. Có 3 phiên bản của registry Docker mà bạn có thể chọn :

  • Registry v1, hiện tại đã bị cộng đồng bỏ rơi
  • Registry v2, viết lại đầy đủ bằng Golang, lần đầu tiên được phát hành vào tháng 4 năm 2015
  • Trusted Registry là 1 một dịch vụ. Vd như Docker Hub

4. Vấn đề của Docker Registry

Từ khi docker registry v2 có mặt thì v1 đã hoàn toàn ko được support. Điều đó có nghĩa là gì ? Nghĩa là nếu bạn hay công ty của bạn đã sử dụng v1 thì bắt buộc phải upgrade lên v2 để nhận được sự hỗ trợ từ phía Docker. Thời gian để chuyển đổi phụ thuộc vào độ phức tạp của hệ thống (config, path, URL, thiết bị đầu cuối v.v...). Vậy bài học rút ra ở đây đó là sẽ là quá phiêu lưu nếu tin cậy vào docker để triển khai trên production rồi 1 ngày nào đó bạn sẽ gặp những vấn đề khi cứ đuổi theo họ.

Docker Registry: Không thể xoá được image Khổng thể xoá các image trên Docker Registry, dung lượng sẽ tăng dần. Nếu bạn sử dụng xây dựng docker registry riêng mà cứ mỗi tuần dữ liệu của bạn tăng lên 50GB vậy thì cần bao nhiêu cho đủ đây. Ở đây thì tôi sẽ nghĩ đến lưu image của registry lên storage và mua thêm ổ cứng lắp vào nếu cần. Tôi cũng đã từng xoá thử bằng tay các tệp tin của Docker Registry nhưng cuối cùng là hỏng hết, hỏng toàn bộ dữ liệu. Nói đến đây thì cách cuối là chờ đợi và phụ thuộc vào Docker sẽ cải tiến dần thôi. Có thể là ra v3 hay v4 gì đó rồi chúng ta lại chạy theo họ.

Những kinh nghiệm rút ra từ bản thân:

  • Không để dữ liệu ở trên container, tất cả đều được mount từ phía ngoài
  • Không chạy những gì quan trọng trên Docker
  • Hiện tại docker vẫn còn khá nhiều vấn đề chỉ nên chạy trên môi trường test hoặc staging
  • Nếu chạy docker phải đảm bảo có hệ thống auto scaling
  • Thử 1 service khác, coreos là một dịch vụ như vậy và cũng đang nhận được phản ứng khá tích cực từ phía cộng đồng
  • Sử dụng 1 công cụ để quản lý như Kubernetes hoặc Rancher.
  • Dùng dịch vụ của 1 ông lớn vd như Google Cloud: Google Container Engine chẳng hạn

5. Kết luận

Nói chung, sẽ không có vấn đề gì quá to tát nếu bạn ko sử dụng docker trên production. Tôi chỉ muốn chỉ ra vấn đề còn tồn tại mà nhiều người cũng đã gặp phải trong đó có tôi. Dù sao, tôi cũng tin docker sẽ có những sản phẩm tốt hơn, hoàn thiện hơn và chúng ta sẽ có 1 sản phẩm ổn định để triển khai được những dịch vụ 1 cách nhanh nhất, tốn ít tài nguyên nhất.


All Rights Reserved