Dit is een bericht speciaal voor alle WordPress developers!

Vandaag leggen we uit hoe je Bedrock en Trellis met Kinsta kan gebruiken en integreren.

Als je nog nooit van deze twee tools hebt gehoord, zullen we ze ook introduceren en hopelijk helpen om uit te leggen waarom je ze zou willen gebruiken in plaats van een traditionele setup.

Bedrock en Trellis

Zowel Bedrock als Trellis zijn er om het ontwikkelen, onderhouden en deployen van WordPress sites gemakkelijker te maken.

  • Bedrock biedt een alternatieve manier om jouw WordPress installatie te beheren maar dan met een verbeterde mappenstructuur, moderne ontwikkeltools en verbeterde beveiliging.
  • Trellis werkt samen met Bedrock om een ontwikkelingsomgeving te creëren met Vagrant, tezamen met één-commando-implementaties.

De belangrijkste reden om Bedrock te gebruiken is om de juiste depencency’s en package managers voor een WordPress project te krijgen. Je bent wellicht al bekend met npm voor JavaScript of Bundler voor Ruby. PHP is niet anders, het equivalent ervan is Composer.

Hoewel het gebruik van een package manager gebruikelijk is, is het minder gebruikelijk voor WordPress zelf, omdat WordPress al een eigen pluginconcept. Bedrock integreert Composer om plugins, thema’s en zelfs de WordPress core zelf als dependency’s te beheren.

Trellis is een tool om eenvoudig development- en productieservers te maken voor het hosten van WordPress sites. Het is speciaal gemaakt om op Bedrock gebaseerde sites te werken. Het standaard gebruik van Trellis is voor ontwikkeling met Vagrant en in productie om pariteit tussen die twee omgevingen te krijgen.

Dit bericht legt een iets ander gebruik uit: Trellis voor je ontwikkelserver en Kinsta voor je productie (en/of staging) server.

Waarom zou je Kinsta gebruiken in plaats van een VPS met Trellis? Omdat het soms gewoon slimmer is iemand anders te betalen om de server te beheren in plaats van het zelf te doen (vooral als je veel klanten hebt). Kinsta maakt daarnaast schalen ook veel gemakkelijker en heb je bij ons nooit problemen met meerdere servers, load balancers en uploads naar de cloud.

Veel WordPress hosts zijn niet erg ontwikkelaarsvriendelijk en bieden geen SSH toegang en Composer- of WP-CLI integratie, wat vereisten zijn om Trellis en Bedrock te gebruiken. Gelukkig biedt Kinsta SSH toegang bij alle hostingpakketten – van Starter tot Enterprise – wat dit allemaal mogelijk maakt. Ze kunnen ook het root-pad wijzigen voor een verbeterde functionaliteit.

Bedrock vs standaard WordPress

Je vraagt je misschien af waarom je Bedrock zou gebruiken in plaats van een traditionele WordPress installatie. De reden is dat Bedrock specifiek is gebouwd met de moderne webontwikkelaar in gedachten:

  • Omgevingsspecifieke configuratiebestanden, opgeslagen buiten de openbare web-root
  • Omgevingsvariabelen om configuratie en code te scheiden in een enkel .env bestand
  • Verbeterde beveiliging door de toegang tot niet-webbestanden te beperken, samen met bcrypt gehashte wachtwoorden
  • Aangepaste wp-content map genaamd app
  • Composer voor het beheren van WordPress, plugins, thema’s en andere PHP dependency’s
  • .gitignore die WordPress core, plugins en uploads uitsluit

Raspberry Pi, Snopes, JetBlue en meer vertrouwen op Bedrock om hun WordPress sites te laten draaien.

Laten we de twee mapstructuren naast elkaar bekijken:

Bedrock vs WordPress
Bedrock vs WordPress

Bedrock is enorm gestroomlijnd in het installeren van WordPress in een submap. Een groot deel van de filosofie achter Bedrock is geïnspireerd door de Twelve-Factor App methodologie, inclusief de WordPress specifieke versie.

Trellis configureren voor Kinsta

Zorg er eerst voor dat je public SSH sleutels zijn toegevoegd aan het MyKinsta dashboard.

Trellis kan met slechts een paar updates naar Kinsta worden geïmplementeerd. Aangezien Kinsta alles biedt vanuit het oogpunt van de webserver, is het inrichten van jouw staging- en productieomgevingen niet van toepassing.

De one-command deploys die onderdeel zijn van Trellis werken ook met Kinsta, na een korte configuratie. Eenmaal geconfigureerd, kan je jouw WordPress sites deployen door het deploy-playbook in Trellis uit te voeren:

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

Open je MyKinsta dashboard en ga naar de WordPress site die je aan het opzetten bent met Bedrock en Trellis, samen met je code-editor die is geopend voor de trellis directory van jouw project.

Bewerk eerst trellis/ansible.cfg om het volgende toe te voegen aan [defaults] bovenaan:

forks = 3
host_key_checking = False

Staging configuratie

