Skip to content
This repository has been archived by the owner on Sep 18, 2020. It is now read-only.

etcd: Add static cluster configuration option #299

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

fillet54
Copy link

Currently the only way to configure an etcd cluster is by using the
discovery service. This may not always be an option especially for
offline scenarios. An option 'enable_discovery_service' is added to
allow for the enabling/disabling of using the discovery service versus
using a static cluster configuration. This option is defaulted to 'true'
to maintain the use of the discovery service as the default. When the
discovery service option is disabled the etcd cluster will be statically
configured and will be comprised of each instance.

Additionally static configuration requires that each etcd member be
named explicitly. This means that each node requires a 'user-data' file
that has the etcd member name set. When the discovery service option is
disabled a 'user-data' file for each instance will be created. The name
of each of these files will be 'user-data' appended with the instance
id (ex. user-data-01) and will have the etcd member name set to the
instance name (ex. core-01).

Currently the only way to configure an etcd cluster is by using the
discovery service. This may not always be an option especially for
offline scenarios. An option 'enable_discovery_service' is added to
allow for the enabling/disabling of using the discovery service versus
using a static cluster configuration. This option is defaulted to 'true'
to maintain the use of the discovery service as the default. When the
discovery service option is disabled the etcd cluster will be statically
configured and will be comprised of each instance.

Additionally static configuration requires that each etcd member be
named explicitly. This means that each node requires a 'user-data' file
that has the etcd member name set. When the discovery service option is
disabled a 'user-data' file for each instance will be created. The name
of each of these files will be 'user-data' appended with the instance
id (ex. user-data-01) and will have the etcd member name set to the
instance name (ex. core-01).
Incorrectly assumed that etcd v1 and v2 static configuration was the
same. In v1 a peers list should be provided that is just a list of the
peers ip and port. In addition to a peers list an initial leader must be
selected by not having a peers list. This was accomplished by deleting
the peers list for the last instance of the cluster.
@fillet54
Copy link
Author

Here is the user-data file I used to test the etcd v1 cluster with static configuration. For the etcd2 case I used user-data.sample as is.

#cloud-config

coreos:
  etcd:
    addr: $public_ipv4:4001
    peer-addr: $private_ipv4:7001

  fleet:
    public-ip: $public_ipv4
  flannel:
    interface: $public_ipv4
  units:
    - name: etcd.service
      command: start
    - name: fleet.service
      command: start
    - name: flanneld.service
      drop-ins:
      - name: 50-network-config.conf
        content: |
          [Service]
          ExecStartPre=/usr/bin/etcdctl set /coreos.com/network/config '{ "Network": "10.1.0.0/16" }'
      command: start
    - name: docker-tcp.socket
      command: start
      enable: true
      content: |
        [Unit]
        Description=Docker Socket for the API

        [Socket]
        ListenStream=2375
        Service=docker.service
        BindIPv6Only=both

        [Install]
        WantedBy=sockets.target

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant