CoreOS AWS Cloudinit Issue

Question

Я пытаюсь настроить экземпляры EC2 с использованием стабильного AMI CoreOS с некоторыми настраиваемыми облачными настройками, но с некоторыми проблемами.

#cloud-config 
coreos: 
    etcd: 
    discovery: https://discovery.etcd.io/5996f1b49fd642c5d1bc2f62cbff2fba 
    addr: $private_ipv4:4001 
    peer-addr: $private_ipv4:7001 
    units: 
    - name: etcd.service 
     command: start 
    - name: fleet.service 
     command: start 
write_files: 
    - path: /etc/fleet/fleet.conf 
    content: | 
     public_ip="$private_ipv4" 
     metadata="elastic_ip=true,public_ip=$public_ipv4" 

Облако-конфигурации выше работает нормально, но когда я использую ниже облачного конфигурации

#cloud-config 
coreos: 
    etcd: 
    discovery: https://discovery.etcd.io/5996f1b49fd642c5d1bc2f62cbff2fba 
    addr: $private_ipv4:4001 
    peer-addr: $private_ipv4:7001 
    units: 
    - name: etcd.service 
     command: start 
    - name: fleet.service 
     command: start 
users: 
    - name: core 
    coreos-ssh-import-github: oba11 
write_files: 
    - path: /etc/fleet/fleet.conf 
    content: | 
     public_ip="$private_ipv4" 
     metadata="elastic_ip=true,public_ip=$public_ipv4" 

или

#cloud-config 
coreos: 
    etcd: 
    discovery: https://discovery.etcd.io/5996f1b49fd642c5d1bc2f62cbff2fba 
    addr: $private_ipv4:4001 
    peer-addr: $private_ipv4:7001 
    units: 
    - name: etcd.service 
     command: start 
    - name: fleet.service 
     command: start 
users: 
    - name: oba11 
    groups: 
     - sudo 
     - docker 
    coreos-ssh-import-github: oba11 
write_files: 
    - path: /etc/fleet/fleet.conf 
    content: | 
     public_ip="$private_ipv4" 
     metadata="elastic_ip=true,public_ip=$public_ipv4" 

я не могу SSH к экземплярам coreos снова либо как " ядро "с моей awp keypair или личным ключом и создал пользователя oba11 с моим личным ключом. Я также пробовал альфа-AMI, но та же проблема. Я не знаю, что я делаю что-то неправильно.

Спасибо большое за помощь.

Answer 1

Я успешно загрузил 3 кластера машин CoreOS и без проблем получил ssh'd. Использование вашей конфигурации. Проверьте свои группы безопасности, возможно, это проблема. Я использовал этот AMI AMI-00158768

#cloud-config 
coreos: 
    etcd: 
    discovery: https://discovery.etcd.io/b0ac83415ff737c16670ce015a5d4eeb 
    addr: $private_ipv4:4001 
    peer-addr: $private_ipv4:7001 
    units: 
    - name: etcd.service 
     command: start 
    - name: fleet.service 
     command: start 
users: 
    - name: gxela 
    groups: 
     - sudo 
     - docker 
    coreos-ssh-import-github: gxela 
write_files: 
    - path: /etc/fleet/fleet.conf 
    content: | 
     public_ip="$private_ipv4" 
     metadata="elastic_ip=true,public_ip=$public_ipv4" 

Answer 2

Вы используете устаревшие обнаружения etcd токена.

Как только ваши узлы кластера использовали этот идентификатор, маркер отмечен как использованный, если по какой-либо причине ни один из узлов узла netbat не попадает в этот адрес, токен оказывается бесполезным.

Если вы попытаетесь запустить новый кластер или один узел с тем же открытым идентификатором UDP, то процесс начальной загрузки завершится с ошибкой.

В вашем случае узлы EC2 будут подключены к службе ssh, но они не будут правильно настроены с помощью этой облачной конфигурации.

Ожидается, что поведение, которое вы испытываете (соединение, но отклонение ПК), может вызвать головную боль, если вы не прочитали документацию по адресу https://coreos.com/docs/cluster-management/setup/cluster-discovery/, где указано, что;

Другая распространенная проблема с обнаружением кластера - попытка загрузить новый кластер с устаревшим URL-адресом обнаружения. Как объяснялось выше, начальные выборы записываются в URL-адрес, что означает, что новый экземпляр etcd должен соединяться с существующим кластером.

Если вы предоставляете несвежий URL обнаружения, новые машины будут пытаться подключиться к каждому из старых одноранговых адресов, которые потерпят неудачу, поскольку они не существуют, и процесс самонастройки потерпит неудачу.