Experimentando con Deno para facilitar las implementaciones de Kubernetes

Hola a todos. Soy Ishai. Soy el CTO de Lifecycle. Hoy voy a hablar sobre cómo podemos usar Dino para definir nuestra implementación de Kubernetes de una manera mucho más fácil de lo que normalmente hacemos.

Para dar un poco de contexto, hablemos sobre YAML. Porque Kubernetes es básicamente, como, toda la configuración de Kubernetes es como este gran archivo YAML. Y probablemente, incluso si no has usado Kubernetes, conoces los archivos YAML de otros lugares, como de GitHub Actions o de Docker Compose o CloudFormation. Y básicamente, casi todas las herramientas, quiero decir, muchas herramientas, en el ecosistema de DevOps, están utilizando YAML para definir esta configuración. Y siendo honesto, la primera vez que me encontré con este archivo YAML, fue terrible. No era conveniente, como, copiar de diferentes YAML y fusionarlos, y la indentación era extraña y, como, diferencias de objetos DRA. Pero me acostumbré a eso. Y ahora, estoy escribiendo muchos YAML y funciona bien. Pero la cosa es que los YAML de Kubernetes, son enormes y complejos, y hay tantos de ellos. En este caso, escribir los YAML manualmente simplemente no es suficiente en términos de escala, corrección e incluso diversión y cordura. Así que hoy voy a hablar sobre cómo podemos escribir estos YAML de manera más fácil y más específicamente, cómo podemos hacerlo usando DNO y TypeScript. Unas palabras sobre mí. Como mencioné, soy cofundador de Lifecycle. Soy ingeniero de software. He usado Kubernetes en los últimos cinco años. También soy mantenedor de código abierto de Tweak. Es una solución de gestión de características nativa de la nube. Dos palabras sobre Lifecycle, es una herramienta de colaboración para equipos de desarrollo basada en un entorno previo. Es un producto en beta pública que lanzamos hace unas semanas, y estamos muy emocionados al respecto. Te invitamos a que lo pruebes en Lifecycle.io. Ok, entonces, ¿qué tenemos en la agenda hoy? Vamos a ver Kubernetes. Vamos a definir la misma configuración en DNO, y luego haremos un resumen. Unas palabras sobre cómo funcionan los recursos en Kubernetes. Básicamente, la idea es que tenemos los usuarios de Kubernetes, que pueden ser desarrolladores o administradores. Ellos están enviando una definición al servidor de API usando YAML, y tenemos los controladores de Kubernetes que hacen que toda la magia suceda. Ahora, estos recursos pueden ser cualquier cosa, desde un trabajo cron hasta una cosa de red.

Entonces, se basa en Deano. Y para aquellos de ustedes que no están familiarizados con Deano, Deano es un tiempo de ejecución para JavaScript y TypeScript. Esa es la definición de Wikipedia. Y en pocas palabras, es algo muy similar a NodeJS. De hecho, fue creado por el mismo creador. Es un tiempo de ejecución seguro para ambos TypeScript y JavaScript. No está impulsado por la API del navegador y las herramientas del ecosistema. Por lo tanto, tiene una sensación diferente. El nodo, aunque se basa en V8. Y algunos dirán que es la próxima evolución de Node.js, no necesariamente lo creo. Es por eso que tenemos el signo de interrogación aquí.

