Me contacter

WordPress en mode ServerLess

WordPress ServerLess

Le développement web a connu une évolution significative au fil des années, et parmi les innovations les plus marquantes, le concept de « serverless » s’est imposé comme une approche révolutionnaire. Dans un monde où la gestion automatisée des ressources côté serveur prend le devant de la scène, le serverless se positionne comme une solution agile et performante.

Le serverless, loin de signifier l’absence totale de serveurs, redéfinit la manière dont les applications web sont conçues et déployées. Il repose sur une infrastructure cloud où la gestion des serveurs est externalisée, permettant aux développeurs de se concentrer pleinement sur la logique métier de leurs applications. Cette approche, initialement adoptée pour des microservices et des applications évolutives, a trouvé une place de choix dans l’écosystème WordPress.

Dans cet article, nous plongerons dans l’univers fascinant du serverless appliqué à WordPress. Avant d’explorer concrètement comment appliquer cette approche en utilisant Ymir sur un projet WordPress.

Pourquoi le ServerLess pour WordPress ?

WordPress, en tant que système de gestion de contenu (CMS) le plus utilisé au monde, bénéficie grandement de l’adoption du serverless. L’avantage fondamental réside dans la gestion automatisée des ressources, permettant une scalabilité dynamique en fonction des besoins réels du site. Loin des contraintes traditionnelles liées à la maintenance des serveurs, le serverless offre une flexibilité inégalée, réduisant les coûts opérationnels et permettant aux développeurs de se concentrer sur l’amélioration des fonctionnalités plutôt que sur la gestion de l’infrastructure.

Avantages spécifiques de l’Approche Serverless pour les Sites WordPress :

  1. Mise à l’Échelle Automatique : Le principal attrait du serverless pour les sites WordPress réside dans sa capacité à automatiser la gestion des ressources. Contrairement aux infrastructures traditionnelles, où les administrateurs doivent dimensionner manuellement les serveurs pour gérer la charge, le serverless alloue et désalloue automatiquement les ressources en fonction de la demande. Cela signifie que les propriétaires de sites n’ont plus à se soucier des tâches fastidieuses de gestion des serveurs, libérant ainsi du temps et des ressources pour se concentrer sur l’amélioration du contenu et de l’expérience utilisateur.
  2. Sécurité Automatisée des Serveurs : Un avantage majeur du serverless réside dans l’externalisation des problèmes de sécurité des serveurs. Contrairement aux infrastructures traditionnelles qui exigent une attention constante pour garantir la sécurité, le serverless prend en charge automatiquement les aspects liés à la sécurité des serveurs. Cela signifie que les propriétaires de sites WordPress n’ont plus à se soucier des tâches complexes liées à la sécurisation et des mises à jour des serveurs. L’externalisation de cet aspect libère du temps et assure une protection robuste sans nécessiter d’interventions manuelles régulières.
  3. Réduction des Coûts en Payant Uniquement pour l’Utilisation : Contrairement aux modèles d’hébergement traditionnels où les coûts sont souvent fixes, le serverless suit un modèle de tarification basé sur la consommation réelle des ressources. Les propriétaires de sites WordPress ne paient que pour les ressources qu’ils utilisent réellement, ce qui peut entraîner des économies substantielles. Les coûts opérationnels sont directement liés à l’utilisation, éliminant ainsi les frais fixes associés aux serveurs dédiés. Cela offre une flexibilité financière significative, en particulier pour les sites dont la charge varie au fil du temps.

En somme, l’approche serverless pour WordPress représente bien plus qu’une simple évolution technique. Elle transforme la manière dont les sites sont gérés, en offrant une gestion automatisée, une mise à l’échelle transparente et des économies de coûts substantielles. Ces avantages spécifiques ouvrent la porte à une nouvelle ère de développement web, où l’efficacité opérationnelle rencontre la performance sans compromis.

Prêts à découvrir Ymir ou comment libérer la puissance de WordPress tout en embrassant la flexibilité du serverless ?

Avant d’explorer les horizons du serverless avec WordPress, deux étapes préliminaires s’imposent : la création d’un compte sur la plateforme Ymir (ymirapp.com) et la détention d’un compte AWS. Ce dernier, hébergeur cloud majeur, sera le lieu d’accueil de tous les services nécessaires pour faire fonctionner votre site WordPress de manière serverless.

