Photo by Mabel Amber
Hugo sigue evolucinando y eso significa que cada nueva versión introduce pequeñas modificaciones y mejoras que no siempre son retrocompatibles.
En mi caso, al actualizar a la versión 0.54 encontré problemas a la hora de construir el blog. En la entrada Hugo: plantilla del tema actualizada explico cómo solucioné los errores que impedían generar el blog.
Debido a un inminente cambio en mi carrera profesional tengo que planificar el traspaso de las tareas que realizo a la persona que ocupe mi posición y que -cosas de los procesos de contratación- todavía no se ha incorporado (ni sabemos cuándo lo hará). Aunque cambio de departamento en la organización (es decir, no dejo la empresa), esta situación me ha llevado a reflexionar sobre todas esas cosas que hacemos en el día a día y que no están documentadas en ningún sitio.
Cada cierto tiempo instalo la última versión de Hugo, el motor que convierte contenido estático -en formato markdown- a las páginas HTML que estás leyendo ahora mismo. Sin embargo, al actualizar a la versión v0.54.0-B1A82C61 darwin/amd64, obtuve múltiples mensajes de error que me impedían construir el sitio web y por tanto, no podía generar nuevas versiones del site.
Como dice el chiste, las nubes están compuestas básicamente de servidores Linux. Una de estas nubes, Amazon Web Services (AWS), ofrece su propia distribución de Linux: Amazon Linux 2.
Con Ansible podemos automatizar la gestión de la configuración de las máquinas virtuales (o no) que creamos. Pero para poder explotar la potencia de Ansible necesitamos que la máquina gestionada cumpla unos requisitos previos: disponer de Python 2.6 o superior y que Ansible pueda conectar con la máquina.
Todas estas tareas se pueden automatizar, así que vamos a ver cómo conseguirlo.
Kubernetes y el ecosistema que se ha desarrollado a su alrededor evoluciona a un ritmo increíble. Kubernetes lanza nuevas releases cada tres meses, con nuevas funcionalidades impulsadas por alguno de los SIGs trabajando en el desarrollo.
En cuanto a las herramientas relacionadas, hace unos días leía acerca de la entrada de Harbor en la incubadora de la CNCF. El mes anterior lo hizo Rook…
Aunque es fascinante el ritmo de aceptación de Kubernetes y el ecosistema al que ha dado lugar, es muy difícil mantenerse al día de todo. Y prácticamente imposible conocer con detalle todas y cada una de las herramientas interesantes que, se desplieguen o no sobre Kubernetes, tienen que ver con conceptos afines, como Ansible, Cloud-Init, OpenStack, GlusterFS, Jenkins X, etc, etc.
cloud-init se define como el estándar para personalizar instancias cloud. Las imágenes para las instancias cloud empiezan siendo idénticas entre sí, al ser clones. Es la información proporcionada por el usuario lo que le da a la instancia su personalidad y cloud-init es la herramienta que aplica esta configuración a las instancias de forma automática.
cloud-init fue desarrollado inicialmente por Canonical para las imágenes cloud de Ubuntu usadas por AWS. Desde entonces, la aplicación ha evolucionado y puede ser usada en otras muchas distribuciones y en otros entornos cloud (y no cloud).
En la entrada anterior explicaba cómo automatizar la instalación de Gitea usando un script y Docker.
Todos los pasos necesarios para crear los volúmenes de datos, la red interna entre Gitea y la base de datos, etc usan Docker.
En esta entrada usaremos Docker Compose para obtener el mismo resultado y analizar las diferencias entre los dos métodos de instalación.
Después de descubrir Gitea en la entrada anterior me puse a probarlo… Como desde el principio vi que Gitea sustituiría a Gogs como mi “repositorio local” por defecto, quería tener documentados todos los pasos necesarios para ponerlo en marcha.
Esto significa crear los volúmenes tanto para Gitea como para la base de datos, la red interna para comunicar la base de datos y Gitea y la puesta en marcha de todo ello en los comandos docker run. En el caso de la base de datos, los passwords de root y del usuario de conexión se pasan como variables de entorno…
Lo más sencillo, decidí, sería crear un script que hiciera el trabajo por mí.
En esta entrada comento el script y algunas de las mejoras que he ido introduciendo.
Gogs es un servidor web de repositorios Git (a lo GitHub). He hablado otras veces de lo sencillo que es montarlo usando Docker, de manera independiente (usando SQLite como base de datos o con MySQL).
A través de este artículo 6 Github alternatives that are open source and self-hosted descubrí hace unos días Gitea y a continuación te explico porqué creo que es todavía mejor que Gogs.
