Servers inventory with consul

264 views
Skip to first unread message

Luis

unread,
Jan 13, 2016, 6:10:27 AM1/13/16
to consu...@googlegroups.com
Hi guys,

I'm working on removing chef server out of our platform. This has
several consequences. One that I'm analyzing is the service discovery.

We use chef server searches mainly for a couple of things.

One is services discovery for another services configuration. This
happens inside every node. Some of this discovery operations are being
moved to live DNS discovery and others will be moved to configuration
files through consul-template or similar.

We use chef server searches for scripts execution. This happens
outside the nodes. With scripts execution I mean maintenance
operations with, for example, fabric or deploys with, for example,
capistrano, ansible, fabric, etc...

The first case is pretty clear to me. I have some doubts about the second one.
We run this searches based on different parameters like role of the
server, datacenter, environment or even some variable tags.

The role filter is pretty much covered with the service discovery
capabilities of consul. The datacenter one is solved too in consul. I
have doubts about environment or any other type of variable.

If I'm not wrong service tags is the only attribute in consul that
allows variable values. It's also possible to list services by a
specific tag. This could solve the problem. I could set the
environment of a service as a tag. I could also set another arbitrary
values in the tags list to be able to do searches by other type of
filters.

I can see there are a couple of API endpoints that allow services
register, which are agent and catalog. I'm already setting tags with
agent endpoint for operations that happen inside a node. However,
sometimes, I may need to change a tag of a service from outside the
node. In this case I believe I would use the catalog endpoint.

I've notice that this endpoints allow absolute service registering.
Not updates. What I'm doing when I want to change a tag with the agent
endpoint is reading the service config json, modify the tag and
re-register the service.
I believe that for registering the service through the catalog API it
would be the same thing. GET the service, modify the tags and POST the
service.

I'm considering other options too for the inventory replacement but it
would be great to be able to use consul for it since we are already
integrating it for live service discovery.

Anyone can tell if my description and use case as a inventory makes
sense? Or I am missing something.

Thanks

James Phillips

unread,
Jan 13, 2016, 10:44:11 PM1/13/16
to consu...@googlegroups.com
Hi Luis,

It seems reasonable to use tags as you described. You are correct that the current HTTP APIs require you to re-post the whole structure to do an update. There's one other subtle thing to keep in mind:

Usually, the agents are the source of truth about the configuration of services and they keep the catalog up to date automatically (they push updates to the catalog on the servers). If an agent wants to change its tags it can use this endpoint and the catalog will be synced up automatically:


If you want to update the tags external to the agent through the catalog, you'll need to be sure to set the EnableTagOverride option is set:


If that option is set, then you can update the tags in the catalog and the agent will sync the changes down from the servers.

Hope that helps!

-- James


--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.

GitHub Issues: https://github.com/hashicorp/consul/issues
IRC: #consul on Freenode
---
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/consul-tool/CAM-gcbTpUj5fH4axRUYQGBwDoJBTmxiYexEQ2L4gE6NGPNmcTw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Luis

unread,
Jan 14, 2016, 2:13:29 AM1/14/16
to consu...@googlegroups.com

Hi James,

Thanks for the feedback. Pretty useful.
I'm already using EnableTagOverride. I was counting on it.

I will give feedback once everything is well integrated.

Cheers

Reply all
Reply to author
Forward
0 new messages