Մոտեցումը IaC (Ենթակառուցվածքը որպես կոդ) բաղկացած է ոչ միայն այն կոդից, որը պահվում է պահեստում, այլև մարդկանցից և գործընթացներից, որոնք շրջապատում են այս կոդը: Հնարավո՞ր է վերաօգտագործել մոտեցումները՝ սկսած ծրագրային ապահովման մշակումից մինչև ենթակառուցվածքների կառավարում և նկարագրություն: Լավ կլինի այս միտքը հիշել հոդվածը կարդալիս:
Սա իմ ձայնագրությունն է մասին .
Սլայդներ և տեսանյութեր
- Չոր վազք 2019-04-24
Ենթակառուցվածքը որպես բաշի պատմություն
Ենթադրենք, դուք գալիս եք նոր նախագծի, և նրանք ձեզ ասում են. «մենք ունենք Ենթակառուցվածքները `որպես ծածկագիր«. Իրականում ստացվում է Ենթակառուցվածքը որպես բաշի պատմություն կամ օրինակ Փաստաթղթեր որպես bash պատմություն. Սա շատ իրական իրավիճակ է, օրինակ, նման դեպք նկարագրել է Դենիս Լիսենկոն իր ելույթում Նա պատմեց, թե ինչպես են բաշի պատմությունից ստացել նախագծի համար համահունչ ենթակառուցվածք:
Որոշակի ցանկությամբ կարելի է ասել Ենթակառուցվածքը որպես բաշի պատմություն սա նման է կոդը.
- վերարտադրելիությունԴուք կարող եք վերցնել bash պատմությունը, այնտեղից գործարկել հրամանները և, ի դեպ, կարող եք ստանալ աշխատանքային կոնֆիգուրացիա որպես արդյունք:
- տարբերակումԴուք գիտեք, թե ովքեր են մտել և ինչ են արել, կրկին փաստ չէ, որ դա ձեզ կտանի աշխատանքային կոնֆիգուրացիայի ելքի մոտ:
- պատմությունըՊատմությունը, թե ով ինչ է արել: միայն դուք չեք կարողանա օգտագործել այն, եթե կորցնեք սերվերը:
Ինչ անել?
Ենթակառուցվածքները `որպես ծածկագիր
Նույնիսկ այնպիսի տարօրինակ դեպք, ինչպիսին Ենթակառուցվածքը որպես բաշի պատմություն դուք կարող եք քաշել այն ականջներից Ենթակառուցվածքները `որպես ծածկագիր, բայց երբ մենք ուզում ենք ավելի բարդ բան անել, քան հին լավ LAMP սերվերը, կգանք այն եզրակացության, որ այս կոդը պետք է ինչ-որ կերպ փոփոխել, փոխել, կատարելագործել։ Հաջորդիվ մենք կցանկանայինք դիտարկել միջև եղած զուգահեռները Ենթակառուցվածքները `որպես ծածկագիր և ծրագրային ապահովման մշակում։
ՉՈՐ
Պահպանման համակարգի զարգացման նախագծում կար ենթախնդիր Մենք թողարկում ենք նոր թողարկում, այն պետք է ներկայացվի հետագա փորձարկման համար: Առաջադրանքը չափազանց պարզ է.
- մուտք գործեք այստեղ ssh-ի միջոցով և կատարեք հրամանը:
- պատճենեք ֆայլը այնտեղ:
- շտկեք կոնֆիգուրն այստեղ:
- այնտեղ սկսեք ծառայությունը
- ...
- ՇԱՀՈՒՅԹ
Նկարագրված տրամաբանության համար bash-ն ավելի քան բավարար է, հատկապես նախագծի վաղ փուլերում, երբ այն նոր է սկսվում։ Սա , բայց ժամանակի ընթացքում նման բան տեղակայելու հարցումներ են լինում, բայց մի փոքր այլ: Առաջին բանը, որ գալիս է մտքին, դա copy-paste-ն է։ Եվ հիմա մենք արդեն ունենք երկու շատ նման սցենար, որոնք գրեթե նույն բանն են անում: Ժամանակի ընթացքում սցենարների թիվն աճեց, և մենք բախվեցինք այն փաստի հետ, որ կա որոշակի բիզնես տրամաբանություն տեղադրման տեղակայման համար, որը պետք է համաժամանակացվի տարբեր սցենարների միջև, սա բավականին բարդ է:
Պարզվում է, որ գոյություն ունի այնպիսի պրակտիկա, ինչպիսին է DRY (Do Not Repeat Yourself): Գաղափարը գոյություն ունեցող ծածկագիրը կրկին օգտագործելն է: Պարզ է թվում, բայց մենք անմիջապես չհասանք դրան: Մեր դեպքում դա սովորական գաղափար էր՝ անջատել կոնֆիգուրները սկրիպտներից: Նրանք. բիզնես տրամաբանությունը, թե ինչպես է տեղադրումը տեղակայվում առանձին, կոնֆիգուրացիաներ՝ առանձին:
SOLID CFM-ի համար
Ժամանակի ընթացքում նախագիծը մեծացավ և Անսիբլի ի հայտ գալն էր։ Նրա տեսքի հիմնական պատճառն այն է, որ թիմում փորձաքննություն կա, և այդ բաշը նախատեսված չէ բարդ տրամաբանության համար։ Անսիբլը նույնպես սկսեց բարդ տրամաբանություն պարունակել։ Որպեսզի բարդ տրամաբանությունը չվերածվի քաոսի, կան ծրագրային ապահովման մշակման մեջ կոդի կազմակերպման սկզբունքներ պինդ Նաև, օրինակ, Գրիգորի Պետրովը «Ինչու՞ է ՏՏ մասնագետին պետք անձնական բրենդ» զեկույցում բարձրացրել է այն հարցը, որ անձը նախագծված է այնպես, որ նրա համար ավելի հեշտ լինի աշխատել որոշ սոցիալական սուբյեկտների հետ, ծրագրային ապահովման մշակման մեջ դրանք. առարկաներ են. Եթե համադրենք այս երկու գաղափարները և շարունակենք զարգացնել դրանք, ապա կնկատենք, որ կարող ենք նաև օգտագործել պինդ հետագայում այս տրամաբանության պահպանումն ու փոփոխումը հեշտացնելու համար:
Միասնական պատասխանատվության սկզբունքը
Յուրաքանչյուր դասարան կատարում է միայն մեկ առաջադրանք:
Կարիք չկա խառնել ծածկագիրը և ստեղծել մոնոլիտ աստվածային սպագետտի հրեշներ: Ենթակառուցվածքը պետք է բաղկացած լինի պարզ աղյուսներից։ Ստացվում է, որ եթե Ansible խաղագիրքը բաժանեք փոքր կտորների, կարդացեք Ansible դերերը, ապա դրանք ավելի հեշտ է պահպանել:
Բաց փակ սկզբունքը
Բաց/փակ սկզբունք.
- Բաց ընդարձակման համար. նշանակում է, որ կազմակերպության վարքագիծը կարող է ընդլայնվել՝ ստեղծելով նոր միավորների տեսակներ:
- Փակ է փոփոխության համար. Կազմակերպության վարքագիծը ընդլայնելու արդյունքում չպետք է փոփոխություններ կատարվեն այդ միավորներն օգտագործող կոդի մեջ:
Սկզբում մենք տեղադրեցինք թեստային ենթակառուցվածքը վիրտուալ մեքենաների վրա, սակայն հաշվի առնելով այն հանգամանքը, որ տեղակայման բիզնես տրամաբանությունը առանձնացված էր իրականացումից, մենք առանց խնդիրների ավելացրինք roll out-ը baremetall-ում:
Լիսկովի փոխարինման սկզբունքը
Բարբարա Լիսկովի փոխարինման սկզբունքը. Ծրագրի օբյեկտները պետք է փոխարինելի լինեն իրենց ենթատիպերի օրինակներով՝ չփոխելով ծրագրի ճիշտ կատարումը
Եթե ավելի լայն նայեք, ապա դա որևէ կոնկրետ նախագծի առանձնահատկություն չէ, որը կարող է կիրառվել այնտեղ պինդ, ընդհանուր առմամբ խոսքը CFM-ի մասին է, օրինակ՝ մեկ այլ նախագծում անհրաժեշտ է տեղակայել տուփով Java հավելված տարբեր Java-ների, հավելվածների սերվերների, տվյալների բազաների, ՕՀ-ի և այլնի վրա։ Օգտագործելով այս օրինակը, ես կքննարկեմ հետագա սկզբունքները պինդ
Մեր դեպքում, ենթակառուցվածքի թիմի ներսում պայմանավորվածություն կա, որ եթե մենք տեղադրել ենք imbjava կամ oraclejava դերը, ապա ունենք java երկուական գործարկվող: Սա անհրաժեշտ է, քանի որ Վերին հոսքի դերերը կախված են այս վարքագծից, նրանք ակնկալում են java: Միևնույն ժամանակ, սա մեզ թույլ է տալիս փոխարինել Java-ի մեկ ներդրումը/տարբերակը մյուսով` առանց հավելվածի տեղակայման տրամաբանությունը փոխելու:
Խնդիրն այստեղ կայանում է նրանում, որ Ansible-ում դա անհնար է իրականացնել, ինչի արդյունքում թիմի ներսում որոշ պայմանավորվածություններ են հայտնվում։
Ինտերֆեյսի տարանջատման սկզբունքը
Ինտերֆեյսի բաժանման սկզբունքը. «Շատ հաճախորդի հատուկ ինտերֆեյսներ ավելի լավն են, քան մեկ ընդհանուր նշանակության ինտերֆեյսը:
Սկզբում մենք փորձեցինք հավելվածի տեղակայման ողջ փոփոխականությունը տեղադրել մեկ Ansible գրքի մեջ, բայց դժվար էր աջակցել, և այն մոտեցումը, երբ մենք ունենք արտաքին ինտերֆեյս, նշված է (հաճախորդը ակնկալում է պորտ 443), ապա ենթակառուցվածքը կարող է հավաքվել անհատից: աղյուսներ կոնկրետ իրականացման համար:
Կախվածության ինվերսիայի սկզբունքը
Կախվածության ինվերսիայի սկզբունքը. Ավելի բարձր մակարդակների մոդուլները չպետք է կախված լինեն ավելի ցածր մակարդակների մոդուլներից: Երկու տեսակի մոդուլները պետք է կախված լինեն աբստրակցիաներից: Աբստրակցիաները չպետք է կախված լինեն մանրամասներից: Մանրամասները պետք է կախված լինեն աբստրակցիաներից:
Այստեղ օրինակը հիմնված կլինի հակապատկերի վրա:
- Հաճախորդներից մեկը մասնավոր ամպ ուներ:
- Մենք պատվիրեցինք վիրտուալ մեքենաներ ամպի ներսում:
- Բայց ամպի բնույթի պատճառով հավելվածի տեղակայումը կապված էր այն հիպերվիզորի հետ, որի վրա էր VM-ը:
Նրանք. Բարձր մակարդակի հավելվածների տեղակայման տրամաբանությունը կախվածություններով հոսում էր դեպի հիպերվիզորի ավելի ցածր մակարդակներ, և դա նշանակում էր խնդիրներ այս տրամաբանությունը նորից օգտագործելիս: Մի արեք դա այսպես.
Փոխազդեցություն
Ենթակառուցվածքը որպես ծածկագիր ոչ միայն ծածկագրի, այլ նաև կոդի և մարդկանց միջև փոխհարաբերությունների, ենթակառուցվածքի մշակողների միջև փոխգործակցության մասին է:
Ավտոբուսի գործոն
Ենթադրենք, որ ձեր նախագծում ունեք Վասյա: Վասյան ամեն ինչ գիտի ձեր ենթակառուցվածքի մասին, ի՞նչ կլինի, եթե Վասյան հանկարծ անհետանա։ Սա շատ իրական իրավիճակ է, քանի որ նրան կարող էր ավտոբուս հարվածել։ Երբեմն դա տեղի է ունենում. Եթե դա տեղի ունենա, և կոդի, կառուցվածքի, դրա աշխատանքի, արտաքին տեսքի և գաղտնաբառերի մասին գիտելիքները չտարածվեն թիմում, ապա դուք կարող եք հանդիպել մի շարք տհաճ իրավիճակների: Այս ռիսկերը նվազագույնի հասցնելու և թիմում գիտելիքները բաշխելու համար կարող եք օգտագործել տարբեր մոտեցումներ
Զույգ մշակում
Դա նման չէ , որ ադմինները գարեջուր են խմել, փոխել գաղտնաբառերը և զույգ ծրագրավորման անալոգը։ Նրանք. երկու ինժեներ նստում են մեկ համակարգչի, մեկ ստեղնաշարի մոտ և սկսում են միասին կարգավորել ձեր ենթակառուցվածքը՝ տեղադրել սերվեր, գրել Ansible դեր և այլն: Հաճելի է հնչում, բայց մեզ մոտ չստացվեց: Բայց այս պրակտիկայի հատուկ դեպքերն աշխատեցին։ Գալիս է նոր աշխատակից, նրա մենթորը իր հետ միասին իրական գործ է ստանձնում, աշխատում ու փոխանցում գիտելիք։
Մեկ այլ հատուկ դեպք է միջադեպի զանգը: Խնդրի ժամանակ հավաքվում է հերթապահներից և ներգրավվածներից մի խումբ, նշանակվում է մեկ ղեկավար, ով կիսվում է իր էկրանով և բարձրաձայնում մտքի գնացքը։ Մյուս մասնակիցները հետևում են առաջնորդի մտքերին, լրտեսում են հնարքները վահանակից, ստուգում են, որ գրանցամատյանում որևէ տող բաց չեն թողել և նոր բաներ են իմանում համակարգի մասին: Այս մոտեցումն ավելի հաճախ աշխատեց, քան ոչ:
Կոդի ակնարկ
Սուբյեկտիվորեն ավելի արդյունավետ էր ենթակառուցվածքի մասին գիտելիքների տարածումը և այն, թե ինչպես է այն աշխատում՝ օգտագործելով կոդերի վերանայումը.
- Ենթակառուցվածքը նկարագրված է պահեստում առկա ծածկագրով:
- Փոփոխությունները տեղի են ունենում առանձին մասնաճյուղում:
- Միաձուլման հարցման ժամանակ դուք կարող եք տեսնել ենթակառուցվածքի փոփոխությունների դելտան:
Այստեղ ամենակարևորն այն էր, որ գրախոսները մեկ առ մեկ ընտրվում էին ըստ ժամանակացույցի, այսինքն. որոշ աստիճանի հավանականությամբ դուք կբարձրանաք նոր ենթակառուցվածքի մեջ:
կոդի ոճը
Ժամանակի ընթացքում վերանայումների ժամանակ սկսեցին վիճաբանություններ առաջանալ, քանի որ... Գրախոսներն ունեին իրենց ոճը, և գրախոսների հերթափոխը դրանք դասավորեց տարբեր ոճերով՝ 2 բացատ կամ 4, camelCase կամ snake_case: Սա միանգամից հնարավոր չեղավ իրականացնել։
- Առաջին գաղափարն այն էր, որ խորհուրդ տվեցին օգտագործել լինտեր, ի վերջո, բոլորը ինժեներ են, բոլորը խելացի են: Բայց տարբեր խմբագրիչներ, ՕՀ, հարմար չեն
- Սա վերածվեց բոտի, որը գրում էր թուլացման համար յուրաքանչյուր խնդրահարույց կատարման համար և կցում էր ալիքի ելքը: Բայց շատ դեպքերում կային ավելի կարևոր անելիքներ, և կոդը մնաց չֆիքսված:
Կանաչ շինարարության վարպետ
Ժամանակն անցնում է, և մենք եկել ենք այն եզրակացության, որ այն պարտավորությունները, որոնք չեն անցնում որոշակի թեստեր, չեն կարող թույլ տալ վարպետին: Voila! Մենք հայտնագործեցինք Green Build Master-ը, որը երկար ժամանակ կիրառվում էր ծրագրային ապահովման մշակման մեջ.
- Զարգացումը կատարվում է առանձին մասնաճյուղում։
- Այս թեմայում թեստեր են ընթանում:
- Եթե թեստերը ձախողվեն, կոդը այն չի վերածվի վարպետի:
Այս որոշումը կայացնելը շատ ցավալի էր, քանի որ... շատ հակասություններ առաջացրեց, բայց արժեր, քանի որ... Վերանայումները սկսեցին միաձուլման հարցումներ ստանալ՝ առանց ոճային տարբերությունների, և ժամանակի ընթացքում խնդրահարույց տարածքների թիվը սկսեց նվազել:
IaC թեստավորում
Բացի ոճի ստուգումից, դուք կարող եք օգտագործել այլ բաներ, օրինակ՝ ստուգելու համար, որ ձեր ենթակառուցվածքն իրականում կարող է տեղակայվել: Կամ ստուգեք, որ ենթակառուցվածքների փոփոխությունները չեն հանգեցնի փողի կորստի։ Ինչու՞ սա կարող է անհրաժեշտ լինել: Հարցը բարդ է և փիլիսոփայական, ավելի լավ է պատասխանել մի պատմությամբ, որ ինչ-որ կերպ Powershell-ում եղել է ավտոմատ սանդղակ, որը չի ստուգել սահմանային պայմանները => ստեղծվել են ավելի շատ VM, քան անհրաժեշտ էր => հաճախորդը ծախսել է ավելի շատ գումար, քան նախատեսված էր: Սա այնքան էլ հաճելի չէ, բայց միանգամայն հնարավոր կլիներ այս սխալը հայտնաբերել ավելի վաղ փուլերում:
Կարելի է հարցնել՝ ինչո՞ւ բարդ ենթակառուցվածքներն էլ ավելի բարդացնել։ Ենթակառուցվածքի թեստերը, ինչպես կոդի համար, չեն վերաբերում պարզեցմանը, այլ այն մասին, թե ինչպես պետք է աշխատի ձեր ենթակառուցվածքը:
IaC փորձարկման բուրգ
IaC թեստավորում. ստատիկ վերլուծություն
Եթե դուք միանգամից տեղակայեք ամբողջ ենթակառուցվածքը և ստուգեք, որ այն աշխատում է, կարող եք պարզել, որ դա շատ ժամանակ է պահանջում և շատ ժամանակ է պահանջում: Հետեւաբար, հիմքը պետք է լինի մի բան, որն արագ աշխատի, այն շատ է, և այն ծածկում է շատ պարզունակ վայրեր:
Բաշը բարդ է
Դիտարկենք մի չնչին օրինակ. ընտրեք բոլոր ֆայլերը ընթացիկ գրացուցակում և պատճենեք մեկ այլ վայրում: Առաջին բանը, որ գալիս է մտքին.
for i in * ; do
cp $i /some/path/$i.bak
doneԻսկ եթե ֆայլի անվան մեջ բացատ լինի: Դե, լավ, մենք խելացի ենք, մենք գիտենք, թե ինչպես օգտագործել չակերտները.
for i in * ; do cp "$i" "/some/path/$i.bak" ; doneԼավ արեցի՞ք: Ո՛չ։ Ինչ անել, եթե գրացուցակում ոչինչ չկա, այսինքն. գլոբբինգը չի աշխատի:
find . -type f -exec mv -v {} dst/{}.bak ;Լավ արեցի՞ք հիմա: Ոչ... Մոռացել եք, թե ինչ կարող է լինել ֆայլի անվան մեջ n.
touch x
mv x "$(printf "foonbar")"
find . -type f -print0 | xargs -0 mv -t /path/to/target-dirՍտատիկ վերլուծության գործիքներ
Նախորդ քայլի խնդիրը կարելի էր բացահայտել, երբ մոռանում էինք մեջբերումները, դրա համար բնության մեջ կան բազմաթիվ միջոցներ , ընդհանուր առմամբ, դրանք շատ են, և, ամենայն հավանականությամբ, դուք կարող եք ձեր IDE-ի տակ գլանափաթեթ գտնել:
Լեզու
Գործիք
ուժեղ հարվածել
սուտակ
Python
ածելի
IaC թեստավորում. միավորի թեստեր
Ինչպես տեսանք նախորդ օրինակից, լինտերները ամենազոր չեն և չեն կարող մատնանշել բոլոր խնդրահարույց ոլորտները: Ավելին, ծրագրային ապահովման մշակման փորձարկման հետ անալոգիայով մենք կարող ենք հիշել միավորի թեստերը: Այն, ինչ անմիջապես գալիս է մտքին, այն է , , , . Բայց ի՞նչ անել ansible-ի, շեֆ-խոհարարի, saltstack-ի և նրանց նմանների հետ:
Հենց սկզբում խոսեցինք պինդ և որ մեր ենթակառուցվածքը պետք է բաղկացած լինի փոքր աղյուսներից: Նրանց ժամանակը եկել է։
- Ենթակառուցվածքը բաժանված է փոքր աղյուսների, օրինակ՝ Ansible դերերի։
- Գործարկված է ինչ-որ միջավայր, լինի դա դոկեր, թե VM:
- Մենք կիրառում ենք մեր Ansible դերը այս թեստային միջավայրում:
- Մենք ստուգում ենք, որ ամեն ինչ աշխատեց այնպես, ինչպես մենք ակնկալում էինք (մենք փորձարկում ենք):
- Մենք որոշում ենք լավ, թե ոչ լավ:
IaC թեստավորում. միավորի փորձարկման գործիքներ
Հարց, որո՞նք են թեստերը CFM-ի համար: Դուք կարող եք պարզապես գործարկել սցենարը, կամ կարող եք օգտագործել պատրաստի լուծումներ դրա համար.
CFM
Գործիք
Հղիություն
Chef
Chef
աղի դիզել
Օրինակ testinfra-ի համար՝ ստուգելով, որ օգտվողները test1, test2 գոյություն ունեն և գտնվում են խմբում sshusers:
def test_default_users(host):
users = ['test1', 'test2' ]
for login in users:
assert host.user(login).exists
assert 'sshusers' in host.user(login).groupsԻ՞նչ ընտրել: Հարցը բարդ է և երկիմաստ, ահա 2018-2019 թվականների համար github-ի նախագծերի փոփոխությունների օրինակ.
IaC փորձարկման շրջանակներ
Հարց է առաջանում՝ ինչպե՞ս հավաքել այդ ամենը և գործարկել։ Կարող է եթե կան բավարար թվով ինժեներներ. Կամ կարող եք վերցնել պատրաստի լուծումներ, չնայած դրանցից շատերը չկան.
CFM
Գործիք
Հղիություն
Chef
Terraform
Github-ում 2018-2019 թվականների նախագծերի փոփոխությունների օրինակ.
Մոլեկուլ ընդդեմ. Փորձարկման խոհանոց
Սկզբում մենք :
- Զուգահեռաբար ստեղծեք VM:
- Կիրառել Ansible դերերը:
- Գործարկել ստուգումը:
25-35 դերերի համար այն աշխատել է 40-70 րոպե, որը երկար էր։
Հաջորդ քայլը jenkins/docker/ansible/մոլեկուլի անցումն էր: Իդիոլոգիապես ամեն ինչ նույնն է
- Լինտ խաղային գրքեր.
- Հերթագրեք դերերը.
- Գործարկման կոնտեյներ
- Կիրառել Ansible դերերը:
- Գործարկել testinfra-ն:
- Ստուգեք անզորությունը.
40 դերերի համար լինզինգը և մեկ տասնյակի համար թեստերը սկսեցին տևել մոտ 15 րոպե:
Ինչ ընտրել, կախված է բազմաթիվ գործոններից, ինչպիսիք են օգտագործվող կույտը, թիմի փորձը և այլն: այստեղ յուրաքանչյուրն ինքն է որոշում, թե ինչպես փակել Unit թեստավորման հարցը
IaC թեստավորում. Ինտեգրման թեստեր
Ենթակառուցվածքի փորձարկման բուրգի հաջորդ քայլը լինելու են ինտեգրացիոն թեստերը: Դրանք նման են միավորի թեստերին.
- Ենթակառուցվածքը բաժանված է փոքր աղյուսների, օրինակ՝ Ansible դերերի։
- Գործարկված է ինչ-որ միջավայր, լինի դա դոկեր, թե VM:
- Այս թեստային միջավայրի համար դիմեք շատ Հասանելի դերեր.
- Մենք ստուգում ենք, որ ամեն ինչ աշխատեց այնպես, ինչպես մենք ակնկալում էինք (մենք փորձարկում ենք):
- Մենք որոշում ենք լավ, թե ոչ լավ:
Կոպիտ ասած, մենք չենք ստուգում համակարգի առանձին տարրի աշխատանքը, ինչպես միավորի թեստերում, մենք ստուգում ենք, թե ինչպես է սերվերը կազմաձևված որպես ամբողջություն:
IaC թեստավորում. վերջից մինչև վերջ թեստեր
Բուրգի գագաթին մեզ դիմավորում են End to End թեստերը: Նրանք. Մենք չենք ստուգում առանձին սերվերի, առանձին սկրիպտի կամ մեր ենթակառուցվածքի առանձին աղյուսի աշխատանքը: Մենք ստուգում ենք, որ շատ սերվերներ միացված են միասին, մեր ենթակառուցվածքն աշխատում է այնպես, ինչպես մենք ակնկալում ենք: Ցավոք, ես երբեք չեմ տեսել պատրաստի տուփով լուծումներ, հավանաբար այն պատճառով, որ... Ենթակառուցվածքը հաճախ եզակի է և դժվար է ձևավորել և ստեղծել փորձարկման շրջանակ: Արդյունքում յուրաքանչյուրն իր լուծումներն է ստեղծում։ Պահանջ կա, բայց պատասխան չկա. Հետևաբար, ես ձեզ կասեմ, թե ինչ կա, որպեսզի ուրիշներին մղեմ առողջ մտքերի կամ քիթս քսեմ այն բանի համար, որ ամեն ինչ հորինված է մեզանից առաջ:
Հարուստ պատմություն ունեցող նախագիծ. Այն օգտագործվում է խոշոր կազմակերպություններում, և հավանաբար ձեզանից յուրաքանչյուրն անուղղակիորեն խաչվել է դրա հետ: Հավելվածն աջակցում է բազմաթիվ տվյալների բազաների, ինտեգրումների և այլնի: Իմանալով, թե ինչպիսին կարող է լինել ենթակառուցվածքը, դա շատ docker-compose ֆայլեր են, և իմանալ, թե որ թեստերը որ միջավայրում պետք է գործարկել Jenkins-ը:
Այս սխեման գործել է բավականին երկար, մինչև շրջանակում մենք չենք փորձել սա փոխանցել Openshift-ին: Կոնտեյներները մնում են նույնը, բայց գործարկման միջավայրը փոխվել է (բարև DRY կրկին):
Հետազոտության գաղափարն ավելի հեռուն գնաց, և openshift-ում նրանք գտան այնպիսի բան, ինչպիսին է APB (Ansible Playbook Bundle), որը թույլ է տալիս հավաքել գիտելիքները, թե ինչպես կարելի է ենթակառուցվածքը տեղակայել կոնտեյների մեջ: Նրանք. կա ենթակառուցվածքը տեղակայելու վերաբերյալ գիտելիքների կրկնվող, փորձարկվող կետ:
Այս ամենը լավ էր հնչում, մինչև որ մենք հանդիպեցինք տարասեռ ենթակառուցվածքի. մեզ Windows-ը պետք էր թեստերի համար: Արդյունքում՝ ինչ, որտեղ, ինչպես տեղակայել և փորձարկել գիտելիքը ջենկիններում է:
Եզրափակում
Ենթակառուցվածքը, ինչպես կոդն է
- Կոդը պահեստում:
- Մարդկային փոխազդեցություն.
- Ենթակառուցվածքի փորձարկում.
հղումներ
- Չոր վազք 2019-04-24
- &
Source: www.habr.com