Chúng tôi đã giảm thời gian triển khai ở nhiều môi trường xuống còn 1/10 nhờ vào công nghệ Docker, đồng thời tiết kiệm được 2 vị trí quản trị hệ thống cho đội ngũ 10 người.

Tháng trước, nhóm nhỏ SaaS thương mại điện tử của chúng tôi ở Singapore suýt sụp đổ - trước khi thúc đẩy lớn để cập nhật chức năng đồng bộ hóa hàng tồn kho cho 3 trang web ở Đông Nam Á, thử nghiệm địa phương tốt, một khi đẩy đến máy chủ đám mây của Indonesia sẽ báo cáo thiếu phụ thuộc tập thể, 2 hậu cần và 1 vận hành và bảo trì phải chịu đựng 18 giờ mới được cứu lại, trì hoãn kế hoạch thử nghiệm căng thẳng trước 3 ngày.

Trước hết, hãy hiểu rõ: Docker triển khai thực chất là gì

Nói một cách đơn giản, đó là việc đóng gói toàn bộ mã nguồn ứng dụng của bạn, các thư viện phụ thuộc, tệp cấu hình, thậm chí là các tham số hệ thống nhân của hệ điều hành thành một “hình ảnh container” tiêu chuẩn. Bất cứ điều gì xảy ra trên máy tính cá nhân của bạn khi bạn chạy ứng dụng đó, sẽ được sao chép y hệt trên bất kỳ máy chủ nào đã cài đặt engine Docker.Mỗi hình ảnh (image) có thể được tối ưu hóa để chỉ chiếm dung lượng tối thiểu là 20MB, và thời gian khởi động không quá 1 giây.。

Chúng tôi đã sử dụng lợi nhuận thực tế trong vòng 3 tháng.

Đầu tiên, vấn đề về sự không nhất quán trong môi trường đã được giải quyết triệt để. Trước đây, chỉ riêng việc cấp phiên bản Node.js và các driver cơ sở dữ liệu khác nhau cho mỗi trang web đã mất rất nhiều thời gian (khoảng nửa ngày). Bây giờ, sau khi các hình ảnh được đóng gói sẵn được truyền vào kho lưu trữ hình ảnh, ba trang web có thể được kéo xuống và khởi động chỉ với một cú nhấp chuột. Thời gian triển khai đã giảm từ trung bình 4 giờ xuống còn 24 phút, và việc cập nhật phiên bản trước các chương trình khuyến mãi lớn không còn phải thức suốt đêm nữa.

Tiếp theo là tỷ lệ sử dụng tài nguyên máy chủ đã tăng gấp đôi. Trước đây, mỗi trang web đều thuê một máy chủ đám mây riêng với 2 lõi (4G), và tỷ lệ sử dụng CPU vào thời gian rảnh thấp hơn 10%. Bây giờ, chúng tôi sử dụng Docker để tích hợp các ứng dụng, bộ đệm và các tác vụ định kỳ của ba trang web trên một máy chủ 4 lõi (8G), và tài nguyên đã đủ để đáp ứng nhu cầu.Chi phí vận hành máy chủ hàng tháng được tiết kiệm trực tiếp 620 đô la Mỹ.Đối với một nhóm nhỏ dưới 10 người, đó không phải là một con số nhỏ.

Cuối cùng, tốc độ mở rộng hệ thống hoàn toàn đáp ứng được lượng truy cập đột ngột. Năm ngoái, vào dịp Black Friday, chúng tôi phải thêm máy chủ một cách khẩn cấp và mất gần 2 giờ để thiết lập môi trường hoạt động. Nhưng năm nay, chỉ trong vòng 10 phút trước thời điểm cao điểm, chúng tôi đã triển khai 12 bản sao của hệ thống và có thể xử lý lượng truy cập gấp 3 lần so với bình thường mà không gặp phải tình trạng truy cập bị trì hoãn.

Đừng vội lên xe, chúng tôi đã giúp bạn tránh những trở ngại này rồi.

Cái hố đầu tiên là hình ảnh phản chiếu viết quá phồng lên. Ban đầu chúng tôi trực tiếp sử dụng chính thức Node.js đầy đủ chức năng gương đóng gói, một ứng dụng gương sẽ có 1.2G, truyền đến kho gương nước ngoài mất hơn 20 phút, sau đó chuyển sang Alpine cơ bản gương, đem không có ích phụ thuộc tất cả xóa, cuối cùng gương chỉ có 90MB, tốc độ truyền nhanh hơn 10 lần đều không ngừng.

