Skip to main content
Version: Develop

a9s CF Service Guard

This section describes the operation of the a9s CF Service Guard component.

The a9s CF Service Guard is intended to ensure that a proper Cloud Foundry (CF) App Security Group (ASG) for each service instance exists, so that a CF app can reach out to the provisioned services instance from its CF space.

Overview​

The a9s CF Service Guard relies on a9s Consul and the a9s Service Brokers, that are part of each service deployment, to manage the ASGs in CF.

It uses a feature from Consul called Watches to be informed as soon as there is a change in the list of network nodes, e.g. a new service instance is created. The received catalog of nodes is then filtered by a configured list to ensure that only nodes from service instances are considered in the next steps. For each remaining node, the configured a9s Service Brokers are called to ensure that this node belongs to a service instance provisioned with the a9s Data Service Framework (DSF). If the node belongs to a service instance known by an a9s Service Broker, a corresponding ASG is created in CF, an existing one is updated or even deleted when the service instance has been deleted.

Additionally, the a9s CF Service Guard can check if a service instance is shared into another space in CF and create an extra ASG so that this service instance is also reachable from this space.

Installation​

To enable the support for the corresponding a9s Data Services the following Ops files MUST be applied to the a9s CF Service Guard deployment manifest, otherwise the a9s CF Service Guard will not create CF ASGs for the corresponding a9s Data Service:

  • a9s KeyValue: cf-service-guard/ops/add-keyvalue.yml
  • a9s MariaDB: cf-service-guard/ops/add-mariadb.yml
  • a9s Messaging: cf-service-guard/ops/add-messaging.yml
  • a9s MongoDB: cf-service-guard/ops/add-mongodb.yml
  • a9s MySQL: cf-service-guard/ops/add-mysql.yml
  • a9s PostgreSQL: cf-service-guard/ops/add-postgresql.yml
  • a9s Redis®*: cf-service-guard/ops/add-redis.yml
  • a9s Search: cf-service-guard/ops/add-search.yml

Background Workers​

The a9s CF Service Guard distributes the work to different background workers that are described in the following.

consul_nodes_processor​

The consul_nodes_processor is responsible to process the incoming catalog of Consul Nodes. It filters the catalog by the configured allowed_consul_nodes list and compares it with the nodes that are already in the database to detect if there are new nodes or stale nodes. If one of the two applies, then the corresponding database entry is marked as unsynchronized to be processed by the security_groups_synchronizer.

security_groups_synchronizer​

The security_groups_synchronizer is responsible to manage the ASGs in CF. It checks regularly if there are unsynchronized database entries and if there is one, it will either create, update or delete an ASG in CF depending on the state of the corresponding service instance.

shared_spaces_updater​

The task of the shared_spaces_updater is to manage the required ASGs for service instances that have been shared in CF. To do so, it checks periodically for each service instances, that is known by the a9s CF Service Guard, if it has beed shared to other spaces. Then it compares this with the internal state in the database to see if there are new shared spaces or less and binds or unbinds the related ASGs from the found spaces.

The shared_spaces_updater is disabled by default and can be enabled by applying the Ops file cf-service-guard/ops/support-shared-instances.yml to the a9s CF Service Guard deployment manifest.

Additional Documentation​

Limitations​

a9s Search vs a9s LogMe2 Service Instances​

a9s Search and a9s LogMe2 are using the same underlying data service, a9s OpenSearch, and the structure of the deployment templates is similar. This results in Consul Node names that look alike and cannot be differentiated by the a9s CF Service Guard. Although it is not necessary to have CF ASGs for a9s LogMe2 Service Instances and the related a9s Service Broker is also not configurable, the configured a9s Service Brokers are checked and this leads to additional requests and error messages in the logs.

note

This behavior can be prevented by using individual deployment name prefixes for the different a9s Data Services in combination with an appropriate regular expression for the allowed_consul_nodes property.

*Redis is a registered trademark of Redis Ltd. Any rights therein are reserved to Redis Ltd. Any use by anynines GmbH is for referential purposes only and does not indicate any sponsorship, endorsement or affiliation between Redis and anynines GmbH.