🥇Po bëjmë një detyrë për vendosje në GKE pa plugin, SMS dhe regjistrim. Le të hedhim një vështrim nën xhaketën e Jenkins

Gjithçka filloi kur drejtuesi i ekipit të një prej ekipeve tona të zhvillimit na kërkoi të testonim aplikacionin e tyre të ri, i cili ishte vendosur në kontejnerë një ditë më parë. Unë e postova. Pas rreth 20 minutash erdhi një kërkesë për përditësimin e aplikacionit, pasi aty ishte shtuar një gjë shumë e nevojshme. rinovova. Pas nja dy orësh... epo, mund ta merrni me mend se çfarë filloi të ndodhte më pas...

Duhet ta pranoj, jam shumë dembel (a nuk e pranova më herët? Jo?), dhe duke pasur parasysh faktin se drejtuesit e ekipit kanë akses te Jenkins, në të cilin kemi të gjithë CI/CD, mendova: le të vendoset si aq sa do ai! M'u kujtua një shaka: jepi një njeriu një peshk dhe ai do të hajë për një ditë; quaj një person Fed dhe ai do të jetë Fed gjatë gjithë jetës së tij. Dhe shkoi luaj truket në punë, i cili do të jetë në gjendje të vendosë një kontejner që përmban aplikimin e çdo versioni të ndërtuar me sukses në Kuber dhe të transferojë çdo vlerë në të ENV (gjyshi im, filolog, mësues i anglishtes në të kaluarën, tani rrotullonte gishtin në tempull dhe më shikonte shumë shprehimisht pasi lexonte këtë fjali).

Pra, në këtë shënim do t'ju tregoj se si mësova:

Përditësoni në mënyrë dinamike punët në Jenkins nga vetë puna ose nga punë të tjera;
Lidhu me tastierën e resë kompjuterike (predha e resë kompjuterike) nga një nyje me agjentin Jenkins të instaluar;
Vendosni ngarkesën e punës në Google Kubernetes Engine.

Në fakt, sigurisht që jam disi i pasinqertë. Supozohet se ju keni të paktën një pjesë të infrastrukturës në cloud të Google, dhe, për rrjedhojë, ju jeni përdoruesi i saj dhe, natyrisht, keni një llogari GCP. Por ky shënim nuk është për këtë.

Kjo është fleta ime tjetër e mashtrimit. Dëshiroj të shkruaj shënime të tilla vetëm në një rast: u përballa me një problem, fillimisht nuk dija si ta zgjidhja, zgjidhja nuk u googled e gatshme, kështu që e kërkova në google pjesë-pjesë dhe përfundimisht e zgjidha problemin. Dhe në mënyrë që në të ardhmen, kur të harroj se si e bëra, nuk duhet të kërkoj përsëri në google çdo gjë pjesë-pjesë dhe t'i përpiloj së bashku, shkruaj vetë fletë të tilla mashtrimi.

Disclaimer: 1. Shënimi shkruhej “për veten time”, për rolin Praktika më e mirë nuk aplikohet. Unë jam i lumtur të lexoj opsionet "do të ishte më mirë ta bëja në këtë mënyrë" në komente.
2. Nëse pjesa e aplikuar e kartës konsiderohet kripë, atëherë, si të gjitha shënimet e mia të mëparshme, kjo është një zgjidhje e dobët kripe.

Përditësimi dinamik i cilësimeve të punës në Jenkins

Unë parashikoj pyetjen tuaj: çfarë lidhje ka përditësimi dinamik i punës me të? Futni manualisht vlerën e parametrit të vargut dhe ikni!

Unë përgjigjem: Unë jam vërtet dembel, nuk më pëlqen kur ankohen: Misha, dislokimi po rrëzohet, gjithçka ka ikur! Ju filloni të shikoni dhe ka një gabim shtypi në vlerën e disa parametrave të nisjes së detyrës. Prandaj, preferoj të bëj gjithçka në mënyrë sa më efikase. Nëse është e mundur që përdoruesi të parandalojë futjen e të dhënave drejtpërdrejt duke i dhënë në vend të kësaj një listë vlerash për të zgjedhur, atëherë unë organizoj përzgjedhjen.

