Tareas #6011

Tareas #5929: Nueva plataforma de servidores

Tareas #5965: Instalación de servidores físicos

Tareas #6009: Automatización de la configuración de los servidores con ansible

Playbook de creación de un virtual o de un container

Añadido por Daniel Viñar Ulriksen hace 7 meses. Actualizado hace 9 días.

Estado:ResueltaFecha de inicio:2018-08-01
Prioridad:NormalFecha fin:
Asignado a:Daniel Viñar Ulriksen% Realizado:

70%

Categoría:-Tiempo dedicado:55.00 horas
Versión prevista:-

Descripción

Ya hay 3 nombres de dominio definidos en el inventario para contenedores o virtuales en guri.

Con los módulos ansible proxmox y proxmox_kvm conviene armar un playbook de creación de un servidor. Típicamente, es una tarea con una cantidad de variables.

Primero hacer un playbook lineal con los valores de los argumentos escritos a fuego en el playbook. Cuando es anda, estudiar la buena manera de organizar los parámetros, que son a priori por host.


Peticiones relacionadas

relacionada con Computación en la nube para el Interior - Tareas #6116: Proceso de creación de un contendor LXC En curso 2018-12-17 2018-12-28

Histórico

#1 Actualizado por Daniel Viñar Ulriksen hace 6 meses

  • Estado cambiado Nueva por En curso
  • % Realizado cambiado 0 por 10

#2 Actualizado por Daniel Viñar Ulriksen hace 6 meses

Un primer playbook funcional de creación de un container con el módulo ansible proxmox:
https://git.interior.edu.uy/adminsys/config/blob/master/instalar_araza.yml

Temas:
  • el parámetro ip_address documentado no parece funionar. A la inversa, en los ejemplos se da la IP mediante sub-parámetros a netif:, con una sintaxis algo rara, que no termina de ser del todo yaml, me parece,
  • por ahora tengo la contraseña a fuego (luego sería mejor borrar ese commit, aunque el proyecto sea de acceso privado). No logro usar la variable PROXMOX_PASSWORD que se menciona en la doc. con un export PROXMOX_PASSWORD=mi_contrtasena antes de correr el playbook no funciona, globalmente la solución en ansible parece ser usar los "vault":

#3 Actualizado por Daniel Viñar Ulriksen hace 6 meses

Dos documentaciones interesantes:

#4 Actualizado por Daniel Viñar Ulriksen hace 5 meses

Acá hay una contribución que se presenta como un PoC (proof of concept) de los módulos proxmox de ansible.

#5 Actualizado por Daniel Viñar Ulriksen hace 5 meses

  • % Realizado cambiado 10 por 20
El playbook más avanzado de creación de contenedor es este de belvil.net
Tardé en comprender el módulo proxmox de ansible:
  • cuando se pone un state=present es para provocar la creación, en cual caso NO hay que poner la VMID.
  • al crear el contenedor, no se puede poner state=started. Aparentemente este parámetro requiere que esté creada la VM, y la arranca. Al contrario requiere la VMID.

Tal cual está el script genera los contenedores con sus parámetros de inventario (aunque falta parametrizar cosas como la IP y MAC addr), los arranca, pero el único acceso que define es como root, y el root está cerrado con password en ssh (default open-ssh-server). Falta por ende generar una forma de acceso a la VM.

Tenemos la posibilidad del comando:

pct <VMID> consola

Pero no estoy logrando en ansible ir a loguearme e ingresar comandos en esa consola, para crear el usuario deploy.

También estaba experimentando usar el comando:

pct push <VMID> <archivo> <destino>

que copia una archivo en la VM, para subir las claves ssh en deploy.

Idea al escribir esto: usar solo pct push para subir las claves del deploy (o del root) del servidor madre al contenedor.

#6 Actualizado por Daniel Viñar Ulriksen hace 5 meses

  • % Realizado cambiado 20 por 30

Listo el playbook de creación de un contenedor, se puede retomar casi tal cual para usarlo en @interior.edu.uy".