Echemos un vistazo a Deno. Lo primero es la CLI. Entonces, todo está en Deno. La única herramienta que necesitas para trabajar con Deno es la CLI. No es como Node que tienes Node y NPM y tal vez solo para pruebas y TypeScript, si quieres compilar código TypeScript. Deno, la CLI hace todo, desde el empaquetado, compilación, ejecución, instalación, pruebas y todo. Así que es realmente bueno. Es muy similar a Go si usas Go. Deno admite TypeScript de forma nativa, por lo que no necesitamos tener un compilador de TypeScript. Ya está incorporado. Y lo interesante de TypeScript es que es un superconjunto de JavaScript con un sistema de tipos extremadamente potente. Estoy seguro de que muchos de ustedes lo han usado en el pasado. Y hoy voy a mostrar lo fácil que es escribir estas definiciones de Kubernetes en TypeScript. Así que veamos algunos ejemplos. Comenzaré con un ejemplo simple. Básicamente, es como el ejemplo del pod. Y puedes notar aquí que, en primer lugar, estoy importando este archivo de definición de Kubernetes desde una URL. Y puedes ver que tengo la API. Y básicamente, todo lo que es posible obtener en Kubernetes, lo tengo con autocompletado completo. Y corrección de tipos. Entonces, aquí estamos agregando un contenedor sin nombre. Por lo tanto, te dirá que falta el nombre. Y lo mismo ocurre si estoy usando el tipo incorrecto. Nuevamente, corrección regular de tipos. Y la cosa es que estos tipos se generan. Y estoy generando, tengo que generar los tipos de todas las API comunes de Kubernetes. Y lo otro que estoy importando aquí es de la biblioteca SD de Deno. En Deno, cada importación, no tenemos NPM y paquetes como esos. Solo importamos URL. Por lo tanto, es muy, muy fácil de consumir.

Ahora voy a ejecutar este ejemplo y obtener el YAML relevante solo creado en TypeScript. Ahora, en este ejemplo, no proporciona mucho valor, pero si volvemos a ver el ejemplo más complejo. Entonces, ese es un ejemplo de la implementación y el servicio y la ingestión que mostré antes. Y en primer lugar, puedes ver que estamos usando variables. Entonces, estoy usando una variable de etiqueta y metadatos, y luego puedo usarla en varios lugares. No necesito hacer esta replicación. Eso también puede causar errores. Y estoy haciendo lo mismo. Simplemente lo estoy volcando en YAML. Entonces, si ejecuto esta definición, tendremos prácticamente el mismo YAML que teníamos antes. Con unas pocas líneas de código. Y también puedo aplicarlo al clúster. Así es como simplemente voy a volcar el YAML creado por el TypeScript a mi Kubernetes.

Ok. Otra cosa interesante es que podemos tener pruebas. He creado una prueba para este servicio. Y nuevamente, no estoy usando ninguna otra herramienta. Solo estoy usando la CLI de Deno aquí. No necesito Mocha o CHI ni ninguna otra herramienta para ejecutar pruebas. Entonces, puedo ejecutar pruebas. Puedo definir esta definición, esta configuración en TypeScript. Y en el momento en que estoy usando un lenguaje real o de propósito general para hacer esta definición, también obtengo todos los beneficios de este lenguaje. Por lo tanto, la composición y la abstracción son mucho más poderosas.

Entonces, aquí he creado una abstracción llamada aplicación. Y nuevamente, es la misma definición que vimos antes, pero ten en cuenta que solo he definido el nombre, la imagen, el nombre del sistema operativo y la cosa se deriva de los parámetros. Puedes ver la definición aquí. Y la definición no es importante. En este caso, es importante que sea muy fácil crear este tipo de definición y es muy fácil consumirlas. Y lo bueno de esto, porque crea un conjunto de recursos, todavía puedo parchearlos después. Entonces, mi abstracción se ve así con este campo 506, pero Kubernetes nos permite

Entonces, nuevamente puedo hacerlo en el script con allow env, y veremos el mismo ejemplo que requiere acceso de lectura a home SSH. Y también, si hago allow read punto, aún no funcionará porque... probablemente no debería funcionar porque la otra permisión también está. Veamos. Actualmente falla en allow net, pero si hago allow net... Entonces ves que no tenemos acceso de lectura a esta carpeta porque cuando hice allow read, solo permití leer esta carpeta y no, por ejemplo, la carpeta home VS code SSH. Entonces eso es otra cosa que también podemos limitar, la carpeta de lectura a la que tiene acceso es la red. Entonces, si estoy haciendo algo como eso, significa que solo podemos conectarnos a la red de la API GitHub.com. De esa manera, podemos hacer que sea mucho más... quiero decir, significa que un script que quiera hacer algo muy ingenuo como robar nuestras variables de entorno o leer un archivo de un sistema de archivos y luego enviarlo a algún lugar, no funcionará en Deno. Entonces eso es algo bueno cuando estamos pensando en cómo vamos a usar esta aplicación y generalmente es como

