davidd2k

MIT License

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The following documents a trial of using etcd, and confd to automatically configure a haproxy load balancer.

It is built using a combination of blogs, resources and experimentation, but provides a rough template of the approach that would allow a fully featured balancer to be configured from etcd keyvalues.

TODO

Include systemd sidekick unit to automatically register the key's into ETCD based on a docker service (for example) being started
A more complete haproxy template that builds a valid, complex haproxy that would be capable of dealing with Future PLC's balancer requirements

	import requests
	from requests.auth import HTTPBasicAuth
	import re
	from StringIO import StringIO

	JIRA_URL = 'https://your-jira-url.tld/'
	JIRA_ACCOUNT = ('jira-username', 'jira-password')
	# the JIRA project ID (short)
	JIRA_PROJECT = 'PRO'
	GITLAB_URL = 'http://your-gitlab-url.tld/'

	import requests
	from requests.auth import HTTPBasicAuth
	import re
	from StringIO import StringIO
	import urllib

	JIRA_URL = 'https://your-jira-url.tld/'
	JIRA_ACCOUNT = ('jira-username', 'jira-password')
	# the JIRA project ID (short)
	JIRA_PROJECT = 'PRO'

	vamp-workflow-health:
	environment:
	VAMP_KEY_VALUE_STORE_TYPE: consul
	VAMP_KEY_VALUE_STORE_CONNECTION: consul:8500
	VAMP_URL: http://vamp:8080
	VAMP_KEY_VALUE_STORE_ROOT_PATH: /vamp/workflow/health
	labels:
	breed: health
	workflow: health
	image: magneticio/vamp-workflow-agent:0.9.0

	#!/bin/sh

	# start it with
	#
	# docker stop $(docker ps -q); docker rm -f $(docker ps -a -q);docker rmi -f $(docker images -a -q); curl -L https://gist.github.com/FractalizeR/86549f16d2948b1b590a/raw/init.sh > init.sh && ./init.sh


	# Start only
	# curl -L https://gist.github.com/FractalizeR/86549f16d2948b1b590a/raw/init.sh > init.sh && ./init.sh

	- What do Etcd, Consul, and Zookeeper do?
	- Service Registration:
	- Host, port number, and sometimes authentication credentials, protocols, versions
	numbers, and/or environment details.
	- Service Discovery:
	- Ability for client application to query the central registry to learn of service location.
	- Consistent and durable general-purpose K/V store across distributed system.
	- Some solutions support this better than others.
	- Based on Paxos or some derivative (i.e. Raft) algorithm to quickly converge to a consistent state.
	- Centralized locking can be based on this K/V store.

	<!DOCTYPE html>
	<html lang="en">
	<head>
	<title>Octopus Release Information</title>
	<style type="text/css">

	</style>
	</head>
	<body>
	<div data-bind="visible: version() != ''">

	#
	# Assumptions
	#
	# 1. If you have a Octopus release deployed, say 1.0.0.73, there is a git
	# tag set for that commit in GitHub that is "v1.0.0.73".
	#
	# 2. You have TeamCity label each successful build in GitHub with the format
	# "v{build number}. Sidenote: it appears that TeamCity only labels the
	# default branch, but not feature branches.
	#