Questo è un post per tutti voi sviluppatori di WordPress! Oggi vi spiegheremo come utilizzare e integrare Bedrock e Trellis su Kinsta. Se non avete mai sentito parlare di questi due strumenti, ve li presenteremo sperando di aiutarvi a capire quanto potrebbero esservi utili rispetto a una configurazione tradizionale.

Bedrock e Trellis

Sia Bedrock che Trellis hanno lo scopo di facilitare lo sviluppo, la manutenzione e la distribuzione dei siti WordPress.

Il motivo principale per utilizzare Bedrock è quello di ottenere una corretta gestione delle dipendenze e dei pacchetti per un progetto WordPress. Potreste già avere familiarità con npm per JavaScript o Bundler per Ruby. PHP non è diverso e il suo equivalente è Composer.

Anche se l’utilizzo di un gestore di pacchetti è frequente, è meno comune per WordPress, perché WordPress ha già un concetto proprio per i plugin. Bedrock integra Composer per gestire come dipendenze plugin, temi e persino il core di WordPress.

Trellis è uno strumento per creare facilmente server di sviluppo e produzione per ospitare siti WordPress. È stato creato appositamente per lavorare anche con siti basati su Bedrock. Il caso d’uso predefinito di Trellis è quello di utilizzarlo insieme a Vagrant in sviluppo e in produzione per pareggiare i due ambienti.

Questo post illustra un caso d’uso leggermente diverso: Trellis per il vostro server di sviluppo e Kinsta per il vostro server di produzione (e/o staging).

Perché utilizzare Kinsta invece di un VPS fornito da Trellis? Perché a volte si vuole pagare qualcun altro per gestire il server invece di farlo da soli (soprattutto se si hanno molti clienti). Kinsta facilita anche la scalabilità senza dover gestire più server, bilanciatori di carico e caricamenti sul cloud.

Molti host WordPress non sono molto developer-friendly e non offrono accesso SSH e Composer o l’integrazione di WP-CLI, che sono richiesti per utilizzare Trellis e Bedrock. Per fortuna, Kinsta offre l’accesso SSH su tutti i suoi piani di hosting, da Starter a Enterprise, il che rende possibile tutto questo. È anche possibile modificare il percorso di root perché tutto funzioni correttamente.

Bedrock e Trellis rendono più semplice lo sviluppo, la manutenzione e la distribuzione di siti WordPress. 🤓Click to Tweet

Bedrock vs il Normale WordPress

Vi starete chiedendo perché utilizzare Bedrock invece di un’installazione tradizionale di WordPress. Il motivo è che Bedrock è sviluppato pensando al moderno web developer:

Raspberry Pi, Snopes, JetBlue e altri si affidano a Bedrock per i propri siti WordPress.

Diamo un’occhiata alle due strutture di cartelle affiancate:

Bedrock vs WordPress
Bedrock vs WordPress

L’installazione di WordPress in una sottodirectory sale di livello con Bedrock. Gran parte della filosofia di Bedrock si ispira alla metodologia Twelve-Factor App, inclusa la versione specifica di WordPress.

Configurare Trellis per Kinsta

Per prima cosa, assicuratevi che le vostre chiavi pubbliche SSH siano state aggiunte al cruscotto di MyKinsta.

Trellis può essere distribuito su Kinsta con pochi aggiornamenti. Dato che Kinsta fornisce tutto dal punto di vista del server web, il provisioning dei vostri ambienti di staging e produzione non è applicabile.

Le distribuzioni mono-comando in Trellis richiedono su Kinsta una configurazione minima. Una volta configurato, potrete distribuire i vostri siti WordPress eseguendo il playbook di distribuzione in Trellis:

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

Aprite il vostro cruscotto MyKinsta e andate al sito WordPress che state configurando con Bedrock e Trellis. Tenete il vostro editor di codice aperto alla directory trellis nel vostro progetto.

Per prima cosa, modificate trellis/ansible.cfg e aggiungete quanto segue a [defaults] in alto:

forks = 3
host_key_checking = False

Configurazione dello Staging

Assicuratevi che trellis/group_vars/staging/wordpress_sites.yml sia configurato con il canonical appropriato per il vostro sito di staging:

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

Quindi aprite trellis/group_vars/staging/main.yml e aggiungete quanto segue alla fine del file:

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

Sostituite i percorsi project_root e www_root con il percorso corretto fornito nel cruscotto di MyKinsta per il vostro ambiente di staging.

Dove trovare la root pubblica in MyKinsta
Dove trovare la root pubblica in MyKinsta

Quindi aprite il file trellis/group_vars/staging/vault.yml eseguendo ansible-vault edit group_vars/staging/vault.yml.

