Kuidas muuta oma käivituspilv stabiilsemaks: 4 praktilist DevOps-nõuannet

Startup-maailmas on tasakaalustav tegevus, kui asi puudutab seda, kuhu oma aega investeerite. Olen olnud paljudes olukordades, kus tänu MVP kohaletoimetamise vajadusele võtavad DevOpsi harjutused tagaistme.

Leian, et see on normaalne ja pole tegelikult halb asi, sest “MVP” peaks olema “minimaalne” ja enamik probleeme, mis heade DevOps-ide abil lahendatakse, pole sellised väiksed probleemid.

Kuid siin on mõned asjad, mida tuleks kindlasti teha (või vähemalt kaaluda). Kuna käivitusmaailmas pole palju halvem kui pilveinfrastruktuuri allakäik.

Kui DevOpsil on käivitamisel aega leida, on seda raske leida

Näpunäide nr 1: kavandage oma andmete varundamine

See on kohustuslik kõigi käivitamisel, mis hoolivad püsivate andmete omamisest. Peate oma kriitilisi andmeid automaatselt varundama, vastasel juhul võite kaotada rohkem kui ainult faile. Samuti kaotate klientide usalduse, mis mõjutab teie edasist kasvu.

Üldiselt automatiseerin projektide alustamisel kahte tüüpi varundusmeetodeid

Varundamine andmebaasides

Üldiselt toimub see ajastatud skriptina, näiteks cron-tööna, mis töötab igal õhtul ja lükkab andmebaasi prügikasti kuskil pilves nagu privaatne S3-ämber. Mõne varunduslahendusega võib teil olla rohkem väljamõeldud lahendusi, kuid need on pigem ettevõtlusele keskendunud ja maksavad teile palju aega ja raha (pole käivitamissõbralikud).

Ketta hetktõmmised

Kui kõik muu ebaõnnestub, siis kui teil on oma ketta koopia, on teil üldiselt turvalisus. Enamikul suurematel pilveteenuse pakkujatel on olemas lahendused, mis võimaldavad teil ketta hetktõmmiseid teha vastavalt teie valitud ajakavale, nii et proovige vältida pilve api-ga ühenduvate skriptide kirjutamist, kuna vastutate nende hooldamise eest.

Kontrollige kindlasti varukoopia taastamise meetodit või riskige GitLabiga juhtunut, kus kõik 5 nende varundusmeetodit ebaõnnestusid, kuna nad ei testinud taastamist kunagi

Näpunäide 2: seadistage jälgimine ja teavitage teid probleemidest

Kas saate teada, kui server läheb alla või kui rakendus jookseb kettaruumi otsa? Kui ei, siis peaksite kaaluma selle probleemi lahendamist (see ei võta liiga palju aega).

Seire seadistamise lihtsaim viis on tavaliselt pilveteenuse pakkuja lahendus, näiteks Amazon CloudWatch või GCP Stackdriver. Võite seadistada mõõdikud, et jälgida ja omada mitmesuguseid teatisi vastusena pilveinfrastruktuuris toimuvatele sündmustele, näiteks saada e-kiri, kui ketas hakkab otsa saama.

Kui te ei soovi pakkuja lahendusega minna - on olemas ka pilveagnostilisi valikuid, mis saavad teie pilvi jälgida. Olemas on lihtsad lahendused, näiteks kestaskriptide ajastamine, mis saadavad e-kirju perioodiliselt käitamiseks, kuid terviklikum lahendus, mis annab teile armatuurlaua ülevaate teie süsteemist, on üldiselt parem ja palju skaleeritavam. Ettevõtte privaatpilve jaoks on olemas sellised valikud nagu Blue Medora ja Solar Winds, kuid enamik alustavaid ettevõtteid peab raha säästma, mis tähendab pöördumist avatud lähtekoodiga lahenduste, näiteks Countly poole.

Kokkuvõttes soovitaksin minna pilveteenuse pakkujapõhise lahenduse juurde, kuna need tagatakse stabiilsena, hõlpsasti seadistatavatena ja käivitamisel ei maksa need teile eriti palju.

Vihje 3: liikuge CI / CD torujuhtme suunas towards

Üks levinumaid võitlusi, mida näen alustavate ettevõtetega, on koodi vabastamine. Paljud pole veel DevOpsisse aega stabiilse väljalaske torujuhtme väljatöötamiseks, mis tähendab, et versioon, mis tõuseb versioonikontrollile, on kas käsitsi testitud, ehitatud ja vabastatud, mis on nii tõrkeoht kui ka teie arenduse jaoks aeganõudev versioon. meeskond.

