ბოდიშს გიხდით, OpenShift, ჩვენ საკმარისად არ დაგიფასეთ და თავისთავად მიგიღეთ

ეს პოსტი დაიწერა იმიტომ, რომ ჩვენს თანამშრომლებს ჰქონდათ საკმაოდ ბევრი საუბარი კლიენტებთან Kubernetes-ზე აპლიკაციების შემუშავებისა და OpenShift-ზე ასეთი განვითარების სპეციფიკის შესახებ.

ჩვენ ჩვეულებრივ ვიწყებთ თეზისით, რომ Kubernetes არის მხოლოდ Kubernetes, და OpenShift უკვე არის Kubernetes პლატფორმა, როგორიცაა Microsoft AKS ან Amazon EKS. თითოეულ ამ პლატფორმას აქვს თავისი უპირატესობა, რომელიც ორიენტირებულია კონკრეტულ სამიზნე აუდიტორიაზე. და ამის შემდეგ, საუბარი უკვე მიედინება კონკრეტული პლატფორმების ძლიერი და სუსტი მხარეების შედარებაში.

ზოგადად, ჩვენ გვგონია დამეწერა ეს პოსტი ისეთი გამომავალით, როგორიცაა „მისმინე, არ აქვს მნიშვნელობა სად გაუშვით კოდი, OpenShift-ზე თუ AKS-ზე, EKS-ზე, ზოგიერთ მორგებულ Kubernetes-ზე, დიახ ნებისმიერ Kubernetes-ზე. (მოდით დავარქვათ მას KUK მოკლედ) ”ეს მართლაც მარტივია, როგორც იქ, ასევე იქ.”

შემდეგ ჩვენ დავგეგმეთ ავიღოთ უმარტივესი "Hello World" და გამოგვეყენებინა, რა არის საერთო და რა განსხვავებებია CMC-სა და Red Hat OpenShift კონტეინერის პლატფორმას შორის (შემდგომში OCP ან უბრალოდ OpenShift).

თუმცა, ამ პოსტის დაწერის დროს მივხვდით, რომ იმდენად შევეჩვიეთ OpenShift-ის გამოყენებას, რომ უბრალოდ ვერ ვხვდებით, როგორ გაიზარდა და გადაიქცა საოცარ პლატფორმად, რომელიც გახდა ბევრად მეტი, ვიდრე უბრალოდ Kubernetes დისტრიბუცია. ჩვენ მიდრეკილნი ვართ, რომ OpenShift-ის სიმწიფე და სიმარტივე თავისთავად მივიღოთ, მაშინ როცა ვუყურებთ მის ბრწყინვალებას.

ზოგადად, დადგა აქტიური მონანიების დრო და ახლა ჩვენ ეტაპობრივად შევადარებთ ჩვენი "Hello World"-ის ექსპლუატაციას KUK-ზე და OpenShift-ზე და ჩვენ ამას გავაკეთებთ რაც შეიძლება ობიექტურად (კარგი, გარდა ზოგჯერ პერსონალური ჩვენების დამოკიდებულება საგნისადმი). თუ გაინტერესებთ წმინდა სუბიექტური აზრი ამ საკითხზე, მაშინ შეგიძლიათ წაიკითხოთ აქ (EN). და ამ პოსტში ჩვენ დავრჩებით ფაქტებზე და მხოლოდ ფაქტებზე.

კლასტერები

ასე რომ, ჩვენს "Hello World" სჭირდება კლასტერები. მოდით ვთქვათ "არა" ნებისმიერ საჯარო ღრუბელზე, რათა არ გადაიხადოთ სერვერები, რეესტრები, ქსელები, მონაცემთა გადაცემა და ა.შ. შესაბამისად, ჩვენ ვირჩევთ მარტივ ერთკვანძოვან კლასტერს მინიკუბე (KUK-ისთვის) და კოდექსისთვის მზად კონტეინერები (OpenShift კლასტერისთვის). ორივე ეს ვარიანტი მართლაც მარტივი ინსტალაციაა, მაგრამ მოითხოვს საკმაოდ დიდ რესურსს თქვენს ლეპტოპზე.

შეკრება კუკ-ე

ასე რომ, წავიდეთ.

ნაბიჯი 1 - ჩვენი კონტეინერის სურათის აგება

დავიწყოთ ჩვენი "Hello World" minikube-ზე განლაგებით. ამას დასჭირდება:

