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
Actualizar VVV
Actualizar el sistema operativo de las máquinas virtuales no es lo mismo que actualizar VVV, que en el fondo no es nada más que una configuración ya preparada de Vagrant para desarrollar con WordPress. En la documentación oficial de VVV se cuenta cómo actualizar.
Antes de actualizar es recomendable hacer una copia de seguridad de las bases de datos. Personalmente, recomiendo activar las copias de seguridad automáticas, que se hacen cada vez que se ejecuta vagrant halt. Esta opción se puede encontrar en el archivo config/config.yml:
# Backup the databases to the database/backups subfolder on halt/suspend/destroy, set to false to disable
db_backup:
enable: true
gzip: true
#exclude:
# - wordpress-trunk
skotperez@lee:~/vvv$ vagrant halt skotperez@lee:~/vvv$ git pull # update to latest git version skotperez@lee:~/vvv$ vagrant plugin update --local # update vagrant plugins skotperez@lee:~/vvv$ vagrant up --provision # launch the VM
Para actualizar las versiones mayores (de 2.X a 3.X, por ejemplo), la documentación oficial recomienda eliminar (destroy) las imágenes de las máquinas virtuales y reconstruirlas después:
# back up your database then skotperez@lee:~/vvv$ vagrant halt # turn off the VM if it's running skotperez@lee:~/vvv$ git pull # update to latest git version skotperez@lee:~/vvv$ vagrant plugin update --local # update vagrant plugins skotperez@lee:~/vvv$ vagrant destroy # destroy or delete the VM image (not your files!) skotperez@lee:~/vvv$ vagrant up --provision # download the new VM image and reinstall everything with a provision # restore the database backup
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 versión 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)'!