Các ứng dụng “bản địa trên nền tảng đám mây” hay đơn giản là “đám mây” được tạo riêng để hoạt động trong cơ sở hạ tầng đám mây. Chúng thường được xây dựng dưới dạng một tập hợp các dịch vụ siêu nhỏ được liên kết lỏng lẻo được đóng gói trong các thùng chứa, do đó các dịch vụ này được quản lý bởi nền tảng đám mây. Các ứng dụng như vậy được chuẩn bị sẵn sàng cho các lỗi theo mặc định, có nghĩa là chúng hoạt động đáng tin cậy và mở rộng quy mô ngay cả trong trường hợp xảy ra lỗi nghiêm trọng ở cấp cơ sở hạ tầng. Mặt khác của đồng tiền là các tập hợp hạn chế (hợp đồng) mà nền tảng đám mây áp đặt cho các ứng dụng vùng chứa để có thể quản lý chúng một cách tự động.
Mặc dù nhận thức đầy đủ về nhu cầu và tầm quan trọng của việc chuyển sang các ứng dụng dựa trên đám mây nhưng nhiều tổ chức vẫn không biết bắt đầu từ đâu. Trong bài đăng này, chúng tôi sẽ xem xét một số nguyên tắc, nếu tuân theo khi phát triển các ứng dụng được đóng gói, sẽ cho phép bạn nhận ra tiềm năng của nền tảng đám mây và đạt được hoạt động đáng tin cậy cũng như mở rộng quy mô ứng dụng ngay cả trong trường hợp xảy ra lỗi nghiêm trọng ở cơ sở hạ tầng CNTT mức độ. Mục tiêu cuối cùng của các nguyên tắc được nêu ở đây là tìm hiểu cách tạo các ứng dụng có thể được quản lý tự động bởi các nền tảng đám mây như Kubernetes.
Nguyên tắc thiết kế phần mềm
Trong thế giới lập trình, nguyên tắc đề cập đến những quy tắc khá chung chung phải tuân theo khi phát triển phần mềm. Chúng có thể được sử dụng khi làm việc với bất kỳ ngôn ngữ lập trình nào. Mỗi nguyên tắc đều có mục tiêu riêng, công cụ để đạt được thường là các khuôn mẫu và thực tiễn. Ngoài ra còn có một số nguyên tắc cơ bản để tạo ra phần mềm chất lượng cao, từ đó tạo nên tất cả các nguyên tắc khác. Dưới đây là một số ví dụ về các nguyên tắc cơ bản:
- (Hãy đơn giản đi, đồ ngốc) – đừng phức tạp hóa nó;
- (Đừng lặp lại chính mình) – đừng lặp lại chính mình;
- (Bạn sẽ không cần nó) - đừng tạo ra thứ gì đó không cần thiết ngay lập tức;
- Tách biệt mối lo – chia sẻ trách nhiệm.
Như bạn có thể thấy, những nguyên tắc này không đặt ra bất kỳ quy tắc cụ thể nào mà thuộc loại được gọi là những cân nhắc thông thường dựa trên kinh nghiệm thực tế, được nhiều nhà phát triển chia sẻ và họ thường xuyên tham khảo.
Ngoài ra, có – Một bộ năm nguyên tắc đầu tiên của lập trình và thiết kế hướng đối tượng, được xây dựng bởi Robert Martin. SOLID bao gồm các nguyên tắc bổ sung, rộng mở, bổ sung mà—khi được áp dụng cùng nhau—giúp tạo ra các hệ thống phần mềm tốt hơn và duy trì chúng tốt hơn trong thời gian dài.
Các nguyên tắc SOLID thuộc lĩnh vực OOP và được xây dựng bằng ngôn ngữ của các khái niệm và khái niệm như lớp, giao diện và tính kế thừa. Bằng cách tương tự, các nguyên tắc phát triển cũng có thể được xây dựng cho các ứng dụng đám mây, chỉ có phần tử cơ bản ở đây sẽ không phải là một lớp mà là một thùng chứa. Bằng cách tuân theo các nguyên tắc này, bạn có thể tạo các ứng dụng được đóng gói đáp ứng tốt hơn các mục tiêu và mục tiêu của nền tảng đám mây như Kubernetes.
Vùng chứa gốc trên nền tảng đám mây: cách tiếp cận của Red Hat
Ngày nay, hầu hết mọi ứng dụng đều có thể được đóng gói tương đối dễ dàng vào các thùng chứa. Nhưng để các ứng dụng được tự động hóa và điều phối một cách hiệu quả trong nền tảng đám mây như Kubernetes thì cần phải có thêm nỗ lực.
Cơ sở cho những ý tưởng được nêu dưới đây là phương pháp luận và nhiều công trình khác về các khía cạnh khác nhau của việc xây dựng ứng dụng web, từ quản lý mã nguồn đến các mô hình mở rộng quy mô. Các nguyên tắc được mô tả chỉ áp dụng cho việc phát triển các ứng dụng được đóng gói được xây dựng dựa trên các vi dịch vụ và được thiết kế cho các nền tảng đám mây như Kubernetes. Thành phần cơ bản trong cuộc thảo luận của chúng ta là hình ảnh vùng chứa và thời gian chạy của vùng chứa mục tiêu là nền tảng điều phối vùng chứa. Mục tiêu của các nguyên tắc được đề xuất là tạo ra các vùng chứa để có thể tự động hóa các tác vụ lập lịch, mở rộng quy mô và giám sát trên hầu hết các nền tảng điều phối. Các nguyên tắc được trình bày không theo thứ tự cụ thể.
Nguyên tắc mối quan tâm duy nhất (SCP)
Nguyên tắc này về nhiều mặt tương tự như Nguyên tắc Trách nhiệm duy nhất. ), là một phần của tập SOLID và tuyên bố rằng mọi đối tượng phải có một trách nhiệm và trách nhiệm đó phải được gói gọn hoàn toàn trong một lớp. Quan điểm của SRP là mọi trách nhiệm đều là lý do để thay đổi và một lớp phải có một và chỉ một lý do để thay đổi.
Trong SCP, chúng tôi sử dụng từ “mối quan tâm” thay vì từ “trách nhiệm” để biểu thị mức độ trừu tượng cao hơn và mục đích rộng hơn của vùng chứa so với lớp OOP. Và nếu mục tiêu của SRP là chỉ có một lý do duy nhất để thay đổi thì đằng sau SCP là mong muốn mở rộng khả năng tái sử dụng, thay thế container. Bằng cách tuân theo SRP và tạo vùng chứa giải quyết một vấn đề duy nhất và thực hiện vấn đề đó theo cách hoàn chỉnh về mặt chức năng, bạn sẽ tăng cơ hội sử dụng lại hình ảnh vùng chứa đó trong các ngữ cảnh ứng dụng khác nhau.
Nguyên tắc SCP nêu rõ rằng mỗi thùng chứa phải giải quyết được một vấn đề duy nhất và làm tốt việc đó. Hơn nữa, SCP trong thế giới container dễ dàng đạt được hơn SRP trong thế giới OOP, vì các container thường chạy một quy trình duy nhất và hầu hết thời gian, quy trình này giải quyết một nhiệm vụ duy nhất.
Nếu một số dịch vụ vi mô vùng chứa phải giải quyết một số vấn đề cùng một lúc thì nó có thể được chia thành các vùng chứa tác vụ đơn lẻ và được kết hợp trong một nhóm (một đơn vị triển khai nền tảng vùng chứa) bằng cách sử dụng các mẫu vùng chứa sidecar và init. Ngoài ra, SCP giúp dễ dàng thay thế vùng chứa cũ (chẳng hạn như máy chủ web hoặc nhà môi giới tin nhắn) bằng vùng chứa mới giúp giải quyết cùng một vấn đề nhưng có chức năng mở rộng hoặc quy mô tốt hơn.
Nguyên tắc có khả năng quan sát cao (HOP)
Khi các vùng chứa được sử dụng như một cách thống nhất để đóng gói và chạy các ứng dụng thì bản thân các ứng dụng đó sẽ được coi là một hộp đen. Tuy nhiên, nếu đây là các vùng chứa trên đám mây thì chúng phải cung cấp các API đặc biệt cho thời gian chạy để theo dõi tình trạng của các vùng chứa và thực hiện hành động thích hợp nếu cần. Nếu không có điều này, sẽ không thể thống nhất việc tự động hóa việc cập nhật vùng chứa và quản lý vòng đời của chúng, do đó, sẽ làm giảm tính ổn định và khả năng sử dụng của hệ thống phần mềm.
Trong thực tế, tối thiểu một ứng dụng được đóng gói phải có API cho nhiều loại kiểm tra tình trạng khác nhau: kiểm tra khả năng hoạt động và kiểm tra mức độ sẵn sàng. Nếu một ứng dụng yêu cầu làm được nhiều việc hơn thì nó phải cung cấp các phương tiện khác để theo dõi trạng thái của nó. Ví dụ: ghi nhật ký các sự kiện quan trọng thông qua STDERR và STDOUT để tổng hợp nhật ký bằng Fluentd, Logstash và các công cụ tương tự khác. Cũng như tích hợp với các thư viện thu thập số liệu và theo dõi, chẳng hạn như OpenTracing, Prometheus, v.v.
Nhìn chung, ứng dụng vẫn có thể được coi là một hộp đen nhưng nó phải được cung cấp tất cả các API mà nền tảng cần để giám sát và quản lý nó một cách tốt nhất có thể.
Nguyên tắc tuân thủ vòng đời (LCP)
LCP là phản đề của HOP. Trong khi HOP tuyên bố rằng vùng chứa phải hiển thị các API đã đọc cho nền tảng, LCP yêu cầu ứng dụng có thể chấp nhận thông tin từ nền tảng. Hơn nữa, vùng chứa không chỉ phải nhận các sự kiện mà còn phải thích ứng, hay nói cách khác là phản ứng với chúng. Do đó, tên của nguyên tắc này có thể được coi là một yêu cầu để cung cấp cho nền tảng khả năng viết API.
Nền tảng có các loại sự kiện khác nhau để giúp quản lý vòng đời của vùng chứa. Nhưng chính ứng dụng sẽ quyết định nhận thức cái nào trong số chúng và phản ứng như thế nào.
Rõ ràng là một số sự kiện quan trọng hơn những sự kiện khác. Ví dụ: nếu một ứng dụng không chịu được sự cố tốt, thì ứng dụng đó phải chấp nhận các thông báo tín hiệu: chấm dứt (SIGTERM) và bắt đầu quy trình chấm dứt của nó càng nhanh càng tốt để bắt được tín hiệu: tiêu diệt (SIGKILL) xuất hiện sau SIGTERM.
Ngoài ra, các sự kiện như PostStart và PreStop có thể quan trọng đối với vòng đời của ứng dụng. Ví dụ: sau khi khởi chạy một ứng dụng, ứng dụng đó có thể cần một khoảng thời gian khởi động trước khi có thể phản hồi các yêu cầu. Hoặc ứng dụng phải giải phóng tài nguyên theo cách đặc biệt nào đó khi tắt.
Nguyên tắc bất biến hình ảnh (IIP)
Người ta thường chấp nhận rằng các ứng dụng được đóng gói sẽ không thay đổi sau khi được xây dựng, ngay cả khi chúng chạy trong các môi trường khác nhau. Điều này đòi hỏi cần phải lưu trữ dữ liệu bên ngoài trong thời gian chạy (nói cách khác là sử dụng các công cụ bên ngoài cho việc này) và dựa vào các cấu hình bên ngoài, dành riêng cho thời gian chạy, thay vì sửa đổi hoặc tạo các vùng chứa duy nhất cho từng môi trường. Sau bất kỳ thay đổi nào đối với ứng dụng, hình ảnh vùng chứa phải được xây dựng lại và triển khai cho tất cả các môi trường được sử dụng. Nhân tiện, khi quản lý hệ thống CNTT, một nguyên tắc tương tự cũng được sử dụng, được gọi là nguyên tắc bất biến của máy chủ và cơ sở hạ tầng.
Mục tiêu của IIP là ngăn chặn việc tạo các hình ảnh vùng chứa riêng biệt cho các môi trường thời gian chạy khác nhau và sử dụng cùng một hình ảnh ở mọi nơi cùng với cấu hình dành riêng cho môi trường thích hợp. Việc tuân theo nguyên tắc này cho phép bạn triển khai các thực tiễn quan trọng như vậy từ quan điểm tự động hóa hệ thống đám mây như khôi phục và khôi phục các bản cập nhật ứng dụng.
Nguyên tắc xử lý quy trình (PDP)
Một trong những đặc điểm quan trọng nhất của vùng chứa là tính phù du của nó: một phiên bản của một vùng chứa rất dễ tạo và dễ phá hủy, do đó nó có thể dễ dàng thay thế bằng một phiên bản khác bất cứ lúc nào. Có thể có nhiều lý do cho việc thay thế như vậy: kiểm tra khả năng sử dụng không thành công, mở rộng quy mô ứng dụng, chuyển sang máy chủ khác, cạn kiệt tài nguyên nền tảng hoặc các tình huống khác.
Do đó, các ứng dụng được đóng gói phải duy trì trạng thái của chúng bằng cách sử dụng một số phương tiện bên ngoài hoặc sử dụng các sơ đồ phân tán nội bộ có tính dự phòng cho việc này. Ngoài ra, ứng dụng phải khởi động nhanh và tắt nhanh, đồng thời chuẩn bị cho trường hợp phần cứng bị lỗi nghiêm trọng đột ngột.
Một phương pháp giúp thực hiện nguyên tắc này là giữ các thùng chứa nhỏ. Môi trường đám mây có thể tự động chọn máy chủ để khởi chạy phiên bản vùng chứa, do đó, vùng chứa càng nhỏ thì khởi động càng nhanh - nó sẽ chỉ sao chép sang máy chủ đích qua mạng nhanh hơn.
Nguyên tắc tự ngăn chặn (S-CP)
Theo nguyên tắc này, ở giai đoạn lắp ráp, tất cả các bộ phận cần thiết đều được đưa vào thùng chứa. Vùng chứa phải được xây dựng dựa trên giả định rằng hệ thống chỉ có nhân Linux thuần túy, vì vậy tất cả các thư viện bổ sung cần thiết phải được đặt trong chính vùng chứa. Nó cũng phải chứa những thứ như thời gian chạy cho ngôn ngữ lập trình tương ứng, nền tảng ứng dụng (nếu cần) và các phần phụ thuộc khác sẽ được yêu cầu trong khi ứng dụng vùng chứa đang chạy.
Các ngoại lệ được tạo cho các cấu hình khác nhau tùy theo môi trường và phải được cung cấp trong thời gian chạy, chẳng hạn như thông qua Bản đồ cấu hình Kubernetes.
Một ứng dụng có thể bao gồm một số thành phần được chứa trong bộ chứa, ví dụ: một bộ chứa DBMS riêng biệt trong một ứng dụng web được chứa trong bộ chứa. Theo nguyên tắc S-CP, các bộ chứa này không nên được kết hợp thành một mà phải được làm sao cho bộ chứa DBMS chứa mọi thứ cần thiết cho hoạt động của cơ sở dữ liệu và bộ chứa ứng dụng web chứa mọi thứ cần thiết cho hoạt động của web. ứng dụng, cùng một máy chủ web. Kết quả là, trong thời gian chạy, bộ chứa ứng dụng web sẽ phụ thuộc vào bộ chứa DBMS và truy cập nó khi cần.
Nguyên tắc giam giữ thời gian chạy (RCP)
Nguyên tắc S-CP xác định cách xây dựng vùng chứa và nội dung nhị phân của hình ảnh nên chứa. Nhưng vùng chứa không chỉ là một “hộp đen” chỉ có một đặc điểm - kích thước tệp. Trong quá trình thực thi, vùng chứa sẽ có các kích thước khác: dung lượng bộ nhớ được sử dụng, thời gian CPU và các tài nguyên hệ thống khác.
Và ở đây, nguyên tắc RCP trở nên hữu ích, theo đó vùng chứa phải loại bỏ các yêu cầu về tài nguyên hệ thống và chuyển chúng sang nền tảng. Với cấu hình tài nguyên của mỗi bộ chứa (cần bao nhiêu tài nguyên CPU, bộ nhớ, mạng và ổ đĩa), nền tảng có thể thực hiện lập lịch và tự động điều chỉnh quy mô một cách tối ưu, quản lý dung lượng CNTT và duy trì mức SLA cho bộ chứa.
Ngoài việc đáp ứng các yêu cầu về tài nguyên của vùng chứa, điều quan trọng là ứng dụng không được vượt quá ranh giới của chính nó. Mặt khác, khi tình trạng thiếu tài nguyên xảy ra, nền tảng có nhiều khả năng sẽ đưa nó vào danh sách các ứng dụng cần chấm dứt hoặc di chuyển.
Khi nói về việc ưu tiên đám mây, chúng ta đang nói về cách chúng ta làm việc.
Ở trên, chúng tôi đã xây dựng một số nguyên tắc chung đặt nền tảng phương pháp luận để xây dựng các ứng dụng vùng chứa chất lượng cao cho môi trường đám mây.
Lưu ý rằng ngoài những nguyên tắc chung này, bạn cũng sẽ cần thêm các phương pháp và kỹ thuật nâng cao để làm việc với vùng chứa. Ngoài ra, chúng tôi có một số khuyến nghị ngắn gọn, cụ thể hơn và nên áp dụng (hoặc không áp dụng) tùy theo tình huống:
- Cố gắng giảm kích thước của hình ảnh: xóa các tệp tạm thời và không cài đặt các gói không cần thiết - kích thước vùng chứa càng nhỏ thì nó được tập hợp và sao chép sang máy chủ đích qua mạng càng nhanh.
- Tập trung vào ID người dùng tùy ý: không sử dụng lệnh sudo hoặc bất kỳ userid đặc biệt nào để khởi chạy vùng chứa của bạn.
- Đánh dấu các cổng quan trọng: Bạn có thể đặt số cổng trong thời gian chạy, nhưng tốt hơn là chỉ định chúng bằng lệnh EXPOSE - điều này sẽ giúp những người và chương trình khác sử dụng hình ảnh của bạn dễ dàng hơn.
- Lưu trữ dữ liệu liên tục trên các ổ đĩa: Dữ liệu còn lại sau khi vùng chứa bị phá hủy phải được ghi vào ổ đĩa.
- Viết siêu dữ liệu hình ảnh: thẻ, nhãn và chú thích giúp hình ảnh dễ sử dụng hơn - các nhà phát triển khác sẽ cảm ơn bạn.
- Đồng bộ hóa máy chủ và hình ảnh: Một số ứng dụng được đóng gói yêu cầu bộ chứa phải đồng bộ hóa với máy chủ trên một số thuộc tính nhất định, chẳng hạn như thời gian hoặc ID máy.
- Tóm lại, chúng tôi chia sẻ các mẫu và phương pháp hay nhất sẽ giúp bạn thực hiện hiệu quả hơn các nguyên tắc được liệt kê ở trên:
Ngày 11 tháng 11.00 lúc XNUMX
Bạn sẽ học được gì:
- Hệ điều hành Linux CoreOS của Red Hat Enterprise bất biến
- Lưới dịch vụ OpenShift
- Khung toán tử
- Khung Knative
Nguồn: www.habr.com