🥇Applicatieontwikkeling en Blue-Green deployment, gebaseerd op de The Twelve-Factor App-methodologie met voorbeelden in php en docker

Laten we beginnen met een beetje theorie. Wat is De Twelve-Factor App?

In eenvoudige woorden is dit een document dat is ontworpen om de ontwikkeling van SaaS-applicaties te vereenvoudigen, door ontwikkelaars en DevOps-ingenieurs bewust te maken van de problemen en praktijken die vaak voorkomen bij de ontwikkeling van moderne applicaties.

Het document is opgesteld door de ontwikkelaars van het Heroku-platform.

De Twelve-Factor App-methodologie kan worden toegepast op applicaties die in elke programmeertaal zijn geschreven en gebruikmaken van elke combinatie van externe diensten (backing services) (databases, berichtenqueues, caches, enz.).

Kort samengevat de factoren waarop deze methodologie is gebaseerd:

Codebase - Eén codebase, gevolgd in een versiebeheersysteem, met meerdere deployments
Afhankelijkheden - Verklaar en isoleer afhankelijkheden expliciet
Configuratie - Bewaar de configuratie in de uitvoeringomgeving
Externe diensten (Backing Services) - Beschouw externe diensten (backing services) als in te schakelen bronnen
Bouwen, release, uitvoering - Scheid strikt de fasen van bouwen en uitvoeren
Processen - Voer de applicatie uit als één of meerdere stateless processen
Poortbinding (Port binding) - Exporteer diensten via poortbinding
Parallelisme - Schaal de applicatie met behulp van processen
Verwijderbaarheid (Disposability) - Maximaliseer betrouwbaarheid door snel op te starten en correct af te sluiten
Pariteit tussen ontwikkeling/werk van de applicatie - Houd ontwikkelings-, staging- en productie-omgevingen zo gelijk mogelijk
Logboekregistratie (Logs) - Beschouw logboeken als een stroom van gebeurtenissen
Beheer taken - Voer beheer- of administratietaken uit via eenmalige processen

Voor meer informatie over de 12 factoren kunt u de volgende bronnen raadplegen:

Officiële bron — absoluut een must-read
Artikel op habr. De Twelve-Factor App — officiële vertaling
Artikel op habr. 7 ontbrekende factoren in de 12 Factor App-aanpak — een frisse kijk op de 12 factoren om ze te verbeteren.

Wat is Blue-Green deployment?

Blue-Green implementatie – dit is een methode voor het leveren van een applicatie op production een manier waarop de eindgebruiker geen veranderingen aan zijn kant ziet. Met andere woorden, de implementatie van de applicatie met nul downtime.

Het klassieke schema van BG Deploy ziet eruit zoals weergegeven in de afbeelding hieronder.

Bij de start zijn er 2 fysieke servers met exact dezelfde code, applicatie, project, en er is een router (load balancer).
De router stuurt aanvankelijk alle verzoeken naar een van de servers (groen).
Op het moment dat er opnieuw een release moet worden gedaan, wordt het gehele project bijgewerkt op de andere server (blauw), die op dat moment geen verzoeken verwerkt.
Nadat de code op de blauwe server volledig is bijgewerkt, krijgt de router de opdracht om over te schakelen van de groene en een werkende opdracht krijgen. blauw server.
Nu zien alle klanten de resultaten van de code op de blauwe servers.
Een tijdje fungeert groen de server als backup voor het geval de implementatie op de blauw server misloopt en bij mislukking en bugs schakelt de router de gebruikersstroom terug naar de groen server met de oude stabiele versie, terwijl de nieuwe code teruggestuurd wordt voor revisie en testen.
En aan het eind van het proces wordt ook zo de groen server geüpdatet. En na zijn update schakelt de router de verzoeken weer terug naar groen server.

Het ziet er allemaal heel goed uit en op het eerste gezicht zouden er geen problemen mee moeten zijn.
Maar omdat we in de moderne wereld leven, is de optie van fysieke overschakeling, zoals in het klassieke schema aangegeven, niet geschikt voor ons. Noteer de informatie voorlopig, we komen hier later op terug.

Slechte en goede tips

Disclaimer: In de onderstaande voorbeelden worden de tools/methodologieën genoemd die ik gebruik; u kunt absoluut elke alternatieve oplossing met vergelijkbare functies gebruiken.

De meeste voorbeelden zullen op de een of andere manier overlappen met webontwikkeling (wat een verrassing), met PHP en Docker.

