Me True Engineeringissä olemme luoneet prosessin päivitysten jatkuvaa toimittamista varten asiakkaiden palvelimille ja haluamme jakaa tämän kokemuksen.
Aluksi kehitimme asiakkaalle verkkojärjestelmän ja otimme sen käyttöön omassa Kubernetes-klusterissamme. Nyt suuren kuormituksen ratkaisumme on siirtynyt asiakkaan alustalle, jolle olemme määrittäneet täysin automaattisen jatkuvan käyttöönottoprosessin. Tämän ansiosta nopeutimme markkinoille tuloa – muutosten toimittamista tuoteympäristöön.
Tässä artikkelissa puhumme kaikista Continuous Deployment (CD) -prosessin vaiheista tai päivitysten toimittamisesta asiakkaan alustalle:
- Miten tämä prosessi alkaa?
- synkronointi asiakkaan Git-tietovaraston kanssa,
- tausta- ja käyttöliittymän kokoonpano,
- automaattinen sovellusten käyttöönotto testiympäristössä,
- automaattinen käyttöönotto Prod.
Jaamme asennustiedot matkan varrella.
1. Käynnistä CD
Jatkuva käyttöönotto alkaa, kun kehittäjä tekee muutoksia Git-tietovarastomme julkaisuhaaraan.
Sovelluksemme toimii mikropalveluarkkitehtuurilla ja kaikki sen komponentit on tallennettu yhteen arkistoon. Tämän ansiosta kaikki mikropalvelut kerätään ja asennetaan, vaikka yksi niistä olisi muuttunut.
Järjestimme työn yhden arkiston kautta useista syistä:
- Kehittämisen helppous - sovellus kehittyy aktiivisesti, joten voit työskennellä kaiken koodin kanssa kerralla.
- Yksi CI/CD-putkilinja, joka takaa, että sovellus yhtenä järjestelmänä läpäisee kaikki testit ja toimitetaan asiakkaan tuotantoympäristöön.
- Poistamme sekaannukset versioissa - meidän ei tarvitse tallentaa mikropalveluversioiden karttaa ja kuvata sen konfiguraatiota kullekin mikropalvelulle Helm-skripteissä.
2. Synkronointi asiakkaan lähdekoodin Git-tietovaraston kanssa
Tehdyt muutokset synkronoidaan automaattisesti asiakkaan Git-tietovaraston kanssa. Siellä konfiguroidaan sovelluskokoonpano, joka käynnistetään haaran päivityksen jälkeen, ja käyttöönotto jatkuu. Molemmat prosessit ovat peräisin ympäristöstään Git-varastosta.
Emme voi työskennellä suoraan asiakkaan arkiston kanssa, koska tarvitsemme omat ympäristömme kehitystä ja testausta varten. Käytämme Git-tietovarastoamme näihin tarkoituksiin - se on synkronoitu heidän Git-tietovarastonsa kanssa. Heti kun kehittäjä lähettää muutoksia arkistomme sopivaan haaraan, GitLab välittää nämä muutokset välittömästi asiakkaalle.
Tämän jälkeen sinun on suoritettava kokoonpano. Se koostuu useista vaiheista: backend ja frontend kokoonpano, testaus ja toimitus tuotantoon.
3. Taustan ja käyttöliittymän kokoaminen
Tausta- ja käyttöliittymän rakentaminen ovat kaksi rinnakkaista tehtävää, jotka suoritetaan GitLab Runner -järjestelmässä. Sen alkuperäinen kokoonpanokokoonpano sijaitsee samassa arkistossa.
.
GitLab Runner ottaa koodin vaaditusta arkistosta, kokoaa sen Java-sovelluksen rakennuskomennolla ja lähettää sen Docker-rekisteriin. Täällä kokoamme tausta- ja käyttöliittymän, hankimme Docker-kuvat, jotka laitamme arkistoon asiakkaan puolelle. Käytämme Docker-kuvien hallintaan .
Synkronoimme kuviemme versiot Dockerissa julkaistavan julkaisuversion kanssa. Sujuvan toiminnan takaamiseksi olemme tehneet useita säätöjä:
1. Säiliöitä ei rakenneta uudelleen testiympäristön ja tuotantoympäristön välillä. Teimme parametrisointeja, jotta sama kontti toimisi kaikkien asetusten, ympäristömuuttujien ja palveluiden kanssa sekä testiympäristössä että tuotannossa ilman uudelleenrakentamista.
2. Jos haluat päivittää sovelluksen Helmin kautta, sinun on määritettävä sen versio. Rakennamme taustajärjestelmän, käyttöliittymän ja päivitämme sovelluksen - nämä ovat kolme eri tehtävää, joten on tärkeää käyttää samaa sovelluksen versiota kaikkialla. Käytämme tähän tehtävään Git-historian tietoja, koska K8S-klusterikokoonpanomme ja sovelluksemme ovat samassa Git-varastossa.
Saamme sovellusversion komennon suoritustuloksista
git describe --tags --abbrev=7.
4. Kaikkien testiympäristön (UAT) muutosten automaattinen käyttöönotto
Seuraava vaihe tässä rakennuskomentosarjassa on päivittää K8S-klusteri automaattisesti. Tämä tapahtuu, jos koko sovellus on rakennettu ja kaikki artefaktit on julkaistu Docker-rekisteriin. Tämän jälkeen testiympäristön päivitys alkaa.
Klusteripäivitys alkaa käyttää . Jos tämän seurauksena jokin ei mennyt suunnitelmien mukaan, Helm peruuttaa automaattisesti ja itsenäisesti kaikki muutokset. Hänen työtään ei tarvitse valvoa.
Toimitamme K8S-klusterikokoonpanon kokoonpanon mukana. Siksi seuraava askel on päivittää se: configMaps, käyttöönotot, palvelut, salaisuudet ja muut muuttamamme K8S-kokoonpanot.
Helm suorittaa sitten itse sovelluksen RollOut-päivityksen testiympäristössä. Ennen kuin sovellus otetaan tuotantoon. Tämä tehdään, jotta käyttäjät voivat testata manuaalisesti testiympäristöön lisäämiämme liiketoimintaominaisuuksia.
5. Kaikkien muutosten automaattinen käyttöönotto Prod
Jos haluat ottaa päivityksen käyttöön tuotantoympäristöön, sinun tarvitsee vain napsauttaa yhtä painiketta GitLabissa - ja säiliöt toimitetaan välittömästi tuotantoympäristöön.
Sama sovellus voi toimia eri ympäristöissä – testauksessa ja tuotannossa – ilman uudelleenrakentamista. Käytämme samoja artefakteja muuttamatta mitään sovelluksessa ja asetamme parametrit ulkoisesti.
Sovellusasetusten joustava parametrointi riippuu ympäristöstä, jossa sovellus suoritetaan. Olemme siirtäneet kaikki ympäristöasetukset ulkoisesti: kaikki parametroidaan K8S-konfiguraation ja Helmin parametrien kautta. Kun Helm ottaa käyttöön kokoonpanon testiympäristössä, testiasetuksia käytetään siihen ja tuoteasetuksia tuotantoympäristöön.
Vaikeinta oli parametroida kaikki käytetyt ympäristöstä riippuvat palvelut ja muuttujat ja kääntää ne ympäristömuuttujiksi ja ympäristöparametrien kuvaus-konfiguraatioiksi Helmille.
Sovellusasetukset käyttävät ympäristömuuttujia. Niiden arvot asetetaan säilöihin K8S-konfiguraatiokartalla, joka on laadittu Go-malleilla. Esimerkiksi ympäristömuuttujan asettaminen toimialueen nimelle voidaan tehdä seuraavasti:
APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}
.Values.global.env – tämä muuttuja tallentaa ympäristön nimen (prod, stage, UAT).
.Values.app.properties.app_external_domain – tässä muuttujassa asetamme halutun verkkotunnuksen .Values.yaml-tiedostoon
Sovellusta päivittäessään Helm luo malleista configmap.yaml-tiedoston ja täyttää APP_EXTERNAL_DOMAIN-arvon halutulla arvolla riippuen ympäristöstä, jossa sovelluspäivitys alkaa. Tämä muuttuja on jo asetettu säilöön. Sitä voidaan käyttää sovelluksesta, joten jokaisella sovellusympäristöllä on eri arvo tälle muuttujalle.
Suhteellisen äskettäin K8S-tuki ilmestyi Spring Cloudiin, mukaan lukien työskentely configMapsin kanssa: . Vaikka projekti kehittyy aktiivisesti ja muuttuu radikaalisti, emme voi hyödyntää sitä tuotannossa. Mutta seuraamme aktiivisesti sen kuntoa ja käytämme sitä DEV-kokoonpanoissa. Heti kun se tasaantuu, siirrymme ympäristömuuttujien käytöstä siihen.
Yhteensä
Jatkuva käyttöönotto on siis määritetty ja toimii. Kaikki päivitykset tapahtuvat yhdellä näppäimen painalluksella. Muutosten toimitus tuoteympäristöön on automaattinen. Ja mikä tärkeintä, päivitykset eivät pysäytä järjestelmää.
Tulevaisuuden suunnitelmat: automaattinen tietokantojen siirto
Ajattelimme tietokannan päivittämistä ja mahdollisuutta peruuttaa nämä muutokset. Loppujen lopuksi sovelluksesta on käynnissä kaksi eri versiota samanaikaisesti: vanha on käynnissä ja uusi on käynnissä. Ja sammutamme vanhan vasta, kun olemme varmoja, että uusi versio toimii. Tietokannan siirron pitäisi antaa sinun työskennellä molempien sovellusversioiden kanssa.
Siksi emme voi vain muuttaa sarakkeen nimeä tai muita tietoja. Mutta voimme luoda uuden sarakkeen, kopioida tietoja vanhasta sarakkeesta siihen ja kirjoittaa triggereitä, jotka päivitettäessä tietoja kopioivat ja päivittävät sen samanaikaisesti toiseen sarakkeeseen. Ja sovelluksen uuden version onnistuneen käyttöönoton jälkeen, julkaisun jälkeisen tukijakson jälkeen, voimme poistaa vanhan sarakkeen ja tarpeettomaksi tulleen liipaisimen.
Jos sovelluksen uusi versio ei toimi oikein, voimme palata aiempaan versioon, mukaan lukien tietokannan edellinen versio. Lyhyesti sanottuna, muutokset antavat sinun työskennellä samanaikaisesti useiden sovellusversioiden kanssa.
Aiomme automatisoida tietokannan migraation K8S-työn kautta integroimalla sen CD-prosessiin. Jaamme ehdottomasti tämän kokemuksen Habrén kanssa.
Lähde: will.com