Разработка на приложения и Blue-Green разгръщане, базирайки се на методологията на The Twelve-Factor App с примери на php и docker

В началото малко теория. Какво е The Twelve-Factor App?

С прости думи, това е документ, който има за цел да опрости разработката на SaaS приложения, като информира разработчиците и DevOps инженери за проблемите и практиките, които най-често се срещат в разработката на съвременни приложения.

Документът е съставен от разработчиците на платформата Heroku.

Методологията на дванадесетте фактора (The Twelve-Factor App) може да бъде приложена за приложения, написани на всеки език за програмиране и използващи всякакви комбинации от външни услуги (backing services) (бази данни, опашки за съобщения, кеш памет и др.).

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

1. Кодова база – Една кодова база, проследявана в система за контрол на версиите, – множество разгръщания
2. Зависимости – Ясно декларирайте и изолирайте зависимостите
3. Конфигурация – Запазвайте конфигурацията в работната среда
4. Външни услуги (Backing Services) – Считайте външните услуги (backing services) за свързани ресурси
5. Сглобяване, издаване, изпълнение – Строго разделяйте фазите на сглобяване и изпълнение
6. Процеси – Стартирайте приложението като един или повече процеси без запазено вътрешно състояние (stateless)
7. Привързване на портове (Port binding) – Изнасяйте услугите чрез привързване на портове
8. Паралелизъм – Масштабирайте приложението с помощта на процеси
9. Утилизируемост (Disposability) – Максимизирайте надеждността чрез бързо стартиране и коректно приключване
10. Паритет между разработка и работа на приложението – Дръжте средите за разработка, междинно разгръщане (staging) и продукция (production) възможно най-подобни
11. Логове (Logs) – Считайте логовете за поток от събития
12. Административни задачи – Изпълнявайте административни/управляващи задачи чрез еднократни процеси

Допълнителна информация за 12-те фактора можете да получите от следните ресурси:

• Официален източник — задължителен за прочит
• Статия в Habr. Приложението на дванадесетте фактора — The Twelve-Factor App — официален превод
• Статия в Habr. 7 липсващи фактора в подхода на 12 Factor App — нов поглед към 12-те фактора с цел усъвършенстване.

Какво е Blue-Green deployment?

Blue-Green deployment – това е метод за доставка на приложение production така, че крайният клиент не вижда никакви промени от своя страна. С други думи, разгръщането на приложението става без нулев престой.

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

• В началото има 2 физически сървъра с напълно идентичен код, приложение, проект и има рутер (балансировчик).
• Рутерът първоначално насочва всички заявки към един от сървърите (син).
• В момента, когато е необходимо отново да се направи релийз, целият проект се обновява на друг сървър (алфа), който в момента не обработва никакви заявки.
• След като кодът на синия сървър е напълно актуализиран, рутерът получава команда да се пренасочи от зеленото на алфа сървър.
• Сега всички клиенти виждат резултата от работата на кода с синия сървър.
• Някакво време, син сървърът служи като резервна копия в случай на неуспешно разгръщане на алфа сървър и в случай на провал и бъгове, рутерът пренасочва потока на потребителите обратно към син сървъра със старата стабилна версия, а новият код се изпраща на доработка и тестване.
• И в края на процеса, точно така се обновява син сървъра. И след обновяването му, рутерът пренасочва потока на заявките обратно на син сървър.

Цялото това изглежда много добре и на пръв поглед с него не би трябвало да има никакви проблеми.
Но понеже живеем в съвременния свят, вариантът с физическото преключване, както е указано в класическата схема, не е подходящ за нас. Записвайте информацията засега, ще се върнем към нея по-късно.

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

Отказ: В примерите по-долу са изброени инструменти / методологии, които аз използвам, можете да използвате абсолютно всякакви алтернативи с подобни функции.

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

В следващите точки следва прост практически описание на използването на факторите при конкретни примери, ако искате да получите повече теория по темата, обърнете се към линковете по-горе към първоизточника.

1. Кодова база

Използвайте FTP и FileZilla, за да качвате файлове на сървърите по един по един, не съхранявайте кода никъде освен на продукционния сървър.

В проект винаги трябва да има единна кодова база, т.е. целият код идва от един източник. Git репозитория. Сървърите (производствени, тестови, staging, test1, test2…) използват код от клонове на един общ репозиторий. По този начин постигаме консистентност на кода.

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

Сваляйте всички библиотеки в папки директно в корена на проекта. Актуализациите се правят просто чрез пренос на новия код в папката с текущата версия на библиотеката. Инсталирайте всички необходими утилити директно на хостинг сървъра, където работят още 20 услуги.

