werf - ჩვენი ინსტრუმენტი CI / CD-სთვის Kubernetes-ში (მიმოხილვა და ვიდეო ანგარიში)

27 მაისს ფესტივალის ფარგლებში ჩატარებული DevOpsConf 2019 კონფერენციის მთავარ დარბაზში РИТ++ 2019, როგორც „უწყვეტი მიწოდების“ განყოფილების ნაწილი, მომზადდა მოხსენება „werf - ჩვენი ინსტრუმენტი CI/CD-ისთვის Kubernetes-ში“. მათზეა საუბარი პრობლემები და გამოწვევები, რომლებიც ყველას აწყდება Kubernetes-ში განლაგებისას, ასევე ნიუანსების შესახებ, რომლებიც შეიძლება მაშინვე არ იყოს შესამჩნევი. შესაძლო გადაწყვეტილებების გაანალიზებით, ჩვენ ვაჩვენებთ, თუ როგორ ხორციელდება ეს ღია კოდის ინსტრუმენტში ვერფ.

პრეზენტაციის შემდეგ, ჩვენმა პროგრამამ (ადრე ცნობილი როგორც dapp) მიაღწია ისტორიულ ეტაპს 1000 ვარსკვლავი GitHub-ზე — ვიმედოვნებთ, რომ მომხმარებელთა მზარდი საზოგადოება გაუადვილებს ცხოვრებას DevOps-ის ბევრ ინჟინრს.

ასე რომ, ჩვენ წარმოგიდგენთ მოხსენების ვიდეო (~47 წუთი, სტატიაზე ბევრად უფრო ინფორმაციული) და მისგან მთავარი ამონაწერი ტექსტის სახით. წადი!

კოდის მიწოდება Kubernetes-ში

საუბარი აღარ იქნება werf-ზე, არამედ CI/CD-ზე Kubernetes-ში, რაც გულისხმობს იმას, რომ ჩვენი პროგრამული უზრუნველყოფა შეფუთულია Docker კონტეინერებში. (ამაზე ვისაუბრე 2016 წლის ანგარიში)და K8s გამოყენებული იქნება მის წარმოებაში გასაშვებად (დაწვრილებით ამის შესახებ 2017 წელი).

როგორ გამოიყურება მიწოდება Kubernetes-ში?

• არსებობს Git-ის საცავი, რომელშიც არის კოდი და ინსტრუქციები მისი მშენებლობისთვის. აპლიკაცია ჩაშენებულია Docker სურათში და გამოქვეყნებულია Docker Registry-ში.
• იგივე საცავი ასევე შეიცავს ინსტრუქციებს აპლიკაციის განლაგებისა და გაშვების შესახებ. განლაგების ეტაპზე ეს ინსტრუქციები იგზავნება Kubernetes-ში, რომელიც იღებს სასურველ სურათს რეესტრიდან და იწყებს მას.
• გარდა ამისა, ჩვეულებრივ არის ტესტები. ზოგიერთი მათგანის გაკეთება შესაძლებელია სურათის გამოქვეყნებისას. თქვენ ასევე შეგიძლიათ (იგივე ინსტრუქციების შემდეგ) განათავსოთ აპლიკაციის ასლი (ცალკე K8s სახელების სივრცეში ან ცალკეულ კლასტერში) და იქ ჩაატაროთ ტესტები.
• დაბოლოს, გჭირდებათ CI სისტემა, რომელიც მიიღებს მოვლენებს Git-დან (ან ღილაკზე დაწკაპუნებებით) და გამოიძახებს ყველა დანიშნულ ეტაპს: აშენება, გამოქვეყნება, დანერგვა, ტესტირება.

აქ არის რამდენიმე მნიშვნელოვანი შენიშვნა:

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

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

სცენის აშენება

Казалось бы, что можно рассказать в 2019 году про сборку Docker-образов, когда все умеют писать Dockerfile’ы и запускать docker build?.. აქ არის ის ნიუანსი, რომელზეც მინდა ყურადღება მიაქციო:

