Crossplane, Infraestructura como Código
En este artículo, Miguel Ángel Chuecos, Technical Manager del área Cloud y Arquitectura de Dare Planet Technology, hace un repaso a Crossplane, qué es, cómo configurarlo y las principales alternativas.
Este artículo corresponde a una sesión que hicimos en LinkedIn Live, te dejamos por aquí el vídeo por si quieres verlo y leer este artículo al mismo tiempo.
Table of Contents
¿Qué es la IaC? ¿Y Crossplane?
En los últimos meses, en el Mundo Cloud y GitOps, se hecho un fuerte eco de una herramienta que ha llegado con fuerza para competir en el mundo de IaC (Infraestructura como código) llegándose a comparar con algunas herramientas asentadas y mayor recorrido como es Terraform.
Pero, ¿Qué es IaC (Infraestructura como código)?
Como su nombre indica, el objetivo principal de este tipo de herramientas, es de gestionar y aprovisionar infraestructura de uno o varios proveedores (GCloud, Kubernetes, Azure, AWS, Oracle…) mediante código en lugar de un proceso manual mediante interfaz, CLI, API, etc.
De esta forma, conseguimos provisionar infraestructuras que se componen de multiples piezas/servicios (Compute, Networking, Storage…) en cuestión de segundos siendo posible multiplicar y «clonar» este entorno sin tener que realizar acciones repetitivas y, a su vez, ofreciendo nuevos entornos al equipo de desarrollo con mayor agilidad.
Y ahora bien, ¿Qué es Crossplane?
Es un proyecto Open-Source que proporciona a Kubernetes un complemento permitiendo actuar como control plane para proveer infraestructura Cloud. Además, Crossplane ofrece y expone APIs de autoservicio de alto nivel para que los equipos la consuman sin tener que escribir ningún código.
DevOps y GitOps
Crossplane es considerada una pieza del framework GitOps pero, veamos primero la definición de DevOps, GitOps y en qué se diferencian.
DevOps es una cultura que enfoca en ofrecer a los equipos de desarrollo y operaciones la posibilidad de trabajar juntos de manera colaborativa.
Por otro lado, GitOps, es el marco de herramientas para que se apliquen las prácticas DevOps utilizando principalmente Git como sistema de control de versiones.
Este framework está diseñado para cumplir los objetivos de colaboración, CI/CD, automatización de infraestructura e implementación de aplicaciones.
El siguiente ejemplo muestra un modelo GitOps mediante algunas herramientas como ECR (Repositorio Docker de AWS), ArgoCD, Crossplane y Git como pieza base.
Mediante la herramienta CI/CD Argo, es posible desplegar un componente en múltiples clústeres de Kubernetes independientemente de donde se ubiquen (siempre y cuando haya accesibilidad); multi-cloud, multi-región, multi-account…
De esta forma, evitamos tener que desplegar el mismo componente por cada clúster de forma manual y repetitiva o mediante un script personalizado que requiere de un mantenimiento.
El diagrama, muestra el ejemplo de una aplicación/componente a desplegar en Kubernetes (empaquetado con chart de Helm) que necesita ser desplegado en múltiples clústeres y que a su vez, requiere la creación de algunos recursos/servicios cloud ya que, la definición de dichos recursos se pueden especificar en manifiestos YAML con el formato de Kubernetes.
Cloud Native Compute Foundation y Crossplane
Crossplane forma parte de la Cloud Native Compute Foundation (CNCF) al ser una herramienta open-source.
La CNCF es una fundación que promueve la adoptación de cloud-native cuya adoptación y objetivos recogen:
- Tecnologías/aplicaciones escalables en entornos dinámicos modernos (nube pública, privada o híbrida).
- Contenedores, service grids, microservicios, infraestructura inmutable, APIs declarativas…
- Técnicas para crear sistemas resilientes, gestionables y observables.
Todas las tecnologías bajo la CNCF son proyectos que se alojan mayormente en repositorios de Github.
Te dejamos por aquí el landscape con todas las herramientas alojadas bajo la CNCF, existiendo varias etapas para cada proyecto:
- Etapa de sandbox: Punto de entrada inicial para los proyectos.
- Etapa de incubación: En la que un proyecto debe cumplir con todos los requisitos de sandbox, así como con criterios adicionales, como la documentación de al menos tres usuarios finales que implementan con éxito el proyecto en producción.
- Etapa de graduación: En la que un proyecto debe cumplir con todos los requisitos de la etapa de incubación, más criterios adicionales, como, por ejemplo, la finalización de una auditoría de seguridad independiente.
Instalación y configuración de Crossplane
Para que el clúster de Kubernetes disponga de Crossplane es necesario su instalación y configuración junto a todos los recursos (Composite, Resource, Definition, Composition…) para su funcionamiento.
En la documentación oficial podemos encontrar los pasos a seguir para ello.
Independientemente del proveedor cloud, es requerido configurar un recurso ProviderConfig que básicamente le informa a Crossplane cómo conectarse a nuestra cloud.
En el caso de AWS, si no dispones de un cluster EKS, puedes crearlo manualmente desde la consola de administración o mediante eksctl con el siguiente comando:
eksctl create cluster
--name learn-crossplane \
--nodes 3 \
--with-oidc \
--ssh-access \
--ssh-public-key learn-crossplane \
--managed
Para establecer el contexto con el cluster de Kubernetes creado:
# Obtener el listado de contextos
kubectl config get-context
# Establecer el contexto con el nombre del cluster EKS mostrado en el listado
kubectl config use-context demo@demo.com@learn-crossplane.eu-west-2.eksctl.ios
Recuerda eliminar el clúster tras finalizar todas las pruebas:
eksctl delete cluster --name learn-crossplane
Recurso de ejemplo de Crossplane
Crossplane dispone de una guía para crear un recurso de ejemplo (BBDD PostgreSQL) junto a la creación de un pod como aplicación de ejemplo para mostrar la conexión con la base de datos a través del secreto creado por el recurso con todos los datos necesarios (endpoint, port, usuario, contraseña).
Puedes ver más sobre el comportamiento y pasos de la guía en el vídeo de Youtube, el link te llevará al momento exacto en el que tratamos el tema.
¿Cómo saber los parámetros a utilizar en la definición de un recurso y qué tipo de recursos puedo crear en función del proveedor cloud?
En la sección API de la documentación oficial de Crossplane, es posible encontrar un listado de recursos por proveedor y una especificación de todos los parámetros a utilizar para personalizar dichos recursos.
Comparativa Crossplane vs Terraform
Si comparamos Crossplane con Terraform veremos que ambas tienen cosas en común pero también con sus diferencias obteniendo una serie de ventajas y desventajas en sus multiples categorías. Estas categorías se clasifican en:
- Previsión: Mediante el comando plan de terraform podemos obtener una preview (dry-run) de lo que se va a aplicar como infraestructura en el entorno destino, sin embargo, con crossplane, no hay una previsión a alto nivel de lo que se va a crear, modificar o eliminar.
- Modificaciones: Cada vez que se requiera aplicar un cambio en infraestructura, con Terraform debe hacerse «manualmente» realizando los cambios oportunos en código y ejecutando sus comandos (A no ser que esté integrado con algun sistema CI/CD y Git que automatice el lanzamiento de esos comandos cuando detecte nuevos cambios). Crossplane aplica los cambios de manera automática, es decir, cuando modificas el manifiesto bien desplegando de nuevo el YAML o bien «en caliente» directamente desde el recurso creado, Crossplane aplica esos cambios detectados. Por otro lado, cuando realizas un cambio manualmente, por ejemplo, modificar el tipo de instancia de una RDS, Crossplane detectará que el manifiesto que tiene no es igual a la infraestructura existente y la modificará con los valores que él dispone.
- CI/CD: Ambas herramientas son fáciles de integrar en las prácticas de CI/CD.
- Requisitos: Terraform únicamente requiere disponer de un sistema donde almacenar el tfstate (Bucket, Terraform Cloud…) para ser compartido con el resto del equipo. Por otro lado, Crossplane requiere un cluster de Kubernetes ya que únicamente funciona sobre esta tecnología y esto puede implicar un coste elevado si se crea exclusivamente para este fin.
- Lenguaje: Terraform utiliza su propio lenguaje HCL (HashiCorp Configuration Language) que tiene una sintaxis muy parecida a JSON el cual permite leer fácilmente su código pese a que tengas que aprender cómo desarrollar en Terraform y sus buenas prácticas. Sin embargo, Crossplane funciona con YAML que es el lenguaje que utilizan los manifiestos de Kubernetes por lo que si ya tienes experiencia con Kubernetes, esto facilita mucho los nuevos desarrollos con Crossplane.
- Comunidad y soporte: Terraform dispone de una comunidad mucho mas amplia al tener más tiempo en el mercado, a la par que el soporte, el cuál es posible encontrar hilos de resolución de problemas fácilmente. Crossplane, al ser una herramienta con menos tiempo, no dispone de tanto soporte, sin embargo, esto va cambiando con el paso del tiempo y ya tiene diferentes fuentes para ello (Slack, Github, Stackoverflow…).
¿Cuándo usar Crossplane o Terraform?
Tras conocer dos herramientas de IaC puede surgir la pregunta… entonces, ¿Qué herramienta tengo que utilizar en cada caso?
Veamos un caso real; Un equipo de desarrollo quiere crear un nuevo servicio, crea su repositorio, configura sus manifiestos de kubernetes (Helm o no), genera la imagen de Docker, la pushean y se despliega al cluster. No tiene interacción humana porque la CI/CD la crea automáticamente con sus recursos necesarios (Ingress, Service, etc.). Incluso antes del despliegue de una aplicación o componente, se podría desplegar de forma automática su infraestructura necesaria para funcionar.
Pero, ¿Qué ocurre cuando aparece una nueva funcionalidad en la aplicación que requiere un nuevo recurso? En muchos casos lo que ocurre es que hay que seguir un procedimiento y una burocracia lenta. Abrir un ticket, pedir crear un recurso (Ej. BBDD) y luego el equipo de cloud o el equipo que mantiene la infra, proceder con ello.
Esto además, conlleva una serie de pasos manuales, por ejemplo establecer los secretos como SSM Params o en un bucket, compartirlo con el equipo de desarrollo y que ellos modifiquen la aplicación para que apunte a esos secretos y se conecte a la BBDD. Este proceso es lento y no escala, sobre todo si este proceso se tiene que repetir n veces.
Aquí aparece Crossplane, una herramienta que se puede utilizar para servicios/casos puntuales y acelerar este proceso. Por lo tanto, Crossplane y Terraform se pueden complementar siendo Terraform como herramienta de infraestructura base (Todo el stack para disponer de una aplicación funcionando) y Crossplane para nuevos servicios/necesidades.
¿Quieres contarnos algo?
¡CONTACTA CON NOSOTROS!
