ჩვენ უკვე ვისაუბრეთ ტარანტულის ვაზნა, რომელიც საშუალებას გაძლევთ განავითაროთ განაწილებული აპლიკაციები და შეფუთოთ ისინი. აღარაფერი დარჩა: ისწავლეთ როგორ განათავსოთ და მართოთ ეს აპლიკაციები. არ ინერვიულო, ჩვენ ყველაფერი მოვიფიქრეთ! ჩვენ შევკრიბეთ ყველა საუკეთესო პრაქტიკა Tarantool Cartridge-თან მუშაობისთვის და დავწერეთ საპასუხო როლი, რომელიც დაშლის პაკეტს სერვერებად, დაიწყებს ინსტანციებს, გააერთიანებს მათ კლასტერში, დააკონფიგურირებს ავტორიზაციას, ჩატვირთვის vshard-ს, ჩართავს ავტომატურ შეფერხებას და დააყენებს კლასტერის კონფიგურაციას.

საინტერესოა? მერე ჭრის ქვეშ ვეკითხები, ყველაფერს გეტყვით და ვაჩვენებთ.

დავიწყოთ მაგალითით

ჩვენ გავაშუქებთ ჩვენი როლის ფუნქციონირების მხოლოდ ნაწილს. თქვენ ყოველთვის შეგიძლიათ იპოვოთ მისი ყველა მახასიათებლისა და შეყვანის პარამეტრების სრული აღწერა დოკუმენტაცია. მაგრამ უმჯობესია ერთხელ სცადოთ, ვიდრე ასჯერ ნახოთ, ასე რომ, მოდით განვათავსოთ პატარა აპლიკაცია.

Tarantool ვაზნა აქვს სახელმძღვანელო პატარა კარტრიჯის აპლიკაციის შესაქმნელად, რომელიც ინახავს ინფორმაციას ბანკის კლიენტებისა და მათი ანგარიშების შესახებ, ასევე უზრუნველყოფს API-ს HTTP-ის საშუალებით მონაცემთა მართვისთვის. ამისათვის აპლიკაცია აღწერს ორ შესაძლო როლს: api и storageრომელიც შეიძლება მიენიჭოს ინსტანციებს.

თავად კარტრიჯი არაფერს ამბობს იმაზე, თუ როგორ უნდა დაიწყოს პროცესები, ის მხოლოდ იძლევა უკვე გაშვებული ინსტანციების კონფიგურაციის შესაძლებლობას. მომხმარებელმა დანარჩენი თავად უნდა გააკეთოს: დაშალოს კონფიგურაციის ფაილები, დაიწყოს სერვისები და დააყენოს ტოპოლოგია. მაგრამ ამ ყველაფერს ჩვენ არ გავაკეთებთ, ანსიბლი ამას ჩვენთვის გააკეთებს.

სიტყვებიდან საქმეებამდე

მოდით გავავრცელოთ ჩვენი აპლიკაცია ორ ვირტუალურ მანქანაზე და დავაყენოთ მარტივი ტოპოლოგია:

• რეპლიკასეტი app-1 როლს შეასრულებს apiრომელიც მოიცავს როლს vshard-router. აქ მხოლოდ ერთი შემთხვევა იქნება.
• რეპლიკასეტი storage-1 ახორციელებს როლს storage (და ამავე დროს vshard-storage), აქ დავამატებთ ორ ინსტანციას სხვადასხვა მანქანებიდან.

