2. Sun Container Spinner Prequisite#

Sun Container Spinner nói riêng và công nghệ Container nói chung là thuật ngữ mới nếu như so sánh với VM(Virtual Machine) trong lĩnh vực triển khai ứng dụng và hệ thống. Bài viết này sẽ giải thích một số thuật ngữ và các điều kiện cần có trước khi sử dụng Sun Container Spinner.

Một số thuật ngữ#

  • Docker: Khi tìm hiểu về container, Docker là một trong những từ khóa phổ biến nhất mà người dùng sẽ tiếp xúc. Chúng ta có các kho chứa container - Docker Hub, môi trường để chạy container trên các hệ điều hành - Docker. Vậy Docker là gì? Docker là nền tảng cho phép phát triển, triển khai và chạy ứng dụng với container. Docker là Container Engine Software phổ biến nhất hiện nay.

  • Image: Container Image là một gói phần mềm nhẹ, độc lập, có thể thực thi được, bao gồm mọi thứ cần thiết để chạy một ứng dụng: mã, thời gian chạy, công cụ hệ thống, thư viện hệ thống và cài đặt. Tính đóng gói khiến Image trở nên độc lập và có thể chạy trên nhiều hệ điều hành/ Engine khác nhau mà không gặp trở ngại khi cài đặt(Dependency).

  • Image tag(version): Một ứng dụng Runtime được cấu thành từ các thành phần về mặt vận hành bao gồm Code, biến môi trường(Environement) và Dữ liệu(Data). Image tag là các image đã được đóng gói và gắn các thẻ khác nhau để phân biệt version/ build number của Code.

  • Container registry(Image registry): Container Registry là dịch vụ lưu trữ Container Image, chức năng phổ biến là quản lý và lưu trữ Container Image của người dùng. Nếu bạn có các Image muốn chia sẻ public cho cộng đồng hoặc các Image cho các ứng dụng của doanh nghiệp cần sự bảo mật, bạn sẽ cần đến Container Registry. Hiện nay Sunteco Cloud đã cung cấp dịch vụ Private Registry cho khách hàng doanh nghiệp.

    • Public Registry thường thấy là registry của các đơn vị lớn, worldwide, hỗ trợ cả public image và private image(Image cần tài khoản/ mật khẩu để truy cập). Vd Docker Hub, Quay, Google Container Registry, AWS Container Registry

    • Private Registry được sử dụng cho các đơn vị muốn chủ động việc lưu trữ và quản lý Container Image. Image thường có dung lượng khá lớn nên việc lưu trữ chủ động còn tối ưu tối độ tải Image trong quá trình triển khai và tiết kiệm chi phí đường truyền.

  • Environment: Ứng dụng chạy trên container có thể linh hoạt runtime với các cấu hình biến môi trường khác nhau nhờ việc cài đặt Container Environment. Environments có thể được cài đặt qua phase build/ run của Image, các giá trị biến môi trường trở thành native environment của hệ điều hành. Một cách khác để cài đặt biến môi trường là sử dụng file system: Một file cấu hình sẽ được mount vào trong container và ứng dụng sẽ đọc các cấu hình từ file.

  • K8S: Tên đầy đủ là Kubernetes - Nền tảng Container Orchestration cho phép điều phối và quản lý các ứng dụng Container. K8S loại bỏ các quy trình thủ công và cung cấp thêm các tính năng nâng cao trong triển khai.

  • POD: Thuật ngữ của K8S, POD là đơn vị deployment nhỏ nhất về tính toán. POD có thể chứa một hoặc nhiều container, các container này luôn được schedule cùng với nhau và chạy trong cùng một context.

  • Persistent Volumes : Trong K8S, quản lý phân vùng lưu trữ được tách biệt khỏi quản lý các instance xử lý tính toán. Các phân vùng lưu trữ dữ liệu này được gọi là Persistent Volume. Các phân vùng này được cấp phát bởi admin hoặc cấp phát tự động dựa trên Storage Class. Persistent Volume được kết nối với container qua thao tác mount bằng mount path(file directory), lúc này dữ liệu sẽ được lưu trữ lâu dài trên Persistent Volume, không bị mất nếu Container bị xóa hoặc restart.

  • Replication: Thuật ngữ chỉ khả năng nhân bản từ một bản mẫu trở thành nhiều instance. Có thể áp dụng cho đơn vị tính toán hoặc lưu trữ. Trong K8S tương ứng với tính năng nhiều POD được schedule từ cùng một Deployment/StatefulSets, lúc này ứng dụng có nhiều instance cùng xử lý requests

  • Microservices: Kiến trúc phần mềm hướng dịch vụ, chia nhỏ business thành các service chạy độc lập. Công nghệ Container phù hợp hoàn toàn cho việc triển khai kiến trúc Microservices, mỗi Container hoặc cụm Container sẽ tương đồng với một microservice khi triển khai.

