Вече говорихме за Tarantool касета, което ви позволява да разработвате разпределени приложения и да ги пакетирате. Не е останало нищо: научете как да внедрявате и управлявате тези приложения. Не се притеснявайте, помислили сме за всичко! Събрахме всички най-добри практики за работа с Tarantool Cartridge и написахме ansible-роля, който ще разложи пакета на сървъри, ще стартира екземплярите, ще ги комбинира в клъстер, ще конфигурира оторизация, bootstrap vshard, ще активира автоматичен отказ и ще закърпи конфигурацията на клъстера.

Интересно? Тогава питам под разреза, ще кажем и покажем всичко.

Да започнем с един пример

Ще покрием само част от функционалността на нашата роля. Винаги можете да намерите пълно описание на всички негови функции и входни параметри в документация. Но е по-добре да опитате веднъж, отколкото да видите сто пъти, така че нека внедрим малко приложение.

Tarantool Cartridge има урок за създаване на малко приложение Cartridge, което съхранява информация за банкови клиенти и техните сметки, а също така предоставя API за управление на данни чрез HTTP. За целта приложението описва две възможни роли: api и storageкоито могат да бъдат присвоени на инстанции.

Самата касета не казва нищо за това как да стартирате процеси, тя само предоставя възможност за конфигуриране на вече работещи екземпляри. Потребителят трябва сам да направи останалото: да разложи конфигурационните файлове, да стартира услугите и да настрои топологията. Но ние няма да направим всичко това, Ansible ще го направи вместо нас.

От думи към дела

И така, нека внедрим нашето приложение на две виртуални машини и да настроим проста топология:

• Набор от реплики app-1 ще играе ролята apiкоето включва ролята vshard-router. Тук ще има само един пример.
• replicaset storage-1 изпълнява ролята storage (и в същото време vshard-storage), тук добавяме два екземпляра от различни машини.

За да стартираме примера, имаме нужда скитник и 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 и се насладете на резултата:

Можете да излеете данни. Готино, нали?

Сега нека разберем как да работим с това и в същото време да добавим друг набор от реплики към топологията.

Започваме да разбираме

И какво стана?

Имаме две виртуални машини и работим с ansible playbook, който настрои нашия клъстер. Нека да разгледаме съдържанието на файла 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-ролята, която се нарича 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 playbook:

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

Обърнете внимание на опцията --limit. Тъй като всеки екземпляр на клъстер е хост в условията на Ansible, можем изрично да посочим кои екземпляри трябва да бъдат конфигурирани, когато изпълняваме книгата за игра.

Назад към уеб интерфейса 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, автоматичен режим на отказ, параметри за оторизация и конфигурация на приложението).

Можем изрично да посочим каква част от работата искаме да свършим, след което ролята ще пропусне останалите задачи. В нашия случай искаме да работим само с топологията, така че сме уточнили cartridge-replicasets.

Нека да оценим резултата от нашите усилия. Намиране на нов репликат http://localhost:8181/admin/cluster/dashboard.

Ура!

Експериментирайте с преконфигуриране на вашите екземпляри и репликати и вижте как се променя топологията на клъстера. Можете да опитате различни оперативни сценарии, напр. текуща актуализация или увеличаване memtx_memory. Ролята ще се опита да направи това, без да рестартира екземпляра, за да намали възможния престой на вашето приложение.

Не забравяйте да бягате vagrant haltза да спрете VM, когато приключите с тях.

И какво се крие под капака?

Тук ще говоря повече за това, което се случи под капака на анзибъла по време на нашите експерименти.

Нека да разгледаме внедряването на приложение Cartridge стъпка по стъпка.

Инсталиране на пакета и стартиране на инстанции

Първо трябва да доставите пакета на сървъра и да го инсталирате. Сега ролята може да работи с RPM и DEB пакети.

След това стартираме екземплярите. Тук всичко е много просто: всеки екземпляр е отделен systemd-обслужване. Говоря за пример:

$ systemctl start myapp@storage-1

Тази команда ще стартира екземпляра storage-1 приложения myapp. Стартираният екземпляр ще търси своя конфигурация в /etc/tarantool/conf.d/. Регистрационните файлове на екземплярите могат да се видят с помощта на journald.

Единичен файл /etc/systemd/system/[email protected] за системна услуга ще бъде доставена с пакета.

Ansible има вградени модули за инсталиране на пакети и управление на systemd услуги, ние не сме измислили нищо ново тук.

Конфигуриране на топологията на клъстера

И тук започва най-интересното. Съгласете се, би било странно да се занимавате със специална ansible-роля за инсталиране на пакети и стартиране systemd-услуги.

Можете да настроите клъстера ръчно:

• Първата опция: отворете уеб потребителския интерфейс и щракнете върху бутоните. За еднократно стартиране на няколко инстанции е доста подходящо.
• Втори вариант: можете да използвате GraphQl API. Тук вече можете да автоматизирате нещо, например да напишете скрипт на Python.
• Третият вариант (за силните по дух): отидете на сървъра, свържете се с един от екземплярите, използвайки tarantoolctl connect и извършете всички необходими манипулации с модула Lua cartridge.

Основната задача на нашето изобретение е да направи това, най-трудната част от работата за вас.

Ansible ви позволява да напишете свой собствен модул и да го използвате в роля. Нашата роля използва тези модули за управление на различните компоненти на клъстера.

Как работи? Вие описвате желаното състояние на клъстера в декларативна конфигурация и ролята дава на всеки модул неговата конфигурационна секция като вход. Модулът получава текущото състояние на клъстера и го сравнява с входа. След това през сокета на един от екземплярите се изпълнява код, който привежда клъстера в желаното състояние.

Резултати от

Днес казахме и показахме как да разположите вашето приложение на Tarantool Cartridge и да настроите проста топология. За да направим това, използвахме Ansible, мощен инструмент, който е лесен за използване и ви позволява едновременно да конфигурирате много инфраструктурни възли (в нашия случай това са екземпляри на клъстер).

По-горе разгледахме един от многото начини за описание на конфигурацията на клъстера с помощта на Ansible. След като разберете, че сте готови да продължите напред, научете се най-добри практики за писане на книги-игри. Може да ви е по-удобно да управлявате топологията с group_vars и host_vars.

Съвсем скоро ще ви кажем как да премахнете завинаги (изгоните) екземпляри от топологията, да стартирате vshard, да управлявате автоматичен режим на отказ, да конфигурирате оторизация и да коригирате конфигурацията на клъстера. Междувременно можете да учите сами документация и експериментирайте с промяна на параметрите на клъстера.

Ако нещо не работи, бъдете сигурни информирам ни за проблема. Ще го разбием бързо!

Източник: www.habr.com