Plani është ky: ne krijojmë një punë në Jenkins, në të cilën, para nisjes, ne mund të zgjidhnim një version nga lista, të specifikonim vlerat për parametrat e kaluar në kontejner përmes ENV, më pas mbledh kontejnerin dhe e shtyn atë në Regjistrin e Kontejnerëve. Pastaj prej andej ena hidhet në kuber si ngarkesa e punës me parametrat e specifikuar në punë.

Ne nuk do të shqyrtojmë procesin e krijimit dhe vendosjes së një pune në Jenkins, kjo është jashtë temës. Ne do të supozojmë se detyra është gati. Për të zbatuar një listë të përditësuar me versione, na duhen dy gjëra: një listë burimesh ekzistuese me numra versioni të vlefshëm a priori dhe një variabël si Parametri i zgjedhjes në detyrë. Në shembullin tonë, le të emërtohet ndryshorja BUILD_VERSION, nuk do të ndalemi në të në detaje. Por le të hedhim një vështrim më të afërt në listën e burimeve.

Nuk ka aq shumë opsione. Dy gjëra më erdhën menjëherë në mendje:

Përdorni API-në e qasjes në distancë që Jenkins ofron për përdoruesit e saj;
Kërkoni përmbajtjen e dosjes së depove në distancë (në rastin tonë ky është JFrog Artifactory, i cili nuk është i rëndësishëm).

Jenkins Remote Access API

Sipas traditës së shkëlqyer të krijuar, do të preferoja të shmangja shpjegimet e gjata.
Unë do t'i lejoj vetes vetëm një përkthim falas të një pjese të paragrafit të parë faqja e parë e dokumentacionit API:

Jenkins ofron një API për akses të lexueshëm nga makina në distancë në funksionalitetin e tij. <…> Qasja në distancë ofrohet në një stil të ngjashëm me REST. Kjo do të thotë që nuk ka asnjë pikë të vetme hyrjeje për të gjitha veçoritë, por në vend të kësaj një URL si ".../api/", ku"..." do të thotë objekti në të cilin aplikohen aftësitë API.

Me fjalë të tjera, nëse detyra e vendosjes për të cilën po flasim aktualisht është e disponueshme në http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build, atëherë bilbilat API për këtë detyrë janë në dispozicion në http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/

Më pas, ne kemi një zgjedhje në çfarë forme të marrim rezultatin. Le të përqendrohemi në XML, pasi API lejon vetëm filtrimin në këtë rast.

Le të përpiqemi të marrim një listë të të gjitha punëve. Ne jemi të interesuar vetëm për emrin e asamblesë (Emri i shfaqur) dhe rezultati i saj (rezultat):

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

Ndodhi?

Tani le të filtrojmë vetëm ato vrapime që përfundojnë me rezultatin SUKSES. Le të përdorim argumentin &përjashto dhe si parametër do t'i kalojmë shtegun në një vlerë jo të barabartë me SUKSES. Po Po. Një negativ i dyfishtë është një deklaratë. Ne 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']

Pamja e ekranit e listës së të suksesshmëve

Epo, thjesht për argëtim, le të sigurohemi që filtri të mos na mashtrojë (filtrat nuk gënjejnë kurrë!) dhe të shfaqim një listë me ato "të pasuksesshme":

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

Pamja e ekranit e listës së atyre jo të suksesshme

Lista e versioneve nga një dosje në një server të largët

