Consul Integration

Engineering : Consul integration

1. Engineering

Engineering : Consul integration

Created by Jon Park, last modified on Dec 18, 2017

• Introduction
  Consul is a service discovery mechanism and tools. Mashling gateway can be integrated with Consul for a user to reap the benefits of the combination.

• Architecture

The key runtime component of Consul is an agent. An agent is the long running daemon on every member of the Consul cluster. It is started by running consul agent. The agent is able to run in either client or server mode. Client is a lighter weight agent that is stateless. Server provides data service and communicates across WAN. A service provider interacts with an agent to register/deregister service/check. Consul handles availability and consistency of the services catalog and status. Mashling gateway is a service provider which will integrate with a Consul agent to register an API or event channel as a service. In the current version, Mashling gateway will register a health check at the gateway host level.

• • Consul architecture

• • Gateway deployment with Consul

• Gateway service registration

  Mashling CLI publish command is augmented to support consul integration in addition to the publish-to-mashery feature as follows:

  mashling publish -a -consul address:port -s -d -f <gateway_json>

  -a => registers the mashling services to Consul.
  -r => removes the mashling services from Consul
  -consul => consul agent's http address and port. The Consul agent's endpoint for this is described at https://www.consul.io/api/agent/service.html. -consul and -portal of the mashling CLI publish command are mutually exclusive. When -consul is present, the rest of the command line options are used for the consul integration, not for publish-to-mashery. When -portal is present, the existing publish-to-mashery options are to be honored as is.
  -s => security token required to invoke consul's http api endpoint. The token is used to set the header "X-consul-Token: " when invoking consul's service registration endpoint, /v1/agent/services/register. When -portal option is present, -s is treated as the api secret key for the existing publish-to-portal command.
  -d => consul's service definition folder. The Consul agent's sevice definition is described at https://www.consul.io/docs/agent/services.html. For a dynamic update of Consul agent, SIGHUP signal by invoking "kill -HUP on the command line after the service definition folder is updated. -t and -d options are mutually exclusive.
  -f => mashling gateway json file to register the services for. The following mapping occurs during registration:

  Consul service definition fields

  Mashling json fields

  Name

  trigger's name

  Tags

  empty

  Address

  gateway hostip

  Port

  trigger's port

• Gateway Health check registration

  Host level health check is added/removed when mashling consul CLI command is executed. Consul agent's health check definition at host level is described at https://www.consul.io/intro/getting-started/checks.html. The endpoint /v1/agent/check/register is invoked with the following definition:

  Consul health check definition

  Value

  Name

  ping

  script

  ping -c1 google.com >/dev/null
  

  interval

  30s

• Other design considerations

  • Auto registration by the gateway runtime binary can be enabled by augmenting the gateway configuration with Consul endpoint configuration. This can be considered for the gateway V2.
  • The future version of the Mashling gateway can support service level health check in addition to the host level check. This will require a gateway feature to interact with the backend service for the target endpoint status.

Attachments:

consul-arch-420ce04a.png (image/png)
Screen Shot 2017-12-13 at 2.58.21 PM.png (image/png)
Screen Shot 2017-12-13 at 3.08.13 PM.png (image/png)
Screen Shot 2017-12-13 at 3.08.13 PM.png (image/png)

Document generated by Confluence on Aug 06, 2018 17:19

Atlassian