4

CoreOS の安定した AMI とカスタムの cloud-init 構成を使用して EC2 インスタンスをセットアップしようとしていますが、いくつか問題があります。

#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"

私のawsキーペアまたは個人キーを使用して「コア」ユーザーとしてcoreosインスタンスに再度SSHで接続できず、個人キーを使用してユーザー「oba11」を作成しました。アルファ AMI も試しましたが、同じ問題です。私が何か間違ったことをしているかどうかはわかりません。

助けてくれてありがとう。

4

2 に答える 2

1

古い etcd 検出トークン ID を使用しています。

クラスター ノードがこの ID を使用するとすぐに、トークンは使用済みとしてマークされます。何らかの理由で、このアドレスにハートビートする etcd ノードがない場合、トークンは役に立たなくなります。

同じ etcd 検出 URI で新しいクラスターまたは単一ノードを起動しようとすると、ブートストラップ プロセスは失敗します。

あなたの場合、EC2ノードはsshサービスをオンにして起動しますが、そのクラウド構成で適切に構成されません.

発生している動作 (PK を接続するが拒否する) は予期されたものであり、 https://coreos.com/docs/cluster-management/setup/cluster-discovery/のドキュメントを読んでいない場合、頭痛の種になる可能性があります。と述べられています。

クラスター検出に関するもう 1 つの一般的な問題は、古い検出 URL を使用して新しいクラスターを起動しようとすることです。上で説明したように、最初のリーダー選出は URL に記録されます。これは、新しい etcd インスタンスが既存のクラスターに参加する必要があることを示します。

古い検出 URL を指定すると、新しいマシンは古いピア アドレスのそれぞれに接続しようとしますが、それらが存在しないために失敗し、ブートストラップ プロセスが失敗します。

于 2015-02-12T16:00:45.977 に答える
0

3 つの CoreOS マシン クラスタを正常に起動し、問題なく SSH 接続しました。設定を使用します。セキュリティグループを確認してください。おそらくそれが問題です。私はこの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"
于 2015-01-29T02:35:12.280 に答える