 buenas noches a todos los que nos están acompañando hoy de nuevo OpenShift Commons en vivo. Yo soy María Baratso y conmigo está Scott McCarty y nuestro invitado Carlos Camacho. Carlos, ¿nos cuentas de qué vamos a hablar hoy en OpenShift Commons en vivo? Sí, por supuesto. Bueno, muchas gracias por haberme invitado. Mi nombre es Carlos Camacho. Trabajo en Red Hat como desarrollador de software y bueno, yo en principio no trabajo con OpenShift, tampoco trabajo con Kubernetes, pero soy parte de la comunidad de desarrollo de OpenStack, que es uno de los productos que nosotros también con los que también trabajamos. Y la charla de hoy era bueno para mostrarle un poco a las personas que están más acostumbrados al desarrollo de OpenShift y de Kubernetes, pues como podemos aprovechar las buenas prácticas de nuestro trabajo en OpenStack para facilitar el despliegue, por ejemplo, en este caso de origin, pero podemos desplegar cualquier otra distribución de Kubernetes utilizando el mismo método. Entonces, vamos a hablar hoy. Y una pregunta, Carlos. Vale. Hola, siento María. Sólo quería preguntar, Kubernetes no está utilizado, por ejemplo, en OpenShift, ¿sí o no? No, una de las cosas con las que yo estoy trabajando ahora mismo es con la gente de Submariner.io para montar el entorno de integración contima utilizando Kubernetes. ¿Qué sucede? Las personas suelen habituarse mucho a una única distribución de Kubernetes, pero por ejemplo, Submariner tenemos personas directas desarrollándolo, pero también hay gente, por ejemplo, de Rancher y el entorno de integración continua ahora mismo está solo basado en OpenShift. Y la idea es extenderlo para poder aumentar el escopo del entorno de integración continua para que funcione con otras distribuciones de Kubernetes. Vamos a hablar un poco más de estos, Carlos, pero cuando yo conversé con Carlos sobre esto, creo que tenía más o menos la misma pregunta que tú te estabas haciendo. O sea, ¿cómo se relaciona Kubernetes con, por ejemplo, el installer de OpenShift? Pero ya vas a ver que Kubernetes llama al installer. En realidad, Kubernetes no es otra manera de desplegar completamente separada de OpenShift, sino que simplemente llama al installer. Ya lo vamos a ver. Bueno, la actitud de la presentación es Kubernetes, buenas prácticas del ecosistema de OpenStack para mejorar la manera de desplegar origin o OpenShift. ¿Quién soy yo? Una presentación super rápida, trabajo en Red Hat, trabajo como desarrollador de software, soy contribuidor dentro de la comunidad OpenStack y llevo ya un par de años investigando el ecosistema de Kubernetes y de qué manera puedo, con el trabajo que llevo, contribuir a Kubernetes. Cuatro enlaces, mi blog angstack.com y soy secamacho en IRC, en el Slack de Kubernetes o en GitHub, por si tienen alguna pregunta más adelante. Y esto es importante porque Carlos pueden comunicarse con él directamente, pero obviamente con nosotros. Y la otra cosa, Carlos, es que los dos somos venezolanos, así que la otra vez hablamos sobre de dónde vienen todos los acentos. Exactamente. Bueno, ahora les voy a hablar una pequeña introducción sobre el proyecto y de dónde surge. Siguiente slide, porfa. En principio, Kubernetes lo único que es es una colección de Ansible. Una colección de Ansible que provee playbooks y roles para desplegar y configurar múltiples distribuciones de cornetes. ¿Por qué? Porque cada distribución tiene su método de instalación particular. Por ejemplo, nosotros utilizamos el Installer de OpenShift o de Origin. Tenemos que desplegar un bootstrap node, de allí desplegamos los otros distintos nudos, pero existen distintos pasos previos a ese despliegue. Por ejemplo, tenemos que montar el servicio de DNS o tenemos que montar una HAProxy para poder balancear la carga a nuestro cluster de Origin. Eso es lo que, en principio, facilita a Kubernetes. Todos esos pasos previos a ejecutar el instalador. Por ejemplo, ahora mismo funciona también Canonical. El instalador de Canonical es Huju. No importa, nosotros montamos el servicio de DNS HAProxy. Le voy a llamar a Huju para hacer el despliegue. Así con otras distribuciones de las cuales les voy a hablar un poquito más adelante. La meta de Kubernetes es tener una manera automatizada para desplegar con un único comando una serie de arquitecturas previamente establecidas. Y, por supuesto, utilizando algunas de las mejores prácticas del ecosistema de OpenStack, que es donde yo suelo trabajar en mi día a día. Para todas las personas que nunca han escuchado hablar de OpenStack, OpenStack es un software de código abierto que permite la gestión de recursos en la nube. Por ejemplo, servicios de cópito, de almacenamiento y redes utilizando APIs previamente definidas. En principio, dentro de la comunidad de OpenStack, nosotros hemos cometido muchísimos errores, como en todos los proyectos grandes de software. Pero la idea es coger esas cosas buenas y reutilizarlas porque tienen, desde mi punto de vista, pues bastante valor. Aquí hablamos de desplegar OKD y OpenShift también. Pero en realidad, Kubernetes es un poco agnóstico al tipo de distribución del que estamos hablando, ¿verdad? O sea, ¿has probado Kubernetes con otras distribuciones que no sean OpenShift, OKD? ¿Hablaste de Canonical? ¡Pujo! Sí, exacto. ¿Hablaste de otra? Ahora mismo he integrado cuatro distribuciones de Kubernetes que son las más utilizadas, según mi punto de vista. Es algo bastante opinionado. Podemos desplegar vanilla Kubernetes. OpenShift, como tal, no el proyecto estaba usado en distribuciones upstream. No despliego OpenShift, pero despliego OKD. También despliego Rancher Kubernetes Engine y Canonical Distribution of Kubernetes. Son las cuatro distribuciones que ahora mismo cualquier persona podría desplegar. Y cuando hablas sobre mejores prácticas, vas a hablar eso un poco más, pero estamos hablando también de automatización. O sea, una de las cosas que estás buscando es rapidez de despliegue, poder repetir tipos de test, etc. ¿Verdad? Si, en principio, los despliegues general de Kubernetes suelen ser complejos, suelen ser complejos. Y la curva de aprendizaje para todas las personas que quieran comenzar a utilizar esta tecnología suele ser un poco traumática al principio. Hay muchísima documentación, el ciclo de desarrollo de software es muy corto, hay muchos cambios muy rápidos y es difícil para una persona mantenerse al tanto de la documentación. La idea de Kubernetes es que con un único comando, ahora se los voy a mostrar en la demo, puedan tener un entorno para aprender cómo funciona. No es lo mismo tener un entorno funcionando y aprender cómo funciona a tener que leer 100 páginas de documentación y encontrar errores o enfrentar errores antes de tener el hecho. La idea es eliminar esa frustración antes de poder tener el cluster instalado. Y me parece que la filosofía es más como usarlo en vez de documentación es mejor tener código, como código de Ansible o algo así más o menos. Exactamente, la idea es que el proyecto genere la documentación en vivo. Más adelante les voy a mostrar que, por ejemplo, la documentación del proyecto se genera desde el mismo código. Entonces, si una persona hace un cambio y ese cambio tiene documentación dentro del código, la documentación va a estar siempre actualizada. Entonces, bueno, la idea es que las personas no necesiten documentación. Eso sería lo ideal, pero en caso de que quieran leerla, que esté lo más actualizada posible. ¿Quién es sentido? Bueno, chicos, ¿por qué el proyecto? En principio, yo he estado trabajando en otros proyectos que tienen un ámbito más de investigación. Y bueno, tuve la necesidad de definir un mecanismo determinístico que me permitiera desplegar el mismo cluster de Kubernetes, en este caso particular de Origin. A lo mejor unas 150, 200 veces. Imagínense el trabajo de tener que instalar el mismo cluster 200 veces a mano, siguiendo la documentación. No escala, es algo bastante complejo de hacer, sobre todo por el tiempo que tomaría. Entonces, bueno, en este caso, Kubernetes surge de la necesidad de demostrar la validez de un experimento científico, porque nosotros tenemos que demostrar la reproducibilidad de los resultados que queremos publicar. Esto se hace de una manera que nosotros podamos repetir el experimento un cierto número de veces para garantizar que el intervalo de confianza de nuestros resultados está dentro de un rango determinado. Siente slide, por favor. Bueno, cuando surge esto, a partir de junio del 2018 para un proyecto de investigación que se llama PyStoL. PyStoL es un framework para ejecutar pruebas de chaos engineering en clusters de Kubernetes. Estaba en el review desde hace ya bastantes meses, y espero que bueno, que si hay suerte este año se pueda publicar. Siente slide, por favor. Eso. Sería bonito publicar en la tributación. Muchas personas me preguntaron por el logotipo. Hace un par de años, tuve una época donde vi muchos capítulos de una serie animada que se llama Dragon Ball Z. Y bueno, el logo de Kubernetes hace algo de analogía a algo que hacían en esta serie que se llama Kame Kamea o aquí en España es Honda Vital. Si se trata de una serie animada que se llama Kame Kamea o aquí en España es Honda Vital. Si se dan cuenta es como una especie de cubo con dos bracitos reuniendo energía en el mismo punto. La idea es que bueno, que podamos liberar toda esa energía como un único comando para tener nuestro cluster de Kubernetes desplegado. Ahora mismo, la idea de la presentación es que en tiempo real yo voy a lanzar una demo del cluster de Kubernetes y cuando termine el despliegue volvemos a ver la terminal y les muestro el cluster. María, siguiente slide, porfa. Vale, como pueden ver en principio son únicamente dos pasos. Clonar el repositorio de Kubernetes que está en GitHub y ejecutar un playbook. Si se dan cuenta el playbook que es súper sencillo es simplemente decir Ansible Playbook y ejecutar el playbook como root le pasamos un archivo con el inventario que es simplemente la descripción de las máquinas que vamos a desplegar en un hypervisor y el playbook que vamos a ejecutar que básicamente si se dan cuenta es OKID va a ser distinto dependiendo de la distribución. Si quieres desplegar Kubernetes pues en vez de OKID va a ser K8S y así con las otras dos distribuciones. Entonces, voy a compartir mi pantalla rápidamente y voy a ejecutar el playbook. María, te robo la pantalla. Vale, adelante. Después volvemos a... Vale Perfecto, ¿pueden ver la pantalla? Sí, está súper. Perfecto. Entonces en principio este es el servidor donde vamos a ejecutar el playbook simplemente esclonado el repositorio de Kubernetes aquí pueden ver la estructura básica del repositorio y lo que vamos a ejecutar es un comando que es Ansible Playbook menos menos user root le pasamos el inventario y el playbook que vamos a ejecutar que depende de la distribución que queremos a desplegar. Pues ese en principio es lo único que tenemos que hacer es se llena un cuenta Está en GitHub, tú lo editas en GitHub y mantienes los cambios en GitHub y lo llamas con ese comando que acabas de hacer, ¿cierto? Claro, sí, sí, en principio Cameja, meja es el comando que acabas de hacer. Claro, exactamente. La idea es que el usuario o la persona que quiera comenzar a trabajar con esto no tenga la necesidad de hacer ningún cambio. En principio, el inventario está definido de tal manera que no hay que hacer cambios. Una vez que tú tienes un servidor con los recursos necesarios para desplegarlo, lo puedes desplegar ves que funciona y si necesitas hacer a posterior y hay algún cambio, lo hagas pero no antes. La idea es que con este comando puedas tener el entorno desplegado. Entonces, bueno, ¿podemos dejar, sí? Tengo dos preguntas. Yo vi un Dockerfile ahí y ¿por qué es eso? Vale, ese Dockerfile es porque si se dieron cuenta yo ejecute directamente el comando que ejecute el Playbook directamente desde el servidor. ¿Qué pasa? Esto es una máquina que yo sé que tiene todas las dependencias para poder ejecutar el Playbook. Por ejemplo, si tú tienes un portátil y no tienes Ansible instalado no vas a poder ejecutar el Playbook. Entonces, esas son cosas que sí están en la documentación. Puedes lanzar el Playbook desde un contenedor. Un contenedor que tiene todas las dependencias necesarias para poder ejecutar el Playbook. Es básicamente la idea de ese Dockerfile. Si una persona llega con un portátil, por ejemplo o con un Mac y no tienes las dependencias necesarias, es simplemente para descargar la imagen del contenedor y montar una carpetita donde está el repositorio y lanzar el Playbook. Y en este caso, sí, ¿quieren ver cómo se hace? Sí, claro. Pero la idea es que no dependas de las dependencias del ordenador o del portátil que estás utilizando para poder lanzar el Playbook. Bien, eso tiene razón. Y una otra pregunta ¿Cómo se pega la versión de OkD con este Playbook, por ejemplo? Solo veo un Playbook que se llama OkD y te cambia, me imagino que está fuera de sincronización con... a veces puede ser fuera de sincronización con la versión que quiero utilizar, por ejemplo. Claro, en este caso ahora mismo solamente estoy utilizando la última versión del instalador de OkD para poder desplegar. Pero es algo que se podría cambiar muy, muy, muy fácilmente, se podría extender. ¿Por qué? Porque la variable que define qué versión se va a desplegar está dentro el Role de OkD. Entonces, en este caso y tú no configuras tu Playbook, vas a desplegar lo que sea que tenga el archivo que tiene las variables por defecto. Pero tú podrías sobre escribir esa variable y cambiar el instalador para usar uno más nuevo o uno anterior. En principio es configurable. Pero por defecto siempre es Latest. Latest, perfecto, esto es bueno. Sí, perfecto, esto es bueno. Pero podrías hacerlo si tienes una versión local con otra distribución? Claro, de las cuatro distribuciones que ahora mismo soporta te puede desplegar out of the box Latest, sin hacer ningún cambio. Quieres desplegar distintas versiones tienes que cambiar el archivo que tiene las variables por defecto donde está definida esa versión que se va a instalar. ¿Qué sucede? Todos los nodos se descargan las imágenes de los contenedores en principio de donde esté definido en el instalador. Lo ideal sería extenderlo para tener un local registry de tal manera de que todas las máquinas del cluster se las descarguen del mismo local. Ahora mismo es una feature que me gustaría implementar eventualmente. Rápido, recap del todo lo que acabamos de ver, porque vi que generamos redes, Startup Networks, Gracias VMs y eso es un montón de cosas. ¿Qué pasó? Vale, ahora eso lo voy a explicar un poquito más adelante porque vamos a hacer una tip dive. Entonces, si puedes volver a compartir los slides les voy a mostrar en principio la arquitectura de la aplicación y cómo funciona. Perfecto, entonces Vale Bueno yendo un poquito más atrás les voy a hablar de la motivación para la arquitectura de Kubernetes. Les voy a hablar de dónde está sacada más o menos la idea y luego les voy a mostrar cómo se configuran las redes, cómo se configuran los nodos de cada distribución. Bueno, en principio la idea de esto es reutilizar piezas del ecosistema de BenStack. Entonces hay a cinco repositorios principales de donde si se dan cuenta y miran el código van a ver que hay varias similitudes. Tenemos primero a Triplo Ansible y OpenStack Ansible, donde la arquitectura por ejemplo de cómo se genera la documentación es exactamente la misma. La documentación del proyecto se genera con Sphinx, que es el sistema de documentación por defecto de OpenStack. Si ven la estructura de cómo se organizan los roles y cómo están distribuidos dentro de la colección van a ver que es muy similar. La idea cuál es, por ejemplo nosotros instalamos el servicio de DNS pero ese servicio de DNS es independiente de la distribución que nosotros vayamos a instalar. Entonces la idea está en un rol que despliegue el servicio de DNS y otro rol que despliegue el servicio de HAProxy. Otro rol que despliegue por ejemplo una distribución de Kubernetes en particular y por ejemplo otro rol que despliegue por ejemplo el servicio de NFS, si lo necesitamos la distribución que vayamos a despliegar. De Triplo Upgrade el soporte de los tests de molecule si se dan cuenta la estructura es bastante similar dentro de QVinit hay test unitarios test funcionales test test end to end pruebas de molecule hay linters hay muchísimas pruebas que bueno que de alguna manera si ven la estructura es muy similar a lo que hacemos en Triplo Upgrade de OS Migrate OS Migrate es un proyecto para hacer workload migrations entre distintos tenants de OpenStack si se dan cuenta la estructura de los linters de los test unitarios y de lo que es el sistema de integración continua es muy similar y de Triplo Validations pues básicamente la estructura de un rol que nos permite ejecutar validaciones pre despliegue y pos despliegue. Estos son digamos los las prácticas, las buenas prácticas del ecosistema de OpenStack y que nacen de proyectos que están dedicados a hacer upgrades in place y entonces para hacer upgrades tu necesitas obviamente desplegar chequear que todo está subiendo de acuerdo y para luego poder seguir con siguientes pasos cuando tienes un upgrade grande digamos si te pelas en un paso al principio pues todo viene cayendo en secuencia así que toda esta manera de hacer test y automatizar el hacer test y volver a despliegar el despliegue para mi tiene mucho sentido que lo estemos haciendo con este tipo de proyectos porque pues vengo de ese lado pero de repente Scott tiene más preguntas sobre exactamente qué es lo que utilizan. La idea es que nosotros hemos invertido muchísimo tiempo en diseñar cómo se van a ejecutar los test de ModelQL, cómo se ejecutan los test unitarios y que no reutilizar todo ese valor que ya hemos generado para algo nuevo es básicamente la idea principal de esto. Bueno aquí les voy a mostrar un poquito la arquitectura de cómo está organizado Qbinit, si se dan cuenta cada barra vertical es un rol distinto, tenemos un rol que se llama bind, otro rol que se llama HAProxy, otro rol que se llama NFS, otro rol que se llama Apache web service free IPA para desplegar Qbinit asesorciosivamente con todos los servicios que nosotros querramos desplegar. ¿Por qué? Porque esos servicios no están attach no están juntos a ninguna distribución de cobernetes son servicios independientes por lo cual no tiene sentido que nosotros tengamos una arquitectura monolítica si lo que queremos es poder reutilizar los componentes para qué para garantizar que la cobertura de las pruebas de cada uno de esos componentes es mayor es decir, no es lo mismo integrar bind en cada distribución de cobernetes por separado que tener un único módulo de bind y reutilizarlo en todas las distintas distribuciones de cobernetes se aprovechan mucho más del código y es mucho más fácil de mantener. Luego tenemos otra capa que aunque sea una barra horizontal que dice cobernetes distribution es un rol más lo único es que es el rol lo que hace es llamar a otros roles que instalan o desplegan o servicios adicionales y debajo de la distribución de cobernetes pues tenemos un rol más que es el driver de infraestructura que nosotros vamos a utilizar para desplegar ahora mismo sólo despliego en LibVirt ¿Por qué? Porque es lo único a lo que tengo acceso idealmente tú podrías utilizar esto para desplegarlo en Amazon Web Services o en cualquier otra nube pública pero de verdad eso es lo más popular LibVirt en todo el mundo en que en Amazon Web Services no, no, LibVirt LibVirt porque por ejemplo lo máximo que me preguntan los clientes es ¿Puedo instalar OpenShift en LibVirt? Solo quiero usar KBM más o menos y eso es difícil porque no quieren utilizar CRC a veces sólo quieren utilizar exactamente lo que vamos a instalar en un servidor más o menos y quieren practicar con administrarlo y todo eso y yo creo que eso está bien pero es esto también claro la idea es esa por ejemplo en mi caso yo no tengo acceso a ningún proveedor de cloud pública, no lo tengo y es muy caro claro que tiene un footprint que me permite desplegar ciertas configuraciones desde 32 gigas de RAM hasta 250 gigas de RAM puedes desplegar lo que tú quieras y tienes pocos recursos pues ajusta los parámetros de la distribución a algo que funcione y a medida que tengas más recursos pues puedes desplegar más nudos o pueden tener más disco más RAM o como como tú quieras en principio del hipervisor con LibVirt soportamos Centro Fedora de Bian y Ubuntu ¿Qué sucede? Yo solo trabajo solo con Centros pero una persona me dijo estoy intentando lanzar TubeVirt pero en mi pervisores claro que falla porque los paquetinos se llaman igual no tenía nada que ver entonces dije pues bueno en principio es bastante sencillo y ahora soportamos Centro Fedora de Bian y Ubuntu como hipervisor solo trabajo con LibVirt porque es algo que tengo acceso y que yo haya probado que otras personas me hayan dado feedback OKG y vanilla Kubernetes pero ahora mismo estoy trabajando con gente de Submariner.io para integrar Rancher en pruebas de integración continua con OpenShift o OKD ahí bueno lo que les decía antes los servicios externos que tenemos son Bind, HEProxy Apache Web Servers o el rol que hacen las validaciones Tintes Light por favor la documentación como les comentaba anteriormente la documentación se genera todo utilizando en Sphinx que es el sistema de documentación por defecto en todos los proyectos de OpenStack en principio la documentación de Kubernetes la basada en un theme que se llama ReadDocs se renderiza automáticamente cada vez que hacemos un launch de cualquier commit en el repositorio y está integrada en GitHub Actions en principio como esto es un proyecto que no tiene recursos asignados per se no tengo ningún sitio donde yo pueda ejecutar por ejemplo las pruebas de integración continua una de las cosas muy muy buenas que tiene GitHub es que para todos los proyectos que están abiertos es utilizar la seguida de ellos indiscriminadamente con lo cual permite que la calidad del código sea bastante mejor como se ejecutan los roles bueno que habiendo que ejecutar un rol es bastante sencillo que sucede imaginaros que ahora quieren crear un rol nuevo llega por ejemplo Scott o María y dicen oye Carlos yo he estado trabajando con Free IPA y veo que no estoy integrado quiero agregar un rol nuevo y yo te digo no pasa nada porque la recomendación está cómo generar un rol nuevo automáticamente utilizando un playbook de Ansible que se llama role addition.jaml si te ejecutas ese playbook te va a generar todo el skeleton para que tú puedas integrar tu servicio de manera automatizada por defecto pues los archivos con las variables por defecto a donde vas a dejar las tareas te deja un test de molecule funcionando porque tú puedes tener una referencia de cómo funciona el mecanismo para ejecutar los test de molecule y adaptarlos al funcionamiento de tu rol y bueno, automáticamente ese rol que estás creando se agrega automáticamente al módulo de XFINX que genera la documentación automáticamente que está todo integrado la integración continua bueno, la integración continua como les comentaba anteriormente está basada en github actions todos los jobs de la CI se ejecutan en github hay linters que verifican el estilo del código hay test unitarios que verifican los módulos de Python dentro de la colección de Ansible hay pruebas end to end de las que les voy a hablar más adelante y bueno, tenemos test de molecule y el job que prueba la documentación se puede generar automáticamente todos estos jobs reportan cada vez que uno envía un pull request al status del pull request y en principio si todos los jobs pasan se puede hacer el merge del código sin ningún problema siguiente slide por favor bueno, lo que les comentaba antes de un resumen la CI estaba basada en github actions se ejecuta dependiendo de si hay un push o un pull request en principio se obtienen resultados en 2-4 minutos dependiendo del job que se va a ejecutar y está todo el código cubierto si entes slide por favor vale, ahora pruebas end to end, yo les venía hablando de que en principio podemos desplegar OKD vanilla governance rancher o la distribución de canonical github actions por cada job que uno lanza se quiere una máquina virtual donde puedes ejecutar tus pruebas, pero los recursos de esa máquina virtual footprint es limitado es decir, que yo no puedo lanzar un cluster de 8 máquinas en esa máquina virtual porque simplemente no tiene recursos y no fallar github recomienda no utilizar hosted runners tu propia infraestructura en aquellos repositorios públicos ¿por qué? porque ellos no pueden garantizar que venga una persona y te ejecute código malicioso en tu infraestructura interna entonces eso es algo que es así, no se puede cambiar hasta nuevo aviso ¿qué sucede? yo tenía la necesidad de poder ejecutar pruebas end to end con hardware, con footprint que es algo más grande para poder desplegar las distribuciones de Kubernetes entonces, las pruebas de integración end to end no están basadas en github actions están basadas en una instancia local de gitlab que ejecuta las pruebas en un entorno externo y lo único que hace es reportar de vuelta el resultado de un pull request basado en un tag que una persona con privilegio de administración dentro del repositorio puede agregar esos tags es decir, si ustedes mandan un pull request vengo yo y digo agrego un tag que se llama app o execute end to end okd automáticamente el job que se está ejecutando en github se da cuenta de que hay un tag que fue agregado por una persona con privilegio de administración y ejecuta el job y devuelve los resultados a ese pull request de esa manera garantizamos que no vamos a tener a nadie ejecutando código malicioso dentro de nuestra infraestructura local y de igual manera le damos visibilidad a esos jobs end to end para que reporten en los pull requests públicos existen ah, espera un punto de hacia atrás en dos scripts se llama launch end to end.py que es la integración de python con el app de github que simplemente ejecuta el script que se llama round.sh hay un check que verifica los tags cada 10 minutos y si el runner encuentra el tag va a configurar el job ejecutar el job y escribir los resultados de pull las validaciones son especialmente importantes para ayudar a los usuarios que están comenzando a utilizar estas tecnologías porque por ejemplo he tenido personas que me han preguntado oye funciona el playbook y no les funcionaba porque por ejemplo no tenían espacio en disco suficiente o no tenían memoria round suficiente en el intervisor para poderle explicar al cluster entonces fallaba eso es algo que está parcialmente resuelto con una serie de validaciones antes del display que si el intervisor cumple con los requisitos mínimos que esos requisitos están definidos dentro del inventario pues simplemente la persona no puede listo se verifican cosas como ram disco o que existan los paquetes o que los paquetes estén por ejemplo instalados correctamente en el intervisor listo, siguiente slide ahora les voy a contar un poco es una deep type pero es bastante breve les voy a hablar sobre la arquitectura de red del despliegue básico de cómo se configura el servicio de DNS y cómo se configura el servicio de HEProxy que son los servicios básicos para poder desplegar el cluster como pueden ver aquí tenemos cuatro roles yo esta explicación o esta parte esta basa en okd porque es lo que suelo desplegar habitualmente en principio creamos una red virtual con NAT cuyo identificador es la 10.0.0 barra 24 y ahí vamos a colocar todas nuestras máquinas en este caso tenemos cuatro tipos de máquinas tenemos bootstrap node el service node es una máquina especial donde vamos a instalar Apache, bind y HEProxy y luego tenemos los workers y los master nodes recuerden que un cluster en principio de Kubernetes en general puede tener un único servidor una única máquina un único master node puede tener tres o puede tener cinco si queremos hacha o no por el cluster de tcd que va a estar funcionando ahí dentro y luego los worker nodes podemos tener de 0 a n en principio si nosotros no desplegamos ningún worker node los master nodes van a procesar user workloads esa red que nosotros creamos pues tiene por defecto de HCP como tiene de HCP nosotros las direcciones MAC de todos esos nodes las registramos dentro del servidor de HCP de esa red virtual que creamos dentro de LeadBird y le asignan por de HCP la dirección IP que nosotros escojamos en este caso la 0 la 1, 2 y 3 para los tres primeros master nodes de la 4 yo creo que tengo puestas en el inventario las primeras 20 de la 4 a la 20 para worker nodes para service nodes que ya tienes desde 4 a 99 bastantes worker nodes para un cluster de pruebas y como sólo se utiliza al momento de instalar el bootstrap node tiene la dirección IP 0.200 dentro del rango 10, 0, 0, 0, barra 24 como ponen todos estos assignments todos estos assignments están ya digamos pre en el config que tienes en GitHub ahora como parte de claro que sucede todos estos pasos son previos al despliegue de okd nadie te va a decir a ti como debes configurar tu el DHCP para desplegar los nodes este trabajo es lo que nosotros hacemos previamente a ejecutar el instalador de okd una vez que nosotros tenemos todos esos pasos previos funcionando decimos instalador ejecutate el bootstrap node y luego con los ignition files se hace el bootstrap de los otros distintos nodes y tiene cluster funcionando utilizando los procedimientos que están en la documentación de okd si se dan cuenta y leen los playbooks van a poder ver que se sigue la documentación oficial simplemente que está automatizada con ansiwell y esta arquitectura para mí es como que la arquitectura de referencia es más utilizada o la que yo más veo si mucho podría hasta menos worker nodes si es nada más se está haciendo solamente el testing del deployment un poco más de worker nodes dependiendo si tienes una aplicación en específico que quieres correr pero me parece que básicamente has automatizado una arquitectura de referencia bastante común claro eso es la idea de tener algo que a lo mejor pueda ser útil para el 70% de las personas que quieran probarlo y puedan tener valor rápido por ejemplo el sistema de integración continua de los chicos de submariner no tiene hacha en los master nodes ellos no les importa ellos tienen un master node y dos workers es un despliegue que está soportado por esto es simplemente hacer un master y dos workers porque ellos en las pruebas de integración continúan lo que hacen es tirar abajo un worker node ver como se comporta la red restaurar los pods en el otro worker node ver que se establecen de nuevo los enlaces de red entre los dos clusters y eso es lo que ellos quieren probar por ejemplo esta arquitectura siendo muy sencilla sirve para lo que ellos claro sería más pesada pero no te gusta menos master nodes claro lo bueno es que es eso tu ajusta es el inventario en función de lo que necesites y bueno otra casilla que les quería decir por defecto las redes se crean con un prefijo que es kai de qbinit mgt de management net y luego la red que tú quieras crear porque en principio puedes desplegar si tiene suficiente footprint múltiples distribuciones de Kubernetes en el mismo en la misma máquina lo que les comentaba antes la integración continua de submarinal es con dos clusters desplegamos un cluster de okd y desplegamos un cluster de rancher que comunicamos entonces lo que hacemos es esta arquitectura copiarla y pegarla en vez de ser la red 10 000 para rancher va a ser 10 00 1 barra 24 y van a poder funcionar al mismo tiempo los dos clusters en el mismo supervisor a ver voy a hacer una pausa porque justo acaba de terminar el despliegue de okd paria te voy a robar la pantalla y voy a mostrar rápidamente el cluster pueden ver la pantalla casi ya perfecto pues fíjense acaba de terminar el despliegue nos ha tomado media presentación pero bueno en 27 minutos hemos podido desplegar un cluster de okd completamente funcional por ejemplo vamos a conectarnos al al service node es la máquina donde nosotros tenemos desplegado el servicio de DNS HAProxy y un servidor web y el nfs también por defecto esta máquina nos permite acceder a los recursos de nuestro cluster de Kubernetes por ejemplo si hacemos un qtl get nodes vamos a poder ver que bueno que hemos desplegado tres master un worker los master tienen 15 minutitos funcionando porque es lo primero que desplegamos y el worker node pues tiene sólo tres minutos funcionando si hacemos por ejemplo un qtl get nodes me faltó una vez pueden ver que en principio los pods del cluster estaban funcionando y si incluso hacemos un grep por por ejemplo qtl que es uno de los roles que desplego yo por defecto porque he estado haciendo bastantes pruebas con el y bueno no me parece muy pesado para tenerlo como servicio por defecto pues vamos a poder ver que en principio tenemos nuestros pods de qtl funcionando entonces fíjense con un solo comando en 30 minutos tenemos el cluster funcionando para aprender cómo funciona una vez que sabemos cómo funciona pues podemos adaptar la arquitectura a nuestras necesidades pero siempre teniendo como una base algo que si y puedes probar tuvert dentro de libert como nidado como le dice en español claro si porque tienes nested virtualization siempre que tu hypervisor soporte nested virtualization puedes crear máquinas virtuales dentro de las máquinas virtuales de cluster que acabas de descrear si entonces bueno nidado o no no, yo digo nester eso es en español que empieza nada pero no pregunte esto para aprender eso para ahora virtualización anida así podría pero yo nunca la no es algo que suelta escuchar muy a menudo listo para para acá tener cuber corriendo básicamente es como decir ya la la última prueba de decir bueno ya tiene está corriendo ya todo está arriba ya necesita claro a ver el cuber está desplegado por defecto habría que configurar los distintos flavors de las máquinas virtuales que se pueden desplegar verificar que el footprint del servidor del cluster que acabamos de desplegar tiene capacidad suficiente para poder albergar las máquinas virtuales pero ese ese trabajo de sizing lo puedes hacer una vez que ya tú tienes todo funcionado que ves que no hay errores que puedes desplegar una maquinita virtual con una imagen decirlo muy chiquitita que te puedes conectar que ves que funciona una vez que tú tengas lo puedes hacer bueno ahora como lo mejor vamos a ajustar el sizing a mis necesidades pero ya funciona Out of the box que es la idea de esto pues listo María si puedes volver a compartir la pantalla terminamos la presentación que no nos debería quedar mucho más en principio debería estar ajustado 40 45 minutos y yo tenía más o menos contados 30 de la demo desde que empieza y ya está bueno lo que les contaba la red es una arquitectura bastante bastante básica María si puedes pasar adelante la siguiente slide vale vea la anterior es que pensaba que había otra imagen les voy a contar algo rápido otra cosa que me comentó del feedback que me parece curioso porque he recibido muchísimo feedback sobre este proyecto que pasa si yo quiero acceder desde fuera del intervisor a los recursos que acabo de desplegar en el clasper porque claro yo desplego el clasper de okd dentro de una red con nat desde fuera del clasper no voy a poder accederlo porque es una red mateada no hay ninguna regla que me permita acceder al tráfico de la red de management que hice para esto pues es muy sencillo tenemos una única máquina que es el service note que debería tener acceso desde fuera yo desde fuera no debería poder tener acceso a ni a los workers ni a los masters directamente sino a los recursos expuestos del HAProxy que funciona dentro del load balancer que es el service note que sucede pues en este caso esto también está en la documentación es simplemente crear un bridge adicional y no se como se dice esclavizar es que esos términos ya no se utilizan a esclavizar una interfaz del intervisor para tener acceso a el el service note entonces esto es algo que está documentado porque es algo que muchas personas me preguntaron oye una vez que lo despliego como tengo acceso a los recursos que desplegan el clasper y pues eso de esta manera más adelante les voy a mostrar que para lograr esto de TNS tiene que estar configurado de una manera un poco más especial como teniendo zonas externas y zonas internas las zonas internas son las zonas que van a dar respuesta a los servicios que se despliquen dentro de la red de management y la zona externa pues simplemente vamos a tener acceso a los registros de la máquina del service note ahora se los voy a mostrar porque es bastante sencillo y claro esta sería la la interfaz claro esta es la definición de la red para que vean que es una red que está dentro el e-beer de MoodleNet van a ver allí también que nosotros hacemos de hcp a los nodes del clasper filtrando por Mac porque nosotros conocemos la Mac que es algo que está definido en el inventario entonces si ya está definido allí pues nosotros hacemos que nuestro hypervisor nosotros querramos y si se dan cuenta abajo hay una sección que se llama DNS for Water que pasa nosotros el gateway de todas las máquinas del clasper es la interfaz de esa red virtual que nosotros creamos una teada donde desplegamos las máquinas ¿Qué sucede? por defecto el DNS de todas esas máquinas es también el gateway y eso es algo que nosotros podemos configurar en Libbird, simplemente le decimos mira Libbird, si te viene una petición para el dominio de nuestro clasper redireccione esa petición al service node entonces de esa manera nosotros tenemos al gateway funcionando para nosotros redireccionando todas las peticiones de DNS que ya está configurado entonces simplemente se dan cuenta el método de configurar el servicio de DNS para cualquier distribución de Kubernetes porque el DNS es el gateway de la red entonces no tiene nada que ver con los servicios que nosotros desplieguemos dentro del clasper y nosotros queremos externalizar no sé si es la palabra correcta este servicio de DNS porque yo tengo a mi propio servidor de DNS como autoritativo de la zona que yo voy a desplegar en el clasper pues simplemente lo ajustas a apuntar al otro lado igual al HAPROXY el HAPROXY es un registro dentro del DNS lo apuntamos a un load balancer F5 que está a saber dónde y en teoría debería funcionar siempre que podamos acceder a los servicios de nuestro service node en principio si nosotros lo configuramos con acceso external podríamos llegarles sin problema bueno y esto es el detalle del bind que estaba antes tenemos dos zonas, una zona externa y una zona interna la zona interna simplemente va a resolver peticiones desde dentro de nuestra red de administración de management y la vista la external view va a responder peticiones y lleguen al service node por la interfaz externa si se dan cuenta abajo abajo a la derecha en la imagen hay un ejemplo de adónde apuntan los registros de nuestra zona si es dentro por ejemplo de la vista interna todas las peticiones por ejemplo a api.name.domain.local va a apuntar a la 10.0.0.100 pero si es una petición DNS que viene por la interfaz externa la va a resolver la external view y la va a resolver como 10.9.41.159 que es la dirección IP que nosotros le vamos a asignar a ese service node externa para poder llegarles desde fuera de esa manera vamos que esto es ultra super no básico pero es algo es algo estándar en la configuración de bind definir zonas en función de por donde vienen las peticiones de DNS aquí esto es un ejemplo de cómo se configura la zona interna para la zona de nuestro cluster por ejemplo en el caso de okd que es lo que yo suelo probar habitualmente si se dan cuenta hay un wildcard en la tercera regla es asterisco.apps. el nombre del del dominio en este caso cada vez que nosotros creemos una aplicación dentro de nuestros worker nodes y la expongamos dentro de ese dominio automáticamente el servicio de DNS va a apuntar todas las peticiones a nuestro service node nosotros vamos a poder crear aplicaciones que utilicen fqdns fully qualified domain names en nuestro cluster porque automáticamente y por defecto bind lo va a soportar lo vamos a tener que estar metiendo dentro de un masquerade cada aplicación que nosotros creamos con la IP en principio esto es algo que soporta bind de manera nativa y no no tenemos que hacer nada más y la configuración de la chat proxy bueno la configuración de la chat proxy también es bastante básica como pueden ver solamente tenemos cuatro endpoints tenemos dos endpoints para lo que es el ingress traffic y otro para el tráfico de management tenemos el OpenShift API server tenemos por defecto el puerto 6443 todas las peticiones llegan al service node y dependiendo de la configuración de la chat proxy lo balanceamos a los master nodes y a los workers en el caso de que no haya worker nodes la chat proxy está configurado para que todo el tráfico lo mande a los masters tenemos cuatro endpoints para los puertos 6443 22623 que es administración y el tráfico ingress HTTP y HTTPS que es 8443 de igual manera la configuración de esto es chat proxy se configura de esta manera que sucede que es bastante tricky la configuración dependiendo de si tenemos muchos endpoints y muchas máquinas entonces de esta manera podemos tener una configuración inicial que es consistente y es correcta y a partir de allí la podríamos extender para que nos perdamos a siguiente y bueno si queremos integrar cualquier otro third party service pues en principio la arquitectura del proyecto lo soporta incluso está automatizada la manera de crear roles adicionales para cualquier cosa que nosotros queramos integrar ahora mismo no está aquí en la presentación pero tengo un rol que de hecho he hecho algunas horas para desplegar submariner que es un servicio adicional que es integrado para utilizarlo dentro de la serie de submariner pero en principio esto sería un servicio totalmente funcional que si una persona quería desplegar dos clusters y conectarlos pues no deberían poder hacerlo siguiente slide y bueno en principio toda la presentación les he hablado un poquito de el por qué, de cómo está hecho el prototipo inicial cómo funciona la idea del proyecto es que sea lo más ágil posible la idea no es que todos están en cuenta hay muchísimos codes mails dentro del código pero es código funcional es decir, ustedes van a poder ver dentro del código que hay algún rol que tenga un shell con un script en bash que fácilmente se podría refactorizar utilizando módulos nativos de Ansible la idea es mejorarlo poco a poco pero una versión inside que funcione int slide porfa y bueno ahora les voy a hablar un poquito sobre un poco sobre los siguientes pasos en principio la idea de esto es buscar personas interesadas sobre todo del feedback y bueno de alguna manera contribuir simplemente creando issues o probando la herramienta sorprendentemente bastantes personas me han escrito lo están utilizando y bueno tengo el siguiente paso como agregar otras distribuciones como corenetes pero como vanilla corenetes pero es bastante viejo esto y ya no tengo solo corenetes sino tres distribuciones más así que bueno eso muestra que ha habido algo de progreso algo que es súper interesante es el desplique de clusters que estén desconectados de la red desconectados de la red en cuanto a que tanto los worker nodes como los masters no tengan que descargar todas las imágenes de los contenidores de internet un caso de uso de mío en particular es que yo tengo un servidor con 64 gigas de RAM conectado por un ADCL que sucede desplegar el cluster solo utilizando el ancho de banda del ADCL toma tres horas y media porque tiene que descargar muchísimo contenido claro, entonces la idea de esto sí exactamente y precisamente por eso al principio te pregunté si podríamos, digamos, utilizar Kubernetes para desplegar algo una distribución que yo tenga local porque dan muchos clientes que tienen test environments también que están completamente desconectados pero le sería súper útil tener unas herramientas básicamente un built-in CI o sea porque lo que has creado es una manera de poder repetir test o crear o conectar con su CI interno un montón de pruebas que si bien la arquitectura como dice sirve para el 70% de los casos es suficientemente genérica como para decir bueno, empiezo por aquí que ya tengo todo el esqueleto y si tengo que hacer tweaks pues es mejor hacer tweaks de esto o modificar esto que empezar desde cero a crear una automatización entera claro, por ejemplo la idea sería crear un rol que permita desplegar un local registry dentro del service node o donde lo quieras desplegar por ejemplo para el sistema de integración continua de Submariner nosotros tenemos que tener un local registry porque nosotros tenemos que generar las imágenes de los contenedores que vamos a utilizar dentro de cluster entonces es algo que ahora mismo no está pero yo supongo que en las próximas semanas y yo quiero que Cubini se pueda utilizar en el entorno de integración continua de Submariner tiene que estar, bueno eso es algo que todavía no está pero vamos, está working progress tenía además es código abierto empezaste a hacerlo con tenías una razón y un propósito que es tu proyecto pero obviamente lo has hecho de una manera súper abierto, súper modular que puede ser también utilizada para muchas otras aplicaciones y bueno, eso me encanta si otra cosilla es que por ejemplo hay muchos roles, hay mucho código y el soporte por ejemplo de las pruebas es bastante lax sería bastante interesante agregar más contenido dentro de las pruebas de integración por ejemplo de los test funcionales o de los test tunitarios el problema es que toma mucho tiempo yo ahora mismo la mayor parte del peso de son las pruebas del proyecto, lo estoy basando en los tests en tu entorno y yo logro desplegar el cluster veo que todos los servicios están arriba para mí funciona que sucede, es importante que para eso están los test de molecule cada servicio se pueda probar de manera independiente ¿por qué? porque esa carga se puede ejecutar dentro de github entonces no tiene sentido que yo invierta una hora y puedo tener feedback en 5 minutos utilizando la sede github pero bueno, poco a poco que son muchas cosas y nada más muchísimas gracias por la invitación por el tiempo algunas cosillas más donde mirar pues la web del proyecto es 3vw en España www.cubinit.com la documentación está en docs.cubinit.com el repositor está en github www.cubinit.com y es FreeNode porque suelo estar en FreeNode porque es el método de comunicación habitual dentro de la comunidad OpenStack he creado un canal que se llama PoundCubinit si necesitan cualquier cosa igual si les ha gustado la presentación pueden ayudar con algo tan sencillo como probar la herramienta para dar feedback también si quieren estar en contacto o recibir actualizaciones si le dan a la estrellita en el proyecto pues si necesito enviar alguna información o algo pues poder utilizar la lista de las personas que están ahí y poco más muchísimas gracias muchísimas gracias a ti Carlos que bien perfecto me interesa mucho lo voy a probar todo lo que sea automatizar y resolver la vida me encanta y obviamente mucho éxito también con él y que tengas más contribuciones pues empecé yo solo y al día de hoy hay somos 4 o 5 personas que hemos enviado algún pull request y muchos issues y comentarios en mi blog de la documentación que voy sacando sobre todo eso a la gente intenta probarlo ven que falla, me preguntan, yo les respondo dicen ah es que no tenemos ramo suficiente o oye que hay algo que no estamos haciendo bien suelen ser cosas muy culturales con lo cual bueno hasta ahora yo estoy contento bueno gracias a todos y hasta la próxima gracias Carlos muchísimas gracias adios adios adios adios adios