Kom ons begin met 'n bietjie teorie. Wat het gebeur ?
In eenvoudige woorde, hierdie dokument is ontwerp om die ontwikkeling van SaaS-toepassings te vereenvoudig, help deur ontwikkelaars en DevOps-ingenieurs bewus te maak van die probleme en praktyke wat die meeste in die ontwikkeling van moderne toepassings teëgekom word.
Die dokument is geskep deur die ontwikkelaars van die Heroku-platform.
Die Twaalf-Factor App-metodologie kan toegepas word op toepassings wat in enige programmeertaal geskryf is en deur enige kombinasie van derdeparty-steundienste (databasisse, boodskaprye, kas, ens.) te gebruik.
Kortliks oor die faktore self waarop hierdie metodologie gebaseer is:
- Kodebasis – Een bron-nagespoorde kodebasis – veelvuldige ontplooiings
- Afhanklikhede – Verklaar en isoleer afhanklikhede uitdruklik
- opset - Stoor konfigurasie tydens looptyd
- Derdepartydienste (Rugsteundienste) – Behandel rugsteundienste as inpropbare hulpbronne
- Bou, los, hardloop - Streng aparte bou- en hardloopfases
- prosesse - Begin die toepassing as een of meer staatlose prosesse
- Poortbinding – Voer dienste uit via hawebinding
- Parallelisme - Skaal jou toepassing met prosesse
- Weggooibaarheid - Maksimeer betroubaarheid met vinnige opstart en grasieuse afsluiting
- Toepassingsontwikkeling/Bedryfspariteit – Hou ontwikkeling-, opstel- en produksie-omgewings so soortgelyk as moontlik
- Tekening - Behandel die logboek as 'n stroom gebeurtenisse
- Administrasie take – Voer administrasie/bestuurstake uit met eenmalige prosesse
Vir meer inligting oor die 12 faktore, sien die volgende hulpbronne:
- - moet lees
- - amptelike vertaling
- - 'n vars blik op die 12 faktore om dit te verbeter.
Wat is Blou-Groen-ontplooiing?
Blou-Groen-ontplooiing is 'n manier om 'n toepassing aan te lewer produksie op so 'n wyse dat die eindkliënt geen veranderinge van sy kant sien nie. Met ander woorde, die implementering van 'n toepassing met nul stilstand.
Die klassieke BG Deploy-skema lyk soos die prent hieronder.
- Aan die begin is daar 2 fisiese bedieners met presies dieselfde kode, toepassing, projek, en daar is 'n router (balanseerder).
- Die router rig aanvanklik alle versoeke na een van die bedieners (groen).
- Op die oomblik wanneer jy weer 'n vrystelling moet maak, word die hele projek op 'n ander bediener opgedateer (blou), wat tans geen versoeke verwerk nie.
- Na die kode aan blou die bediener is heeltemal opgedateer, die router kry 'n opdrag om van oor te skakel groen op blou bediener.
- Nou sien alle kliënte die resultaat van die kode met blue bediener.
- Vir 'n geruime tyd, groen die bediener dien as 'n rugsteun in die geval van 'n onsuksesvolle ontplooiing na blou bediener en in die geval van mislukking en foute, skakel die router die gebruikervloei terug na groen bediener met die ou stabiele weergawe, en die nuwe kode word vir hersiening en toetsing gestuur.
- En aan die einde van die proses word dit op dieselfde manier opgedateer groen bediener. En nadat dit opgedateer is, skakel die router die versoekvloei terug na groen bediener.
Dit lyk alles baie goed en met die eerste oogopslag behoort daar geen probleme daarmee te wees nie.
Maar aangesien ons in die moderne wêreld leef, pas die opsie met fisiese skakeling, soos aangedui in die klassieke skema, ons nie. Teken die inligting vir eers aan, ons sal later daarna terugkeer.
Slegte en goeie raad
Vrywaring: Die voorbeelde hieronder wys die nutsprogramme / metodologieë wat ek gebruik, jy kan absoluut enige alternatiewe met soortgelyke funksies gebruik.
Die meeste van die voorbeelde sal op een of ander manier met webontwikkeling kruis (wat 'n verrassing), met PHP en Docker.
In die paragrawe hieronder is daar 'n eenvoudige praktiese beskrywing van die gebruik van faktore op sekere voorbeelde, as jy meer teorie oor hierdie onderwerp wil kry, verwys na die skakels hierbo na die oorspronklike bron.
1. Kodebasis
Gebruik FTP en FileZilla om lêers een op 'n slag na bedieners op te laai, stoor kode nêrens behalwe op 'n produksiebediener nie.
'n Projek moet altyd 'n enkele kodebasis hê, dit wil sê, alle kode kom van een gaan bewaarplek. Bedieners (produksie, opvoering, toets1, toets2 ...) gebruik kode van die takke van een gedeelde bewaarplek. Sodoende bereik ons kodekonsekwentheid.
2. Afhanklikhede
Laai alle biblioteke in dopgehou direk na die wortel van die projek af. Maak opdaterings bloot deur die nuwe kode na die gids met die huidige weergawe van die biblioteek oor te dra. Plaas al die nodige nutsprogramme direk op die gasheerbediener waar nog 20 dienste loop.
Die projek moet altyd 'n duidelik verstaanbare lys van afhanklikhede hê (met afhanklikhede bedoel ek ook die omgewing). Alle afhanklikhede moet eksplisiet gedefinieer en geïsoleer word.
Kom ons neem as 'n voorbeeld komponis и Docker.
komponis - 'n pakketbestuurder waarmee u biblioteke in PHP kan installeer. Composer gee jou die vermoë om weergawes streng of nie streng te spesifiseer, en dit uitdruklik te definieer. Daar kan 20 verskillende projekte op 'n bediener wees, en elkeen sal 'n privaat lys van pakkette en biblioteke hê, onafhanklik van die ander.
Docker - 'n program waarmee u die omgewing waarin die toepassing sal werk, kan definieer en isoleer. Gevolglik, net soos met komponis, maar meer deeglik, kan ons bepaal waarmee die toepassing werk. Kies 'n spesifieke weergawe van PHP, installeer slegs die pakkette wat nodig is vir die projek om te werk, sonder om iets ekstra by te voeg. En die belangrikste, sonder om in te meng met pakkette en die omgewing van die gasheermasjien en ander projekte. Dit wil sê, alle projekte op die bediener wat deur Docker loop, kan absoluut enige stel pakkette en heeltemal verskillende omgewings gebruik.
3. Konfigurasie
Stoor konfigurasies as konstantes reg in die kode. Afsonderlike konstantes vir die toetsbediener, apart vir produksie. Bind die werk van die toepassing, afhangende van die omgewing, direk in die besigheidslogika van die projek deur die if else-konstrukte te gebruik.
Konfigurasies - dit is die enigste ding wat moet verskil in die ontplooiing van die projek (ontplooiing). Ideaal gesproke moet konfigurasies deur omgewingsveranderlikes (env vars) deurgegee word.
Dit wil sê, selfs al stoor jy verskeie konfigurasielêers .config.prod .config.local en hernoem hulle ten tyde van ontplooiing na .config (die hoofkonfigurasie waaruit die toepassing data lees) - sal dit nie die regte benadering wees nie, aangesien in hierdie geval sal die inligting van die konfigurasies publiek beskikbaar wees aan alle toepassingsontwikkelaars en data vanaf die produksiebediener sal in gevaar gestel word. Alle konfigurasies moet direk in die ontplooiingstelsel (CI / CD) gestoor word en gegenereer word vir verskillende omgewings met verskillende waardes wat nodig is vir 'n spesifieke omgewing ten tye van ontplooiing.
4. Derdepartydienste (Rugsteundienste)
Bind hard op die omgewing, gebruik verskillende verbindings vir dieselfde dienste in sekere omgewings.
Trouens, hierdie item is sterk deursny met die item oor konfigurasies, aangesien sonder die teenwoordigheid van hierdie item normale konfigurasiedata nie gemaak kan word nie en in die algemeen sal die moontlikheid van konfigurasie verdwyn.
Alle verbindings met eksterne dienste soos toubedieners, databasisse, kasdienste moet dieselfde wees vir beide die plaaslike omgewing en die derdeparty-/produksie-omgewing. Met ander woorde, ek kan enige tyd die verbindingstring verander om oproepe na basis #1 met basis #2 te vervang sonder om die toepassingskode te verander. Of, kyk vorentoe, as 'n voorbeeld, wanneer u die diens skaal, hoef u nie die verbinding op 'n spesiale manier aan te dui vir 'n bykomende kasbediener nie.
5. Bou, los, hardloop
Hou slegs die finale weergawe van die kode op die bediener, met geen kans om die vrystelling terug te rol nie. Nie nodig om skyfspasie vol te maak nie. Wie dink dat hy die kode met 'n fout in produksie kan plaas, is 'n slegte programmeerder!
Alle ontplooiingstadiums moet van mekaar geskei word.
Kry 'n kans om terug te draai. Maak vrystellings met vinnige toegang tot ou kopieë van die toepassing (reeds saamgestel en gereed vir geveg), om die ou weergawe te herstel in geval van foute. Dit wil sê, voorwaardelik is daar 'n gids uitgawes en gids huidige, en na suksesvolle ontplooiing en samestelling, die gids huidige word geassosieer met 'n simboliese skakel na die nuwe vrystelling wat daarin lê uitgawes met die voorwaardelike naam van die vrystellingnommer.
Dit is waar ons Blou-Groen-ontplooiing onthou, wat jou toelaat om nie net tussen kode te wissel nie, maar ook tussen alle hulpbronne en selfs omgewings kan wissel met die vermoë om alles terug te rol.
6. Prosesse
Stoor toepassingstatusdata direk in die toepassing self. Gebruik sessies in die RAM van die toepassing self. Gebruik soveel as moontlik gedeel tussen derdepartydienste. Bind op die feit dat die toepassing slegs een proses kan hê en nie skaal toelaat nie.
Met betrekking tot sessies, stoor data slegs in 'n kas wat deur derdepartydienste beheer word (memcached, redis), so selfs al het jy 20 aansoekprosesse aan die gang, sal enige van hulle wat toegang tot die kas kry, kan voortgaan om met die kliënt in dieselfde toestand te werk. waarin die gebruiker in 'n ander proses met die toepassing gewerk het. Met hierdie benadering blyk dit dat, ongeag hoeveel kopieë van derdeparty-dienste jy gebruik, alles behoorlik en sonder probleme met toegang tot data sal werk.
7. Poortbinding
Slegs die webbediener behoort te weet hoe om met derdepartydienste te werk. En dit is beter om oor die algemeen derdepartydienste direk binne die webbediener in te samel. Byvoorbeeld, as 'n PHP-module in Apache.
Al jou dienste moet vir mekaar toeganklik wees deur 'n oproep na een of ander adres en poort (localgost:5432, localhost:3000, nginx:80, php-fpm:9000), dit wil sê, vanaf nginx het ek toegang tot beide php- fpm en postgres, en van php-fpm na postgres en nginx, en vanaf elke diens self kan ek toegang tot 'n ander diens kry. Die gesondheid van 'n diens is dus nie gekoppel aan die gesondheid van 'n ander diens nie.
8. Parallelisme
Werk met een proses, en dan sal verskeie prosesse skielik nie met mekaar oor die weg kan kom nie!
Laat die opsie om te skaal. Docker-swerm is wonderlik hiervoor.
Docker Swarm is 'n hulpmiddel vir die skep en bestuur van groepe houers tussen verskillende masjiene en 'n klomp houers op dieselfde masjien.
Deur gebruik te maak van swarm, kan ek bepaal hoeveel hulpbronne ek vir elke proses sal toewys en hoeveel prosesse van dieselfde diens ek sal hardloop, en die interne balanseerder, wat data op 'n gegewe poort ontvang, sal dit outomaties na prosesse instaan. Dus, aangesien die las op die bediener toegeneem het, kan ek meer prosesse byvoeg en sodoende die las op sekere prosesse verminder.
9. Weggooibaarheid
Moenie rye gebruik om met prosesse en data te werk nie. Om een proses dood te maak, behoort die werking van die hele toepassing te beïnvloed. As een diens afgaan, gaan alles af.
Elke proses en diens kan enige tyd afgeskakel word en dit behoort nie ander dienste te raak nie (natuurlik gaan dit nie daaroor dat die diens vir 'n ander diens ontoeganklik sal wees nie, maar dat 'n ander diens nie na hierdie een sal afskakel nie) . Alle prosesse moet sag beëindig word, sodat wanneer hulle beëindig word, data nie geaffekteer sal word nie en die stelsel sal korrek werk wanneer dit weer aangeskakel word. Dit wil sê, selfs in die geval van 'n afbreek, moet die data nie geraak word nie (die transaksiemeganisme is hier geskik, navrae na die databasis werk slegs in groepe, en as ten minste een navraag van die groep misluk het of met 'n fout uitgevoer is , dan word geen ander navraag van die groep uiteindelik in werklikheid uitgevoer nie).
10. Toepassingsontwikkeling/Bedryfspariteit
Produksie, opvoering en plaaslike weergawe van die toepassing moet anders wees. In produksie het ons die Yii Lite-raamwerk, en plaaslik Yii, sodat dit vinniger in produksie werk!
In werklikheid moet alle ontplooiings en werk met kode in byna identiese omgewing wees (ons praat nie van fisiese hardeware nie). Enige ontwikkelingswerknemer behoort ook in staat te wees om die kode na produksie te ontplooi indien nodig, en nie een of ander spesiaal opgeleide devops-afdeling nie, wat slegs die toepassing in produksie kan verhoog as gevolg van spesiale krag.
Docker help ons ook hiermee. Onderhewig aan al die vorige punte, sal die gebruik van docker die proses van ontplooiing van die omgewing beide op produksie en op die plaaslike masjien bring om een of twee opdragte in te voer.
11. Aantekening (logboeke)
Ons skryf logs na lêers en databasis! Ons maak nie lêers en databasisse van logs skoon nie. Kom ons koop net 'n hardeskyf vir 9000 Peta grepe en norme.
Alle logs moet as 'n stroom gebeurtenisse beskou word. Die aansoek self behoort nie die verwerking van logs te hanteer nie. Die logs moet óf na stdout uitgereik word óf oor 'n protokol soos udp gestuur word sodat die toepassing geen probleme met die logs skep nie. Graylog werk goed hiervoor. Graylog wat alle logs via udp aanvaar (met behulp van hierdie protokol is dit nie nodig om te wag vir 'n antwoord oor die suksesvolle ontvangs van die pakkie nie) meng op geen manier met die toepassing in nie en is slegs besig met die strukturering en verwerking van logs. Die toepassingslogika verander nie om met hierdie benaderings te werk nie.
12. Administrasie take
Om data, databasis, ens. op te dateer, gebruik 'n afsonderlik geskepde eindpunt in api, waarvan die uitvoering 2 keer in 'n ry daartoe sal lei dat alles vir jou gedupliseer kan word. Maar jy is nie dwase nie, jy sal nie 2 keer klik nie, en ons het nie migrasies nodig nie.
Alle administrasietake moet in dieselfde omgewing as alle kode uitgevoer word, op die vrystellingsvlak. Dit wil sê, as ons die struktuur van die databasis moet verander, sal ons dit nie handmatig doen deur die name van die kolomme te verander en nuwes by te voeg deur 'n soort visuele databasisbestuurnutsmiddels nie. Vir sulke dinge skep ons aparte skrifte - migrasies wat oral en op alle omgewings uitgevoer word met dieselfde algemene en verstaanbare resultaat. Vir alle ander take, soos om 'n projek met data te vul, moet soortgelyke metodologieë toegepas word.
Implementeringsvoorbeeld in PHP, Laravel, Laradock, Docker-Compose
NS Alle voorbeelde is op MacOS gemaak. Die meeste sal ook vir Linux werk. Jammer, Windows-gebruikers, maar ek het lanklaas met Windows gewerk.
Stel jou 'n situasie voor dat ons geen weergawe van PHP op ons rekenaar geïnstalleer het nie en glad niks nie.
Installeer nuutste weergawes van docker en docker-compose. (dit kan aanlyn gevind word)
docker -v &&
docker-compose -v
1. Ons sit
git clone https://github.com/Laradock/laradock.git &&
ls
Oor Laradock sal ek sê dat dit 'n baie gawe ding is, waarin baie houers en bykomstighede versamel word. Maar om Laradock as sodanig te gebruik sonder veranderinge in produksie - ek sal dit nie aanbeveel nie as gevolg van sy oortolligheid. Dit is beter om jou houers te skep op grond van voorbeelde in Laradock, so daar sal baie optimalisering wees, want niemand het alles nodig wat terselfdertyd daar is nie.
2. Konfigureer Laradock vir ons toepassing om te werk.
cd laradock &&
cp env-example .env
2.1. Maak die habr-gids oop (die ouerlêergids waarin laradock gekloon word) in enige redigeerder. (In my PHPStorm geval)
Op hierdie stadium plaas ons slegs die naam van die projek.
2.2. Ons begin die werkspasie-beeld. (In jou geval sal die beelde vir 'n geruime tyd bou)
Werkspasie is 'n spesiaal voorbereide beeld om namens die ontwikkelaar met die raamwerk te werk.
Gaan binne die houer met
docker-compose up -d workspace &&
docker-compose exec workspace bash
2.3. Laravel installeer
composer create-project --prefer-dist laravel/laravel application
2.4. Na die installasie kyk ons of die gids met die projek geskep is, en maak compose dood.
ls
exit
docker-compose down
2.5. Ons keer terug na PHPStorm en stel die korrekte pad na ons laravel-toepassing in die .env-lêer.
3. Voeg al die kode by Git.
Om dit te doen, sal ons 'n bewaarplek op Github (of enige ander plek) skep. Kom ons gaan na die habr-gids in die terminale en voer die volgende kode uit.
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
Ons kyk of alles in orde is.
Vir gerief beveel ek aan om 'n soort visuele koppelvlak vir Git te gebruik, in my geval is dit . (verwysing skakel hier)
4. Begin!
Voordat jy begin, maak seker dat daar niks aan poorte 80 en 443 hang nie.
docker-compose up -d nginx php-fpm
Ons projek bestaan dus uit 3 afsonderlike dienste:
- nginx - webbediener
- php-fpm - php vir die ontvangs van versoeke vanaf 'n webbediener
- werkspasie - php vir ontwikkelaar
Op die oomblik het ons bereik dat ons 'n toepassing geskep het wat ooreenstem met 4 punte uit 12, naamlik:
1. Kodebasis - al die kode is in een bewaarplek ('n klein nota: dit kan reg wees om docker binne die laravel-projek te bring, maar dit is nie belangrik nie).
2. Afhanklikhede - Al ons afhanklikhede is uitdruklik geskryf in application/composer.json en in elke Dockerfile van elke houer.
3. Derdepartydienste (Rugsteundienste) - Elkeen van die dienste (php-fom, nignx, werkspasie) leef sy eie lewe en is van buite af verbind en wanneer met een diens gewerk word, sal die ander nie geraak word nie.
4. prosesse Elke diens is een proses. Elke diens stoor nie interne toestand nie.
5. Poortbinding
docker ps
Soos ons kan sien, loop elke diens op sy eie poort en is dit beskikbaar vir alle ander dienste.
6. Parallelisme
Docker stel ons in staat om verskeie prosesse van dieselfde dienste te skep met outomatiese lasbalansering tussen hulle.
Stop houers en begin dit met 'n vlag --skaal
docker-compose down &&
docker-compose up -d --scale php-fpm=3 nginx php-fpm
Soos ons kan sien, het die php-fpm-houer kopieë. Ons hoef niks te verander wanneer ons met hierdie houer werk nie. Ons gaan ook voort om toegang daartoe te kry op poort 9000, en Docker reguleer die vrag tussen houers vir ons.
7. Weggooibaarheid - elke houer kan doodgemaak word sonder om die ander te benadeel. As u die houer stop of herbegin, sal dit nie die werking van die toepassing met daaropvolgende bekendstellings beïnvloed nie. Elke houer kan ook enige tyd opgelig word.
8. Toepassingsontwikkeling/Bedryfspariteit Al ons omgewings is dieselfde. Deur die stelsel op die bediener in produksie te laat loop, hoef jy niks in jou opdragte te verander nie. Alles sal op dieselfde manier op Docker gebaseer wees.
9. Tekening - alle logs in hierdie houers gaan na die stroom en is sigbaar in die Docker-konsole. (in hierdie geval, in werklikheid, met ander tuisgemaakte houers, is dit dalk nie die geval as jy nie daarvoor sorg nie)
docker-compose logs -f
Maar daar is 'n hak daarin dat die standaardwaardes in PHP en Nginx ook logs na 'n lêer skryf. Om aan die 12 faktore te voldoen, moet jy afgeskakel skryf logs na 'n lêer in die konfigurasies van elke houer afsonderlik.
Docker bied ook die vermoë om logs nie net na stdout te stuur nie, maar ook na dinge soos greylog, wat ek hierbo genoem het. En binne greylog kan ons met logs werk soos ons wil en ons toepassing sal dit op geen manier opmerk nie.
10. Administrasie take - alle administrasietake word deur laravel opgelos danksy die vakman-instrument presies soos die skeppers van die 12-faktor-toepassing wil hê.
As 'n voorbeeld sal ek wys hoe sommige opdragte uitgevoer word.
Ons gaan in die houer.
docker-compose exec workspace bash
php artisan list
Nou kan ons enige opdrag gebruik. (Let asseblief daarop dat ons nie die databasis en kas opgestel het nie, so die helfte van die opdragte sal nie korrek uitgevoer word nie, want hulle is ontwerp om met die kas en databasis te werk).
11. Konfigurasies en 12. Bou, los, hardloop
Ek wou hierdie deel aan Blue-Green Deployment toewy, maar dit blyk te gedetailleerd te wees vir hierdie artikel. Ek sal 'n aparte artikel hieroor skryf.
In 'n neutedop, die konsep is gebaseer op CI / CD-stelsels soos Jenkins и Gitlab CI. In beide kan jy omgewingsveranderlikes stel wat met 'n spesifieke omgewing geassosieer word. Gevolglik, in hierdie scenario, item c Konfigurasies.
En die punt oor Bou, los, hardloop opgelos deur die ingeboude funksies in beide nutsprogramme genoem Pyplyn.
Pyplyn laat jou toe om die ontplooiingsproses in baie stadiums te verdeel, wat die stadiums van samestelling, vrystelling en uitvoering beklemtoon. Ook in Pipeline kan u rugsteun skep, en inderdaad enigiets. Hierdie instrument het onbeperkte potensiaal.
Die toepassingskode is aan .
Moenie vergeet om die submodule te inisialiseer wanneer hierdie bewaarplek gekloon word nie.
NS: Al hierdie benaderings kan met enige ander nutsprogramme en programmeertale gebruik word. Die belangrikste ding is dat die essensie nie verskil nie.
Bron: will.com