Для пачатку крыху тэорыі. Што такое ?
Простымі словамі, гэта дакумент закліканы спрасціць распрацоўку SaaS прыкладанняў, дапамагае тым што, інфармавае распрацоўшчыкаў і DevOps інжынераў аб праблемах практыках якія часцей за ўсё сустракаліся ў распрацоўцы сучасных прыкладанняў.
Дакумент сфарміраваны распрацоўшчыкамі платформы Heroku.
Метадалогія дванаццаці фактараў (The Twelve-Factor App) можа быць ужытая для прыкладанняў, напісаных на любой мове праграмавання і выкарыстоўвалых любыя камбінацыі іншых службаў (backing services) (базы дадзеных, чэргі паведамленняў, кэш-памяці, і г.д.).
Коратка пра самі фактары на якіх будуецца гэтая метадалогія:
- Кодавая база – Адна кодавая база, якая адсочваецца ў сістэме кантролю версій, – мноства разгортванняў
- Залежнасці - Відавочна аб'яўляйце і ізалюйце залежнасці
- Канфігурацыя – Захоўвайце канфігурацыю ў асяроддзі выканання
- Іншыя службы (Backing Services) – Лічыце іншыя службы (backing services) падключаемымі рэсурсамі
- Зборка, рэліз, выкананне - Строга падзяляйце стадыі зборкі і выканання
- працэсы – Запускайце дадатак як адзін або некалькі працэсаў не захоўваюць унутраны стан (stateless)
- Прывязка партоў (Port binding) – Экспартуйце сэрвісы праз прывязку партоў
- паралелізм – Маштабуйце прыкладанне з дапамогай працэсаў
- Утылізавальнасць (Disposability) – Максімізуйце надзейнасць з дапамогай хуткага запуску і карэктнага завяршэння працы
- Парытэт распрацоўкі / працы прыкладання – Трымайце асяроддзі распрацоўкі, прамежкавага разгортвання (staging) і працоўнага разгортвання (production) максімальна падобнымі
- Журналіраванне (Logs) - Разглядайце часопіс як паток падзей
- Задачы адміністравання - Выконвайце задачы адміністравання / кіравання з дапамогай разавых працэсаў
Больш інфармацыі аб 12 фактарах вы можаце атрымаць з наступных рэсурсаў:
- - абавязкова да чытання
- - афіцыйны пераклад
- - свежы погляд на 12 фактараў з мэтай удасканаліць іх.
Што такое Blue-Green deployment?
Blue-Green deployment - гэта спосаб дастаўкі прыкладання на вытворчасць такім чынам, што канчатковы кліент не бачыць ніякіх змен са свайго боку. Іншымі словамі, разгортванне прыкладання з нулявым час прастою.
Класічная схема BG Deploy выглядае бо паказана на малюнку ніжэй.
- На старце ёсць 2 фізічных сервера з абсалютна аднолькавым кодам, дадаткам, праектам, і ёсць роўтар (балансавальнік).
- Роўтар першапачаткова накіроўвае ўсе запыты на адзін з сервераў (зялёны).
- У момант калі трэба зноў зрабіць рэліз, увесь праект абнаўляецца на іншым сэрвэры (сіні), які ў дадзены момант не апрацоўвае ніякіх запытаў.
- Пасля таго як код на сінім серверы цалкам абноўлены, роўтэру даецца каманда на тое, што трэба пераключыцца з зялёнага на сіні сервер.
- Цяпер усе кліенты бачаць вынік працы кода з сіняга сервера.
- Нейкі час, зялёны сервер служыць рэзервовай копіяй на выпадак няўдалага дэплою на сіні сервер і ў выпадку няўдачы і багаў, роўтэр перамыкае паток карыстальнікаў назад на зялёны сервер са старой стабільнай версіяй, а новы код адпраўляецца на дапрацоўку і тэсціраванне.
- І пад канец працэсу, сапраўды гэтак жа абнаўляецца зялёны сервер. І пасля яго абнаўлення, роўтэр перамыкае паток запытаў назад на зялёны сервер.
Выглядае гэта ўсё вельмі добрае і на першы погляд з гэтым не павінна быць ніякіх праблем.
Але бо мы жывем у сучасным міры, то варыянт з фізічным пераключэннем як паказана ў класічнай схеме нам не падыходзіць. Інфармацыю пакуль зафіксуйце, мы вернемся да яе пазней.
Шкодныя і добрыя парады
адмова: У прыкладах ніжэй пазначаны ўтыліты / метадалогіі якія выкарыстоўваю я, вы можаце выкарыстоўваць абсалютна любыя альтэрнатывы з падобнымі функцыямі.
Большасць прыкладаў будзе так ці інакш перасякацца з вэб-распрацоўкай (вось гэта нечаканасць), з PHP і Docker.
У пунктах ніжэй ідзе простае практычнае апісанне выкарыстання фактараў на пэўных прыкладах, калі вы хочаце атрымаць больш тэорыі па дадзенай тэме, звернецеся па спасылках вышэй да першакрыніцы.
1. Кодавая база
Выкарыстоўвайце FTP і FileZilla загружаючы файлы на серверы па адной штучцы, не захоўвайце код нідзе акрамя як на production серверы.
У праекце заўсёды павінна быць адзіная кодавая база, гэта значыць, увесь код ідзе з аднаго ісці рэпазітара. Серверы (production, staging, test1, test2 …) выкарыстоўваюць код з галінак аднаго агульнага рэпазітара. Такім чынам мы дамагаемся кансістэнтнасць кода.
2. Залежнасці
Спампоўвайце ўсе бібліятэкі тэчкамі прама ў корань праекта. Абнаўленні рабіце проста пераносам новага кода ў тэчку з бягучай версіяй бібліятэкі. Стаўце ўсе неабходныя ўтыліты прама на хаставы сервер дзе працуе яшчэ 20 службаў.
Праект заўсёды павінен мець выразна зразумелы спіс залежнасцяў (пад залежнасцямі я таксама разумею і асяроддзе). Усе залежнасці павінны быць відавочна вызначаны і ізаляваны.
У якасці прыкладу возьмем кампазітар и Докер.
кампазітар - пакетны мэнэджар, які дазваляе ўсталёўваць у PHP бібліятэкі. Composer дае магчымасць строга ці не строга паказваць версіі, і відавочна іх вызначаць. На серверы можа быць 20 розных праектаў і ў кожнага будзе асабісты спіс пакетаў і бібліятэк не які залежыць ад іншага.
Докер - Утыліта, якая дазваляе вызначаць і ізаляваць асяроддзе ў якім будзе працаваць прыкладанне. Адпаведна, гэтак жа як і з composer, але ўжо больш грунтоўна, мы можам вызначыць тое з чым працуе дадатак. Выбраць пэўную версію PHP, паставіць толькі неабходныя для працы праекту пакеты, не дадаючы нічога лішняга. А самае галоўнае не перасякаючыся з пакетамі і асяроддзем хаставой машыны і іншых праектаў. Гэта значыць, усе праекты на серверы працуюць праз Docker, могуць выкарыстоўваць абсалютна любы набор пакетаў і абсалютна рознае асяроддзе.
3. Канфігурацыя
Захоўваеце канфігі канстантамі прама ў кодзе. Асобныя канстанты для тэставага сервера, асобныя для прадакшэна. Завязвайце працу прыкладання ў залежнасці ад асяроддзя прама ў бізнэс логіцы праекту выкарыстоўваючы канструкцыі if else.
канфігурацыі - гэта адзінае чым павінны адрознівацца разгортванні праекта (deployment). У ідэале канфігурацыі павінны перадавацца праз зменныя асяроддзі (env vars).
Гэта значыць нават калі вы будзеце захоўваць некалькі канфігурацыйных файлаў. config.prod. config.local і пераназываць іх у момант разгортвання ў . з канфігурацый будзе агульнадаступная ўсім распрацоўнікам прыкладання і дадзеныя ад прадакшэн сервера будуць скампраметаваныя. Усе канфігурацыі павінны захоўвацца непасрэдна ў сістэме дэплайменту (CI/CD) і генеравацца пад розныя асяроддзі з рознымі значэннямі неабходнымі для пэўнага асяроддзя менавіта ў момант дэплойменту.
4. Іншыя службы (Backing Services)
Жорстка завязвайцеся на асяроддзі, выкарыстоўвайце розныя падлучэнні для адных і тых жа сэрвісаў у вызначаных акружэннях.
Насамрэч гэты пункт моцна перасякаецца з пунктам аб канфігурацыях, бо без наяўнасці гэтага пункта не зрабіць нармальныя канфігурацыйныя дадзеныя і наогул магчымасць канфігуравання спадзе на нішто.
Усе падлучэнні да вонкавых службаў, такім як серверы чэргаў, базы дадзеных, службы кэшавання павінны быць адзінымі як для лакальнага асяроддзя, так і для іншага / прадакшэн асяроддзя. Іншымі словамі, я ў любы момант магу змяніўшы радок падлучэння замяніць звароты да базы #1 на базу #2 без змены кода прыкладання. Ці забягаючы наперад як прыклад падыдзе тое што пры маштабаванні сэрвісу, вам не прыйдзецца для дадатковага сервера кэша паказваць падлучэнне нейкім адмысловым чынам.
5. Зборка, рэліз, выкананне
Майце на серверы толькі фінальную версію кода, без шанцаў адкаціць рэліз назад. Не трэба забіваць дыскавую прастору. Хто думае што можа пусціць код на прадакшэн з памылкай, той дрэнны праграміст!
Усе стадыі дэплайменту, павінны быць падзелены паміж сабой.
Майце шанец адкаціцца назад. Рабіце рэлізы з захаваннем у хуткім доступе старых копій прыкладання (ужо сабраных і гатовых да бою), каб у выпадку памылак аднавіць старую версію. Гэта значыць, умоўна ёсць тэчка рэлізы і тэчка ток, і пасля паспяховага дэплою і зборкі тэчка ток звязваецца сімвалічнай спасылкай з новым рэлізам які ляжыць усярэдзіне рэлізы з умоўнай назвай нумара рэлізу.
Вось тут мы і ўспамінаем аб 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, давядзе працэс разгортвання асяроддзя як на production, так і на лакальнай машыне да ўводу адной-двух каманд.
11. Журналіраванне (Logs)
Логі пішам у файлы і бд! Файлы і бд ад логаў не чысцім. Купім проста цвёрдая кружэлка на 9000 Пэта байт і нормаў.
Усе логі трэба разглядаць як паток падзей. Само прыкладанне не павінна займацца апрацоўкай логаў. Логі павінны выдавацца альбо ў stdout, альбо адпраўляцца па такім пратаколе як udp, каб з дадаткам праца з логамі не стварала ніякіх праблем. Для гэтага добра падыдзе graylog. Graylog прымаючы ўсе логі па udp (па гэтым пратаколе не патрабуецца чакаць адказу аб паспяховым прыёме пакета) не мяшае з дадаткам ніякай выявай і займаецца толькі структураваннем і апрацоўкай логаў. Логіка прыкладання не мяняецца для працы з падобнымі падыходамі.
12. Задачы адміністравання
Для абнаўлення дадзеных, бд і т/д выкарыстоўвайце асобна створаны эндпаінт у апі, выкананне якога 2 разы запар прывядзе да таго, што ў вас усё можа за дублявацца. Але вы ж не дурні, не націснеце 2 разы, а міграцыі нам ні да чаго.
Усе задачы адміністравання павінны выконвацца ў тым жа асяроддзі, што і ўвесь код, на ўзроўні рэлізаў. Гэта значыць, калі нам неабходна змяніць структуру бд, то мы не будзем рабіць гэта рукамі мяняючы назвы калонак і дадаючы новыя праз нейкія візуальныя інструменты кіравання БД. Для такіх рэчаў мы ствараем асобныя скрыпты - міграцыі, якія выконваюцца ўсюды і на ўсіх асяродках аднолькавага з агульным і зразумелым вынікам. Для ўсіх астатніх задач, тыпу напаўнення праекту дадзенымі, павінны ўжывацца падобныя метадалогіі.
Прыклад рэалізацыі на PHP, Laravel, Laradock, Docker-Compose
PS Усе прыклады рабіліся на MacOS. Большая частка падыдзе і для Linux. Карыстальнікі Windows ужо прабачыце, але з віндой я даўно не працаваў.
Прадстаўляльны сітуацыю што ў нас на ПК не ўсталяваная ніякая версія PHP і наогул нічога няма.
Усталеўваны docker і docker-compose апошніх версій. (гэта можна знайсці ў інтэрнэце)
docker -v &&
docker-compose -v
1. Ставім
git clone https://github.com/Laradock/laradock.git &&
ls
Па нагоды Laradock скажу што гэта вельмі класная штука, у якой сабрана вельмі шмат кантэйнераў і дапаможных штук. Але выкарыстоўваць як такі Laradock без мадыфікацый на production я б не рэкамендаваў з-за яго надмернасці. Лепш стварыць свае кантэйнеры абапіраючыся на прыклады ў 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 [email protected]:nzulfigarov/habr-12factor.git # здесь будет ссылка на ваш репо
git push -u origin master
git status
Правяраем ці ўсё ў парадку.
Для зручнасці рэкамендую выкарыстоўваць які-небудзь візуальны інтэрфейс для Git, у маім выпадку гэта . (тут реферальная спасылка)
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-fom, 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 фактарам, неабходна адключыць запіс логаў у файл у канфігурацыях кожнага кантэйнера асобна.
Гэтак жа докер дае магчымасць накіроўваць логі не проста ў stdout, а яшчэ і ў такія рэчы як graylog аб якім я казаў вышэй. А ўнутры graylog, мы можам апераваць логамі як заўгодна і наша дадатак ніяк не будзе заўважаць гэтага.
10. Задачы адміністравання — усе задачы адміністравання вырашаюцца laravel дзякуючы прыладзе artisan менавіта бо гэтага жадалі бы стваральнікі 12 фактарнага прыкладання.
У якасці прыкладу пакажу, як выконваюцца некаторыя каманды.
Заходзім у кантэйнер.
docker-compose exec workspace bash
php artisan list
Цяпер можам скарыстацца любой камандай. (звярніце ўвагу што мы не наладжвалі базу дадзеных і кэш таму палова каманд не выканаецца карэктна, бо яны прызначаны для працы з кэшам і бд).
11. канфігурацыі і 12. Зборка, рэліз, выкананне
Гэтую частку я хацеў прысвяціць Blue-Green Deployment, але гэта аказалася занадта разгорнутым для гэтага артыкула. Аб гэтым я напішу асобны артыкул.
У двух словах, канцэпт будуецца на сістэмах CI/CD. Джэнкінс и Gitlab CI. І ў той і ў другой можна задаваць зменныя асяроддзі злучаныя з пэўным асяроддзем. Адпаведна пры такім раскладзе будзе выконвацца пункт з Канфігурацыямі.
А пункт пра Зборка, рэліз, выкананне вырашаецца убудаванымі ў абедзве ўтыліты функцыі з назвай Трубаправод.
Трубаправод дазваляе падзяляць на шмат этапаў працэс дэплойменту, вылучаючы стадыі зборкі, рэлізу і выкананні. Гэтак жа ў Pipeline, вы зможаце стварыць бекапы, ды і наогул што заўгодна. Гэты інструмент з бязмежным патэнцыялам.
Код прыкладання ляжыць на .
Не забудзьцеся ініцыялізаваць submodule пры кланаванні дадзенага рэпазітара.
PS: Усе гэтыя падыходы можна выкарыстоўваць з любымі іншымі ўтылітамі і мовамі праграмавання. Галоўнае, каб іста не адрознівалася.
Крыніца: habr.com