ჩვენ ვქმნით განლაგების დავალებას GKE-ში დანამატების, SMS-ების ან რეგისტრაციის გარეშე. მოდი, ჯენკინსის ქურთუკის ქვეშ გადავხედოთ

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

უნდა ვაღიარო, რომ საკმაოდ ზარმაცი ვარ (ეს ადრე არ ვაღიარე? არა?) და იმის გათვალისწინებით, რომ გუნდის ლიდერებს აქვთ წვდომა ჯენკინსზე, რომელშიც ჩვენ გვაქვს ყველა CI/CD, გავიფიქრე: დაე, განლაგდეს როგორც რამდენიც მას სურს! ერთი ხუმრობა გამახსენდა: კაცს თევზი მიეცი და ერთი დღე შეჭამს; უწოდეთ ადამიანს Fed და ის იქნება ყელში მთელი ცხოვრება. და წავიდა ითამაშე ხრიკები სამუშაოზე, რომელიც შეძლებს Kuber-ში განათავსოს კონტეინერი, რომელიც შეიცავს ნებისმიერი წარმატებით ჩაშენებული ვერსიის აპლიკაციას და გადაიტანოს მასში ნებისმიერი მნიშვნელობა ენვ (ბაბუაჩემი, ფილოლოგი, წარსულში ინგლისური ენის მასწავლებელი, ახლა თითს ატრიალებდა ტაძარში და ამ წინადადების წაკითხვის შემდეგ ძალიან ექსპრესიულად მიყურებდა).

ასე რომ, ამ ჩანაწერში გეტყვით, როგორ ვისწავლე:

1. Jenkins-ში სამუშაოების დინამიურად განახლება თავად სამუშაოდან ან სხვა სამუშაოებიდან;
2. დაკავშირება ღრუბლის კონსოლთან (Cloud shell) კვანძიდან დაინსტალირებული ჯენკინსის აგენტით;
3. განათავსეთ დატვირთვა Google Kubernetes Engine-ზე.

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

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

პასუხისმგებლობის შეზღუდვის განაცხადი: 1. შენიშვნა ეწერა „ჩემთვის“, როლისთვის საუკეთესო პრაქტიკა არ ვრცელდება. მოხარული ვარ, რომ წავიკითხე კომენტარებში "უმჯობესი იქნებოდა ასე გამეკეთებინა".
2. თუ ნოტის გამოყენებული ნაწილი ითვლება მარილით, მაშინ, როგორც ყველა ჩემი წინა შენიშვნა, ეს არის სუსტი მარილის ხსნარი.

Jenkins-ში სამუშაო პარამეტრების დინამიურად განახლება

მე ვგეგმავ თქვენს შეკითხვას: რა შუაშია სამუშაოს დინამიური განახლება? ხელით შეიყვანეთ სიმებიანი პარამეტრის მნიშვნელობა და წადით!

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

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

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

ამდენი ვარიანტი არ არის. ორი რამ მაშინვე გამახსენდა:

• გამოიყენეთ დისტანციური წვდომის API, რომელსაც ჯენკინსი სთავაზობს მომხმარებლებს;
• მოითხოვეთ დისტანციური საცავის საქაღალდის შინაარსი (ჩვენს შემთხვევაში ეს არის JFrog Artifactory, რაც არ არის მნიშვნელოვანი).

Jenkins Remote Access API

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

ჯენკინსი უზრუნველყოფს API-ს დისტანციური მანქანით წაკითხვადი წვდომისთვის მის ფუნქციონირებაზე. <…> დისტანციური წვდომა შემოთავაზებულია REST-ის მსგავსი სტილით. ეს ნიშნავს, რომ არ არის ერთი შესვლის წერტილი ყველა მახასიათებლში, არამედ URL, როგორიცაა ".../api/"სად"..." ნიშნავს ობიექტს, რომელზეც გამოიყენება API შესაძლებლობები.

სხვა სიტყვებით რომ ვთქვათ, თუ განლაგების ამოცანა, რომელზეც ამჟამად ვსაუბრობთ, ხელმისაწვდომია http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build, მაშინ ამ ამოცანის API სასტვენები ხელმისაწვდომია აქ http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/

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

