Viegli un dabiski izvietojiet lietojumprogrammas Tarantool kasetnē (1. daļa)

Viegli un dabiski izvietojiet lietojumprogrammas Tarantool kasetnē (1. daļa)

Mēs jau esam runājuÅ”i par Tarantool kārtridžs, kas ļauj izstrādāt izplatÄ«tas lietojumprogrammas un iepakot tās. Atliek tikai uzzināt, kā izvietot Ŕīs lietojumprogrammas un tās pārvaldÄ«t. Neuztraucieties, mēs to visu esam nokārtojuÅ”i! Mēs apkopojām visu paraugpraksi darbam ar Tarantool Cartridge un uzrakstÄ«jām iespējamā loma, kas izplatÄ«s pakotni serveriem, palaidÄ«s gadÄ«jumus, apvienos tos klasterÄ«, konfigurēs autorizāciju, bootstrap vshard, iespējos automātisko kļūmjpārlēci un izlabos klastera konfigurāciju.

Interesanti? Tad, lūdzu, zem griezuma mēs jums visu pastāstīsim un parādīsim.

Sāksim ar piemēru

Mēs apskatīsim tikai daļu no mūsu lomas funkcionalitātes. Jūs vienmēr varat atrast pilnīgu visu tā iespēju un ievades parametru aprakstu dokumentācija. Bet labāk ir mēģināt vienu reizi, nekā redzēt to simts reizes, tāpēc izvietosim nelielu lietojumprogrammu.

Tarantool kārtridžā ir pamācÄ«ba izveidot nelielu Kasetņu aplikāciju, kas glabā informāciju par bankas klientiem un viņu kontiem, kā arÄ« nodroÅ”ina API datu pārvaldÄ«bai caur HTTP. Lai to panāktu, pielikumā ir aprakstÄ«tas divas iespējamās lomas: api Šø storage, ko var pieŔķirt gadÄ«jumiem.

Kasetne pati par sevi neko nesaka par procesu palaiÅ”anu, tikai nodroÅ”ina iespēju konfigurēt jau darbojoŔās instances. Pārējais lietotājam jādara paÅ”am: jāsakārto konfigurācijas faili, jāuzsāk pakalpojumi un jākonfigurē topoloÄ£ija. Bet mēs to visu nedarÄ«sim; Ansible to izdarÄ«s mÅ«su vietā.

No vārdiem uz darbiem

Tātad, izvietosim savu lietojumprogrammu divās virtuālajās maŔīnās un iestatīsim vienkārŔu topoloģiju:

  • Replicat app-1 Ä«stenos lomu api, kas ietver lomu vshard-router. Å eit bÅ«s tikai viens gadÄ«jums.
  • Replicat storage-1 Ä«steno lomu storage (un tajā paŔā laikā vshard-storage), Å”eit mēs pievienosim divus gadÄ«jumus no dažādām iekārtām.

Viegli un dabiski izvietojiet lietojumprogrammas Tarantool kasetnē (1. daļa)

Lai palaistu mums vajadzÄ«go piemēru Vagrant Šø Iespējams (versija 2.8 vai vecāka).

Pati loma ir iekŔā Ansible Galaxy. Šī ir krātuve, kas ļauj dalīties ar savu darbu un izmantot gatavas lomas.

Klonēsim repozitoriju ar piemēru:

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

Mēs izvirzām virtuālās maŔīnas:

$ vagrant up

Uzstādiet Tarantool kasetnes iespējamo lomu:

$ ansible-galaxy install tarantool.cartridge,1.0.1

Palaidiet instalēto lomu:

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

Mēs gaidām, līdz rokasgrāmata pabeigs izpildi, dodieties uz http://localhost:8181/admin/cluster/dashboard un izbaudi rezultātu:

Viegli un dabiski izvietojiet lietojumprogrammas Tarantool kasetnē (1. daļa)

Varat augÅ”upielādēt datus. ForÅ”i, vai ne?

Tagad izdomāsim, kā ar to strādāt, un tajā paŔā laikā topoloģijai pievienosim citu kopiju kopu.

Sāksim to izdomāt

Kas tad notika?

Mēs iestatÄ«jām divas virtuālās maŔīnas un izlaidām iespējamu rokasgrāmatu, kas konfigurēja mÅ«su kopu. ApskatÄ«sim faila saturu playbook.yml:

---
- name: Deploy my Tarantool Cartridge app
  hosts: all
  become: true
  become_user: root
  tasks:
  - name: Import Tarantool Cartridge role
    import_role:
      name: tarantool.cartridge