Ekziston një mënyrë e dytë për të marrë një listë versionesh. Më pëlqen edhe më shumë sesa qasja në API të Jenkins. Epo, sepse nëse aplikacioni është ndërtuar me sukses, do të thotë se është paketuar dhe vendosur në depo në dosjen përkatëse. Për shembull, një depo është ruajtja e paracaktuar e versioneve të punës të aplikacioneve. si. Epo, le ta pyesim se cilat versione janë në ruajtje. Ne do të mbështjellim, grep dhe prishim dosjen në distancë. Nëse dikush është i interesuar për oneliner, atëherë ai është nën spoiler.

Komanda me një rresht
Ju lutemi vini re dy gjëra: i kaloj detajet e lidhjes në kokë dhe nuk më duhen të gjitha versionet nga dosja, dhe zgjedh vetëm ato që janë krijuar brenda një muaji. Ndryshoni komandën për t'iu përshtatur realiteteve dhe nevojave tuaja:

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

Vendosja e punëve dhe skedari i konfigurimit të punës në Jenkins

Ne kuptuam burimin e listës së versioneve. Tani le të inkorporojmë listën që rezulton në detyrë. Për mua, zgjidhja e dukshme ishte të shtoja një hap në detyrën e ndërtimit të aplikacionit. Hapi që do të ekzekutohej nëse rezultati do të ishte "sukses".

Hapni cilësimet e detyrës së montimit dhe lëvizni në fund. Klikoni në butonat: Shto hapin e ndërtimit -> Hapin e kushtëzuar (i vetëm). Në cilësimet e hapit, zgjidhni kushtin Statusi aktual i ndërtimit, vendosni vlerën SUKSES, veprimi që do të kryhet nëse është i suksesshëm Ekzekutoni komandën e guaskës.

Dhe tani pjesa argëtuese. Jenkins ruan konfigurimet e punës në skedarë. Në formatin XML. Pergjate rruges http://путь-до-задания/config.xml Prandaj, mund të shkarkoni skedarin e konfigurimit, ta modifikoni sipas nevojës dhe ta vendosni përsëri aty ku e keni marrë.

Mos harroni, ne ramë dakord më lart se do të krijojmë një parametër për listën e versioneve BUILD_VERSION?

Le të shkarkojmë skedarin e konfigurimit dhe të hedhim një vështrim brenda tij. Vetëm për t'u siguruar që parametri është në vend dhe i llojit të dëshiruar.

Pamja e ekranit nën spoiler.

Fragmenti juaj config.xml duhet të duket i njëjtë. Përveç që përmbajtja e elementit të zgjedhjeve mungon ende

A je i sigurt? Kjo është e gjitha, le të shkruajmë një skenar që do të ekzekutohet nëse ndërtimi është i suksesshëm.
Skripti do të marrë një listë versionesh, do të shkarkojë skedarin e konfigurimit, do të shkruajë listën e versioneve në të në vendin që na nevojitet dhe më pas do ta vendosë përsëri. Po. Kjo është e drejtë. Shkruani një listë versionesh në XML në vendin ku ekziston tashmë një listë versionesh (do të jetë në të ardhmen, pas lëshimit të parë të skenarit). E di që ka ende fansa të zjarrtë të shprehjeve të rregullta në botë. Unë nuk u përkas atyre. Ju lutemi instaloni xmlstarler në makinën ku do të modifikohet konfigurimi. Më duket se ky nuk është një çmim aq i madh për të shmangur modifikimin e XML duke përdorur sed.

Nën spoiler, unë paraqes kodin që kryen sekuencën e mësipërme në tërësi.

Shkruani një listë versionesh nga një dosje në serverin në distancë në konfigurimin

#!/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 preferoni opsionin e marrjes së versioneve nga Jenkins dhe jeni po aq dembel sa unë, atëherë nën spoiler është i njëjti kod, por një listë nga Jenkins:

Shkruani një listë versionesh nga Jenkins te konfigurimi
Vetëm mbani në mend këtë: emri im i asamblesë përbëhet nga një numër sekuence dhe një numër versioni, të ndarë me dy pika. Prandaj, awk ndërpret pjesën e panevojshme. Për veten tuaj, ndryshoni këtë linjë për t'iu përshtatur 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