#7 Actualizado por Andrés Pías hace 5 meses

Copié el rol y playbooks dentro de mi rama andres-dev y configuré variables:

Daniel Viñar Ulriksen escribió:

Listo el playbook de creación de un contenedor, se puede retomar casi tal cual para usarlo en @interior.edu.uy".

Quedaron algunas cosas por resolver:
  • Al correr el playbook se observan errores:
    fatal: [pitanga.interior.edu.uy -> guri.interior.edu.uy]: FAILED! => {"changed": false, "msg": "uploading of template debian-9.0-standard_9.5-1_amd64.tar.gz failed with exception: 403 Forbidden: {\"data\":null}"}
    
  • Me sigue sin convencer poner una Mac y una IP por defecto para cualquier contenedor LXC. No entiendo o no recuerdo como se sobrescriben estos valores para cada contenedor en particular.
  • No nos tenemos que olvidar de hacer un merge de la rama andres-dev a la master.

#8 Actualizado por Daniel Viñar Ulriksen hace 5 meses

  • % Realizado cambiado 30 por 70

Ya está, tenemos el playbook crear_lxc.yml más o menos operacional, nos sirvió para araza y mburucuya.

#9 Actualizado por Daniel Viñar Ulriksen hace 4 meses

Caímos sobre un error de acceso a un contenedor recién creado:

TASK [crear_lxc : instalar contenedores proxmox en guri] **************************************************************************************************************
changed: [mburucuya.interior.edu.uy -> botija.interior.edu.uy]

TASK [crear_lxc : Mirá el número de la VM] ****************************************************************************************************************************
ok: [mburucuya.interior.edu.uy] => {
    "contenedor": {
        "changed": true, 
        "failed": false, 
        "msg": "deployed VM 101 from template local:vztmpl/debian-9.0-standard_9.5-1_amd64.tar.gz" 
    }
}

(...)

TASK [crear_lxc : arrancar el contenedor] *****************************************************************************************************************************
changed: [mburucuya.interior.edu.uy -> botija.interior.edu.uy]

PLAY [configuración del acceso del usuario deploy] ********************************************************************************************************************

TASK [acceso_deploy : instalar paquetes para seguridad y admin] *******************************************************************************************************
fatal: [mburucuya.interior.edu.uy]: UNREACHABLE! => {"changed": false, "msg": "Failed to connect to the host via ssh: ssh: connect to host mburucuya.interior.edu.uy port 22: Network is unreachable\r\n", "unreachable": true}
    to retry, use: --limit @/home/ulvida/Documentos/tech/interior/config/site.retry

PLAY RECAP ************************************************************************************************************************************************************
mburucuya.interior.edu.uy  : ok=8    changed=3    unreachable=1    failed=0  

En realidad, aparentemente el problema sucede sólo cuando borramos un contenedor y que volvemos a crear uno con la misma IP. Y el problema es simplemente que, en las tablas del bridge en el servidor madre, la IP aún está asociada a otra MAC address, como documentado acá para proxmox, y en la contribuciń siguiente un enlace al problema más general.

¿hacemos un clean de las tablas arp? Ok, pero no es urgente.

#10 Actualizado por Daniel Viñar Ulriksen hace 4 meses

Probé bastante soluciones (más bien workaround) para el problema anterior. Raro.

  • El síntoma: si existe un contenedor (o cualquier servidor en la vuelta, sin duda) con una IP, que se lo suprime, al crear un nuevo contenedor con la misma IP (pero con una dirección MAC diferente), no se llega ni en ping (menos en ssh) al mismo.
  • La solución (a mano): Se resuelve cuando uno entra a la consola del contenedor (a través de la consola proxmox) y simplemente tirar cualquier comando de red.

#11 Actualizado por Daniel Viñar Ulriksen hace 4 meses

  • Asignado a cambiado Cielito - adminsys por Daniel Viñar Ulriksen

Los parámetros del módulo proxmox de ansible no están muy bien documentados, pero en realidad, sólo retoma la APIv2 de proxmox, a través del wapper python proxmoxer.