მოდით შევეცადოთ მივიღოთ ყველა სამუშაოს სია. ჩვენ მხოლოდ ასამბლეის სახელი გვაინტერესებს (ჩვენების სახელი) და მისი შედეგი (შედეგად):

http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]

შეიმუშავეს?

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

http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]&exclude=freeStyleProject/allBuild[result!='SUCCESS']

წარმატებულთა სიის სკრინშოტი

ისე, უბრალოდ გასართობად, მოდით დავრწმუნდეთ, რომ ფილტრმა არ მოგვატყუა (ფილტრები არასოდეს იტყუებიან!) და გამოვაჩინოთ "წარუმატებლების" სია:

http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]&exclude=freeStyleProject/allBuild[result='SUCCESS']

წარუმატებელთა სიის სკრინშოტი

ვერსიების სია დისტანციური სერვერის საქაღალდედან

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

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

curl -H "X-JFrog-Art-Api:VeryLongAPIKey" -s http://arts.myre.po/artifactory/awesomeapp/ | sed 's/a href=//' | grep "$(date +%b)-$(date +%Y)|$(date +%b --date='-1 month')-$(date +%Y)" | awk '{print $1}' | grep -oP '>K[^/]+' )

სამუშაოების და სამუშაოს კონფიგურაციის ფაილის დაყენება ჯენკინსში

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

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

ახლა კი სახალისო ნაწილი. ჯენკინსი ინახავს სამუშაოს კონფიგურაციებს ფაილებში. XML ფორმატში. გზად http://путь-до-задания/config.xml შესაბამისად, შეგიძლიათ ჩამოტვირთოთ კონფიგურაციის ფაილი, დაარედაქტიროთ ის საჭიროებისამებრ და დააბრუნოთ იქ, სადაც მიიღეთ.

გახსოვდეთ, ზემოთ შევთანხმდით, რომ შევქმნით პარამეტრს ვერსიების სიისთვის BUILD_VERSION?

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

სკრინშოტი სპოილერის ქვეშ.

თქვენი config.xml ფრაგმენტი ერთნაირად უნდა გამოიყურებოდეს. გარდა იმისა, რომ არჩევანის ელემენტის შინაარსი ჯერ არ არის დაკარგული

Დარწმუნებული ხარ? ესე იგი, დავწეროთ სკრიპტი, რომელიც შესრულდება, თუ ბილდინგი წარმატებული იქნება.
სკრიპტი მიიღებს ვერსიების ჩამონათვალს, ჩამოტვირთავს კონფიგურაციის ფაილს, ჩაწერს მასში ვერსიების ჩამონათვალს ჩვენთვის საჭირო ადგილას და შემდეგ დააბრუნებს. დიახ. Სწორია. ჩაწერეთ ვერსიების სია XML-ში იმ ადგილას, სადაც უკვე არის ვერსიების სია (მომავალში იქნება, სკრიპტის პირველი გაშვების შემდეგ). მე ვიცი, რომ მსოფლიოში ჯერ კიდევ არიან რეგულარული გამონათქვამების სასტიკი თაყვანისმცემლები. მე მათ არ ვეკუთვნი. გთხოვთ დააინსტალიროთ xmlstarler მანქანაზე, სადაც კონფიგურაციის რედაქტირება მოხდება. მეჩვენება, რომ ეს არც ისე დიდი ფასია, რათა თავიდან აიცილოთ XML რედაქტირება sed-ის გამოყენებით.

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

ჩაწერეთ ვერსიების სია დისტანციური სერვერის საქაღალდედან კონფიგურაციამდე

#!/bin/bash
############## Скачиваем конфиг
curl -X GET -u username:apiKey http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_k8s/config.xml -o appConfig.xml

############## Удаляем и заново создаем xml-элемент для списка версий
xmlstarlet ed --inplace -d '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a[@class="string-array"]' appConfig.xml

xmlstarlet ed --inplace --subnode '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]' --type elem -n a appConfig.xml

xmlstarlet ed --inplace --insert '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a' --type attr -n class -v string-array appConfig.xml

