Diximus iam de Tarantool Cartridgequae tibi permittit ut applicationes distributa et involucrum elaborandum habeas. Reliquum est omnia discere quomodo has applicationes explicandi et eas administrandi. Ne cures, opertum totum tenemus! Nos omnes optimas exercitationes ad operandum cum Tarantool Cartridge componimus et scripsimus ansible-raquae sarcinam servientibus distribuet, instantiae immittendi, eas in botrum coniunge, potestatem configurare, vshard bootstrap, dativum deficientis activitatis et botri config.

Novus? Tunc amabo, sub inciso, tibi narrabimus et omnia tibi demonstrabimus.

Exemplum sit amet

Tantum spectamus partem functionis nostrae muneris. Potes semper invenire plenam descriptionem omnium eius facultatum et ambitum initus documentum. Sed melius est semel tentare quam centies videre, ut parvam rem explicemus.

Tarantool Adapter habet doceo ad applicationem parvam Cartridge creare, qui informationes de clientibus argentariis et rationibus eorum reponit, et etiam API providet ad administrationem data per HTTP. Ad hoc assequendum, appendix duas partes possibilium describit; api и storagequae instantiis assignari possunt.

Cartridge ipsa nihil dicit de processibus deducendis, tantum facultatem praebet instantiarum jam currentium configurandi. Usor se ceteris praestare debet: schemata configurationem disponere, officia incipere et topologiam configurare. Sed non omnia, Ansible nobis faciet.

A verbis ad facta

Itaque applicationem nostram ad duas machinis virtuales disponamus et topologiam simplicem constituamus:

Replicaset app-1 et ad efficiendum partes apiquae includit partes vshard-router. Una tantum instantia hic erit.
Replicaset storage-1 ad munus exercet storage (Et simul vshard-storage) Duo hic addemus Instantias ex diversis machinis.

Exemplum decurrendum nobis opus est incertis vagus и Ansible (Versio 2.8 vel maior).

Munus ipsum in Ansible Galaxy. Hoc repositio est quod permittit ut opus tuum communicet ac muneribus paratis utatur.

Clone repositorium per exemplum:

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

Machinationes virtuales excitamus:

$ vagrant up

Install a Tarantool Adapter ansible partes:

$ ansible-galaxy install tarantool.cartridge,1.0.1

Partes installed in launch:

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

Exspectavimus playbook ad executionem, ite to http://localhost:8181/admin/cluster/dashboard et fruere fructu;

Data imposuisti. Cool, vox?

Nunc quid opus hoc sit figurate, simulque aliam imaginem topologiae propositam addas.

Sit scriptor satus ut instar is sicco

Quid igitur factum est?

Duos machinis virtualis constituimus et ansibilis fabularum libri qui botrum nostrum configurantur. Intueamur quae in tabella 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

Nihil interesting hic fit, munus quod vocatur ansibile ineamus tarantool.cartridge.

Omnia principalia (nempe figuram botri) in inventarium-file 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:

Omnes opus est discere quomodo instantias et replicationes regere debeamus, mutatis contentis in hoc documento. Deinde novas sectiones ei adiiciemus. Ne confundas ubi ea adiicias, ultimam huius fasciculi versionem inspicere potes. hosts.updated.ymlquod est in promptuario.

Instantia procuratio

In Ansible terms, each instance is a host (not to be confused with a hardware server), i.e. nodi infrastructuram quam Ansible aget. Pro unaquaque multitudine parametris nexum exprimere possumus (ut ansible_host и ansible_user) , necnon figuratio instantia. Descriptio instantiarum in sectione est hosts.

Intueamur instantia configuratione storage-1:

all:
  vars:
    ...

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

  ...

In variabilis config exempli gratia parametri sumus certa - advertise URI и HTTP port.
Infra instantia parametri app-1 и storage-1-replica.

Indicanda Ansible nexum parametri pro singulis instantia necesse est. Consentaneum videtur esse instantiarum coetus in virtualis machinae circulos. Ad quem finem instantiae coniunguntur in circulos host1 и host2et singulis in sectione vars values significatur ansible_host и ansible_user unius virtualis apparatus. Et in sectione hosts - Virtutes (alias instantiae) quae in hoc coetu continentur:

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:

Mutare incipimus hosts.yml. Addamus duo exempla. storage-2-replica ad primam virtualem machinam et storage-2 Altero;

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

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

Placere note optio --limit. Cum singulae instantiae botri sit hospes in terminis Ansible, aperte exprimere possumus quae instantiae conformari debent cum exsecutioni in fabula.

Rediens ad Web UI http://localhost:8181/admin/cluster/dashboard et vide Instantias Novas.

Non illic desinamus ac magisterii topologiae administratione.

Acta administrationis

