Развој на апликации и распоредување сино-зелено, засновано на методологијата на апликацијата дванаесет фактори со примери во php и docker

Прво, малку теорија. Што се случи Апликацијата Twelve-Factor?

Со едноставни зборови, овој документ е дизајниран да го поедностави развојот на SaaS апликациите, помагајќи преку информирање на програмерите и инженерите на DevOps за проблемите и практиките кои најчесто се среќаваат при развојот на современите апликации.

Документот е креиран од развивачите на платформата Хероку.

Апликацијата Twelve-Factor може да се примени на апликации напишани на кој било програмски јазик и со користење на која било комбинација на услуги за поддршка (бази на податоци, редици за пораки, кешови итн.).

Накратко за факторите на кои се заснова оваа методологија:

1. Кодбаза – Една база на кодови следена во контролата на верзијата – повеќекратни распоредувања
2. Зависности – Експлицитно декларирајте и изолирајте ги зависностите
3. Конфигурација – Зачувајте ја конфигурацијата во траење
4. Услуги за поддршка – Размислете за услугите за поддршка како приклучни ресурси
5. Изградете, ослободете, трчајте – Строго одделете ги фазите на склопување и извршување
6. Процеси – Стартувај ја апликацијата како еден или повеќе процеси без државјанство
7. Врзување на пристаништето – Услуги за извоз преку пристаниште за врзување
8. Паралелизам – Скалирај ја вашата апликација користејќи процеси
9. Еднократна употреба – Максимизирајте ја доверливоста со брзо стартување и чисто исклучување
10. Паритет на развој/оперативна апликација – Чувајте ги вашите опкружувања за развој, инсценирање и производство колку што е можно слични
11. Сеча – Прикажете го дневникот како прилив на настани
12. Административни задачи – Извршете административни/управувачки задачи користејќи ad hoc процеси

Можете да добиете повеќе информации за 12-те фактори од следниве ресурси:

• Официјален извор - мора да се прочита
• Статија за habr. Апликацијата Twelve-Factor - официјален превод
• Статија за habr. 7 фактори што недостасуваат во апликацијата 12 фактори - свеж поглед на 12-те фактори со цел нивно подобрување.

Што е Сино-зелено распоредување?

Сино-зелено распоредување е метод за доставување апликација до производство на тој начин што крајниот клиент не гледа никакви промени од негова страна. Со други зборови, распоредување на апликација со нула престој.

Класичната шема BG Deploy изгледа како онаа прикажана на сликата подолу.

• На почеток има 2 физички сервери со апсолутно ист код, апликација, проект, а има и рутер (балансер).
• Рутерот првично ги насочува сите барања до еден од серверите (зелена).
• Во моментот кога треба повторно да го ослободите, целиот проект се ажурира на друг сервер (сина), која во моментов не обработува никакви барања.
• Откако кодот е вклучен сина боја серверот е целосно ажуриран, на рутерот му е дадена команда да се префрли зелени на сина сервер.
• Сега сите клиенти го гледаат резултатот од кодот што работи со сина сервер.
• За некое време, зелена серверот служи како резервна копија во случај на неуспешно распоредување на сина серверот и во случај на неуспех и грешки, рутерот го префрла корисничкиот проток назад кон зелена сервер со стара стабилна верзија, а новиот код се испраќа на ревизија и тестирање.
• И на крајот од процесот, тој се ажурира на ист начин зелена сервер. И по неговото ажурирање, рутерот го префрла протокот на барања назад кон зелена сервер.

Сето тоа изгледа многу добро и на прв поглед не би требало да има никакви проблеми со тоа.
Но, бидејќи живееме во современиот свет, опцијата со физичко префрлување како што е наведено во класичната шема не ни одговара. Забележете ги информациите засега, ќе се вратиме подоцна.

Лош и добар совет

Општи услови: Примерите подолу ги прикажуваат алатките/методологиите што ги користам, можете да користите апсолутно сите алтернативи со слични функции.

Повеќето од примерите на еден или друг начин ќе се вкрстат со веб-развојот (ова е изненадување), со PHP и Docker.

Ставовите подолу даваат едноставен практичен опис на употребата на факторите користејќи конкретни примери; ако сакате да добиете повеќе теорија на оваа тема, следете ги линковите погоре до оригиналниот извор.