1. 1. დაინსტალირებული Docker.
2. 2. დაინსტალირებული Git.
3. 3. დაინსტალირებული Maven (ფაქტობრივად, ეს პროექტი იყენებს mvnw ორობით, ასე რომ თქვენ შეგიძლიათ ამის გარეშე).
4. 4. რეალურად, თავად წყარო, ე.ი. საცავის კლონი github.com/gcolman/quarkus-hello-world.git

პირველი ნაბიჯი არის Quarkus პროექტის შექმნა. არ შეგეშინდეთ, თუ არასოდეს გამოგიყენებიათ Quarkus.io - ეს მარტივია. თქვენ უბრალოდ ირჩევთ კომპონენტებს, რომელთა გამოყენებაც გსურთ პროექტში (RestEasy, Hibernate, Amazon SQS, Camel და ა.შ.), შემდეგ კი თავად Quarkus, თქვენი მონაწილეობის გარეშე, აყენებს maven არქეტიპს და ყველაფერს აყენებს github-ზე. ანუ, ფაქტიურად მაუსის ერთი დაწკაპუნებით - და დასრულებულია. სწორედ ამიტომ გვიყვარს Quarkus.

ჩვენი "Hello World" კონტეინერულ გამოსახულებად ასაშენებლად უმარტივესი გზაა Docker-ისთვის quarkus-maven გაფართოებების გამოყენება, რომელიც შეასრულებს ყველა საჭირო სამუშაოს. Quarkus-ის მოსვლასთან ერთად ეს მართლაც მარტივი და მარტივი გახდა: დაამატეთ კონტეინერის გამოსახულების დოკერის გაფართოება და შეგიძლიათ შექმნათ სურათები maven ბრძანებებით.

./mvnw quarkus:add-extension -Dextensions=”container-image-docker”

და ბოლოს, ჩვენ ვაშენებთ ჩვენს სურათს Maven-ის გამოყენებით. შედეგად, ჩვენი წყაროს კოდი იქცევა მზა კონტეინერის სურათად, რომლის გაშვება უკვე შესაძლებელია კონტეინერის გაშვების დროს.

./mvnw -X clean package -Dquarkus.container-image.build=true

ფაქტობრივად, ეს არის ყველაფერი, ახლა თქვენ შეგიძლიათ გაუშვათ კონტეინერი docker run ბრძანებით, რომლითაც ჩვენი სერვისი პორტ 8080-ზე შეიტანეთ ისე, რომ მასზე წვდომა იყოს შესაძლებელი.

docker run -i — rm -p 8080:8080 gcolman/quarkus-hello-world

კონტეინერის ინსტანციის დაწყების შემდეგ, რჩება მხოლოდ curl ბრძანებით შემოწმება, რომ ჩვენი სერვისი მუშაობს:

ასე რომ, ყველაფერი მუშაობს და ეს მართლაც მარტივი და მარტივი იყო.

ნაბიჯი 2 - გაგზავნეთ ჩვენი კონტეინერი კონტეინერის გამოსახულების საცავში

ამ დროისთვის, ჩვენ მიერ შექმნილი სურათი ადგილობრივად ინახება ჩვენს ადგილობრივ კონტეინერში. თუ გვინდა გამოვიყენოთ ეს სურათი ჩვენს KUK გარემოში, მაშინ ის სხვა საცავში უნდა განვათავსოთ. Kubernetes-ს არ აქვს ეს ფუნქციები, ამიტომ ჩვენ გამოვიყენებთ dockerhub-ს. იმიტომ, რომ, ჯერ ერთი, ეს უფასოა და მეორეც, ამას (თითქმის) ყველა აკეთებს.

ეს ასევე ძალიან მარტივია და აქ მხოლოდ dockerhub ანგარიშია საჭირო.

ასე რომ, ჩვენ ვაყენებთ dockerhub-ს და ვაგზავნით ჩვენს სურათს იქ.

ნაბიჯი 3 - დაიწყეთ Kubernetes

არსებობს მრავალი გზა, რომ შევკრიბოთ კუბერნეტის კონფიგურაცია ჩვენი "Hello World"-ის გასაშვებად, მაგრამ ჩვენ გამოვიყენებთ მათგან უმარტივესს, რადგან ჩვენ ასეთი ხალხი ვართ ...

პირველი, ჩვენ ვიწყებთ მინიკუბების კლასტერს:

minikube start

ნაბიჯი 4 - ჩვენი კონტეინერის გამოსახულების განლაგება

