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.
NoteApplications that previously used the
spring-cloud-services-starter-config-client
dependency can use these instructions without removing the dependency.
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.
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.
NoteIn this example, the listed content will result in configuration being read from the following files:
cook-production.properties
on thetap
branchcook.properties
on themain
branchFor 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.
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
.
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.