Estou escrevendo scripts de chef para configurar um cluster do etcd. A lista de nós (incluindo seus IPs) será codificada no script do chef (como um atributo) e passará para o etcd usando bootstrapping estático com - initial-cluster e - parâmetros de novo estado de cluster inicial . Assim, o script chef chama o etcd com esses parâmetros, eles configuram o cluster e, em execuções futuras (por exemplo, reinicializações), ignoram esses parâmetros - cluster inicial .
Para configuração inicial, isso funciona bem. Agora, suponha que eu queira adicionar mais tarde um novo nó ao cluster do etcd. Primeiro adiciono outro nó à lista codificada no atributo chef e inicializo o novo nó. Quando o script chamar o etcd, o parâmetro - cluster inicial também conterá o nó adicional, mas o etcd exigirá que ele seja chamado com - estado do cluster inicial existente em vez de - novo estado do cluster inicial . Então eu preciso de um script de chef separado para adicionar novos nós do que para iniciar os primeiros nós. Isso não parece uma boa solução para mim.
Uma primeira ideia para uma solução é ter distinção de maiúsculas e minúsculas no roteiro do chef. Mantemos uma lista codificada separada dos IPs dos nós iniciais. Se o nó bootstrapped pertencer ao conjunto inicial, ele usará - initial-cluster-state new e, se não, usará - initial-cluster-state existing No entanto, isso não funciona quando um dos nós iniciais morre. Ao deletar e rearranjar novamente, ele obterá o mesmo IP de antes (que o qualifica como um nó inicial) e tentará se conectar ao cluster usando - initial-cluster-state new .
Se houvesse algum tipo de reconhecimento automático no etcd que escolheria o parâmetro - initial-cluster-state automaticamente, isso seria ótimo. Mas até onde sei, o etcd não oferece isso.
Qual é a maneira recomendada de configurar um cluster do etcd com o chef?