Básicamente estoy importando el recurso desde la entrada estándar. Estoy haciendo un recorrido en el recurso de tipos específicos. Aquí es como un despliegue y nuevamente, fíjate en el tipo, el poder del sistema de tipos de TypeScript. Entonces aquí tengo todas las definiciones de mis grupos de API en Kubernetes, y aquí solo tendré los recursos bajo appsv1. Entonces, si elijo, por ejemplo, un daemon set, aquí tendré el despliegue que en realidad es un objeto de daemon set, por lo que no tiene réplicas, pero si uso despliegue, funcionará porque el punto está bajo v1 y tiene réplicas y todo como tenemos autocompletado y corrección, básicamente significa que filtramos el tipo correcto y también tenemos el objeto correcto que podemos modificar si queremos. Podemos usarlo para modificar objetos, para parchear, también se puede usar para validación, como una validación rápida y muy fácil. Entonces aquí defino si tengo un ingreso sin TLS, como una excepción, y lo voy a ejecutar, y obtendremos esta excepción. Y nuevamente, todo es como autocompletado y muy fácil de usar. Y este archivo se puede ejecutar desde cualquier lugar. No necesitamos, solo necesitamos Deno CLI y este archivo y simplemente lo ejecutamos. No necesitamos configuración del proyecto, no necesitamos instalar dependencias, todo está en este archivo. Entonces es bastante asombroso, en mi opinión, el tooling de Deno. Quiero decir, todos los ejemplos que he mostrado, los ingredientes aquí, no es como un marco o tooling complejo y muy poderoso. Es simplemente Deno, generación de tipos, una cantidad mínima de código utilizando bloques de construcción y básicamente eso es todo. Es muy simple y obtenemos mucho de él. No es perfecto porque todavía necesitamos tener generación de código para obtener el tipo de Kubernetes. La definición de la API de Kubernetes a veces no es lo suficientemente confiable. Necesitamos utilidades. Pero es muy poderoso. Si damos un paso atrás y pensamos en lo que es importante en una herramienta como esa, o al menos puedo decir lo que es importante para mí. Para mí, es importante poder tener características de composición, tener una composición que sea declarativa. Puedo usar parámetros. Puedo crear abstracciones. Puedo hacer superposiciones. Tengo un recurso y quiero hacer algún parche en él.

¿Cuántas herramientas, frameworks y software como servicio en tu stack utilizan configuraciones basadas en YAML? Esta encuesta mostró que la mayoría de nosotros, como desarrolladores, enfrentamos los desafíos de la configuración en YAML en muchas de nuestras herramientas. Quiero decir, originalmente pensé que sería, la mayoría de los desarrolladores tendrían menos de tres. Esperaba que nadie usara ninguno de ellos en absoluto, porque creo que lo vemos en todas partes, pero el hecho de que la mayoría de nuestros desarrolladores usen YAML, más de tres herramientas que tienen configuración YAML, muestra que es algo con lo que nos encontramos bastante seguido.

Absolutamente, absolutamente. Y creo, bueno, esta es mi opinión, pero también está respaldada por encuestas anteriores que realicé en Twitter, que las personas que vienen de un desarrollo front-end, particularmente, no quieren hacer ninguna configuración en absoluto. ¿Cuál es tu opinión al respecto? Sí, creo que, quiero decir, cuando comencé a desarrollar con configuración YAML, incluso cuando trabajaba en front-end y back-end, la cosa es que YAML puede ser un poco intimidante. Al principio, pensé que era como escribir un archivo JSON. Aunque, quiero decir, porque eso me resultaba familiar, aunque YAML debería ser un formato más legible para los humanos del mismo formato. Entonces, lo que sucede con YAML es que, debido a que creo que la cantidad de configuración es intimidante. Y debemos usarlos, quiero decir, cuando estoy lidiando, por ejemplo, con un archivo package JSON u otros archivos de configuración JSON, generalmente son manejados por algún script o CLI o herramienta. Pero muchos de estos YAML, los estamos codificando. Y hay tanta configuración. Es un poco como, creo, cuando hice una configuración de Webpack, si lo hiciste manualmente, es muy tedioso. Es muy difícil. Y necesitamos escribir mucha configuración en YAML para configurar nuestras canalizaciones de CI/CD, nuestros despliegues de Kubernetes. Y básicamente lo vemos en todas partes, pero en una escala mucho más grande de lo que solíamos ver al tratar con configuraciones. Al escribir aplicaciones.

Absolutamente. Y YAML es un lenguaje que tiene la fama o es conocido por causar dolores de cabeza. Si hay algún error de formato, todo se viene abajo inmediatamente. Así que sí, esa fue una pregunta muy interesante. También es muy interesante saber que la gente lo está usando en más de tres herramientas o lo que sea que tengan en su stack. Y quieren saber, hay una pregunta del público, quieren saber qué tan difícil será usar este enfoque de herramienta que estás proponiendo en despliegues que no sean de Kubernetes. Sí, básicamente los ejemplos que he mostrado en esta presentación son cómo podemos tomar este gran bloque de Kubernetes, escribirlo en un TypeScript y disfrutar de todas las buenas herramientas que tenemos de TypeScript y composición y todos los beneficios que obtenemos de un lenguaje de propósito general.

Y la cosa es que estas definiciones de tipo se generan a partir de la especificación OpenAPI de Kubernetes y en OpenAPI tenemos el formato que utiliza un JSON schema, por lo que podemos utilizar el mismo enfoque para otras configuraciones que tienen JSON schema, y la mayoría de las configuraciones lo tienen. Solo necesitamos tener estas herramientas que generan los tipos, y no será muy diferente de la herramienta que utilizo en la presentación, y probablemente haya otras herramientas que conviertan una definición de JSON schema a TypeScript, y todo lo demás es básicamente lo mismo. Por lo tanto, debería ser relativamente fácil de lograr eso. Entonces, básicamente lo que estás diciendo es que solo necesitas adaptar el esquema a las necesidades de la herramienta que estás tratando de configurar, ¿y luego es posible? Sí. Estamos conectando el esquema a TypeScript, y luego simplemente escribimos TypeScript y lo serializamos de vuelta a YAML. Sí.

De acuerdo. Y tenemos otra pregunta de la audiencia. ¿Cuáles son los desafíos de usar Deno, en general, desde tu perspectiva? Creo que uno de los desafíos es que Deno es diferente a Node en términos de API. No es compatible. No tiene compatibilidad con Node, por lo que no podemos usar modelos de Node que son muy específicos de Node. Necesitamos aprender nuevas bibliotecas estándar. Aunque Deno comparte, por diseño, está diseñado para ser similar a la API del navegador. Entonces, si somos desarrolladores frontend, nos sentiremos cómodos usando la API de Deno. Y el hecho de que sea una nueva herramienta, necesitamos un buen soporte del editor porque tiene algunas características que no usamos en la importación regular de paquetes. Estos son desafiantes, son algunos desafíos, pero se vuelve más fácil después de jugar un poco con ello y luego es realmente agradable. Absolutamente. Y esta es una pregunta que también le hice a Matias, porque estoy muy interesado en cómo los desarrolladores terminan trabajando con herramientas o configuraciones con YAML. ¿Cuál es tu experiencia? ¿Cómo terminaste trabajando o incluso fundando una startup? De acuerdo. Es como dos preguntas diferentes... quiero decir... Preguntas diferentes. ¿Cómo llegaste aquí y por qué? La primera. Sí. Básicamente me encantan las herramientas de desarrollo. En la empresa anterior en la que trabajé, utilizaba herramientas de construcción internamente y específicamente la configuración es de muchos desafíos y lidiar con muchas configuraciones complejas masivas. Y una de las razones por las que cofundé la empresa en este ámbito de herramientas de desarrollo es porque realmente amo esta área. Entonces querías facilitar las cosas para otros desarrolladores, ¿verdad? Sí. Pero son dos productos diferentes. Pero sí, definitivamente. Absolutamente. De acuerdo. Muchas gracias por la charla y por todo lo que nos has enseñado hoy. Recuerden que pueden seguir haciendo preguntas a Ishai en discord, devops-talks, charla, lo siento, dash Q&A, y que pueden unirse a este chat especial para la sala de oradores donde Ishai estará respondiendo aún más preguntas. Muchas gracias. Muchas gracias. Adiós. Adiós.