Đầu năm 2015, sau nhiều năm chạy các triển khai trên Amazon EC2, nhóm của tôi tại Luminis Technologies được giao nhiệm vụ xây dựng một nền tảng deploy mới cho tất cả các nhóm phát triển phần mềm. Thiết lập dựa trên AWS đã hoạt động rất tốt để release mới trong nhiều năm qua. Tuy nhiên việc thiết lập deploy với các tập lệnh và công cụ tùy chỉnh để tự động deploy không thuận lợi cho các nhóm ngoài bộ phận vận hành sử dụng, đặc biệt là các nhóm nhỏ không có tài nguyên để tìm hiểu tất cả các chi tiết về các tập lệnh và công cụ này. Vấn đề chính là không có 1 bộ phận chuyên deploy, điều này tạo ra khoảng cách giữa phát triển và vận hành. Xu hướng Container xuất hiện hứa hẹn mang lại nhiều sự thay đổi. 

Nếu bạn chưa sẵn sàng để sử dụng Docker và Kubernetes, hãy đọc về cách nhóm của tôi trở thành những người dùng đầu tiên. Chúng tôi đã chạy Kubernetes trong hơn một năm qua!

 

1. Bắt đầu với Containers và các công cụ quản lý

Thời điểm này tôi tin rằng Container là định dạng triển khai của tương lai. Container giúp đóng gói một ứng dụng với cơ sở hạ tầng cần thiết dễ dàng hơn nhiều. Mặc dù các công cụ như Docker cung cấp các Containers thực tế, chúng tôi vẫn  cần các công cụ để xử lý những thứ như sao chép và chuyển đổi dự phòng cũng như API để tự động deploy cho nhiều máy.

Các công cụ phân cụm như Kubernetes và Docker Swarm còn khá sơ sài vào đầu năm 2015 khi chỉ có các phiên bản alpha đầu tiên. Chúng tôi vẫn thử sử dụng chúng và bắt đầu với Docker Swarm. Lúc đầu, chúng tôi sử dụng nó để tự xử lý kết nối mạng với Ambassador Pattern và một loạt các kịch bản để tự động deploy. Đây là bài học khó khăn đầu tiên của chúng tôi: Phân cụm Container, kết nối mạng và tự động deploy thực sự là những vấn đề rất khó giải quyết.

Chúng tôi nhận ra điều này đủ nhanh và quyết định đặt cược vào một trong những công cụ có sẵn. Kubernetes dường như là lựa chọn tốt nhất, vì được hỗ trợ bởi Google, Red Hat, Core OS và một vài tổ chức khác có kinh nghiệm về deploy quy mô lớn. 

2. Cân bằng tải với Kubernetes

Khi làm việc với Kubernetes, bạn phải làm quen với các khái niệm như: nhóm (Pods), dịch vụ (Services) và bộ điều khiển sao chép (Replication controllers). Nếu bạn chưa quen với các khái niệm này, có một số tài nguyên tuyệt vời có sẵn để giúp bạn tăng tốc như Kubernetes documentation. Thư viện này có một số hướng dẫn cho người mới bắt đầu.

Khi có một cụm Kubernetes và chạy, chúng tôi có thể deploy một ứng dụng bằng cách sử dụng kubectl, Kubernetes CLI, nhưng chúng tôi nhanh chóng thấy rằng kubectl không hiệu quả khi muốn tự động deploy. Nhưng trước tiên, chúng tôi có một vấn đề khác cần giải quyết: Làm thế nào để truy cập ứng dụng đã deploy từ Internet?

Dịch vụ trước khi deploy có địa chỉ IP, nhưng địa chỉ này chỉ tồn tại trong cụm Kubernetes. Điều này có nghĩa là dịch vụ này không có sẵn trên Internet! Khi chạy trên Google Cloud Engine, Kubernetes có thể tự động configure bộ cân bằng tải để truy cập ứng dụng. Nếu bạn không ở trên GCE (như chúng tôi), bạn cần thực hiện thêm một chút công việc để cân bằng tải hoạt động.

Hiển thị một dịch vụ trực tiếp trên một máy chủ cổng là cách nhiều người sử dụng khi bắt đầu nhưng chúng tôi thấy rằng điều này lãng phí nhiều lợi ích của Kubernetes. Nếu dựa vào các cổng trong máy chủ của mình, chúng ta sẽ gặp xung đột cổng khi deploy nhiều ứng dụng. Điều này làm cho việc mở rộng cụm hoặc thay thế máy chủ trở nên khó khăn hơn nhiều.

 

3. Thiết lập cân bằng tải hai bước

Chúng tôi phát hiện ra một cách tiếp cận tốt hơn nhiều là configure bộ cân bằng tải như HAProxy hoặc NGINX trước cụm Kubernetes. Chúng tôi đã bắt đầu chạy các cụm Kubernetes của mình bên trong VPN trên AWS và sử dụng bộ cân bằng tải đàn hồi AWS để route lưu lượng truy cập web bên ngoài đến cụm HAProxy bên trong. HAProxy được configure với một back-end cuối cùng cho mỗi dịch vụ Kubernetes – hỗ trợ lưu lượng truy cập cho các nhóm riêng lẻ.

Thiết lập cân bằng tải hai bước này chủ yếu để đáp ứng các tùy chọn cấu hình khá hạn chế của AWS ELB, một trong đó là không thể xử lý nhiều vhost. Đây cũng là lý do chúng tôi sử dụng HAProxy. Chỉ sử dụng HAProxy mà không có ELB cũng có thể hoạt động, nhưng bạn sẽ work around các địa chỉ IP AWS động ở cấp độ DNS.

 

