🥇Dizajnojmë një detyrë për implementim në GKE pa plugins, sms dhe regjistrim. Një sy hedhim Jenkins-it nën xhaketë

Të gjitha filloi nga kërkesa e liderit të skuadrës sonë të zhvilluesve që të publikonte aplikacionin e tyre të ri, i cili kishte kaluar përmes kontenorizimit. E publikova. Rreth 20 minuta më vonë, erdhi një kërkesë për të përditësuar aplikacionin, sepse kishin shtuar një funksion shumë të nevojshëm. E përditësova. Pas disa orësh… mirë, ju e dini se çfarë ndodhi më pas…

Unë, për t'u pranuar, jam pak lenitive (kam pranuar më parë apo jo?), dhe duke marrë parasysh se liderët e skuadrës kanë qasje në Jenkins, ku kemi të gjithë CI/CD, mendova: le të publikojnë sa herë të duan! Më erdhi në mend një anekdotë: jepni një njeri peshk dhe ai do të jetë i ngopur për një ditë; quajeni njeriun Syt dhe ai do të jetë i ngopur për gjithë jetën. Dhe shkuam për të krijuar një punë, e cila do të ishte në gjendje të publikonte në kub me një kontenier aplikacioni të çdo versioni të ndërtuar me sukses dhe të kalonte çdo vlerë në të ENV (gjyshi im, - filolog, mësues anglisht në të kaluarën, - tani do të rrotullonte gishtin përreth tempullit dhe do të më shikonte shumë shprehshëm, duke lexuar këtë frazë).

Pra, në këtë shënim do të flas për atë se si mësova:

Të përditësoj dinamikisht detyrat në Jenkins nga vetë detyra ose nga detyra të tjera;
Të lidhëm me konsolën cloud (Cloud shell) nga një nodë me agjentin e instaluar të Jenkins;
Të publikoj ngarkesën e punës (workload) në Google Kubernetes Engine.

Në të vërtetë, natyrisht, po gënjej pak. Supozohet se të paktën një pjesë e infrastrukturës është në shërbimin cloud të Google, dhe, gjithashtu, ju jeni përdorues dhe, sigurisht, keni një llogari GCP. Por shënimi nuk është për këtë.

Ky është një tjetër shënim i imi. Më pëlqen të shkruaj shënime si këto vetëm në një rast: kur kam një detyrë, fillimisht nuk dija si ta zgjidhja, zgjidhja nuk u gjet në formë të gatshme, prandaj e kërkova pjesë-pjesë dhe në fund e zgjida detyrën. Dhe për qëllim që në të ardhmen, kur të harroj se si e bëra, të mos më duhet të kërkoj përsëri çdo pjesë dhe t'i bashkoj ato, shkruaj këto shënime.

Kujdes: 1. Shënimi është shkruar 'për vete', nuk pretendoj për rolin e praksës më të mirë do të isha i lumtur të lexoja sugjerime ‘do të ishte më mirë të bëhej kështu’ në komente.
2. Nëse pjesa aplikative e shënimit konsiderohet si kripë, atëherë, siç janë të gjitha shënimet e mia të mëparshme, kjo është një solucion i dobët i kripës.

Përditësimi dinamik i cilësimeve të detyrave në Jenkins

Parashikoj pyetjen tuaj: çfarë lidhje ka në të vërtetë përditësimi dinamik i punës? E kam vendosur dorazi vlerën e parametrave të vargut dhe përpara!

Përgjigjem: vërtet jam lenxhak, nuk më pëlqen kur ankohen: Misha, deploy po dështoni, çdo gjë u humb! Fillon të shikosh, e aty është një gabim në vlerën e një parametri për nisjen e detyrës. Prandaj preferoj ta bëj gjithçka sa më të sigurta. Nëse ka mundësi që t'i heqësh përdoruesit mundësinë e të dhënave të futura direkt, duke dhënë në vend të kësaj një listë vlerash për të zgjedhur, atëherë unë organizoj zgjedhjen.

Plani është kështu: krijojmë një detyrë në Jenkins ku para nismës të jetë e mundur të zgjedhim versionin nga një listë, të përcaktojmë vlerat për parametrat që kalohen në kontejner përmes ENV, pastaj ajo ndërton kontejnerin dhe e ngarkon atë në Container Registry. Më pas kontejneri aty nis në kuber si workload me parametrat e caktuar në detyrë.

