Již jsme hovořili o Tarantool Cartridge, který umožňuje vyvíjet distribuované aplikace a balit je. Už zbývá jen málo: naučit se tyto aplikace nasazovat a spravovat. Nebojte se, na vše jsme mysleli! Shromáždili jsme všechny osvědčené postupy pro práci s Tarantool Cartridge a napsali ansible-rolích, která nainstaluje balík na servery, spustí instance, spojí je do clusteru, nastaví autorizaci, připraví vshard, zapne automatický failover a propatche clusterovou konfiguraci.

Zajímavé? Tak pojďte dál, všechno vám povíme a ukážeme.

Začněme s příkladem

Podíváme se pouze na část funkcionality naší role. Úplný popis všech jejích funkcí a vstupních parametrů vždy najdete v dokumentaci. Ale lepší jednou zkusit, než stokrát vidět, tak si dejme malé nasazení aplikace.

Tarantool Cartridge má tutoriál příklad pro vytvoření malé Cartridge aplikace, která uchovává informace o bankovních klientech a jejich účtech, a také poskytuje API pro správu dat přes HTTP. V aplikaci jsou popsány dvě možné role: api a úložiště, které mohou být přiřazeny instancím.

Samotný Cartridge nenaznačuje, jak spouštět procesy, pouze umožňuje konfiguraci již spuštěných instancí. Ostatní musí uživatel udělat sám: rozložit konfigurační soubory, spustit služby a nastavit topologii. Ale nebudeme se tím vším zabývat, to za nás udělá Ansible.

Od slov k činům

Tak tedy, nasadíme naši aplikaci na dva virtuální stroje a nastavíme jednoduchou topologii:

• Replika set app-1 bude realizovat roli api, která zahrnuje roli vshard-router. Tady bude pouze jedna instance.
• Replika set storage-1 realizuje roli úložiště (a zároveň vshard-storage), sem přidáme dvě instance z různých strojů.

Pro spuštění příkladu budeme potřebovat Vagrant a Ansible (verze 2.8 nebo starší).

Samotná role se nachází v Ansible Galaxy. To je takový repozitář, který umožňuje sdílení vlastních znalostí a používání hotových rolí.

Naklonujeme repozitář s příkladem:

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

Zvedáme virtuální stroje:

$ vagrant up

Nainstalujeme ansible-rol na Tarantool Cartridge:

$ ansible-galaxy install tarantool.cartridge,1.0.1

Spouštíme nainstalovanou roli:

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

Čekáme na dokončení spuštění playbooku, přejdeme na http://localhost:8181/admin/cluster/dashboard a užíváme si výsledek:

Můžeme přenášet data. Skvělé, že?

A teď se podívejme, jak s tím pracovat, a zároveň přidáme další replikaset do topologie.

Začínáme se zabývat

Tak co se vlastně stalo?

Vytvořili jsme dvě virtuální stroje a spustili ansible playbook, který nastavil náš klastr. Podívejme se na obsah souboru playbook.yml:

---
- name: Nasadit mou aplikaci Tarantool Cartridge
  hosts: all
  become: true
  become_user: root
  tasks:
  - name: Importovat roli Tarantool Cartridge
    import_role:
      name: tarantool.cartridge

Zde se nic zajímavého neděje, spouštíme ansible roli, která se jmenuje tarantool.cartridge.

Všechno důležité (a to, konkrétně, konfigurace klastru) se nachází v inventář- souboru hosts.yml:

---
all:
  vars:
    # běžné proměnné klastru
    cartridge_app_name: getting-started-app
    cartridge_package_path: ./getting-started-app-1.0.0-0.rpm  # cesta k balíčku

    cartridge_cluster_cookie: app-default-cookie  # cluster cookie

    # běžné možnosti 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'

  # INSTANCI
  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:
    # SKUPINOVÉ INSTANCI PODLE STROJŮ
    host1:
      vars:
        # připojovací možnosti prvního stroje
        ansible_host: 172.19.0.2
        ansible_user: vagrant

      hosts:  # instance, které budou spuštěny na prvním stroji
        storage-1:

    host2:
      vars:
        # připojovací možnosti druhého stroje
        ansible_host: 172.19.0.3
        ansible_user: vagrant

      hosts:  # instance, které budou spuštěny na druhém stroji
        app-1:
        storage-1-replica:

    # SKUPINOVÉ INSTANCI PODLE REPLIKOVÝCH SATOV
    replicaset_app_1:
      vars:  # konfigurace replikového sadu
        replicaset_alias: app-1
        failover_priority:
          - app-1  # vůdce
        roles:
          - 'api'

      hosts:  # instance replikového sadu
        app-1:

    replicaset_storage_1:
      vars:  # konfigurace replikového sadu
        replicaset_alias: storage-1
        weight: 3
        failover_priority:
          - storage-1  # vůdce
          - storage-1-replica
        roles:
          - 'storage'

      hosts:   # instance replikového sadu
        storage-1:
        storage-1-replica:

Všechno, co potřebujeme, je naučit se ovládat instance a replikové sady, změnou obsahu tohoto souboru. Dále do něj budeme přidávat nové sekce. Abychom se neztratili, kam je přidávat, můžete nahlédnout do finální verze tohoto souboru, hosts.updated.yml, který se nachází v repozitáři s příkladem.

Správa instancí

V pojmech Ansible je každá instance - to je host (neplést s fyzickým serverem), tj. uzel infrastruktury, kterým Ansible bude spravovat. Pro každého hostitele můžeme specifikovat parametry připojení (takové, jako je ansible_host a ansible_user), a také konfiguraci instance. Popis instancí naleznete v sekci hosts.

Zvažme konfiguraci instance storage-1:

all:
  vars:
    ...

  # INSTANČNÍ
  hosts:
    storage-1:
      config:
        advertise_uri: '172.19.0.2:3301'
        http_port: 8181

  ...

V proměnné config uvedli jsme parametry instance — advertise URI a HTTP port.
Níže jsou parametry instancí app-1 a storage-1-replica.

Musíme Ansible sdělit parametry připojení pro každou instanci. Zdá se logické sloučit instance do skupin podle virtuálních strojů. K tomu byly instance sloučeny do skupin host1 a host2, a v každé skupině v sekci vars jsou uvedeny hodnoty ansible_host a ansible_user pro jeden virtuální stroj. A v sekci hosts — hosté (také instance), které patří do této skupiny:

all:
  vars:
    ...
  hosts:
    ...
  children:
    # SKUPINOVÉ INSTANCI PODLE STROJŮ
    host1:
      vars:
        # možnosti připojení prvního stroje
        ansible_host: 172.19.0.2
        ansible_user: vagrant
       hosts:  # instance, které budou spuštěny na prvním stroji
        storage-1:

     host2:
      vars:
        # možnosti připojení druhého stroje
        ansible_host: 172.19.0.3
        ansible_user: vagrant
       hosts:  # instance, které budou spuštěny na druhém stroji
        app-1:
        storage-1-replica:

Začínáme měnit hosts.yml. Přidáme ještě dvě instance, storage-2-replica na prvním virtuálním stroji a storage-2 na druhém:

all:
  vars:
    ...

  # INSTANČNÍ
  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:
    # SKUPINOVÉ INSTANCI PODLE STROJŮ
    host1:
      vars:
        ...
      hosts:  # instance, které budou spuštěny na prvním stroji
        storage-1:
        storage-2-replica:  # <==

    host2:
      vars:
        ...
      hosts:  # instance, které budou spuštěny na druhém stroji
        app-1:
        storage-1-replica:
        storage-2:  # <==
  ...

Spouštíme ansible-playbook:

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

Všimněte si možnosti --limit. Protože každá instance clusteru je host v terminologii Ansible, můžeme jasně uvádět, které instance by měly být nakonfigurovány při spuštění playbooku.

Znovu se přihlašujeme do Web UI http://localhost:8181/admin/cluster/dashboard a sledujeme naše nové instance:

Nenecháme se zastavit a osvojíme si správu topologie.

Správa topologie

Sloučíme naše nové instance do replikaset storage-2. Přidáme novou skupinu replicaset_storage_2 a popíšeme v jejích proměnných parametry replikasetu podle vzoru replicaset_storage_1. V sekci hosts určíme, které instance budou do této skupiny patřit (tedy náš replikaset):

---
all:
  vars:
    ...
  hosts:
    ...
  children:
    ...
    # SKUPINY INSTANCÍ ROZDĚLENÉ PODLE REPLIKOVÝCH SAD
    ...
    replicaset_storage_2:  # <==
      vars:  # konfigurace replikové sady
        replicaset_alias: storage-2
        weight: 2
        failover_priority:
          - storage-2
          - storage-2-replica
        roles:
          - 'storage'

      hosts:   # instance replikové sady
        storage-2:
        storage-2-replica:

Znovu spouštíme playbook:

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

V parametru --limit jsme tentokrát předali název skupiny, která odpovídá naší replikové sadě.

Pojďme se podívat na možnost tags.

Naše role postupně provádí různé úkoly, které jsou označeny následujícími tagy:

• cartridge-instances: správa instancí (nastavení, připojení k membership);
• cartridge-replicasets: správa topologie (správa replikových sad a nevratné odstraňování (expel) instancí z clusteru);
• cartridge-config: správa ostatních parametrů clusteru (vshard bootstrapping, režim automatického failoveru, parametry autorizace a konfigurace aplikace).

Můžeme jasně určit, kterou část práce chceme provést, a role přeskočí provádění ostatních úkolů. V našem případě chceme pracovat pouze s topologií, proto jsme uvedli cartridge-replicasets.

Pojďme vyhodnotit výsledek našich snah. Najdeme novou replikovou sadu na http://localhost:8181/admin/cluster/dashboard.

Hurá!

Experimentujte se změnami konfigurace instancí a replikových sad a sledujte, jak se mění topologie clusteru. Můžete vyzkoušet různé provozní scénáře, například, rolling update nebo zvýšení memtx_memory. Role se to pokusí udělat bez restartu instance, aby se snížil možný downtime vaší aplikace.

Nezapomeňte spustit vagrant halt, abyste zastavili virtuální stroje, když s nimi skončíte.

A co se děje uvnitř?

Zde podrobněji popíšu, co se dělo uvnitř ansible role během našich experimentů.

Podívejme se krok za krokem na nasazení aplikace Cartridge.

Instalace balíčku a spuštění instancí

Nejprve je třeba doručit balíček na server a nainstalovat ho. Nyní role umí pracovat s RPM a DEB balíčky.

Poté spustíme instance. Tady je to velmi jednoduché: každá instance je samostatný systemd-služba. Popisuji na příkladu:

$ systemctl start myapp@storage-1

Tento příkaz spustí instanci storage-1 aplikace myapp. Spuštěná instance bude hledat svou konfiguraci v /etc/tarantool/conf.d/. Logy instance lze zobrazit pomocí journald.

Unit souboru /etc/systemd/system/myapp@.sevice pro systemd službu budou doručeny spolu s balíčkem.

V Ansible jsou vestavěné moduly pro instalaci balíčků a správu systemd služeb, zde jsme nevymysleli nic nového.

Nastavení topologie clustera

A tady začíná to nejzajímavější. Souhlasíte, bylo by divné se obracet na speciální ansible roli pro instalaci balíčků a spouštění systemd-služeb.

Cluster lze nastavit ručně:

• První možnost: otevřete Web UI a klikněte na tlačítka. Pro jednorázové spuštění několika instancí to bude zcela vyhovovat.
• Druhá možnost: můžete využít GraphQl API. Zde už můžete něco automatizovat, například napsat skript v Pythonu.
• Třetí možnost (pro silné duše): přihlaste se na server, připojte se k jedné z instancí pomocí tarantoolctl connect a proveďte všechny potřebné manipulace s Lua modulem cartridge.

Hlavním cílem našeho vynálezu je udělat za vás právě tu nejobtížnější část práce.

Ansible umožňuje napsat svůj modul a používat ho v roli. Naše role používá takové moduly pro správu různých komponentů clustera.

Jak to funguje? Popíšete požadovaný stav clustera v deklarativním konfigu a role poskytuje každému modulu jeho sekci konfigurace. Modul získá aktuální stav clustera a porovná ho s tím, co dostal na vstupu. Poté je prostřednictvím socketu jedné z instancí spuštěn kód, který přivede cluster do požadovaného stavu.

Závěry

Dnes jsme vám ukázali, jak nasadit vaši aplikaci na Tarantool Cartridge a nastavit jednoduchou topologii. K tomu jsme použili Ansible – mocný nástroj, který se vyznačuje jednoduchostí použití a umožňuje zároveň konfigurovat množství uzlů infrastruktury (v našem případě to jsou instance clustera).

Výše jsme se zaměřili na jeden z mnoha způsobů popisu konfigurace clustera pomocí Ansible. Jakmile si uvědomíte, že jste připraveni jít dál, prostudujte si best practices pro psaní playbooků. Možná pro vás bude pohodlnější spravovat topologii pomocí group_vars a host_vars.

Brzy vám ukážeme, jak bezv return delet výsti žrá vzan studnestinstence z topologie, bootstrapovat vshard, spravovat režim automatického failoveru, nastavovat autorizaci a patchovat konfigura clustera. A zatím si můžete samostatně prostudovat. dokumentaci a experimentovat se změnou parametrů clusteru.

Pokud něco nefunguje, určitě nás informujte o problému. Rychle to vyřešíme!

Zdroj: habr.com