2015-09-04 10 views
5

私たちは以下の問題があります。私たちのクラスタでは、URLが変更されています。これらの変更を反映するように設定を変更したら、URLは 'discovery.etcd.io'で更新されませんでした。だから私たちの考えは新しいトークンを使うことだった。しかし、これは動作しません。クラスタは 'discovery.etcd.io'の新しいトークンに登録されません。 URLやトークンを変更するたびに再インストールする必要はありません。より良い方法がありますか?再インストールは問題なく動作します。CoreOS - 新しいトークンの使い方は?

#cloud-config 
hostname: server1 
coreos: 
    etcd2: 
    # generate a new token for each unique cluster from https://discovery.etcd.io/new?size=3 
    discovery: https://discovery.etcd.io/<our token> 
    # multi-region and multi-cloud deployments need to use $public_ipv4 
    advertise-client-urls: server1:2379 
    initial-advertise-peer-urls: server1:2380 
    # listen on the official ports 
    listen-client-urls: server1:2379 
    listen-peer-urls: server1:2380 
    #fleet: 
    # public-ip: server1 
    # metadata: region=eu-central-1 
    #update: 
    # reboot-strategy: etcd-lock 
    units: 
    - name: etcd2.service 
     command: start 
    # - name: fleet.service 
    # command: start 
ssh_authorized_keys: 
    <our ssh keys> 

答えて

4

あなたが繰り返し再インストールする必要はありません。

基本的なバックアップ手順は次のようです。次のプロセスは、デバッグが困難な巨大なクラウド構成ファイルを用意するのではなく、クラスタを段階的に取得するのに役立ちます。

  1. ストップetcdと(etcd2に依存などフランネル、艦隊、など)すべての依存サービス:etcd2

  2. はは/ var/libに/ etcd2/*からetcdデータファイルを削除停止(またはsystemctl ETCD_DATA_DIRでパス)

  3. 変更に保存されているクラウドの設定ファイルで発見トークン:は/ var/libに/ coreosインストール/ user_dataを

  4. を再起動します。

2

discovery.etcd.ioのみブートストラップに使用されている:あなたは、たとえばhttps://discovery.etcd.io/new?size=3でホストの数のトークンを要求しますが、基本的にはあなたの3つのホストをブートストラップするためにそのURLを予約。

クラスタがブートストラップされると、クラスタ内のノードはそれぞれ独自のローカルストレージを使用します。つまり、3つのノードがディスカバリエンドポイントを介して互いに知り合い、その情報を持つクラスタを形成しますもう検出エンドポイントが必要です。

「新しい」トークンを使用すると、ノードがすでに独自のクラスタを形成しているため、クラスタはすでにブートストラップされているため、実際には使用しません。 新しいクラスタをブートストラップするには、各ノードのローカルデータを削除する必要があります。

新しいクラスタに移動する必要がある他のデータがある場合は、移行のドキュメントを読むことをお勧めします。

etcdctl backup \ 
     --data-dir /var/lib/etcd \ 
     --backup-dir /tmp/etcd_backup 
関連する問題