Merge pull request #133 from LLParse/etcd-ha

Etcd v2.3.3 upgrade with standalone bugfix
This commit is contained in:
Bill Maxwell 2016-05-11 14:59:47 -07:00
commit 9cc4ca52f8
5 changed files with 96 additions and 2 deletions

View File

@ -33,6 +33,7 @@ etcd-discovery:
bootstrap: bootstrap:
image: rancher/etcd:v2.3.0 image: rancher/etcd:v2.3.0
command: bootstrap ${REPLICAS} command: bootstrap ${REPLICAS}
link: container:etcd-discovery links:
- etcd-discovery
labels: labels:
io.rancher.container.start_once: 'true' io.rancher.container.start_once: 'true'

View File

@ -0,0 +1,37 @@
# Etcd
A distributed, highly-available key/value store written in Go.
### Info:
This creates an N-node etcd cluster on top of Rancher. The bootstrap process is performed using a standalone etcd discovery node. Upon the cluster entering a running state, this discovery service will shutdown. The state of the etcd cluster is a key/value pair stored on etcd itself, in a hidden key at location `/_state`.
Etcd node restarts and upgrades are fully supported. Please only restart/upgrade `floor(N/2)` nodes at one time in order to maintain service stability. Restarting or upgrading all nodes at once will cause service downtime, but the volume containerization should prevent data loss. While this template can survive `floor(N/2)` node/data volume failures while maintaining service uptime, manual intervention may be required in the face of a corrupted data volume.
Scaling up an existing etcd cluster is fully automated using the [Etcd Members API](https://coreos.com/etcd/docs/2.3.0/members_api.html).
Scaling down is unsupported..
### Usage:
Select etcd the catalog page.
Fill in the number of nodes desired. This should be an **ODD** number. Recommended configurations are 3, 5, or 7 node deployments. More nodes increases read availability while decreasing read latency. Less nodes decreases write latency, but sacrifices read latency and availability.
Click deploy.
Once the stack is deployed and assuming your application is deployed within it, you can access the etcd cluster in your application like so:
```
etcdctl --endpoints http://etcd:2379 member list
```
On the etcd cluster itself, ETCDCTL_ENDPOINT environment variable is set so you may inspect like so:
```
etcdctl member list
```
It is always possible that DNS will return an IP address for an etcd node that is dying. Your application should ensure connection retry logic exists when it uses etcd, or alternatively provide 2+ endpoints using IP addresses to ensure high availability.

View File

@ -0,0 +1,40 @@
etcd:
image: rancher/etcd:v2.3.3
command: node ${REPLICAS}
labels:
io.rancher.sidekicks: data
# try not to schedule etcd nodes on the same host
io.rancher.scheduler.affinity:container_label_soft_ne: etcd=node
etcd: node
expose:
- "2379"
- "2380"
environment:
ETCDCTL_ENDPOINT: http://etcd:2379
volumes_from:
- data
# containerize data volume to enable restarts and upgrades
data:
image: busybox
command: /bin/true
net: none
volumes:
- /data
labels:
io.rancher.container.start_once: 'true'
# Discovery containers are used for bootstrapping a cluster.
# They will shutdown once this process is completed.
etcd-discovery:
image: rancher/etcd:v2.3.3
command: discovery_node
labels:
io.rancher.container.start_once: 'true'
io.rancher.sidekicks: bootstrap
bootstrap:
image: rancher/etcd:v2.3.3
command: bootstrap ${REPLICAS}
links:
- etcd-discovery
labels:
io.rancher.container.start_once: 'true'

View File

@ -0,0 +1,16 @@
.catalog:
name: "Etcd"
version: "2.3.3-rancher1"
description: |
Distributed highly-available key-value store
minimum_rancher_version: "v0.46.0"
questions:
- variable: "REPLICAS"
description: "Number of Etcd nodes. 3, 5, or 7 are good choices"
label: "Number of Nodes:"
required: true
default: 3
type: "int"
etcd:
retain_ip: true
scale: ${REPLICAS}

View File

@ -1,5 +1,5 @@
name: Etcd name: Etcd
description: | description: |
A highly-available key value store A highly-available key value store
version: 2.3.0-rancher1 version: 2.3.3-rancher1
category: Clustering category: Clustering