Så använder du Bedrock och Trellis på Kinsta (WordPress-utveckling)

Detta är ett inlägg för alla er WordPress-utvecklare där ute!

Idag ska vi förklara hur du använder och integrerar Bedrock och Trellis på Kinsta.

Om du inte har hört talas om dessa två verktyg innan, kommer vi också att presentera dem och förhoppningsvis hjälpa till att förklara varför du borde använda dem över en traditionell konfiguration.

Bedrock och Trellis

Både Bedrock och Trellis är till för att göra det lättare att utveckla, underhålla och distribuera WordPress-sajter.

• Bedrock erbjuder ett alternativt sätt att hantera din WordPress-installation med en förbättrad mappstruktur, moderna utvecklingsverktyg och förbättrad säkerhet.
• Trellis arbetar med Bedrock för att skapa utvecklingsmiljöer med Vagrant tillsammans med distributioner med ett enda kommando.

Den främsta anledningen att använda Bedrock är att få korrekt beroende och pakethantering för ett WordPress-projekt. Du kanske redan är bekant med npm för JavaScript eller Bundler för Ruby. PHP är inte annorlunda, och dess motsvarighet är Composer.

Att använda en pakethanterare är vanligt, men det är mindre vanligt för själva WordPress eftersom WordPress redan har sitt eget koncept för plugin. Bedrock integrerar Composer för att hantera plugins, teman, och även själva WordPress-kärnan som beroenden.

Trellis är ett verktyg för att enkelt skapa utvecklings- och produktionsservrar för att hosta WordPress-sajter. Det är speciellt skapat för att fungera med Bedrock-baserade webbplatser också. Trellis vanligaste användningsfall är utveckling med Vagrant och i produktionen samt att skapa paritet mellan dessa två miljöer.

Det här inlägget förklarar ett något annorlunda användningsfall: Trellis som din utvecklingsserver och Kinsta för din produktionsserver (och eller stagingserver).

Varför använda Kinsta över en Trellis-etablerad VPS? Eftersom du ibland vill betala någon annan för att hantera servern istället för att göra det själv (speciellt om du har många klienter). Kinsta underlättar också skalning utan att behöva hantera flera servrar, lastbalanserare och molnuppladdningar.

Många WordPress-värdar är inte särskilt utvecklarvänliga och erbjuder inte SSH-åtkomst och Composer eller WP-CLI-integration som är krav för att använda Trellis och Bedrock. Lyckligtvis erbjuder Kinsta SSH-åtkomst på alla sina hostingplaner från Starter till Enterprise som gör allt detta möjligt. De kan också ändra rotsökvägen för korrekt funktionalitet.

Bedrock vs Vanlig WordPress

Du kanske undrar varför du borde använda Bedrock över en traditionell WordPress-installation. Anledningen är att Bedrock är byggd speciellt med den moderna webbutvecklaren i åtanke:

• Miljöspecifika konfigurationsfiler som lagras utanför den offentliga webbroten
• Miljövariabler för att separera config från kod i en enda .env -fil
• Förbättrad säkerhet genom att begränsa tillgången till icke-webbfiler tillsammans med bcrypt hashed-lösenord
• Anpassad wp-content-katalog som heter app
• Composer för att hantera WordPress, plugin, teman och andra PHP-beroenden
• .gitignore som utesluter WordPress-kärnan, plugin och uppladdningar

Raspberry Pi, Snopes, JetBlue, och mer, litar på Bedrock för att driva sina WordPress-sajter.

Låt oss ta en titt på de två mappstrukturerna sida vid sida:

Bedrock tar att installera WordPress i en underkatalog till nästa nivå. Mycket av filosofin bakom Bedrock är inspirerad av Twelve-Factor App-metoden inklusive den WordPress-specifika versionen.

Konfigurera Trellis för Kinsta

Först se till att dina offentliga SSH-nycklar är tillagda i MyKinsta-panelen.

Trellis kan distribueras till Kinsta med bara några få uppdateringar. Eftersom Kinsta tillhandahåller allt som handlar om webbservern kommer det inte tillhandahålla dina staging- och produktionsmiljöer.

Distributionen med ett kommando i Trellis fungerar med Kinsta med några mindre konfigurationer. När det är konfigurerat kan du distribuera dina WordPress-sajter genom att köra ”deploy playbook” i Trellis:

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

Öppna din MyKinsta-panel och navigera till WordPress-sajten som du skapar med Bedrock och Trellis, tillsammans med din kodredaktör öppen till Trellis-katalogen för ditt projekt.