1. Кодбаза

Користете FTP и FileZilla за да испраќате датотеки на серверите еден по еден, не чувајте го кодот на друго место освен на серверот за производство.

Проектот секогаш треба да има единствена база на кодови, односно целиот код доаѓа од еден оди складиште. Серверите (производство, поставување, тест1, тест2...) користат код од гранки на едно заедничко складиште. На овој начин постигнуваме конзистентност на кодот.

2. Зависности

Преземете ги сите библиотеки во папки директно во коренот на проектот. Направете ажурирања едноставно со префрлање на новиот код во папката со тековната верзија на библиотеката. Инсталирајте ги сите потребни алатки директно на серверот на домаќинот каде што работат уште 20 услуги.

Проектот секогаш треба да има јасно разбирлива листа на зависности (под зависности мислам и на околината). Сите зависности мора да бидат експлицитно дефинирани и изолирани.
Да земеме како пример композитор и пристанишен работник.

композитор — менаџер на пакети кој ви овозможува да инсталирате библиотеки во PHP. Композиторот ви овозможува строго или лабаво да наведете верзии и експлицитно да ги дефинирате. Може да има 20 различни проекти на серверот и секој ќе има лична листа на пакети и библиотеки независни од другите.

пристанишен работник — алатка која ви овозможува да ја дефинирате и изолирате околината во која ќе работи апликацијата. Според тоа, исто како и кај композиторот, но потемелно, можеме да одредиме со што работи апликацијата. Изберете специфична верзија на PHP, инсталирајте ги само пакетите потребни за да функционира проектот, без да додавате ништо дополнително. И што е најважно, без мешање во пакетите и околината на машината домаќин и други проекти. Тоа е, сите проекти на серверот што работат преку Docker можат да користат апсолутно секој сет на пакети и сосема поинаква средина.

3. Конфигурација

Чувајте ги конфигурациите како константи директно во кодот. Посебни константи за тест-серверот, одделни за производство. Врзете ја работата на апликацијата во зависност од околината директно во деловната логика на проектот користејќи if else конструира.

конфигурации - ова е единствениот начин на кој распоредувањето на проектите треба да се разликуваат. Идеално, конфигурациите треба да се пренесуваат низ променливите на околината (env vars).

Тоа е, дури и ако складирате неколку конфигурациски датотеки .config.prod .config.local и ги преименувате во моментот на распоредување во .config (главната конфигурација од која апликацијата чита податоци) - ова нема да биде вистинскиот пристап, бидејќи во овој случај информациите од конфигурациите ќе бидат јавно достапни за сите развивачи на апликации и податоците од производствениот сервер ќе бидат компромитирани. Сите конфигурации мора да се складираат директно во системот за распоредување (CI/CD) и да се генерираат за различни средини со различни вредности неопходни за одредена средина во моментот на распоредување.

4. Услуги од трета страна

Бидете строго врзани за околината, користете различни врски за исти услуги во одредени средини.

Всушност, оваа точка силно се преклопува со точката за конфигурации, бидејќи без оваа точка, не може да се направат нормални податоци за конфигурација и, генерално, способноста за конфигурирање нема да падне на ништо.

Сите врски со надворешни услуги, како што се сервери за редици, бази на податоци, услуги за кеширање, мора да бидат исти и за локалната средина и за околината од трета страна/производство. Со други зборови, во секое време, со менување на низата за поврзување, можам да ги заменам повиците до базата #1 со базата #2 без да го менувам кодот на апликацијата. Или, гледајќи напред, како пример, при скалирање на услугата, нема да мора да ја одредувате врската на некој посебен начин за дополнителен кеш-сервер.

5. Изградба, ослободување, извршување

Имајте ја само конечната верзија на кодот на серверот, без шанси за враќање назад. Нема потреба да се пополнува простор на дискот. Секој што мисли дека може да пушти код во производство со грешка е лош програмер!

Сите фази на распоредување мора да бидат одделени една од друга.

