Autonomía digital y tecnológica

Código e ideas para una internet distribuida

Entorno de desarrollo en local para WordPress con Varying Vagrant Vagrants

Imago voragine.net

Qué es Varying Vagrant Vagrants

Varying Vagrant Vagrants (VVV) es una de las maneras recomendadas por la comunidad que desarrolla WordPress para poner en marcha un servidor de desarrollo en local.

VVV es un entorno de desarrollo para WordPress que usa Vagrant, una herramienta pensada para montar entornos de desarrollo. Vagrant usa máquinas virtuales para ello. Al usar Vagrant se puede elegir el sistema de virtualización. VVV recomienda Virtualbox. Vagrant añade al sistema de virtualización, por ejemplo Virtualbox, una capa que facilita la automatización a la hora de crear y gestionar las máquinas virtuales usadas en el entorno de desarrollo.

VVV viene listo para comenzar inmediatamente el desarrollo, equipado con todo lo necesario en un entorno de desarrollo incluyendo herramientas específicas de WordPress como wp-cli.

Instalar Varying Vagrant Vagrants

Al funcionar VVV con máquinas virtuales, hace falta tener activada la virtualización en la BIOS, que en muchos casos viene desactivada por omisión. Cada BIOS es diferente y el sistema de virtualización depende del procesador que use el ordenador. En los procesadores AMD se llama AMD Virtualization o Secure Virtual Machine. En los procesadores Intel se llama Virtualization Technology.

VVV funciona usando Vagrant y un motor de virtualización, por ejemplo Virtualbox. Así que hay que instalar ambos programas.

skotperez@lee:~$ apt install vagrant virtualbox

Después se puede instalar VVV:

skotperez@lee:~$ git clone -b stable https://github.com/Varying-Vagrant-Vagrants/VVV.git vvv
Clonando en 'vvv'...
remote: Enumerating objects: 279, done.
remote: Counting objects: 100% (279/279), done.
remote: Compressing objects: 100% (193/193), done.
remote: Total 14049 (delta 182), reused 123 (delta 85), pack-reused 13770
Recibiendo objetos: 100% (14049/14049), 8.47 MiB | 1.16 MiB/s, listo.
Resolviendo deltas: 100% (7169/7169), listo.

Y algunos plugins de VVV para montar entornos de desarrollo en local:

skotperez@lee:~$ cd vvv
skotperez@lee:~$ vagrant plugin install --local
Installing the 'vagrant-goodhosts' plugin. This can take a few minutes...
Fetching os-1.1.4.gem
Fetching vagrant-goodhosts-1.1.1.gem
Fetching vagrant-libvirt-0.7.0.gem
Installed the plugin 'vagrant-goodhosts (1.1.1)'!

Este último comando instala en local (solo para esta instancia de VVV) los plugins que vienen listados en el archivo Vagrantfile.

Configuración de los entornos de desarrollo: config.yml

Una misma máquina virtual puede contener varios entornos de desarrollo. Salvo necesidades muy específicas, a mí me parece lo más rápido y cómodo. Cada uno de los entornos se puede configurar en el archivo config/config.yml. En este archivo vienen varios ejemplos con distintas opciones que son útiles para empezar a familiarizarse con la versatilidad de VVV.

Para crear, antes de activar por primera vez la máquina virtual, el archivo config.yml se ejecuta vagrant status:

skotperez@lee:~$ vagrant status
__ __ __ __
\ V\ V\ V / Varying Vagrant Vagrants
\_/\_/\_/ v3.5.1-git::stable

Copying config/default-config.yml to config/config.yml
IMPORTANT NOTE: Make all modifications to config/config.yml in future so that they are not lost when VVV updates.

Platform: platform-linux-gnu shell:/bin/bash systemd vagrant-goodhosts CaseSensitiveFS shared_db_folder_disabled, VVV Path: "/home/skotperez/vvv"
Vagrant: v2.2.9, VirtualBox: v6.1.18_Debianr142142

Docs: https://varyingvagrantvagrants.org/
Contribute: https://github.com/varying-vagrant-vagrants/vvv
Dashboard: http://vvv.test

Current machine states:

default not created (virtualbox)

The environment has not yet been created. Run `vagrant up` to
create the environment. If a machine is not created, only the
default provider will be shown. So if a provider is not listed,
then the machine is not created for that environment.

A modo de ejemplo, para poner en marcha un entorno de desarrollo de este blog, de voragine.net, puedo incluir en el archivo config.yml las siguientes líneas:

