Làm cách nào tôi có thể đảm bảo tính nhất quán giữa các dịch vụ mới?


10

Tổ chức của tôi đang trải qua một sự bùng nổ của microservice. Chúng tôi hiện không có cách chính thức để bootstrapping dự án mới. Tôi thấy rằng một nhóm sẽ gặp tôi với một lỗi trong quá trình triển khai hoặc xây dựng của họ và tôi sẽ dành thời gian cho nó để nhận ra rằng tôi đã giải quyết nó trong một dự án khác. Cũng có nhiều mâu thuẫn giữa các dự án mà tôi muốn thấy được tiêu chuẩn hóa.

Các thay đổi thường liên quan đến một tệp duy nhất (ví dụ: serverless.yml hoặc Makefile), do đó, một giải pháp liên quan đến các thư viện dùng chung, ví dụ như các mô đun con git dường như không khả thi. Mỗi dự án sẽ có một bộ cấu hình riêng cần được duy trì, ví dụ Dockerfiles hoặc serverless.yml, vì vậy các giải pháp quản lý cấu hình tập trung cho VM không thực sự áp dụng.

Làm cách nào tôi có thể đảm bảo rằng các dịch vụ siêu nhỏ mới tuân thủ các tiêu chuẩn của tổ chức và bao gồm các lỗi / tính năng từ các dự án hiện tại theo cách dễ dàng và trực quan cho các nhà phát triển muốn bắt đầu các dự án mới? Một số thực tiễn tốt nhất xung quanh việc giải quyết các vấn đề này là gì?

Quy trình công việc hiện tại chúng tôi có là hỏi người bên cạnh bạn "tôi nên sao chép dự án nào để sử dụng làm mẫu?" và sau đó xóa tất cả những thứ không cần thiết cho dự án đó.

Câu trả lời:


5

Tôi sẽ thêm một câu trả lời về giải pháp của tôi cho đến nay, nhưng tôi vẫn thực sự quan tâm đến việc nghe các tổ chức khác đang giải quyết vấn đề này như thế nào và các thực tiễn tốt nhất mà họ có.

Để giải quyết vấn đề không có cơ sở nhất quán để tạo dự án, ý tưởng của tôi là tạo một kho lưu trữ (kho lưu trữ?) Các mẫu / mẫu nồi hơi và sử dụng cookiecutter như một công cụ để tạo ra các dịch vụ siêu nhỏ mới. Theo cách này, mỗi dự án được tạo ra từ một cơ sở tiêu chuẩn với tất cả các bài học mà chúng tôi đã học được khi là một tổ chức được tích hợp vào đó. Mọi thay đổi chúng tôi thực hiện có thể được tích hợp ngược dòng vào kho lưu trữ soạn sẵn. Tôi tưởng tượng chúng ta sẽ có các mẫu cho hình ảnh Nodejs Docker, Serverless SPAs, Python lambdas, v.v.

Để giải quyết vấn đề thay đổi được thực hiện đối với các mẫu được đưa vào hạ nguồn cho mọi dự án, giải pháp của tôi là thực hiện quy trình mà chủ sở hữu microservice nhận thức được các thay đổi đối với mẫu và sau đó chịu trách nhiệm truyền bá các thay đổi đó cho microservice của họ.


Đây là những gì chúng tôi làm, kết hợp với một ứng dụng hello world đơn giản minh họa các thực tiễn tốt nhất như một ví dụ cụ thể.
Tẩy chay SE cho Monica Cellio

4