Lỗi thứ hai là dữ liệu được lưu trữ trong một container. Ban đầu chúng tôi không chú ý đến điều này và đã lưu trữ hình ảnh sản phẩm do người dùng tải lên trực tiếp trong thư mục cục bộ của container. Sau đó, khi container được khởi động lại, tất cả các hình ảnh đều bị mất và mất một ngày để phục hồi chúng từ bản sao lưu. Kể từ đó, tất cả dữ liệu được lưu trữ lâu dài đều được đưa lên thư mục cục bộ của máy chủ hoặc lưu trữ đối tượng (object storage), và không còn gặp phải vấn đề gì nữa.

Lỗi thứ ba là không có giới hạn về nguồn lực. Khi hệ thống mới được triển khai, không có giới hạn về CPU và bộ nhớ được đặt cho các container. Một lần, một tác vụ định kỳ trên một trang web gặp lỗi và chiếm hết CPU của toàn bộ máy chủ, khiến cho hai trang web khác cũng bị đóng. Sau đó, chúng tôi đã đặt các giới hạn về nguồn lực cho mỗi container, vì vậy ngay cả khi một dịch vụ bị lỗi, nó cũng không ảnh hưởng đến toàn bộ hệ thống.

Liệu có nên sử dụng Docker hay không? Tiêu chí đánh giá của chúng tôi rất đơn giản.

Trường hợp nên sử dụng: Bạn cần triển khai cùng một ứng dụng trên nhiều máy chủ, thường xuyên chuyển đổi giữa môi trường phát triển, thử nghiệm và sản xuất, và quy mô nhóm lớn hơn 3 người, mỗi người có môi trường phát triển khác nhau. Việc sử dụng Docker sẽ giúp tăng hiệu quả làm việc.

Trường hợp không nên sử dụng: Nếu bạn chỉ có một blog nhỏ, chạy trên một máy chủ duy nhất, và chỉ cập nhật mã nguồn mỗi nửa năm một lần, thì hoàn toàn không cần phải dành thời gian học Docker. Thay vào đó, việc sử dụng công cụ như Baota hoặc thực hiện quá trình triển khai thủ công sẽ tiết kiệm thời gian và công sức hơn nhiều.

3 lời khuyên cụ thể dành cho người mới bắt đầu

• Trong 3 lần đầu tiên tạo ra hình ảnh (image), hãy tìm trực tiếp các mẫu thực hành tốt nhất từ nguồn chính thức; đừng tự mình viết file Dockerfile một cách tùy tiện. Bằng cách này, bạn có thể tránh được khoảng 80% các vấn đề liên quan đến sự cồng kềnh của hình ảnh và lỗi quyền (permission errors).
• Ban đầu, bạn không cần phải sử dụng những công cụ phức tạp như K8s; chỉ cần sử dụng Docker Compose để quản lý tối đa 3 dịch vụ là đã đủ rồi.
• Hãy sử dụng các nút cục bộ ở nước ngoài của nhà cung cấp dịch vụ đám mây để lưu trữ kho lưu trữ ảnh; đừng tự mình xây dựng nó. Thời gian tiết kiệm được đó đủ để bạn phát triển thêm vài tính năng nữa.

Câu trả lời thống nhất cho các vấn đề nhỏ thường gặp

Câu hỏi: Docker có làm tăng thêm đáng kể hiệu năng của máy chủ không? Chúng tôi đã kiểm tra và thấy rằng mức sụt giảm hiệu năng chưa đến 5%, điều này hoàn toàn không thể được nhận thấy bởi hầu hết các nhóm nhỏ và vừa.

Câu hỏi: Các ứng dụng cũ có thể được chuyển sang Docker không? Tất nhiên là có thể. Chúng tôi có một dự án PHP cũ đã vận hành được 3 năm, và chỉ mất 2 ngày để tạo ra hình ảnh (image) và thực hiện việc chuyển đổi, điều này nhanh hơn nhiều so với việc thiết lập môi trường lại từ đầu.