ახლა ჩვენ უნდა გადავიყვანოთ ჩვენი კოდი და კონტეინერის სურათი kubernetes კონფიგურაციაში. სხვა სიტყვებით რომ ვთქვათ, ჩვენ გვჭირდება pod და განლაგების განმარტება, რომელიც მიუთითებს ჩვენს კონტეინერის სურათზე dockerhub-ზე. ამის გაკეთების ერთ-ერთი ყველაზე მარტივი გზა არის შექმნას განლაგების ბრძანების გაშვება, რომელიც მიუთითებს ჩვენს სურათზე:

kubectl create deployment hello-quarkus — image =gcolman/quarkus-hello-world:1.0.0-SNAPSHOT

ამ ბრძანებით, ჩვენ ვუთხარით ჩვენს COOK-ს, შექმნას განლაგების კონფიგურაცია, რომელიც უნდა შეიცავდეს ჩვენი კონტეინერის გამოსახულების pod სპეციფიკაციას. ეს ბრძანება ასევე გამოიყენებს ამ კონფიგურაციას ჩვენს minikube კლასტერზე და შექმნის განლაგებას, რომელიც ჩამოტვირთავს ჩვენს კონტეინერის სურათს და გაუშვებს პოდს კლასტერზე.

ნაბიჯი 5 - ღია წვდომა ჩვენს სერვისზე

ახლა, როდესაც ჩვენ გვაქვს განლაგებული კონტეინერის სურათი, დროა ვიფიქროთ იმაზე, თუ როგორ უნდა დააკონფიგურიროთ გარე წვდომა ამ Restful სერვისზე, რომელიც, ფაქტობრივად, დაპროგრამებულია ჩვენს კოდში.

აქ ბევრი გზაა. მაგალითად, შეგიძლიათ გამოიყენოთ ექსპოზიციის ბრძანება, რათა ავტომატურად შექმნათ Kubernetes-ის შესაბამისი კომპონენტები, როგორიცაა სერვისები და ბოლო წერტილები. სინამდვილეში, ეს არის ის, რასაც ჩვენ გავაკეთებთ ჩვენი განლაგების ობიექტისთვის expose ბრძანების შესრულებით:

kubectl expose deployment hello-quarkus — type=NodePort — port=8080

მოდით, ცოტა ხნით შევჩერდეთ ექსპოზიციის ბრძანების "-type" ვარიანტზე.

როდესაც ჩვენ ვამჟღავნებთ და ვქმნით კომპონენტებს, რომლებიც საჭიროა ჩვენი სერვისის გასაშვებად, ჩვენ გვჭირდება, სხვა საკითხებთან ერთად, შეგვეძლოს გარედან დაკავშირება hello-quarkus სერვისთან, რომელიც განთავსებულია ჩვენი პროგრამული უზრუნველყოფით განსაზღვრულ ქსელში. და პარამეტრი ტიპი საშუალებას გვაძლევს შევქმნათ და დავაკავშიროთ ისეთი რამ, როგორიცაა დატვირთვის ბალანსერი, რათა ტრაფიკი ამ ქსელში გადაიყვანოს.

მაგალითად, წერა type=LoadBalancer, ჩვენ ავტომატურად ვაკეთებთ ინიციალიზაციას საჯარო ღრუბლოვანი დატვირთვის ბალანსერი ჩვენს Kubernetes კლასტერთან დასაკავშირებლად. ეს, რა თქმა უნდა, შესანიშნავია, მაგრამ თქვენ უნდა გესმოდეთ, რომ ასეთი კონფიგურაცია მჭიდროდ იქნება მიბმული კონკრეტულ საჯარო ღრუბელთან და უფრო რთული იქნება მისი გადატანა კუბერნეტის ინსტანციებს შორის სხვადასხვა გარემოში.

ჩვენს მაგალითში type=NodePort, ანუ ჩვენს სერვისზე ზარი მიდის კვანძის IP მისამართით და პორტის ნომრით. ეს პარამეტრი საშუალებას გაძლევთ არ გამოიყენოთ საჯარო ღრუბლები, მაგრამ მოითხოვს დამატებით ნაბიჯებს. პირველ რიგში, თქვენ გჭირდებათ საკუთარი დატვირთვის ბალანსერი, ამიტომ ჩვენ განვათავსებთ NGINX დატვირთვის ბალანსერს ჩვენს კლასტერში.

ნაბიჯი 6 - დააყენეთ დატვირთვის ბალანსერი

