Hệ sinh thái Docker: Khám phá dịch vụ và Cửa hàng cấu hình phân tán

Container cung cấp một giải pháp thanh lịch cho những người muốn thiết kế và triển khai các ứng dụng trên quy mô lớn. Trong khi Docker cung cấp công nghệ chứa thực tế, nhiều dự án khác hỗ trợ phát triển các công cụ cần thiết để khởi động và giao tiếp thích hợp trong môi trường triển khai.

Một trong những công nghệ cốt lõi mà nhiều môi trường Docker dựa vào là khám phá dịch vụ. Khám phá dịch vụ cho phép một ứng dụng hoặc thành phần khám phá thông tin về môi trường và hàng xóm của chúng. Điều này thường được triển khai dưới dạng một repository key-value được phân phối, cũng có thể đóng role như một vị trí tổng quát hơn để xác định chi tiết cấu hình. Cấu hình công cụ khám phá dịch vụ cho phép bạn tách cấu hình thời gian chạy của bạn khỏi containers thực tế, cho phép bạn sử dụng lại cùng một hình ảnh trong một số môi trường.

Trong hướng dẫn này, ta sẽ thảo luận về những lợi ích của việc khám phá dịch vụ trong môi trường Docker được phân cụm. Ta sẽ chủ yếu tập trung vào các khái niệm chung, nhưng cung cấp các ví dụ cụ thể hơn nếu thích hợp.

Khám phá dịch vụ và Cửa hàng cấu hình có thể truy cập trên phạm vi global

Ý tưởng cơ bản đằng sau việc khám phá dịch vụ là bất kỳ version mới nào của ứng dụng đều có thể xác định theo chương trình các chi tiết của môi trường hiện tại của nó. Điều này là bắt buộc để version mới có thể "cắm" vào môi trường ứng dụng hiện có mà không cần can thiệp thủ công. Các công cụ khám phá dịch vụ thường được triển khai như một nơi đăng ký có thể truy cập global để lưu trữ thông tin về các version hoặc dịch vụ hiện đang hoạt động. Hầu hết thời gian, để làm cho cấu hình này có thể chịu được lỗi và có thể mở rộng, register được phân phối giữa các server có sẵn trong cơ sở hạ tầng.

Trong khi mục đích chính của các nền tảng khám phá dịch vụ là phục vụ các chi tiết kết nối để liên kết các thành phần với nhau, chúng được dùng tổng quát hơn để lưu trữ bất kỳ loại cấu hình nào. Nhiều triển khai tận dụng khả năng này bằng cách ghi dữ liệu cấu hình của chúng vào công cụ khám phá. Nếu các containers được cấu hình để chúng biết tìm kiếm các chi tiết này, chúng có thể sửa đổi hành vi của bạn dựa trên những gì chúng tìm thấy.

Dịch vụ Discovery hoạt động như thế nào?

Mỗi công cụ khám phá dịch vụ cung cấp một API mà các thành phần có thể sử dụng để cài đặt hoặc truy xuất dữ liệu. Do đó, đối với mỗi thành phần, địa chỉ khám phá dịch vụ phải được mã hóa cứng vào chính ứng dụng / containers hoặc được cung cấp dưới dạng một tùy chọn trong thời gian chạy. Thông thường, dịch vụ khám phá được triển khai dưới dạng kho key-value có thể truy cập được bằng các phương thức http chuẩn.

Cách thức hoạt động của cổng khám phá dịch vụ là mỗi dịch vụ, khi xuất hiện trực tuyến, tự đăng ký với công cụ khám phá. Nó ghi lại bất kỳ thông tin nào mà một thành phần liên quan có thể cần để sử dụng dịch vụ mà nó cung cấp. Ví dụ: database MySQL có thể đăng ký địa chỉ IP và cổng nơi daemon đang chạy và tùy chọn tên user và thông tin đăng nhập cần thiết để đăng nhập.

Khi khách hàng sử dụng dịch vụ đó trực tuyến, nó có thể truy vấn register khám phá dịch vụ để biết thông tin tại một điểm cuối được định nghĩa . Sau đó, nó có thể tương tác với các thành phần nó cần dựa trên thông tin mà nó tìm thấy.Một ví dụ điển hình về điều này là bộ cân bằng tải. Nó có thể tìm thấy mọi server backend mà nó cần để cung cấp lưu lượng truy cập bằng cách truy vấn cổng khám phá dịch vụ và điều chỉnh cấu hình của nó cho phù hợp.

Điều này đưa các chi tiết cấu hình ra khỏi chính các containers . Một trong những lợi ích của việc này là nó làm cho các container thành phần linh hoạt hơn và ít bị ràng buộc hơn với một cấu hình cụ thể. Một lợi ích khác là nó làm cho việc làm cho các thành phần của bạn phản ứng với các version mới của một dịch vụ liên quan trở nên đơn giản, cho phép cấu hình lại động.

Lưu trữ cấu hình liên quan như thế nào?

Một ưu điểm chính của hệ thống khám phá dịch vụ phân tán global là nó có thể lưu trữ bất kỳ loại dữ liệu cấu hình nào khác mà các thành phần của bạn có thể cần trong thời gian chạy. Điều này nghĩa là bạn có thể extract nhiều cấu hình hơn ra khỏi containers và vào môi trường thực thi lớn hơn.

Thông thường, để làm cho việc này hoạt động hiệu quả nhất, các ứng dụng của bạn nên được thiết kế với các giá trị mặc định hợp lý có thể được overrides trong thời gian chạy bằng cách truy vấn kho cấu hình. Điều này cho phép bạn sử dụng kho cấu hình tương tự như cách bạn sử dụng cờ dòng lệnh. Sự khác biệt là bằng cách sử dụng một cửa hàng có thể truy cập global , bạn có thể cung cấp các tùy chọn giống nhau cho từng trường hợp thành phần của bạn mà không cần thực hiện thêm công việc nào.

Lưu trữ cấu hình trợ giúp như thế nào với quản lý cụm?

Một chức năng của kho key-value được phân phối trong triển khai Docker mà ban đầu có thể không rõ ràng là lưu trữ và quản lý thành viên cụm. Các cửa hàng cấu hình là môi trường hoàn hảo để theo dõi thành viên của server lưu trữ vì lợi ích của các công cụ quản lý.

Một số thông tin có thể được lưu trữ về các server riêng lẻ trong repository lưu trữ key-value được phân phối là:

Địa chỉ IP server
Thông tin kết nối cho chính các server
Siêu dữ liệu và nhãn tùy ý có thể được nhắm đến cho các quyết định lên lịch
Role trong group (nếu sử dụng mô hình lãnh đạo / người theo dõi)

Những chi tiết này có thể không phải là điều bạn cần quan tâm khi sử dụng nền tảng khám phá dịch vụ trong trường hợp bình thường, nhưng chúng cung cấp vị trí cho các công cụ quản lý để truy vấn hoặc sửa đổi thông tin về chính cụm.

Điều gì về Phát hiện thất bại?

Việc phát hiện lỗi có thể được thực hiện theo một số cách. Mối quan tâm là liệu, nếu một thành phần bị lỗi, dịch vụ khám phá có được cập nhật để cho biết là nó không còn khả dụng hay không. Loại thông tin này rất quan trọng để giảm thiểu các lỗi ứng dụng hoặc dịch vụ.

Nhiều nền tảng khám phá dịch vụ cho phép đặt giá trị với thời gian chờ có thể cấu hình . Thành phần có thể đặt một giá trị với thời gian chờ và ping dịch vụ khám phá theo các khoảng thời gian đều đặn để đặt lại thời gian chờ. Nếu thành phần không thành công và đạt đến thời gian chờ, thông tin kết nối của version đó sẽ bị xóa khỏi cửa hàng. Khoảng thời gian chờ chủ yếu là một chức năng cho biết ứng dụng cần phản hồi nhanh như thế nào đối với lỗi thành phần.

Điều này cũng có thể được thực hiện bằng cách liên kết một containers “helper” đơn giản với từng thành phần, có trách nhiệm duy nhất là kiểm tra tình trạng của thành phần theo định kỳ và cập nhật register nếu thành phần gặp sự cố.Mối quan tâm với kiểu kiến trúc này là containers trợ giúp có thể bị hỏng, dẫn đến thông tin không chính xác trong cửa hàng. Một số hệ thống giải quyết vấn đề này bằng cách có thể xác định kiểm tra sức khỏe trong công cụ khám phá dịch vụ. Bằng cách đó, bản thân nền tảng khám phá có thể kiểm tra định kỳ xem các thành phần đã đăng ký có còn khả dụng hay không.

