Creando Taberna WordPress desde cero: servidor (I)

Como ya comenté en el primera entrada de esta web (¡Hola Mundo!) una de las ideas era crear un sitio totalmente desde cero e iros contando el proceso de creación sobre la marcha, así que vamos a ello contando en esta primera parte como se configuró el servidor e instalé WordPress, posteriormente se trabajará un poco el estilo para que la web «sea más cómoda», se le dará algo de funcionalidad, integrará la comunidad Gitter de TaberaWP y poco a poco se construirá un MVP… pero vamos por partes como dijo Jack el destripador:

Creando container desde Proxmox

Lo primero que hacemos desde la consola web de Proxmox es crear el contenedor (Crear CT) y configuramos los parámetros (posteriormente podremos aumentar o disminuir el HD, memoria, procesadores, etc.); para usar una IP externa FailOver que anteriormente habremos solicitado desde el panel de control de nuestro proveedor del servidor dedicado y configurado su MAC Virtual y Registro Inverso, en red seleccionamos Bridged mode y como puente (bridge) seleccionamos vmbr0.

Después y antes de arrancar el contenedor, seleccionamos el contenedor y en Redes, marcamos el dispositivo de red, seleccionamos Editar y en la Dirección Mac ponemos la Mac Virtual que tenemos asignada desde el panel de Control de nuestro proveedor:

A continuación desde el host arrancamos el contenedor, entramos en el y editamos el interface de red:

# vzctl init 105
# vzctl enter 105
105# nano /etc/network/interfaces

Le llamamos eth0 al interface y le ponemos los datos de nuestra IP del siguiente modo:

auto eth0
iface eth0 inet static
 address Nuestra-IP-Failover
 netmask 255.255.255.255
 broadcast Nuestra-IP-Failover
 gateway IP_NUESTRO_SERVIDOR_PRINCIPAL_ACABADA_EN_1_xxx.xxx.xxx.1
 pointopoint IP_NUESTRO_SERVIDOR_PRINCIPAL_ACABADA_EN_1_xxx.xxx.xxx.1

Una vez creado el contenedor con la plantilla Open VZ de Ubuntu 16.04.02 LTS, nos queda crear las carpetas compartidas con el host para que el contenedor únicamente se ocupe de la configuración y los datos residan en el propio host para poder cambiar rápidamente de contenedor. Iniciamos la máquina si no lo estaba y creamos el directorio donde albergaremos los archivos de la web que en breve mapearemos a una carpeta del host:

125# mkdir /home/webs
125# mkdir /home/webs/tabernawp.com

Aprovechamos para crear también los directorios de la Base de Datos:

125# mkdir /var/lib/mysql
125# mkdir /home/db-backups

A continuación apagamos el contenedor con el Ubuntu 16.04 (desde consola o desde la administración web) y desde el host creamos el archivo con el ID de la máquina y extensión mount en el directorio de configuración vz (/etc/vz/conf), suponiendo que nuestro contenedor tiene el ID 125:

# cd /etc/vz/conf
# touch 125.mount

nos aseguramos que en el host tenemos la carpeta donde vamos a albergar los archivos, por ejemplo /var/lib/vz/tabernawp-files (con por ejemplo los directorios db, log y web) ya que debe existir el directorio a mapear tanto en el host como en el contenedor y editamos el archivo /etc/vz/conf/125.mount con el siguiente contenido (ya incluimos los directorios de la Base de Datos):

#!/bin/bash
. /etc/vz/vz.conf
. ${VE_CONFFILE}
SRC1=/var/lib/vz/tabernawp-files/web
DST1=/home/webs/tabernawp.com
SRC2=/var/lib/vz/tabernawp-files/db/data
DST2=/var/lib/mysql
SRC3=/var/lib/vz/tabernawp-files/db/backup
DST3=/home/db-backups

mount -n -t simfs ${SRC1} ${VE_ROOT}${DST1} -o ${SRC1}
mount -n -t simfs ${SRC2} ${VE_ROOT}${DST2} -o ${SRC2}
mount -n -t simfs ${SRC3} ${VE_ROOT}${DST3} -o ${SRC3}

Si existen ambos directorios y todo está correcto, podemos arrancar la máquina desde consola o desde el interface web,entrar en el contenedor y comprobar que existe el directorio:

# vzctl start 125
# vzctl enter 125
125# ls /home/webs/taberna.com