In de punten hieronder vindt u een eenvoudige praktische beschrijving van het gebruik van factoren op bepaalde voorbeelden. Als u meer theorie over dit onderwerp wilt, kunt u terecht bij de bovenstaande links naar de originele bron.

1. Codebasis

Gebruik FTP en FileZilla om bestanden één voor één naar de servers te uploaden; sla de code nergens anders op dan op de productie server.

Er moet altijd één enkele codebasis in het project zijn, dat wil zeggen, alle code komt uit één Git repositories. Servers (production, staging, test1, test2, etc.) use code from branches of a common repository. This way, we achieve code consistency.

2. Dependencies

Download all libraries in folders directly to the root of the project. Updates are made simply by transferring new code into the folder with the current version of the library. Install all necessary utilities directly on the host server where 20 other services are running.

The project must always have a clearly defined list of dependencies (by dependencies, I also mean the environment). All dependencies must be explicitly defined and isolated.
As an example, let's take Composer en Docker.

Composer — a package manager that allows you to install libraries in PHP. Composer enables you to specify versions strictly or loosely and define them explicitly. There can be 20 different projects on the server, each with its own list of packages and libraries that do not depend on each other.

Docker — a utility that allows you to define and isolate the environment in which the application will run. Accordingly, just like with Composer, but more thoroughly, we can define what the application works with. Choose a specific version of PHP, install only the packages necessary for the project to work, without adding anything extra. Most importantly, do not overlap with the packages and environment of the host machine and other projects. This means all projects on the server running through Docker can use any set of packages and a completely different environment.

3. Configuration

Store configuration constants directly in the code. Separate constants for the test server, separate for production. Tie the application's operation to the environment directly in the business logic of the project using if else statements.

Configurations — this is the only thing that should differ between project deployments. Ideally, configurations should be passed through environment variables (env vars).

Dat wil zeggen, zelfs als u meerdere configuratiebestanden .config.prod .config.local opslaat en deze tijdens de uitrol hernoemt naar .config (de belangrijkste configuratie waarvan de gegevens door de applicatie worden gelezen), is dit geen correcte benadering. In dit geval zal de informatie uit de configuraties voor alle ontwikkelaars van de applicatie toegankelijk zijn en de gegevens van de productieserver zullen gecompromitteerd zijn. Alle configuraties moeten direct in het deploymentsysteem (CI/CD) worden opgeslagen en gegenereerd voor verschillende omgevingen met verschillende waarden die nodig zijn voor de specifieke omgeving op het moment van uitrol.

4. Externe Diensten (Backing Services)

Verbindt strikt met de omgeving, gebruik verschillende verbindingen voor dezelfde diensten in bepaalde omgevingen.

Dit punt overlapt sterk met het punt over configuraties, omdat zonder dit punt normale configuratiegegevens niet kunnen worden gemaakt en de mogelijkheid tot configureren volledig verdwijnt.

Alle verbindingen met externe diensten, zoals queue servers, databases en cachingdiensten, moeten hetzelfde zijn voor zowel de lokale omgeving als de externe / productieserveromgeving. Met andere woorden, ik moet op elk moment de verbindingsstring kunnen wijzigen om toegang van database #1 naar database #2 te wijzigen zonder de code van de applicatie te wijzigen. Of om vooruit te lopen, als voorbeeld, bij het opschalen van de dienst hoeft u voor een extra cachingserver de verbinding niet op een bijzondere manier aan te geven.

5. Build, Release, Execute

Houd alleen de uiteindelijke versie van de code op de server, zonder kans om de release terug te draaien. Vul de schijfruimte niet op. Wie denkt dat hij foutieve code in productie kan zetten, is een slechte programmeur!

Alle fasen van de uitrol moeten van elkaar gescheiden zijn.

Zorg ervoor dat u de kans heeft om terug te keren. Maak releases met de mogelijkheid om oude versies van de applicatie in de sneltoegang te bewaren (al gebouwde en inzetbare kopieën), zodat u in geval van fouten de oude versie kunt herstellen. Dat wil zeggen, er is voorwaardelijk een map releases en een map current, en na een succesvolle uitrol en build wordt de map current symbolisch gekoppeld aan de nieuwe release die binnen releases is met een voorwaardelijke naam van het release nummer.

Hier herinneren we ons het Blue-Green deployment, dat niet alleen de mogelijkheid biedt om tussen code te schakelen, maar ook om tussen alle bronnen en zelfs omgevingen te schakelen met de mogelijkheid om alles weer terug te draaien.

