Ազնվորեն ու հեշտությամբ գործարկում ենք Tarantool Cartridge-ի հավելվածները (պահեստ 1)

Մենք արդեն խոսել ենք Tarantool Cartridge, որն իրավասու է մշակել բաշխված ծրագրեր և փաթեթավորել դրանք: Միայն մի բան է մնացել՝ սովորել այս ծրագրերի տեղադրումը և կառվարչումը: Մի անհանգստացեք, մենք ամեն բան սպասարկել ենք: Մենք միասին հավաքել ենք Tarantool Cartridge-ի վերաբերյալ բոլոր լավագույն պրակտիկաները և գրել ansible-հաղորդակցություն, որը կմեկնարկի փաթեթը սերվերներում, կսկսի ինստանցները, կհամախմբի դրանք կլաստերը, կնպաստի հեղինակությանը, կօգտագործի vshard-ը, կշարունակի ավտոմատ failover և կթարմացնի կլաստերի կոնֆիգուրացիան:

Հետաքրքիր է? Ուրեմն անցեք ստորև, մենք ամեն բան կպատմենք և ցույց կտանք:

Մեր օրինակով սկսենք

Մենք կքննարկենք միայն մեր հաղորդակցության կոմպլեքսի մասը: Նախանմուշի բոլորը հնարավորությունները և մուտքի պարամետրերը միշտ կարող եք գտնել փաստաթղթավորումը. Բայց ավելի լավ է 한번 փորձել, քան ևս հարյուր անգամ տեսնել, թե ասում են, որ թողնենք փոքր ծրագիր:

Tarantool Cartridge-ն ունի տուրյալ փոքր Cartridge-ծրագրի ստեղծման մասին, որը պահում է բանկի հաճախորդների և նրանց հաշվի տեղեկությունները, ինչպես նաև տրամադրում է API տվյալների կառավարման համար HTTP-ի միջոցով: Այդ նպատակով ծրագրում նկարագրված են երկու հնարավոր դերեր: api և պահեստը, որոնք կարող են նշանակվել ինստանցներին:

Ձեռնարկությունը ինքնին որևէ բան չի ասում այն մասին, թե ինչպես պետք է գործարկել գործընթացները, միայն հնարավորություն է տալիս արդեն մեկնարկված ինստանցների կարգավորելով: Ուղեկցողն այլ հարց է՝ ստանալ կոնֆիգուրացիոն ֆայլերն, գործարկել ծառայությունները և կարգաբերել թոփոլոգիան: Բայց մենք չենք զբաղվի այդ ամենով, դրա փոխարեն դա կանի Ansible:

Աշխատանքին

Ուրեմն, թողեք մեր ծրագիրը տեղադրենք երկու վիրտուալ մեքենաների վրա և կարգավորենք պարզ թոփոլոգիա:

Ռեպլիկասեթը app-1 կիրառի դերը api, որը ներառում է դերը vshard-router. Այստեղ միայն մեկ ինստանց կլինի:
Ռեպլիկասեթը storage-1 կիրառի դերը պահեստը (և միաժամանակ vshard-storage), այստեղ հավելենք երկու ինստանց տարբեր մեքենաներից:

Ազնվորեն ու հեշտությամբ գործարկում ենք Tarantool Cartridge-ի հավելվածները (պահեստ 1)

Օրինակն գործարկելու համար մեզ անհրաժեշտ է Vagrant և Ansible (2.8 կամ ավելի հին տարբերակներ):

Հաղորդակցությունը գտնվում է Ansible Galaxy-ում. Սա մի պահեստ է, որը թույլ է տալիս կիսել ձեր աշխատանքները և օգտագործել պատրաստված հաղորդակցությունները:

Կլոնենք օրինակով իրավունքը:

$ git clone https://github.com/dokshina/deploy-tarantool-cartridge-app.git
$ cd deploy-tarantool-cartridge-app && git checkout 1.0.0

Առաջարկենք վիրտուալ մեքենաները:

$ vagrant up

Կտեղադրենք Tarantool Cartridge ansible-հաղորդակցությունը:

$ ansible-galaxy install tarantool.cartridge,1.0.1

Կսկսենք տեղադրված հաղորդակցությունը:

$ ansible-playbook -i hosts.yml playbook.yml

Սպասենք վերջանալուն, անցնենք դեպի http://localhost:8181/admin/cluster/dashboard և վայելենք արդյունքը:

Ազնվորեն ու հեշտությամբ գործարկում ենք Tarantool Cartridge-ի հավելվածները (պահեստ 1)