1. გამოსახულების წონა имеет значение, поэтому используйте მრავალსაფეხურიანისურათზე დატოვონ მხოლოდ ის აპლიკაცია, რომელიც ნამდვილად აუცილებელია ოპერაციისთვის.
2. ფენების რაოდენობა უნდა შემცირდეს ჯაჭვების გაერთიანებით RUN- ბრძანებს მნიშვნელობის მიხედვით.
3. თუმცა, ეს პრობლემებს მატებს გამართვა, რადგან როდესაც ასამბლეა იშლება, თქვენ უნდა იპოვოთ სწორი ბრძანება ჯაჭვიდან, რომელმაც პრობლემა გამოიწვია.
4. შეკრების სიჩქარე მნიშვნელოვანია, რადგან ჩვენ გვსურს სწრაფად გამოვაქვეყნოთ ცვლილებები და ვნახოთ შედეგები. მაგალითად, თქვენ არ გსურთ აღადგინოთ დამოკიდებულებები ენების ბიბლიოთეკებში ყოველ ჯერზე, როდესაც აპლიკაციის შექმნით.
5. ხშირად ერთი Git საცავიდან გჭირდებათ ბევრი სურათი, რომელიც შეიძლება გადაიჭრას Dockerfiles-ის ნაკრებით (ან დასახელებული ეტაპები ერთ ფაილში) და Bash სკრიპტით მათი თანმიმდევრული შეკრებით.

ეს იყო მხოლოდ აისბერგის მწვერვალი, რომელსაც ყველა აწყდება. მაგრამ არის სხვა პრობლემები, კერძოდ:

1. ხშირად შეკრების ეტაპზე რაღაც გვჭირდება მთაზე (მაგალითად, ქეშით ბრძანების შედეგი, როგორიცაა apt მესამე მხარის დირექტორიაში).
2. Ჩვენ გვინდა შეუძლებელია ნაჭუჭით დაწერის ნაცვლად.
3. Ჩვენ გვინდა აშენება Docker-ის გარეშე (რატომ გვჭირდება დამატებითი ვირტუალური მანქანა, რომელშიც ყველაფრის კონფიგურაცია გვჭირდება, როცა უკვე გვაქვს Kubernetes კლასტერი, რომელშიც შეგვიძლია კონტეინერების გაშვება?).
4. პარალელური შეკრება, რომლის გაგება შესაძლებელია სხვადასხვა გზით: სხვადასხვა ბრძანებები Dockerfile-დან (თუ გამოიყენება მრავალსაფეხურიანი), ერთი და იმავე საცავიდან რამდენიმე დავალება, რამდენიმე Dockerfiles.
5. განაწილებული შეკრება: ჩვენ გვინდა შევაგროვოთ ნივთები ბოდებში, რომლებიც "ეფემერულია", რადგან მათი ქეში ქრება, რაც იმას ნიშნავს, რომ ის სადმე ცალკე უნდა იყოს შენახული.
6. ბოლოს სურვილების მწვერვალი დავასახელე ავტომაგიური: იდეალური იქნებოდა საცავში წასვლა, აკრიფეთ რაიმე ბრძანება და მიიღეთ მზა სურათი, აწყობილი იმის გაგებით, თუ როგორ და რა უნდა გააკეთოთ სწორად. თუმცა, მე პირადად არ ვარ დარწმუნებული, რომ ყველა ნიუანსი ამ გზით შეიძლება განჭვრეტა.

И вот есть проекты:

• მობი/ბილდკიტი — მშენებელი Docker Inc-ისგან (უკვე ინტეგრირებულია Docker-ის მიმდინარე ვერსიებში), რომელიც ცდილობს გადაჭრას ყველა ეს პრობლემა;
• კანიკო — Google-ის მშენებელი, რომელიც საშუალებას გაძლევთ შექმნათ Docker-ის გარეშე;
• Buildpacks.io - CNCF-ის მცდელობა, გააკეთოს ავტომატური მაგია და, კერძოდ, საინტერესო გადაწყვეტა ფენების რებაზით;
• და მრავალი სხვა კომუნალური პროგრამა, როგორიცაა ბულდაჰი, genuinetools/img...

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

შეკრება ვერფში