Si vemos que no resuelve los DNS’s podemos poner los de Google (https://developers.google.com/speed/public-dns/) en /etc/resolv.conf cada vez que se inicie el sistema desde /etc/rc.local para lo que lo editamos:

125# nano /etc/rc.local
echo "nameserver 8.8.8.8" > /etc/resolv.conf
echo "nameserver 8.8.4.4" >> /etc/resolv.conf

Y probamos si hace ping correctamente al exterior:

125# ping google.com

Conectándonos por SSH

Aunque la administración se puede (y debería) realizar completamente desde el host, para la ejecución de las tareas con Ansible PlayBooks vamos a usar SSH para poder gestionar cada contenedor independientemente (en otros posts veremos el uso de mosh, una auténtica maravilla).

Primero entramos en el contenedor (suponiendo que está arrancado):

# vzctl enter 125

y comprobamos que esté instalado OpenSSH

125# service ssh status

de no ser así lo instaríamos, aunque la plantilla Proxmox del Ubuntu Xenial Xerus (16.04.2 LTS) ya trae OpenSSH instalado por defecto:

125# apt-get install openssh-server

Ahora ya podemos ejecutar las tareas desde nuestro ordenador con el Ansible Playbook.

Provisionando el servidor con Ansible PlayBook

Ahora que tenemos un «servidor pelado» al que nos podemos conectar por SSH nos queda «provisionarlo», es decir, instalar en el mismo todo el software necesario para que realice las tareas a las que está destinado, en nuestro caso servir una web en WordPress, esta que estáis leyendo.

En mi caso y en una progresión de pruebas desde hace años, la configuración que me gusta y utilizo es:

• Nginx como servidor web, sin Apache, con el inconveniente que tenemos que gestionar los archivos de configuración sin el uso de .htaccess, pero a mi me gusta más y me brinda unas cuantas facilidades. Además para la funcionalidad esperada debe tener instalado el módulo fastcgi_cache_purge.
• PHP 7.1 como fpm (fast process manager) escuchando en un socket en vez de en por TCP/IP (esto depende mucho del tipo de web, carga, etc.).
• MariaDB 10.1.22
• Y algunos programas de utilidades además de WP-CLI y por supuesto WordPress.

Usando Ansible en Windows

Yo utilizo Windows por una serie de razones que puede que explique en otro momento, en este post desde luego no, y si, desde Windows se puede tener un entorno completo de desarrollo como el Linux más geek o el Mac más cool, bueno, al menos para mi es funcional al 100%.

Para eso utilizo la consola de Ubuntu de Windows 10, Windows Subsystem for Linux ó WSL, para mi la consola de Ubuntu 😉

Si no la tenéis instalada y queréis usarla, con una búsqueda en San Google os guiará por los cuatro pasos (paso más, paso menos) necesarios para meter al pingüino dentro de la ventana.

Para usar Ansible con las funcionalidades de las últimas versiones primero miramos si nuestra versión de Ubuntu en la consola de Windows 10 es Xenial (16.04.2 LTS, Xenial Xerus) con lsb_release -a, si es la versión 14.04 (trusty) y nuestra versión de Windows 10 es la Creators Update (versión 1703 en Configuración > Sistema > Acerca de), entonces podemos actualizar a Xenial como lo haríamos en Ubuntu:

# sudo do-release-upgrade

El proceso tardará un ratito, te puedes ir a preparar un café, y nos realizará algunas preguntas por lo que tendremos que atender la consola, una vez actualizada, cerramos la consola y la volvemos a abrir y comprobamos de nuevo nuestra versión de consola de Ubuntu con:

# lsb_release -a

Podemos instalar programas como mc, aptitude y screen a nuestro gusto:

$ sudo apt-get install aptitude
$ sudo apt-get install mc
$ sudo apt-get install screen

Para poder copiar y pegar fácilmente desde el teclado, usar el ratón, cambiar theme y muchas otras opciones, instalamos wsltty (https://github.com/mintty/wsltty para sustituir la consola por defecto de Ubuntu Windows 10, instalamos desde https://github.com/mintty/wsltty/releases y botón derecho sobre la consola nos aparecerá el menú de configuración:

• Comandos en http://mintty.github.io/mintty.1.html
• Wiki en https://github.com/mintty/mintty/wiki

Bien, ahora que ya tenemos nuestra consola de Ubuntu preparada, actualizada y tuneada a nuestro gusto, instalamos Ansible que será el encargado de automatizar nuestras tareas, desde instalar el servidor, hasta gestionarlo y realizar Continuos Delivery, desarrollar en local y con un sólo comando enviar los archivos a nuestro WordPress sin necesidad de mantener una copia Git en el mismo, pero manteniéndola en local (no seas hereje y trabajes sin Git, HG, SVN…), en nuestro repositorio externo (GitHub, BitBucket, GitLab…), a la vez que lo probamos con Travis CI u otra herramienta de CI, suena bien? bueno, todo esto lo iremos viendo poco a poco y siempre que el tiempo lo vaya permitiendo. Lo dicho, que instalamos Ansible:

$ sudo apt-get install ansible

Uno de los motivos por los que me encanta Ansible frente a otros sistemas de automatización, es su simplicidad en el lenguaje YAML para definir las tareas, el uso de templates jinja2, pero sobre todo, que no tenemos que tener instalado nada en el servidor (bueno, python si, pero ya viene de serie 😉 ), sólo un acceso SSH al mismo.

Bueno, como aún queda mucho por contar y para no alargar en exceso esta entrada, dejamos pendiente la segunda parte con el aprovisionamiento del servidor e instalación de WordPress con nuestro Playbook que de momento utiliza siete roles pero se irá ampliando y perfeccionando. Veremos como usar el Playbook para instalar todo, o solo el webserver el de database en otro distinto, tener un servidor de develop en VirtualBox, otro de Staging  y el de producción… y sobre todo empezaremos a cambiar la apariencia a la web, que van a decir que no tenemos ni idea de CSS 🙂 de momento he hecho un pequeño cambio directamente en el personalizador de WordPress para que al menos se pueda leer minimamemnte