Շրջակա միջավայրի արբանյակային տվյալների տեղեկատվական ազգային ծառայությունը (NESDIS) 35%-ով նվազեցրել է Red Hat Enterprise Linux-ի (RHEL) կոնֆիգուրացիայի կառավարման ծախսերը՝ տիկնիկային ձեռնարկությունից Ansible Tower տեղափոխվելով: Այս «ինչպես մենք դա արեցինք» տեսանյութում համակարգերի ինժեներ Մայքլ Ռաուն բացատրում է այս միգրացիայի դեպքը՝ կիսվելով օգտակար խորհուրդներով և դասերով, որոնք քաղված են մի SCM-ից մյուսը տեղափոխվելուց:
Այս տեսանյութից դուք կսովորեք.
- ինչպես հիմնավորել տնօրինությանը Տիկնիկային ձեռնարկությունից Ansible Tower-ին անցնելու իրագործելիությունը.
- ինչ ռազմավարություններ օգտագործել՝ անցումը հնարավորինս սահուն դարձնելու համար.
- խորհուրդներ PE-ի դրսևորումները Ansible Playbook-ում վերծանելու համար;
- Ansible Tower-ի օպտիմալ տեղադրման վերաբերյալ առաջարկություններ.
Բարև բոլորին, իմ անունը Մայքլ Ռաուն է, ես ActioNet-ի համակարգերի ավագ ինժեներ եմ, որն աշխատում է Օվկիանոսային և մթնոլորտային ազգային վարչության (NOAA) NESDIS ծառայության համար: Այսօր մենք կխոսենք լարերի կտրման մասին՝ Տիկնիկային Enterprise-ից Ansible Tower տեղափոխվելու իմ սեփական փորձը: Այս շնորհանդեսի թեման է «նայել իմ սպիներին», որոնք մնացել են տարվա սկզբին այս անցում կատարելուց հետո: Ես ուզում եմ կիսվել այն ամենով, ինչ սովորել եմ այս գործընթացի ընթացքում: Այսպիսով, երբ դուք ստանձնում եք նման բան, օգտագործելով իմ փորձը, կարող եք անցում կատարել առանց որևէ լրացուցիչ աշխատանքի:
Ansible Fest-ի յուրաքանչյուր շնորհանդեսի սկզբում տեսնում եք սրա նման սլայդներ: Այս սլայդը ուրվագծում է իմ ընկերության ավտոմատացման պատմությունը: Ես նոր չեմ այս հարցում, քանի որ ես օգտագործում եմ Puppet/Puppet Enterprise-ը 2007 թվականից: Ես սկսեցի աշխատել Ansible-ի հետ 2016 թվականին, և, ինչպես այս ապրանքի շատ այլ օգտվողներ, ինձ գրավեց հրամանի տողի և պարզ սցենարների (playbooks) օգտագործմամբ «հնարքների» հնարավորությունը: 2017 թվականի վերջում ես դիմեցի իմ ղեկավարությանը Անսիբլ Թաուեր տեղափոխվելու լուրջ պատճառների մասին: Մեկ րոպեից կպատմեմ այն պատճառների մասին, որոնք ինձ դրդեցին գնալ այս քայլին։ Ղեկավարության համաձայնությունը ստանալուց հետո պլանն ավարտելու համար պահանջվեց ևս մի քանի ամիս, և ես անցում կատարեցի այս տարվա հունվար-փետրվարին։ Այսպիսով, մենք ամբողջովին լքեցինք Տիկնիկը հօգուտ Ansible-ի, և դա հիանալի բան է:
Ansible-ում ինձ ամենաշատը գրավում է դերեր և խաղային գրքեր գրելու և օգտագործելու ունակությունը: Դերերը հիանալի են տարբեր, բայց կապված առաջադրանքներ ստեղծելու և այդ առաջադրանքների հետ կապված բոլոր տվյալները մեկ տեղում դնելու համար: Խաղագիրքը YAML շարահյուսություն է, սցենարային ֆայլ, որը նկարագրում է գործողությունները մեկ կամ մի քանի հոսթների համար: Ես օգտատերերին ասում եմ այս հատկանիշների մասին, առաջին հերթին՝ ծրագրավորողներին: Ansible Tower-ը ձեզ հնարավորություն է տալիս ասելու, «ոչ, դուք չունեք shell հասանելիություն, բայց ես ձեզ հնարավորություն եմ տալիս գործարկել Tower-ի բոլոր գործընթացները և վերագործարկել ծառայությունը, երբ դրա կարիքը ունեք»: Ես ձեզ կպատմեմ աշխատանքային միջավայրի և այն սարքավորումների մասին, որոնք մենք օգտագործում ենք:
Սա դաշնային LAN է, ամպային MPLS-ի միջոցով միացված 7 ֆիզիկական կայք, 140 RHEL սերվեր, որոնց 99%-ը վիրտուալ է (vSphere), SuperMicro սարքավորում, NexentaStore ցանցային պահեստավորում, Cisco, Arista և Cumulus անջատիչների մի շարք և Fortinet UTM սպառնալիքների միասնական կառավարում։ գործիքներ յուրաքանչյուր կայքում:
Դաշնային ցանցը նշանակում է, որ ես պետք է օգտագործեմ օրենքով նախատեսված տեղեկատվական անվտանգության բոլոր միջոցները։ Պետք է նկատի ունենալ, որ Puppet Enterprise-ը չի աջակցում մեր օգտագործած սարքավորումների մեծ մասը: Մենք ստիպված ենք օգտագործել բյուջետային տեխնիկա, քանի որ պետական կառույցները խնդիրներ ունեն այս ծախսային հոդվածը ֆինանսավորելու հարցում: Այդ իսկ պատճառով մենք գնում ենք SuperMicro սարքավորում և հավաքում մեր սարքավորումները առանձին մասերից, որոնց սպասարկումը երաշխավորված է պետական պայմանագրերով: Մենք օգտագործում ենք Linux, և դա Ansible-ին անցնելու կարևոր պատճառներից մեկն է։
Մեր պատմությունը Puppet-ի հետ հետևյալն է.
2007-ին մենք ունեինք 20-25 հանգույցներից բաղկացած փոքր ցանց, որում տեղակայեցինք Puppet-ը: Հիմնականում այս հանգույցները պարզապես RedHat «արկղեր» էին: 2010 թվականին մենք սկսեցինք օգտագործել Տիկնիկային վահանակի վեբ ինտերֆեյսը 45 հանգույցների համար: Քանի որ ցանցը շարունակեց ընդլայնվել, մենք տեղափոխվեցինք PE 2014 3.3 թվականին՝ կատարելով ամբողջական անցում մանիֆեստի վերաշարադրմամբ 75 հանգույցների համար: Դա պետք է արվեր, քանի որ Puppet-ը սիրում է փոխել խաղի կանոնները, և այս դեպքում նրանք ամբողջովին փոխել են լեզուն: Մեկ տարի անց, երբ ավարտվեց Puppet Enterprise-ի 3 տարբերակի աջակցությունը, մենք ստիպված եղանք տեղափոխվել PE 2015.2: Մենք պետք է նորից գրեինք մանիֆեստը նոր սերվերների համար և գնեինք 100 հանգույցի պահուստով լիցենզիա, չնայած այն ժամանակ մենք ունեինք ընդամենը 85 հանգույց։
Անցել է ընդամենը 2 տարի, և մենք կրկին ստիպված եղանք մեծ աշխատանք կատարել PE 2016.4 նոր տարբերակին անցնելու համար։ Մենք գնեցինք լիցենզիա 300 հանգույցի համար՝ ունենալով ընդամենը 130: Մենք կրկին ստիպված եղանք խոշոր փոփոխություններ կատարել մանիֆեստում, քանի որ լեզվի նոր տարբերակն ուներ տարբեր շարահյուսություն, քան 2015-ի տարբերակի լեզուն: Արդյունքում, մեր SCM-ը SVN տարբերակի կառավարումից անցավ Bitbucket (Git): Սա էր մեր «հարաբերությունները» Տիկնիկի հետ:
Այսպիսով, ես ստիպված էի ղեկավարությանը բացատրել, թե ինչու մենք պետք է տեղափոխվեինք այլ SCM՝ օգտագործելով հետևյալ փաստարկները: Առաջինը ծառայության բարձր գինն է։ Ես խոսեցի RedHat-ի տղաների հետ, և նրանք ասացին, որ Ansible Tower-ով 300 հանգույց ցանցի գործարկման արժեքը կազմում է Puppet Enterprise-ի արժեքի կեսը: Եթե դուք նաև գնեք Ansible Engine, արժեքը մոտավորապես նույնն է լինելու, բայց դուք կստանաք շատ ավելի շատ հնարավորություններ, քան PE-ն: Քանի որ մենք դաշնային բյուջեից ֆինանսավորվող պետական ընկերություն ենք, սա բավականին հզոր փաստարկ է:
Երկրորդ փաստարկը բազմակողմանիությունն է: Puppet-ն աջակցում է միայն սարքաշար, որն ունի Puppet գործակալ: Սա նշանակում է, որ գործակալը պետք է տեղադրվի բոլոր անջատիչների վրա, և այն պետք է լինի վերջին տարբերակը։ Եվ եթե ձեր անջատիչներից մի քանիսն աջակցում են մեկ տարբերակին, իսկ ոմանք աջակցում են մեկ այլ տարբերակին, դուք պետք է դրանց վրա տեղադրեք PE գործակալի նոր տարբերակը, որպեսզի նրանք բոլորը կարողանան աշխատել նույն SCM համակարգում:
Ansible Tower համակարգը տարբեր կերպ է աշխատում, քանի որ այն չունի որևէ գործակալ, բայց այն ունի մոդուլներ, որոնք աջակցում են Cisco անջատիչներին և բոլոր մյուս անջատիչներին: Այս SCM-ն աջակցում է Qubes OS, Linux և 4.NET UTM: Ansible Tower-ը նաև աջակցում է NexentaStore ցանցային պահեստավորման կարգավորիչներին, որոնք հիմնված են Illumos միջուկի՝ բաց կոդով Unix-ի վրա հիմնված օպերացիոն համակարգի վրա: Սա շատ քիչ աջակցություն է, բայց Ansible Tower-ը դա անում է ամեն դեպքում:
Երրորդ փաստարկը, որը շատ կարևոր է և՛ ինձ, և՛ մեր վարչակազմի համար, օգտագործման հեշտությունն է։ Ես 10 տարի յուրացրի Տիկնիկային մոդուլները և մանիֆեստի կոդը, բայց Ansible-ը սովորեցի մեկ շաբաթվա ընթացքում, քանի որ այս SCM-ի հետ աշխատելը շատ ավելի հեշտ է: Եթե դուք գործարկում եք գործարկվող ֆայլեր, իհարկե, եթե դա անտեղի չանեք, ապա դրանց հետ աշխատում են խելացի և պատասխանատու մշակողները: YAML-ի վրա հիմնված գրքույկները հեշտ է սովորել և արագ օգտագործել: Նրանք, ովքեր նախկինում երբեք չեն լսել YAML-ի մասին, կարող են պարզապես կարդալ սցենարները և հեշտությամբ հասկանալ, թե ինչպես է այն աշխատում:
Անկեղծ ասած, Puppet-ը շատ ավելի բարդացնում է ձեր աշխատանքը որպես ծրագրավորող, քանի որ այն հիմնված է Puppet Master-ի օգտագործման վրա: Դա միակ մեքենան է, որը թույլ է տալիս շփվել Տիկնիկային գործակալների հետ: Եթե դուք որևէ փոփոխություն եք կատարել մանիֆեստում և ցանկանում եք փորձարկել ձեր կոդը, դուք պետք է վերագրեք ծածկագիրը Puppet Master-ի համար, այսինքն՝ կարգավորեք Puppet Master /etc/hosts ֆայլը, որպեսզի միացնի բոլոր հաճախորդները և սկսի Puppet Server ծառայությունը: Միայն դրանից հետո դուք կկարողանաք փորձարկել ցանցային սարքավորումների աշխատանքը մեկ հոսթի վրա: Սա բավականին ցավոտ պրոցեդուրա է։
Ansible-ում ամեն ինչ շատ ավելի պարզ է: Ձեզ անհրաժեշտ է միայն կոդ մշակել մեքենայի համար, որը կարող է SSH-ի միջոցով շփվել փորձարկվող հոսթի հետ: Սա շատ ավելի հեշտ է աշխատել:
Ansible Tower-ի հաջորդ մեծ առավելությունը ձեր գոյություն ունեցող աջակցության համակարգը օգտագործելու և ձեր առկա ապարատային կոնֆիգուրացիան պահպանելու հնարավորությունն է: Այս SCM-ն առանց լրացուցիչ քայլերի օգտագործում է ձեր ենթակառուցվածքի և սարքավորումների, վիրտուալ մեքենաների, սերվերների և այլնի մասին հասանելի բոլոր տեղեկությունները: Այն կարող է խոսել ձեր RH Satellite սերվերների հետ, եթե ունեք, և ձեզ տալիս է ինտեգրումներ, որոնք երբեք չեք ստանա Puppet-ի հետ:
Մեկ այլ կարևոր բան մանրամասն հսկողությունն է։ Դուք գիտեք, որ Puppet-ը մոդուլային համակարգ է, այն հաճախորդ-սերվերի հավելված է, այնպես որ դուք պետք է սահմանեք ձեր բոլոր մեքենաների առկա ասպեկտները մեկ երկար մանիֆեստում: Այս դեպքում համակարգի յուրաքանչյուր առանձին տարրի վիճակը պետք է փորձարկվի յուրաքանչյուր կես ժամը մեկ՝ սա լռելյայն ժամկետն է: Ահա թե ինչպես է աշխատում Տիկնիկը.
Աշտարակը ձեզ փրկում է դրանից: Դուք կարող եք մի շարք գործընթացներ իրականացնել տարբեր սարքավորումների վրա առանց սահմանափակումների, կարող եք կատարել հիմնական աշխատանք, գործարկել այլ կարևոր գործընթացներ, ստեղծել անվտանգության համակարգ և աշխատել տվյալների բազաների հետ: Դուք կարող եք անել այն ամենը, ինչ դժվար է Տիկնիկային ձեռնարկությունում: Այսպիսով, եթե դուք այն կարգավորել եք մեկ հոսթի վրա, ժամանակ կպահանջվի, որպեսզի փոփոխություններն ուժի մեջ մտնեն մնացած հոսթների վրա: Ansible-ում բոլոր փոփոխություններն ուժի մեջ են մտնում միաժամանակ:
Վերջապես, եկեք նայենք անվտանգության մոդուլին: Ansible Tower-ն այն իրականացնում է պարզապես զարմանալիորեն, մեծ ճշգրտությամբ և խնամքով: Դուք կարող եք օգտվողներին տրամադրել մուտք դեպի հատուկ ծառայություններ կամ կոնկրետ հոսթորդներ: Ես դա անում եմ իմ աշխատակիցների հետ, ովքեր սովոր են աշխատել Windows-ի վրա՝ սահմանափակելով նրանց մուտքը դեպի Linux shell: Ես ապահովում եմ, որ նրանք մուտք ունենան Tower-ին, որպեսզի նրանք կարողանան կատարել միայն աշխատանքը և գործարկել միայն իրենց համար համապատասխան ծառայությունները:
Եկեք նայենք այն բաներին, որոնք դուք պետք է անեք ժամանակից շուտ՝ ձեր անցումը Ansible Tower-ին հեշտացնելու համար: Առաջին հերթին, դուք պետք է պատրաստեք ձեր սարքավորումները. Եթե ձեր ենթակառուցվածքի որոշ տարրեր արդեն տվյալների բազայում չեն, դուք պետք է դրանք ավելացնեք այնտեղ: Կան համակարգեր, որոնք չեն փոխում իրենց բնութագրերը և հետևաբար չկան Puppet տվյալների բազայում, բայց եթե դրանք չավելացնեք այնտեղ մինչև Tower տեղափոխվելը, կկորցնեք մի շարք առավելություններ: Սա կարող է լինել «կեղտոտ», նախնական տվյալների բազա, բայց այն պետք է պարունակի տեղեկատվություն ձեր ունեցած բոլոր սարքավորումների մասին: Հետևաբար, դուք պետք է գրեք դինամիկ ապարատային սկրիպտ, որն ավտոմատ կերպով կմղի ենթակառուցվածքի բոլոր փոփոխությունները տվյալների բազա, այնուհետև Ansible-ը կիմանա, թե որ հոսթները պետք է ներկա լինեն նոր համակարգում: Դուք կարիք չեք ունենա այս SCM-ին ասել, թե որ հոսթ եք ավելացրել, և որ հոսթներն այլևս գոյություն չունեն, քանի որ այն ավտոմատ կերպով կիմանա այս ամենը: Որքան շատ տվյալներ լինեն տվյալների բազայում, այնքան ավելի օգտակար և ճկուն կլինի Ansible-ը: Այն աշխատում է այնպես, կարծես այն պարզապես կարդում է ապարատային կարգավիճակի շտրիխ կոդը տվյալների բազայից:
Որոշ ժամանակ անցկացրեք Ansible-ում հրամանի տողին ծանոթանալու համար: Գործարկեք որոշ հատուկ հրամաններ՝ ապարատային սկրիպտը փորձարկելու համար, գրեք և գործարկեք մի քանի պարզ, բայց օգտակար խաղային գրքի սցենարներ, անհրաժեշտության դեպքում օգտագործեք Jinja2 ձևանմուշները: Փորձեք գրել դեր և սցենար բարդ, բազմաքայլ գործընթացի համար՝ օգտագործելով սովորական, հաճախ հանդիպող ապարատային կոնֆիգուրացիա: Խաղացեք այս բաների հետ, փորձեք, թե ինչպես է այն աշխատում: Այս կերպ դուք կսովորեք, թե ինչպես օգտագործել գրադարանի ստեղծման գործիքները, որոնք օգտագործվում են Tower-ում: Արդեն ասացի, որ անցմանը պատրաստվելու համար ինձանից պահանջվեց մոտ 3 ամիս։ Կարծում եմ, որ իմ փորձի հիման վրա դուք կկարողանաք դա անել ավելի արագ: Այս ժամանակը իզուր մի համարեք, քանի որ հետագայում դուք կզգաք կատարված աշխատանքի բոլոր օգուտները։
Հաջորդը, դուք պետք է որոշեք, թե ինչ եք ակնկալում Ansible Tower-ից, կոնկրետ ինչ պետք է անի այս համակարգը ձեզ համար:
Ձեզ անհրաժեշտ է համակարգը տեղակայել մերկ ապարատային, մերկ վիրտուալ մեքենաների վրա: Թե՞ ցանկանում եք պահպանել գործող սարքավորումների սկզբնական աշխատանքային պայմաններն ու կարգավորումները: Սա շատ կարևոր ասպեկտ է հանրային ընկերությունների համար, այնպես որ դուք պետք է վստահ լինեք, որ կկարողանաք տեղափոխել և տեղակայել Ansible-ը ձեր առկա կազմաձևում: Բացահայտեք սովորական վարչական գործընթացները, որոնք ցանկանում եք ավտոմատացնել: Պարզեք, թե արդյոք Ձեզ անհրաժեշտ է նոր համակարգում տեղակայել հատուկ հավելվածներ և ծառայություններ: Կազմեք ցանկ, թե ինչ եք ուզում անել և առաջնահերթություն տվեք դրան:
Այնուհետև սկսեք գրել սցենարի կոդ և դերեր, որոնք հնարավորություն կտան կատարել ձեր նախատեսած առաջադրանքները: Համատեղեք դրանք Նախագծերի մեջ՝ համապատասխան գրքույկների տրամաբանական հավաքածու: Յուրաքանչյուր նախագիծ կպատկանի առանձին Git պահոց կամ այլ պահոց՝ կախված նրանից, թե որ կոդերի կառավարիչն եք օգտագործում: Դուք կարող եք կառավարել խաղային գրքույկների սկրիպտները և գրքույկների գրացուցակները՝ դրանք ձեռքով տեղադրելով Tower սերվերի Project Base Path-ում կամ տեղադրելով խաղագիրքը ցանկացած աղբյուրի կոդերի կառավարման (SCM) համակարգում, որն աջակցում է Tower-ը, ներառյալ Git, Subversion, Mercurial և Red Hat: Խորաթափանցություն. Մեկ Ծրագրի շրջանակներում դուք կարող եք տեղադրել այնքան սցենար, որքան ցանկանում եք: Օրինակ, ես ստեղծեցի մեկ հիմնական նախագիծ, որտեղ տեղադրեցի սկրիպտ RedHat հիմնական տարրերի համար, սցենար Linux միջուկի համար և սցենարներ մնացած հիմնական գծերի համար: Այսպիսով, մեկ նախագծում կային մի շարք դերեր և սցենարներ, որոնք կառավարվում էին մեկ Git պահոցից:
Այս բոլոր բաները հրամանի տողի միջոցով գործարկելը լավ միջոց է դրանց ֆունկցիոնալությունը ստուգելու համար: Սա ձեզ կնախապատրաստի Tower-ի տեղադրմանը:
Եկեք մի փոքր խոսենք Տիկնիկային մանիֆեստի տրանսկոդավորման մասին, քանի որ ես շատ ժամանակ ծախսեցի դրա վրա, մինչև հասկացա, թե իրականում ինչ է պետք անել:
Ինչպես նախկինում ասացի, Puppet-ը պահում է բոլոր կարգավորումները և ապարատային տարբերակները մեկ երկար մանիֆեստում, և այս մանիֆեստը պահում է այն ամենը, ինչ պետք է անի այս SCM-ը: Անցում կատարելիս ձեզ հարկավոր չէ ձեր բոլոր առաջադրանքները մեկ ցուցակի մեջ խցկել, փոխարենը մտածեք նոր համակարգի կառուցվածքի մասին՝ դերեր, սցենարներ, պիտակներ, խմբեր և ինչ պետք է գնա այնտեղ: Ինքնավար ցանցի որոշ տարրեր պետք է խմբավորվեն խմբերի, որոնց համար կարող են ստեղծվել սցենարներ: Ավելի բարդ ենթակառուցվածքային տարրերը, որոնք ներառում են մեծ թվով ռեսուրսներ, ներառյալ ինքնուրույն դասեր, կարող են համակցվել դերերի մեջ: Նախքան գաղթելը, դուք պետք է որոշեք այս մասին: Եթե դուք ստեղծում եք մեծ դերեր կամ սցենարներ, որոնք չեն տեղավորվում մեկ էկրանին, դուք պետք է օգտագործեք պիտակներ, որպեսզի կարողանաք նկարել ենթակառուցվածքի որոշակի հատվածներ:
18:00
Մի քանի գովազդ 🙂
Շնորհակալություն մեզ հետ մնալու համար: Ձեզ դուր են գալիս մեր հոդվածները: Ցանկանու՞մ եք տեսնել ավելի հետաքրքիր բովանդակություն: Աջակցեք մեզ՝ պատվիրելով կամ խորհուրդ տալով ընկերներին, , մուտքի մակարդակի սերվերների եզակի անալոգ, որը հորինվել է մեր կողմից ձեզ համար. (հասանելի է RAID1 և RAID10-ով, մինչև 24 միջուկով և մինչև 40 ԳԲ DDR4):
Dell R730xd 2 անգամ ավելի էժան Ամստերդամի Equinix Tier IV տվյալների կենտրոնում: Միայն այստեղ Նիդեռլանդներում! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99-ից: Կարդացեք մասին
Source: www.habr.com