Ahioros Home

[ Guillermo@Garcia ]# more /var/pub | beer

lunes, 16 de septiembre de 2024

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.

viernes, 30 de agosto de 2024

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/

lunes, 26 de agosto de 2024

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:

lunes, 19 de agosto de 2024

Helm el manejador de paquetes de Kubernetes

## ¿Qué es Helm?

Helm es el administrador de paquetes de Kubernetes. En pocas palabras es un nivel más alto sobre kubernetes para manejar las aplicaciones, esto nos permite poder desplegar aplicaciones y solo cambiar ciertas variables de configuración en tus archivos de Helm. Piensa que Helm es el equivalente a apt, yum, Homebrew o pip para kubernetes.

jueves, 15 de agosto de 2024

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: *

lunes, 12 de agosto de 2024

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**

lunes, 5 de agosto de 2024

Monitoreo y Observabilidad: Instalando Grafana - Parte 2


Este post es continuación de [Monitoreo y Observabilidad: Instalando Prometheus - Parte 1](https://www.ahioros.info/2024/08/monitoreo-y-observabilidad-instalando.html)

## ¿Qué es Grafana?

**Grafana** es una herramienta open-source de análisis, almacenamiento y visualización de series de datos, ofreciendo una interfaz de usuario amigable y muy poderosa.

En el ejemplo que estoy usando [Prometheus](https://www.ahioros.info/2024/08/monitoreo-y-observabilidad-instalando.html) como nuestra fuente de información (Datasource).

Básicamente Prometheus es el que se encarga de recabar los datos, mientras que **Grafana** es el que se encarga de mostrar la información.

**Nota:** Debido a que yo lo estoy ejecutando desde un cluster de Kubernetes onpremise, he tenido que definir un PV, por lo que si tu intentas ejecutarlo en tu proveedor de nube no debería ser necesario ya que dicho almacenamiento te lo debe facilitar tu proveedor en la nube.

Aqui te dejo el video para que vayas realizándolo conmigo:

jueves, 1 de agosto de 2024

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.