6. Processen

Bewaar de statusdata van de applicatie direct in de applicatie zelf. Gebruik sessies in het werkgeheugen van de applicatie. Gebruik zoveel mogelijk gedeelde opslag tussen externe diensten. Baseer je op het feit dat de applicatie maar één proces kan hebben en voorkom de mogelijkheid van schaalvergroting.

Wat sessies betreft, bewaar gegevens alleen in de cache die wordt beheerd door externe diensten (memcached, redis). Op deze manier, zelfs als je 20 applicatieprocessen hebt draaien, kan elk proces dat de cache benadert, blijven werken met de gebruiker in dezelfde staat als waar de gebruiker was toen hij met de applicatie in een ander proces werkte. Met deze aanpak zal, ongeacht het aantal exemplaren van de externe diensten dat je gebruikt, alles soepel werken zonder problemen met toegang tot gegevens.

7. Poortbinding (Port binding)

Slechts de webserver moet weten hoe te werken met externe diensten. Het is beter om externe diensten zelfs direct binnen de webserver te draaien. Bijvoorbeeld als een PHP-module in Apache.
Al je diensten moeten toegankelijk zijn voor elkaar via een bepaald adres en poort (localgost:5432, localhost:3000, nginx:80, php-fpm:9000). Dit betekent dat ik vanuit nginx toegang heb tot zowel php-fpm als postgres, en vanuit php-fpm tot postgres en nginx. Eigenlijk kan ik vanuit elke dienst toegang krijgen tot een andere dienst. Op deze manier hangt de levensvatbaarheid van de ene dienst niet af van de levensvatbaarheid van een andere dienst.

8. Parallelisme

Werk met één proces, want anders kunnen meerdere processen het moeilijk met elkaar hebben!

Laat de mogelijkheid tot schaalvergroting open. Docker swarm is hier excellent voor.
Docker Swarm is een tool voor het creëren en beheren van containerclusters, zowel tussen verschillende machines als tussen een heleboel containers op één machine.

Met behulp van swarm kan ik bepalen hoeveel resources ik aan elk proces toewijs en hoeveel processen van dezelfde service ik ga starten, terwijl de interne balancer de gegevens op de opgegeven poort automatisch naar de processen zal proxy'en. Als ik zie dat de belasting op de server is toegenomen, kan ik meer processen toevoegen, waardoor de belasting op bepaalde processen vermindert.

9. Beschikbaarheid

Gebruik geen queues voor het werken met processen en data. Het beëindigen van één proces moet invloed hebben op de werking van de hele applicatie. Als één service uitvalt, valt alles uit.

Elk proces en elke service kunnen op elk moment worden uitgeschakeld en dit mag geen invloed hebben op andere services (het gaat natuurlijk niet om het feit dat een service niet beschikbaar zal zijn voor een andere service, maar dat een andere service niet stopt omdat deze dat doet). Alle processen moeten op een zachte manier worden beëindigd, zodat er geen gegevens verloren gaan en het systeem bij de volgende opstart correct functioneert. Zelfs in het geval van een onverwachte beëindiging, mogen gegevens niet verloren gaan (een transactie-mechanisme is hier handig, waarbij database-aanvragen alleen in groepen werken, en als slechts één aanvraag in de groep faalt of met een fout wordt uitgevoerd, dan wordt geen andere aanvraag uit de groep feitelijk uitgevoerd).

10. Pariteit van ontwikkeling/werk van de applicatie

Productie, staging en lokale versies van de applicatie moeten verschillend zijn. Op productie hebben we het Yii Lite framework, terwijl we lokaal Yii gebruiken, zodat het op productie sneller werkt!

In werkelijkheid zouden alle implementaties en het werken met code bijna in identieke omgevingen moeten plaatsvinden (dit betreft niet de fysieke hardware). Ook moet elke medewerker van ontwikkeling in staat zijn om de code indien nodig in productie te implementeren, en niet slechts een speciaal opgeleid devops-team dat alleen dankzij een bijzondere vaardigheid de applicatie in productie kan brengen.

Hier helpt Docker ons ook bij. Door de naleving van alle voorgaande punten zal het gebruik van Docker het proces voor het opzetten van de omgeving, zowel op productie als op de lokale machine, reduceren tot het invoeren van één of twee commando's.

11. Logging

We schrijven logs naar bestanden en de database! We maken geen bestanden en databases van logs schoon. We kopen gewoon een harde schijf van 9000 Petabyte en dat is normaal.

