What Is ACS
ACS or Application Configuration Service, is a new optional component added in TAP 1.5. ACS, is a Kubernetes native replacement for the Spring Cloud Config Server, which was an essential part of a Spring Cloud based microservices based architecture, heavily used by Spring based workloads in the Cloud Foundry and Azure Spring Apps world.
Spring Cloud Config Server helped by enabling setting runtime config for spring apps, in Git repositories. These configs could be stored on different branches and in directories that could be used to generate runtime configuration properties for applications running in multiple environments.
ACS is compatible with the existing Git repository configuration management approach, and offers a Kubernetes native integration layer, making the configuration fit much more seamlessly, with application when deployed to TAP. ACS filters runtime configuration for any application by using slices that produce secrets, which can the be bound using Service Claims, like all other external configurations or service binding in a TAP environment.
When ACS Should be used
ACS is a great replacement for any usage you may currently have of Spring Cloud Config Server, and with minimal changes can replace it, without any major changes.
ACS is extremely beneficial if you are migrating to TAP for PCF/TAS environments, where SCCS is very commonly used, and having a native integration for the same features via ACS, allows for a much easier migration path for your applications.
What does the UX look like
The first thing one would do, is configure a CR of type "Configuration Source", pointing at the Git repository where your SCCS config resides. For example:
apiVersion: "config.apps.tanzu.vmware.com/v1alpha4"
kind: ConfigurationSource
metadata:
name: greeter-config-source
namespace: my-apps
spec:
backends:
- type: git
uri: https://github.com/your-org/your-config-repo
Once we have our source configured, we then can define a slice, where points at a specific config in that source repo. for example:
apiVersion: config.apps.tanzu.vmware.com/v1alpha4
kind: ConfigurationSlice
metadata:
name: greeter-config
namespace: my-apps
spec:
configurationSource: greeter-config-source
content:
- greeter/dev
configMapStrategy: applicationProperties
interval: 10m
As you can see, this is a very simple and clear UX. the spec of these resources can be much more complex, and these are just examples, but the idea is always the same.
You can find the full documentation on this service here.
Once we have configured the ACS resources, we can simply create a resource claim which will allow us to bind the config to our workload as such:
apiVersion: services.apps.tanzu.vmware.com/v1alpha1
kind: ResourceClaim
metadata:
name: greeter-config-claim
namespace: my-apps
spec:
ref:
apiVersion: config.apps.tanzu.vmware.com/v1alpha4
kind: ConfigurationSlice
name: greeter-config
And now we can reference this resource claim in our workload as such:
apiVersion: carto.run/v1alpha1
kind: Workload
metadata:
name: greeter-messages
namespace: my-apps
labels:
apps.tanzu.vmware.com/workload-type: web
app.kubernetes.io/part-of: greeter
spec:
build:
env:
- name: BP_JVM_VERSION
value: "17"
- name: BP_GRADLE_BUILT_MODULE
value: "greeter-messages"
env:
- name: SPRING_CONFIG_IMPORT
value: "${SERVICE_BINDING_ROOT}/spring-properties/"
serviceClaims:
- name: spring-properties
ref:
apiVersion: services.apps.tanzu.vmware.com/v1alpha1
kind: ResourceClaim
name: greeter-config-claim
source:
git:
url: https://github.com/spring-cloud-services-samples/greeting
ref:
branch: main
Summary
While this feature may not be a game changing feature for many, the ability it brings to easily migrate apps from TAS/PCF/ASA environments into TAP, is a huge accomplishment, and is a huge step in the direction of TAP becoming the de-facto standard for running Spring based apps at scale in containerized environments!
I am truly excited to see these types of features being added in to TAP, making the migration story into TAP, that much smoother for brownfield environments.