Az egész azzal kezdődött, hogy az egyik fejlesztőcsapatunk csapatvezetője megkért minket, hogy teszteljük új alkalmazásukat, amelyet előző nap konténerbe helyeztek. közzétettem. Körülbelül 20 perc múlva érkezett egy kérés az alkalmazás frissítésére, mert egy nagyon szükséges dolog került oda. megújítottam. Újabb pár óra elteltével... nos, sejtheti, mi történt ezután...
Bevallom, elég lusta vagyok (ezt nem ismertem be korábban? Nem?), és tekintettel arra, hogy a csapatvezetők hozzáférhetnek a Jenkins-hez, amelyben minden CI/CD-vel rendelkezünk, arra gondoltam: hadd telepítse amennyit akar! Eszembe jutott egy vicc: adj egy halat az embernek, és egy napig eszik; hívj egy személyt Fed-nek, és egész életében Fed lesz. És ment trükközni a munkában, amely képes lenne telepíteni egy tárolót, amely bármely sikeresen beépített verzió alkalmazását tartalmazza a Kuberben, és átvinni rá az értékeket Env (nagyapám, filológus, angoltanár a múltban, most a halántéka felé forgatta az ujját, és nagyon kifejezően nézett rám, miután elolvasta ezt a mondatot).
Tehát ebben a megjegyzésben elmondom, hogyan tanultam:
- Dinamikusan frissítheti a Jenkins-feladatokat magából a munkából vagy más jobokból;
- Csatlakozás a felhőkonzolhoz (Cloud shell) egy olyan csomópontról, amelyen a Jenkins ügynök telepítve van;
- Munkaterhelés telepítése a Google Kubernetes Engine-be.
Valójában, természetesen, kissé hamis vagyok. Feltételezzük, hogy az infrastruktúra legalább egy része a Google felhőben található, és ezért Ön a felhasználója, és természetesen rendelkezik GCP-fiókkal. De ez a feljegyzés nem erről szól.
Ez a következő csalólapom. Csak egy esetben szeretnék ilyen megjegyzéseket írni: szembesültem egy problémával, eleinte nem tudtam, hogyan kell megoldani, a megoldás nem volt készen a google-ban, így a google-ban részleteztem és végül megoldottam a problémát. És hogy a jövőben, amikor elfelejtem, hogyan csináltam, ne kelljen mindent újra google-ba keresnem, és össze kell állítanom, írok magamnak ilyen csalós lapokat.
Jogi nyilatkozat: 1. A jegyzet „magamnak”, a szerephez íródott legjobb gyakorlat nem vonatkozik. Örömmel olvasom a "jobb lett volna így csinálni" opciókat a kommentekben.
2. Ha a hangjegy felvitt részét sónak tekintjük, akkor az összes korábbi jegyzetemhez hasonlóan ez is egy gyenge sóoldat.
A Jenkins munkabeállításainak dinamikus frissítése
Előre látom a kérdését: mi köze ehhez a dinamikus munkafrissítésnek? Írja be kézzel a karakterlánc paraméter értékét, és már indulhat is!
Azt válaszolom: Nagyon lusta vagyok, nem szeretem, ha panaszkodnak: Misha, összeomlik a bevetés, minden elment! Elkezdi keresni, és elírás van valamelyik feladatindító paraméter értékében. Ezért inkább mindent a lehető leghatékonyabban csinálok. Ha meg lehet akadályozni, hogy a felhasználó közvetlenül adjon meg adatokat úgy, hogy helyette megadom a választható értékek listáját, akkor megszervezem a kijelölést.
A terv a következő: létrehozunk egy jobot a Jenkins-ben, amelyben indítás előtt kiválaszthatunk egy verziót a listából, megadhatjuk a konténerbe továbbított paraméterek értékeit. Env, majd összegyűjti a tárolót, és benyomja a Container Registry-be. Aztán onnan indul a konténer cuber as-ban terhelés a munkában megadott paraméterekkel.
Nem vesszük figyelembe a Jenkins-i munkahely létrehozásának és felállításának folyamatát, ez nem téma. Feltételezzük, hogy a feladat készen áll. A frissített listák verzióinak megvalósításához két dologra van szükségünk: egy meglévő forráslistára eleve érvényes verziószámokkal és egy olyan változóval, mint pl. Választási paraméter a feladatban. Példánkban legyen a változó neve BUILD_VERSION, nem foglalkozunk vele részletesen. De nézzük meg közelebbről a forráslistát.
Nincs olyan sok lehetőség. Két dolog jutott rögtön eszembe:
- Használja a távelérési API-t, amelyet a Jenkins kínál felhasználóinak;
- Kérd le a távoli repository mappa tartalmát (esetünkben ez a JFrog Artifactory, ami nem fontos).
Jenkins Remote Access API
A kialakult kiváló hagyomány szerint inkább kerülöm a hosszadalmas magyarázatokat.
Csak az első bekezdés egy részének szabad fordítását engedem meg magamnak :
A Jenkins API-t biztosít a funkcióihoz való távoli, géppel olvasható hozzáféréshez. <…> A távoli hozzáférést REST-szerű stílusban kínáljuk. Ez azt jelenti, hogy nincs egyetlen belépési pont az összes szolgáltatáshoz, hanem egy URL, például ".../api/", Ahol "..." azt az objektumot jelenti, amelyre az API-képességek vonatkoznak.
Más szóval, ha a telepítési feladat, amelyről jelenleg beszélünk, elérhető a címen http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build, akkor az ehhez a feladathoz tartozó API-sípok a címen érhetők el http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/
Ezután választhatunk, hogy milyen formában kapjuk meg a kimenetet. Koncentráljunk az XML-re, mivel az API csak ebben az esetben engedélyezi a szűrést.
Próbáljunk meg összegyűjteni egy listát az összes feladatról. Csak az összeállítás neve érdekel minket (megjelenítendő név) és eredménye (eredményez):
http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]Kiderült?
Most csak azokat a futtatásokat szűrjük, amelyek az eredménnyel zárulnak SIKER. Használjuk az érvelést &kizárás és paraméterként átadjuk neki a nem egyenlő érték elérési útját SIKER. Igen igen. A kettős negatív egy állítás. Kizárunk mindent, ami minket nem érdekel:
http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]&exclude=freeStyleProject/allBuild[result!='SUCCESS'] Képernyőkép a sikeresek listájáról
Nos, csak a móka kedvéért, győződjünk meg arról, hogy a szűrő nem csalt meg minket (a szűrők soha nem hazudnak!), és jelenítsük meg a „sikertelenek” listáját:
http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]&exclude=freeStyleProject/allBuild[result='SUCCESS'] Képernyőkép a nem sikeresek listájáról
Egy távoli szerveren lévő mappából származó verziók listája
Van egy második módja a verziók listájának beszerzésének. Még jobban tetszik, mint a Jenkins API elérése. Nos, mert ha az alkalmazást sikeresen felépítették, az azt jelenti, hogy becsomagolták és a megfelelő mappába helyezték a tárolóba. Hasonlóan, a tároló az alkalmazások működő verzióinak alapértelmezett tárolója. Mint. Nos, kérdezzük meg tőle, milyen verziók vannak a raktárban. Göndörítjük, grep és awk a távoli mappát. Ha valakit érdekel a oneliner, akkor az a spoiler alatt van.
Egysoros parancs
Két dolgot vegyél figyelembe: átadom a kapcsolat adatait a fejlécben, és nincs szükségem minden verzióra a mappából, és csak azokat választom ki, amelyek egy hónapon belül jöttek létre. Szerkessze a parancsot a valóságnak és igényeinek megfelelően:
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[^/]+' )Feladatok és feladatkonfigurációs fájl beállítása a Jenkinsben
Rájöttünk a verziólista forrására. Most építsük be a kapott listát a feladatba. Számomra a kézenfekvő megoldás az volt, hogy hozzáadtam egy lépést az alkalmazásépítési feladathoz. Az a lépés, amelyet akkor hajtanak végre, ha az eredmény "siker".
Nyissa meg az összeállítási feladat beállításait, és görgessen le az aljára. Kattintson a gombokra: Építési lépés hozzáadása -> Feltételes lépés (egyetlen). A lépésbeállításokban válassza ki a feltételt Jelenlegi build állapota, állítsa be az értéket SIKER, a sikeresség esetén végrehajtandó művelet Futtassa a shell parancsot.
És most a szórakoztató rész. A Jenkins a feladatkonfigurációkat fájlokban tárolja. XML formátumban. Az út mentén http://путь-до-задания/config.xml Ennek megfelelően letöltheti a konfigurációs fájlt, szükség szerint szerkesztheti, és visszahelyezheti oda, ahol kapta.
Ne feledje, fentebb megegyeztünk abban, hogy létrehozunk egy paramétert a verziók listájához BUILD_VERSION?
Töltsük le a konfigurációs fájlt, és nézzünk bele. Csak azért, hogy megbizonyosodjunk arról, hogy a paraméter a helyén van és a kívánt típusú.
Képernyőkép spoiler alatt.
A config.xml töredéknek ugyanúgy kell kinéznie. Kivéve, hogy a választási elem tartalma még hiányzik
biztos vagy ebben? Ennyi, írjunk egy scriptet, ami akkor fut le, ha a build sikeres lesz.
A szkript megkapja a verziók listáját, letölti a konfigurációs fájlt, beírja a verziók listáját a kívánt helyre, majd visszahelyezi. Igen. Úgy van. Írja meg a verziók listáját XML-ben arra a helyre, ahol már van verziólista (a jövőben, a szkript első indítása után lesz). Tudom, hogy még mindig vannak ádáz rajongói a reguláris kifejezéseknek a világon. nem tartozom közéjük. Kérjük, telepítse arra a gépre, ahol a konfigurációt szerkeszteni fogják. Számomra úgy tűnik, hogy ez nem olyan nagy ár, hogy elkerülje az XML sed használatával történő szerkesztését.
A spoiler alatt bemutatom azt a kódot, amely a fenti sorozatot teljes egészében végrehajtja.
Írja be a verziók listáját a távoli kiszolgálón lévő mappából a konfigurációba
#!/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.xmlHa inkább a Jenkins-től szerezhet be verziókat, és olyan lusta vagy, mint én, akkor a spoiler alatt ugyanaz a kód található, csak a Jenkins listája:
Írjon egy listát a Jenkinstől a konfigurációig terjedő verziókról
Ne feledje: az összeállítás nevem egy sorszámból és egy verziószámból áll, kettősponttal elválasztva. Ennek megfelelően az awk levágja a felesleges részt. Saját maga változtassa meg ezt a sort az igényeinek megfelelően.
#!/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.xmlElméletileg, ha a fenti példák alapján megírt kódot teszteltük, akkor a telepítési feladatban már rendelkeznie kell egy legördülő listával a verziókkal. Olyan, mint a spoiler alatti képernyőképen.
A verziók helyesen kitöltött listája
Ha minden működött, akkor másolja be a szkriptet Futtassa a shell parancsot és mentse el a változtatásokat.
Csatlakozás a Cloud shellhez
Gyűjtőink konténerekben vannak. Az Ansible-t használjuk alkalmazásszállító eszközként és konfigurációkezelőként. Ennek megfelelően, ha konténerek építéséről van szó, három lehetőség jut eszünkbe: a Docker telepítése a Dockerben, a Docker telepítése Ansible-t futtató gépre, vagy konténerek építése felhőkonzolban. Megállapodtunk, hogy ebben a cikkben hallgatunk a Jenkins bővítményeiről. Emlékezik?
Úgy döntöttem: nos, mivel a „dobozból” konténereket össze lehet gyűjteni a felhőkonzolban, akkor miért baj? Tartsd tisztán, igaz? A Jenkins konténereket szeretném összegyűjteni a felhőkonzolban, majd onnan elindítani a cuberbe. Ráadásul a Google igen gazdag csatornákkal rendelkezik az infrastruktúrájában, ami jótékony hatással lesz a telepítés sebességére.
A felhőkonzolhoz való csatlakozáshoz két dologra van szüksége: gcloud és hozzáférési jogokat A Google Cloud API ahhoz a virtuális gép-példányhoz, amelyről ugyanez a kapcsolat létrejön.
Azoknak, akik egyáltalán nem a Google felhőből terveznek csatlakozni
A Google szolgáltatásaiban lehetővé teszi az interaktív engedélyezés letiltását. Ez lehetővé teszi, hogy akár kávéfőzőről is csatlakozzon a konzolhoz, ha az *nix fut és van konzolja.
Ha szükséges, hogy a jelen jegyzet keretein belül részletesebben foglalkozzam ezzel a kérdéssel, írd meg kommentben. Ha lesz elég szavazatunk, írok egy frissítést ebben a témában.
A jogok megadásának legegyszerűbb módja a webes felületen keresztül történik.
- Állítsa le azt a virtuális gép-példányt, amelyről később csatlakozni fog a felhőkonzolhoz.
- Nyissa meg a Példány részleteit, és kattintson a gombra Profil módosítás.
- Az oldal alján válassza ki a példány hozzáférési hatókörét Teljes hozzáférés az összes Cloud API-hoz.
screenshot
- Mentse el a változtatásokat, és indítsa el a példányt.
A virtuális gép betöltése után csatlakozzon hozzá SSH-n keresztül, és győződjön meg arról, hogy a kapcsolat hiba nélkül történik. Használja a parancsot:
gcloud alpha cloud-shell ssh Egy sikeres kapcsolat valahogy így néz ki
Telepítés a GKE-be
Mivel minden lehetséges módon arra törekszünk, hogy teljesen áttérjünk az IaC-re (infrastruktúra mint kód), a docker fájljainkat Gitben tároljuk. Ez egyrészt. A kubernetes telepítését pedig egy yaml fájl írja le, amelyet csak ez a feladat használ, amely maga is olyan, mint egy kód. Ez a másik oldalról. Általában úgy értem, a terv a következő:
- A változók értékeit vesszük BUILD_VERSION és opcionálisan azoknak a változóknak az értékei, amelyeken átmennek Env.
- Töltse le a docker-fájlt a Git-ről.
- Hozzon létre yaml-t a telepítéshez.
- Mindkét fájlt scp-n keresztül feltöltjük a felhőkonzolra.
- Ott építünk egy tárolót, és betoljuk a Container registry-be
- A betöltési telepítési fájlt alkalmazzuk a cuberre.
Legyünk konkrétabbak. Egyszer elkezdtünk beszélni Env, akkor tegyük fel, hogy két paraméter értékét kell átadnunk: PARAM1 и PARAM2. Hozzáadjuk a feladatukat a telepítéshez, típus - Karakterlánc paraméter.
screenshot
Egy egyszerű átirányítással generáljuk a yaml-t visszhang fájlhoz. Természetesen feltételezzük, hogy a dockerfájlban van PARAM1 и PARAM2hogy a terhelés neve az lesz félelmetes alkalmazás, és az összeállított tároló a megadott verzió alkalmazásával benne fekszik Tároló nyilvántartás az út mentén gcr.io/awesomeapp/awesomeapp-$BUILD_VERSIONAhol $BUILD_VERSION most lett kiválasztva a legördülő listából.
Csapatlista
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 ügynök csatlakoztatás után használja gcloud alfa cloud-shell ssh interaktív mód nem elérhető, ezért a paraméter segítségével parancsokat küldünk a felhőkonzolnak --parancs.
Megtisztítjuk a felhőkonzol otthoni mappáját a régi dockerfájlból:
gcloud alpha cloud-shell ssh --command="rm -f Dockerfile"Helyezze a frissen letöltött docker-fájlt a felhőkonzol otthoni mappájába az scp használatával:
gcloud alpha cloud-shell scp localhost:./Dockerfile cloudshell:~Összegyűjtjük, címkézzük és továbbítjuk a tárolót a Container registry-be:
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"
Ugyanezt tesszük a telepítési fájllal is. Kérjük, vegye figyelembe, hogy az alábbi parancsok annak a fürtnek a fiktív neveit használják, ahol a telepítés megtörténik (awsm-cluster) és a projekt neve (félelmetes projekt), ahol a klaszter található.
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"Futtatjuk a feladatot, megnyitjuk a konzol kimenetét, és reméljük, hogy a konténer sikeresen összeáll.
screenshot
És akkor az összeszerelt konténer sikeres telepítése
screenshot
Szándékosan figyelmen kívül hagytam a beállítást Bemenetel. Egyetlen egyszerű okból: ha egyszer beállítottad terhelés adott névvel, működőképes marad, függetlenül attól, hogy hány telepítést hajt végre ezen a néven. Nos, általában ez egy kicsit túlmutat a történelem keretein.
Következtetések helyett
Valószínűleg a fenti lépéseket nem lehetett volna megtenni, csak egyszerűen telepíteni kellett volna valami plugint a Jenkinshez, az ő muuulionjukhoz. De valamiért nem szeretem a pluginokat. Nos, pontosabban csak kétségbeesésből folyamodom hozzájuk.
És csak szeretek felvenni valami új témát a számomra. A fenti szöveg arra is alkalmas, hogy megosszam azokat a megállapításokat, amelyeket a legelején leírt probléma megoldása során tettem. Oszd meg azokkal, akik hozzá hasonlóan egyáltalán nem vészes farkasok a devopsban. Ha a leleteim legalább valakinek segítenek, akkor boldog leszek.
Forrás: will.com