Alle logs moeten worden beschouwd als een stroom van gebeurtenissen. De applicatie zelf mag zich niet bezighouden met het verwerken van logs. Logs moeten ofwel naar stdout worden geschreven, of verzonden via een protocol zoals udp, zodat de applicatie geen problemen ondervindt bij het werken met logs. Graylog is hiervoor een goede optie. Graylog accepteert alle logs via udp (dit protocol vereist niet dat je wacht op een bevestiging van succesvolle ontvangst van het pakket) en verstoort de applicatie op geen enkele manier; het richt zich alleen op het structureren en verwerken van logs. De logica van de applicatie verandert niet voor het werken met dergelijke benaderingen.

12. Beheertaken

Voor het bijwerken van gegevens, de database, enz. gebruik een apart aangemaakt eindpunt in de API. Het uitvoeren hiervan twee keer achter elkaar kan ertoe leiden dat alles in uw systeem wordt gedupliceerd. Maar u bent geen idioten; u zult niet twee keer klikken, en migraties zijn niet nodig.

Alle beheertaken moeten worden uitgevoerd in dezelfde omgeving als de rest van de code, op het niveau van releases. Dus, als we de database-structuur moeten wijzigen, dan zullen we dat niet handmatig doen door kolomnamen te veranderen of nieuwe toe te voegen via visual management tools. Voor dergelijke taken creëren we aparte scripts — migraties, die overal en op alle omgevingen hetzelfde resultaat opleveren. Voor alle andere taken, zoals het vullen van het project met gegevens, moeten vergelijkbare methodologieën worden toegepast.

Voorbeeldimplementatie in PHP, Laravel, Laradock, Docker-Compose

P.S. Alle voorbeelden zijn gemaakt op MacOS. Het grootste deel is ook toepasselijk voor Linux. Windows-gebruikers, excuses, maar ik heb al lang niet meer met Windows gewerkt.

Stel je voor dat we op onze PC geen versie van PHP geïnstalleerd hebben en überhaupt niets hebben.
Installeer de laatste versies van docker en docker-compose. (dit kan online gevonden worden)

docker -v && docker-compose -v

1. Installeer Laradock

git clone https://github.com/Laradock/laradock.git && ls

Over Laradock kan ik zeggen dat het een geweldige tool is, die veel containers en hulpprogramma's samenbrengt. Maar ik zou niet aanraden om Laradock zoals het is te gebruiken op productie, vanwege de overmaat. Het is beter om je eigen containers te maken, gebaseerd op de voorbeelden in Laradock; dat biedt ruimte voor optimalisatie, want niemand heeft alles wat daar is tegelijkertijd nodig.

2. Configureer Laradock voor het werken met onze applicatie.

cd laradock && cp env-example .env

2.1. Open de map habr (de bovenliggende map waarin laradock is gekloond) in een editor naar keuze. (In mijn geval PHPStorm)

In deze fase geven we alleen een naam aan het project.

2.2. Start de workspace afbeelding. (In jouw geval zullen de afbeeldingen een tijdje worden opgebouwd)
Workspace is een speciaal voorbereide afbeelding voor het werken met het framework namens de ontwikkelaar.

Ga naar binnen in de container met behulp van

docker-compose up -d workspace && 
docker-compose exec workspace bash

2.3. Installeer Laravel

composer create-project --prefer-dist laravel/laravel application

2.4. Controleer na de installatie of de projectmap is aangemaakt, en stop compose.

ls
exit
docker-compose down

2.5. Ga terug naar PHPStorm en stel het juiste pad naar onze Laravel-applicatie in het .env-bestand in.

3. Voeg alle code toe aan Git.

Daarvoor maken we een repository aan op Github (of ergens anders). Laten we in de terminal naar de habr-directory 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 git@github.com:nzulfigarov/habr-12factor.git # hier komt de link naar jouw repo
git push -u origin master
git status

Controleer of alles in orde is.

Voor de eenvoud raad ik aan een visuele interface voor Git te gebruiken, in mijn geval is dat GitKraken. (hier is de referral link)

4. Start nu!

Zorg ervoor dat er op poorten 80 en 443 niets draait voordat je start.

docker-compose up -d nginx php-fpm

Zo bestaat ons project uit 3 aparte services:

nginx — webserver
php-fpm — php voor het verwerken van aanvragen van de webserver
workspace — php voor de ontwikkelaar

