[Feature]: App Developer can see service binding credentials are volume mounted onto their workload containers

cloudfoundry / korifi

Cloud Foundry on Kubernetes

Apache License 2.0

317 stars 65 forks source link

Blockers/Dependencies

Blocker: https://github.com/cloudfoundry/cf-k8s-controllers/issues/506

Background

Cloud Native Buildpacks and some app frameworks (such as Spring Cloud Bindings) are adopting the K8s ServiceBinding spec model of volume mounted secrets. We currently are providing apps access to these via the VCAP_SERVICES environment variable (see this issue) for backwards compatibility reasons, but want to support these newer developments in the ecosystem as well.

We don't need to implement this ourselves. Theoretically any reconciler that adopts the spec can update Pod-specable workloads to do this. Let's look into using this Service Binding reconciler to do this and install it in our dev envs (Kind) and hack installation scripts. If we set up the spec.workload correctly in https://github.com/cloudfoundry/cf-k8s-controllers/issues/506 this reconciler should be able to modify the StatefulSets that Eirini Controller is producing†. Then we can document that if developers/operators want this behavior they can use that reconciler or install a comparable one. If that all works well then it means we can avoid having to develop a partial implementation of the projection spec in our own controllers.

As an App Developer I want service binding credentials to be projected into my running workloads via volume mounts So that I my K8s Service Binding-aware apps can find service binding credentials in the way they expect

† Let's confirm there is no contention between this reconciler and Eirini Controller

Acceptance Criteria

Documentation

GIVEN I have a cluster available WHEN I Follow our installation documentation THEN I Can install a Service Binding reconciler and see the K8s ServiceBindings associated with our CFServiceBindings get reconciled by it

Functionality

GIVEN I have installed cf-k8s-controllers and have included a Service Binding reconciler WHEN I bind a user-provided service instance to my app (cf bind-service MY_APP MY_INSTANCE) THEN I see that eventually there exists a K8s ServiceBinding (done in https://github.com/cloudfoundry/cf-k8s-controllers/issues/506) AND I see that the credentials for that binding are volume mounted into the Pods for my app

Dev Notes

https://github.com/vmware-labs/service-bindings
https://github.com/servicebinding/spec#workload-projection
We can use this Spring PetClinic app to test: https://github.com/vmware-labs/service-bindings/tree/main/samples/spring-petclinic

How I accepted this:

Deploying Spring PetClinic with kpack

I started with the same app that the Service Bindings reconciler codebase uses to test.

Cloned Spring PetClinic
Created the following CF app manifest in the app's directory to set the required env vars
```
---
applications:
- env:
SPRING_PROFILES_ACTIVE: "mysql"
```
Ran kubectl -n $(cf space s --guid) apply -f https://raw.githubusercontent.com/vmware-tanzu/servicebinding/4248dce6f9f7617662a098a3f2ef37f0c706e32c/samples/spring-petclinic/service.yaml to deploy a MySQL db I could use

Created an UPSI with the same credentials as the db above:

cf cups mysql -p '{"type":"mysql","provider":"mariadb","host":"spring-petclinic-db","port":"3306","database":"default","username":"user","password":"pass"}'`

Pushed the app with no-start so that I could bind the service before staging: cf push spring-petclinic --no-start
Bound the UPSI: cf bind-service spring-petclinic mysql
Pushed the app cf push spring-petclinic (it failed due to there being competing maven and gradle config present https://github.com/paketo-buildpacks/java/issues/423)
- We can't set buildpack specific env vars until https://github.com/cloudfoundry/cf-k8s-controllers/issues/774 is done, so I manually deleted the maven dirs/files and pom.xml from the repo
Pushed the app again..
Built successfully, but failed to start: ERROR: failed to launch: determine start command: when there is no default process a command is required
Apparently the gradle stuff was messed up and prevented the buildpack from being able to detect anything to run, so I restored the pom.xml and deleted the gradle files instead
It worked!!

This is what my spring-petclinic working dir looked like after what I did to it:

✔ ~/workspace/spring-petclinic [main|✚ 6…1]
16:53 $ gst
On branch main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    deleted:    build.gradle
    deleted:    gradle/wrapper/gradle-wrapper.jar
    deleted:    gradle/wrapper/gradle-wrapper.properties
    deleted:    gradlew
    deleted:    gradlew.bat
    deleted:    settings.gradle

Untracked files:
  (use "git add <file>..." to include in what will be committed)
    manifest.yml

cloudfoundry / korifi