Já falamos sobre , que permite desenvolver aplicativos distribuídos e empacotá-los. Não resta mais nada: aprenda a implantar e gerenciar esses aplicativos. Não se preocupe, nós pensamos em tudo! Reunimos todas as melhores práticas para trabalhar com Tarantool Cartridge e escrevemos , que irá decompor o pacote em servidores, iniciar as instâncias, combiná-las em um cluster, configurar a autorização, inicializar vshard, habilitar o failover automático e corrigir a configuração do cluster.
Interessante? Aí eu pergunto embaixo do corte, vamos contar e mostrar tudo.
Vamos começar com um exemplo
Cobriremos apenas parte da funcionalidade de nossa função. Você sempre pode encontrar uma descrição completa de todos os seus recursos e parâmetros de entrada em . Mas é melhor tentar uma vez do que ver cem vezes, então vamos implantar um pequeno aplicativo.
Cartucho Tarantool tem criar um pequeno aplicativo Cartridge que armazena informações sobre os clientes do banco e suas contas, além de fornecer uma API para gerenciamento de dados via HTTP. Para fazer isso, o aplicativo descreve duas funções possíveis: api и storageque podem ser atribuídos a instâncias.
O cartucho em si não diz nada sobre como iniciar processos, apenas fornece a capacidade de configurar instâncias já em execução. O resto deve ser feito pelo próprio usuário: decompor os arquivos de configuração, iniciar os serviços e configurar a topologia. Mas não faremos tudo isso, o Ansible fará por nós.
Das palavras às ações
Então, vamos implantar nosso aplicativo em duas máquinas virtuais e configurar uma topologia simples:
- replicaset
app-1vai fazer o papelapique inclui o papelvshard-router. Haverá apenas uma instância aqui. - replicaset
storage-1implementa o papelstorage(e ao mesmo tempovshard-storage), aqui adicionamos duas instâncias de máquinas diferentes.
Para executar o exemplo, precisamos и (versão 2.8 ou posterior).
O papel em si é . Este é um repositório que permite compartilhar seu trabalho e usar papéis prontos.
Clone o repositório com um exemplo:
$ git clone https://github.com/dokshina/deploy-tarantool-cartridge-app.git
$ cd deploy-tarantool-cartridge-app && git checkout 1.0.0Levantamos máquinas virtuais:
$ vagrant upInstale a função Tarantool Cartridge ansible:
$ ansible-galaxy install tarantool.cartridge,1.0.1Execute a função instalada:
$ ansible-playbook -i hosts.yml playbook.ymlEstamos aguardando o final da execução do playbook, acesse e aproveite o resultado:
Você pode derramar dados. Legal certo?
Agora vamos descobrir como trabalhar com isso e, ao mesmo tempo, adicionar outro conjunto de réplicas à topologia.
começamos a entender
Então o que aconteceu?
Temos duas VMs instaladas e executando um playbook ansible que configura nosso cluster. Vamos ver o conteúdo do arquivo 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.cartridgeNada de interessante acontece aqui, iniciamos o ansible-role, que se chama tarantool.cartridge.
Tudo o mais importante (ou seja, a configuração do cluster) está localizado em -arquivo 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:Tudo o que precisamos é aprender a gerenciar instâncias e replicasets alterando o conteúdo desse arquivo. Em seguida, adicionaremos novas seções a ele. Para não ficar confuso onde adicioná-los, você pode dar uma olhada na versão final deste arquivo, hosts.updated.yml, que está no repositório de exemplo.
Gerenciamento de Instância
Em termos de Ansible, cada instância é um host (não confundir com um servidor de ferro), ou seja, o nó de infraestrutura que o Ansible irá gerenciar. Para cada host, podemos especificar parâmetros de conexão (como ansible_host и ansible_user), bem como a configuração da instância. A descrição das instâncias está na seção hosts.
Considere a configuração da instância storage-1:
all:
vars:
...
# INSTANCES
hosts:
storage-1:
config:
advertise_uri: '172.19.0.2:3301'
http_port: 8181
...Em uma variável config especificamos os parâmetros da instância - advertise URI и HTTP port.
Abaixo estão os parâmetros da instância app-1 и storage-1-replica.
Precisamos informar ao Ansible os parâmetros de conexão para cada instância. Parece lógico agrupar instâncias em grupos de máquinas virtuais. Para fazer isso, as instâncias são combinadas em grupos. host1 и host2, e em cada grupo na seção vars valores ansible_host и ansible_user para uma máquina virtual. E na seção hosts - hosts (são instâncias) que estão incluídos neste grupo:
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:Nós começamos a mudar hosts.yml. Vamos adicionar mais duas instâncias, storage-2-replica na primeira máquina virtual e storage-2 No segundo:
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: # <==
...Execute o manual do ansible:
$ ansible-playbook -i hosts.yml
--limit storage-2,storage-2-replica
playbook.ymlFique atento à opção --limit. Como cada instância de cluster é um host nos termos do Ansible, podemos especificar explicitamente quais instâncias devem ser configuradas ao executar o playbook.
Voltar para a interface do usuário da Web e observe nossas novas instâncias:
Não descansaremos sobre os louros e dominaremos o controle de topologia.
Gerenciamento de topologia
Vamos mesclar nossas novas instâncias em um replicaset storage-2. Vamos adicionar um novo grupo replicaset_storage_2 e descrever em suas variáveis os parâmetros do replicaset por analogia com replicaset_storage_1. Na seção hosts especifique quais instâncias serão incluídas neste grupo (ou seja, nosso conjunto de réplicas):
---
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:Vamos começar o playbook novamente:
$ ansible-playbook -i hosts.yml
--limit replicaset_storage_2
--tags cartridge-replicasets
playbook.ymlPor opção --limit desta vez passamos o nome do grupo que corresponde ao nosso replicaset.
Considere a opção tags.
Nossa função executa sequencialmente várias tarefas, marcadas com as seguintes tags:
cartridge-instances: gerenciamento de instâncias (configuração, conexão com membros);cartridge-replicasets: gerenciamento de topologia (gerenciamento de replicaset e remoção permanente (expulsão) de instâncias do cluster);cartridge-config: gerencie outros parâmetros de cluster (bootstrapping vshard, modo de failover automático, parâmetros de autorização e configuração do aplicativo).
Podemos especificar explicitamente qual parte do trabalho queremos fazer, então a função irá ignorar o restante das tarefas. No nosso caso, queremos trabalhar apenas com a topologia, por isso especificamos cartridge-replicasets.
Vamos avaliar o resultado de nossos esforços. Encontrando um novo conjunto de replicações .
Hooray!
Experimente reconfigurar instâncias e conjuntos de réplicas e veja como a topologia do cluster muda. Você pode tentar diferentes cenários operacionais, por exemplo, ou aumentar memtx_memory. A função tentará fazer isso sem reiniciar a instância para reduzir o possível tempo de inatividade do seu aplicativo.
Não se esqueça de correr vagrant haltpara interromper as VMs quando terminar de usá-las.
E o que há sob o capô?
Aqui falarei mais sobre o que aconteceu sob o capô do papel ansible durante nossos experimentos.
Vamos dar uma olhada na implantação de um aplicativo Cartridge passo a passo.
Instalando o pacote e iniciando as instâncias
Primeiro você precisa entregar o pacote ao servidor e instalá-lo. Agora a função pode trabalhar com pacotes RPM e DEB.
Em seguida, lançamos as instâncias. Tudo é muito simples aqui: cada instância é uma instância separada systemd-serviço. Estou falando de um exemplo:
$ systemctl start myapp@storage-1Este comando iniciará a instância storage-1 Aplicativos myapp. A instância iniciada procurará seu в /etc/tarantool/conf.d/. Os logs de instância podem ser visualizados usando journald.
arquivo de unidade /etc/systemd/system/[email protected] para um serviço systemd será entregue com o pacote.
O Ansible possui módulos integrados para instalar pacotes e gerenciar serviços systemd, não inventamos nada de novo aqui.
Configurando a topologia do cluster
E aqui começa o mais interessante. Concordo, seria estranho se preocupar com uma função ansible especial para instalar pacotes e executar systemd-Serviços.
Você pode configurar o cluster manualmente:
- A primeira opção: abra a interface do usuário da Web e clique nos botões. Para um início único de várias instâncias, é bastante adequado.
- Segunda opção: você pode usar a API GraphQl. Aqui você já pode automatizar algo, por exemplo, escrever um script em Python.
- A terceira opção (para os fortes de espírito): vá para o servidor, conecte-se a uma das instâncias usando
tarantoolctl connecte realizar todas as manipulações necessárias com o módulo Luacartridge.
A principal tarefa da nossa invenção é fazer isso, a parte mais difícil do trabalho para você.
Ansible permite que você escreva seu próprio módulo e use-o em uma função. Nossa função usa esses módulos para gerenciar os vários componentes do cluster.
Como funciona? Você descreve o estado desejado do cluster em uma configuração declarativa e a função fornece a cada módulo sua seção de configuração como entrada. O módulo recebe o estado atual do cluster e o compara com a entrada. Em seguida, um código é executado no soquete de uma das instâncias, o que leva o cluster ao estado desejado.
Resultados de
Hoje contamos e mostramos como implantar sua aplicação no Tarantool Cartridge e configurar uma topologia simples. Para fazer isso, usamos o Ansible, uma ferramenta poderosa, fácil de usar e que permite configurar vários nós de infraestrutura simultaneamente (no nosso caso, são instâncias de cluster).
Acima, lidamos com uma das muitas maneiras de descrever a configuração do cluster usando o Ansible. Assim que souber que está pronto para seguir em frente, aprenda para escrever playbooks. Você pode achar mais conveniente gerenciar a topologia com group_vars и host_vars.
Em breve, mostraremos como remover permanentemente (expulsar) instâncias da topologia, inicializar vshard, gerenciar o modo de failover automático, configurar a autorização e corrigir a configuração do cluster. Enquanto isso, você pode estudar por conta própria e experimente alterar os parâmetros do cluster.
Se algo não funcionar, certifique-se nós sobre o problema. Nós vamos quebrá-lo rapidamente!
Fonte: habr.com