cboettig's questions

A documentação do CoreOS indica que deve-se usar $public_ipv4 em vez de $private_ipv4 na configuração ectd addre peer-addrse nenhuma rede privada estiver disponível para o cluster. Isso faz todo o sentido, mas não estou claro quais são as implicações dessa escolha. Presumivelmente, a comunicação entre os nós ainda pode ser protegida adequadamente em um endereço público? Dado que um endereço privado limita apenas a adição de nós na mesma rede privada no futuro, que vantagem tem o uso do endereço privado? Isso difere em termos de segurança da conexão ou apenas problemas de desempenho/velocidade?

É possível que um cluster CoreOS compartilhe espaço em disco, por exemplo, usando NFS? Em caso afirmativo, como alguém faria isso? (por exemplo, no cenário em que um nó possui muito espaço em disco). Isso seria útil para evitar que cada nó tenha que baixar e armazenar sua própria biblioteca de imagens docker, por exemplo, ou para compartilhar o espaço do diretório inicial entre os nós.

Como não podemos instalar software adicional diretamente no CoreOS, imagino que seria necessário escrever um contêiner apenas para instalar o NFS (por exemplo nfs-kernel-server, em um contêiner baseado no Ubuntu).

Não tenho ideia se isso é possível, mas espero que haja alguma maneira estabelecida de compartilhar o espaço em disco em um cluster CoreOS (afinal, parece uma expectativa comum para um cluster e talvez minha proposta abaixo seja mais complicada do que o necessário) . Apenas para fornecer algum feedback, aqui está o que estou pensando até agora:

Fornecer o lado do host do NFS parece uma tarefa docker razoável, por exemplo, imagino um Dockerfile como:

FROM ubuntu:14.04
ENV CLIENT_IP 11.111.111.111          
RUN apt-get update && apt-get install -y nfs-kernel-server supervisor
RUN mkdir /var/nfs && chown nobody:nogroup /var/nfs
RUN echo "/home       ${CLIENT_IP}(rw,sync,no_root_squash,no_subtree_check)" >> /etc/exports
RUN echo "/var/nfs    ${CLIENT_IP}(rw,sync,no_subtree_check)" >> /etc/exports
RUN exportfs -a
CMD service nfs-kernel-server start

Onde CLIENT_IPfoi preenchido adequadamente (e talvez precisemos substituir o CMD por uma chamada para supervisordou algo semelhante para tornar isso persistente, mas você entendeu)

Então, como vincularíamos os volumes adequadamente ao executar esse contêiner? Qual volume vincularíamos do host CoreOS? Ou preciso adicionar algo como --net="host"para disponibilizar o cliente?

docker run -v /home:/home nfs-server

Não está claro para mim como poderíamos implementar o lado do cliente, já que mais uma vez precisaríamos de um contêiner para fornecer nfs-commone, de alguma forma, descobrir como outros contêineres poderiam compartilhar esse recurso (talvez algum uso apropriado de --volumes-from?) Adoraria ver um esboço de como fazer isso ou por que não é possível e se existem alternativas melhores para lidar com esse caso de uso. Obrigado!