 ¡Hey, Alex! ¡Hola! ¿Cómo están, amigo? ¡Hola! ¿Cómo estás? Muy bien. Ya preparados para una sesión sobre... ¡Muy, muy, muy! ...GitOps y Kubernetes. Sí, yo estoy muy... Sí, estoy queriendo aprender más sobre este tópico, entonces será muy bueno aprender directamente contigo que hoy tú trabajas como un director de la experiencia, ¿correcto? Sí, soy director de Developer Experience aquí en Red Hat y, bueno, como digo, tocamos un poco de todo lo que sea el mundo Java, el mundo Kubernetes. Y hoy, bueno, pues nos vamos a centrar un poco en lo que sería Continuous Integration Continuous, the library, GitOps, DevOps, todos estos conceptos. Yo no he formado un poco práctica. Ya sé que no lo podremos ver todo y habrá cosas que diréis... pero quizás un poco rápido. Pero no os preocupéis porque al final hay los links con tutoriales que son gratis, que podéis ir allí y, o sea, funcionan por Minikube, funcionan también con OpenShift, o sea que no necesitéis un OpenShift para aprender y nada, y podréis hacer lo mismo que voy a hacer hoy, pero en casa. ¿Y las aplicaciones Java son con cuarcas o no es importante saber de runtime? Bueno, para hoy no importa, porque al final no estamos construyendo aplicaciones Java, pero en nuestro caso también trabajamos mucho en parkus, pero también en Springboard. Muy bueno, ok. Entonces, ¿puedes compartirlo con Talia y empezar? Vale, pues creo que ya podéis ver todos mi pantalla. Bueno, veis que el eslatch se llama Continuous Integration and delivery con K, porque al final vamos a hablar sobre Kubernetes. Mi nombre es Alex Soto, mi email es a SotoWare.com, mi Twitter es Alex SotoV. Si queréis estar actualizados sobre noticias de Java, sobre Kubernetes también, o sobre proyectos que están, digamos, debajo de Kubernetes, o encima de Kubernetes, depende de cómo lo miramos, iba a decir debajo del paraguas de Kubernetes, y si tenéis alguna pregunta, pues también me la podéis hacer por Twitter o también por email. Finalmente, soy el cautor de testing Java Microservices, CortosCubebook, y se cura en Kubernetes. Así que, ya, vamos a empezar, porque sino nos quedaremos en tiempo. Primero de todo, vamos a coger un poco de perspectiva y vamos a pensar cómo desarrollábamos hace 5 años, o 6 años, ¿no? Ahora tenemos que pensar que seguramente teníamos una aplicación monolítica, donde tenía su base de datos, y que, bueno, igual la despegábamos a producción una vez cada 4 meses. Ya sé que algunos de vosotros diréis, una vez cada 4 meses. Si íbamos a producción una vez al año y hacíamos una fiesta, sé que seguramente algunos de vosotros pasaban este tipo de cosas. Pero bueno, podemos asumir que cada 4 o 5 meses pasamos la producción. Pero desde hace estos 5 o 6 años, empezamos ya a coger nuestro monolítico, romperlo en piezas más pequeñas, y diríamos empezar a implementar una arquitectura más basada en microservicios, o un arquitectura basada en servicios, donde tenemos muchos servicios, todos ellos interconectados mediante la red. Y una de las grandes ventajas que tiene es trocear un monolítico en piezas más pequeñas, es de que ahora podemos desplegar, no una vez cada 4 meses la producción, sino podemos desplegar una vez por semana, una vez al día, o una vez a la hora. Y en ningún momento estoy diciendo que estamos desplegando a producción toda la aplicación cada hora. Seguramente lo que está pasando es desplegar una pequeña parte de esta aplicación, por ejemplo, esta parte, esta parte, o esta parte cada hora. Cada vez desplegamos simplemente un servicio. Y fijaos que usando esta aproximación nos permite ir a producción muchas más veces, pero tenemos que tener en cuenta que tenemos que poder desplegar estos servicios de forma aislada, vale? Sin tener ningún tipo de coreografía entre servicios, vale? Sea que si desplegamos un servicio A, que este nuevo despliegue no implique un despliegue de servicio B. Y como en arquitectura de microservicios, arquitectura de servicios, podemos tener varios lenguajes o incluso varias formas de desplegar a producción, implica que cada uno de estos servicios tiene que tener su propio pipeline, tiene que tener su forma, propia forma de desplegarse. Evidentemente no se despliega igual una aplicación en Java, en términos de construir la aplicación, quizá manejo de memoria, etcétera, que una aplicación hecha en Go. Por tanto tenemos que poder definir nuestros pipelines para que cada uno de los servicios de una forma rápida. Y, aparte, como Kubernetes, se está siendo ya la plataforma de facto de desplegar microservicios, necesitamos unas herramientas que se integren de forma nativa a Kubernetes. Pero vamos a empezar un poco, una definición de qué es DevOps, ¿vale? Seguramente muchos de vosotros ya muchos de vosotros ya sabéis qué es, ¿vale? Pero podríamos decir que DevOps es una metodología que permite a nuestras aplicaciones desplegarse a producción de una forma más rápida sin tener que prescindir de la calidad, ¿de acuerdo? Es simplemente esto, ¿vale? Es una metodología que ayuda a que podemos ir a producción muy a menudo y, por tanto, tener una ventaja competitiva respecto a nuestros competidores. Y muchos de vosotros diréis, bueno, pero es que DevOps, al final, como dice su nombre, sobre los devs y sobre los softs, es decir, es... No podemos pensar que se trata de una metodología que afecta a los developers y a la gente de operaciones, pero no es verdad. DevOps afecta a todo el equipo. Todo el equipo tiene que estar trabajando desde un inicio en ver cómo va a ir este proyecto a producción. ¿Cómo lo vamos a desplegar? La gente de operaciones tiene que estar desde un inicio cuando empezamos a generar una nueva aplicación, ahí, ver cómo se va a desplegar. La PMO, la gente de negocio, la gente de seguridad. No tenemos que dejar la seguridad hasta que se haya terminado un desarrollo. La gente de seguridad tiene que estar allí mirando cómo se desarrolla, mirando, revisando código para que sea más seguro, explicando a los desarrolladores cómo generar código seguro. Los devs, los QAs. La fase de QA no es una fase que sale al final, cuando ya está todo desarrollado. Tiene que ser una fase continua de ver cómo se va a desplegar la aplicación. ¿Cómo los desarrolladores pueden escribir mejor estés? Y finalmente también hay los devs, que en ningún caso digo que los devs sean zombies. Estoy diciendo aquí que los devs les gusta mucho a working dev y los devs también tienen que estar desde un inicio validando que todas las operaciones de la base de datos se hagan de forma correcta. Esto es devops, devops es todo un equipo conjunto, sin silos, trabajando teniendo en mente que la meta es llegar a producción. Una vez que tenemos toda esta metodología, toda esta filosofía dentro de nuestra organización es el momento de empezar a automatizar todo el proceso, porque sin automatización no es posible ir a producción una vez cada hora. Por ejemplo, una vez a un día. Por tanto tenemos que adaptar Continuous Integration Continuous Delivery, seguramente casi todos ya sabemos que es Continuous Integration Continuous Delivery, ¿verdad? Pero bueno, podemos decir que Continuous Integration es la parte donde se construye la aplicación, vemos que se hace la actualización de la aplicación quizás se crea el contenedor, se testea la aplicación se hacen unos security checks, ¿no? Podríamos pensar aquí como security checks como por ejemplo análisis estático de código para ver, detectar código que no sea todo correcto y finalmente ahí la fase de release y en la parte de Continuous Integration cuando hablamos de release estamos hablando de coger nuestro artefacto nuestro artefacto puede ser un pichero jar puede ser un pichero guard puede ser un contenedor y guardarlo dentro de un servidor de guardarlo dentro de un servidor de artefactos Algunos otros quizás pensaréis en QuioIO, otros con Dover Hub quizás otros con Artifacto Nexus, perfecto Finalmente tenemos los dos fases más que es la de despliegue a staging y despliegue a producción que esto es la parte de Continuous Delivery esta parte es donde realmente cogemos nuestro artefacto que hemos construido en la fase de Continuous Integration y la despliegamos quizás a staging y quizás después ya a producción Así que ahora que ya sabemos de Pops sabemos que tenemos que adoptar los fases para poder desplegar correctamente y rápidamente a producción Después también tenemos Continuous Integration en Continuous Delivery para poder desplegar rápidamente de forma automática evitando problemas bien, tenemos todo esto pero ya sabemos que cuando ya hemos adoptado de Pops, cuando ya tenemos Continuous Integration Continuous Delivery realmente paso que sería ya coger la metodología GitOps la metodología GitOps se basa en que todo nuestra aplicación y cuando digo todo no me refiero simplemente a la aplicación me refiero también a la infraestructura está toda guardada en Git el repositorio Git es es el repositorio que es la fuente de la verdad todo lo que está en ese repositorio es lo que realmente está en producción lo que no está en ese repositorio simplemente no existe esto nos permite poder usar todo nuestro código no simplemente de la aplicación sino también el código de infraestructura el código que construye nuestra infraestructura el código que configura nuestra infraestructura también tratarlo como si fuera código fuente por tanto, podemos empezar a crear sin operaciones y queremos mediante lo que nos ofrece Git por ejemplo si no tenemos GitOps queremos actualizar la versión de una base de datos seguramente iríamos a hablar con alguien al final quizá nos darían el OK y finalmente un manual que terminaría con la actualización de la versión de la base de datos ¿Qué pasa? pues que es un proceso que no queda traseado no se puede hacer una revisión antes de que se produzca simplemente tenemos que confiar en que se va a producir de forma correcta pero fijaos que si usamos GitOps como toda esta operación pasa a través de Git lo que podemos hacer es una pull request lo que tiene es una actualización de unos scripts y queremos decirle de esta forma que actualizan la base de datos ¿Y por qué es importante? porque como tenemos un pull request lo que podemos hacer es hacer un review hacer comentarios escribir por qué se hace de esta forma en no de otra y por tanto poderlo revisar en el futuro por tanto al final GitOps no deja de ser una forma de implementar contiones de delivery operaciones que se aplican a la infraestructura de una forma como los desarrolladores y hemos estado trabajando siempre para desarrollar las aplicaciones por tanto GitOps usamos Git porque todo el mundo usa Git funciona muy bien ya que nos ayuda a poder tener un histórico de todos los cambios que hemos hecho a nuestra aplicación en nuestra infraestructura de tal forma que imaginamos que en un momento dado en el tiempo queremos cambiar una versión de la base de datos otra vez la cambiamos empezamos el proceso y al cabo de media hora nos damos cuenta que esa nueva versión no funciona bien podemos volver a la antigua esto como lo podríamos hacer si lo hemos hecho de forma manual pues seguramente cuesta lo suyo pero si lo hacemos con Git siempre podemos hacer un Git Reverb revertiríamos el cambio dentro de Git y luego como hemos cambiado el repositorio de Git y recordamos que Git es la fuente de la verdad automáticamente todo el sistema vuelve a la versión anterior por tanto fijaos que gracias a que sea Git podemos revisar cambios podemos hacer comentarios y incluso podemos revertir problemas y finalmente también importante con Git recordamos que hacemos comentarios hacemos comentarios por tanto allí podemos explicar por qué hemos querido realizar un cambio sumongamos que yo tengo una aplicación simplemente hay una instancia simplemente no está replicada y queremos replicarlo a tres instancias esto lo podríamos hacer haciendo un Qt carol scale pero fijaos que perderíamos el por qué hemos escalado a tres instancias quizá hemos escalado tres instancias porque tenemos mucho tráfico quizá por resiliencia a priori no lo podríamos saber y lo más importante al cabo de tres meses si algo nos pregunta por qué escalamos el servicio de una instancia a tres instancias seguramente no nos vamos a acordar en cambio si lo hacemos con Git con GitOps como habremos puesto un comentario escalamos nuestra aplicación a tres instancias por qué por resiliencia al menos cuando alguien nos pregunte oye por qué escalaste la aplicación de una instancia de tres instancias podríamos hacer un GitBlame y verlo por qué y ver quién hizo el cambio y poderle ir a preguntar también por eso es muy muy importante adoptar GitOps también evidentemente como Git es la fuente de la verdad podemos tener consistencia entre clusters todos los clusters que se conecten a ese repositorio Git van a ser idénticos así que ¿cuál es el modelo de despliegue en GitOps? pues como hemos dicho hay la parte de Continuous Integration, la parte de Continuous Delivery empezamos con la parte de Continuous Integration básicamente lo que tenemos es un repositorio donde tenemos todo nuestro código fuente luego cogemos este código fuente lo que hacemos es hacer un build de la aplicación ejecutar los tests generar un contenedor en el caso de Kubernetes y crear este contenedor hay más registros un registro de contenedores donde los guardamos como puede ser Quai como puede ser Docker Hub y si queremos implementar toda esta parte de Continuous Integration de una forma Kubernetes native lo tenemos que hacer con Tecton Tecton simplemente es un proyecto que nos permite a implementar Continuous Integration de forma nativa en Kubernetes está pensado para que funcione dentro de Kubernetes lo cual fijaos que es muy importante porque si nosotros queremos construir un contenedor es una muy buena práctica construir este contenedor en las mismas máquinas donde después se va a ejecutar si usamos Tecton como Tecton está funcionando dentro de el cluster de Kubernetes ya sabemos que las imágenes que van a construir van a estar construidas en la misma máquina donde después se van a desplegar aparte Tecton es una tecnología Serverless, lo que implica es que nosotros veremos que no tenemos que configurar ni mantener nada de el engine de Continuous Integration porque todo va a estar containerizado por tanto no hay plugins no hay no hay versiones de plugins simplemente hay gestión de un pipeline y finalmente veremos como hemos visto en un inicio que como tenemos un arquitecto basado en microservicios y cada uno de estos microservicios puede tener su propio pipeline y cada servicio puede estar desplegado manejado desarrollado por diferentes equipos Tecton nos permite que cada servicio tenga su propia forma de desplegar es muy importante tener en cuenta que Tecton estipado está desacoplado, es clonarive y es declarativo y lo que es aún más importante es tener claro los conceptos de Tecton porque hay cuatro conceptos pero es muy importante tenerlos claros el primero es un pipeline resource un pipeline resource no deja de ser un recurso ahora es un recurso que nosotros vamos a usar en nuestro pipeline por ejemplo el repositorio de código fuente la dirección de el repositorio de código fuente esto es un recurso que necesitamos otro podría ser la imagen o el contenedor que queremos crear o que queremos usar para ejecutar test esto también es un recurso que se necesita en nuestro pipeline o también podría ser a una localización de un disco, como digamos que yo quiero coger un pichero jar y lo quiero guardar a disco pues esto es también un recurso luego también tenemos un step y una tarea un step no es un objeto como tal dentro de Tecton simplemente una parte pero me gusta tenerla aparte porque es importante entenderla primero de todo comentaros que un step no deja de ser un contenedor es decir cada vez que creamos un step realmente lo que estamos creando es un contenedor y este contenedor va a ejecutar comandos, ya veremos como pero lo que haremos es configurar comandos que se van a ejecutar dentro de un contenedor y como es un contenedor que está funcionando dentro de Kubernetes, tenemos que pensar que podemos añadirle volúmenes podemos usar variables de entorno secretos confinments, etc. porque nos dejan de ser contenedores que funcionan dentro de Kubernetes pero realmente en Tecton lo que estamos ejecutando ejecutando y deteniendo son tareas no steps y una tarea no deja de ser una lista de steps una lista de pasos que se ejecutan de forma secuencial esto es importante de acuerdo, una tarea es una lista de contenedores porque recordamos que un step es un contenedor que se ejecuta de forma secuencial primero el step 1 2, 3, etc. y fijaos que si un step es un contenedor una tarea es un es un pot porque un pot puede ejecutar más de un contenedor por tanto una tarea es un pot y un step es un contenedor que puedes tener para entrar y de salir y finalmente tenemos un pipeline que al final un pipeline es una lista que se que definen en qué orden queremos ejecutar estas tareas tenemos las cuartareas en paralelo en secuencial haciendo poniendo barreras para esperar ciertos resultados etc. pero todos estos fijaos que todos estos conceptos que os he explicado ahora pipeline de solo steps siempre son definiciones de acuerdo no son ejecutiones, nosotros queremos definir un pipeline y este pipeline lo vamos a definir con una tarea ahora bien ¿cómo ejecutamos esta tarea? ¿cómo ejecutamos un pipeline? pues mediante un task run y un pipeline run estos son objetos que son creados que son instancias de nuestro pipeline ¿de acuerdo? si nosotros tenemos nuestro pipeline y llega un momento que nosotros queremos ejecutar este pipeline ¿cómo se pueden crear estos tasks run? pues diríamos que hay unas herramientas, la primera es mediante un fichero llameo, podemos crear un fichero llameo de tipo task run, que lo que hace es crear un instante de una tarea la segunda forma es usando tiki n tiki n es una herramienta que nos ofrece detector de línea de comandos, que nosotros la ejecutamos y automáticamente crea un task run o pipeline run y la tercera forma es mediante un evento por ejemplo, supongamos que tenemos un webhook en nuestro servidor git, que cuando hacemos un merge a master, por ejemplo este merge lanza un evento dentro de Tecton, que lo que hace es crear un pipeline run para ejecutar todo el pipeline de este cambio luego vamos a ver un poco en acción tengo aquí Tecton, no les voy a enseñar el primer ejemplo de Tecton, es uno muy muy fácil es este task Hello podemos ver que no deja de ser un objeto de tipo Tecton Tecton que es un task fijaos que tiene un nombre y tiene una lista de steps, recordamos que dijimos una tasquera o un pot que contiene contenedores que son steps luego tenemos aquí simplemente un step que es un contenedor, le tenemos que decir que contenedor queremos usar y finalmente qué comando queremos ejecutar dentro de este contenedor en este caso simplemente mostrar Hello World vamos a hacer un Qtc Hello Hello World ahora yo he creado una tarea fijaos que si hago un Qtc no hay nada porque recordamos que yo ahora simplemente lo que he hecho ha sido registrar la tarea dentro del cluster de Kubernetes pero no estoy ejecutando nada ahora cómo ejecutaría yo esta tarea, yo digo muy bien ahora yo quiero ejecutar esta tarea recordamos que hemos dicho de tres formas diferentes o creando un pichero ya medio de tipo run o usando tkm o registrando un evento, un webhook que lo que haces es que cuando haya un cambio ejecute esta tarea vamos a hacerlo con fichero yaml el fichero yaml que ahora lo veréis de esta forma fijaos que es de tipo task run y lo que le decimos es que cuando yo aplique este fichero yaml lo que quiero es instanciar una tarea que tiene nombre hello world que es este por tanto yo ahora haré un qtc task run el world y ahora si hago un qtc podremos ver como se esta inicializando un pod que simplemente tiene un contenedor porque recordamos que simplemente hay en este mientras se va ejecutando que veréis que va se tiene que fijaos que ya ha salido el pod y se ha ejecutado y ahora algunos de vosotros os diréis como puedo ver que se ha ejecutado pues podría hacer un qtc de este pod y fijaos como ha dicho hello world que es lo que hemos puesto aquí esto es el comando que hemos ejecutado también podríamos hacer un tkm task list y podríamos ver la lista de tareas fijaos que tenemos una tarea hello world y también podríamos hacer un tkm task run list y nos devolvería la lista de tareas que se han ejecutado que es esta es una y con subsidi y incluso si queremos podríamos hacer un describe y nos va a describir la tarea fijaos que hemos dicho que se ejecutó esta tarea que se llama hello world bien y ahora diréis bueno vale pero esto es un ejemplo muy tonto yo quiero ver algo más algo de continuous integration que se llama real un proyecto que yo haga a un clon de un proyecto hago un compile y hago un contenedor y luego este contenedor lo suba a mi registro de contenedores pues aquí tenemos un ejemplo también que voy a enseñaros un resource fijaos que ahora el ejemplo es mucho más complicado lo que yo quiero hacer es hacer un clon de un repositor hacer un build hacer el funcionar los tests y finalmente como output de este pipeline es tener un contenedor creado un contenedor linux creado luego ¿qué necesitamos? necesitamos dos recursos primero de todo uno que sea de tipo git donde yo le tiene un parámetro url donde yo lo digo la url donde está el repositorio y luego también tener otro pipeline resource de tipo image donde yo le digo cuál será el nombre que le quiero dar al contenedor ahora puedo hacer un keycard de este fichero y a mel y en ahora ya tengo mis recursos creados fijaos que simplemente yo he registrado unos recursos que quiero usar y luego lo que también tendría que poner es aquí una tarea que lo que me haga es construir mi aplicación fijaos que es una tipo tarea ahora fijaos que es mucho más complicado porque tenemos de parámetros de entrada un git y de salida una image estos son los parámetros ahora cuando lo ejecutamos será con los parámetros que hemos registrado como pipeline resources y ahora fijaos que tenemos dos steps el primero step es un mail-in-veal donde lo que haremos es coger, hacer un git clone automáticamente esto pasa se va a hacer un git clone dentro de este contenedor y luego ejecutar este comando mail-in-cleaning-install y cuando termine este step va a ejecutar otro step que es la construcción de la imagen vamos a hacer un buildup es una tecnología dockerless que nos permite crear contenedores dentro de contenedores ahora voy a registrarlo simplemente he creado una tarea no hay ningún task run y ahora lo que podemos hacer es arrancar la tarea pero usando TKN en cambio de hacer un yamed fijaos como yo le he dicho TKN task start le digo el nombre de la tarea que quiero arrancar que se llama build.pt y ahora fijaos que aquí le he dicho yo que como input resource source fijaos que aquí el input resource se llama source quiero usar git source es decir quiero hacer el link con este pipeline resource ahora ya está ejecutándose creo que habéis entendido cuando yo he hecho el TKN el TKN he creado un task run añadiendo como parámetros de entrada y de salida los pipeline resource que yo he creado anteriormente ahora fijaos aquí como se va ejecutando todo fijaos como aquí se ha ejecutado mayband se ha construido la aplicación y ahora aquí podéis ver como se está creando el contenedor fijaos aquí como es el step 1 de los plan registriáxer ad uvi open gk copy target java deployments ya podéis ver como se va ejecutando el docker files de la forma que construye el contenedor y finalmente podemos ver como se ha hecho el push de la imagen que hemos creado en huai.io de hecho un segundo huai.io si ahora creo creo que es aquí el repositorio se llama un segundo que nos vamos a hacer un repositorio ahora pues bueno, puedo hacer un tiki en ah, el repositorio se llama tecton tutorial gritter podéis ver aquí a ver, por enlace tecton tutorial gritter en packs podemos ver que a few seconds ago bueno, ahora hace un minuto he hecho un push de un contenedor podemos ver que gracias a tecton y simplemente usando yamels podemos generar todo un pipeline de construcción de mi aplicación y fijaos que este pipeline se ha ejecutado dentro de Kubernetes no en un sitio externo fijaos como aquí, esto ha sido el vintapt como es un 05 es decir, han habido 5 steps ejecutados para esta tarea pero evidentemente podemos ver que hemos terminado con la parte de Continuous Integration pero nos falta también la parte de Continuous Delivery como podemos desplegar a producción y esto se hace mediante Argo Siri lo que haríamos es que recordamos que hemos dicho que GitOps es la forma correcta de desplegar a producción hoy en día que es manteniendo toda nuestra configuración de nuestro entorno de producción en Git por tanto, si yo quiero cambiar la imagen de la versión 1.0.0 la versión 1.0.1 lo que tengo que hacer es crear un fichero yamel que cambia la parte de imagen de a 1.0.0 a 1.0.1 luego lo que haría sería la parte de Continuous Integration lanzaría un pull request a un repositorio Git que lo llamamos Configured Repository toda la configuración de mi entorno lo que haría es modificar el entorno mediante Git yo iría modificaría mi fichero yamel que está en Git y le diría que ahora la imagen que quiero tener a producción es la 1.0.0 si no es la 1.0.1 y luego automáticamente Argo Siri detectaría este cambio y lo detecta y le regaría a Kubernetes porque al final realmente lo que tienes con Argo CD y con GitOps es que el sistema está constantemente monitorizando este repositorio Git constantemente están viendo si hay cambios en este repositorio y si los hay si detecte que ha habido un cambio lo que hace es aplicar el cambio en el caso de querer desplegar una nueva versión detectaría que un fichero yamel ha cambiado este fichero yamel nos tiene una nueva versión y por tanto lo aplicaría como he dicho Argo Siri es una aplicación para Kubernetes para implementar GitOps de tal forma que toda nuestra configuración del cluster ya sea usuarios, creación de namespaces, etc. como la configuración y despliegue nuestra aplicación está dentro de Git y Argo Siri simplemente lo que hace es detectar cambios y aplicarlos en nuestro cluster sé que algunos diréis ostras, pero esto es de GitOps y Argo Siri no tengo muy paro si usarlo o no simplemente pensar de una cosa antes de Kubernetes hacía una ssh producción para desplegar si no lo haciais ¿por qué? tenéis que hacer KitKart no deja de ser como si estuvieramos haciendo una ssh a un servidor de producción vamos a ver un ejemplo muy rápido y podremos ir a las preguntas como os digo ahora os pasaré los links para que vosotros podáis verlo todo con calma ahora lo que quiero que veáis es lo siguiente segundo aquí segundo aquí yo aquí tengo un repositorio ¿dónde? lo que estoy definiendo es la configuración de mi cluster podemos ver que en este caso tengo una aplicación que se llama BGV es de BlueprintDeployment y mi aplicación está definida en estos ficheros yamels y fijaos que estos ficheros yamels están en un repositorio que se llama KitGitOpsExample y están en este directorio de OverlaysBGV osea que tenemos un repositorio donde está mi aplicación BGV y otro repositorio donde está cómo desplegar cómo configurar mi aplicación luego ahora viene la pregunta cómo despliego yo esta aplicación a producción haciendo un KubeKart apply de este yamel obviamente no lo que tenemos que hacer es como os he comentado usar KitOps y hacer que ArgosDB automáticamente pueda detectar estos cambios y los aplique luego como se hace esto es relativamente fácil lo único que tenemos que hacer es definirle a ArgosDB una vez que lo tenemos instalado aquí está el repositorio Kit donde está los ficheros para desplegar luego vamos a ir a documentation Modus Roots Examples aquí tenemos la aplicación fijaos que es un yamel de tipo aplicación donde es de ArgosDB aquí le digo donde quiero desplegar la aplicación fijaos que le digo que quiero desplegarla en el mismo cluster donde está funcionando ArgosDB le digo un NemSpace donde yo quiero aplicar todos estos ficheros yamels donde quiero aplicarlos lo tengo que configurar y esto lo configuró aquí con el NemSpace luego lo tengo que decir donde están mis ficheros para desplegarse a producción aquí tenemos este repositorio Kit en esta rama fijaos que podría tener una rama de producción una rama de testin y tener varios ficheros aplicación de ArgosDB y en qué directorio están estos yamels en esta ocasión apps.bgb.bgb o que si veis aquí fijaos que están apps.bgb.bgb sí ahora qué va a pasar cuando yo aplique este fichero aplique este de vgb.aplan lo que va a pasar es que voy a registrar una nueva aplicación tipo ArgosDB luego si yo voy aquí podremos ver que nos ha venido aquí una nueva aplicación que se llama dcd y que si le pongo fijaos que nos está diciendo que está Sinti es decir está sincronizando el repositorio Kit que es el cluster actual fijaos que como no había ninguna aplicación lo que tiene que hacer es ejecutar todos los ficheros yamels pero si la aplicación ya estuviera creada y simplemente hubiera cambiado por ejemplo la versión de la imagen el tag que yo quiero desplegar simplemente ejecutaría la parte que ha cambiado el fichero que ha cambiado que es el de deployment ahora fijaos como aquí ahora está desplegándose fijaos como está sinc es decir que toda la aplicación ya está funcionando correctamente de hecho ahora puedo ir aquí puedo hacer un qvnes dgf hay dgf perdón porque fijaos que es como se dice en the name space me voy y puedo hacer un qfcarl getPot y podremos ver como tenemos la aplicación del dgf es decir la aplicación ion, blubrim, deployment que está funcionando evidentemente algunos de vosotros diréis bueno esto está muy bien pero al final no deja de ser un cologwall de una forma que tiene una aplicación que tiene unos ficheros aquí yamels dejadme deciros que tenemos una aplicación aquí desplegada que es aún más compleja que es un turo vale es una aplicación donde despliegas una parte servidora una parte de frontend creamos un despliegue de base de datos creamos un despliegue de una aplicación creamos los esquemas de base de datos y todo esto fijaos que se tiene que coordinar de alguna forma no podemos empezar a crear los esquemas de base de datos hasta que la base de datos no esté arrancada no podemos arrancar nuestra parte de backend hasta que la base de datos esté arrancada porque si no a que base de datos se va a conectar y esto también se puede hacer con argosidie y se hace de la siguiente forma fijaos aquí tengo yo un fichero yamels que es como se despliega posgre fijaos yo le digo aquí la versión etc etc y aquí hay una anotación que se llama singway 0 lo que hace argosidie cuando tiene esta anotación es ordenar de menor a mayor de tal forma que los ficheros con un singway más pequeños se ejecutan antes que los que tienen un número más elevado en este caso fijaos que lo que tengo aquí es un fichero es la base de datos la despliegue de la base de datos que vale 0 y si vemos aquí hay un otro un job en este caso que lo que hace es crear el esquema de base de datos y fijaos que el singway vale 1 porque porque yo lo que quiero hacer es primero de todo crear la base de datos después crear el esquema en esta base de datos después que quiero hacer bueno pues seguramente lo que quiero hacer después es ya desplegar mi aplicación, mi aplicación to do después cuando es mi aplicación to do ya esté desplegada lo que quiero hacer seguramente es configurar el ingres para tener acceso a esta aplicación porque no quiero configurar el ingres hasta que esté ya arrancada por tanto lo que hago es añadir un singway 3 ahora fijaos que sí voy aquí otra vez voy a ir a to do ya mel mi fichero al final no va a ser muy diferente que el anterior fijaos que es una aplicación que ahora está apuntando también en el mismo repositorio pero en otro opad yo lo voy a aplicar to do application yo simplemente aplicando este fichero ya mel lo que pasa es que es que se crea una nueva aplicación y fijaos como aquí ahora han detectado todos los recursos que tiene que aplicar porque fijaos que están en amarillo que dicen que están out of sync o sea aún no se han sincronizado y veremos como se ejecutan en un orden todos a la vez sino que empezará creando el name space fijaos primero crea el name space porque si no crea un name space no puedo desplegar nada después empezará ya a crear la base de datos fijaos está creando la base de datos cuando termina la base de datos bueno ahora estamos arranzando la base de datos tenemos que ver como crea la tabla porque hasta que la base de datos no esté creada no tenemos que no podemos crearlo esperaría un rato podremos que cuando pasó a paso y la fijaos termina de la base de datos vamos a crear la tabla y crea la tabla una vez que hemos creado la tabla podemos ya empezar a arrancar mi aplicación luego qué pasaría si ahora dijera yo lo que necesito ahora es cambiar mi aplicación de desliegue en este caso fijaos que es la versión yo quiero cambiar a la versión 1.0.1 lo único que tendría que hacer es hacer un merge mediante un pull request si queremos a este fichero y amel cambiando esto este fichero de 1.0.0 a 1.0.1 luego y ahora si fiera el commit automáticamente argosid este fichero ha cambiado y lo re-recutaría iría aquí dejamos que la aplicación ya está toda desplegada pues si ahora comitear a este cambio de 1.0.0.1.0.1 es decir, la nueva versión que yo ya hubiera creado él automáticamente argosid cogería y veríamos como aquí la parte de la parte de deployment que está por aquí tutuguitops la parte de aquí simplemente se ejecutaría actualizando la la la imagen que está desplegada fijaos pues que todas las operaciones pasan a través de git nunca haremos un git card a la play de un deployment.jp nunca lo que haremos es pondremos un push registraremos la aplicación como nos hecho ahora haríamos un push a git y automáticamente ya se encargaría para actualizarlo simplemente ya para ir terminando comentaros que si vais a diendo depth as large tecton tutorial aquí veréis todo un tutorial gratuito para aprender tecton, para aprender triggers etc. si queréis aprender algo de todo esto que os he enseñado aquí super rápido lo que queréis escuchar vosotros con calma en vuestra máquina, diendo depth barra argosid global, también igual a gratuito y si queréis ver un ejemplo global donde se junta tecton y argosid y hace el pull reek etc. etc. pues hay este juego que es en github.com barralor.jp veréis que es un juego pacman donde integra toda la parte de tecton y toda la parte de argosid en un solo ejemplo evidentemente si por cualquier cosa en twitter me podéis pedir también los links y os los facilitaré sin ningún problema y esto es todo creo que no tenemos tenemos un minuto para preguntas voy a mirar si, muy muy interesante este contenido, muchas gracias por compartirlo a mi me gusta mucho tecton y su modo de funcionamiento en la cloud y aquí tenemos algunas preguntas como esta de jonathan vila yo no sé cual de esas tuya respondió las voy leyendo una es decir el orden de dependencia en drapabla en resources, no puedes definir dependencias, es simplemente recursos que necesitas, puede ser el repositor y obit la imagen que quieres crear, no hay dependencia si tuvieras por ejemplo 3 repositorios git pues habría 3 paglan resources que luego, cuando los pusieres dentro de una task pues sería un clone o vienes del task que establece el orden bueno podríamos, si de alguna forma podríamos decir que es el task que define el orden hola sebastián me dices azur devol versus argosid tecton por qué cambiar esas soluciones no sea azur devol, esto es lo primero pero yo te dije que argosid y tecton son nativos de cobernetes no sé si azur devol es nativo de cobernetes o no, esto sería un punto tener, y lo otro es que si tienes todo tu paglan en azur devol y algún día quieres cambiar a otro cloud pues vas a tener que crear vas a tener que migrar todos estos paglans mientras si es argosid y tecton es una solución abierta donde siempre te va a funcionar yo no tanto también me dice de en qué punto tenemos de mirar de github actions con commandos bash para crear proyectos open source bueno son diferentes, github actions como digo son acciones que se pasan en la infraestructura de gith y luego hacen cosas te sincronizas mientras que con tecton y argosid siempre lo tienes una propia máquina donde se van a ejecutar veo que hay una pregunta de dio que dice por qué es una buena práctica es una buena práctica porque al final lo que eres una tecnología diríamos que usa cgroups cgroups, perdón y cgroups dependerá de la implementación también de el kernel que se está ejecutando o de la distribución de Linux el proceso de build puede pasar de una forma o de otra no digo que por un ejemplo normal de un pasenada seguramente no pasa nada, pero un ejemplo es mucho más complejo donde empezamos a usar tecnología más específica de Linux porque recordamos que al final un contenedor no deja de ser Linux veremos qué o nos podríamos encontrar con problemas de compatibilidad entre distribuciones entre gernos por tanto es importante siempre construirlo en el mismo kernel donde se van a ejecutar y también tenemos que ver que hay algunas corporaciones que aún no no optaron para abrir su código entonces muchos de los proyectos Enterprise tal vez tal vez usen un Git privado entonces hay muchos escenarios para el público Enterprise y la última es de Jonathan que ofrece un concepto en hardware que es de Jenkins bueno es que mantener plugins de Jenkins es bastante doloroso seguro que todo el mundo no nos ha encontrado una vez que hemos utilizado un plugin y ha habido otras cosas que han dejado de funcionar o que ha actualizado un plugin y por dependencia de plugins pues ha habido pues toda una cascada de actualizaciones contacto no, siempre va a ser todo ejecutado en el mismo contenedor y un pipeline que se ha ejecutado ahora y hay una última de Diego ya le he respondido perfecto entonces muchas gracias Alex y después por lo corto tiempo que tenemos pero aun así fue muy buena la presentación muchas gracias a vosotros adios