Por ejemplo, en /nodes/{node}/lxc, pestaña POST, tenemos las especificaciones que tanto buscamos para definir los parámetros de red netif.

#12 Actualizado por Daniel Viñar Ulriksen hace alrededor de 1 mes

  • Añadido relacionada con Tareas #6116: Proceso de creación de un contendor LXC

#13 Actualizado por Daniel Viñar Ulriksen hace alrededor de 1 mes

Perdón por no haber documentado, la última versión que yo trabajé de este rol debería ser la versión subida a github, más específicamente este commit.

Hay un commit más reciente sobre este tema en nuestro gitlab

Conviene ver un merge manual el tema.

#14 Actualizado por Daniel Viñar Ulriksen hace alrededor de 1 mes

  • Asignado a cambiado Daniel Viñar Ulriksen por Santiago Martinez

#15 Actualizado por Daniel Viñar Ulriksen hace alrededor de 1 mes

Conviene ver un merge manual el tema.

En este commit tomé en cuenta el parámetro faltante de la memoria del container. ¿Algo más que se me haya escapado para pasar a trabajar en la versión galaxy del role?

Santiago, ¿podés verificar y luego poner la referencia oportuna en los requirements.yml? Y luego borrar el role local de config denominado crear_lxc.

#16 Actualizado por Santiago Martinez hace alrededor de 1 mes

Ya quedó efectuado el merge manual de los avances en paralelo sobre el rol 'crear_lxc'. La versión resultante es el commit

En el proyecto 'config' de git.interior ya fue eliminado el role 'crear_lxc', y actualizados los host_vars y requirements.yml para funcionar correcamente con el role de la galaxia en el commit

La integración fue probada recreando los contenedores de Pitanga y Guayabo.

#17 Actualizado por Andrés Pías hace alrededor de 1 mes

Para tener forma de crear virtuales KVM, la idea es modificar el propio rol crear_lxc, el cual por ende debería recibir un cambio de nombre.

Por el momento decidí trabajar mas bien en desarrollo y prueba del modulo proxmox_kvm para en un paso futuro darle una mayor parametrización al rol en cuestión.

Para mantener versionando en local de los proyectos github usamos ansible-galaxy con -g:

apias@batareload:~/desarrolloudelar/ansible/config$ ansible-galaxy install -r requirements.yml -g --force

Creo una rama dentro del proyecto crear_lxc para hacer unas pruebas con:

apias@batareload:~/desarrolloudelar/ansible/UdelaRInterior/crear_lxc$ git checkout -b crear_vm

En esta rama, en la task del role modifiqué todas las referencias al módulo proxmox por proxmox_kvm.

Como voy a hacer pruebas sobre yeta.interior.edu.uy, procedí a definirlo y configurarlo:
  • identificando sus ips y viendo que tiene resolución ipv4 e ipv6
  • agregándolo al inventario
  • configurando sus hosts_vars

Luego lanzo el playbook site.yml sobre yeta para probar si funciona:

ansible-playbook --limit yeta.interior.edu.uy config/site.yml -verbose

Al correrlo de esta manera observo este error:

TASK [crear_lxc : Instalar contenedores proxmox en el nodo proxmox idóneo, sin disco adicional] ******************************************************************
fatal: [yeta.interior.edu.uy -> guri.interior.edu.uy]: FAILED! => {"changed": false, "msg": "Unsupported parameters for (proxmox_kvm) module: disk, hostname, nameserver, netif, ostemplate, password, pubkey Supported parameters include: acpi, agent, api_host, api_password, api_user, args, autostart, balloon, bios, boot, bootdisk, clone, cores, cpu, cpulimit, cpuunits, delete, description, digest, force, format, freeze, full, hostpci, hotplug, hugepages, ide, keyboard, kvm, localtime, lock, machine, memory, migrate_downtime, migrate_speed, name, net, newid, node, numa, numa_enabled, onboot, ostype, parallel, pool, protection, reboot, revert, sata, scsi, scsihw, serial, shares, skiplock, smbios, snapname, sockets, startdate, startup, state, storage, tablet, target, tdf, template, timeout, update, validate_certs, vcpus, vga, virtio, vmid, watchdog"}
    to retry, use: --limit @/home/apias/desarrolloudelar/ansible/config/site.retry

