"Pilvipohjaiset" tai yksinkertaisesti "pilvi"sovellukset on luotu erityisesti toimimaan pilviinfrastruktuureissa. Ne rakennetaan tyypillisesti joukoksi löyhästi kytkettyjä mikropalveluita, jotka on pakattu kontteihin, joita puolestaan hallinnoi pilvialusto. Tällaiset sovellukset ovat oletuksena valmiita vikoja varten, mikä tarkoittaa, että ne toimivat luotettavasti ja skaalautuvat myös vakavissa infrastruktuuritason vioissa. Kolikon toinen puoli on rajoitussarjat (sopimukset), joita pilvialusta asettaa konttisovelluksille voidakseen hallita niitä automaattisesti.
Vaikka monet organisaatiot ovat täysin tietoisia pilvipohjaisiin sovelluksiin siirtymisen tarpeesta ja tärkeydestä, monet organisaatiot eivät vieläkään tiedä, mistä aloittaa. Tässä postauksessa tarkastellaan useita periaatteita, joita konttisovellusten kehittämisessä noudatettaessa voit toteuttaa pilvialustojen potentiaalin ja saavuttaa luotettavan toiminnan ja sovellusten skaalauksen myös IT-infrastruktuurin vakavissa vioissa. taso. Tässä esitettyjen periaatteiden perimmäisenä tavoitteena on oppia rakentamaan sovelluksia, joita voidaan automaattisesti hallita pilvialustoilla, kuten Kubernetes.
Ohjelmiston suunnittelun periaatteet
Ohjelmointimaailmassa periaatteet viittaavat melko yleisiin sääntöihin, joita tulee noudattaa ohjelmistoa kehitettäessä. Niitä voidaan käyttää työskennellessäsi minkä tahansa ohjelmointikielen kanssa. Jokaisella periaatteella on omat tavoitteensa, joiden saavuttamiseksi työkalut ovat yleensä mallipohjat ja käytännöt. Laadukkaiden ohjelmistojen luomisessa on myös useita perusperiaatteita, joista kaikki muut lähtevät. Tässä on esimerkkejä perusperiaatteista:
- (Pidä se yksinkertainen, tyhmä) – älä monimutkaista sitä;
- (Älä toista itseäsi) - älä toista itseäsi;
- (Et tule tarvitsemaan sitä) - älä luo jotain, jota ei heti tarvita;
- Huolenaiheiden erottaminen – jaa vastuut.
Kuten näette, nämä periaatteet eivät aseta mitään erityisiä sääntöjä, vaan kuuluvat niin kutsuttujen käytännön kokemukseen perustuvien terveen järjen huomioiden luokkaan, joita monet kehittäjät jakavat ja joihin he säännöllisesti viittaavat.
Lisäksi on – Robert Martinin muotoilema joukko olio-ohjelmoinnin ja suunnittelun viidestä ensimmäisestä periaatteesta. SOLID sisältää laajat, avoimet, toisiaan täydentävät periaatteet, jotka yhdessä käytettyinä auttavat luomaan parempia ohjelmistojärjestelmiä ja ylläpitämään niitä paremmin pitkällä aikavälillä.
SOLID-periaatteet kuuluvat OOP:n alaan ja on muotoiltu sellaisten käsitteiden ja käsitteiden kielellä kuin luokat, rajapinnat ja perinnöllisyys. Analogisesti kehitysperiaatteet voidaan muotoilla myös pilvisovelluksiin, vain peruselementti tässä ei ole luokka, vaan kontti. Näitä periaatteita noudattamalla voit luoda konttisovelluksia, jotka vastaavat paremmin Kubernetesin kaltaisten pilvialustojen tavoitteita ja tavoitteita.
Pilvipohjaiset säiliöt: Red Hat -lähestymistapa
Nykyään lähes kaikki sovellukset voidaan pakata suhteellisen helposti säiliöihin. Mutta sovellusten tehokas automatisointi ja organisointi pilvialustassa, kuten Kubernetes, vaatii lisäponnistuksia.
Alla esitettyjen ideoiden perustana oli metodologia ja monia muita töitä web-sovellusten rakentamisen eri näkökohdista lähdekoodin hallinnasta skaalausmalleihin. Kuvatut periaatteet koskevat vain sellaisten konttisovellusten kehittämistä, jotka on rakennettu mikropalvelujen päälle ja suunniteltu pilvialustoille, kuten Kubernetes. Keskustelumme peruselementti on säilön imago, ja kohdesäiliön suoritusaika on kontin orkestrointialusta. Ehdotettujen periaatteiden tavoitteena on luoda säiliöitä, joiden ajoitus-, skaalaus- ja valvontatehtävät voidaan automatisoida useimmilla orkestrointialustoilla. Periaatteet on esitetty ilman erityistä järjestystä.
Yhden huolen periaate (SCP)
Tämä periaate on monella tapaa samanlainen kuin yhden vastuun periaate. ), joka on osa SOLID-joukkoa ja jossa todetaan, että jokaisella objektilla on oltava yksi vastuu ja tämä vastuu on kapseloitu kokonaan luokkaan. SRP:n pointti on, että jokainen vastuu on syy muutokseen ja luokalla täytyy olla yksi ja vain yksi syy muutokseen.
SCP:ssä käytämme sanaa "huoli" sanan "vastuu" sijaan osoittamaan kontin korkeampaa abstraktiotasoa ja laajempaa tarkoitusta verrattuna OOP-luokkaan. Ja jos SRP:n tavoitteena on vain yksi syy muutokseen, niin SCP:n takana on halu laajentaa mahdollisuuksia käyttää ja vaihtaa säiliöitä. Noudattamalla SRP:tä ja luomalla säilön, joka ratkaisee yksittäisen ongelman ja tekee sen toiminnallisesti täydellisesti, lisäät mahdollisuuksia käyttää konttikuvaa uudelleen eri sovelluskonteksteissa.
SCP-periaatteen mukaan jokaisen kontin tulee ratkaista yksi ongelma ja tehdä se hyvin. Lisäksi SCP konttimaailmassa on helpompi saavuttaa kuin SRP OOP-maailmassa, koska kontit ajavat yleensä yhtä prosessia ja suurimman osan ajasta tämä prosessi ratkaisee yhden tehtävän.
Jos jonkin konttimikropalvelun on ratkaistava useita ongelmia kerralla, se voidaan jakaa yhden tehtävän konteiksi ja yhdistää yhdeksi podiksi (konttialustan käyttöönottoyksikkö) käyttämällä sivuvaunu- ja aloituskonttimalleja. Lisäksi SCP helpottaa vanhan kontin (kuten web-palvelimen tai viestivälittäjän) korvaamista uudella, joka ratkaisee saman ongelman, mutta jonka toimintoja on laajennettu tai skaalautuu paremmin.
High Observability Principle (HOP)
Kun konttia käytetään yhtenäisenä tapana pakata ja ajaa sovelluksia, itse sovelluksia käsitellään mustana laatikkona. Jos nämä ovat kuitenkin pilvisäilöjä, niiden on tarjottava suoritukseen erityisiä API-liittymiä säiliöiden kunnon valvomiseksi ja tarvittaessa tarvittavien toimien toteuttamiseksi. Ilman tätä konttien päivittämisen ja elinkaaren hallinnan automatisointia ei voida yhtenäistää, mikä puolestaan heikentää ohjelmistojärjestelmän vakautta ja käytettävyyttä.
Käytännössä konttisovelluksessa tulisi olla vähintään API erityyppisiä terveystarkastuksia varten: elävyystestejä ja valmiustestejä. Jos sovellus väittää tekevänsä enemmän, sen on tarjottava muita tapoja seurata sen tilaa. Esimerkiksi tärkeiden tapahtumien kirjaaminen STDERR:n ja STDOUTin kautta lokien yhdistämistä varten Fluentd-, Logstash- ja muiden vastaavien työkalujen avulla. Sekä integrointi jäljitys- ja metriikkakokoelmakirjastoihin, kuten OpenTracing, Prometheus jne.
Yleisesti ottaen sovellusta voidaan edelleen käsitellä mustana laatikkona, mutta se on varustettava kaikilla alustan tarvitsemilla API:illa, jotta se voi valvoa ja hallita sitä parhaalla mahdollisella tavalla.
Elinkaarivaatimustenmukaisuusperiaate (LCP)
LCP on HOP:n vastakohta. Vaikka HOP ilmoittaa, että säilön on esitettävä lukusovellusliittymät alustalle, LCP edellyttää, että sovellus pystyy vastaanottamaan tietoja alustalta. Lisäksi kontin tulee paitsi vastaanottaa tapahtumia, myös mukautua, toisin sanoen reagoida niihin. Tästä johtuu periaatteen nimi, jota voidaan pitää vaatimuksena tarjota alustalle kirjoitussovellusliittymiä.
Alustalla on erilaisia tapahtumia, jotka auttavat hallitsemaan kontin elinkaarta. Mutta sovellus itse päättää, mitkä niistä havaitsevat ja miten reagoivat.
On selvää, että jotkut tapahtumat ovat tärkeämpiä kuin toiset. Jos sovellus ei esimerkiksi siedä kaatumisia hyvin, sen on hyväksyttävä signal: terminate (SIGTERM) -viestit ja aloitettava lopetusrutiini mahdollisimman nopeasti saadakseen kiinni SIGTERM:n jälkeen tulevan signaalin: kill (SIGKILL).
Lisäksi tapahtumat, kuten PostStart ja PreStop, voivat olla tärkeitä sovelluksen elinkaaren kannalta. Esimerkiksi sovelluksen käynnistämisen jälkeen se voi vaatia lämpenemisaikaa, ennen kuin se voi vastata pyyntöihin. Tai sovelluksen on vapautettava resurssit jollain erityisellä tavalla sammutettaessa.
Kuvan muuttumattomuuden periaate (IIP)
On yleisesti hyväksyttyä, että konttisovellusten tulee pysyä muuttumattomina rakentamisen jälkeen, vaikka niitä ajettaisiin eri ympäristöissä. Tämä edellyttää tarvetta ulkoistaa tietojen tallennus ajon aikana (eli käyttää ulkoisia työkaluja tähän) ja luottaa ulkoisiin, ajonaikakohtaisiin kokoonpanoihin sen sijaan, että muokataan tai luodaan yksilöllisiä säilöjä kullekin ympäristölle. Sovellukseen tehtyjen muutosten jälkeen säiliökuva on rakennettava uudelleen ja otettava käyttöön kaikissa käytetyissä ympäristöissä. Muuten, IT-järjestelmiä hallittaessa käytetään samanlaista periaatetta, joka tunnetaan palvelinten ja infrastruktuurin muuttumattomuuden periaatteena.
IIP:n tavoitteena on estää erillisten konttikuvien luominen eri ajonaikaisiin ympäristöihin ja käyttää samaa kuvaa kaikkialla sopivan ympäristökohtaisen konfiguraation kanssa. Tätä periaatetta noudattamalla voit toteuttaa pilvijärjestelmien automatisoinnin kannalta tärkeitä käytäntöjä, kuten sovelluspäivitysten palautus- ja palautuskäytäntöjä.
Prosessin kertakäyttöperiaate (PDP)
Yksi kontin tärkeimmistä ominaisuuksista on sen lyhytaikaisuus: säiliön esiintymä on helppo luoda ja helppo tuhota, joten se voidaan helposti korvata toisella esiintymällä milloin tahansa. Tällaiseen korvaamiseen voi olla monia syitä: huollettavuustestin epäonnistuminen, sovelluksen skaalaus, siirto toiseen isäntään, alustan resurssien loppuminen tai muut tilanteet.
Tämän seurauksena konttisovellusten on säilytettävä tilansa jollain ulkoisella tavalla tai käytettävä sisäisiä hajautettuja järjestelmiä redundanssilla. Lisäksi sovelluksen on käynnistettävä nopeasti ja sammuttava nopeasti sekä varauduttava äkilliseen kohtalokkaaseen laitteistovikaan.
Yksi käytäntö, joka auttaa tämän periaatteen toteuttamisessa, on pitää kontit pieninä. Pilviympäristöt voivat automaattisesti valita isäntäkoneen käynnistääkseen säilön ilmentymän, joten mitä pienempi säilö, sitä nopeammin se käynnistyy – se yksinkertaisesti kopioi kohdeisäntään verkon kautta nopeammin.
Itsestään sulkemisen periaate (S-CP)
Tämän periaatteen mukaan kokoonpanovaiheessa kaikki tarvittavat komponentit sisällytetään säiliöön. Säilö tulee rakentaa sillä oletuksella, että järjestelmässä on vain puhdas Linux-ydin, joten kaikki tarvittavat lisäkirjastot tulisi sijoittaa itse säiliöön. Sen tulisi sisältää myös asioita, kuten vastaavan ohjelmointikielen ajonaika, sovellusalusta (tarvittaessa) ja muut riippuvuudet, joita tarvitaan konttisovelluksen ollessa käynnissä.
Poikkeuksia ovat kokoonpanot, jotka vaihtelevat ympäristöstä toiseen ja jotka on annettava suorituksen aikana, esimerkiksi Kubernetes ConfigMap -sovelluksen kautta.
Sovellus voi sisältää useita säilöttyjä komponentteja, esimerkiksi erillisen DBMS-kontin kontillisessa verkkosovelluksessa. S-CP-periaatteen mukaan näitä säilöjä ei tule yhdistää yhdeksi, vaan ne tulee tehdä niin, että DBMS-säilössä on kaikki tietokannan toimintaan tarvittava ja verkkosovelluskontti sisältää kaiken, mitä webin toimintaan tarvitaan. sovellus, sama verkkopalvelin . Tämän seurauksena verkkosovellussäilö on ajon aikana riippuvainen DBMS-säiliöstä ja käyttää sitä tarvittaessa.
Runtime Confinement Principle (RCP)
S-CP-periaate määrittelee, kuinka kontti tulee rakentaa ja mitä kuvabinaarin tulee sisältää. Mutta kontti ei ole vain "musta laatikko", jolla on vain yksi ominaisuus - tiedostokoko. Suorituksen aikana säilö saa muut mitat: käytetyn muistin määrän, suorittimen ajan ja muut järjestelmäresurssit.
Ja tässä on hyödyllinen RCP-periaate, jonka mukaan kontin on katkaistava järjestelmäresurssivaatimukset ja siirrettävä ne alustalle. Kunkin säilön resurssiprofiilien (kuinka paljon suoritinta, muistia, verkko- ja levyresursseja se tarvitsee) avulla alusta voi optimaalisesti suorittaa ajoituksen ja automaattisen skaalauksen, hallita IT-kapasiteettia ja ylläpitää SLA-tasoja säilöille.
Säilön resurssivaatimusten lisäksi on myös tärkeää, että sovellus ei ylitä omia rajojaan. Muussa tapauksessa, kun resurssipula ilmenee, alusta todennäköisemmin sisällyttää sen niiden sovellusten luetteloon, jotka on lopetettava tai siirrettävä.
Kun puhumme pilvipalveluista, puhumme tavasta, jolla toimimme.
Yllä muotoilimme joukon yleisiä periaatteita, jotka luovat metodologisen perustan korkealaatuisten konttisovellusten rakentamiselle pilviympäristöihin.
Huomaa, että näiden yleisten periaatteiden lisäksi tarvitset myös muita kehittyneitä menetelmiä ja tekniikoita säiliöiden kanssa työskentelemiseen. Lisäksi meillä on muutama lyhyt suositus, jotka ovat tarkempia ja joita tulisi soveltaa (tai olla soveltamatta) tilanteesta riippuen:
- Yritä pienentää kuvien kokoa: poista väliaikaiset tiedostot äläkä asenna tarpeettomia paketteja - mitä pienempi säilön koko, sitä nopeammin se kootaan ja kopioidaan kohdeisäntään verkon kautta.
- Keskity mielivaltaisiin käyttäjätunnuksiin: älä käytä sudo-komentoa tai mitään erityistä käyttäjätunnusta säilöiden käynnistämiseen.
- Merkitse tärkeät portit: Voit asettaa porttinumeroita ajon aikana, mutta on parempi määrittää ne käyttämällä EXPOSE-komentoa - se helpottaa muiden ihmisten ja ohjelmien käyttöä kuviesi käytössä.
- Tallenna pysyviä tietoja taltioille: Tiedot, joiden pitäisi jäädä säiliön tuhoutumisen jälkeen, tulee kirjoittaa taltioihin.
- Kirjoita kuvien metatietoja: tagit, tarrat ja merkinnät helpottavat kuvien käyttöä – muut kehittäjät kiittävät sinua.
- Synkronoi isäntä ja kuvat: Jotkin säilötyt sovellukset vaativat säilön synkronoitavan isännän kanssa tiettyjen attribuuttien, kuten ajan tai koneen tunnuksen, perusteella.
- Lopuksi jaamme malleja ja parhaita käytäntöjä, jotka auttavat sinua toteuttamaan yllä luetellut periaatteet tehokkaammin:
11. kesäkuuta klo 11.00
Mitä opit:
- Muuttumaton Red Hat Enterprise Linux CoreOS
- OpenShift-palveluverkko
- Operaattorikehys
- Knative kehys
Lähde: will.com