Procesi i krijimit dhe konfigurimit të detyrës në Jenkins nuk do ta shqyrtojmë, është jashtë temës. Do të supozojmë se detyra është gati. Për të realizuar një listë përditësuese me versionet, na nevojiten dy gjëra: një listë burimi që ekziston tashmë me numra versionesh të vlefshme dhe një variablë e tipit Choice parameter në detyrë. Në shembullin tonë le të quhet variabla BUILD_VERSION, këtu nuk do të ndalemi në detaje. Por le të ndalemi më në detaje te lista burimore.

Opsionet nuk janë aq shumë. Më vijnë ndër mend dy menjëherë:

Të përdorim Remote access API, i cili ofrohet nga Jenkins për përdoruesit e tij;
Të kërkojmë përmbajtjen e dosjes së largët të repositorit (në rastin tonë ky është JFrog Artifactory, që nuk është thelbësor).

Jenkins Remote access API

Në përputhje me traditën e shkëlqyer preferoj të shmang shpjegimet e gjata.
Më lejoni të ofroj një përkthim të lirë të një pjese të parashkëllim të dokumentacionit mbi API Jenkins ofron API për qasje të largët dhe të kuptueshme për makinat në funksionalitetin e tij. Qasja e largët ofrohet në stilin e ngjashëm me REST. Kjo do të thotë se nuk ka një pikë të vetme hyrjeje për të gjitha funksionalitetet, por në vend të kësaj përdoret një URL si:

…/api/", ku "" përfaqëson objektin në të cilin aplikohen funksionalitetet e API-së.…" do të thotë objekti, të cilit i aplikohen mundësitë e API-së.

Me përshtatje, nëse detyra për deploy, për të cilën po flasim tani, është e aksesueshme në adresën http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build, atëherë API-të për këtë detyrë janë të aksesueshme në adresën http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/

Më pas kemi mundësinë të zgjedhim në cilin format të marrim daljen. Le të ndalemi te XML, pasi API lejon filtrimin vetëm në këtë rast.

Le ta provojmë thjesht të marrim listën e të gjitha ekzekutimeve të detyrës. Na intereson vetëm emri i ndërtimit (displayName) dhe rezultati i saj (rezultati):

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

A e arritëm?

Tani do të filtrojmë vetëm ato ekzekutime që përfundimisht kanë rezultatin SUCCESS. Përdorim argumentin &exclude dhe si parameter do t'i kalojmë rrugën deri te vlera që nuk është e barabartë me SUCCESS. Po, po. Dyfishi i mohimit është pohim. Po përjashtojmë gjithçka që nuk na intereson:

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

Screenshot i listës së suksesshme

Dhe thjesht për t'u argëtuar, të sigurohemi që filtri nuk na ka gënjyer (filtrat nuk thonë kurrë të vërtetën!) dhe do të nxjerrim listën e "jo-suksesshme":

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

Screenshot i listës jo-suksesshme

Lista e versioneve nga dosja në serverin e largët

Ka edhe një mënyrë tjetër për të marrë listën e versioneve. Më pëlqen edhe më shumë se sa të drejtohem te API i Jenkins. Pse? Sepse nëse aplikacioni u ndërtua me sukses, do të thotë se ai është paketuar dhe vendosur në depo në dosjen përkatëse. Një lloj depoje është me default një ruajtje për versionet e punës së aplikacioneve. Pra, le ta pyesim se cilat versione janë në ruajtje. Do të përdorim curl, grep dhe awk për të marrë dosjen e largët. Nëse dikujt i intereson një uanliner, ai është nën spoiler.

Komanda një rresht
Kujdesuni për dy gjëra: po dërgoj në titull kredencialet për lidhjen dhe nuk më nevojiten të gjitha versionet nga dosja, dhe po filtroj vetëm ato që janë krijuar brenda një muaji. Redaktoni komandën sipas realitetit dhe nevojave tuaja:

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

Konfigurimi i detyrave dhe skedari i konfigurimit të detyrës në Jenkins

Me burimin e listës së versioneve e patëm të qartë. Le të integrojmë tani listën e marrë në detyrë. Për mua, zgjidhja e qartë ishte të shtoj një hap në detyrën për ndërtimin e aplikacionit. Një hap që do të ekzekutohet në rastin e rezultatit "sukses".

Hapim cilësimet e detyrës për ndërtim dhe rrokullisim deri në fund. Shtypim butonat: Shto hap ndërtimi -> Hapi kushtor (i vetëm). Në cilësimet e hapit, zgjedhim kushtin Statusi i tanishëm i ndërtimit, vendosim vlerën SUCCESS, veprimi i kryer në rast suksesi Ekzekuto komandën shell.

Dhe tani vjen pjesa më interesante. Konfigurimet e punës Jenkins ruhen në skedarë. Në formatin XML. Në rrugën http://rruga-deri-te-puna/config.xml Prandaj, mund të shkarkoni skedarin e konfigurimit, ta redaktoni siç e keni nevojë dhe ta vendosni në vendin nga e keni marrë.

