8. Install the a9s Data Services

The a9s Data Services provide on-demand provisioning of dedicated service instances. Each Service Instance is deployed as an independent BOSH deployment, managed by the a9s Data Services Framework. The framework consists of three core components per Data Service: the a9s Service Broker, the a9s BOSH Deployer, and the a9s Service Provisioning Interface (SPI), alongside other components that help these main ones achieve their goals.

The Data Services coexist with supporting services such as the a9s Backup Service, and rely on foundational services such as a9s Consul for service discovery and a9s-pg as the central state store for all framework components. More information on the overall framework architecture can be found in Deployment Architecture.

The following Data Services are available:

• a9s PostgreSQL: Relational database service
• a9s MongoDB: Document database service
• a9s MariaDB: Relational database service
• a9s Messaging: Message broker service
• a9s KeyValue: Key-value store service
• a9s LogMe2: Logging stack service
• a9s Search: Search and analytics service
• a9s Prometheus [BETA]: Aggregation and visualization service

This step must be repeated for each Data Service to be installed.

8.1. Update BOSH Director Configuration

The a9s BOSH Deployer requires access to a BOSH Director in order to provision Service Instances. Therefore, the BOSH Director credentials must be configured into the deployment manifest.

The first step is to retrieve the following credentials from the BOSH Director's creds.yml file and store them in CredHub:

• deployer_director_environment: this value has the BOSH director's IP address. It is a single string value.
• deployer_director_ca_cert: this value has the BOSH director's CA certificate. It is a certificate-type value.
• deployer_director_client: this value has the BOSH director's username and password. It is a user-type value, meaning that the username and password can be accessed as follows: ((/deployer_director_client.username)) and ((/deployer_director_client.password))

The values can be set in CredHub by executing the following commands:

credhub set --type value --name '/deployer_director_environment' --value <BOSH_IP_ADDR>
credhub set --type certificate --name '/deployer_director_ca_cert' --certificate <(bosh int ./creds.yml \
  --path /director_ssl/ca)
credhub set --type user --name '/deployer_director_client' -w $(bosh int ./creds.yml --path /admin_password) \
  -z 'admin'

8.2. Deploy a9s Data Service

The deployment is created by executing:

bosh -d <data-service>-service deploy <data-service>-service/<data-service>-service.yml \
  -l config/iaas-config.yml \
  -l config/<data-service>.yml

8.3. Upload Service Plan Templates

The a9s BOSH Deployer is the component that talks with the BOSH director and creates BOSH deployments. In order to do this, this component needs templates of BOSH deployment manifests. There are templates for each a9s Data Service available.

Each service provides an errand called templates-uploader, this errand encapsulates these templates and uploads them to the a9s BOSH Deployer.

After deploying the service, the errand can be executed with the following command:

bosh -d <deployment-name> run-errand templates-uploader

8.4. Create Service Broker in Cloud Foundry

In order to make a service offering available in a Cloud Foundry marketplace (e.g. a9s PostgreSQL), the following commands must be executed as a Cloud Foundry admin:

cf create-service-broker a9s-postgresql-broker admin [password] \
  http://postgresql-service-broker.service.dc1.consul:3000
cf enable-service-access a9s-postgresql15

For a9s PostgreSQL, the key for retrieving the password looks like this: /postgresql_service_broker_password. It can be retrieved with credhub get -n /postgresql_service_broker_password when using CredHub.

8.5. Run Service Smoke Tests to Validate the Setup

For each a9s Data Service, there is an errand smoke-tests included. This errand verifies that the main a9s Data Service features work in the target environment.

For more information, see the Smoke Tests documentation.

bosh -d postgresql-service run-errand smoke-tests

caution

Depending on how Cloud Foundry ASGs have been configured, the a9s CF Service Guard must be deployed first (see Configure Cloud Foundry Security Groups), otherwise the smoke tests will fail.

8.6. Enable Non-GA Services

By default, each a9s Data Service's manifest only contains the corresponding GA services. Release candidates, services in the BETA phase, and deprecated services are not contained and must be enabled explicitly via the corresponding Ops-file.

caution

Note that enabling Non-GA services may have some implications. For more information, see a9s Data Service Sunrise/Sunset for Major Versions.

8.6.1. Enable Release Candidate Services

To enable a release candidate (RC) for a particular a9s Data Service, the corresponding Ops-file for that specific service version must be applied, which can be found under ops/enable_rc_services/<data_service_name>-<version_number>.yml.

8.6.2. Enable Beta Services

To enable a service in the beta release phase for a particular a9s Data Service, the corresponding Ops-file for that specific service version must be applied, which can be found under ops/enable_beta_services/<data_service_name>-<version_number>.yml.

BOSH Deployments Reference

BOSH Deployment	Description
a9s-billing/a9s-billing.yml	All components required to provide the a9s Billing System.
a9s-environment-info/a9s-environment-info.yml	All components required to provide the a9s Environment Info Service.
a9s-pg/a9s-pg.yml	A PostgreSQL cluster of three nodes based on the a9s PostgreSQL BOSH Release. The PostgreSQL cluster will be used as a data store by all a9s Data Services Framework components (e.g. the a9s Service Brokers, a9s BOSH Deployers, a9s Service Guard, etc.). If the anynines-PaaS-deployment/cf/cf.yml is deployed, the Cloud Foundry setup will also use the a9s-pg cluster (Cloud Controller and UAA will store its data there).
backup-service/backup-service.yml	The a9s Backup Framework takes care of the backup of all Service Instances. It is an optional component.
cf-service-guard/cf-service-guard.yml	The a9s CF Service Guard observes the Consul catalog and updates Cloud Foundry App Security Groups (ASGs) as soon as something changes, so that only apps deployed into Cloud Foundry space A can access Service Instances provisioned in space A. It is an optional component.
consul-dns/consul-dns.yml	An internal domain name system to resolve hostnames provided and used by the a9s Data Services Framework. While installing the a9s Data Services, these name servers must be made available in the platform environment either via DNS query delegation or by configuring these name servers into the platform directly.
keyvalue-service/keyvalue-service.yml	All components required to provide the a9s KeyValue Data Service.
mariadb-service/mariadb-service.yml	All components required to provide the a9s MariaDB Data Service (versions >= 10.6).
mongodb-service/mongodb-service.yml	All components required to provide the a9s MongoDB Data Service.
postgresql-service/postgresql-service.yml	All components required to provide the a9s PostgreSQL Data Service.
rabbitmq-service/rabbitmq-service.yml	All components required to provide the a9s Messaging Data Service.