ინსტრუმენტები Kubernetes-ზე გაშვებული აპლიკაციების დეველოპერებისთვის

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

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

მარტივი დამხმარეები

Kubectl-გამართვა

• არსი: დაამატეთ თქვენი კონტეინერი პოდში და ნახეთ რა ხდება მასში.
• GitHub.
• მოკლე GH სტატისტიკა: 715 ვარსკვლავი, 54 ვალდებულება, 9 მონაწილე.
• ენა: წადი.
• ლიცენზია: Apache License 2.0.

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

თქვენ ასევე შეგიძლიათ გადახვიდეთ პროცესის კონტეინერზე გაშვებით chroot /proc/PID/root - ეს შეიძლება იყოს ძალიან მოსახერხებელი, როდესაც თქვენ გჭირდებათ ფესვის გარსის მიღება კონტეინერში, რომლისთვისაც იგი მითითებულია მანიფესტში securityContext.runAs.

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

ტელეპრესენს

• არსი: გადაიტანეთ აპლიკაცია თქვენს კომპიუტერში. ადგილობრივად შემუშავება და გამართვა.
• საიტის; GitHub.
• მოკლე GH სტატისტიკა: 2131 ვარსკვლავი, 2712 ვალდებულება, 33 კონტრიბუტორი.
• ენა: პითონი.
• ლიცენზია: Apache License 2.0.

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

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

ჩვენ უკვე გავუზიარეთ Telepresence-ის გამოყენების გამოცდილება აქ.

Ksync

• არსი: კოდის თითქმის მყისიერი სინქრონიზაცია კლასტერში არსებულ კონტეინერთან.
• GitHub.
• მოკლე GH სტატისტიკა: 555 ვარსკვლავი, 362 ვალდებულება, 11 მონაწილე.
• ენა: წადი.
• ლიცენზია: Apache License 2.0.

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

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

რჩება მხოლოდ ksync-ს მითითება, რასთან სინქრონიზაცია მოახდინოს. მაგალითად, ეს ბრძანება:

ksync create --name=myproject --namespace=test --selector=app=backend --container=php --reload=false /home/user/myproject/ /var/www/myproject/

...შექმნის დამკვირვებელს სახელად myprojectრომელიც მოძებნის პოდს ეტიკეტით app=backend და სცადეთ ადგილობრივი დირექტორიას სინქრონიზაცია /home/user/myproject/ კატალოგით /var/www/myproject/ კონტეინერში ე.წ php.

პრობლემები და შენიშვნები ksync-ზე ჩვენი გამოცდილებიდან:

• უნდა იყოს გამოყენებული Kubernetes კლასტერულ კვანძებზე overlay2 როგორც შენახვის დრაივერი Docker-ისთვის. კომუნალური პროგრამა არ იმუშავებს სხვასთან.
• Windows-ის, როგორც კლიენტის OS-ის გამოყენებისას, ფაილური სისტემის დამკვირვებელმა შეიძლება სწორად არ იმუშაოს. ეს ხარვეზი შენიშნა დიდ დირექტორიაებთან მუშაობისას - დიდი რაოდენობით ჩადგმული ფაილებითა და დირექტორიებით. ჩვენ შევქმენით შესაბამისი საკითხი სინქრონიზაციის პროექტში, მაგრამ მასზე ჯერ პროგრესი არ არის (ივლისის დასაწყისიდან).
• გამოიყენეთ ფაილი .stignore მიუთითეთ ბილიკები ან ფაილების შაბლონები, რომლებიც არ საჭიროებს სინქრონიზაციას (მაგალითად, დირექტორიები app/cache и .git).
• ნაგულისხმევად, ksync გადატვირთავს კონტეინერს, როდესაც ფაილები შეიცვლება. Node.js-ისთვის ეს მოსახერხებელია, მაგრამ PHP-სთვის სრულიად არასაჭიროა. უმჯობესია გამორთოთ opcache და გამოიყენოთ დროშა --reload=false.
• კონფიგურაციის გამოსწორება ყოველთვის შესაძლებელია $HOME/.ksync/ksync.yaml.

Squash

• არსი: გამართვის პროცესები პირდაპირ კლასტერში.
• GitHub.
• მოკლე GH სტატისტიკა: 1154 ვარსკვლავი, 279 ვალდებულება, 23 კონტრიბუტორი.
• ენა: წადი.
• ლიცენზია: Apache License 2.0.

