@ -55,3 +55,249 @@ La metodología GitOps se basa en los principios de la automatización, la colab
Argo CD es una herramienta de entrega continua (Continuous Delivery) y de operaciones de infraestructura (Infrastructure Operations) que se ejecuta en Kubernetes. Permite la automatización y el control del proceso de implementación y despliegue de aplicaciones en un clúster de Kubernetes.
Argo CD es una herramienta de entrega continua (Continuous Delivery) y de operaciones de infraestructura (Infrastructure Operations) que se ejecuta en Kubernetes. Permite la automatización y el control del proceso de implementación y despliegue de aplicaciones en un clúster de Kubernetes.
Una de las características más destacadas de Argo CD es su capacidad para automatizar la gestión de versiones y el despliegue de aplicaciones. Permite la definición de flujos de trabajo (workflows) para la implementación de cambios, lo que garantiza que los cambios se realicen de manera controlada y segura. Argo CD también incluye características de seguridad, como el control de acceso basado en roles y la autenticación de usuarios.
### Infraestructura como código
Es una práctica que consiste en definir la infraestructura de una aplicación o sistema de forma programática utilizando un lenguaje de programación o una sintaxis específica. En lugar de configurar manualmente servidores, redes y otros recursos de infraestructura, los desarrolladores y los equipos de operaciones pueden definir la infraestructura como código y utilizar herramientas de automatización para gestionar y desplegar la infraestructura en un entorno reproducible y escalable.
### Crossplane
Crossplane es una extensión de kubernetes que transforma kubernetes en un **plano de control Universal**. Permite a los usuarios utilizar cualquier API como si fuera nativa de Kubernetes. Esto se logra mediante el uso de los recursos personalizados de Kubernetes (CRD), que permiten a los desarrolladores definir y extender los recursos de Kubernetes con sus propias definiciones. Puede crear y gestionar recursos que no son nativos de Kubernetes, como bases de datos, servicios de almacenamiento en la nube, cuentas de usuario y cualquier otra cosa que una API pueda ofrecer.
Además, Crossplane es compatible con **múltiples proveedores de nube**, lo que significa que los usuarios pueden utilizar cualquier servicio de cualquier proveedor de nube, incluidos Amazon Web Services, Google Cloud Platform y Microsoft Azure, entre otros. Esto permite a los usuarios crear **aplicaciones que utilizan servicios de varios proveedores de nube** sin tener que preocuparse por la complejidad de gestionar múltiples APIs de nube diferentes.
#### Proveedor
Un proveedor de Crossplane le permite aprovisionar una **infraestructura en un servicio externo**. se utiliza, entre otras cosas, para la autenticación, la realización de llamadas a API externas y utilizando APIs de kubernetes.
Para utilizar un proveedor además, es necesaria una configuración. Ésta se realiza por medio del uso de **providerConfig**. Normalmente se utilizan para autenticarse con la API con la que se está comunicando, En este proyecto, se utilizan tanto con las credenciales de **AWS** como con el **clúster de EKS**.
## Escenario realizado
El escenario consiste en lo siguiente:
* Clúster local de kubernetes, en el que se han instalado las siguientes aplicaciones:
* ArgoCD
* Crossplane, con los proveedores de AWS y Kubernetes.
* Clúster de EKS creado y gestionado por Crossplane, en el que hay 3 nodos.
### Instalaciones
Para la realización del proyecto, se necesita instalar los siguientes recursos:
#### Clúster local de kubernetes
Para desplegar un clúster local de k8s, se usará **kind**, ya que el proveedor de aws de crossplane consume muchos recursos, y kind es más liviano. Para su instalación se seguirá la documentación oficial: [Instalación kind](https://kind.sigs.k8s.io/docs/user/quick-start/). Para gestionar el clúster también es necesario kubectl, y la documentación oficial de instalación es la siguiente: [instalación kubectl](https://kubernetes.io/es/docs/tasks/tools/install-kubectl/). Es muy importante partir de un **clúster nuevo** y sin configuraciones previas.
#### ArgoCD
Para instalar ArgoCD se ejecutan los siguientes comandos:
Tras eso, creamos el fichero **aws-credentials.txt** con las claves generadas en AWS con el siguiente formato:
```bash
[default]
aws_access_key_id = <aws_access_key>
aws_secret_access_key = <aws_secret_key>
```
Creamos un **secret** de kubernetes con las credenciales
```bash
kubectl create secret \
generic aws-creds \
-n crossplane-system \
--from-file=creds=./aws-credentials.txt
```
Finalmente, se crea un **providerconfig** con el secret que hemos creado
```bash
cat <<EOF|kubectlapply-f-
apiVersion: aws.crossplane.io/v1beta1
kind: ProviderConfig
metadata:
name: default
spec:
credentials:
source: Secret
secretRef:
namespace: crossplane-system
name: aws-creds
key: creds
EOF
```
##### kubernetes
Instalamos el proveedor con el siguiente comando:
```bash
cat <<EOF|kubectlapply-f-
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
name: crossplane-provider-kubernetes
spec:
package: crossplane/provider-kubernetes:main
EOF
```
#### Recursos gestionados
Para desplegar un clúster de aws de forma sencilla, se van a utilizar dos recursos gestionados (managed resources):
* **eks.yaml**, de tipo composition que contiene parámetros para la creación del clúster, como lo son las redes que se crearán, en qué servidores, qué tipo de máquinas pueden crearse, etc..
* **definition.yaml**, de tipo compositeResourceDefinition, contiene los parámetros que se le van a pasar con el manifiesto final, así como los recursos a los que corresponden en composition. También contiene valores por defecto.
Ambos ficheros se encuentran en el repositorio del proyecto en la carpeta crossplane:
Para que ArgoCD esté atento a los commits de github y siga así la metodología GitOps, al tenerlo instalado en un clúster local, es necesario instalar ngrok, exponiendo el puerto 8080:
Para que GitHub notifique a ArgoCD en el evento de un push al repositorio, tenemos que añadirlo en la configuración del mismo. Para hacerlo, en el repositorio accedemos al apartado **Settings**; en la barra lateral seleccionamos **Webhooks** y **Add webhook**.
Dentro de la página, tenemos que rellenar los siguientes campos:
* **Payload URL**: la url generada por Ngrok, con la cadena /api/webhook añadida al final.
* **Content type**: application/json.
* **Event**: Cuando se produce un
#### Preparación previa a la demo
Para preparar la demo, iniciaremos la aplicación de argocd **app.yaml** que se encuentra en el repositorio, ésta despliega el siguiente manifiesto:
```yaml
apiVersion: prodready.cluster/v1alpha1
kind: ClusterClaim
metadata:
name: proyecto-eks
labels:
cluster-owner: robertorm
spec:
id: proyecto-eks
compositionSelector:
matchLabels:
provider: aws
cluster: eks
parameters:
nodeSize: medium
minNodeCount: 3
```
Donde podemos modificar los siguientes parámetros:
* **name**: Nombre del clúster.
* **nodesize**: tipo de máquina que se van a utilizar en los nodos. En el fichero eks.yaml se establecen los siguientes tamaños:
* small: t2:micro
* medium: t3.micro
* large: t3.medium
Los dos primeros tamaños, entran dentro de la capa gratuita de AWS.
* **minNodeCount**: mínimo de nodos que tienen que crearse en el clúster.
Tras aproximadamente **15 minutos**, el clúster estará creado junto a sus nodos. Si observamos el panel de ArgoCD de la aplicación, podemos ver todos los recursos de AWS que se han desplegado:
