1. Introducción a Dino y YAML en Kubernetes
Voy a hablar sobre cómo podemos usar Dino para definir nuestra implementación de Kubernetes de una manera más fácil. Vamos a hablar sobre YAML y sus desafíos. Los archivos YAML de Kubernetes son enormes y complejos, lo que dificulta la escritura manual. Hoy discutiremos cómo escribir YAML de manera más fácil utilizando DNO y TypeScript. Soy cofundador de Lifecycle y mantenedor de código abierto de Tweak. Lifecycle es una herramienta de colaboración para equipos de desarrollo. También exploraremos cómo funcionan los recursos en 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.
2. Introducción a YAML y Recursos de Kubernetes
Kubernetes es vasto e impresionante. Todo se describe con YAML, lo que lo hace extensible y permite la creación de recursos personalizados. Mostraré un caso de uso ingenuo con una aplicación de Tetris y demostraré cómo ejecutarla y eliminarla. Luego, explicaré una definición ingenua de un servicio utilizando un objeto de implementación, que es más poderoso que un pod.
o un volumen, o un bucket. Es realmente vasto y es bastante impresionante. Quiero decir, realmente es uno de los puntos de venta de
Kubernetes, en mi opinión. Todo es
data, todo es recurso. Cada recurso se describe con YAML. Es extensible, por lo que podemos tener recursos personalizados, y realmente tenemos ese tipo de cosas para monitoreo, o para escalar, o para plataforma, como una compilación o cosas de
CI. Y este ecosistema de
Kubernetes es enorme, y todo se define en YAML. Así que es bastante asombroso. Voy a mostrar cómo se ven estos YAML en casos de uso muy ingenuos. Así que estaremos en la misma página de lo que estamos tratando de resolver en este tipo de YAML. Entonces, el primer ejemplo que voy a mostrar es una aplicación que es como una aplicación de Tetris. Podemos decir que tenemos la definición de
Kubernetes. Cada recurso tiene la versión del grupo de este recurso, la versión de la API se llama en
Kubernetes. El tipo, en este caso, es un pod. Un pod es simplemente unidades de cómputo que ejecutan
containers. Y si quiero ejecutarlo, estoy usando la
CLI de
Kubernetes y simplemente lo ejecuto. Tengo un clúster de
Kubernetes en funcionamiento con todos los subgrupos. Es un servidor real. Así que podemos ver estos ejemplos en vivo. Entonces, ejecuto la aplicación de Tetris. Y básicamente, ahora tenemos un contenedor que ejecuta Tetris. No es muy útil, porque quiero interactuar con él. Así que voy a eliminar esta definición. De la misma manera, en lugar de aplicar el archivo, lo estoy eliminando. Y veamos cómo suele nuevamente, una definición muy ingenua de un servicio se verá. Entonces, tengo la misma configuración de la aplicación. Pero con límites de CPU y memoria, estoy utilizando un objeto de implementación, que es un poco más poderoso que un pod, porque básicamente crea un número de pods. Por ejemplo, en este caso, son dos pods. También es como, si uno de ellos se cae, los va a revivir. También está diseñado para una estrategia de implementación gradual. Básicamente, la implementación es la
3. Definición de Servicios y Exposición de Aplicaciones
Voy a definir un servicio conectado a la misma implementación y usar Ingress para exponerlo externamente. Ejecutar y eliminar la aplicación de Tetris demuestra la complejidad de las configuraciones YAML. Una sola definición de servicio de Kubernetes puede ser enorme, especialmente para aplicaciones distribuidas nativas de la nube. A menudo se utilizan múltiples YAML en escenarios del mundo real. La capacidad de orquestación se muestra con una aplicación compleja. Trabajar con archivos YAML grandes puede ser agotador y propenso a errores. Hay muchas herramientas y soluciones para simplificar este problema, y hoy presentaré una solución única.
La forma en que normalmente definimos una aplicación. Otra cosa que voy a definir es un servicio que está conectado a la misma implementación utilizando este selector, y el servicio está diseñado para crear como un DNS y un balanceador de carga para los pods que son creados por la implementación. Así que tenemos la implementación, tenemos el servicio y lo último que necesitamos es exponerlo externamente porque quiero ejecutarlo en el navegador que no se está ejecutando en el clúster, así que voy a usar otro recurso llamado Ingress. Así que todos estos recursos son simplemente para ejecutar una aplicación y exponerla, y veamos que funciona. Así que voy a ejecutar el servicio y voy a ejecutar aquí el Tetris, y vemos que funciona. Tenemos una aplicación de Tetris aquí que se está ejecutando, y nuevamente lo voy a eliminar, y observa que esto es como líneas de código para una configuración muy ingenua. La mayoría de las configuraciones son mucho más complejas. Podemos tener volumen, escalado automático, configuración, nivel de entorno, tal vez cosas relacionadas con el monitoreo y muchas cosas más. Y esa es la idea aquí, que una sola definición de servicio de
Kubernetes puede ser enorme, y si estamos ejecutando una aplicación distribuida nativa de la nube completa, es aún más difícil. Por ejemplo, si tomo esta aplicación que es uno de los ejemplos de
Docker. Así que tenemos una aplicación de votación, una aplicación de resultados, Redis,
DB, una aplicación muy compleja para algo muy simple. Como está sobreingenierado a propósito. Aquí tendré el YAML de múltiples servicios, pero en el mundo real, probablemente serán varios YAML y no un solo archivo. Y tenemos el espacio de nombres, la implementación de la
DB, tenemos el servicio para la
DB, la implementación de Redis, el servicio de Redis, la aplicación, dos aplicaciones, una es Python, otra es
NodeJS, el .Networker, y puedes ver que tenemos muchas cosas aquí. Y nuevamente, si lo ejecuto, podemos ver que tenemos todos estos pods ejecutándose y todas estas aplicaciones. Podemos ver el voto, Redis,
DB, y también tenemos servicios y cosas así. Y también podemos verlo aquí. Así que tenemos la aplicación de votación y el resultado. Aquí podemos elegir entre gatos y perros, y puedes ver que está cambiando. Una aplicación muy compleja para algo muy simple. Pero está diseñada para mostrar la capacidad de orquestación. Simplemente lo eliminaré. Y la cosa es que este tipo de YAML era muy, muy ingenuo. Y cuando estás trabajando con estos YAML, que son tan grandes, incluso para los casos simples, puede ser agotador. Por no mencionar muy propenso a errores. Entonces, ¿puede ser más simple que esto? Sí. Y hay muchas herramientas y soluciones para este problema. Y de hecho, hay tantas herramientas porque este problema, como todos los que usan
Kubernetes, lo encuentran de una forma u otra. Y ya sea que se resuelva utilizando diferentes abstracciones o utilizando plantillas o algo así. Hay múltiples soluciones. Y hoy voy a mostrar otra que creo que tiene propiedades específicas que la hacen muy interesante y única.
4. Introducción al tiempo de ejecución de Deno
Deno es un tiempo de ejecución para JavaScript y TypeScript, similar a NodeJS pero con una sensación diferente. Es un tiempo de ejecución seguro para ambos lenguajes y no está impulsado por la API del navegador y las herramientas del ecosistema.
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í.
5. Introducción a la CLI de Deno y TypeScript
Echemos un vistazo a Deno y su CLI. Deno hace todo, desde el empaquetado hasta las pruebas. Es similar a Go y admite TypeScript de forma nativa. TypeScript es un sistema de tipos potente. Mostraré lo fácil que es escribir definiciones de Kubernetes en TypeScript. Importamos archivos de definición de Kubernetes desde URL y tenemos autocompletado y verificación de tipos. Los tipos se generan y los importamos usando URL en Deno.
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.
6. Ejecución de Ejemplo y Creación de YAML en TypeScript
Ahora voy a ejecutar este ejemplo y obtener el YAML relevante creado en TypeScript. Podemos usar variables para evitar la replicación y los errores. Se pueden crear pruebas sin necesidad de herramientas adicionales. El uso de un lenguaje de propósito general para la configuración proporciona beneficios de composición y abstracción. Crear abstracciones en TypeScript facilita la definición y el consumo de configuraciones. Kubernetes permite parchear recursos.
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
7. Creación de Servicios y Abstracciones
Estoy creando servicios y modificando sus propiedades, como el número de réplicas y la configuración de TLS. El YAML resultante es conciso y permite abstracciones de nivel superior. También estoy agregando volúmenes y utilizando 'expose' para exponer aplicaciones externamente. Este enfoque reduce el código y proporciona flexibilidad. Se pueden crear pruebas para las abstracciones de aplicaciones y se puede utilizar una API fluida para agregar y eliminar componentes. El potente sistema de tipos de TypeScript detecta errores y mejora la productividad.
. Los recursos tienen muchas más características que puedo ajustar. . Aquí estoy creando el servicio y voy a modificar el número de réplicas a tres, o cambiar el TLS del ingreso para tener un TLS basado en secretos que tienen en un clúster, o cambiar el nombre de host. Nuevamente, después, solo estoy imprimiendo este YAML y si ejecuto este ejemplo, tendremos la misma definición de YAML y se vuelve mucho más útil en el momento en que intentamos crear múltiples servicios. Aquí está el ejemplo que vimos antes con los grandes YAML, pero con casi cuatro veces menos código. Y lo más importante, no es solo el número de líneas de código que tenemos aquí, sino lo concisas que son. Solo estamos especificando las cosas que queremos y podemos hablar de una abstracción de nivel superior. Entonces, estoy creando un ASPACE, estoy creando la aplicación
DB. Aquí hay un ejemplo en el que agrego el volumen, por lo que no es parte del contrato de la aplicación, pero nuevamente, puedo modificarlo después. Lo mismo ocurre con Redis, tenemos la aplicación de votación que estoy exponiendo para exponerla externamente. Lo mismo ocurre con la aplicación de resultados, porque son dos aplicaciones diferentes y el trabajo solo está ejecutando la imagen de
Docker. Entonces, es menos cantidad de código y aún así, tenemos la misma flexibilidad porque siempre podemos cambiar estas propiedades y también podemos hacer algunas lógicas. Es decir, en función de algunas propiedades en un objeto, queremos derivar el valor correcto para otras propiedades también. Entonces, también puede haber, como, menos puntos de error. Para esta abstracción de aplicación, también creo pruebas. Eso también podemos crear objetos reutilizables que sean testables y que todos puedan usar. Otro ejemplo es crear una API más fluida, como la API de aplicación que creé. Entonces, aquí es, como, más funcional. Podemos agregar y eliminar cosas. Es como una API fluida. Y lo interesante de este ejemplo es lo poderoso que es el sistema de tipos de
TypeScript. Entonces, puedes notar que si elimino el servicio de agregar aquí, ya no tenemos la opción de 'expose'. Entonces, no funcionará. Y porque no tenemos 'expose', tampoco tenemos el ingreso. Y si agrego el servicio, aún no tenemos el ingreso. Solo tendré un servicio. Para tener el objeto de ingreso, necesito exponerlo. Entonces, básicamente, me protege de cometer errores. Por ejemplo, olvidar hacer algo o... quiero decir, el sistema de tipos puede detectar muchos de estos errores. Y también, no solo es bueno para los errores, también es bueno para darme una buena y completa
8. Creación de un Plan de Servicio y Flexibilidad
Creé un plan de servicio llamado monitor, tomado del proyecto Prometheus, que permite a otros desarrolladores configurar y monitorear fácilmente sus servicios en Kubernetes. Este plan proporciona flexibilidad para que los desarrolladores personalicen sus implementaciones mientras utilizan recursos predefinidos.
Para ser más productivo, utilizo características que me permiten crear, como una especie de plan. Pero es muy similar. Entonces, creé un plan de servicio llamado monitor que simplemente realiza toda esta configuración. Y también, en este caso, es un recurso personalizado llamado monitor que se toma de un proyecto llamado Prometheus. Entonces, aquí estamos utilizando un monitor de servicio que monitorea mi servicio. Porque, nuevamente, el recurso de
Kubernetes puede ser de todo, especialmente si vamos a utilizar recursos personalizados. Los recursos personalizados también se generan aquí. Entonces, he generado los recursos para el proyecto Prometheus. Y así, también puedo usarlos aquí. Y sí, este plan de servicio es algo que puedo dar a otros desarrolladores y ellos pueden usarlo. Algo así como que el equipo de plataforma puede construir y luego otros desarrolladores pueden usarlo y consumirlo. Pero lo bueno es que aún tienen flexibilidad para cambiar estas propiedades después. Entonces, nuevamente, si quieren definir su implementación, algo aquí que quieran cambiar, pueden hacerlo. Y eso es como
9. Ejecución de un Archivo Malicioso en el Entorno Seguro de Deno
Voy a mostrar un ejemplo de cómo se ejecuta un archivo malicioso en Deno y cómo falla debido al entorno seguro. Por defecto, Deno restringe el acceso a las variables de entorno, sistemas de archivos y redes. Ejecutar el archivo malicioso sin permisos resulta en un error de permiso denegado. Sin embargo, al ejecutarlo con la bandera allow env se otorga acceso a las variables de entorno.
Es bueno tener esta flexibilidad. Y los dos últimos ejemplos que voy a mostrar son cosas muy interesantes en
Deno y en
TypeScript. El primero es que voy a mostrar un ejemplo. Estás viendo que siempre están importando módulos desde URLs. Y te preguntas qué pasaría si esta URL fuera algo como veneno o malicioso. Así que voy a ejecutar este ejemplo, que aquí tenemos un archivo malicioso. Y vemos que va a fallar. Y la razón es porque por defecto se ejecuta en un entorno seguro. Cuando hago run, por defecto, el archivo
TypeScript no tiene acceso a las variables de entorno, al sistema de archivos ni a la red. Y este ejemplo, esta utilidad maliciosa está obteniendo mi variable de entorno, robando mis credenciales SSH y enviándolas a un servicio malicioso. Si lo ejecuto con allow env, podemos ver que se produce un error de permiso denegado, requiere y accede a ejecutar nuevamente con allow env.
10. Limitando el Acceso y Uso en Sistemas CI
Puedo limitar la carpeta de lectura a la que Deno tiene acceso y restringir el acceso a la red a la API GitHub.com. Esto evita que los scripts roben variables de entorno o lean archivos del sistema de archivos. Es una característica útil para aplicaciones como los sistemas CI.
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
11. El Poder de la Escritura en Deno
En esta sección, demuestro el poder de la escritura en Deno. Al importar recursos y aprovechar el sistema de tipos de TypeScript, podemos modificar fácilmente objetos de Kubernetes. Podemos usarlo para parchear, validar y más. Las herramientas en Deno son simples pero poderosas, requieren un código mínimo y proporcionan autocompletado y corrección. Elimina la necesidad de configuración del proyecto y dependencias externas. Aunque no es perfecto, Deno ofrece características de composición, composición declarativa, parámetros, abstracción, superposiciones y capacidades de parcheo. Es una herramienta versátil para trabajar con Kubernetes.
en sistemas
CI. Otra cosa que es muy interesante es el poder de la tarea de escritura. En este caso, voy a mostrar un ejemplo de cómo modificar un archivo existente. Entonces, si tomamos el archivo
kubernetes que recuerdas de mi ejemplo anterior. Aquí tengo un despliegue con réplicas también y lo voy a ejecutar en el tubo que va a cambiarlo y podemos ver que tenemos como tres réplicas y si miramos el código aquí.
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.
12. Beneficios de Usar Reno para la Configuración
Busco corrección, seguridad de tipos, capacidad de prueba y facilidad para compartir código. Busco un lenguaje amigable para los desarrolladores con un mínimo de código repetitivo. La seguridad es importante y Reno se compara bien con herramientas populares como Elm Customize. El uso de un lenguaje de programación de propósito general para la configuración tiene muchos beneficios, y Reno ofrece ventajas específicas como la falta de dependencias, soporte para TypeScript y un buen ecosistema. La generación de código proviene de una herramienta de código abierto creada en Lifecycle.
Encontré este ejemplo. Busco corrección. Busco seguridad de tipos. Busco capacidad de prueba. Busco compartir código para que sea fácil importar otras abstracciones o configuraciones o compartir mi configuración con otros. Quiero que sea amigable para los desarrolladores, como un buen lenguaje de programación conocido, con soporte para IDE. Mínimo código repetitivo. No quiero tener que configurar un proyecto para definir mi archivo, como hacer esta implementación. Quiero algo muy, muy mínimo.
Y también está la seguridad. No quiero tener algo que ponga en riesgo mi proceso de
CI/
CD. Creo que Reno no es malo en este tipo de métricas. Lo comparé con Elm Customize. Por supuesto, no es preciso, pero Elm Customize es una herramienta muy popular en el ecosistema de
Kubernetes. Creo que Reno puede obtener muchas de estas capacidades de una manera muy buena. En resumen, en primer lugar, creo que hay muchos beneficios en el uso de un lenguaje de programación de propósito general para la configuración. Ya se ha hecho antes. Pulumi lo hace muy bien. Probablemente sean los pioneros de este enfoque. Y tenemos el
AWS CDK y CDK4JS, y JKCFG, todos hacen algo similar, o en realidad algo mucho más poderoso. Pero creo que Reno tiene beneficios específicos. No hay dependencias, no hay código repetitivo. Obtenemos
TypeScript de forma nativa. Es fácil de usar. Muy buen ecosistema. Buena y flexible seguridad. Y la generación de código que importé proviene de una pequeña biblioteca de código abierto que creamos en Lifecycle. Es una herramienta. Se puede integrar fácilmente con otras herramientas. Es de código abierto. Eres más que bienvenido a
13. Simplificando la Configuración YAML y sus Desafíos
Este enfoque no es solo para Kubernetes, sino que se puede aplicar a otros sistemas de configuración complejos. El objetivo es simplificar los archivos de configuración. Una encuesta mostró que los desarrolladores se encuentran con la configuración YAML en muchas herramientas. YAML puede resultar intimidante debido a la cantidad de configuración requerida. Es tedioso y difícil escribir YAML para canalizaciones de CI/CD y despliegues de Kubernetes. YAML es conocido por causar dolores de cabeza si no está bien formateado. La audiencia está interesada en utilizar este enfoque para despliegues que no sean de Kubernetes y el orador explica cómo se puede hacer.
échale un vistazo. Está en una etapa muy temprana, obviamente. Y creo que este enfoque no es necesariamente solo para
Kubernetes. También se puede aplicar a otros sistemas de configuración complejos. Y el punto de esta charla es que todo esto fue un experimento. Pero el objetivo final es que nuestros archivos de configuración sean mucho más simples. Pueden y deben serlo. Muchas gracias.
¿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.
14. Usando OpenAPI y Desafíos de Deno
Estas definiciones de tipo se generan a partir de la especificación OpenAPI de Kubernetes y se pueden utilizar para otras configuraciones con JSON schema. Deno tiene desafíos en cuanto a la compatibilidad de API con Node y requiere aprender nuevas bibliotecas estándar. El soporte del editor es crucial. La experiencia del orador en herramientas de desarrollo y manejo de configuraciones complejas llevó a cofundar una empresa en este ámbito.
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.
JSNation Live 2021
Comments