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 Elasticsearch:
cf-service-guard/ops/add-elasticsearch.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 backgorund 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 disbled 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 similiar. This results in Consul Node names that look alike and cannot be differentiated by the a9s CF Service Guard. Although there is no necessaty 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.
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.