Hình 1: Sơ đồ thiết lập cân bằng tải hai bước

 

Trong mọi trường hợp, chúng tôi cần một cơ chế reconfigure bộ cân bằng tải (HAProxy, trong trường hợp của chúng tôi) khi các dịch vụ Kubernetes mới được tạo.

Cộng đồng Kubernetes hiện đang làm việc trên một tính năng được gọi là Ingress. Ingress có thể hỗ trợ trực tiếp configure một bộ cân bằng tải bên ngoài từ Kubernetes. Hiện tại, tính năng này vẫn chưa thể sử dụng được vì nó chưa hoàn thành. Năm ngoái, chúng tôi đã sử dụng API và một công cụ nguồn mở nhỏ để configure cân bằng tải.

 

4. Configure cân bằng tải

Đầu tiên, chúng tôi cần một nơi để lưu trữ các cấu hình cân bằng tải. Chúng có thể được lưu trữ ở bất cứ đâu, nhưng vì chúng tôi đã có sẵn ETCD, chúng tôi quyết định lưu trữ các cấu hình cân bằng tải ở đó. Chúng tôi sử dụng một công cụ có tên confd để theo dõi sự thay đổi của các  cấu hình hình trong etcd và tạo tệp cấu hình HAProxy mới dựa trên mẫu. Khi một dịch vụ mới được thêm vào Kubernetes, chúng tôi sẽ thêm một cấu hình mới vào etcd, dẫn đến một tệp cấu hình mới cho HAProxy.

 

5. Kubernetes: Phát triển tính năng tốt cần thời gian

Vẫn còn nhiều vấn đề chưa được giải quyết trong Kubernetes, cũng như trong cân bằng tải nói chung. Nhiều vấn đề trong số này được cộng đồng thừa nhận và đã có những tài liệu được viết để thảo luận về các tính năng mới có thể giải quyết một trong số các vấn đề còn tồn đọng. Tuy nhiên việc đưa ra các giải pháp phù hợp với mọi người cần có thời gian, đồng nghĩa với việc một số tính năng này có thể mất khá nhiều thời giờ trước khi được phát hành. Nếu “đốt cháy giai đoạn” và vội vàng khi thiết kế các tính năng mới có thể gây ra các hậu quả về lâu dài.

Điều này không có nghĩa là ngày nay Kubernetes bị hạn chế. Với việc sử dụng API, Kubernetes có thể thực hiện khá nhiều thứ bạn cần nếu bạn muốn bắt đầu sử dụng ngay hôm nay. Một khi nhiều tính năng được triển khai trong chính Kubernetes, chúng ta có thể thay thế các giải pháp tùy chỉnh bằng các giải pháp tiêu chuẩn. Sau khi chúng tôi phát triển giải pháp tùy chỉnh để cân bằng tải, thử thách tiếp theo của chúng tôi là deploy một kỹ thuật thiết yếu: Blue-green deploy.

 

6. Blue-green deploy trong Kubernetes

Blue-green deploy không có downtime. Trái ngược với các bản cập nhật, một Blue-green deploy hoạt động bằng cách bắt đầu một cụm bản sao chạy phiên bản mới trong khi tất cả các bản sao cũ vẫn phục vụ các yêu cầu trực tiếp. Khi bản sao mới hoàn tất hoạt động, cấu hình cân bằng tải sẽ được chuyển sang phiên bản mới. Một lợi ích của cách tiếp cận này là chỉ có duy nhất một phiên bản của application chạy, làm giảm sự phức tạp của việc xử lý nhiều application đồng thời. Blue-green deploy cũng hoạt động tốt hơn với số lượng ít bản sao.

Hình 2: Blue-green deployments với Kubernetes 

Hình 2 cho thấy cách “Deployer” tổ chức deploy. Thành phần này có thể dễ dàng được tạo bởi nhóm của bạn bởi chúng tôi đã mở nguồn triển khai của theo Giấy phép Apache như một phần của dự án Amdatu. Nó cũng đi kèm với một giao diện Web để deploy.

Một khía cạnh quan trọng của cơ chế này là kiểm tra tình trạng mà nó thực hiện trên các pods trước khi cấu hình lại bộ cân bằng tải. Chúng tôi muốn từng thành phần được triển khai để kiểm tra tình trạng hoạt động. Bây giờ chúng tôi thường thêm một phần kiểm tra tình trạng có sẵn trên HTTP cho từng thành phần ứng dụng.

7. Triển khai Deploy tự động

Với Deployer sẵn có, chúng tôi có thể kết nối các deployments với một build pipeline. Sau khi xây dựng thành công, máy chủ xây dựng của chúng tôi có thể đẩy hình ảnh Docker mới vào một sổ đăng ký, ví dụ như  Docker Hub. Sau đó, máy chủ xây dựng có thể gọi Deployer để tự động triển khai phiên bản mới trong môi trường thử nghiệm. Hình ảnh tương tự có thể được sử dụng vào sản xuất bằng cách kích hoạt Deployer trên môi trường sản xuất.

Hình 3: Pipeline deploy container tự động

 

…(còn tiếp)

Like và follow Fanpage của Pixta Việt Nam tại đây để cùng đọc và cập nhật những tin tức công nghệ mới nhé!

 

Tác giả: Paul Bakker, Software architect, Netflix

Xem bài viết gốc tại đây

Tổng hợp và dịch: Vân Phạm, Thảo Ly, Nhật Anh