Մոտենում էր Նոր տարին։ Ամբողջ երկրում երեխաներն արդեն նամակներ էին ուղարկել Ձմեռ պապին կամ նվերներ էին պատրաստել իրենց համար, և նրանց գլխավոր կատարողը, խոշոր մանրածախ վաճառողներից մեկը, պատրաստվում էր վաճառքի ապոթեոզին: Դեկտեմբերին նրա տվյալների կենտրոնի բեռը մի քանի անգամ ավելանում է։ Ուստի ընկերությունը որոշել է արդիականացնել տվյալների կենտրոնը և շահագործման հանձնել մի քանի տասնյակ նոր սերվերներ ծառայության ժամկետի ավարտին հասնող սարքավորումների փոխարեն։ Սա ավարտում է հեքիաթը պտտվող ձյան փաթիլների ֆոնին, և սկսվում է թրիլլերը:
Սարքավորումը տեղ է հասել վաճառքի գագաթնակետից մի քանի ամիս առաջ: Գործառնությունների ծառայությունը, իհարկե, գիտի, թե ինչպես և ինչ պետք է կարգավորել սերվերների վրա՝ դրանք արտադրական միջավայր բերելու համար: Բայց մեզ անհրաժեշտ էր դա ավտոմատացնել և վերացնել մարդկային գործոնը: Բացի այդ, սերվերները փոխարինվել են մինչև ընկերության համար կարևոր SAP համակարգերի միգրացիան:
Նոր սերվերների գործարկումը խստորեն կապված էր վերջնաժամկետի հետ: Իսկ այն տեղափոխելը նշանակում էր վտանգել թե՛ մեկ միլիարդ նվերների առաքումը, թե՛ համակարգերի միգրացիան: Նույնիսկ հայր Ֆրոստից և Ձմեռ պապից բաղկացած թիմը չկարողացավ փոխել ամսաթիվը. դուք կարող եք փոխանցել SAP համակարգը պահեստի կառավարման համար միայն տարին մեկ անգամ: Դեկտեմբերի 31-ից հունվարի 1-ը մանրածախ վաճառողի հսկայական պահեստները՝ ընդհանուր առմամբ 20 ֆուտբոլի դաշտի չափով, դադարեցնում են իրենց աշխատանքը 15 ժամով։ Եվ սա համակարգը տեղափոխելու միակ ժամանակահատվածն է։ Սերվերներ ներկայացնելիս մենք սխալվելու տեղ չունեինք:
Թույլ տվեք հստակ ասել. իմ պատմությունը արտացոլում է գործիքները և կազմաձևման կառավարման գործընթացը, որն օգտագործում է մեր թիմը:
Կազմաձևման կառավարման համալիրը բաղկացած է մի քանի մակարդակներից: Հիմնական բաղադրիչը CMS համակարգն է: Արդյունաբերական շահագործման դեպքում մակարդակներից մեկի բացակայությունը անխուսափելիորեն կհանգեցներ տհաճ հրաշքների:
OS տեղադրման կառավարում
Առաջին մակարդակը ֆիզիկական և վիրտուալ սերվերների վրա օպերացիոն համակարգերի տեղադրման կառավարման համակարգ է: Այն ստեղծում է ՕՀ-ի հիմնական կոնֆիգուրացիաներ՝ վերացնելով մարդկային գործոնը։
Օգտագործելով այս համակարգը, մենք ստացանք ստանդարտ սերվերի օրինակներ ՕՀ-ով, որոնք հարմար են հետագա ավտոմատացման համար: «Հորդառատ» ժամանակ նրանք ստացել են տեղական օգտագործողների և հանրային SSH ստեղների նվազագույն փաթեթ, ինչպես նաև OS-ի հետևողական կոնֆիգուրացիա: Մենք երաշխավորված էինք կառավարել սերվերները CMS-ի միջոցով և վստահ էինք, որ «ներքևում» OS մակարդակում անակնկալներ չեն եղել:
Տեղադրման կառավարման համակարգի «առավելագույն» խնդիրն է ավտոմատ կերպով կարգավորել սերվերները BIOS/Firmware մակարդակից դեպի ՕՀ: Այստեղ շատ բան կախված է սարքավորումներից և տեղադրման խնդիրներից: Տարասեռ սարքավորումների համար կարող եք հաշվի առնել . Եթե ամբողջ սարքավորումը մեկ մատակարարից է, ապա հաճախ ավելի հարմար է օգտագործել պատրաստի կառավարման գործիքները (օրինակ՝ HP ILO Amplifier, DELL OpenManage և այլն):
Ֆիզիկական սերվերների վրա ՕՀ-ն տեղադրելու համար մենք օգտագործեցինք հայտնի Cobbler-ը, որը սահմանում է օպերացիոն ծառայության հետ համաձայնեցված տեղադրման պրոֆիլների մի շարք: Ենթակառուցվածքին նոր սերվեր ավելացնելիս ինժեները սերվերի MAC հասցեն կապեց Cobbler-ի պահանջվող պրոֆիլին: Առաջին անգամ ցանցով բեռնելիս սերվերը ստացել է ժամանակավոր հասցե և թարմ ՕՀ: Այնուհետև այն փոխանցվեց թիրախային VLAN/IP հասցեին և շարունակեց աշխատանքը այնտեղ: Այո, VLAN-ի փոփոխությունը ժամանակ է պահանջում և պահանջում է համակարգում, սակայն այն լրացուցիչ պաշտպանություն է ապահովում սերվերի պատահական տեղադրումից արտադրական միջավայրում:
Մենք ստեղծեցինք վիրտուալ սերվերներ HashiСorp Packer-ի միջոցով պատրաստված կաղապարների հիման վրա: Պատճառը նույնն էր՝ կանխել հնարավոր մարդկային սխալները ՕՀ-ի տեղադրման ժամանակ։ Բայց, ի տարբերություն ֆիզիկական սերվերների, Packer-ը վերացնում է PXE-ի, ցանցի բեռնման և VLAN-ի փոփոխությունների անհրաժեշտությունը: Սա հեշտացրել և պարզեցրել է վիրտուալ սերվերների ստեղծումը:
Բրինձ. 1. Օպերացիոն համակարգերի տեղադրման կառավարում.
Գաղտնիքների կառավարում
Ցանկացած կոնֆիգուրացիայի կառավարման համակարգ պարունակում է տվյալներ, որոնք պետք է թաքցվեն սովորական օգտվողներից, սակայն անհրաժեշտ են համակարգերը պատրաստելու համար: Սրանք գաղտնաբառեր են տեղական օգտատերերի և սպասարկման հաշիվների համար, վկայականի բանալիներ, տարբեր API նշաններ և այլն: Դրանք սովորաբար կոչվում են «գաղտնիքներ»:
Եթե դուք ի սկզբանե չեք որոշել, թե որտեղ և ինչպես պահել այդ գաղտնիքները, ապա, կախված տեղեկատվական անվտանգության պահանջների ծանրությունից, հավանական են պահպանման հետևյալ մեթոդները.
- ուղղակիորեն կազմաձևման կառավարման կոդում կամ պահեստի ֆայլերում.
- մասնագիտացված կոնֆիգուրացիայի կառավարման գործիքներում (օրինակ, Ansible Vault);
- CI/CD համակարգերում (Jenkins/TeamCity/GitLab/և այլն) կամ կոնֆիգուրացիայի կառավարման համակարգերում (Ansible Tower/Ansible AWX);
- գաղտնիքները կարող են փոխանցվել նաև «ձեռքով»: Օրինակ, դրանք դրված են նշված վայրում, այնուհետև դրանք օգտագործվում են կազմաձևման կառավարման համակարգերի կողմից.
- վերը նշվածների տարբեր համակցություններ:
Յուրաքանչյուր մեթոդ ունի իր սեփական թերությունները: Հիմնականը գաղտնիքների հասանելիության քաղաքականության բացակայությունն է. անհնար է կամ դժվար է որոշել, թե ով կարող է օգտագործել որոշակի գաղտնիքներ: Մեկ այլ թերություն է մուտքի աուդիտի բացակայությունը և լիարժեք կյանքի ցիկլը: Ինչպե՞ս արագ փոխարինել, օրինակ, հանրային բանալին, որը գրված է կոդում և մի շարք հարակից համակարգերում:
Մենք օգտագործել ենք HashiCorp Vault կենտրոնացված գաղտնի պահեստը: Սա մեզ թույլ տվեց.
- պահեք գաղտնիքները: Դրանք գաղտնագրված են, և նույնիսկ եթե ինչ-որ մեկը մուտք ստանա Vault տվյալների բազա (օրինակ՝ վերականգնելով այն կրկնօրինակից), նրանք չեն կարողանա կարդալ այնտեղ պահված գաղտնիքները.
- կազմակերպել գաղտնիքների հասանելիության քաղաքականություն: Օգտագործողների և հավելվածների համար հասանելի են միայն նրանց «հատկացված» գաղտնիքները.
- աուդիտի հասանելիություն գաղտնիքներին. Գաղտնիքներով ցանկացած գործողություն գրանցվում է Vault-ի աուդիտի մատյանում.
- կազմակերպել գաղտնիքների հետ աշխատելու լիարժեք «կյանքի ցիկլ»: Դրանք կարող են ստեղծվել, չեղյալ համարվել, ժամկետանց ժամկետ սահմանել և այլն։
- հեշտ է ինտեգրվել այլ համակարգերի հետ, որոնք գաղտնիքների հասանելիության կարիք ունեն.
- և նաև օգտագործել ծայրից ծայր կոդավորում, ՕՀ-ի և տվյալների բազայի միանգամյա գաղտնաբառեր, լիազորված կենտրոնների վկայագրեր և այլն:
Այժմ եկեք անցնենք կենտրոնական նույնականացման և թույլտվության համակարգին: Դա հնարավոր էր անել առանց դրա, բայց շատ հարակից համակարգերում օգտատերերին կառավարելը չափազանց աննշան է: Մենք կարգավորել ենք նույնականացումը և թույլտվությունը LDAP ծառայության միջոցով: Հակառակ դեպքում, Vault-ը ստիպված կլինի անընդհատ թողարկել և հետևել օգտատերերի վավերացման նշաններին: Իսկ օգտատերերի ջնջումն ու ավելացումը կվերածվի հարցման.
Մենք մեր համակարգին ավելացնում ենք ևս մեկ մակարդակ՝ գաղտնիքների կառավարում և կենտրոնական նույնականացում/լիազորում.
Բրինձ. 2. Գաղտնիքների կառավարում.
Կազմաձևման կառավարում
Մենք հասանք հիմքին՝ CMS համակարգին: Մեր դեպքում սա Ansible-ի և Red Hat Ansible AWX-ի համադրություն է:
Ansible-ի փոխարեն կարող են օգտագործվել Chef, Puppet, SaltStack-ը: Մենք ընտրել ենք Ansible-ը մի քանի չափանիշների հիման վրա:
- Նախ, դա բազմակողմանիություն է: Կառավարման համար պատրաստի մոդուլների հավաքածու . Եվ եթե դա բավարար չէ, կարող եք որոնել GitHub-ում և Galaxy-ում:
- Երկրորդ, կարիք չկա կառավարվող սարքավորումների վրա գործակալներ տեղադրել և աջակցել, ապացուցել, որ դրանք չեն խանգարում բեռին և հաստատել «էջանիշների» բացակայությունը:
- Երրորդ, Ansible-ն ունի մուտքի ցածր խոչընդոտ: Իրավասու ինժեները աշխատանքային գրքույկ կգրի բառացիորեն արտադրանքի հետ աշխատելու առաջին օրը:
Բայց միայն Անսիբլը արտադրական միջավայրում մեզ բավարար չէր։ Հակառակ դեպքում, բազմաթիվ խնդիրներ կառաջանան մուտքի սահմանափակման և ադմինիստրատորների գործողությունների աուդիտի հետ կապված: Ինչպե՞ս սահմանափակել մուտքը: Ի վերջո, անհրաժեշտ էր, որ յուրաքանչյուր բաժին կառավարեր (կարդացեք՝ գործարկել Ansible playbook-ը) սերվերների «սեփական» փաթեթը: Ինչպե՞ս թույլատրել միայն որոշ աշխատակիցների գործարկել հատուկ Ansible գրքույկներ: Կամ ինչպե՞ս հետևել, թե ով է գործարկել գրքույկը՝ առանց Ansible-ի աշխատող սերվերների և սարքավորումների վրա տեղային մեծ գիտելիքներ տեղադրելու:
Նման հարցերի առյուծի բաժինը լուծում է Red Hat-ը , կամ նրա բաց կոդով հոսանքին հակառակ նախագիծը . Այդ իսկ պատճառով մենք այն նախընտրեցինք հաճախորդի համար։
Եվ ևս մեկ հպում մեր CMS համակարգի դիմանկարին: Ansible playbook-ը պետք է պահվի կոդերի պահեստի կառավարման համակարգերում: Մենք ունենք այն .
Այսպիսով, կոնֆիգուրացիաներն իրենք են կառավարվում Ansible/Ansible AWX/GitLab-ի համակցությամբ (տես Նկար 3): Իհարկե, AWX/GitLab-ը ինտեգրված է նույնականացման մեկ համակարգով, իսկ Ansible playbook-ը ինտեգրված է HashiCorp Vault-ի հետ: Կազմաձևերը արտադրական միջավայր են մտնում միայն Ansible AWX-ի միջոցով, որում նշված են բոլոր «խաղի կանոնները».
Բրինձ. 3. Կազմաձևման կառավարում:
Թեստի կառավարում
Մեր կոնֆիգուրացիան ներկայացված է ծածկագրի տեսքով: Հետեւաբար, մենք ստիպված ենք խաղալ նույն կանոններով, ինչ ծրագրային ապահովման մշակողները: Մեզ անհրաժեշտ էր կազմակերպել մշակման գործընթացները, շարունակական թեստավորումը, կոնֆիգուրացիայի կոդի առաքումը և կիրառումը արտադրության սերվերներին:
Եթե դա անմիջապես չկատարվի, ապա կազմաձևման համար գրված դերերը կամ կդադարեն օժանդակվել և փոփոխվել, կամ կդադարեն գործարկվել արտադրության մեջ: Այս ցավի բուժումը հայտնի է, և այն իրեն ապացուցել է այս նախագծում.
- յուրաքանչյուր դեր ծածկված է միավորի թեստերով.
- թեստերն ավտոմատ կերպով գործարկվում են, երբ կոնֆիգուրացիաները կառավարող կոդի մեջ որևէ փոփոխություն կա.
- Կազմաձևման կառավարման կոդի փոփոխությունները թողարկվում են արտադրական միջավայր միայն բոլոր թեստերը և կոդի վերանայումը հաջողությամբ անցնելուց հետո:
Կոդի մշակումը և կազմաձևման կառավարումը դարձել են ավելի հանգիստ և կանխատեսելի: Շարունակական թեստավորում կազմակերպելու համար մենք օգտագործեցինք GitLab CI/CD գործիքակազմը և վերցրեցինք .
Ամեն անգամ, երբ կոնֆիգուրացիայի կառավարման կոդի մեջ փոփոխություն է տեղի ունենում, GitLab CI/CD-ն կանչում է Molecule-ը.
- այն ստուգում է կոդի շարահյուսությունը,
- բարձրացնում է Docker կոնտեյները,
- կիրառում է փոփոխված կոդը ստեղծված կոնտեյների վրա,
- ստուգում է դերը անզորության համար և անցկացնում է այս կոդի թեստերը (այստեղ մանրակրկիտությունը կարևոր դերի մակարդակի վրա է, տես նկ. 4):
Մենք կոնֆիգուրացիաներ ենք փոխանցել արտադրական միջավայրին՝ օգտագործելով Ansible AWX: Գործողությունների ինժեներները կիրառեցին կոնֆիգուրացիայի փոփոխությունները նախապես սահմանված ձևանմուշների միջոցով: AWX-ն ինքնուրույն «պահանջել» է կոդի վերջին տարբերակը GitLab-ի գլխավոր մասնաճյուղից ամեն անգամ, երբ այն օգտագործվել է: Այս կերպ մենք բացառեցինք չստուգված կամ հնացած կոդի օգտագործումը արտադրական միջավայրում: Բնականաբար, ծածկագիրը գլխավոր մասնաճյուղ է մտել միայն թեստավորումից, վերանայումից և հաստատումից հետո։
Բրինձ. 4. GitLab CI/CD-ում դերերի ավտոմատ փորձարկում:
Խնդիր կա նաև արտադրական համակարգերի շահագործման հետ կապված։ Իրական կյանքում շատ դժվար է միայն CMS կոդի միջոցով կոնֆիգուրացիայի փոփոխություններ կատարել: Արտակարգ իրավիճակներ են առաջանում, երբ ինժեները պետք է փոխի կոնֆիգուրացիան «այստեղ և հիմա»՝ չսպասելով կոդի խմբագրման, փորձարկման, հաստատման և այլն:
Արդյունքում, ձեռքով փոփոխությունների պատճառով, նույն տեսակի սարքավորումների կոնֆիգուրացիայի մեջ անհամապատասխանություններ են հայտնվում (օրինակ, sysctl կարգավորումները տարբեր կերպ են կազմաձևվում HA կլաստերային հանգույցներում): Կամ սարքավորման իրական կոնֆիգուրացիան տարբերվում է CMS կոդում նշվածից:
Հետևաբար, ի լրումն շարունակական փորձարկումների, մենք ստուգում ենք արտադրական միջավայրերը կազմաձևման անհամապատասխանությունների համար: Մենք ընտրեցինք ամենապարզ տարբերակը՝ գործարկել CMS-ի կազմաձևման կոդը «չոր գործարկում» ռեժիմով, այսինքն՝ առանց փոփոխություններ կիրառելու, բայց պլանավորված և իրական կազմաձևման միջև բոլոր անհամապատասխանությունների ծանուցմամբ: Մենք դա իրականացրել ենք՝ պարբերաբար գործարկելով բոլոր Ansible գրքույկները՝ «—ստուգել» տարբերակով արտադրական սերվերների վրա: Ինչպես միշտ, Ansible AWX-ը պատասխանատու է խաղագիրքը գործարկելու և թարմացնելու համար (տես Նկար 5):
Բրինձ. 5. Ստուգում է Ansible AWX-ում կազմաձևման անհամապատասխանությունները:
Ստուգումներից հետո AWX-ը անհամապատասխանության մասին հաղորդում է ուղարկում ադմինիստրատորներին: Նրանք ուսումնասիրում են խնդրահարույց կոնֆիգուրացիան, այնուհետև այն ուղղում ճշգրտված գրքույկների միջոցով: Ահա թե ինչպես ենք մենք պահպանում կոնֆիգուրացիան արտադրական միջավայրում, և CMS-ը միշտ թարմացված է և համաժամանակացված: Սա վերացնում է տհաճ «հրաշքները», երբ CMS կոդը օգտագործվում է «արտադրական» սերվերների վրա:
Այժմ մենք ունենք կարևոր փորձարկման շերտ, որը բաղկացած է Ansible AWX/GitLab/Molecule-ից (Նկար 6):
Բրինձ. 6. Թեստի կառավարում.
Դժվա՞ր: Ես չեմ վիճում։ Բայց կոնֆիգուրացիայի կառավարման նման համալիրը դարձել է սերվերի կազմաձևման ավտոմատացման հետ կապված բազմաթիվ հարցերի համապարփակ պատասխան: Այժմ մանրածախ վաճառողի ստանդարտ սերվերները միշտ ունեն խիստ սահմանված կոնֆիգուրացիա: CMS-ը, ի տարբերություն ինժեների, չի մոռանա ավելացնել անհրաժեշտ կարգավորումները, ստեղծել օգտվողներ և կատարել տասնյակ կամ հարյուրավոր պահանջվող կարգավորումներ:
Այսօր սերվերների և միջավայրերի կարգավորումներում «գաղտնի գիտելիք» չկա: Բոլոր անհրաժեշտ հատկանիշները արտացոլված են խաղատախտակում: Այլևս ոչ մի ստեղծագործություն և անորոշ հրահանգներ.Տեղադրեք այն սովորական Oracle-ի պես, բայց դուք պետք է նշեք մի քանի sysctl կարգավորում և ավելացնեք անհրաժեշտ UID-ով օգտվողներ: Գործող տղերքին հարցրեք, գիտեն.
Կազմաձևման անհամապատասխանությունները հայտնաբերելու և դրանք ակտիվորեն շտկելու ունակությունն ապահովում է մտքի խաղաղություն: Առանց կոնֆիգուրացիայի կառավարման համակարգի, սա սովորաբար տարբեր տեսք ունի: Խնդիրները կուտակվում են այնքան ժամանակ, մինչև մի օր «կրակեն» արտադրության մեջ։ Այնուհետև անցկացվում է ամփոփագիր, կոնֆիգուրացիաները ստուգվում և ուղղվում են: Եվ ցիկլը նորից կրկնվում է
Եվ իհարկե, մենք արագացրել ենք սերվերների գործարկումը մի քանի օրից մինչև ժամ:
Դե, հենց Ամանորի նախօրեին, երբ երեխաները ուրախությամբ բացում էին նվերները, իսկ մեծահասակները ցանկություններ էին հայտնում հնչյունների ժամանակ, մեր ինժեներները SAP համակարգը տեղափոխեցին նոր սերվերներ: Նույնիսկ Ձմեռ պապը կասի, որ լավագույն հրաշքները լավ պատրաստվածներն են։
Հ.Գ. Մեր թիմը հաճախ հանդիպում է այն փաստի, որ հաճախորդները ցանկանում են հնարավորինս պարզ լուծել կոնֆիգուրացիայի կառավարման խնդիրները: Իդեալում, ասես կախարդությամբ - մեկ գործիքով: Բայց կյանքում ամեն ինչ ավելի բարդ է (այո, արծաթե փամփուշտները կրկին չեն առաքվել). դուք պետք է ստեղծեք մի ամբողջ գործընթաց՝ օգտագործելով հաճախորդների թիմի համար հարմար գործիքներ:
Հեղինակ՝ Սերգեյ Արտեմով, բաժնի ճարտարապետ «Jet Infosystems»
Source: www.habr.com