Aloita Serverless Jenkins X:n käyttö

Tässä kirjoituksessa tarkastelen lähemmin Tektonia käyttävää Jenkins X -versiota, jotta saat käsityksen siitä, miltä yleinen kehitys-, build-, testaus- ja käyttöönottovirta näyttää Jenkins X:ssä. Miltä tuntuu viedä koodisi tuotantoon Jenkins-yhteisöstä peräisin olevalla tuotteella, jossa on hyvin vähän Jenkinsiä?

Arvioitu aika tämän ohjeen kaikkien vaiheiden läpikäyntiin: 60–90 minuuttia. Lukuaika: 15 minuuttia.

Siirry blogin eri osioihin:

• Jenkins X ja Tekton

• Tarvitsemasi työkalut

• Ota Jenkins X käyttöön

• Luo uusi sovellus

• Luo tunneli ja päivitä webhookit

• Ymmärrä tähänastinen kokonaisuus

• Toteuta pieni ominaisuus ja ota se käyttöön

• Muutama loppuhuomio

Jenkins X ja Tekton

Jenkins X -projekti on ollut olemassa lähes kaksi vuotta, ja noin kuukausi ensimmäisen syntymäpäivänsä jälkeen tiimi julkaisi Tektonin päällä toimivan uuden Jenkins X Pipeline Enginen.

Jenkins X on käytännössä Jenkinsin coolimpi serkku – Jenkins-yhteisön pitkään odotettu Cloud Native -vaihtoehto. Se perustuu vahvasti tiettyihin käytäntöihin, ja sitä ovat inspiroineet merkittävästi Accelerate-kirjassa kuvatut DevOps-käytännöt, joiden on osoitettu parantavan ohjelmisto-organisaatioiden suorituskykyä kestävällä tavalla.

Kubernetes-klusteriin asennettavaksi valitsemastasi versiosta riippuen käytössäsi voi olla staattisen Jenkins masterin sisältävä versio tai uusi serverless Jenkins X Pipelines, joka käyttää Tektonia ”Jenkinsin sijaan taustalla toimivana CI/CD-enginenä modernin, erittäin käytettävissä olevan Cloud Native -arkkitehtuurin tarjoamiseksi”.

Tekton on pohjimmiltaan joukko Kubernetes Custom Resource Definitioneja (CRD), joita käytetään CI/CD-tyylisten putkien määrittelyyn Kubernetesissa. Voit lukea niistä lisää virallisesta dokumentaatiosta, mutta tätä tietoa ei tarvita tämän kirjoituksen seuraamiseen.

Tarvitsemasi työkalut

• Jenkins X, vaihtoehtona Serverless Jenkins X Pipelines with Tekton

• Tekton

• Minikube

• Ngrok

• GitHub

Ota Jenkins X käyttöön

Huomautus: Tässä kirjoituksessa käytettävä Jenkins X:n oletusasetus edellyttää GitHub-tiliä. Sitä käytetään muutaman repositorion luomiseen (yksi jokaista ympäristöä sekä kehitysprojektia varten) ja webhookien määrittämiseen niistä paikallisessa Kubernetes-klusterissa toimiviin Tekton-resursseihin.

Ensimmäinen vaihe on asentaa Jenkins X CLI paikalliselle koneellesi. Käyttämästäsi käyttöjärjestelmästä riippuen tähän on useita vaihtoehtoja. Koska käytän macOS:ää ja minulla on brew asennettuna, teen sen brewilla:

brew tap jenkins-x/jx brew install jx

Nyt kun jx on asennettu, asennetaan Jenkins X Kubernetes-klusteriin. Jos sinulla ei satu olemaan käyttämätöntä Kubernetes-klusteria, ei hätää: käytä Minikubea, yksinkertaista vaihtoehtoa, joka ajaa yhden noodin Kubernetes-klusteria tietokoneellasi. Jenkins X sisältää onneksi erityisen komennon Jenkins X:n asentamiseen Minikubeen. Se asentaa myös Minikuben ja kaikki sen riippuvuudet, jos niitä ei ole vielä asennettu.

