Service Groups

[edit on GitHub]

A service group is a logical grouping of services with the same package and topology type connected together across a Supervisor network. They are created to share configuration and file updates among the services within those groups and can be segmented based on workflow or deployment needs (QA, Production, and so on). Updates can also be encrypted so that only members of a specific service group can decrypt the contents.

By default, every service joins the service-name.default service group unless otherwise specified at runtime.

In addition, multiple service groups can reside in the same Supervisor network. This allows data exposed by Supervisors to be shared with other members of the ring, regardless of which group they are in.

Joining a Service Group

To join services together in a group, they must be running on Supervisors that are participating in the same Supervisor gossip network (i.e., they are ultimately peered together), and they must be using the same group name. To illustrate, we’ll show two core/redis services joining into the same group.

First, we’ll start up two Supervisors on different hosts, peering the second one back to the first.

$ hab sup run # on 172.18.0.2 (Supervisor A)
hab-sup(MR): Supervisor Member-ID e89b6616d2c040c8a82f475b00ba8c69
hab-sup(MR): Starting gossip-listener on 0.0.0.0:9638
hab-sup(MR): Starting ctl-gateway on 0.0.0.0:9632
hab-sup(MR): Starting http-gateway on 0.0.0.0:9631

$ hab sup run --peer=172.18.0.2:9638 # on 172.18.0.3 (Supervisor B)
hab-sup(MR): Supervisor Member-ID bc8dc23243e44fee8ea7b9023073c28a
hab-sup(MR): Starting gossip-listener on 0.0.0.0:9638
hab-sup(MR): Starting ctl-gateway on 0.0.0.0:9632
hab-sup(MR): Starting http-gateway on 0.0.0.0:9631

Now, run the following on each Supervisor to load core/redis in the “prod” group:

hab svc load core/redis --group=prod

Each will start up, and will be joined into the same group; here is Supervisor A’s output:

And here is Supervisor B’s output:

Note that they are both listening on the same port.

To prove they are in the same group, we can apply a configuration change; if they are in the same group, they should both receive the change.

Let’s change the port they’re running on using the hab config apply command, run from Supervisor A.

echo 'port = 2112' | hab config apply redis.prod 1

Both service instances restart with the new configuration. Supervisor A’s output is:

and Supervisor B’s output is:

Note that they have both restarted (as evidenced by the new PID values), and that both are now running on port 2112, as we instructed.

Had the services been in different groups, the configuration change would not have applied to both of them (it was targeted at redis.prod). If the Supervisors has not been in gossip communication (achieved here through the use of the --peer option when Supervisor B was started), the configuration rumor (injected into Supervisor A’s gossip network) would not have made it to core/redis service running on Supervisor B.