| ... | @@ -25,61 +25,17 @@ Para solventar esta limitación y contar también para las VM con el flujo ínte |
... | @@ -25,61 +25,17 @@ Para solventar esta limitación y contar también para las VM con el flujo ínte |
|
|
- nombre de *host*
|
|
- nombre de *host*
|
|
|
- acceso SSH para el usuario *root* con llave RSA
|
|
- acceso SSH para el usuario *root* con llave RSA
|
|
|
|
|
|
|
|
|
Nues (https://git.interior.edu.uy/cielito/adminsys/-/wikis/automatizar-la-forma-manual-que-ten%C3%ADamos-de-armar-Templates-y-VMs-en-PVE)
|
|
|
Actualmente, contamos con 2 estrategias para solucionar ambos elementos:
|
|
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)
|
|
La primer estrategia que adoptamos - hoy abandonada - consistía en [[automatizar la forma manual que teníamos de armar Templates y VMs en PVE]].
|
|
|
|
|
|
|
|
Tal como se introduce en la [wiki Proxmox](https://pve.proxmox.com/wiki/VM_Templates_and_Clones#Introduction), un *VM Template*:
|
|
Actualmente armamos nuestras plantillas de VM, *Proxmox VM Templates*, a partir de imágenes *cloud-init* principalmente de las distribuciones que usamos, como [las de la debian](https://cloud.debian.org).
|
|
|
> (...) 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.
|
|
# Plantillas propias o de terceros + *cloud-init*
|
|
|
|
|
|
|
|
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.
|
|
La estrategia recomendada para armar VMs es utilizando [*cloud-init*](https://cloud-init.io/), una tecnología extremadamente popular y extendida, que viene a resolver precisamente la de configuración específica de diversas configuraciones, particularmente la IP y las credenciales de acceso, de las múltiples instancias que se obtienen de una plantilla.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- 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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- 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).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# 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.
|
|
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.
|
|
|
|
|
|
| ... | @@ -165,4 +121,4 @@ root@pve_node01:~# rm debian-10-generic-amd64.qcow2 |
... | @@ -165,4 +121,4 @@ root@pve_node01:~# rm debian-10-generic-amd64.qcow2 |
|
|
|
|
|
|
|
# Referencia histórica
|
|
# Referencia histórica
|
|
|
|
|
|
|
|
Antes de usar cloud-image / cloud-init, empezamos por [[automatizar la forma manual que teníamos de armar Templates y VMs en PVE]] |
|
Antes de usar cloud-image / cloud-init, empezamos por [[automatizar la forma manual que teníamos de armar Templates y VMs en PVE]]. |
|
\ No newline at end of file |
|
\ No newline at end of file |