ეს ინსტრუმენტი შექმნილია პროცესების გამართვისთვის პირდაპირ პოდებში. პროგრამა მარტივია და ინტერაქტიულად გაძლევთ საშუალებას აირჩიოთ სასურველი გამართვა (იხილეთ ქვემოთ) და სახელთა სივრცე + pod, რომლის პროცესში თქვენ უნდა ჩაერიოთ. ამჟამად მხარდაჭერილი:

• delve - Go აპლიკაციებისთვის;
• GDB - სამიზნე დისტანციური + პორტის გადამისამართებით;
• JDWP პორტის გადამისამართება Java აპლიკაციების გამართვისთვის.

IDE მხარეს, მხარდაჭერა ხელმისაწვდომია მხოლოდ VScode-ში (გამოყენებით გაფართოება), თუმცა, მიმდინარე (2019) წლის გეგმებში შედის Eclipse და Intellij.

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

სრული გადაწყვეტილებები

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

NB: ამ სიაში, რა თქმა უნდა, არის ადგილი ჩვენი ღია კოდის პროგრამისთვის ვერფ (ადრე ცნობილი როგორც dapp). თუმცა, ჩვენ უკვე არაერთხელ დავწერეთ და ვისაუბრეთ ამის შესახებ და ამიტომ გადავწყვიტეთ, რომ არ შეგვეტანა იგი მიმოხილვაში. მათთვის, ვისაც სურს უკეთ გაეცნოს მის შესაძლებლობებს, გირჩევთ წაიკითხოთ/მოუსმინოთ მოხსენება ”werf არის ჩვენი ინსტრუმენტი CI/CD-ისთვის Kubernetes-ში".

DevSpace

• არსი: მათთვის, ვისაც სურს დაიწყოს მუშაობა Kubernetes-ში, მაგრამ არ სურს ღრმად ჩაღრმავება მის ჯუნგლებში.
• GitHub.
• მოკლე GH სტატისტიკა: 630 ვარსკვლავი, 1912 ვალდებულება, 13 კონტრიბუტორი.
• ენა: წადი.
• ლიცენზია: Apache License 2.0.

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

ბრძანების გაშვებისას devspace init პროექტის კატალოგში შემოგთავაზებთ (ინტერაქტიულად):

• აირჩიეთ სამუშაო Kubernetes კლასტერი,
• გამოიყენე არსებული Dockerfile (ან გენერირება ახალი) მის საფუძველზე კონტეინერის შესაქმნელად,
• შეარჩიეთ საცავი კონტეინერის სურათების შესანახად და ა.შ.

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

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

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

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

DevSpace-თან მუშაობის არქიტექტურა და ძირითადი ეტაპები

გარდა ამისა, ადვილია პროექტში წინასწარ განსაზღვრული კომპონენტის (მაგალითად, MySQL DBMS) ან Helm ჩარტის დამატება. წაიკითხეთ მეტი ში დოკუმენტაცია - ეს არ არის რთული.

ხარაჩო

• საიტის; GitHub.
• მოკლე GH სტატისტიკა: 7423 ვარსკვლავი, 4173 ვალდებულება, 136 მონაწილე.
• ენა: წადი.
• ლიცენზია: Apache License 2.0.

Google-ის ეს პროგრამა ამტკიცებს, რომ მოიცავს დეველოპერის ყველა საჭიროებას, რომლის კოდი როგორღაც იმუშავებს Kubernetes კლასტერზე. მისი გამოყენების დაწყება არც ისე ადვილია, როგორც devspace: არ არის ინტერაქტიულობა, ენის ამოცნობა და ავტომატური შექმნა Dockerfile აქ არ შემოგთავაზებენ.

თუმცა, თუ ეს არ შეგაშინებთ, აი, რის საშუალებას გაძლევთ Skaffold:

• თვალყური ადევნეთ წყაროს კოდის ცვლილებებს.
• სინქრონიზაცია მოახდინეთ პოდის კონტეინერთან, თუ ის არ საჭიროებს შეკრებას.
• შეაგროვეთ კონტეინერები კოდით, თუ ენა ინტერპრეტირებულია, ან შეადგინეთ არტეფაქტები და ჩაალაგეთ ისინი კონტეინერებში.
• შედეგად მიღებული სურათები ავტომატურად შემოწმდება გამოყენებით კონტეინერი-სტრუქტურა-ტესტი.
• სურათების მონიშვნა და ატვირთვა Docker Registry-ში.
• განათავსეთ აპლიკაცია კლასტერში kubectl, Helm ან kustomize გამოყენებით.
• შეასრულეთ პორტის გადამისამართება.
• Java, Node.js, Python-ში დაწერილი აპლიკაციების გამართვა.

