Photo by Mabel Amber
En la entrada anterior, Revisión de la Helm chart oficial de Gitea, analicé la chart oficial de Gitea. Después de revisarla, en esta entrada explico cómo instalar Gitea a partir de la chart oficial usando Helm.
Iba a escribir sobre las lecciones aprendidas al intentar crear una Helm Chart desde cero en una entrada cuando descubrí que las imágenes habían dejado de mostrarse en el blog. Eso me hizo reconducir mis esfuerzos en corregir el problema y dió al traste con la entrada que tenía a medias…
Desde entonces he enfocado los esfuerzos en entender cómo funciona la chart oficial para Gitea y en instalarla para ver qué posibilidades de personalización ofrece.
En esta entrada me enfoco en la primera parte: analizar las elecciones realizadas por el equipo de Gitea a la hora de crear la chart oficial.
En la entrada anterior No se muestran imágenes en el blog comentaba cómo un cambio en la configuración de Hugo (en la versión 0.60.x) estaba haciendo que no se mostraran las imágenes en los artículos del blog.
En esta entrada comento los pasos que he seguido para actualizar todos los artículos con imágenes así como qué otras opciones he estado revisando.
No soy muy fan de insertar imágenes con capturas de pantalla en las entradas que escribo, excepto cuando es estrictamente necesario. Además, por la naturaleza de este blog y los temas que trato, para ilustrar es suficiente con copiar y pegar el texto de la consola o del editor de texto. Pero de vez en cuando, es necesario insertar una imagen… Y de pronto, las imágenes han desaparecido del blog.
Velero realiza copias de seguridad (puntuales o recurrentes) para recuperarnos con rapidez de un desastre en el clúster de Kubernetes.
En la entrada anterior Velero - Backup y Disaster Recovery para Kubernetes (II) Crear copia de seguridad desplegamos una aplicación de prueba en el clúster (dos réplicas de Nginx en el Namespace nginx-example). Simulamos la pérdida “accidental” del Namespace nginx-example para ver cómo recuperarnos usando la copia creada por Velero.
En la entrada anterior Velero - Backup y Disaster Recovery para Kubernetes (I) Instalación vimos cómo instalar Velero en Kubernetes. Usamos el comando velero install lanzado desde un Job en la línea de la filosofía GitOps.
En esta entrada veremos cómo crear copias de seguridad puntuales y recurrentes usando la herramienta de línea de comandos velero (lanzada desde un Job)
Velero es una herramienta de código abierto que permite realizar copias de seguridad, restaurarlas y migrar recursos de Kubernetes entre clústers (lo que también permite recuperar un clúster en caso de desastre).
Velero soporta diferentes proveedores en los que almacenar las copias de seguridad que realiza. La lista completa y actualizada se encuentra en Providers. En mi caso, voy a utilizar MinIO, que es compatible con AWS S3 y que tengo desplegado localmente en Kubernetes.
En la entrada anterior, MinIO en Kubernetes, explicaba cómo desplegar MinIO en Kubernetes (de forma manual).
mc se puede usar como herramienta de línea de comandos o como contenedor minio/mc; sin embargo, en esta entrada veremos cómo usarlo en Jobs de Kubernetes para configurar el alias de un servidor de MinIO y crear un bucket.
MinIO proporciona almacenamiento de objetos compatible con AWS S3. Desde la última vez que revisé este producto, MinIO ha crecido hasta convertirse en una solución de calidad empresarial.
También han cambiado el logo, y por lo que veo, el “flamenco” o lo que sea el animal del logo ha quedado relegado al
favicony el footer de la página web…Yo mantendré por ahora el logo “antiguo” (que curiosamente, tiene al pájaro mirando hacia la izquierda¯\_(ツ)_/¯)
En este artículo, voy a desplegarlo sobre Kubernetes de forma manual con un sólo servidor. Usaremos el almacenamiento en MinIO como destino de las copias de seguridad del clúster de Kubernetes usando Velero (en un próximo artículo).
