WordPress con GridPane, Proxmox y OVH

Los que sepáis lo que es GridPane, Proxmox y OVH ya sabréis de que va el tema, a los demás os parecerá que es algo Friki (que puede que lo sea) y también algo de un hosting que ardió.

Por resumirlo mucho, GridPane es a día de hoy el panel especializado de WordPress en servidores de alto rendimiento, algo que no es fácil explicar sin experimentarlo. Sin paneles bonitos con cientos de opciones y medidores de colores, lo necesario y con las configuraciones más optimizadas.

Proxmox es un sistema operativo para la virtualización, lo que nos permite crear varias máquinas virtuales con ese servidor físico y de gran tamaño que hemos alquilado para nuestros servicios y/o los de nuestros clientes.

Y OVH es un proveedor de hosting y de servicios de internet, que al igual que Google Cloud, Amazon Web Services y otros muchos, utilizan tanto particulares como compañías de hosting para ofrecer sus servicios y tristemente conocido en las últimas semanas por el incendio de uno de sus centros de datos en Estrasburgo (lo que podría haberle sucedido a cualquier servicio similar).

Normalmente para mis clientes les suelo recomendar un servicio de hosting personalizado según sus necesidades, en los casos «más personalizados» les ofrezco un servidor a medida con GridPane y generalmente sobre un VPS, que suele ser una máquina Vultr High Frequency Compute adecuada a las necesidades del cliente. Esta web, por ejemplo, está alojada en Kinsta, uno de los hostings que recomiendo (sólo recomiendo hostings o servicios que utilice para mi o haya probado con mis clientes),

Pero para mis pruebas y algunos servicios propios, utilizo máquinas virtuales sobre un servidor OVH con Proxmox y para un nuevo proyecto que comienzo en breve, la máquina de Staging para el cliente la voy a montar sobre esta infraestructura.

Experiencia previa

Cuando comencé con la web de la revista DNG, contraté un servidor en USA (ServerPronto), que configuré con servidor de DNS (BIND), servidor de correo, web, base de datos, etc… todos los servicios configurados a mano y en el mismo servidor.

Grave error, un único punto de fallo. Con los años he ido aprendiendo a separar lo máximo posible los servicios y seleccionar proveedores especializados para cada servicio, además de la libertad de poder migrar un sólo servicio sin tener que cambiar todo.

Pero la verdad es que aprendí mucho en el proceso, con el tiempo fui automatizando pasos, después aprendí Ansible y como automatizar la creación de servidores desde local hasta docenas o cientos en la nube; hasta me creé mis propios Playbooks especiales para WordPress (e inicialmente uno de PrestaShop cuando aún realizaba proyectos de ese CMS).

Con el servidor para la revista DNG (inicialmente en FreeBSD, después ya con Ubuntu), fui escribiendo mis guías para acordarme de los pasos y buscando por mi disco duro veo que tengo las siguientes:

• PASOS BÁSICOS CONFIGURACIÓN Ubuntu Server 9.10
• PASOS BÁSICOS CONFIGURACIÓN Ubuntu Server 10.04
• PASOS BÁSICOS CONFIGURACIÓN Ubuntu Server 12.04 LTS
• CONFIGURACIÓN Servidor Web (Ubuntu Server 12.04 LTS)
• CONFIGURACIÓN Foto DNG (Ubuntu Server 14.04 LTS Docker)
• CONFIGURACIÓN DNG Server (Ubuntu Server 16.04.02 LTS Open VZ)

Todas estas guías (realizadas en LibreOffice) tienen entre 40 y 70 páginas, de momento no las publico porque en primer lugar tendría que repasarlas por si tienen algunos datos no publicables (claves, etc.), además de ser configuraciones muy específicas y adaptadas a mis necesidades y también porque pueden contener algún error y estar obsoletas.

Actualidad

Ahora mismo sigo teniendo servidores en la máquina antigua que tendré que ir migrando, el caso es que están sobre un Proxmox 3.4 y el nuevo servidor tiene instalado un Proxmox 6.3, por lo que ha llegado el momento de parar de crear guías y publicar los cambios directamente en la web, como siempre para acordarme en próximas ocasiones, pero si además le puede servir de ayuda a alguien, pues tanto que mejor.