minikube-ს აქვს პლატფორმის მრავალი ფუნქცია, რაც გაადვილებს გარე წვდომისთვის საჭირო კომპონენტების შექმნას, როგორიცაა შესასვლელი კონტროლერები. Minikube მოყვება Nginx შემოსვლის კონტროლერთან ერთად და რაც ჩვენ უნდა გავაკეთოთ არის მისი ჩართვა და კონფიგურაცია.

minikube addons enable ingress

ახლა, მხოლოდ ერთი ბრძანებით, ჩვენ შევქმნით Nginx შემოსვლის კონტროლერს, რომელიც იმუშავებს ჩვენს minikube კლასტერში:

ingress-nginx-controller-69ccf5d9d8-j5gs9 1/1 Running 1 33m

ნაბიჯი 7 - შეყვანის დაყენება

ახლა ჩვენ უნდა დავაკონფიგურიროთ Nginx ingress კონტროლერი, რომ მიიღოს hello-quarkus მოთხოვნები.

და ბოლოს, ჩვენ უნდა გამოვიყენოთ ეს კონფიგურაცია.

kubectl apply -f ingress.yml

ვინაიდან ამ ყველაფერს საკუთარ მანქანაზე ვაკეთებთ, უბრალოდ დავამატებთ ჩვენი კვანძის IP მისამართს /etc/hosts ფაილს, რათა http მოთხოვნები მივმართოთ ჩვენს minikube-ზე NGINX დატვირთვის ბალანსერზე.

192.168.99.100 hello-quarkus.info

ეს ასეა, ახლა ჩვენი minikube სერვისი ხელმისაწვდომია გარედან Nginx შემოსვლის კონტროლერის საშუალებით.

ისე, ეს ადვილი იყო, არა? თუ არც ისე ბევრი?

გაშვება OpenShift-ზე (კოდის მზა კონტეინერები)

ახლა კი ვნახოთ, როგორ კეთდება ეს ყველაფერი Red Hat OpenShift კონტეინერის პლატფორმაზე (OCP).

როგორც minikube-ის შემთხვევაში, ჩვენ ვირჩევთ სქემას ერთი კვანძის OpenShift კლასტერით Code Ready Containers (CRC) სახით. ადრე მას ეძახდნენ minishift და ეფუძნებოდა OpenShift Origin პროექტს, მაგრამ ახლა ის არის CRC და აგებულია Red Hat-ის OpenShift კონტეინერის პლატფორმაზე.

აქ, ბოდიში, არ შეგვიძლია არ ვთქვათ: "OpenShift შესანიშნავია!"

თავდაპირველად, ჩვენ გვგონია დამეწერა, რომ OpenShift-ზე განვითარება არაფრით განსხვავდება Kubernetes-ის განვითარებისგან. და ფაქტობრივად, ეს ასეა. მაგრამ ამ პოსტის დაწერის პროცესში ჩვენ გავიხსენეთ რამდენი ზედმეტი მოძრაობა უნდა გააკეთოთ, როცა OpenShift არ გაქვთ და, შესაბამისად, ისევ ლამაზია. ჩვენ გვიყვარს, რომ ყველაფერი მარტივი იყოს და რამდენად ადვილია OpenShift-ზე ჩვენი მაგალითის გამოყენება და გაშვება minikube-სთან შედარებით, არის ის, რამაც შთააგონა ეს პოსტის დაწერა.

მოდით გავიაროთ პროცესი და ვნახოთ, რა უნდა გავაკეთოთ.

ასე რომ, minikube-ის მაგალითში დავიწყეთ Docker-ით... მოიცადეთ, ჩვენ აღარ გვჭირდება Docker დაყენებული მანქანაზე.

და ჩვენ არ გვჭირდება ადგილობრივი ჯიში.
და მეივენი არ არის საჭირო.
და თქვენ არ გჭირდებათ ხელით შექმნათ კონტეინერის სურათი.
და თქვენ არ გჭირდებათ კონტეინერის სურათების რაიმე საცავი მოძებნოთ.
და თქვენ არ გჭირდებათ შეღწევის კონტროლერის დაყენება.
და არც შეყვანის კონფიგურაცია გჭირდებათ.

Გესმის? ჩვენი აპლიკაციის OpenShift-ზე განსათავსებლად და გასაშვებად, არცერთი ზემოთ ჩამოთვლილი არ არის საჭირო. და თავად პროცესი შემდეგია.

ნაბიჯი 1 – თქვენი OpenShift კლასტერის დაწყება

