Đây là bài viết đầu tiên trong loạt bài viết về những thay đổi, cải tiến và bổ sung trong bản cập nhật nền tảng Red Hat OpenShift 4.0 sắp tới sẽ giúp bạn chuẩn bị cho việc chuyển đổi sang phiên bản mới.
Kể từ thời điểm cộng đồng Kubernetes non trẻ lần đầu tiên tập trung tại văn phòng Google ở Seattle vào mùa thu năm 2014, dự án Kubernetes đã được định sẵn để cách mạng hóa cách phát triển và triển khai phần mềm ngày nay. Đồng thời, các nhà cung cấp dịch vụ đám mây công cộng tiếp tục tích cực đầu tư vào việc phát triển cơ sở hạ tầng và dịch vụ, giúp việc làm việc với CNTT và tạo ra phần mềm trở nên dễ dàng và dễ tiếp cận hơn nhiều, đồng thời khiến chúng có giá cả phải chăng đến mức khó tin, điều mà ít ai có thể tưởng tượng được khi bắt đầu thập kỷ.
Tất nhiên, thông báo về mỗi dịch vụ đám mây mới đi kèm với nhiều cuộc thảo luận giữa các chuyên gia trên Twitter và các cuộc tranh luận đã được tiến hành về nhiều chủ đề khác nhau - bao gồm sự kết thúc của kỷ nguyên nguồn mở, sự suy giảm của CNTT tại chỗ và tính tất yếu của về sự độc quyền phần mềm mới, trên đám mây và cách mô hình X mới sẽ thay thế tất cả các mô hình khác.
Không cần phải nói, tất cả những tranh chấp này đều rất ngu ngốc.
Thực tế là sẽ không có gì biến mất và ngày nay chúng ta có thể thấy sự tăng trưởng theo cấp số nhân của các sản phẩm cuối cùng cũng như cách chúng được phát triển do sự xuất hiện liên tục của phần mềm mới trong cuộc sống của chúng ta. Và mặc dù thực tế là mọi thứ xung quanh sẽ thay đổi, nhưng về bản chất, mọi thứ sẽ không thay đổi. Các nhà phát triển phần mềm sẽ vẫn viết mã có lỗi, các kỹ sư vận hành và chuyên gia về độ tin cậy sẽ vẫn đi loanh quanh với máy nhắn tin và nhận thông báo tự động trong Slack, người quản lý vẫn sẽ hoạt động theo OpEx và CapEx, và mỗi khi xảy ra lỗi, nhà phát triển cấp cao sẽ thở dài buồn bã với câu nói: “Anh đã bảo rồi mà”…
Ồ vậy ư nên được thảo luận, là những công cụ mà chúng ta có thể sử dụng để tạo ra các sản phẩm phần mềm tốt hơn cũng như cách chúng có thể cải thiện tính bảo mật và giúp việc phát triển trở nên dễ dàng và đáng tin cậy hơn. Khi các dự án trở nên phức tạp hơn, những rủi ro mới nảy sinh và cuộc sống ngày nay của mọi người phụ thuộc quá nhiều vào phần mềm đến mức các nhà phát triển chỉ cần cố gắng thực hiện công việc của mình tốt hơn.
Kubernetes là một trong những công cụ như vậy. Công việc đang được tiến hành để kết hợp Red Hat OpenShift với các công cụ và dịch vụ khác thành một nền tảng duy nhất giúp phần mềm trở nên đáng tin cậy hơn, dễ quản lý hơn và an toàn hơn cho người dùng.
Như đã nói, nhóm OpenShift hỏi một câu hỏi đơn giản:
Làm cách nào để bạn có thể làm việc với Kubernetes dễ dàng và thuận tiện hơn?
Câu trả lời rõ ràng một cách đáng ngạc nhiên:
- tự động hóa các khía cạnh phức tạp của việc triển khai trên đám mây hoặc bên ngoài đám mây;
- tập trung vào độ tin cậy trong khi che giấu sự phức tạp;
- tiếp tục làm việc liên tục để phát hành các bản cập nhật đơn giản và an toàn;
- đạt được khả năng kiểm soát và kiểm toán;
- cố gắng ban đầu để đảm bảo tính bảo mật cao, nhưng không ảnh hưởng đến khả năng sử dụng.
Bản phát hành tiếp theo của OpenShift phải tính đến cả trải nghiệm của người sáng tạo và trải nghiệm của các nhà phát triển khác đang triển khai phần mềm trên quy mô lớn tại các công ty lớn nhất thế giới. Ngoài ra, nó phải tính đến tất cả kinh nghiệm tích lũy của các hệ sinh thái mở làm nền tảng cho thế giới hiện đại ngày nay. Đồng thời, cần phải từ bỏ tâm lý trước đây của nhà phát triển nghiệp dư và chuyển sang triết lý mới về tương lai tự động hóa. Nó cần thu hẹp khoảng cách giữa cách triển khai phần mềm cũ và mới, đồng thời tận dụng tối đa tất cả cơ sở hạ tầng sẵn có—cho dù cơ sở hạ tầng đó được lưu trữ bởi nhà cung cấp đám mây lớn nhất hay chạy trên các hệ thống nhỏ ở biên.
Làm thế nào để đạt được kết quả này?
Tại Red Hat, người ta thường làm những công việc nhàm chán và bạc bẽo trong thời gian dài để bảo vệ cộng đồng đã thành lập và ngăn chặn việc đóng cửa các dự án mà công ty tham gia. Cộng đồng nguồn mở chứa một số lượng lớn các nhà phát triển tài năng, những người tạo ra những điều phi thường nhất - giải trí, giáo dục, mở ra những cơ hội mới và đơn giản là đẹp đẽ, nhưng tất nhiên, không ai mong đợi tất cả những người tham gia sẽ đi theo cùng một hướng hoặc theo đuổi mục tiêu chung. bàn thắng. Khai thác năng lượng này và chuyển hướng nó theo đúng hướng đôi khi là cần thiết để phát triển các lĩnh vực có lợi cho người dùng, nhưng đồng thời chúng ta phải theo dõi sự phát triển của cộng đồng và học hỏi từ họ.
Vào đầu năm 2018, Red Hat đã mua lại dự án CoreOS, dự án có quan điểm tương tự về tương lai - an toàn và đáng tin cậy hơn, được tạo ra trên nguyên tắc nguồn mở. Công ty đã nỗ lực phát triển hơn nữa những ý tưởng này và triển khai chúng, áp dụng triết lý của chúng tôi vào thực tế - cố gắng đảm bảo rằng tất cả phần mềm đều chạy an toàn. Tất cả công việc này được xây dựng trên Kubernetes, Linux, đám mây công cộng, đám mây riêng và hàng nghìn dự án khác làm nền tảng cho hệ sinh thái kỹ thuật số hiện đại của chúng tôi.
Bản phát hành mới của OpenShift 4 sẽ rõ ràng, tự động và tự nhiên hơn
Nền tảng OpenShift sẽ hoạt động với các hệ điều hành Linux tốt nhất và đáng tin cậy nhất, với sự hỗ trợ phần cứng cơ bản, ảo hóa thuận tiện, lập trình cơ sở hạ tầng tự động và tất nhiên là các thùng chứa (về cơ bản chỉ là hình ảnh Linux).
Nền tảng phải được bảo mật ngay từ đầu nhưng vẫn cho phép các nhà phát triển dễ dàng lặp lại—nghĩa là phải đủ linh hoạt và bảo mật trong khi vẫn cho phép quản trị viên kiểm tra và quản lý nó một cách dễ dàng.
Nó phải cho phép phần mềm được chạy “như một dịch vụ” và không dẫn đến sự phát triển cơ sở hạ tầng không thể quản lý được đối với các nhà khai thác.
Nó sẽ cho phép các nhà phát triển tập trung vào việc tạo ra các sản phẩm thực sự cho người dùng và khách hàng. Bạn sẽ không phải loay hoay trong rừng cài đặt phần cứng và phần mềm, đồng thời mọi biến chứng vô tình sẽ chỉ còn là quá khứ.
OpenShift 4: Nền tảng NoOps không cần bảo trì
В đã mô tả những nhiệm vụ đã giúp định hình tầm nhìn của công ty về OpenShift 4. Mục tiêu của nhóm là đơn giản hóa các nhiệm vụ hàng ngày về vận hành và bảo trì phần mềm nhiều nhất có thể, giúp các quy trình này trở nên dễ dàng và thoải mái - cho cả các chuyên gia tham gia triển khai và nhà phát triển. Nhưng làm thế nào bạn có thể tiến gần hơn đến mục tiêu này? Làm cách nào để tạo một nền tảng chạy phần mềm cần ít sự can thiệp nhất? NoOps thậm chí còn có ý nghĩa gì trong bối cảnh này?
Nếu bạn cố gắng trừu tượng hóa, thì đối với các nhà phát triển, khái niệm “không có máy chủ” hoặc “NoOps” có nghĩa là các công cụ và dịch vụ cho phép bạn ẩn thành phần “vận hành” hoặc giảm thiểu gánh nặng này cho nhà phát triển.
- Làm việc không phải với hệ thống mà với giao diện ứng dụng (API).
- Đừng bận tâm đến việc triển khai phần mềm - hãy để nhà cung cấp làm việc đó cho bạn.
- Đừng lao vào việc tạo một khung lớn ngay lập tức - hãy bắt đầu bằng cách viết các phần nhỏ sẽ đóng vai trò như "khối xây dựng", cố gắng làm cho mã này hoạt động với dữ liệu và sự kiện chứ không phải với đĩa và cơ sở dữ liệu.
Mục tiêu, như trước đây, là tăng tốc độ lặp lại trong quá trình phát triển phần mềm, tạo cơ hội tạo ra các sản phẩm tốt hơn và để nhà phát triển không phải lo lắng về hệ thống mà phần mềm của mình chạy trên đó. Một nhà phát triển có kinh nghiệm nhận thức rõ rằng việc tập trung vào người dùng có thể nhanh chóng thay đổi bức tranh, vì vậy bạn không nên nỗ lực quá nhiều vào việc viết phần mềm trừ khi bạn hoàn toàn chắc chắn rằng nó cần thiết.
Đối với các chuyên gia vận hành và bảo trì, từ “NoOps” nghe có vẻ hơi đáng sợ. Nhưng khi giao tiếp với các kỹ sư hiện trường, rõ ràng là các mô hình và kỹ thuật họ sử dụng nhằm đảm bảo độ tin cậy và độ tin cậy (Site Reliability Engineering, SRE) có nhiều điểm tương đồng với các mô hình được mô tả ở trên:
- Đừng quản lý hệ thống - hãy tự động hóa quy trình quản lý của chúng.
- Không triển khai phần mềm - hãy tạo quy trình để triển khai phần mềm.
- Tránh kết hợp tất cả các dịch vụ của bạn lại với nhau và để lỗi của một dịch vụ khiến toàn bộ hệ thống bị lỗi—phân tán chúng trên toàn bộ cơ sở hạ tầng của bạn bằng các công cụ tự động hóa và kết nối chúng theo cách được giám sát và giám sát.
SRE biết rằng có thể xảy ra sự cố và họ sẽ phải theo dõi cũng như khắc phục sự cố—vì vậy, họ tự động hóa công việc thường ngày và đặt trước ngân sách lỗi để sẵn sàng ưu tiên và đưa ra quyết định khi có sự cố phát sinh. .
Kubernetes trong OpenShift là một nền tảng được thiết kế để giải quyết hai vấn đề chính: thay vì buộc bạn phải hiểu máy ảo hoặc API cân bằng tải, nó hoạt động với các khái niệm trừu tượng bậc cao hơn - các quy trình và dịch vụ triển khai. Thay vì cài đặt các tác nhân phần mềm, bạn có thể chạy các bộ chứa và thay vì viết ngăn xếp giám sát của riêng mình, hãy sử dụng các công cụ đã có sẵn trong nền tảng. Vì vậy, bí quyết của OpenShift 4 thực sự không có gì bí mật - đó chỉ là vấn đề áp dụng các nguyên tắc SRE và khái niệm serverless rồi đưa chúng đi đến kết luận hợp lý nhằm giúp các nhà phát triển và kỹ sư vận hành:
- Tự động hóa và chuẩn hóa cơ sở hạ tầng mà các ứng dụng sử dụng
- Liên kết các quá trình triển khai và phát triển với nhau mà không hạn chế chính các nhà phát triển
- Việc đảm bảo rằng việc khởi chạy, kiểm tra và bảo mật dịch vụ, tính năng, ứng dụng hoặc toàn bộ ngăn xếp thứ XNUMX không khó khăn hơn dịch vụ, tính năng, ứng dụng thứ XNUMX.
Nhưng sự khác biệt giữa nền tảng OpenShift 4 với các nền tảng tiền nhiệm của nó và so với cách tiếp cận “tiêu chuẩn” để giải quyết những vấn đề như vậy là gì? Điều gì thúc đẩy quy mô cho các nhóm triển khai và vận hành? Bởi vì vua trong tình huống này là cụm. Vì thế,
- Chúng tôi đảm bảo rằng mục đích của các cụm là rõ ràng (Mây thân mến, tôi đã chọn cụm này vì tôi có thể)
- Máy móc và hệ điều hành tồn tại để phục vụ cụm (Tâu bệ hạ)
- Quản lý trạng thái của các máy chủ từ cụm, giảm thiểu việc xây dựng lại (trôi dạt) của chúng.
- Đối với mỗi thành phần quan trọng của hệ thống, cần có một bảo mẫu (cơ chế) để giám sát và loại bỏ các vấn đề
- Lỗi *mọi* khía cạnh hoặc thành phần của hệ thống và các cơ chế phục hồi liên quan là một phần bình thường của cuộc sống
- Toàn bộ cơ sở hạ tầng phải được cấu hình thông qua API.
- Sử dụng Kubernetes để chạy Kubernetes. (Vâng, vâng, đó không phải là lỗi đánh máy)
- Các bản cập nhật phải dễ dàng và không gặp rắc rối khi cài đặt. Nếu phải mất nhiều lần nhấp chuột để cài đặt bản cập nhật thì rõ ràng là chúng tôi đã làm sai điều gì đó.
- Việc giám sát và gỡ lỗi bất kỳ thành phần nào không phải là vấn đề và do đó việc theo dõi và báo cáo trên toàn bộ cơ sở hạ tầng cũng phải dễ dàng và thuận tiện.
Bạn muốn xem khả năng hoạt động của nền tảng?
Phiên bản xem trước của OpenShift 4 đã có sẵn cho các nhà phát triển. Với trình cài đặt dễ sử dụng, bạn có thể chạy một cụm trên AWS trên Red Had CoreOS. Để sử dụng bản xem trước, bạn chỉ cần có tài khoản AWS để cung cấp cơ sở hạ tầng và một bộ tài khoản để truy cập vào hình ảnh xem trước.
- Để bắt đầu, hãy truy cập và nhấp vào “Bắt đầu”.
- Đăng nhập vào tài khoản Red Hat của bạn (hoặc tạo tài khoản mới) và làm theo hướng dẫn để thiết lập cụm đầu tiên của bạn.
Sau khi cài đặt thành công, hãy xem hướng dẫn của chúng tôi để hiểu sâu hơn về các hệ thống và khái niệm giúp nền tảng OpenShift 4 trở thành một cách dễ dàng và thuận tiện để chạy Kubernetes.
Hãy thử bản phát hành OpenShift mới và chia sẻ ý kiến của bạn. Chúng tôi cam kết làm cho việc làm việc với Kumbernetes trở nên dễ tiếp cận và dễ dàng nhất có thể—tương lai của NoOps bắt đầu từ hôm nay.
Và bây giờ chú ý!
Tại hội nghị Vào ngày 20 tháng 37, một trong những nhà phát triển OpenShift, Vadim Rutkovsky, sẽ tổ chức một lớp học chính - anh ấy sẽ phá vỡ mười cụm và buộc họ phải sửa chúng. Hội nghị được thanh toán nhưng với mã khuyến mại #RedHat bạn được giảm giá XNUMX%
Lớp Master lúc 17h15 - 18h15, gian hàng mở cửa cả ngày. Áo phông, mũ, nhãn dán - những điều bình thường!
Hội trường số 2
“Ở đây, toàn bộ hệ thống cần được thay đổi: chúng tôi sửa chữa các cụm k8 bị hỏng cùng với các thợ máy đã được chứng nhận.”
Nguồn: www.habr.com