2020-03-18 20:00
Tras haber aprendido algunos conceptos, ahora vamos a realizar un ejercicio similar al que podríamos tener que hacer en la vida real. La idea es coger una aplicación tradicional y ejecutarla de la mejor manera posible en un clúster de Kubernetes.
La aplicación elegida es Traccar, una aplicación rusa de seguimiento GPS que cumple muchos de los puntos que buscaba:
-
Es una aplicación con diferentes capas: tiene un frontal web, un backend de procesamiento y necesita una base de datos relacional para funcionar. Su frontal y su backend se encuentran acoplados en el mismo paquete.
-
Está bien mantenida por sus desarrolladores y ofrece imágenes Docker oficiales (para no empezar todo el proceso de 0).
-
Su frontend web está desarrollado actualmente en tecnologías no punteras como el gestor de componentes Sencha.
-
Su backend está desarrollado en Java, sin un diseño específico para adaptarse per se a un sistema como Kubernetes: gestiona cachés internas en local haciendo problemático su escalado.
¡Manos a la obra!
2020-02-01 18:00
Tras unos pocos meses de atraso, continuamos con los posts de Kubernetes :)
En el post anterior aprendimos unos cuantos conceptos básicos (pods, namespaces, deployments, replicasets y services) de Kubernetes. Son lo mínimo que debería saber un usuario (que no un administrador) para empezar a utilizar nuestro timonel favorito con un mínimo de cabeza, pero no son los únicos y existen otros objetos importantes.
Hoy vamos a explicar algunos conceptos extra que mejorarán nuestra comprensión de la herramienta y ayudará a que desatemos todo su potencial.
De momento vamos a seguir utilizando MicroK8s para los ejemplos que hagamos, pero si algún lector tiene otro clúster instalado podrá utilizarlo también. Leña al mono.
2020-01-16 18:00
Como comenté en el post anterior, uno de los problemas que tuve el año pasado estuvo relacionado con mi portátil personal: llegado un momento el GRUB de mi PC se corrompió y no hubo manera de arreglarlo. Intenté reinstalarlo, arreglar los ficheros de GRUB que habían petado, hacer un chroot desde un CD live y hacer una reparación manual desde ahí, paso a paso.
Tras probar durante unas horas, decidí que lo mejor era reinstalar de 0 puesto que sólo había perdido tiempo y no datos. Y aunque siempre hago un seguimiento de qué tengo instalado, ahí fue cuando me di cuenta de la pereza que me daba reconfigurarlo todo. Llegados a este punto pensé… ¿por qué no utilizar mis conocimientos de automatizaciones para evitar perezas futuras?
2020-01-01 05:00
Buenas a todos, aunque lo pudiera parecer no he abandonado el blog (o al menos no lo he hecho definitivamente).
Hace unos meses que quería escribir este post y aunque no esperaba que se demorara tanto, creo que la ausencia de contenido durante estos seis meses merece una explicación seria y sincera.
2019-06-15 18:00
Hace más de un año que decidí empezar a escribir este blog. Aunque tuve dudas sobre qué stack o tecnologías utilizar o investigar, siempre supe que mi código iba a ir a Gitlab.
A lo largo de este año han ocurrido muchas cosas respecto a sistemas de gestión de código: Microsoft compró Github y ahora ofrecen repositorios privados de código gratis, el SaaS de Gitlab cambió de proveedor de nube pública (de Microsoft Azure a Google Cloud Platform) y de paradigma conceptual (de monolitos a microservicios y contenedores) y Gitea, un hermano pequeño de Github escrito en Go ha empezado a ser una alternativa potente a tener en cuenta.
2019-06-05 18:00
Tras unos meses un poco desaparecido debido a temas personales… volvemos a la carga con un clásico. Es prácticamente imposible tener un blog de temática tecnológica y Cloud sin hablar del producto estrella de dicho mundillo, así de cómo su orquestador principal: hablamos respectivamente de los contenedores y kubernetes.
2019-03-07 18:00
En el post anterior hablamos por encima de infraestructura como código y la importancia de utilizar herramientas que podamos utilizar en el proveedor que queramos para evitar tener que estar aprendiendo lenguajes y sintaxis nuevos cada vez que utilizamos un proveedor nuevo.
Para ello, Terraform utiliza un lenguaje propio, el Hashicorp configuration language o HCL. Como podemos leer en su Github, la idea detrás de la creación de este lenguaje es que sea de fácil lectura para máquinas y para humanos. También buscaban que no fuese necesario tener conocimientos previos de algún lenguaje de programación y que fuese ligeramente diferente a otro previo como JSON o YAML.
Pero… ¿y si ya sabemos programar? ¿No podríamos utilizar ese conocimiento para desplegar infraestructura en lugar de aprender un lenguaje nuevo? Si ambas respuestas son afirmativas, nuestra respuesta es Pulumi.
2019-01-30 10:00
Ya he comentado en alguna ocasión mi amor por Hashicorp por las facilidades que nos ofrecen a los que trabajamos en entornos Cloud. Hoy vamos a hablar de su herramienta de aprovisionamiento de infraestructura, Terraform.
2019-01-03 23:00
En el mundo en el que vivimos, la nube se está extendiendo gracias a la proliferación de servicios integrados, ya sea en móviles, en electrodomésticos. El uso de los servicios ya gestionados por terceros, listos para utilizar, es algo generalizado: los de Google (Google Docs, Google Drive o GMail entre otros) son usados por casi todos los usuarios de Android, pero éstos no son los únicos y tenemos otros como Zoho, Office 365 o Quip entre otros.
Sin embargo también existen alternativas que ofrecen experiencias más o menos equivalentes y que podemos instalar y gestionar nosotros. Ya hemos hablado en el pasado de Nextcloud pero no son los únicos: Cozy (Parecido a Google Drive), Turtl (Una alternativa a Evernote) u otros…
Siempre me ha gustado montar los servicios que utilizo, por aprender y valorar lo que me ofrecen y gracias a la proliferación de placas como la Raspberry Pi, me he montado un sistema propio combinando algunos servicios antes citados.
2018-12-01 20:00
Cuando empecé a plantearme esta web hace un año aproximadamente la ví como un pasatiempo, un sitio donde plasmar cuando me apeteciera algunas de las pruebas y tests que hago en mi tiempo libre, esperando que a alguien le pudiese resultar útil. Bajo esa base, me comprometí conmigo mismo a cumplir con una serie de premisas:
-
Los posts deberían de estar en castellano. Ya existe una cantidad de documentación de una calidad excelente en inglés y me parecía que se debía enrriquecer un poco la blogosfera hispana.
-
Los post deberían de tratar temas que no estuviesen siendo tratados en la blogosfera hispana o de los cuales hubiera poca documentación en español o bien estuviese muy dispersa. Y la temática debía estar relacionada con las metodologías devops o la nube pública. El ritmo de publicación debe ser al menos de una vez al mes.
-
Internet está llena de documentación anticuada. Me comprometía a ir revisando periódicamente el contenido para evitar lo que me ha pasado a mi en numerosas ocasiones… que al buscar documentación ésta ya no funcionara debido a que el producto ya había cambiado tanto que no era compatible (en Ansible es bastante sangrante).
Nota del autor: Desde finales del 2020 no utilizo Nikola, por lo que el contenido de este post es meramente informativo.