Dobbiamo aggiungere db_user, db_name e db_password a env. Potete trovarne i valori nella schermata principale delle informazioni sul vostro sito nel cruscotto di MyKinsta.

Credenziali SFTP e database in MyKinsta
Credenziali SFTP e database 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: ""

Infine, aprite trellis/hosts/staging e sostituite il contenuto 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

Assicuratevi che l’host e la porta SSH corrispondano a quanto riportato nel cruscotto di MyKinsta.

Dettagli host e porta SFTP ambiente di staging
Dettagli host e porta SFTP per l’ambiente di staging

Configurazione della Produzione

Ora ripetiamo la stessa procedura descritta sopra per l’ambiente di produzione. Assicuratevi di passare al vostro ambiente “live” nel cruscotto di MyKinsta.

Ambiente live in MyKinsta
Passare all’ambiente live in MyKinsta

Aprite trellis/group_vars/production/main.yml e aggiungete quanto segue alla fine del file:

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

Assicuratevi di sostituire i percorsi project_root e www_root con il percorso corretto fornito nel cruscotto di MyKinsta per il vostro ambiente live.

Quindi aprite trellis/group_vars/production/vault.yml per l’editing eseguendo 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: ""

Infine, aprite trellis/hosts/production e sostituite il contenuto con:

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

Modificare i Task di Deploy

Le distribuzioni di Trellis tentano di ricaricare php-fpm, che dobbiamo rimuovere dal tentativo di esecuzione sui server di Kinsta. Dobbiamo anche attivare lo svuotamento della cache di Kinsta su una distribuzione.

Alle prese con i tempi di inattività e problemi di WordPress? Kinsta è la soluzione di hosting progettata per farvi risparmiare tempo! Scopri i nostri servizi

Aprite trellis/roles/deploy/hooks/finalize-after.yml e scorrete fino in fondo. Rimuovete l’ultimo task per Reload php-fpm e aggiungete quanto segue:

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

Sostituite il ask-support-rep qui sopra dopo aver chiesto a un addetto al supporto di Kinsta l’URL per cancellare la cache del vostro sito.

Opzionale: Installare le Dipendenze di Composer

Se ricevete una schermata che dice di eseguire “Composer Install”, aggiungete quanto segue subito prima del codice “Clear Kinsta cache” di cui sopra:

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

Il percorso /final-path potrebbe variare a seconda delle impostazioni della vostra configurazione Bedrock/Trellis.

Aggiungere kinsta-mu-plugins a Bedrock

I siti Kinsta sono dotati di mu-plugins installati automaticamente. Con le installazioni Bedrock dovrete portare dentro il pacchetto kinsta-mu-plugins.

Aprite site/composer.json e aggiungete quanto segue all’interno dell’array 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"
    }
  }
}

Quindi eseguite quanto segue dalla directory del vostro sito Bedrock:

composer require kinsta/kinsta-mu-plugins:2.3.3

Configurazione del CDN di Kinsta

Con il vostro sito Bedrock potete utilizzare il CDN di Kinsta e il plugin Kinsta MU, dovete solo definire la directory manualmente nel vostro file wp-config.php. Quello che segue è un esempio di come utilizzare la directory /app sul vostro sito.

define( 'KINSTA_CDN_USERDIRS', 'app');

Se volete aggiungere più di una directory, è sufficiente separarle con delle virgole.

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

Passi Finali con il Supporto di Kinsta

L’ultima cosa da fare è informare Kinsta della stringa da impostare per la radice del documento. Saltate in MyKinsta e chiedete al team di supporto di aggiornare la vostra document root a public/current/web.

Se non si è già ottenuto l’URL di cancellazione della cache, chiedete aiuto anche per questo e assicuratevi che trellis/roles/deploy/hooks/finalize-after.yml sia stato aggiornato con l’URL corretto affinché la cache di Kinsta sia cancellata ad un deploy eseguito con successo.

Una volta fatto, sarete in grado di implementare sia nel vostro ambiente di staging che in quello di produzione con una sola linea:

# 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

Meglio ancora… configurate un servizio di integrazione continuo, come CircleCI, per eseguire automaticamente l’implementazione quando eseguite il commit su staging o master!


Risparmia tempo e costi e massimizza le prestazioni del sito con:

  • Aiuto immediato dagli esperti dell’hosting WordPress, 24/7.
  • Integrazione di Cloudflare Enterprise.
  • Copertura globale del pubblico con 29 data center in tutto il mondo.
  • Ottimizzazione del sito con il nostro Monitoraggio delle Prestazioni delle Applicazioni integrato.

Tutto questo e molto altro, in un piano senza contratti a lungo termine, con migrazioni assistite e una garanzia di 30 giorni di rimborso. Scopri i nostri piani o contattaci per trovare il piano che fa per te.