La sorcellerie des opérations à la source pour WordPress

Les opérations à la source ont été lancées sur Platform.sh il y a environ 4 ans, mais elles étaient limitées aux clients des plans Enterprise et Elite. Sur Upsun, l'accès aux Opérations à la Source est disponible sur tous les plans.

Si vous n'êtes pas familier avec les Opérations Source, il s'agit d'une fonctionnalité qui vous permet de spécifier des commandes qui peuvent commettre des changements dans le dépôt de votre projet lorsqu'elles sont appelées. Par exemple, les Opérations Source peuvent être utilisées pour mettre à jour vos dépendances, et même accrocher une mise à jour du compositeur à une tâche cron afin que les mises à jour des dépendances se produisent automatiquement sur un environnement dédié.

Mais qu'en est-il si vous n'utilisez pas composer ? Que se passe-t-il si vous avez une installation WordPress traditionnelle ?

Vanilla waiver

Nous appelons ce cas WordPressvanille; il se distingue par ses points d'incompatibilité avec la façon dont nous faisons normalement les choses chez Upsun. Les développeurs WordPress sont habitués à pouvoir se connecter par SFTP à un serveur sur lequel tourne WordPress pour effectuer des modifications ou utiliser l'interface de commande pour obtenir des mises à jour. Mais la fonction auto_update_core de WordPress ne fonctionne pas avec les systèmes de fichiers en lecture seule que vous obtenez sur nos conteneurs d'applications.

Pour cette raison, nous vous suggérons de désactiver WP_AUTO_UPDATE_CORE et recommandons aux développeurs d'utiliser Composer. Si vous devez suivre la voie vanille, vous êtes limité à "mettre à jour localement, commiter, et pousser".

Mais avec Source Operations, il est possible d'accéder à un système de fichiers accessible en écriture, de vérifier la branche actuelle, et de faire ce genre de changements. Devriez-vous faire cela ? Il y a beaucoup de mises en garde et de cas limites que nous n'avons pas encore découverts. Il est peut-être préférable de considérer cet article comme un "regardez ce que les opérations sur les sources peuvent faire", après quoi nous pourrons déterminer ensemble les meilleures pratiques pour ces opérations, ainsi que leurs limites.

Mise en place

Pour commencer, nous suivons le guide de déploiement d'une base de code WordPress Vanilla sur Upsun. Si vous essayez de migrer votre propre site WordPress Vanilla, ce guide sera la meilleure ressource pour le faire. Une fois que vous avez terminé le guide et déployé votre site, connectez-vous au tableau de bord d'administration de WordPress. La section "Mises à jour" se trouve dans la barre latérale. Lorsqu'une mise à jour d'un plugin, d'un thème ou du noyau de WordPress est disponible, vous verrez une notification sur cet onglet. Normalement, c'est à ce moment-là que nous vous conseillons d'extraire, de mettre à jour, de livrer et de pousser vers un nouvel environnement pour tester ces mises à jour.

Mais essayons plutôt avec Source Operations cette fois-ci.

CLI et authentification

L'exécution de la mise à jour va nécessiter l'utilisation du CLI d'Upsun dans l'environnement et, par conséquent, un jeton API. Obtenez un jeton depuis votre page "Accounts" de la console de gestion, et ensuite (avec le CLI installé localement) créez une variable d'environnement au niveau du projet avec ce jeton :

$ upsun variable:create -l project --prefix env :--name UPSUN_CLI_TOKEN --value "API_TOKEN" --json N --sensitive y --visible-build y --visible-runtime y

Nous allons encore ajouter quelques restrictions qui empêchent l'opération de s'exécuter sur votre environnement de production dans la section suivante, mais le fait de définir la variable à l'échelle du projet nous permet de la rendre visible au moment de la construction, ce qui est le niveau dont nous aurons besoin pour qu'elle soit visible au cours d'une opération de source. C'est à ce stade que nous avons notre première grande mise en garde : dans quelle mesure est-il sûr d'inclure un jeton d'API dans votre projet de cette manière ?

Si vous êtes le seul à travailler sur le projet, il n'y a pas de problème. Mais dans la pratique, cela arrive rarement, et votre jeton d'API personnel - bien qu'il ne soit pas visible dans la console d'administration - sera visible par toute personne ayant un accès SSH à l'un des environnements du projet. Quelqu'un pourrait utiliser ce jeton, s'il appartenait au propriétaire du projet, et supprimer le site s'il était motivé. Ce qui n'est pas une bonne chose.

Nous recommandons généralement d'utiliser des jetons d'API qui appartiennent à des utilisateurs demachines¹, un compte Upsun ayant des permissions restreintes sur le projet et dont le seul but est d'exécuter des tâches d'automatisation comme celle-ci.

Après avoir ajouté le jeton comme variable d'environnement, vous pouvez ajouter le CLI Upsun comme dépendance de construction à votre fichier .upsun/config.yaml:

dependencies : php : wp-cli/wp-cli-bundle : "^2.4" psy/psysh : "^0.10.4" platformsh/cli : "*"

Dans d'autres tutoriels, nous vous avons demandé de télécharger le CLI dans vos hooks de construction, mais il s'avère que cela ne fonctionnera pas vraiment comme prévu ici. Les opérations sur les sources ont lieu sur les systèmes de fichiers juste avant l' exécution du crochet de compilation. Les dépendances de compilation sont donc disponibles, mais si le CLI était installé plus tard, il ne le serait pas. Si vous préférez ne pas inclure le CLI en tant que dépendance de construction de cette manière, vous pouvez toujours l'installer pendant vos crochets de construction. Mais vous devrez également exécuter la même commande d'installation dans la définition de l'opération source.