Sử dụng quản lý cấu hình / hệ thống triển khai tự động. Đây là những gì chúng được thiết kế cho. Những thứ như Kubernetes, Puppet, Chef, Ansible và Salt Stack được thiết kế cho mục đích này và có thể được sử dụng với các mẫu Golden Master, tập lệnh khởi động, Amazon AMIs hoặc chỉ là một container Docker. Điều này cho phép bạn sử dụng các mẫu cơ sở mặc định và sau đó lớp trên các vai trò bổ sung. Điều này sẽ đảm bảo các bản dựng được ghi lại hoàn toàn (dưới dạng mã) và sẽ nhanh chóng và dễ dàng triển khai vào sản xuất và sẽ được triển khai chính xác theo những gì đã được thiết kế hoặc triển khai các trường hợp bổ sung khi có nhu cầu về khả năng mở rộng hoặc dự phòng. Thay đổi / cập nhật cũng có thể được tích hợp theo cách này. Giống như bạn phát hành bản cập nhật phần mềm, bạn có thể phát hành các bản cập nhật cho cấu hình của mình và mã cấu hình có thể được quản lý giống như mã phần mềm của bạn được quản lý - trong cùng một repos và với cùng một quy trình công việc. Và khi thời gian nâng cấp đến, không có gì bí ẩn về cách thức xây dựng, chỉ cần nhìn vào kịch bản.

Một cách mà các hệ thống quản lý cấu hình thực hiện điều này là thông qua việc sử dụng nhiều khuôn mẫu cho các tệp cấu hình của bạn. Ví dụ, nhìn chung có nhiều dòng sẽ giống hoặc tương tự trong môi trường của bạn. SaltStack sử dụng các mẫu jinja và con rối sử dụng các mẫu Ruby nhúng . Sử dụng AWS làm ví dụ, bạn có thể cần đặt khóa api, vai trò IAM, vùng (hoặc chọn ngẫu nhiên một vùng từ danh sách các vùng), VPC, v.v ... giống nhau trên tất cả các trường hợp. Nhưng sau đó bạn cần phải có chức năng và đầu ra duy nhất. Hoặc tốt hơn là bạn có thể viết mô-đun con rối hoặc công thức muối xác định "hợp đồng" và sử dụng các hợp đồng đó (định nghĩa api) cho cả đầu vào và đầu ra giúp bạn không phải cấu hình microservice hai hoặc ba vị trí.

SaltStack gần đây đã có một cuộc họp để thảo luận về kịch bản cụ thể này . Hơn nữa, SaltStack cũng có thể quản lý và triển khai các container docker nguyên bản . (Puppet cũng có một mô-đun cho Docker ) Tương tự như vậy Ansible có các playbook và tài liệu để làm việc với các triển khai không có máy chủcác container Docker .

Ngoài ra, nếu bạn muốn tiếp tục với chủ đề / mô hình không có máy chủ, Puppet , Ansible và saltstack, tất cả đều vô dụng hoặc hỗ trợ chế độ không chủ, nếu bạn muốn tiếp tục chủ đề này.


Tôi đã thêm một số ví dụ và làm rõ câu hỏi của tôi. Quản lý cấu hình không thực sự hữu ích vì mỗi dự án đều nằm trong cấu hình của nó. Không có vấn đề gì với việc chuyển sang cấu hình dưới dạng mã, đó là về việc duy trì cấu hình dưới dạng mã và cấu hình mở rộng mà bạn có thể kết thúc nếu bạn có 100 microservice mỗi cấu hình khác nhau. Chúng tôi hiện đang sử dụng CI / CD với các bản dựng nhất quán nên điều đó cũng không phải là vấn đề đáng lo ngại.
dùng2640621

1
@ user2640621 - Bạn đã bao giờ sử dụng hệ thống quản lý cấu hình chưa? Tập trung "mở rộng cấu hình" giúp bạn quản lý dễ dàng hơn và từ một nơi (thay vì 100 địa điểm khác nhau). Mặc dù mỗi dự án có thể được khép kín, rõ ràng có một số chồng chéo khi bạn hỏi về việc triển khai khuôn mẫu. Có thể đáng để thử một vài trong hộp sanbox để cảm nhận về cách chúng hoạt động trước khi bạn xóa chúng ... Điều này không chỉ tự động hóa việc quản lý các tệp cấu hình của bạn - nó còn hơn thế nữa.
James Shewey

1
Tôi đã sử dụng SaltStack, Chef và Puppet, nhưng chỉ bao giờ để quản lý VM. Cảm ơn câu trả lời của bạn, tôi chắc chắn đang thấy cách quản lý cấu hình có thể được sử dụng bên ngoài việc quản lý VM bây giờ.
dùng2640621

