🥇 «Սթարթափից» մինչև հազարավոր սերվերներ տասնյակ տվյալների կենտրոններում: Ինչպես մենք հետապնդեցինք Linux ենթակառուցվածքի աճը

Եթե ձեր ՏՏ ենթակառուցվածքը չափազանց արագ է աճում, վաղ թե ուշ ընտրության առաջ կկանգնեք՝ գծային կերպով մեծացնել մարդկային ռեսուրսները՝ աջակցելու համար կամ սկսել ավտոմատացում: Մինչև ինչ-որ պահ մենք ապրում էինք առաջին պարադիգմում, իսկ հետո սկսվեց երկար ճանապարհը դեպի Ենթակառուցվածք-որպես կոդ:

Իհարկե, NSPK-ն ստարտափ չէ, բայց նման մթնոլորտ էր տիրում ընկերությունում իր գոյության առաջին տարիներին, և դրանք շատ հետաքրքիր տարիներ էին։ Իմ ԱՆՈՒՆՆ Է Կորնյակով Դմիտրի, ես աջակցում եմ Linux-ի ենթակառուցվածքը բարձր հասանելիության պահանջներով ավելի քան 10 տարի: Նա միացավ NSPK թիմին 2016 թվականի հունվարին և, ցավոք, չտեսավ ընկերության գոյության հենց սկիզբը, բայց եկավ մեծ փոփոխությունների փուլում:

Ընդհանուր առմամբ, կարելի է ասել, որ մեր թիմն ընկերության համար մատակարարում է 2 ապրանք։ Առաջինը ենթակառուցվածքն է: Փոստը պետք է աշխատի, DNS-ը պետք է աշխատի, իսկ տիրույթի կարգավորիչները պետք է թույլ տան ձեզ մտնել սերվերներ, որոնք չպետք է խափանվեն: Ընկերության ՏՏ լանդշաֆտը հսկայական է: Սրանք բիզնեսի և առաքելության կարևոր համակարգեր են, որոշների համար մատչելիության պահանջները 99,999 են: Երկրորդ արտադրանքը հենց սերվերներն են՝ ֆիզիկական և վիրտուալ: Գոյություն ունեցողները պետք է մոնիտորինգի ենթարկվեն, իսկ նորերը պետք է պարբերաբար մատակարարվեն բազմաթիվ գերատեսչությունների հաճախորդներին: Այս հոդվածում ես ուզում եմ կենտրոնանալ այն բանի վրա, թե ինչպես ենք մենք մշակել ենթակառուցվածքը, որը պատասխանատու է սերվերի կյանքի ցիկլի համար:

Սկիզբն է ճանապարհորդության

Մեր ճանապարհորդության սկզբում մեր տեխնոլոգիական փաթեթը այսպիսի տեսք ուներ.
ՕՀ CentOS 7
FreeIPA տիրույթի վերահսկիչներ
Ավտոմատացում - Ansible(+Tower), Cobbler

Այս ամենը տեղակայված էր 3 տիրույթում՝ տարածված մի քանի տվյալների կենտրոններում։ Մի տվյալների կենտրոնում կան գրասենյակային համակարգեր և թեստային կայքեր, մնացածում՝ PROD:

Սերվերների ստեղծումը մի կետում այսպիսի տեսք ուներ.

VM ձևանմուշում CentOS-ը նվազագույն է, և պահանջվող նվազագույնը ճիշտ /etc/resolv.conf-ի նման է, մնացածը գալիս է Ansible-ի միջոցով:

CMDB - Excel.

Եթե սերվերը ֆիզիկական է, ապա վիրտուալ մեքենան պատճենելու փոխարեն ՕՀ-ն տեղադրվել է դրա վրա՝ օգտագործելով Cobbler - թիրախային սերվերի MAC հասցեները ավելացվում են Cobbler կոնֆիգուրացիայի մեջ, սերվերը ստանում է IP հասցե DHCP-ի միջոցով, այնուհետև ՕՀ-ն: ավելացված է.

