¡Esta es una publicación para todos los desarrolladores de WordPress que nos visitan!

Hoy explicaremos cómo usar e integrar Bedrock y Trellis en Kinsta.

Si no ha escuchado hablar antes de estas dos herramientas, usaremos esta oportunidad para presentársela y también le explicaremos por qué es preferible usarlas en lugar de usar una configuración tradicional.

Bedrock y Trellis

Tanto Bedrock como Trellis existen para facilitar el desarrollo, mantenimiento e implementación de sitios de WordPress.

  • Bedrock ofrece una forma alternativa para administrar su instalación de WordPress con una estructura de carpetas mejorada, herramientas de desarrollo modernas, y una mejor seguridad.
  • Trellis trabaja con Bedrock para crear entornos de desarrollo con Vagrant, junto con implementación comandos únicos.

La principal razón para usar Bedrock es para obtener una adecuada gestión de dependencias y paquetes para un proyecto de WordPress. Es posible que ya esté familiarizado con npm para JavaScript o Bundler para Ruby. PHP no es diferente, y su equivalente es Composer.

Si bien el uso de un administrador de paquetes es común, es menos común para WordPress ya que WordPress ya tiene su propio concepto para plugins. Bedrock integra Composer para gestionar plugins, temas, e incluso el núcleo de WordPress como dependencias.

Trellis es una herramienta para crear con facilidad servidores de desarrollo y producción para alojar sitios de WordPress. Además, ha sido creado específicamente para trabajar con sitios basados en Bedrock. El caso de uso por defecto de Trellis es utilizarlo para desarrollar con Vagranty también en producción para conseguir paridad entre esos dos entornos.

Esta publicación explica un caso de uso ligeramente diferente: Trellis para su servidor de desarrollo y Kinsta para su servidor de producción (y/o de staging).

¿Por qué usar Kinsta en lugar de un VPS provisto por Trellis? Porque a veces usted podría querer pagarle a alguien más para que administre el servidor en lugar de hacerlo usted mismo (especialmente si tiene muchos clientes). Kinsta también facilita la escalabilidad sin tener que lidiar con múltiples servidores, distribuidores de carga, y subidas a la nube.

Muchos hosts de WordPress no son muy amigables con los desarrolladores y no ofrecen acceso SSH ni integración de Composer o WP-CLI, los cuales son requisitos para usar Trellis y Bedrock. Afortunadamente, Kinsta ofrece acceso SSH en todos sus planes desde el plan Starter hasta Enterprise que hace que todo eso sea posible. También pueden modificar la ruta raíz para una funcionalidad adecuada.

Bedrock vs WordPress Regular

Es posible que se pregunte por qué utilizaría Bedrock en lugar de una instalación tradicional de WordPress. La razón es que Bedrock está diseñado específicamente pensando en el desarrollador web moderno:

  • Archivos de configuración específicos para el entorno, almacenados fuera de la raíz web publica
  • Variables de entorno para separar la configuración del código en un único archivo .env
  • Seguridad mejorada al limitar el acceso a archivos no-web, junto con contraseñas hasheadas con bcrypt
  • Directorio wp-content personalizado llamado app
  • Composer para administrar WordPress, plugins, temas, y otras dependencias de PHP
  • .gitignore que excluye la base de WordPress, plugins y subidas

Raspberry Pi, Snopes, JetBlue y más, confian en Bedrock para impulsar sus sitios de WordPress.

Démosle un vistazo a la comparación entre las dos estructuras de carpetas:

Bedrock vs WordPress
Estructura de Bedrock vs WordPress

Bedrock lleva al siguiente nivel el instalar WordPress en un subdirectorio. Gran parte de la filosofía detrás de Bedrock está inspirada en la metodología de la Twelve-Factor App, incluyendo la versión específica de WordPress.

Configurando Trellis para Kinsta

Primero asegúrese de que sus claves SSH sean agregadas al panel MyKinsta.

Trellis puede implementarse en Kinsta con sólo unas pocas actualizaciones. Dado que Kinsta proporciona todo desde el punto de vista del servidor. El aprovisionamiento de sus entornos de producción y de staging no se aplica.

