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.

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 och Trellis finns till för att göra det lättare att utveckla, underhålla och distribuera WordPress-sajter. 🤓Click to Tweet

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:

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 vs WordPress
Bedrock vs WordPress

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ö.

Hitta din public-rot i MyKinsta.
Hitta din public-rot i MyKinsta.

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_userdb_name, och db_password till env. Du hittar värdena för dessa på huvudinfoskärmen för din webbplats i MyKinsta-panelen.

SFTP och databasuppgifter i MyKinsta.
SFTP och databasuppgifter i 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: ""

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.

SFTP-värd och port-detaljer för din stagingmiljö.
SFTP-värd och port-detaljer för din stagingmiljö.

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.

Byt till din live-miljö i MyKinsta.
Byt till din live-miljö i MyKinsta.

Ö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.

Kämpar du med driftstopp och WordPress-problem? Kinsta är hosting-lösningen som är utformad för att spara tid! Kolla in våra funktioner

Ö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

Kinsta-sajter kommer med mu-plugins automatiskt installerade. Med Bedrock-installationer måste du ta in kinsta-mu-plugins -paketet.

Ö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/site-katalog:

composer require kinsta/kinsta-mu-plugins:2.3.3

Konfigurera Kinstas CDN

Du kan använda Kinstas CDN tillsammans med din Bedrock-sajt och Kinstas MU-plugin, du behöver bara definiera katalogen manuellt i din /config/application.php -fil. Följande skulle vara ett exempel på att använda /app-katalogen på din webbplats.

define( 'KINSTA_CDN_USERDIRS', 'app');

Om du vill lägga till mer än en extra katalog, helt enkelt separera dem med kommatecken.

define( 'KINSTA_CDN_USERDIRS', 'app,app2,app3');

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!


Spara tid, kostnad och maximera webbplatsens prestanda med:

  • Omedelbar hjälp från WordPress -hostingexperter, 24/7.
  • Cloudflare Enterprise-integration.
  • Global publik räckvidd med 29 datacenter över hela världen.
  • Optimering med vår inbyggda Application Performance Monitoring.

Allt detta och mer, i en plan utan långsiktiga kontrakt, assisterad migration och en 30-dagars pengarna-tillbaka-garanti. Kolla in våra paket, eller prata med säljteamet för att hitta den plan som fungerar för dig.