Я пишу поварские сценарии для настройки кластера etcd. Список узлов (включая их IP-адреса) будет жестко закодирован в сценарии chef (как атрибут), и он будет передавать их etcd с использованием статической начальной загрузки с - начальный кластер и --initial-cluster-state новое параметры. Таким образом, сценарий Chef вызывает etcd с этими параметрами, они настроят кластер и в будущих запусках (например, перезагрузках) игнорируют эти параметры. - начальный кластер параметры.
При первой настройке это работает хорошо. Теперь предположим, что позже я хочу добавить новый узел в кластер etcd. Сначала я добавляю еще один узел в жестко запрограммированный список в атрибуте chef и загружаю новый узел. Когда скрипт затем вызывает etcd, - начальный кластер параметр также будет содержать дополнительный узел, но etcd требует его вызова с --initial-cluster-state существует вместо того --initial-cluster-state новое. Поэтому мне нужен отдельный сценарий для добавления новых узлов, а не для запуска первых нескольких узлов. Мне это не кажется хорошим решением.
Первая идея решения состоит в том, чтобы иметь различие в регистре в сценарии шеф-повара. Мы ведем отдельный жестко запрограммированный список IP-адресов начальных узлов. Если загружаемый узел принадлежит начальному набору, он будет использовать --initial-cluster-state новое и если этого не произойдет, он будет использовать --initial-cluster-state существует. Однако это не работает, когда один из начальных узлов умирает. При удалении и повторной загрузке он получит тот же IP-адрес, что и раньше (что квалифицирует его как начальный узел), и попытается подключиться к кластеру, используя --initial-cluster-state новое.
Если бы в etcd было какое-то автоматическое распознавание, то выбрал бы - исходное состояние кластера параметр автоматически, это было бы здорово. Но насколько мне известно, etcd этого не предлагает.
Как рекомендуется настроить кластер etcd с помощью Chef?