Como defino um relacionamento?
Assim, para definir um relacionamento entre dois charms, você deve primeiro, como você fez a alusão, definir a relação em cada charms metadata.yaml file. Desde que você definiu uma função de servidor / cliente, vou manter isso em meus exemplos abaixo com foo-server e foo-client charms. Como é provável que o servidor forneça a maioria dos dados para o cliente , seus arquivos metadata.yaml ficariam assim:
foo-server
name: foo-server
description: Something more than this
provides:
server:
interface: foo
foo-client
name: foo-client
description: Something more than this
requires:
backend:
interface: foo
Juju tem dois tipos de relação principais. Fornece e requer. Neste caso, o encanto do servidor é fornecendo "foo" como uma interface. O charme do cliente requer que a interface "foo" funcione. Isso fornece / requer que o juju saiba quais charms podem falar com quais outros charms.
A interface é um nome arbitrário, neste caso foo, mas poderia ser qualquer coisa. Há uma lista grande de interfaces já definidas, como: mysql, http, mongodb, etc. Se o seu serviço fornecer uma dessas interfaces existentes gostaria de considerar a implementação. Se não estiver à vontade para criar um novo.
Como obtenho / envio dados?
Depois de definir seus metadados, você precisará criar alguns novos ganchos os nomes dos ganchos são definidos na documentação vinculada, mas como você está apenas enviando as informações de endereço, continuaremos com um exemplo simplificado da implementação de cada gancho.
Então, temos dois encantos, foo-server e foo-client . foo-server fornece uma relação "servidor" com a interface foo. foo-client requer uma relação "backend" com a interface foo. Ganchos de relação são nomeados com base no nome da relação (não no nome da interface). Estes dois podem ser chamados server, mas para ilustrar que juju corresponde na interface e não na relação, eu fiz o nome da relação foo-client "backend".
foo-server / hooks / server-relation-joined
#!/bin/bash
set -eux
relation-set hostname='unit-get private-address'
Este é um exemplo muito básico, em que estamos criando uma chave de relação chamada hostname e definindo o valor, usando o comando unit-get , para o endereço privado da unidade em que o encanto está implantado. Este endereço irá variar de provedor para provedor, mas será sempre acessível dentro de um ambiente de juju. Você pode definir várias chaves adicionando um espaço entre as teclas, por exemplo:
relation-set hostname='unit-get private-address' public-address='unit-get public-address'
Isso enviará duas chaves, hostname e public-address para qualquer serviço ao qual esteja conectado.
foo-client / hooks / relação de backend alterada
Observe a diferença no nome do arquivo, que está chamando o relation-changed hook em vez de relation-joined . Presumivelmente, o servidor está apenas dando os detalhes de onde ele mora, portanto, o encanto do cliente precisa saber onde esse endereço está. Colocando isso no gancho relation-changed toda vez que os dados na relação são atualizados, o hook é chamado novamente.
#!/bin/bash
set -eux
server_address='relation-get hostname'
if [ -z "$server_address" ]; then
juju-log "No data sent yet"
exit 0
fi
# If you've gotten this far, you have a $server_address, configure as you see fit
Agora, há um pouco mais de envolvimento nesse gancho. Tomando linha a linha, os três primeiros são apenas coisas padrão. É um charme bash e set -eux está lá para garantir que o gancho se comporte como deveria. A próxima linha usa relation-get , que lerá dados de relação da conexão. Agora, tudo em um ambiente de juju é orquestrado de forma assíncrona. Então você nunca tem 100% de certeza de que terá dados quando ligar para relation-get . É aqui que o bloco if ajuda a resolver isso. Se não houver nada em "$ server_address", ou seja, não obtivermos um valor de retorno, o gancho sairá da forma simples. No entanto, ele está saindo com um status zero, então não aparecerá como um erro no juju.
Eu sei que isso parece contra-intuitivo, tecnicamente temos um problema porque não temos dados. Sim, mas é mais na linha de "Ainda não temos dados". Ao sair de zero, assim que o serviço correspondente realmente definir o valor, ele acionará o gancho relation-changed novamente e poderemos ler o valor. Este é considerado um exemplo de um guarda de idempotência que é crucial à medida que você escreve ganchos .