Wie man Bedrock und Trellis bei Kinsta benutzt (WordPress Entwicklung)

Dies ist ein Beitrag für alle WordPress-Entwickler da draußen!

Heute werden wir erklären, wie man Bedrock und Trellis bei Kinsta benutzt und integriert.

Falls du noch nie von diesen beiden Tools gehört hast, werden wir sie auch vorstellen und hoffentlich helfen, zu erklären, warum du sie gegenüber einem traditionellen Setup verwenden solltest.

Bedrock und Trellis

Sowohl Bedrock als auch Trellis existieren, um die Entwicklung, Wartung und Bereitstellung von WordPress-Seiten zu erleichtern.

• Bedrock bietet eine alternative Möglichkeit, deine WordPress-Installation mit einer verbesserten Ordnerstruktur, modernen Entwicklungswerkzeugen und verbesserter Sicherheit zu verwalten.
• Trellis arbeitet mit Bedrock zusammen, um Entwicklungsumgebungen mit Vagrant zusammen mit Ein-Kommando-Einsätzen zu erstellen.

Der Hauptgrund für die Verwendung von Bedrock ist die korrekte Verwaltung von Abhängigkeiten und Paketen für ein WordPress-Projekt. Vielleicht bist du bereits mit npm für JavaScript oder Bundler für Ruby vertraut. PHP ist nicht anders, und sein Äquivalent ist Composer.

Während die Verwendung eines Paketmanagers üblich ist, ist sie für WordPress selbst weniger üblich, da WordPress bereits ein eigenes Konzept für Plugins hat. Bedrock integriert Composer, um Plugins, Themes und sogar den WordPress-Core selbst als Abhängigkeiten zu verwalten.

Trellis ist ein Werkzeug zur einfachen Erstellung von Entwicklungs- und Produktionsservern zum Hosten von WordPress-Seiten. Es wurde speziell für die Arbeit mit Bedrock-basierten Seiten entwickelt. Trellis wird standardmäßig für die Entwicklung mit Vagrant und in der Produktion verwendet, um die Parität zwischen diesen beiden Umgebungen zu erreichen.

Dieser Beitrag erklärt einen etwas anderen Anwendungsfall: Trellis für deinen Entwicklungsserver und Kinsta für deinen Produktions- (und/oder Staging-) Server.

Warum Kinsta über einen Trellis-versorgten VPS verwenden? Weil man manchmal jemand anderen für die Verwaltung des Servers bezahlen möchte, anstatt es selbst zu tun (besonders wenn man viele Clients hat). Kinsta macht auch die Skalierung einfacher, ohne dass man sich mit mehreren Servern, Loadbalancern und Cloud-Uploads beschäftigen muss.

Viele WordPress-Hosts sind nicht sehr entwicklerfreundlich und bieten keinen SSH-Zugang und keine Composer- oder WP-CLI-Integration an, die Voraussetzung für die Verwendung von Trellis und Bedrock sind. Glücklicherweise bietet Kinsta SSH-Zugang für alle ihre Hosting-Pakete, von Starter bis Enterprise, was all dies ermöglicht. Du kannst auch den Root-Pfad für die richtige Funktionalität modifizieren.

Bedrock vs. reguläres WordPress

Du fragst dich vielleicht, warum du Bedrock gegenüber einer traditionellen WordPress-Installation verwenden solltest. Der Grund dafür ist, dass Bedrock speziell für den modernen Webentwickler entwickelt wurde:

• Umgebungsspezifische Konfigurationsdateien, die außerhalb des öffentlichen Web-Stammverzeichnisses gespeichert werden.
• Umgebungsvariablen zur Trennung von Konfiguration und Code in einer einzigen .env-Datei
• Verbesserte Sicherheit durch Beschränkung des Zugriffs auf Nicht-Web-Dateien zusammen mit gehashten bcrypt-Passwörtern
• Benutzerdefiniertes wp-Inhaltsverzeichnis namens app
• Composer zur Verwaltung von WordPress, Plugins, Themes und anderen PHP-Abhängigkeiten
• .gitignore, das den WordPress-Core, Plugins und Uploads ausschließt

Raspberry Pi, Snopes, JetBlue und andere vertrauen auf Bedrock, um ihre WordPress-Seiten zu betreiben.

Schauen wir uns die beiden Ordnerstrukturen nebeneinander an:

Bedrock bringt die Installation von WordPress in ein Unterverzeichnis auf die nächste Ebene. Ein großer Teil der Philosophie hinter Bedrock ist von der Twelve Factor App Methode inspiriert, einschließlich der WordPress-spezifischen Version.

Konfigurieren von Trellis für Kinsta

Stelle zunächst sicher, dass deine öffentlichen SSH-Schlüssel zum MyKinsta-Dashboard hinzugefügt werden.

Trellis kann mit nur wenigen Aktualisierungen in Kinsta eingesetzt werden. Da Kinsta alles vom Standpunkt des Web-Servers aus bietet, ist die Bereitstellung deiner Staging- und Produktionsumgebung nicht erforderlich.

Die Ein-Befehl-Bereitstellungen in Trellis funktionieren mit Kinsta mit einer kleinen Konfiguration. Nach der Konfiguration kann man die WordPress-Seiten bereitstellen, indem man das Deploy-Playbook in Trellis ausführt:

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

Rufe dein MyKinsta-Dashboard auf und navigiere zu der WordPress-Seite, die du mit Bedrock und Trellis einrichtest, zusammen mit deinem Code-Editor, der zum trellis-Verzeichnis in deinem Projekt geöffnet ist.

