Plantillas-de-máquinas-virtuales-Proxmox.md

+## Tabla de contenidos
+- [Introducción](#introducción)
+- [Estartegia](#estartegia)
+- [Crear un *Proxmox VM Template* compatible con nuestro flujo automatizado](#crear-un-proxmox-vm-template-compatible-con-nuestro-flujo-automatizado)
+
 # 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 solución es utilizar máquinas virtuales "completas". En la que el host se ejecuta con su propio *hardware* y *kernel* completamente aisaldo del nodo Proxmox. Este hecho no ameritaría mayor problema (ni esta entrada en la wiki) de no ser porque rompe completamente nuestro flujo de trabajo cotidiano. En él se encuentra automatizada desde la creación del *host* hasta el aprovisionamiento de sistema operativo, configuraciones elementales y servicio final.
+Para estos escenarios, la solución es utilizar máquinas virtuales "completas". En la que el *host* se ejecuta con su propio *hardware* y *kernel* completamente aislado del nodo Proxmox. Este hecho no ameritaría mayor problema (ni esta entrada en la wiki) de no ser porque rompe completamente nuestro flujo de trabajo cotidiano. En él se encuentra automatizada desde la creación del *host* hasta el aprovisionamiento de sistema operativo, configuraciones elementales y servicio final.
 
 De toda la cadena, el eslabón crítico aquí es que una vez creada la máquina virtual en Proxmox (en adelante VM), a diferencia de los contenedores LXC, la VM se transformará en una caja negra para el nodo, que no podrá aprovisionarle: sistema operativo, *hostname*, direcciones IP ni acceso SSH al usuario *root*.
 
-Para solventar esta limitación y contar con el flujo íntegramente automatizado que acostumbramos para los LXC, debemos dividirla en dos partes:
+Para solventar esta limitación y contar también para las VM con el flujo íntegramente automatizado que acostumbramos en los LXC, hay dos aspectos a afrontar:
 1) aprovisionar un sistema operativo dentro de una VM (típica tarea de intervención humana)
 2) realizar las configuraciones elementales a ese sistema operativo (típica tarea automatizable) para poder ejecutar nuestros playbooks, es decir:
     - establecer direcciones IP
@@ -14,37 +19,37 @@ Para solventar esta limitación y contar con el flujo íntegramente automatizado
     - acceso SSH para el usuario *root* con llave RSA
 
 
-##### Para atacar la primera, haremos uso de los *Templates Proxmox*, para la segunda de un [role Ansible propio](https://github.com/UdelaRInterior/ansible-role-make-vm-template-unique) desarrollado para tal fin. Comencemos por el principio.
-
-
-# La estartegia
+# Estartegia
 
 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 KVM. 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 mas concretamente para cada caso.
+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 [create_kvm](https://github.com/UdelaRInterior/ansible-role-proxmox-create-kvm)) y se encendida 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*).
+Una vez se clone ese *template* (tarea automatizada en el role [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, y se reunieron en el role [make_vm_template_unique](https://github.com/UdelaRInterior/ansible-role-make-vm-template-unique), que es el nexo final para conseguir nuestro objetivo: un flujo de automatización completo y sin interrupciones desde la creación del host hasta contar con el servicio listo para producción.
+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 nuestro flujo automatizado
+# Crear un *Proxmox VM Template* compatible con nuestro flujo automatizado
 
 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 un KVM Proxmox con los recursos de hardware (CPU, RAM, almacenamiento, etc.) que se consideren mas polivalentes para el sistema de esa VM y sus futuros clones. **El nombre deberá utilizar [camel case](https://en.wikipedia.org/wiki/Camel_case) y ser representativo del sistema operativo a instalar, sucedido por el sufijo "Template"**. La estructura será `<Distribución><Versión>Template`. Por ej. `DebianBusterTemplate`, `UbuntuBionicTemplate`. Es importante establecer ya el nombre correcto, porque así se identificará el *template* obtenido finalmente.
+- Crear un KVM 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. **El nombre de la KVM deberá utilizar [camel case](https://en.wikipedia.org/wiki/Camel_case) y ser representativo 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.
 - Descargar una imagen ISO del sistema operativo que se desea instalar, cargarla al nodo Proxmox, y *bootear* la flamante KVM desde ese ISO para proceder a realizar una instalación manual estándar.
 - 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 KVM clonadas desde el *template*.** Esto es:
-  - **Direcciones IP**. En al menos una de las interfaces de red se debe asiganar la IPv4 e IPv6 a las que apunta el nombre de dominio `template.interior.edu.uy`
+  - **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-ip` como primer paso luego de clonar el *template*. Dependiendo el sistema operativo la forma de habilitarlo puede variar. Para sistemas basados en Debian, el proceso consiste simplemente en modificar el archivo `/etc/ssh/sshd_config` y establecer `PermitRootLogin` en el valor `yes`
+  - **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-ip` como primer paso luego de clonar el *template*. Dependiendo el sistema operativo la forma de habilitarlo puede variar. Para sistemas basados en Debian, 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*.
 
-  > 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 desde el sistema ya instalado e iniciado normalmente, 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, procedemos a apagar la máquina virtual.
+- Por último, desde el panel web de Proxmox convertimos la VM en un *template*, haciendo click derecho sobre ella y seleccionando la opción *"Convertir a plantilla"* (*"Convert to template"* en inglés).
+  Cualquier información o comentario que consideremos sea de utilidad posterior, podemos dejarla registrada como nota Proxmox del *template*
 
-- Una finalizada la instalación del sistema operativo y configurado de acuerdo a las pautas del punto anterior, procedemos a apagar la máquina virtual
-- Por último, desde el panel web de Proxmox convertimos la VM en un *template*, haciendo click derecho sobre ella y seleccionando la opción *"Convertir a plantilla"* (*"Convert to template"* en inglés). A partir de este momento, la VM no podrá ser encendida directamente, sino únicamente previo clonado.
\ No newline at end of file
+Hemos finalizado el procedimiento. A partir de este momento contamos con un *Proxmox VM Template* compatible con nuestro flujo automatizado y *read-only* (no podrá ser encendida directamente, sino únicamente previo clonado). 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)
\ No newline at end of file