Имајте шанса да се вратите назад. Направете изданија со стари копии од апликацијата (веќе составени и подготвени за битка) зачувани во брз пристап, за во случај на грешки да можете да ја вратите старата верзија. Тоа е, условно постои папка соопштенија и папка тековната, и по успешното распоредување и склопување на папката тековната поврзано со симболична врска до новото издание што се наоѓа внатре соопштенија со конвенционалното име на бројот на изданието.

Ова е местото каде што се сеќаваме на распоредувањето на Сино-Зеленото, кое ви овозможува не само да се префрлате помеѓу кодот, туку и да се префрлате помеѓу сите ресурси, па дури и средини со можност да вратите сè назад.

6. Процеси

Чувајте ги податоците за состојбата на апликацијата директно во самата апликација. Користете сесии во RAM меморијата на самата апликација. Користете што е можно повеќе споделување помеѓу услуги од трети страни. Потпрете се на фактот дека апликацијата може да има само еден процес и не дозволува скалирање.

Што се однесува до сесиите, складирајте ги податоците само во кеш контролиран од услуги од трети страни (memcached, redis), па дури и ако имате 20 процеси на апликација кои работат, секој од нив, откако ќе пристапи до кешот, ќе може да продолжи да работи со клиентот во истата состојба во која корисникот работеше со апликацијата во друг процес. Со овој пристап, излегува дека без разлика колку копии од услуги од трети лица користите, сè ќе работи нормално и без проблеми со пристапот до податоците.

7. Поврзување на пристаништето

Само веб-серверот треба да знае како да работи со услуги од трети страни. Или уште подобро, инсталирајте услуги од трети лица директно во веб-серверот. На пример, како PHP модул во Apache.
Сите ваши услуги мора да бидат достапни меѓу себе преку пристап до некоја адреса и порта (localgost:5432, localhost:3000, nginx:80, php-fpm:9000), односно од nginx можам да пристапам и до php-fpm и до postgres, и од php-fpm до postgres и nginx и всушност од секој сервис можам да пристапам до друг сервис. На овој начин, одржливоста на услугата не е поврзана со одржливоста на друга услуга.

8. Паралелизам

Работете со еден процес, инаку неколку процеси нема да можат да се сложуваат еден со друг!

Оставете простор за скалирање. Докерскиот рој е одличен за ова.
Docker Swarm е алатка за создавање и управување со кластери на контејнери и помеѓу различни машини и куп контејнери на иста машина.

Користејќи рој, можам да одредам колку ресурси ќе доделам за секој процес и колку процеси од истата услуга ќе започнам, а внатрешниот балансер, примајќи податоци на дадена порта, автоматски ќе ги префрли на процесите. Така, гледајќи дека оптоварувањето на серверот е зголемено, можам да додадам повеќе процеси, а со тоа да го намалам оптоварувањето на одредени процеси.

9. Еднократна употреба

Не користете редици за работа со процеси и податоци. Убивањето на еден процес треба да влијае на целата апликација. Ако една услуга се намали, сè се намалува.

Секој процес и услуга може да се исклучи во секое време и тоа не треба да влијае на другите услуги (се разбира, тоа не значи дека услугата ќе биде недостапна за друга услуга, туку дека друга услуга нема да се исклучи по оваа). Сите процеси мора да се прекинат благодатно, така што кога ќе се прекинат, нема да се оштетат никакви податоци и системот ќе работи правилно следниот пат кога ќе го вклучите. Односно, дури и во случај на итен прекин, податоците не треба да се оштетат (механизмот на трансакцијата е погоден овде, барањата во базата работат само во групи и ако барем едно барање од групата не успее или се изврши со грешка, тогаш ниту едно друго барање од групата на крајот всушност не успева).

10. Паритет на развој/работење на апликации

Производството, поставувањето и локалната верзија на апликацијата мора да бидат различни. Во производството ја користиме рамката Yii Lite, и локално Yii, за да работи побрзо во производството!

Во реалноста, сите распоредувања и работа со код треба да бидат во речиси идентична средина (не зборуваме за физички хардвер). Исто така, секој вработен во развојот треба да може да го распореди кодот во производството доколку е потребно, а не некој специјално обучен оддел за развој, кој само благодарение на посебната сила може да ја подигне апликацијата во производство.

Во ова ни помага и Docker. Ако се почитуваат сите претходни точки, користењето на докер ќе доведе до внесување на една или две команди процесот на распоредување на околината и на производството и на локалната машина.