ასე რომ, ჩვენ მივიღეთ ვერფ (ადრე ცნობილი მოსწონს dapp) — ღია კოდის პროგრამა ფლანტის კომპანიისგან, რომელსაც მრავალი წელია ვამზადებთ. ყველაფერი 5 წლის წინ დაიწყო Bash სკრიპტებით, რომლებიც ოპტიმიზებდნენ Dockerfiles-ის აწყობას და ბოლო 3 წლის განმავლობაში სრულფასოვანი განვითარება განხორციელდა ერთი პროექტის ფარგლებში საკუთარი Git საცავით. (ჯერ Ruby-ში და შემდეგ გადაწერილი на Go, а заодно и переименовали). რა ასამბლეის საკითხები წყდება ვერფში?

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

Стадия публикации в registry (publish)

ავკრიფეთ docker push... - რა შეიძლება იყოს რთული სურათის რეესტრში ატვირთვა? და შემდეგ ჩნდება კითხვა: "რა ტეგი უნდა დავაყენო სურათზე?" ეს წარმოიქმნება იმ მიზეზით, რაც ჩვენ გვაქვს გიტფლოუ (или другая стратегия Git’а) и Kubernetes, а индустрия стремится к тому, чтобы происходящее в Kubernetes следовало тому, что делается в Git. Ведь Git — наш единственный источник правды.

რა არის ამაში რთული? უზრუნველყოს განმეორებადობა: გიტში ჩადენიდან, რომელიც ბუნებით უცვლელია (immutable), დოკერის სურათზე, რომელიც უნდა დარჩეს იგივე.

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

სტრატეგიების მონიშვნა

პირველი მარტივია გიტის დღე. ჩვენ გვაქვს რეესტრი, რომელზეც სურათი არის მონიშნული როგორც 1.0. Kubernetes-ს აქვს სცენა და წარმოება, სადაც ეს სურათი აიტვირთება. Git-ში ვაკეთებთ ვალდებულებებს და რაღაც მომენტში თეგირებით 2.0. ჩვენ ვაგროვებთ მას საცავის ინსტრუქციის მიხედვით და ვათავსებთ რეესტრში ტეგით 2.0. Выкатываем на stage и, если всё хорошо, потом на production.

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

მეორე ვარიანტი - git commit + tag. სამაგისტრო ფილიალს აქვს ტეგი 1.0; მას რეესტრში - გამოსახულება განლაგებულია წარმოებაში. გარდა ამისა, Kubernetes კლასტერს აქვს გადახედვისა და დადგმის კონტურები. შემდეგ ჩვენ მივყვებით Gitflow: განვითარების მთავარ ფილიალში (develop) ჩვენ ვქმნით ახალ ფუნქციებს, რის შედეგადაც ვიღებთ ვალდებულებას იდენტიფიკატორით #c1. ჩვენ ვაგროვებთ მას და ვაქვეყნებთ მას რეესტრში ამ იდენტიფიკატორის გამოყენებით (#c1). იგივე იდენტიფიკატორით ჩვენ გავაფართოვებთ წინასწარ გადახედვას. ჩვენ იგივე ვაკეთებთ ვალდებულებებს #c2 и #c3.