Las implementaciones de un comando en Trellis funcionan en Kinsta con sólo una pequeña configuración. Una vez configurado, usted podrá implementar sus sitios de WordPress ejecutando el playbook de implementación en Trellis:

ansible-playbook deploy.yml -e env=staging -e site=example.com --limit=kinsta_staging

Abra su panel de control MyKinsta y navegue hasta el sitio de WordPress que está configurando con Bedrock y Trellis, junto con su editor de código abierto en el directorio de trellis de su proyecto.

Primero edite trellis/ansible.cfg para agregar lo siguiente[defaults] en la parte superior:

forks = 3
host_key_checking = False

Configuración de Staging

Asegúrese de que trellis/group_vars/staging/wordpress_sites.yml está configurado con el canonical para su sitio de staging:

wordpress_sites:
  example.com:
    site_hosts:
      - canonical: staging-example.kinsta.com

Abra trellis/group_vars/staging/main.ymly agregue lo siguiente al final del archivo:

project_root: /www/example_123/public
www_root: /www/example_123/public
web_user: example
web_group: www-data

Reemplaza las rutas project_root y www_root por la ruta correcta proporcionada en el panel de control de MyKinsta para tu entorno de staging de Kinsta.

Encuentra tu raíz pública en MyKinsta.
Encuentra tu raíz pública en MyKinsta.

Ahora abra trellis/group_vars/staging/vault.ymlpara editarlo ejecutando ansible-vault edit group_vars/staging/vault.yml.

Necesitamos agregardb_user, db_name, y db_password a env. También necesitamos agregarvault_ansible_ssh_pass. Puede encontrar los valores para estos en la pantalla de información principal de su sitio, en el panel de control MyKinsta.

Added:

SFTP y credenciales de la base de datos en MyKinsta.
SFTP y credenciales de la base de datos en MyKinsta.
vault_wordpress_sites:
  example.com:
    env:
      db_user: "example"
      db_name: "example"
      db_password: "xxxxxxxxxxxxxxx"
      # Generate your keys here: https://roots.io/salts.html
      auth_key: ""
      secure_auth_key: ""
      logged_in_key: ""
      nonce_key: ""
      auth_salt: ""
      secure_auth_salt: ""
      logged_in_salt: ""
      nonce_salt: ""

Finalmente abra trellis/hosts/staging y reemplace el contenido con:

kinsta_staging ansible_host=104.154.94.123 ansible_ssh_port=12345 ansible_ssh_extra_args='-o StrictHostKeyChecking=no'

[web]
kinsta_staging

[staging]
kinsta_staging

Asegúrese de que el host y el puerto SSH coincidan con lo que se muestra en el panel de control MyKinsta.

Detalles del host y del puerto del SFTP para su entorno de staging.
Detalles del host y del puerto del SFTP para su entorno de staging.

Configuración de Producción

Ahora, repitamos el proceso anterior para el entorno de producción. Asegúrese de cambiar a su entorno vivo en el panel de control MyKinsta.

Cambia al entorno en vivo en MyKinsta.
Cambia al entorno en vivo en MyKinsta.

Abra trellis/group_vars/production/main.yml y agregue lo siguiente al final del archivo:

project_root: /www/example_123/public
www_root: /www/example_123/public
web_user: example
web_group: www-data

Asegúrate de reemplazar las rutas project_root y www_root con la ruta correcta proporcionada en el panel de control de MyKinsta para tu entorno en vivo.

Ahora abra trellis/group_vars/production/vault.yml para editarlo ejecutando ansible-vault edit group_vars/production/vault.yml:

vault_wordpress_sites:
  example.com:
    env:
      db_user: "example"
      db_name: "example"
      db_password: "xxxxxxxxxxxxxxx"
      # Generate your keys here: https://roots.io/salts.html
      auth_key: ""
      secure_auth_key: ""
      logged_in_key: ""
      nonce_key: ""
      auth_salt: ""
      secure_auth_salt: ""
      logged_in_salt: ""
      nonce_salt: ""

Finalmente abra trellis/hosts/production y reemplace el contenido con:

kinsta_production ansible_host=104.154.94.123 ansible_ssh_port=12345 ansible_ssh_pass="{{ vault_ansible_ssh_pass }}"

[web]
kinsta_production

[production]
kinsta_production

