C’est un article pour tous les développeurs WordPress !

Aujourd’hui, nous allons expliquer comment utiliser et intégrer Bedrock et Trellis chez Kinsta.

Si vous n’avez jamais entendu parler de ces deux outils auparavant, nous les présenterons également et nous espérons vous aider en expliquant pourquoi vous devriez les utiliser par rapport à une configuration traditionnelle.

Bedrock et Trellis

Bedrock et Trellis existent tous deux pour faciliter le développement, la maintenance et le déploiement des sites WordPress.

  • Bedrock offre une autre façon de gérer votre installation WordPress avec une structure de dossiers améliorée, des outils de développement modernes et une sécurité accrue.
  • Trellis travaille avec Bedrock pour créer des environnements de staging avec Vagrant et des déploiements à commande unique.

La principale raison d’utiliser Bedrock est d’obtenir une bonne gestion des dépendances et des paquets pour un projet WordPress. Vous connaissez peut-être déjà npm pour JavaScript ou Bundler pour Ruby. PHP n’est pas différent, et son équivalent est Composer.

Bien que l’utilisation d’un gestionnaire de paquets soit courante, elle l’est moins pour WordPress lui-même puisque WordPress a déjà son propre concept pour les plugins. Bedrock intègre Composer pour gérer les plugins, les thèmes et même le noyau WordPress lui-même comme dépendances.

Trellis est un outil permettant de créer facilement des serveurs de développement et de production pour héberger des sites WordPress. Il a été spécialement conçu pour fonctionner également avec les sites basés sur Bedrock. Le cas d’utilisation par défaut de Trellis est de l’utiliser en développement avec Vagrant et en production pour obtenir la parité entre ces deux environnements.

Cet article explique un cas d’utilisation légèrement différent : Trellis pour votre serveur de développement et Kinsta pour votre serveur de production (et/ou de staging).

Pourquoi utiliser Kinsta plutôt qu’un VPS avec Trellis ? Parce que parfois vous voulez payer quelqu’un d’autre pour gérer le serveur au lieu de le faire vous-même (surtout si vous avez beaucoup de clients). Kinsta facilite également l’évolution sans avoir à gérer plusieurs serveurs, répartiteurs de charge et téléchargements dans les nuages.

Beaucoup d’hébergeurs WordPress ne sont pas très conviviaux pour les développeurs et n’offrent pas l’accès SSH et l’intégration de Composer ou WP-CLI qui sont nécessaires pour utiliser Trellis et Bedrock. Heureusement, Kinsta offre un accès SSH sur tous leurs plans d’hébergement, de Starter à Entreprise, ce qui rend tout cela possible. Ils peuvent également modifier le chemin racine pour une fonctionnalité correcte.

Bedrock par rapport à un WordPress traditionnel

Vous vous demandez peut-être pourquoi vous utiliseriez Bedrock plutôt qu’une installation WordPress traditionnelle. La raison en est que Bedrock a été construit spécifiquement pour les développeurs web modernes :

  • Fichiers de configuration spécifiques à l’environnement, stockés en dehors de la racine du Web public
  • Variables d’environnement pour séparer la configuration du code dans un seul fichier .env
  • Sécurité renforcée en limitant l’accès aux fichiers non Web ainsi qu’aux mots de passe cryptés bcrypt
  • Répertoire wp-content personnalisé nommé app
  • Composer pour la gestion de WordPress, plugins, thèmes et autres dépendances PHP
  • .gitignore qui exclut le noyau, les plugins et les téléchargements WordPress

Raspberry Pi, Snopes, JetBlue, et plus encore, font confiance à Bedrock pour alimenter leurs sites WordPress.

Examinons les deux structures de dossiers côte à côte :

Bedrock par rapport à WordPress
Bedrock par rapport à WordPress

Bedrock amène l’installation de WordPress dans un sous-répertoire au niveau suivant. Une grande partie de la philosophie derrière Bedrock s’inspire de la méthodologie Twelve-Factor App, y compris la version spécifique de WordPress.

Configuration de Trellis pour Kinsta

Tout d’abord, assurez-vous que vos clés publiques SSH sont ajoutées au tableau de bord MyKinsta.

Trellis peut se déployer sur Kinsta avec seulement quelques mises à jour. Puisque Kinsta fournit tout du point de vue du serveur web, l’approvisionnement de vos environnements de staging et de production ne s’applique pas.

La commande unique déployée dans Trellis fonctionne avec Kinsta avec un peu de configuration. Une fois configuré, vous pourrez déployer vos sites WordPress en exécutant le playbook de déploiement dans Trellis :

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

Affichez votre tableau de bord MyKinsta et naviguez jusqu’au site WordPress que vous êtes en train de configurer avec Bedrock et Trellis, ainsi que votre éditeur de code ouvert dans le répertoire trellis de votre projet.

Éditez d’abord trellis/ansible.cfg pour ajouter ce qui suit à [defaults] en haut :

forks = 3
host_key_checking = False

Configuration du développement

Assurez-vous que trellis/group_vars/staging/wordpress_sites.yml est configuré avec le canonical approprié pour votre site de développement :

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