voragine:
  skip_provisioning: false
  description: "Entorno de desarrollo de voragine.net"
  repo: https://github.com/Varying-Vagrant-Vagrants/custom-site-template.git
  hosts:
    - voragine.test
  custom:
    wpconfig_constants:
      WP_DEBUG: true
      WP_DEBUG_LOG: true
      WP_DISABLE_FATAL_ERROR_HANDLER: true # To disable in WP 5.2 the FER mode
    db_name: "voragine_db"
    db_prefix: "vrg_"
    live_url: "https://voragine.net"
    install_plugins:
      - pods
      - polylang

Hay multitud de opciones para crear un entorno de desarrollo: qué versión de PHP usar, conjunto de opciones ya definidas para un WordPress Multisite, qué plugins pre-instalar, configuración de la base de datos… Se pueden consultar la lista completa de opciones en la documentación oficial de VVV. Una manera más ágil de empezar es copiar y modificar los ejemplos que vienen en el archivo config.yml.

Poner en marcha el entorno de desarrollo, y pararlo

Una vez todo instalado la gestión de la máquina virtual que contiene el entorno de desarrollo se hace con Vagrant usando su interfaz de línea de comandos. Para poner en marcha la máquina virtual:

skotperez@lee:~$ cd vvv
skotperez@lee:~/vvv$ vagrant up

Y para parar la máquina:

skotperez@lee:~/vvv$ vagrant halt

Una vez la máquina virtual ha sido levantada VVV dispone de un panel de control en http://vvv.test/ donde se puede acceder a todos los entornos de desarrollo y a varias herramientas muy útiles para el desarrollo: Mailhog, un servidor de correo para simular el envío de aplicación; PHPMyAdmin, una interfaz web para gestionar bases de datos; paneles de estado de PHP.

El archivo config.yml trae activa por omisión la herramienta para generar certificados y que así los sitios funcionen con conexión HTTPS. Los certificados se generan automáticamente al levantar la máquina por primera vez.

Actualizar una máquina virtual

Para actualizar el sistema operativo que tiene la máquina virtual instalado, también usamos Vagrant. Primero nos descargamos la nueva versión:

skotperez@lee:~/vvv$ vagrant box update
==> default: Checking for updates to 'ubuntu/bionic64'
default: Latest installed version: 20210319.0.0
default: Version constraints:
default: Provider: virtualbox
==> default: Updating 'ubuntu/bionic64' with provider 'virtualbox' from version
==> default: '20210319.0.0' to '20210908.0.0'...
==> default: Loading metadata for box 'https://vagrantcloud.com/ubuntu/bionic64'
==> default: Adding box 'ubuntu/bionic64' (v20210908.0.0) for provider: virtualbox
default: Downloading: https://vagrantcloud.com/ubuntu/boxes/bionic64/versions/20210908.0.0/providers/virtualbox.box
Download redirected to host: cloud-images.ubuntu.com
Progress: 22% (Rate: 967k/s, Estimated time remaining: 0:05:05)

Para instalar la versión descargada hay que aprovisionar la máquina virtual, con provision:

skotperez@lee:~/vvv$ vagrant provision

Si la máquina virtual está parada y se quiere iniciar tras el aprovisionamiento se puede usar:

skotperez@lee:~/vvv$ vagrant up --provision

Si la máquina está activa:

skotperez@lee:~/vvv$ vagrant reload --provision

Añadir un nuevo entorno de desarrollo (un nuevo WordPress) a la máquina virtual

Para activar un nuevo sitio tenemos que editar el archivo config/config.yml y añadir sus características en un nuevo bloque, al estilo del descrito previamente.

Imaginemos que ahora quiero añadir un WordPress multisite que está en un servidor con una versión de PHP 5.6, obsoleta que quiero actualizar. En este caso viene bien un entorno de desarrollo porque antes de actualizar la versión de PHP en el servidor de producción puedo montarlo en local para ver que con la nueva versión de PHP no se rompe nada.

VVV me permite montar un entorno de desarrollo con la versión de PHP de mi elección, y luego cambiando una línea en el archivo de configuración, probar otra versión.

Empiezo montando el multisite con la misma versión que el servidor de producción, PHP 5.6:

sitio_obsoleto:
  skip_provisioning: false
  description: "Entorno de desarrollo de mi sitio obsoleto"
  repo: https://github.com/Varying-Vagrant-Vagrants/custom-site-template.git
  nginx_upstream: php56
  hosts:
    - sitio-obsoleto.test
    - otro.sitio-obsoleto.test
  custom:
    wp_type: subdomain
    wpconfig_constants:
      WP_DEBUG: true
      WP_DEBUG_LOG: true
      WP_DISABLE_FATAL_ERROR_HANDLER: true # To disable in WP 5.2 the FER mode
    db_name: "sitio_obsoleto_db"
    db_prefix: "wp_"

