Развој апликација и плаво-зелена примена, заснована на методологији Тхе Твелве-Фацтор Апп са примерима у пхп-у и доцкер-у

Прво, мало теорије. Шта се десило Апликација Твелве-Фацтор?

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

Документ су креирали програмери Хероку платформе.

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

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

1. Цодебасе – Једна кодна база праћена у контроли верзија – вишеструка имплементација
2. Зависности – Експлицитно декларишите и изолујте зависности
3. Конфигурација – Сачувајте конфигурацију у току рада
4. Бацкинг Сервицес – Размотрите пратеће услуге као додатне ресурсе
5. Направи, пусти, покрени – Строго раздвојите фазу склапања и извођења
6. Процеси – Покрените апликацију као један или више процеса без држављанства
7. Порт биндинг – Извоз услуга преко повезивања порта
8. Паралелизам – Скалирајте своју апликацију користећи процесе
9. Једнократна употреба – Максимизирајте поузданост уз брзо покретање и чисто гашење
10. Паритет развоја апликације/операције – Нека ваша развојна, сценска и производна окружења буду што сличнија
11. Логгинг – Прегледајте дневник као ток догађаја
12. Послови администрације – Обављање задатака администрације/управљања користећи ад хоц процесе

Више информација о 12 фактора можете добити из следећих извора:

• Званични извор - обавезно прочитати
• Чланак на хабр. Апликација Твелве-Фацтор — званични превод
• Чланак на хабр. 7 фактора који недостају у апликацији 12 фактора - нови поглед на 12 фактора са циљем њиховог побољшања.

Шта је плаво-зелена примена?

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

Класична шема БГ Деплои изгледа као она приказана на слици испод.

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

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

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

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

Већина примера ће се на овај или онај начин укрштати са веб развојем (ово је изненађење), са ПХП-ом и Доцкер-ом.

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

1. Цодебасе

Користите ФТП и ФилеЗилла за отпремање датотека на сервере једну по једну, немојте чувати код нигде осим на производном серверу.

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

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

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

Пројекат увек треба да има јасно разумљиву листу зависности (под зависностима мислим и на окружење). Све зависности морају бити експлицитно дефинисане и изоловане.
Узмимо за пример Саставити и лучки радник.

Саставити — менаџер пакета који вам омогућава да инсталирате библиотеке у ПХП-у. Цомпосер вам омогућава да наведете верзије стриктно или слободно и да их експлицитно дефинишете. На серверу може бити 20 различитих пројеката и сваки ће имати личну листу пакета и библиотека независно од другог.

лучки радник — услужни програм који вам омогућава да дефинишете и изолујете окружење у коме ће апликација радити. Сходно томе, баш као и са цомпосер-ом, али детаљније, можемо утврдити са чиме апликација ради. Изаберите одређену верзију ПХП-а, инсталирајте само пакете неопходне да би пројекат функционисао, без додавања било чега додатног. И што је најважније, без мешања у пакете и окружење хост машине и друге пројекте. То јест, сви пројекти на серверу који раде кроз Доцкер могу користити апсолутно било који скуп пакета и потпуно другачије окружење.

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

Чувајте конфигурације као константе директно у коду. Одвојене константе за тест сервер, одвојене за производњу. Повежите рад апликације у зависности од окружења директно у пословну логику пројекта користећи иф елсе конструкције.

Конфигурације - ово је једини начин на који треба да се разликују имплементације пројеката. У идеалном случају, конфигурације треба да се прослеђују кроз променљиве окружења (енв варс).

Односно, чак и ако ускладиштите неколико конфигурационих датотека .цонфиг.прод .цонфиг.лоцал и преименујете их у тренутку постављања у .цонфиг (главна конфигурација из које апликација чита податке) - ово неће бити прави приступ, јер у овом случају ће информације из конфигурација бити јавно доступне свим програмерима апликација и подаци са производног сервера ће бити угрожени. Све конфигурације морају бити ускладиштене директно у систему за примену (ЦИ/ЦД) и генерисане за различита окружења са различитим вредностима неопходним за одређено окружење у време примене.

4. Услуге трећих лица

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

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

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

5. Направи, пусти, изврши

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

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

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

Овде се сећамо плаво-зелене примене, која вам омогућава не само да прелазите са једног кода на други, већ и да прелазите између свих ресурса, па чак и окружења са могућношћу да све вратите уназад.

6. Процеси

Чувајте податке о стању апликације директно у самој апликацији. Користите сесије у РАМ-у саме апликације. Користите што је могуће више дељења између услуга трећих страна. Ослоните се на чињеницу да апликација може имати само један процес и не дозвољава скалирање.

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

7. Везивање порта

Само веб сервер треба да зна како да ради са услугама трећих страна. Или још боље, инсталирајте услуге треће стране директно унутар веб сервера. На пример, као ПХП модул у Апацхе-у.
Сви ваши сервиси морају бити доступни једни другима путем приступа некој адреси и порту (лоцалгост:5432, лоцалхост:3000, нгинк:80, пхп-фпм:9000), односно из нгинк-а могу приступити и пхп-фпм-у и постгрес, и са пхп-фпм на постгрес и нгинк и заправо из сваког сервиса могу приступити другом сервису. На овај начин, одрживост услуге није везана за одрживост друге услуге.

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

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

Оставите простор за скалирање. Доцкер рој је одличан за ово.
Доцкер Сварм је алатка за креирање и управљање кластерима контејнера између различитих машина и гомиле контејнера на истој машини.

Користећи рој, могу да одредим колико ресурса ћу доделити сваком процесу и колико процеса истог сервиса ћу покренути, а интерни балансер, који прима податке о датом порту, аутоматски ће их прокси процесима. Дакле, видећи да се оптерећење на серверу повећало, могу додати још процеса, чиме се смањује оптерећење на одређеним процесима.

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

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

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

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

Производња, постављање и локална верзија апликације морају да се разликују. У производњи користимо Иии Лите фрамеворк, а локално Иии, тако да ради брже у производњи!

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

Доцкер нам такође помаже у томе. Ако се поштују све претходне тачке, коришћење доцкер-а ће довести до процеса постављања окружења и на производној и на локалној машини до уноса једне или две команде.

11. Трупци

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

Све евиденције треба посматрати као ток догађаја. Сама апликација не би требало да буде укључена у обраду дневника. Дневници треба да се излазе или на стдоут или шаљу путем протокола као што је удп, тако да рад са евиденцијама не ствара проблеме за апликацију. Граилог је добар за ово. Граилог прима све логове преко удп-а (овај протокол не захтева чекање одговора о успешном пријему пакета) ни на који начин не омета апликацију и бави се само структурирањем и обрадом дневника. Логика апликације се не мења да би радила са таквим приступима.

12. Послови администрације

Да бисте ажурирали податке, базе података, итд., користите посебно креирану крајњу тачку у АПИ-ју, њено извршавање 2 пута заредом ће довести до тога да се све дуплира. Али нисте глупи, нећете кликнути двапут, и не треба нам миграција.

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

Пример имплементације у ПХП, Ларавел, Ларадоцк, Доцкер-Цомпосе

П.С. Сви примери су направљени на МацОС-у. Већина њих је такође погодна за Линук. Корисници Виндовс-а, опростите ми, али дуго нисам радио са Виндовс-ом.

Хајде да замислимо ситуацију у којој немамо инсталирану ниједну верзију ПХП-а на нашем рачунару и уопште ништа.
Инсталирајте најновије верзије доцкер-а и доцкер-цомпосе. (ово се може наћи на Интернету)

docker -v && 
docker-compose -v

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

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

Што се тиче Ларадока, рећи ћу да је то врло кул ствар, која садржи доста контејнера и помоћних ствари. Али не бих препоручио коришћење Ларадоцка као таквог без модификација у производњи због његове сувишности. Боље је да креирате сопствене контејнере на основу примера у Ларадоцк-у, ово ће бити много оптимизованије, јер никоме није потребно све што је тамо у исто време.

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

cd laradock && 
cp env-example .env

2.1. Отворите хабр директоријум (надређени директоријум у који је клониран ларадоцк) у неком уређивачу. (У мом ПХПСторм случају)

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

