Bài đăng này được viết vì nhân viên của chúng tôi đã có khá nhiều cuộc trò chuyện với khách hàng về việc phát triển ứng dụng trên Kubernetes và các chi tiết cụ thể của sự phát triển đó trên OpenShift.
Chúng tôi thường bắt đầu với luận điểm rằng Kubernetes chỉ là Kubernetes và OpenShift đã là một nền tảng Kubernetes, giống như Microsoft AKS hoặc Amazon EKS. Mỗi nền tảng này đều có những ưu điểm riêng, tập trung vào một đối tượng mục tiêu cụ thể. Và sau đó, cuộc trò chuyện chuyển sang phần so sánh điểm mạnh và điểm yếu của các nền tảng cụ thể.
Nói chung, chúng tôi đã nghĩ đến việc viết bài đăng này với đầu ra như “Nghe này, bạn chạy mã ở đâu không quan trọng, trên OpenShift hay trên AKS, trên EKS, trên một số Kubernetes tùy chỉnh, vâng trên bất kỳ Kubernetes nào (hãy gọi tắt là KUK) “Nó thực sự đơn giản, cả ở đó và ở đó.”
Sau đó, chúng tôi dự định sử dụng "Xin chào thế giới" đơn giản nhất và sử dụng nó để chỉ ra điểm chung và điểm khác biệt giữa CMC và Nền tảng bộ chứa OpenShift của Red Hat (sau đây gọi là OCP hoặc đơn giản là OpenShift).
Tuy nhiên, trong quá trình viết bài đăng này, chúng tôi nhận ra rằng chúng tôi đã quá quen với việc sử dụng OpenShift đến mức đơn giản là chúng tôi không nhận ra nó đã phát triển và biến thành một nền tảng tuyệt vời như thế nào, không chỉ là một bản phân phối Kubernetes. Chúng ta có xu hướng coi sự trưởng thành và đơn giản của OpenShift là điều hiển nhiên, trong khi bỏ qua vẻ đẹp lộng lẫy của nó.
Nói chung, đã đến lúc phải tích cực ăn năn và bây giờ chúng tôi sẽ từng bước so sánh việc vận hành “Xin chào thế giới” của chúng tôi trên KUK và trên OpenShift, đồng thời chúng tôi sẽ thực hiện điều đó một cách khách quan nhất có thể (tốt, đôi khi có thể thể hiện quan điểm cá nhân thái độ với đối tượng). Nếu bạn quan tâm đến ý kiến hoàn toàn chủ quan về vấn đề này, thì bạn có thể đọc nó . Và trong bài đăng này, chúng tôi sẽ bám vào sự thật và chỉ sự thật.
Cụm
Vì vậy, "Xin chào thế giới" của chúng tôi cần các cụm. Hãy nói "không" với bất kỳ đám mây công cộng nào, để không phải trả tiền cho máy chủ, cơ quan đăng ký, mạng, truyền dữ liệu, v.v. Theo đó, chúng tôi chọn cụm một nút đơn giản trên (đối với KUK) và (đối với cụm OpenShift). Cả hai tùy chọn này đều thực sự dễ cài đặt, nhưng yêu cầu khá nhiều tài nguyên trên máy tính xách tay của bạn.
Lắp ráp trên KUK-e
Vậy hãy đi đi.
Bước 1 - Xây dựng hình ảnh vùng chứa của chúng tôi
Hãy bắt đầu bằng cách triển khai "Xin chào thế giới" của chúng tôi cho minikube. Điều này sẽ yêu cầu:
- 1. Đã cài đặt Docker.
- 2. Đã cài đặt Git.
- 3. Đã cài đặt Maven (thực ra, dự án này sử dụng tệp nhị phân mvnw, vì vậy bạn có thể thực hiện mà không cần nó).
- 4. Trên thực tế, nguồn chính nó, tức là. bản sao kho lưu trữ
Bước đầu tiên là tạo một dự án Quarkus. Đừng sợ nếu bạn chưa bao giờ sử dụng Quarkus.io - thật dễ dàng. Bạn chỉ cần chọn các thành phần bạn muốn sử dụng trong dự án (RestPal, Hibernate, Amazon SQS, Camel, v.v.), sau đó, chính Quarkus, không có sự tham gia của bạn, thiết lập nguyên mẫu maven và đưa mọi thứ lên github. Nghĩa là, chỉ cần một cú nhấp chuột - và bạn đã hoàn thành. Đây là lý do tại sao chúng tôi yêu Quarkus.
Cách dễ nhất để xây dựng "Xin chào thế giới" của chúng tôi thành một hình ảnh được chứa trong vùng chứa là sử dụng tiện ích mở rộng quarkus-maven cho Docker, phần mở rộng này sẽ thực hiện tất cả các công việc cần thiết. Với sự ra đời của Quarkus, điều này đã trở nên thực sự dễ dàng và đơn giản: thêm tiện ích mở rộng container-image-docker và bạn có thể tạo hình ảnh bằng các lệnh maven.
./mvnw quarkus:add-extension -Dextensions=”container-image-docker”
Và cuối cùng, chúng tôi xây dựng hình ảnh của mình bằng Maven. Do đó, mã nguồn của chúng tôi chuyển thành hình ảnh vùng chứa được tạo sẵn, có thể chạy được trong thời gian chạy vùng chứa.
./mvnw -X clean package -Dquarkus.container-image.build=true
Trên thực tế, đó là tất cả, bây giờ bạn có thể chạy vùng chứa bằng lệnh docker run, sau khi đã ánh xạ dịch vụ của chúng tôi tới cổng 8080 để có thể truy cập được.
docker run -i — rm -p 8080:8080 gcolman/quarkus-hello-world
Sau khi phiên bản bộ chứa đã bắt đầu, tất cả những gì còn lại là kiểm tra bằng lệnh curl xem dịch vụ của chúng ta có đang chạy hay không:
Vì vậy, mọi thứ hoạt động, và nó thực sự dễ dàng và đơn giản.
Bước 2 - Gửi vùng chứa của chúng tôi đến kho lưu trữ hình ảnh vùng chứa
Hiện tại, hình ảnh chúng tôi đã tạo được lưu trữ cục bộ trong bộ lưu trữ vùng chứa cục bộ của chúng tôi. Nếu chúng tôi muốn sử dụng hình ảnh này trong môi trường KUK của mình, thì chúng tôi cần đặt nó vào một số kho lưu trữ khác. Kubernetes không có các tính năng này, vì vậy chúng tôi sẽ sử dụng dockerhub. Bởi vì, thứ nhất, nó miễn phí và thứ hai, (hầu hết) mọi người đều làm điều đó.
Việc này cũng rất đơn giản, ở đây chỉ cần có tài khoản dockerhub.
Vì vậy, chúng tôi cài đặt dockerhub và gửi hình ảnh của chúng tôi đến đó.
Bước 3 - Bắt đầu Kubernetes
Có nhiều cách để kết hợp cấu hình kubernetes để chạy "Xin chào thế giới" của chúng tôi, nhưng chúng tôi sẽ sử dụng cách đơn giản nhất trong số chúng, bởi vì chúng tôi là những người như vậy ...
Đầu tiên, chúng tôi bắt đầu cụm minikube:
minikube start
Bước 4 - Triển khai hình ảnh vùng chứa của chúng tôi
Bây giờ chúng ta cần chuyển đổi mã và hình ảnh vùng chứa sang cấu hình kubernetes. Nói cách khác, chúng ta cần một nhóm và định nghĩa triển khai trỏ đến hình ảnh bộ chứa của chúng ta trên dockerhub. Một trong những cách dễ nhất để làm điều này là chạy lệnh tạo triển khai chỉ vào hình ảnh của chúng tôi:
kubectl create deployment hello-quarkus — image =gcolman/quarkus-hello-world:1.0.0-SNAPSHOT
Với lệnh này, chúng tôi đã yêu cầu COOK của mình tạo cấu hình triển khai, cấu hình này sẽ chứa thông số kỹ thuật nhóm cho hình ảnh bộ chứa của chúng tôi. Lệnh này cũng sẽ áp dụng cấu hình này cho cụm minikube của chúng tôi và tạo một triển khai sẽ tải xuống hình ảnh bộ chứa của chúng tôi và chạy một nhóm trên cụm.
Bước 5 - mở quyền truy cập vào dịch vụ của chúng tôi
Bây giờ chúng ta đã có một hình ảnh bộ chứa được triển khai, đã đến lúc nghĩ về cách định cấu hình quyền truy cập bên ngoài vào dịch vụ Restful này, trên thực tế, dịch vụ này được lập trình trong mã của chúng ta.
Có nhiều cách ở đây. Ví dụ: bạn có thể sử dụng lệnh Exposure để tự động tạo các thành phần Kubernetes thích hợp, chẳng hạn như dịch vụ và điểm cuối. Trên thực tế, đây là những gì chúng ta sẽ làm bằng cách thực hiện lệnh Exposure cho đối tượng triển khai của mình:
kubectl expose deployment hello-quarkus — type=NodePort — port=8080
Hãy tập trung vào tùy chọn "-type" của lệnh Exposure trong giây lát.
Khi chúng tôi hiển thị và tạo các thành phần cần thiết để chạy dịch vụ của mình, ngoài những thứ khác, chúng tôi cần có khả năng kết nối từ bên ngoài với dịch vụ hello-quarkus nằm trong mạng do phần mềm xác định của chúng tôi. Và tham số kiểu cho phép chúng tôi tạo và kết nối những thứ như bộ cân bằng tải để định tuyến lưu lượng truy cập đến mạng đó.
Ví dụ, viết loại=LoadBalancer, chúng tôi sẽ tự động khởi tạo bộ cân bằng tải trên đám mây công cộng để kết nối với cụm Kubernetes của chúng tôi. Tất nhiên, điều này thật tuyệt, nhưng bạn cần hiểu rằng cấu hình như vậy sẽ được liên kết chặt chẽ với một đám mây công cộng cụ thể và sẽ khó chuyển nó giữa các phiên bản Kubernetes trong các môi trường khác nhau.
trong ví dụ của chúng tôi loại = NodePort, nghĩa là, cuộc gọi đến dịch vụ của chúng tôi đi theo địa chỉ IP của nút và số cổng. Tùy chọn này cho phép bạn không sử dụng bất kỳ đám mây công cộng nào, nhưng yêu cầu một số bước bổ sung. Trước tiên, bạn cần có bộ cân bằng tải của riêng mình, vì vậy chúng tôi sẽ triển khai bộ cân bằng tải NGINX trong cụm của chúng tôi.
Bước 6 - Thiết lập bộ cân bằng tải
minikube có một số tính năng nền tảng giúp dễ dàng tạo các thành phần bạn cần để truy cập bên ngoài, chẳng hạn như bộ điều khiển xâm nhập. Minikube đi kèm với bộ điều khiển xâm nhập Nginx và tất cả những gì chúng ta phải làm là kích hoạt và định cấu hình nó.
minikube addons enable ingress
Bây giờ, chỉ với một lệnh, chúng ta sẽ tạo một bộ điều khiển xâm nhập Nginx sẽ hoạt động bên trong cụm minikube của chúng ta:
ingress-nginx-controller-69ccf5d9d8-j5gs9 1/1 Running 1 33m
Bước 7 - Thiết lập đường vào
Bây giờ chúng ta cần định cấu hình bộ điều khiển xâm nhập Nginx để chấp nhận các yêu cầu hello-quarkus.
Và cuối cùng, chúng ta cần áp dụng cấu hình này.
kubectl apply -f ingress.yml
Vì chúng tôi đang thực hiện tất cả những điều này trên máy của mình, nên chúng tôi chỉ cần thêm địa chỉ IP của nút vào tệp /etc/hosts để chuyển các yêu cầu http tới minikube của chúng tôi tới bộ cân bằng tải NGINX.
192.168.99.100 hello-quarkus.info
Vậy là xong, bây giờ dịch vụ minikube của chúng ta đã có sẵn từ bên ngoài thông qua bộ điều khiển xâm nhập Nginx.
Vâng, đó là dễ dàng, phải không? Hay không quá nhiều?
Chạy trên OpenShift (Bộ chứa mã sẵn sàng)
Và bây giờ, hãy xem tất cả được thực hiện như thế nào trên Nền tảng bộ chứa OpenShift (OCP) của Red Hat.
Như trong trường hợp của minikube, chúng tôi chọn sơ đồ có cụm OpenShift một nút ở dạng Bộ chứa mã sẵn sàng (CRC). Nó từng được gọi là minishift và dựa trên dự án OpenShift Origin, nhưng giờ nó là CRC và được xây dựng trên Nền tảng bộ chứa OpenShift của Red Hat.
Đến đây, xin lỗi, chúng tôi không thể không thốt lên: "OpenShift thật tuyệt!"
Ban đầu, chúng tôi nghĩ viết rằng quá trình phát triển trên OpenShift không khác gì quá trình phát triển trên Kubernetes. Và trên thực tế, nó là như vậy. Nhưng trong quá trình viết bài đăng này, chúng tôi đã nhớ rằng bạn phải thực hiện bao nhiêu chuyển động không cần thiết khi không có OpenShift, và do đó, một lần nữa, nó rất đẹp. Chúng tôi thích mọi thứ trở nên dễ dàng và việc triển khai cũng như chạy ví dụ của chúng tôi trên OpenShift dễ dàng như thế nào so với minikube là điều đã truyền cảm hứng cho chúng tôi viết bài đăng này.
Hãy chạy qua quá trình và xem những gì chúng ta cần làm.
Vì vậy, trong ví dụ về minikube, chúng tôi đã bắt đầu với Docker… Đợi đã, chúng tôi không cần cài đặt Docker trên máy nữa.
Và chúng tôi không cần một git địa phương.
Và Maven là không cần thiết.
Và bạn không cần phải tạo hình ảnh vùng chứa bằng tay.
Và bạn không cần phải tìm kiếm bất kỳ kho lưu trữ hình ảnh vùng chứa nào.
Và bạn không cần cài đặt bộ điều khiển xâm nhập.
Và bạn cũng không cần cấu hình xâm nhập.
Bạn hiểu không? Để triển khai và chạy ứng dụng của chúng tôi trên OpenShift, không cần điều nào ở trên. Và bản thân quá trình này như sau.
Bước 1 – Bắt đầu cụm OpenShift của bạn
Chúng tôi sử dụng Bộ chứa mã sẵn sàng từ Red Hat, về cơ bản giống như Minikube, nhưng chỉ với cụm Openshift một nút đầy đủ.
crc start
Bước 2 - Xây dựng và Triển khai Ứng dụng cho Cụm OpenShift
Chính tại bước này, sự đơn giản và tiện lợi của OpenShift thể hiện ở tất cả vinh quang của nó. Như với tất cả các bản phân phối Kubernetes, chúng ta có nhiều cách để chạy một ứng dụng trên một cụm. Và, như trong trường hợp của KUK, chúng tôi đặc biệt chọn cái đơn giản nhất.
OpenShift luôn được xây dựng như một nền tảng để xây dựng và chạy các ứng dụng được đóng gói. Xây dựng các thùng chứa luôn là một phần không thể thiếu của nền tảng này, do đó, có rất nhiều tài nguyên Kubernetes bổ sung cho các nhiệm vụ tương ứng.
Chúng tôi sẽ sử dụng quy trình Hình ảnh nguồn 2 (S2I) của OpenShift, quy trình này có một số cách khác nhau để lấy nguồn (mã hoặc tệp nhị phân) của chúng tôi và biến nó thành hình ảnh được chứa chạy trên cụm OpenShift.
Đối với điều này, chúng ta cần hai điều:
- Mã nguồn của chúng tôi trong kho git
- Builder-image, dựa vào đó việc lắp ráp sẽ được thực hiện.
Có rất nhiều hình ảnh như vậy, được duy trì bởi cả Red Hat và cộng đồng, và chúng tôi sẽ sử dụng hình ảnh OpenJDK, vì tôi đang xây dựng một ứng dụng Java.
Bạn có thể chạy bản dựng S2I từ cả bảng điều khiển đồ họa dành cho Nhà phát triển OpenShift và từ dòng lệnh. Chúng tôi sẽ sử dụng lệnh ứng dụng mới, cho biết nơi lấy hình ảnh trình tạo và mã nguồn của chúng tôi.
oc new-app registry.access.redhat.com/ubi8/openjdk-11:latest~https://github.com/gcolman/quarkus-hello-world.git
Vậy là xong, ứng dụng của chúng ta đã được tạo. Khi làm như vậy, quy trình S2I đã thực hiện những việc sau:
- Đã tạo nhóm xây dựng dịch vụ cho tất cả những thứ liên quan đến việc xây dựng ứng dụng.
- Đã tạo cấu hình OpenShift Build.
- Tôi đã tải hình ảnh trình xây dựng xuống sổ đăng ký docker OpenShift nội bộ.
- Đã sao chép "Hello World" vào kho lưu trữ cục bộ.
- Thấy có một maven pom trong đó và vì vậy đã biên dịch ứng dụng với maven.
- Đã tạo một hình ảnh vùng chứa mới chứa ứng dụng Java đã biên dịch và đưa hình ảnh này vào sổ đăng ký vùng chứa nội bộ.
- Đã tạo Triển khai Kubernetes với thông số kỹ thuật cho nhóm, dịch vụ, v.v.
- Đã khởi chạy hình ảnh vùng chứa triển khai.
- Đã xóa nhóm xây dựng dịch vụ.
Có rất nhiều trong danh sách này, nhưng điều quan trọng chính là toàn bộ quá trình xây dựng chỉ diễn ra bên trong OpenShift, sổ đăng ký Docker nội bộ nằm trong OpenShift và quá trình xây dựng tạo ra tất cả các thành phần Kubernetes và chạy chúng trên cụm.
Nếu bạn theo dõi trực quan quá trình khởi chạy S2I trong bảng điều khiển, bạn có thể thấy cách nhóm xây dựng được khởi chạy trong quá trình xây dựng.
Và bây giờ, hãy xem nhật ký của nhóm trình tạo: trước tiên, ở đó bạn có thể thấy cách maven thực hiện công việc của nó và tải xuống các phụ thuộc để xây dựng ứng dụng java của chúng ta.
Sau khi quá trình xây dựng maven hoàn tất, quá trình xây dựng hình ảnh vùng chứa được bắt đầu và sau đó hình ảnh đã xây dựng này được gửi đến kho lưu trữ nội bộ.
Mọi thứ, quá trình lắp ráp đã hoàn tất. Bây giờ, hãy đảm bảo rằng các nhóm và dịch vụ của ứng dụng của chúng tôi đã bắt đầu trong cụm.
oc get service
Đó là tất cả. Và chỉ có một đội. Tất cả những gì chúng ta phải làm là hiển thị dịch vụ này để truy cập từ bên ngoài.
Bước 3 - làm cho dịch vụ hiển thị để truy cập từ bên ngoài
Như trong trường hợp của KUK, trên nền tảng OpenShift, “Hello World” của chúng tôi cũng cần một bộ định tuyến để hướng lưu lượng truy cập bên ngoài đến một dịch vụ bên trong cụm. Trong OpenShift, điều này trở nên rất dễ dàng. Đầu tiên, thành phần định tuyến HAProxy được cài đặt trong cụm theo mặc định (có thể thay đổi thành NGINX tương tự). Thứ hai, có các tài nguyên đặc biệt và có khả năng định cấu hình cao được gọi là Tuyến đường, gợi nhớ đến các đối tượng Ingress trong Kubernetes cũ (trên thực tế, Routes của OpenShift ảnh hưởng lớn đến thiết kế của các đối tượng Ingress, hiện có thể được sử dụng trong OpenShift), nhưng đối với "Xin chào" của chúng tôi World", và trong hầu hết các trường hợp khác, Tuyến tiêu chuẩn là đủ cho chúng tôi mà không cần cấu hình bổ sung.
Để tạo FQDN có thể định tuyến cho “Xin chào thế giới” (vâng, OpenShiift có DNS riêng để định tuyến theo tên dịch vụ), chúng tôi chỉ cần hiển thị dịch vụ của mình:
oc expose service quarkus-hello-world
Nếu bạn nhìn vào Tuyến đường mới được tạo, thì bạn có thể tìm thấy FQDN và thông tin định tuyến khác ở đó:
oc get route
Và cuối cùng, chúng tôi truy cập dịch vụ của mình từ trình duyệt:
Nhưng bây giờ nó đã thực sự dễ dàng!
Chúng tôi yêu thích Kubernetes và mọi thứ mà công nghệ này cho phép bạn làm, đồng thời chúng tôi cũng yêu thích sự đơn giản và nhẹ nhàng. Kubernetes được thiết kế để làm cho các thùng chứa phân tán, có khả năng mở rộng cực kỳ dễ vận hành, nhưng sự đơn giản của nó không còn đủ để đưa các ứng dụng vào sản xuất ngày nay. Và đây là lúc OpenShift phát huy tác dụng, theo kịp thời đại và cung cấp Kubernetes, chủ yếu tập trung vào nhà phát triển. Rất nhiều nỗ lực đã được đầu tư để điều chỉnh nền tảng OpenShift dành riêng cho nhà phát triển, bao gồm việc tạo các công cụ như S2I, ODI, Cổng thông tin dành cho nhà phát triển, Khung điều hành OpenShift, tích hợp IDE, Danh mục nhà phát triển, tích hợp Helm, giám sát và nhiều công cụ khác.
Chúng tôi hy vọng rằng bài viết này là thú vị và hữu ích cho bạn. Và bạn có thể tìm thấy các tài nguyên, tài liệu bổ sung và những thứ khác hữu ích để phát triển trên nền tảng OpenShift trên cổng thông tin .
Nguồn: www.habr.com