Սկզբում մենք նույնիսկ փորձեցինք ինչ-որ կոնֆիգուրացիայի կառավարում անել Cobbler-ում: Բայց ժամանակի ընթացքում դա սկսեց խնդիրներ առաջացնել կոնֆիգուրացիաների տեղափոխելիության հետ կապված ինչպես այլ տվյալների կենտրոնների, այնպես էլ VM-ների պատրաստման Ansible կոդի հետ:

Այն ժամանակ մեզանից շատերը Ansible-ն ընկալում էին որպես Bash-ի հարմար ընդլայնում և չէին խնայում շելլ և sed դիզայներ: Ընդհանուր Bashsible. Սա ի վերջո հանգեցրեց նրան, որ եթե խաղագիրքը ինչ-ինչ պատճառներով չի աշխատում սերվերի վրա, ավելի հեշտ էր ջնջել սերվերը, շտկել խաղատախտակը և նորից գործարկել այն: Ըստ էության, չկար սկրիպտների տարբերակում, կոնֆիգուրացիաների շարժականություն:

Օրինակ, մենք ցանկանում էինք փոխել որոշ կոնֆիգուրացիա բոլոր սերվերների վրա.

Մենք փոխում ենք կոնֆիգուրացիան գոյություն ունեցող սերվերների վրա տրամաբանական հատվածում/տվյալների կենտրոնում: Երբեմն ոչ մեկ օրում՝ մատչելիության պահանջները և մեծ թվերի օրենքը թույլ չեն տալիս բոլոր փոփոխությունները միանգամից կիրառել: Եվ որոշ փոփոխություններ պոտենցիալ կործանարար են և պահանջում են ինչ-որ բան վերագործարկել՝ ծառայություններից մինչև բուն ՕՀ:
Ամրագրելով այն Ansible-ում
Մենք այն ամրացնում ենք կոշկակարի մեջ
Կրկնել N անգամ յուրաքանչյուր տրամաբանական հատվածի/տվյալների կենտրոնի համար

Որպեսզի բոլոր փոփոխությունները սահուն ընթանան, անհրաժեշտ էր հաշվի առնել բազմաթիվ գործոններ, և փոփոխություններն անընդհատ տեղի են ունենում։

Ansible կոդի, կազմաձևման ֆայլերի վերամշակում
Ներքին լավագույն փորձի փոփոխություն
Միջադեպերի/պատահարների վերլուծության արդյունքների հիման վրա կատարված փոփոխություններ
Անվտանգության ստանդարտների փոփոխություն՝ ինչպես ներքին, այնպես էլ արտաքին: Օրինակ, PCI DSS-ը ամեն տարի թարմացվում է նոր պահանջներով

Ենթակառուցվածքների աճ և ճանապարհորդության սկիզբ

Սերվերների/տրամաբանական տիրույթների/տվյալների կենտրոնների թիվն աճեց, և դրանց հետ մեկտեղ ավելացավ նաև կոնֆիգուրացիաներում սխալների թիվը: Ինչ-որ պահի մենք եկանք երեք ուղղությունների, որոնցում պետք է մշակվի կոնֆիգուրացիայի կառավարում.

Ավտոմատացում. Կրկնվող գործողություններում մարդկային սխալներից պետք է հնարավորինս խուսափել:
Կրկնելիություն. Շատ ավելի հեշտ է կառավարել ենթակառուցվածքը, երբ այն կանխատեսելի է: Սերվերների և դրանց պատրաստման գործիքների կազմաձևումը պետք է լինի նույնը ամենուր: Սա նաև կարևոր է արտադրանքի թիմերի համար. փորձարկումից հետո հավելվածը պետք է երաշխավորված լինի, որ կհայտնվի արտադրական միջավայրում, որը կազմաձևված է փորձարկման միջավայրի նմանությամբ:
Կազմաձևման կառավարման մեջ փոփոխություններ կատարելու պարզությունն ու թափանցիկությունը:

Մնում է ավելացնել մի քանի գործիք:

Մենք ընտրեցինք GitLab CE-ն որպես մեր կոդերի պահոց, հատկապես ներկառուցված CI/CD մոդուլների համար:

Գաղտնիքների պահոց - Hashicorp Vault, ներառյալ: մեծ API-ի համար:

Փորձարկման կոնֆիգուրացիաներ և հստակ դերեր – Molecule+Testinfra: Թեստերը շատ ավելի արագ են անցնում, եթե միացնեք անզգայուն միտոգենին: Միևնույն ժամանակ, մենք սկսեցինք գրել մեր սեփական CMDB-ն և նվագախումբը ավտոմատ տեղակայման համար (վերևի նկարում գտնվող Cobbler-ում), բայց սա բոլորովին այլ պատմություն է, որը ապագայում կպատմի իմ գործընկերը և այս համակարգերի հիմնական մշակողը:

Մեր ընտրությունը.

Մոլեկուլ + Testinfra
Ansible + Tower + AWX
Սերվերների աշխարհ + DITNET (սեփական զարգացում)
Կոբլեր
Gitlab + GitLab վազող
Hashicorp պահոց

Ի դեպ, հասկանալի դերերի մասին. Սկզբում կար միայն մեկը, բայց մի քանի վերամշակումից հետո դրանցից 17-ը: Ես խստորեն խորհուրդ եմ տալիս մոնոլիտը կոտրել անիմաստ դերերի, որոնք այնուհետև կարող են գործարկվել առանձին, բացի այդ, կարող եք ավելացնել պիտակներ: Մենք դերերը բաժանեցինք ըստ ֆունկցիոնալության՝ ցանց, գրանցում, փաթեթներ, սարքավորումներ, մոլեկուլ և այլն: Ընդհանուր առմամբ, մենք հետևեցինք ստորև ներկայացված ռազմավարությանը. Ես չեմ պնդում, որ սա միակ ճշմարտությունն է, բայց դա մեզ մոտ աշխատեց։

