თანამედროვე პლატფორმა პროგრამული უზრუნველყოფის განვითარებისა და დანერგვისთვის

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

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

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

ზედმეტია იმის თქმა, რომ ყველა ეს დავა ძალიან სულელური იყო

რეალობა ისაა, რომ არაფერი გაქრება და დღეს ჩვენ ვხედავთ საბოლოო პროდუქტებისა და მათი შემუშავების ექსპონენციალურ ზრდას, ჩვენს ცხოვრებაში ახალი პროგრამული უზრუნველყოფის მუდმივი გაჩენის გამო. და მიუხედავად იმისა, რომ გარშემო ყველაფერი შეიცვლება, ამავე დროს, არსებითად, ყველაფერი უცვლელი დარჩება. პროგრამული უზრუნველყოფის დეველოპერები კვლავ დაწერენ კოდს შეცდომით, ოპერაციების ინჟინრები და სანდოობის სპეციალისტები კვლავ დადიან პეიჯერებით და მიიღებენ ავტომატურ გაფრთხილებებს Slack-ში, მენეჯერები კვლავ იმუშავებენ OpEx-ისა და CapEx-ის თვალსაზრისით და ყოველ ჯერზე, როცა მოხდება მარცხი, უფროსი დეველოპერი სევდიანად ამოისუნთქე სიტყვებით: „მე გითხარი“...

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

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

ამასთან, OpenShift გუნდი სვამს ერთ მარტივ კითხვას:

როგორ შეგიძლიათ Kubernetes-თან მუშაობა უფრო ადვილი და მოსახერხებელი გახადოთ?

პასუხი საოცრად აშკარაა:

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

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

როგორ მივაღწიოთ ამ შედეგს?

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

2018 წლის დასაწყისში Red Hat-მა შეიძინა CoreOS პროექტი, რომელსაც ჰქონდა მსგავსი შეხედულებები მომავალზე - უფრო უსაფრთხო და საიმედო, შექმნილი ღია კოდის პრინციპებზე. კომპანია მუშაობდა ამ იდეების შემდგომ განვითარებასა და მათ განხორციელებაზე, ჩვენი ფილოსოფიის პრაქტიკაში რეალიზებით - ცდილობს უზრუნველყოს ყველა პროგრამული უზრუნველყოფის უსაფრთხოდ მუშაობა. მთელი ეს ნამუშევარი აგებულია Kubernetes-ზე, Linux-ზე, საჯარო ღრუბლებზე, კერძო ღრუბლებზე და ათასობით სხვა პროექტზე, რომლებიც ეფუძნება ჩვენს თანამედროვე ციფრულ ეკოსისტემას.

OpenShift 4-ის ახალი გამოშვება იქნება ნათელი, ავტომატური და უფრო ბუნებრივი

OpenShift პლატფორმა იმუშავებს Linux-ის საუკეთესო და ყველაზე საიმედო ოპერაციულ სისტემებთან, შიშველი მეტალის ტექნიკის მხარდაჭერით, მოსახერხებელი ვირტუალიზებით, ავტომატური ინფრასტრუქტურის პროგრამირებით და, რა თქმა უნდა, კონტეინერებით (რომლებიც არსებითად მხოლოდ Linux-ის სურათებია).

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

მან უნდა დაუშვას პროგრამული უზრუნველყოფის „მომსახურების სახით“ გაშვება და არ გამოიწვიოს ოპერატორებისთვის უმართავი ინფრასტრუქტურის ზრდა.

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

OpenShift 4: NoOps პლატფორმა, რომელიც არ საჭიროებს შენარჩუნებას

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

თუ ცდილობთ აბსტრაქციას, მაშინ დეველოპერებისთვის ცნებები "სერვერის გარეშე" ან "NoOps" ნიშნავს ინსტრუმენტებსა და სერვისებს, რომლებიც საშუალებას გაძლევთ დამალოთ "ოპერაციული" კომპონენტი ან მინიმუმამდე დაიყვანოთ ეს ტვირთი დეველოპერისთვის.

• იმუშავეთ არა სისტემებთან, არამედ აპლიკაციის ინტერფეისებთან (API).
• არ დაიზაროთ პროგრამული უზრუნველყოფის დანერგვა - მიეცით პროვაიდერს ამის გაკეთება თქვენთვის.
• ნუ გადახვალთ მაშინვე დიდი ჩარჩოს შექმნაზე – დაიწყეთ პატარა ნაწილების დაწერით, რომლებიც იმოქმედებენ როგორც „სამშენებლო ბლოკი“, შეეცადეთ ეს კოდი იმუშაოს მონაცემებთან და მოვლენებთან და არა დისკებთან და მონაცემთა ბაზებთან.

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