ჩვენ ვიყენებთ Code Ready Containers-ს Red Hat-ისგან, რომელიც არსებითად არის იგივე Minikube, მაგრამ მხოლოდ ერთი კვანძის სრული Openshift კლასტერით.

crc start

ნაბიჯი 2 - შექმენით და განათავსეთ აპლიკაცია OpenShift კლასტერში

სწორედ ამ ეტაპზე ვლინდება OpenShift-ის სიმარტივე და მოხერხებულობა მთელი თავისი დიდებით. როგორც Kubernetes-ის ყველა დისტრიბუციას, ჩვენ გვაქვს მრავალი გზა აპლიკაციის კლასტერზე გასაშვებად. და, როგორც KUK-ის შემთხვევაში, ჩვენ კონკრეტულად ვირჩევთ უმარტივესს.

OpenShift ყოველთვის იყო აგებული, როგორც პლატფორმა კონტეინერირებული აპლიკაციების შესაქმნელად და გასაშვებად. კონტეინერების აგება ყოველთვის იყო ამ პლატფორმის განუყოფელი ნაწილი, ამიტომ არის Kubernetes-ის დამატებითი რესურსები შესაბამისი ამოცანებისთვის.

ჩვენ გამოვიყენებთ OpenShift-ის Source 2 Image (S2I) პროცესს, რომელსაც აქვს რამდენიმე განსხვავებული გზა, რომ ავიღოთ ჩვენი წყარო (კოდი ან ბინარები) და გადავაქციოთ კონტეინერულ სურათად, რომელიც მუშაობს OpenShift კლასტერზე.

ამისთვის გვჭირდება ორი რამ:

• ჩვენი წყარო კოდი git საცავში
• Builder-image, რომლის საფუძველზეც შესრულდება აწყობა.

ბევრი ასეთი გამოსახულებაა, შენახული როგორც Red Hat-ის, ასევე საზოგადოების მიერ და ჩვენ გამოვიყენებთ OpenJDK სურათს, რადგან ვაშენებ Java აპლიკაციას.

თქვენ შეგიძლიათ გაუშვათ S2I build როგორც OpenShift Developer გრაფიკული კონსოლიდან, ასევე ბრძანების ხაზიდან. ჩვენ გამოვიყენებთ ახალი აპლიკაციის ბრძანებას, სადაც ვეუბნებით, სად უნდა მიიღოთ მშენებლის სურათი და ჩვენი წყარო კოდი.

oc new-app registry.access.redhat.com/ubi8/openjdk-11:latest~https://github.com/gcolman/quarkus-hello-world.git

ესე იგი, ჩვენი აპლიკაცია შეიქმნა. ამით, S2I პროცესმა გააკეთა შემდეგი რამ:

• შევქმენით სერვისის build-pod აპლიკაციის შექმნასთან დაკავშირებული ყველა სახის ნივთისთვის.
• შექმენით OpenShift Build კონფიგურაცია.
• მე გადმოვწერე მშენებლის სურათი შიდა OpenShift დოკერის რეესტრში.
• კლონირებული "Hello World" ადგილობრივ საცავში.
• დაინახა, რომ იქ მავენ პომი იყო და ასე შეადგინა აპლიკაცია მავენთან ერთად.
• შექმენით ახალი კონტეინერის სურათი, რომელიც შეიცავს შედგენილ Java აპლიკაციას და ჩადეთ ეს სურათი შიდა კონტეინერის რეესტრში.
• შექმენით Kubernetes Deployment სპეციფიკაციებით pod, სერვისი და ა.შ.
• გაშვებულია განლაგების კონტეინერის სურათი.
• ამოღებულია სერვისის build-pod.

ამ სიაში ბევრია, მაგრამ მთავარი ის არის, რომ მთელი კონსტრუქცია ხდება ექსკლუზიურად OpenShift-ში, Docker-ის შიდა რეესტრი არის OpenShift-ში და build-ის პროცესი ქმნის Kubernetes-ის ყველა კომპონენტს და აწარმოებს მათ კლასტერზე.

თუ თქვენ ვიზუალურად ადევნებთ თვალყურს S2I-ის გაშვებას კონსოლში, ხედავთ, თუ როგორ ხდება build pod-ის გაშვება მშენებლობის დროს.

ახლა კი მოდით გადავხედოთ builder pod-ის ჟურნალებს: პირველ რიგში, იქ ნახავთ, როგორ აკეთებს maven თავის საქმეს და ჩამოტვირთავს დამოკიდებულებებს ჩვენი java აპლიკაციის შესაქმნელად.

