docker

Photo by Mabel Amber

• Autocompletado de comandos (y ramas) de Git en Devcontainer

  • 5 Sep 2023
  • post
  • Xavi Aznar

  En una entrada anterior (Usa un contenedor como entorno de desarrollo con ‘devcontainers’) explicaba cómo usar un contenedor y Devcontainers para suplir las carencias de MacOS con respecto a Bash.

  Desde entonces uso Devcontainers más y más; por ejemplo, para desarrollar en Go ya no tengo que levantar una máquina virtual o instalar Go en mi equipo: genero un fichero devcontainer.json, indico la imagen oficial de Go y ¡listo!

  No todo es perfecto; una de las cosas que últimamente estaba sufriendo es que Git no autocompleta, por ejemplo, los nombres de las ramas.

  La solución a la que siempre acabo acudiendo (y ejecutando manualmente) es Autocomplete Git Commands and Branch Names.

  Pero claro, yo quería automatizarlo ;)

  Así que hoy explico cómo he conseguido incluir el autocompletado de Git directamente al arrancar un devcontainer.

• Usa un contenedor como entorno de desarrollo con 'devcontainers'

  • 19 Jul 2023
  • post
  • Xavi Aznar

  Contexto

  Apple no incluye versiones modernas de Bash; la versión incluida por defecto es 3.2. Esto se debe a que a partir de esta versión la licencia que cubre Bash es la GPLv3 y ésta obliga a compartir el código fuente, cosa que Apple no quiere hacer.

  El caso es que ahora uso un Mac M2 para el trabajo y algunas funcionalidades como los arrays asociativos (name["dog"]="snoopy"), sólo están disponibles en Bash v4 o superior.

  La solución más obvia, actualizar Bash manualmente en el Mac, es posible pero tiene inconvenientes. El Bash “nativo” de Mac OS se encuentra en /usr/bin, mientras que otra versión de Bash, sólo puede ser instalada fuera de /usr/bin, porque el Mac usa algo llamado System Integrity Protection, que evita la ejecución de código no autorizado. Aunque SIP puede deshabilitarse, no es una buena idea.

  Dado que en Bash nuestros scripts usan el shebang #!/bin/bash (ver Shell Style Guide de Google), al ejecutar el script en Mac OS, se usaría Bash 3.2 y no la nueva versión (p.ej, Bash v5).

• Todo lo que esconden las opciones por defecto en Docker

  • 25 Mar 2022
  • post
  • Xavi Aznar

  El título tiene una sonoridad un poco a click bait, así que explicaré rápidamente a qué me refiero.

  Hace poco que hemos empezado a colaborar en un proyecto nuevo. Mientras nos vamos poniendo al día estoy ayudando a uno de mis compañeros -un crack en networking- con temas relacionados con contenedores, con los que está menos familiarizado.

  Revisando los ficheros de configuración de Google Cloud Build, encontramos, en el mismo fichero, referencias a la imagen de un contenedor como hashicorp/terraform:latest, otras en las que el nombre es de la forma gcr.io/cloud-builders/gcloud y otras en las que es, simplemente, alpine.

  Y claro, mi compañero no entiende nada…

• Guardar el estado de Terraform en MinIO

  • 11 Mar 2022
  • post
  • Xavi Aznar

  Terraform almacena el estado de la configuración en un fichero. Este fichero es crítico para que Terraform pueda mantener la coherencia entre el estado definido en los ficheros de configuración y el estado real de la infraestructura desplegada.

  Por defecto, Terraform almacena el estado de forma local; para facilitar la colaboración entre diferentes miembros de un equipo -entre otros casos de uso-, Terraform ofrece la posibilidad de usar otras ubicaciones para guardar el estado. Estas ubicaciones reciben el nombre de backends en Terraform (y hay unos cuantos disponibles, como puedes observar desplegando la entrada Available Backends en la web de Terraform).

  Una opción habitual es la de usar un bucket en un servicio como S3 de AWS como remote backend. Pero si no tienes acceso a una cuenta de AWS, puedes usar MinIO para trabajar con un backend de tipo S3 de forma completamente offline (por ejemplo, para aprender cómo funciona Terraform ;-D )

• k3d: k3s en Docker (o la manera más rápida de montar clústers de Kubernetes para desarrollo)

  • 21 Mar 2021
  • post
  • Xavi Aznar

  kind es una herramienta para ejecutar clústers de Kubernetes en los que cada “nodo” del clúster se ejecuta en un contenedor. k3d toma esta misma idea pero en vez de un clúster de Kubernetes vanilla, despliega un clúster de k3s usando contenedores como “nodos”.

• Imagen base de un registry diferente a Docker Hub

  • 26 Sep 2020
  • post
  • Xavi Aznar

  A continuación de la entrada anterior, Multi-stage builds con Docker, la idea es explicar cómo usar una imagen base de un registro diferente a Docker Hub, que es el registro por defecto para Docker.

• Multi-stage builds con Docker

  • 26 Sep 2020
  • post
  • Xavi Aznar

  Los multi-stage builds son una funcionalidad introducida en Docker en la versión 17.05 que proporciona importantes ventajas respecto a los builds “todo-en-uno”, principalmente en cuanto a seguridad y tamaño de la imagen resultante.

• Resetear el password de administrador en Gitea

  • 25 Sep 2020
  • post
  • Xavi Aznar

  Uno de los problemas de los entornos de laboratorio es que son fungibles, casi de “usar y tirar”. Un efecto colateral es que cosas como las credenciales no se gestionan correctamente, se pone la primera que se nos ocurre y después… pues no hay manera de volver a acceder.

  En mi caso me he encontrado en esta situación con Gitea y en esta entrada voy a documentar cómo establecer una nueva contraseña para el usuario administrador.

• Automatizando la instalación de Gitea (con Docker Compose)

  • 15 Jul 2018
  • post
  • Xavi Aznar

  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.

• Automatizando la instalación de Gitea (sin Docker Compose)

  • 15 Jul 2018
  • post
  • Xavi Aznar

  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.