
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.
Photo by Mabel Amber
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 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.