Tätä kirjoitettaessa Kubernetes 1.16 julkaistiin juuri, ja näyttää siltä, että Jenkins X:n käyttämät Deployment-resurssit käyttävät tukematonta extensions/v1beta1-API-ryhmää. Suosittelen siksi määrittämään asennettavan Kubernetes-version erikseen, kunnes ongelma on korjattu:

jx create cluster minikube --kubernetes-version=v1.15.4

Suosittelen myös käyttämään seuraavia asetuksia oletusasetusten sijaan, kun jx pyytää määrittämään muistin, CPU:n ja levyn koon. Näin varmistat, että kaikkea varten on riittävästi resursseja:

? memory (MB) 8192 ? cpu (cores) 6 ? disk-size (MB) 150GB ? Select driver: hyperkit

Valitse Serverless Jenkins X Pipelines with Tekton, kun sinua pyydetään valitsemaan Jenkins-asennuksen tyyppi. Myöhemmin sinun on luotava API-token GitHub-tilillesi ja annettava se asennusta varten. Asennus voi kestää hetken, sillä ladattavana on paljon Docker-imageja. Suosittelenkin tekemään asennuksen nopealla internetyhteydellä.

Huomautus: Jos valitsit hyperkitin ja olet yhdistetty VPN:ään ajaessasi yllä olevaa komentoa, se todennäköisesti epäonnistuu Minikuben uudelleen ilmenneen bugin vuoksi. Kun katkaiset VPN-yhteyden ja yrität uudelleen (poista Minikube-klusteri, .minikube ja .jx), kaiken pitäisi toimia hyvin. —

Jos näet alla olevan kaltaisen tulosteen, asennus on valmistunut onnistuneesti ja Jenkins X on käynnissä paikallisessa klusterissasi:

Jenkins X installation completed successfully	********************************************************	     NOTE: Your admin password is: q0DVn0ylXXEn_MVH5x3-	********************************************************Your Kubernetes context is now set to the namespace: jxTo switch back to your original namespace use: jx namespace defaultOr to use this context/namespace in just one terminal use: jx shellFor help on switching contexts see: https://jenkins-x.io/developing/kube-context/To import existing projects into Jenkins:       jx importTo create a new Spring Boot microservice:       jx create spring -d web -d actuatorTo create a new microservice from a quickstart: jx create quickstartContext "minikube" modified.NAME              HOSTS                                    ADDRESS        PORTS   AGEchartmuseum       chartmuseum.jx.192.168.64.8.nip.io       192.168.64.8   80      92sdeck              deck.jx.192.168.64.8.nip.io              192.168.64.8   80      92sdocker-registry   docker-registry.jx.192.168.64.8.nip.io   192.168.64.8   80      91shook              hook.jx.192.168.64.8.nip.io              192.168.64.8   80      92snexus             nexus.jx.192.168.64.8.nip.io             192.168.64.8   80      91stide              tide.jx.192.168.64.8.nip.io              192.168.64.8   80      92s

Huomaa alareunassa olevat hostit. Ne ovat käteviä URL-osoitteita, jotka käyttävät loistavaa nip.io-palvelua. Palvelu ohjaa käytännössä kaikki tämänmuotoiset DNS-kyselyt URL-osoitteessa olevaan IP-osoitteeseen. Viittaamme näihin tietueisiin jatkossa nimellä klusterin Ingressit. Omassa tapauksessani 192.168.64.8 on Minikube-klusterin paikallinen IP-osoite, ja kaikki nämä DNS-tietueet on määritetty Ingress-säännöiksi, jotka osoittavat paikallisessa Minikube-klusterissani käynnissä oleviin palveluihin.

