Comment déployer un site WordPress sur Platform.sh en 5 minutes

Déployer Wordpress Platform.sh devops Programisto Blog

Platform.sh est un outil de déploiement web extrêmement efficace lorsqu’on évoque les phases de DevOps (ou Développement Opérationnel) de votre projet. Cet outil permet de placer une sur-couche maléable et résilient par-dessus le service d’hébergement (1&1, Gandi, Google Cloud Platform, AWS, Azure…) choisi. Une fois l’environnement déterminé et construit ; les équipes techniques pourront manipuler votre(vos) site(s) et serveur(s) en quelques clics. 

Déployer WordPress sur Platform.sh

Gestionnaire de contenu parmi les plus populaires au monde, WordPress, écrit sur une base de language PHP permet de créer des sites vitrines et e-commerce rapide à mettre en place et faciles à éditer. Platform.sh propose un système basé sur un Composer et des Templates WordPress permettant de gérer les paquets PHP plus intuitivement et du00e9ployer votre site en toute résilience et stabilité.

Temps total 5 minutes

  1. Installez les outils DevOps de Platform.sh

    Le premier outil à mettre en place est Git. En tant que plateforme en tant que service, ou PaaS, Platform.sh gère automatiquement tout ce dont votre application a besoin pour fonctionner ; se basant sur l’outil Git pour en gérer les fichiers. Chaque commit poussé donne lieu à un nouveau déploiement, et toute votre configuration est gérée presque entièrement par un petit nombre de fichiers YAML dans votre Git (que nous aborderons dans les u00e9tapes ci-dessous). Votre infrastructure, décrite dans ces fichiers, devient une partie de votre application elle-même – complètement transparente et contrôlée par versions. Si vous n’avez pas encore Git sur votre ordinateur, vous devriez l’installer maintenant.

    Ensuite, vous aurez besoin de Secure Shell (SSH) pour vous connecter en toute sécurité à votre dépôt et vos environnements Git. Des clients SSH sont facilement disponibles pour toutes les plateformes et sont peut-être déjà installés sur votre ordinateur.

    Platform.sh prend en charge l’authentification par paire de clés et par certificat. Les deux sont sécurisés et protègent votre compte contre le snooping lorsque vous vous connectez. Pour l’instant, vous pouvez utiliser l’authentification par certificat car elle est plus simple. Vous serez invité à vous connecter via votre navigateur Web la première fois que vous exécuterez Platform SSH. Si vous souhaitez utiliser l’authentification par paire de clés, consultez la page SSH de Platform.SH avant de poursuivre.

    Enfin, dans ce guide, vous interagirez avec votre projet sur Platform.sh à la fois depuis votre navigateur et depuis la ligne de commande en utilisant le CLI de Platform.sh. Les deux utilisent notre API afin que vous puissiez apporter des modifications à vos projets, mais le CLI sera l’outil que vous utiliserez le plus dans ce guide.

    Vous trouverez ci-dessous un ensemble de commandes d’installation pour différents systèmes d’exploitation :

    # Linux/OSx $ curl -sS https://platform.sh/cli/installer | php

    # Windows $ curl https://platform.sh/cli/installer -o cli-installer.php $ php cli-installer.php

    # Verify the installation $ platform

    # View the list of CLI commands $ platform list

  2. Configurez l’environnement Platform.sh pour WordPress

    Vous pouvez déployer une template WordPress directement sur Platform.sh. Vous pouvez vous inscrire au service en utilisant un compte GitHub, Bitbucket ou Google existant.

    À bien des égards, un projet est simplement une collection d’outils autour d’un dépôt Git. Il reproduit exactement la structure des branches d’un dépôt, mais avec un ajout important : toute branche peut être activée pour devenir un environnement sur Platform.sh.

    Les environnements activés passent par les phases de construction et de déploiement de Platform.sh, ce qui permet d’obtenir un site d’exécution totalement isolé pour chaque branche activée (ou pull request) sur ce dépôt.

    Une fois qu’un environnement est activé, Platform.sh provisionne un cluster de conteneurs pour déployer votre application, et la configuration de ce cluster est contrôlée par trois fichiers YAML :

    .platform/routes.yaml contrôle la façon dont les demandes entrantes sont acheminées vers votre application, ou vos applications si vous utilisez une configuration multi-applications. Il contrôle également le cache HTTP intégré.

    .platform/services.yaml contrôle les services supplémentaires qui sont créés pour supporter votre application, tels que les bases de données ou les serveurs de recherche. Chaque environnement possède sa propre copie indépendante de chaque service.

    .platform.app.yaml contrôle la configuration du conteneur où vit votre application. C’est le plus puissant, avec le plus d’options, et il peut donc être un peu long selon votre configuration.

    Chaque projet sur Platform.sh a besoin d’au moins ces trois fichiers et chacun peut être personnalisé selon vos besoins. Cependant, la plupart des sites WordPress auront une configuration assez similaire, du moins au début.

    Vous pouvez commencer par créer des versions vides de chacun de ces fichiers dans votre référentiel :

    Créer des fichiers de configuration Platform.sh vides

    $ touch .platform.app.yaml && mkdir -p .platform && touch .platform/routes.yaml && touch .platform/services.yaml

    Maintenant que vous avez ajouté ces fichiers à votre projet, vous pouvez passer en revue et configurer chacun d’entre eux pour WordPress sur le site officiel de Platform.sh. Chaque section couvre un fichier de configuration particulier, définit ce que chaque attribut configuré et montre ensuite un extrait de code final qui inclut la configuration recommandée pour WordPress tirée de son modèle. À l’intérieur de cet extrait, assurez-vous de lire chacun des commentaires, car ils fournissent des informations supplémentaires et expliquent pourquoi WordPress exige ces valeurs.

  3. Customisez votre site WordPress via Platform.sh

    Maintenant que votre code contient toute la configuration nécessaire au déploiement sur Platform.sh, il est temps de préparer votre site WordPress à fonctionner dans un environnement Platform.sh.

    Installez le lecteur de configuration

    Platform.sh fournit toutes les informations sur l’environnement d’exécution, y compris la façon de se connecter aux services, par le biais de variables d’environnement. Celles-ci sont accessibles directement, mais il est souvent plus facile d’utiliser la bibliothèque Config Reader que Platform.sh fournit.

    Le Config Reader est simplement un ensemble d’utilitaires pour envelopper les variables d’environnement et les rendre un peu plus ergonomiques à utiliser. Le code ci-dessous l’utilise, vous devrez donc l’installer via Composer si ce n’est pas déjà fait.

    $ composer require platformsh/config-reader

    Une fois la bibliothèque Configuration Reader installée, ajoutez ou mettez à jour un fichier wp-config.php à la racine de votre référentiel pour qu’il corresponde au code ci-dessous.

    Dans ce fichier, l’objet Config de la bibliothèque est utilisé pour :

    • Récupérer les informations d’identification de connexion pour MariaDB via la relation avec la base de données pour configurer la base de données WordPress. Cela configurera la base de données automatiquement et vous évitera d’avoir à configurer la connexion vous-même pendant l’installation.

    • Utiliser les routes du projet pour définir les paramètres WP_HOME et WP_SITEURL. Définissez toutes les clés de sécurité et d’authentification de WordPress dans la variable PLATFORM_PROJECT_ENTROPY fournie par Platform.sh – une variable hachée spécifique à votre référentiel et cohérente entre les environnements.

    De nombreux autres paramètres de WordPress sont prédéfinis dans ce fichier pour vous, consultez les commentaires en ligne pour plus d’informations.

    Configuration de Composer

    Dans ce guide, vous allez configurer votre dépôt WordPress pour qu’il installe tout ce qu’il faut pendant sa construction en utilisant Composer. Cela inclut les thèmes, les plugins, et même le noyau de WordPress lui-même. Tous les nouveaux plugins que vous souhaitez utiliser ou migrer depuis votre application existante peuvent être envoyés en tant que dépendances à l’aide de Composer, mais nous devons apporter quelques modifications au fichier composer.json pour le préparer à l’environnement final Platform.sh.

    Vous pouvez retrouver le détail de ces configurations sur le site officiel de Platform.sh ici.

  4. Déployez votre site WordPress

    Si vous avez personnalisé votre projet existant au fur et à mesure, c’est le moment de vous assurer que tout le code est validé sur Git et de le pousser vers Platform.sh sur la branche master.

    Platform.sh construira alors votre code, produisant une image du système de fichiers en lecture seule de votre application, puis la déploiera dans un cluster de conteneurs en cours d’exécution.

    Vous pouvez visualiser le processus à partir de la console de gestion ; lorsqu’il est terminé, cliquez sur l’URL affichée dans la console pour voir votre site.

  5. Configurer WordPress en écriture sur Platform.sh

    Par défaut, les applications déployées sur Platform.sh sont en « read-only » pour une question de sécurité et de stabilité. Cependant, lorsque l’on utilise un WordPress, on a tendance à vouloir installer différents plugins et ces derniers doivent avoir la permission d’écrire dans certains fichiers afin de pouvoir fonctionner normalement.

    Nous allons voir ensemble comment mettre un place l’écriture sur le dossier wp-content.

    Ouvrez le fichier .platform.app.yaml et insérez ces lignes en dessous de la section « dependencies » :

    mounts:
    « wordpress/wp-content »:
    source: local
    source_path: « wp-content »

    Nous venons d’ajouter une section « mount » à notre application Platform.sh. Ce « mount » est défini comme un dossier qui est accessible en écriture. (il faut bien évidemment pousser ces modifications sur le git et redéployer l’application)

    Pour résumé, grâce à ces quelques lignes de configuration, nous venons de rendre le dossier wp-content et son contenu modifiable. Cela va nous permettre d’installer des plugins qui ont besoin de créer des dossiers/modifier des fichiers au fur et à mesure.

    Pour finir, un des autres fichiers qui est souvent amené à être modifier est : wp-config.php.
    Ce fichier ne se trouve pas dans le dossier wp-content, mais bien à la racine du projet.

    Vous allez me dire, pourquoi ne pas mettre directement le dossier racine en mount, ce qui permettrait d’avoir tout en écriture ?
    Le problème avec cette solution c’est que vous serez amené à modifier potentiellement des choses qui ne doivent pas être modifiées. De plus, afin d’assurer des environnements sains et faciles à déployer, les modifications du code ne doivent être fait uniquement via le git, ce qui permets de suivre l’évolution de l’application. Le mount ne doit servir que pour les uploads, les logs ou les fichiers temporaires.

    Pour citer leurs documentation : « Dans Platform.sh, on ne peut pas ‘hacker la production’. C’est une contrainte, mais une bonne contrainte ».

    Mais Platform.sh propose une alternative, dans le dossier local de votre application se trouve une fichier wp-config.php (celui dont on parle plus haut dans l’article lors de l’installation du Configuration Reader)

    C’est ce fichier qui est utilisé à chaque déploiement. Il vous suffit donc d’ajouter la ligne que vous voulez et elle sera prise en compte lors du déploiement. Par exemple :

    define( 'WP_CACHE', true );

    Cette ligne est utilisée par beaucoup de plugins de gestion du cache. Afin de les faire fonctionner, il vous faudra ajouter cette ligne à la main, puis pousser les modifications vers le git.