Multiple environments

956 views
Skip to first unread message

Carl Johnson

unread,
Aug 17, 2014, 1:31:22 PM8/17/14
to consu...@googlegroups.com
I'm curious how people are managing multiple environments with Consul.

I set up a few servers and had some agents connecting to them. Works great. I'm starting in our QA environment for testing things out, and it got me wondering how to distinguish QA instances of services (or any pre-production environment) versus production itself.

There are a few options I can think of:

* Different Consul clusters for each environment, or at least two: pre-prod and prod.
* Using tags to specify environment. This is what I've done so far. I'm a little worried that a client of a service might not use the tagging functionality properly, though, and connect to the wrong systems.
* Put environment in the service name. foobar-qa, foobar-dev, foobar-prod, etc.

The third option of naming the service as appropriate is probably the simplest (and thus probably the best option). I don't think I want multiple clusters in every datacenter.

What would be ideal: clients and servers specifying some sort of namespace within a cluster. For example, if agents providing services and agents consuming services both ran their agent with an option such as "-namespace qa" or "-environment qa" they would only get results returned within that namespace. Opinions?

Thanks,
Carl


Armon Dadgar

unread,
Aug 17, 2014, 11:37:04 PM8/17/14
to Carl Johnson, consu...@googlegroups.com
We recommend using the “datacenter” as the environment namespacing mechanism.
Because clients have a concept of a default datacenter it makes it harder to do
accidental requests to the wrong environment.

If you don’t want to run multiple clusters per-environment, one approach is to
just run multiple instances of Consul on the same hardware. For example, if
you have 3 physical servers, you can run the prod and stage environments
on them by just running 2 instances of Consul per server.

Hope that helps!

Best Regards,
Armon Dadgar
--
You received this message because you are subscribed to the Google Groups "Consul" group.
To unsubscribe from this group and stop receiving emails from it, send an email to consul-tool...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Eduard Dudar

unread,
Mar 26, 2015, 7:03:25 PM3/26/15
to consu...@googlegroups.com, carliva...@gmail.com
Are there any concerns regarding multiple Consul clusters for environments? So basically if we have production and staging clusters, then each cluster has multiple data centers that correspond to actual AWS data centers - us-east-1, us-west-1, us-west-2, etc. This way we don't mix production and staging at all that minimizes chances to create a mess accidentally. We may configure key-value replication between data centers and staging keys won't get to production because of isolation. Seems reasonable to have them isolated. Are there negative consequences expected? Thanks!

Armon Dadgar

unread,
Mar 30, 2015, 3:31:56 PM3/30/15
to consu...@googlegroups.com, Eduard Dudar, carliva...@gmail.com
Hey Eduard,

There are no concerns with it, that is the recommended deployment for multiple environments.
Having independent clusters as you’ve suggested is the simplest and safest way to handle it.

Best Regards,
Armon Dadgar

karthikeyan palanivelu

unread,
Feb 9, 2016, 8:39:03 AM2/9/16
to Consul, eduard...@gmail.com, carliva...@gmail.com
Hi All,

In my scenario we have different QA regions one System testing, Regression Testing(Automated Nightly) and Integration testing. We would like to use the same cluster. Please advice how I can achieve this functionality using Consul?

We are planning to use Consul, Nginx, ECS and Docker for Microservices.

Regards
Karthik


On Monday, March 30, 2015 at 3:31:56 PM UTC-4, Armon Dadgar wrote:
Hey Eduard,

There are no concerns with it, that is the recommended deployment for multiple environments.
Having independent clusters as you’ve suggested is the simplest and safest way to handle it.

Best Regards,
Armon Dadgar
Reply all
Reply to author
Forward
0 new messages