Unue, iom da teorio. Kio okazis ?
En simplaj vortoj, ĉi tiu dokumento estas desegnita por simpligi la disvolviĝon de SaaS-aplikoj, helpante informante programistojn kaj DevOps-inĝenierojn pri la problemoj kaj praktikoj, kiuj plej ofte troviĝas en la disvolviĝo de modernaj aplikoj.
La dokumento estis kreita de la programistoj de la Heroku-platformo.
La Twelve-Factor App povas esti aplikata al aplikaĵoj skribitaj en iu ajn programlingvo kaj uzante ajnan kombinaĵon de apogservoj (datumbazoj, mesaĝvostoj, kaŝmemoroj, ktp.).
Mallonge pri la faktoroj sur kiuj baziĝas ĉi tiu metodaro:
- Kodbazo - Unu kodbazo spurita en versiokontrolo - multoblaj deplojoj
- Dependecoj – Eksplicite deklari kaj izoli dependecojn
- Agordo - Konservu agordon en rultempo
- Subtenaj Servoj – Konsideru subteni servojn kiel aldonajn rimedojn
- Konstrui, liberigi, kuri – Strikte apartigu la muntajn kaj ekzekutajn stadiojn
- Procezoj – Rulu la aplikaĵon kiel unu aŭ pluraj sennaciaj procezoj
- Haveno ligado - Eksportservoj per havena ligado
- Paralelismo - Skali vian aplikaĵon per procezoj
- Disponebleco - Maksimumigu fidindecon kun rapida ekfunkciigo kaj pura malŝalto
- Aplika evoluo/operacia egaleco - Konservu viajn evoluajn, surscenigitajn kaj produktadajn mediojn kiel eble plej similajn
- Enhavo - Rigardu la protokolon kiel fluon de eventoj
- Administraj taskoj – Faru administrajn/administrajn taskojn per ad hoc procezoj
Vi povas akiri pliajn informojn pri la 12 faktoroj el la jenaj rimedoj:
- - nepre leginda
- — oficiala traduko
- - freŝa rigardo al la 12 faktoroj kun la celo plibonigi ilin.
Kio estas Blua-Verda deplojo?
Blua-Verda deplojo estas metodo de liverado de aplikaĵo al produktado tiel, ke la fina kliento ne vidas ŝanĝojn siaflanke. Alivorte, disfaldi aplikaĵon kun nulo malrapida tempo.
La klasika BG Deploy-skemo aspektas kiel tiu montrita en la bildo sube.
- Komence estas 2 fizikaj serviloj kun absolute la sama kodo, aplikaĵo, projekto, kaj estas enkursigilo (balancilo).
- La enkursigilo komence direktas ĉiujn petojn al unu el la serviloj (verda).
- En la momento, kiam vi devas liberigi denove, la tuta projekto estas ĝisdatigita sur alia servilo (blua), kiu nuntempe ne prilaboras iujn ajn petojn.
- Post kiam la kodo estas ŝaltita blua servilo estas tute ĝisdatigita, la enkursigilo ricevas komandon por ŝanĝi verda sur blua servilo.
- Nun ĉiuj klientoj vidas la rezulton de la kodo kuranta kun blua servilo.
- Dum kelka tempo, verda la servilo funkcias kiel rezerva kopio en kazo de malsukcesa deplojo al blua servilo kaj en kazo de fiasko kaj cimoj, la enkursigilo ŝanĝas la uzantfluon reen al verda servilo kun la malnova stabila versio, kaj la nova kodo estas sendita por revizio kaj testado.
- Kaj ĉe la fino de la procezo, ĝi estas ĝisdatigita en la sama maniero verda servilo. Kaj post ĝisdatigi ĝin, la enkursigilo ŝanĝas la peton-fluon reen al verda servilo.
Ĉio aspektas tre bone kaj unuavide ne devus esti problemoj kun ĝi.
Sed ĉar ni vivas en la moderna mondo, la opcio kun fizika ŝanĝado kiel indikite en la klasika skemo ne konvenas al ni. Registru la informojn nuntempe, ni revenos al ĝi poste.
Malbona kaj bona konsilo
malgarantio: La malsupraj ekzemploj montras la ilojn/metodologiojn, kiujn mi uzas, vi povas uzi absolute iujn ajn alternativojn kun similaj funkcioj.
La plej multaj el la ekzemploj iel aŭ alia intersekciĝos kun TTT-disvolviĝo (ĉi tio estas surprizo), kun PHP kaj Docker.
La subaj alineoj provizas simplan praktikan priskribon de la uzo de faktoroj uzante specifajn ekzemplojn; se vi volas akiri pli da teorio pri ĉi tiu temo, sekvu la suprajn ligilojn al la originala fonto.
1. Kodbazo
Uzu FTP kaj FileZilla por alŝuti dosierojn al la serviloj unuope, ne konservu la kodon ie ajn krom sur la produktservilo.
La projekto ĉiam havu ununuran kodbazon, tio estas, ĉiu kodo venas de unu Git deponejo. Serviloj (produktado, enscenigo, test1, test2...) uzas kodon de branĉoj de unu komuna deponejo. Tiel ni atingas kodkonsekvencon.
2. Dependecoj
Elŝutu ĉiujn bibliotekojn en dosierujoj rekte al la radiko de la projekto. Faru ĝisdatigojn simple transdonante la novan kodon al la dosierujo kun la aktuala versio de la biblioteko. Instalu ĉiujn necesajn ilojn rekte sur la gastiga servilo, kie funkcias 20 pliaj servoj.
Projekto havu ĉiam klare kompreneblan liston de dependecoj (per dependecoj mi celas ankaŭ la medion). Ĉiuj dependecoj devas esti eksplicite difinitaj kaj izolitaj.
Ni prenu kiel ekzemplon komponisto и Docker.
komponisto — pakaĵmanaĝero kiu permesas vin instali bibliotekojn en PHP. Komponisto permesas al vi specifi versiojn strikte aŭ loze, kaj eksplicite difini ilin. Povas ekzisti 20 malsamaj projektoj sur la servilo kaj ĉiu havos personan liston de pakaĵoj kaj bibliotekoj sendependa de la alia.
Docker — ilo kiu permesas vin difini kaj izoli la medion en kiu la aplikaĵo funkcios. Sekve, same kiel kun komponisto, sed pli detale, ni povas determini per kio funkcias la aplikaĵo. Elektu specifan version de PHP, instalu nur la pakaĵojn necesajn por ke la projekto funkciu, sen aldoni ion kroman. Kaj plej grave, sen enmiksiĝi kun la pakoj kaj medio de la gastiga maŝino kaj aliaj projektoj. Tio estas, ĉiuj projektoj sur la servilo kuranta tra Docker povas uzi absolute ajnan aron da pakaĵoj kaj tute malsaman medion.
3. Agordo
Konservu agordojn kiel konstantojn rekte en la kodo. Apartaj konstantoj por la testa servilo, apartaj por produktado. Ligu la funkciadon de la aplikaĵo depende de la medio rekte en la komerca logiko de la projekto uzante se alie konstruas.
Agordoj - jen la nura maniero, ke projektdeplojoj devus diferenci. Ideale, agordoj devus esti pasitaj tra mediovariabloj (env vars).
Tio estas, eĉ se vi stokas plurajn agordajn dosierojn .config.prod .config.local kaj renomas ilin en la momento de deplojo al .config (la ĉefa agordo el kiu la aplikaĵo legas datumojn) - ĉi tio ne estos la ĝusta aliro, ĉar ĉi-kaze la informoj de la agordoj estos publike haveblaj al ĉiuj aplikaĵprogramistoj kaj datumoj de la produktadservilo estos kompromititaj. Ĉiuj agordoj devas esti stokitaj rekte en la deplojsistemo (CI/KD) kaj generitaj por malsamaj medioj kun malsamaj valoroj necesaj por specifa medio en la momento de deplojo.
4. Triaj Servoj
Estu strikte ligita al la medio, uzu malsamajn konektojn por la samaj servoj en certaj medioj.
Fakte, ĉi tiu punkto forte interkovras kun la punkto pri agordoj, ĉar sen ĉi tiu punkto, normalaj agordaj datumoj ne povas esti faritaj kaj, ĝenerale, la kapablo agordi falos al nenio.
Ĉiuj konektoj al eksteraj servoj, kiel atendovicserviloj, datumbazoj, kaŝmemorservoj, devas esti la samaj kaj por la loka medio kaj la triaparta/produktada medio. Alivorte, iam ajn, ŝanĝante la konektan ĉenon, mi povas anstataŭigi alvokojn al bazo n-ro 1 per bazo n-ro 2 sen ŝanĝi la aplikan kodon. Aŭ, rigardante antaŭen, ekzemple, dum skalado de la servo, vi ne devos specifi la konekton en iu speciala maniero por plia kaŝmemorservilo.
5. Konstrui, liberigi, ekzekuti
Havu nur la finan version de la kodo sur la servilo, sen ebleco revenigi la liberigon. Ne necesas plenigi diskospacon. Ĉiu, kiu opinias, ke ili povas liberigi kodon en produktadon kun eraro, estas malbona programisto!
Ĉiuj stadioj de deplojo devas esti apartigitaj unu de la alia.
Havu ŝancon retroiri. Faru eldonojn kun malnovaj kopioj de la aplikaĵo (jam kunvenitaj kaj pretaj por batalo) konservitaj en rapida aliro, por ke en kazo de eraroj vi povu restarigi la malnovan version. Tio estas, kondiĉe estas dosierujo liberigoj kaj dosierujo nuna, kaj post sukcesa deplojo kaj muntado la dosierujon nuna ligita per simbola ligo al la nova eldono kiu kuŝas interne liberigoj kun la konvencia nomo de la eldonnumero.
Ĉi tie ni memoras Blu-Verdan deplojon, kiu permesas vin ne nur ŝanĝi inter kodo, sed ankaŭ ŝanĝi inter ĉiuj rimedoj kaj eĉ medioj kun la kapablo refari ĉion.
6. Procezoj
Stoku aplikaĵajn statodatenojn rekte ene de la aplikaĵo mem. Uzu sesiojn en la RAM de la aplikaĵo mem. Uzu kiel eble plej multe da kundivido inter triaj servoj. Fidu sur la fakto, ke la aplikaĵo povas havi nur unu procezon kaj ne permesas grimpi.
Koncerne kunsidojn, konservu datumojn nur en kaŝmemoro kontrolita de triaj servoj (memcached, redis), do eĉ se vi havas 20 aplikajn procezojn kurantaj, iu el ili, alirinte la kaŝmemoron, povos daŭrigi labori kun la kliento en la sama stato en kiu la uzanto laboris kun la aplikaĵo en alia procezo. Kun ĉi tiu aliro, rezultas, ke kiom ajn kopioj de triaj servoj vi uzas, ĉio funkcios normale kaj sen problemoj kun aliro al datumoj.
7. Haveno ligado
Nur la retservilo devus scii kiel labori kun triaj servoj. Aŭ pli bone, instalu triajn servojn rekte en la retservilo. Ekzemple, kiel PHP-modulo en Apache.
Ĉiuj viaj servoj devas esti alireblaj unu por la alia per aliro al iu adreso kaj haveno (localgost:5432, localhost:3000, nginx:80, php-fpm:9000), tio estas, de nginx mi povas aliri kaj php-fpm kaj al postgres, kaj de php-fpm al postgres kaj nginx kaj fakte de ĉiu servo mi povas aliri alian servon. Tiel, la daŭrigebleco de servo ne estas ligita al la daŭrigebleco de alia servo.
8. Paralelismo
Laboru kun unu procezo, alie pluraj procezoj ne povos interkonsenti!
Lasu lokon por grimpi. Docker-svarmo estas bonega por ĉi tio.
Docker Swarm estas ilo por krei kaj administri aretojn de ujoj ambaŭ inter malsamaj maŝinoj kaj aro da ujoj sur la sama maŝino.
Uzante svarmon, mi povas determini kiom da rimedoj mi asignos al ĉiu procezo kaj kiom da procezoj de la sama servo mi lanĉos, kaj la interna ekvilibristo, ricevante datumojn pri donita haveno, aŭtomate prokuros ĝin al la procezoj. Tiel, vidante, ke la ŝarĝo sur la servilo pliiĝis, mi povas aldoni pli da procezoj, tiel reduktante la ŝarĝon de certaj procezoj.
9. Disponebleco
Ne uzu vostojn por labori kun procezoj kaj datumoj. Mortigi unu procezon devus influi la tutan aplikaĵon. Se unu servo malfunkcias, ĉio falas.
Ĉiu procezo kaj servo povas esti malŝaltita iam ajn kaj tio ne devus influi aliajn servojn (kompreneble, tio ne signifas, ke la servo estos neatingebla por alia servo, sed ke alia servo ne malŝaltos post ĉi tiu). Ĉiuj procezoj devas esti finitaj gracie, tiel ke kiam ili finiĝos, neniuj datumoj estos difektitaj kaj la sistemo funkcios ĝuste la venontan fojon kiam vi enŝaltos ĝin. Tio estas, eĉ en la okazo de kriz-ĉesigo, la datumoj ne devus esti difektitaj (la transakcia mekanismo taŭgas ĉi tie, demandoj en la datumbazo funkcias nur en grupoj, kaj se almenaŭ unu demando de la grupo malsukcesas aŭ estas efektivigita kun eraro, tiam neniu alia demando de la grupo finfine malsukcesas fakte).
10. Aplika evoluo/operacia egaleco
Produktado, enscenigo kaj loka versio de la aplikaĵo devas esti malsamaj. En produktado ni uzas la kadron Yii Lite, kaj loke Yii, por ke ĝi funkcias pli rapide en produktado!
En realeco, ĉiuj deplojoj kaj laboro kun kodo devus esti en preskaŭ identa medio (ni ne parolas pri fizika aparataro). Ankaŭ ĉiu disvolva dungito devus povi disfaldi la kodon al produktado se necese, kaj ne iu speciale trejnita devops-sekcio, kiu nur danke al speciala forto povas levi la aplikon en produktadon.
Docker ankaŭ helpas nin pri tio. Se ĉiuj antaŭaj punktoj estas observataj, uzi docker alportos la procezon de deploji la medion kaj sur produktado kaj sur la loka maŝino por enigi unu aŭ du komandojn.
11. Registroj
Ni skribas protokolojn al dosieroj kaj datumbazoj! Ni ne purigas dosierojn kaj datumbazojn el protokoloj. Ni nur aĉetu malmolan diskon kun 9000 Peta-bajtoj kaj tio estas bone.
Ĉiuj protokoloj estu konsiderataj kiel fluo de eventoj. La aplikaĵo mem ne devus esti implikita en prilaborado de protokoloj. Protokoloj devus esti eligitaj aŭ al stdout aŭ senditaj per protokolo kiel ekzemple udp, tiel ke labori kun protokoloj ne kreu problemojn por la aplikaĵo. graylog estas bona por ĉi tio. Graylog ricevi ĉiujn protokolojn per udp (ĉi tiu protokolo ne postulas atendi respondon pri la sukcesa ricevo de la pako) neniel malhelpas la aplikaĵon kaj nur traktas strukturadon kaj prilaboradon de protokoloj. La aplika logiko ne ŝanĝas por labori kun tiaj aliroj.
12. Administraj taskoj
Por ĝisdatigi datumojn, datumbazojn ktp., uzu aparte kreitan finpunkton en la API, ekzekuti ĝin 2 fojojn sinsekve rezultos, ke ĉio estas duobligita. Sed vi ne estas stulta, vi ne klakos dufoje, kaj ni ne bezonas migradon.
Ĉiuj administraj taskoj devas esti faritaj en la sama medio kiel ĉiu kodo, je la eldonnivelo. Tio estas, se ni bezonas ŝanĝi la strukturon de la datumbazo, tiam ni ne faros ĝin permane ŝanĝante la nomojn de kolumnoj kaj aldonante novajn per iuj vidaj datumbazaj administradaj iloj. Por tiaj aferoj, ni kreas apartajn skriptojn - migradojn, kiuj estas ekzekutitaj ĉie kaj en ĉiuj medioj sammaniere kun komuna kaj komprenebla rezulto. Por ĉiuj aliaj taskoj, kiel plenigi la projekton per datumoj, similaj metodaroj estu uzataj.
Ekzempla efektivigo en PHP, Laravel, Laradock, Docker-Compose
PS Ĉiuj ekzemploj estis faritaj sur MacOS. Plej multaj el ili ankaŭ taŭgas por Linukso. Vindozaj uzantoj, pardonu min, sed mi delonge ne laboris kun Vindozo.
Ni imagu situacion, kie ni havas neniun version de PHP instalita en nia komputilo kaj tute nenio.
Instalu la plej novajn versiojn de docker kaj docker-compose. (ĉi tio troveblas en la interreto)
docker -v &&
docker-compose -v
1. Ni metas
git clone https://github.com/Laradock/laradock.git &&
ls
Pri Laradock, mi diros, ke ĝi estas tre mojosa afero, kiu enhavas multajn ujojn kaj helpaĵojn. Sed mi ne rekomendus uzi Laradock kiel tia sen modifoj en produktado pro ĝia redundo. Pli bone estas krei viajn proprajn ujojn surbaze de ekzemploj en Laradock, ĉi tio estos multe pli optimumigita, ĉar neniu bezonas ĉion, kio estas tie samtempe.
2. Agordu Laradock por ruli nian aplikaĵon.
cd laradock &&
cp env-example .env
2.1. Malfermu la habr-dosierujon (la gepatra dosierujo en kiu laradock estas klonita) en iu redaktilo. (En mia kazo PHPStorm)
En ĉi tiu etapo ni nur donas nomon al la projekto.
2.2. Lanĉu la laborspacan bildon. (En via kazo, la bildoj daŭros iom da tempo por konstrui)
Laborspaco estas speciale preparita bildo por labori kun la kadro nome de la programisto.
Ni eniras la ujon uzante
docker-compose up -d workspace &&
docker-compose exec workspace bash
2.3. Instalante Laravel
composer create-project --prefer-dist laravel/laravel application
2.4. Post instalado, ni kontrolas ĉu la dosierujo kun la projekto estas kreita kaj kill compose.
ls
exit
docker-compose down
2.5. Ni reiru al PHPStorm kaj starigu la ĝustan vojon al nia laravel-apliko en la dosiero .env.
3. Aldonu la tutan kodon al Git.
Por fari tion, ni kreos deponejon sur Github (aŭ ie ajn). Ni iru al la dosierujo habr en la terminalo kaj ekzekutu la sekvan kodon.
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
Ni kontrolu ĉu ĉio estas en ordo.
Por komforto, mi rekomendas uzi iun vidan interfacon por Git, en mia kazo ĝi estas . (jen referenca ligilo)
4. Ni lanĉu!
Antaŭ ol komenci, certigu, ke nenio pendas sur la havenoj 80 kaj 443.
docker-compose up -d nginx php-fpm
Tiel, nia projekto konsistas el 3 apartaj servoj:
- nginx - retservilo
- php-fpm - php por ricevi petojn de retservilo
- laborspaco - php por programistoj
Nuntempe, ni atingis, ke ni kreis aplikaĵon, kiu plenumas 4 punktojn el 12, nome:
1. Kodbazo — la tuta kodo estas en unu deponejo (malgranda noto: eble estus ĝuste aldoni docker ene de la laravel-projekto, sed ĉi tio ne gravas).
2. Dependecoj - Ĉiuj niaj dependecoj estas eksplicite skribitaj en application/composer.json kaj en ĉiu Dockerfile de ĉiu ujo.
3. Subtenaj Servoj — Ĉiu el la servoj (php-fom, nignx, laborspaco) vivas sian propran vivon kaj estas konektita de ekstere kaj kiam oni laboras kun unu servo, la alia ne estos tuŝita.
4. Procezoj — ĉiu servo estas unu procezo. Ĉiu el la servoj ne konservas internan staton.
5. Haveno ligado
docker ps
Kiel ni povas vidi, ĉiu servo funkcias per sia propra haveno kaj estas alirebla por ĉiuj aliaj servoj.
6. Paralelismo
Docker permesas al ni generi plurajn procezojn de la samaj servoj kun aŭtomata ŝarĝoekvilibro inter ili.
Ni haltigu la ujojn kaj kuru ilin tra la flago --skalo
docker-compose down &&
docker-compose up -d --scale php-fpm=3 nginx php-fpm
Kiel ni povas vidi, kopioj estis kreitaj de la php-fpm-ujo. Ni ne bezonas ŝanĝi ion ajn laborante kun ĉi tiu ujo. Ni ankaŭ daŭre aliras ĝin sur haveno 9000, kaj Docker reguligas la ŝarĝon inter ujoj por ni.
7. Disponebleco - ĉiu ujo povas esti mortigita sen damaĝi la alian. Ĉesigi aŭ rekomenci la ujon ne influos la funkciadon de la aplikaĵo dum postaj lanĉoj. Ĉiu ujo ankaŭ povas esti levita iam ajn.
8. Aplika evoluo/operacia egaleco - ĉiuj niaj medioj estas samaj. Funkciante la sistemon sur servilo en produktado, vi ne devos ŝanĝi ion ajn en viaj komandoj. Ĉio estos bazita sur Docker en la sama maniero.
9. Enhavo — ĉiuj protokoloj en ĉi tiuj ujoj fluas kaj estas videblaj en la Docker-konzolo. (en ĉi tiu kazo, fakte, kun aliaj memfaritaj ujoj, tio eble ne estas la kazo se vi ne prizorgas ĝin)
docker-compose logs -f
Sed estas problemo, ke la defaŭltaj valoroj en PHP kaj Nginx ankaŭ skribas protokolojn al dosiero. Por renkonti la 12 faktorojn, necesas senaktivigi skribante protokolojn al dosiero en la agordoj de ĉiu ujo aparte.
Docker ankaŭ disponigas la kapablon sendi protokolojn ne nur al stdout, sed ankaŭ al tiaj aferoj kiel graylog, kiun mi menciis supre. Kaj ene de graylog, ni povas funkciigi la protokolojn laŭplaĉe kaj nia aplikaĵo neniel rimarkos tion.
10. Administraj taskoj — ĉiuj administraj taskoj estas solvitaj de laravel danke al la metiista ilo ĝuste kiel ŝatus la kreintoj de la aplikaĵo de 12 faktoroj.
Kiel ekzemplo, mi montros kiel kelkaj komandoj estas ekzekutitaj.
Ni iras en la ujon.
docker-compose exec workspace bash
php artisan list
Nun ni povas uzi ajnan komandon. (bonvolu noti, ke ni ne agordis la datumbazon kaj kaŝmemoron, do duono de la komandoj ne estos ekzekutitaj ĝuste, ĉar ili estas dizajnitaj por labori kun la kaŝmemoro kaj datumbazo).
11. Agordoj kaj 12. Konstrui, liberigi, kuri
Mi volis dediĉi ĉi tiun parton al Blua-Verda Deplojo, sed ĝi montriĝis tro ampleksa por ĉi tiu artikolo. Mi skribos apartan artikolon pri tio.
En resumo, la koncepto baziĝas sur CI/KD-sistemoj kiel Jenkins и Gitlab CI. En ambaŭ, vi povas agordi mediajn variablojn asociitajn kun specifa medio. Sekve, en ĉi tiu situacio, punkto c estos plenumita Agordoj.
Kaj la punkto pri Konstrui, liberigi, kuri estas solvita per enkonstruitaj funkcioj kun la nomo Pipeline.
Pipeline ebligas al vi dividi la procezon de deplojo en multajn stadiojn, elstarigante la stadiojn de muntado, liberigo kaj ekzekuto. Ankaŭ en Pipeline, vi povas krei sekurkopiojn, kaj efektive ion ajn. Ĉi tio estas ilo kun senlima potencialo.
La aplika kodo estas ĉe .
Ne forgesu pravalorigi la submodulon dum la klonado de ĉi tiu deponejo.
PS: Ĉiuj ĉi tiuj aliroj povas esti uzataj kun iuj aliaj utilecoj kaj programlingvoj. La ĉefa afero estas, ke la esenco ne diferencas.
fonto: www.habr.com