From 6035e552d3f46e2553603f711db008784ff99d0e Mon Sep 17 00:00:00 2001 From: Giovanni Liva Date: Mon, 22 May 2023 14:31:43 +0200 Subject: [PATCH] docs: fix getting started guides (#1447) --- .../getting-started/observability/_index.md | 430 ++++++++++-------- .../getting-started/orchestrate/_index.md | 212 ++++++++- 2 files changed, 458 insertions(+), 184 deletions(-) diff --git a/docs/content/en/docs/getting-started/observability/_index.md b/docs/content/en/docs/getting-started/observability/_index.md index 4549f1f085..cccb7c8fbe 100644 --- a/docs/content/en/docs/getting-started/observability/_index.md +++ b/docs/content/en/docs/getting-started/observability/_index.md @@ -1,216 +1,280 @@ --- -title: Orchestrating pre- and post-deployment tasks and evaluations -description: Learn how the Keptn Lifecycle Toolkit can orchestrate deployment checks. -weight: 55 +title: Standardize access to observability data +description: Learn how the Keptn Lifecycle Toolkit provides observability for Kubernetes deployments +weight: 45 --- -In this exercise, we will configure the Keptn Lifecyle Toolkit -to run deployment checks as part of your deployment. -Whether you are deploying your software with -Argo, Flux, another deployment engine, or even `kubectl apply`, -the Lifecycle Toolkit can do the following: - -* Pre-deploy: Validate external dependencies, - confirm that images are scanned, and so forth - -* Post-deply: Execute tests, notify stakeholders, - promote to the next stage - -* Automatically validate against your SLO (Service Level Objectives) - -KLT sits in the Kubernetes scheduler and can trace the deployment -from start to end. -KLT is also application aware, -so we can extend the deployment -with tasks and evaluations that -are run either before or after your whole application starts the deployment -or even at the individual workload level. -You can also validate any metric, -either pre- or post-deployment, -using the metrics from the Keptn Metrics Server introduced in -[Getting started with Keptn metrics](../metrics). -This means that you can be sure that the environment is healthy -and has adequate resources before you begin the deployment. -After the deployment succeeds, -use Keptn metrics to confirm that your deployed software is really healthy -- -not just that the pods are running but validate against SLOs -such as performance and user experience. -You can also check for new logs that came in from a log monitoring solution. +The Keptn Lifecycle Toolkit (KLT) makes any Kubernetes deployment observable. +You can readily see why a deployment takes so long or why it fails, +even when using multiple deployment tools. +Keptn introduces a concept of an application +which is an abstraction that connects multiple +Workloads belonging together. +In other words, KLT, creates a distributed end-to-end trace +of everything Kubernetes does in the context of a Deployment. + +The observability data is an amalgamation of the following: + +- DORA metrics are collected out of the box + when the Lifecycle Toolkit is enabled +- OpenTelemetry runs traces that show everything that happens in the Kubernetes cluster + and can display this information with dashboard tools + such as Grafana. +- Specific metrics that you can define to monitor + information from all the data providers configured in your cluster. + +The Keptn Lifecycle Toolkit can provide this information +for all applications running in your cluster, +even if they are using different deployment tools. +And it can capture metrics from multiple data sources +using multiple data platforms. +With KLT deployed on your cluster, +you can easily monitor what is happening during a deployment into your Kuberenetes cluster, +and quickly get data to help you understand issues such as +why a deployment took so long or why it failed. ## Using this exercise -This exercise is based on the +This exercise shows how to standardize access +to the observability data for your cluster. +It is based on the [simplenode-dev](https://github.com/keptn-sandbox/klt-on-k3s-with-argocd) example. You can clone that repo to access it locally or just look at it for examples as you implement the functionality "from scratch" on your local Kubernetes deployment cluster. +The +[README](https://github.com/keptn-sandbox/klt-on-k3s-with-argocd/blob/main/setup/observability/README.md) +file for that repo contains useful information. + +Two videos are available +to walk you through this exercise if you prefer: + +- [Introducing Keptn Lifecycle Toolkit](https://youtu.be/449HAFYkUlY) +- [Use SLOs and get DORA the Native K8s way!](https://www.youtube.com/watch?v=zeEC0475SOU) + +In the +[Getting started with Keptn metrics](../metrics) +exercise, you learn how to define and use Keptn metrics. +You may want to complete that exercise before doing this exercise +although that is not required. + +This exercise shows how to standardize access +to the observability data for your cluster. +The steps are: + +1. [Install and enable]( #install-and-enable-klt) + the Lifecycle Toolkit on your cluster +1. [Integrate the Lifecycle Toolkit with your applications](#integrate-the-lifecycle-toolkit-with-your-applications) +1. [DORA metrics](#dora-metrics) +1. [Using OpenTelemetry](#using-opentelemetry) +1. [Keptn metrics](#keptn-metrics) +1. [View the results](#view-the-results) + +## Install and enable KLT + +To install and enable the Keptn Lifecycle Toolkit on your cluster: + +1. Be sure that your cluster includes the components discussed in + [Prepare your cluster for KLT](../../install/k8s.md/#prepare-your-cluster-for-klt) +1. Follow the instructions in + [Install the Keptn Lifecycle Toolkit](../../install/install.md/#use-helm-chart) + to install KLT on your cluster using the Helm chart + + If you installed KLT on your cluster for the + [Getting started with Keptn metrics](../metrics) + exercise, you do not need to re-install it for this exercise. + However, if you only installed the `metrics-operator` for that exercise, + you now need to install the full KLT. + +1. Follow the instructions in + [Enable KLT for your cluster](../../install/install.md/#enable-klt-for-your-cluster) + to enable KLT on your cluster + by annotating the `Namespace` resource.. + See the + [simplenode-dev-ns.yaml](https://github.com/keptn-sandbox/klt-on-k3s-with-argocd/blob/main/simplenode-dev/simplenode-dev-ns.yaml) + file for an example + +1. Run the following command to ensure that your Kuberetes cluster + is ready to complete this exercise: + + ```shell + kubectl get pods -n keptn-lifecycle-toolkit-system + ``` + + You should see pods for the following components: + - certificate-operator (or another cert manager) + - lifecycle-operator + - scheduler + - metrics-operator + +## Integrate the Lifecycle Toolkit with your applications + +The Keptn Lifecycle Toolkit sits in the scheduler +so it can trace all activities of all deployment workloads on the cluster, +no matter what tool is used for the deployment. +This same mechanism allows KLT to inject pre- and post-deployment checks +into all deployment workloads; +we discuss this in another exercise. + +KLT uses metadata to identify the workloads of interest. +To integrate KLT with your applications, +you need to populate the metadata it needs. +This requires the following steps: + +- Define a Keptn application +- Annotate the `Deployment` resource to recognize your Keptn application + +### Define the Keptn application + +A Keptn application defines the workloads +to be included in your Keptn Application. +We will use the application discovery feature +to automatically generate a Keptn Application +that includes all workloads on the cluster, +regardless of the tools being used. + +A Keptn application aggregates multiple workloads +that belong to a logical app into a single +[KeptnApp](../../yaml-crd-ref/app.md) +resource. -The steps to implement pre- and post-deployment orchestration are: - -1. [Bring or create a Kubernetes cluster](../../install/k8s.md) -1. [Install the Keptn Lifecycle Toolkit and enable it](../../install/install.md) -1. [Integrate KLT with your cluster](../../implementing/integrate/) -1. [Define evaluations to be performed pre- and post-deployment](#define-evaluations-to-be-performed-pre--and-post-deployment) -1. [Define tasks to be performed pre- and post-deployment](#define-tasks-to-be-performed-pre--and-post-deployment) - -## Bring or create a Kubernetes deployment cluster - -You can run this exercise on an existing Kubernetes cluster -or you can create a new cluster. -For personal study and demonstrations, -this exercise runs well on a local Kubernetes cluster. -See [Bring or Install a Kubernetes Cluster](../../install/k8s.md). - -## Install KLT on your cluster - -Install the Keptn Lifecycle Toolkit on your cluster -by executing the following command sequence: +You can view a sample of this file in the +[keptn-app.yaml](https://github.com/keptn-sandbox/klt-on-k3s-with-argocd/blob/main/simplenode-dev/keptn-app.yaml.tmp) +file. +You see the metadata that names this `KeptnApp` +and identifies the namespace where it lives: -```shell -helm repo add klt https://charts.lifecycle.keptn.sh -helm repo update -helm upgrade --install keptn klt/klt \ - -n keptn-lifecycle-toolkit-system --create-namespace --wait +```yaml +metadata: + name: simpleapp + namespace: simplenode-dev ``` -See -[Install KLT](../../install/install.md) -for more information about installing the Lifecycle Toolkit. +You can also see the `spec.workloads` list. +In this simple example, +we only have one workload defined +but most production apps will have multiple workloads defined. -## Enable KLT for your cluster +You can create the YAML file to define the resource manually +but the easier approach is to let KLT create this definition for you. +This requires that you annotate all your workloads +(`Deployments`, `Pods`, `StatefulSets`, `DaemonSets`, and `ReplicaSets` +as described in +[Use Keptn automatic app discovery](../../implementing/integrate/#use-keptn-automatic-app-discovery). -To enable KLT for your cluster, annotate the -[Namespace](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/) -resource -In this example, this is defined in the -[simplenode-dev-ns.yaml](https://github.com/keptn-sandbox/klt-on-k3s-with-argocd/blob/main/simplenode-dev/simplenode-dev-ns.yaml) -file, which looks like this: +### Annotate your Deployment resource -```yaml -apiVersion: v1 -kind: Namespace -metadata: - name: simplenode-dev - annotations: - keptn.sh/lifecycle-toolkit: "enabled" -``` +Follow the instructions in +[Annotate workload](../../implementing/integrate/#basic-annotations) +to apply basic annotations to your `Deployment` resource. -You see the annotation line that enables `lifecycle-toolkit`. -This line tells the webhook to handle the namespace +The +[simplenode-dev-deployment.yaml](https://github.com/keptn-sandbox/klt-on-k3s-with-argocd/blob/main/simplenode-dev/simplenode-dev-deployment.yaml/) +file defines the `Deployment` resource for our example. +You see that the `metadata` specifies the same +`name` and `namespace` values defined in the `KeptnApp` resource. -## Integrate KLT with your cluster +The example file also includes annotations for +pre- and post-deployment activities. +We will discuss those in a separate exercise. -To integrate KLT with your cluster, annotate the Kubernetes -[Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) -resource. -In this example, this is defined in the -[simplenode-dev-deployment.yaml](https://github.com/keptn-sandbox/klt-on-k3s-with-argocd/blob/main/simplenode-dev/simplenode-dev-deployment.yaml) -file, which includes the following lines: +## DORA metrics -```yaml -apiVersion: apps/v1 -kind: Deployment -metadata: - name: simplenode - namespace: simplenode-dev -... -template: - metadata: - labels: - app: simplenode - app.kubernetes.io/name: simplenodeservice - annotations: - # keptn.sh/app: simpleapp - keptn.sh/workload: simplenode - keptn.sh/version: 1.0.2 - keptn.sh/pre-deployment-evaluations: evaluate-dependencies - keptn.sh/pre-deployment-tasks: notify - keptn.sh/post-deployment-evaluations: evaluate-deployment - keptn.sh/post-deployment-tasks: notify -... -``` +DORA metrics are an industry-standard set of measurements; +see the following for a description: -For more information about using annotations and labels -to integrate KLT into your deployment cluster, see -[Integrate KLT with your applications](../../implementing/integrate/_index.md). +- [What are DORA Metrics and Why Do They Matter?](https://codeclimate.com/blog/dora-metrics) +- [Are you an Elite DevOps Performer? + Find out with the Four Keys Project](https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance) -## Define evaluations to be performed pre- and post-deployment +DORA metrics provide information such as: -An `evaluation` is a KeptnMetric that has a defined target value. -Evaluations are resources that are defined in a -[KeptinEvaluationDefinition](../../yaml-crd-ref/evaluationdefinition.md) -yaml file. -In our example, evaluations are defined in the -[keptn-evaluations.yaml](https://github.com/keptn-sandbox/klt-on-k3s-with-argocd/blob/main/simplenode-dev/keptn-evaluations.yaml) -file. -For example, the definition of the `evaluate-dependencies` evaluation -looks like this: +- How many deployments happened in the last six hours? +- Time between deployments +- Deployment time between versions +- Average time between versions. -```yaml -apiVersion: lifecycle.keptn.sh/v1alpha3 -kind: KeptnEvaluationDefinition -metadata: - name: evaluate-dependencies - namespace: simplenode-dev -spec: - objectives: - - keptnMetricRef: - name: available-cpus - namespace: simplenode-dev - evaluationTarget: ">4" -``` +The Keptn Lifecycle Toolkit starts collecting these metrics +as soon as you annotate the `Deployment` resource. +Metrics are collected only for the `Deployment` resources +that are annotated. -You see that the `available-cpus` metric is defined in the -[keptn-metric.yaml](https://github.com/keptn-sandbox/klt-on-k3s-with-argocd/blob/main/simplenode-dev/keptn-metric.yaml) -file. -The `evaluationTarget` is set to be `>4`, -so this evaluation makes sure that more than 4 CPUs are available. -You could include objectives and additional metrics in this evaluation. +To view DORA metrics, run the following command: -## Define tasks to be performed pre- and post-deployment +```shell +kubectl port-forward -n keptn-lifecycle-toolkit-system \ + svc/lifecycle-operator-metrics-service 2222 +``` -Tasks are resources that are defined in a -[KeptnTaskDefinition](../../yaml-crd-ref/taskdefinition.md) -file. -In our example, the tasks are defined in the -[keptn-tasks.yaml](https://github.com/keptn-sandbox/klt-on-k3s-with-argocd/blob/main/simplenode-dev/keptn-tasks.yaml) -file -As an example, -we have a `notify` task that composes some markdown text -to be sent as Slack notifications -The `KeptnTaskDefinition` looks like this: +Then view the metrics at: -```yaml -apiVersion: lifecycle.keptn.sh/v1alpha3 -kind: KeptnTaskDefinition -metadata: - name: notify -spec: - function: - inline: - code: | - - secureParameters: - secret: slack-notification +```shell +http://localhost:2222/metrics ``` -For more information about sending Slack notifications with KLT, see -[Implement Slack notifications](../../implementing/slack.md). -The code to be executed is expressed as a -[Deno](https://deno.land/) -script, which uses JavaScript syntax. -It can be embedded in the definition file -or pulled in from a remote webserver that is specified. -For this example, the code to be executed is embedded in this file -although, in practice, -this script would probably be located on a remote webserver. - -You can view the actual JavaScript code for the task in the repository. -You see that "context" is important in this code. -This refers to the context in which this code executes -- -for which application, for which version, for which Workload. - -Because the slack server that is required to execute this task -is protected by a secret, the task definition also specifies that secret. +DORA metrics are also displayed on Grafana +or whatever dashboard application you choose. +For example: + +![DORA metrics](assets/dynatrace_dora_dashboard.png) + +## Using OpenTelemetry + +The Keptn Lifecycle Toolkit extends the Kubernetes +primitives to create OpenTelemetry data +that connects all your deployment and observability tools +without worrying about where it is stored and where it is managed. +OpenTelemetry traces collect data as Kubernetes is deploying the changes, +which allows you to trace everything done in the context of that deployment. + +- You must have an OpenTelemetry collector installed on your cluster. + See + [OpenTelemetry Collector](https://opentelemetry.io/docs/collector/) + for more information. +- Follow the instructions in + [OpenTelemetry observability](../../implementing/otel.md) + to configure where your OpenTelemetry data is sent. + - Define a [KeptnConfig](../../yaml-crd-ref/config.md) resource + that defines the URL and port of the OpenTelemetry collector. + For our example, this is in the + [keptnconfig.yaml](https://github.com/keptn-sandbox/klt-on-k3s-with-argocd/blob/main/setup/keptn/keptnconfig.yaml) + file. +- Set the `EXPOSE_KEPTN_METRICS` environment variable + in the `metrics-operator` + +TODO: How to set this env variable in `metrics-operator` + or where is it set in the example? + +## Keptn metrics + +You can supplement the DORA Metrics and OpenTelemetry information +with information you explicitly define using Keptn metrics. +The +[Getting started with Keptn metrics](../metrics) +exercise discusses how to define Keptn metrics. + +## View the results + +To start feeding observability data for your deployments +onto a dashboard of your choice, +modify either your `Deployment` or `KeptnApp` resource yaml file +to increment the version number +and commit that change to your repository. +Note that, from the `KeptnApp` YAML file, +you can either increment the version number of the application +(which causes all workloads to be rerun and produce observability data) +or you can increment the version number of a single workload, +(which causes just that workload to be rerun and produce data). + +The videos that go with this exercise show how the +DORA, OpenTelemetry, and Keptn metrics information +appears on a Grafana dashboard with +[Jaeger](https://grafana.com/docs/grafana-cloud/data-configuration/metrics/prometheus-config-examples/the-jaeger-authors-jaeger/). + +If you also have Jaeger extension for Grafana installed on your cluster, +you can view full end-to-end trace for everything +that happens in your deployment. +For more information, see +[Monitoring Jaeger](https://www.jaegertracing.io/docs/1.45/monitoring/). diff --git a/docs/content/en/docs/getting-started/orchestrate/_index.md b/docs/content/en/docs/getting-started/orchestrate/_index.md index b87b7241bd..4549f1f085 100644 --- a/docs/content/en/docs/getting-started/orchestrate/_index.md +++ b/docs/content/en/docs/getting-started/orchestrate/_index.md @@ -1,6 +1,216 @@ --- -title: Orchestrate deployment checks +title: Orchestrating pre- and post-deployment tasks and evaluations description: Learn how the Keptn Lifecycle Toolkit can orchestrate deployment checks. weight: 55 --- +In this exercise, we will configure the Keptn Lifecyle Toolkit +to run deployment checks as part of your deployment. +Whether you are deploying your software with +Argo, Flux, another deployment engine, or even `kubectl apply`, +the Lifecycle Toolkit can do the following: + +* Pre-deploy: Validate external dependencies, + confirm that images are scanned, and so forth + +* Post-deply: Execute tests, notify stakeholders, + promote to the next stage + +* Automatically validate against your SLO (Service Level Objectives) + +KLT sits in the Kubernetes scheduler and can trace the deployment +from start to end. +KLT is also application aware, +so we can extend the deployment +with tasks and evaluations that +are run either before or after your whole application starts the deployment +or even at the individual workload level. +You can also validate any metric, +either pre- or post-deployment, +using the metrics from the Keptn Metrics Server introduced in +[Getting started with Keptn metrics](../metrics). +This means that you can be sure that the environment is healthy +and has adequate resources before you begin the deployment. +After the deployment succeeds, +use Keptn metrics to confirm that your deployed software is really healthy -- +not just that the pods are running but validate against SLOs +such as performance and user experience. +You can also check for new logs that came in from a log monitoring solution. + +## Using this exercise + +This exercise is based on the +[simplenode-dev](https://github.com/keptn-sandbox/klt-on-k3s-with-argocd) +example. +You can clone that repo to access it locally +or just look at it for examples +as you implement the functionality "from scratch" +on your local Kubernetes deployment cluster. + +The steps to implement pre- and post-deployment orchestration are: + +1. [Bring or create a Kubernetes cluster](../../install/k8s.md) +1. [Install the Keptn Lifecycle Toolkit and enable it](../../install/install.md) +1. [Integrate KLT with your cluster](../../implementing/integrate/) +1. [Define evaluations to be performed pre- and post-deployment](#define-evaluations-to-be-performed-pre--and-post-deployment) +1. [Define tasks to be performed pre- and post-deployment](#define-tasks-to-be-performed-pre--and-post-deployment) + +## Bring or create a Kubernetes deployment cluster + +You can run this exercise on an existing Kubernetes cluster +or you can create a new cluster. +For personal study and demonstrations, +this exercise runs well on a local Kubernetes cluster. +See [Bring or Install a Kubernetes Cluster](../../install/k8s.md). + +## Install KLT on your cluster + +Install the Keptn Lifecycle Toolkit on your cluster +by executing the following command sequence: + +```shell +helm repo add klt https://charts.lifecycle.keptn.sh +helm repo update +helm upgrade --install keptn klt/klt \ + -n keptn-lifecycle-toolkit-system --create-namespace --wait +``` + +See +[Install KLT](../../install/install.md) +for more information about installing the Lifecycle Toolkit. + +## Enable KLT for your cluster + +To enable KLT for your cluster, annotate the +[Namespace](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/) +resource +In this example, this is defined in the +[simplenode-dev-ns.yaml](https://github.com/keptn-sandbox/klt-on-k3s-with-argocd/blob/main/simplenode-dev/simplenode-dev-ns.yaml) +file, which looks like this: + +```yaml +apiVersion: v1 +kind: Namespace +metadata: + name: simplenode-dev + annotations: + keptn.sh/lifecycle-toolkit: "enabled" +``` + +You see the annotation line that enables `lifecycle-toolkit`. +This line tells the webhook to handle the namespace + +## Integrate KLT with your cluster + +To integrate KLT with your cluster, annotate the Kubernetes +[Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) +resource. +In this example, this is defined in the +[simplenode-dev-deployment.yaml](https://github.com/keptn-sandbox/klt-on-k3s-with-argocd/blob/main/simplenode-dev/simplenode-dev-deployment.yaml) +file, which includes the following lines: + +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: simplenode + namespace: simplenode-dev +... +template: + metadata: + labels: + app: simplenode + app.kubernetes.io/name: simplenodeservice + annotations: + # keptn.sh/app: simpleapp + keptn.sh/workload: simplenode + keptn.sh/version: 1.0.2 + keptn.sh/pre-deployment-evaluations: evaluate-dependencies + keptn.sh/pre-deployment-tasks: notify + keptn.sh/post-deployment-evaluations: evaluate-deployment + keptn.sh/post-deployment-tasks: notify +... +``` + +For more information about using annotations and labels +to integrate KLT into your deployment cluster, see +[Integrate KLT with your applications](../../implementing/integrate/_index.md). + +## Define evaluations to be performed pre- and post-deployment + +An `evaluation` is a KeptnMetric that has a defined target value. +Evaluations are resources that are defined in a +[KeptinEvaluationDefinition](../../yaml-crd-ref/evaluationdefinition.md) +yaml file. +In our example, evaluations are defined in the +[keptn-evaluations.yaml](https://github.com/keptn-sandbox/klt-on-k3s-with-argocd/blob/main/simplenode-dev/keptn-evaluations.yaml) +file. +For example, the definition of the `evaluate-dependencies` evaluation +looks like this: + +```yaml +apiVersion: lifecycle.keptn.sh/v1alpha3 +kind: KeptnEvaluationDefinition +metadata: + name: evaluate-dependencies + namespace: simplenode-dev +spec: + objectives: + - keptnMetricRef: + name: available-cpus + namespace: simplenode-dev + evaluationTarget: ">4" +``` + +You see that the `available-cpus` metric is defined in the +[keptn-metric.yaml](https://github.com/keptn-sandbox/klt-on-k3s-with-argocd/blob/main/simplenode-dev/keptn-metric.yaml) +file. +The `evaluationTarget` is set to be `>4`, +so this evaluation makes sure that more than 4 CPUs are available. +You could include objectives and additional metrics in this evaluation. + +## Define tasks to be performed pre- and post-deployment + +Tasks are resources that are defined in a +[KeptnTaskDefinition](../../yaml-crd-ref/taskdefinition.md) +file. +In our example, the tasks are defined in the +[keptn-tasks.yaml](https://github.com/keptn-sandbox/klt-on-k3s-with-argocd/blob/main/simplenode-dev/keptn-tasks.yaml) +file +As an example, +we have a `notify` task that composes some markdown text +to be sent as Slack notifications +The `KeptnTaskDefinition` looks like this: + +```yaml +apiVersion: lifecycle.keptn.sh/v1alpha3 +kind: KeptnTaskDefinition +metadata: + name: notify +spec: + function: + inline: + code: | + + secureParameters: + secret: slack-notification +``` + +For more information about sending Slack notifications with KLT, see +[Implement Slack notifications](../../implementing/slack.md). +The code to be executed is expressed as a +[Deno](https://deno.land/) +script, which uses JavaScript syntax. +It can be embedded in the definition file +or pulled in from a remote webserver that is specified. +For this example, the code to be executed is embedded in this file +although, in practice, +this script would probably be located on a remote webserver. + +You can view the actual JavaScript code for the task in the repository. +You see that "context" is important in this code. +This refers to the context in which this code executes -- +for which application, for which version, for which Workload. + +Because the slack server that is required to execute this task +is protected by a secret, the task definition also specifies that secret.