Már írtunk a Tarantool Cartridge-ról, amely lehetővé teszi elosztott alkalmazások fejlesztését és csomagolását. Már csak egy lépés van hátra: megtanulni, hogyan telepítsük ezeket az alkalmazásokat és kezeljük őket. Ne aggódjon, mindent előre láttunk! Összegyűjtöttük a Tarantool Cartridge használatának legjobb gyakorlatait és írtunk egy ansible-szerepről, amely telepíti a csomagot a szerverekre, elindítja az instanciákat, klaszterbe egyesíti őket, beállítja a hitelesítést, elkezdi a vshard-ot, aktiválja az automatikus hibajavítást és frissíti a klaszter konfigurációt.

Érdekes? Akkor jöjjön, mindent elmondunk és megmutatunk.

Kezdjük egy példával

Csak a szerepünk funkcionalitásának egy részét fogjuk megvizsgálni. A szerep összes lehetőségének és bemeneti paraméterének teljes leírását mindig megtalálja a dokumentáció. De jobb egyszer kipróbálni, mint százszor látni, ezért telepítsünk egy kis alkalmazást.

A Tarantool Cartridge rendelkezik tutoriál egy kis Cartridge-alkalmazás létrehozásához, amely tárolja a bank ügyfeleinek és számláinak adatait, valamint API-t kínál az adatok HTTP-n keresztüli kezelésére. Ehhez az alkalmazásban két lehetséges szerepet írunk le, api és tárolás, amelyek az instanciákhoz rendelhetők.

A Cartridge nem mond semmit arról, hogyan kell a folyamatokat elindítani, csupán lehetőséget biztosít a már elindított instanciák konfigurálásához. A többit a felhasználónak kell elvégeznie: a konfigurációs fájlok telepítése, a szolgáltatások elindítása és a topológia beállítása. De mi nem fogunk mindezzel foglalkozni, ezt elvégzi helyettünk az Ansible.

Szavakból tettek

Tehát telepítsük alkalmazásunkat két virtuális gépre, és állítsunk be egy egyszerű topológiát:

• Replikakészlet app-1 azt a szerepet fogja betölteni, api, amely tartalmazza a szerepet vshard-router. Itt csak egy instancia lesz.
• Replikakészlet storage-1 betölti a szerepet tárolás (egyetlen vshard-storage), ide két instanciát fogunk hozzáadni különböző gépekről.

A példa futtatásához szükségünk lesz Vagrant és Ansible (2.8-as vagy újabb verziójú).

A szerep magában található Ansible Galaxy. Ez egy olyan tároló, amely lehetővé teszi az egyéni munkák megosztását és kész szerepek használatát.

Klónozzuk a példát tartalmazó tárolót:

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

Emeljük a virtuális gépeket:

$ vagrant up

Telepítsük a Tarantool Cartridge ansible-szerepet:

$ ansible-galaxy install tarantool.cartridge,1.0.1

Futtassuk az telepített szerepet:

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

Várjuk meg a playbook végrehajtásának befejezését, majd térjünk át a http://localhost:8181/admin/cluster/dashboard és élvezzük az eredményt:

Az adatokat lehet táplálni. Hű, igaz?

Most nézzük meg, hogyan működik ez, és közben hozzáadunk egy új replikakészletet a topológiához.

Kezdjük a részletezést

Tehát mi történt?

Feltettünk két virtuális gépet és futtattunk egy ansible-playbookot, amely beállította a klasztert. Nézzük meg a fájl tartalmát playbook.yml:

---
- name: Telepítse a Tarantool Cartridge alkalmazásomat
  hosts: all
  become: true
  become_user: root
  tasks:
  - name: Tarantool Cartridge szerep importálása
    import_role:
      name: tarantool.cartridge

Itt nem történik semmi érdekes, futtatjuk az ansible-szerepet, amelynek neve tarantool.cartridge.

