Usando Ganchos¶

Você pode usar ganchos no SolusVM 2 para executar scripts personalizados automaticamente antes ou depois da ocorrência de eventos específicos.

Resumindo, veja como funcionam os ganchos no SolusVM 2:

É possível criar um diretório especial no nó de gerenciamento e/ou em qualquer recurso de cálculo. Você pode fazer com que um gancho vinculado a um evento específico se comporte de maneira diferente nos recursos de computação A e B e esteja totalmente ausente do recurso de computação C.
No diretório, você precisa colocar um ou mais arquivos executáveis contendo um script personalizado. Scripts personalizados podem ser escritos em Bash, PHP, Python, Golang, Java ou qualquer outra linguagem de programação capaz de analisar um arquivo JSON passado para ele.
Cada vez que um dos eventos suportados, como a reinicialização de um servidor virtual, ocorre para um servidor virtual, o SolusVM 2 executa todos os scripts personalizados encontrados no nó de gerenciamento ou no recurso de computação que hospeda esse servidor virtual. Você pode encontrar a lista completa de eventos suportados neste tópico. Você não pode criar ganchos para eventos não suportados. Cada gancho configurado é acionado duas vezes por evento: antes e depois da ocorrência do evento. Os ganchos são acionados independentemente de um evento suportado ser iniciado por meio da GUI, CLI ou API.
Quando um gancho é acionado, o SolusVM 2 passa para ele um objeto JSON contendo as seguintes informações: o tipo do evento, se o gancho foi acionado antes ou depois do evento, e também alguns dados relevantes, como o ID do servidor virtual em questão.

Por exemplo, quando um novo servidor virtual está sendo criado, o evento “servidor virtual criado” é acionado. Ele transmite, entre outros dados, o endereço IP do servidor virtual recém-criado. Você pode criar um script personalizado que analisaria o objeto JSON de entrada, pegaria esses dados e os usaria para criar as regras de firewall necessárias no recurso de computação que o hospeda.

Criando um Gancho¶

Recomendamos usar um único arquivo como ponto de partida, que determinará quais outros scripts ou comandos serão executados.

Para criar um gancho no nó de gerenciamento ou recurso de cálculo:

Faça login no nó de gerenciamento ou recurso de cálculo via SSH como usuário "root".
Crie um diretório chamado /usr/local/solus/hooks/ se ele não existir.

mkdir /usr/local/solus/hooks/

Crie um arquivo e cole seu script personalizado nele. Você pode dar ao arquivo o nome que desejar, por exemplo, "hook.sh".

touch /usr/local/solus/hooks/hook.sh

Torne o arquivo executável.

chmod +x /usr/local/solus/hooks/hook.sh

Seu gancho agora está criado. O executável será executado sempre que ocorrer um evento compatível. Você não pode configurar o SolusVM 2 para executar apenas executáveis específicos para eventos específicos. O script personalizado deve ser capaz de analisar o objeto JSON e executar determinada(s) ação(ões) dependendo de seu conteúdo.

Quando ocorre um evento suportado, todos os ganchos de configuração (se houver) são acionados. A ação é pausada no lado do SolusVM 2 até que todos os scripts personalizados tenham sido encerrados ou até que um minuto tenha passado, o que ocorrer primeiro. Então, por exemplo, eis o que acontece quando um servidor virtual é reiniciado e há um ou mais ganchos configurados no nó de gerenciamento ou no recurso de computação que hospeda esse servidor virtual:

O comando para reiniciar o servidor virtual é fornecido através da GUI, CLI ou API.
SolusVM 2 executa todos os executáveis no diretório /usr/local/solus/hooks/, passando para cada um o objeto JSON contendo todas as informações relevantes, incluindo o ID do evento suportado e o indicador de estágio "pre".
Todos os executáveis são encerrados ou um minuto passa.
O servidor virtual é reiniciado.
SolusVM 2 executa todos os executáveis no diretório /usr/local/solus/hooks/, passando para cada um o objeto JSON contendo todas as informações relevantes, incluindo o ID do evento suportado e o indicador de estágio "post".

Note

Não coloque nenhum arquivo além de hooks no diretório /usr/local/solus/hooks/.

Anatomia do objeto JSON¶

Seu gancho deve esperar dados em stdin (entrada padrão) em formato JSON válido. Cada vez que um evento de disparo ocorre, um objeto JSON contendo todos os dados relevantes é passado para cada binário no diretório /usr/local/solus/hooks/. Esta é a aparência deste objeto:

{
    "action": "server-restart",
    "stage": "pre",
    "data": {
      "uuid": "c7ee19aa-2722-4139-9223-60ed4baf09e2",
      "virtualization_type": "kvm"
    }
  }

Aqui, "action" especifica que tipo de evento acionou o gancho (neste caso, um servidor virtual sendo reiniciado), "stage" especifica se o evento está prestes a acontecer ou acabou de acontecer (neste caso, o primeiro), e "data" especifica informações relevantes para o evento (neste caso, ID do servidor virtual e seu tipo de virtualização). Portanto, o objeto em questão nos informa que o servidor virtual baseado em KVM com o ID "c7ee19aa-2722-4139-9223-60ed4baf09e2" está prestes a ser reiniciado, e o script customizado chamado pelo gancho pode, por exemplo, ser usado para notifique o proprietário do servidor virtual.

As teclas “action”, “stage” e “data” estão sempre presentes.

A chave “stage” só pode ter os valores “pre” e “post”.
A chave "action" pode ter vários valores correspondentes aos eventos suportados.
"server-create"
"server-delete"
"server-migrate"
"server-reinstall"
"server-restart"
"server-start"
"server-stop"
"server-network-create"
"server-network-delete"
"server-network-update"
O objeto "data" inclui várias chaves que podem ter valores diferentes. Uma ou mais chaves específicas correspondem a cada tecla de "action" específica. Por exemplo, um objeto JSON correspondente a um servidor virtual sendo reiniciado (a ação "server-restart") sempre incluirá as chaves "uuid" e "virtualization_type" dentro do objeto "data", e nunca quaisquer outras.

Note

Um único evento pode acionar vários ganchos. Por exemplo, a criação de um novo servidor virtual aciona os ganchos "server-create" e "server-network-create".

Note

Se um evento falhar durante a execução (por exemplo, um servidor virtual não pode ser criado), apenas os ganchos "pré" serão acionados, mas não os ganchos "pós".

Exemplos de ganchos¶

Exemplo de Bash

Faça login no nó de gerenciamento ou recurso de cálculo via SSH como usuário "root".
Crie um diretório chamado /usr/local/solus/hooks/ se ele não existir.

mkdir /usr/local/solus/hooks/

Criar um arquivo.

touch /usr/local/solus/hooks/hook.sh

Torne-o executável.

chmod +x /usr/local/solus/hooks/hook.sh

Cole o seguinte conteúdo no arquivo.

#!/bin/bash
set -xEeuo pipefail

tfile=$(mktemp /tmp/hook_test_$(date "+%Y-%m-%d-%H-%M-%S-%N")_XXX)

cat /dev/stdin | jq > $tfile

Instale o programa “jq” no servidor.

apt install jq ou dnf install jq

Exemplo de Python

Faça login no nó de gerenciamento ou recurso de cálculo via SSH como usuário "root".
Crie um diretório chamado /usr/local/solus/hooks/ se ele não existir.

mkdir /usr/local/solus/hooks/

Criar um arquivo.

touch /usr/local/solus/hooks/hook.py

Torne-o executável.

chmod +x /usr/local/solus/hooks/hook.py

Cole o seguinte conteúdo no arquivo.

#!/usr/bin/env python3
import sys
import json

ACTION_SERVER_RESTART = "server-restart"
STAGE_PRE = "pre"
STAGE_POST = "post"

event = json.loads(sys.stdin.read())


def handle_server_restart_pre(event_data):
    print(f'Server going restart: {event_data["uuid"]}')


def handle_server_restart_post(event_data):
    print(f'Server was restarted: {event_data["uuid"]}')


action = event["action"]
stage = event["stage"]
data = event["data"]

if ACTION_SERVER_RESTART == action:
    if STAGE_PRE == stage:
        handle_server_restart_pre(data)
        sys.exit(0)
    if STAGE_POST == stage:
        handle_server_restart_post(data)
        sys.exit(0)

Instale o módulo "json" no servidor.

python -c "help('modules')"

Testando seu gancho

Faça login no nó de gerenciamento ou recurso de cálculo via SSH como usuário "root".

Passe um objeto JSON para o seu gancho, por exemplo:

echo '{
"action": "server-restart",
"stage": "pre",
"data":

{ "uuid": "c7ee19aa-2722-4139-9223-60ed4baf09e2", "virtualization_type": "kvm" }
}' | /usr/local/solus/hooks/hook.sh