Linux

La base de todas las máquinas: una imagen Ubuntu con cloud-init y un servidor base sobre el que se construye cada aplicación.

Imagen Linux

linux-image descarga una cloud image en un datastore de Proxmox. Se ejecuta una vez por imagen y antes que cualquier cosa que cree una máquina.

Se despliega desde ISOs en Horizon con la plantilla Linux Cloud Image Downloader. Horizon rellena la conexión a Proxmox, el nodo y el datastore según el servidor y almacenamiento elegidos, y solo pregunta:

• iso_url: la URL de la imagen. Se esperan las Ubuntu minimal.
• iso_filename: el nombre con el que se guarda.

aviso

La imagen debe incluir cloud-init: es lo que permite a Proxmox configurar el hostname, los usuarios, las claves SSH y la red en el primer arranque. Una ISO de instalación se descarga sin problema y arranca una máquina en la que nadie puede entrar.

consejo

En un clúster de Proxmox, usa un datastore compartido entre todos los nodos, o la imagen solo estará disponible en el nodo que la descargó.

Servidor base

linux crea una VM Ubuntu sin ningún servicio: solo el agente de QEMU, el agente NRPE y el Node Exporter de Prometheus. Tiene dos usos:

• Un servidor que se configura fuera de Terraform, mediante la plantilla Ubuntu Base Server.
• La primera fase de cualquier aplicación desplegada por fases. Todas las plantillas de Sora empiezan con él.

Disco de datos

vm_disk_data_size añade un segundo disco montado en /data. Es la convención de todo el proyecto: el disco raíz guarda el sistema operativo y todo lo que un servicio necesita conservar va en /data. Por defecto es 0, sin disco. Su check de Nagios solo se publica cuando existe.

CPU

Por defecto el tipo de CPU es x86-64-v3 con el flag +pcid:

• x86-64-v3 ofrece AVX2, FMA y BMI, que usan compiladores y bases de datos. Haswell es la CPU más antigua que lo tiene todo.
• +pcid evita que la mitigación de Meltdown vacíe la TLB en cada llamada al sistema.
• No se usa host porque una VM conserva la CPU con la que arrancó: en un clúster con CPUs diferentes, una migración en caliente hacia un nodo más antiguo fallaría.

precaución

Cambiar la CPU de una VM existente la reinicia. Planifícalo como cualquier otra ventana de mantenimiento.

Umbrales de Nagios

El agente NRPE de cada VM define sus límites, así que la carga y el número de procesos son variables del proyecto:

Variable	Por defecto
nagios_check_load_warning	.80,.75,.70
nagios_check_load_critical	.90,.85,.80
nagios_check_procs_warning	400
nagios_check_procs_critical	600

La carga es por CPU: .80 significa el 80% de un núcleo, sea cual sea el tamaño de la VM. Una aplicación con mucha carga sube sus propios límites en el formulario de Horizon, sin tocar Nagios.

Orden de arranque

vm_startup_order decide cuándo arranca la VM tras reiniciar el nodo de Proxmox. Las plantillas lo definen según su lugar en la secuencia:

Aplicación	Orden
PostgreSQL	10
Kubernetes	20
Monitorización	70
GitLab Runner	99

Salidas

host_domain, data_mount_point y metrics_urls son salidas que leen las fases siguientes y los checks de Nagios (steps.vm.host_domain), en lugar de preguntar al operador algo que la plataforma ya sabe.