ტექნიკური და ოპერაციების პროფესიონალებისთვის სიტყვა "NoOps" შეიძლება ცოტა საშინლად ჟღერდეს. მაგრამ საველე ინჟინრებთან კომუნიკაციისას აშკარა ხდება, რომ შაბლონებსა და ტექნიკას, რომელსაც ისინი იყენებენ, რომლებიც მიზნად ისახავს საიმედოობისა და სანდოობის უზრუნველყოფას (Site Reliability Engineering, SRE) ბევრი მსგავსება აქვს ზემოთ აღწერილ შაბლონებთან:

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

SRE-ებმა იციან, რომ რაღაც შეიძლება არასწორედ მოხდეს და მათ მოუწევთ პრობლემის თვალყურის დევნება და გამოსწორება — ამიტომ ისინი ავტომატიზირებენ რუტინულ მუშაობას და წინასწარ ადგენენ შეცდომების ბიუჯეტს, რათა მზად იყვნენ პრიორიტეტების დასაყენებლად და გადაწყვეტილების მისაღებად, როდესაც პრობლემა წარმოიქმნება.

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

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

მაგრამ რა განსხვავებაა OpenShift 4 პლატფორმასა და მის წინამორბედებს შორის და ასეთი პრობლემების გადაჭრის "სტანდარტული" მიდგომისგან? რა განაპირობებს მასშტაბებს განხორციელებისა და ოპერაციების გუნდებისთვის? იმის გამო, რომ მეფე ამ სიტუაციაში არის მტევანი. Ისე,

• ჩვენ დარწმუნებული ვართ, რომ კლასტერების დანიშნულება ნათელია (ძვირფასო ღრუბელი, მე ავიღე ეს კლასტერი, რადგან შემეძლო)
• მანქანები და ოპერაციული სისტემები არსებობს კლასტერისთვის (თქვენო უდიდებულესობავ)
• მართეთ ჰოსტების მდგომარეობა კლასტერიდან, შეამცირეთ მათი აღდგენა (დრიფტი).
• სისტემის თითოეული მნიშვნელოვანი ელემენტისთვის საჭიროა ძიძა (მექანიზმი), რომელიც მონიტორინგს გაუწევს და აღმოფხვრის პრობლემებს
• სისტემის *ყველა* ასპექტის ან ელემენტის და მასთან დაკავშირებული აღდგენის მექანიზმების უკმარისობა ცხოვრების ნორმალური ნაწილია
• მთელი ინფრასტრუქტურა უნდა იყოს კონფიგურირებული API-ს მეშვეობით.
• გამოიყენეთ Kubernetes Kubernetes-ის გასაშვებად. (დიახ, დიახ, ეს არ არის შეცდომა)
• განახლებები უნდა იყოს მარტივი და უპრობლემოდ ინსტალაცია. თუ განახლების ინსტალაციას ერთზე მეტი დაწკაპუნება სჭირდება, მაშინ აშკარად რაღაცას არასწორად ვაკეთებთ.
• ნებისმიერი კომპონენტის მონიტორინგი და გამართვა არ უნდა იყოს პრობლემა და, შესაბამისად, თვალყურის დევნება და მოხსენება მთელ ინფრასტრუქტურაზე ასევე მარტივი და მოსახერხებელი უნდა იყოს.

გსურთ ნახოთ პლატფორმის შესაძლებლობები მოქმედებაში?

OpenShift 4-ის წინასწარი ვერსია ხელმისაწვდომი გახდა დეველოპერებისთვის. ადვილად გამოსაყენებელი ინსტალერით, შეგიძლიათ გაუშვათ კლასტერი AWS-ზე Red Had CoreOS-ის თავზე. გადახედვის გამოსაყენებლად, საჭიროა მხოლოდ AWS ანგარიში ინფრასტრუქტურის უზრუნველსაყოფად და ანგარიშების ნაკრები წინასწარი გადახედვის სურათებზე წვდომისთვის.

1. დასაწყებად, გადადით try.openshift.com და დააჭირეთ "დაწყება".
2. შედით თქვენს Red Hat ანგარიშში (ან შექმენით ახალი) და მიჰყევით ინსტრუქციას თქვენი პირველი კლასტერის დასაყენებლად.

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

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

ახლა კი ყურადღება!
კონფერენციაზე DevOpsForum 2019 20 აპრილს OpenShift-ის ერთ-ერთი დეველოპერი ვადიმ რუტკოვსკი გამართავს მასტერ კლასს - ათ კლასტერს დაამტვრევს და აიძულებს მათ გაასწორონ. კონფერენცია ფასიანია, მაგრამ სარეკლამო კოდით #RedHat იღებთ 37%-იან ფასდაკლებას

მასტერკლასი 17:15 - 18:15 საათზე, ხოლო სტენდი ღიაა მთელი დღის განმავლობაში. მაისურები, ქუდები, სტიკერები - ჩვეულებრივი!

დარბაზი #2
„აქ მთელი სისტემა უნდა შეიცვალოს: ჩვენ ვაკეთებთ გატეხილი k8 კლასტერებს სერტიფიცირებულ მექანიკასთან ერთად“.

წყარო: www.habr.com