Update to Consul V1.0.1 by diemonster · Pull Request #11 · quintilesims/consul

diemonster · 2017-11-30T23:26:52Z

This PR updates Consul to use the latest 1.0.1 version, which introduced several new pieces of functionality and/or breaking changes. Several runtime configuration options for Consul needed to be changed as a result, with some new features added as well.

Details

Added Consul's new aws -retry-join functionality, which can target a tagged cluster for new node joins. This is an improvement over using an ELB for bootstrapping a Consul cluster.
Enabled host networking for Consul server containers, and configured DNS to listen on port 53 rather than an overly complex port mapping from 8600 as we had previously.
Split HelloWorld's dev environment and Consul into two separate environments with link enabled.
Set min_count for Consul's environment to ensure that server instances are not scaled down
Created persistent data volume for Consul's data-dir, which allows manual outage mitigation as detailed here.

Testing

Extensive manual testing on Layer0 v0.10.3; will need future testing on v0.11.0.

TODO

Remove hardcoded AMIs for Consul and Dev environments (must be completed after Layer0 v0.11.0 refactor)
Add environment link example in documentation

jparsons04

Some nitty things and other external considerations to think about.

jparsons04 · 2017-12-01T00:19:02Z

README.md


-When you have multiple services in a Layer0 environment, how do you get them to connect to each other? One simple answer is that you hardcode service endpoints (i.e. a Loadbalancer URL) in your application configurations. That may be OK for testing, but ultimately hardcoding endpoints is not portable, annoying to maintain, and not in line with the [guidelines of a 12-factor app](https://12factor.net/). A much better solution is to use a service like Consul, which along with another tool called Registrator, can automatically detect your services when they come online and add them to a service registry. You can then 'discover' these services using catalog endpoints via [DNS](https://www.consul.io/docs/agent/dns.html) or [HTTP](https://www.consul.io/docs/agent/http.html).
-
 For a practical applications of Consul, see our [Layer0 Consul Documentation](http://docs.xfra.ims.io/guides/consul/).


[sort of nit] This sentence doesn't make sense grammatically and the link is now out of date.

True. Docs are still WIP, I'll get to those tmrw.

jparsons04 · 2017-12-01T00:21:28Z

example/terraform/main.tf

+  environment_id = "${layer0_environment.consul.id}"
+}
+
+resource "layer0_environment" "consul" {


Just want to make a future note that adding the consul environment in this module will likely have implications for the layer0 walkthroughs that consume this module (for instance, if the walkthroughs have terraform files that make their own consul environment)

This environment is created by the HelloWorld application, I kept the Consul module behavior (of not creating an environment by itself) as-is.

andycmaj · 2017-12-01T18:34:33Z

example/terraform/main.tf

+  name = "consul"
+  // TODO: Remove hardcoded AMI
+  ami = "ami-f5fc2c8d"
+  min_count = 3


in the future, would be nice to have min_count determined internally by scheduler...

i consider it dangerous that users need to manually set this based on sum of discrete ECS instances that will end up getting spun up.

I agree this is not ideal, and we're talking about ways to make it less dangerous within our current Layer0 refactor. That being said, there is an argument for the explicitness here and how such apps are not designed to run on Layer0 in the first place.

andycmaj · 2017-12-01T18:35:00Z

terraform/Agent.json.template

 {
  "name": "consul-agent",
  "image": "consul:${consul_version}",
+  "privileged": true,


guessing this is to bind to port 53?

i see the port 53 binding on the Server template, not not the Agent. is the Server the only one that actually needs this?

It makes things a lot easier for the Server specifically because dealing w the Docker bridge IP is a pain. As for the Agent, technically containers local to it can use the Agent's exposed dns port for resolution as well. As such, I considered having the Agent follow the same port mapping pattern as Server but I opted not to in order to keep changes to a minimum. Could be convinced otherwise, though...

well this does make sense if you are using the Agent specifically for DNS service discovery... so yeah... i'll buy that... but an example of that in your getting started would be cool

andycmaj · 2017-12-01T18:35:25Z

terraform/Registrator.json.template

 {
  "name": "registrator",
  "image": "gliderlabs/registrator:latest",
+  "privileged": true,


why does registrator also need to be privileged?

because it already requires mounting the docker socket http://gliderlabs.github.io/registrator/latest/ (see their runtime params), which is effectively privileged behavior anyway. I prefer making this overall behavior more explicit.

andycmaj · 2017-12-12T00:58:48Z

so i think the one remaining thing that's preventing me from consuming this as a module is that the consul LB is private and doesn't expose http:80 by default, and there aren't variables to control that.

here is the change i needed to make to be able to consume this:

andycmaj · 2017-12-12T01:24:05Z

terraform/main.tf

  environment   = "${var.environment_id}"
  deploy        = "${layer0_deploy.consul.id}"
  load_balancer = "${layer0_load_balancer.consul.id}"
+  size          = "t2.medium" // https://www.consul.io/docs/guides/performance.html#minimum-server-requirements


FYI i don't think size works for previous (<=0.10.3) versions of L0

Ivers, Brandon (Seattle) added 15 commits November 27, 2017 13:36

update to Consul v1.0.1

0a04c28

specify environment id

0452030

fix typo

66de937

set version to v1.0.1

97ac410

fix tag interpolation

2fbb6a4

fix tag interpolation

4aff780

fix tag interpolation

0d5512a

fix tag interpolation

f177ada

fix tag interpolation

61d0d9d

fix networkMode param

32e7278

docker host mode config

f4543af

docker host mode config

55fc13a

bind config added

35524b3

update docs, add persistant consul data volume

2bc32e8

add consul / dev environment links

d097594

diemonster added the enhancement label Nov 30, 2017

diemonster requested review from tlake and zpatrick November 30, 2017 23:26

jparsons04 suggested changes Dec 1, 2017

View reviewed changes

andycmaj reviewed Dec 1, 2017

View reviewed changes

add documentation fixes

f056afb

diemonster changed the title ~~WIP: Update to Consul V1.0.1~~ Update to Consul V1.0.1 Dec 5, 2017

andycmaj reviewed Dec 12, 2017

View reviewed changes


		When you have multiple services in a Layer0 environment, how do you get them to connect to each other? One simple answer is that you hardcode service endpoints (i.e. a Loadbalancer URL) in your application configurations. That may be OK for testing, but ultimately hardcoding endpoints is not portable, annoying to maintain, and not in line with the [guidelines of a 12-factor app](https://12factor.net/). A much better solution is to use a service like Consul, which along with another tool called Registrator, can automatically detect your services when they come online and add them to a service registry. You can then 'discover' these services using catalog endpoints via [DNS](https://www.consul.io/docs/agent/dns.html) or [HTTP](https://www.consul.io/docs/agent/http.html).

		For a practical applications of Consul, see our [Layer0 Consul Documentation](http://docs.xfra.ims.io/guides/consul/).

Comments

Conversation

diemonster commented Nov 30, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Details

Testing

TODO

Uh oh!

jparsons04 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

andycmaj commented Dec 12, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

diemonster commented Nov 30, 2017 •

edited

Loading