2
@ user2640621: Nếu tất cả đều khác nhau: "Bạn mã hóa nó, bạn chạy nó". Hãy để các đội quản lý các dịch vụ của họ. Hãy để họ cảm nhận nỗi đau của bạn.
Phục hồi Monica - M. Schröder

3

Câu hỏi này rất rộng nên nếu câu trả lời của tôi hơi lạc hậu, hãy thoải mái thêm ngữ cảnh và ví dụ cụ thể để tôi hiểu rõ hơn.

Sử dụng hình ảnh máy như AMI của AWS sẽ cho phép bạn tạo một hình ảnh cơ sở hoặc vàng, sau đó bạn có thể duy trì và phân phối hoặc thực hiện trong phân phối liên tục của mình. Sử dụng kiến ​​trúc này, bạn đảm bảo rằng mọi microservice đều được triển khai trên phần cứng phù hợp với cấu hình giống hệt nhau để mọi vấn đề bạn gặp phải đều liên quan đến cấu hình microservice / ứng dụng.

Bạn có thể tiếp tục sự bất biến này với việc bổ sung các công cụ cấu hình như Ansible và Packer. Sử dụng quản lý cấu hình, bạn có thể cung cấp hình ảnh máy với bất cứ thứ gì bạn muốn trên đó (bao gồm cả ứng dụng). Trình đóng gói sau đó sẽ cho phép bạn chụp ảnh nhanh của máy đó và mỗi lần triển khai sẽ giống hệt nhau.

Sử dụng ví dụ này, bạn có thể 'nướng' một AMI cơ sở với các gói, bản cập nhật và cấu hình chính xác được cài đặt với sự trợ giúp của Ansible và Packer. Ngoài ra, bạn có thể xem 'Ansible-Pull' để hoàn thành việc triển khai bằng cách kéo mã ứng dụng, thực hiện bất kỳ thay đổi nào và triển khai microservice trên hình ảnh cơ sở đó.

Tuy nhiên, lời khuyên quan trọng nhất tôi có thể đưa ra là chỉ cần đưa ra một giải pháp mà toàn bộ tổ chức có thể hỗ trợ và duy trì. Thật đáng để cố gắng thiết lập một SDLC giải quyết các vấn đề cụ thể của bạn, phù hợp với văn hóa và thái độ lãnh đạo và chấp nhận thực hành kiến ​​trúc hiện đại.

Tôi đã làm việc với ba tổ chức và chúng tôi đã thực hiện ba cách tiếp cận rất khác nhau.

Chúc may mắn!


Chúng tôi không sử dụng bất kỳ giải pháp dựa trên VM nào (chủ yếu là Serverless và một chút Docker), nhưng tôi sẽ thử áp dụng vấn đề của mình vào ví dụ của bạn. Khi ai đó muốn tạo một hình ảnh đóng gói mới, họ sẽ bắt đầu từ đâu? Nếu mỗi dự án là độc lập và không có kho lưu trữ trung tâm cho cấu hình trình đóng gói, thì chúng sử dụng làm cơ sở gì để tạo hình ảnh? Có lẽ một trong những khác biệt là các dự án tôi đang làm việc cố gắng khép kín nhất có thể, không phụ thuộc vào các dịch vụ tập trung như Ansible nơi bạn có thể cập nhật cấu hình cho tất cả các dự án cùng một lúc.
dùng2640621

Với kiến ​​trúc dựa trên máy chủ và Docker, bạn vẫn có thể áp dụng các nguyên tắc cơ bản này. Một chiến lược của tôi là duy trì một tập tin docker cơ sở. Bạn có thể xây dựng tệp docker dựa trên centOS bao gồm một số cấu hình mà bạn mong đợi trên mỗi microservice, sau đó mỗi nhóm có thể kéo tệp docker đó vào và xây dựng tệp docker cụ thể microservice của riêng họ trên đó. Để giúp quản lý container và triển khai liên tục, bạn có thể sử dụng một công cụ như Kubernetes.
Chad
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.