Mos harroni, më sipër u dakorduam që për listën e versioneve do të krijojmë një parametrin BUILD_VERSION?

Le të shkarkojmë skedarin e konfigurimit dhe të shikojmë brenda tij. Thjesht për të siguruar se parametri është aty dhe në të vërtetë është i duhuri.

Ekrani i kapur nën spojler.

Fragmenti juaj config.xml duhet të duket ashtu si ky. Me përjashtim të faktit se përmbajtja e elementit choices është e papërfshirë për momentin

A e kuptuat? Tani, le të shkruajmë skenarin që do të ekzekutohet në rastin e ndërtimit të suksesshëm.
Skripti do të marrë listën e versioneve, do të shkarkojë skedarin e konfigurimit, do të shkruajë në të në vendin e nevojshëm listën e versioneve dhe pastaj do ta vendosë prapa. Po, është e saktë. Të shkruash listën e versioneve në XML aty ku tashmë ka një listë versionesh (do të jetë në të ardhmen, pas ekzekutimit të parë të skenarit). E di, në botë ende ekzistojnë adhurues të lëngshëm të shprehjeve të rregullta. Unë nuk i përkas atyre. Ju lutem, instaloni xmlstarlet në atë makinë ku do të redaktoni konfigurimin. Më duket se kjo nuk është një tarifë kaq e madhe për të shmangur redaktimin e XML me sed.

Nën spojler po ofroj kodin që ekzekuton tërë sekuencën e përshkruar më sipër.

Të shkruajmë listën e versioneve nga dosja në serverin e largët

#!/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

Nëse ju pëlqeu më shumë versioni me marrjen e versioneve nga Jenkins dhe jeni po aq të dembel si unë, atëherë nën spojler është i njëjti kod, por lista nga Jenkins:

Të shkruajmë listën e versioneve nga Jenkins'i
Vetëm mbani parasysh: emri im i ndërtimit përbëhet nga numri rendor dhe numri i versionit, të ndara me një dy pikë. Prandaj, awk e prish pjesën e panevojshme. Për veten tuaj, ndryshoni këtë rresht sipas nevojave tuaja.

#!/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

Teorikisht, nëse keni testuar kodin e shkruar mbi shembujt më lart, atëherë në detyrën e deponimit duhet të ketë një listë të rënëshme me versionet. Ja si duhet të duket në ekranin e kapur nën spojler.

Lista e versioneve e plotësuar saktë

Nëse gjithçka ka shkuar mirë, atëherë kopjoni skenarin në Ekzekuto komandën shell dhe ruani ndryshimet.

Lidhja me Cloud shell

Koleksionuesit tanë janë në kontejnerë. Si mjet për shpërndarjen e aplikacioneve dhe menaxherin e konfigurimeve, ne përdorim Ansible. Prandaj, kur bëhet fjalë për ndërtimin e kontejnerëve, në mendje vijnë tre mundësi: të instalosh Docker brenda Docker-it, të instalosh Docker në makinën me Ansible, ose të ndërtohen kontejnerët në konsolën cloud. Ne rregulluam të mos flasim për pluginat e Jenkins në këtë shënim. E mbani mend?

Vendosa: mirë, nëse kontejnerët mund të ndërtohen "nga kutia" në konsolën cloud, pse të krijojmë kaq shumë mundime? Mbajeni të pastër, apo jo? Dua të ndërtoj kontejnerë me Jenkins në konsolën cloud dhe pastaj t’i dërgoj në Kubernetes. Sidomos, brenda infrastrukturës së Google, kanalizimet janë shumë të mëdha, që do të ndikojë pozitivisht në shpejtësinë e shpërndarjes.

Për t'u lidhur me konsolën cloud, duhen dy gjëra: gcloud dhe të drejtat e aksesit në Google Cloud API për atë instancë VM nga e cila do të bëhet kjo lidhje.

Për ata që planifikojnë të lidhen fare jo nga cloud-i i Google-it
Google lejon mundësinë e çaktivizimit të autorizimit interaktiv në shërbimet e tij. Kjo do të lejojë t'u lidhen konsolës madje edhe nga makina e kafesë, për sa kohë që ajo është nën *nix dhe vetë ka konsolë.

Nëse keni nevojë që unë ta përshkruaj këtë çështje më në detaje në këtë shënim — shkruani në komentet. Nëse mblidhen mjaft vota — do të shkruaj një përditësim mbi këtë temë.

Mënyra më e thjeshtë për të dhënë të drejta është përmes ndërfaqes web.

