 Cristian Roldán, trabajo para Produán. Generalmente cuando me invitan a una presentación suelo hacer una introducción de qué es Produán. Lo veas en bien corto. Produán es una empresa del grupo Santander, operamos todos los sistemas del grupo y desde hace unos meses estamos en una transformación. Produán se va a unificar con otra empresa del grupo Santander y seguramente dentro de unos meses pasaremos a ser Santander Global Technology. Así que bueno, voy a comenzar con mi longa, ¿vale? Bien. A mí lo que me gustaría es hablar de hacer un poco de historia. ¿Cómo hemos llegado hasta aquí? A partir de los últimos 4 años y bueno pues creo que ahí es muy importante, es muy muy interesante. Hemos comenzado en esta tecnología del PAS con OpenSYS version 2. Hemos empezado con OpenSYS Online a trabajar, a hacer pruebas, a desplegar aplicaciones monolíticas, aplicaciones que teníamos en Westfield. Empezamos bueno a ver qué tal se comportan esas aplicaciones en un entorno público y en un entorno PAS. Luego más o menos para mayo del 2014 aparece la primer versión GA de Docker. Nosotros ya veníamos trabajando con una versión alfa, una versión beta y realmente ahí tuvimos un cambio muy importante. Vimos que esa tecnología era muy prometedora, era tremendamente prometedora y supimos que ese tenía que hacer nuestro camino. Veníamos trabajando con aplicaciones virtuales, gestionar, crear, mantener una aplicación virtual, era tremendamente costoso en el que tenían que intervenir varios grupos, sin embargo con temas de Docker toda esa gestión se simplificaba enormemente. Vimos más o menos por agosto de 2014 que esas aplicaciones que teníamos en el entorno de Westfield, aplicaciones monolíticas muy grandes eran realmente complejas gestionarlas en un entorno de PAS. Y ahí apareció el tema de microservicios, empezamos a jugar con Spring Boot y nos dimos cuenta sobre todas las áreas de arquitectura y de desarrollo que esa tecnología de Spring era muy prometedora, era hacia dónde teníamos que orientar nuestros diseños. Esa tecnología vimos que se adaptaba perfectamente al entorno clado, al entorno de PAS y en ese entonces decidimos que las aplicaciones monolíticas no las íbamos a mirar al PAS, sino que se iba a hacer una re-ingeniería o directamente se iba a diseñar desde cero en una arquitectura de microservicios. Más o menos por octubre, noviembre del 2014 empezamos a trabajar con Cloud Foundry. ¿Alguien ha trabajado con Cloud Foundry aquí? O un Pivotal? Excelente. Bien, ese producto cuando lo instalamos on-premise nos cambió la cabeza completamente. Aprendimos muchísimo utilizando on-premise Cloud Foundry, y sobre todo nos abrió la cabeza en el sentido de cómo teníamos que gestionar un entorno Cloud on-premise. Lo que nos han comentado recién de la consola de operación de Tectonic, la consola de operación que va a tener las futuras versiones OpenShift, pues en Cloud Foundry esas funcionalidades ya existían. Entonces por eso Cloud Foundry a nosotros nos abrió la cabeza. Para nosotros fue un hito muy importante, trabajamos en esa herramienta, pero nosotros lo que creamos es un PAS basado en Docker. Esa era nuestro objetivo. Más o menos en el, a principio del 2015, ProDuan pone productivo unías privado. Unías privado basado en OpenStack. Y al principio del 2016 se pone productivo el primer PAS que le hemos llamado Global PAS y luego vamos a ver de qué se trata. Global PAS en versión uno y está basado en OpenShift. No está basado en Cloud Foundry, en OpenShift. Y por qué hemos decidido OpenShift una decisión bastante compleja, pero la visión que tuvo Red Hat era la que nosotros necesitábamos. Esa visión, teníamos una visión muy compartida, sabíamos que teníamos que ir a un orquestador de contenedores, queríamos Docker, porque sabíamos que esa era nuestro camino. Y eso fue el motivo por el cual nos decantamos para principios del 2016 brindar un servicio global de PAS para el grupo. Y bueno, y al principio del 2018 se ha decidido, nosotros cada dos años se hace el análisis, se revalida en las estrategias y se ha decidido empezar con la versión 2 de nuestra tecnología Cloud y bueno pues el PAS comenzaremos en breve a desplegar en distintas geografías el PAS versión 2 que está basado básicamente en OpenShift 3.9 sobre VMware. Muy bien, esta de nuestra historia realmente hay más hitos importantes pero en un solo slide creo que resumen bastante bien cómo hemos llegado hasta agosto del 2018. Bien, ¿qué es el PAS versión 1? Es decir, ¿cuáles fueron los requisitos para diseñar el PAS versión 1? O fueron los requisitos son básicamente estos y son, parecen simples pero no son nada simples. Primero, lo que se ha decidido es que teníamos que diseñar e implementar una plataforma al estilo Heroku. ¿Alguien conoce Heroku de aquí? Ah, unos cuantos, vale. Entonces bueno, pues lo teníamos que diseñar algo parecido a Heroku, un servicio global que pueda ser consumido por distintas entidades y bueno eso fue el requisito principal y luego había otras series de requisitos que teníamos que cumplir como por ejemplo teníamos que estar basados en contenedores. Nosotros supimos más o menos en el 2015 que nuestra estrategia de PAS, de plataforma, tenía que estar basado en contenedores. En ese entonces la única implementación de contenedores que había era Docker, ¿vale? Pero ese es otro requisito muy importante, tiene que estar basado en contenedores. El otro punto es autoservicio, teníamos que brindar una serie de portales de autoservicio para que cualquier desarrollador o cualquier DevOps o administrador de las aplicaciones mediante un portal o mediante un cliente pudiera gestionar absolutamente todo el ciclo de su aplicación. Otro punto que nos han planteado es mejorar la utilización de los recursos. Por eso fuimos a un entorno global, agilidad, ¿sí? Es otro de los aspectos que hemos logrado también, orientado DevOps. Básicamente todo lo que hemos hecho es para los DevOps, esa es la realidad. Luego hemos hablado de una serie de herramientas alrededor de OpenShift que hemos diseñado para los DevOps para mejorar el ciclo de vida de las aplicaciones. Esta solución de PAS también tiene que estar pensada para la escalabilidad. Las aplicaciones tienen que escalar muy fácilmente y la infraestructura tiene que estar preparada para escalar muy fácilmente. En versión 3.0 de OpenShift, todos estos requisitos eran un gran reto. Con la versión nueva de Red Hat, pues de caja prácticamente todo esto se soluciona muy fácilmente. Pero en ese entonces todos estos requisitos realmente fueron un reto impresionante para nosotros. ¿Qué más? La solución de PAS tiene que soportar distintos proveedores de IaaS. Como he dicho, hemos comenzado con OpenStack y estamos desplegando en otros proveedores como en Azure. Hemos desplegado también nuestra solución en Azure y pronto iremos a más proveedores. Porque la versión 2 del cloud básicamente es una cloud híbrida. El diseño nativo es híbrido, mal de la nuestra solución. Y después otros puntos que nos habían planteado es que tenemos que tener la capacidad, tenemos que brindar la capacidad de poder desplegar cualquier tipo de runtime, middleware o backend. En el entorno tradicional nosotros teníamos absolutamente todo en Westfield, en la piqueación server de Westfield. Y aquí nos dijeron, bueno pues queremos, como queremos agilizar el time to market, queremos renovar las aplicaciones pues tenemos que ir a otros tipos de runtime. Si bien prácticamente el 80% de las aplicaciones son Java, pero los clientes ya estaban necesitando otro tipo de runtime. Bien, y eso fue uno de los requisitos. Y estos requisitos pues dio nacimiento a lo que nosotros lo hemos llamado el global pass. Global pass básicamente porque es un servicio global. Al estilo Heroku, OpenSafe Online, Pivotal, Web Services, es un servicio global que se ejecuta, ahora vamos a ver en dónde, en qué datacenters, pero brindan servicios a todas las entidades. Entonces la arquitectura del global pass está basado en OpenShift principalmente, luego a nivel de IaaS usamos OpenStack y para toda la gestión de las redes virtuales usamos una SDN, es de Noash y también lo que vimos en ese entonces que para diseñar un servicio ágil productivo y que pueda competir con proveedores públicos como Heroku, nuestra meta siempre fue hacer algo similar a Heroku. Es imposible realmente hacer algo similar a Heroku porque de un punto de vista es un servicio extraordinario, pero nuestra meta era parecernos, acercarnos lo máximo posible a Heroku. Entonces nosotros dijimos, bueno, si tenemos que parecer al que es el padre de esta tecnología, pues tenemos que diseñar una serie de servicios de valor añadido para agilizar los desarrollos como la gestión de las aplicaciones. Luego vamos a hablar de qué hemos desarrollado, ¿vale? Muy bien, esta es la arquitectura de nuestro pass en OpenStack, tenemos tres, a ver por aquí, donde está. ¿Es este? Sí, bueno, se ve algo, no, ahí el, tenemos tres acetas en OpenStack, tenemos una serie de componentes, cada componente está en su propia subred y bueno tenemos una capa de balanceo, aquí balanceamos el API, la consola, las aplicaciones, herramienta de gestión, todo pasa por esta capa de balanceo, luego tenemos tres masters, una cosa importante, todas nuestras regiones del paso son idénticas, es decir, esta arquitectura es idéntica en todas las regiones. Bien, tenemos tres masters, tenemos una capa de nodo de infraestructura, aquí ejecutamos en esta capa de infra ejecutamos los routers como las herramientas de monitorización, la solución de monitorización hacular que viene con OpenShift. Luego tenemos una cantidad muy importante de nodos de cómputos, luego veremos cuántos, una capa de estoras para brindar los servicios de presistencia de volúmenes, luego tenemos unos cuantos, unos cuantas VMs encargadas de la gestión, aquí es donde nosotros tenemos el Samp Host, tenemos las herramientas de monitorización de la infraestructura, en fin, tenemos unas cuantas máquinas para gestionar todo este cluster completo del global pass. Luego también brindamos a nuestros clientes una solución de monitorización pero para la capa de aplicaciones, no de infraestructura del pass, sino de las aplicaciones. Aquí nosotros usamos Wild Introscope, venimos con Wild Introscope, es de SA, es una herramienta de código privado, pero bueno en el mundo tradicional es una herramienta que tiene mucha presencia dentro del grupo, entonces para facilitar pruebas de carga, para facilitar pruebas muy puntuales, nosotros hemos brindado este servicio de monitorización y todas nuestras imágenes corporativas pues ya tienen enbebido el agente de monitorización. Y luego también hemos instalado un Data Lake para el pass. ¿Y qué hacemos con este Data Lake? Pues básicamente guardamos todos los logs que generan los contenedores de nuestros clientes, los guardamos en este Data Lake, todo el log de acceso que se genera, que generan los routers, lo guardamos en este Data Lake y todos los eventos de OpenShift también se almacenan en este Data Lake. Y luego mediante unos dashboard de equivana, los usuarios pueden consultar en un modo multitenan, puede consultar sus logs, los logs de acceso, quien accedió con que IP, que router atendió esta petición, que contenedor procesó esa petición, cuánto ha tardado el contenedor, en fin, brindamos información muy, muy detallada de todo lo que entra por los routers. Bien, como puedes ver aquí, nosotros usamos un ALM, tenemos una solución de ALM, tenemos dos versiones de ALM, la versión 1 y la versión 2, la versión 2 está muy focalizada para la cloud 2.0 y yo creo que es interesante mencionar que no utilizamos ni image stream, ni build config, esas soluciones que vienen de caja, ni el yankings que viene integrado en OpenShift, no los utilizamos, ¿por qué no lo utilizamos? Porque aquí tenemos una solución exclusiva de construcción de imágenes y de aplicaciones. Y este ALM lo que hace tiene un pipeline específico para desplegar en el PAS, inclusive no en una región, sino en varias, eso depende del administrador de la aplicación, él decide en qué regiones despliega sus aplicaciones. Entonces, todo ese conjunto de herramientas para acompañar el ciclo de vidas a aplicaciones se brinda desde este ALM y no desde OpenShift, desde dentro de OpenShift con las herramientas de OpenShift. Otro punto que hemos tenido que desarrollar nosotros es la parte de charback, inicialmente OpenShift, si querías ese tipo de información, tenías que irte al CloudForms y bueno, pues vimos que el CloudForm es entonces, eran básicamente, nos brindaban reportes dashboard de uso, esto y el otro, pero realmente no nos permitía gestionar el cluster de OpenShift. Entonces, realmente instalar un producto complejo como el CloudForms, no sé lo que hemos decidido, es, mira, vamos a hacer un este módulo, consultamos mediante API REST al API de OpenShift y obtenemos el uso de los distintos recursos que hacen todos los proyectos. Y otra cosa interesante que hace este módulo es, se viene a la monitorización dice, a ver, este proyecto, ¿cuántos agentes tiene, tiene instanciado? Perfecto, venga, y se anota ahí en la agenda. Y después, bueno, hacemos, vamos también al registry y le decimos, a ver, este proyecto, ¿qué imágenes está utilizando? ¿Esas imágenes tienen coste, sí o no? Bueno, todo eso lo dejamos registrado. Entonces, lo que vimos es que CloudForm, ese tipo de información tan personalizada, pues no lo brindaba, ¿vale? Bien, luego nuestra arquitectura consume servicios que nos da la infraestructura IaaS, utilizamos NTP, DNS, el IPA, en fin, el Satellite, y bueno, pues estos son servicios que lo brindan otro grupo y lo tenemos instanciado en todas las regiones. Y también lo que tenemos es, tenemos un LDAP corporativo, todos los usuarios están registrados en este edad corporativo y también tenemos los grupos, la definición de grupos, sincronizamos grupos que están almacenados en LDAP, lo sincronizamos hacia el OpenShift y por último mencionar que el docker registry, que por cierto, el docker registry de Quay es excelente. Lo quería comentar porque lo hemos probado, pero al final no lo hemos usado, pero sí que es un docker registry que si tenés la oportunidad de usarlo, la verdad que funciona tremendamente bien. Nosotros, cuando se diseñó esta arquitectura, todo tenía que ser OpenSource, es un nuevo requerimiento que yo no lo puse en la presentación, pero la dirección nos trajó esa necesidad de que todo lo que hagamos tenía que ser OpenSource y todo lo que hagamos lo teníamos que publicar GitHub. Entonces, bueno, entonces lo que hemos decidido aquí a nivel del docker registry es utilizar hardware, no sé si alguien lo conoce, hardware de VMware. Es un proyecto OpenSource para la gestión de las imágenes. Desde hace dos días la Cloud Native Compute Foundation la adoptó hace dos días que ya pertenece a la fundación y bueno pues OpenShift al principio no brindaba una solución de docker registry, no me acuerdo si a partir de 3.3, a partir de ahí empezó a brindar ese servicio, pero a su vez ese docker registry que brindaba no cubría todas nuestras necesidades, nosotros tenemos 10 regiones de OpenShift, entonces las imágenes corporativas las tenemos que sincronizar entre todas las regiones, entonces el docker registry integrado pues no brindaba esas capacidades. A su vez tenemos clientes que usan el docker registry pero que no son clientes del PAS, que eso lo que hacen es desplegar contenedores en algún rel que está a quién sabe dónde, pero no está gestionado ni por su arm, ni por mesos, ni por OpenShift, entonces nosotros tenemos que dar servicio también a esos clientes y por ese motivo decidimos utilizar hardware y lo seguimos usando y en las futuras versiones también usaremos hardware. Muy bien, esta es nuestra arquitectura, es la que tenemos actualmente, esta es la versión 1. ¿Qué productos componen esta arquitectura? Bien, hardware como he comentado, usamos safe para todo el tema de almacenamiento, para la gestión de las redes, el NOAS es un SDN, está integrado con OpenStack, ¿Qué más usamos para toda parte de Data Lake? Usamos Hortonworks y estos son los elementos que más utilizamos de esa solución. Luego hemos comenzado con rel 7.2, luego 7.4 y ahora estamos con rel 7.5, con la versión 3.9, etcd lógicamente, no nos queda otra, etcd OpenStack, luego vamos a hablar de una solución de monitorización, aquí nos comentó en la sesión anterior que la consola de Tectonic nos empieza a dar métricas de uso de OpenShift, pues eso en las versiones anteriores no teníamos esas capacidades, entonces nosotros lo que tuvimos que hacer y a su vez nuestros proveedores de herramientas y monitorización, el tema de Docker al principio les ha costado arrancar con esa tecnología, entonces nosotros lo que tuvimos que hacer es plantear, es hacer un diseño de una solución para monitorizar los contenidos de Docker y hemos usado y seguimos usando InfluxDB y Grafana y Telegraph, OpenShift que es el corazón de toda nuestra solución, junto con Kubernetes, Docker lógicamente, por el momento nuestro gestor de contenedores es Docker, y luego vamos a hablar del futuro y vamos a ver qué otras posibilidades tenemos, monitorización es Wiley introscope y Prometheus, Prometheus lo utilizamos en este momento es para monitorizar el etcd, el etcd es fundamental saber segundo a segundo el comportamiento del etcd, porque básicamente el etcd es el corazón de Kubernetes, entonces pues ahí lo que utilizamos es Prometheus. Muy bien, estas nuestras arquitecturas son los distintos productos que utilizamos en la versión 1. Bien, ¿dónde tenemos desplegado la versión 1 del PAS? Lo tenemos en distintas geografías, en distintos países, en distintos datacenters, en UK, en España, en Brasil y en México, todas estas regiones del PAS están interconectadas por una red global del grupo que se llama GSNET y estas son todas las regiones del PAS, donde están tenemos en España exactamente, tenemos cuatro regiones, cuatro clásteres completos, en UK 2, en México 2 y en Brasil otras 2, y en total tenemos al día a día de más o menos cuando obtuve este valor hace una semana atrás de 1.500 máquinas virtuales, pero día a día vamos agregando entre una y dos máquinas virtuales nuevas en todas las regiones y desde aquí, desde estas regiones, pues brindamos servicios a los entornos de desarrollo, pre y producción. Muy bien, ¿qué más? Estos son los servicios de valor agregado que he comentado, es para dar, brindar un servicio a la altura o algo similar a Helocool, lo que tuvimos que hacer es desarrollar una serie de servicios. Entonces voy a nombrar alguno de estos servicios y de qué se trata y por qué, por qué son importantes. Primero, el GPL, le hemos llamado GPL, que es el Global PAS Logging, básicamente esto es un servicio centralizado para la gestión de logs de nuestros contenedores. Todos los logs de standard output y error que generan los contenedores lo mandamos mediante flume al data lake y luego con un dashboard de equivana se pueden consultar en un modo multitenal. Luego, por la forma de gestión de nuestro cluster, la forma en que gestionamos como un proveedor de servicios dentro del grupo, lo que hicimos es desarrollar un status page, al estilo como lo hace Amazon o como lo hace Azure, pues nosotros este es un dashboard público todo el mundo, clientes y no clientes puede consultar esta página de estado y puede ver minuto a minuto el estado del cluster de OpenShift. Entonces, si ocurre un error en una aplicación, generalmente nuestro speech es, mira si hay un error en una aplicación y todo esto está en verde, el problema de la aplicación, simple y se termina ahí y se cierra el ticket, entonces esta consola nos ha sudado enormemente a reducir y agilizar la gestión de los tickets y realmente es así, tiene una precisión casi 99%, es decir, puede ser que un 1% haya una aplicación que tenga un problema y que aquí marque todo verde, eso puede ocurrir pero realmente el 99% de los casos, si una aplicación tiene un problema generalmente es de la aplicación o de algún backend que utiliza la aplicación. ¿Qué más hemos desarrollado? Un cliente, hemos extendido el OC, necesitamos determinadas funcionalidades, hemos movido a la comunidad para que el OC tenga una arquitectura basada en plugins, ahora el OC tú puedes inyectar plugins para determinadas funcionalidades, eso es algo que pedimos nosotros, es algo que aprendimos nosotros de CloudFondry, CloudFondry en 60 o su cliente es muy extensible, le puedes desplegar plugins y bueno, desde hace un año tenemos esta capacidad de extender el OC, pero nosotros lo que hicimos en ese entonces como todavía no teníamos esas capacidades, hemos desarrollado un cliente y que nos brinda ese cliente, capacidad de hacer backup y restor en cualquier región, es decir, mover una aplicación de la región a otra es cuestión de segundos. ¿Qué más tenemos? Tenemos reportes de uso con este cliente, un almizado de un proyecto puede ver cuánta memoria está consumiendo, cuánto dinero le está costando ese proyecto y determinadas funcionalidades que no las tenemos con el OC, pues lo que hacemos es lo brindamos mediante este cliente. Luego tenemos otro servicio que es el global pass access log, que aquí almacenamos el log de acceso, todo lo que pasa, toda petición que pasa a través de routers se registra en este servicio y se puede consultar mediante un Kibana. Otro producto o servicio que hemos desarrollado es el global pass operation framework, básicamente nosotros cuando definimos qué tenía que ser el global pass, nos dimos cuenta que hacer una gestión de ese pass a modo tradicional imposible, que lo teníamos que automatizar al 100%, tenían que estar completamente automatizado, tenían que ser idénticas esas regiones. Entonces, lo que hicimos fue diseñar esta herramienta, luego vamos a hablar qué es esta herramienta y bueno, mi esperanza es ver ciertas funcionalidades que tenemos en esta herramienta, verlo en el producto en breve. ¿Qué más hemos desarrollado? Es un portal de autoprovisionamiento para los clientes, es decir, cómo se hace el onboarding de los proyectos, cómo se hace el onboarding de los usuarios. Bien, pues hemos desarrollado un portal para que determinadas personas autorizadas, que ya tienen una línea de coste asignada para ese proyecto, puedan crear proyectos en cualquiera de las regiones. Y por último, bueno, antes último, brindamos un catálogo de imágenes corporativas, alrededor tenemos más o menos 40 imágenes que están certificadas, que están firmadas, que le hemos hecho el escaneo de vulnerabilidades, en fin, y las mantenemos nosotros, las publicamos, las actualizamos y están ahí disponibles en todas las regiones. Y este es el tema de él, el último servicio que es el Global Pass Watch, que como he comentado antes, está basado en influx, en grafana y en telegraph, lo que hacemos es, hemos forqueado el proyecto de telegraph y lo hemos transformado en multitenan. Telegraph no es multitenan por defecto. Entonces, lo que hicimos fue usar el plugin de Docker para las métricas, lo transformamos en multitenan y mediante una grafana y un token específico, tú te conectas y obtienes las métricas de Docker, todas las métricas de Docker de tu proyecto. Vale, no puedes ver las métricas de otro proyecto, solamente las que estás autorizado. Bueno, y estos son todos los servicios que hemos desarrollado para Global Pass, que son de tremenda utilidad para absolutamente todos lo que estamos detrás del pass, no solo los DevOps, sino también la gente de ingeniería como de operaciones. Muy bien, continuemos. ¿Cuál es el nivel de adopción que tenemos hoy en día? Pues a nivel de pods tenemos 35.000, seguramente hoy debemos rondarlos 36.000, puesto todos los días evoluciona de 100 pods para arriba, proyectos 4.153 proyectos en total, proyectos que de desarrollo esta cantidad de producción, de preproducción 1.480, de producción tenemos 1.426. Una cosa interesante es tenemos aplicaciones críticas desplegadas en el pass, entonces algunas de estas son aplicaciones críticas, no puedo decir cuáles, pero sí hay unas aplicaciones críticas. Y luego tenemos otro tipo de proyectos que es bastante interesante, que son los temporales. Nosotros vivimos al principio que para agilizar la adopción de esta tecnología, es decir, mover a todo un grupo hacia esta tecnología es una tarea titánica, es una tarea enorme, no es fácil convencer a la gente. Entonces lo que hicimos es crear proyectos temporales. Tú vienes a un portal del global pass y completando dos o tres datos, cualquier empleado del grupo, cualquier usuario autenticado puede crearse un proyecto. No necesita ninguna línea de coste, ninguna autorización de nadie lo puede crear y lo tiene disponible por 15 días. Y este servicio realmente ha permitido a muchos grupos dentro de muchos teams dentro del grupo Santander pues ir a esta tecnología. Resultó realmente muy útil tener esta flexibilidad de poder crear un proyecto en 10 segundos y ya tener la capacidad de desplegar aplicaciones. Y bueno, solo mencionar que en el último año hemos duplicado el número de usuarios de Vops, tenemos alrededor de 12.000 usuarios de Vops registrados en todas las regiones. Y estos son los números, son números bastante interesantes. Bien, y ahora la pregunta es ¿y cómo gestionamos todo esto? Entonces bueno, os voy a contar cómo es la gestión del PAS de estas 10 regiones que tenemos en distintas geografías. Primero, un punto importante, nosotros trabajamos de forma Shile, el grupo se ha movido a esta metodología Shile, todos los miembros del Lule Pass somos todos de Vops, absolutamente todos. Y eso ha permitido hacer este diseño tan complejo que he comentado con ese ecosistema de servicios alrededor de OpenShift. Otro punto interesante es bueno ¿y cómo gestionamos este proyecto? Porque es simple decirlo aquí, comentarlo, pero gestionar el día a día de todos esos servicios es bastante complejo, pues usamos Gira y definimos todas las tareas que están en Gira y a su vez el soporte, el soporte también los damos mediante Gira. Otro tema que hemos introducido es absolutamente todo lo guardamos en Git, si bien tenemos herramientas de uso colaborativo pero para nosotros el Git es fundamental ¿sí? Y todo está ahí, inclusive la documentación. Y luego lo que hicimos fue para gestionar técnicamente las 10 regiones y los 1000 y pico de servidores hemos diseñado esta herramienta, el Global Pass Operation Framework, que no tiene que nada que ver con la Operation Framework que acaban de comentar de Coroés ¿vale? ¿Y qué es esto el Operation Framework? Básicamente lo que hacemos es una implementación de infraestructura como código. Un caso interesante es, hace poquito tuvimos que reinstalar toda región de Brasil, pues se hizo aproximadamente en 5 horas, en 5 horas se reinstaló todos los nodos workers de OpenShift que tenían 100 y pico de nodos y eso se hizo gracias a esta herramienta, hacerlo manualmente 100 y pico sería una locura, no llevaría muchas semanas. Bien y esta herramienta que está basada es 100% Ancible. Al principio teníamos Puppet y después cuando hicimos un análisis de por dónde iba el mercado, en ese entonces justo Red Hat había adquirido Ancible y nosotros dijimos vamos por Ancile porque este es el futuro y hemos migrado todo lo que teníamos de Puppet a Ancile. Esta solución soporta varios proveedores de IaaS ¿vale? ¿Qué más tenemos? Un Jenkins Master porque no solo tú puedes ejecutar los playbooks manualmente desde una consola central sino que también tienes Jenkins para la gente de operaciones para que puedan ejecutar los Ancible de forma más amigable. Luego tenemos un par de Jamhost en todas las regiones, tenemos dos Jamhost en cada regione por si se cae uno tenemos el otro y a su vez desde ahí se pueden ejecutar Ancile y también lo que tenemos instalado es un Jenkins Slay, es decir desde el Master, desde un Master de Jenkins controlamos todas las 10 regiones del PAS. Una cosa interesante es la pregunta es ¿y por qué? ¿y por qué habéis usado Jenkins y no Randeck o Ancile Tower? Básicamente este es el secreto, el Pipeland de Jenkins ¿alguien lo conoce el Pipeland de Jenkins? Unos cuantos ¿no? Es brillante ¿no? Funciona bien es muy flexible. Entonces nosotros lo que teníamos nuestros playbooks que luego vamos a hablar en las siguientes slides algunos de ellos son muy complejos por ejemplo cuando agregamos un nodo nosotros no nos quedamos con la tarea a aprovisionos en nodo en IaaS y listo ¿no? No, no solo la aprovisiono, lo agrego el cláster de OpenShift y lo certifico. Yo cuando agrego un nodo en producción tengo que estar 100% seguro de que ese nodo no va a generar ningún tipo de problema y lo tenemos que certificar. Entonces la ejecución de todos de todos esos playbooks pues lo tenemos que hacer de forma coordinada y ahí es donde el Pipeland de Jenkins para la definición de los Warflow juega un papel fundamental. Bien ¿qué tenemos? Todos nuestros nodos, todas nuestras VMs tienen un rol asignado dentro de Ansible y a su vez hacemos uso de los metadatos ¿sí? Todo tipo de información, toda la definición de los VMs se guardan en metadatos y nosotros a partir de estos metadatos generamos los inventarios dinámicos ¿vale? Y así es como gestionamos realmente y esto a nosotros nos ha salvado la vida. En operaciones para esas 10 regiones para gestiones a 10 regiones el grupo de operaciones son tan solo 5 personas con 5 personas se gestionan esas 10 regiones y mil y pico de máquinas y eso es gracias a esta herramienta. Mi esperanza es ver algunas de estas funcionalidades en el producto. Bien otro punto interesante que nos ha permitido ser mucho más ágiles, más productivos es el tema de las Golden Image. Entonces nosotros lo que hacemos tenemos Golden Image para el nodo, definido una específica para el nodo, para el máster y para un real base y para que lo usamos para el real base por ejemplo la máquina de load balancer, la máquina del registry es un real base. Entonces nosotros ahí tenemos todas las dependencias en estas Golden Image almacenamos todas las dependencias, todas las mejores prácticas, todo lo que hemos aprendido pues lo que hacemos es regeneramos, generamos una nueva Golden Image ¿vale? Cada vez que tenemos que actualizar el PAS que luego lo vamos a hablar como es nuestro proceso de actualización lo que hacemos es generar una nueva Golden Image. Entonces cada vez que creamos una máquina nueva decimos con qué versión de Golden Image desplegamos esta máquina y nosotros no tocamos nada en la máquina, cuando entramos, cuando desplegamos la bien pues esa bien no se entra nunca, nunca tenemos que hacer ninguna tarea manual porque todo está en la Golden Image. Nosotros hemos llegado a este concepto de usar Golden Image casi simultáneamente con la gente de OpenShip Online. Nosotros hacíamos todo el despliegue on the fly, es decir desplegamos una pequeña semisita y después llegamos al satellite decirle desplígame esto, despliegue este y el otro y el otro. Lo que vivíamos es que el satellite pues no daba vasto esa versión de satellite, después hay una recomendación más adelante que habla del tema. Entonces el grupo de OpenShip Online nosotros prácticamente simultáneamente en el tiempo llegamos a conclusión que el mejor approach para gestionar esta cantidad de máquinas y soragiles teníamos que ir a un esquema de Golden Image. Otro concepto que hemos cambiado en la gestión de las máquinas es todo gestionarlo mediante ganado. Ya no hay más cotas en el mundo tradicional, cada máquina es sagrada, vale pues aquí no, cada máquina pues si no funciona y no lo logra arreglar en cinco minutos, la borro y la vuelo general. Entonces esa es la gestión que hemos cambiado, la gestión basada en ganados y básicamente cuando no funciona se evacúan los pod y la logramos reparar, la intentamos reparar y luego vamos a ver algunos playbooks de reparación, pero si no lo puedo reparar al cabo de unos pocos minutos se borra y se vuelve a generar, y esa es la forma que tenemos para gestionar. Otro punto importante que luego hablaremos de las actualizaciones, nosotros cuando diseñamos esto, lo diseñamos pensando en un servicio, como un servicio, como un productor de servicios públicos, dijimos nosotros tenemos la capacidad de actualizar el PAS o cualquier componente del PAS en momentos críticos de uso del PAS, en horarios pico tenemos que ser capaces, entonces hemos diseñado todo el PAS en función de esas premisas. Entonces toda la parte de los routers lo que vimos es que los routers como todo entre las peticiones externas entran a través del router, entonces el router es una pieza crítica en este ecosistema, entonces lo que dijimos es bueno vamos a darle una capacidad de blue green deployment de los routers y esto nos ha salvado la vida, el blue green deployment, la vida. Y como trabajamos internamente, aparte de Selasize, DevOps, etcétera, utilizamos Telegram, usamos canales Slack y unas cosas muy interesantes que tenemos unos bots para alertados que nos llegan a nuestro grupo y se mira esta máquina que está un pelín fastidiada o ha superado un umbral tal y otras cosas que hemos avanzado es en comandos de reparación, desde el canal de Slack decimos repárame esto y lo que hace ese comando es ir al Jenkins y decirle ejecuta tal playbook de reparación y esto nos ha permitido ser mucho más ágiles. Hace un par de días un compañero que es rumano, mientras estaba ahí en la carretera haciendo arrumanía a visitar a su familia pues le llegó una alerta y se metió en el canal de Slack y pudo reparar ese nodo estando arriba del coche y esa es la forma que nosotros nos permite este tipo de herramientas nos permite mejorar el servicio y sobre todo ser más ágiles. Bien, estos son los playbooks que tenemos que desarrollar, que mi esperanza vuelvo a repetirlo es algún día ver esta serie de servicios dentro del producto. Bueno, tenemos para lo que son distintas categorías de host, monitorización, big data, storage, utilidades, routers, tenemos por ejemplo agregar un nodo de activar y desactivar la VM, aplicar un rol específico a una máquina, borrar la VM, certificar el nodo, este es un playbook súper complejo porque lo que hace es despliega un proyecto en ese nodo, el nodo se agrega con una etiqueta temporal específica, no se pone productivo todavía ese nodo, se despliegan una serie de aplicaciones de certificación, a su vez una de esas aplicaciones, uno de esos deployment config utilizan volumen persistente, también variamos el volumen persistente, se conecta a distintos puntos para ver temas de conectividad, para ver si funciona el CDN, etcétera y si todo va bien ese nodo automáticamente se pone productivo. Este playbook por nosotros es fundamental. Otros temas es el tema del parcheo, por temas de riesgo nos obligan todos los meses a parchear, absolutamente todas las VMs del grupo, entonces bueno pues aquí lo que hacemos es parcheamos el sistema operativo, no el OpenShift, el sistema operativo, luego vamos a ver la actualización de OpenShift como se hace, esta es la reparación del nodo, muchos de nuestros nodos ahora mismo estamos usando device mapper, device mapper pues a veces quiere tomarse vacaciones, no sabemos bien por qué motivo pero lo que ocurre es que puede llegar a tener un tipo de problema y lo que tenemos que hacer es básicamente la reparación es, consiste en parar ese demonio de docker y borrar absolutamente todos los dispositivos de device mapper y borrar todas las imágenes que están cacheadas en ese nodo. Después que más tenemos cosas interesantes por ejemplo la sincronización con la cmdb, suscribir un nodo con el satélite, retiquetar las VMs, en fin tenemos unos cuantos playbooks y en fin y el más interesante según uno de los interesantes es el tema de router que he comentado que lo hemos definido un componente crítico en esta solución es el router se despliega siempre automáticamente, nada manual, si para minimizar los errores todo router se tiene que desplegar mediante mediante el lienkins o directamente tipiando la línea de comando en ansio y una cosa interesante es el traffic switch, una vez que certificamos que ese router que hemos desplegado una vez que certificamos que funciona correctamente que no tiene problemas que los logs no hay cosas extrañas lo que hacemos es es movemos todo el tráfico del router viejo al router nuevo y esto lo hacemos en hora en hora pico, entonces esas son son herramientas que a nosotros nos han facilitado enormemente la vida por ejemplo si no sabemos si el blue o el green está activo pues aquí tenemos otra funcionalidad que nos dice quién está activo. Bien y ahora la otra pregunta es ¿y cómo actualizamos un cluster de ciento y pico de nodos? No sólo lo que vimos es que los playboots de que venía con OpenShift podían ponernos en riesgo, podían afectar la disponibilidad del cluster y a su vez la estrategia del rollback no estaba muy bien definida, entonces lo que dijimos es ok venga vamos a definir cuál es la estrategia de actualización y estos son los requisitos cuando lo definimos, entonces primero poder actualizar en cualquier momento en hora en pico inclusive una estrategia de blue green deployment de los load balancer y de los routers y luego vamos a una estrategia de recreación de nodos y esto es interesante tener en cuenta directamente borramos todos los nodos viejos y volvemos a desplegar vale y eso ha mejorado radicalmente en el sentido de que muchas veces cuando tú arrastras un nodo viejo siempre te van quedando cosas antiguas y después al cabo de 5 o 6 meses aparecen problemas y dice ¿y estos problemas de qué son? Son cosas de hace 7 o 8 meses que has dejado por ahí vale entonces nosotros en base a la golden image lo que hacemos es regeneramos absolutamente todos los nodos por el momento es una solución semiautomática la podemos automatizar el 100 por ciento pero bueno por el momento de semiautomática y unas cosas interesantes tenemos una estrategia de rollback perfectamente definida y luego como he comentado no usamos los los playboot de offensive no los estamos usando y otro punto a tener en cuenta es hasta la versión 3.9 esto es válido a partir de las 3.9 tenemos que cambiar la estrategia ¿por qué? porque básicamente offensive no va a soportar más la actualización manual vale así que esto nos tocará dentro de poco tener que re-deseniarlo bien y otro punto interesante es durante la actualización vamos a a tener nodos en dos versiones y eso sí que está soportado por OpenShift entonces tenemos tres fases principales la fase de preparación que más o menos lleva 10 días y que significa preparar bueno es hacer todas las tareas dentro del satellite genera las content views activación kits etcétera etcétera genera Golden Image certificarlas luego certificar absolutamente todo el ecosistema nuestro es el portal de autoprovisionamiento probar algunas imágenes críticas en fin todo eso lo tenemos que volver a certificar porque pueden haber diferencias y sí que las hay a veces entonces mi recomendación es eso que después vamos a ver unas recomendaciones es cuidadín con con las actualizaciones que más que más hacemos aprovisionamos a nivel de máquina virtual aprovisionamos máquinas bien de infraestructura y workers nods entonces bueno pues nos adelantamos y ya aprovisionamos no las agregamos el cluster aprovisionamos luego viene una fase que la más crítica que es la actualización de los másteres y los nodos de infraestructura y aquí lo que hacemos es básicamente un new update de los másteres gracias a dios nunca hemos tenido problemas pero esta la fase más crítica y suele durar cinco horas en cada cluster luego que hacemos los nodos de infra que se están previamente aprovisionados los agregamos al cluster y los certificamos desplegamos los routers y certificamos los routers desplegamos el jácula el jácula es fundamental sobre todo para el tema auto escalado si tú no si tú si tú has definido regla auto escalado y no tienes el jácula no van a poder auto escalar y si todo va bien hacemos el traffic switch switchamos del del router viejo al nuevo y aquí es donde empiezan a caer algunas gotitas de sudor pero gracias a dios al jepov todo esto está perfectamente controlado ha surgido problemas pues no nunca hemos tenido problemas esa es la realidad todo siempre ha funcionado ha funcionado muy bien bajo este esquema de actualización y luego viene una fase que es menos crítica que es una fase de actualizar los nodos que básicamente actualizar es es es marcar el nodo viejo marcarlo como no es que duleable agregar uno nuevo y mover todos los pods del viejo al nuevo y eso dependiendo dependiendo de cómo negociemos con cada uno de los clientes de las regiones lo podemos hacer más menos agresivo vale pero bueno en realidad para un cluster de ciento y pico se puede tardar entre tres y diez días vale y así como hemos actualizado este proceso de actualización nunca hemos tenido un incidente me quedan seis minutos madre mía creo que no voy a llegar cómo vamos de cafeína en la sangre poco mucho bien ésta es la famosa status page como hizo una introducción hace un ratito atrás y básicamente mostramos el estado de todos nuestros componentes se actualiza cada minuto y bueno medimos el api medimos los balancers lo tenemos robots de despliegue que bueno lo que hacen es un uso intensivo del api y miden el estado del api de opensiv y también tenemos unos canales unos canales son unas aplicaciones que están inclusive desplegadas en internet están desplegadas en intranet y vamos midiendo el tiempo de respuesta de todos estos canales y luego tenemos información detallada de cada uno de los nodos básicamente a zona esto nos ha servido para decir si esto está en verde la infraestructura del pas funciona perfectamente bien y el tema es y ahora cómo estamos organizados para para hacer la ingeniería y la operación de todo esto de las 10 regiones y de las nuevas versiones antiguamente a bueno antiguamente hace 10 meses atrás hasta hace 10 meses atrás la operación la ingeniería estaba bajo mi responsabilidad y desde hace 10 meses nos hemos esto ha tomado tal nivel dentro del grupo que se ha dividido lo se ha dividido el el se ha dividido este tema en dos áreas principales en operaciones y ingeniería hay una unidad que se llama ccc que es cloud competence enter que depende directamente de corporación y y donde desde corporación donde llegan todas las estrategias donde tenemos y nosotros pues prácticamente implementamos esas estrategias ahora yo estoy como responsable de la ingeniería hay otro grupo de operaciones realmente aquí puse dos cajitas para hacerlo más pequeños de gráficos pero realmente dentro de operaciones tenemos mucho más grupos y dentro del ccc hay mucho más grupos el cc lo que hace es es está encargado de todos los servicios cloud del grupo y dentro de ingeniería tenemos grupos para el paz que es eso soy responsable de ese grupo tenemos para el tema del m tenemos para el tema de lias para el tema de data lake en fin hay mucho más grupo pero bueno quise resumir esta organización y en este grupo que con qué gente contamos que en qué especialista tenemos tres consultores de red hat un arquitecto de red hat a tiempo parcial tenemos un tam de red hat tenemos un integrador de ansible que lo que se encarga este integrador es básicamente marca las directrices de cómo tenemos que generar código ansible y en lo que se se encarga es de integrar todo el código que generamos todos nosotros vale que más tenemos tenemos un ingeniero señor de paz esto es una una persona que está trabajando nosotros una persona brillante que conoce esta tecnología clafondri como el paz lo conoce a la perfección e tenemos una persona encargada de mantener el catálogo de imágenes corporativas de docker y luego tenemos un product owner que se encarga de negociar todo con todo el mundo y luego un servicio especialista que es la persona que bueno que se encarga un poco de definir el servicio del paz no están temas técnicos pero sin definir el servicio del paz porque a partir de la definición del servicio luego viene la implementación que es lo que hacemos el resto de personas que estamos en y cómo trabajamos con la gente de operaciones pues el trato es muy cordial porque realmente está la gente que antes estaba en mi grupo y qué es lo que nosotros entregamos a ellos bueno pues básicamente el placer de ansible todos nosotros lo que hacemos producir placer de ansible principalmente que más que más entregamos pues guías de referencia de cómo operar el paz de cómo instalar una versión nueva de cómo actualizar el openshift documentación de arquitectura documento definición de servicios las imágenes corporativas se les entregamos para que sean publicados en los docker registry los templos de openshift también nosotros nos encargamos de generar los templos de openshift somos un soporte de segundo nivel y bueno y trabajamos principalmente conjuntamente en las instalaciones nuevas como las actualizaciones nuevas y ahí hacemos una especie de skill transfer y luego otra de nuestra responsabilidad es publicar todos los documentos de buenas prácticas y todo lo que se pone en ese documento es sagrado vale y todas aplicaciones se tienen que adaptar a esa guía de buenas prácticas vale y así es como estamos organizados básicamente lo importante aquí en mencionar es que hay un grupo de ingeniería y un grupo de operaciones bien y ahora vamos a hablar de KPI cómo medimos cómo medimos el uso del paz o cómo medimos cómo está funcionando el paz o cómo fue adoptado el paz o cómo está siendo adoptado el paz bueno tenemos varias KPI son todas públicas si las puede las puedes las puede consultar cualquier persona ajena al paz tenemos de porcentaje de utilización de las del entorno de producción como de no producción y lo importante aquí en mencionar es que una vez que pasa el 70 por ciento el porcentaje de utilización automáticamente creamos un nodo nuevo si es tan simple como eso luego tenemos otros muy interesantes estas que pedís muy interesantes es el tiempo de respuesta del del canari como el tiempo de respuesta del api fíjate que al canari me dice mira cristian tienes un problema acá este pico me dice mira tienes un problema y verdaderamente la verdad había un problema tenemos problemas con un nodo y este nodo nos generaba este pico entonces para nosotros y nuestros clientes lo que hacen es consultar a diario estas estas capéis luego que más tenemos el tiempo de respuesta del api aquí el api nos estaba también generando cierto ruido vale que más medimos el patrón de conexión cuántas conexiones concurrentes tenemos y cómo es el patrón si cómo se conectan cómo es a través de un día entero es el patrón de conexión que más medimos el uso del docker registry si la cantidad de pods por ejemplo aquí vemos una bajada importante eso es eso es a raíz de que se han movido un montón de contenedores de una región a otra vale pero bueno aquí medimos cómo como usan nuestros clientes el docker registry como podemos observar tenemos alrededor de seis mil y pico de imágenes vale de tags eso es la cantidad de proyectos de una sola región estos estas capéis son por región tenemos 10 en total vale y aquí medimos la cantidad de proyectos por sitios temporales y el uso medio de memoria de los proyectos y estas otras capa y muy interesante que se lo verá el performance que básicamente no es no es un s lea pero lo que sí medimos hemos identificado alrededor de 15 métricas críticas y de esas que tenemos el tiempo de respuesta y la disponibilidad de la métrica y en función de eso las alandemos un poquito y mediante una fórmula un poquito compleja que hemos diseñado cada métrica tiene un peso y eso nos da el estado de salud minuto a minuto del paz por ejemplo un 99.5 del punto vista del s lea es bastante bajo pero aquí lo que significa que el servicio el servicio es muy bueno porque no es un s lea esto no nos pero cualquier variación mínima por ejemplo una actualización de opensiv y si aquí vemos que bajamos de estos umbrales sabemos que esa versión algo tiene algo de ruido está generando vale entonces esto es esta esta capa y lo usamos internamente la gente de operación de ingeniería como para ver pequeñas variaciones que a nivel de aplicación no se nota la aplicación se pierde vale bien he comentado del del paz que hemos evolucionado que fue el primer slide y ahora llegamos al paz versión 2 pas versión 2 está basado principalmente en el en la clau 2 y que tiene de bueno el el el pás versión 2 opensiv si es siendo el centro de universo en el pás versión 2 luego está basado en un nias privado versión 2 pero el paz que tiene interesante es vamos a empezar a dar el servicio de cluster dedicado que significa eso que algún cliente mediante marketplace va a decir quiero un cluster dedicado para mí solito vale y esta es una una ventaja importante respecto al modelo global que tenemos actualmente va a estar basado en 39 si bien salió opensiv 310 a ayer o antes de ayer pero nosotros hemos certificado 39 con Kubernetes 1 9 vale vamos a tener volúmenes presintentes distintos flavors distintos sabores de los volúmenes persistentes en fs y basados de visan otro punto importantísimo es la micro sementación una cosa que no he comentado es nuestra solución es multitenan el global paz es multitenan y y esa capacidad de multitenan si lo hacíamos mediante el plugin de multitenan y ahora lo que hemos hecho en esta versión en esta arquitectura nueva es basar basamos en micro sementación y que usamos pues usamos en el volu polisí egres polisí y hemos creado un rol específico para gestionar todos los temas de micro sementación y este rol recae en el grupo de seguridad del del del grupo que otras cosas hemos mejorado temas de seguridad si hemos hecho ahí algunas pequeñas mejoras hemos recortado todas las capabilities prácticamente no dejamos hacer nada están seguro que no dejamos hacer nada inclusive hemos agregado alguna hemos quitado unas capabilities más de las que viene por defecto con openshift vamos a hacer un uso muy intensivo de marketplace el service catalogue para nosotros es una pieza fundamental como el service broker vale alguien conoce lo que es el service broker alguien lo ha utilizado no si bien nosotros hemos aprendido este concepto del service broker que es un concepto brisante lo hemos aprendido en pivota y siempre hemos empujado desde que lo aprendimos hemos empujado a red card como a google a adoptar esta tecnología y red card no se escuchó y le gustó la idea y red card movió a google para ir en esta en ir hacia esa tecnología vale y bueno es muy interesante explorar lo recomiendo que más está basada en estrés cláster de bienbuer luego el corazón delías 2 es una clado híbrida y otro aspecto interesante es el aislamiento vamos a mejorar el tema de aislamiento entre entornos que básicamente son cláster cláster distintos para algunos de esos entornos y bueno esa es esa es el pas versión 2 que dentro de unos días ya empezamos a desplegar en todas las regiones y ahora nos toca hablar un poco de recomendaciones a raíz de en los últimos años hemos aprendido algunas cuantas cositas y bueno voy a tratar de hacer rápido porque ya creo que me recontra pase el etcd he dicho es el corazón de todo es fundamental tenemos que monitorizar monitorear o como le queráis llamar el etcd es fundamental si el etcd empieza a estornudar seguramente nuestro cláster va a tener la gripe a vale entonces mi mi consejo es mirar bien de cerca qué le pasa a la tcd y utilizar discos es es es es es es fundamental es fundamental yo lo puse primero esta recomendación es más importante más allá que los documentos de red ja te dice eso pero bueno a veces en alguna ocasión no le hacemos tanto caso pues esta es fundamental borrar objetos viejos de tcd a ser tarea de housekeeping es también fundamental hemos tenido un problema de forma muy serio en una región que creció en muy poco tiempo y eso era a raíz de objetos viejos que quedaban que no se borraban adecuadamente planificar muy bien los los prefijos de ofensives podéis tener colisiones vale que nos ha pasado nosotros y cuando no colisionan tenés que bajar todo a pagar todo el ofensives y volver a definir los prefijos de ofensives y volver a levantar todo es decir que si no se planifica vamos a generar disponibilidad monitorear el control plane es fundamental actualizar a la última versión disponible esto es una recomendación de red hat y también es mi recomendación cada versión se corrigen muchas cosas entonces mi recomendación es intentar estar a la última versión si no si bien es una tarea muy compleja porque ya he mostrado de cómo que ahí tenemos 10 días de certificaciones de preparación es una tarea muy compleja y muy costosa pero bueno vale la pena vale la pena los routers de ofensives la versión 39 hay una mejora importante no activar el swap en las primeras versiones no decía nada el ofensives de qué hacer con el swap y por defecto lo activábamos bueno hemos tenido 10 millones de problemas hemos tenido que desactivarlo no no lo activen nunca aunque estentador a veces pero no lo activen para nada respecto al java utilizar jdk o jr19 porque a partir de esa versión si que es complian con docker entiende a docker antes no entendía docker y seguramente tú le decías dímelo toda la memoria que hay en este contenedor y te mostraba absolutamente toda la memoria del host docker y a partir de ahí de esas sobales erróneos internamente el java reconfigura hace una serie de configuraciones en función de esa información errónea que más aplicaciones monolíticas ya he comentado que no no no encajaban muy bien e usar disco de cds y se puede para para el docker para el maceramiento de docker e actualizar a a 37 y rel 74 acá y no importa una mejora muy importante respecto de ipetables cuando llegas a un nivel de 3000 4000 servicios de cubernetes el ipetables empieza a tener problemas de performance le cuesta actualizar vale y sobre todo en el modelo como el nuestro donde tenemos 12000 de bops actualizando constantemente escalando para arriba hacia abajo borrando post creando post cada una de esas tareas implica un refresh de lipetables y eso cuesta muchísimo que más actualizar el cliente o sea vale decir si me voy a 39 mi cliente o el cliente que usa el alem también tiene que estar en 39 hay pequeñas distintas versiones pequeñas diferencias que puede ser que tus automatismos dejen de funcionar usar satelites 2 esta es una de las mejores recomendaciones versiones previas vamos a tener 10 millones de problemas vale a partir de aquí funciona estupendamente estupendamente bien otra otra recomendación es ver certificar una versión concreta de openshift es decir a veces entre minor version pueden haber unas variaciones no muy bien documentadas pero puede haber variaciones en el comportamiento de openshift que haga que el resto de tu escosistema empieza a tener problemas o no sea muy compatible entonces si tu certificas la 3.9 25 a producción tiene que ir a 3.9 25 y no la 24 vale porque seguramente en algún momento pasa a tener un problema nosotros lo tuvimos y hemos aprendido esa lección otro punto interesante es a nuestros clientes le tenemos que obligar para mejorar resiliencia de aplicaciones utilizar el line es y el readyness pro les tenemos que obligar les tengo que decir mira si tu deployment config o tu deployment no viene con el no viene con el line es y redine es perfectamente definido no aceptar esa aplicación en producción porque tarde temprano vamos a tener problemas entonces nosotros hemos mejorado radicalmente la resiliencia de las aplicaciones con el line es y redines pro bien al otro punto interesante es definir el pipeline de construcción y la homologación de las imágenes corporativas o las imágenes docker y aquí cuando diseñamos esto tengo que tener cuenta varias cosas porque esto no es darle sólo al docker bil y listo no es tan simple como eso primero tenemos que definir cómo lo voy a construir luego cómo voy a hacer el escaneo de vulnerabilidades luego cómo voy a firmar digitalmente y cómo voy a comprobar la firma digital después el otro es y quién le da soporte y si surge un problema quién va a soportar esas imágenes y el otro es quién va a probar esas imágenes antes de pasarlas a producción quién va a ser el guá con qué frecuencias actualizan es otra otra pregunta que nos tenemos que hacer el etiquetado cómo vamos a etiquetar esas esas imágenes y el tema de obsolescencia es bueno pues son cosas que tenemos que ir pensando y las tenemos que definir bien si no lo que hacemos si nos definimos nos estamos hipotegando hipotecando al futuro y el otro punto es que es muy tentador en docker hay miles y miles de imágenes de imágenes de imágenes de docker algunas de ellas son de proveedores conocidos pero mi recomendación es no utilizar imágenes de proveedores que no estén adecuadamente certificados porque nos podemos encontrar con algún chiste de mal gusto bien logros bueno voy a tratar de pasarlo rápidamente pero prácticamente esta tecnología se vende sola no no hay que hablar mucho pero hemos logrado de bajar los tiempos de puesta producción y eso es cierto que más la agilidad eso se traduce en reducción de costes hemos logrado normalizar todos los entornos en el mundo tradicional el entorno de deb lo llevó un grupo el de pre otro y el producción otro en cada una de las entidades es distinto pues todos los entornos aquí son idénticos idénticos no hay diferencia y se administra desde el mismo hipo desde las mismas herramientas centralizada variedad de runtime que esto nos exigían nuestros clientes tenemos de warprez de java esprimbu no de js en chiné x tom calio en fin tenemos mucho más que esto la residencia de la aplicación es Kubernetes nos ayuda enormemente la residencia la resolución de de los problemas todos los problemas son conocidos son idénticos no nos vamos a encontrar con chistes malos en algún momento no son casi todos idénticos que más nos hemos mejorado nuestros servicios gracias al feedback de 8000 usuarios que nos dan nos nos recomiendan cosas en determinados foros nos piden nuevos servicios y luego una cosa importante es el grupo se ha movido hacia la metodología y el paz son herramientas fundamentales en esta en esta transición a nivel de cultural tenemos que entender que el paz nos va a implicar cambios y los cambios dependen de cómo vamos a usar el paz nuestro uso como he comentado es es un uso tremendo tenemos 35 mil 4 mil y pico de proyectos entonces evidentemente para nosotros eso nos trajo un cambio cultural tremendo ir a un entorno y ir a una metodología de box en un grupo grande es complejo es muy muy complejo después termados procesos internos por ejemplo a cmdb que esto es una pelea que tuve con la gente de cmdb como como registramos en el mundo tradicional registrar una aplicación se me es muy fácil mira se ejecuta en el nodo 1 y listo pero en un entorno tan dinámico como el paz esa aplicación hoy está en el 1 mañana está en el 2 pasado mañana hasta el 3 y cómo lo registro eso cambia son procesos internos que quizás una empresa pequeña esto sea una tontería pero en un grupo grande esos son cambios muy importantes la gestión hoy para atrás ahí está la gestión basado en enganado ya no tenemos más mascotas un nodo no funciona se tira se va a crear simple eso es un cambio importante cambio de roles y responsabilidades en este nuevo entorno una clara separación entre plataformas y aplicaciones antes pues había ahí una zona de grises ahora está muy claro mira está tu page está en verde está todo verde a otro lado flexibilidad esta herramienta es muy flexible vale y bueno pues hay que definir responsabilidades hay que tener en cuenta eso pago por uso nosotros no estábamos acostumbrado es decir cuando hacíamos los costes de un proyecto decíamos ah mira este proyecto significa un cláster de open ship perdón un cláster de westfield con tantos nodos y ya está el coste pues aquí distinto aquí es por la cantidad de memoria como va a escalar qué cantidad de peticiones va a tener y en ese modelo del coste para nosotros no fue no fue fácil el pasado un montón de horas discutiendo este tema e autoservicio si es todo autoservicio antes están acostumbrado de tal grupo hace tal cosa el otro grupo hace otra cosita ésta es el dns ésta es el otro pues aquí no aquí le estamos dando una serie de herramientas una serie de consolas una serie de clientitos para que alguien con determinado rol pueda hacer absolutamente todo eso y eso cambia el modelo de operación del paz eso ya le hemos hablado es un cambio radical del mundo tradicional a un mundo cloud es es radical el cambio cuesta asimilarlo nos ha costado mucho y luego otro punto interesante la evangelización divulgación es decir esta tecnología es es compleja para ese simple hacer un docker usar el docker y leerlo entenderlo es muy fácil pero ahora es y cómo despliega una aplicación cómo la escalo donde guardo la configuración donde guardo los logs cómo algún travel shooting si entonces es un cambio radical a nosotros acostumbrado durante 15 años a utilizar una tecnología una tecnología y ahora venimos a esto entonces nosotros detectamos al principio del proyecto de que la adopción de este proyecto iba a ser exitoso en medida en función de cómo íbamos nosotros a evangelizar y a divulgar y lo que hicimos fue hacer charlas workshops 15 nales a 15 días hacíamos un workshop ese workshop venían 30 40 50 personas y así estuvimos casi todo un año y este fue parte del secreto de cómo se pudo adoptar y acelerar la adopción de esta tecnología dentro del grupo bien y me he recontrapasado el futuro que estamos haciendo por el futuro que a parte del paz 2 que tenemos que empezar a despliegarlo a la en breve qué cosas tenemos que ver en el futuro tenemos que empezar a invertir tiempo en el futuro bueno se ha comentado en la presentación a anterior el josas tomic nos para nosotros es un más tenemos que lo tenemos que usar ya no quiero más más mantener golden image es muy costoso mantener a golden image porque la tenemos que generar para el stack para bien web para azure y para amazon entonces gestionar eso requiere tiempo recursos entonces nuestra idea es ir a redhat coro es queremos ir y porque no fuimos ya porque porque evidentemente hubo una transición del josas tomic y y con adquisición de coro s pues lo que estamos esperando es que un poco queden claras las reglas del juego y una vez que quede claro pues vamos a ir vamos a hacerlo es nuestra decisión ya la tenemos tomada vamos a ir a eso vale porque las mejoras son tremendas vamos a partir del 2019 tenemos que empezar a despliegar en nias públicos a actualizar con más frecuencia si si bien tenemos una metodología de actualización pero mi reto es poder actualizar con más frecuencia es empujar a operaciones que si teniendo las herramientas adecuadas que pueda actualizar más frecuentemente esta tecnología es no podemos quedarnos con un open shift hace un año atrás porque quizás funcione bien la primera el primer mes el segundo tercero pero en cuanto empiece a subir la número de peticiones y la carga empezamos a ver comportamientos no muy adecuados entonces la actualización es fundamental que más vamos a invertir mucho en lo que es monitorización basado en promesios promesos prácticamente es un estándar en el mundo cloud luego tema de policies enforcement grafías mi recomendación es mirar leer un poquito de esto de grafías que es bastante interesante estamos esperando esta versión de cubernetes la y por qué esperamos porque trae una tecnología nueva que es ip vs es decir hasta ahora los servicios de cubernetes cuando se implementan se implementan como reglas de hipetables y ya he comentado los problemas de hipetables pues aquí se soluciona y eso es importante y aquí hay un documentito muy interesante que explica toda esta toda esta historia vamos a tener por lo menos en la versión 2 30 clastres más o menos esa es es es lo que entendemos que vamos a tener y gestionar todo eso para para usar esa cantidad de regiones evidente la federación es algo importante creo también tenemos que empezar a investigar este tema porque docker avanza de una forma cubernetes avanza de otra pero a su vez cubernetes usa un porcentaje muy bajito de docker entonces lo que queremos es empezar a ver qué tal va el crallo ya que es ciudadano de primera clase en cubernetes queremos ver qué tal va con todas nuestras imágenes y con todos nuestros servicios service mesh es otra tecnología en el cual tenemos que posicionarnos todos los proveedores los que estamos viendo los poderes principales se están moviendo en esa tecnología y bueno vamos a tener que hacer algo tenemos que definir tenemos que definir cuál es la estrategia todavía no tenemos muy claro este uno punto cero e g a desde ayer desde ayer vale entonces yo que ya creo que estamos en ciertas en condiciones de empezar a teorizar por dónde tenemos que ir los proveedores como he dicho están haciendo cosas realmente muy interesante proveedores muy grandes están haciendo cosas muy interesantes la consola de administración de open ship que se hizo la introducción en la sesión anterior para nosotros es fundamental y esto lo tendría que haber puesto en rojo con bling que aparezca porque realmente lo venimos esperando desde hace muchísimo tiempo hemos invertido un montón de dinero un montón de gente para que el paz sea operable entonces tectonic creemos que va a responder a nuestras necesidades lo que me gusta lo que me ha gustado realmente cuando me enteré de la adquisición de coro s lo que me ha gustado es que coro se tiene la visión de la operación de una operación rabiosa esa visión para nosotros es fundamental porque no sólo se vive del desarrollo esto hay que operarlo tenemos aplicaciones críticas y esa visión de coro s hacia la operación siempre nos ha gustado entonces para nosotros hemos prácticamente aplaudido hemos saltado hemos tirado hemos hecho mucho ruido alrededor de este tema porque creemos como cliente nos vamos a ver muy beneficiados con esa unión de esas dos empresas y entre otras cosas tienen ingenieros brillantes que más operation framework también se ha mencionado tenemos que movilizar todos nuestros servicios a este a este esquema nuestros clientes nos están pidiendo ejecutar cualquier tipo de carga hasta ahora veníamos con aplicaciones webs pues ahora dicen uno es que quiero ejecutar mi spark lo quiero ejecutar aquí y quiero ejecutar esta esta base de datos que por ciento quizás dentro de un año sea una base de datos crítica nosotros estamos tratando de poner paños fríos a esas necesidades pero bueno nos están pidiendo esto luego el soporte de cualquier tipo de puerto tcp y udp estamos trabajando para brindar esta capacidad no es fácil en absoluto pero creemos que en algún momento lo vamos a poder dar y bueno estos son links de interés os recomiendo este link donde podés recibir noticias semanales de cubernetes de todo lo que ocurre alrededor de cubernetes a mí me ha permitido aprender muchísimo muchísimo y ver qué hace otra gente alrededor de este ecosistema que ha crecido en los últimos tres años enormemente a su vez interesantes de la fundación yo creo que aquí cada dos por tres hay que si tenéis usuarios de twitter yo os recomiendo seguir a la clave de computación estos son todos los proyectos que apadrinan entre ellos ellos apadrinan cubernetes lógicamente pero hay proyectos muy interesantes tremendamente interesantes y ya y hace dos días se sumó aquí el doc registry hardware cubernetes lógicamente openshift hemos aprendido muchísimo en muchas cosas en muchos problemas los hemos detectado ahí hemos reportado muchas cosas realmente la comunidad origin es muy muy interesante y luego estos son otros otros links bueno pues de del state metrics de de de de de cubernetes que está evolucionando muchísimo en la dirección correcta y el último mensaje es para tener un un pas saludable el secreto es automatización pero principalmente monitorización o monitorear monitorear todo pero no del punto de vista de infraestructuras sino también el punto de vista del usuario como el usuario percibe la salud del pas eso es fundamental y mi último slide y aquí determinado mi milonga muchas gracias a todos