Først lidt teori. Hvad er der sket ?
Med enkle ord er dette dokument designet til at forenkle udviklingen af SaaS-applikationer og hjælpe ved at informere udviklere og DevOps-ingeniører om de problemer og praksis, der oftest støder på i udviklingen af moderne applikationer.
Dokumentet blev oprettet af udviklerne af Heroku-platformen.
Twelve-Factor-appen kan anvendes på applikationer skrevet i et hvilket som helst programmeringssprog og ved hjælp af enhver kombination af backing-tjenester (databaser, beskedkøer, caches osv.).
Kort om de faktorer, som denne metode er baseret på:
- Kodebase – Én kodebase sporet i versionskontrol – flere implementeringer
- Afhængigheder – Eksplicit erklære og isolere afhængigheder
- Konfiguration – Gem konfiguration i runtime
- Backing Services – Overvej backing-tjenester som plug-in-ressourcer
- Byg, slip, løb – Adskil monterings- og udførelsesfaserne strengt
- processer – Kør applikationen som en eller flere statsløse processer
- Port binding – Eksporttjenester via havnebinding
- parallelitet – Skaler din ansøgning ved hjælp af processer
- Disponibilitet – Maksimer pålideligheden med hurtig opstart og ren nedlukning
- Applikationsudvikling/driftsparitet – Hold dine udviklings-, iscenesættelses- og produktionsmiljøer så ens som muligt
- Logning – Se loggen som en strøm af begivenheder
- Administrationsopgaver – Udføre administration/ledelsesopgaver ved hjælp af ad hoc processer
Du kan få flere oplysninger om de 12 faktorer fra følgende ressourcer:
- - et must at læse
- — officiel oversættelse
- - et nyt kig på de 12 faktorer med det formål at forbedre dem.
Hvad er Blue-Green implementering?
Blue-Green implementering er en metode til at levere en applikation til produktion på en sådan måde, at slutkunden ikke ser ændringer fra sin side. Med andre ord, at implementere en applikation med nul nedetid.
Det klassiske BG Deploy-skema ser ud som det, der er vist på billedet nedenfor.
- I starten er der 2 fysiske servere med absolut samme kode, applikation, projekt, og der er en router (balancer).
- Routeren dirigerer i første omgang alle anmodninger til en af serverne (grøn).
- I det øjeblik du skal frigive igen, opdateres hele projektet på en anden server (blå), som i øjeblikket ikke behandler nogen anmodninger.
- Efter at koden er tændt blå serveren er fuldstændig opdateret, får routeren en kommando at skifte fra grøn på blå server.
- Nu ser alle klienter resultatet af koden, der kører med blå server.
- I nogen tid, grøn serveren fungerer som en sikkerhedskopi i tilfælde af mislykket implementering til blå server og i tilfælde af fejl og fejl skifter routeren brugerflowet tilbage til grøn server med den gamle stabile version, og den nye kode sendes til revision og test.
- Og i slutningen af processen bliver den opdateret på samme måde grøn server. Og efter at have opdateret den, skifter routeren anmodningsflowet tilbage til grøn server.
Det hele ser meget godt ud, og ved første øjekast burde der ikke være nogen problemer med det.
Men da vi lever i den moderne verden, passer muligheden med fysisk omskiftning som angivet i den klassiske ordning os ikke. Registrer oplysningerne indtil videre, vi vender tilbage til dem senere.
Dårlige og gode råd
Ansvarsfraskrivelse: Eksemplerne nedenfor viser de hjælpeprogrammer/metoder, som jeg bruger, du kan bruge absolut alle alternativer med lignende funktioner.
De fleste af eksemplerne vil på den ene eller anden måde krydse webudvikling (dette er en overraskelse), med PHP og Docker.
Afsnittene nedenfor giver en enkel praktisk beskrivelse af brugen af faktorer ved hjælp af specifikke eksempler; hvis du ønsker at få mere teori om dette emne, skal du følge linksene ovenfor til den originale kilde.
1. Kodebase
Brug FTP og FileZilla til at uploade filer til serverne én ad gangen, gem ikke koden andre steder end på produktionsserveren.
Projektet skal altid have en enkelt kodebase, det vil sige, at al kode kommer fra én Git depot. Servere (produktion, iscenesættelse, test1, test2...) bruger kode fra grene af ét fælles lager. På denne måde opnår vi kodekonsistens.
2. Afhængigheder
Download alle biblioteker i mapper direkte til roden af projektet. Foretag opdateringer blot ved at overføre den nye kode til mappen med den aktuelle version af biblioteket. Installer alle de nødvendige hjælpeprogrammer direkte på værtsserveren, hvor der kører yderligere 20 tjenester.
Et projekt bør altid have en klart forståelig liste over afhængigheder (med afhængigheder mener jeg også miljøet). Alle afhængigheder skal være eksplicit defineret og isoleret.
Lad os tage som eksempel Komponere и Docker.
Komponere — en pakkehåndtering, der giver dig mulighed for at installere biblioteker i PHP. Composer giver dig mulighed for at specificere versioner strengt eller løst og eksplicit definere dem. Der kan være 20 forskellige projekter på serveren, og hver vil have en personlig liste over pakker og biblioteker uafhængig af hinanden.
Docker — et hjælpeprogram, der giver dig mulighed for at definere og isolere det miljø, som programmet skal køre i. Derfor kan vi, ligesom med komponist, men mere grundigt bestemme, hvad applikationen fungerer med. Vælg en specifik version af PHP, installer kun de pakker, der er nødvendige for, at projektet kan fungere, uden at tilføje noget ekstra. Og vigtigst af alt, uden at forstyrre pakkerne og miljøet på værtsmaskinen og andre projekter. Det vil sige, at alle projekter på serveren, der kører gennem Docker, kan bruge absolut ethvert sæt pakker og et helt andet miljø.
3. Konfiguration
Gem konfigurationer som konstanter direkte i koden. Separate konstanter for testserveren, separate for produktion. Bind applikationens drift afhængigt af miljøet direkte i projektets forretningslogik ved hjælp af if else-konstruktioner.
konfigurationer - det er den eneste måde, hvorpå projektimplementeringer bør være forskellige. Ideelt set bør konfigurationer sendes gennem miljøvariabler (env vars).
Det vil sige, at selvom du gemmer flere konfigurationsfiler .config.prod .config.local og omdøber dem på tidspunktet for implementeringen til .config (hovedkonfigurationen, som applikationen læser data fra) - vil dette ikke være den rigtige tilgang, da i dette tilfælde vil oplysningerne fra konfigurationerne være offentligt tilgængelige for alle applikationsudviklere, og data fra produktionsserveren vil blive kompromitteret. Alle konfigurationer skal lagres direkte i implementeringssystemet (CI/CD) og genereres til forskellige miljøer med forskellige værdier, der er nødvendige for et specifikt miljø på tidspunktet for implementeringen.
4. Tredjepartstjenester
Vær strengt knyttet til miljøet, brug forskellige forbindelser til de samme tjenester i visse miljøer.
Faktisk overlapper dette punkt kraftigt med punktet om konfigurationer, da uden dette punkt kan normale konfigurationsdata ikke laves, og i almindelighed vil muligheden for at konfigurere falde til ingenting.
Alle forbindelser til eksterne tjenester, såsom køservere, databaser, cachetjenester, skal være ens for både det lokale miljø og tredjeparts-/produktionsmiljøet. Med andre ord kan jeg til enhver tid, ved at ændre forbindelsesstrengen, erstatte opkald til base #1 med base #2 uden at ændre applikationskoden. Eller hvis du ser fremad, for eksempel, når du skalerer tjenesten, behøver du ikke at angive forbindelsen på nogen særlig måde for en ekstra cache-server.
5. Byg, frigiv, eksekver
Har kun den endelige version af koden på serveren, uden chance for at rulle udgivelsen tilbage. Ingen grund til at fylde diskplads op. Enhver, der tror, at de kan frigive kode i produktion med en fejl, er en dårlig programmør!
Alle faser af implementeringen skal være adskilt fra hinanden.
Har en chance for at rulle tilbage. Lav udgivelser med gamle kopier af applikationen (allerede samlet og klar til kamp) gemt i hurtig adgang, så du i tilfælde af fejl kan gendanne den gamle version. Det vil sige, betinget er der en mappe udgivelser og mappe strøm, og efter vellykket implementering og samling af mappen strøm forbundet med et symbolsk link til den nye udgivelse, der ligger indeni udgivelser med det konventionelle navn på udgivelsesnummeret.
Det er her, vi husker Blue-Green-implementeringen, som giver dig mulighed for ikke kun at skifte mellem kode, men også at skifte mellem alle ressourcer og endda miljøer med mulighed for at rulle alt tilbage.
6. Processer
Gem applikationstilstandsdata direkte i selve applikationen. Brug sessioner i selve applikationens RAM. Brug så meget deling mellem tredjepartstjenester som muligt. Stol på det faktum, at applikationen kun kan have én proces og ikke tillader skalering.
Med hensyn til sessioner, gem kun data i en cache styret af tredjepartstjenester (memcached, redis), så selvom du har 20 applikationsprocesser kørende, vil enhver af dem, efter at have adgang til cachen, kunne fortsætte med at arbejde med klienten i samme tilstand, som brugeren arbejdede med applikationen i en anden proces. Med denne tilgang viser det sig, at uanset hvor mange kopier af tredjepartstjenester du bruger, vil alt fungere normalt og uden problemer med adgang til data.
7. Portbinding
Kun webserveren bør vide, hvordan man arbejder med tredjepartstjenester. Eller endnu bedre, installer tredjepartstjenester direkte inde på webserveren. For eksempel som PHP-modul i Apache.
Alle jeres tjenester skal være tilgængelige for hinanden gennem adgang til en eller anden adresse og port (localgost:5432, localhost:3000, nginx:80, php-fpm:9000), dvs. fra nginx kan jeg få adgang til både php-fpm og til postgres, og fra php-fpm til postgres og nginx og faktisk fra hver tjeneste kan jeg få adgang til en anden tjeneste. På denne måde er levedygtigheden af en tjeneste ikke bundet til levedygtigheden af en anden tjeneste.
8. Parallelisme
Arbejd med én proces, ellers vil flere processer ikke kunne komme overens med hinanden!
Efterlad plads til skalering. Docker swarm er fantastisk til dette.
Docker Swarm er et værktøj til at skabe og administrere klynger af containere både mellem forskellige maskiner og en masse containere på den samme maskine.
Ved hjælp af swarm kan jeg bestemme, hvor mange ressourcer jeg vil allokere til hver proces, og hvor mange processer af den samme tjeneste, jeg vil starte, og den interne balancer, der modtager data på en given port, vil automatisk proxy det til processerne. Når jeg ser, at belastningen på serveren er steget, kan jeg tilføje flere processer, og derved reducere belastningen på visse processer.
9. Disponibilitet
Brug ikke køer til at arbejde med processer og data. At dræbe én proces bør påvirke hele applikationen. Hvis en tjeneste går ned, går alt ned.
Hver proces og tjeneste kan til enhver tid slås fra, og dette bør ikke påvirke andre tjenester (det betyder selvfølgelig ikke, at tjenesten ikke vil være tilgængelig for en anden tjeneste, men at en anden tjeneste ikke slukkes efter denne). Alle processer skal afsluttes med ynde, så når de afsluttes, vil ingen data blive beskadiget, og systemet vil fungere korrekt, næste gang du tænder det. Det vil sige, at selv i tilfælde af en nødophør bør dataene ikke beskadiges (transaktionsmekanismen er velegnet her, forespørgsler i databasen fungerer kun i grupper, og hvis mindst én forespørgsel fra gruppen fejler eller udføres med en fejl, så mislykkes ingen anden forespørgsel fra gruppen i sidste ende).
10. Applikationsudvikling/driftsparitet
Produktion, iscenesættelse og lokal version af applikationen skal være anderledes. I produktionen bruger vi Yii Lite frameworket, og lokalt Yii, så det virker hurtigere i produktionen!
I virkeligheden bør alle implementeringer og arbejde med kode være i næsten identiske omgivelser (vi taler ikke om fysisk hardware). Desuden bør enhver udviklingsmedarbejder kunne implementere koden til produktion, hvis det er nødvendigt, og ikke en eller anden specialuddannet devops-afdeling, som kun takket være særlig styrke kan løfte applikationen i produktion.
Docker hjælper os også med dette. Hvis alle de foregående punkter overholdes, vil brug af docker bringe processen med at implementere miljøet både på produktion og på den lokale maskine til at indtaste en eller to kommandoer.
11. Logs
Vi skriver logs til filer og databaser! Vi renser ikke filer og databaser fra logfiler. Lad os bare købe en harddisk med 9000 Peta bytes, og det er fint.
Alle logfiler skal betragtes som en strøm af begivenheder. Selve applikationen bør ikke være involveret i behandling af logfiler. Logs bør udsendes enten til stdout eller sendes via en protokol som udp, så arbejdet med logs ikke skaber problemer for applikationen. Graylog er god til dette. Graylog-modtagelse af alle logfiler via udp (denne protokol kræver ikke at vente på et svar om en vellykket modtagelse af pakken) forstyrrer ikke applikationen på nogen måde og beskæftiger sig kun med strukturering og behandling af logfiler. Applikationslogikken ændres ikke til at arbejde med sådanne tilgange.
12. Administrationsopgaver
For at opdatere data, databaser osv. skal du bruge et separat oprettet slutpunkt i API'et, hvis du udfører det 2 gange i træk, vil alt blive duplikeret. Men du er ikke dum, du klikker ikke to gange, og vi har ikke brug for migrering.
Alle administrationsopgaver skal udføres i samme miljø som al kode på udgivelsesniveau. Det vil sige, at hvis vi skal ændre strukturen af databasen, så vil vi ikke gøre det manuelt ved at ændre navnene på kolonner og tilføje nye gennem nogle visuelle databasestyringsværktøjer. Til sådanne ting laver vi separate scripts - migreringer, som udføres overalt og i alle miljøer på samme måde med et fælles og forståeligt resultat. Til alle andre opgaver, såsom at fylde projektet med data, bør lignende metoder anvendes.
Eksempel på implementering i PHP, Laravel, Laradock, Docker-Compose
PS Alle eksempler blev lavet på MacOS. De fleste af dem er også velegnede til Linux. Windows-brugere, tilgiv mig, men jeg har ikke arbejdet med Windows i lang tid.
Lad os forestille os en situation, hvor vi ikke har nogen version af PHP installeret på vores pc og intet overhovedet.
Installer de seneste versioner af docker og docker-compose. (denne kan findes på internettet)
docker -v &&
docker-compose -v
1. Vi sætter
git clone https://github.com/Laradock/laradock.git &&
ls
Med hensyn til Laradock vil jeg sige, at det er en meget fed ting, som indeholder en masse containere og hjælpeting. Men jeg vil ikke anbefale at bruge Laradock som sådan uden ændringer i produktionen på grund af dens redundans. Det er bedre at oprette dine egne containere baseret på eksempler i Laradock, dette vil være meget mere optimeret, fordi ingen har brug for alt, hvad der er der på samme tid.
2. Konfigurer Laradock til at køre vores applikation.
cd laradock &&
cp env-example .env
2.1. Åbn habr-mappen (den overordnede mappe, hvori laradock er klonet) i en editor. (I mit PHPStorm-tilfælde)
På nuværende tidspunkt giver vi kun projektet et navn.
2.2. Start arbejdsområdebilledet. (I dit tilfælde vil billederne tage noget tid at bygge)
Workspace er et specielt forberedt billede til at arbejde med rammeværket på vegne af udvikleren.
Vi går ind i containeren vha
docker-compose up -d workspace &&
docker-compose exec workspace bash
2.3. Installation af Laravel
composer create-project --prefer-dist laravel/laravel application
2.4. Efter installationen tjekker vi om mappen med projektet er oprettet og dræber compose.
ls
exit
docker-compose down
2.5. Lad os gå tilbage til PHPStorm og indstille den korrekte sti til vores laravel-applikation i .env-filen.
3. Tilføj al koden til Git.
For at gøre dette vil vi oprette et lager på Github (eller andre steder). Lad os gå til habr-biblioteket i terminalen og udføre følgende kode.
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
Lad os tjekke om alt er i orden.
For nemheds skyld anbefaler jeg at bruge en visuel grænseflade til Git, i mit tilfælde er det det . (her er et henvisningslink)
4. Lad os starte!
Før du starter, skal du sikre dig, at der ikke hænger noget på port 80 og 443.
docker-compose up -d nginx php-fpm
Vores projekt består således af 3 separate tjenester:
- nginx - webserver
- php-fpm - php til at modtage anmodninger fra en webserver
- arbejdsområde - php for udviklere
I øjeblikket har vi opnået, at vi har lavet en applikation, der opfylder 4 point ud af 12, nemlig:
1. Kodebase — al koden er i ét lager (lille bemærkning: det kan være korrekt at tilføje docker inde i Laravel-projektet, men dette er ikke vigtigt).
2. Afhængigheder - Alle vores afhængigheder er eksplicit skrevet i application/composer.json og i hver Dockerfile i hver container.
3. Backing Services — Hver af tjenesterne (php-fom, nignx, workspace) lever sit eget liv og er forbundet udefra, og når man arbejder med en tjeneste, vil den anden ikke blive påvirket.
4. processer — hver service er én proces. Hver af tjenesterne opretholder ikke intern tilstand.
5. Port binding
docker ps
Som vi kan se, kører hver tjeneste på sin egen havn og er tilgængelig for alle andre tjenester.
6. parallelitet
Docker giver os mulighed for at skabe flere processer af de samme tjenester med automatisk belastningsbalancering mellem dem.
Lad os stoppe containerne og køre dem gennem flaget --vægt
docker-compose down &&
docker-compose up -d --scale php-fpm=3 nginx php-fpm
Som vi kan se, er der oprettet kopier af php-fpm-beholderen. Vi behøver ikke at ændre noget i arbejdet med denne container. Vi fortsætter også med at få adgang til det på port 9000, og Docker regulerer belastningen mellem containere for os.
7. Disponibilitet - hver container kan aflives uden at skade den anden. Stop eller genstart af beholderen vil ikke påvirke driften af applikationen under efterfølgende lanceringer. Hver container kan også løftes til enhver tid.
8. Applikationsudvikling/driftsparitet - alle vores miljøer er ens. Ved at køre systemet på en server i produktion, behøver du ikke at ændre noget i dine kommandoer. Alt vil være baseret på Docker på samme måde.
9. Logning — alle logfiler i disse containere går til stream og er synlige i Docker-konsollen. (i dette tilfælde, faktisk med andre hjemmelavede beholdere, er dette muligvis ikke tilfældet, hvis du ikke tager dig af det)
docker-compose logs -f
Men der er en hake i, at standardværdierne i PHP og Nginx også skriver logs til en fil. For at opfylde de 12 faktorer er det nødvendigt slukke skrive logfiler til en fil i konfigurationerne af hver container separat.
Docker giver også mulighed for at sende logs ikke kun til stdout, men også til ting som graylog, som jeg nævnte ovenfor. Og inde i graylog kan vi betjene logfilerne, som vi vil, og vores applikation vil ikke bemærke dette på nogen måde.
10. Administrationsopgaver — alle administrationsopgaver løses af laravel takket være håndværksværktøjet, præcis som skaberne af 12-faktor-applikationen ønsker det.
Som et eksempel vil jeg vise, hvordan nogle kommandoer udføres.
Vi går ind i containeren.
docker-compose exec workspace bash
php artisan list
Nu kan vi bruge enhver kommando. (bemærk venligst, at vi ikke har konfigureret databasen og cachen, så halvdelen af kommandoerne vil ikke blive udført korrekt, fordi de er designet til at fungere med cachen og databasen).
11. konfigurationer og 12. Byg, slip, løb
Jeg ønskede at dedikere denne del til Blue-Green Deployment, men den viste sig at være for omfattende til denne artikel. Jeg vil skrive en separat artikel om dette.
I en nøddeskal er konceptet baseret på CI/CD-systemer som f.eks Jenkins и Gitlab CI. I begge kan du indstille miljøvariabler knyttet til et specifikt miljø. I denne situation vil punkt c følgelig være opfyldt Konfigurationer.
Og pointen vedr Byg, slip, løb løses af indbyggede funktioner med navnet Pipeline.
Pipeline giver dig mulighed for at opdele implementeringsprocessen i mange faser, hvilket fremhæver stadierne af montering, frigivelse og udførelse. Også i Pipeline kan du oprette sikkerhedskopier, og faktisk hvad som helst. Dette er et værktøj med ubegrænset potentiale.
Ansøgningskoden er på .
Glem ikke at initialisere undermodulet, når du kloner dette lager.
PS: Alle disse tilgange kan bruges med alle andre hjælpeprogrammer og programmeringssprog. Det vigtigste er, at essensen ikke adskiller sig.
Kilde: www.habr.com