Tot nu toe hebben we een applicatie gecreëerd die voldoet aan 4 van de 12 punten, namelijk:

1. Codebase — alle code bevindt zich in één repository (een kleine opmerking: het zou misschien beter zijn om Docker binnen het Laravel-project te implementeren, maar dat is niet cruciaal).

2. Afhankelijkheden — Al onze afhankelijkheden zijn expliciet gedefinieerd in application/composer.json en in elk Dockerfile van elke container.

3. Externe diensten (Backing Services) — Elke service (php-fpm, nginx, workspace) heeft zijn eigen leven en is van buitenaf verbonden, en bij het werken met één service wordt de andere niet aangetast.

4. Processen — elke service is één proces. Elke service bewaart geen interne staat.

5. Poortbinding (Port binding)

docker ps

Zoals we zien, draait elke service op zijn eigen poort en is toegankelijk voor alle andere services.

6. Parallelisme

Docker stelt ons in staat om meerdere processen van dezelfde services op te starten met automatische belastingverdeling tussen hen.

Laten we de containers stoppen en ze opnieuw starten met de vlag —scale

docker-compose down && 
docker-compose up -d --scale php-fpm=3 nginx php-fpm

Zoals we zien, zijn er kopieën van de php-fpm-container gecreëerd. We hoeven niets te veranderen bij het werken met deze container. We blijven ook verbinding maken met poort 9000, terwijl Docker de belasting tussen de containers regelt.

7. Verwijderbaarheid (Disposability) — elke container kan zonder schade voor de andere worden gestopt. Het stoppen of herstarten van een container heeft geen invloed op het functioneren van de applicatie bij volgende opstarten. Elke container kan op elk moment opnieuw worden opgestart.

8. Pariteit tussen ontwikkeling/werk van de applicatie — al onze omgevingen zijn identiek. Wanneer u het systeem op een server in productie draait, hoeft u niets aan uw commando's te veranderen. Alles zal precies dezelfde basis hebben in Docker.

9. Logboekregistratie (Logs) — alle logs in deze containers worden naar de stroom gestuurd en zijn zichtbaar in de Docker-console. (in deze casus, in feite, met andere zelfgemaakte containers, kan dit anders zijn als u daar geen rekening mee houdt)

 docker-compose logs -f

Maar er is een probleem: de standaardwaarden in PHP en Nginx schrijven ook logs naar een bestand. Om te voldoen aan de 12 factoren, is het noodzakelijk om uit te schakelen de logregistratie 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 dingen zoals graylog waar ik eerder over sprak. Binnen graylog kunnen we met logs omgaan zoals we willen en onze applicatie zal hier niets van merken.

10. Beheer taken — alle administratietaken worden door Laravel opgelost dankzij het artisan-hulpmiddel precies zoals de ontwikkelaars van de 12-factorapplicatie dat zouden willen.

Als voorbeeld laat ik zien hoe enkele commando's worden uitgevoerd.
We gaan de container binnen.

 
docker-compose exec workspace bash
php artisan list

Nu kunnen we gebruik maken van elk commando. (let op dat we de database en cache niet hebben ingesteld, daarom zal de helft van de commando's niet correct worden uitgevoerd, omdat ze zijn bedoeld voor gebruik met cache en db).

11. Configurations en 12. Bouwen, release, uitvoering

Ik wilde dit deel wijden aan Blue-Green Deployment, maar het bleek te uitgebreid voor dit artikel. Hierover zal ik een apart artikel schrijven.

In het kort, het concept is gebaseerd op CI/CD-systemen zoals Jenkins en Gitlab CI. In beide kan omgevingsvariabelen worden gedefinieerd die verband houden met de specifieke omgeving. Bij deze opzet wordt het punt met Configuraties.

En het punt over Bouwen, release, uitvoering wordt opgelost door de ingebouwde functies in beide hulpprogramma's met de naam Pipeline.

Pipeline maakt het mogelijk om het implementatieproces in veel fasen te splitsen, waarbij de fasen van bouwen, vrijgeven en uitvoeren worden benadrukt. In de Pipeline kunt u ook back-ups maken, en eigenlijk van alles. Deze tool heeft ongekende mogelijkheden.

De application code bevindt zich op Github.
Vergeet niet om de submodule te initialiseren bij het klonen van deze repository.

P.S.: Al deze benaderingen kunnen met elk ander hulpmiddel en programmeertaal worden gebruikt. Het belangrijkste is dat de essentie niet verschilt.

Bron: habr.com