Սերվերները «ոսկե պատկերից» պատճենելը չարիք է:Հիմնական թերությունն այն է, որ դուք չգիտեք, թե կոնկրետ ինչ վիճակում են պատկերները հիմա, և որ բոլոր փոփոխությունները տեղի կունենան բոլոր պատկերների վրա բոլոր վիրտուալացման ֆերմերներում:
Օգտագործեք լռելյայն կազմաձևման ֆայլերը նվազագույնի և համաձայնեք այլ բաժինների հետ, որ դուք պատասխանատու եք հիմնական համակարգի ֆայլերի համար, օրինակ `
1. Դատարկ թողեք /etc/sysctl.conf, կարգավորումները պետք է լինեն միայն /etc/sysctl.d/-ում: Ձեր լռելյայն մեկ ֆայլում, հարմարեցված է մեկ այլ ֆայլում հավելվածի համար:
2. Օգտագործեք վերագրանցող ֆայլեր՝ համակարգված միավորները խմբագրելու համար:
Կաղապարեք բոլոր կոնֆիգուրացիաները և ամբողջությամբ ներառեք դրանք, եթե հնարավոր է, խաղագրքերում sed կամ դրա անալոգներ չկան
Կազմաձևման կառավարման համակարգի կոդի վերամշակում.
1. Առաջադրանքները բաժանեք տրամաբանական սուբյեկտների և մոնոլիտը վերագրեք դերերի
2. Օգտագործեք լինտերներ! Ansible-lint, yaml-lint և այլն
3. Փոխե՛ք ձեր մոտեցումը։ Ոչ մի խայտառակություն: Պետք է նկարագրել համակարգի վիճակը
Ansible-ի բոլոր դերերի համար դուք պետք է թեստեր գրեք մոլեկուլում և ստեղծեք հաշվետվություններ օրական մեկ անգամ:
Մեր դեպքում թեստերը պատրաստելուց հետո (որոնցից ավելի քան 100-ը) հայտնաբերվել է մոտ 70000 սխալ։ Այն շտկելու համար պահանջվել է մի քանի ամիս։

Մեր իրականացումը

Այսպիսով, անսխալ դերերը պատրաստ էին, կաղապարված և ստուգված էին լինտերներով: Եվ նույնիսկ gits բարձրացվում են ամենուր: Սակայն տարբեր հատվածներին կոդերի հուսալի առաքման հարցը բաց մնաց։ Մենք որոշեցինք սինխրոնիզացնել սցենարների հետ: Կարծես թե.

Փոփոխության ժամանումից հետո CI-ն գործարկվում է, ստեղծվում է թեստային սերվեր, դերերը գլորվում են և փորձարկվում մոլեկուլի կողմից: Եթե ամեն ինչ կարգին է, կոդը գնում է prod մասնաճյուղ: Բայց մենք նոր կոդ չենք կիրառում մեքենայի առկա սերվերների վրա: Սա մի տեսակ խցան է, որն անհրաժեշտ է մեր համակարգերի բարձր հասանելիության համար: Եվ երբ ենթակառուցվածքը դառնում է հսկայական, գործում է մեծ թվերի օրենքը. նույնիսկ եթե համոզված եք, որ փոփոխությունն անվնաս է, այն կարող է հանգեցնել սարսափելի հետևանքների:

Կան նաև բազմաթիվ տարբերակներ սերվերներ ստեղծելու համար: Մենք վերջացրինք Python-ի մաքսային սկրիպտների ընտրությունը: Իսկ CI ansible-ի համար.

- name: create1.yml - Create a VM from a template
  vmware_guest:
    hostname: "{{datacenter}}".domain.ru
    username: "{{ username_vc }}"
    password: "{{ password_vc }}"
    validate_certs: no
    cluster: "{{cluster}}"
    datacenter: "{{datacenter}}"
    name: "{{ name }}"
    state: poweredon
    folder: "/{{folder}}"
    template: "{{template}}"
    customization:
      hostname: "{{ name }}"
      domain: domain.ru
      dns_servers:
        - "{{ ipa1_dns }}"
        - "{{ ipa2_dns }}"
    networks:
      - name: "{{ network }}"
        type: static
        ip: "{{ip}}"
        netmask: "{{netmask}}"
        gateway: "{{gateway}}"
        wake_on_lan: True
        start_connected: True
        allow_guest_control: True
    wait_for_ip_address: yes
    disk:
      - size_gb: 1
        type: thin
        datastore: "{{datastore}}"
      - size_gb: 20
        type: thin
        datastore: "{{datastore}}"

Սրան ենք եկել, համակարգը շարունակում է ապրել ու զարգանալ։

17 Հասանելի դերեր՝ սերվերը կարգավորելու համար: Դերերից յուրաքանչյուրը նախատեսված է առանձին տրամաբանական առաջադրանք լուծելու համար (գրանցում, աուդիտ, օգտագործողի թույլտվություն, մոնիտորինգ և այլն):
Դերերի փորձարկում. Մոլեկուլ + TestInfra.
Սեփական զարգացում. CMDB + նվագախումբ:
Սերվերի ստեղծման ժամանակը ~30 րոպե է, ավտոմատացված և գործնականում անկախ առաջադրանքների հերթից:
Ենթակառուցվածքի նույն վիճակը/անվանումը բոլոր սեգմենտներում՝ գրքույկներ, պահոցներ, վիրտուալացման տարրեր:
Սերվերի կարգավիճակի ամենօրյա ստուգում ստանդարտի հետ անհամապատասխանությունների վերաբերյալ հաշվետվությունների ստեղծմամբ:

Հուսով եմ, որ իմ պատմությունը օգտակար կլինի նրանց համար, ովքեր գտնվում են իրենց ճանապարհորդության սկզբում: Ավտոմատացման ո՞ր փաթեթն եք օգտագործում:

Source: www.habr.com

«Սկսնակից» մինչև հազարավոր սերվերներ տասնյակ տվյալների կենտրոններում: Ինչպես մենք հետապնդեցինք Linux ենթակառուցվածքի աճը