Photo by Mabel Amber
En la entrada Pods en estado creatingContainer en K8s describía el problema surgido al crear un clúster de Kubernetes usando Vagrant. Al partir de la misma imagen, todas las máquinas del clúster tienen el mismo machine-id.
El machine-id debe ser único, como se describe en los requerimientos de Kubernetes; si no lo es, se producen problemas como el descrito.
En esta entrada analizo con más detalle cómo se crea el machine-id y cómo generar uno nuevo.
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.
Una de las maneras más sencillas de crear un entorno de desarrollo para Kubernetes es usando Vagrant y Ansible.
En el Vagrantfile definimos un conjunto de tres máquinas, llamadas node1, node2 y node3.
Una vez las máquinas están levantadas, desde el servidor de Ansible uso ssh-copy-id para habilitar el login sin password de Ansible en los nodos del clúster.
A partir de aquí, tanto la instalación de los prerequisitos como la inicialización del clúster funcionan sin problemas; sin embargo, al intentar desplegar una aplicación, los pods se quedan en el estado CreatingContainer.
En entradas anteriores hemos subido el código de la aplicación al repositorio en Gogs y hemos instalado SonarQube y Jenkins. Ahora, vamos a configurar Jenkins para que analice el código de la aplicación y detectar fallos incluso antes de compilar la aplicación.
Update 2022-01-06 He actualizado los enlaces externos hacia la documentación de SonarQube. Por favor, revisa la documentación oficial actualizada ya que este artículo se escribió para una versión anterior de SonarQube.
Docker proporciona el comando docker stats para monitorizar el uso de CPU, memoria, etc de los contenedores en ejecución:
En las guías y tutoriales en internet siempre funciona todo sin ningún fallo. Sin embargo, lo más habitual es que encontremos problemas en los primeros intentos de poner en marcha una aplicación.
Personalmente, creo que el aprendizaje es un proceso de ensayo y error, por lo que se aprende solucionando los errores que nos encontramos.
Con esa idea en mente, también intento documentar los fallos que cometo. A continuación tienes el registro de las acciones que realicé para solucionar los problemas encontrados en el arranque de SonarQube.
SonarQube es una herramienta de análisis continuo de código.
La versión open source ofrece soporte para 20 lenguajes de programación, mientras que la versión comercial amplía el número de analizadores. También hay analizadores creados por la comunidad.
Una vez tenemos código en el repositorio de Gogs, para poder avanzar tenemos que definir y configurar el pipeline en Jenkins.
