Նախ, մի փոքր տեսություն. Ինչ է պատահել ?
Պարզ բառերով ասած, այս փաստաթուղթը նախատեսված է պարզեցնելու SaaS հավելվածների զարգացումը` օգնելով ծրագրավորողներին և DevOps-ի ինժեներներին տեղեկացնելով ժամանակակից հավելվածների մշակման ժամանակ առավել հաճախ հանդիպող խնդիրների և պրակտիկայի մասին:
Փաստաթուղթը ստեղծվել է Heroku հարթակի մշակողների կողմից։
Twelve-Factor հավելվածը կարող է կիրառվել ցանկացած ծրագրավորման լեզվով գրված հավելվածների վրա և օգտագործելով օժանդակ ծառայությունների ցանկացած համակցություն (տվյալների բազաներ, հաղորդագրությունների հերթեր, քեշեր և այլն):
Համառոտ այն գործոնների մասին, որոնց վրա հիմնված է այս մեթոդաբանությունը.
- Codebase – Մեկ կոդերի բազա, որը հետևվում է տարբերակի վերահսկման մեջ՝ բազմաթիվ տեղակայումներ
- Կախվածություններ – Հստակորեն հայտարարել և մեկուսացնել կախվածությունները
- Տեսիլ - Պահպանեք կոնֆիգուրացիան գործարկման ժամանակ
- Պահպանման ծառայություններ – Համարեք օժանդակ ծառայությունները որպես հավելյալ ռեսուրսներ
- Կառուցել, ազատել, վազել – Խստորեն առանձնացրեք հավաքման և կատարման փուլերը
- Գործընթացները – Գործարկեք հավելվածը որպես քաղաքացիություն չունեցող մեկ կամ մի քանի գործընթաց
- Նավահանգստի կապում - Արտահանման ծառայություններ նավահանգիստների միջոցով
- Զուգահեռություն - Ձեր դիմումը մասշտաբավորեք՝ օգտագործելով գործընթացները
- Միանգամյա օգտագործման - Առավելագույնի հասցնել հուսալիությունը արագ գործարկման և մաքուր անջատման միջոցով
- Հավելվածի մշակման/գործողության հավասարություն – Պահպանեք ձեր զարգացման, բեմադրության և արտադրության միջավայրը հնարավորինս նման
- անտառահատումներ - Դիտեք գրանցամատյանը որպես իրադարձությունների հոսք
- Կառավարման առաջադրանքներ – Կատարել կառավարման/կառավարման առաջադրանքներ՝ օգտագործելով ժամանակավոր գործընթացները
12 գործոնների մասին լրացուցիչ տեղեկություններ կարող եք ստանալ հետևյալ ռեսուրսներից.
- - պարտադիր կարդալ
- - պաշտոնական թարգմանություն
- - 12 գործոնների թարմ հայացք՝ դրանք բարելավելու նպատակով:
Ի՞նչ է Կապույտ-Կանաչ տեղակայումը:
Կապույտ-կանաչ տեղաբաշխումը դիմումի առաքման մեթոդ է արտադրություն այնպես, որ վերջնական հաճախորդն իր կողմից որևէ փոփոխություն չտեսնի: Այսինքն՝ զրոյով հավելվածի տեղակայում դադար.
Դասական BG Deploy սխեման նման է ստորև նկարում ներկայացվածին:
- Սկզբում կան 2 ֆիզիկական սերվերներ՝ բացարձակապես նույն կոդով, հավելվածով, պրոյեկտով, և կա երթուղիչ (հավասարակշռող)։
- Ուղղորդիչը սկզբում բոլոր հարցումներն ուղղում է սերվերներից մեկին (կանաչ).
- Այն պահին, երբ դուք պետք է նորից թողարկեք, ամբողջ նախագիծը թարմացվում է մեկ այլ սերվերի վրա (կապույտ), որը ներկայումս որևէ հարցում չի մշակում:
- Կոդը միացնելուց հետո Կապույտ սերվերն ամբողջությամբ թարմացվել է, երթուղիչին հրաման է տրվում անցնել կանաչ մասին կապույտ սերվեր.
- Այժմ բոլոր հաճախորդները տեսնում են կոդի գործարկման արդյունքը կապույտ սերվեր.
- Ինչ - որ ժամանակ, կանաչ սերվերը ծառայում է որպես պահեստային պատճեն՝ անհաջող տեղակայման դեպքում կապույտ սերվեր, և ձախողման և սխալների դեպքում երթուղիչը հետ է փոխում օգտատիրոջ հոսքը կանաչ սերվերը հին կայուն տարբերակով, և նոր կոդը ուղարկվում է վերանայման և փորձարկման:
- Եվ գործընթացի վերջում այն նույն կերպ թարմացվում է կանաչ սերվեր. Եվ այն թարմացնելուց հետո երթուղիչը հետ է փոխում հարցումների հոսքը կանաչ սերվեր.
Ամեն ինչ շատ լավ է թվում, և առաջին հայացքից դրա հետ կապված որևէ խնդիր չպետք է լինի:
Բայց քանի որ մենք ապրում ենք ժամանակակից աշխարհում, դասական սխեմայում նշված ֆիզիկական անջատման տարբերակը մեզ չի համապատասխանում: Առայժմ գրանցեք տեղեկատվությունը, կանդրադառնանք ավելի ուշ։
Վատ և լավ խորհուրդ
Հրաժարում պատասխանատվությունիցՍտորև բերված օրինակները ցույց են տալիս իմ օգտագործած կոմունալ ծառայությունները/մեթոդոլոգիաները, դուք կարող եք օգտագործել բացարձակապես ցանկացած այլընտրանք՝ նմանատիպ գործառույթներով:
Օրինակների մեծ մասը այս կամ այն կերպ կհատվի վեբ մշակման հետ (սա անակնկալ է), PHP-ի և Docker-ի հետ։
Ստորև բերված պարբերությունները տալիս են գործոնների օգտագործման պարզ գործնական նկարագրություն՝ օգտագործելով կոնկրետ օրինակներ: Եթե ցանկանում եք ավելի շատ տեսություն ստանալ այս թեմայի վերաբերյալ, հետևեք վերը նշված հղումներին դեպի սկզբնաղբյուր:
1. Codebase
Օգտագործեք FTP և FileZilla ֆայլերը սերվերներ մեկ առ մեկ վերբեռնելու համար, մի պահեք կոդը ոչ մի այլ վայրում, բացառությամբ արտադրության սերվերի:
Նախագիծը միշտ պետք է ունենա մեկ ծածկագրի հիմք, այսինքն՝ բոլոր ծածկագրերը գալիս են մեկից գնալ պահոց. Սերվերները (արտադրություն, բեմականացում, test1, test2...) օգտագործում են կոդ մեկ ընդհանուր պահեստի մասնաճյուղերից: Այս կերպ մենք հասնում ենք կոդի հետևողականությանը:
2. Կախվածություններ
Ներբեռնեք բոլոր գրադարանները թղթապանակներում անմիջապես նախագծի արմատին: Կատարեք թարմացումներ՝ պարզապես նոր կոդը փոխանցելով գրադարանի ընթացիկ տարբերակով թղթապանակ: Տեղադրեք բոլոր անհրաժեշտ կոմունալ ծառայություններն անմիջապես հոսթ սերվերի վրա, որտեղ ևս 20 ծառայություններ են աշխատում:
Նախագիծը միշտ պետք է ունենա կախվածությունների հստակ հասկանալի ցանկ (կախվածություն ասելով նկատի ունեմ նաև շրջակա միջավայրը): Բոլոր կախվածությունները պետք է հստակորեն սահմանված և մեկուսացված լինեն:
Որպես օրինակ վերցնենք Կոմպոզիտոր и դոկեր.
Կոմպոզիտոր — փաթեթի կառավարիչ, որը թույլ է տալիս տեղադրել գրադարաններ PHP-ում: Կոմպոզիտորը թույլ է տալիս խստորեն կամ անկաշկանդ նշել տարբերակները և հստակորեն սահմանել դրանք: Սերվերում կարող են լինել 20 տարբեր նախագծեր, և յուրաքանչյուրը կունենա փաթեթների և գրադարանների անձնական ցուցակ, որոնք անկախ են մյուսից:
դոկեր — օգտակար ծրագիր, որը թույլ է տալիս սահմանել և մեկուսացնել այն միջավայրը, որտեղ կաշխատի հավելվածը: Համապատասխանաբար, ինչպես կոմպոզիտորի դեպքում, բայց ավելի մանրակրկիտ, մենք կարող ենք որոշել, թե ինչով է աշխատում հավելվածը։ Ընտրեք 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, որպեսզի այն ավելի արագ աշխատի արտադրության մեջ:
Իրականում, բոլոր տեղակայումները և կոդի հետ աշխատանքը պետք է լինեն գրեթե նույնական միջավայրում (խոսքը ֆիզիկական ապարատի մասին չէ): Բացի այդ, զարգացման ցանկացած աշխատակից պետք է կարողանա անհրաժեշտության դեպքում ծածկագիրը տեղակայել արտադրության մեջ, և ոչ թե հատուկ վերապատրաստված devops բաժինը, որը միայն հատուկ ուժի շնորհիվ կարող է հավելվածը արտադրություն բարձրացնել:
Docker-ը նույնպես օգնում է մեզ այս հարցում: Եթե պահպանվեն բոլոր նախորդ կետերը, ապա դոկերի օգտագործումը կբերի շրջակա միջավայրի տեղակայման գործընթացը ինչպես արտադրության, այնպես էլ տեղական մեքենայի վրա մեկ կամ երկու հրամաններ մուտքագրելու համար:
11. Տեղեկամատյաններ
Մենք գրում ենք տեղեկամատյաններ ֆայլերում և տվյալների բազաներում: Մենք չենք մաքրում ֆայլերը և տվյալների բազաները տեղեկամատյաններից: Եկեք ուղղակի գնենք կոշտ սկավառակ 9000 Peta բայթով, և դա լավ է:
Բոլոր տեղեկամատյանները պետք է դիտարկել որպես իրադարձությունների հոսք: Հավելվածն ինքնին չպետք է ներգրավվի տեղեկամատյանների մշակման մեջ: Տեղեկամատյանները պետք է դուրս բերվեն կա՛մ stdout-ին, կա՛մ ուղարկվեն այնպիսի արձանագրության միջոցով, ինչպիսին udp-ն է, որպեսզի տեղեկամատյանների հետ աշխատելը որևէ խնդիր չստեղծի հավելվածի համար: graylog-ը լավ է դրա համար: Graylog-ը ստանալով բոլոր տեղեկամատյանները udp-ի միջոցով (այս արձանագրությունը չի պահանջում փաթեթի հաջող ընդունման վերաբերյալ պատասխանի սպասել) ոչ մի կերպ չի խանգարում հավելվածին և զբաղվում է միայն տեղեկամատյանների կառուցվածքով և մշակմամբ: Նման մոտեցումներով աշխատելու համար կիրառման տրամաբանությունը չի փոխվում։
12. Կառավարման առաջադրանքներ
Տվյալները, տվյալների բազաները և այլն թարմացնելու համար օգտագործեք API-ում առանձին ստեղծված վերջնակետ, այն 2 անգամ անընդմեջ կատարելը կհանգեցնի ամեն ինչի կրկնօրինակմանը: Բայց դուք հիմար չեք, դուք երկու անգամ չեք սեղմի, և մեզ միգրացիա պետք չէ:
Վարչական բոլոր առաջադրանքները պետք է կատարվեն նույն միջավայրում, ինչ բոլոր ծածկագրերը, թողարկման մակարդակում: Այսինքն, եթե մեզ անհրաժեշտ է փոխել տվյալների բազայի կառուցվածքը, ապա մենք դա ձեռքով չենք անի՝ փոխելով սյունակների անունները և ավելացնելով նորերը տվյալների բազայի կառավարման որոշ վիզուալ գործիքների միջոցով։ Նման բաների համար մենք ստեղծում ենք առանձին սկրիպտներ՝ միգրացիաներ, որոնք ամենուր և բոլոր միջավայրերում կատարվում են նույն ձևով՝ ընդհանուր և հասկանալի արդյունքով։ Մնացած բոլոր առաջադրանքների համար, օրինակ՝ նախագիծը տվյալների լրացման համար, պետք է օգտագործվեն նմանատիպ մեթոդաբանություններ:
Իրականացման օրինակ PHP-ում, Laravel-ում, Laradock-ում, Docker-Compose-ում
Հ.Գ. Բոլոր օրինակները պատրաստվել են 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. Գործարկեք աշխատանքային տարածքի պատկերը: (Ձեր դեպքում, պատկերների ստեղծման համար որոշ ժամանակ կպահանջվի)
Workspace-ը հատուկ պատրաստված պատկեր է մշակողի անունից շրջանակի հետ աշխատելու համար:
Մենք մտնում ենք տարայի ներս՝ օգտագործելով
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-ի համար, իմ դեպքում դա այդպես է . (այստեղ ուղղորդման հղում է)
4. Եկեք գործարկենք:
Նախքան սկսելը, համոզվեք, որ ոչինչ կախված չէ 80 և 443 նավահանգիստներից:
docker-compose up -d nginx php-fpm
Այսպիսով, մեր նախագիծը բաղկացած է 3 առանձին ծառայություններից.
- nginx - վեբ սերվեր
- php-fpm - php վեբ սերվերից հարցումներ ստանալու համար
- աշխատանքային տարածք - php մշակողների համար
Այս պահին մենք հասել ենք նրան, որ ստեղծել ենք հավելված, որը համապատասխանում է 4-ից 12 միավորին, այն է՝
1. Codebase — ամբողջ կոդը գտնվում է մեկ պահոցում (փոքր նշում. կարող է ճիշտ լինել docker ավելացնել laravel նախագծի ներսում, բայց դա կարևոր չէ):
2. Կախվածություններ - Մեր բոլոր կախվածությունները հստակորեն գրված են application/composer.json-ում և յուրաքանչյուր կոնտեյների յուրաքանչյուր Dockerfile-ում:
3. Պահպանման ծառայություններ — Ծառայություններից յուրաքանչյուրը (php-fom, nignx, workpace) ապրում է իր կյանքով և կապված է դրսից, և մի ծառայության հետ աշխատելիս մյուսի վրա չի տուժի։
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-ի միջոցով՝ արհեստագործական գործիքի շնորհիվ ճիշտ այնպես, ինչպես կցանկանային 12 գործոն հավելվածի ստեղծողները:
Որպես օրինակ, ես ցույց կտամ, թե ինչպես են որոշ հրամաններ կատարվում:
Մենք մտնում ենք տարայի մեջ:
docker-compose exec workspace bash
php artisan list
Այժմ մենք կարող ենք օգտագործել ցանկացած հրաման: (Խնդրում ենք նկատի ունենալ, որ մենք չենք կարգավորել տվյալների բազան և քեշը, ուստի հրամանների կեսը ճիշտ չի կատարվի, քանի որ դրանք նախատեսված են քեշի և տվյալների բազայի հետ աշխատելու համար):
11: Կազմաձևերը և 12 թ. Կառուցել, ազատել, վազել
Ես ուզում էի այս մասը նվիրել Կապույտ-կանաչ տեղակայմանը, բայց պարզվեց, որ այն չափազանց ծավալուն է այս հոդվածի համար: Այս մասին առանձին հոդված կգրեմ։
Մի խոսքով, հայեցակարգը հիմնված է CI/CD համակարգերի վրա, ինչպիսիք են Jenkins и Gitlab CI. Երկուսում էլ կարող եք սահմանել որոշակի միջավայրի հետ կապված միջավայրի փոփոխականներ: Ըստ այդմ, այս իրավիճակում կկատարվի «գ» կետը Կոնֆիգուրացիաներ.
Եվ կետը Կառուցել, ազատել, վազել լուծվում է անվան հետ ներկառուցված ֆունկցիաներով Խողովակաշար.
Խողովակաշար թույլ է տալիս տեղակայման գործընթացը բաժանել բազմաթիվ փուլերի՝ ընդգծելով հավաքման, թողարկման և կատարման փուլերը: Նաև Pipeline-ում կարող եք ստեղծել կրկնօրինակներ և իսկապես ցանկացած բան: Սա անսահման ներուժ ունեցող գործիք է:
Դիմումի կոդը՝ հասցեով .
Այս պահոցը կլոնավորելիս մի մոռացեք նախաստորագրել ենթամոդուլը:
Հ.Գ.: Այս բոլոր մոտեցումները կարող են օգտագործվել ցանկացած այլ օգտակար և ծրագրավորման լեզուների հետ: Հիմնական բանը այն է, որ էությունը չի տարբերվում:
Source: www.habr.com