Huomautus: Joissakin tapauksissa nip.io-palvelu ei ehkä ole käytettävissä verkostasi, jolloin klusterin Ingressien verkkotunnukset eivät toimi. Yksi syy siihen, ettei tietueita ratkaista paikallisesti, voi olla reitittimesi käytössä oleva DNS Rebinding -tarkistus. Se hylkää käytännössä kaikki yksityisiä IP-osoitteita palauttavat DNS-vastaukset. Avaa asennuksesi deck-URL-osoite, joka omassa tapauksessani on http://deck.jx.192.168.64.8.nip.io. Jos et näe perinteistä kirjautumisikkunaa, joko nip.io ei toimi sinulla tai deck-podissa on jotain vialla. Jos pod on kunnossa, suosittelen tarkistamaan reitittimesi asetukset ja etsimään DNS rebinding -tarkistusten asetuksia tai lisäämään /etc/hosts-tiedostoon tietueen kaikille klusterin Ingressien hosteille. Jos valitset /etc/hosts-vaihtoehdon, huomioi, että lisättäviä hosteja tulee lisää edetessämme.

Jos listaat luodut namespace-alueet, näet todennäköisesti tämänkaltaisen luettelon:

$ k get nsNAME              STATUS   AGEdefault           Active   26mjx                Active   24mjx-production     Active   18mjx-staging        Active   18mkube-node-lease   Active   26mkube-public       Active   26mkube-system       Active   26m

jx-production- ja jx-staging-namespace-alueet vastaavat Jenkins X:n oletuksena luomia production- ja vastaavasti staging-ympäristöjä. Asennuksen aikana GitHub-tilillesi luotiin myös näitä ympäristöjä vastaavat yksityiset repositoriot:

Kerron näistä ympäristöistä ja repositorioista lisää hieman myöhemmin. Luodaan nyt kehitettävä projekti!

Luo uusi sovellus

Jenkins X tarjoaa laajan valikoiman sovellusmalleja, joiden avulla pääset helposti alkuun. Jos kuitenkin kaipaat valikoimaan jotain, voit lisätä oman mallisi PR:n kautta. Valitsin tätä ohjetta varten mallin react-quickstart. Voit tehdä samoin seuraavalla komennolla:

jx create quickstart -f react-quickstart

Päätin nimetä projektin react-quickstart-jenkinsx ja pyysin jx:ää luomaan repositorion määritetylle GitHub-tililleni. Tässä vaiheessa ensimmäinen pipeline on käynnistetty puolestasi. Suosittelen käyttämään hetken ja ajamaan komennon jx get activity -f <repo_name> -w, jossa repo_name on jx create quickstart-komennolle antamasi repositorion nimi.

Näet kaikki nykyisessä pipelinessa käynnissä olevat vaiheet ja saat käsityksen siitä, mitä Jenkins X on määrittänyt automaattisesti. Älä kuitenkaan jää seuraamaan sitä liian pitkäksi aikaa. Koska ajamme klusteria paikallisesti, meidän on korjattava muutama asia ennen kuin pipeline voi valmistua.

Luo tunneli ja päivitä webhookit

Huomasit todennäköisesti konsolitulosteessa kohdan Creating GitHub webhook ja ehkä myös nopeasti, että hookin URL-osoite ohjautuu yksityiseen IP-osoitteeseen. GitHub ei pääse siihen käsiksi, joten repositorioidesi webhookit eivät tässä vaiheessa toimi. Korjataan asia!

Helppo tapa tehdä tämä on käyttää ngrok.io:ta. Luo siis maksuton tili heidän verkkosivustollaan. Seuraavaksi määritetään se:

Noudata vaiheita 1–3. Kun olet tehnyt ne, kaikki on valmista.

Tässä haluamme avata tunnelin paikalliselta tietokoneeltamme ulkoiseen URL-osoitteeseen, mutta emme millä tahansa tavalla. Haluamme, että ngrok tekee myös host-uudelleenkirjoituksen, sillä klusterimme Ingress-säännöt tarvitsevat sitä erottaakseen eri palvelut, joihin haluamme päästä käsiksi. Voimme tehdä tämän seuraavalla komennolla, jossa <hook_host> on klusterin Ingressien hook-host:

ngrok http -host-header=rewrite <hook_host>:80

Seuraavaksi näet todennäköisesti alla olevan kaltaisen tulosteen, kun tunneli on valmis. Huomaa Forwarding-tietueet:

Kun ulkoinen URL-osoite on käytössä, seuraavaksi päivitetään GitHub-repositorioiden webhookit. Siirry tätä varten jokaisen repositorion Settings -> Webhooks -sivulle: staging-, tuotanto- ja itse projektille luotuun repositorioon. Muokkaa kunkin repositorion olemassa olevaa webhookia ja vaihda Payload URL -kenttään ngrok.io-URL-osoite nip.io-osoitteen tilalle. Tässä esimerkki tuotantorepositoriostani:

Napsauta sivun alareunasta Update webhook. Kun muutos on tallennettu, laajenna Recent Deliveries -osion viimeisin tietue napsauttamalla sitä ja käynnistä sitten Redeliver. Jos kaikki meni hyvin, juuri uudelleenlähettämäsi toimituksen vieressä näkyy vihreä valintamerkki. Varmista nyt, että kaikkien kolmen repositorion webhook on päivitetty ja että viimeisin toimitus on vihreä.

Ymmärrä tähänastinen kokonaisuus

Kun kaikki webhookit on päivitetty ja lähetetty uudelleen, useiden pipelinejen pitäisi käynnistyä. Jos kaikki menee hyvin, komennon jx get activities tuloste näyttää kaikki tähän mennessä suoritetut pipelinet ja niiden vaiheet.

