2. Configure the Environment

Configuration Layers

There are three configuration layers that Platform Operators need to know about when deploying the a9s Data Services Framework:

• The Cloud Config layer, which is managed by the BOSH Director and defines the IaaS-level resources. The Cloud Config is not part of the anynines-deployment repository and must be managed separately.
• The IaaS configuration layer, which contains all framework-specific information that can differ from environment to environment.
• The Service Catalog configuration layer, which is specific for each a9s Data Service, as it contains all information specific to the available offerings.

Before any deployment can be executed, a proper Cloud Config, IaaS configuration and a Service Catalog configuration for each a9s Data Service to be deployed, must be in place.

2.1. Update the Cloud Config

The Cloud Config defines the IaaS-level resources (availability zones, networks, VM types, and disk types) that BOSH uses when deploying VMs. Network definitions control which IPs are available to each deployment, and include both static and dynamic ranges. These definitions are referenced by name in deployment manifests. For full documentation on the BOSH Cloud Config format, see the official BOSH Cloud Config documentation.

Example Cloud Config Entries

The following tables show example Cloud Config entries as used in the provided config/iaas-config.yml.example, which can be used as a starting point for a faster installation. The names and sizes indicated below must be adapted to the actual workload requirements of the deployed services.

Overview

Entry Type	Example Names	Comment
azs	z1, z2, z3	Three different Availability Zones are strongly recommended.
networks	dynamic, static	Example network names used in the provided manifests. If different names are used, they must be updated in the deployment manifests and Service Plan configuration. Networks must include a static IP range for `consul-dns` and a dynamic range for all other deployments.
vm_types	small, medium, large	Additional VM types must be added for each distinct Service Plan that requires different compute resources.
disk_types	small, medium, large	Additional disk types must be added for each distinct Service Plan that requires different persistent storage.

Persistent disk types

Name	Size [GB]
small	4
medium	10
large	50

VM types

Name	vCPU count	RAM [GB]	Ephemeral Disk [GB]
small	2	4	5
medium	2	4	5
large	4	8	5

2.2. Set Up the IaaS Configuration

The IaaS configuration file contains infrastructure-specific configurations that are interpolated and applied to the deployment manifests. These configurations effectively tailor the a9s Data Services Framework to a specific environment; for example, stemcells need to be specified according to the IaaS of choice.

This file must be created under config/iaas-config.yml. An example configuration is available here. Detailed information can be found in the IaaS Configuration Properties page.

2.3. Setup the Service Catalog Configuration

The Service Catalog configuration describes how Service Plans are exposed to Application Platforms (e.g. Cloud Foundry). This configuration is specific for each a9s Data Service, and contains all information specific to the offerings that are made available, and the service plans they provide. Detailed information can be found in the Service Catalog section and the Service Plans page.

2.4. Upload the Stemcell

As part of the IaaS Configuration discussed in step 2.2, specific stemcells are defined so that deployment manifests can reference those. In order for deployments to work, these stemcells must be uploaded to the Director.

The Stemcells page of the official BOSH documentation provides the corresponding BOSH stemcell versions available for upload. In addition, the a9s Data Services Framework supports specific stemcells, as shown in Supported Stemcells.

2.5. Prepare Credentials

Certain variables must be created in CredHub before deployment. The environment preparation script generates default credentials, certificates, and encryption keys required by framework components.

The environment preparation script must be executed:

./bin/prepare.sh

This script generates default credentials and certificates with a validity period of 365 days. The certificate duration can be customized using the following environment variable:

Variable Name	Description
CERT_DURATION	Duration to be used when generating new certificates. The default is 365 days.