11. Дневници

Ние пишуваме дневници на датотеки и бази на податоци! Ние не чистиме датотеки и бази на податоци од дневници. Ајде само да купиме хард диск со 9000 Пета бајти и тоа е во ред.

Сите дневници треба да се сметаат како тек на настани. Самата апликација не треба да биде вклучена во обработка на дневници. Дневниците треба да се излезат или во stdout или да се испраќаат преку протокол како што е udp, така што работата со дневници не создава никакви проблеми за апликацијата. Graylog е добар за ова. Graylog што ги прима сите дневници преку udp (овој протокол не бара да се чека одговор за успешното примање на пакетот) не ја попречува апликацијата на кој било начин и се занимава само со структурирање и обработка на дневници. Логиката на апликацијата не се менува за да работи со такви пристапи.

12. Административни задачи

За да ги ажурирате податоците, базите на податоци итн., користете одделно креирана крајна точка во API, ако ја извршите 2 пати по ред ќе резултира со дуплирање на сè. Но, вие не сте глупави, нема да кликнете двапати и не ни треба миграција.

Сите административни задачи треба да се извршуваат во истата средина како и сите кодови, на ниво на ослободување. Односно, ако треба да ја промениме структурата на базата на податоци, тогаш тоа нема да го направиме рачно со менување на имињата на колоните и додавање нови преку некои алатки за визуелно управување со базата на податоци. За такви работи создаваме посебни скрипти - миграции, кои се извршуваат насекаде и во сите средини на ист начин со заеднички и разбирлив резултат. За сите други задачи, како што е пополнување на проектот со податоци, треба да се користат слични методологии.

Пример за имплементација во PHP, Laravel, Laradock, Docker-Compose

P.S Сите примери се направени на MacOS. Повеќето од нив се погодни и за Linux. Корисници на Windows, простете ми, но јас долго време не работам со Windows.

Ајде да замислиме ситуација кога немаме инсталирана верзија на PHP на нашиот компјутер и ништо воопшто.
Инсталирајте ги најновите верзии на docker и docker-compose. (ова може да се најде на Интернет)

docker -v && 
docker-compose -v

1. Стави Ларадок

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

Во врска со Ларадок, ќе кажам дека е многу кул работа, која содржи многу контејнери и помошни работи. Но, јас не би препорачал да го користите Laradock како таков без модификации во производството поради неговата вишок. Подобро е да креирате свои контејнери врз основа на примери во Ларадок, ова ќе биде многу пооптимизирано, бидејќи никому не му треба сè што е таму во исто време.

2. Конфигурирајте го Laradock да ја извршува нашата апликација.

cd laradock && 
cp env-example .env

2.1. Отворете го директориумот habr (матичната папка во која е клониран laradock) во некој уредник. (Во мојот случај PHPStorm)

Во оваа фаза на проектот му даваме само име.

2.2. Стартувајте ја сликата на работниот простор. (Во вашиот случај, на сликите ќе им треба извесно време да се изградат)
Работниот простор е специјално подготвена слика за работа со рамката во име на развивачот.

Влегуваме во контејнерот користејќи

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

2.3. Инсталирање на Ларавел

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

2.4. По инсталацијата, проверуваме дали директориумот со проектот е креиран и kill compose.

ls
exit
docker-compose down

2.5. Ајде да се вратиме на PHPStorm и да ја поставиме правилната патека до нашата laravel апликација во датотеката .env.

3. Додадете го целиот код во Git.

За да го направите ова, ќе создадеме складиште на Github (или на кое било друго место). Ајде да одиме во директориумот habr во терминалот и да го извршиме следниот код.

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

Ајде да провериме дали се е во ред.

За погодност, препорачувам да користите некој визуелен интерфејс за Git, во мојот случај тоа е GitKraken. (еве линк за упатување)

4. Ајде да започнеме!

Пред да започнете, проверете дали ништо не виси на портите 80 и 443.

docker-compose up -d nginx php-fpm

Така, нашиот проект се состои од 3 посебни услуги:

• nginx - веб сервер
• php-fpm - php за примање барања од веб-сервер
• работен простор - php за програмери