როდესაც მივხვდით, რომ საკმარისი ფუნქციებია, ვიწყებთ ყველაფრის სტაბილიზაციას. შექმენით ფილიალი Git-ში release_1.1 (ბაზაზე #c3 საქართველოს develop). არ არის საჭირო ამ გამოშვების შეგროვება, რადგან... ეს გაკეთდა წინა ეტაპზე. ამიტომ, ჩვენ შეგვიძლია უბრალოდ გავაფართოვოთ ის დადგმაზე. ჩვენ ვასწორებთ შეცდომებს #c4 და ანალოგიურად გააფართოვოს დადგმა. პარალელურად მიმდინარეობს განვითარება develop, საიდანაც პერიოდულად ხდება ცვლილებების აღება release_1.1. В какой-то момент получаем собранный и выкаченный на staging коммит, которым мы довольны (#c25).

შემდეგ ვაერთებთ (სწრაფად წინსვლას) გამოშვების ტოტი (release_1.1) მასტერში. ჩვენ დავაყენეთ ტეგი ახალი ვერსიით ამ commit-ზე (1.1). მაგრამ ეს სურათი უკვე შეგროვებულია რეესტრში, ამიტომ იმისათვის, რომ აღარ შევაგროვოთ იგი, ჩვენ უბრალოდ ვამატებთ მეორე ტეგს არსებულ სურათს (ახლა მას აქვს ტეგები რეესტრში #c25 и 1.1). ამის შემდეგ, ჩვენ გავაფართოვოთ იგი წარმოებაში.

Есть недостаток, что на staging выкачен один образ (#c25), და წარმოებაში ეს რაღაცნაირად განსხვავებულია (1.1), მაგრამ ჩვენ ვიცით, რომ "ფიზიკურად" ეს არის იგივე სურათი რეესტრიდან.

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

ჩვენ შეგვიძლია წავიდეთ უფრო შორს და გავაკეთოთ ხრიკი... მოდით შევხედოთ მარტივი Dockerfile-ის მაგალითს:

FROM ruby:2.3 as assets
RUN mkdir -p /app
WORKDIR /app
COPY . ./
RUN gem install bundler && bundle install
RUN bundle exec rake assets:precompile
CMD bundle exec puma -C config/puma.rb

FROM nginx:alpine
COPY --from=assets /app/public /usr/share/nginx/www/public

ავაშენოთ ფაილი მისგან შემდეგი პრინციპის მიხედვით:

• SHA256 გამოყენებული სურათების იდენტიფიკატორებიდან (ruby:2.3 и nginx:alpine), რომლებიც წარმოადგენს მათი შინაარსის საკონტროლო ჯამებს;
• все команды (RUN, CMD და ასე შემდეგ.);
• SHA256 ფაილებიდან, რომლებიც დამატებულია.

… и возьмём контрольную сумму (снова SHA256) от такого файла. Это ხელმოწერა ყველაფერი, რაც განსაზღვრავს Docker გამოსახულების შინაარსს.

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

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

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

მონიშვნა werf-ში

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

werf Git საცავი ინახავს build-ის სპეციფიკურ ინსტრუქციებს, რომლებიც აღწერს მშენებლობის სხვადასხვა ეტაპებს (ინსტალაციამდე, ინსტალაცია, დაყენებამდე, setup). ჩვენ ვაგროვებთ პირველი ეტაპის სურათს ხელმოწერით, რომელიც განისაზღვრება, როგორც პირველი ნაბიჯების საკონტროლო ჯამი. შემდეგ ვამატებთ საწყის კოდს, ახალი ეტაპის გამოსახულებაზე ვიანგარიშებთ მის საკონტროლო ჯამს... ეს ოპერაციები მეორდება ყველა საფეხურზე, რის შედეგადაც ვიღებთ ეტაპების გამოსახულების კომპლექტს. შემდეგ ვაკეთებთ საბოლოო სურათს, რომელიც ასევე შეიცავს მეტამონაცემებს მისი წარმოშობის შესახებ. და ჩვენ ამ სურათს სხვადასხვა გზით ვსვამთ (დეტალები მოგვიანებით).

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

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

რეესტრის გაწმენდა

ჩვენ არ ვსაუბრობთ ფენების წაშლაზე, რომლებიც ჩამოკიდებული დარჩა წაშლილი ტეგების შემდეგ - ეს არის თავად Docker Registry-ის სტანდარტული ფუნქცია. ჩვენ ვსაუბრობთ სიტუაციაზე, როდესაც უამრავი Docker ტეგი გროვდება და გვესმის, რომ ზოგიერთი მათგანი აღარ გვჭირდება, მაგრამ ისინი ადგილს იკავებენ (ან/და ჩვენ ვიხდით მას).

რა არის დასუფთავების სტრატეგიები?

1. უბრალოდ არაფერი შეგიძლია არ გაასუფთავო. ზოგჯერ მართლაც უფრო ადვილია ზედმეტი სივრცისთვის ცოტა გადაიხადო, ვიდრე ტეგების უზარმაზარი აურზაურის ამოხსნა. მაგრამ ეს მუშაობს მხოლოდ გარკვეულ მომენტამდე.
2. სრული გადატვირთვა. თუ წაშლით ყველა სურათს და აღადგენთ მხოლოდ მიმდინარე სურათებს CI სისტემაში, შეიძლება წარმოიშვას პრობლემა. თუ კონტეინერი ხელახლა დაიწყება წარმოებაში, მისთვის ახალი სურათი ჩაიტვირთება - ისეთი, რომელიც ჯერ არავის მიერ არ არის გამოცდილი. ეს კლავს უცვლელი ინფრასტრუქტურის იდეას.
3. Ლურჯი მწვანე. ერთმა რეესტრმა დაიწყო გადატვირთვა - ჩვენ ავტვირთავთ სურათებს მეორეში. იგივე პრობლემა, როგორც წინა მეთოდით: რა მომენტში შეგიძლიათ გაასუფთავოთ რეესტრი, რომელმაც დაიწყო გადატვირთვა?
4. დროთა განმავლობაში. წაშალოთ 1 თვეზე ძველი ყველა სურათი? მაგრამ აუცილებლად იქნება სერვისი, რომელიც ერთი თვეა არ განახლებულა...
5. ხელით განსაზღვრეთ რა შეიძლება უკვე წაიშალოს.

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

რა მივედით ვერფ? ჩვენ ვაგროვებთ:

1. Git head: ყველა ტეგი, ყველა ფილიალი - ვივარაუდოთ, რომ ჩვენ გვჭირდება ყველაფერი, რაც Git-შია მონიშნული სურათებში (და თუ არა, მაშინ ის თავად Git-ში უნდა წავშალოთ);
2. ყველა ჯიში, რომელიც ამჟამად ამოტუმბულია Kubernetes-ში;
3. ძველი ReplicaSets (რაც ახლახან გამოვიდა), და ჩვენ ასევე ვგეგმავთ Helm-ის გამოშვებების სკანირებას და იქ უახლესი სურათების შერჩევას.

… и делаем из этого набора whitelist — список образов, которые мы не будем удалять. Всё остальное вычищаем, после чего находим сиротские stage-образы и удаляем их тоже.

განლაგების ეტაპი

სანდო დეკლარაციულობა

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

1. იდენტიფიკატორები;
2. служебную информацию;
3. ბევრი ნაგულისხმევი მნიშვნელობა;
4. განყოფილება მიმდინარე სტატუსით;
5. დაშვების ვებ გვერდის ფარგლებში განხორციელებული ცვლილებები;
6. სხვადასხვა კონტროლერების (და გრაფიკის) მუშაობის შედეგი.

Поэтому, когда появляется новая конфигурация ресурса (ახალი), ჩვენ არ შეგვიძლია უბრალოდ ავიღოთ და გადავწეროთ მიმდინარე, „ცოცხალი“ კონფიგურაცია მასთან (ცხოვრება). ამისათვის ჩვენ მოგვიწევს შედარება ახალი ბოლო გამოყენებული კონფიგურაციით (ბოლო-გამოყენებული) და გადაახვიეთ ცხოვრება მიღებული პაჩი.

ამ მიდგომას ე.წ ორმხრივი შერწყმა. იგი გამოიყენება, მაგალითად, ჰელმში.

Არსებობს ასევე ორმხრივი შერწყმა, который отличается тем, что:

• შედარება ბოლო-გამოყენებული и ახალი, ვუყურებთ რა წაშლილია;
• შედარება ახალი и ცხოვრება, ვუყურებთ რა დაემატა ან შეიცვალა;
• შეჯამებული პაჩი გამოიყენება ცხოვრება.

ჩვენ ვაყენებთ 1000+ აპლიკაციას Helm-ით, ასე რომ, ჩვენ რეალურად ვცხოვრობთ 2-მხრივ შერწყმით. თუმცა, მას აქვს მთელი რიგი პრობლემები, რომლებიც ჩვენ მოვაგვარეთ ჩვენი პატჩებით, რაც ეხმარება ჰელმს ნორმალურად მუშაობაში.

რეალური გაშვების სტატუსი

მას შემდეგ, რაც ჩვენი CI სისტემა წარმოქმნის ახალ კონფიგურაციას Kubernetes-ისთვის შემდეგი მოვლენის საფუძველზე, ის გადასცემს მას გამოსაყენებლად (მიმართე) კლასტერამდე - Helm ან kubectl apply. Далее происходит уже описанный N-way merge, на что Kubernetes API одобрительно отвечает CI-системе, а та — своему пользователю.

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

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

ამ ტრეკერის ქცევა werf დონეზე კონფიგურირებულია ანოტაციების გამოყენებით, რომლებიც განთავსებულია Deployments ან StatefulSets. მთავარი ანოტაცია - fail-mode - ესმის შემდეგი მნიშვნელობები:

• IgnoreAndContinueDeployProcess — игнорируем проблемы выката этого компонента и продолжаем деплой;
• FailWholeDeployProcessImmediately — ამ კომპონენტში შეცდომა აჩერებს განლაგების პროცესს;
• HopeUntilEndOfDeployProcess — ვიმედოვნებთ, რომ ეს კომპონენტი განლაგების ბოლომდე იმუშავებს.

მაგალითად, რესურსებისა და ანოტაციის მნიშვნელობების ეს კომბინაცია fail-mode:

როდესაც ჩვენ პირველად განვათავსებთ, მონაცემთა ბაზა (MongoDB) შეიძლება ჯერ არ იყოს მზად - განლაგება ვერ მოხერხდება. მაგრამ შეგიძლიათ დაელოდოთ მის დაწყებას და განლაგება მაინც მოხდება.

არსებობს კიდევ ორი ​​ანოტაცია კუბედოგისთვის werf-ში:

• failures-allowed-per-replica - დაშვებული ვარდნის რაოდენობა თითოეულ რეპლიკაზე;
• show-logs-until — არეგულირებს იმ მომენტს, სანამ werf აჩვენებს (stdout-ში) ჟურნალებს ყველა გაშლილი ჯიშიდან. ნაგულისხმევი არის PodIsReady (იმ შეტყობინებების იგნორირება, რომლებიც ალბათ არ გვინდა, როდესაც ტრაფიკი იწყება პოდზე), მაგრამ მნიშვნელობები ასევე მოქმედებს: ControllerIsReady и EndOfDeploy.

კიდევ რა გვინდა განლაგებისგან?

უკვე აღწერილი ორი პუნქტის გარდა, ჩვენ გვსურს:

• სანახავად მორები - და მხოლოდ საჭირო და არა ყველაფერი ზედიზედ;
• კვალს პროგრესი, потому что если job «молча» висит несколько минут, важно понимать, что там происходит;
• აქვს ავტომატური დაბრუნება თუ რამე არასწორედ წარიმართა (და, შესაბამისად, მნიშვნელოვანია იცოდეთ განლაგების რეალური სტატუსი). გაშვება უნდა იყოს ატომური: ან გადის ბოლომდე, ან ყველაფერი უბრუნდება თავის წინა მდგომარეობას.

შედეგები

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

დასკვნის ნაცვლად:

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

ვიდეოები და სლაიდები

ვიდეო სპექტაკლიდან (~47 წუთი):

ანგარიშის პრეზენტაცია:

PS

სხვა მოხსენებები Kubernetes-ის შესახებ ჩვენს ბლოგზე:

• «ავტომატური მასშტაბირება და რესურსების მართვა Kubernetes-ში» (დიმიტრი სტოლიაროვი; 27 წლის 2019 აპრილი "Strike");
• «Kubernetes-ის გაფართოება და შევსება» (ანდრეი პოლოვოვი; 8 წლის 2019 აპრილი Saint HighLoad++-ზე);
• «მონაცემთა ბაზები და კუბერნეტები» (დმიტრი სტოლიაროვი; 8 წლის 2018 ნოემბერი HighLoad++-ზე);
• «მონიტორინგი და კუბერნეტები» (დმიტრი სტოლიაროვი; 28 წლის 2018 მაისი RootConf-ზე);
• «CI/CD საუკეთესო პრაქტიკა Kubernetes-თან და GitLab-თან» (დმიტრი სტოლიაროვი; 7 წლის 2017 ნოემბერი HighLoad++-ზე);
• «ჩვენი გამოცდილება Kubernetes-თან მცირე პროექტებში» (დმიტრი სტოლიაროვი; 6 წლის 2017 ივნისი RootConf-ზე).

წყარო: www.habr.com