Service Mesh Istio

Imagina que tienes una aplicación la cual está construida por muchos microservicios, ¿Cómo la vas a monitorear/supervisar/optimizar el rendimiento y la comunicación de la aplicación entre todos estos microservicios?

Aquí es dónde te ayudan tener un service mesh:

- Administrar conexiones entre servicios
- Supervisión de tráfico
- Registro de tráfico
- Rastreo de tráfico
- Control de tráfico
- Escalabilidad y alta disponibilidad

En resumen un **service mesh** es una software dedicado a manejar la comunicación entre servicios.

Aquí te dejo el video para que lo sigas conmigo:

Un regalo para ti: DevOps, Aplicación para hacer tu prueba técnica

Hola querido lector, he escrito una aplicación en FastAPI, cuya finalidad es que realices las tareas que dice en el documento README.md, así podrás practicar para tus pruebas técnicas de DevOps. 

Puedes clonar el repositorio que se encuentra [aquí](https://github.com/ahioros/Bookstore-demo)

Te muestro algunas de las tareas de la prueba técnica:

En el área de los comentarios me puedes poner la URL con el informe si quieres que lo revise y te de feedback.

Kubernetes Horizontal Pod Autoscaling

Hoy vamos a hablar sobre Horizontal Pod Autoscaling (HPA para los amigos).

## ¿Qué es HPA?

Es una funcionalidad que ajusta automáticamente el número de pods en un deployment, replicaset o statefulset de "forma automática", según el uso de métricas personalizadas.

Con lo que nos lleva a nuestra siguiente pregunta:

## ¿Qué es una métrica personalizada?

Se basan en cualquier métrica que un objeto de Kubernetes informe en un cluster, como la cantidad de solicitudes de un cliente por segundo, la escritura de E/S por segundo, el uso de CPU o memoria, entre otros.

## ¿Por qué es importante HPA?

Porque es una manera de ahorrar ~~recursos~~ dinero, billete, cash, marmaja, etc. haciendo que la cantidad de pods crezca cuando se cumpla una política de uso en las métricas y disminuya la cantidad de pods cuando esté bajo del umbral.
Imagina que tu aplicación creará pods cuando sea necesario y los eliminará cuando no sean necesarios.

Helm creando tu repositorio

Antes de enseñarte a cómo hacer tu propio repositorio, primero te voy a enseñar cómo administrar los repositorios.

Buscar en el repositorio de Helm:

```bash
helm search hub grafana
```

Buscar en los repositorios ya instalados:

```bash
helm searh repo grafana
```

Para ver los Values de un paquete:

```bash
helm show values grafana
```

Supongamos que hiciste tu propio archivo de values y lo quieres aplicar en lugar del que trae por el paquete:

```bash
helm install -f miarchivo.yaml aplicación paquete
```

## Crear repositorio con GitHub

    1. Creas un nuevo repositorio público en GitHub.
    2. Ahora que estas en el repositorio nuevo que creaste, vas a settings -> Pages (en la barra de la izquierda).

    3. En Branch seleccionas la branch que quieres usar, en este ejemplo usaré main y por último seleccionas el directorio que por default es /(root).
    4. Por  último le das click en Save. Con esto has creado un repositorio.

La URL para acceder a tu repositorio es:

https://tuuser.github.io/tu-repositorio/

Por ejemplo:
https://ahioros.github.io/nginx-charts/

Helm Charts: Empaquetando tu aplicación

Seguimos con nuestro primer Helm Chart. Ya en el [anterior post](https://www.ahioros.info/2024/08/helm-el-manejador-de-paquetes-de.html) te enseñe como instalar helm y tus primeros pasos.

## Creación de un Chart

En este paso, crearemos un Chart para nuestra aplicación. Hacemos esto a traves de la herramienta [Helm](https://helm.sh/).


```bash
helm create nginx-chart
```

Esto nos genera la siguiente estructura de directorios y archivos:

Deploy Github Actions y Argo CD

Ya tengo un post explicando [cómo instalar Argo CD](https://www.ahioros.info/2024/06/como-instalar-argo-cd.html). Si no sabes cómo hacerlo ve a leerlo y regresas.

En este post vamos a configurar Argo CD para que utilice el repositorio Github.

El video está acá para que vayas haciéndolo conmigo:

## Configurando Argo CD

Necesitamos un pre-requisito:

- Crear un Personal Access Token (PAT) para conectar el proyecto con Argo CD, por motivos de practicicidad lo he llamado argocd. Si no sabes cómo hacerlo puedes leer los prerequisitos en este [post](https://www.ahioros.info/2024/08/github-actions-y-dockerfile-multi-stage.html).

Ahora entramos a Argo CD con nuestras credenciales.

## Creando el Proyecto

Vamos a Settings -> Projects y damos click en el botón que dice: "+ NEW PROJECT", llenamos los campos con la información que nos pide.

**Nota**: Para este caso que es un ejemplo no voy a explicar a detalle el apartado de seguridad todavía, haremos algo básico e "inseguro".

SOURCE REPOSITORIES: *
DESTINATIONS -  Server: *, Name: *, Namespace: *
CLUSTER RESOURCE ALLOW LIST - Kind: *, Group: *

Github Actions y Dockerfile Multi-Stage

Vamos a pasar el pipeline que hicimos en Azure Devops a Github Actions.

## ¿Qué es Github Actions?
Es una plataforma de integración continua (CI) y Continuous Delivery (CD) para el desarrollo de código.

Este servicio que proporciona GitHub tiene costo, pero cuenta con una versión [gratis](https://docs.github.com/en/billing/managing-billing-for-github-actions/about-billing-for-github-actions).

A la escritura de este post el plan gratis te da lo siguiente:

    - Storage: 500 MB
    - 2,000 Minutos (per month)

Tip, al igual que Azure DevOps (agent pools), en GitHub Actions puedes configurar **self-hosted runners** para que se ejecuten en tu propio servidor/equipo y esto es libre de los minutos que te dan gratis. Hay ciertos requisitos por ejemplo: si vas a usar docker, debe ser en un equipo con Linux, te dejo toda la información [aquí](https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners).

**Nota** Si quieres saber cómo hacer un self-hosted runner, deja tu comentario y te enseñaré a hacerlo.

Mientras que en Azure DevOps se llaman pipelines, en Github Actions se llaman **workflows**.

**Nota:** El ejemplo que estoy mostrándo consta de dos repositorios:

	a. El repositorio con el código de la aplicación. Este repositorio es en el que realizamos las configuraciones del workflow
[Link aquí](https://github.com/ahioros/workflow-react-example)

    b. El repositorio con el código de los manifests para kubernetes.
[Link aquí](https://github.com/ahioros/deploy-workflow-react-example)

## Configuración de Github Actions Workflows

### Prerequisitos

En el ejemplo que vamos a desarrollar tenemos que hacer unas configuraciones:

    1. Configurar permisos de GitHub Actions workflow:

    Ve a repo settings -> Actions -> General -> Workflow Permissions:

    2. Crear PAT (Personal Access Token):

    Ve a tu GitHub perfil -> Settings -> Developer settings -> Personal access tokens -> Tokens(classic):

    3. Crear secrets para el repositorio:

    Ve a tu repo settings -> Secrets and variables -> Actions -> Repository Secrets:

**Nota:** Donde puedes ver que tengo el usuario y el password con el que me voy a conectar hacia mi docker registry, en este caso es dockerhub.com. El API_TOKEN_GITHUB es el Personal Access Token que creamos en el paso 2.

    4. Tener un repositorio donde están los manifest de kubernetes, ejemplo:

```bash
    https://github.com/ahioros/deploy-workflow-react-example
```

Para crear un workflow se deben crear unas carpetas en nuestro proyecto de Github.

```bash
    .github/workflows/workflow-react-example.yml
```

El contenido de nuestro archivo yaml es el siguiente:

    ---
    name: workflow-react-example
    on:
      push:
        branches:
        - master

    jobs:
      CI:
        runs-on: ubuntu-latest

        steps:

        - name: checkout
          uses: actions/checkout@v4.1.0

        - name: Install Node.js
          uses: actions/setup-node@v4.0.0
          with:
            node-version: 15.x

        - name: npm install
          run: npm install

        - name: npm lint
          run: npm run lint

        - name: npm prettier
          run: npm install prettier && npx prettier . --write && npm run prettier

        - name: npm test
          run: CI=true npm run test

        - name: npm build
          run: npm run build

      Build_Docker_Image_ReactApp:
        needs:
        - CI

        runs-on: ubuntu-latest

        steps:

        - name: checkout
          uses: actions/checkout@v4.1.0

        - name: BuildAndPush
          uses: docker/login-action@v3.3.0
          with:
            username: "${{ secrets.DOCKERHUBCONNECTION_DOCKER_USERNAME }}"
            password: "${{ secrets.DOCKERHUBCONNECTION_DOCKER_PASSWORD }}"

        - name: Build the Docker image
          run: docker build . --file "Dockerfile" -t ahioros/rdicidr:${{ github.run_id }}

        - name: Create latest image as well
          run: docker tag ahioros/rdicidr:${{ github.run_id }} ahioros/rdicidr:latest

        - name: Push Docker image with the version number
          run: docker push ahioros/rdicidr:${{ github.run_id }}

        - name: Push the latest tag
          run: docker push ahioros/rdicidr:latest

        - name: Logout
          run: docker logout

      Deployment:
        needs:
        - Build_Docker_Image_ReactApp

        runs-on: ubuntu-latest
        steps:

        - name: checkout
          uses: actions/checkout@v4.1.0
          with:
            token: ${{ secrets.GITHUB_TOKEN }}
            repository: ahioros/deploy-workflow-react-example
            fetch-depth: 0
            persist-credentials: false

        - name: Deploy
          run: |-
            TAG=${{ github.run_id }}
            EXP="image: ahioros/rdicidr:[0-9]+"
            REP="image: ahioros/rdicidr:$TAG"
            sed -E -i "s|$EXP|$REP|g" k8s/02-deployment.yaml
            git config user.name  "Argo CD"
            git config user.email "ArgoCD@example.com"
            git checkout master --
            git add --all
            git commit -m "Deployment ID: ${{ github.run_id }}"
          shell: bash

        - name: Push changes
          uses: ad-m/github-push-action@master
          with:
            repository: ahioros/deploy-workflow-react-example
            GITHUB_TOKEN: ${{ secrets.API_TOKEN_GITHUB }}
    ---

El workflow es el mismo que el pipeline que se hizo en Azure Devops


Azure:

**CodeValidation -> Containerized -> Deploy**

Github Actions:

**CI -> Build_Docker_Image_ReactApp -> Deployment**


Aquí te dejo el repositorio de Azure para que lo compares:

https://dev.azure.com/guillermogarcialedezma/DockerHub%20Test/

Cada vez que hagas un cambio en el código y lo subas/empujes (push) al branch de master, el workflow se ejecutará.
Recuerda que esto es solo un ejemplo y no es recomendable subir/empujar directamente a tu rama/branch principal main/master.

En nuestro siguiente post haremos la configuración de Argo CD, para automatizar el despliegue en kubernetes con **Github Actions**.

**NOTA:** Mira el Dockerfile ya que ahora lo hice multi-stage para que tenga un menor peso:

Antes la imagen pesaba **1.09GB**
Ahora la imagen pesa: **188MB**

Monitoreo y Observabilidad: Instalando Prometheus - Parte 1

Como parte del ciclo CI/CD en la implementación de la cultura DevOps, después de realizar el Deploy necesitamos tener visibilidad de lo que está pasando dentro de nuestro cluster de kubernetes, tanto a nivel de hardware (uso de CPU, Memoria, Red, etc) sino también a nivel de aplicaciones que se están ejecutando en el cluster, podemos ver los hits que está teniendo o la memoria y CPU que está usando, esto nos puede servir para determinar cuándo escalar la aplicación y que se vuelva elástica, lo que nos ahorra dinero, así como para lanzar alertas cuando algo "pasa" y toca enviar una alarte para levantar al que está de guardia, incluso puedes integrar las alertas con una central telefónica y que llame al número del equipo que está de guardia/oncall, pero eso ya es una integración que te toca hacer a tí.

Antes de entrar en materia aquí te dejo el video en Youtube para que lo sigas conmigo:

### Prometheus

Empecemos por el principio, ¿Qué es [Prometheus](https://prometheus.io/)? Lo podemos definir como un sistema de monitoreo y alertas de código abierto. Esta escrito en Go. Todos los datos y métricas se almacenan como series temporales.

Desplegando con Argo CD

Se llegó el gran día, vamos a configurar Argo CD para automatizar nuestros despliegues.

Este es el video de la guía para que lo veas y vayas siguiendo paso a paso conmigo:

Necesitamos un pre-requisito:

	- Crear un Personal Access Token (PAT) para conectar el proyecto con Argo CD, por motivos de practicicidad lo he llamado argocd.

Ahora entramos a Argo CD (recuerda que le cambiamos el password hace dos publicaciones y creamos un port-forward con kubectl).

Agregando el Stage Deploy

## Introducción

Siguiendo con nuestros tutoriales, vamos a conectar Argo CD con Azure Devops, pero antes debemos preparar nuestro pipeline.

Para que se tenga una idea más clara he creado este diagrama:

Este es el video de la guía para que lo veas y vayas siguiendo paso a paso conmigo:

Cómo Instalar Argo CD

Continuando con nuestros posts de DevOps en español, ya hemos cubierto la parte CI (Continue Integration) ahora vamos a la parte CD (Continue Delivery).

## Qué es Argo CD
Comenzamos por el principio, vamos a definir qué es Argo CD.

Pipeline Validación de Código

Siguiendo con la construcción de nuestro pipeline para aplicaciones en react, vamos a agregar herramientas para validar el código del repositorio cada vez que realizamos un commit o un PR en el repositorio.

Antes de todo vamos a definir cada uno de estos conceptos.