Coniungamus novas instantias nostras in statuto imaginis storage-2. Addamus novum coetus replicaset_storage_2 et describe parametros replicaset in suis variabilibus per analogiam cum replicaset_storage_1. In sectione hosts Indicamus quae instantiae in hoc circulo includantur (hoc est, figura nostra);

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

Sit scriptor playbook iterum incipit:

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

In parametri --limit Hoc tempore transivimus nomen sodalitatis nostrae replicaset respondet.

Consideremus optio tags.

Munus nostrum successive varia opera fungitur, quae sequentibus tags notantur;

cartridge-instances: instantia procuratio (configuratio, connexio ad membra);
cartridge-replicasetstopology administratione (replicaset administratione ac remotione permanentium instantiarum e botro);
cartridge-config: administratio aliorum parametri botri (vshard bootstrapping, modus deficientis latae sententiae, parametri licentia et configuratione applicationis).

Explicare possumus quamnam partem operis quam volumus facere, tunc partes operarum reliqua omittemus. In casu nostro, solum cum topologia laborare velimus, sic nominavimus cartridge-replicasets.

Perpendamus exitum laboris nostri. Invenimus novam replicaset in http://localhost:8181/admin/cluster/dashboard.

Euax!

Experimentum de mutanda configuratione instantiarum et imaginum ponit et vide quomodo topologia botri mutatur. Diversas missiones operationales experiri potes, exempli causa. volubilem update aut incremento memtx_memory. Munus hoc facere conabitur sine instantiam reprimendo, ut possibilis downtime applicationis tuae minuatur.

Noli oblivisci currere vagrant haltvirtualis machinis prohibere cum illis opus peractum es.

Quid sub cucullo?

Plura hic vobis dicam de iis quae sub cucullo munere ansibilis in nostris experimentis fiebant.

Intueamur gradatim explicandam applicationem ad Cartridge.

Installing in sarcina et incipiens instantiarum

Primum opus est sarcinam servo tradere ac instituere. Nunc munus cum RPM et DEB fasciculis laborare potest.

Deinde instantias deducimus. Omnia hic valde simplicia sunt: utrumque instantia separatum est systemd-servitium. Exemplum dabo;

$ systemctl start myapp@storage-1

Hoc mandatum deducunt exempli storage-1 apps myapp. Instantia deductae expecto suum configuratione в /etc/tarantool/conf.d/. Exempli gratia omnia videri potest utens journald.

Unitas file /etc/systemd/system/[email protected] pro systemd servitium una cum sarcina tradetur.

Ansible fabricavit in modulis ad inaugurandi sarcinas et systematica administrandi officia, nihil novi hic invenimus.

Botrus in topology profecta

Hic est ubi incipit iocus. Esto consentiens mirum esset cum munere ansibilis speciali vexare sarcinas et currit inaugurari systemd-officia.

Configurare potes botrum manually:

Prima optio: Web UI aperi et in globulis strepita. Plurium instantiarum unum tempus satis idoneum est.
Secunda optio: uti potes GraphQl API. Hic iam potes aliquid automate, verbi gratia, in Pythone scriptum.
Tertia optio (pro valido): vade ad ministratorem, coniunge uni exemplorum utentium tarantoolctl connect ac perfice omnia quae necessaria sunt cum Luae moduli cartridge.

Praecipuum inventionis nostrae negotium est, ut id facias, quod difficillimum est operis tui.

Ansible permittit tibi modulum tuum scribere et eo uti munere. Munus nostrum talibus modulis utitur ad varias partes ligaturas disponendas.

Quomodo facitur? Status botri desideratus in config declarativo describis, et partes singulae moduli cum sectione configurationis sua sicut input praebet. Modulus praesentem statum botri accipit et comparat cum eo quod input receptum est. Deinde per nervum cujusdam instantiarum, qui botrum fert ad statum desideratum, educitur.

results

Hodie narravimus et monstravimus applicationem tuam ad Tarantool Cartridge explicandam et simplicem topologiam erexisse. Ad hoc faciendum nos usi sumus Ansible - potens instrumentum quo uti facile est ac permittit ut simul plures nodos infrastructuras configurare (in casu nostro, instantiae botrus).

Supra inspeximus unum e multis modis figuram botri Ansible utentem describere. Cum sentis procedere paratus, explora optimus exercitia de scripto playbooks. Potes facilius invenire topologiam tuam utens group_vars и host_vars.

Propediem narrabimus tibi exempla e topologia (expellere) exempla e topologia, bootstrap vshard, modum defectivi automatismi administrare, cessionem configurare et botrum config repeciare. Interim studeas tuo Litterarum et experimento parametri ad mutandum botrum.

Si aliquid non operatur, cave to certiorem de nobis problema. Omnia celeriter exponemus!

Source: www.habr.com

Facile et naturaliter applicationes ad Tarantool Cartridge explicant.