Y este día fue el último del que disfrute conversando con diferentes personas acerca del futuro de SUSE y del futuro tecnlógico, este día como los anteriores estaba repleto de sesiones, hands-on y examenes de certificación de SUSE. Charlando con algunos me han estado contando las novedades sobre el desarrollo del depliegue de su solucion openstack, muy interesante, ya que si llegan a tiempo serán de los primeros en utilizar un despliegue basado en Kubernetes con el uso de componentes como openstack-helm y Airship (o Ironic).
En el segundo día de la SUSECON 19 estuve en un par de sesiones que me resultaron muy interesantes y también hablando con gente de desarrollo de SUSE sobre ciertas inquietudes que tenía, que seguramente se traduzcan en algún homelab. En la primera, nos presentaron una arquitectura de despliegue de infraestructura como código en la que participaban diferentes elementos, entre ellos se usaba Gitlab como repositorio de todo el código YAML que se va a usar en el SUSE Manager y por otro lado Jenkins como ejecutor via webhooks de los cambios en el código, de esta forma mediante SALT se hace el despliegue de la infraestructura.
Durante la primera semana de Abril se está celebrando en Nashville (Tennessee) el evento SUSECON 19 al que tengo el placer de poder asistir. De las más de 170 sesiones a las que poder asistir en 3 días tengo que elegir las que considero que me pueden resultar más interesantes, una tarea complicada ya que en muchas ocasiones se me solapan más de una a la que me gustaría presentarme. En este articulo os voy a contar alguna de las novedades de las que me he enterado en alguna de estas sesiones.
Las plataformas que actualmente trabajan con contenedores hacen uso de un registro de imágenes para poder realizar los despliegues, este registro puede ser público o privado. El registro publico utilizado y más famoso es DockerHub, ya que es la plataforma oficial pública para los contenedores basados en Docker. En primer lugar lo más recomendable es disponer de un registry privado que nos permita subir las imágenes que creamos nosotros sin exponer datos al público y evitar posibles brechas de seguridad.
La semana pasada se celebró el SUSE Containers Day y estuve presente para ver que novedades nos tenía preparado SUSE en el apartado de contenedores. Nos presentaron dos de sus herramientas más prometedoras (CaaSP y CaP) y luego presenciamos una demo de uno de sus partner mostrando como utilizar nginx plus como ingress-controller. Todas las charlas resultaron muy interesantes, sin embargo, hoy nos vamos a centrar en el producto de Container as a Service Platform (CaaSP), este producto nos permite desplegar una plataforma completa de kubernetes en formato multi-master, y gestionarla toda a través de una interfaz web sencilla, el tiempo para crecer en número de nodos (master o worker) se reduce significativamente dado que todo se centraliza en su dashboard llamado Velum (https://github.
Últimamente he estado creando algunos scripts que automatizan procesos en aplicaciones Android. En un primer momento comencé con el uso de la herramienta xdotool y simulando los clicks que quería ejecutar. Desde el punto de abrir la aplicación hasta el punto cerrarla y usar los propios ajustes de Android para hacer limpieza de los datos guardados por la aplicación. Tras tener todo preparado y varios intentos, me he topado con que dependía mucho de la velocidad de carga de la APP para poder hacer el siguiente click, lo que suponía errores en muchas ocasiones en las que el emulador de Android tardaba más de lo planeado.