Tas viss sākās, kad vienas no mūsu izstrādes komandām komandas vadītājs lūdza mūs pārbaudīt viņu jauno lietojumprogrammu, kas iepriekšējā dienā tika ievietota konteineros. Es to ievietoju. Pēc aptuveni 20 minūtēm tika saņemts lūgums atjaunināt aplikāciju, jo tur bija pievienota ļoti nepieciešama lieta. Es atjaunoju. Vēl pēc pāris stundām... nu, var uzminēt, kas sākās tālāk...
Man jāatzīst, ka esmu diezgan slinks (vai es to neatzinu agrāk? Nē?), un, ņemot vērā faktu, ka komandas vadītājiem ir piekļuve Dženkinsam, kurā mums ir viss CI/CD, es nodomāju: lai viņš izvieto kā cik viņš vēlas! Atcerējos joku: iedod cilvēkam zivi, un viņš dienu ēdīs; sauc cilvēku par Fed un viņš būs Barots visu mūžu. Un aizgāja izspēlēt trikus darbā, kas varētu izvietot Kuber konteineru, kurā ir jebkuras veiksmīgi iebūvētas versijas lietojumprogramma, un pārsūtīt uz to visas vērtības ENV (mans vectēvs, filologs, agrāk angļu valodas skolotājs, tagad pēc šī teikuma izlasīšanas vicināja ar pirkstu pa deniņu un skatījās uz mani ļoti izteiksmīgi).
Tāpēc šajā piezīmē es jums pastāstīšu, kā es iemācījos:
- Dinamiski atjauniniet darbu Dženkinsā no paša darba vai no citiem darbiem;
- Izveidojiet savienojumu ar mākoņa konsoli (mākoņa apvalku) no mezgla, kurā ir instalēts Jenkins aģents;
- Izvietojiet darba slodzi Google Kubernetes Engine.
Patiesībā es, protams, esmu nedaudz nekrietns. Tiek pieņemts, ka jums ir vismaz daļa infrastruktūras Google mākonī, un tāpēc jūs esat tā lietotājs un, protams, jums ir GCP konts. Bet ne par to ir šī piezīme.
Šī ir mana nākamā krāpšanās lapa. Šādas piezīmes gribu uzrakstīt tikai vienā gadījumā: saskāros ar problēmu, sākotnēji nezināju, kā to atrisināt, risinājums netika googlēts gatavs, tāpēc google pa daļām un galu galā problēmu atrisināju. Un, lai turpmāk, kad aizmirstu, kā es to izdarīju, man nebūtu atkal viss pa gabaliņam jāmeklē googlē un jāsaliek kopā, es rakstu sev tādas blēžu lapas.
Atruna: 1. Piezīme tika uzrakstīta “sev”, par lomu labākā prakse neattiecas. Es priecājos komentāros izlasīt opcijas “labāk būtu bijis darīt šādi”.
2. Ja uzklātā nots daļa tiek uzskatīta par sāli, tad, tāpat kā visas manas iepriekšējās notis, arī šis ir vājš sāls šķīdums.
Dinamiska darba iestatījumu atjaunināšana pakalpojumā Jenkins
Es paredzu jūsu jautājumu: kāds sakars ar dinamisko darbu atjaunināšanu? Ievadiet virknes parametra vērtību manuāli un dodieties!
Es atbildu: es esmu ļoti slinks, man nepatīk, kad viņi sūdzas: Miša, izvietošana brūk, viss ir pagājis! Jūs sākat meklēt, un kāda uzdevuma palaišanas parametra vērtībā ir drukas kļūda. Tāpēc es dodu priekšroku visu darīt pēc iespējas efektīvāk. Ja ir iespējams neļaut lietotājam tieši ievadīt datus, tā vietā dodot vērtību sarakstu, no kuriem izvēlēties, tad es organizēju atlasi.
Plāns ir šāds: mēs izveidojam darbu Dženkinsā, kurā pirms palaišanas mēs varētu izvēlēties versiju no saraksta, norādīt parametru vērtības, kas tiek nodotas konteineram, izmantojot ENV, tad tas savāc konteineru un iespiež to konteineru reģistrā. Tad no turienes konteiners tiek palaists kuber kā darba slodze ar darbā norādītajiem parametriem.
Mēs neapsvērsim darba izveides un izveides procesu Dženkinsā, tas ir ārpus tēmas. Mēs pieņemsim, ka uzdevums ir gatavs. Lai ieviestu atjauninātu sarakstu ar versijām, mums ir nepieciešamas divas lietas: esošs avotu saraksts ar a priori derīgiem versiju numuriem un mainīgais, piemēram, Izvēles parametrs uzdevumā. Mūsu piemērā ļaujiet mainīgajam nosaukt nosaukumu BUILD_VERSION, mēs pie tā sīkāk nepakavēsimies. Bet sīkāk aplūkosim avotu sarakstu.
Nav tik daudz iespēju. Uzreiz prātā ienāca divas lietas:
- Izmantojiet attālās piekļuves API, ko Jenkins piedāvā saviem lietotājiem;
- Pieprasiet attālās repozitorija mapes saturu (mūsu gadījumā tas ir JFrog Artifactory, kas nav svarīgi).
Jenkins attālās piekļuves API
Saskaņā ar iedibināto izcilo tradīciju es gribētu izvairīties no gariem skaidrojumiem.
Es atļaušos tikai brīvi tulkot pirmās rindkopas fragmentu :
Jenkins nodrošina API attālai mašīnlasāmai piekļuvei tās funkcionalitātei. <…> Attālā piekļuve tiek piedāvāta REST līdzīgā stilā. Tas nozīmē, ka visiem līdzekļiem nav viena ieejas punkta, bet gan vietrādis URL, piemēram, ".../api/", kur"..." ir objekts, kuram tiek lietotas API iespējas.
Citiem vārdiem sakot, ja izvietošanas uzdevums, par kuru mēs pašlaik runājam, ir pieejams vietnē http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build, tad API svilpes šim uzdevumam ir pieejamas vietnē http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/
Tālāk mums ir izvēle, kādā formā saņemt produkciju. Koncentrēsimies uz XML, jo API ļauj filtrēt tikai šajā gadījumā.
Mēģināsim iegūt visu veikto darbu sarakstu. Mūs interesē tikai montāžas nosaukums (displayName) un tā rezultāts (radīt):
http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]Izrādījās?
Tagad filtrēsim tikai tos skrējienus, kas beidzas ar rezultātu SUCCESS. Izmantosim argumentu &izslēgt un kā parametru mēs nodosim tam ceļu uz vērtību, kas nav vienāda ar SUCCESS. Jā jā. Dubults negatīvs ir apgalvojums. Mēs izslēdzam visu, kas mūs neinteresē:
http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]&exclude=freeStyleProject/allBuild[result!='SUCCESS'] Veiksmīgo saraksta ekrānuzņēmums
Nu, prieka pēc, pārliecināsimies, ka filtrs mūs nav maldinājis (filtri nekad nemelo!), un parādīsim “neveiksmīgo” sarakstu:
http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]&exclude=freeStyleProject/allBuild[result='SUCCESS'] Ekrānuzņēmums ar neveiksmīgo sarakstu
Attālā servera mapes versiju saraksts
Ir otrs veids, kā iegūt versiju sarakstu. Man tas patīk pat vairāk nekā piekļuve Jenkins API. Nu, jo, ja lietojumprogramma tika veiksmīgi izveidota, tas nozīmē, ka tā tika iesaiņota un ievietota repozitorijā attiecīgajā mapē. Tāpat kā repozitorijs ir lietojumprogrammu darba versiju noklusējuma krātuve. Patīk. Nu, pajautāsim viņam, kādas versijas ir glabāšanā. Mēs lokosim, grep un awk attālo mapi. Ja kādam interesē oneliner, tad tas ir zem spoilera.
Vienas rindas komanda
Lūdzu, ņemiet vērā divas lietas: es nododu savienojuma informāciju galvenē, un man nav vajadzīgas visas versijas no mapes, un es atlasu tikai tās, kas tika izveidotas mēneša laikā. Rediģējiet komandu, lai tā atbilstu jūsu realitātei un vajadzībā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[^/]+' )Darbu un darba konfigurācijas faila iestatīšana pakalpojumā Jenkins
Mēs noskaidrojām versiju saraksta avotu. Tagad iekļausim iegūto sarakstu uzdevumā. Man acīmredzams risinājums bija pievienot soli lietojumprogrammas izveides uzdevumā. Solis, kas tiktu izpildīts, ja rezultāts būtu "veiksmīgs".
Atveriet montāžas uzdevumu iestatījumus un ritiniet līdz pašai apakšai. Noklikšķiniet uz pogām: Pievienot izveides soli —> nosacījuma darbība (viena). Darbības iestatījumos atlasiet nosacījumu Pašreizējais būvējuma statuss, iestatiet vērtību SUCCESS, darbība, kas jāveic, ja tas izdodas Palaidiet čaulas komandu.
Un tagad jautrākā daļa. Dženkinss saglabā darbu konfigurācijas failos. XML formātā. Paceļam http://путь-до-задания/config.xml Attiecīgi varat lejupielādēt konfigurācijas failu, rediģēt to pēc vajadzības un ievietot atpakaļ tur, kur to ieguvāt.
Atcerieties, ka mēs iepriekš vienojāmies, ka mēs izveidosim parametru versiju sarakstam BUILD_VERSION?
Lejupielādēsim konfigurācijas failu un ieskatīsimies tajā. Tikai tāpēc, lai pārliecinātos, ka parametrs ir vietā un vēlamā veida.
Ekrānuzņēmums zem spoilera.
Jūsu config.xml fragmentam vajadzētu izskatīties tāpat. Izņemot to, ka vēl trūkst izvēles elementa satura
Vai tu esi pārliecināts? Tas arī viss, rakstīsim skriptu, kas tiks izpildīts, ja būvēšana būs veiksmīga.
Skripts saņems versiju sarakstu, lejupielādēs konfigurācijas failu, ierakstīs tajā versiju sarakstu mums vajadzīgajā vietā un pēc tam ievietos to atpakaļ. Jā. Pareizi. Uzrakstiet versiju sarakstu XML formātā vietā, kur jau ir versiju saraksts (būs nākotnē, pēc pirmās skripta palaišanas). Es zinu, ka pasaulē joprojām ir nikni regulāro izteiksmju cienītāji. Es viņiem nepiederu. Lūdzu, instalējiet uz mašīnu, kurā tiks rediģēta konfigurācija. Man šķiet, ka tā nav tik liela cena, kas jāmaksā, lai izvairītos no XML rediģēšanas, izmantojot sed.
Zem spoilera es piedāvāju kodu, kas pilnībā izpilda iepriekš minēto secību.
Uzrakstiet versiju sarakstu no attālā servera mapes uz konfigurāciju
#!/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.xmlJa vēlaties iegūt versijas no Dženkinsa un esat tikpat slinks kā es, tad zem spoilera ir tas pats kods, bet saraksts no Dženkinsa:
Uzrakstiet versiju sarakstu no Jenkins līdz konfigurācijai
Vienkārši paturiet prātā: mans montāžas nosaukums sastāv no kārtas numura un versijas numura, kas atdalīti ar kolu. Attiecīgi awk nogriež nevajadzīgo daļu. Mainiet šo līniju sev atbilstoši savām vajadzībā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.xmlTeorētiski, ja esat pārbaudījis kodu, kas uzrakstīts, pamatojoties uz iepriekš minētajiem piemēriem, tad izvietošanas uzdevumā jums jau vajadzētu būt nolaižamajam sarakstam ar versijām. Tas ir tāpat kā ekrānuzņēmumā zem spoilera.
Pareizi aizpildīts versiju saraksts
Ja viss strādāja, kopējiet un ielīmējiet skriptu Palaidiet čaulas komandu un saglabājiet izmaiņas.
Savienojuma izveide ar mākoņa apvalku
Mums ir savācēji konteineros. Mēs izmantojam Ansible kā mūsu lietojumprogrammu piegādes rīku un konfigurācijas pārvaldnieku. Attiecīgi, runājot par konteineru veidošanu, prātā nāk trīs iespējas: instalēt Docker programmā Docker, instalēt Docker mašīnā, kurā darbojas Ansible, vai izveidot konteinerus mākoņa konsolē. Mēs vienojāmies šajā rakstā klusēt par Dženkinsa spraudņiem. Atceries?
Es nolēmu: labi, tā kā konteinerus “izņemtus no kastes” var savākt mākoņa konsolē, tad kāpēc uztraukties? Turiet to tīru, vai ne? Es vēlos savākt Jenkins konteinerus mākoņa konsolē un pēc tam palaist tos kuberī no turienes. Turklāt Google infrastruktūrā ir ļoti bagāti kanāli, kas labvēlīgi ietekmēs izvietošanas ātrumu.
Lai izveidotu savienojumu ar mākoņa konsoli, ir nepieciešamas divas lietas: gcloud un piekļuves tiesības Google Cloud API VM instancei, ar kuru tiks izveidots šis pats savienojums.
Tiem, kas plāno pieslēgties vispār ne no Google mākoņa
Google savos pakalpojumos pieļauj iespēju atspējot interaktīvo autorizāciju. Tas ļaus pieslēgties konsolei pat no kafijas automāta, ja tas darbojas *nix un tam ir pati konsole.
Ja man šīs piezīmes ietvaros ir nepieciešams šo jautājumu apskatīt sīkāk, rakstiet komentāros. Ja saņemsim pietiekami daudz balsu, es uzrakstīšu atjauninājumu par šo tēmu.
Vienkāršākais veids, kā piešķirt tiesības, ir tīmekļa saskarne.
- Apturiet VM gadījumu, no kura vēlāk izveidosit savienojumu ar mākoņa konsoli.
- Atveriet Instances informāciju un noklikšķiniet uz Maiņa.
- Lapas apakšā atlasiet instances piekļuves tvērumu Pilnīga piekļuve visiem mākoņa API.
Ekrānuzņēmums
- Saglabājiet izmaiņas un palaidiet instanci.
Kad virtuālā mašīna ir pabeigusi ielādi, izveidojiet savienojumu ar to, izmantojot SSH, un pārliecinieties, vai savienojums notiek bez kļūdas. Izmantojiet komandu:
gcloud alpha cloud-shell ssh Veiksmīgs savienojums izskatās apmēram šādi
Izvietot GKE
Tā kā mēs visos iespējamos veidos cenšamies pilnībā pārslēgties uz IaC (Infrastruktūra kā kods), mūsu docker faili tiek glabāti Git. Tas ir no vienas puses. Un izvietošanu kubernetes apraksta yaml fails, kuru izmanto tikai šis uzdevums, kas arī pats ir kā kods. Tas ir no otras puses. Kopumā es domāju, plāns ir šāds:
- Mēs ņemam mainīgo vērtības BUILD_VERSION un, pēc izvēles, mainīgo lielumu vērtības, kas tiks nodotas cauri ENV.
- Lejupielādējiet docker failu no Git.
- Ģenerējiet yaml izvietošanai.
- Mēs augšupielādējam abus šos failus, izmantojot scp, mākoņa konsolē.
- Mēs tur uzbūvējam konteineru un ievietojam to konteineru reģistrā
- Mēs lietojam slodzes izvietošanas failu cuber.
Būsim konkrētāki. Reiz mēs sākām runāt par ENV, tad pieņemsim, ka mums ir jānodod divu parametru vērtības: PARAM1 и PARAM2. Mēs pievienojam viņu uzdevumu izvietošanai, ierakstiet - Virknes parametrs.
Ekrānuzņēmums
Mēs ģenerēsim yaml ar vienkāršu novirzīšanu palaist garām uz failu. Protams, tiek pieņemts, ka tas ir jūsu dockerfile PARAM1 и PARAM2ka slodzes nosaukums būs awesomeapp, un saliktais konteiners ar norādītās versijas lietojumprogrammu atrodas Konteineru reģistrs paceļam gcr.io/awesomeapp/wesomeapp-$BUILD_VERSIONKur $BUILD_VERSION tikko tika atlasīts no nolaižamā saraksta.
Komandu saraksts
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.yamlDženkinsa aģents pēc savienošanas, izmantojot gcloud alfa cloud-shell ssh interaktīvais režīms nav pieejams, tāpēc mēs nosūtām komandas uz mākoņa konsoli, izmantojot parametru -- pavēli.
Mēs notīrām mājas mapi mākoņa konsolē no vecā dockerfaila:
gcloud alpha cloud-shell ssh --command="rm -f Dockerfile"Novietojiet tikko lejupielādēto dockerfile mākoņa konsoles mājas mapē, izmantojot scp:
gcloud alpha cloud-shell scp localhost:./Dockerfile cloudshell:~Mēs apkopojam, atzīmējam un nospiežam konteineru uz konteineru reģistru:
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"
Mēs darām to pašu ar izvietošanas failu. Lūdzu, ņemiet vērā, ka tālāk norādītajās komandās tiek izmantoti izdomāti klastera nosaukumi, kurā notiek izvietošana (awsm-klasteris) un projekta nosaukums (superīgs projekts), kur atrodas klasteris.
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"Mēs izpildām uzdevumu, atveram konsoles izvadi un ceram redzēt veiksmīgu konteinera montāžu.
Ekrānuzņēmums
Un tad veiksmīga saliktā konteinera izvietošana
Ekrānuzņēmums
Es apzināti ignorēju iestatījumu Iekļūšana. Viena vienkārša iemesla dēļ: kad esat to iestatījis darba slodze ar noteiktu nosaukumu, tas darbosies neatkarīgi no tā, cik izvietošanas ar šo nosaukumu veicat. Nu, kopumā tas ir nedaudz ārpus vēstures tvēriena.
Secinājumu vietā
Visas iepriekš minētās darbības, iespējams, nevarēja izdarīt, bet vienkārši instalēja kādu spraudni Jenkins, viņu muuulion. Bet man nez kāpēc nepatīk spraudņi. Nu, precīzāk, es pie tiem ķeros tikai aiz izmisuma.
Un man vienkārši patīk izvēlēties kādu jaunu tēmu. Iepriekš minētais teksts ir arī veids, kā dalīties ar atklājumiem, ko izdarīju, risinot pašā sākumā aprakstīto problēmu. Dalieties ar tiem, kuri, tāpat kā viņš, nepavisam nav briesmīgi vilki devops. Ja mani atklājumi vismaz kādam palīdzēs, es priecāšos.
Avots: www.habr.com