Une fois ces deux comptes à votre disposition, l’installation de Ymir devient la porte d’entrée vers une gestion serverless efficace. Vous avez le choix de l’installer via Composer, soit de manière globale pour une utilisation sur différents projets, soit directement dans le projet en cours. Dans cette exploration, j’opte personnellement pour l’installation globale, une approche qui offre une flexibilité accrue et la possibilité de réutiliser Ymir sur plusieurs projets simultanément.

composer global require ymirapp/cli

Après l’installation vous pouvez utilisez Ymir CLI en tapant la commande :

ymir <command>

Pour lier votre compte AWS à Ymir, suivez ces étapes pour créer un utilisateur via le service Identity and Access Management (IAM) d’AWS. Pour ce faire, rendez-vous dans la console AWS et accédez à la section IAM. Sélectionnez « Utilisateurs » dans le menu de gauche, puis cliquez sur « Ajouter un utilisateur ».

Définissez un nom pour votre utilisateur, par exemple « ymir2 », puis cliquez sur « Suivant ».

Pour l’attribution des politiques choisissez « Attacher directement des politiques » puis cocher la case « AdministratorAccess » pour accorder des privilèges d’administration, puis cliquez sur « Suivant »

Révisez les détails puis cliquez sur « Créer un utilisateur ».

Pour terminer il va falloir procéder à la création des accès pour cet utilisateur, pour ce faire vous devez cliquer sur l’utilisateur que vous venez de créer.

Puis cliquez sur « Créer une clé d’accès ».

Sélectionnez « Service tiers » et cliquez sur « Suivant ».

Finalisez en cliquant sur « Créer une clé d’accès ».

À ce stade, récupérez la clé d’accès et la clé d’accès secrète générées. Ces informations seront nécessaire pour connecter Ymir à cet utilisateur.
Cliquez sur « Terminé » pour finaliser la création des accès de cet utilisateur.

Déploiement de notre application en mode ServerLess

Nous allons maintenant connecter depuis la commande ymir à notre compte Ymir préalablement créé. Pour cela ouvrez votre terminal et tapez la commande suivante :

ymir login

Il suffit de suivre le prompt et d’ajouter votre adresse email et votre mot de passe lorsque cela vous est demandé puis éventuellement d’autoriser la connexion si vous avez activé la double authentification (2FA).

Ensuite vous devez spécifier l’équipe à laquelle vous souhaitez vous connecter (par défaut : Personal) en tapant la commande suivante :

ymir team:select

Pour finir, vous devez vous connecter à votre fournisseur AWS via les accès préalablement créés en tapant la commande :

ymir provider:connect

Ici encore il suffit de suivre le prompt, de donner un nom à la connexion du provider, puis d’entrer la clé et la clé secrète que vous avez obtenues lors de la création de l’utilisateur IAM sur AWS.

En suivant les étapes précédentes, Ymir sera correctement connecté à votre compte, à l’équipe spécifiée, et au fournisseur AWS. Ces connexions établissent le lien essentiel pour déployer et gérer vos projets WordPress en mode ServerLess.

Maintenant nous pouvons initialiser notre projet en se mettant à la racine de celui-ci puis en utilisant la commande :

ymir init

What is the name of the project [Mon-Projet]:
>  Mon Projet

Enter the name of the region that the project will be in:
   [ap-northeast-1] Asia Pacific (Tokyo)
   [ap-northeast-2] Asia Pacific (Seoul)
   [ap-south-1    ] Asia Pacific (Mumbai)
   [ap-southeast-1] Asia Pacific (Singapore)
   [ap-southeast-2] Asia Pacific (Sydney)
   [ca-central-1  ] Canada (Central)
   [eu-central-1  ] Europe (Frankfurt)
   [eu-north-1    ] Europe (Stockholm)
   [eu-west-1     ] Europe (Ireland)
   [eu-west-2     ] Europe (London)
   [eu-west-3     ] Europe (Paris)
   [sa-east-1     ] South America (São Paulo)
   [us-east-1     ] US East (N. Virginia)
   [us-east-2     ] US East (Ohio)
   [us-west-1     ] US West (N. California)
   [us-west-2     ] US West (Oregon)
   eu-west-3
eu-west-3

Your team doesn't have any configured database servers in the "eu-west-3" region. Would you like to create one for this team first? (yes/no) [yes]:
>  yes

What is the name of the database server:
>  mon-site

On what network should the database server be created?:
  [0] mon-site (eu-west-3) [available]
> 0

