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.

  • Bedrock offre una soluzione alternativa per la gestione di un’installazione di WordPress con una struttura di cartelle migliorata, strumenti di sviluppo moderni e maggiore sicurezza.
  • Trellis funziona insieme a Bedrock permettendo di creare ambienti di sviluppo con Vagrant con implementazioni ad un solo comando.

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 è preferibile 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 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 Single 35k a WP 60 e oltre, il che rende possibile tutto questo. È anche possibile modificare il percorso di root perché tutto funzioni correttamente.

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:

  • File di configurazione specifici per l’ambiente, memorizzati al di fuori della web root pubblica
  • Variabili d’ambiente per separare la configurazione dal codice in un unico file .env
  • Maggiore sicurezza ottenuta limitando l’accesso ai file non web e alle password hashed bcrypt
  • Directory personalizzata dei contenuti wp denominata app
  • Composer per la gestione di WordPress, dei plugin, dei temi e di altre dipendenze PHP
  • .gitignore che esclude il core, i plugin e gli upload di WordPress

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.

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 Bedrock sono dotati di mu-plugin installati automaticamente, ma è necessario installare il MU plugin di Kinsta inserendo il pacchetto kinsta-mu-plugins. Questo plugin (che viene installato per impostazione predefinita quando si crea un sito WordPress tramite MyKinsta) gestisce aspetti quali il caching di tutta la pagina e l’integrazione del CDN di Kinsta.

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 esegui quanto segue dalla cartella Bedrock/sito (o specifica i plugin kinsta/kinsta-mu come requisito nel file composer.json):

composer require kinsta/kinsta-mu-plugins:2.3.3

Le seguenti costanti possono essere necessarie per risolvere i problemi con i percorsi CDN e gli URL delle risorse condivise dei plugin. Aggiungete il seguente codice al file di configurazione del sito (bedrock/config/application.php nei siti Bedrock):

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

Per ulteriori informazioni, tra cui anche come aggiornare il plugin, consultate la nostra guida al MU plugin di Kinsta.

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!

Ben Word

Ben Word è un web developer e interaction designer. È il fondatore di Roots, un'organizzazione open-source che crea strumenti per aiutare gli sviluppatori di WordPress a costruire siti migliori.