У меня есть минимальная облачная конфигурация, которая без проблем работает в DigitalOcean. Я добавил усиление безопасности для SSH, которое требует перезапуска sshd.socket чтобы стать эффективным:

units:
  - name: sshd.socket
    command: restart

Добавление только этого модуля (без фактических изменений конфигурации sshd) приводит к сбою инициализации с той же облачной конфигурацией при попытке ее на Hetzner:ssh: connect to host xx.xx.xx.xx port 22: Connection refused. Тем не менее, он по-прежнему отлично подключается к DigitalOcean.

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

Замена переменных

Единственное различие между обеими платформами, о котором я знаю, заключается в том, что в DigitalOcean переменные $public_ipv4 и $private_ipv4 заменяются фактическими IP-адресами, чего нельзя сказать о таких установках, как Hetzner.

Из Документация CoreOS:

Примечание. Переменные подстановки $ private_ipv4 и $ public_ipv4, упомянутые в других документах, поддерживаются только в Amazon EC2, Google Compute Engine, OpenStack, Rackspace, DigitalOcean и Vagrant.

Поэтому я заменяю переменные статическим IP-адресом. Я использую общедоступный IP-адрес, потому что это единственный доступный интерфейс, кроме loopback.

Однако когда я обеспечиваю без подстановки этих переменных с общедоступным IP-адресом, то он ТАКЖЕ подключается нормально.

При просмотре журнала обнаруживаются некоторые ошибки, связанные с разрешением имен:

systemd[1]: Starting etcd2...
etcd2[874]: recognized and used environment variable ETCD_ADVERTISE_CLIENT_URLS=http://:2379,http://:4001
etcd2[874]: recognized and used environment variable ETCD_DATA_DIR=/var/lib/etcd2
etcd2[874]: recognized and used environment variable ETCD_DISCOVERY=https://discovery.etcd.io/616b3957c5c78e7738207011f9c51841
etcd2[874]: recognized and used environment variable ETCD_INITIAL_ADVERTISE_PEER_URLS=http://:2380
etcd2[874]: recognized and used environment variable ETCD_LISTEN_CLIENT_URLS=http://0.0.0.0:2379,http://0.0.0.0:4001
etcd2[874]: recognized and used environment variable ETCD_LISTEN_PEER_URLS=http://:2380
etcd2[874]: recognized and used environment variable ETCD_NAME=39b2a003672546f8a0b648dbc66e8f6f
etcd2[874]: etcd Version: 2.2.0
etcd2[874]: Git SHA: e4561dd
etcd2[874]: Go Version: go1.4.2
etcd2[874]: Go OS/Arch: linux/amd64
etcd2[874]: setting maximum number of CPUs to 1, total number of available CPUs is 12
etcd2[874]: listening for peers on http://:2380
etcd2[874]: listening for client requests on http://0.0.0.0:2379
etcd2[874]: listening for client requests on http://0.0.0.0:4001
etcd2[874]: resolving :2380 to :2380
etcd2[874]: resolving :2380 to :2380
etcd2[874]: error #0: dial tcp: lookup discovery.etcd.io: Temporary failure in name resolution
etcd2[874]: cluster status check: error connecting to https://discovery.etcd.io, retrying in 2s
etcd2[874]: error #0: dial tcp: lookup discovery.etcd.io: Temporary failure in name resolution
etcd2[874]: cluster status check: error connecting to https://discovery.etcd.io, retrying in 4s
etcd2[874]: found self 61dbc8c9c2aca1e8 in the cluster
etcd2[874]: found 1 needed peer(s)

Но они не кажутся фатальными: systemctl status etcd2.service показывает, что услуга активна:

core@localhost ~ $ systemctl status etcd2.service
● etcd2.service - etcd2
   Loaded: loaded (/usr/lib64/systemd/system/etcd2.service; disabled; vendor preset: disabled)
  Drop-In: /run/systemd/system/etcd2.service.d
           └─20-cloudinit.conf
   Active: active (running) since Tue 2016-03-22 14:10:33 UTC; 7min ago
 Main PID: 874 (etcd2)
   Memory: 20.3M
      CPU: 1.771s
   CGroup: /system.slice/etcd2.service
           └─874 /usr/bin/etcd2

etcd2[874]: added local member 61dbc8c9c2aca1e8 [http://:2380] to cluster 216c373aaf11ccfa
systemd[1]: Started etcd2.
etcd2[874]: 61dbc8c9c2aca1e8 is starting a new election at term 1
etcd2[874]: 61dbc8c9c2aca1e8 became candidate at term 2
etcd2[874]: 61dbc8c9c2aca1e8 received vote from 61dbc8c9c2aca1e8 at term 2
etcd2[874]: 61dbc8c9c2aca1e8 became leader at term 2
etcd2[874]: raft.node: 61dbc8c9c2aca1e8 elected leader 61dbc8c9c2aca1e8 at term 2
etcd2[874]: published {Name:39b2a003672546f8a0b648dbc66e8f6f ClientURLs:[http://:2379 http://:4001]} to cluster 216c373aaf11ccfa
etcd2[874]: setting up the initial cluster version to 2.2
etcd2[874]: set the initial cluster version to 2.2

Контейнеры, которые подключаются к другим службам, таким как Logstash, не работают: the scheme http does not accept registry part: :9200 (or bad hostname?)

Cloud-config

Это урезанная облачная конфигурация, но она по-прежнему демонстрирует проблему (проверено).

#cloud-config

ssh_authorized_keys:
  - "ssh-rsa A valid SSH key here"
write_files:
coreos:
  etcd2:
    # NOTE: replace $discovery_url with a url generated at https://discovery.etcd.io/new?size=X
    discovery: $discovery_url
    listen-client-urls: http://0.0.0.0:2379,http://0.0.0.0:4001
    advertise-client-urls: http://my.public.ip.address:2379,http://my.public.ip.address:4001
    initial-advertise-peer-urls: http://my.public.ip.address:2380
    listen-peer-urls: http://my.public.ip.address:2380          # Remove this flag or use localhost and the connection issue goes away
  units:
    - name: etcd2.service
      command: start
    - name: fleet.service
      command: start
    - name: sshd.socket
      command: restart   # Remove this unit and all issues go away (but no SSH hardening in that case)

Я заметил одну вещь: когда я снимаю флаг listen-peer-urls проблема с подключением также исчезает, хотя logstash все еще не запускается по той же причине.

Этот документ говорит, что значением по умолчанию для этих флагов являются URL-адреса с localhost, но название переменных подстановки, которые используются на таких платформах, как DigitalOcean, похоже, предполагает, что это должен быть адрес, доступный для одноранговых машин.

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

Вопрос 1

Какой должна быть правильная облачная конфигурация для машин с голым железом, у которых есть только общедоступный интерфейс и интерфейс обратной связи (без частной сети)?

вопрос 2

Какая связь между sshd и etcd вызывает этот сбой?