Pirma, šiek tiek teorijos. Kas nutiko ?
Paprastais žodžiais tariant, šis dokumentas skirtas supaprastinti SaaS programų kūrimą, padedant informuoti kūrėjus ir „DevOps“ inžinierius apie problemas ir praktikas, su kuriomis dažniausiai susiduriama kuriant šiuolaikines programas.
Dokumentą sukūrė Heroku platformos kūrėjai.
Dvylikos faktorių programėlę galima pritaikyti programoms, parašytoms bet kuria programavimo kalba ir naudojant bet kokį atsarginių paslaugų derinį (duomenų bazes, pranešimų eiles, talpyklas ir kt.).
Trumpai apie veiksnius, kuriais grindžiama ši metodika:
- Kodų bazė – Versijų valdyme stebima viena kodų bazė – keli diegimai
- Priklausomybės – Aiškiai deklaruokite ir išskirkite priklausomybes
- Konfigūravimas - Išsaugokite konfigūraciją vykdymo metu
- Atraminės paslaugos – Apsvarstykite atsargines paslaugas kaip papildinius
- Statykite, paleiskite, paleiskite – Griežtai atskirkite surinkimo ir vykdymo etapus
- Procesai – Paleiskite programą kaip vieną ar daugiau procesų be būsenos
- Prievado įrišimas – Eksporto paslaugos per prievadą
- Lygiagrečiai – Padidinkite savo taikomąją programą naudodami procesus
- Atsikratymas – Maksimaliai padidinkite patikimumą greitu paleidimu ir švariu išjungimu
- Programų kūrimo / veikimo paritetas – Kad kūrimo, pastatymo ir gamybos aplinka būtų kuo panašesnė
- Miško ruoša – Peržiūrėkite žurnalą kaip įvykių srautą
- Administravimo užduotys – Atlikti administravimo/valdymo užduotis naudojant ad hoc procesus
Daugiau informacijos apie 12 veiksnių galite gauti iš šių šaltinių:
- – būtina perskaityti
- - oficialus vertimas
- - naujas žvilgsnis į 12 veiksnių, siekiant juos pagerinti.
Kas yra mėlynai žalios spalvos diegimas?
Mėlynai žalias diegimas yra programos pristatymo būdas gamyba tokiu būdu, kad galutinis klientas nepastebėtų jokių savo pakeitimų. Kitaip tariant, programos diegimas su nuliu prastovos.
Klasikinė BG diegimo schema atrodo taip, kaip parodyta paveikslėlyje žemiau.
- Pradžioje yra 2 fiziniai serveriai su visiškai tuo pačiu kodu, programa, projektu ir yra maršrutizatorius (balanseris).
- Maršrutizatorius iš pradžių nukreipia visas užklausas į vieną iš serverių (žalia).
- Tuo metu, kai vėl reikia išleisti, visas projektas atnaujinamas kitame serveryje (синий), kuri šiuo metu neapdoroja jokių užklausų.
- Įjungus kodą mėlyna serveris yra visiškai atnaujintas, maršrutizatoriui suteikiama komanda perjungti žalia apie синий serveris.
- Dabar visi klientai mato kodo paleidimo rezultatą mėlynas serveris.
- Tam tikrą laiką, žalia serveris tarnauja kaip atsarginė kopija nesėkmingo diegimo atveju синий serverio, o gedimo ir klaidų atveju maršrutizatorius perjungia vartotojo srautą atgal į žalia serveryje su sena stabilia versija, o naujas kodas siunčiamas peržiūrėti ir išbandyti.
- Ir proceso pabaigoje jis atnaujinamas tokiu pat būdu žalia serveris. Ir jį atnaujinus, maršrutizatorius perjungia užklausų srautą atgal į žalia serveris.
Viskas atrodo labai gerai ir iš pirmo žvilgsnio problemų dėl to neturėtų kilti.
Tačiau kadangi gyvename šiuolaikiniame pasaulyje, klasikinėje schemoje nurodytas fizinio perjungimo variantas mums netinka. Kol kas įrašykite informaciją, prie jos grįšime vėliau.
Blogas ir geras patarimas
Atsakomybės neigimas: Žemiau esantys pavyzdžiai rodo mano naudojamas komunalines paslaugas/metodikas, galite naudoti visiškai bet kokias alternatyvas su panašiomis funkcijomis.
Dauguma pavyzdžių vienaip ar kitaip susikirs su interneto svetainių kūrimu (tai yra staigmena), su PHP ir Docker.
Toliau pateiktose pastraipose pateikiamas paprastas praktinis veiksnių naudojimo aprašymas naudojant konkrečius pavyzdžius; jei norite gauti daugiau teorijos šia tema, sekite pirmiau pateiktas nuorodas į pirminį šaltinį.
1. Kodų bazė
Failams po vieną įkelti į serverius naudokite FTP ir FileZilla, nesaugokite kodo niekur kitur, tik gamybos serveryje.
Projektas visada turi turėti vieną kodo bazę, tai yra, visas kodas gaunamas iš vieno git saugykla. Serveriai (gamyba, statymas, test1, test2...) naudoja kodą iš vienos bendros saugyklos šakų. Tokiu būdu pasiekiame kodo nuoseklumą.
2. Priklausomybės
Atsisiųskite visas aplankuose esančias bibliotekas tiesiai į projekto šaknį. Atnaujinkite tiesiog perkeldami naują kodą į aplanką su dabartine bibliotekos versija. Įdiekite visas reikalingas paslaugas tiesiai pagrindiniame serveryje, kuriame veikia dar 20 paslaugų.
Projekte visada turi būti aiškiai suprantamas priklausomybių sąrašas (dėl priklausomybių turiu omenyje ir aplinką). Visos priklausomybės turi būti aiškiai apibrėžtos ir atskirtos.
Paimkime kaip pavyzdį kompozitorius и dokininkas.
kompozitorius - paketų tvarkyklė, leidžianti įdiegti bibliotekas PHP. Kompozitorius leidžia griežtai arba laisvai nurodyti versijas ir jas aiškiai apibrėžti. Serveryje gali būti 20 skirtingų projektų ir kiekvienas turės asmeninį paketų ir bibliotekų sąrašą, nepriklausantį nuo kito.
dokininkas — įrankis, leidžiantis apibrėžti ir išskirti aplinką, kurioje veiks programa. Atitinkamai, kaip ir su kompozitoriumi, bet nuodugniau, galime nustatyti, su kuo programa veikia. Pasirinkite konkrečią PHP versiją, įdiekite tik projektui reikalingus paketus, nieko papildomai nepridedant. Ir svarbiausia, nesikišant į pagrindinio kompiuterio paketus ir aplinką bei kitus projektus. Tai reiškia, kad visi serverio projektai, veikiantys per „Docker“, gali naudoti absoliučiai bet kokį paketų rinkinį ir visiškai skirtingą aplinką.
3. Konfigūracija
Saugokite konfigūracijas kaip konstantas tiesiai kode. Atskiros konstantos bandomajam serveriui, atskiros gamybai. Priklausomai nuo aplinkos taikomosios programos veikimą tiesiogiai susiekite su projekto verslo logika, naudodami if else konstrukcijas.
Konfigūracijos - Tik tokiu būdu projektų diegimas turėtų skirtis. Idealiu atveju konfigūracijos turėtų būti perduodamos per aplinkos kintamuosius (env vars).
Tai yra, net jei saugote kelis konfigūracijos failus .config.prod .config.local ir diegdami pervadinate juos į .config (pagrindinė konfigūracija, iš kurios programa nuskaito duomenis), tai nebus teisingas būdas, nes šiuo atveju informacija iš konfigūracijų bus viešai prieinama visiems programų kūrėjams, o duomenys iš gamybos serverio bus pažeisti. Visos konfigūracijos turi būti saugomos tiesiogiai diegimo sistemoje (CI/CD) ir sugeneruotos skirtingoms aplinkoms su skirtingomis reikšmėmis, kurios būtinos konkrečiai aplinkai diegimo metu.
4. Trečiųjų šalių paslaugos
Būkite griežtai susieti su aplinka, tam tikrose aplinkose naudokite skirtingus ryšius toms pačioms paslaugoms.
Tiesą sakant, šis punktas labai sutampa su tašku apie konfigūracijas, nes be šio punkto negalima atlikti įprastų konfigūracijos duomenų ir apskritai galimybė konfigūruoti nukris.
Visi ryšiai su išorinėmis paslaugomis, pvz., eilių serveriais, duomenų bazėmis, talpyklos paslaugomis, turi būti vienodi tiek vietinėje, tiek trečiosios šalies / gamybos aplinkoje. Kitaip tariant, bet kuriuo metu, pakeisdamas ryšio eilutę, galiu pakeisti skambučius į bazę Nr. 1 baze Nr. 2 nekeisdamas programos kodo. Arba, žvelgiant į ateitį, kaip pavyzdį, kai keičiate paslaugos mastelį, nereikės jokiu specialiu būdu nurodyti prisijungimo prie papildomo talpyklos serverio.
5. Sukurti, išleisti, vykdyti
Turėkite tik galutinę kodo versiją serveryje, be galimybės grąžinti leidimą. Nereikia užpildyti vietos diske. Kiekvienas, kuris mano, kad gali išleisti kodą į gamybą su klaida, yra blogas programuotojas!
Visi diegimo etapai turi būti atskirti vienas nuo kito.
Turėkite galimybę atsitraukti. Padarykite leidimus naudodami senas programos kopijas (jau surinktas ir paruoštas kovai), išsaugotas greitoje prieigoje, kad klaidų atveju galėtumėte atkurti senąją versiją. Tai yra, sąlygiškai yra aplankas spaudai ir aplankas dabartinis, o po sėkmingo diegimo ir surinkimo aplanką dabartinis susieta simboline nuoroda į naują leidimą, kuris yra viduje spaudai su sutartiniu leidimo numerio pavadinimu.
Čia prisimename „Blue-Green“ diegimą, kuris leidžia ne tik perjungti kodą, bet ir perjungti visus išteklius ir net aplinkas su galimybe viską atšaukti.
6. Procesai
Saugokite programos būsenos duomenis tiesiai pačioje programoje. Naudokite seansus pačios programos RAM. Naudokite kuo daugiau bendrinimo tarp trečiųjų šalių paslaugų. Pasikliaukite tuo, kad programa gali turėti tik vieną procesą ir neleisti keisti mastelio.
Kalbant apie seansus, saugokite duomenis tik talpykloje, kurią valdo trečiųjų šalių paslaugos (memcached, redis), todėl net jei turite 20 taikomųjų programų procesų, bet kuris iš jų, prisijungęs prie talpyklos, galės toliau dirbti su klientu ta pati būsena, kurioje vartotojas dirbo su programa kitame procese. Taikant šį metodą paaiškėja, kad nesvarbu, kiek trečiųjų šalių paslaugų kopijų naudosite, viskas veiks normaliai ir be problemų dėl prieigos prie duomenų.
7. Prievado įrišimas
Tik žiniatinklio serveris turėtų žinoti, kaip dirbti su trečiųjų šalių paslaugomis. Arba dar geriau, įdiekite trečiųjų šalių paslaugas tiesiai žiniatinklio serveryje. Pavyzdžiui, kaip PHP modulis „Apache“.
Visos jūsų paslaugos turi būti pasiekiamos viena kitai per prieigą prie tam tikro adreso ir prievado (localgost: 5432, localhost: 3000, nginx: 80, php-fpm: 9000), tai yra, iš nginx galiu pasiekti ir php- fpm, ir postgres ir nuo php-fpm iki postgres ir nginx ir iš tikrųjų iš kiekvienos paslaugos galiu pasiekti kitą paslaugą. Tokiu būdu paslaugos gyvybingumas nėra susietas su kitos paslaugos gyvybingumu.
8. Lygiagretumas
Dirbkite su vienu procesu, kitaip keli procesai nesuderės vienas su kitu!
Palikite vietos mastelio keitimui. Docker spiečius tam puikiai tinka.
„Docker Swarm“ yra įrankis, skirtas sukurti ir valdyti konteinerių grupes tarp skirtingų mašinų ir krūvos konteinerių tame pačiame įrenginyje.
Naudodamas spiečius galiu nustatyti, kiek resursų paskirsiu kiekvienam procesui ir kiek tos pačios paslaugos procesų paleisiu, o vidinis balansuotojas, gavęs duomenis apie tam tikrą prievadą, automatiškai perkels jį į procesus. Taigi, matydamas, kad serverio apkrova padidėjo, galiu pridėti daugiau procesų, taip sumažinant tam tikrų procesų apkrovą.
9. Vienkartiškumas
Nenaudokite eilių darbui su procesais ir duomenimis. Vieno proceso nužudymas turėtų turėti įtakos visai programai. Jei viena paslauga sugenda, viskas.
Kiekvienas procesas ir paslauga gali būti išjungiami bet kuriuo metu ir tai neturėtų turėti įtakos kitoms paslaugoms (žinoma, tai nereiškia, kad paslauga bus nepasiekiama kitai paslaugai, bet kad po šios neišsijungs kita paslauga). Visi procesai turi būti nutraukti grakščiai, kad juos nutraukus nebūtų pažeisti jokie duomenys ir kitą kartą įjungus sistema veiktų tinkamai. Tai yra, net ir avarinio nutraukimo atveju duomenys neturėtų būti sugadinti (čia tinka operacijų mechanizmas, užklausos duomenų bazėje veikia tik grupėse, o jei bent viena užklausa iš grupės nepavyksta arba vykdoma naudojant klaida, tada jokia kita užklausa iš grupės galiausiai nepavyksta).
10. Programos kūrimo / veikimo lygybė
Programos gamyba, pastatymas ir vietinė versija turi skirtis. Gamyboje naudojame „Yii Lite“ sistemą, o vietoje – „Yii“, kad ji greičiau veiktų gamyboje!
Realiai visi diegimai ir darbas su kodu turėtų būti beveik identiškoje aplinkoje (kalbame ne apie fizinę aparatinę įrangą). Be to, bet kuris kūrimo darbuotojas turėtų turėti galimybę pritaikyti kodą gamyboje, jei reikia, o ne koks nors specialiai apmokytas devops skyrius, kuris tik dėl ypatingo stiprumo gali pakelti programą į gamybą.
Docker mums taip pat padeda tai padaryti. Jei laikomasi visų ankstesnių punktų, naudojant docker aplinkos diegimo procesą tiek gamyboje, tiek vietiniame kompiuteryje bus įvesta viena ar dvi komandos.
11. Rąstai
Rašome žurnalus į failus ir duomenų bazes! Failų ir duomenų bazių iš žurnalų nevalome. Nusipirkime kietąjį diską su 9000 Peta baitų ir viskas.
Visi žurnalai turėtų būti laikomi įvykių srautu. Pati programa neturėtų būti įtraukta į žurnalų apdorojimą. Žurnalai turėtų būti išvesti arba į stdout, arba siunčiami naudojant protokolą, pvz., udp, kad dirbant su žurnalais nekiltų jokių problemų programai. graylog tam tinka. Graylogas, gaunantis visus žurnalus per udp (šis protokolas nereikalauja laukti atsakymo apie sėkmingą paketo priėmimą) niekaip netrukdo programai ir užsiima tik žurnalų struktūrizavimu ir apdorojimu. Taikymo logika nesikeičia, kad būtų galima dirbti naudojant tokius metodus.
12. Administravimo užduotys
Norėdami atnaujinti duomenis, duomenų bazes ir pan., naudokite API atskirai sukurtą galutinį tašką, jį vykdant 2 kartus iš eilės viskas bus dubliuojama. Bet jūs nesate kvailas, du kartus nepaspustelėsite ir mums nereikia migracijos.
Visos administravimo užduotys turi būti atliekamos toje pačioje aplinkoje kaip ir visas kodas, leidimo lygiu. Tai yra, jei mums reikia pakeisti duomenų bazės struktūrą, tai mes to nedarysime rankiniu būdu, keisdami stulpelių pavadinimus ir pridėdami naujų per kai kuriuos vaizdinius duomenų bazės valdymo įrankius. Tokiems dalykams kuriame atskirus scenarijus – migracijas, kurios visur ir visose aplinkose vykdomos vienodai su bendru ir suprantamu rezultatu. Visoms kitoms užduotims, pavyzdžiui, projekto užpildymui duomenimis, turėtų būti naudojamos panašios metodikos.
Diegimo pavyzdys PHP, Laravel, Laradock, Docker-Compose
PS Visi pavyzdžiai buvo sukurti „MacOS“. Dauguma jų tinka ir Linux. „Windows“ vartotojai, atleiskite, bet aš ilgą laiką nedirbau su „Windows“.
Įsivaizduokime situaciją, kai mūsų kompiuteryje nėra įdiegtos jokios PHP versijos ir nieko.
Įdiekite naujausias docker ir docker-compose versijas. (tai galima rasti internete)
docker -v &&
docker-compose -v
1. Dedame
git clone https://github.com/Laradock/laradock.git &&
ls
Dėl Laradoko pasakysiu, kad tai labai šaunus dalykas, kuriame yra daug konteinerių ir pagalbinių dalykų. Tačiau nerekomenduočiau naudoti Laradock kaip tokio be pakeitimų gamyboje dėl jo pertekliškumo. Geriau kurti savo konteinerius pagal Laradock pavyzdžius, tai bus daug labiau optimizuota, nes niekam nereikia visko, kas yra vienu metu.
2. Sukonfigūruokite Laradock, kad paleistumėte mūsų programą.
cd laradock &&
cp env-example .env
2.1. Atidarykite habr katalogą (pagrindinį aplanką, į kurį klonuotas laradock) tam tikrame redaktoriuje. (Mano PHPStorm atveju)
Šiame etape projektui suteikiame tik pavadinimą.
2.2. Paleiskite darbo srities vaizdą. (Jūsų atveju vaizdai bus sukurti šiek tiek laiko)
Darbo sritis yra specialiai paruoštas vaizdas, skirtas darbui su sistema kūrėjo vardu.
Mes einame į konteinerį naudodami
docker-compose up -d workspace &&
docker-compose exec workspace bash
2.3. „Laravel“ diegimas
composer create-project --prefer-dist laravel/laravel application
2.4. Įdiegę patikriname, ar sukurtas katalogas su projektu ir užmušame kompoziciją.
ls
exit
docker-compose down
2.5. Grįžkime prie PHPStorm ir .env faile nustatykime teisingą kelią į mūsų laravel programą.
3. Pridėkite visą kodą prie Git.
Norėdami tai padaryti, sukursime saugyklą „Github“ (arba bet kur kitur). Eikime į habr katalogą terminale ir vykdykime šį kodą.
echo "# habr-12factor" >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin [email protected]:nzulfigarov/habr-12factor.git # здесь будет ссылка на ваш репо
git push -u origin master
git status
Pažiūrėkime, ar viskas tvarkoje.
Patogumui rekomenduoju naudoti kokią nors vaizdinę Git sąsają, mano atveju tai yra . (čia yra nuoroda)
4. Paleidžiame!
Prieš pradėdami įsitikinkite, kad ant 80 ir 443 prievadų niekas nekabina.
docker-compose up -d nginx php-fpm
Taigi mūsų projektą sudaro 3 atskiros paslaugos:
- nginx - žiniatinklio serveris
- php-fpm - php užklausoms iš žiniatinklio serverio gauti
- darbo sritis – php kūrėjams
Šiuo metu mes pasiekėme, kad sukūrėme programą, kuri atitinka 4 taškus iš 12, būtent:
1. Kodų bazė — visas kodas yra vienoje saugykloje (maža pastaba: gali būti teisinga įtraukti dokerį į laravel projektą, bet tai nėra svarbu).
2. Priklausomybės – Visos mūsų priklausomybės yra aiškiai įrašytos Application/composer.json ir kiekviename kiekvieno sudėtinio rodinio Docker faile.
3. Atraminės paslaugos — Kiekviena iš paslaugų (php-fom, nignx, workspace) gyvena savo gyvenimą ir yra prijungta iš išorės, o dirbant su viena paslauga, tai nebus paveikta.
4. Procesai — kiekviena paslauga yra vienas procesas. Kiekviena iš paslaugų nepalaiko vidinės būsenos.
5. Prievado įrišimas
docker ps
Kaip matome, kiekviena paslauga veikia savo prievadu ir yra prieinama visoms kitoms tarnyboms.
6. Lygiagrečiai
„Docker“ leidžia mums sukurti kelis tų pačių paslaugų procesus su automatiniu apkrovos balansavimu tarp jų.
Sustabdykime konteinerius ir paleiskime juos per vėliavą --skalė
docker-compose down &&
docker-compose up -d --scale php-fpm=3 nginx php-fpm
Kaip matome, buvo sukurtos php-fpm konteinerio kopijos. Mums nereikia nieko keisti dirbant su šiuo konteineriu. Mes taip pat ir toliau jį pasiekiame 9000 uoste, o „Docker“ reguliuoja apkrovą tarp konteinerių už mus.
7. Atsikratymas - kiekvienas konteineris gali būti nužudytas nepažeidžiant kito. Konteinerio sustabdymas ar paleidimas iš naujo neturės įtakos programos veikimui vėlesnių paleidimų metu. Kiekvieną konteinerį taip pat galima bet kada pakelti.
8. Programų kūrimo / veikimo paritetas – visos mūsų aplinkos yra vienodos. Paleidus sistemą gamybiniame serveryje, jums nereikės nieko keisti savo komandose. Viskas taip pat bus pagrįsta Docker.
9. Miško ruoša — visi žurnalai šiuose konteineriuose patenka į srautą ir yra matomi „Docker“ konsolėje. (šiuo atveju, tiesą sakant, su kitais naminiais indeliais to gali nebūti, jei tuo nepasirūpinsite)
docker-compose logs -f
Tačiau yra klaida, nes numatytosios PHP ir Nginx reikšmės taip pat įrašo žurnalus į failą. Kad atitiktų 12 veiksnių, būtina išjungti žurnalų rašymas į failą kiekvieno konteinerio konfigūracijose atskirai.
„Docker“ taip pat suteikia galimybę siųsti žurnalus ne tik į stdout, bet ir į tokius dalykus kaip „greylog“, apie kuriuos minėjau aukščiau. Greylog viduje galime valdyti žurnalus, kaip norime, ir mūsų programa to niekaip nepastebės.
10. Administravimo užduotys — visas administravimo užduotis laravel išsprendžia amatininkų įrankio dėka tiksliai taip, kaip norėtų 12 faktorių programos kūrėjai.
Kaip pavyzdį parodysiu, kaip vykdomos kai kurios komandos.
Einame į konteinerį.
docker-compose exec workspace bash
php artisan list
Dabar galime naudoti bet kurią komandą. (atkreipkite dėmesį, kad mes nesukonfigūravome duomenų bazės ir talpyklos, todėl pusė komandų nebus tinkamai vykdomos, nes jos skirtos dirbti su talpykla ir duomenų baze).
11. Konfigūracijos ir 12 m. Statykite, paleiskite, paleiskite
Šią dalį norėjau skirti mėlynai žaliam diegimui, tačiau ji pasirodė per plati šiam straipsniui. Apie tai parašysiu atskirą straipsnį.
Trumpai tariant, koncepcija yra pagrįsta CI / CD sistemomis, tokiomis kaip Jenkins и Gitlab CI. Abiejuose galite nustatyti aplinkos kintamuosius, susietus su konkrečia aplinka. Atitinkamai, šioje situacijoje bus įvykdytas c punktas Konfigūracijos.
Ir esmė apie Statykite, paleiskite, paleiskite išsprendžiama įtaisytomis funkcijomis su pavadinimu Naftotiekis.
Naftotiekis leidžia suskirstyti diegimo procesą į daugybę etapų, išryškinant surinkimo, išleidimo ir vykdymo etapus. Taip pat „Pupeline“ galite kurti atsargines kopijas ir, tiesą sakant, bet ką. Tai neriboto potencialo įrankis.
Paraiškos kodas yra adresu .
Nepamirškite inicijuoti submodulio, kai klonuojate šią saugyklą.
PS: Visi šie metodai gali būti naudojami su bet kokiomis kitomis programomis ir programavimo kalbomis. Svarbiausia, kad esmė nesiskirtų.
Šaltinis: www.habr.com