Проектът винаги трябва да има ясно и разбираемо изброяване на зависимостите (под зависимостите разбирам и средата). Всички зависимости трябва да бъдат явно определени и изолирани.
Като пример взимаме Composer и Docker.

Composer — пакетен мениджър, позволяващ инсталиране на PHP библиотеки. Composer дава възможност строго или не строго да се указват версии и да се определят явно. На сървъра могат да съществуват 20 различни проекта и всеки от тях ще има личен списък с пакети и библиотеки, независещи от другите.

Docker — утилита, позволяваща определяне и изолиране на средата, в която ще работи приложението. Следователно, както и при composer, но по-подробно, можем да определим с какво работи приложението. Да изберем определена версия на PHP, да инсталираме само необходимите пакети за функционирането на проекта, без да добавяме нищо излишно. Най-важното е, да не се пресичаме с пакетите и средата на хостинг машината и на другите проекти. Тоест всички проекти на сървера, работещи чрез Docker, могат да използват абсолютно всякакъв набор от пакети и съвсем различна среда.

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

Съхранявайте конфигурациите като константи директно в кода. Отделни константи за тестовия сървър, отделни за продукцията. Връзвайте работата на приложението в зависимост от средата в бизнес логиката на проекта, използвайки конструкции if else.

Конфигурации — това е единственото, с което трябва да се различават разгръщанията на проекта (deployment). В идеалния случай конфигурациите трябва да се предават чрез променливи на средата (env vars).

Тоест, дори ако съхранявате няколко конфигурационни файла .config.prod .config.local и ги преименувате по време на разгръщане на .config (основният конфиг, от който приложението чете данни) — това ще бъде неправилен подход, тъй като в такъв случай информацията от конфигурациите ще бъде публично достъпна за всички разработчици на приложението, а данните от продакшън сървъра ще бъдат компрометирани. Всички конфигурации трябва да се съхраняват директно в системата за деплоймент (CI/CD) и да се генерират за различни среди с различни стойности, необходими за конкретната среда именно в момента на деплоймент.

4. Външни услуги (Backing Services)

Стриктно се свързвайте с околната среда, използвайте различни връзки за едни и същи услуги в определени среди.

Всъщност този пункт силно се пресича с пункта за конфигурации, тъй като без наличието на този пункт не е възможно да се създадат нормални конфигурационни данни и изобщо възможността за конфигуриране ще изчезне.

Всички връзки към външни услуги, като сървъри за опашки, бази данни, услуги за кеширане, трябва да бъдат унифицирани както за локалната среда, така и за външната/продакшън среда. С други думи, във всеки момент мога, като променя връзката, да заменя повикванията към база #1 с база #2, без да променям кода на приложението. Или, казвайки напред, например, при мащабиране на услугата, няма да е необходимо за допълнителен кеш сървър да указвате връзката по някакъв специален начин.

5. Събиране, релиз, изпълнение

Имайте на сървъра само финалната версия на кода, без шансове за откат на релиза назад. Не е нужно да запълвате дисковото пространство. Онзи, който смята, че може да пусне код в продакшън с грешка, е лош програмист!

Всички етапи на деплоймента трябва да бъдат разделени помежду си.

Имайте възможност да се върнете назад. Правете релизи с запазване в бърз достъп на стари копия на приложението (вече събрани и готови за бой), така че в случай на грешки да възстановите стара версия. Тоест, условно, има папка releases и папка current, а след успешен деплой и сборна папка current свързва се с новия релиз, който е вътре в releases с условно име на номера на релиза.

Тук си спомняме за Blue-Green deployment, който позволява не само да се превключва между кода, но също така и между всички ресурси и дори среди, с възможност за реверсия на всичко.

6. Процеси

Съхранявайте данни за състоянието на приложението директно в самото приложение. Използвайте сесии в оперативната памет на самото приложение. Използвайте колкото се може повече споделени ресурси между външни услуги. Зависи от това, че приложението може да има само един процес и не допускайте възможност за мащабиране.

По отношение на сесиите, съхранявайте данни само в кеша, контролиран от външни услуги (memcached, redis), така че дори ако имате 20 работещи процеса на приложението, всякакъв от тях, свързвайки се с кеша, може да продължи работа с клиента в същото състояние, в което потребителят е работил с приложението в друг процес. С такъв подход, колкото и копия на външни услуги да използвате, всичко ще работи нормално и без проблеми с достъпа до данни.

7. Привързване на портове (Port binding)

Само уеб-сървърът трябва да знае как да работи с външни услуги. А по-добре е да стартирате външни услуги директно в уеб-сървъра. Например, като PHP модул в Apache.
Всички ваши услуги трябва да са достъпни помежду си чрез обръщение към определен адрес и порт (localgost:5432, localhost:3000, nginx:80, php-fpm:9000), т.е. от nginx мога да получа достъп както до php-fpm, така и до postgres, а от php-fpm до postgres и nginx, и всъщност от всяка услуга мога да получа достъп до друга услуга. По този начин устойчивостта на една услуга не зависи от устойчивостта на друга услуга.

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

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