Կարող ենք տվյալներ ավելացնել: Մարզիկ չէ՞, իսկ правда?

Եվ հիմա եկեք քննարկենք, ինչպես աշխատել այդ մասին, և միանգամից ավելացնենք մեկ այլ ռեպլիկասեթ թոփոլոգիային:

Սկսենք որոշել

Ուրեմն, ինչ է տեղի ունեցել?

Մենք բացել ենք երկու վիրտուալ մեքենաներ և մեկնարկել ենք ansible-հաղորդակը, որը կարգավորեց մեր կլաստերը: Եկեք նայենք ֆայլի բովանդակությունը playbook.yml:

---
- name: Իշխանել իմ Tarantool Cartridge հավելվածը
  hosts: all
  become: true
  become_user: root
  tasks:
  - name: Ներմուծել Tarantool Cartridge դեր
    import_role:
      name: tarantool.cartridge

Այստեղ ոչինչ հետաքրքիր չի տեղի ունենում, գործարկում ենք ansible-դերը, որը կոչվում է tarantool.cartridge.

Ամենակարևոր բաները (հատկապես, կլաստերի կոնֆիգուրացիան) գտնվում են inventory-ֆայլում hosts.yml:

---
all:
  vars:
    # ընդհանուր կլաստերի փոփոխականներ
    cartridge_app_name: getting-started-app
    cartridge_package_path: .\/getting-started-app-1.0.0-0.rpm  # փաթեթի ճանապարհ

    cartridge_cluster_cookie: app-default-cookie  # կլաստերի բլոկ 

    # ընդհանուր ssh տարբերակներ
    ansible_ssh_private_key_file: ~\/\.vagrant.d\/insecure_private_key
    ansible_ssh_common_args: '-o IdentitiesOnly=yes -o UserKnownHostsFile=\/dev\/null -o StrictHostKeyChecking=no'

  # ԻՆՍՏԱՆՍՆԵՐ
  hosts:
    storage-1:
      config:
        advertise_uri: '172.19.0.2:3301'
        http_port: 8181

    app-1:
      config:
        advertise_uri: '172.19.0.3:3301'
        http_port: 8182

    storage-1-replica:
      config:
        advertise_uri: '172.19.0.3:3302'
        http_port: 8183

  children:
    # Խմբավորել ԻՆՍՏԱՆՍՆԵՐԸ ՏԱՐԱՆՔՆԵՐՈՎ
    host1:
      vars:
        # առաջին մեքենայի միացման տարբերակներ
        ansible_host: 172.19.0.2
        ansible_user: vagrant

      hosts:  # առաջին մեքենայում սկսվող ինսթանսներ
        storage-1:

    host2:
      vars:
        # երկրորդ մեքենայի միացման տարբերակներ
        ansible_host: 172.19.0.3
        ansible_user: vagrant

      hosts:  # երկրորդ մեքենայում սկսվող ինսթանսներ
        app-1:
        storage-1-replica:

    # Խմբավորել ԻՆՍՏԱՆՍՆԵՐԸ ՎԵՐԱՆՎԱՌԻ ՀԱՄԱՐ
    replicaset_app_1:
      vars:  # վերանայման հավաքականների կոնֆիգուրացիա
        replicaset_alias: app-1
        failover_priority:
          - app-1  # ղեկավարը
        roles:
          - 'api'

      hosts:  # ձեռք բերված հավաքականների ինսթանսներ
        app-1:

    replicaset_storage_1:
      vars:  # վերանայման հավաքականների կոնֆիգուրացիա
        replicaset_alias: storage-1
        weight: 3
        failover_priority:
          - storage-1  # ղեկավարը
          - storage-1-replica
        roles:
          - 'storage'

      hosts:   # ձեռք բերված հավաքականների ինսԹանսներ
        storage-1:
        storage-1-replica:

Ամեն ինչ, ինչ մեզ պետք է, դա սովորել ինսթանսներ և վերանայման հավաքականներ կառավարել, փոխելով այս ֆայլի պարունակությունը: Հաջողությամբ, մենք նոր հատվածներ կհավելենք դրան: Շփոթվելուց խուսափելու համար, կարող եք նայել այն ֆայլի վերջին տարբերակին, hosts.updated.yml, որը գտնվում է օրինակների ապարատին։

Ինսթանսների կառավարում