Modificando las Tareas de Implementación

Las implementaciones de Trellis tratan de volver a cargar php-fpm, lo que debemos eliminar para evitar que sigan intentando ejecutarse en los servidores de Kinsta. También tenemos que borrar la cache de Kinsta.

Abra trellis/roles/deploy/hooks/finalize-after.yml y desplácese hasta el fondo. Elimine la última tarea de Reload php-fpm y agregue lo siguiente:

- name: Clear Kinsta cache
  uri:
    url: "{{ site_env.wp_home }}/ask-support-rep/"
    method: GET

Reemplace ask-support-rep (mostrado arriba) después de pedirle a un ingeniero de soporte de Kinsta la URL para borrar la cache de su sitio.

Opcional: Instalar Dependencias de Composer

Si le aparece una pantalla que le pide que ejecute ‘Composer Install’, agregue lo siguiente junto antes del código “Clear Kinsta cache” (mostrado arriba):

- name: Install Composer dependencies
composer:
command: install
working_dir: >/www/example123/public/final-path

O /final-path pode variar de acordo com a sua configuração Bedrock/Trellis.

Agregando kinsta-mu-plugins a Bedrock

Los sitios de Bedrock vienen con mu-plugins instalados automáticamente, pero, tendrás que instalar el plugin Kinsta MU con el paquete kinsta-mu-plugins. Este plugin (que se instala por defecto cuando se crea un sitio de WordPress a través de MyKinsta) gestiona cosas como el almacenamiento en caché de la página completa y la integración de Kinsta CDN.

Abra site/composer.json y agregue lo siguiente dentro de la matriz de repositories:

{
  "type": "package",
  "package": {
    "name": "kinsta/kinsta-mu-plugins",
    "type": "wordpress-muplugin",
    "version": "2.3.3",
    "dist": {
      "url": "https://kinsta.com/kinsta-tools/kinsta-mu-plugins.zip",
      "type": "zip"
    }
  }
}

Entonces ejecute lo siguiente desde el directorio de su sitio/Bedrock (o especifique kinsta/kinsta-mu plugins como requisito en tu archivo composer.json):

composer require kinsta/kinsta-mu-plugins:2.3.3

Las siguientes constantes pueden ser necesarias para solucionar los problemas con las rutas de CDN y las URL de activos compartidos de los plugins. Añade el siguiente código al archivo de configuración de tu sitio (bedrock/config/application.php en los sitios de Bedrock):

/**
 * Kinsta CDN fix for Bedrock
 */
define('KINSTA_CDN_USERDIRS', 'app');
/**
 * Fix Kinsta MU Plugins URL path with Bedrock
 */
$mu_plugins_url = Config::get('WP_CONTENT_URL') . '/mu-plugins';
define('KINSTAMU_CUSTOM_MUPLUGIN_URL', "{$mu_plugins_url}/kinsta-mu-plugins");

Para más información, incluyendo cómo actualizar el plugin, consulta nuestra guía para el plugin Kinsta MU.

Final Steps With Kinsta Support

Lo último que tiene que hacer es informar a Kinsta sobre a que donde quiere que se configure su raíz de documentos. Entre a MyKinsta y solicítele al equipo de soporte que actualice su raíz de documentos a public/current/web.

Si aún no ha conseguido su URL para borrar la cache, pídele al técnico de soporte que se la proporcione, y asegúrese de que trellis/roles/deploy/hooks/finalize-after.yml esté actualizado con la URL correcta para borrar la cache de Kinsta.

Una vez que se haya realizado este cambio podrá implementar sus entornos de producción y de staging con una sola línea:

# Deploy staging
ansible-playbook deploy.yml -e env=staging -e site=example.com --limit=kinsta_staging

# Deploy production
ansible-playbook deploy.yml -e env=production -e site=example.com --limit=kinsta_production

Mejor aún… ¡configure un servicio de integración continua, como CircleCI, para que ejecute automáticamente la implementación por usted cuando haga commit a staging o master!

Brian Jackson

Brian tiene una gran pasión por WordPress, lo ha estado utilizando durante más de 10 años e incluso ha desarrollado un par de plugins premium. Brian disfruta de los blogs, las películas y el senderismo. Conéctese con Brian en Twitter.