Nekas interesants te nenotiek, palaidīsim saprātīgu lomu ar nosaukumu tarantool.cartridge.

Visas svarīgākās lietas (proti, klastera konfigurācija) atrodas inventārs- fails hosts.yml:

---
all:
  vars:
    # common cluster variables
    cartridge_app_name: getting-started-app
    cartridge_package_path: ./getting-started-app-1.0.0-0.rpm  # path to package

    cartridge_cluster_cookie: app-default-cookie  # cluster cookie

    # common ssh options
    ansible_ssh_private_key_file: ~/.vagrant.d/insecure_private_key
    ansible_ssh_common_args: '-o IdentitiesOnly=yes -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no'

  # INSTANCES
  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:
    # GROUP INSTANCES BY MACHINES
    host1:
      vars:
        # first machine connection options
        ansible_host: 172.19.0.2
        ansible_user: vagrant

      hosts:  # instances to be started on the first machine
        storage-1:

    host2:
      vars:
        # second machine connection options
        ansible_host: 172.19.0.3
        ansible_user: vagrant

      hosts:  # instances to be started on the second machine
        app-1:
        storage-1-replica:

    # GROUP INSTANCES BY REPLICA SETS
    replicaset_app_1:
      vars:  # replica set configuration
        replicaset_alias: app-1
        failover_priority:
          - app-1  # leader
        roles:
          - 'api'

      hosts:  # replica set instances
        app-1:

    replicaset_storage_1:
      vars:  # replica set configuration
        replicaset_alias: storage-1
        weight: 3
        failover_priority:
          - storage-1  # leader
          - storage-1-replica
        roles:
          - 'storage'

      hosts:   # replica set instances
        storage-1:
        storage-1-replica:

Viss, kas mums nepiecieÅ”ams, ir iemācÄ«ties pārvaldÄ«t gadÄ«jumus un replikātus, mainot Ŕī faila saturu. Tālāk mēs tai pievienosim jaunas sadaļas. Lai neapjuktu, kur tos pievienot, varat apskatÄ«t Ŕī faila galÄ«go versiju, hosts.updated.yml, kas atrodas piemēru repozitorijā.

Instanču vadība

Ansible izteiksmē katrs gadÄ«jums ir resursdators (nejaukt ar aparatÅ«ras serveri), t.i. infrastruktÅ«ras mezgls, ko Ansible pārvaldÄ«s. Katram resursdatoram mēs varam norādÄ«t savienojuma parametrus (piemēram, ansible_host Šø ansible_user), kā arÄ« instances konfigurāciju. GadÄ«jumu apraksts ir sadaļā hosts.

Apskatīsim gadījuma konfigurāciju storage-1:

all:
  vars:
    ...

  # INSTANCES
  hosts:
    storage-1:
      config:
        advertise_uri: '172.19.0.2:3301'
        http_port: 8181

  ...

MainÄ«gā config mēs norādÄ«jām gadÄ«juma parametrus - advertise URI Šø HTTP port.
Tālāk ir norādÄ«ti gadÄ«jumu parametri app-1 Šø storage-1-replica.

Mums ir jāpasaka Ansible savienojuma parametri katram gadÄ«jumam. Å Ä·iet loÄ£iski grupēt gadÄ«jumus virtuālo maŔīnu grupās. Å im nolÅ«kam gadÄ«jumi tiek apvienoti grupās host1 Šø host2, un katrā sadaļā sadaļā vars vērtÄ«bas ir norādÄ«tas ansible_host Šø ansible_user vienai virtuālajai maŔīnai. Un sadaļā hosts ā€” resursdatori (pazÄ«stami arÄ« kā gadÄ«jumi), kas ir iekļauti Å”ajā grupā:

all:
  vars:
    ...
  hosts:
    ...
  children:
    # GROUP INSTANCES BY MACHINES
    host1:
      vars:
        # first machine connection options
        ansible_host: 172.19.0.2
        ansible_user: vagrant
       hosts:  # instances to be started on the first machine
        storage-1:

     host2:
      vars:
        # second machine connection options
        ansible_host: 172.19.0.3
        ansible_user: vagrant
       hosts:  # instances to be started on the second machine
        app-1:
        storage-1-replica:

Mēs sākam mainÄ«ties hosts.yml. Pievienosim vēl divus gadÄ«jumus, storage-2-replica pirmajā virtuālajā maŔīnā un storage-2 Otrajā:

all:
  vars:
    ...

  # INSTANCES
  hosts:
    ...
    storage-2:  # <==
      config:
        advertise_uri: '172.19.0.3:3303'
        http_port: 8184

    storage-2-replica:  # <==
      config:
        advertise_uri: '172.19.0.2:3302'
        http_port: 8185

  children:
    # GROUP INSTANCES BY MACHINES
    host1:
      vars:
        ...
      hosts:  # instances to be started on the first machine
        storage-1:
        storage-2-replica:  # <==

    host2:
      vars:
        ...
      hosts:  # instances to be started on the second machine
        app-1:
        storage-1-replica:
        storage-2:  # <==
  ...

Palaidiet iespējamo rokasgrāmatu:

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

Lūdzu, ņemiet vērā opciju --limit. Tā kā Ansible izteiksmē katrs klastera gadījums ir resursdators, mēs varam skaidri norādīt, kuri gadījumi ir jākonfigurē, izpildot rokasgrāmatu.

AtgrieŔanās pie tīmekļa lietotāja interfeisa http://localhost:8181/admin/cluster/dashboard un skatiet mūsu jaunos gadījumus:

Viegli un dabiski izvietojiet lietojumprogrammas Tarantool kasetnē (1. daļa)

Neapstāsimies pie tā un apgūsim topoloģijas pārvaldību.

Topoloģijas pārvaldība

Apvienosim savus jaunos gadÄ«jumus kopiju komplektā storage-2. Pievienosim jaunu grupu replicaset_storage_2 un apraksta replicaset parametrus tā mainÄ«gajos pēc analoÄ£ijas ar replicaset_storage_1. Sadaļā hosts NorādÄ«sim, kuri gadÄ«jumi tiks iekļauti Å”ajā grupā (tas ir, mÅ«su kopiju komplektā):

---
all:
  vars:
    ...
  hosts:
    ...
  children:
    ...
    # GROUP INSTANCES BY REPLICA SETS
    ...
    replicaset_storage_2:  # <==
      vars:  # replicaset configuration
        replicaset_alias: storage-2
        weight: 2
        failover_priority:
          - storage-2
          - storage-2-replica
        roles:
          - 'storage'

      hosts:   # replicaset instances
        storage-2:
        storage-2-replica:

Sāksim no jauna rokasgrāmatu:

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

Pēc iespējas --limit Šoreiz mēs izturējām grupas nosaukumu, kas atbilst mūsu replikātam.

Apsvērsim variantu tags.

MÅ«su loma secÄ«gi veic dažādus uzdevumus, kas ir atzÄ«mēti ar Ŕādiem tagiem:

  • cartridge-instances: instanču pārvaldÄ«ba (konfigurācija, savienojums ar dalÄ«bu);
  • cartridge-replicasets: topoloÄ£ijas pārvaldÄ«ba (replikātu pārvaldÄ«ba un gadÄ«jumu pastāvÄ«ga noņemÅ”ana (izraidÄ«Å”ana) no klastera);
  • cartridge-config: citu klastera parametru pārvaldÄ«ba (vshard bootstrapping, automātiskais kļūmjpārlēces režīms, autorizācijas parametri un lietojumprogrammas konfigurācija).

Mēs varam skaidri norādīt, kuru darba daļu mēs vēlamies veikt, tad loma izlaidīs pārējos uzdevumus. Mūsu gadījumā mēs vēlamies strādāt tikai ar topoloģiju, tāpēc mēs precizējām cartridge-replicasets.

Novērtēsim mūsu pūļu rezultātu. Mēs atrodam jaunu replikātu http://localhost:8181/admin/cluster/dashboard.

Viegli un dabiski izvietojiet lietojumprogrammas Tarantool kasetnē (1. daļa)

Urā!

Eksperimentējiet, mainot gadÄ«jumu un reprodukciju kopu konfigurāciju, un skatiet, kā mainās klasteru topoloÄ£ija. Varat izmēģināt dažādus darbÄ«bas scenārijus, piem. ritoÅ”ais atjauninājums vai palielināt memtx_memory. Loma mēģinās to izdarÄ«t, nerestartējot gadÄ«jumu, lai samazinātu iespējamo jÅ«su lietojumprogrammas dÄ«kstāvi.

Neaizmirsti skriet vagrant haltlai apturētu virtuālās maŔīnas, kad esat pabeidzis darbu ar tām.

Un kas ir zem pārsega?

Šeit es jums pastāstīŔu vairāk par to, kas mūsu eksperimentu laikā notika zem ansible lomas pārsega.

Apskatīsim soli pa solim lietojumprogrammas Cartridge izvietoŔanu.