Pidev integreerimine - tagades, et muudatused pole katkematud

Pideva integreerimise mõte on torujuhtme olemasolu, mis käivitatakse iga kord, kui kood on valmis pühenduma.

Pidev integreerimine kaitseb teie koodbaasi stabiilsust
  1. Kood on seotud versioonikontrolliga
  2. Automaatikasüsteem nagu Jenkins loob rakenduse ehituse
  3. Automaatteste tehakse selleks, et kontrollida, kas süsteem töötab endiselt korralikult
  4. Kui kõik testid on läbitud, lubatakse kood stabiilsele koodialusele lisada
  5. Uus kood on nüüd juurutamiseks valmis (siin tuleb mängu pidev juurutamine)

Pidev juurutamine - teie väljaannete automatiseerimine tootmisesse

Pidev juurutamine algab pärast seda, kui pideva integreerimise torujuhtme on teinud oma töö uue koodi valideerimisega, mis teie ehitust ei riku. Üldiselt koosneb see uue tootmiskonstruktsiooni loomisest, nagu ka pideva integreerimise etapis, ja vana ehituse (muutumatu infrastruktuuri) asendamisest.

Tehniliselt võib teil olla pidev juurutamine ilma pideva integreerimiseta, kuid sellega seotud riskid on suured. Põhimõtteliselt lükkaksite testimata koodi otse klientidele (BAD)

Kust peaksite CI / CD poole liikudes alustama? - automatiseeritud testimine!

See pole saladus, enamik arendajaid ei naudi testide kirjutamist. Rakenduste arenedes vajavad nad sageli pidevat värskendamist ja on ajaliselt vaevalised, nii et loomulikult jätavad paljud startupid testide kirjutamise unarusse, kuna “MVP”.

Kui teil pole terviklikku testikomplekti, ei viitsiks ma mõelda CI / CD-le enne, kui see on parandatud. Testimiskatte paranemisel näete suuremat tõhususe kasvu, kui näete tootmises üha vähem vigu. See on punkt, kus peaksite liikuma oma CI / CD torujuhtme teistesse osadesse.

4. nõuanne. Hoidke oma rakendus sisse

Konteinerid muudavad rakenduste automatiseeritud ehituse loomise lihtsaks

Ärge kartke konteinereid, kuna tehnoloogia ise on keerukate ja ilma põhiteadmisteta kernalt raskesti mõistetav, nende kasutamine ja rakenduste teisendamine mahutiteks on tõesti üsna triviaalne.

Dockerfaili koostamine võtab tavaliselt vähem kui tund (olenevalt teie rakenduse keerukusest) ja enne, kui sellest tead, saate oma rakenduse kohe kasutusele võtta ja kasutada ära selliseid suurepäraseid süsteeme nagu Kubernetes.

Siin on mõned eelised, mida saate kohe oma rakenduse koondamisega saada.

Järjepidev ehitab

Enam pole probleeme “see töötab minu masinal” - kui konteiner ehitatakse, töötab see suvalisel masinal samamoodi.

Valuvabad juurutamised

Teate, kuidas avatud lähtekoodiga projekti seadistamiseks peate läbima kõikvõimalikud käsitsi tehtavad toimingud, andmebaaside seadistamise ja vajaliku paketi installimise? Konteineri puhul see enam nii pole, kõik need toimingud võetakse arvesse ehitamisprotsessis ja kõik, mida peate tegema, on serverite käivitamiseks ühe käsu käivitamine.

Elav konteinerite ökosüsteem

Konteineriplatvormidel, nagu Docker ja Kubernetes, on väga suur ja kasvav toodete ja teenuste ökosüsteem, mis aitab teil oma rakendusi hõlpsamalt hallata. Säästmaks teie aega ja raha, elimineeritakse põhimõtteliselt palju peavalu, näiteks ladustamine, võrgustamine ja ressursside eraldamine.

Järeldus

Paljud idufirmad ei pane pilveinfrastruktuuri palju mõtlema ega aega. Üldiselt tuleneb see MVP filosoofiast, mis hõlmab esiteks saatmist ja pärast seda tehnilise võla puhastamist.

DevOps-i infrastruktuuri laiendamiseks - kaaluge kavandatud varundamist, jälgimist, CI / CD-d ja konteinerite seadmist. Need on üldiselt lihtsad võidud ja viivad palju stabiilsema pilveni.

Kas soovite oma pilveinfrastruktuuri laiendada? ServiceBot saab aidata.