Para que en la máquina virtual esté disponible PHP 5.6, u otra versión de PHP hay que modificar el listado de extensiones activas en el archivo config.xml. Para ello, descomento la extensión php56 en la lista que figura en el archivo:

extensions:
  core: # The core VVV extensions
    - tls-ca # HTTPS SSL/TLS certificates
    - phpmyadmin # Web based database client
    #- memcached-admin # Object cache management
    #- opcache-status # opcache management
    #- webgrind # PHP Debugging
    #- mongodb # needed for Tideways/XHGui
    #- tideways # PHP profiling tool, also installs xhgui check https://varyingvagrantvagrants.org/docs/en-US/references/tideways-xhgui/
    #- nvm # Node Version Manager
    - php56
    #- php70
    #- php71
    #- php72
    #- php73
    #- php74
    #- php80

Se puede consultar en la documentación oficial de VVV un listado completo de extensiones .

Para activar la nueva configuración hay que reaprovisionar la máquina:

skotperez@lee:~/vvv$ vagrant reload --provision

Una vez que veo que el sitio está correctamente funcionando en local puedo probar a cambiar la versión de PHP, modificando la opción nginx_upstream: php56, por ejemplo a php74:

sitio_obsoleto:
  skip_provisioning: false
  description: "Entorno de desarrollo de mi sitio obsoleto"
  repo: https://github.com/Varying-Vagrant-Vagrants/custom-site-template.git
  nginx_upstream: php74
  hosts:
    - sitio-obsoleto.test
    - otro.sitio-obsoleto.test
  custom:
    wp_type: subdomain
    wpconfig_constants:
      WP_DEBUG: true
      WP_DEBUG_LOG: true
      WP_DISABLE_FATAL_ERROR_HANDLER: true # To disable in WP 5.2 the FER mode
    db_name: "sitio_obsoleto_db"
    db_prefix: "wp_"

Y vuelvo a reaprovisionar:

skotperez@lee:~/vvv$ vagrant reload --provision

Pasos para desplegar la version de desarrollo de un sitio en producción

Para poner en marcha un servidor de desarrollo de, por ejemplo, montera34.com, puedo seguir los siguientes pasos:

1. Configurar el nuevo sitio en el archivo config.xml y reaprovisionar

montera34:
  skip_provisioning: false
  description: "Entorno de desarrollo de montera34.com"
  repo: https://github.com/Varying-Vagrant-Vagrants/custom-site-template.git
  hosts:
    - montera34.test
  custom:
    wpconfig_constants:
      WP_DEBUG: true
      WP_DEBUG_LOG: true
      WP_DISABLE_FATAL_ERROR_HANDLER: true # To disable in WP 5.2 the FER mode
    db_name: "montera34com_db"
    db_prefix: "m34_"

Esto instalará un wordpress nuevo en ~/vvv/www/montera34/public_html/

2. Copiar los archivos del servidor de producción al entorno de desarrollo

Sustituir los archivos del wordpress que se acaba de crear en ~/vvv/www/montera34/public_html/ por los de la web en producción.

3. Importar la base de datos

Para importar la base de datos a la máquina virtual copiamos el archivo que contiene la base de datos (supongamos que es montera34.sql) a la carpeta ~/vvv/database/sql/backups/.Esta ubicación es accesible tanto desde el sistema host como desde la máquina virtual. Para importar la base de datos iniciamos primero sesión ssh en la máquina virtual, para ello usamos vagrant ssh:

skotperez@lee:~$ cd vvv
skotperez@lee:~/vvv$ vagrant ssh
    ✧ Hello Again! ✧         ✧            ✧    
✧   ▄▀▀▀▄▄▄▄▄▄▄▀▀▀▄   ✧  __ __ __ __
   ✧█▒▒░░░░░░░░░▒▒█      \ V\ V\ V /
 ▄▄  █░░█░░░░░█░░█ ✧      \_/\_/\_/
█░░█  █░░░▀█▀░░░█     ✧              ✧          
█░░█  ▀▄░░░░░░░▄▀ ✧      Have a nice day :)



This system is built by the Bento project by Chef Software
More information can be found at https://github.com/chef/bento
Last login: Sun Jul 24 10:03:39 2022 from 10.0.2.2
vagrant@vvv:~$

Una vez en la máquina virtual se puede importar la base de datos usando mysql o directamente wp-cli:

vagrant@vvv:~$ wp db import /srv/database/backups/montera34.sql --path=/srv/www/montera34/public_html

Ahora solo falta cambiar las URLs del sitio incluidas en la base de datos. Esto lo podemos hacer también desde la sesión SSH usando wp-cli:

vagrant@vvv:~$ wp db search-replace 'https://montera34.com' 'https://montera34.test' --path=/srv/www/montera34/public_html

