Restart applications on binding/secret changes in an automated way
a-thaler opened this issue · 5 comments
Description
The BTP Operator module provides a nice way of integration services with your workload. It defines a kubernetes Secret as the agreed interface, so the operator takes care that binding data gets injected into a well-defined secret and the workload just mounts the secret and can consume that data, no direct coupling. On top, the operator supports automatic secret rotation, resulting in an updating secret over time. The app just need to fetch the most recent binding data from the local mount.
However, not all applications are supporting a dynamic reload of credentials via the file system and will just fail after the rotated secret gets wiped out. Currently the SAP CAP application is falling under that category, a binding change will not get picked up.
As there is no trivial solution for such applications at hand, it will be great if the Kyma modules could provide some functionality to automatically restart such application on secret changes.
Reasons
It is not trivial to find a solution of restarting an app for changes secrets. It usually will require custom logic coded into an operator or job.
Attachments
Potential solution is to build an additional controller in the BTP Operator module which supports the scenario. In best case it is not complicating the things by building up relations between ServiceBindings and workloads but just allows to mark the secrets to watch and the related Deployment to rollout.
A solution like letting the app crash on secret updates so that kubernetes will do the restart will not help, as all pods would crash at the same time. However, the restart must happened coordinated using the rollout command to avoid downtimes.
For inspiration please also consider https://servicebinding.io/spec/core/1.0.0/#workload-resource-mapping which defines an explicit mapping of the binding to workloads.
We can check this OS project: https://github.com/stakater/Reloader if application restart would be the decision to be followed.
Currently, CAP supports consuming credentials via VolumeMounts which is K8s specific as compared to VCAP_SERVCIES which is CF native. These approaches are totally transparent to the developers.
Similarly, perhaps CAP should add further capabilities to auto consume new credentials once they become available.
This issue has been automatically marked as stale due to the lack of recent activity. It will soon be closed if no further activity occurs.
Thank you for your contributions.
This issue has been automatically closed due to the lack of recent activity.
/lifecycle rotten