Všetko to začalo, keď nás vedúci tímu jedného z našich vývojárskych tímov požiadal o testovanie ich novej aplikácie, ktorá bola deň predtým kontajnerizovaná. Zverejnil som to. Asi po 20 minútach prišla požiadavka na aktualizáciu aplikácie, pretože tam pribudla veľmi potrebná vec. obnovil som. Po ďalších pár hodinách... no, môžete hádať, čo sa začalo diať ďalej...
Musím sa priznať, som dosť lenivý (nepriznal som to skôr? Nie?) a vzhľadom na skutočnosť, že vedúci tímov majú prístup k Jenkinsovi, v ktorom máme všetky CI/CD, pomyslel som si: nech nasadí ako koľko chce! Spomenul som si na vtip: daj človeku rybu a bude jeden deň jesť; nazvite človeka Fedom a bude Fed celý život. A šiel hrať triky v práci, ktorý by dokázal do Kuberu nasadiť kontajner obsahujúci aplikáciu ľubovoľnej úspešne zabudovanej verzie a preniesť do neho ľubovoľné hodnoty ENV (môj starý otec, filológ, v minulosti učiteľ angličtiny, by teraz po prečítaní tejto vety krútil prstom na spánku a veľmi expresívne sa na mňa díval).
Takže v tejto poznámke vám poviem, ako som sa naučil:
- Dynamicky aktualizujte úlohy v Jenkins zo samotnej úlohy alebo z iných úloh;
- Pripojte sa ku cloudovej konzole (Cloud shell) z uzla s nainštalovaným agentom Jenkins;
- Nasaďte pracovné zaťaženie na Google Kubernetes Engine.
V skutočnosti som, samozrejme, trochu neúprimný. Predpokladá sa, že máte aspoň časť infraštruktúry v cloude Google, a teda ste jeho používateľom a samozrejme máte účet GCP. Ale o tom táto poznámka nie je.
Toto je môj ďalší cheat. Takéto poznámky chcem napísať len v jednom prípade: Stál som pred problémom, spočiatku som nevedel, ako ho vyriešiť, riešenie nebolo vygooglované hotové, tak som ho vygooglil po častiach a nakoniec problém vyriešil. A aby som v budúcnosti, keď zabudnem, ako som to urobil, nemusel všetko znova googliť po kúskoch a zostavovať to dokopy, píšem si takéto cheat sheety.
disclaimer: 1. Poznámka bola napísaná „pre seba“, pre rolu najlepšej praxe neplatí. Som rád, že si v komentároch prečítam možnosti „bolo by lepšie to urobiť takto“.
2. Ak sa aplikovaná časť poznámky považuje za soľ, potom, ako všetky moje predchádzajúce poznámky, aj táto je slabým soľným roztokom.
Dynamická aktualizácia nastavení úloh v Jenkins
Predvídam vašu otázku: čo s tým má spoločné dynamická aktualizácia zamestnania? Zadajte hodnotu parametra reťazca ručne a môžete začať!
Odpovedám: Som naozaj lenivý, nemám rád, keď sa sťažujú: Mišo, nasadenie padá, všetko je preč! Začnete hľadať a v hodnote niektorého parametra spustenia úlohy je preklep. Preto radšej robím všetko čo najefektívnejšie. Ak je možné zabrániť používateľovi v priamom zadávaní údajov tým, že namiesto toho poskytnem zoznam hodnôt, z ktorých si môže vybrať, potom výber organizujem.
Plán je takýto: v Jenkins vytvoríme úlohu, v ktorej by sme si pred spustením mohli vybrať verziu zo zoznamu, zadať hodnoty parametrov odovzdaných do kontajnera cez ENV, potom zhromaždí kontajner a vloží ho do registra kontajnerov. Potom sa kontajner spustí v cuber as pracovná záťaž s parametrami špecifikovanými v zákazke.
Nebudeme uvažovať o procese vytvárania a nastavovania práce v Jenkins, toto je mimo témy. Budeme predpokladať, že úloha je pripravená. Na implementáciu aktualizovaného zoznamu s verziami potrebujeme dve veci: existujúci zdrojový zoznam s a priori platnými číslami verzií a premennú ako Parameter výberu v úlohe. V našom príklade nech je premenná pomenovaná BUILD_VERSION, nebudeme sa tomu podrobne venovať. Poďme sa však bližšie pozrieť na zdrojový zoznam.
Nie je toľko možností. Hneď mi napadli dve veci:
- Použite API pre vzdialený prístup, ktoré Jenkins ponúka svojim používateľom;
- Vyžiadajte si obsah priečinka vzdialeného úložiska (v našom prípade je to JFrog Artifactory, čo nie je dôležité).
API pre vzdialený prístup Jenkins
Podľa ustálenej výbornej tradície by som sa zdĺhavému vysvetľovaniu radšej vyhol.
Dovolím si len voľný preklad kúska prvého odseku :
Jenkins poskytuje API pre vzdialený strojovo čitateľný prístup k jeho funkciám. <…> Vzdialený prístup je ponúkaný v štýle REST. To znamená, že neexistuje jediný vstupný bod pre všetky funkcie, ale namiesto toho adresa URL ako „.../api/", Kde "...“ znamená objekt, na ktorý sa aplikujú schopnosti API.
Inými slovami, ak je úloha nasadenia, o ktorej práve hovoríme, dostupná na http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build, potom sú API píšťalky pre túto úlohu dostupné na http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/
Ďalej máme na výber, v akej forme dostaneme výstup. Zamerajme sa na XML, keďže API v tomto prípade umožňuje iba filtrovanie.
Pokúsme sa získať zoznam všetkých úloh. Zaujíma nás iba názov zostavy (zobraziť meno) a jeho výsledok (následok):
http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]Ukázalo sa to?
Teraz vyfiltrujme len tie chody, ktoré skončia s výsledkom ÚSPECH. Použime argument &vylúčiť a ako parameter mu predáme cestu k hodnote, ktorá sa nerovná ÚSPECH. Áno áno. Dvojitý negatív je výrok. Vylučujeme všetko, čo nás nezaujíma:
http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]&exclude=freeStyleProject/allBuild[result!='SUCCESS'] Snímka obrazovky so zoznamom úspešných
No, len tak pre zaujímavosť sa presvedčíme, že nás filter neoklamal (filtre nikdy neklamú!) a zobrazme zoznam „neúspešných“:
http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]&exclude=freeStyleProject/allBuild[result='SUCCESS'] Snímka obrazovky zoznamu neúspešných
Zoznam verzií z priečinka na vzdialenom serveri
Existuje druhý spôsob, ako získať zoznam verzií. Páči sa mi to ešte viac ako prístup k API Jenkins. Nuž, pretože ak bola aplikácia úspešne zostavená, znamená to, že bola zabalená a umiestnená do úložiska v príslušnom priečinku. Podobne ako úložisko je predvolené úložisko pracovných verzií aplikácií. Páči sa mi to. No, spýtajme sa ho, aké verzie sú v sklade. Vzdialený priečinok skrútime, grepujeme a awk. Ak má niekto záujem o oneliner, tak je pod spojlerom.
Jeden riadkový príkaz
Vezmite prosím na vedomie dve veci: podrobnosti o pripojení odovzdávam v hlavičke a nepotrebujem všetky verzie z priečinka a vyberiem len tie, ktoré boli vytvorené do mesiaca. Upravte príkaz tak, aby vyhovoval vašim realitám a potrebám:
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[^/]+' )Nastavenie úloh a konfiguračný súbor úloh v Jenkins
Zistili sme zdroj zoznamu verzií. Výsledný zoznam teraz zakomponujme do úlohy. Pre mňa bolo samozrejmým riešením pridať krok v úlohe zostavenia aplikácie. Krok, ktorý by sa vykonal, ak by bol výsledkom „úspech“.
Otvorte nastavenia úlohy zostavy a prejdite úplne dole. Kliknite na tlačidlá: Pridať krok zostavenia -> Podmienený krok (jeden). V nastaveniach kroku vyberte podmienku Aktuálny stav zostavy, nastavte hodnotu ÚSPECH, akcia, ktorá sa má vykonať v prípade úspechu Spustite príkaz shell.
A teraz tá zábavná časť. Jenkins ukladá konfigurácie úloh do súborov. Vo formáte XML. Pozdĺž cesty http://путь-до-задания/config.xml V súlade s tým si môžete stiahnuť konfiguračný súbor, upraviť ho podľa potreby a vrátiť ho tam, kde ste ho získali.
Pamätajte, že sme sa dohodli vyššie, že vytvoríme parameter pre zoznam verzií BUILD_VERSION?
Stiahneme si konfiguračný súbor a pozrieme sa do neho. Len aby ste sa uistili, že parameter je na svojom mieste a že má požadovaný typ.
Snímka obrazovky pod spojlerom.
Váš fragment config.xml by mal vyzerať rovnako. Až na to, že obsah prvku voľby zatiaľ chýba
Si si istý? To je všetko, napíšme skript, ktorý sa spustí, ak bude zostava úspešná.
Skript dostane zoznam verzií, stiahne konfiguračný súbor, zapíše do neho zoznam verzií na požadované miesto a potom ho vráti späť. Áno. To je správne. Napíšte zoznam verzií v XML na miesto, kde už je zoznam verzií (bude v budúcnosti, po prvom spustení skriptu). Viem, že na svete sú stále zarytí fanúšikovia regulárnych výrazov. Ja k nim nepatrím. Prosím nainštalujte na stroj, kde sa bude upravovať konfigurácia. Zdá sa mi, že to nie je až taká veľká cena, ktorú treba zaplatiť, aby sme sa vyhli úpravám XML pomocou sed.
Pod spojlerom uvádzam kód, ktorý vykonáva vyššie uvedenú sekvenciu v celom rozsahu.
Napíšte zoznam verzií z priečinka na vzdialenom serveri do konfigurácie
#!/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.xmlAk dávate prednosť možnosti získať verzie od Jenkinsa a ste leniví ako ja, potom pod spojlerom je rovnaký kód, ale zoznam od Jenkinsa:
Napíšte zoznam verzií od Jenkinsa do konfigurácie
Majte na pamäti toto: názov mojej zostavy pozostáva z poradového čísla a čísla verzie oddelených dvojbodkou. V súlade s tým awk odreže nepotrebnú časť. Pre seba zmeňte tento rad tak, aby vyhovoval vašim potrebám.
#!/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.xmlTeoreticky, ak ste otestovali kód napísaný na základe príkladov vyššie, v úlohe nasadenia by ste už mali mať rozbaľovací zoznam s verziami. Je to ako na snímke obrazovky pod spojlerom.
Správne vyplnený zoznam verzií
Ak všetko fungovalo, skopírujte a vložte skript do Spustite príkaz shell a uložte zmeny.
Pripája sa k cloudovému shellu
Zberače máme v kontajneroch. Ansible používame ako náš nástroj na doručovanie aplikácií a konfiguračný manažér. V súlade s tým, pokiaľ ide o vytváranie kontajnerov, prichádzajú na myseľ tri možnosti: nainštalovať Docker v Docker, nainštalovať Docker na počítač so systémom Ansible alebo zostaviť kontajnery v cloudovej konzole. Dohodli sme sa, že v tomto článku budeme mlčať o zásuvných moduloch pre Jenkins. Pamätáte si?
Rozhodol som sa: dobre, keďže kontajnery „out of the box“ je možné zhromažďovať v cloudovej konzole, tak prečo sa obťažovať? Udržujte to čisté, však? Chcem zhromaždiť kontajnery Jenkins v cloudovej konzole a odtiaľ ich spustiť do kocky. Okrem toho má Google v rámci svojej infraštruktúry veľmi bohaté kanály, čo bude mať priaznivý vplyv na rýchlosť nasadenia.
Na pripojenie ku cloudovej konzole potrebujete dve veci: gcloud a prístupové práva k nim Google Cloud API pre inštanciu VM, s ktorou sa vytvorí rovnaké pripojenie.
Pre tých, ktorí sa plánujú pripojiť nie z cloudu Google
Google vo svojich službách povoľuje možnosť deaktivácie interaktívnej autorizácie. To vám umožní pripojiť sa ku konzole aj z kávovaru, ak beží *nix a má samotnú konzolu.
Ak je potrebné, aby som sa tejto problematike venoval podrobnejšie v rámci tejto poznámky, napíšte do komentárov. Ak získame dostatok hlasov, napíšem aktualizáciu na túto tému.
Najjednoduchší spôsob udelenia práv je cez webové rozhranie.
- Zastavte inštanciu virtuálneho počítača, z ktorej sa následne pripojíte ku cloudovej konzole.
- Otvorte Podrobnosti o inštancii a kliknite pozmeniť.
- Úplne dole na stránke vyberte rozsah prístupu k inštancii Úplný prístup ku všetkým cloudovým API.
screenshot
- Uložte zmeny a spustite inštanciu.
Po dokončení načítania virtuálneho počítača sa k nemu pripojte cez SSH a uistite sa, že pripojenie prebieha bez chyby. Použite príkaz:
gcloud alpha cloud-shell ssh Úspešné pripojenie vyzerá asi takto
Nasadiť do GKE
Keďže sa všetkými možnými spôsobmi snažíme o úplný prechod na IaC (Infrastruktura ako kód), naše súbory dockerov sú uložené v Git. Toto je na jednej strane. A nasadenie v kubernetes je popísané súborom yaml, ktorý používa iba táto úloha, ktorá je sama o sebe tiež ako kód. Toto je z druhej strany. Vo všeobecnosti mám na mysli, že plán je takýto:
- Berieme hodnoty premenných BUILD_VERSION a voliteľne aj hodnoty premenných, ktoré budú prechádzať ENV.
- Stiahnite si dockerfile z Git.
- Vygenerujte yaml na nasadenie.
- Oba tieto súbory nahrávame cez scp do cloudovej konzoly.
- Postavíme tam kontajner a vložíme ho do registra kontajnerov
- Na kocku aplikujeme súbor nasadenia načítania.
Buďme konkrétnejší. Raz sme sa začali rozprávať o ENV, potom predpokladajme, že musíme odovzdať hodnoty dvoch parametrov: PARAM1 и PARAM2. Pridáme ich úlohu na nasadenie, typ - Parameter reťazca.
screenshot
Vygenerujeme yaml jednoduchým presmerovaním minúť vyplniť. Predpokladá sa, samozrejme, že máte vo svojom dockerfile PARAM1 и PARAM2že názov záťaže bude úžasná aplikácia, a zostavený kontajner s aplikáciou špecifikovanej verzie leží v Register kontajnerov na ceste gcr.io/awesomeapp/awesomeapp-$BUILD_VERSIONKde $BUILD_VERSION bol práve vybraný z rozbaľovacieho zoznamu.
Výpis tímu
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.yamlJenkins agent po pripojení pomocou gcloud alpha cloud-shell ssh interaktívny režim nie je k dispozícii, takže príkazy odosielame do cloudovej konzoly pomocou parametra --príkaz.
Vyčistíme domovský priečinok v cloudovej konzole zo starého dockerfile:
gcloud alpha cloud-shell ssh --command="rm -f Dockerfile"Umiestnite čerstvo stiahnutý dockerfile do domovského priečinka cloudovej konzoly pomocou scp:
gcloud alpha cloud-shell scp localhost:./Dockerfile cloudshell:~Zhromažďujeme, označíme a presunieme kontajner do registra kontajnerov:
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"
To isté robíme so súborom nasadenia. Upozorňujeme, že nižšie uvedené príkazy používajú fiktívne názvy klastra, kde dochádza k nasadeniu (awsm-cluster) a názov projektu (úžasný projekt), kde sa klaster nachádza.
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"Spustíme úlohu, otvoríme výstup konzoly a dúfame, že uvidíme úspešné zostavenie kontajnera.
screenshot
A potom úspešné nasadenie zostaveného kontajnera
screenshot
Úmyselne som ignoroval nastavenie Ingress. Z jedného jednoduchého dôvodu: akonáhle ho nastavíte pracovná záťaž s daným názvom zostane funkčný bez ohľadu na to, koľko nasadení s týmto názvom vykonáte. No vo všeobecnosti je to trochu mimo rámca histórie.
Namiesto záverov
Všetky vyššie uvedené kroky sa pravdepodobne nedali urobiť, ale jednoducho nainštalovali nejaký plugin pre Jenkinsa, ich muuulion. Ale z nejakého dôvodu nemám rád pluginy. No presnejšie povedané, uchyľujem sa k nim len zo zúfalstva.
A ja len rád preberiem nejakú novú tému pre mňa. Vyššie uvedený text je tiež spôsob, ako sa podeliť o zistenia, ku ktorým som dospel pri riešení problému opísaného na samom začiatku. Podeľte sa s tými, ktorí ako on vôbec nie sú strašným vlkom v devopse. Ak moje zistenia pomôžu aspoň niekomu, budem rád.
Zdroj: hab.com