timperrett · July 10, 2017 22:01
diff --git a/gistfile1.txt b/gistfile1.txt
 nelson {
  network {
    # Typically Nelson is hosted behind a reverse proxy, or otherwise bound
    # to an internal address. In order for cookie retention to work for browsers,
    # and for Nelson to rewrite its generated URLs to locations that are
    # network accessible, the operator must tell Nelson what that external address is.
    external-host = "nelson.yourco.com"
  }
  github {
    # If you're operating Nelson in conjunction with Github Enterprise, then you
    # need to be sure you've set this value to the host (without protocol prefix).
    # For example <code>github.yourco.com</code>
    domain = "github.yourco.com"
    # The client_id and client_secret provided to you from Github, whilst
    # setting up the application. See the "Authorize with Github" section for more
    # on the paramaters below:
    client-id = "XXXXXXX"
    client-secret = "YYYYYYYYYY"
    redirect-uri = "http://nelson.yourcompany.com/auth/exchange"
    access-token = "TOKEN-FROM-SCRIPT"
    # Certain operations in Nelson make serious state modifications, and as such
    # these are restricted to a specific set of "admin" users. The operator must
    # specifiy these users at boot time. Changing these values whilst Nelson is
    # running will have absolutely no effect (i.e. the process must be rebooted
    # for changes to take effect)
    organization-admins = [ "user1", "user2" ]
  }
  security {
    # These keys are used to securely encrypt the Nelson session token that are
    # generated when a user logs into the system. The keys themselves must be
    # at least 24 characters long. A helpful script in ./bin/generate-keys can
    # be used to automatically generate the right values.
    # *****DO NOT USE THESE VALUES*****
    encryption-key = "4e08LjzM42El6+Gbfp9XaQ=="
    signature-key = "ZRq3NkqbccXE7+ZkRirjOg=="
  }
  docker {
    # Decide how you would like Nelson to attempt to interact with Docker.
    # This is typically done either by a unix domain socket, or via a tcp
    # endpoint. Nelson itself is controling docker via the CLI, so it will
    # use whatever the configuration is for a given host.
    connection = "unix:///path/to/docker.sock"
    # connection = "tcp://0.0.0.0:12345"
  }

  datacenters {
    # The name of this key must be a DNS value name. Typically you want to call your
    # datacenters something logical, but keep it short. AWS for example, uses
    # us-east-1, us-west-1 etc.
    # Datacenter names must be lowercase, and not include specical characters.
    texas {

      docker-registry = "sxxxx.net/bar"

      # this is the DNS domain used for a given datacenter. When writing out the lighthouse
      # routing graph or similar, Nelson will use this value as the TLD for a given datacenter
      # "world". An assumption is being made here that you're running DNS fowrading for
      # the consul service: https://www.consul.io/docs/guides/forwarding.html
      domain = "service.example.com"

      # What should the default traffic shifting policy be in this particular DC.
      # Configurable per-DC such that you might have production DCs, vs dev DCs
      # (of course remember DC is a virtual concept)
      traffic-shift {
        policy = "atomic"
        duration = 30 minutes
      }

      infrastructure {
        scheduler {
          nomad {
            # Where can Nelson access the Nomad leader cluster
            endpoint  = "https://nomad.service"
            # How much grace shall we give when talking to Nomad.
            # Depending upon your link speed (e.g. if you're tunneling via SSH or
            # IPSEC it might be slower)
            timeout   = 1 second
            # On average, how many MHz of CPU does each node in this datacenter have?
            # This is used to compute the `cores` convenience in the Nelson manifest;
            # its typically better to under-specify this value, rather than over-specify
            # in the event you have a mixed fleet of machines.
            mhz-per-cpu = 2300
            # location of the runtime Docker registry. Optionally, if you require auth
            # for pushing or pulling from this registry, specify it here.
            # NOTE: Nomad does not currently encrypt these values in its `nomad inspect`
            # functionality, so be aware that unless you have a secure API access to
            # nomad, then users might see these values.
            docker {
              user = "randal mcmurphy"
              password = "one flew"
              host = "registery.service.whatever.com"
              logging-image = "fooo/logging-sidecar:1.2.3"
            }
          }
        }
        consul {
          # Location of the consul service in this datacenter.
          endpoint  = "https://consul.service.whatever.com"
          # How much grace shall we give when talking to Consul.
          # Depending upon your link speed (e.g. if you're tunneling via SSH or
          # IPSEC it might be slower)
          timeout   = 1 second
          # Nelson will be writing to the KV store in Consul, so be sure to have
          # an appropriate ACL token set here if required for read or write operations.
          acl-token = "..."
        }
        vault {
          endpoint = "https://vault.california.service"
          # How much grace shall we give when talking to Vault.
          # Depending upon your link speed (e.g. if you're tunneling via SSH or
          # IPSEC it might be slower)
          timeout   = 1 second
          # Nelson will be administering Vault, creating policies and such. With this
          # in mind, you need to ensure that Nelson has a vault authentication token
          # which permits these operations.
          auth-token = "..."
        }
      }
      policy {
        # When Nelson manages policies and credential stores in Vault, where should
        # it assume it can find them. This simplistic substitution syntax allows you
        # to control how Nelson will read and write to and from Vault storage paths.
        resource-creds-path = "nelson/%env/%resource%/creds/%unit%"
        # If you have Vault configured to generate SSL certificates, then in order for
        # deployed containers to be able to generate these certs at runtime, you need
        # to have Nelosn include that backend in the policy it generates. If you have
        # a global PKI backend called "sslpki", then you can statically set the
        # backend like this:
        # pki-path = "sslpki"
        # In the event you have a dynamic "per-environment" SSL security world, then
        # this simple substitution language allows you to tell Nelson how it should
        # discover the PKI backend path in vault.
        pki-path = "%env%_certificates"
      }
    }
  }
 }
	nelson {
	network {
	# Typically Nelson is hosted behind a reverse proxy, or otherwise bound
	# to an internal address. In order for cookie retention to work for browsers,
	# and for Nelson to rewrite its generated URLs to locations that are
	# network accessible, the operator must tell Nelson what that external address is.
	external-host = "nelson.yourco.com"
	}
	github {
	# If you're operating Nelson in conjunction with Github Enterprise, then you
	# need to be sure you've set this value to the host (without protocol prefix).
	# For example <code>github.yourco.com</code>
	domain = "github.yourco.com"
	# The client_id and client_secret provided to you from Github, whilst
	# setting up the application. See the "Authorize with Github" section for more
	# on the paramaters below:
	client-id = "XXXXXXX"
	client-secret = "YYYYYYYYYY"
	redirect-uri = "http://nelson.yourcompany.com/auth/exchange"
	access-token = "TOKEN-FROM-SCRIPT"
	# Certain operations in Nelson make serious state modifications, and as such
	# these are restricted to a specific set of "admin" users. The operator must
	# specifiy these users at boot time. Changing these values whilst Nelson is
	# running will have absolutely no effect (i.e. the process must be rebooted
	# for changes to take effect)
	organization-admins = [ "user1", "user2" ]
	}
	security {
	# These keys are used to securely encrypt the Nelson session token that are
	# generated when a user logs into the system. The keys themselves must be
	# at least 24 characters long. A helpful script in ./bin/generate-keys can
	# be used to automatically generate the right values.
	# ***DO NOT USE THESE VALUES***
	encryption-key = "4e08LjzM42El6+Gbfp9XaQ=="
	signature-key = "ZRq3NkqbccXE7+ZkRirjOg=="
	}
	docker {
	# Decide how you would like Nelson to attempt to interact with Docker.
	# This is typically done either by a unix domain socket, or via a tcp
	# endpoint. Nelson itself is controling docker via the CLI, so it will
	# use whatever the configuration is for a given host.
	connection = "unix:///path/to/docker.sock"
	# connection = "tcp://0.0.0.0:12345"
	}

	datacenters {
	# The name of this key must be a DNS value name. Typically you want to call your
	# datacenters something logical, but keep it short. AWS for example, uses
	# us-east-1, us-west-1 etc.
	# Datacenter names must be lowercase, and not include specical characters.
	texas {

	docker-registry = "sxxxx.net/bar"

	# this is the DNS domain used for a given datacenter. When writing out the lighthouse
	# routing graph or similar, Nelson will use this value as the TLD for a given datacenter
	# "world". An assumption is being made here that you're running DNS fowrading for
	# the consul service: https://www.consul.io/docs/guides/forwarding.html
	domain = "service.example.com"

	# What should the default traffic shifting policy be in this particular DC.
	# Configurable per-DC such that you might have production DCs, vs dev DCs
	# (of course remember DC is a virtual concept)
	traffic-shift {
	policy = "atomic"
	duration = 30 minutes
	}

	infrastructure {
	scheduler {
	nomad {
	# Where can Nelson access the Nomad leader cluster
	endpoint = "https://nomad.service"
	# How much grace shall we give when talking to Nomad.
	# Depending upon your link speed (e.g. if you're tunneling via SSH or
	# IPSEC it might be slower)
	timeout = 1 second
	# On average, how many MHz of CPU does each node in this datacenter have?
	# This is used to compute the `cores` convenience in the Nelson manifest;
	# its typically better to under-specify this value, rather than over-specify
	# in the event you have a mixed fleet of machines.
	mhz-per-cpu = 2300
	# location of the runtime Docker registry. Optionally, if you require auth
	# for pushing or pulling from this registry, specify it here.
	# NOTE: Nomad does not currently encrypt these values in its `nomad inspect`
	# functionality, so be aware that unless you have a secure API access to
	# nomad, then users might see these values.
	docker {
	user = "randal mcmurphy"
	password = "one flew"
	host = "registery.service.whatever.com"
	logging-image = "fooo/logging-sidecar:1.2.3"
	}
	}
	}
	consul {
	# Location of the consul service in this datacenter.
	endpoint = "https://consul.service.whatever.com"
	# How much grace shall we give when talking to Consul.
	# Depending upon your link speed (e.g. if you're tunneling via SSH or
	# IPSEC it might be slower)
	timeout = 1 second
	# Nelson will be writing to the KV store in Consul, so be sure to have
	# an appropriate ACL token set here if required for read or write operations.
	acl-token = "..."
	}
	vault {
	endpoint = "https://vault.california.service"
	# How much grace shall we give when talking to Vault.
	# Depending upon your link speed (e.g. if you're tunneling via SSH or
	# IPSEC it might be slower)
	timeout = 1 second
	# Nelson will be administering Vault, creating policies and such. With this
	# in mind, you need to ensure that Nelson has a vault authentication token
	# which permits these operations.
	auth-token = "..."
	}
	}
	policy {
	# When Nelson manages policies and credential stores in Vault, where should
	# it assume it can find them. This simplistic substitution syntax allows you
	# to control how Nelson will read and write to and from Vault storage paths.
	resource-creds-path = "nelson/%env/%resource%/creds/%unit%"
	# If you have Vault configured to generate SSL certificates, then in order for
	# deployed containers to be able to generate these certs at runtime, you need
	# to have Nelosn include that backend in the policy it generates. If you have
	# a global PKI backend called "sslpki", then you can statically set the
	# backend like this:
	# pki-path = "sslpki"
	# In the event you have a dynamic "per-environment" SSL security world, then
	# this simple substitution language allows you to tell Nelson how it should
	# discover the PKI backend path in vault.
	pki-path = "%env%_certificates"
	}
	}
	}
	}