CD de terraform con github actions en AWS

Ya he mostrado dos formas de realizar un CD de terraform con Jenkins que puedes encontrar [aquí](https://www.ahioros.info/2024/12/pipeline-cd-en-jenkins-para-terraform.html) y [aquí](https://www.ahioros.info/2024/12/pipeline-cd-en-jenkins-para-terraform_12.html).

Ahora vamos a realizar lo mismo pero con GitHub Actions. El código está [aquí](https://github.com/ahioros/terraform-aws-eks) como ya debes saber los actions van dentro de la carpeta .github/workflows.

El video lo puedes ver aquí de este tutorial:

Instalando DeepSeek con interfaz web en docker y soporte nvidia

En este post vamos a instalar DeepSeek usando docker y aprovechando la gráfica nvidia.

¿Por qué usando contenedores? Por que no soy cochino instalando cosas que no sé qué haran en mi sistema y no tengo tiempo de ponerme a leer el script de instalación.

Aquí te dejo el video para que veas cómo lo realizo:

## Pre requisitos

Instala los pre-requisitos para usar tu tarjeta gríafica:

libnvidia-container nvidia-container-toolkit

Pipeline CD en Jenkins para terraform AWS EKS segunda parte (plugin AWS Credentials)

En el [post anterior](https://www.ahioros.info/2024/12/pipeline-cd-en-jenkins-para-terraform.html) te mostré como usar Jenkis como CD para desplegar tu infraestructura EKS con terraform en AWS. El "detalle" es que usamos el secret de Jenkins de texto cifrado.

Ahora lo que usaremos es el plugin de [AWS Credentials](https://plugins.jenkins.io/aws-credentials/), lo puedes instalar desde el administrador de plugins de Jenkins con un par de clicks.

Aquí abajo te dejo el video para que veas la configuración en caso que tengas dudas:

Pipeline CD en Jenkins para terraform AWS EKS

En el [post anterior](https://www.ahioros.info/2024/12/creacion-de-un-cluster-aws-eks-con.html) hicimos un cluster AWS EKS con terraform. Como lo que nos gusta aquí es el tema de automatización, vamos a crear el pipeline de CD con Jenkins, les motraré 2 maneras de hacerlo, en este primer post vamos a hacerlo usando Secrets de Jenkins.

## Explicación del Pipeline

El Pipeline -> repositorio github (puede ser cualquier repositorio de git) -> Terraform (init, plan, apply/destroy) -> kubectl test

## Requisitos

Para Jenkins estoy usando el contenedor de Jenkins.
Los Plugins que tengo para este ejemplo son:

    * Pipeline: GitHub Groovy Libraries
    * Pipeline: Stage view
    * Terraform Plugin (opcional)

**Nota:** En mi caso yo tengo los binarios de terraform y kubectl en el directorio jenkins_home/terraform-bin y jenkins_home/kubectl-bin/.

Aquí abajo te dejo el video para que veas la configuración en caso que tengas dudas:

AWS Creación de un cluster EKS con terraform

## Introducción

Ya hace un tiempo enseñé [cómo instalar localstack para que puedas probar terraform](https://www.ahioros.info/2024/05/how-to-install-localstack-with-docker.html). Bueno ahora voy a enseñarte una de las maneras de como crear un cluster de kubernetes (EKS) en AWS.
 
¿Cuántas maneras de crear un cluster de kubernetes (EKS) en AWS hay?

1. Con terraform escribiendo desde 0.
2. Con terraform haciendo uso del module.
3. Con cloudformation.
4. Crear un cluster de kubernetes (EKS) en AWS con eksctl (esta al final es un wrapper y hace uso de cloudformation).

Nosotros vamos a realizar la primera configuración.


Puedes ver el video aquí:

No te voy a decir todas las ventajas que tiene hacerlo con terraform (que para eso ya debes de saberlas) solo diré que no me gusta tanto hacerlos con cloudformation por que "tarda" bastante tiempo.

**Nota:** más adelante vamos a hacer el pipeline CI/CD para automatizar el deploy e ir agregándo más características, así como ir poniéndo "presentable" el proyecto.

Hablemos de: Seguridad en Kubernetes

Vamos a dividir en antes del despliegue y en Kubernetes.

## Antes del Despliegue

1. Escaneo de las imágenes de contenedores

  - Durante CI.
  - Escaneo constante del registry de imagenes.

	Herramientas:

  - snyk.
  - sysdig.
  - Sonarqube.
  - Trivy.

2. Que el servicio de la imgen lo ejecute un usuario de servicio (non-root)

	**Nota:** Esto lo podemos sobreescribir en kubernetes usando **spec.securityContext.runAsUser: 1000** o **spec.allowPrivilegeEscalation: false**

## En Kubernetes

1. Manejo usuarios y permisos

	Usa RBAC, ClusterRole, ServiceAccount y siempre usa la regla de menor privilegio.

2. Políticas de red

	Aplica NetworkPolicy para limitar la comunicación entre pods, no quieres que un pod de front se comunique con un pod de database, se debe comunicar con el backend solamente, por mencionar un ejemplo.
  **Nota:** Usa la regla del mínimo acceso permitido.

	Herramientas:

  - calico
  - weave Net

	También puedes usar herramientas a nivel de aplicación, usando un service mesh ya hemos hablado de dos, [Linkerd](https://www.ahioros.info/2024/10/service-mesh-linkerd.html) e [Istio](https://www.ahioros.info/2024/10/service-mesh-istio.html).

	Herramientas:

  - Istio
  - Linkerd

3. Cifrado de tráfico, mTLS entre Servicios

	Esto se resuelve usando un service mesh, solo tienes que habilitarlo.

4. Seguridad y cifrado de Secrets

	Habilita el cifrado usando el recurso EncryptionConfiguration. Pero todavía necesitamos algo para manejar las llaves cifradas, aquí nos apoyamos de herramientas de terceros como AWS KMS, Google KMS, Vault de HashiCorp,etc. o incluso te puede funcionar algo como pass si estás on-premise.

5. Seguridad en etcd

	Si estas administrando etcd ponlo detrás de un firewall, cifra toda la informacion en etcd.

6. Backup y Restore

	En este caso me refiero a la data de tu(s) aplicacion(es) que están corriendo en kubernetes.

  - Realiza backups de tus aplicaciones regularmente.
  - Guarda los backups en un lugar seguro.
  - Hagan pruebas de sus backups para ver que estén funcionando correctamente en un ambiente controlado, incluso pueden automatizar estos tests para que se ejecuten cada cierto tiempo.

7. Define y Aplica Políticas de seguridad

	Por ejemplo:

  - No permitas ejecutar contenedores como root.
  - Cada pod debe tener su política de red.
  - Los backups se realizan cada día a X hora.

	Algunas herramientas que te pueden ayudar son:

  - Open Policy Agent.
  - Kyverno.

8. Disaster Recovery

  Define estrategias y mecanismos para una recuperación ante un desastre y sobre todo automatiza.
  Define también hacer pruebas para que todo el equipo sepa qué hacer en caso de uno y poder ajustar la estrategia de recuperación, entre mayor conocimiento tengan menor tiempo les tomará en ejecutar la recuperación y menor tiempo afectaran la experiencia del usuario.

Kubernetes: Controla tus recursos

Ya todos sabemos que la cultura DevOps parte de cederle responsabilidades al área de desarrollo para liberar sus servicios más ágil, esto no quiere decir que debamos darles las llaves del cielo y que hagan lo que quieran, por lo que es responsabilidad de nosotros tomar precauciones para que no tumben los servicios y tengamos que correr como pollos sin cabeza a solucionar.

Como ya sabemos tener el servicio indisponible se traduce en pérdida de dinero, pero te cuento que tener el servicio consumiendo recursos sin control también se traduce en pérdida de dinero.

Ya en posts anteriores cuando hablé de [HPA](https://www.ahioros.info/2024/09/kubernetes-horizontal-pod-autoscaling.html) mencioné unas buenas prácticas para aplicar a nuestros deployments, para ser más específicos resources.requests y resources.limits.

Puedes seguir el video aquí:

 

## LimitRanges

Hablemos de: Pod Disruption Budgets

El escenario "normal" cuando tienes que hacer un mantenimiento en tu cluster de k8s, es que marcas un nodo como cordon esto hace que no acepte más pods y de ahí empiezas a "drenar" los pods el nodo. Lo que hará k8s es que "sacará" los pods del nodo y después empezará a crearlos en el nodo activo. Si nuestra aplicación tiene la mayoría de los pods en el nodo que vamos a hacer el mantenimiento, nos trae inconvenientes como:

- Indisponibilidad de nuestra aplicación.
- Perder dinero.

Aquí te dejo el video para que veas el funcionamiento:

El Pod Disruption Budget (para los compas "PDB" de ahora en adelante) sirve para drenar un nodo, con la diferencia que va a recrear primero en el (los) otro(s) nodo(s) los pods y cuando estén listos (RUNNING), va a matar los pods del nodo que quieres hacer el mantenimiento. Suena bien ¿no? Así, evitamos la indisponibilidad de nuestra aplicación.