მაგალითის გასაშვებად, ჩვენ გვჭირდება ვაგროანტი и შეუძლებელია (ვერსია 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-galaxy install tarantool.cartridge,1.0.1

გაუშვით დაინსტალირებული როლი:

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

ველოდებით სათამაშო წიგნის შესრულების დასრულებას, გადადით http://localhost:8181/admin/cluster/dashboard და ისიამოვნეთ შედეგით:

შეგიძლიათ დაასხით მონაცემები. მაგარია, არა?

ახლა მოდით გავარკვიოთ, როგორ ვიმუშაოთ ამით და ამავდროულად დავამატოთ ტოპოლოგიას კიდევ ერთი რეპლიკა.

ჩვენ ვიწყებთ გაგებას

მერე რა მოხდა?

ჩვენ მივიღეთ ორი ვირტუალური მანქანა და გავუშვით მარტივი სათამაშო წიგნი, რომელმაც შექმნა ჩვენი კლასტერი. მოდით შევხედოთ ფაილის შინაარსს 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

აქ არაფერი საინტერესო არ ხდება, ვიწყებთ ansible-role-ს, რომელსაც ე.წ tarantool.cartridge.

ყველა ყველაზე მნიშვნელოვანი (კერძოდ, კლასტერის კონფიგურაცია) მდებარეობს მასში ინვენტარი- ფაილი 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:

ყველაფერი რაც ჩვენ გვჭირდება არის ვისწავლოთ როგორ ვმართოთ ეგზემპლარები და რეპლიკასტები ამ ფაილის შინაარსის შეცვლით. შემდეგი, ჩვენ დავამატებთ მას ახალ განყოფილებებს. იმისათვის, რომ არ დაიბნეთ სად დაამატოთ ისინი, შეგიძლიათ გადახედოთ ამ ფაილის საბოლოო ვერსიას, hosts.updated.yml, რომელიც არის მაგალითის საცავში.

ინსტანციის მენეჯმენტი

Ansible-ის თვალსაზრისით, თითოეული ინსტანცია არის ჰოსტი (არ უნდა აგვერიოს რკინის სერვერთან), ე.ი. ინფრასტრუქტურის კვანძი, რომელსაც Ansible მართავს. თითოეული ჰოსტისთვის, ჩვენ შეგვიძლია მივუთითოთ კავშირის პარამეტრები (როგორიცაა ansible_host и ansible_user), ისევე როგორც ინსტანციის კონფიგურაცია. შემთხვევების აღწერა მოცემულია განყოფილებაში hosts.

განვიხილოთ მაგალითის კონფიგურაცია storage-1:

all:
  vars:
    ...

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

  ...

ცვლადში config ჩვენ დავაზუსტეთ ინსტანციის პარამეტრები - advertise URI и HTTP port.
ქვემოთ მოცემულია ინსტანციის პარამეტრები app-1 и storage-1-replica.

Ansible-ს უნდა ვუთხრათ კავშირის პარამეტრები თითოეული ინსტანციისთვის. როგორც ჩანს, ლოგიკურია ინსტანციების დაჯგუფება ვირტუალური მანქანების ჯგუფებად. ამისათვის ინსტანციები გაერთიანებულია ჯგუფებად. host1 и host2და თითოეულ ჯგუფში განყოფილებაში vars ღირებულებები ansible_host и ansible_user ერთი ვირტუალური მანქანისთვის. და განყოფილებაში hosts - მასპინძლები (ისინი არიან შემთხვევები), რომლებიც შედიან ამ ჯგუფში:

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:

ვიწყებთ შეცვლას hosts.yml. დავამატოთ კიდევ ორი ​​შემთხვევა, storage-2-replica პირველ ვირტუალურ მანქანაზე და storage-2 მეორეზე:

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:  # <==
  ...

გაუშვით ansible სათამაშო წიგნი:

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

ყურადღება მიაქციეთ ვარიანტს --limit. ვინაიდან თითოეული კლასტერული ინსტანცია Ansible ტერმინით არის ჰოსტი, ჩვენ შეგვიძლია ცალსახად განვსაზღვროთ რომელი ინსტანციები უნდა იყოს კონფიგურირებული სათამაშო წიგნის გაშვებისას.

ვებ UI-ზე დაბრუნება http://localhost:8181/admin/cluster/dashboard და დააკვირდით ჩვენს ახალ მაგალითებს:

ჩვენ არ დავისვენებთ და დავეუფლებით ტოპოლოგიის კონტროლს.

ტოპოლოგიის მართვა

მოდით გავაერთიანოთ ჩვენი ახალი ინსტანციები რეპლიკასეტში storage-2. დაამატეთ ახალი ჯგუფი replicaset_storage_2 და აღწერს მის ცვლადებში რეპლიკასის პარამეტრების ანალოგიით replicaset_storage_1. განყოფილებაში hosts მიუთითეთ რომელი ინსტანციები შედის ამ ჯგუფში (ანუ ჩვენი რეპლიკა ნაკრები):

---
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:

მოდით თავიდან დავიწყოთ სათამაშო წიგნი:

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

თითო ვარიანტი --limit ჩვენ ამჯერად გადავეცით ჯგუფის სახელი, რომელიც შეესაბამება ჩვენს რეპლიკასტს.

განიხილეთ ვარიანტი tags.

ჩვენი როლი თანმიმდევრულად ასრულებს სხვადასხვა დავალებებს, რომლებიც აღინიშნება შემდეგი ტეგებით:

• cartridge-instances: ინსტანციის მართვა (კონფიგურაცია, კავშირი წევრობასთან);
• cartridge-replicasets: ტოპოლოგიის მენეჯმენტი (რეპლიკასტების მართვა და კლასტერიდან ინსტანციების მუდმივი ამოღება (გამოდევნა);
• cartridge-config: მართეთ სხვა კლასტერული პარამეტრები (vshard bootstrapping, ავტომატური failover რეჟიმი, ავტორიზაციის პარამეტრები და აპლიკაციის კონფიგურაცია).

ჩვენ შეგვიძლია ცალსახად განვსაზღვროთ სამუშაოს რომელი ნაწილის შესრულება გვინდა, შემდეგ როლი გამოტოვებს დანარჩენ დავალებებს. ჩვენს შემთხვევაში, ჩვენ გვინდა ვიმუშაოთ მხოლოდ ტოპოლოგიით, ამიტომ დავაზუსტეთ cartridge-replicasets.

შევაფასოთ ჩვენი ძალისხმევის შედეგი. ახალი რეპლიკასის პოვნა http://localhost:8181/admin/cluster/dashboard.

Hooray!

ექსპერიმენტი ჩაატარეთ ინსტანციების და რეპლიკასტების ხელახალი კონფიგურაცია და ნახეთ, როგორ იცვლება კასეტური ტოპოლოგია. შეგიძლიათ სცადოთ სხვადასხვა ოპერაციული სცენარი, მაგალითად, მოძრავი განახლება ან გაზრდის memtx_memory. როლი შეეცდება ამის გაკეთებას ინსტანციის გადატვირთვის გარეშე, რათა შეამციროს თქვენი განაცხადის შესაძლო შეფერხების დრო.

არ დაგავიწყდეთ სირბილი vagrant haltრათა შეაჩერონ VM-ები, როცა დაასრულებ მათ.

რა არის კაპოტის ქვეშ?

აქ უფრო მეტს ვისაუბრებ იმაზე, რაც მოხდა ჩვენი ექსპერიმენტების დროს გონივრული როლის ქვეშ.

მოდით შევხედოთ კარტრიჯის აპლიკაციის განლაგებას ეტაპობრივად.

პაკეტის დაყენება და ინსტანციების დაწყება

ჯერ თქვენ უნდა მიაწოდოთ პაკეტი სერვერს და დააინსტალიროთ იგი. ახლა როლს შეუძლია იმუშაოს RPM და DEB პაკეტებით.

შემდეგი, ჩვენ ვიწყებთ ინსტანციებს. აქ ყველაფერი ძალიან მარტივია: თითოეული ინსტანცია ცალკეა systemd- სერვისი. მე ვსაუბრობ მაგალითზე:

$ systemctl start myapp@storage-1

ეს ბრძანება დაიწყებს მაგალითს storage-1 apps myapp. გაშვებული ინსტანცია მოძებნის მას კონფიგურაცია в /etc/tarantool/conf.d/. მაგალითების ჟურნალების ნახვა შესაძლებელია გამოყენებით journald.

ერთეულის ფაილი /etc/systemd/system/[email protected] სისტემური სერვისისთვის მიწოდებული იქნება პაკეტით.

Ansible-ს აქვს ჩაშენებული მოდულები პაკეტების დაყენებისა და სისტემური სერვისების მართვისთვის, ჩვენ აქ ახალი არაფერი გამოგვიგონია.

კასეტური ტოპოლოგიის კონფიგურაცია

და აქ იწყება ყველაზე საინტერესო. დამეთანხმებით, უცნაური იქნებოდა შეწუხება პაკეტების ინსტალაციისა და გაშვებისთვის სპეციალური ცალსახა როლით systemd-მომსახურებები.

თქვენ შეგიძლიათ დააყენოთ კლასტერი ხელით:

• პირველი ვარიანტი: გახსენით Web UI და დააწკაპუნეთ ღილაკებზე. რამდენიმე ინსტანციის ერთჯერადი დაწყებისთვის, ეს საკმაოდ შესაფერისია.
• მეორე ვარიანტი: შეგიძლიათ გამოიყენოთ GraphQl API. აქ უკვე შეგიძლიათ რაღაცის ავტომატიზაცია, მაგალითად, დაწეროთ სკრიპტი პითონში.
• მესამე ვარიანტი (სულით ძლიერებისთვის): გადადით სერვერზე, დაუკავშირდით ერთ-ერთ ინსტანციას გამოყენებით tarantoolctl connect და შეასრულეთ ყველა საჭირო მანიპულაცია ლუას მოდულით cartridge.

ჩვენი გამოგონების მთავარი ამოცანაა ეს, თქვენთვის სამუშაოს ყველაზე რთული ნაწილი.

Ansible გაძლევთ საშუალებას დაწეროთ საკუთარი მოდული და გამოიყენოთ იგი როლებში. ჩვენი როლი იყენებს ასეთ მოდულებს კლასტერის სხვადასხვა კომპონენტების სამართავად.

Როგორ მუშაობს? თქვენ აღწერთ კლასტერის სასურველ მდგომარეობას დეკლარაციულ კონფიგურაციაში და როლი თითოეულ მოდულს აძლევს კონფიგურაციის განყოფილებას, როგორც შეყვანის სახით. მოდული იღებს კლასტერის მიმდინარე მდგომარეობას და ადარებს მას შეყვანასთან. შემდეგი, კოდი გადის ერთ-ერთი ინსტანციის სოკეტში, რომელიც კლასტერს სასურველ მდგომარეობამდე მიაქვს.

შედეგები

დღეს ჩვენ ვუთხარით და ვაჩვენეთ, თუ როგორ უნდა განათავსოთ თქვენი აპლიკაცია Tarantool Cartridge-ზე და დავაყენოთ მარტივი ტოპოლოგია. ამისათვის ჩვენ გამოვიყენეთ Ansible, მძლავრი ინსტრუმენტი, რომელიც მარტივი გამოსაყენებელია და საშუალებას გაძლევთ ერთდროულად დააკონფიგურიროთ მრავალი ინფრასტრუქტურული კვანძი (ჩვენს შემთხვევაში, ეს არის კლასტერული შემთხვევები).

ზემოთ, ჩვენ განვიხილეთ კასეტური კონფიგურაციის აღწერის მრავალი გზა Ansible-ის გამოყენებით. როგორც კი გაიგებთ, რომ მზად ხართ წინსვლისთვის, ისწავლეთ საუკეთესო პრაქტიკა სათამაშო წიგნების დასაწერად. ტოპოლოგიის მართვა უფრო მოსახერხებელია group_vars и host_vars.

ძალიან მალე ჩვენ გეტყვით, თუ როგორ სამუდამოდ ამოიღოთ (გამორიცხოთ) ინსტანციები ტოპოლოგიიდან, ჩატვირთოთ vshard, მართოთ ავტომატური ჩავარდნის რეჟიმი, დააკონფიგურიროთ ავტორიზაცია და დააყენოთ კლასტერის კონფიგურაცია. ამასობაში შეგიძლიათ დამოუკიდებლად ისწავლოთ დოკუმენტაცია და ექსპერიმენტი კასეტური პარამეტრების შეცვლაზე.

თუ რამე არ მუშაობს, დარწმუნდით ინფორმირება ჩვენ პრობლემის შესახებ. ჩვენ სწრაფად დავანგრევთ!

წყარო: www.habr.com