/keptn/
is a message-driven control plane for application delivery and automated operations, that allows
- Developers to focus on code instead of creating YAML files
- DevOps to focus on tools instead of building pipelines
- SREs to enforce processes instead of debugging problems
Learn more about Keptn, its components, and its use cases
See and hear more about Keptn!
Keptn Core Features
Message-driven Control Plane
Keptn is a message-driven control plane that can be used for Application Delivery and Automated Operations. Here are two examples how Keptn orchestrates both delivery and operations. Please note that the tools that deploy, tests, monitor, etc. are left out for simplicity. This section focuses on the control-plane aspect of Keptn.Back to top
Application Delivery
Application Delivery starts when a new artifact is available, e.g. a container that has been built in a CI pipeline has been pushed to a container registry (1). Keptn gets notified about the new artifact by either a webhook or a user that sends an event to Keptn (2). Keptn updates the project configuration in git (3) and dispatches an event to start a dark deployment (4), . After a successful deployment tests are executed (5). Keptn gathers metrics from a monitoring provider (6) and evaluates against the specified quality criteria (quality gate) and decides that the artifact gets promoted to the next stage. Keptn updates the configuration (7) and triggers a blue/green deployment (8). As before, Keptn gathers metrics (9) and finds that the metrics don't pass the specified quality gate. Keptn rolls back changes in the configuration (10) and undeploys the new artifact from the current stage (11). Eventually, Keptn notifies the user that the application delivery workflow wasn't successful.
Back to top
Automated Operations
Automated Operations starts by adding service level indicators (SLI), service level objectives (SLO), and remediation instructions to the project configuration in Keptn (1)(2). Based on this information, Keptn configures the monitoring provider with alerting rules (3). As the monitoring of the application takes place (4), the monitoring provider finds that a SLO is not met anymore (5) and sends an alert to Keptn (6). Keptn finds an appropriate remediation action in the configuration (7) and executes said remediation action (8). The monitoring provider oversees the process and gives feedback if the problem has been solved (9).
Back to top