############## Читаем в массив список версий из репозитория
readarray -t vers < <( curl -H "X-JFrog-Art-Api:Api:VeryLongAPIKey" -s http://arts.myre.po/artifactory/awesomeapp/ | sed 's/a href=//' | grep "$(date +%b)-$(date +%Y)|$(date +%b --date='-1 month')-$(date +%Y)" | awk '{print $1}' | grep -oP '>K[^/]+' )

############## Пишем массив элемент за элементом в конфиг
printf '%sn' "${vers[@]}" | sort -r | 
                while IFS= read -r line
                do
                    xmlstarlet ed --inplace --subnode '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a[@class="string-array"]' --type elem -n string -v "$line" appConfig.xml
                done

############## Кладем конфиг взад
curl -X POST -u username:apiKey http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_k8s/config.xml --data-binary @appConfig.xml

############## Приводим рабочее место в порядок
rm -f appConfig.xml

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

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

#!/bin/bash
############## Скачиваем конфиг
curl -X GET -u username:apiKey http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_k8s/config.xml -o appConfig.xml

############## Удаляем и заново создаем xml-элемент для списка версий
xmlstarlet ed --inplace -d '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a[@class="string-array"]' appConfig.xml

xmlstarlet ed --inplace --subnode '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]' --type elem -n a appConfig.xml

xmlstarlet ed --inplace --insert '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a' --type attr -n class -v string-array appConfig.xml

############## Пишем в файл список версий из Jenkins
curl -g -X GET -u username:apiKey 'http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]&exclude=freeStyleProject/allBuild[result!=%22SUCCESS%22]&pretty=true' -o builds.xml

############## Читаем в массив список версий из XML
readarray vers < <(xmlstarlet sel -t -v "freeStyleProject/allBuild/displayName" builds.xml | awk -F":" '{print $2}')

############## Пишем массив элемент за элементом в конфиг
printf '%sn' "${vers[@]}" | sort -r | 
                while IFS= read -r line
                do
                    xmlstarlet ed --inplace --subnode '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a[@class="string-array"]' --type elem -n string -v "$line" appConfig.xml
                done

############## Кладем конфиг взад
curl -X POST -u username:apiKey http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_k8s/config.xml --data-binary @appConfig.xml

############## Приводим рабочее место в порядок
rm -f appConfig.xml

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

სწორად შევსებული ვერსიების სია

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

დაკავშირება Cloud shell-თან

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

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

ღრუბლოვან კონსოლთან დასაკავშირებლად საჭიროა ორი რამ: gcloud და წვდომის უფლებები Google Cloud API VM მაგალითისათვის, რომელთანაც იგივე კავშირი განხორციელდება.

მათთვის, ვინც გეგმავს დაკავშირებას არა Google ღრუბელიდან
Google იძლევა შესაძლებლობას გამორთოს ინტერაქტიული ავტორიზაცია თავის სერვისებში. ეს საშუალებას მოგცემთ დაუკავშირდეთ კონსოლს თუნდაც ყავის აპარატიდან, თუ ის მუშაობს *nix და აქვს კონსოლი.

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

უფლებების მინიჭების უმარტივესი გზაა ვებ ინტერფეისი.

1. შეაჩერე VM ინსტანცია, საიდანაც შემდგომში დაუკავშირდებით ღრუბლოვან კონსოლს.
2. გახსენით ინსტანციის დეტალები და დააწკაპუნეთ შეცვალოს.
3. გვერდის ბოლოში აირჩიეთ ინსტანციის წვდომის ფარგლები სრული წვდომა Cloud API-ზე.

   Screenshot
   

4. შეინახეთ ცვლილებები და გაუშვით ეგზემპლარი.

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

gcloud alpha cloud-shell ssh

წარმატებული კავშირი ასე გამოიყურება

განლაგება GKE-ზე

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

1. ჩვენ ვიღებთ ცვლადების მნიშვნელობებს BUILD_VERSION და სურვილისამებრ, ცვლადების მნიშვნელობები, რომლებზეც გადაიცემა ენვ.
2. ჩამოტვირთეთ dockerfile Git-დან.
3. შექმენით yaml განლაგებისთვის.
4. ჩვენ ვტვირთავთ ორივე ფაილს scp-ის საშუალებით ღრუბლოვან კონსოლში.
5. ჩვენ იქ ვაშენებთ კონტეინერს და ვაყენებთ კონტეინერების რეესტრში
6. ჩვენ ვიყენებთ დატვირთვის განლაგების ფაილს კუბერზე.

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

Screenshot

ჩვენ შევქმნით yaml-ს მარტივი გადამისამართებით echo შეიტანოს. რა თქმა უნდა, ვარაუდობენ, რომ თქვენ გაქვთ თქვენს dockerfile PARAM1 и PARAM2რომ დატვირთვის სახელი იქნება გასაოცარი აპლიკაცია, და აწყობილი კონტეინერი მითითებული ვერსიის აპლიკაციით დევს კონტეინერის რეესტრი გზაში gcr.io/awesomeapp/awesomeapp-$BUILD_VERSIONსად $BUILD_VERSION უბრალოდ არჩეული იყო ჩამოსაშლელი სიიდან.

გუნდის სია

touch deploy.yaml
echo "apiVersion: apps/v1" >> deploy.yaml
echo "kind: Deployment" >> deploy.yaml
echo "metadata:" >> deploy.yaml
echo "  name: awesomeapp" >> deploy.yaml
echo "spec:" >> deploy.yaml
echo "  replicas: 1" >> deploy.yaml
echo "  selector:" >> deploy.yaml
echo "    matchLabels:" >> deploy.yaml
echo "      run: awesomeapp" >> deploy.yaml
echo "  template:" >> deploy.yaml
echo "    metadata:" >> deploy.yaml
echo "      labels:" >> deploy.yaml
echo "        run: awesomeapp" >> deploy.yaml
echo "    spec:" >> deploy.yaml
echo "      containers:" >> deploy.yaml
echo "      - name: awesomeapp" >> deploy.yaml
echo "        image: gcr.io/awesomeapp/awesomeapp-$BUILD_VERSION:latest" >> deploy.yaml
echo "        env:" >> deploy.yaml
echo "        - name: PARAM1" >> deploy.yaml
echo "          value: $PARAM1" >> deploy.yaml
echo "        - name: PARAM2" >> deploy.yaml
echo "          value: $PARAM2" >> deploy.yaml

ჯენკინსის აგენტი დაკავშირების შემდეგ გამოყენება gcloud alpha cloud-shell ssh ინტერაქტიული რეჟიმი მიუწვდომელია, ამიტომ ჩვენ ვაგზავნით ბრძანებებს ღრუბლოვან კონსოლში პარამეტრის გამოყენებით -- ბრძანება.

ჩვენ ვასუფთავებთ სახლის საქაღალდეს ღრუბლოვან კონსოლში ძველი dockerfile-დან:

gcloud alpha cloud-shell ssh --command="rm -f Dockerfile"

მოათავსეთ ახლად გადმოწერილი dockerfile ღრუბლოვანი კონსოლის მთავარ საქაღალდეში scp-ის გამოყენებით:

gcloud alpha cloud-shell scp localhost:./Dockerfile cloudshell:~

ჩვენ ვაგროვებთ, მონიშნავთ და ვაყენებთ კონტეინერს კონტეინერების რეესტრში:

gcloud alpha cloud-shell ssh --command="docker build -t awesomeapp-$BUILD_VERSION ./ --build-arg BUILD_VERSION=$BUILD_VERSION --no-cache"
gcloud alpha cloud-shell ssh --command="docker tag awesomeapp-$BUILD_VERSION gcr.io/awesomeapp/awesomeapp-$BUILD_VERSION"
gcloud alpha cloud-shell ssh --command="docker push gcr.io/awesomeapp/awesomeapp-$BUILD_VERSION"

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

gcloud alpha cloud-shell ssh --command="rm -f deploy.yaml"
gcloud alpha cloud-shell scp localhost:./deploy.yaml cloudshell:~
gcloud alpha cloud-shell ssh --command="gcloud container clusters get-credentials awsm-cluster --zone us-central1-c --project awesome-project && 
kubectl apply -f deploy.yaml"

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

Screenshot

შემდეგ კი აწყობილი კონტეინერის წარმატებული განლაგება

Screenshot

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

დასკვნების ნაცვლად

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

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

წყარო: www.habr.com