Оставете възможност за мащабиране. Docker Swarm е отличен за това.
Docker Swarm е инструмент за създаване и управление на клъстери от контейнери, както между различни машини, така и на много контейнери на една машина.

Използвайки swarm, мога да определям колко ресурси ще отделя за всеки процес и колко на брой процеси на една и съща услуга ще стартирам, а вътрешният балансировчик, получавайки данни на зададен порт, автоматично ще ги проксира към процесите. По този начин, виждайки, че натоварването на сървъра се е увеличило, мога да добавя повече процеси, като по този начин намаля натоварването на определени процеси.

9. Утилизируемост (Disposability)

Не използвайте опашки за работа с процеси и данни. Убийството на един процес трябва да влияе на работата на цялото приложение. Ако една услуга падне — всичко ще падне.

Всеки процес и услуга могат да бъдат изключени по всяко време и това не трябва да засяга другите услуги (става дума не за това, че услугата няма да бъде достъпна за друга услуга, а за това, че другата услуга няма да се изключи след тази). Всички процеси трябва да приключват плавно, така че при приключването им данните да не пострадат и при следващото включване системата да работи коректно. Тоест, дори в случай на аварийно приключване, данните не трябва да пострадат (тук подхожда механизъм на транзакции, запитванията в базата данни работят само на групи, и ако поне едно запитване от групата не е изпълнено или е изпълнено с грешка, то никакво друго запитване от групата всъщност не се изпълнява).

10. Паритет на разработката/работата на приложението

Продукционната, стейджинг и локалната версия на приложението трябва да бъдат различни. На продукцията имаме рамка Yii Lite, а локално Yii, за да работи по-бързо в продукция!

В действителност всички разгръщания и работа с код трябва да бъдат почти в идентично обкръжение (става дума не за физическото желязо). Също така, разгръщането на кода на продукцията, при необходимост, трябва да може да извърши всеки служител от разработката, а не специално обучен отдел devops, който само благодарение на специална сила може да пуска приложението в продукцията.

Тук също ни помага Docker. При спазването на всички предходни точки, използването на docker ще доведе до процес на разгръщане на околната среда както на продукция, така и на локален компютър до въвеждането на едно-две команди.

11. Журнализиране (Logs)

Записваме логовете в файлове и бази данни! Не чистим файловете и базите данни от логове. Просто ще купим твърд диск с капацитет 9000 Пета бита и всичко ще бъде наред.

Всички логове трябва да се разглеждат като поток от събития. Самото приложение не трябва да се занимава с обработката на логовете. Логовете трябва да се изпращат или в stdout, или да се предават по протокол като udp, за да не създават проблеми на приложението по време на работа с логове. За това Graylog е отличен избор. Graylog, приемайки всички логове по udp (протоколът не изисква изчакване на потвърждение за успешен прием на пакета), не пречи на приложението по никакъв начин и се грижи само за структуриране и обработка на логовете. Логиката на приложението не се променя, за да работи с подобни подходи.

12. Задачи за администриране

За обновяване на данни, база данни и т.н., използвайте отделно създаден ендпоинт в API, чиято реализация, ако се извърши два пъти подред, може да доведе до дублиране на информацията. Но вие не сте глупави, няма да натиснете два пъти, а миграции не са ни нужни.

Всички задачи по администриране трябва да се извършват в същата среда, в която е целият код, на ниво издания. Тоест, ако трябва да променим структурата на базата данни, няма да го правим ръчно, променяйки имената на колоните и добавяйки нови чрез визуални инструменти за управление на БД. За такива неща създаваме отделни скриптове — миграции, които се изпълняват навсякъде и на всички среди с общ и разбираем резултат. За всички останали задачи, като запълване на проекта с данни, трябва да се прилагат подобни методологии.

Пример за реализация на PHP, Laravel, Laradock, Docker-Compose

P.S. Всички примери бяха направени на MacOS. Повечето от тях стават и за Linux. Потребителите на Windows, извинете, но отдавна не съм работил с Windows.

Да предположим, че на ПК ни не е инсталирана никаква версия на PHP и всъщност нищо няма.
Инсталираме docker и docker-compose в последните версии. (можете да ги намерите в интернет)

docker -v && 
docker-compose -v

1. Инсталираме Laradock

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

