Սա ելույթի սղագրությունն է и .
Սա մի նախագծի պատմություն է, որն օգտագործում էր ինքնուրույն գրված կոնֆիգուրացիայի կառավարման համակարգ, և ինչու է Ansible տեղափոխությունը տևել 18 ամիս:
Օր թիվ -ХХХ: Նախքան սկիզբը
Սկզբում ենթակառուցվածքը բաղկացած էր Hyper-V-ով աշխատող բազմաթիվ առանձին հյուրընկալողներից: Վիրտուալ մեքենայի ստեղծումը պահանջում էր բազմաթիվ քայլեր՝ սկավառակների ճիշտ տեղում տեղադրում, DNS գրանցում, DHCP-ի ամրագրում, VM կոնֆիգուրացիան git պահոցում տեղադրում: Այս գործընթացը մասամբ մեքենայացված էր, բայց, օրինակ, VM-ները բաժանվում էին հյուրընկալողների միջև ձեռքով: Բայց, օրինակ, մշակողները կարող են ուղղել VM-ի կոնֆիգուրացիան git-ում և կիրառել այն՝ վերագործարկելով VM-ը:
Պատվերով կազմաձևման կառավարման լուծում
Նախնական գաղափարը, ես կասկածում եմ, ստեղծվել է որպես IaC. շատ քաղաքացիություն չունեցող VM-ներ, որոնք վերագործարկվելիս զրոյականացնում են իրենց վիճակը: Ի՞նչ էր VM-ի կազմաձևման կառավարումը: Սխեմատիկորեն պարզ է թվում.
- VM-ի համար ստեղծվել է ստատիկ MAC:
- VM-ին միացված են CoreOS-ով ISO և boot disk:
- CoreOS-ը գործարկում է հարմարեցման սկրիպտը՝ ներբեռնելով այն WEB սերվերից՝ հիմնվելով իր IP-ի վրա:
- Սցենարը ներբեռնում է VM-ի կոնֆիգուրացիան SCP-ի միջոցով՝ հիմնված IP հասցեի վրա:
- Գործարկվել են systemd միավոր ֆայլերի ոտնաթաթը և bash սկրիպտների ոտնաթաթը:
Այս լուծումն ուներ բազմաթիվ ակնհայտ խնդիրներ.
- CoreOS ISO-ն հնացել է:
- Բազմաթիվ բարդ ավտոմատացված գործողություններ և մոգություն VM-ներ տեղափոխելիս/ստեղծելիս:
- Թարմացման հետ կապված դժվարություններ և երբ անհրաժեշտ է ծրագրային ապահովման որոշակի տարբերակ: Նույնիսկ ավելի զվարճալի միջուկային մոդուլներով:
- VM-ները այդպես էլ ձեռք չեն բերվել առանց տվյալների, այսինքն. VM-ները հայտնվեցին սկավառակով, որի վրա տեղադրված էին լրացուցիչ օգտվողի տվյալները:
- Ինչ-որ մեկը անընդհատ խեղաթյուրում էր համակարգային միավորների կախվածությունը, և CoreOS-ը սառչում էր վերաբեռնման ժամանակ: Դժվար էր դա հասկանալ CoreOS-ում առկա գործիքների միջոցով:
- Գաղտնիքների կառավարում.
- ԿՄ չի եղել։ CoreOS-ի համար կային bash և YML կազմաձևեր:
VM-ի կոնֆիգուրացիան կիրառելու համար դուք պետք է վերաբեռնեք այն, բայց այն կարող է չվերագործարկվել: Թվում է, թե ակնհայտ խնդիր է, բայց մշտական սկավառակներ չկան. տեղեկամատյանները փրկելու տեղ չկա: Լավ, լավ, փորձենք ավելացնել միջուկի բեռնման տարբերակը, որպեսզի տեղեկամատյանները ուղարկվեն։ Բայց ոչ, որքան բարդ է այդ ամենը:
Օր թիվ 0. Ճանաչեք խնդիրը
Դա զարգացման սովորական ենթակառուցվածքն էր՝ ջենկիններ, թեստային միջավայրեր, մոնիտորինգ, ռեեստր: CoreOS-ը նախատեսված էր k8s կլաստերների հոսթինգի համար, այսինքն. խնդիրն այն էր, թե ինչպես է օգտագործվել CoreOS-ը: Առաջին քայլը կույտի ընտրությունն էր: Մենք որոշեցինք.
- CentOS որպես բազային բաշխում, քանի որ Սա արտադրական միջավայրերին ամենամոտ բաշխումն է:
- Հղիություն կոնֆիգուրացիայի կառավարման համար, քանի որ դրա վերաբերյալ ծավալուն փորձաքննություն է եղել։
- Jenkins որպես գործող գործընթացների ավտոմատացման շրջանակ, քանի որ այն արդեն ակտիվորեն օգտագործվել է զարգացման գործընթացների համար
- Hyper-V- ը որպես վիրտուալացման հարթակ: Կան մի շարք պատճառներ, որոնք դուրս են գալիս պատմության շրջանակներից, բայց մի խոսքով, մենք չենք կարող օգտագործել ամպերը, մենք պետք է օգտագործենք մեր սեփական սարքավորումը:
Օր թիվ 30. Գոյություն ունեցող պայմանագրերի ամրագրում - Պայմանագրերը որպես օրենսգիրք
Երբ կույտը պարզ դարձավ, սկսվեցին շարժման նախապատրաստական աշխատանքները: Գոյություն ունեցող պայմանագրերի ամրագրում կոդի ձևով (Համաձայնագրերը որպես օրենսգիրք!). Անցում ձեռքի աշխատանք -> մեքենայացում -> ավտոմատացում.
1. Կարգավորել VM-ները
Ansible-ն այս հարցում մեծ աշխատանք է կատարում: Մարմնի նվազագույն շարժումներով դուք կարող եք վերահսկել VM կոնֆիգուրացիաները.
- Ստեղծեք git պահոց:
- Մենք տեղադրում ենք VM-ների ցուցակը գույքագրման մեջ, կոնֆիգուրացիաները՝ խաղային գրքերում և դերերում:
- Մենք ստեղծում ենք հատուկ jenkins ստրուկ, որից դուք կարող եք գործարկել Ansible-ը:
- Մենք ստեղծում ենք աշխատանք և կարգավորում Jenkins-ը:
Առաջին գործընթացը պատրաստ է։ Պայմանագրերը ամրագրված են։
2. Ստեղծեք նոր VM
Այստեղ ամեն ինչ այնքան էլ հարմար չէր։ Linux-ից Hyper-V-ում VM-ներ ստեղծելն այնքան էլ հարմար չէ։ Այս գործընթացը մեքենայացնելու փորձերից մեկն էր.
- Ansbile-ը միանում է WinRM-ի միջոցով windows հոսթին:
- Ansible-ը գործարկում է powershell սկրիպտը:
- Powershell script-ը ստեղծում է նոր VM:
- Օգտագործելով Hyper-V/ScVMM, հյուրի ՕՀ-ում VM ստեղծելիս, հոսթի անունը կազմաձևվում է:
- DHCP վարձակալությունը թարմացնելիս VM-ն ուղարկում է իր հոսթի անունը:
- Ստանդարտ ddns և dhcp ինտեգրումը Domain Controller-ի կողմում կարգավորում է DNS գրառումը:
- Դուք կարող եք VM ավելացնել ձեր գույքագրմանը և կարգավորել այն Ansible-ի միջոցով:
3. Ստեղծեք VM ձևանմուշ
Նրանք այստեղ ոչինչ չեն հորինել, նրանք տարան փաթեթավորող:
- Ավելացնել փաթեթավորող, kickstart կազմաձևը git պահոցում:
- Հատուկ ջենկինսի ստրուկի ստեղծում hyper-v-ի և Packer-ի հետ:
- Մենք ստեղծում ենք աշխատանք և կարգավորում Jenkins-ը:
Ինչպես է աշխատում այս հղումը.
- Փաքերը ստեղծում է դատարկ VM և վերցնում ISO-ն:
- VM boots, Packer-ը մուտքագրում է հրամանը bootloader՝ օգտագործելու մեր kickstart ֆայլը ճկուն սկավառակից կամ http-ից:
- Anaconda-ն գործարկվում է մեր կազմաձևով, և ՕՀ-ի նախնական կազմաձևումն ավարտված է:
- Փաքերը սպասում է, որ VM-ը հասանելի դառնա:
- VM-ի ներսում փաթեթավորողն աշխատում է լոկալ ռեժիմով:
- Ansible-ն օգտագործում է ճիշտ նույն դերերը, որոնք աշխատում է #1 քայլում:
- Փաքերը արտահանում է VM ձևանմուշը:
Օր թիվ 75. Վերափոխեք համաձայնագիրը առանց խախտելու = Փորձարկում + Փորձնական խոհանոց
Կոդի մեջ կոնվենցիաների գրանցումը կարող է բավարար չլինել: Ի վերջո, եթե գործընթացի խորքում ուզում ես ինչ-որ բան փոխել, կարող ես ինչ-որ բան կոտրել: Ուստի ենթակառուցվածքի դեպքում ի հայտ է գալիս հենց այս ենթակառուցվածքի փորձարկումը։ Թիմի ներսում գիտելիքները համաժամեցնելու համար մենք սկսեցինք փորձարկել Ansible դերերը: Չեմ խորանա, որովհետև... կա հոդված, որը նկարագրում է ժամանակի իրադարձությունները (սփոյլեր սա վերջնական տարբերակը չէր, և ավելի ուշ ամեն ինչ ավելի բարդացավ ).
Օր #130. Միգուցե CentOS+ansible-ն անհրաժեշտ չէ: միգուցե openshift?
Պետք է հասկանանք, որ ենթակառուցվածքների ներդրման գործընթացը միակը չի եղել, եղել են կողմնակի ենթածրագրեր։ Օրինակ՝ մեր հավելվածը openshift-ով գործարկելու հարցում եկավ, և դա հանգեցրեց մեկ շաբաթից ավելի հետազոտությունների ինչը դանդաղեցրեց շարժման գործընթացը: Արդյունքը պարզվեց, որ openshift-ը չի ծածկում բոլոր կարիքները, անհրաժեշտ է իրական սարքավորում կամ գոնե միջուկի հետ խաղալու հնարավորություն:
Օր #170. Openshift-ը հարմար չէ, եկեք հնարավորություն ընձեռենք Windows Azure Pack-ի հետ:
Hyper-V-ն այնքան էլ բարեկամական չէ, SCVMM-ն այն շատ ավելի լավ չի դարձնում: Բայց կա Windows Azure Pack-ի նման բան, որը հավելում է SCVMM-ին և նմանակում է Azure-ին: Բայց իրականում ապրանքը լքված տեսք ունի. փաստաթղթերը կոտրված են հղումներով և շատ նոսր են: Բայց որպես մեր ամպի կյանքը պարզեցնելու տարբերակների ուսումնասիրության մաս, նրանք նույնպես նայեցին դրան:
Օր #250. Windows Azure փաթեթը այնքան էլ լավ չէ: Մենք մնում ենք SCVMM-ում
Windows Azure Pack-ը խոստումնալից տեսք ուներ, բայց որոշվեց չմտցնել WAP-ն իր բարդություններով համակարգ՝ հանուն ավելորդ գործառույթների և մնաց SCVMM-ի հետ:
Օր #360. Փղին մաս առ մաս ուտել
Միայն մեկ տարի անց տեղափոխվելու հարթակը պատրաստ էր, և շարժման գործընթացը սկսվեց։ Այդ նպատակով տեղադրվել է S.M.A.R.T. առաջադրանք. Մենք ստուգեցինք բոլոր VM-ները և սկսեցինք մեկ առ մեկ պարզել կոնֆիգուրացիան, նկարագրել այն Ansible-ում և ծածկել այն թեստերով:
Օր #450. Ինչպիսի՞ համակարգ եք ստացել:
Գործընթացն ինքնին հետաքրքիր չէ։ Դա սովորական է, կարելի է նշել, որ կոնֆիգուրացիաների մեծ մասը եղել է համեմատաբար պարզ կամ իզոմորֆ, և ըստ Պարետոյի սկզբունքի, VM կոնֆիգուրացիաների 80%-ը պահանջում է ժամանակի 20%-ը: Նույն սկզբունքով ժամանակի 80%-ը ծախսվել է տեղափոխության նախապատրաստման վրա և միայն 20%-ը՝ հենց շարժման վրա:
Օր #540. Եզրափակիչ
Ի՞նչ տեղի ունեցավ 18 ամսում.
- Պայմանագրերը դարձան օրենսգիրք.
- Ձեռքի աշխատանք -> Մեխանիզացիա -> Ավտոմատ.
հղումներ
Source: www.habr.com