Mindez a legfontosabb (nevezetesen, a klaszter konfigurációja) a következő helyen található inventory-fájlban hosts.yml:

---
all:
  vars:
    # közös klaszter változók
    cartridge_app_name: getting-started-app
    cartridge_package_path: .\/getting-started-app-1.0.0-0.rpm  # csomag elérési út

    cartridge_cluster_cookie: app-default-cookie  # klaszter süti

    # közös ssh beállítások
    ansible_ssh_private_key_file: ~\/vagrant.d\/insecure_private_key
    ansible_ssh_common_args: '-o IdentitiesOnly=yes -o UserKnownHostsFile=\/dev\/null -o StrictHostKeyChecking=no'

  # INSTANCIAK
  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:
    # Csoportosítsa az INSTANCIAKAT GÉPEK ALAPJÁN
    host1:
      vars:
        # első gép kapcsolati beállításai
        ansible_host: 172.19.0.2
        ansible_user: vagrant

      hosts:  # példányok, amelyeket az első gépen indítunk
        storage-1:

    host2:
      vars:
        # második gép kapcsolati beállításai
        ansible_host: 172.19.0.3
        ansible_user: vagrant

      hosts:  # példányok, amelyeket a második gépen indítunk
        app-1:
        storage-1-replica:

    # Csoportosítsa az INSTANCIAKAT REPLIKAKÉSZLETEK ALAPJÁN
    replicaset_app_1:
      vars:  # replikakészlet konfiguráció
        replicaset_alias: app-1
        failover_priority:
          - app-1  # vezető
        roles:
          - 'api'

      hosts:  # replikakészlet példányai
        app-1:

    replicaset_storage_1:
      vars:  # replikakészlet konfiguráció
        replicaset_alias: storage-1
        weight: 3
        failover_priority:
          - storage-1  # vezető
          - storage-1-replica
        roles:
          - 'storage'

      hosts:   # replikakészlet példányai
        storage-1:
        storage-1-replica:

Minden, amire szükségünk van - az a példányok és replikakészletek kezelése a fájl tartalmának módosításával. Továbbá új szakaszokat fogunk hozzáadni. Hogy ne zavarodjunk össze, hivatkozhatsz a fájl végső verziójára, hosts.updated.yml, ami a példa tárolójában található.

Instance-ok kezelése

Az Ansible terminológiájában minden példány egy host (ne keverd össze a fizikális szerverrel), azaz egy olyan infrastruktúra csomópont, amelyet az Ansible kezelni fog. Minden hosthoz megadhatjuk a kapcsolati paramétereket (mint például ansible_host és ansible_user), valamint az instance konfigurációját. Az instance-okk leírása a szekcióban található hosts.

Nézzük meg az instance konfigurációját storage-1:

all:
  vars:
    ...

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

  ...

Az config megadtuk az instance paramétereit — advertise URI és HTTP port.
Az alábbiakban találhatók az instance-ok paraméterei app-1 és storage-1-replica.

Azt kell közölnünk az Ansible-nek, hogy az egyes instance-ok csatlakozási paraméterei mik. Logikusnak tűnik, hogy az instance-okat virtuális gépek szerint csoportosítsuk. Ennek érdekében az instance-okat csoportokba soroltuk host1 és host2, és minden csoportban a szekcióban vars jelennek meg az értékek ansible_host és ansible_user egy virtuális géphez. A szekcióban pedig hosts a hostok (azaz az instance-ok), amelyek ebbe a csoportba tartoznak:

all:
  vars:
    ...
  hosts:
    ...
  children:
    # Csoportosítás gépek szerint
    host1:
      vars:
        # első gép csatlakozási opciói
        ansible_host: 172.19.0.2
        ansible_user: vagrant
       hosts:  # instance-ok, amelyeket az első gépen indítanak
        storage-1:

     host2:
      vars:
        # második gép csatlakozási opciói
        ansible_host: 172.19.0.3
        ansible_user: vagrant
       hosts:  # instance-ok, amelyeket a második gépen indítanak
        app-1:
        storage-1-replica:

Kezdünk változtatni hosts.yml. Két új instance-ot adunk hozzá, storage-2-replica az első virtuális gépen és storage-2 a másodikon:

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:
    # Csoportosítás gépek szerint
    host1:
      vars:
        ...
      hosts:  # instance-ok, amelyeket az első gépen indítanak
        storage-1:
        storage-2-replica:  # <==

    host2:
      vars:
        ...
      hosts:  # instance-ok, amelyeket a második gépen indítanak
        app-1:
        storage-1-replica:
        storage-2:  # <==
  ...

Elindítjuk az ansible playbook-ot:

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

Figyeljünk az opcióra --limit. Mivel minden cluster instance egy host az Ansible szempontjából, világosan jelezhetjük, hogy mely instance-okat kell beállítani a playbook futtatásakor.

Ismét belépünk a Web UI-ba http://localhost:8181/admin/cluster/dashboard és figyeljük az új instance-ainkat:

Ne álljunk meg itt, ismerkedjünk meg a topológia kezelésével.

Topológia kezelése

Csoportosítsuk új instance-ainkat replikációs készletbe storage-2. Hozzáadunk egy új csoportot replicaset_storage_2 és a változói között leírjuk a replikációs készlet paramétereit a következőképpen, mint a replicaset_storage_1. A szakaszban hosts megadjuk, hogy mely instance-ok tartoznak ebbe a csoportba (azaz a replikációs készletünk):

---
all:
  vars:
    ...
  hosts:
    ...
  children:
    ...
    # INSTANCIAK CSOPORTOSÍTÁSA REPLIKA KÉSZLET SZERINT
    ...
    replicaset_storage_2:  # <==
      vars:  # replika készlet konfiguráció
        replicaset_alias: storage-2
        weight: 2
        failover_priority:
          - storage-2
          - storage-2-replica
        roles:
          - 'storage'

      hosts:   # replika készlet példányok
        storage-2:
        storage-2-replica:

Újra futtatjuk a playbookot:

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

A paraméterben --limit ezúttal a csoport nevét adtuk meg, amely megfelel a replika készletünknek.

Vizsgáljuk meg az opciót címkék.

A szerepünk különböző feladatokat hajt végre, amelyeket a következő címkék jelölnek:

• cartridge-instances: példányok kezelése (beállítás, csatlakozás a tagsághoz);
• cartridge-replicasets: topológia kezelése (replika készletek kezelése és példányok véglegesen eltávolítása (expel) a klaszterből);
• cartridge-config: a klaszter többi paraméterének kezelése (vshard bootstrapping, automatikus failover mód, hitelesítési paraméterek és alkalmazás konfiguráció).

Kifejezetten megadhatjuk, hogy melyik feladatot szeretnénk elvégezni, így a szerep kihagyja a többi feladat végrehajtását. Az esetünkben csak a topológiával szeretnénk foglalkozni, ezért megadtuk, hogy cartridge-replicasets.

Nézzük meg az erőfeszítéseink eredményét. Keresünk új replika készletet a http://localhost:8181/admin/cluster/dashboard.

Hurrá!

Kísérletezzünk a példányok és replika készletek konfigurációjának megváltoztatásával, és nézzük meg, hogyan változik a klaszter topológiája. Kipróbálhat különböző üzemeltetési forgatókönyveket, például rolling update vagy a memtx_memorynövelése. A szerep megpróbálja ezt végrehajtani anélkül, hogy újraindítaná a példányt, hogy minimalizálja az alkalmazás leállásának időtartamát.

Ne felejtsük el futtatni a vagrant haltparancsot, hogy leállítsuk a virtuális gépeket, amikor befejeztük a velük való munkát.

És mi történik a háttérben?

Itt részletesebben mesélek arról, hogy mi zajlott a háttérben az ansible szerepével a kísérleteink során.

