Configuring workloads in Tanzu Application Platform using Application Configuration Service

Here you will find instructions for creating, configuring, and updating ConfigurationSource and ConfigurationSlice resources for Application Configuration Service for VMware Tanzu so that an Tanzu Application Platform workloads may use them.

Note

Applications that previously used the spring-cloud-services-starter-config-client dependency can use these instructions without removing the dependency.

Create a configuration source

To create a configuration source, create a file named my-config-source.yaml file, with the following YAML definition:

apiVersion: "config.apps.tanzu.vmware.com/v1alpha4"
kind: ConfigurationSource
metadata:
  name: cook-config-source
  namespace: my-apps
spec:
  backends:
    - type: git
      uri: https://github.com/spring-cloud-services-samples/cook-config

For the metadata.name value, substitute your desired configuration source name.

Next, apply this resource to your Kubernetes cluster:

kubectl apply -f my-config-source.yaml

This will create a ConfigurationSource resource, but otherwise will not do anything until you create a configuration slice that references this configuration source resource.

Create a configuration slice

To create a configuration slice, create a file named my-config-slice.yaml file, with the following YAML definition:

apiVersion: "config.apps.tanzu.vmware.com/v1alpha4"
kind: ConfigurationSlice
metadata:
  name: cook-config-slice
  namespace: my-apps
spec:
  configurationSource: cook-config-source
  content:
  - cook/production/tap
  - cook/default

For the metadata.name value, substitute your desired configuration slice name. Likewise, for the spec.configurationSource value, substitute the name of the configuration source resource created in the previous section.

The list under spec.content specifies one or more slices of configuration to be pulled from the referenced configuration source.

Note

In this example, the listed content will result in configuration being read from the following files:

• cook-production.properties on the tap branch
• cook.properties on the main branch

For a more in-depth explanation of how content is resolved, see the ConfigurationSlice API Documentation

Next, apply this resource to your Kubernetes cluster:

kubectl apply -f my-config-slice.yaml

This will create a namespace-scoped ConfigurationSlice resource in the currently active namespace. After a few seconds, there should be a new Secret resource with a similar name as the ConfigurationSlice created in the same namespace that includes properties retrieved based on the specifications from the ConfigurationSlice and its referenced ConfigurationSource.

You can verify the creation of the Secret like this:

$ kubectl get secrets
NAME                      TYPE                             DATA   AGE
cook-config-slice-ll8hf   Opaque                           3      24s

Because secrets are immutable, it's expected to see multiple secrets for a ConfigurationSlice. This happens as a regular part of the reconciliation process and the Service Binding used in later sections will ensure a workload consumes the most up-to-date secret. The Status.Binding.Name field of a ConfigurationSlice contains the current secret and any others can safely be deleted.

Using Configuration in a Workload

Before the Secret can be consumed by a Workload, a ResourceClaim must created to claim the configuration generated by the ConfigurationSlice using this YAML definition:

apiVersion: services.apps.tanzu.vmware.com/v1alpha1
kind: ResourceClaim
metadata:
  name: cook-config-claim
  namespace: my-apps
spec:
  ref:
    apiVersion: config.apps.tanzu.vmware.com/v1alpha4
    kind: ConfigurationSlice
    name: cook-config-slice
    namespace: my-apps

Next, apply this resource to your Kubernetes cluster:

kubectl apply -f resource-claim.yaml

The configuration can be claimed in a workload using the spec.serviceClaims:

serviceClaims:
  - name: spring-properties
    ref:
      apiVersion: services.apps.tanzu.vmware.com/v1alpha1
      kind: ResourceClaim
      name: cook-config-claim

Add the following environment variable to the spec.env:

env:
- name: SPRING_CONFIG_IMPORT
  value: "optional:configtree:${SERVICE_BINDING_ROOT}/spring-properties/"

A full workload.yaml definition might look like:

apiVersion: carto.run/v1alpha1
kind: Workload
metadata:
  name: my-web-app
  labels:
    ...
spec:
  serviceClaims:
    - name: spring-properties
      ref:
        apiVersion: services.apps.tanzu.vmware.com/v1alpha1
        kind: ResourceClaim
        name: cook-config-claim
  env:
    - name: SPRING_CONFIG_IMPORT
      value: "optional:configtree:${SERVICE_BINDING_ROOT}/spring-properties/"
  source:
    git:
      url: https://github.com/spring-cloud-services-samples/cook.git
      ref:
        branch: tap

Once the workload definition has been created/updated, apply the change using tanzu workload update --file workload.yaml or tanzu workload create --file workload.yaml.

Refreshing Configuration

When the contents of a Secret change, either because the configuration source and slice have changed or because the backend repository has changed, it will be necessary for the application to be refreshed to pick up those changes.

When the Secret changes, a new and uniquely named Secret will be created with the new properties and values and the new Secret name will be reflected in the ConfigurationSlice resource's status. The workload reconciler will detect this change, adjust the deployment accordingly, and reapply the deployment automatically. This will effectively trigger a rolling restart on the application pods, all of which will start with the new configuration in effect.