Ansible- ի պայմաններում, յուրաքանչյուրը ինսթանս դա հոստ է (չ confund նույնացնել ռիսկային սերվերի հետ), այսինքն` ենթակառուցվածքի այն հանգույցը, որը Ansible- ը կառավարման համար օգտագործում է։ Յուրաքանչյուր հոսի համար մենք կարող ենք նշել միացման պարամետրերը (օրինակ, ansible_host և ansible_user), ինչպես նաև ինսթանսի կոնֆիգուրացիան։ ԻնՍՏԱՆՍների նկարագրությունը գտնվում է hosts.

Եկեք քննարկենք ինսթանսի կոնֆիգուրացիան storage-1:

all:
  vars:
    ...

  # ԻՆՍՏԱՆՍՆԵՐ
  hosts:
    storage-1:
      config:
        advertise_uri: '172.19.0.2:3301'
        http_port: 8181

  ...

Վնասված է config մենք նշել ենք ինսթանսի պարամետրերը՝ advertise URI և HTTP պորտ.
Ստորև գտնվում են ինսթանսների պարամետրերը app-1 և storage-1-replica.

Մեզ անհրաժեշտ է տեղեկացնել Ansible- ին յուրաքանչյուր ինսթանսի միացման պարամետրերը։ Շատ նորմալ է, որ ինսթանսները խմբավորել միմյանց շուրջ վիրտուալ մեքենաների՝, որպեսզի այդ նպատակով ինսթանսները բաժանվել են խմբերի host1 և host2, և յուրաքանչյուր խմբում 'vars' բաժնում նշված են արժեքները մի վիրտուալ մեքենայի համար։ Եվ 'hosts' ստորաբաժանումում նշված են այն հոսթերը (այն նույն ինսթանսները), որոնք ընդգրկված են այդ խմբում: ansible_host և ansible_user для одной виртуалки. А в секции hosts — хосты (они же инстансы), которые входят в эту группу:

բոլորը:
  փոփոխականներ:
    ...
  հյուրընկալողները:
    ...
  երեխաներ:
    # Խմբավորել ինստանցները մեքենաների համաձայն
    հյուրընկալող1:
      փոփոխականներ:
        # առաջին մեքենայի միացման ընտրանքները
        ansible_host: 172.19.0.2
        ansible_user: vagrant
       հյուրընկալողներ:  # առաջին մեքենայում սկսվելու ինստանցներ
        storage-1:

     հյուրընկալող2:
      փոփոխականներ:
        # երկրորդ մեքենայի միացման ընտրանքները
        ansible_host: 172.19.0.3
        ansible_user: vagrant
       հյուրընկալողներ:  # երկրորդ մեքենայում սկսվելու ինստանցներ
        app-1:
        storage-1-replica:

Սկսում ենք փոփոխություններ անել hosts.yml. Ավելացնենք ևս երկու ինստանցներ, storage-2-replica առաջին վիրտուալ մեքենայում և storage-2 օգտագործելը:

բոլորը:
  փոփոխականներ:
    ...

  # ԻՆՍՏԱՆՑՆԵՐ
  հյուրընկալողները:
    ...
    storage-2:  # <==
      կազմություն:
        advertise_uri: '172.19.0.3:3303'
        http_port: 8184

    storage-2-replica:  # <==
      կազմություն:
        advertise_uri: '172.19.0.2:3302'
        http_port: 8185

  երեխաներ:
    # Խմբավորել ինստանցները մեքենաների համաձայն
    հյուրընկալող1:
      փոփոխականներ:
        ...
      հյուրընկալողներ:  # առաջին մեքենայում սկսվող ինստանցները
        storage-1:
        storage-2-replica:  # <==

    հյուրընկալող2:
      փոփոխականներ:
        ...
      հյուրընկալողներ:  # երկրորդ մեքենայում սկսվելու ինստանցներ
        app-1:
        storage-1-replica:
        storage-2:  # <==
  ...

Սկսում ենք ansible-խաղաթուղթը:

$ ansible-playbook -i hosts.yml 
                   --limit storage-2,storage-2-replica 
                   playbook.yml

Նկատի ունեցեք ընտրությունը --limit. Քանի որ յուրաքանչյուր ինստանց կլաստերը համարվում է հյուրընկալող Ansible-ի իմաստով, մենք կարող ենք հստակ նշել, որ ինստանցներն են պետք կարգավորել խաղաթուղթը իրականացնելու ժամանակ:

Նորից մտնում ենք Web UI http://localhost:8181/admin/cluster/dashboard և դիտենք մեր նոր ինստանցները:

Ազնվորեն ու հեշտությամբ գործարկում ենք Tarantool Cartridge-ի հավելվածները (պահեստ 1)

Մի կանգ առնենք ձեռքբերումների վրա և մուտք գործենք տոպոլոգիայի կառավարում:

Տոպոլոգիայի կառավարում

Միավորենք մեր նոր ինստանցները replicaset-ի մեջ storage-2. Ավելացնենք նոր խումբ replicaset_storage_2 և նկարագրենք դրա փոփոխականներում replicaset-ի պարամետրերը, ինչպես զանգվածաբար նկարագրված replicaset_storage_1. Ընդհանուրում, hosts նշել, թե որ ինստանցները մտնում են այս խմբի մեջ (այսինքն, մեր replicaset):

---
բոլորը:
  փոփոխականներ:
    ...
  հյուրընկալողները:
    ...
  երեխաներ:
    ...
    # Խմբավորել ինստանցները replicaset-ների համաձայն
    ...
    replicaset_storage_2:  # <==
      փոփոխականներ:  # replicaset-ի կազմավորում
        replicaset_alias: storage-2
        քաշ: 2
        անհաջողության առաջնապահություն:
          - storage-2
          - storage-2-replica
        դերեր:
          - 'storage'

      հյուրընկալողներ:   # replicaset-ի ինստանցները
        storage-2:
        storage-2-replica:

Նորից գործարկենք խաղաթուղթը:

$ ansible-playbook -i hosts.yml 
                   --limit replicaset_storage_2 
                   --tags cartridge-replicasets 
                   playbook.yml

Այս անգամ պարամետրին --limit հայտարարել ենք խմբի անունը, որը համապատասխանում է մեր replicaset-ին:

Պատկեք ընտրությունը tags.

Մեր դերերըSequentially գործարկում են տարբեր առաջադրանքներ, որոնք պիտակվում են հետևյալ նշաններով:

cartridge-instances: ինստանցների կառավարում (համակարգերի կարգավորում, միացում membership-ի);
cartridge-replicasets: տոպոլոգիայի կառավարում (replicaset-ների կառավարում և այլևս անվերադարձ հեռացում (expel) ինստանցներից կլաստերից);
cartridge-config: կլաստերի մնացած պարամետրերի կառավարում (vshard bootstrapping, ինքնավար անհաջողության ռեժիմ, մուտքի պարամետրեր և ծրագրի կազմավորում):

Մենք կարող ենք հստակ նշեցնել, թե որ աշխատանքը ուզում ենք անել, որի դեպքում դերերը կբաց թողնի մնացած առաջադրանքների կատարումը: Մեր դեպքում, մենք ուզում ենք աշխատել միայն տոպոլոգիայի վրա, ուստի նշեցինք cartridge-replicasets.

Եկեք գնահատեմ մեր ջանքերի արդյունքը: Դիտենք նոր replicaset-ը http://localhost:8181/admin/cluster/dashboard.

Ազնվորեն ու հեշտությամբ գործարկում ենք Tarantool Cartridge-ի հավելվածները (պահեստ 1)

Հուրա!

Փորձեք փոփոխել ինստանսների և կրկնօրինակման կազմաձևերը և տեսեք, թե ինչպես է փոխվում կանխատեսումը: Դուք կարող եք փորձարկել տարբեր շահագործման սցենարներ, օրինակ, եշեք թարմացում կամ ավելացնել memtx_memory. Ռոլը կփորձի անել դա առանց ինստանսի վերագործարկման, որպեսզի նվազեցնի ձեր ծրագրի հնարավոր դաունթայմը:

Մրս էիք մի բանը, որ vagrant halt, որպեսզի կանգնեցնեք վիրտուալները, երբ ավարտեք դրանց հետ աշխատելը:

Ի՞նչ կա «կափարիչի» ներքևում.

Ահա, թե ինչ է տեղի ունենում «կափարիչի» ներքևում ansible-ռոլի ժամանակ մեր փորձարկումների ընթացքում:

Եկեք քայլերով դիտարկենք Cartridge-հաղորդակցման տեղադրումը:

Փաթեթի տեղադրում և ինստանսների սկսումով

Նախ անհրաժեշտ է հասցնել փաթեթը սերվերին և տեղադրել այն: Այժմ ռոլը կարող է աշխատել RPM և DEB փաթեթների հետ:

Այժմ սկսում ենք ինստանսները: Այստեղ ամեն ինչ շատ պարզ է. յուրաքանչյուր ինստանս՝ սա առանձին systemd-ծառայություն: Պատասխանատու եմ օրինակով:

$ systemctl start myapp@storage-1

Այս հրամանը կսկսի ինստանսը. storage-1 ծրագրային ապահովումը myappՄիացրած ինստանսը կփնտրի իր կոնֆիգուրացիան մեջ /etc/tarantool/conf.d/. Ինստանսի լոգերը կարելի է տեսնել journald.

Unit-ֆայլը /etc/systemd/system/myapp@.sevice systemd-ծառայության համար կփոխանցվի փաթեթի հետ:

Ansible-ում կա встроенные մոդուլներ փաթեթների տեղադրման և systemd-ծառայությունների կառավարման համար, այստեղ նոր բան չենք հորինել:

Կլաստերի կազմը

Ահա այստեղ իսկապես հետաքրքրաշարժ է: Համաձայնեք, տարօրինակ կլինի, եթե կարևորենք հատուկ ansible-ռոլը փաթեթների տեղադրման և սկսումով systemd-ծառայությունների համար:

Կլաստերը կարելի է կարգավորել ձեռքով:

Առաջին տարբերակը. բացում ենք Web UI-ն և սեղմում կոճակներին. Խնդիրների դաշտում մի քանի ինստանսների一次ական սկսելիս, այս հիանալի կլինի:
Երկրորդ տարբերակը. կարելի է օգտվել GraphQl API-ից: Այստեղ կարող եք ավտոմատացնել մի բան, օրինակ, գրել Python-ի սկրիպտ:
Երրորդ տարբերակը (բարձր ոգով): մուտք է գործել սերվեր, միանալ որևէ ինստանսի միջոցով tarantoolctl connect և կատարել անհրաժեշտ գործողությունները Lua-ի մոդուլի cartridge.

Հիմնական նպատակն մեր հնարքի — անել ձեզ համար հենց այս, ամենադժվար մասը:

Ansible-ն թույլ է տալիս գրել ձեր մոդուլն ու օգտագործել այն վոլում: Մեր ռոլը օգտագործում է այդպիսի մոդուլներ՝ տարբեր կլաստեր բաղադրիչները կառավարելու համար:

Ինչպե՞ս է դա աշխատում: Դուք նկարագրում եք ցանկալի կլաստերի վիճակը դեկլարատիվ configs-ում, իսկ ռոլը առաջարկում է յուրաքանչյուր մոդուլին իր կոնֆիգի մասը: Մոդուլն ստանում է կլաստերի ներկա վիճակը և համեմատում նրան մուտքագրվածի հետ: Հետո մեկի ինստանսի միջոցով սոքիտի միջոցով запускается код, որը բերում է կլաստերը ցանկալի վիճակին:

Եզրակացություններ

Այսօր մենք պատմեցինք և ցույց տվեցինք, թե ինչպես պետք է տեղադրել ձեր կիրառումը Tarantool Cartridge-ում և կարգավորել պարզTopology։ Դա անելու համար մենք օգտագործեցինք Ansible-ն՝ հզոր գործիք, որն առանձնանում է օգտագործման հեշտությամբ և թույլ է տալիս միաժամանակ կարգավորել բազմաթիվ ենթակառուցվածքների узлы (մեր դեպքում՝ կլաստերի ինստանցներ):

Վերներս մենք ուսումնասիրեցինք կլաստերի կոնֆիգուրացիայի նկարագրության բազմաթիվ միջոցներից մեկը Ansible-ի միջոցով։ Երբ զգաք, որ պատրաստ եք առաջ մղվել, ուսումադեք նշանակված լավագույն պրակտիկաներ փլեյբուքների գրեթե։ Հնարավոր է, որ ձեր համար ավելի հարմար կլինի կառավարելTopology group_vars և host_vars.

Շուտով մենք պատմելու ենք, թե ինչպես կարող եք հավերժական կերպով դուրս հանել (expel) ինստանցներTopology- ում, Bootstrap անել vshard-ը, կառավարել ավտոմատ failover ռեժիմը, կարգավորել մակագրություն և պաչնչել կլաստերի եզրակացությունը: Մինչ այդ, կարող եք ինքնուրույն ուսումնասիրել փաթեթավորում և փորձարկել կլաստերի պարամետրերի փոփոխությունները:

Եթե որևէ բան չի աշխատում, ուրախությամբ օգնեք մեզ պրոբլեմի մասին։ Մենք արագորեն ամեն ինչ կլուծենք!

Ընտանիք: habr.com