Разработване на приложения и синьо-зелено внедряване въз основа на методологията на приложението с дванадесет фактора с примери за php и докер

Да започнем с малко теория. Какво стана Приложението Дванадесет фактора?

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

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

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

Накратко за самите фактори, на които се базира тази методика:

1. Кодова база – Една кодова база, проследявана от източника – множество внедрявания
2. зависимости – Изрично деклариране и изолиране на зависимости
3. Конфигурация – Запазване на конфигурацията по време на изпълнение
4. Услуги на трети страни (подкрепителни услуги) – Отнасяйте се към услугите за поддръжка като към допълнителни ресурси
5. Изграждане, освобождаване, стартиране – Строго разделени етапи на изграждане и изпълнение
6. процеси - Стартирайте приложението като един или повече процеси без състояние
7. Обвързване на порт – Експортиране на услуги чрез обвързване на порт
8. паралелизъм – Мащабирайте приложението си с процеси
9. Еднократна употреба – Увеличете надеждността с бързо стартиране и елегантно изключване
10. Паритет за разработка на приложения/операции – Поддържайте развойната, сценичната и производствената среда възможно най-сходни
11. Сеч - Третирайте дневника като поток от събития
12. Задачи на администрацията – Изпълнявайте административни/управленски задачи с еднократни процеси

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

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

Какво е синьо-зелено внедряване?

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

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

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

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

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

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

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

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

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

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

Един проект винаги трябва да има единична кодова база, тоест целият код идва от един отивам хранилище. Сървърите (производствени, етапни, test1, test2 ...) използват код от клоновете на едно общо хранилище. Така постигаме последователност на кода.

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

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

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

композирам - мениджър на пакети, който ви позволява да инсталирате библиотеки в PHP. Композиторът ви дава възможност да указвате стриктно или не стриктно версии и изрично да ги дефинирате. Може да има 20 различни проекта на сървър и всеки ще има частен списък с пакети и библиотеки, независими от другия.

докер - помощна програма, която ви позволява да дефинирате и изолирате средата, в която ще работи приложението. Съответно, точно както при composer, но по-задълбочено, можем да определим с какво работи приложението. Изберете конкретна версия на 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 е страхотен за това.
Docker Swarm е инструмент за създаване и управление на клъстери от контейнери както между различни машини, така и куп контейнери на една и съща машина.

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

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

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

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

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

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

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

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

11. Регистриране (Дневници)

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

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

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

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

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

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

PS Всички примери са направени на MacOS. Повечето ще работят и за Linux. Съжалявам, потребители на Windows, но не съм работил с Windows от дълго време.

Представете си ситуация, че нямаме никаква версия на PHP инсталирана на нашия компютър и изобщо нищо.
Инсталирайте най-новите версии на docker и docker-compose. (това може да се намери онлайн)

docker -v && 
docker-compose -v

1. Слагаме Ларадок

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

Влезте в контейнера с

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

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

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

2.4. След инсталацията проверяваме дали директорията с проекта е създадена и убиваме композирането.

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. Кодова база - целият код е в едно хранилище (малка забележка: може да е правилно да вкарате docker в проекта laravel, но това не е важно).

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

3. Услуги на трети страни (подкрепителни услуги) - Всяка от услугите (php-fom, nigx, workspace) живее свой собствен живот и е свързана отвън и при работа с една услуга, другата няма да бъде засегната.

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г. Изграждане, освобождаване, стартиране

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

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

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

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

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

PS: Всички тези подходи могат да се използват с всякакви други помощни програми и езици за програмиране. Основното е, че същността не се различава.

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