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

Преди всичко, малко теория. Какво е The Twelve-Factor App?

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

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

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

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

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

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

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

Какво е Blue-Green deployment?

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

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

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

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

Вредни и полезни съвети

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

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

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

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

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

В проекта винаги трябва да има единна кодова база, тоест, целият код идва от едно Git Репозиториите. Сървърите (production, 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.
Всички ваши услуги трябва да бъдат достъпни една за друга чрез обращение към някакъв адрес и порт (localhost: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, изпълнението на който два пъти подред може да доведе до дублиране на всичко. Но вие не сте глупаци да натиснете 2 пъти, а миграциите не ни трябват.

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

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

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

Представяме си ситуация, в която на нашия PC не е инсталирана никаква версия на 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 "first commit"
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, nginx, 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

Но, тук има уловка, че стойностите по подразбиране в 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