Vizsgáljuk meg lépésről lépésre a Cartridge-alkalmazás telepítését.

A csomag telepítése és a példányok indítása

Először a csomagot a szerverre kell juttatni és telepíteni. A szerep most már képes RPM és DEB csomagokkal dolgozni.

Ezután elindítjuk a példányokat. Itt minden nagyon egyszerű: minden példány egy külön systemd-szolgáltatás. Példaként mesélek:

$ systemctl start myapp@storage-1

Ez a parancs elindítja a példányt. storage-1 alkalmazás myappAz elindított példány megkeresi a saját konfiguráció be. /etc/tarantool/conf.d/. A példány naplóit a következővel nézhetjük meg: journald.

Unit-fájl /etc/systemd/system/myapp@.sevice a systemd-szolgáltatáshoz a csomaggal együtt lesz telepítve.

Az Ansible beépített modulokkal rendelkezik csomagok telepítésére és a systemd-szolgáltatások kezelésére, itt nem találtunk ki semmi újat.

A klaszter topológia beállítása

Itt kezdődik a legérdekesebb rész. Egyetérthetünk, hogy furcsa lenne külön Ansible-szerepet készíteni a csomagok telepítésére és a szolgáltatások indítására. systemd-szolgáltatások.

A klasztert manuálisan is beállíthatjuk:

• Első lehetőség: megnyitjuk a Web UI-t, és nyomogatjuk a gombokat. Egyszeri több példány indítására ez teljesen megfelelő.
• Második lehetőség: használhatjuk a GraphQl API-t. Itt már lehet automatizálni valamit, például írhatunk egy Python szkriptet.
• Harmadik lehetőség (az erős lelkűeknek): belépünk a szerverre, csatlakozunk az egyik példányhoz a tarantoolctl connect parancs használatával, és elvégezzük az összes szükséges műveletet a Lua-modullal. cartridge.

Feltalálásunk fő feladata, hogy ezt a legnehezebb munkarészt elvégezze helyettetek.

Az Ansible lehetővé teszi saját moduljaink írását és használatát szerepként. A mi szerepünk különböző klaszterkomponensek kezelésére használ ilyen modulokat.

Hogyan működik ez? Ön a klaszter kívánt állapotát írja le egy deklaratív konfigurációban, a szerep pedig bemenetként adja meg minden modulnak a konfigurációs szakaszát. A modul megkapja a klaszter aktuális állapotát és összehasonlítja azzal, ami bemenetként érkezett. Ezután az egyik példány socketjén keresztül elindít egy kódot, amely a klasztert a kívánt állapotba hozza.

Összegzés

Ma bemutattuk, hogyan lehet telepíteni az alkalmazását Tarantool Cartridge-re, és egyszerű topológiát beállítani. Ehhez az Ansible-t használtuk - egy erőteljes eszközt, amely egyszerű használatáról ismert, és lehetővé teszi, hogy egyszerre sok infrastruktúra csomópontot (esetünkben klasztereik példányait) konfiguráljunk.

Fent a klaszter konfigurációjának leírásának egyik módjával foglalkoztunk Ansible segítségével. Amint készen áll arra, hogy tovább lépjen, tanulmányozza a legjobb gyakorlatokat a playbookok írásához. Lehet, hogy kényelmesebb lesz a topológia kezelése a group_vars és host_vars.

Hamarosan mesélünk arról, hogyan lehet végleg eltávolítani (expel) a példányokat a topológiából, bootstrappelni a vshard-ot, kezelni az automatikus failover módot, beállítani az azonosítást és javítani a klaszter konfigurációját. De addig is önállóan tanulmányozhat. a dokumentációval és kísérletezhet a klaszter paramétereinek megváltoztatásával.

Ha valami nem működik, feltétlenül tájékoztasson minket a problémáról. Gyorsan megoldjuk!

Forrás: habr.com