diff --git a/chapter-9/README-es.md b/chapter-9/README-es.md new file mode 100644 index 0000000..0237dcc --- /dev/null +++ b/chapter-9/README-es.md @@ -0,0 +1,32 @@ +# Chapter 9 :: Midiendo tus plataformas + +--- +_🌍 Disponible en_: [English](README.md) | [中文 (Chinese)](README-zh.md) | [日本語 (Japanese)](README-ja.md)| [Español](README-es.md) + +> **Nota:** Presentado por la fantástica comunidad +> de [ 🌟 contribuidores](https://github.com/salaboy/platforms-on-k8s/graphs/contributors) cloud-native! + +--- + +Este capítulo cubre dos tutoriales diferentes, sobre cómo usar las métricas de DORA para medir el rendimiento de tu iniciativa de plataforma. + +- [Métricas de DORA y CloudEvents](dora-cloudevents/README-es.md) +- [Keptn Lifecycle Toolkit](keptn/README-es.md) + +## Resumen + +Los tutoriales cubiertos en este capítulo tienen el propósito de mostrar dos formas completamente distintas, +pero complementarias para observar y monitorizar nuestras aplicaciones. +Mientras que el primer tutorial se enfoca en CloudEvents y CDEvents para mostrar cómo los equipos de plataformas pueden mirar los distintos orígenes para calcular las métricas de DORA, el segundo tutorial se enfoca en el toolkit de Ketpn, que provee la métrica de Frecuencia de Despliegue por defecto al extender el programador de Kubernetes y recolectando información acerca de nuestras aplicaciones. + +Los equipos de plataformas deberían evaluar herramientas como las presentadas aquí, no solo para calcular métricas, sino también para justificar sus inversiones en la plataforma. +Si las decisiones e iniciativas de plataforma mejoran la frecuencia de despliegue, el tiempo de respuesta a los cambios y al mismo tiempo reducen el tiempo de recuperación de fallos, estás construyendo la plataforma correcta. +Si notas que los equipos no están desplegando tan frecuentemente como esperabas, los cambios tardan más en llegar a los clientes, es posible que tengas que reevaluar tus decisiones. + +## Limpieza + +Si quieres deshacerte del Clúster de KinD creado para este tutorial, puedes ejecutar: + +```shell +kind delete clusters dev +``` diff --git a/chapter-9/README.md b/chapter-9/README.md index 1f26bba..95ed86b 100644 --- a/chapter-9/README.md +++ b/chapter-9/README.md @@ -1,7 +1,7 @@ # Chapter 9 :: Measuring your Platforms --- -_🌍 Available in_: [English](README.md) | [中文 (Chinese)](README-zh.md) | [日本語 (Japanese)](README-ja.md) +_🌍 Available in_: [English](README.md) | [中文 (Chinese)](README-zh.md) | [日本語 (Japanese)](README-ja.md) | [Spanish](README-es.md) > **Note:** Brought to you by the fantastic cloud-native community's [ 🌟 contributors](https://github.com/salaboy/platforms-on-k8s/graphs/contributors)! diff --git a/chapter-9/dora-cloudevents/README-es.md b/chapter-9/dora-cloudevents/README-es.md new file mode 100644 index 0000000..60c09d4 --- /dev/null +++ b/chapter-9/dora-cloudevents/README-es.md @@ -0,0 +1,209 @@ +# Métricas de DORA + CloudEvents & CDEvents para Kubernetes + +--- +_🌍 Disponible en_: [English](README.md) | [中文 (Chinese)](README-zh.md) | [日本語 (Japanese)](README-ja.md) | [Spanish](README-es.md) + +> **Nota:** Presentado por la fantástica comunidad +> de [ 🌟 contribuidores](https://github.com/salaboy/platforms-on-k8s/graphs/contributors) cloud-native! + +--- + +Este tutorial instala un conjunto de componentes que consumen [CloudEvents](https://cloudevents.io) desde múltiples orígenes y permite observar las métricas de DORA, usando una arquitectura nativa de Kubernetes (sin dependencias externas). + +Esta demostración se centra en observar los distintos orígenes de eventos, para luego mapear estos resultados a eventos relevantes para nuestras prácticas de entrega de software, que pueden ser agregados para calcular las métricas de DORA. + +El flujo de transformación de eventos va así: +- La entrada son [CloudEvents](https://cloudevents.io) provenientes de orígenes distintos. +- Estos CloudEvents se pueden mapear y transformar en [CDEvents](https://cdevents.dev) para procesarlos adicionalmente. +- Se pueden definir Funciones de agregación para calcular las métricas de DORA (u otras). +- Las métricas pueden ser expuestas para consumo (en este ejemplo, via REST endpoints). + +## Instalación + +Utilizaremos un clúster de Kubernetes con Knative Serving para ejecutar nuestras funciones de transformación. Puedes seguir las instrucciones del [Capítulo 8 para crear un clúster con Knative Serving instalado](../../chapter-8/README-es.md#creando-un-kubernetes-con-knative-serving). + +Luego instalaremos Knative Eventing, que es opcional, porque utilizaremos Knative Eventing para instalar la API de Event Source de Kubernetes, que toma eventos internos de Kubernetes y los transforma en CloudEvents. + +1. Instala [Knative Eventing](https://knative.dev/docs/install/yaml-install/eventing/install-eventing-with-yaml/) +```shell +kubectl apply -f https://github.com/knative/eventing/releases/download/knative-v1.11.0/eventing-crds.yaml +kubectl apply -f https://github.com/knative/eventing/releases/download/knative-v1.11.0/eventing-core.yaml +``` + +1. Crea tu namespace `dora-cloudevents`: +```shell +kubectl create ns dora-cloudevents +``` + +1. Instala PostgreSQL y crea las tablas: +```shell +kubectl apply -f resources/dora-sql-init.yaml +helm install postgresql oci://registry-1.docker.io/bitnamicharts/postgresql --version 12.5.7 --namespace dora-cloudevents --set "image.debug=true" --set "primary.initdb.user=postgres" --set "primary.initdb.password=postgres" --set "primary.initdb.scriptsConfigMap=dora-init-sql" --set "global.postgresql.auth.postgresPassword=postgres" --set "primary.persistence.size=1Gi" +``` + +1. Instala Sockeye, un monitor sencillo de CloudEvents, requiere instalar Knative Serving: + +```shell +kubectl apply -f https://github.com/n3wscott/sockeye/releases/download/v0.7.0/release.yaml +``` + +1. Instala [Kubernetes API Server CloudEvent Event Source](https://knative.dev/docs/eventing/sources/apiserversource/getting-started/#create-an-apiserversource-object): +```shell +kubectl apply -f api-serversource-deployments.yaml +``` + + +## Componentes + +Esta demostración despliega los siguientes componentes para transformar CloudEvents en CdEvents y luego agregar los datos disponibles. + +- **Endpoint de CloudEvents**: el endpoint para enviar todos los CloudEvents; estos CloudEvents se almacenarán en la base de datos en la tabla `cloudevents-raw`. + +- **Enrutador CloudEvents**: enrutador, con una tabla de enrutamiento, que redirige los eventos para transformarlos en `CDEvents`. Este mecanismo permite que el mismo tipo de evento se transforme en múltiples `CDEvents`, si es necesario. Este componente lee de la tabla `cloudevents-raw`y procesa los eventos. Este componente es lanzado por medio de un periodo de tiempo fijo configurable. + +- **Transformador de CDEvents**: estas funciones reciben eventos del `Enrutador de CloudEvents` y transforma los CloudEvents en CDEvents. el resultado se envía al `Endpoint de CDEvents`. + +- **Endpoint de CDEvents**: endpoint para enviar `CDEvents`, estos CloudEvents se almacenarán en la base de datos SQL en la tabla `cdevents-raw`, porque no necesitan ninguna transformación. Este endpoint valida que el CloudEvent recibido sean un CD CloudEvent. + +- **Funciones de Métricas**: estas funciones están a cargo de calcular diferentes métricas y guardarlas en tablas especiales, probablemente una por tabla. Para calcular dichas métricas, estas funciones leen de `cdevents-raw`. Un ejemplo de cómo calcular la **frecuencia de despliegue** se explica abajo. + +- **Endpoint de Métricas**: endpoint que te permite consultar métricas por nombre y agregar algunos filtros. Este componente es opcional, porque puedes construir un dashboard desde las tablas de las métricas sin usar estos endpoints. + + +![dora-cloudevents-architecture](../imgs/dora-cloudevents-architecture.png) + + +## Desplegando Componentes y generando datos + +Primero despliega los componentes y funciones de transformación ejecutando: + +```shell +kubectl apply -f resources/components.yaml +``` + +Abre Sockeye para monitorizar CloudEvents al abrir tu navegador en [http://sockeye.default.127.0.0.1.sslip.io/](http://sockeye.default.127.0.0.1.sslip.io/). + +Luego, crea un nuevo despliegue en el namespace `default` para probar que tu configuración funciona. + + +```shell +kubectl apply -f test/example-deployment.yaml +``` + +En este punto deberías ver cientos de eventos en Sockeye: + +![sockeye](../imgs/sockeye.png) + +Si las funciones de frecuencia de despliegue (transformación y cálculo) están instaladas, deberías poder consultar el endpoint de frecuencia de despliegue y ver la métrica. +Ten en cuenta que esto puede tomar un par de minutos, porque se utilizan Cron Jobs para agregar los datos periódicamente: + +```shell +curl http://dora-frequency-endpoint.dora-cloudevents.127.0.0.1.sslip.io/deploy-frequency/day | jq +``` +Y observa algo como esto, +dependiendo de cuáles despliegues has creado (he creado dos despliegues: `nginx-deployment` and `nginx-deployment-3`): + +```shell +[ + { + "DeployName": "nginx-deployment", + "Deployments": 1, + "Time": "2023-08-05T00:00:00Z" + }, + { + "DeployName": "nginx-deployment-3", + "Deployments": 1, + "Time": "2023-08-05T00:00:00Z" + } +] + +``` + +Intenta modificar los despliegues o crear nuevos, los componentes están configurados para monitorizar todos los despliegues en el namespace `default`. + +Observa que todos los componentes fueron instalados en el namespace `dora-cloudevents`. +Puedes revisar los pods y la url para los servicios de Knative ejecutando los siguientes comandos: + +Revisa la url para los servicios Knative en el namespace `dora-cloudevents`: +```shell +kubectl get ksvc -n dora-cloudevents +``` + +Revisa cuáles pods se están ejecutando, +esto lo encuentro interesante porque usando Knative Serving, todas las funciones de transformación que no se están usando no necesitan estar en ejecución todo el tiempo: + +```shell +kubectl get pods -n dora-cloudevents +``` + +Finalmente, puedes revisar las ejecuciones CronJob que agrega datos ejecutando: + +```shell +kubectl get cronjobs -n dora-cloudevents +``` + +## Desarrollo + +Despliega los componentes `dora-cloudevents` usando `ko`para desarrollar: + +```shell +ko apply -f config/ +``` + +# Métricas + +De [https://github.com/GoogleCloudPlatform/fourkeys/blob/main/METRICS.md](https://github.com/GoogleCloudPlatform/fourkeys/blob/main/METRICS.md) + +## Frecuencia de Despliegue + +![deployment frequency](../imgs/deployment-frequency-metric.png) + +Miramos nuestros recursos nuevos o actualizados. Esto se hace usando el `APIServerSource` que configuramos anteriormente. + + +El flujo debería ser +```mermaid +graph TD + A[API Server Source] --> |writes to `cloudevents_raw` table| B[CloudEvent Endpoint] + B --> |read from `cloudevents_raw` table| C[CloudEvents Router] + C --> D(CDEvent Transformation Function) + D --> |writes to `cdevents_raw` table| E[CDEvents Endpoint] + E --> F(Deployment Frequency Function) + F --> |writes to `deployments` table| G[Deployments Table] + G --> |read from `deployments` table| H[Metrics Endpoint] +``` + +Calcular cubos: diariamente, semanalmente, mensualmente, anualmente. + +Esto cuenta el número de despliegues por día: + +```sql +SELECT +distinct deploy_name AS NAME, +DATE_TRUNC('day', time_created) AS day, +COUNT(distinct deploy_id) AS deployments +FROM +deployments +GROUP BY deploy_name, day; +``` + + +## TODOs y Extensiones + +- Añadir mecanismos de eventos procesados para las tablas `cloudevents_raw` y `cdevents_raw`. Esto debería evitar que el `Enroutador de CloudEvents` y las `funciones de cálculo de Métricas` recalculen los eventos ya procesados. Esto se puede lograr añadiendo una tabla que almacene el último evento procesado y asegurándose que el `Enroutador de CloudEvents` y las `funciones de cálculo de Métricas` coinciden con las nuevas tablas. +- añadir consultas para calcular cubos para la Frecuencia de Despliegue: semanalmente, mensualmente, anualmente a `deployment-frequency-endpoint.go`. Revisa el artículo del blog para calcular la frecuencia y no el volúmen: https://codefresh.io/learn/software-deployment/dora-metrics-4-key-metrics-for-improving-devops-performance/ +- Crea un chart de Helm para componentes genéricos (Endpoint de CloudEvents, Endpoint de CDEvents, Enrutador de CloudEvents) +- Automatiza la creación de tablas para el chart de Helm para PostgreSQL (https://stackoverflow.com/questions/66333474/postgresql-helm-chart-with-initdbscripts) +- Crear funciones para **Plazo de ejecución de cambios** + +## Otras fuentes y Extensiones + +- [Instala Tekton](https://github.com/cdfoundation/sig-events/tree/main/poc/tekton) + - Dashboard de Tekton: `k port-forward svc/tekton-dashboard 9097:9097 -n tekton-pipelines` + - Controlador de Cloud Events: `kubectl apply -f https://storage.cloud.google.com/tekton-releases-nightly/cloudevents/latest/release.yaml` + - ConfigMap: `config-defaults` para +- https://github.com/GoogleCloudPlatform/fourkeys +- https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance +- Eventos de Entrega Continua, también conocido como [CDEvents](https://cdevents.dev) +- CloudEvents [CEs](https://cloudevents.io/) +- Fuente en GitHub: https://github.com/knative/docs/tree/main/code-samples/eventing/github-source diff --git a/chapter-9/keptn/README-es.md b/chapter-9/keptn/README-es.md new file mode 100644 index 0000000..e80c92f --- /dev/null +++ b/chapter-9/keptn/README-es.md @@ -0,0 +1,174 @@ +# Keptn Lifecycle Toolkit, out of the box Deployment Frequency + +--- +_🌍 Disponible en_: [English](README.md) | [中文 (Chinese)](README-zh.md) | [日本語 (Japanese)](README-ja.md)| [Español](README-es.md) + +> **Nota:** Presentado por la fantástica comunidad +> de [ 🌟 contribuidores](https://github.com/salaboy/platforms-on-k8s/graphs/contributors) cloud-native! + +--- + +En este breve tutorial exploraremos Ketpn Lifecycle Toolkit para monitorizar, observar y reaccionar a eventos del ciclo de vida de nuestras aplicaciones nativas en la nube. + +## Instalación + +Necesitas un Clúster de Kubernetes para instalar [Keptn KLT](https://keptn.sh). +Puedes crear uno usando Kubernetes KinD como lo hicimos en el [Capítulo 2](https://github.com/salaboy/platforms-on-k8s/blob/main/chapter-2/README-es.md#creando-un-clúster-local-con-kubernetes-kind) + +Luego podemos instalar el toolkit de Keptn lifecycle (KLT, en inglés). +Esto se puede hacer usualmente con el chart de Helm de, pero para este ejemplo también queremos instalar Prometheus, Jaeger y Grafana para tener dashboards. +Por esta razón, basado en el repositorio de KLT, utilizaremos un Makefile para instalar todas las herramientas que necesitamos para este ejemplo. + +Ejecuta: + +```shell +make install +``` + +**Nota*: EL proceso de instalación tomará unos minutos para instalar todas las herramientas necesarias. + +Finalmente, necesitamos hacerle saber a KLT cuál _namespace_ queremos monitorizar, y para ese necesitamos anotar los namespaces: + +```shell +kubectl annotate ns default keptn.sh/lifecycle-toolkit="enabled" +``` + +## Keptn Lifecycle toolkit en acción + +Keptn utiliza anotaciones estándar de Kubernetes para reconocer y monitorizar nuestras cargas de trabajo. +Los Despliegues de Kubernetes usados por la Aplicación de Conferencias están anotados con las siguientes anotaciones, por ejemplo el Servicio Agenda: + + +```shell + app.kubernetes.io/name: agenda-service + app.kubernetes.io/part-of: agenda-service + app.kubernetes.io/version: {{ .Values.services.tag }} +``` + +Estas anotaciones permiten a las herramientas entender un poco más nuestras cargas de trabajo, por ejemplo, en el caso que las herramientas sepanr que el nombre del servicio es `agenda-service`. +Podemos usar la anotación `app.kubernetes.io/part-of` para agregar múltiples servicios para que sean parte de la misma aplicación. Para este ejemplo, queremos que cada servicio sea una entidad separada para monitorizarla individualmente. + +En este ejemplo usaremos también una `KeptnTask`, que nos permite realizar tareas de pre- y post-despliegue. +Puedes desplegar el siguiente ejemplo extremadamente sencillo usando `KeptnTaskDefinition`: + +```yaml +apiVersion: lifecycle.keptn.sh/v1alpha3 +kind: KeptnTaskDefinition +metadata: + name: stdout-notification +spec: + function: + inline: + code: | + let context = Deno.env.get("CONTEXT"); + console.log("Tarea Keptn ejecutada con el contexto: \n"); + console.log(context); + +``` + +Como puedes ver, esta tarea solo imprimie el contexto de su ejecuación, pero aquí es donde puedes construir integraciones con otros proyectos o llamar sistemas externos. +Si mirar los ejemplos de Keptn, encontrarás `KeptnTaskDefinition` para conectar con Slack, por ejemplo, o ejecutar pruebas de carga, o validar que los despligues funcionan de forma esperada luego de ser actualizados. +Estas tareas usan [Deno](https://deno.land/), un _runtime_ de JavaScript seguro y con soporte para Typescript por defecto, Python 3 o directamente una imagen de un contenedor. + +Al ejecutar: + +```shell +kubectl apply -f keptntask.yaml +``` + +KeptnTaskDefinition les permite a los equipos de plataformas crear tareas reutilizables que se pueden ejecutar en los hooks de pre/post-despliegue de nuestra aplicación. Al añadir la siguiente anotación a nuestras cargas de trabajo (despliegues en este caso), Keptn ejecutará automáticamente la tarea `stdout-notification`, en este caso luego de realizar el despliegue (y luego de cualquier actualización). + +```shell + keptn.sh/post-deployment-tasks: stdout-notification +``` + +Vamos a desplegar la aplicación de Conferencias, y vamos a abrir los dashboards de Jaeger y Grafana. +Ejecuta en pestañas separadas: + + +```shell +make port-forward-jaeger +``` + +Puedes abrir tu navegador en la URL `http://localhost:16686/`, y deberías ver: + +![jaeger](../imgs/jaeger.png) + +y luego en un terminal separado: + +```shell +make port-forward-grafana +``` + +Puedes abrir tu navegador en la URL [http://localhost:3000/](http://localhost:3000). +Utiliza las credenciales `admin/admin` y deberías ver: + +![grafana](../imgs/grafana.png) + +Vamos a desplegar ahora la aplicación de Conferencias como lo hicimos en el capítulo 2: + +```shell +helm install conference oci://registry-1.docker.io/salaboy/conference-app --version v1.0.0 +``` + +Revisa los dashboards de Jaeger y Grafana, y por defecto Keptn Workloads rastreará la frecuencia de despliegue. + +En Grafana, ve a `Dashboards` -> `Keptn Applications`. +Verás un cuadro desplegable que permite seleccionar los servicios de las diferentes aplicaciones. +Revisa el servicio de Notificaciones. +Debido a que solo hemos desplegado la primera versión del despliegue, no hay mucho que ver, pero el dashboard se volverá más interesante cuando lancemos nuevas versiones de nuestros servicios. + +Por ejemplo, edita el despliegue del servicio de notificaciones y actualiza la anotación `app.kubernetes.io/version` con el valor `v1.1.0` y actualiza la etiqueta utilizada por la imagen del contendedor a `v1.1.0`. + +```shell +kubectl edit deploy conference-notifications-service-deployment +``` + +Luego de realizar los cambios, +y la nueva versión está ejecutándose, revisa nuevamente los dashboards. +En Grafana, verás que estamos en el segundo despliegue exitoso, +que el promedio entre despliegues fue de 5,83 minutos en mi ambiente, +y que `v1.0.0` tomó 641 s mientras que `v1.1.0` tomó solo 40 s. Definitivamente, hay mucho que podemos mejorar ahí. + + +![grafana](../imgs/grafana-notificatons-service-v1.1.0.png) + +Si miras las trazas en Jaeger, +verás que `lifecycle-operator`, uno de los components núcleo en Keptn está monitorizando nuestros recursos de despliegue y realizando operaciones del ciclo de vida, como por ejemplo llamar a tareas de pre y post-despliegue. + +![jager](../imgs/jaeger-notifications-service-v1.1.0.png) + +Estas tareas se ejecutan como Jobs de Kubernetes en el mismo namespace donde se ejecutan las cargas de trabajo. +Puedes mirar los logs de estas tareas siguiendo los registros de los jobs del pod. + +```shell +kubectl get jobs +NAME COMPLETIONS DURATION AGE +post-stdout-notification-25899-78387 1/1 3s 66m +post-stdout-notification-28367-11337 1/1 4s 61m +post-stdout-notification-54572-93558 1/1 4s 66m +post-stdout-notification-75100-85603 1/1 3s 66m +post-stdout-notification-77674-78421 1/1 3s 66m +post-stdout-notification-93609-30317 1/1 3s 23m +``` + +El Job con el id `post-stdout-notification-93609-30317` fue ejecutado luego que realicé la actualización en el despliegue del Servicio de Notificaciones. + +```shell +> kubectl logs -f post-stdout-notification-93609-30317-vvwp4 +Keptn Task Executed with context: + +{"workloadName":"notifications-service-notifications-service","appName":"notifications-service","appVersion":"","workloadVersion":"v1.1.0","taskType":"post","objectType":"Workload"} + +``` + +## Próximos pasos + +Te recomiendo encarecidamente que te familiarices con las características y funcionalidades de Keptn Lifecycle toolkit, ya que solo hemos visto lo básico en este breve tutorial. +Revisa los conceptos de [KeptnApplication](https://lifecycle.keptn.sh/docs/concepts/apps/) para tener más control sobre cómo se despliegan tus servicios, porque Keptn te permite reglas específicas sobre cuáles servicios y qué versiones es permitido desplegar. + +Al agrupar múltiples servicios como parte de la misma aplicación de Kubernetes, usando la anotación `app.kubernetes.io/part-of`, puedes realizar acciones pre. +y post en un grupo de servicios, permitiéndote validar que no solo los servicios individuales funcionan como se espera, sino que todo el conjunto lo hace. + + + diff --git a/chapter-9/keptn/README.md b/chapter-9/keptn/README.md index f7bb09b..4f12363 100644 --- a/chapter-9/keptn/README.md +++ b/chapter-9/keptn/README.md @@ -1,14 +1,14 @@ # Keptn Lifecycle Toolkit, out of the box Deployment Frequency --- -_🌍 Available in_: [English](README.md) | [中文 (Chinese)](README-zh.md) | [日本語 (Japanese)](README-ja.md) +_🌍 Available in_: [English](README.md) | [中文 (Chinese)](README-zh.md) | [日本語 (Japanese)](README-ja.md)| [Español](README-es.md) > **Note:** Brought to you by the fantastic cloud-native community's [ 🌟 contributors](https://github.com/salaboy/platforms-on-k8s/graphs/contributors)! --- -On this short tutorial we explore the Keptn Lifecycle Toolkit to monitor, observe and react to our cloud native applications lifecycle events. +In this short tutorial, we explore the Keptn Lifecycle Toolkit to monitor, observe and react to our cloud native applications lifecycle events. ## Installation @@ -33,8 +33,8 @@ kubectl annotate ns default keptn.sh/lifecycle-toolkit="enabled" ## Keptn Lifecycle toolkit in action -Keptn uses standard Kubernetes annotation to recognized and monitor our workloads. -The Kubernetes Deployments used by the Conference Application are annotated with the following annotations, for example the Agenda Service: +Keptn uses standard Kubernetes annotation to recognize and monitor our workloads. +The Kubernetes Deployments used by the Conference Application are annotated with the following annotations, for example, the Agenda Service: ```shell app.kubernetes.io/name: agenda-service @@ -44,7 +44,7 @@ The Kubernetes Deployments used by the Conference Application are annotated with These annotations allow tools to understand a bit more about our workloads, for example, in this case tools know that the service name is `agenda-service`. We can use the `app.kubernetes.io/part-of` to aggregate multiple services to be part of the same applicaiton. For this example, we wanted to keep each service as a separate entity so we can monitor each individually. -On this example we will be also using a KeptnTask, that enable us to perform pre and post deployment tasks. You can deploy the following extremely simple example `KeptnTaskDefinition`: +In this example, we will be also using a KeptnTask that enables us to perform pre- and post-deployment tasks. You can deploy the following extremely simple example `KeptnTaskDefinition`: ```yaml apiVersion: lifecycle.keptn.sh/v1alpha3 @@ -61,7 +61,7 @@ spec: ``` -As you can see this task is only printing the context from its execution, but here is where you can build any integration with other projects or call external systems. If you look at the Keptn examples, you will find KeptnTaskDefinition to connect for example to Slack, run load tests or to validate that deployments are working as expected after being updated. These tasks uses [Deno](https://deno.land/), a secure JavaScript runtime with Typescript supported out-of-the-box, Python 3 or directly a container image. +As you can see this task is only printing the context from its execution, but here is where you can build any integration with other projects or call external systems. If you look at the Keptn examples, you will find KeptnTaskDefinition to connect, for example, to Slack, run load tests or to validate that deployments are working as expected after being updated. These tasks use [Deno](https://deno.land/), a secure JavaScript runtime with Typescript supported out-of-the-box, Python 3 or directly a container image. By running: @@ -69,7 +69,7 @@ By running: kubectl apply -f keptntask.yaml ``` -KeptnTaskDefinitions allow Platform Teams to create reusable tasks that can be hooked into Pre/Post deployment hooks of our applications. By adding the following annotation to our workloads (deployments in this case), Keptn will execute the `stdout-notification` automatically, in this case after performing the deployment (and after any update): +KeptnTaskDefinitions allow Platform Teams to create reusable tasks that can be hooked into Pre-/ Post-deployment hooks of our applications. By adding the following annotation to our workloads (deployments in this case), Keptn will execute the `stdout-notification` automatically, in this case after performing the deployment (and after any update): ```shell keptn.sh/post-deployment-tasks: stdout-notification @@ -103,9 +103,9 @@ Let's now deploy the Conference Application as we did in Chapter 2: helm install conference oci://registry-1.docker.io/salaboy/conference-app --version v1.0.0 ``` -Check the both Jaeger and Grafana Keptn Dashboards, as by default Keptn Workloads will track the deployment frequency. +Check both Jaeger and Grafana Keptn Dashboards, as by default, Keptn Workloads will track the deployment frequency. -In Grafana go to `Dashboards` -> `Keptn Applications`. You will see a drop down that allows you to select the different applications services. Check the Notifications Service. Because we have only deployed the first version of the deployment, there is not much to see, but the dashboard will become more interesting after we release new versions of our services. +In Grafana go to `Dashboards` -> `Keptn Applications`. You will see a drop-down that allows you to select the different applications services. Check the Notifications Service. Because we’ve only deployed the first version of the deployment, there is not much to see, but the dashboard will become more interesting after we release new versions of our services. For example, edit the notifications-service deployment and update the `app.kubernetes.io/version` annotation to have the value `v1.1.0` and update the tag used for the container image to be `v1.1.0` @@ -113,16 +113,16 @@ For example, edit the notifications-service deployment and update the `app.kuber kubectl edit deploy conference-notifications-service-deployment ``` -After you performed the changes, and the new version is up and running, check the dashboards again. -In Grafana you will see we are on the second successful deployment, that the average between deployments was 5.83 minutes in my environment, and that `v1.0.0` took 641s while `v1.1.0` took only 40s. There is definitely room for improvement there. +After you perform the changes, and the new version is up and running, check the dashboards again. +In Grafana, you will see we’re on the second successful deployment, that the average between deployments was 5.83 minutes in my environment, and that `v1.0.0` took 641s while `v1.1.0` took only 40s. There is definitely room for improvement there. ![grafana](../imgs/grafana-notificatons-service-v1.1.0.png) -If you look at the traces in Jaeger, you will see that the `lifecycle-operator` one of the core components in Keptn is monitoring our deployment resources and performing lifecycle operations, like for example calling pre and post deployments tasks. +If you look at the traces in Jaeger, you will see that the `lifecycle-operator` one of the core components in Keptn is monitoring our deployment resources and performing lifecycle operations, like, for example, calling pre- and post-deployments tasks. ![jager](../imgs/jaeger-notifications-service-v1.1.0.png) -These tasks are executed as Kubernetes Jobs in the same namespace where the workloads are running. You can take a look at the logs from this tasks by tailing the jobs pod's logs. +These tasks are executed as Kubernetes Jobs in the same namespace where the workloads are running. You can take a look at the logs from these tasks by tailing the job pod's logs. ```shell kubectl get jobs @@ -147,7 +147,7 @@ Keptn Task Executed with context: ## Next steps -I strongly recommend you to get more familiar with Keptn Lifecycle Toolkit features and functionalities as what we have seen in this short tutorial are just the basics. Check the concept of [KeptnApplication](https://lifecycle.keptn.sh/docs/concepts/apps/) for more control on how your services are deployed, as Keptn allows you to define fine-grained rules about which services and which versions are allowed to be deployed. +I strongly recommend you to get more familiar with Keptn Lifecycle Toolkit features and functionalities as what we’ve seen in this short tutorial are just the basics. Check the concept of [KeptnApplication](https://lifecycle.keptn.sh/docs/concepts/apps/) for more control on how your services are deployed, as Keptn allows you to define fine-grained rules about which services and which versions are allowed to be deployed. -By grouping multiple services as part of the same Kubernetes Application using the `app.kubernetes.io/part-of` annotation, you can perform pre and post actions on a group of services, allowing you to validate that not only individual services are working as expected but the whole set is. +By grouping multiple services as part of the same Kubernetes Application using the `app.kubernetes.io/part-of` annotation, you can perform pre- and post-actions on a group of services, allowing you to validate that not only individual services are working as expected but the whole set is.