Në teori, nëse e keni testuar kodin e shkruar bazuar në shembujt e mësipërm, atëherë në detyrën e vendosjes duhet të keni tashmë një listë rënëse me versione. Është si në pamjen e ekranit nën spoiler.

Lista e versioneve e plotësuar saktë

Nëse gjithçka funksionoi, atëherë kopjoni-ngjisni skenarin në Ekzekutoni komandën e guaskës dhe ruani ndryshimet.

Lidhja me guaskën e resë kompjuterike

Ne kemi kolektorë në kontejnerë. Ne përdorim Ansible si mjetin tonë të dorëzimit të aplikacionit dhe menaxherin e konfigurimit. Prandaj, kur bëhet fjalë për ndërtimin e kontejnerëve, tre opsione vijnë në mendje: instaloni Docker në Docker, instaloni Docker në një makinë që funksionon Ansible ose ndërtoni kontejnerë në një tastierë cloud. Ne ramë dakord të heshtim për shtojcat për Jenkins në këtë artikull. E mbani mend?

Vendosa: mirë, meqenëse kontejnerët "jashtë kutisë" mund të mblidhen në tastierën e cloud, atëherë pse të shqetësoheni? Mbajeni të pastër, apo jo? Dua të mbledh kontejnerët e Jenkins në tastierën e resë kompjuterike dhe më pas t'i hedh në kuber prej andej. Për më tepër, Google ka kanale shumë të pasura brenda infrastrukturës së saj, të cilat do të kenë një efekt të dobishëm në shpejtësinë e vendosjes.

Për t'u lidhur me tastierën cloud, ju duhen dy gjëra: gcloud dhe të drejtat e aksesit në API Cloud Cloud për shembullin VM me të cilin do të bëhet e njëjta lidhje.

Për ata që planifikojnë të lidhen jo fare nga Google cloud
Google lejon mundësinë e çaktivizimit të autorizimit interaktiv në shërbimet e tij. Kjo do t'ju lejojë të lidheni me tastierën edhe nga një aparat kafeje, nëse funksionon *nix dhe ka vetë një tastierë.

Nëse ka nevojë që unë ta trajtoj këtë çështje në mënyrë më të detajuar në kuadër të këtij shënimi, shkruani në komente. Nëse marrim vota të mjaftueshme, do të shkruaj një përditësim për këtë temë.

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

Ndaloni shembullin VM nga i cili do të lidheni më pas me tastierën cloud.
Hapni Detajet e shembullit dhe klikoni ndryshoj.
Në fund të faqes, zgjidhni sferën e hyrjes së shembullit Qasje e plotë në të gjitha API-të e Cloud.
screenshot
Ruani ndryshimet tuaja dhe nisni shembullin.

Pasi VM të ketë mbaruar ngarkimin, lidheni me të nëpërmjet SSH dhe sigurohuni që lidhja të ndodhë pa gabim. Përdorni komandën:

gcloud alpha cloud-shell ssh

Një lidhje e suksesshme duket diçka si kjo

Vendoseni në GKE

Meqenëse ne po përpiqemi në çdo mënyrë të mundshme që të kalojmë plotësisht në IaC (Infrastruktura si kod), skedarët tanë docker ruhen në Git. Kjo është nga njëra anë. Dhe vendosja në kubernetes përshkruhet nga një skedar yaml, i cili përdoret vetëm nga kjo detyrë, e cila në vetvete është gjithashtu si kod. Kjo është nga ana tjetër. Në përgjithësi, dua të them, plani është ky:

Marrim vlerat e variablave BUILD_VERSION dhe, sipas dëshirës, vlerat e variablave që do të kalohen ENV.
Shkarkoni skedarin docker nga Git.
Gjeneroni yaml për vendosje.
Ne i ngarkojmë të dy këta skedarë përmes scp në tastierën cloud.
Ne ndërtojmë një kontejner atje dhe e shtyjmë atë në regjistrin e kontejnerëve
Ne aplikojmë skedarin e vendosjes së ngarkesës në kuber.