სამუშაო პროცესი სხვადასხვა ვარიაციებში დეკლარაციულად არის აღწერილი ფაილში skaffold.yaml. პროექტისთვის, თქვენ ასევე შეგიძლიათ განსაზღვროთ რამდენიმე პროფილი, რომლებშიც შეგიძლიათ ნაწილობრივ ან მთლიანად შეცვალოთ შეკრების და განლაგების ეტაპები. მაგალითად, განვითარებისთვის, მიუთითეთ დეველოპერისთვის მოსახერხებელი საბაზისო სურათი, ხოლო დადგმისა და წარმოებისთვის - მინიმალური (+ გამოყენება securityContext კონტეინერები ან ხელახლა განსაზღვრეთ კლასტერი, რომელშიც განთავსდება აპლიკაცია).

დოკერის კონტეინერები შეიძლება აშენდეს ადგილობრივად ან დისტანციურად: in Google Cloud Build ან კლასტერში გამოყენებით კანიკო. ასევე მხარდაჭერილია Bazel და Jib Maven/Gradle. მონიშვნისთვის Skaffold მხარს უჭერს ბევრ სტრატეგიას: git commit hash, თარიღი/დრო, sha256 წყაროების ჯამი და ა.შ.

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

• ბრძანებების შესრულება კონტეინერის კონტექსტში გასასვლელი სტატუსების თვალყურის დევნებით და ბრძანების ტექსტის გამომავალი შემოწმებით.
• კონტეინერში ფაილების არსებობის შემოწმება და მითითებული ატრიბუტების შესაბამისობა.
• ფაილის შინაარსის კონტროლი რეგულარული გამონათქვამების გამოყენებით.
• სურათის მეტამონაცემების დადასტურება (ENV, ENTRYPOINT, VOLUMES და ა.შ.).
• ლიცენზიის თავსებადობის შემოწმება.

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

Skaffold-ის მუშაობის ძირითადი ეტაპები

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

ეზო

• საიტის; GitHub.
• მოკლე GH სტატისტიკა: 1063 ვარსკვლავი, 1927 ვალდებულება, 17 კონტრიბუტორი.
• ენა: TypeScript (დაგეგმილია პროექტის დაყოფა რამდენიმე კომპონენტად, რომელთაგან ზოგიერთი იქნება Go-ში და ასევე დამზადდება SDK დანამატების შესაქმნელად TypeScript/JavaScript-ში და Go-ში).
• ლიცენზია: Apache License 2.0.

Skaffold-ის მსგავსად, Garden მიზნად ისახავს K8s კლასტერში განაცხადის კოდის მიწოდების პროცესების ავტომატიზირებას. ამისათვის ჯერ უნდა აღწეროთ პროექტის სტრუქტურა YAML ფაილში და შემდეგ გაუშვათ ბრძანება garden dev. ის გააკეთებს მთელ ჯადოსნობას:

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

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

პროექტის მოდული შეიძლება იყოს კონტეინერი, Maven კონტეინერი, Helm სქემა, მანიფესტი kubectl apply ან თუნდაც OpenFaaS ფუნქცია. უფრო მეტიც, ნებისმიერი მოდულის ამოღება შესაძლებელია დისტანციური Git საცავიდან. მოდულმა შეიძლება განსაზღვროს ან არ განსაზღვროს სერვისები, ამოცანები და ტესტები. სერვისებსა და ამოცანებს შეიძლება ჰქონდეთ დამოკიდებულებები, ასე რომ თქვენ შეგიძლიათ განსაზღვროთ კონკრეტული სერვისის განლაგების თანმიმდევრობა და მოაწყოთ ამოცანებისა და ტესტების დაწყება.

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

პანელი ბაღისთვის

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

დასკვნა

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

PS

ასევე წაიკითხეთ ჩვენს ბლოგზე:

• «werf - ჩვენი ინსტრუმენტი CI / CD-სთვის Kubernetes-ში (მიმოხილვა და ვიდეო ანგარიში)";
• «Garden v0.10.0: თქვენს ლეპტოპს არ სჭირდება Kubernetes";
• «Kubernetes-ის რჩევები და ხრიკები: ადგილობრივი განვითარებისა და ტელეყოფის შესახებ";
• «kubectl-debug დანამატი Kubernetes pods-ში გამართვისთვის".

წყარო: www.habr.com