Những lưu ý khi sử dụng Sun Container Spinner#

Vấn đề Image và ứng dụng

  • Ứng dụng chạy được trên hệ điều hành Linux: Các ứng dụng chạy trên Sun Container Spinner cần có khả năng chạy trên hệ điều hành nhân linux

  • Cần có Image để bắt đầu: Image đã được test có thể chạy trên môi trường Container Engine(vd Docker), đã được push lên một Image registry.

  • Các Image không phù hợp chạy trên Sun Container Spinner: Các image không có Entry Point, hoặc không có Command, hoặc Entry Point và CMD không phải dạng service chạy vô hạn mà là job có thể finish và return, sau khi deploy cũng sẽ xảy ra tình trạng CrassLoopBackOff, thực tế các image này đã được run thành công nhưng sau khi Completed, hệ thống sẽ tiếp tục reschedule và image sẽ start lại liên tục

  • Xác định nhu cầu ứng dụng(Stateless/Stateful application) về compute và lưu trữ: Nếu ứng dụng nghiên về hướng compute, có nhu cầu scale thường xuyên, không lưu trữ dữ liệu hoặc việc lưu trữ chỉ là tạm thời thì lựa chọn No Volume. Nếu ứng dụng cần đến vùng nhớ lưu trữ lâu dài, có hai option cho người dùng lựa chọn là sử dụng Shared Volume và Dedicated Volume. Shared Volume là hình thức các container có thể sử dụng chung một volume, volume này sẽ tồn tại độc lập với các POD. Dedicated volume là hình thức các volume được sinh ra theo cấu hình cài đặt cùng với POD, nhưng khi POD bị destroy, các volume này không bị ảnh hường, người dùng cần chủ động quản lý các volume này, lần tiếp theo khi các POD được sinh ra sẽ tự nhận các dedicated volume nếu có sẵn theo thứ tự tương ứng của pod và volume(hậu tố phía sau tên của pod và volume).

Lựa chọn cấu hình CPU/RAM và số lượng POD cho Sun Container Spinner

Có một sự tương quan giữa cấu hình CPU/RAM và số lượng POD(Instance) với khả năng xử lý của ứng dụng, người dùng cần hiểu rõ mối quan hệ này để cài đặt các thông số cho phù hợp với nhu cầu hệ thống. Chúng ảnh hưởng trực tiếp đến performance chung của ứng dụng và cả chi phí. Hai thông số này có thể set trong lúc tạo Spinner nhưng cũng có thể thay đổi tùy ý về sau. Concept đằng sau việc lựa chọn số CPU/Ram hoặc số lượng POd cho ứng dụng là Vertical Scaling và Horizontal Scaling. Với các nền tảng Container có thể hiểu Vertical Scaling nói đến việc tăng performance bằng cách tăng tài nguyên của đối tượng Compute hiện tại. Còn Horizontal Scaling không tăng cấu hình của đối tượng Compute mà tạo ra thêm các đối tượng Compute để xử lý song song.

Nói một cách đơn giản CPU/RAM sẽ quyết định khả năng xử lý của một POD, giá trị càng lớn POD càng có nhiều tài nguyên để xử lý.

Một số usecase CPU/RAM nhiều hơn sẽ phù hợp:

  • Với các ứng dụng cần nhiều tài nguyên để xử lý lần lượt các công việc(queue)

  • Lượng RAM tiêu thụ lớn khi lưu cache, in memory DB,

  • Sử dụng lượng tài nguyên lớn CPU/RAM trong một số thời điểm: Chạy job, xuất báo cáo

Multiple PODs ngoài khả năng xử lý song song còn đảm bảo High Availability của hệ thống. Một instance gặp lỗi sẽ không ảnh hưởng đến toàn bộ ứng dụng, hệ thống cân bằng tải(Load balance) sẽ chuyển hướng request đến các instance đang hoạt động.

Chuyển đổi từ Monolith sang Microservice

Thường các ứng dụng đang được triển khai trên VM chưa thể chuyển đổi ngay lập tức sang container, nhưng việc chuyển đổi sang Microservice không quá khó khăn nếu hệ thống đang tuân thủ các nguyên tắc của thiết kế hệ thống. Người dùng có thể cân nhắc chuyển đổi một phần hoặc hoàn toàn hệ thống sang Microservice dựa trên Sun Container Spinner. Xem thêm ví dụ về chuyển đổi từ Monolith sang Microservice