Nd停roni instancën VM nga e cila do të bëhet lidhja me konsolën cloud.
Hapni Informacionin e instancës dhe klikoni Ndrysho.
Në fund të faqes zgjidhni fushën e aksessit të instancës Qasje e plotë në të gjitha Cloud API.
Screenshot
Ruani ndryshimet dhe startoni instancën.

Pas përfundimit të ngarkesës së VM, lidheni me të përmes SSH dhe sigurohuni që lidhja ndodh pa gabime. Përdorni komandën:

gcloud alpha cloud-shell ssh

Një lidhje e suksesshme duket diçka si kjo

Shpërndarja në GKE

Duke pasur parasysh se ne përpiqemi të kalojmë plotësisht në IaC (Infrastucture as a Code), dockerfile-t tanë ruhen në git. Ky është një aspekt. Shpërndarja në Kubernetes përshkruhet nga një skedar yaml, i cili përdoret vetëm për këtë detyrë, ai vetë gjithashtu është një lloj kodesh. Kjo është një tjetër anë. Në përgjithësi, plani është ky:

Marrim vlerat e variablave BUILD_VERSION dhe, opcionalisht, vlerat e ndryshoreve që do të kalohen përmes ENV.
Shkarko nga gita skedarin docker.
Gjenerojmë yaml për shpërndarjen.
Ngarkojmë këto dy skedarë përmes scp në konsolën e cloud.
Ndërtojmë aty kontejnerin dhe e dërgojmë në Container registry
Aplikojmë skedarin e shpërndarjes së ngarkesës në kuber.

Le të jemi më të saktë. Pasi folëm për ENV, le të supozojmë se na nevojitet të kalojmë vlerat e dy parametrave: PARAM1 dhe PARAM2. Shtojmë detyrimin e tyre për shpërndarje, lloji — String Parameter.

Screenshot

Do ta gjenerojmë yaml me një redirigjim të thjeshtë echo në skedar. Supozohet, natyrisht, që në dockerfile tuaj ekzistojnë PARAM1 dhe PARAM2, që emri i ngarkesës do të jetë awesomeapp, dhe kontejneri i ndërtuar me versionin e kërkuar ndodhet në Container registry në rrugën gcr.io/awesomeapp/awesomeapp-$BUILD_VERSIONindex $BUILD_VERSION pika e përzgjedhur nga lista e rënë.

Lista e komandave

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

Agjentit të Jenkins pas lidhjes me gcloud alpha cloud-shell ssh režimi interaktiv nuk është i disponueshëm, prandaj kalojmë komandat në konsolën e cloud me ndihmën e parametrave --command.

Pastroni papastërtitë në dosjen e shtëpisë në konsolën e cloud nga skedari i vjetër docker:

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

Vendosim skedarin e saposhtuar docker në dosjen e shtëpisë të konsolës së cloud me scp:

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

Ndërtojmë, etiketojmë dhe dërgojmë kontejnerin në Container registry:

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"

Procedojmë njësoj me skedarin e shpërndarjes. Vini re se në komandat më poshtë janë përdorur emra të rremë për klasterin ku zhvillohet shpërndarja (awsm-cluster) dhe emri i projektit (awesome-project), ku ndodhet klasteri.

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"

Jemi duke e ekzekutuar një detyrë, hapim daljen e konsolës dhe shpresojmë të shohim ndërtimin e suksesshëm të kontejnerit.

Screenshot

Më pas, dhe një implementim të suksesshëm të kontejnerit të ndërtuar.

Screenshot

Unë qëllimisht e kam anashkaluar përshtatjen. Ingress. Për një arsye të thjeshtë: një herë e konfiguroni me një workload emër të caktuar, do të mbetet funksional, pavarësisht sa implementime bëni me këtë emër. Dhe në përgjithësi, kjo është pak jashtë historisë.

Në vend të përfundimeve

Të gjitha hapat e mësipërm mbase nuk duhej të bëheshin, por thjesht të instalonim ndonjë plugin për Jenkins-in, të cilat janë mijëra. Por për ndonjë arsye, unë nuk i pëlqej plugins. Në fakt, i përdor vetëm nga dëshpërimi.

Dhe më vonë, thjesht më pëlqen të shqyrtoj ndonjë temë të re për mua. Teksti më sipër — gjithashtu një mënyrë për të ndarë zbulesat që kam bërë duke zgjidhur detyrën e përshkruar në fillim. Të ndaj me ata që, si dhe unë, nuk janë aspak vrasës të egër në devops. Nëse ndonjë prej zbulimeve të mia ndihmon dikë — do të jem i kënaqur.

Burimi: habr.com