Maven build-ის დასრულების შემდეგ იწყება კონტეინერის სურათის აგება და შემდეგ ეს ჩაშენებული სურათი იგზავნება შიდა საცავში.

ყველაფერი, შეკრების პროცესი დასრულებულია. ახლა მოდით დავრწმუნდეთ, რომ ჩვენი აპლიკაციის პოდები და სერვისები დაიწყო კლასტერში.

oc get service

Სულ ეს არის. და მხოლოდ ერთი გუნდია. ყველაფერი რაც ჩვენ უნდა გავაკეთოთ არის ამ სერვისის გამოვლენა გარე წვდომისთვის.

ნაბიჯი 3 - გახადეთ სერვისი გარედან წვდომისთვის

როგორც KUK-ის შემთხვევაში, OpenShift პლატფორმაზე, ჩვენს "Hello World"-ს ასევე ესაჭიროება როუტერი, რათა გარე ტრაფიკი მიმართოს კლასტერში არსებულ სერვისს. OpenShift-ში ეს ძალიან მარტივს ხდის. პირველ რიგში, HAProxy მარშრუტიზაციის კომპონენტი დაინსტალირებულია კლასტერში ნაგულისხმევად (ის შეიძლება შეიცვალოს იმავე NGINX-ზე). მეორეც, არსებობს სპეციალური და უაღრესად კონფიგურირებადი რესურსები სახელწოდებით Routes, რომლებიც მოგვაგონებს Ingress ობიექტებს ძველ კარგ Kubernetes-ში (ფაქტობრივად, OpenShift-ის მარშრუტებმა დიდი გავლენა მოახდინა Ingress ობიექტების დიზაინზე, რომლებიც ახლა შეიძლება გამოყენებულ იქნას OpenShift-ში), მაგრამ ჩვენი "გამარჯობა". World", და თითქმის ყველა სხვა შემთხვევაში, სტანდარტული მარშრუტი საკმარისია ჩვენთვის დამატებითი კონფიგურაციის გარეშე.

იმისათვის, რომ შევქმნათ მარშრუტირებადი FQDN "Hello World"-ისთვის (დიახ, OpenShiift-ს აქვს საკუთარი DNS სერვისების სახელების მიხედვით მარშრუტიზაციისთვის), ჩვენ უბრალოდ გამოვაქვეყნებთ ჩვენს სერვისს:

oc expose service quarkus-hello-world

თუ გადახედავთ ახლად შექმნილ მარშრუტს, შეგიძლიათ იპოვოთ FQDN და სხვა მარშრუტიზაციის ინფორმაცია:

oc get route

და ბოლოს, ჩვენ შევდივართ ჩვენს სერვისზე ბრაუზერიდან:

მაგრამ ახლა ეს მართლაც ადვილი იყო!

ჩვენ გვიყვარს Kubernetes და ყველაფერი, რისი გაკეთების საშუალებას გაძლევთ ეს ტექნოლოგია, ასევე გვიყვარს სიმარტივე და სიმსუბუქე. Kubernetes შეიქმნა იმისთვის, რომ განაწილებული, მასშტაბირებადი კონტეინერები წარმოუდგენლად მარტივი ფუნქციონირებისთვის ყოფილიყო, მაგრამ მისი სიმარტივე აღარ არის საკმარისი იმისათვის, რომ აპლიკაციები დღეს წარმოებაში შემოიტანოს. სწორედ აქ მოქმედებს OpenShift, რომელიც ემორჩილება დროს და სთავაზობს დეველოპერებზე ორიენტირებულ Kubernetes-ს. დიდი ძალისხმევა დაიხარჯა OpenShift პლატფორმის სპეციალურად დეველოპერებისთვის მორგებისთვის, მათ შორის ისეთი ინსტრუმენტების შექმნა, როგორიცაა S2I, ODI, დეველოპერის პორტალი, OpenShift ოპერატორის ჩარჩო, IDE ინტეგრაცია, დეველოპერის კატალოგები, Helm ინტეგრაცია, მონიტორინგი და მრავალი სხვა.

ვიმედოვნებთ, რომ ეს სტატია თქვენთვის საინტერესო და სასარგებლო იყო. და თქვენ შეგიძლიათ იპოვოთ დამატებითი რესურსები, მასალები და სხვა რამ, რაც გამოსადეგია OpenShift პლატფორმაზე პორტალზე Red Hat დეველოპერები.

წყარო: www.habr.com