Voit tarkastella samoja pipelineja Prow-hallintapaneelissa, johon pääset klusterin Ingressien yhteydessä näkyvästä deck-URL-osoitteesta (minulla se on http://deck.jx.192.168.64.18.nip.io/). Sinulta saatetaan pyytää käyttäjätunnusta ja salasanaa: käytä käyttäjätunnuksena admin, ja salasana näkyy komennon jx create cluster konsolitulosteessa.

Tähän mennessä suoritetut pipelinet ovat seuraavat: yksi projektimme master-haaralle, yksi staging-repositorion ensimmäiselle PR:lle ja yksi saman repositorion master-haaralle. Tässä vaiheessa varmasti mietit, miten kaikki nämä pipelinet ilmestyivät ja mikä tai kuka ne loi. Yritän selittää sen alla. Seuraavat kaaviot havainnollistavat hyvin yksinkertaistetusti, mitä tapahtuu. Ne keskittyvät repositorioissa ja klusterin ympäristöjen namespaceissa tapahtuviin muutoksiin.

Luotiin klusteri, johon on asennettu Jenkins X

Kun luomme uuden klusterin Jenkins X:llä, CLI luo kaikki tarvittavat resurssit. Se luo muun muassa uuden paikallisen Minikube-klusterin, jossa on useita namespaceja, mukaan lukien staging-ympäristön ja tuotantoympäristön namespacet. Tässä vaiheessa ne ovat molemmat tyhjiä. Luodaan myös muita namespaceja, joita ei tässä näytetä, mukaan lukien jx-namespace, joka sisältää kaikki tarvittavat työkalut Jenkins X:n ja pipelinejen suorittamiseen klusterissa.

jx create cluster luo myös kaksi uutta GitHub-repositoriota: yhden staging-ympäristölle ja toisen tuotantoon. Repositorioiden nimet luodaan muodossa environment-$prefix-$environmentName. $prefix luodaan tavallisesti satunnaisesti, mutta voit määrittää sen komennon jx create cluster argumentilla --default-environment-prefix.

Yhtään pipelinea ei ole vielä suoritettu, sillä CLI teki kaikki asetukset.

Luotiin uusi sovellus valmista quickstart-mallia käyttäen

Seuraavassa vaiheessa loin Jenkins X:llä kehitettävän uuden sovelluksen ja käytin yhtä sen quickstart-malleista uuden ReactJS-sovelluksen luomiseen. Tämäkin tehdään Jenkins X CLI:llä.

1. Uusi repositorio luodaan paikallisesti ja siirretään määritetylle GitHub-tilille. Repositorion sisältö perustuu quickstart-mallin tiedostoihin (jokainen quickstart on repositorio tässä projektissa) sekä projektissa käytettyjä teknologioita vastaavaan build packiin. Tähän projektiin valittu build pack on javascript-paketti, ja se kopioi osan tiedostoistaan, kuten Dockerfilen, projektiin ensimmäistä committia varten. Dockerfileä käytetään sovelluksen suorittamiseen kaikissa ympäristöissä.

2. Sovellusrepositorion ensimmäinen commit käynnistää ensimmäisen pipelinen, joka buildaa sovelluksen ja luo Dockerfilen tästä sovellusversiosta. Koska kaikki sovellusrepositorion master-haaraan tehdyt commitit ylennetään oletusarvoisesti automaattisesti stagingiin, pipeline luo myös uuden haaran ja PR:n staging-repositorioon version 0.0.1 käyttöönottoa varten. Tämän jälkeen ensimmäinen pipeline odottaa, kunnes promotion-buildit suoritetaan tai sen aikakatkaisu umpeutuu – sen mukaan, kumpi tapahtuu ensin.

3. Staging-repositorioon luotu uusi promotion-PR käynnistää toisen pipelinen, joka valmistelee Helm chartin staging-käyttöönottoa varten ja julkaisee sen klusterin chart-museum-palveluun. Kun tämä on tehty, toinen pipeline yhdistää PR:n staging-repositorion master-haaraan. Tämä vapauttaa ensimmäisen pipelinen ja käynnistää uuden buildin sovelluksen käyttöönottoa varten stagingiin.

Uusi repositorio luodaan paikallisesti ja siirretään määritetylle GitHub-tilille. Repositorion sisältö perustuu quickstart-mallin tiedostoihin (jokainen quickstart on repositorio tässä projektissa) sekä projektissa käytettyjä teknologioita vastaavaan build packiin. Tähän projektiin valittu build pack on javascript-paketti, ja se kopioi osan tiedostoistaan, kuten Dockerfilen, projektiin ensimmäistä committia varten. Dockerfileä käytetään sovelluksen suorittamiseen kaikissa ympäristöissä.

Sovellusrepositorion ensimmäinen commit käynnistää ensimmäisen pipelinen, joka buildaa sovelluksen ja luo Dockerfilen tästä sovellusversiosta. Koska kaikki sovellusrepositorion master-haaraan tehdyt commitit ylennetään oletusarvoisesti automaattisesti stagingiin, pipeline luo myös uuden haaran ja PR:n staging-repositorioon version 0.0.1 käyttöönottoa varten. Tämän jälkeen ensimmäinen pipeline odottaa, kunnes promotion-buildit suoritetaan tai sen aikakatkaisu umpeutuu – sen mukaan, kumpi tapahtuu ensin.

Uusi promote-PR staging-repositoriossa käynnistää uuden putken, joka valmistelee Helm chartin käyttöönottoa varten staging-ympäristöön ja julkaisee sen klusterin chart-museumiin. Kun tämä on tehty, toinen putki yhdistää PR:n staging-repositorion master-haaraan. Tämä vapauttaa ensimmäisen putken ja käynnistää uuden buildin sovelluksen käyttöönottoa varten staging-ympäristöön.

Tämän vaiheen lopussa sovellus on käynnissä staging-ympäristössä. Sen URL-osoite löytyy helposti komennolla jx get applications.

Toteuta pieni ominaisuus ja ota se käyttöön

Nyt kun toimintaperiaate on hieman selkeämpi, kokeillaan toteuttaa React-sovellukseemme muutamia ominaisuuksia ja katsotaan, miten Jenkins X:n avulla ne voidaan toimittaa tuotantoon.

Teen pienen muutoksen projektimme pääkomponenttiin ja lisään sivulle uuden tekstirivin: Lisäsin projektiimme pienen mutta tärkeän muutoksen.

Luon sitten uuden haaran nimeltä new-feature ja pushan sen etärepositorioon. Seuraavaksi luon tästä haarasta PR:n masteriin ja odotan uuden putken käynnistymistä. Näen putken etenemisen ja sen sisältämät vaiheet seuraavalla komennolla:

jx get activities -f react-quickstart-jenkinsx/PR-1 -w

Kuten ehkä arvasitkin, jokainen push haaraan, josta on tehty pull request, käynnistää uuden putken. Putken nimi on muotoa: <repo-owner>/<repo-name>/PR-<pull-request-number>

Jos putki valmistuu onnistuneesti, tulosteen pitäisi näyttää tältä:

alexchiri/react-quickstart-jenkinsx/PR-1 #1                2m51s    2m41s Succeeded  meta pipeline                                            2m51s      20s Succeeded    Credential Initializer 5ftfw                           2m51s       0s Succeeded    Working Dir Initializer 8v64t                          2m51s       1s Succeeded    Place Tools                                            2m50s       1s Succeeded    Git Source Meta Alexchiri React Quickstart Ch8zz       2m49s       6s Succeeded https://github.com/alexchiri/react-quickstart-jenkinsx.git    Git Merge                                              2m43s       3s Succeeded    Merge Pull Refs                                        2m40s       2s Succeeded    Create Effective Pipeline                              2m38s       5s Succeeded    Create Tekton Crds                                     2m33s       2s Succeeded  from build pack                                          2m28s    2m18s Succeeded    Credential Initializer Tsg4g                           2m28s       0s Succeeded    Working Dir Initializer N72vt                          2m28s       1s Succeeded    Place Tools                                            2m27s       1s Succeeded    Git Source Alexchiri React Quickstart Jenk Ndg74       2m26s       7s Succeeded https://github.com/alexchiri/react-quickstart-jenkinsx.git    Git Merge                                              2m19s       3s Succeeded    Build Npmrc                                            2m16s       2s Succeeded    Build Npm Install                                      2m14s      38s Succeeded    Build Npm Test                                         1m36s       4s Succeeded    Build Container Build                                  1m32s      24s Succeeded    Postbuild Post Build                                    1m8s       1s Succeeded    Promote Make Preview                                    1m7s      18s Succeeded    Promote Jx Preview                                       49s      39s Succeeded  Preview                                                    31s           https://github.com/alexchiri/react-quickstart-jenkinsx/pull/1    Preview Application                                      31s           http://react-quickstart-jenkinsx.jx-alexchiri-react-quickstart-jenkinsx-pr-1.192.168.64.18.nip.io

Huomaa putken viimeinen vaihe: meille luotiin myös Preview-ympäristö, jossa muutoksia voi kokeilla väliaikaisessa ympäristössä. Sain lisäksi PR:ääni kommentin – Jenkins X -botin tekemänä tunnuksillani – jossa oli Preview-ympäristön URL-osoite:

(kuvakaappaus)

Totta kai URL-osoitetta seuraamalla näemme toteuttamamme ominaisuuden toiminnassa:

Pidän toteutuksen ulkoasusta, joten seuraavaksi yhdistän pull requestin ja promotoimme tämän ominaisuuden staging-ympäristöön. Tätä varten minun tarvitsee vain yhdistää pull request ja antaa putkien hoitaa loput.

Huomautus: Pull request on tarkoitus yhdistää hyväksymällä se GitHubissa botin tunnistamalla komennolla, kuten /lgtm, ja antamalla putkien tehdä yhdistäminen. Tätä varten tarvitsisin kuitenkin toisen GitHub-käyttäjän, jonka voisin lisätä tarkistajaksi ja jolla pull request hyväksyttäisiin. Oletuksena on, että projektissa työskentelee tavallisesti tiimi, joten projektilla on useita omistajia, jotka tarkistavat pull requestit. Voit määrittää nämä käyttäjät muokkaamalla projektirepositorion OWNERS-tiedostoa.

Pian yhdistämisen jälkeen käynnistyy uusi putki, joka julkaisee muutokset staging-ympäristöön. Tämä tapahtuu samalla tavalla kuin versio 0.0.1 julkaistiin aluksi staging-ympäristöön, kun react-quickstart-jenkinsx-repositorioon tehtiin ensimmäinen commit.

Tässä vaiheessa voit tarkistaa, mitkä previewt ovat edelleen käynnissä komennolla jx get previews. Huomaat, että ensimmäistä pull requestiamme varten luotu Preview-ympäristö on edelleen käynnissä, vaikka PR on yhdistetty. Voit joko antaa Jenkins X:n cron jobin poistaa sen – se ajetaan kolmen tunnin välein – tai poistaa ympäristöt manuaalisesti CLI:llä:

jx delete preview

Olemme siis toteuttaneet projektiimme uuden ominaisuuden, testanneet sitä Preview-ympäristössä ja promotoineet sen staging-ympäristöön. Oletetaan, että olemme tehneet lisää testejä staging-ympäristössä ja olemme tyytyväisiä tuloksiin. Miten promotoimme sen tuotantoon?

Käytämme yksinkertaisesti promote-komentoa:

jx promote react-quickstart-jenkinsx --version 0.0.2 --env production

Kuten varmasti arvasit, tämä käynnisti kaksi uutta buildia: ensimmäinen loi tuotantorepositorioon pull requestin uudella versiolla, ja toinen yhdisti sen ja otti sen käyttöön tuotantoympäristössä. Kun tämä on tehty, voimme käyttää sovellustamme uuden ominaisuuden kanssa tuotannon URL-osoitteessa. Voit milloin tahansa tarkastella hallinnoimiasi sovelluksia ja niiden URL-osoitteita eri ympäristöissä suorittamalla komennon jx get applications. Tulosteen pitäisi näyttää suunnilleen tältä:

APPLICATION               STAGING PODS URL                                                              PRODUCTION PODS URLreact-quickstart-jenkinsx 0.0.2   1/1  http://react-quickstart-jenkinsx.jx-staging.192.168.64.18.nip.io 0.0.2      1/1  http://react-quickstart-jenkinsx.jx-production.192.168.64.18.nip.io

Käytä tuotannon URL-osoitetta, niin näet samat muutokset käyttöönotettuina, kun putki valmistuu. Alla on yksinkertaistettu esitys siitä, mitä tuotantoon promotoitaessa tapahtui:

Huomautus: Jos haluat siivota ympäristösi ja poistaa Jenkins X:n Minikube-klusterista, voit käyttää komentoa jx uninstall ja seurata CLI:n näyttämiä ohjeita. Se poistuu klusterista hetkessä!

Muutama loppuhuomio

Tämä läpikäynti raapaisee vain pintaa. Emme ole käsitelleet monia loistavia lisäosia, kuten monitorointiin tarkoitettua Prometheusta tai sovellusten ja resurssien parempaan hallintaan tarkoitettuja KNativea ja Gloota, emmekä ominaisuuksia, kuten Dev Podseja.

Uskon, että niitä on tulossa vielä lisää ja että kuulemme näistä sekä Jenkins X:stä paljon enemmän tulevina vuosina.

Tässä vaiheessa Jenkins X vaikuttaa yhä olevan varhaisessa kehitysvaiheessa. Sitä kehitetään aktiivisesti, ja dokumentaatiota voisi parantaa huomattavasti, erityisesti käyttäjille, jotka eivät käytä oletuskonfiguraatiota ja -asetuksia.

Siitä huolimatta se lupaa kehittyä erittäin tehokkaaksi työkaluksi, joka tukee tiimien hyviä toimintatapoja. Samalla se hyödyntää ajantasaisia CI/CD-parhaita käytäntöjä.