Zorg ervoor dat trellis/group_vars/staging/wordpress_sites.yml is geconfigureerd met de juiste canonical voor jouw staging-site:

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

Open vervolgens trellis/group_vars/staging/main.yml en voeg het volgende toe aan het einde van het bestand:

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

Vervang het pad van project_root en www_root door het juiste pad in het MyKinsta dashboard voor je Kinsta testomgeving.

Vind je openbare root in MyKinsta
Vind je openbare root in MyKinsta

Open vervolgens trellis/group_vars/staging/vault.yml om te bewerken door ansible-vault edit group_vars/staging/vault.yml uit te voeren.

We moeten db_user, db_name, en db_password toevoegen aan env. Je kunt de waarden hiervoor vinden op het hoofdinformatiescherm van je site in het MyKinsta dashboard.

SFTP- en databasereferenties in MyKinsta
SFTP- en databasereferenties in 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: ""

Open ten slotte trellis/hosts/staging en vervang de inhoud door:

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

Zorg ervoor dat de host en SSH poort overeenkomen met wat wordt vermeld in het MyKinsta dashboard.

SFTP host- en poortgegevens voor jouw testomgeving
SFTP host- en poortgegevens voor jouw testomgeving

Configuratie productieomgeving

Laten we nu hetzelfde proces hierboven herhalen voor de productieomgeving. Zorg ervoor dat je overschakelt naar je “live” omgeving in het MyKinsta dashboard.

Schakel over naar je live-omgeving in MyKinsta
Schakel over naar je live-omgeving in MyKinsta

Open trellis/group_vars/production/main.yml en voeg het volgende toe aan het einde van jouw file:

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

Zorg ervoor dat je de paden project_root en www_root vervangt door het juiste pad in het MyKinsta dashboard voor je live-omgeving.

Open vervolgens trellis/group_vars/production/vault.yml om te bewerken door ansible-vault edit group_vars/production/vault.yml uit te voeren:

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: ""

Open ten slotte trellis/hosts/production en vervang de inhoud door:

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

[web]
kinsta_production

[production]
kinsta_production

De deploy taken wijzigen wijzigen

De deploys van Trellis proberen om php-fpm opnieuw te laden. Deze moeten we verwijderen zodat ze niet op de servers van Kinsta draaien. We moeten ook het wissen van de cache van Kinsta activeren bij een deploy.

Open trellis/roles/deploy/hooks/finalize-after.yml en scroll naar beneden. Verwijder de laatste taak van Reload php-fpm en voeg het volgende toe:

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

Vervang ask-support-rep hierboven nadat je een Kinsta supportmedewerker om de URL hebt gevraagd om de cache op je site te wissen.

Optioneel: Installeer Composer dependency’s

Als je een scherm krijgt dat je vertelt om ‘Composer Install’ uit te voeren, voeg dan het volgende toe vlak voor de ‘ Clear Kinsta cache’ code hierboven:

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

Het /final-path kan variëren op basis van jouw Bedrock/Trellis instellingen.

Kinsta mu-plugins toevoegen aan Bedrock

Bedrock sites worden geleverd met mu-plugins die automatisch worden geïnstalleerd, maar je moet de Kinsta MU plugins installeren door de kinsta-mu-plugins package uit te voeren. Deze plugin (die standaard wordt geïnstalleerd wanneer je een WordPress site maakt via MyKinsta) behandelt zaken als volledige paginacaching en de Kinsta CDN integratie.

Open site/composer.json en voeg het volgende toe aan de repositories array:

{
  "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"
    }
  }
}

Voer vervolgens het volgende uit vanuit je Bedrock/site directory (of specificeer kinsta/kinsta-mu plugins als vereiste in je composer.json bestand:

composer require kinsta/kinsta-mu-plugins:2.3.3

De volgende constanten kunnen nodig zijn om problemen met CDN paden en URL’s van gedeelde pluginasset op te lossen. Voeg de volgende code toe aan het configuratiebestand van je site (bedrock/config/application.php in Bedrock sites):

/**
 * 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");

Voor meer informatie, waaronder het updaten van de plugin, bekijk je onze gids voor de Kinsta MU plugin.

Laatste stappen met Kinsta ondersteuning

Het laatste dat je hoeft te doen, is Kinsta laten weten waar de document root op moet worden ingesteld. Ga naar MyKinsta en vraag het support om je document root te updaten naar public/current/web.

Als je de clear cache URL nog niet eerder hebt gekregen, vraag dan hier ook naar bij je supportmedewerker en zorg ervoor dat trellis/roles/deploy/hooks/finalize-after.yml is bijgewerkt met de juiste URL om de cache van Kinsta te wissen voor een succesvolle implementatie.

Zodra deze wijziging is aangebracht kan je met één regel deployen in zowel jouw staging als productieomgevingen:

# 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

Nog beter… stel een continue integratieservice in – zoals CircleCI- om de implementatie automatisch voor je uit te voeren wanneer je jezelf commit aan staging of master!