2.2. Покрените слику радног простора. (У вашем случају, сликама ће бити потребно неко време да се направе)
Радни простор је посебно припремљена слика за рад са оквиром у име програмера.

Улазимо у контејнер користећи

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

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

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

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

ls
exit
docker-compose down

2.5. Вратимо се на ПХПСторм и поставимо исправну путању до наше ларавел апликације у .енв датотеци.

3. Додајте сав код у Гит.

Да бисмо то урадили, направићемо спремиште на Гитхуб-у (или било где другде). Идемо у директоријум хабр у терминалу и извршимо следећи код.

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

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

Ради практичности, препоручујем коришћење неког визуелног интерфејса за Гит, у мом случају јесте ГитКракен. (овде је линк за упућивање)

4. Покренимо!

Пре него што почнете, уверите се да ништа не виси на портовима 80 и 443.

docker-compose up -d nginx php-fpm

Дакле, наш пројекат се састоји од 3 одвојене услуге:

• нгинк - веб сервер
• пхп-фпм - пхп за пријем захтева са веб сервера
• радни простор - пхп за програмере

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

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

2. Зависности - Све наше зависности су експлицитно написане у апплицатион/цомпосер.јсон и у сваком Доцкерфилеу сваког контејнера.

3. Бацкинг Сервицес — Сваки од сервиса (пхп-фом, нигк, радни простор) живи свој живот и повезан је споља и када се ради са једним сервисом, други неће бити погођен.

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

5. Порт биндинг

docker ps

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

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

Доцкер нам омогућава да покренемо више процеса истих услуга са аутоматским балансирањем оптерећења између њих.

Хајде да зауставимо контејнере и прођемо их кроз заставу --Скала

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

Као што видимо, направљене су копије пхп-фпм контејнера. Не морамо ништа да мењамо у раду са овим контејнером. Такође настављамо да му приступамо на порту 9000, а Доцкер за нас регулише оптерећење између контејнера.

7. Једнократна употреба - сваки контејнер се може убити без повреде другог. Заустављање или поновно покретање контејнера неће утицати на рад апликације током наредних покретања. Сваки контејнер се такође може подићи у било ком тренутку.

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

9. Логгинг — сви записи у овим контејнерима иду у стрим и видљиви су у Доцкер конзоли. (у овом случају, у ствари, са другим домаћим контејнерима, то можда неће бити случај ако не водите рачуна о томе)

 docker-compose logs -f

Али постоји квака у томе што подразумеване вредности у ПХП-у и Нгинк-у такође пишу евиденције у датотеку. Да би се испунило 12 фактора, неопходно је онемогући писање дневника у датотеку у конфигурацијама сваког контејнера посебно.

Доцкер такође пружа могућност слања евиденција не само на стдоут, већ и на ствари као што је сиви дневник, који сам поменуо горе. А унутар сивог дневника, можемо управљати евиденцијама како желимо и наша апликација то ни на који начин неће приметити.

КСНУМКС. Послови администрације — сви административни задаци су решени ларавелом захваљујући занатском алату тачно онако како би креатори апликације са 12 фактора желели.

Као пример, показаћу како се неке команде извршавају.
Идемо у контејнер.

 
docker-compose exec workspace bash
php artisan list

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

КСНУМКС. Конфигурације i 12. Направи, пусти, покрени

Хтео сам да посветим овај део плаво-зеленој примени, али се испоставило да је превише опширан за овај чланак. О томе ћу написати посебан чланак.

Укратко, концепт је заснован на ЦИ/ЦД системима као што су јенкинс и Гитлаб ЦИ. У оба, можете поставити променљиве окружења повезане са одређеним окружењем. Сходно томе, у овој ситуацији, тачка ц ће бити испуњена Конфигурације.

И поента о Направи, пусти, покрени решава се уграђеним функцијама са именом Цевовод.

Цевовод омогућава вам да поделите процес имплементације у многе фазе, истичући фазе склапања, ослобађања и извршења. Такође у Пипелине-у можете креирати резервне копије, и заиста било шта. Ово је алат са неограниченим потенцијалом.

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

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

Извор: ввв.хабр.цом