Во моментов, постигнавме дека направивме апликација која исполнува 4 поени од 12, и тоа:

1. Кодбаза — целиот код е во едно складиште (мала забелешка: можеби е точно да се додаде докер во проектот ларавел, но тоа не е важно).

2. Зависности - Сите наши зависности се експлицитно напишани во application/composer.json и во секоја Dockerfile од секој контејнер.

3. Услуги за поддршка — Секоја од услугите (php-fom, nignx, работен простор) живее свој живот и е поврзана однадвор и при работа со една услуга, другата нема да биде засегната.

4. Процеси — секоја услуга е еден процес. Секоја од услугите не одржува внатрешна состојба.

5. Врзување на пристаништето

docker ps

Како што можеме да видиме, секоја услуга работи на сопствена порта и е достапна за сите други услуги.

6. Паралелизам

Docker ни овозможува да создадеме повеќе процеси на исти услуги со автоматско балансирање на оптоварување меѓу нив.

Да ги запреме контејнерите и да ги поминеме низ знамето -- скала

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

Како што можеме да видиме, создадени се копии од контејнерот php-fpm. Не треба ништо да менуваме при работа со овој контејнер. Ние, исто така, продолжуваме да му пристапуваме на пристаништето 9000, а Docker го регулира товарот помеѓу контејнерите за нас.

7. Еднократна употреба - секој контејнер може да се убие без да му наштети на другиот. Запирањето или рестартирањето на контејнерот нема да влијае на работата на апликацијата за време на следните лансирања. Секој контејнер може да се подигне во секое време.

8. Паритет на развој/оперативна апликација - сите наши средини се исти. Со извршување на системот на сервер во производство, нема да мора да менувате ништо во вашите команди. Сè ќе се базира на Docker на ист начин.

9. Сеча - сите дневници во овие контејнери одат во пренос и се видливи во конзолата Docker. (во овој случај, всушност, со други домашни контејнери, ова може да не биде случај ако не се грижите за тоа)

 docker-compose logs -f

Но, постои забелешка во тоа што стандардните вредности во PHP и Nginx исто така пишуваат дневници во датотека. За да се исполнат 12-те фактори, потребно е оневозможи пишување логови во датотека во конфигурациите на секој контејнер посебно.

Docker, исто така, обезбедува можност за испраќање логови не само за stdout, туку и за такви работи како што се graylog, што ги споменав погоре. И внатре во Graylog, можеме да работиме со дневниците како што сакаме и нашата апликација нема да го забележи тоа на кој било начин.

10. Административни задачи — сите административни задачи се решаваат со Laravel благодарение на алатката artisan токму онака како што би сакале креаторите на апликацијата 12 фактор.

Како пример, ќе покажам како се извршуваат некои команди.
Влегуваме во контејнерот.

 
docker-compose exec workspace bash
php artisan list

Сега можеме да користиме која било команда. (Ве молиме имајте предвид дека не ги конфигуриравме базата на податоци и кешот, така што половина од командите нема да се извршат правилно, бидејќи тие се дизајнирани да работат со кешот и базата на податоци).

11. конфигурации и 12 година. Изградете, ослободете, трчајте

Сакав да го посветам овој дел на Сино-зелено распоредување, но се покажа дека е премногу обемен за оваа статија. Ќе напишам посебна статија за ова.

Накратко, концептот се заснова на CI/CD системи како Џенкинс и Гитлаб CI. Во двете, можете да поставите променливи на околината поврзани со одредена средина. Според тоа, во оваа ситуација, точката в ќе биде исполнета Конфигурации.

И поентата за Изградете, ослободете, трчајте се решава со вградени функции со името Гасоводот.

Гасоводот ви овозможува да го поделите процесот на распоредување во многу фази, истакнувајќи ги фазите на склопување, ослободување и извршување. Исто така во Pipeline, можете да креирате резервни копии, и навистина сè. Ова е алатка со неограничен потенцијал.

Кодот на апликацијата е на Github.
Не заборавајте да го иницијализирате подмодулот при клонирање на ова складиште.

P.S.: Сите овие пристапи може да се користат со кои било други алатки и програмски јазици. Главната работа е дека суштината не се разликува.

Извор: www.habr.com