Я развертываю несколько экземпляров coreos на VMware ESXi. etcd довольно привередлив к IP-адресам, особенно если они меняются.
Я хотел бы иметь возможность определить статический IP-адрес через cloud-config таким образом, чтобы не сбивать с толку кластер etcd. Похоже, что во время загрузки coreos должно произойти то, что он должен сначала вызвать интерфейс со статическим IP-адресом, прежде чем запускать etcd. Я попытался сделать это с этим разделом моего файла user_data:
write_files:
- path: /etc/systemd/network/static.network
permissions: 0644
content: |
[Match]
Name=ens192
[Network]
Address=192.168.1.58/24
Gateway=192.168.1.1
DNS=192.168.1.42
Что происходит, так это то, что процесс coreos-cloudinit запишет этот файл в файловую систему во время загрузки, но только после того, как он сначала запустит сетевой интерфейс с использованием DHCP. etcd запустится, но будет сбит с толку, так как настройки адреса пользователя и адреса равноправного узла не соответствуют DHCP. Если я вручную перезагружу систему после ее первой загрузки, она начнет использовать статический IP-адрес, который был записан ранее в файле static.network. Можно ли избежать этой второй перезагрузки, т.е. запустить сеть после определения static.network?
Похоже, основная проблема может заключаться в том, что провайдер vmware не понимает конструкцию $public_ip4, используемую другими провайдерами, такими как vagrant:
etcd:
# generate a new token for each unique cluster from https://discovery.etcd.io/new
# WARNING: replace each time you 'vagrant destroy'
discovery: https://discovery.etcd.io/####
addr: $public_ipv4:4001
peer-addr: $public_ipv4:7001
Насколько я могу судить, этой проблемы не существует при использовании vagrant/virtualbox.