Bearbeite zuerst die Datei trellis/ansible.cfg, um das Folgende zu [defaults] oben hinzuzufügen:

forks = 3
host_key_checking = False

Staging Konfiguration

Stelle sicher, dass trellis/group_vars/staging/wordpress_sites.yml mit der richtigen canonical Version für deine Staging-Seite konfiguriert ist:

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

Öffne dann trellis/group_vars/staging/main.yml und füge Folgendes am Ende der Datei hinzu:

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

Ersetze die project_root– und www_root-Pfade mit dem korrekten Pfad, der dir im MyKinsta-Dashboard für deine Kinsta-Staging-Umgebung angeboten wird.

Als nächtes öffne trellis/group_vars/staging/vault.yml zur Bearbeitung, indem du ansible-vault edit group_vars/staging/vault.yml.

Wir müssen db_user, db_name, und db_password zu envhinzufügen. Du findest die Werte für diese auf dem Hauptinfobildschirm deiner Webseite im MyKinsta-Dashboard.

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

Zum Schluss öffne trellis/hosts/staging und esetze den Inhalt durch:

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

Vergewisser dich, dass der Host und der SSH-Port mit der Liste im MyKinsta-Dashboard übereinstimmen.

Konfiguration der Produktion

Wiederholen wir nun den oben beschriebenen Prozess für die Produktionsumgebung. Stelle sicher, dass du im MyKinsta-Dashboard auf deine „Live“-Umgebung umschaltest.

Öffne trellis/group_vars/production/main.yml und füge Folgendes am Ende der Datei hinzu:project_root: /www/example_123/public
www_root: /www/example_123/public
web_user: example
web_group: www-data

Achte darauf, die project_root– und www_root-Pfade durch den korrekten Pfad zu ersetzen, der dir im MyKinsta-Dashboard für deine Live-Umgebung angeboten wird.

Als nächtes öffnetrellis/group_vars/production/vault.yml zur Bearbeitung, indem du 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: ""

Schließlich öffne das  trellis/hosts/production production und ersetze den Inhalt durch

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

Ändern der Bereitstellungsaufgaben

Trellis versucht, php-fpm neu zu laden, was wir von dem Versuch, auf den Kinsta-Servern zu laufen, entfernen müssen. Wir müssen auch die Löschung von Kinsta’s Cache auf einem Deployment auslösen.

Öffne die Datei trellis/roles/deploy/hooks/finalize-after.yml und scrolle nach unten. Entferne die letzte Aufgabe für Reload php-fpmand und füge Folgendes hinzu::

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

Ersetze ask-support-rep oben, nachdem du einen Kinsta-Supportvertreter nach der URL zum Löschen des Caches auf deiner Webseite gefragt hast.

Optional: Composer-Abhängigkeiten installieren

Wenn du einen Screen bekommst, der dir sagt, dass du ‚Composer Install‘ ausführen sollst, füge das folgende direkt vor dem obigen „Clear Kinsta cache“-Code hinzu:

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

Der /final-path kann je nach deinen Bedrock / Trellis Einstellungen variieren.

Hinzufügen von kinsta-mu-Plugins zu Bedrock

Auf Bedrock-Seiten werden mu-plugins automatisch installiert, aber du musst das Kinsta MU-Plugin installieren, indem du das Paket kinsta-mu-plugins mitbringst. Dieses Plugin (das standardmäßig installiert wird, wenn du eine WordPress-Seite über MyKinsta erstellst) kümmert sich um Dinge wie Full Page Caching und die Integration des Kinsta CDN.

Öffne site/composer.json und füge Folgendes innerhalb des Arrays der repositories hinzu:

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

Dann führe Folgendes in deinem Bedrock/site-Verzeichnis aus (oder gib kinsta/kinsta-mu plugins als Voraussetzung in deiner composer.json-Datei an:

composer require kinsta/kinsta-mu-plugins:2.3.3

Die folgenden Konstanten können erforderlich sein, um Probleme mit CDN-Pfaden und gemeinsam genutzten Plugin-URLs zu beheben. Füge den folgenden Code in die Konfigurationsdatei deiner Seite ein (bedrock/config/application.php in Bedrock-Seiten):

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

Weitere Informationen und wie du das Plugin aktualisieren kannst, findest du in unserer Anleitung für das Kinsta MU Plugin.

Letzte Schritte mit Unterstützung von Kinsta

Das letzte, was man tun muss, ist, Kinsta darüber zu informieren, worauf der Dokument-Stamm zu setzen ist. Hüpfe auf MyKinsta und bitte das Support-Team darum, dass dein Dokumentenstamm auf public/current/web aktualisiert wird.

Falls die URL zum Löschen des Caches nicht schon früher bekannt war, frage auch den Support-Mitarbeiter danach und stelle sicher, dass die Datei trellis/roles/deploy/hooks/finalize-after.yml mit der richtigen URL aktualisiert wird, um den Cache von Kinsta bei einem erfolgreichen Deployment zu löschen.

Sobald diese Änderung vorgenommen wurde, kannst du die Bereitstellung sowohl in deiner Staging- als auch in deiner Produktionsumgebung mit einer einzigen Zeile durchführen:

# 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

Besser noch… richte einen kontinuierlichen Integrationsdienst wie CircleCI ein, um das Deployment automatisch für dich auszuführen, wenn du dich entweder für staging oder master entscheidest!

Ben Word

Ben Word ist ein Webentwickler und Interaktionsdesigner. Er ist der Gründer von Roots, einer Open-Source-Organisation, die Tools entwickelt, mit denen WordPress-Entwickler bessere Seiten erstellen können.