Changes

Daniel Viñar Ulriksen · 6994dc36
--- a/Plantillas-de-máquinas-virtuales-Proxmox.md
+++ b/Plantillas-de-máquinas-virtuales-Proxmox.md
 ## Tabla de contenidos
 - [Introducción](#introducción)
 - [Estartegia N° 1](#estartegia-n-1-plantillas-propias-make_vm_template_unique-no-recomendada)
  - [Crear un *Proxmox VM Template* compatible con `make_vm_template_unique`](#crear-un-proxmox-vm-template-compatible-con-make_vm_template_unique)
- [Estartegia N° 2](#estartegia-n-2-plantillas-propias-o-de-terceros-cloud-init-recomendada)
+- [Estartegia N° 2](#estartegia-n-2-plantillas-propias-o-de-terceros--cloud-init-recomendada)
  - [Crear plantilla personalizada](#crear-plantilla-personalizada)
  - [Importar plantilla de terceros (*cloud images*)](#importar-plantilla-de-terceros-cloud-images)
 # Introducción
 Si bien cuando necesitamos crear un nuevo *host* en la plataforma (clúster de nodos Proxmox VE) preferimos hacerlo como un contenedor LXC, muchas veces nos enfrentamos al escenario en que por seguridad y/o robustez, no es posible brindar el servico desde un contenedor.
 Para estos escenarios, la mejor alternativa es utilizar máquinas virtuales "completas". En la que el *host* se ejecuta con su propio *hardware* virtualizado y *kernel* aislado del nodo Proxmox.
 Este hecho no ameritaría mayor problema (ni esta entrada en la wiki) de no ser porque complejiza en cierta medida flujo de trabajo acostumbrado con los contenedores LXC.
 Con los contenedores, y particularmente con las plantillas LXC provistas por Proxmox, tenemos automatizada desde la creación del *host* hasta el aprovisionamiento de sistema operativo, configuraciones elementales y servicio final sin mayor complicación.
 Sin embargo, una vez creada una máquina virtual (VM) en Proxmox VE, a diferencia de los contenedores LXC, ésta se transforma en una suerte de caja negra para el nodo, una agrupación de recursos de hardware que no cuenta siquiera con un sistema operativo.
 Para solventar esta limitación y contar también para las VM con el flujo íntegramente automatizado que acostumbramos en los LXC, hay dos elementos a resolver:
 1) aprovisionar un sistema operativo dentro de una VM (típica tarea de intervención humana en nuestro trabajo, porque nunca terminamos de lograr automatizar la instalación de una ISO)
 2) realizar las configuraciones elementales a ese sistema operativo (típica tarea automatizable) para poder ejecutar nuestros playbooks, es decir:
    - establecer direcciones IP
    - nombre de *host*
    - acceso SSH para el usuario *root* con llave RSA
 Actualmente, contamos con 2 estrategias para solucionar ambos elementos:
 1) Confeccionar *Proxmox VM Templates* a ser utilizadas en combinación al *role* `make_vm_template_unique`
 2) Confeccionar *Proxmox VM Templates* (o emplear las de terceros) compatibles con *cloud-init*
 # Estartegia N° 1: plantillas propias + make_vm_template_unique (No recomendada)
 Tal como se introduce en la [wiki Proxmox](https://pve.proxmox.com/wiki/VM_Templates_and_Clones#Introduction), un *VM Template*:
 > (...) es una imagen de sistema operativo totalmente preconfigurada que se puede usar para desplegar máquinas virtuales. Por lo general, se prefiere crear una plantilla (*template*) dedicada que clonar una VM existente. (...). Las plantillas son creadas convirtiendo máquinas virtuales "al uso" en *templates*.
 Esta característica de Proxmox, aunque en principio no resulte evidente, es la solución a nuestro primer asunto a atender: el aprovisionamiento de un sistema operativo. Si bien la instalación del sistema en sí debe ser realizada manualmente por un humano, Proxmox permitirá sacarle mucho provecho a esa instalación. Al convertirla en *template*, podrá reutilzarse innumerables veces.
 No perdamos de vista que el objetivo es ejecutar Ansible sobre una instalación limpia de determinado sistema operativo, y a partir de *playbooks* aprovisionar lo que se desee más concretamente para cada caso.
 Por lo tanto la estrategia consistirá en confeccionar manualmente la instalación de un sistema operativo sobre una VM; para luego [convertir la VM en un template Proxmox](https://pve.proxmox.com/wiki/VM_Templates_and_Clones#Create_VM_Template) que pueda ser clonado las veces que se necesite.
 Una vez se clone ese *template* (tarea automatizada en el role [proxmox_create_kvm](https://github.com/UdelaRInterior/ansible-role-proxmox-create-kvm/blob/master/tasks/clone_kvm.yml)) y se encienda la VM resultante, sólo necesitaremos que se encuentre en línea y accesible mediante SSH. ¿Cómo lo logramos? Previendo este escenario al crear el *VM Template*, asignándole una dirección IP específica para tal fin (la asociada al alias *template.interior.edu.uy*) y una contraseña registrada en *vaults* del proyecto `config` al superusuario (*root*).
 De este modo, apenas encienda la nueva VM, podremos realizar un `ssh-copy-id root@template.interior.edu.uy` para contar con acceso Ansible convencional y a partir de ahí configurar direcciones IP, *hostname* y contraseñas de usuario particulares de la instancia que se está creando. Todas estas tareas también son automatizables, por lo que se reunieron e implementaron en el role [make_vm_template_unique](https://github.com/UdelaRInterior/ansible-role-make-vm-template-unique), nexo final para conseguir nuestro objetivo: un flujo de automatización completo y sin interrupciones desde la creación de la VM hasta contar con el servicio listo para producción.
 ## Crear un *Proxmox VM Template* compatible con `make_vm_template_unique`
 Dado que buscamos simplemente una instalación limpia de determinado sistema operativo sobre el cual ejecutar Ansible, crear un *VM Template* será sumamente sencillo y consistirá de los siguientes pasos:
 - Crear una VM Proxmox con los recursos de hardware (CPU, RAM, almacenamiento, interfaces de red, etc.) que se consideren más polivalentes para el sistema operativo a instalar. Como regla general, 2 núcleos de CPU, 4 GB de RAM y 128GB de HDD son recursos razonables para la mayoría de distribuciones GNU/Linux. Tener en cuenta que estos podrán ser modificados luego de clonado el *template* en caso de ser necesario. **Para mantener un estándar de nomenclatura, la VM deberá nombrarse utilizando [camel case](https://en.wikipedia.org/wiki/Camel_case), de forma representativa del sistema operativo a instalar, sucedido por el sufijo "Template"**. La estructura será `<Distribución><Versión>Template`. Por ej. `DebianBusterTemplate` o `UbuntuBionicTemplate`. Es importante establecer ya el nombre correcto porque así se identificará el *template* resultante de este procedimiento.
  ![Iniciando creación de una KVM en panel web Proxmox](uploads/5131d521171ba95ba40d43ae6e54a058/image.png)
 - Descargar una imagen ISO del sistema operativo que se desea instalar, cargarla al nodo Proxmox, y *bootear* la flamante VM desde ese ISO para proceder a realizar una instalación manual estándar.
  ![Cargando una imagen ISO a nodo Proxmox desde panel web](uploads/90b6dd1580ec53a9b196ef77804def5a/image.png)
 - En el proceso de instalación, típicamente deberemos configurar varias cosas. El objetivo es obtener una instalación de *stock*. Por lo que deberán mantenerse los valores por defecto siempre que sea posible. **Lo que único que nos interesa personalizar, es lo estríctamente necesario para acceder por SSH mediante contraseña como superusuario a las VM´s clonadas desde el *template*.** Esto es:
  - **Direcciones IP**. En al menos una de las interfaces de red se debe asignar la IPv4 e IPv6 a las que apunta el nombre de dominio `template.interior.edu.uy`.
  - **Superusuario**. Establecer al superusuario del sistema (típicamente `root`) la contraseña que se registra en la variable `vault_default_kvm_template_password` de los *vaults* globales (`group_vars/all/vault/main.yml`) u otra debidamente gestionada.
  - **Acceso SSH por contraseña**. Típicamente las distros deshabilitan el acceso por password para los superusuarios, pero nosotros lo necesitaremos para realizar el `ssh-copy-id` como primer paso luego de clonar el *template*. Dependiendo el sistema operativo la forma de habilitarlo puede variar. Para la mayoría de las distros, el proceso consiste simplemente en modificar el archivo `/etc/ssh/sshd_config` y establecer `PermitRootLogin` en el valor `yes`.
  > Tener en cuenta que dependiendo de la distribución que se esté instalando, puede que algunas de estas configuraciones no sean parte del proceso de instalación. En esos casos será necesario realizarlas luego del primer inicio normal del sistema, previo a convertir esa VM en *template*.
 - Una finalizada la instalación del sistema operativo y configurado de acuerdo a las pautas del punto anterior, tomamos nota del nombre asignado a las interfaces de red y procedemos a apagar la máquina virtual. (El nombre de las interfaces lo registraremos luego en la *Nota Proxmox*, ver útlimo punto).
 - Por último, desde el panel web de Proxmox convertimos la VM en un *template*, haciendo click derecho sobre ella (panel izquierdo) y seleccionando la opción *"Convertir a plantilla"* (*"Convert to template"* en inglés).
  ![Convirtiendo VM en template desde panel web Proxmox](uploads/1e2c09068899d3812082ec2cbce6eb46/image.png)
  Cualquier información o comentario que consideremos sea de utilidad posterior, debemos dejarla registrada como nota Proxmox del *template*: IPs, usuarios, contraseñas, interfaces de red, detalle del sistema operativo instalado, etc.
  ![Nota Proxmox en el VM template](uploads/7991289e17a2d946b7602069e16966be/image.png)
 # Estartegia N° 2: plantillas propias o de terceros + *cloud-init* (Recomendada)
 Como el lector atento podrá haber apreciado, la estrategia N° 1 presenta potenciales problemas, como la posibilidad de generar un conflicto con la IP de `template.interior.edu.uy` si el clonado de 2 o más plantillas se solapa en un momento dado. Además, la plantilla resultante es de dimensiones considerables y muy poco flexible a futuro debido a los numerosos accesos que se deben preconfigurar.
 Por esta razón, la estrategia recomendada es la N° 2, ya que [*cloud-init*](https://cloud-init.io/) (una tecnología extremadamente popular y extendida) viene a resolver precisamente esta problemática.
 Con *cloud-init*, es posible utilizar plantillas que no llevan preasignadas direcciónes IP, contraseñas de usuario ni llaves SSH autorizada. Por tanto crearlas es mucho mas sencillo, e incluso podemos descargar las *cloud images* oficiales de cada distro. Plantillas que ya incluyen *cloud-init* preinstalado en un imagen tan pequeña como es posible.
 Tenemos entonces 2 opciones:
 ## Crear plantilla personalizada
 Si nos decidimos por esta opción deberemos crear una VM y concluir en ella una instalación "limpia" del sistema operativo deseado a partir de su ISO oficial, tal cual como fue descrito para la estrategia N° 1. En este caso, se recomienda utilizar para la VM una nomenclatura con la estructura `<Distribución><Versión>TemplateC-I`.
 > Es áltamente recomendable asignar el menor tamaño y cantidad de particiones posible al disco de sistema
 Finalizada la instalación del sistema operativo, solo resta instalar `cloud-init`, cuyo paquete habitualmente se encuentra disponible desde los repositorios de la propia distro.
 Para ello será necesario iniciar sesión desde la consola KVM de la máquina virtual y configurar provisoriamente una interface de red para contar con conectividad hacia internet.
 Hecho esto, instalamos el paquete. Por ejemplo, para sistemas basados en Debian:
 ```
 root@template:~# apt update && apt install cloud-init
 ```
 Eso es todo. Con el paquete instalado, ya podemos apagar la VM y convertirla en *template* Proxmox, pero previamente es recomendable revertir la configuración de las interfaces de red realizadas para brindar internet.
 Para mas detalles, consultar la [documentación de Proxmox](https://pve.proxmox.com/wiki/Cloud-Init_FAQ#Creating_a_custom_cloud_image) al respecto.
 Recordar documentar cualquier información o comentario de utilidad (como las contraseñas utilizadas) en las notas Proxmox del *template*.
 ## Importar plantilla de terceros (*cloud images*)
 Llegamos finalmente a la opción mas interesante, crear nuestras platillas Proxmox a través de las imágenes provistas por las propias distribuciones. Esta es la alternativa mas sencilla y la que nos garantiza que nuestras futuras VM´s partan de una instalación completamente "limpia" y actualizada (si mantenemos las plantillas al día, claro). La nomenclatura recomendada para estas plantillas utiliza la estructura `<Distribución><Versión>CloudImage`.
 Las mayoría de las distribuciones distribuyen sus imágenes en formatos `.img` y/o `.qcow2` a través de su sitio oficial. Deberemos localizar la versión y edición deseada para la arquitectura de nuestro hipervisor y obtener el link de descarga.
 Luego, en un nodo Proxmox, ejecutaremos las siguientes instrucciones de acuerdo a lo [documentado por Proxmox](https://pve.proxmox.com/wiki/Cloud-Init_Support#_preparing_cloud_init_templates) (ejemplo utilizando *cloud image* de Debian Buster):
 Descargamos la imagen:
 ```
 root@pve_node01:~# wget https://cloud.debian.org/images/cloud/buster/latest/debian-10-generic-amd64.qcow2
 ```
 Creamos una nueva VM de base:
 ```
 root@pve_node01:~# qm create 9000 --name DebianBusterCloudImage --memory 1024 --net0 virtio,bridge=vmbr0
 ```
 Importamos la imagen de disco previamente descargada al *storage* `local-lvm`:
 ```
 root@pve_node01:~# qm importdisk 9000 debian-10-generic-amd64.qcow2 local-lvm
 ```
 Vinculamos a la VM el disco importado como unidad SCSI. (En ocasiones este paso falla desde la terminal y debe realizarse este desde el GUI web de Proxmox)
 ```
 root@pve_node01:~# qm set 9000 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-9000-disk-1
 ```
 Agregamos una unidad de CD-ROM que se utilizará para pasar la *meta-data* de *cloud-init* a la VM:
 ```
 root@pve_node01:~# qm set 9000 --ide2 local-lvm:cloudinit
 ```
 Establecemos el "disco duro" de la VM como dispositivo de arranque (*booteo*):
 ```
 root@pve_node01:~# qm set 9000 --boot c --bootdisk scsi0
 ```
 Agregar un consola serie a utilizar como *output*. (Muchas imágenes de cloud-init necesitan esto ya que es un requisito para las plantillas de OpenStack):
 ```
 root@pve_node01:~# qm set 9000 --serial0 socket --vga serial0
 ```
 Todo listo para convertir la máquina virtual en *template* Proxmox:
 ```
 root@pve_node01:~# qm template 9000
 ```
 Ya no necesitaremos la imagen descargada, por lo que opcionalmente podemos eliminarla para liberar espacio de almacenamiento en el nodo:
 ```
 root@pve_node01:~# rm debian-10-generic-amd64.qcow2
 ```
 ---
 ¡Felicitaciones! Llegado a este punto ya cuentas con un *Proxmox VM Template* compatible con nuestro flujo automatizado. Para saber como utilizar este u otro *VM template* desde Ansible, puedes consultar [esta entrada de la wiki.](Creación-de-una-nueva-máquina-virtual-KVM)