Introduction
Helm hooks enables the user to define and execute custom actions during the lifecycle of a helm release. This makes complex deployments easier. Let’s explore a bit about helm-hooks in the following.
What are Helm Hooks ?
Helm hooks provides a way to inject custom actions into the Helm chart deployment process. They allow you to define actions at various points in the lifecycle of a Helm release, such as before(pre-install) or after installing(post-install), upgrading, or deleting a release. These actions can be resources or scripts or commands that interact with the Kubernetes cluster or perform any necessary tasks to prepare or clean up resources.
Key Use Cases for Helm Hooks:
- Database Migrations: In many applications, you might need to run database migrations when deploying a new version. Helm Hooks can execute scripts to handle these migrations automatically.
- Secrets Management: If your application relies on secrets, Helm Hooks can be used to set up or rotate these secrets securely during installation or upgrades.
- Custom Initialisation: Sometimes, applications require specific initialisation tasks like creating configuration files, populating databases, or setting up external services. Helm Hooks can perform these tasks as part of the deployment process.
- Integration with External Services: If your application needs to integrate with external services or APIs, Helm Hooks can be used to set up the necessary configurations and establish connections.
- Post-Deployment Testing: After deploying an application, you might want to perform tests to ensure everything is working as expected. Helm Hooks can trigger testing processes or validation checks.
Available hooks
- pre-install
- post-install
- pre-delete
- post-delete
- pre-upgrade
- post-upgrade
- pre-rollback
- post-rollback
- test
What you need to know before using helm hooks?
The resources created by hooks are not currently tied to the corresponding releases. When a hook reaches its ready state, Helm doesn’t actively manage or track the hook resources. Although there is a possibility that in the upcoming releases helm might introduce garbage collection for hook resources upon release deletion, it’s not a guaranteed feature.
This practical implication implies that if you generate resources within a hook, you can’t rely on the helm uninstall command to automatically remove these resources when you uninstall or delete the Helm release. To properly handle the removal of such resources, you have a couple of options:
Custom Annotations: You can annotate the hook template file with helm.sh/hook-delete-policy: hook-succeeded. This annotation informs Helm to delete the resources created by the hook when the hook succeeds.
annotations:
"helm.sh/hook-delete-policy": before-hook-creation,hook-succeeded,hook-failedSet Time to Live (TTL): Alternatively, you can set a Time to Live (TTL) value for the resources, especially if they are created as part of a Job resource. This TTL value will determine how long the resources should be retained, and they will be automatically deleted once the TTL period is over.
My thoughts on hook resource deletions
Though we have TTL and annotations for the hook deletion, I feel it should also have the feature to completely remove the resource on helm uninstall.
Conclusion
Helm Hooks are a valuable feature for Helm users, simplifying the management of Kubernetes deployments by automating custom actions. They provide greater flexibility, consistency, and reliability in your deployment workflows. It’s crucial to remember that Helm Hooks also allow you to define specific deletion policies for hook-generated resources. This added level of control ensures that resources are managed with precision, and you can choose whether they are retained or deleted based on the success or failure of the associated hooks. This fine-grained resource management further enhances the reliability and predictability of your Helm-based deployments, making Helm Hooks an even more indispensable tool for Kubernetes application management.