Pakotnes instalēŔana un gadījumu palaiŔana

Vispirms jums ir jānogādā pakete uz serveri un jāinstalē. PaÅ”laik loma var darboties ar RPM un DEB pakotnēm.

Tālāk mēs palaižam gadÄ«jumus. Å eit viss ir ļoti vienkārÅ”i: katrs gadÄ«jums ir atseviŔķs systemd-apkalpoÅ”ana. Es sniegÅ”u jums piemēru:

$ systemctl start myapp@storage-1

Å Ä« komanda palaidÄ«s instanci storage-1 progr myapp. Palaistais gadÄ«jums meklēs savu konfigurācija Š² /etc/tarantool/conf.d/. GadÄ«jumu žurnālus var apskatÄ«t, izmantojot journald.

VienÄ«bas fails /etc/systemd/system/[email protected] sistēmai pakalpojums tiks piegādāts kopā ar paku.

Ansible ir iebÅ«vēti moduļi pakotņu instalÄ“Å”anai un sistēmisko pakalpojumu pārvaldÄ«bai; mēs Å”eit neesam izgudrojuÅ”i neko jaunu.

Klasteru topoloģijas iestatīŔana

Å eit sākas jautrÄ«ba. PiekrÄ«tu, bÅ«tu dÄ«vaini apnikt ar Ä«paÅ”u Ansible lomu pakotņu instalÄ“Å”anai un palaiÅ”anai systemd-pakalpojumi.

Klasteru var konfigurēt manuāli:

  • Pirmā iespēja: atveriet Web UI un noklikŔķiniet uz pogām. Tas ir diezgan piemērots vienreizējai vairāku gadÄ«jumu sākumam.
  • Otrā iespēja: varat izmantot GraphQl API. Å eit jau var kaut ko automatizēt, piemēram, uzrakstÄ«t skriptu Python.
  • TreŔā iespēja (spēcÄ«gajiem): dodieties uz serveri, izveidojiet savienojumu ar kādu no gadÄ«jumiem, izmantojot tarantoolctl connect un veiciet visas nepiecieÅ”amās manipulācijas ar Lua moduli cartridge.

Mūsu izgudrojuma galvenais uzdevums ir paveikt tieŔi Ŕo, visgrūtāko darba daļu jūsu vietā.

Ansible ļauj jums uzrakstīt savu moduli un izmantot to lomā. Mūsu loma izmanto Ŕādus moduļus, lai pārvaldītu dažādus klastera komponentus.

Kā tas strādā? JÅ«s aprakstāt vēlamo klastera stāvokli deklaratÄ«vā konfigurācijā, un loma nodroÅ”ina katram modulim konfigurācijas sadaļu kā ievadi. Modulis saņem klastera paÅ”reizējo stāvokli un salÄ«dzina to ar to, kas tika saņemts kā ievade. Pēc tam caur vienas instances ligzdu tiek palaists kods, kas nodroÅ”ina kopu vēlamajā stāvoklÄ«.

Rezultāti

Å odien mēs stāstÄ«jām un parādÄ«jām, kā izvietot lietojumprogrammu Tarantool Cartridge un iestatÄ«t vienkārÅ”u topoloÄ£iju. Lai to izdarÄ«tu, mēs izmantojām Ansible ā€” jaudÄ«gu rÄ«ku, kas ir viegli lietojams un ļauj vienlaikus konfigurēt daudzus infrastruktÅ«ras mezglus (mÅ«su gadÄ«jumā ā€” klasteru gadÄ«jumus).

IepriekÅ” mēs apskatÄ«jām vienu no daudzajiem veidiem, kā aprakstÄ«t klastera konfigurāciju, izmantojot Ansible. Kad jÅ«taties gatavs doties tālāk, izpētiet Labākās prakses par rotaļu grāmatu rakstÄ«Å”anu. Iespējams, jums bÅ«s vieglāk pārvaldÄ«t savu topoloÄ£iju, izmantojot group_vars Šø host_vars.

Ļoti drīz mēs jums pateiksim, kā neatgriezeniski dzēst (izraidīt) gadījumus no topoloģijas, bootstrap vshard, pārvaldīt automātisko kļūmjpārlēces režīmu, konfigurēt autorizāciju un izlabot klastera konfigurāciju. Tikmēr jūs varat mācīties patstāvīgi dokumentācija un eksperimentēt, mainot klastera parametrus.

Ja kaut kas nedarbojas, noteikti informēt mums par problēmu. Ātri visu nokārtosim!

Avots: www.habr.com

Pievieno komentāru