Điều gì về cấu hình lại các dịch vụ khi các chi tiết thay đổi?

Một cải tiến quan trọng đối với mô hình khám phá dịch vụ cơ bản là cấu hình lại động. Trong khi dịch vụ khám phá thông thường cho phép bạn tác động đến cấu hình ban đầu của các thành phần bằng cách kiểm tra thông tin khám phá khi khởi động, cấu hình lại động bao gồm việc cấu hình các thành phần của bạn để phản ứng với thông tin mới trong repository cấu hình. Ví dụ: nếu bạn triển khai trình cân bằng tải, việc kiểm tra tình trạng trên các server backend có thể cho biết một thành viên của group không hoạt động. Phiên bản đang chạy của bộ cân bằng tải cần được thông báo và cần có khả năng điều chỉnh cấu hình và reload để giải quyết vấn đề này.

Điều này có thể được thực hiện theo một số cách. Vì ví dụ về cân bằng tải là một trong những trường hợp sử dụng chính cho khả năng này, một số dự án tồn tại chỉ tập trung vào việc cấu hình lại bộ cân bằng tải khi các thay đổi cấu hình được phát hiện. Điều chỉnh cấu hình HAProxy là phổ biến do tính phổ biến của nó trong không gian cân bằng tải.

Một số dự án linh hoạt hơn ở chỗ chúng được dùng để kích hoạt các thay đổi trong bất kỳ loại phần mềm nào. Các công cụ này thường xuyên truy vấn dịch vụ khám phá và khi phát hiện thay đổi, sử dụng hệ thống tạo khuôn mẫu để tạo file cấu hình kết hợp các giá trị được tìm thấy tại điểm cuối khám phá. Sau khi file cấu hình mới được tạo, dịch vụ bị ảnh hưởng sẽ được reload .

Loại cấu hình lại động này yêu cầu lập kế hoạch và cấu hình nhiều hơn trong quá trình xây dựng vì tất cả các cơ chế này phải tồn tại trong containers của thành phần. Điều này làm cho chính containers thành phần chịu trách nhiệm điều chỉnh cấu hình của nó. Tìm ra các giá trị cần thiết để ghi vào dịch vụ khám phá và thiết kế cấu trúc dữ liệu thích hợp để dễ tiêu thụ là một thách thức khác mà hệ thống này yêu cầu, nhưng lợi ích và tính linh hoạt có thể rất đáng kể.

Điều gì về Bảo mật?

Một mối quan tâm của nhiều người khi lần đầu tiên tìm hiểu về lưu trữ cấu hình có thể truy cập global , đúng ra là bảo mật. Có thực sự ổn khi lưu trữ thông tin kết nối vào một vị trí có thể truy cập global ?

Câu trả lời cho câu hỏi đó phần lớn phụ thuộc vào những gì bạn đang chọn để đặt trong cửa hàng và bao nhiêu lớp bảo mật mà bạn cho là cần thiết để bảo vệ dữ liệu của bạn . Hầu hết mọi nền tảng khám phá dịch vụ đều cho phép mã hóa các kết nối với SSL / TLS. Đối với một số dịch vụ, quyền riêng tư có thể không quá quan trọng và việc đặt dịch vụ khám phá trên một mạng riêng có thể chứng minh là thỏa đáng. Tuy nhiên, hầu hết các ứng dụng có thể sẽ được hưởng lợi từ bảo mật bổ sung.

Có một số cách khác nhau để giải quyết vấn đề này và các dự án khác nhau đưa ra các giải pháp của riêng họ. Giải pháp của một dự án là tiếp tục cho phép truy cập mở vào chính nền tảng khám phá, nhưng mã hóa dữ liệu được ghi vào đó.Người sử dụng ứng dụng phải có khóa liên quan để giải mã dữ liệu mà nó tìm thấy trong cửa hàng. Các bên khác sẽ không thể truy cập vào dữ liệu chưa được mã hóa.

Đối với một cách tiếp cận khác, một số công cụ khám phá dịch vụ triển khai danh sách kiểm soát truy cập để chia không gian khóa thành các vùng riêng biệt. Sau đó, họ có thể chỉ định quyền sở hữu hoặc quyền truy cập vào các khu vực dựa trên các yêu cầu truy cập được xác định bởi một không gian chính cụ thể. Điều này cài đặt một cách dễ dàng để cung cấp thông tin cho một số bên nhất định trong khi vẫn giữ bí mật cho những người khác. Mỗi thành phần có thể được cấu hình để chỉ có quyền truy cập vào thông tin mà nó cần một cách rõ ràng.