За Laradock ще кажа, че е чудесен инструмент, в който има много контейнери и помощни инструменти. Однако, не бих препоръчал да се използва Laradock в производствени условия без модификации поради неговата излишност. По-добре е да се създадат собствени контейнери, основавайки се на примерите в Laradock, така че да има възможности за оптимизация, тъй като никому не е нужно всичко, което там има, едновременно.

2. Конфигурираме Laradock за работа с нашето приложение.

cd laradock && 
cp env-example .env

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

На този етап поставяме само име на проекта.

2.2. Стартираме образа workspace. (Във вашия случай образите ще се билдват известно време)
Workspace — това е специално подготвен образ за работа с фреймворка от името на разработчика.

Влизаме в контейнера с помощта на

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

2.3. Инсталираме Laravel

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

2.4. След инсталацията проверяваме дали е създадена директорията с проекта и спираме 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 "първо комит"
git remote add origin git@github.com: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 за приемане на заявки от уеб сървъра
• workspace — php за разработчика

Към момента сме постигнали създаването на приложение, което отговаря на 4 пункта от 12, а именно:

1. Кодова база — целият код е в един репозиториум (малка бележка: може би е правилно да се вкара docker вътре в проекта laravel, но това не е решаващо).

2. Зависимости — Всичките ни зависимости са ясно описани в application/composer.json и във всеки Dockerfile на всеки контейнер.

3. Външни услуги (Backing Services) — Всяка от службите (php-fpm, nignx, workspace) живее своя живот и е свързана от външно, при работа с една служба, другата няма да бъде засегната.

4. Процеси — всяка служба е един процес. Всяка от услугите не запазва вътрешно състояние.

5. Привързване на портове (Port binding)

docker ps

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

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

Docker ни позволява да стартираме няколко процеса на едни и същи услуги с автоматично балансиране на натоварването между тях.

Спираме контейнерите и ги стартираме с флага —scale

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

Как можем да видим, php-fpm контейнерът е създал копия. Няма нужда да променяме нищо в работата с този контейнер. Продължаваме да взаимодействаме с него на порт 9000, а Docker регулира натоварването между контейнерите.

7. Утилизируемост (Disposability) — всеки контейнер може да бъде убит без вреда за друг. Спирането или рестартирането на контейнера не оказва влияние на работата на приложението при последващи стартирания. Всеки контейнер също може да се стартира по всяко време.

8. Паритет между разработка и работа на приложението — всичките ни среди са еднакви. Стартирайки системата на сървъра в продукция, няма да е необходимо да променяте нищо в вашите команди. Всичко ще бъде точно така, базирано на Docker.

9. Логове (Logs) — всички логове в тези контейнери излизат на поток и са видими в конзолата на Docker. (в този случай, наистина, с други самостоятелни контейнери, може да не е така, ако не се погрижите за това)

 docker-compose logs -f

Но тук има уловка, че Default стойностите в PHP и Nginx също записват логове в файл. За съответствие на 12 факторите, е необходимо можете да деактивирате записването на логове в файл в конфигурациите на всеки контейнер поотделно.

Също така Docker предоставя възможност за насочване на логовете не само в stdout, но и в неща като graylog, за които говорих по-горе. А в graylog можем да манипулираме логовете както искаме и нашето приложение няма да забележи това.

10. Административни задачи — всички задачи по администрирането се решават от Laravel благодарение на инструмента Artisan, точно както искат създателите на 12 факторното приложение.

Като пример ще покажа как се изпълняват някои команди.
Влизаме в контейнера.

 
docker-compose exec workspace bash
php artisan list

Сега можем да използваме всяка команда. (обърнете внимание, че не конфигурирахме базата данни и кеша, така че половината команди няма да се изпълнят правилно, тъй като са предназначени за работа с кеша и БД).

11. Конфигурации и 12. Сглобяване, издаване, изпълнение

Тази част исках да посветя на Blue-Green Deployment, но се оказа твърде обширна за тази статия. Ще напиша отделна статия за това.

Накратко, концепцията се основава на системи CI/CD, като Jenkins и Gitlab CI. И в двете можете да задавате променливи среда, свързани с конкретната среда. Съответно при такъв сценарий ще се изпълнява точка за Конфигурации.

А точката за Сглобяване, издаване, изпълнение се решава от вградените в двете утилити функции с името Pipeline.

Pipeline позволява да разделите процеса на много етапа, като обособите етапите на сборка, пускане и изпълнение. Също така в Pipeline можете да създавате резервни копия и наистина всичко, което желаете. Този инструмент има неограничен потенциал.

Кодът на приложението се намира на Github.
Не забравяйте да инициализирате submodule при клониране на този репозиторий.

P.S.: Всички тези подходи могат да се използват с каквито и да било други инструменти и програмни езици. Важно е основната идея да не се различава.

Източник: habr.com