Le të jemi më konkret. Pasi filluam të flasim për ENV, atëherë supozojmë se duhet të kalojmë vlerat e dy parametrave: PARAM1 и PARAM2. Ne shtojmë detyrën e tyre për vendosjen, shkruani - Parametri i vargut.

screenshot

Ne do të gjenerojmë yaml me një ridrejtim të thjeshtë humbas për të paraqitur. Supozohet, sigurisht, që e keni në dosjen tuaj docker PARAM1 и PARAM2se emri i ngarkesës do të jetë aplikacion i mrekullueshëm, dhe kontejneri i montuar me aplikimin e versionit të specifikuar qëndron në Regjistri i kontejnerëve Rrugës gcr.io/awesomeapp/awesomeapp-$BUILD_VERSIONKu $BUILD_VERSION sapo u zgjodh nga lista rënëse.

Lista e ekipit

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

Agjenti Jenkins pas lidhjes duke përdorur gcloud alfa cloud-shell ssh modaliteti interaktiv nuk është i disponueshëm, kështu që ne dërgojmë komanda në tastierën e cloud duke përdorur parametrin -- komandë.

Ne pastrojmë dosjen kryesore në tastierën cloud nga skedari i vjetër docker:

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

Vendosni skedarin docker të sapo shkarkuar në dosjen kryesore të tastierës cloud duke përdorur scp:

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

Ne mbledhim, etiketojmë dhe e shtyjmë kontejnerin në regjistrin e kontejnerit:

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"

Ne bëjmë të njëjtën gjë me skedarin e vendosjes. Ju lutemi vini re se komandat e mëposhtme përdorin emra fiktive të grupit ku ndodh vendosja (awsm-grup) dhe emri i projektit (projekt i mrekullueshëm), ku ndodhet grupi.

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"

Ne ekzekutojmë detyrën, hapim daljen e konsolës dhe shpresojmë të shohim montimin e suksesshëm të kontejnerit.

screenshot

Dhe pastaj vendosja e suksesshme e kontejnerit të mbledhur

screenshot

E injorova qëllimisht vendosjen Hyrje. Për një arsye të thjeshtë: sapo ta konfiguroni ngarkesa e punës me një emër të caktuar, ai do të mbetet funksional, pavarësisht sa vendosje me këtë emër do të kryeni. Epo, në përgjithësi, kjo është pak përtej fushëveprimit të historisë.

Në vend të konkluzioneve

Të gjithë hapat e mësipërm ndoshta nuk mund të ishin bërë, por thjesht instaluan disa shtojca për Jenkins, muuulion e tyre. Por për disa arsye nuk më pëlqejnë shtojcat. Epo, më saktë, unë u drejtohem atyre vetëm nga dëshpërimi.

Dhe thjesht më pëlqen të marr një temë të re për mua. Teksti i mësipërm është gjithashtu një mënyrë për të ndarë gjetjet që bëra gjatë zgjidhjes së problemit të përshkruar në fillim. Ndani me ata që, si ai, nuk janë aspak një ujk i tmerrshëm në devops. Nëse gjetjet e mia ndihmojnë të paktën dikë, do të jem i lumtur.

Burimi: www.habr.com

Ne krijojmë një detyrë vendosjeje në GKE pa shtojca, SMS ose regjistrim. Le të hedhim një vështrim nën xhaketën e Jenkins

Përditësimi dinamik i cilësimeve të punës në Jenkins

Jenkins Remote Access API

Lista e versioneve nga një dosje në një server të largët

Vendosja e punëve dhe skedari i konfigurimit të punës në Jenkins

Lidhja me guaskën e resë kompjuterike

Vendoseni në GKE

Në vend të konkluzioneve

Shto një koment Cancel përgjigje