Después de contratar el nuevo servidor la semana pasada con un conjunto de IPs Failover para asignar a las máquinas virtuales, seleccioné como SO un Proxmox 6.3.

Una vez instalado el SO podemos acceder por SSH con los datos que nos envían por mail o al panel web del Proxmox con la IP o nombre de la máquina y puerto 8006.

Primero instalo un Nginx para hacer de reverse Proxy y poder acceder al gestor Proxmox desde el puerto 443 (https) u otro puerto a mi conveniencia, además del nombre de dominio que yo prefiera. Es tan fácil como seguir la siguiente guía https://pve.proxmox.com/wiki/Web_Interface_Via_Nginx_Proxy por lo que no necesita más explicación, los pasos son:

• Instalar Nginx
• Eliminar la configuración del sitio web por defecto.
• Crear la configuración para Proxmox.
• En dicha configuración redirigimos la petición al puerto 80 al deseado (443 u otro).
• Configuramos el certificado con el predeterminado de Proxmox, aquí o ideal es ir un paso más allá y con certbot crear un certificado válido para el dominio que configuremos.
• Hacer proxy al servidor local de Proxmox (https://localhost:8006).
• Comprobar la configuración y reiniciar Nginx.
• Configurar el servicio de Nginx para que se inicie sólo después de que los certificados estén disponibles.

Ya tenemos disponible la interface de Proxmox desde nuestro dominio y puerto SSL evitando tener que acceder desde el puerto 8006. Ahora desde web vamos a crear un servidor para utilizar en nuestro WordPress con GridPane.

Para GridPane no vale cualquier OS ni versión, tiene que ser un Ubuntu Server 18.04 LTS, así que nos descargamos la imagen ISO de Ubuntu 18.04 y que posteriormente subimos para poder usar en la instalación de nuestra máquina.

Creamos una nueva máquina virtual (crear VM), no contenedor que no es válido para GridPane. Seleccionado el disco, memoria, procesadores, etc que deseemos para la máquina, a posteriori podremos incrementar su potencia con más RAM, procesadores o espacio.

Desde el panel de control de OVH y en la IP Failover que vayamos a utilizar para nuestra máquina, seleccionamos Añadir una MAC Virtual y la ponemos en el controlador de red antes de crear nuestra nueva máquina, o si ya la hemos creado, la modificamos y añadimos la MAC con la máquina apagada.

Iniciamos la máquina y el proceso de instalación con la imagen ISO en el CD de la misma y continuamos el proceso desde la consola web mediante el noVNC integrado en Proxmox.

Una vez finalizada la instalación, deberemos entrar en la máquina y configurar la conectividad con la IP virtual a la que ya le configuramos la MAC. También deberemos saber la IP del servidor principal (el que ejecuta Proxmox) y con estas dos IPs vamos a nuestra configuración.

Todo el proceso anterior y la configuración de la tarjeta de red, está perfectamente indicado en la siguiente guía https://support.us.ovhcloud.com/hc/en-us/articles/360002394324-How-to-Connect-a-VM-to-the-Internet-Using-Proxmox-VE que a mi me ha salvado, ya que estaba configurando la maquina mediante /etc/network/interfaces que era el método utilizado hasta la versión de Ubuntu 16.04, ahora se realiza mediante Netplan (es lo que pasa por no estar al día como sysadmin y hacer a diario de developer)

Recordad que el archivo de configuración YAML utiliza espacios y no tabulaciones, aunque si usáis tabulaciones al ejecutar sudo netplan apply os avisará que debéis cambiar a espacios.

A diferencia de lo que pone en el manual, para editar el archivo de configuración (# sudo vi /etc/netplan/01-netcfg.yaml), os recomiendo nano ya que es más fácil de utilizar que vi. El archivo resultante será similar a este:

# This file describes the network interfaces available on your system
# For more information, see netplan(5).
 network:
   version: 2
   renderer: networkd
   ethernets:
           ens18:
                   dhcp4: no
                   dhcp6: no
                   addresses: [192.0.2.1/32]
                   gateway4: 201.0.116.254
                   nameservers:
                           addresses: [1.1.1.1,1.0.0.1]
                   routes:
                   - to: 201.0.116.254/32
                     via: 0.0.0.0
                     scope: link

Donde el nombre de la tarjeta por defecto será ens18 pero si no es vuestro caso, siempre podéis ver su nombre con $ ip add como se indica en la guía o también con $ ip link.

En «addresses», cambiaremos «192.0.2.1» con la IP Failover a la que le añadimos previamente la vMAC en el panel de OVH.

Donde pone «gateway4» y en la sección «routes», cambiaremos «201.0.116» con los tres primeros octetos de la IP del servidor dedicado (el que está ejecutando Proxmox) con un octeto final de «254».

En la lista de servidores DNS he puesto los de Cloudflare que son muy rápidos y los que suelo utilizar siempre, pero podéis configurar los de Google, OpenDNS o los que prefiráis.

Ya podemos aplicar la configuración con $ sudo netplan apply y si lo hemos realizado todo bien, ya tendremos acceso al exterior con resolución de nombres y desde el exterior hasta nuestro server. Podemos probar a realizar ping a cualquier dominio para ver si resuelve correctamente $ ping -c4 tabernawp.com

Ya casi tenemos todo disponible para configurar nuestro GridPane, pero después de los pasos iniciales necesitamos ejecutar en el servidor unos comandos como root (no con sudo), así que para poder ser root, necesitamos configurarle una contraseña al usuario root, para lo que ejecutamos $ sudo passwd root y ponemos el password deseado para el usuario root.

Ahora ya podemos conectarnos por SSH con nuestro usuario configurado previamente en Ubuntu y a continuación cambiar al usuario root ejecutando $ su root

Ya tenemos todo preparado. Vamos a nuestro panel de GridPane y realizamos un nuevo aprovisionamiento de servidor, seleccionando Custom VPS con el nombre y Datacenter que queramos y la IP configurada previamente.

A continuación GridPane nos indicará el comando a ejecutar como root en nuestro servidor (si lo ejecutamos con sudo, no llegará al final de la instalación) y en unos 15 minutos tenemos un servidor de alto rendimiento configurado. Después crearemos el sitio o sitios web ya con Nginx, Redis y todas las configuraciones optimizadas para nuestro estupendo servidor.

Conclusiones finales

El único problema de montar un servidor de alto rendimiento para el sitio web en staging del cliente, es que si todo está bien configurado y funciona de maravilla, nuestro cliente es posible que note que su web va más lenta cuando la pasamos a su sitio web definitivo, ya que no está tan optimizado como el servidor que hemos preparado para la fase de pruebas. Deberemos advertirle de estas circunstancias.

Recordad que en Proxmox tenemos tres cortafuegos, a nivel de centro de datos, a nivel de servidor y por último de la máquina virtual. Por defecto sólo está activado el del servidor. Cuidado si activamos el del centro de datos sin cambiar nada, porque nos quedaremos sin acceso a nuestro servidor, ni vía web ni mediante SSH.

Si os pasa esto, tenemos la opción de reinstalar el SO con Proxmox desde el panel de OVH, si aún no habéis realizado ningún trabajo y no perdéis nada, o esperar unos minutos. Al pasar unos minutos OVH detectará que el servidor no responde y lo arrancará con un núcleo de rescate, enviándoos los datos de acceso de emergencia.

Desde ahí podréis entrar por SSH a vuestro server y ya en la consola arreglar el problema, para a continuación reiniciarlo con el núcleo por defecto.

Para finalizar sólo deciros que no os recomiendo pelearos con Proxmox, servidores dedicados, máquinas virtuales, configuraciones, comandos, etc., ya que consume mucho tiempo y cualquier equivocación puede tirar por tierra todo vuestro trabajo.

Si os gustan las tareas de sysadmin, adelante, si sois desarrolladores recordad que los experimentos «mejor con gaseosa» y que los full stack están muy bien sobre el papel, pero optimizar servidor, base de datos, servidor web, PHP y CMS desde backend hasta frontend, suena muy bien, pero en mis más de 20 años trabajando en la web, creo que me sobran los dedos de una mano para contar los full stack reales que he conocido.