Một số công cụ khám phá dịch vụ phổ biến là gì?

Bây giờ ta đã thảo luận về một số tính năng chung của các công cụ khám phá dịch vụ và kho giá trị chính được phân phối trên phạm vi global , ta có thể đề cập đến một số dự án liên quan đến các khái niệm này.

Một số công cụ khám phá dịch vụ phổ biến nhất là:

etcd : Công cụ này được tạo ra bởi các nhà production CoreOS để cung cấp khả năng khám phá dịch vụ và cấu hình phân tán global cho cả containers và chính hệ thống server . Nó triển khai một API http và có sẵn một ứng dụng client dòng lệnh trên mỗi server .
lãnh sự : Nền tảng khám phá dịch vụ này có nhiều tính năng nâng cao làm cho nó nổi bật bao gồm kiểm tra sức khỏe có thể cấu hình , chức năng ACL, cấu hình HAProxy, v.v.
Zookeeper : Ví dụ này cũ hơn một chút so với hai phần trước, cung cấp một nền tảng trưởng thành hơn với một số tính năng mới hơn.

Một số dự án khác mở rộng khám phá dịch vụ cơ bản là:

crypt : Crypt cho phép các thành phần bảo vệ thông tin chúng viết bằng cách sử dụng mã hóa public key . Các thành phần được dùng để đọc dữ liệu có thể được cung cấp khóa giải mã. Tất cả các bên khác sẽ không thể đọc dữ liệu.
confd : Confd là một dự án nhằm cho phép cấu hình lại động của các ứng dụng tùy ý dựa trên những thay đổi trong cổng khám phá dịch vụ. Hệ thống bao gồm một công cụ để xem các điểm cuối có liên quan để biết các thay đổi, một hệ thống tạo khuôn mẫu để xây dựng các file cấu hình mới dựa trên thông tin thu thập được và khả năng reload các ứng dụng bị ảnh hưởng.
vulcand : Vulcand đóng role như một bộ cân bằng tải cho các group thành phần. Nó nhận biết và sửa đổi cấu hình của nó dựa trên những thay đổi được phát hiện trong cửa hàng.
marathon : Trong khi marathon chủ yếu là một bộ lập lịch (sẽ đề cập sau), nó cũng triển khai một khả năng cơ bản để reload HAProxy khi các thay đổi được thực hiện đối với các dịch vụ có sẵn mà nó nên được cân bằng giữa.
frontrunner : Dự án này kết nối với marathon để cung cấp giải pháp cập nhật HAProxy mạnh mẽ hơn.
synapse : Dự án này giới thiệu một version HAProxy nhúng có thể định tuyến lưu lượng đến các thành phần.
dây thần kinh : Dây thần kinh được sử dụng cùng với khớp thần kinh để kiểm tra sức khỏe cho các trường hợp thành phần riêng lẻ. Nếu thành phần không khả dụng, dây thần kinh cập nhật khớp thần kinh để đưa thành phần ra khỏi vòng quay.

Kết luận

Các repository cấu hình global và khám phá dịch vụ cho phép containers Docker thích ứng với môi trường hiện tại của chúng và cắm vào các thành phần hiện có. Đây là yêu cầu cần thiết để cung cấp khả năng mở rộng và triển khai đơn giản, rảnh tay bằng cách cho phép các thành phần theo dõi và phản ứng với những thay đổi trong môi trường của chúng.

Trong hướng dẫn tiếp theo , ta sẽ thảo luận về các cách mà các containers và server Docker có thể giao tiếp với các cấu hình mạng tùy chỉnh.

Tags:

Các tin liên quan

Hệ sinh thái Docker: Giới thiệu về các thành phần chung
2015-02-01
Hệ sinh thái Docker: Tổng quan về Containerization
2015-02-01
Hệ sinh thái Docker: Lập lịch và Điều phối
2015-02-01
Hệ sinh thái Docker: Mạng và Truyền thông
2015-02-01
Cách thiết lập registry Docker riêng trên Ubuntu 14.04
2014-10-15
Cách thực hiện kiểm tra tích hợp liên tục với Drone.io trên CoreOS và Docker
2014-10-08