Ouvrez ensuite trellis/group_vars/staging/main.yml et ajoutez ce qui suit à la fin du fichier :

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

Remplacez les chemins project_root et www_root par le chemin correct fourni dans le tableau de bord MyKinsta pour votre environnement de staging Kinsta.

Trouvez votre racine publique dans MyKinsta.
Trouvez votre racine publique dans MyKinsta.

Ensuite, ouvrez trellis/group_vars/staging/vault.yml pour l’éditer en exécutant ansible-vault edit group_vars/staging/vault.yml.

Nous devons ajouter db_user, db_name et db_password à env. Vous pouvez trouver les valeurs de ces éléments sur l’écran d’information principal de votre site dans le tableau de bord MyKinsta.

Les identifiants SFTP et de la base de données dans MyKinsta.
Les identifiants SFTP et de la base de données dans 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: ""

Enfin, ouvrez  trellis/hosts/staging et remplacez le contenu par :

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

Assurez-vous que l’hôte et le port SSH correspondent à ce qui est indiqué dans le tableau de bord MyKinsta.

Détails SFTP et port de l’hébergeur pour votre environnement de staging.
Détails SFTP et port de l’hébergeur pour votre environnement de staging.

Configuration de la production

Répétons maintenant le même processus ci-dessus pour l’environnement de production. Assurez-vous de basculer vers votre environnement « Production » dans le tableau de bord MyKinsta.

Passez à votre environnement de production dans MyKinsta.
Passez à votre environnement de production dans MyKinsta.

Ouvrez trellis/group_vars/production/main.yml et ajoutez ce qui suit à la fin du fichier :

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

Veillez à remplacer les chemins project_root et www_root par le chemin correct fourni dans le tableau de bord de MyKinsta pour votre environnement de production.

Ensuite, ouvrez trellis/group_vars/production/vault.yml pour l’éditer en exécutant 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: ""

Enfin, ouvrez trellis/hosts/production et remplacez le contenu par :

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

Modification des tâches de déploiement

Trellis Deploys essaie de recharger php-fpm, que nous devons supprimer des tentatives d’exécution sur les serveurs de Kinsta. Nous devons aussi déclencher le nettoyage du cache de Kinsta lors d’un déploiement.

Ouvrez trellis/roles/deploy/hooks/finalize-after.yml et faites défiler vers le bas. Supprimez la dernière tâche pour Reload php-fpm et ajoutez ce qui suit :

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

Remplacez ask-support-rep ci-dessus après avoir demandé à un représentant du support Kinsta l’URL pour vider le cache sur votre site.

Optionnel : Installer les dépendances de composer

Si vous obtenez un écran qui vous dit d’exécuter ‘Composer Install’, ajoutez ce qui suit juste avant le code « Clear Kinsta cache » ci-dessus :

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

Le /final-path peut varier selon vos paramètres de Bedrock/Trellis.

Ajout de kinsta-mu-plugins à Bedrock

Les sites Bedrock sont livrés avec des mu-plugins installés automatiquement, mais, vous devrez installer le mu-plugin de Kinsta en apportant le paquet kinsta-mu-plugins. Cette extension (qui est installée par défaut quand vous créez un site WordPress via MyKinsta) gère des choses comme la mise en cache de la page entière et l’intégration du CDN de Kinsta.

Ouvrez site/composer.json et ajoutez ce qui suit dans la table repositories  :

{
  "type": "package",
  "package": {
    "name": "kinsta/kinsta-mu-plugins",
    "type": "wordpress-muplugin",
    "version": "2.0.15",
    "dist": {
      "url": "https://kinsta.com/kinsta-tools/kinsta-mu-plugins.zip",
      "type": "zip"
    }
  }
}

Exécutez ensuite ce qui suit depuis votre répertoire Bedrock/site (ou spécifiez les extensions kinsta/kinsta-mu comme pré-requis dans votre fichier composer.json :

composer require kinsta/kinsta-mu-plugins:2.3.3

Les constantes suivantes peuvent être nécessaires pour résoudre les problèmes liés aux chemins CDN et aux URL des ressources des extensions partagées. Ajoutez le code suivant au fichier de configuration de votre site (bedrock/config/application.php dans les sites 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");

Pour plus d’informations, y compris la façon de mettre à jour l’extension, consultez notre guide pour l’extension Kinsta MU.

Étapes finales avec le support de Kinsta

La dernière chose à faire est d’informer Kinsta de la valeur de la racine du document. Allez sur MyKinsta et demandez à l’équipe de support de remplacer votre racine de document par public/current/web.

Si vous n’avez pas déjà obtenu l’URL de cache clair plus tôt, demandez-la également à votre représentant du support, et assurez-vous que trellis/roles/deploy/hooks/finalize-after.yml est mis à jour avec l’URL correcte pour effacer le cache Kinsta lors d’un déploiement réussi.

Une fois ce changement effectué, vous serez en mesure de déployer à la fois dans vos environnements de staging et de production avec une seule ligne :

# 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

Mieux encore…. configurez un service d’intégration continue, tel que CircleCI, pour exécuter automatiquement le déploiement pour vous lorsque vous faites un commit soit vers le développement soit au master !