What should the database server type be?:
   [aurora-mysql   ] Aurora serverless cluster
   [db.t4g.micro   ] 2 vCPU, 1GiB RAM (~$12/month)
   [db.t4g.small   ] 2 vCPU, 2GiB RAM (~$24/month)
   [db.t4g.medium  ] 2 vCPU, 4GiB RAM (~$48/month)
   [db.t4g.large   ] 2 vCPU, 8GiB RAM (~$96/month)
   [db.t4g.xlarge  ] 4 vCPU, 16GiB RAM (~$192/month)
   [db.t4g.2xlarge ] 8 vCPU, 32GiB RAM (~$384/month)
   [db.t3.micro    ] 1 vCPU, 1 GiB RAM (~$13/month)
   [db.t3.small    ] 1 vCPU, 2 GiB RAM (~$25/month)
   [db.t3.medium   ] 2 vCPU, 4 GiB RAM (~$50/month)
   [db.t3.large    ] 2 vCPU, 8 GiB RAM (~$100/month)
   [db.t3.xlarge   ] 4 vCPU, 16 GiB RAM (~$200/month)
   [db.t3.2xlarge  ] 8 vCPU, 32 GiB RAM (~$400/month)
   [db.m7g.large   ] 2 vCPU, 8 GiB RAM (~$125/month)
   [db.m7g.xlarge  ] 4 vCPU, 16 GiB RAM (~$250/month)
   [db.m7g.2xlarge ] 8 vCPU, 32 GiB RAM (~$500/month)
   [db.m7g.4xlarge ] 16 vCPU, 64 GiB RAM (~$1000/month)
   [db.m7g.8xlarge ] 32 vCPU, 128 GiB RAM (~$2000/month)
   [db.m7g.12xlarge] 48 vCPU, 192 GiB RAM (~$3000/month)
   [db.m7g.16xlarge] 64 vCPU, 256 GiB RAM (~$4000/month)
   [db.m5.large    ] 2 vCPU, 8 GiB RAM (~$125/month)
   [db.m5.xlarge   ] 4 vCPU, 16 GiB RAM (~$250/month)
   [db.m5.2xlarge  ] 8 vCPU, 32 GiB RAM (~$500/month)
   [db.m5.4xlarge  ] 16 vCPU, 64 GiB RAM (~$1000/month)
   [db.m5.8xlarge  ] 32 vCPU, 128 GiB RAM (~$2000/month)
   [db.m5.12xlarge ] 48 vCPU, 192 GiB RAM (~$3000/month)
   [db.m5.16xlarge ] 64 vCPU, 256 GiB RAM (~$4000/month)
   [db.m5.24xlarge ] 96 vCPU, 384 GiB RAM (~$6100/month)
   [db.r7g.large   ] 2 vCPU, 16 GiB RAM (~$177/month)
   [db.r7g.xlarge  ] 4 vCPU, 32 GiB RAM (~$355/month)
   [db.r7g.2xlarge ] 8 vCPU, 64 GiB RAM (~$711/month)
   [db.r7g.4xlarge ] 16 vCPU, 128 GiB RAM (~$1423/month)
   [db.r7g.8xlarge ] 32 vCPU, 256 GiB RAM (~$2845/month)
   [db.r7g.12xlarge] 48 vCPU, 384 GiB RAM (~$4269/month)
   [db.r7g.16xlarge] 64 vCPU, 512 GiB RAM (~$5692/month)
   [db.r5.large    ] 2 vCPU, 16 GiB RAM (~$178/month)
   [db.r5.xlarge   ] 4 vCPU, 32 GiB RAM (~$357/month)
   [db.r5.2xlarge  ] 8 vCPU, 64 GiB RAM (~$714/month)
   [db.r5.4xlarge  ] 16 vCPU, 128 GiB RAM (~$1428/month)
   [db.r5.8xlarge  ] 32 vCPU, 256 GiB RAM (~$2857/month)
   [db.r5.12xlarge ] 48 vCPU, 384 GiB RAM (~$4285/month)
   [db.r5.16xlarge ] 64 vCPU, 512 GiB RAM (~$5714/month)
   [db.r5.24xlarge ] 96 vCPU, 768 GiB RAM (~$8571/month)
>  db.t4g.micro

What should the maximum amount of storage (in GB) allocated to the database server be? [50]:
> 25

Should the database server be publicly accessible? (yes/no) [yes]:
>

Important: Please write down the password shown below as it won't be displayed again. Ymir will inject it automatically whenever you assign this database server to a project. If you lose the password, use the "database:server:rotate-password" command to generate a new one.
 
 Database Sever    mon-site
 
 Username          ymir
 Password          XXXXXXXXXXXXXXXXXXX
 
 Type              db.t4g.micro
 Public            yes
 Storage (in GB)   25
 
 Database server created (process takes several minutes to complete)
 What database prefix would you like to use for this project? [mon-site]:
 >
 
 Would you like to create the staging and production databases for your project on the "mon-site" database server? (yes/no) [yes]:
 >  no 
 
