Com isso dito, vamos dissecar sua pergunta em particular aqui.
Em termos de servidor e aplicativo, vamos usar o gitlab-ci e o gitlab-ci-runner como nosso modelo de servidor / aplicativo. Com gitlab-ci sendo o servidor e gitlab-ci-runner como o aplicativo. Nosso modelo de implantação é um para muitos, com 1 servidor e muitos aplicativos. (podemos ter muitos servidores, mas eu quero manter o exemplo conciso)
Metadados do Gitlab-CI
Primeiro definimos o relacionamento nos metadados do gitlab-ci.
provides:
ci-job:
interface: ci-worker
Esta declaração única diz ao juju que temos uma relação ci-job, usando a interface ci-worker. Com essa definição de relacionamento, temos quatro estados possíveis que podemos consumir para fazer alterações.
ci-job-joined, ci-job-changed, ci-job-quebrado, ci-job-departed
A convenção para isto, é relação-nome - evento - então avançando, nós temos aqueles 4 ganchos de evento possíveis ligados a um nome de relação. Eles executam na seguinte sequência:
- relation-joined
- relação-alterada
- relação-quebrado
- relação-partiu
O ingresso é para "pré-trabalho" e é um local para você fazer qualquer trabalho necessário para preparar o serviço para receber o relacionamento (fazendo backup de um banco de dados SQLite local existente, por exemplo).
Alterado é executado sempre que uma alteração é detectada no relacionamento. Isso às vezes é acionado quando o recurso remoto tem uma atualização de configuração e pode não refletir necessariamente uma alteração necessária em seu serviço - portanto, tenha 100% de certeza de que ele é idempotente.
Broken é executado quando você quebra o relacionamento pela primeira vez. É quando você deseja fazer backups de dados e reconfiguração para remover a configuração remota.
Partida é qualquer trabalho de finalização final para remover o relacionamento. Como reinstalar o backup do SQLite para operação e gravar a configuração correta.
Existem vários encantos que exercitam esses ganchos na loja de charme. Eu sugeriria olhar para o conteúdo do anzol de alguns dos encantos. MongoDB , MediaWiki , Ghost
Metadados do Gitlab-CI-Worker
O serviço de terminal oposto terá uma história muito semelhante ao serviço listado acima, mas em vez de fornecer, usaremos uma instrução requer para fazer o relacionamento. Isso é muito mais do que uma configuração Tab A, Slot B - você define o que pode conversar com essas definições.
requires:
ci-job:
interface: ci-worker
E nossos ganchos parecerão basicamente os mesmos: ci-job-joined, ci-job-alterado, ci-job-broken, ci-job-afastado
O conteúdo do código do gancho depende inteiramente de você.
Enviando o IP da unidade
Existem convenções enviadas com juju - dependendo do idioma que você está usando para escrever o charme. Certifique-se de ler os documentos sobre relação-get, relation-set e unit-get
unit-get destina-se a ler as variáveis do nível do sistema. Por exemplo: unit-get public-address
relation-set é o que você gostaria de usar no host que envia as informações. Na instância da configuração do gitlab-ci, nós relation-set publicip=$(unit-get public-address)
relation-get é como consumimos os dados enviados pela rede no serviço de recebimento. relation-get publicip
Espero que isso ajude!