Först, redigera trellis/ansible.cfg för att lägga till följande i [default] högst upp:

forks = 3
host_key_checking = False

Stagingkonfiguration

Se till att trellis/group_vars/staging/wordpress_sites.yml är konfigurerat med rätt canonical för din staging-sajt:

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

Öppna sedan upptrellis/group_vars/staging/main.yml och lägg till följande i slutet av filen:

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

Ersätt sökvägarna project_root och www_root med rätt sökväg i MyKinsta-panelen för din Kinsta-stagingmiljö.

Därefter, öppna trellis/group_vars/staging/vault.yml för redigering genom att köra ansible-vault edit group_vars/staging/vault.yml.

Vi måste lägga till db_user, db_name, och db_password till env. Du hittar värdena för dessa på huvudinfoskärmen för din webbplats i MyKinsta-panelen.

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

Slutligen, öppna trellis/hosts/staging och ersätt innehållet med:

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

Se till att värden och SSH-porten motsvarar det som anges i MyKinsta-panelen.

Produktionskonfiguration

Låt oss nu upprepa samma process som ovan för produktionsmiljön. Se till att växla till din ”live”-miljö i MyKinsta-panelen.

Öppna trellis/group_vars/production/main.yml och lägg till följande i slutet av filen:

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

Var noga med att ersätta sökvägarna project_root och www_root med rätt sökväg i MyKinsta-panelen för din livemiljö.

Därefter, öppna trellis/group_vars/production/vault.yml för redigering genom att köra 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: ""

Slutligen, öppna trellis/hosts/production och ersätt innehållet med:

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

Ändra distributionsuppgifterna

Trellis-distributioner försöker ladda om php-fpm, som vi måste hindra från att köras på Kinstas servrar. Vi måste också utlösa rensning av Kinstas cacheminne på en distribution.

Öppna trellis/roles/deploy/hooks/finalize-after.yml och bläddra längst ner. Ta bort den sista uppgiften för Reload php-fpm och lägg till följande:

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

Ersätt ask-support-rep ovan efter att du bett en Kinsta-supportagent om webbadressen för att rensa cacheminnet på din webbplats.

Valfritt: Installera Composer-beroenden

Om du får en skärm som talar om för dig att köra ’Composer Install’, lägg till följande strax före ”Clear Kinsta cache”-koden ovan:

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

/final-path kan variera beroende på dina Bedrock/Trellis–inställningar.

Lägg till kinsta-mu-plugins till Bedrock

Bedrock-webbplatser inkluderar automatiskt installerade mu-plugins, men du måste installera Kinsta MU-plugin genom att ta in paketet kinsta-mu-plugins. Detta plugin (som installeras som standard när du skapar en WordPress-webbplats via MyKinsta) hanterar saker som helsidescachelagring och Kinsta CDN-integrering.

Öppna site/composer.json och lägg till följande inom repositories-arrayen:

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

Kör sedan följande från din Bedrock/webbplats-katalog (eller ange kinsta/kinsta-mu plugins som ett krav i filen composer.json:

composer require kinsta/kinsta-mu-plugins:2.3.3

Följande konstanter kan krävas för att åtgärda problem med CDN-sökvägar och delade plugintillgångars webbadresser. Lägg till följande kod till din webbplats konfigurationsfil (bedrock/config/application.php i Bedrock-webbplatser):

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

För mer information, inklusive hur du uppdaterar insticksprogrammet, se vår guide för Kinsta MU-plugin.

Sista stegen med Kinstas support

Det sista du behöver göra är att informera Kinsta om hur de ska ställa in dokumentroten. Öppna upp MyKinsta och be supportteamet att uppdatera din dokumentrot till public/current/web.

Om du inte redan fått adressen för att rensa cacheminnet tidigare, be också din supportagent om denna, och se till att trellis/roles/deploy/hooks/finalize-after.yml uppdateras med rätt webbadress för att rensa Kinstas cacheminne vid en lyckad distribution.

När denna förändring har gjorts kommer du att kunna distribuera till både dina staging- och produktionsmiljöer med en enda rad:

# 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

Ännu bättre: installera en kontinuerlig integrationstjänst, till exempel CircleCI, för att automatiskt köra distributionen åt dig när du sparar antingen staging eller master!

Ben Word

Ben Word är en webbutvecklare och interaktionsdesigner. Han är grundaren av Roots, en öppen källkodsorganisation som skapar verktyg för att hjälpa WordPress-utvecklare att bygga bättre webbplatser.