Si no se quiere descargar todas las imágenes y resto de archivos estáticos del servidor de producción se puede incluir la opción live_url en la sección del sitio del archivo config.yml. Esto hará que si algún archivo no está disponible en local, se cargue la versión de producción.

Solución de problemas frecuentes

Recuperar una máquina virtual con disco corrupto

El error:

There was an error while executing `VBoxManage`, a CLI used by Vagrant for controlling VirtualBox. The command and stderr is shown below.

VBoxManage: error: VMDK: inconsistency between grain table and backup grain table in '/home/skotperez/VirtualBox VMs/vvv_161c6beea3c/ubuntu-bionic-18.04-cloudimg.vmdk' (VERR_VD_VMDK_INVALID_HEADER).

La solución:

Crear una máquina nueva y limpia, con el mismo archivo de configuración config.yml y con los backups de las bases de datos. Para ello se puede seguir el tutorial de la documentación oficial de VVV.

Problemas con el driver de virtualización en algunos kernels

En sistemas testing o unstable, al actualizar hay veces que obtenemos algún error con el driver de virtualización y virtualbox no es capaz de arrancar.

El error:

The VirtualBox Linux kernel driver (vboxdrv) is either not loaded or there is a permission problem with /dev/vboxdrv. Please reinstall the kernel module by executing

'/etc/init.d/vboxdrv setup'

as root. Users of Ubuntu, Fedora or Mandriva should install the DKMS package first. This package keeps track of Linux kernel changes and recompiles the vboxdrv kernel module if necessary.

La solución:

Comprobar que se tienen instalados los paquetes dkms, build-essential y linux-headers-$(uname -r). Esto se puede hacer con apt policy dkms.

Luego hay que añadir el driver de virtualización al archivo /etc/modules para que se cargue al inicio. Para ello añadir al archivo la siguiente línea:

vboxdrv

La solución se puede consultar en la wiki de Debian.

Problema con el gestor de gemas de ruby

Este error impide instalar los módulos que usan las máquinas virtuales, y tras determinadas actualizaciones de vagrant, no se pueden instalar actualizaciones de los plugins utilizados, por ejemplo de goodhosts.

El error:

SocketError: Failed to open TCP connection to rubygems.org:443 (getaddrinfo: Name or service not known) (https://rubygems.org/quick/Marshal.4.8/vagrant-goodhosts-1.0.0.gemspec.rz)

Más en detalle, si se intenta reparar los plugins, como sugiere vagrant, ocurre lo siguiente:

skotperez@lee:~/vvv$ vagrant plugin repair
Repairing currently installed global plugins. This may take a few minutes...
Failed to automatically repair installed Vagrant plugins. To fix this
problem remove all user installed plugins and reinstall. Vagrant can
do this for you automatically by running the following command:

vagrant plugin expunge --reinstall

Failure message received during repair:

can't modify frozen Gem::Dependency:

Si ahora intentamos reinstalar, como nos sugiere:

skotperez@lee:~/vvv$ vagrant plugin expunge --reinstall

This command permanently deletes all currently installed user plugins. It
should only be used when a repair command is unable to properly fix the
system.

Continue? [N]: y

All user installed plugins have been removed from this Vagrant environment!

Vagrant will now attempt to reinstall user plugins that were removed.
Installing the 'vagrant-goodhosts' plugin. This can take a few minutes...
Vagrant failed to properly resolve required dependencies. These
errors can commonly be caused by misconfigured plugin installations
or transient network issues. The reported error is:

SocketError: Failed to open TCP connection to rubygems.org:443 (getaddrinfo: Name or service not known) (https://rubygems.org/quick/Marshal.4.8/vagrant-goodhosts-1.0.0.gemspec.rz)

Luego, cuando intentamos levantar vagrant:

skotperez@joy:~/vvv$ vagrant up

Vagrant has detected project local plugins configured for this
project which are not installed.

vagrant-goodhosts
Install local plugins (Y/N) [N]: y

Installing the 'vagrant-goodhosts' plugin. This can take a few minutes...
/usr/share/rubygems-integration/all/gems/vagrant-2.2.19/lib/vagrant/bundler.rb:855:in `find_all': can't modify frozen Gem::Dependency: (FrozenError)

La solución:

skotperez@lee:~/vvv$ VAGRANT_DISABLE_STRICT_DEPENDENCY_ENFORCEMENT=1 vagrant plugin install vagrant-goodhosts
Installing the 'vagrant-goodhosts' plugin. This can take a few minutes...
Fetching os-1.1.4.gem
Fetching vagrant-goodhosts-1.1.4.gem
Installed the plugin 'vagrant-goodhosts (1.1.4)'!

Otros recursos

Dejar un comentario

No hay comentarios en esta entrada.
*
*

 

No hay trackbacks