Helm makes it easy to spin up applications, tools and services for a developer. Select, configure, and deploy an application, a tool or a service from an approved catalog.
Ease of distribution
Helm can be used to package and share applications with ease, lending scalability to applications.
Helm makes the development and testing process quicker, while refining your CI/CD strategy by building new, or using existing Helm Charts, for different environments.
Help streamline and integrate into GitOps and CI/CD efforts. It provides agility with automatic deployment and simple, consistent upgrades.
Simplify deployment by making automation generally available to developers for frequently deployed applications.
Automate manual tasks, significantly reducing deployment time, as well as chances of error during deployment.
Both custom and ISV-supported workloads and applications can be deployed on Red Hat® OpenShift® using Helm Charts. This helps with interoperability and support of cloud-native applications from ISVs, great user experience in deploying and managing ISV apps along with best practices compliance for deployment.
The OpenShift web console can be used to select and install a chart from the Helm charts listed in the Developer Catalog, as well as adding custom Helm chart repositories. Helm releases can be created, upgraded, rolled back, and uninstalled using these charts. The Helm CLI is integrated with the web terminal in the OpenShift web console making it easy to visualize, browse, and manage information regarding projects.
Listen to a short talk from Discover Financial Services on building an enterprise Helm chart repository and managing Helm charts on Red Hat OpenShift:
A Kubernetes Operator is a method of deploying and managing a Kubernetes-native application. It simplifies deployment and lifecycle management (e.g. scale in-out, update, upgrade, backup, restoration, and data-integrity management). Operators run in a loop, continuously checking the application's status and determining if the application is running according to the configuration defined by the software developer. They also automatically make any necessary changes to comply with defined and desired configuration.
Objective: Application requires automation of day-1 tasks (installation) and some simple day-2 tasks (e.g. straightforward updating from one version to the next)
Objective: Application needs simple updates, but does not need a lot of automation for day-2 ops
Objective: Maintaining or customizing an application deployed by a Helm chart requires manual steps (outside of the Helm CLI) by the user
Objective: Application requires advanced day-2 tasks, (e.g. auto-tuning, backup and recovery in case of failure, sequenced orchestration steps for updates or reconfiguration or intelligent scaling)
Tip: As a best practice, anytime an update or a reconfiguration would require manual steps using kubectl, use Operators.