Овладяване на задачата за внедряване в GKE без добавки, SMS и регистрация. С едно око гледаме под сакото на Дженкинс

Всичко започна, когато ръководителят на един от нашите екипи за разработка ни помоли да тестваме тяхното ново приложение, което беше контейнеризирано предишния ден. Публикувах го. След около 20 минути се получи заявка за актуализиране на приложението, тъй като там беше добавено нещо много необходимо. поднових. След още няколко часа... е, можете да познаете какво започна да се случва след това...

Трябва да призная, че съм доста мързелив (не го ли признах по-рано? Не?) и предвид факта, че ръководителите на екипи имат достъп до Jenkins, в който имаме всички CI/CD, си помислих: нека го разположи като колкото иска! Спомних си един виц: дай на човек риба и той ще яде за един ден; наречете човек Fed и той ще бъде Fed през целия си живот. И отиде играйте номера на работа, който би могъл да разположи контейнер, съдържащ приложението на всяка успешно изградена версия в Kuber и да прехвърли всякакви стойности към него ENV (дядо ми, филолог, учител по английски в миналото, сега щеше да върти пръст на слепоочието си и да ме погледне много изразително, след като прочете това изречение).

И така, в тази бележка ще ви кажа как научих:

1. Динамично актуализиране на задания в Jenkins от самото задание или от други задания;
2. Свържете се с облачната конзола (Cloud shell) от възел с инсталиран агент Jenkins;
3. Разположете работното натоварване в Google Kubernetes Engine.

Всъщност, разбира се, съм малко неискрен. Предполага се, че имате поне част от инфраструктурата в облака на Google и следователно сте негов потребител и, разбира се, имате GCP акаунт. Но тази бележка не е за това.

Това е следващият ми измамник. Искам да напиша такива бележки само в един случай: бях изправен пред проблем, първоначално не знаех как да го реша, решението не беше гугъл готово, така че го гугъл на части и в крайна сметка реших проблема. И така, че в бъдеще, когато забравя как съм го направил, не се налага да търся всичко отново част по част и да го компилирам заедно, аз си пиша такива измамни листове.

Опровержение: 1. Бележката е написана „за себе си“, за ролята най-добри практики не се прилага. Щастлив съм да прочета опциите „би било по-добре да го направя по този начин“ в коментарите.
2. Ако нанесената част от нотката се счита за сол, то, както всичките ми предишни нотки, тази е слаб солен разтвор.

Динамично актуализиране на настройките за работа в Jenkins

Предвиждам въпроса ви: какво общо има с това динамичното актуализиране на работата? Въведете стойността на низовия параметър ръчно и тръгвайте!

Отговарям: наистина съм мързелив, не ми харесва, когато се оплакват: Миша, внедряването се срива, всичко е изчезнало! Започвате да търсите и има правописна грешка в стойността на някакъв параметър за стартиране на задача. Затова предпочитам да правя всичко възможно най-ефективно. Ако е възможно да се попречи на потребителя да въвежда данни директно, като вместо това се даде списък със стойности, от които да избирате, тогава аз организирам избора.

Планът е следният: създаваме работа в Jenkins, в която преди стартиране можем да изберем версия от списъка, да посочим стойности за параметри, предадени на контейнера чрез ENV, след което събира контейнера и го избутва в регистъра на контейнерите. След това оттам контейнерът се пуска в cuber as натовареността с параметрите посочени в заданието.

Няма да разглеждаме процеса на създаване и настройка на работа в Jenkins, това не е по темата. Ще приемем, че задачата е готова. За да внедрим актуализиран списък с версии, имаме нужда от две неща: съществуващ списък с източници с априори валидни номера на версиите и променлива като Параметър за избор в задачата. В нашия пример нека променливата е именувана BUILD_VERSION, няма да се спираме подробно на него. Но нека разгледаме по-отблизо списъка с източници.

Няма толкова много опции. Веднага ми хрумнаха две неща:

• Използвайте API за отдалечен достъп, който Jenkins предлага на своите потребители;
• Поискайте съдържанието на папката на отдалеченото хранилище (в нашия случай това е JFrog Artifactory, което не е важно).

API за отдалечен достъп на Jenkins

Според установената отлична традиция бих предпочел да избегна дългите обяснения.
Ще си позволя само свободен превод на част от първия параграф първа страница от документацията на API:

Jenkins предоставя 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']

Екранна снимка на списъка с неуспешни

Списък с версии от папка на отдалечен сървър

Има и втори начин за получаване на списък с версии. Харесва ми дори повече от достъпа до Jenkins API. Е, защото ако приложението е било успешно изградено, това означава, че е било пакетирано и поставено в хранилището в съответната папка. Например, хранилището е хранилището по подразбиране на работещи версии на приложения. Като. Е, нека го попитаме какви версии има в хранилището. Ще curl, grep и awk отдалечената папка. Ако някой се интересува от oneliner, то той е под спойлера.

Команда от един ред
Моля, обърнете внимание на две неща: предавам подробностите за връзката в заглавката и не се нуждая от всички версии от папката и избирам само тези, които са създадени в рамките на един месец. Редактирайте командата, за да отговаря на вашите реалности и нужди:

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[^/]+' )

Настройване на задания и конфигурационен файл на задание в Jenkins

Разбрахме източника на списъка с версии. Нека сега включим получения списък в задачата. За мен очевидното решение беше да добавя стъпка в задачата за изграждане на приложение. Стъпката, която ще бъде изпълнена, ако резултатът е "успех".

Отворете настройките на задачата за сглобяване и превъртете до самото дъно. Кликнете върху бутоните: Добавете стъпка на изграждане -> Условна стъпка (единична). В настройките на стъпката изберете условието Текущо състояние на компилация, задайте стойността УСПЕХ, действието, което трябва да се извърши при успех Изпълнете командата на обвивката.

А сега забавната част. Jenkins съхранява конфигурациите на задачите във файлове. В 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

Ако предпочитате опцията да получите версии от Jenkins и сте мързеливи като мен, тогава под спойлера е същият код, но списък от Jenkins:

Напишете списък с версии от Дженкинс в конфигурацията
Просто имайте това предвид: моето име на сборка се състои от пореден номер и номер на версия, разделени с двоеточие. Съответно 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

На теория, ако сте тествали кода, написан въз основа на примерите по-горе, тогава в задачата за внедряване вече трябва да имате падащ списък с версии. Това е като на екранната снимка под спойлера.

Правилно попълнен списък с версии

Ако всичко работи, копирайте и поставете скрипта в Изпълнете командата на обвивката и запазете промените.

Свързване към Cloud shell

Разполагаме с колектори в контейнери. Ние използваме Ansible като наш инструмент за доставка на приложения и конфигурационен мениджър. Съответно, когато става въпрос за изграждане на контейнери, три опции идват на ум: инсталиране на Docker в Docker, инсталиране на Docker на машина, работеща с Ansible, или изграждане на контейнери в облачна конзола. Съгласихме се да запазим мълчание относно плъгините за Jenkins в тази статия. Помня?

Реших: добре, тъй като контейнерите „извън кутията“ могат да се събират в облачната конзола, тогава защо да се притеснявате? Пазете го чисто, нали? Искам да събера контейнери на Дженкинс в облачната конзола и след това да ги стартирам в куба от там. Освен това Google има много богати канали в своята инфраструктура, което ще има благоприятен ефект върху скоростта на внедряване.

За да се свържете с облачната конзола, имате нужда от две неща: gcloud и права за достъп до Google Cloud API за VM екземпляра, от който ще бъде направена същата връзка.

За тези, които планират да се свържат изобщо не от облака на Google
Google допуска възможността за деактивиране на интерактивното оторизиране в своите услуги. Това ще ви позволи да се свържете с конзолата дори от кафе машина, ако тя работи с *nix и има самата конзола.