Lo que implica que hay que ir a leer mas sobre el comando proxmox_kvm.

#18 Actualizado por Andrés Pías hace 19 días

  • Asignado a cambiado Santiago Martinez por Andrés Pías

21 Enero

Estuve mirando esta PVE IaaS proof of concept, me descargué el código y me puse a entender con este ejemplo qué parámetros debo usar para trabajar con proxmox_kvm (dudas con especificar la red, etc).

También estuve mirando esta documentación. Esto también me sirvió. Hice mucho de prueba y error.

El mensaje de error decía:

Unsupported parameters for (proxmox_kvm) module: disk, hostname, nameserver, netif, ostemplate, password, pubkey

Concretamente al interpretar esto se deduce que solo la primera parte del comando funciona:

    proxmox_kvm:
        node: "{{ node }}" 
        api_user: "{{ api_user }}" 
        api_host: "{{ api_host }}" 
        api_password: "{{ node_deploy_password }}" 
        cores: "{{ cores }}" 
        memory: "{{ memory }}" 
        storage: "{{ storage }}" 

O sea me quedan varias variables por fuera, principalmente de las host vars.
  • Cómo indico el disco (disk)? por virtio
  • Cómo defino parámetros de red: (hostname, nameserver, netif)? con net y args
  • Cómo completo el resto: ostemplate, password, pubkey ? Ostemplate dentro de los args

26 Enero

Me enfoque en este pedazo de código de la prueba de concepto para entender y resolver la parte de los args:

-append "inst.stage2={{ item.value.stage2 | default(deployments[item.value.type].stage2) }}
 inst.repo={{ item.value.repo | default(deployments[item.value.type].repo) }}
 inst.ks={{ item.value.ks | default(deployments[item.value.type].ks) }}
 rd.noverifyssl net_cfg=#network --device=link --bootproto=
{% if item.value.network is defined %}
{% if ( item.value.network.ip is defined and item.value.network.netmask is defined ) %}static
 --ip={{ item.value.network.ip}} --netmask={{ item.value.network.netmask }}
{% if item.value.network.gateway is defined %}
 --gateway={{ item.value.network.gateway }}
{% endif %}
{% if item.value.network.nameserver is defined %}
 --nameserver={{ item.value.network.nameserver }}
{% endif %}
{% endif %}
 --hostname={{ item.key }}#" 

Hice una serie de modificaciones como quitar lo de descargar e instalar el template que era propio de un lxc. Factoricé muchas cosas. Modifiqué la forma de determinar el Id de la VM que está corriendo ya que se hace de otra manera cuando se trata de un LXC. Luego probé si funcionaba

ansible-playbook --limit yeta.interior.edu.uy config/site.yml -verbose

y me encontré con esto:

Tengo un tema, el módulo proxmox_kvm si uso args requiere que el api_user sea root@pam, pero ese usuario no tiene permisos para autenticarse....

Cómo usé el parámetro args me dice lo siguiente: "args parameter require root@pam user." y si pongo api_user: root@pam, luego tengo " authorization on proxmox cluster failed with exception: Couldn't authenticate user: root@pam"

29

Encontré que el error con args tiene que ver con un bug recientemtne reportado

Busco otra forma de instalar un sistema operativo en una virtual KVM, sin necesidad de usar el args. Veo que hay distintas opciones como esta que ojeo pero entiendo que meterme con eso es complicarme demasiado siendo que perfectamente puedo usar el parámetro args. Encuentro también este otro ejemplo de usar args para levantar una virtual KVM.

30

Intento seguir adelante ejecutando con el usuario root@pam. Para que esto funcione tengo que especificar la contraseña root de guri como parte del parámetro api_password del comando proxmox_kvm.

Primero intenté algo complicado:

¿cómo hago para que almacenar en una variable de las host_vars de un host, un valor almacenado en una variable del grupo proxmox?
concretamente en las variables de yeta.interior quiero poner node_root_password: "{{guri_contrasenha_root}}"

Daniel me respondé:

A ver: conceptualmente esa variable diría que se debe llamarse "root_password" y poder tener definiciones diferentes por host (a priori no tener el nombre del host en el de variable).
El tema es que necesitamos acá acceder, desde un playbook ejecutándose para un futuro container, tener la contraseña (por no poder acceder con otra autenticación) de otro host, el servidor madre.
Sugiero que dejes ese tema documentado en algún lado oportuno, y sigas con el playbbok en sí, poniendo "en duro", en el vault del virtual, esa contraseña (que vas a buscar donde se deba, la de ahora deber ser común a los 3 nodos y estar en secretos.yml)

Entonces luego salí en búsqueda de esa contraseña. Pude comprobar que la password contrasenha_root_default almacenada en secretos.xml no coincide con la contraseña root de Gurí.
Entendí que en config/group_vars/proxmox/vault/main.yml (variables del grupo Proxmox que pasó a ser nodos_seciu) está la clave root de guri. Pedí indicaciones para buscar la clave de los vaults para desencriptar dicho archivo. Probé con una clave a fuego puesta en una vieja versión del ansible.cfg y con la que está en compartido/ansible/contrasenha_vault (en Bourdeu) y ninguno sirvió para descencriptar con ansible-vaults view:

ERROR! Decryption failed (no vault secrets were found that could decrypt) for /home/apias/desarrolloudelar/ansible/config/group_vars/proxmox/vault/main.yml

Al encontrarme trancado, decidí cambiar la clave root de guri por la genérica que está definida en secretos.yml ( contrasenha_root_default) e hice las correspondientes modificaciones a las host_vars de yeta.interior.edu.uy. A partir de ese momento las cosas empezaron a funcionar.

31

Al momento trabajé directamente en el proyecto del rol crear_lxc que teníamos en github. Básicamente adapté el task/main.yml para que en lugar de crear un contenedor lxc cree una virtual kvm.
La vm ya se crea, se le asigna disos, red pero aún no se le ha instala un sistema operativo.
Al momento no hay ninguna toma de decisión respecto al tipo de host que se quiera crear.

Hice mi commit a mi rama definida dentro del proyecto

apias@batareload:~/desarrolloudelar/ansible/UdelaRInterior/crear_lxc$ git add -A
apias@batareload:~/desarrolloudelar/ansible/UdelaRInterior/crear_lxc$ git commit -a -m "Rol modificado para crear vms kvm en lugar de lxc, trabajo inicial con args" 
apias@batareload:~/desarrolloudelar/ansible/UdelaRInterior/crear_lxc$ git push origin crear_vm

Este último commit está acá

#19 Actualizado por Andrés Pías hace 12 días

Seguí avanzando imitando mucha cosa de la Proove of concept, entendiendo y completando los args y usando preesed para automatizar la instalación y configuración del sistema operativo. Hice este nuevo commit dentro de mi rama crear_vm

#20 Actualizado por Andrés Pías hace 9 días

  • Estado cambiado En curso por Resuelta
  • Asignado a cambiado Andrés Pías por Daniel Viñar Ulriksen

Dado que no vamos a seguir trabajando específicamente en un rol para crear completamente una virtual KVM, podemos dar por concluida esta tarea y la vamos cerrando?
Mi trabajo con Godel lo voy a documentar en la tarea correspondiente #6051

Santiago Martinez escribió:

Ya quedó efectuado el merge manual de los avances en paralelo sobre el rol 'crear_lxc'. La versión resultante es el commit

En el proyecto 'config' de git.interior ya fue eliminado el role 'crear_lxc', y actualizados los host_vars y requirements.yml para funcionar correcamente con el role de la galaxia en el commit

La integración fue probada recreando los contenedores de Pitanga y Guayabo.

Exportar a: Atom PDF