L'opération de mise à jour

Dans votre fichier .upsun/config.yaml, ajoutez le bloc suivant :

source : operations : update-wordpress : command : # Ouvrir un tunnel vers l'environnement actuel, ce qui nous permet d'obtenir les informations d'identification de la base de données. ENVIRONMENT=$(git rev-parse --abbrev-ref HEAD) platform tunnel:open -p $PLATFORM_PROJECT -e $ENVIRONMENT -y # Exporter l'objet relations et ensuite les informations d'identification de la base de données vers l'environnement.
        export PLATFORM_RELATIONSHIPS="$(platform tunnel:info --encode)" export DB_NAME=$(echo $PLATFORM_RELATIONSHIPS | base64 --decode | jq -r ".mariadb[0].path") export DB_HOST=$(echo $PLATFORM_RELATIONSHIPS | base64 --decode | jq -r ".mariadb[0].host") export DB_PORT=$(echo $PLATFORM_RELATIONSHIPS | base64 --decode | jq -r ".mariadb[0].port") export DB_USER=$(echo $PLATFORM_RELATIONSHIPS | base64 --decode | jq -r ".mariadb[0].username") export DB_PASSWORD=$(echo $PLATFORM_RELATIONSHIPS | base64 --decode | jq -r ".mariadb[0].password") export DB_HOST=$DB_HOST:$DB_PORT # Mettez à jour WordPress avec le WP CLI.
        wp core --path=$PLATFORM_SOURCE_DIR/wordpress update wp plugin --path=$PLATFORM_SOURCE_DIR/wordpress update-all wp theme update --path=$PLATFORM_SOURCE_DIR/wordpress --all # Mettre en scène les changements, en ne validant que lorsque les mises à jour sont disponibles.
        git add . STAGED_UPDATES=$(git diff --cached) if [ ${#STAGED_UPDATES} -gt 0 ] ; then git commit -m "Gloriously autoupdated Wordpress." else echo "No WordPress updates found." fi # Fermer la connexion. platform tunnel:close -y

Note : si vous avez choisi MySQL au lieu de MariaDB dans le guide de démarrage, ou si vous avez changé le nom de votre service de base de données en quelque chose d'autre que mariadb, vous devrez changer le code ci-dessus pour refléter le nom que vous avez utilisé.

Nous avons donc un bloc de YAMLintéressant , décortiquons-le. Lorsque l'opération est exécutée, nous allons en fait utiliser l'interface de programmation pour ouvrir un tunnel vers l'environnement et utiliser ce tunnel pour imiter le tableau des relations localement, comme nous le ferions dans un scénario de développement local en tethered. Le fait d'avoir nos identifiants de base de données disponibles nous permet de lancer nos commandes de mise à jour avec l'interface de programmation de WordPress.

Une fois cela fait, nous lançons la mise à jour. Ensuite, nous avons un petit bloc qui vérifie si des changements de fichiers ont eu lieu sur le référentiel après la mise à jour. Nous avons remarqué que sans ce bloc, une commande de mise à jour qui ne donne aucune mise à jour disponible (rien à livrer, un arbre de travail propre devrait être une bonne nouvelle) peut parfois entraîner un blocage de l'opération lorsque nous essayons de livrer. Ce bloc vérifie s'il y a quelque chose de mis en scène pour le commit et sort lorsque tout est à jour. Ensuite, nous fermons notre tunnel pour nettoyer après nous.

Après avoir validé et poussé l'opération vers le projet, créons une nouvellebranche² que nous pourrons dédier au test des mises à jour.

$ upsun environment:branch update-wordpress

Une fois le déploiement réussi, nous pouvons à tout moment exécuter l'opération sur cetenvironnement³:

$ upsun source-operation:run update-wordpress

Vous verrez que l'opération s'exécutera et, si des mises à jour sont disponibles pour des plugins, des thèmes ou le noyau de WordPress, les validera dans l'environnement, prêt à être testé.

Mises à jour automatiques

C'est bien que nous ayons créé un nouveau point de terminaison pour le projet afin de rechercher et d'appliquer les mises à jour à notre site WordPress vanille. Mais je ne vais pas me rappeler de le faire régulièrement, et comme je suppose que vous et moi ne sommes pas faits de matériaux différents, automatisons cela.

Ajoutez ce qui suit à .upsun/config.yaml:

crons : auto-update-wordpress : spec : "0 1 * * *" cmd : | if [ "$PLATFORM_BRANCH" = update-wordpress ] ; then platform environment:sync code data --no-wait --yes platform source-operation:run update-wordpress --no-wait --yes fi

Nous avons maintenant une tâche cron qui s'exécute tous les jours à 1 heure du matin, synchronise lecode⁴ et les données de notre site de production, puis exécute notre opération de mise à jour. Nous avons même inclus quelques restrictions de branches pour que toutes nos mises à jour se fassent au même endroit - uniquement sur notre environnement de mise à jour dédié.

Maintenant que nous vous avons montré les secrets de cette astuce des Opérations Source, nous espérons que vous l'essaierez et que vous nous direz si elle a été un succès ou une simple bouffée de fumée.