Ако има нужда да разгледам този въпрос по-подробно в рамките на тази бележка, пишете в коментарите. Ако получим достатъчно гласове, ще напиша актуализация по тази тема.

Най-лесният начин за предоставяне на права е чрез уеб интерфейса.

1. Спрете VM екземпляра, от който впоследствие ще се свържете с облачната конзола.
2. Отворете Подробности за екземпляра и щракнете изменят.
3. В най-долната част на страницата изберете обхвата на достъп до екземпляра Пълен достъп до всички облачни API.

   снимки
   

4. Запазете промените си и стартирайте екземпляра.

След като VM приключи със зареждането, свържете се с него чрез SSH и се уверете, че връзката се осъществява без грешка. Използвайте командата:

gcloud alpha cloud-shell ssh

Успешната връзка изглежда по следния начин

Разположете в GKE

Тъй като се стремим по всякакъв възможен начин да преминем изцяло към IaC (Инфраструктура като код), нашите докер файлове се съхраняват в Git. Това е от една страна. И внедряването в kubernetes се описва от yaml файл, който се използва само от тази задача, която сама по себе си също е като код. Това е от другата страна. Общо взето планът е следният:

1. Взимаме стойностите на променливите BUILD_VERSION и, по избор, стойностите на променливите, които ще бъдат предадени ENV.
2. Изтеглете docker файла от Git.
3. Генерирайте yaml за внедряване.
4. Ние качваме и двата файла чрез scp в облачната конзола.
5. Създаваме контейнер там и го поставяме в регистъра на контейнерите
6. Прилагаме файла за разгръщане на натоварването към cuber.

Нека бъдем по-конкретни. След като започнахме да говорим за ENV, тогава да предположим, че трябва да предадем стойностите на два параметъра: ПАРАМЕТР1 и ПАРАМЕТР2. Добавяме тяхната задача за внедряване, тип - Параметър на низ.

снимки

Ще генерираме yaml с просто пренасочване ехо да подаде. Предполага се, разбира се, че имате във вашия докер файл ПАРАМЕТР1 и ПАРАМЕТР2че името на товара ще бъде страхотно приложение, а сглобеният контейнер с приложението на посочената версия лежи вътре Регистър на контейнери по пътя 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

Агент на Jenkins след свързване с помощта gcloud алфа облачна обвивка ssh интерактивният режим не е наличен, така че изпращаме команди към облачната конзола, използвайки параметъра -- команда.

Почистваме домашната папка в облачната конзола от стария dockerfile:

gcloud alpha cloud-shell ssh --command="rm -f 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"

Правим същото с файла за внедряване. Моля, обърнете внимание, че командите по-долу използват измислени имена на клъстера, където се извършва внедряването (awsm-клъстер) и име на проекта (страхотен проект), където се намира клъстерът.

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"

Изпълняваме задачата, отваряме изхода на конзолата и се надяваме да видим успешното сглобяване на контейнера.

снимки

И след това успешното разгръщане на сглобения контейнер

снимки

Нарочно пренебрегнах настройката Влизане. Поради една проста причина: след като го настроите натовареността с дадено име, той ще остане работещ, без значение колко внедрявания с това име извършите. Е, като цяло това е малко извън рамките на историята.

Вместо заключения

Всички горни стъпки вероятно не биха могли да бъдат направени, а просто да инсталирате някакъв плъгин за Jenkins, техния muuulion. Но по някаква причина не харесвам плъгини. Ами по-точно прибягвам до тях само от отчаяние.

И просто обичам да подхвана някоя нова тема за мен. Текстът по-горе е и начин да споделя констатациите, които направих при решаването на проблема, описан в самото начало. Споделете с тези, които като него изобщо не са страшен вълк в devops. Ако моите открития помогнат поне на някого, ще се радвам.

Източник: www.habr.com