Eerst een beetje theorie. Wat is er gebeurd ?
In eenvoudige bewoordingen is dit document bedoeld om de ontwikkeling van SaaS-applicaties te vereenvoudigen, door ontwikkelaars en DevOps-ingenieurs te informeren over de problemen en praktijken die het vaakst voorkomen bij de ontwikkeling van moderne applicaties.
Het document is gemaakt door de ontwikkelaars van het Heroku-platform.
De Twaalf-Factor-app kan worden toegepast op applicaties die in elke programmeertaal zijn geschreven en die elke combinatie van back-upservices gebruiken (databases, berichtenwachtrijen, caches, enz.).
Kort over de factoren waarop deze methodiek is gebaseerd:
- Codebasis – Eén codebase bijgehouden in versiebeheer – meerdere implementaties
- afhankelijkheden – Afhankelijkheden expliciet declareren en isoleren
- Configuratie – Configuratie opslaan in runtime
- Ondersteuningsdiensten – Beschouw back-upservices als plug-inbronnen
- Bouwen, loslaten, rennen – Houd de montage- en uitvoeringsfasen strikt gescheiden
- processen – Voer de applicatie uit als een of meer staatloze processen
- Poortbinding – Exportdiensten via poortbinding
- parallelliteit – Schaal uw applicatie met behulp van processen
- Wegwerpbaarheid – Maximaliseer de betrouwbaarheid met snel opstarten en schoon afsluiten
- Pariteit voor applicatieontwikkeling/-exploitatie – Houd uw ontwikkelings-, staging- en productieomgevingen zo vergelijkbaar mogelijk
- Loggen – Bekijk het logboek als een stroom gebeurtenissen
- Administratieve taken – Voer beheer-/beheertaken uit met behulp van ad-hocprocessen
Meer informatie over de twaalf factoren kunt u vinden in de volgende bronnen:
- - een must om te lezen
- - officiële vertaling
- - een frisse blik op de 12 factoren met als doel deze te verbeteren.
Wat is Blauw-Groene inzet?
Blue-Green-implementatie is een methode om een applicatie aan te leveren productie zodanig dat de eindklant geen veranderingen van zijn kant ziet. Met andere woorden: een applicatie implementeren met nul uitvaltijd.
Het klassieke BG Deploy-schema ziet eruit zoals weergegeven in de onderstaande afbeelding.
- In het begin zijn er 2 fysieke servers met absoluut dezelfde code, applicatie, project en is er een router (balancer).
- De router stuurt in eerste instantie alle verzoeken naar een van de servers (groen).
- Op het moment dat je opnieuw moet vrijgeven, wordt het hele project bijgewerkt op een andere server (blauw), die momenteel geen verzoeken verwerkt.
- Nadat de code is ingeschakeld blauw server volledig is bijgewerkt, krijgt de router een opdracht om van over te schakelen groen op blauw server.
- Nu zien alle clients het resultaat van de code die wordt uitgevoerd blauw server.
- Al enige tijd, groen de server dient als reservekopie voor het geval de implementatie mislukt blauw server en in geval van storingen en bugs schakelt de router de gebruikersstroom terug naar groen server met de oude stabiele versie, en de nieuwe code wordt verzonden voor revisie en testen.
- En aan het einde van het proces wordt het op dezelfde manier bijgewerkt groen server. En na het updaten schakelt de router de verzoekstroom terug naar groen server.
Het ziet er allemaal erg goed uit en op het eerste gezicht zouden er geen problemen mee moeten zijn.
Maar aangezien we in de moderne wereld leven, past de optie met fysiek schakelen zoals aangegeven in het klassieke schema niet bij ons. Noteer de informatie voor nu, we komen er later op terug.
Slecht en goed advies
Disclaimer: De onderstaande voorbeelden tonen de hulpprogramma's/methodologieën die ik gebruik. U kunt absoluut alle alternatieven met vergelijkbare functies gebruiken.
De meeste voorbeelden zullen op de een of andere manier kruisen met webontwikkeling (dit is een verrassing), met PHP en Docker.
De onderstaande paragrafen geven een eenvoudige praktische beschrijving van het gebruik van factoren aan de hand van specifieke voorbeelden; als je meer theorie over dit onderwerp wilt krijgen, volg dan de links hierboven naar de originele bron.
1. Codebasis
Gebruik FTP en FileZilla om bestanden één voor één naar de servers te uploaden. Bewaar de code nergens anders dan op de productieserver.
Het project moet altijd één codebasis hebben, dat wil zeggen dat alle code uit één codebasis komt Git opslagplaats. Servers (productie, staging, test1, test2...) gebruiken code uit vertakkingen van één gemeenschappelijke repository. Op deze manier bereiken we codeconsistentie.
2. Afhankelijkheden
Download alle bibliotheken in mappen rechtstreeks naar de hoofdmap van het project. Voer eenvoudig updates uit door de nieuwe code over te brengen naar de map met de huidige versie van de bibliotheek. Installeer alle benodigde hulpprogramma's rechtstreeks op de hostserver waar nog 20 services actief zijn.
Een project moet altijd een duidelijk begrijpelijke lijst van afhankelijkheden hebben (met afhankelijkheden bedoel ik ook de omgeving). Alle afhankelijkheden moeten expliciet worden gedefinieerd en geïsoleerd.
Laten we als voorbeeld nemen Componist и havenarbeider.
Componist — een pakketbeheerder waarmee u bibliotheken in PHP kunt installeren. Met Composer kunt u versies strikt of losjes specificeren en deze expliciet definiëren. Er kunnen 20 verschillende projecten op de server staan en elk project heeft een persoonlijke lijst met pakketten en bibliotheken, onafhankelijk van de ander.
havenarbeider — een hulpprogramma waarmee u de omgeving waarin de toepassing zal worden uitgevoerd, kunt definiëren en isoleren. Dienovereenkomstig kunnen we, net als bij composer, maar grondiger, bepalen waarmee de applicatie werkt. Selecteer een specifieke versie van PHP, installeer alleen de pakketten die nodig zijn om het project te laten werken, zonder iets extra's toe te voegen. En het allerbelangrijkste: zonder de pakketten en de omgeving van de hostmachine en andere projecten te verstoren. Dat wil zeggen dat alle projecten op de server die via Docker lopen, absoluut elke set pakketten en een compleet andere omgeving kunnen gebruiken.
3. Configuratie
Bewaar configuraties als constanten rechtstreeks in de code. Aparte constanten voor de testserver, apart voor productie. Verbind de werking van de applicatie, afhankelijk van de omgeving, rechtstreeks in de bedrijfslogica van het project met behulp van if else-constructies.
Configuraties - dit is de enige manier waarop projectimplementaties zouden moeten verschillen. Idealiter moeten configuraties worden doorgegeven via omgevingsvariabelen (env vars).
Dat wil zeggen, zelfs als u meerdere configuratiebestanden .config.prod .config.local opslaat en deze op het moment van implementatie hernoemt naar .config (de hoofdconfiguratie waaruit de applicatie gegevens leest) - dit zal niet de juiste aanpak zijn, aangezien in dit geval zal de informatie uit de configuraties publiekelijk beschikbaar zijn voor alle applicatieontwikkelaars en zullen de gegevens van de productieserver in gevaar komen. Alle configuraties moeten rechtstreeks in het implementatiesysteem (CI/CD) worden opgeslagen en worden gegenereerd voor verschillende omgevingen met verschillende waarden die nodig zijn voor een specifieke omgeving op het moment van implementatie.
4. Diensten van derden
Wees strikt gebonden aan de omgeving, gebruik in bepaalde omgevingen verschillende verbindingen voor dezelfde diensten.
In feite overlapt dit punt sterk met het punt over configuraties, omdat zonder dit punt geen normale configuratiegegevens kunnen worden gemaakt en, in het algemeen, de mogelijkheid om te configureren tot niets zal leiden.
Alle verbindingen met externe diensten, zoals wachtrijservers, databases, cachingdiensten, moeten hetzelfde zijn voor zowel de lokale omgeving als de externe/productieomgeving. Met andere woorden, door de verbindingsreeks te wijzigen, kan ik op elk moment oproepen naar basis #1 vervangen door basis #2 zonder de applicatiecode te wijzigen. Of als u vooruitkijkt, hoeft u bij het schalen van de service bijvoorbeeld de verbinding voor een extra cacheserver niet op een speciale manier te specificeren.
5. Bouwen, loslaten, uitvoeren
Zorg dat alleen de definitieve versie van de code op de server staat, zonder de kans om de release terug te draaien. U hoeft geen schijfruimte in te vullen. Iedereen die denkt dat hij code met een fout in productie kan brengen, is een slechte programmeur!
Alle fasen van de implementatie moeten van elkaar worden gescheiden.
Maak een kans om terug te rollen. Maak releases met oude exemplaren van de applicatie (al samengesteld en klaar voor de strijd) die snel zijn opgeslagen, zodat u in geval van fouten de oude versie kunt herstellen. Dat wil zeggen, voorwaardelijk is er een map releases en map actueel, en na succesvolle implementatie en montage van de map actueel verbonden door een symbolische link naar de nieuwe release die erin ligt releases met de conventionele naam van het releasenummer.
Dit is waar we ons de Blue-Green-implementatie herinneren, waarmee je niet alleen tussen code kunt schakelen, maar ook tussen alle bronnen en zelfs omgevingen kunt schakelen met de mogelijkheid om alles terug te draaien.
6. Processen
Bewaar applicatiestatusgegevens rechtstreeks in de applicatie zelf. Gebruik sessies in het RAM-geheugen van de applicatie zelf. Maak zoveel mogelijk gebruik van delen tussen services van derden. Vertrouw erop dat de applicatie slechts één proces kan hebben en geen schaalvergroting mogelijk maakt.
Wat sessies betreft, sla gegevens alleen op in een cache die wordt beheerd door services van derden (memcached, redis), dus zelfs als u 20 applicatieprocessen actief heeft, kan elk van deze, nadat ze toegang hebben gekregen tot de cache, met de client blijven werken. dezelfde staat waarin de gebruiker in een ander proces met de applicatie werkte. Met deze aanpak blijkt dat, ongeacht hoeveel exemplaren van services van derden u ook gebruikt, alles normaal en zonder problemen met toegang tot gegevens zal werken.
7. Poortbinding
Alleen de webserver mag weten hoe hij met services van derden moet werken. Of beter nog: installeer services van derden rechtstreeks op de webserver. Bijvoorbeeld als PHP-module in Apache.
Al uw services moeten voor elkaar toegankelijk zijn via toegang tot een bepaald adres en poort (localgost:5432, localhost:3000, nginx:80, php-fpm:9000), dat wil zeggen, vanuit nginx heb ik toegang tot zowel php-fpm als naar postgres, en van php-fpm tot postgres en nginx en eigenlijk heb ik vanaf elke service toegang tot een andere service. Op deze manier is de levensvatbaarheid van een dienst niet gebonden aan de levensvatbaarheid van een andere dienst.
8. Parallellisme
Werk met één proces, anders kunnen meerdere processen niet met elkaar overweg!
Laat ruimte voor schaalvergroting. Dockerzwerm is hier geweldig voor.
Docker Swarm is een hulpmiddel voor het maken en beheren van clusters van containers, zowel tussen verschillende machines als een aantal containers op dezelfde machine.
Met behulp van swarm kan ik bepalen hoeveel bronnen ik aan elk proces zal toewijzen en hoeveel processen van dezelfde service ik zal starten, en de interne balancer, die gegevens op een bepaalde poort ontvangt, zal deze automatisch aan de processen doorgeven. Omdat ik zie dat de belasting op de server is toegenomen, kan ik meer processen toevoegen, waardoor de belasting van bepaalde processen wordt verminderd.
9. Wegwerpbaarheid
Gebruik geen wachtrijen om met processen en gegevens te werken. Het beëindigen van één proces zou de hele applicatie moeten beïnvloeden. Als één dienst uitvalt, gaat alles kapot.
Elk proces en elke dienst kan op elk moment worden uitgeschakeld en dit mag geen invloed hebben op andere diensten (dit betekent uiteraard niet dat de dienst niet beschikbaar zal zijn voor een andere dienst, maar dat een andere dienst hierna niet wordt uitgeschakeld). Alle processen moeten netjes worden beëindigd, zodat wanneer ze worden beëindigd, er geen gegevens beschadigd raken en het systeem de volgende keer dat u het inschakelt correct zal werken. Dat wil zeggen, zelfs in het geval van een noodbeëindiging mogen de gegevens niet worden beschadigd (het transactiemechanisme is hier geschikt, queries in de database werken alleen in groepen, en als minstens één query uit de groep mislukt of wordt uitgevoerd met een fout, dan mislukt geen enkele andere vraag van de groep uiteindelijk).
10. Pariteit tussen applicatieontwikkeling en -gebruik
Productie, staging en lokale versie van de applicatie moeten verschillend zijn. In productie gebruiken we het Yii Lite framework, en lokaal Yii, zodat het in productie sneller werkt!
In werkelijkheid zouden alle implementaties en het werken met code in vrijwel een identieke omgeving moeten plaatsvinden (we hebben het niet over fysieke hardware). Bovendien zou elke ontwikkelingsmedewerker de code indien nodig in productie moeten kunnen zetten, en niet een speciaal opgeleide devops-afdeling, die alleen dankzij speciale kracht de applicatie in productie kan brengen.
Ook Docker helpt ons hierbij. Als aan alle voorgaande punten wordt voldaan, zal het gebruik van docker het proces van het implementeren van de omgeving, zowel op de productie als op de lokale machine, tot het invoeren van een of twee opdrachten leiden.
11. Logboeken
Wij schrijven logs naar bestanden en databases! We reinigen geen bestanden en databases uit logbestanden. Laten we gewoon een harde schijf kopen met 9000 Peta bytes en dat is prima.
Alle logboeken moeten worden beschouwd als een stroom gebeurtenissen. De applicatie zelf mag niet betrokken zijn bij het verwerken van logbestanden. Logs moeten worden uitgevoerd naar stdout of worden verzonden via een protocol zoals udp, zodat het werken met logs geen problemen oplevert voor de applicatie. Graylog is hier goed voor. Graylog die alle logs via udp ontvangt (dit protocol vereist geen wachten op een reactie over de succesvolle ontvangst van het pakket) interfereert op geen enkele manier met de applicatie en houdt zich alleen bezig met het structureren en verwerken van logs. De applicatielogica verandert niet als u met dergelijke benaderingen werkt.
12. Administratieve taken
Om gegevens, databases, enz. bij te werken, gebruikt u een afzonderlijk aangemaakt eindpunt in de API. Als u dit twee keer achter elkaar uitvoert, wordt alles gedupliceerd. Maar je bent niet dom, je klikt niet twee keer en we hebben geen migratie nodig.
Alle beheertaken moeten worden uitgevoerd in dezelfde omgeving als alle code, op releaseniveau. Dat wil zeggen, als we de structuur van de database moeten veranderen, dan zullen we dit niet handmatig doen door de namen van kolommen te wijzigen en nieuwe toe te voegen via een aantal visuele databasebeheertools. Voor zulke zaken maken we aparte scripts – migraties, die overal en in alle omgevingen op dezelfde manier worden uitgevoerd met een gemeenschappelijk en begrijpelijk resultaat. Voor alle andere taken, zoals het vullen van het project met gegevens, moeten vergelijkbare methoden worden gebruikt.
Voorbeeldimplementatie in PHP, Laravel, Laradock, Docker-Compose
PS Alle voorbeelden zijn gemaakt op MacOS. De meeste zijn ook geschikt voor Linux. Windows-gebruikers, vergeef me, maar ik heb al een hele tijd niet meer met Windows gewerkt.
Laten we ons een situatie voorstellen waarin we geen enkele versie van PHP op onze pc hebben geïnstalleerd en helemaal niets.
Installeer de nieuwste versies van docker en docker-compose. (dit is te vinden op internet)
docker -v &&
docker-compose -v
1. Wij zetten
git clone https://github.com/Laradock/laradock.git &&
ls
Wat Laradock betreft, zal ik zeggen dat het een heel cool ding is, dat veel containers en aanvullende dingen bevat. Maar ik zou Laradock als zodanig niet aanraden zonder aanpassingen in de productie vanwege de redundantie. Het is beter om zelf containers te maken op basis van voorbeelden in Laradock, dit zal veel geoptimaliseerder zijn, omdat niemand alles nodig heeft wat er tegelijkertijd is.
2. Configureer Laradock om onze applicatie uit te voeren.
cd laradock &&
cp env-example .env
2.1. Open de habr-map (de bovenliggende map waarin Laradock wordt gekloond) in een of andere editor. (In mijn PHPStorm-geval)
In dit stadium geven we het project alleen een naam.
2.2. Start de werkruimteafbeelding. (In jouw geval zal het enige tijd duren voordat de afbeeldingen zijn opgebouwd)
Workspace is een speciaal voorbereide afbeelding voor het werken met het raamwerk namens de ontwikkelaar.
We gaan de container binnen met behulp van
docker-compose up -d workspace &&
docker-compose exec workspace bash
2.3. Laravel installeren
composer create-project --prefer-dist laravel/laravel application
2.4. Na de installatie controleren we of de map met het project is aangemaakt en doden we compose.
ls
exit
docker-compose down
2.5. Laten we teruggaan naar PHPStorm en het juiste pad naar onze laravel-applicatie instellen in het .env-bestand.
3. Voeg alle code toe aan Git.
Om dit te doen, zullen we een repository op Github (of ergens anders) maken. Laten we naar de habr-map in de terminal gaan en de volgende code uitvoeren.
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
Laten we kijken of alles in orde is.
Voor het gemak raad ik aan om een visuele interface voor Git te gebruiken, in mijn geval is dat zo . (hier is een verwijzingslink)
4. Laten we lanceren!
Zorg er voordat u begint voor dat er niets op poort 80 en 443 blijft hangen.
docker-compose up -d nginx php-fpm
Ons project bestaat dus uit 3 afzonderlijke diensten:
- nginx - webserver
- php-fpm - php voor het ontvangen van verzoeken van een webserver
- werkruimte - php voor ontwikkelaars
Op dit moment hebben we bereikt dat we een applicatie hebben gemaakt die voldoet aan 4 punten van de 12, namelijk:
1. Codebasis — alle code bevindt zich in één repository (kleine opmerking: het kan correct zijn om docker toe te voegen aan het laravel-project, maar dit is niet belangrijk).
2. afhankelijkheden - Al onze afhankelijkheden worden expliciet geschreven in application/composer.json en in elk Dockerfile van elke container.
3. Ondersteuningsdiensten — Elk van de services (php-fom, nignx, workspace) leeft zijn eigen leven en is van buitenaf verbonden en als je met de ene service werkt, wordt de andere niet beïnvloed.
4. processen — elke dienst is één proces. Elk van de services behoudt de interne status niet.
5. Poortbinding
docker ps
Zoals we kunnen zien, draait elke dienst op zijn eigen poort en is toegankelijk voor alle andere diensten.
6. parallelliteit
Met Docker kunnen we meerdere processen van dezelfde services voortbrengen met automatische taakverdeling daartussen.
Laten we de containers tegenhouden en ze door de vlag halen --schaal
docker-compose down &&
docker-compose up -d --scale php-fpm=3 nginx php-fpm
Zoals we kunnen zien, zijn er kopieën gemaakt van de php-fpm-container. Aan het werken met deze container hoeven wij niets te veranderen. Ook blijven wij er toegang toe krijgen op poort 9000, en Docker regelt voor ons de lading tussen containers.
7. Wegwerpbaarheid - elke container kan worden gedood zonder de andere te schaden. Het stoppen of herstarten van de container heeft geen invloed op de werking van de applicatie tijdens volgende lanceringen. Elke container kan bovendien op elk moment worden gehesen.
8. Pariteit voor applicatieontwikkeling/-exploitatie - al onze omgevingen zijn hetzelfde. Door het systeem op een server in productie te laten draaien, hoeft u niets aan uw opdrachten te wijzigen. Alles zal op dezelfde manier op Docker gebaseerd zijn.
9. Loggen — alle logbestanden in deze containers worden gestreamd en zijn zichtbaar in de Docker-console. (in dit geval is dit bij andere zelfgemaakte bakjes misschien niet het geval als je er niet goed voor zorgt)
docker-compose logs -f
Maar er zit een addertje onder het gras: de standaardwaarden in PHP en Nginx schrijven ook logs naar een bestand. Om aan de 12 factoren te voldoen, is het noodzakelijk afsluiten het schrijven van logboeken naar een bestand in de configuraties van elke container afzonderlijk.
Docker biedt ook de mogelijkheid om logs niet alleen naar stdout te sturen, maar ook naar zaken als Graylog, die ik hierboven noemde. En binnen Graylog kunnen we de logs gebruiken zoals we willen, en onze applicatie zal hier op geen enkele manier iets van merken.
10. Administratieve taken — alle beheertaken worden door laravel opgelost dankzij de ambachtelijke tool, precies zoals de makers van de 12-factor-applicatie zouden willen.
Als voorbeeld zal ik laten zien hoe sommige opdrachten worden uitgevoerd.
We gaan de container in.
docker-compose exec workspace bash
php artisan list
Nu kunnen we elk commando gebruiken. (Houd er rekening mee dat we de database en de cache niet hebben geconfigureerd, dus de helft van de opdrachten zal niet correct worden uitgevoerd, omdat ze zijn ontworpen om met de cache en de database te werken).
11. Configuraties en 12. Bouwen, loslaten, rennen
Ik wilde dit onderdeel wijden aan Blue-Green Deployment, maar het bleek te uitgebreid voor dit artikel. Ik zal hier een apart artikel over schrijven.
In een notendop is het concept gebaseerd op CI/CD-systemen zoals Jenkins и Gitlab-CI. In beide kunt u omgevingsvariabelen instellen die aan een specifieke omgeving zijn gekoppeld. Dienovereenkomstig zal in deze situatie aan punt c worden voldaan Configuraties.
En het punt erover Bouwen, loslaten, rennen wordt opgelost door ingebouwde functies met de naam Pijpleiding.
Pijpleiding Hiermee kunt u het implementatieproces in vele fasen verdelen, waarbij de fasen van assemblage, release en uitvoering worden benadrukt. Ook in Pipeline kunt u back-ups maken, en eigenlijk alles. Dit is een instrument met onbeperkte mogelijkheden.
De applicatiecode is op .
Vergeet niet de submodule te initialiseren bij het klonen van deze repository.
PS: Al deze benaderingen kunnen worden gebruikt met alle andere hulpprogramma's en programmeertalen. Het belangrijkste is dat de essentie niet verschilt.
Bron: www.habr.com