CoreOS AWS Cloudinit Проблема

Question

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

#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 выше работает нормально, но как только я использую ниже cloud-config

#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 ни как "основной" пользователь с моей парой ключей aws, ни как с личным ключом, и создал пользователя "oba11" с моим личным ключом. Я также пробовал альфа-AMI, но та же проблема. Я не знаю, делаю ли я что-то не так.

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

Answer 1

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

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

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

В вашем случае узлы EC2 включат службу ssh, но они не будут должным образом сконфигурированы с этим cloud-config.

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

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

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

Answer 2

Я успешно загрузил 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"