Project initialized (process takes several minutes to complete)
 
Would you like to install the Ymir WordPress plugin? (yes/no) [yes]:
>

Installing Ymir plugin using Composer
Ymir plugin installed

Will you deploy this project using a container image? (yes/no) [no]:
>

Cette fois encore il suffit de suivre le prompt et de répondre à différentes questions, telles que le nom du projet, la région du projet (basée sur AWS), la création éventuelle d’une base de données, le nom du serveur de base de données à créer, le réseau sur lequel le serveur de base de données doit être situé, le type de serveur de base de données (pour un petit projet, le db.t4g.micro est suffisant), la taille du disque (minimum 25 Go), l’accessibilité publique de la base de données (indiquer « oui » pour éviter de payer un VPC privé), le préfixe à utiliser pour ce projet, la configuration du projet pour une utilisation en staging et en production, l’installation de Ymir (répondre « oui » s’il n’est pas encore ajouté au projet), le déploiement du projet en utilisant une image (nécessaire pour les projets dont le poids total est supérieur à 250 Mo décompressé). Au-delà de cette limite, l’utilisation d’images est nécessaire, et Docker sera requis. En déployant avec des images, la limite est de 10 Go, ce qui devrait suffire pour la plupart des projets WordPress. Il peut également être nécessaire d’utiliser une image si des besoins spécifiques dans les extensions PHP, par exemple, sont présents.

Une fois l’initialisation terminée vous pouvez retrouver la configuration ymir à la racine du projet dans le fichier ymir.yml

id: 858
name: mon-projet
type: bedrock
environments:
  production:
    architecture: arm64
    php: '8.2'
    build:
      - 'composer install --no-dev'
    database:
      server: mon-site
      name: wordpress

Étant donné que mon projet fonctionne sous la version PHP 8.2, il est crucial de spécifier cette version dans le fichier de configuration ymir.yml. Par défaut, Ymir installe la version 7.4, mais cette étape permet d’ajuster la configuration selon les besoins spécifiques du projet. Vous pouvez consulter l’ensemble des configurations disponibles dans la documentation officielle ici : https://docs.ymirapp.com/reference/configuration.html

Pour déployer il suffit de taper la commande suivante : 

ymir deploy production

Project ymir.yml file is valid
Building project
  > Copying WordPress files
  > Downloading WP-CLI
  > Executing build commands
  > Ensuring Ymir plugin is installed
  > Copying Ymir must-use plugin
  > Extracting asset files
  > Compressing build files
Project built successfully
Uploading build (100%)
No assets change detected (skipping processing assets)
Deployment starting
  > Ensuring cache table exists
  > Ensuring email domains exist 
  > Ensuring environment role exists 
  > Ensuring functions exist 
  > Configuring environment image processing function 
  > Configuring network 
  > Preparing domain names 
  > Assigning SSL certificate 
  > Configuring object store 
  > Creating secrets 
  > Updating functions 
  > Configuring logs 
  > Configuring scheduled cron event 
  > Configuring scheduled warming up event 
  > Configuring gateway 
  > Configuring firewall
  > Configuring content delivery network policies
  > Configuring content delivery network
  > Updating gateway domain mappings
  > Updating DNS records
  > Configuring content delivery network
  > Updating gateway domain mappings
  > Updating DNS records
  > Updating vanity domain DNS record
  > Warming up deployed function
  > Updating function aliases to new version
Project deployed successfully to "production" environment
Environment URL is: https://xxxx-xxxxx-xxxx.ymirsites.com (copied to clipboard)

Note: You cannot send emails using the "ymirsites.com" domain. Please use the "email:identity:create" command to add an email address or domain for sending emails.

Et voilà ! Vous pouvez désormais consulter votre site en utilisant l’url affichée dans le terminal. Pour maintenir une approche minimaliste, certains aspects tels que le nom de domaine personnalisé et l’envoi de mails ont été délibérément laissés de côté. Pour obtenir toutes les informations nécessaires, référez-vous à la documentation complète disponible à l’adresse suivante : : https://docs.ymirapp.com/

Vous pouvez également consulter l’ensemble des commandes disponibles (init, deploy, etc…) en consultant la documentation détaillée disponible ici : https://docs.ymirapp.com/reference/ymir-cli.html

Ou simplement en tapant la commande suivante dans votre terminal :

ymir list