Aujourd’hui je vous propose d’installer WordPress sur Azure Web App. Cela dit, j’ai pris l’exemple de WordPress car c’est un CMS très connu mais cet article vous aidera pour tout autre CMS que ce soit Drupal, Joomla ou encore phpBB – bref tout CMS qui nécessite une base de données de type MySQL ou MariaDB.
Avant d’aller plus loin, précisons tout de suite que l’objectif n’est pas d’expliquer comment installer un serveur en mode IaaS sur lequel nous allons installer Apache, MySQL, phpmyadmin, etc. Mais bien d’utiliser la solution Azure Web App au sein de laquelle vous déploierez uniquement votre CMS sans avoir à gérer votre serveur, les mises à jour, les séances de patchs ou de configuration…
En effet, Azure Web App gérera tout ça pour vous mais s’occupera également de la haute disponibilité ou de l’équilibrage de charges (évidemment toutes ses options auront un coût). Notons d’ailleurs que votre Azure Web App pourra reposer sur un système Windows ou Linux (pour notre test nous allons prendre Linux).
Plus d’informations sur la page officielle Azure.
Pour mettre en place tout ça, nous allons suivre les étapes ci-dessous :
Je passe sur la création d’un compte dans Azure. Je suppose que c’est déjà fait et que vous n’avez pas oublié de bénéficier de votre crédit gratuit (170 €) ! 🙂
Dans la liste de toutes les fonctionnalités disponibles, choisissez Resource Groups et créez-vous un nouveau Resource Group. Ce dernier nous permettra de regrouper tous les éléments nécessaires à notre hébergement web WordPress.
Choisissez un nom (pas déjà utilisé) et la localisation de vos ressources. Azure disposera prochainement d’emplacements en France mais dans l’immédiat j’ai choisi West Europe mais libre à vous d’adapter en fonction de vos besoins.
Pour la souscription, choisissez là où vous avez du crédit ou sur une souscription sur laquelle vous avez renseigné une carte de paiement. Dans mon cas, je dispose d’une souscription avec du crédit grâce à mon abonnement MSDN.
Et voilà, c’est terminé pour le Resource Group. 🙂
Si vous ne le trouvez pas dans la liste des choix n’hésitez pas à effectuer une recherche dans le champ de recherches pour trouver la fonctionnalité App service Plan.
C’est le composant qui va vous permettre de définir le niveau de service que vous souhaitez pour votre site en fonction de si c’est de la production, du développement ou en fonction de vos besoins métiers (si c’est critique ou non par exemple).
Définissez pour votre App Service Plan :
Le pricing tiers correspond au niveau de service souhaité. Le prix ne sera évidemment pas le même en fonction de votre choix.
Le niveau Basic est moins cher mais vous aurez moins de stockage, pas de gestion automatique de la charge et elle sera limitée à 3 instances (gérées manuellement). Ce niveau n’est en général pas utilisé pour des environnements de Production.
Le niveau Standard possède les mêmes spécificités en termes de vCPU ou de RAM mais offre plus de stockage, la gestion automatique de la charge avec la possibilité d’utiliser jusqu’à 10 instances. Ce niveau offre également la possibilité d’utiliser d’autres services tels que le Backup automatique ou encore Traffic Manager.
Pour notre test, restons sur le level S1 – Standard (car j’ai prévu de tester les sous-fonctionnalités dans d’autres articles).
Notez qu’il existe d’autres niveaux mais vous les verrez uniquement selon la configuration de votre souscription (si vous avez associé une carte de paiement) : version Free F1 avec 1 GB d’espace de stockage (sans aucune option), Premium (avec de meilleures performances CPU et stockage) ou encore Isolated (le plus cher).
Comme vous voyez ça peut monter haut en termes de prix mais ce que vous devez garder en tête c’est que ces options sont pour les sites à très forte fréquentation. Ce n’est donc pas tellement élevé si on part du principe que vous n’aurez aucun serveur à administrer en contrepartie ! 🙂
Il nous reste à créer notre Azure Web App. Cette fonctionnalité d’Azure supporte .NET, PHP, Node.js, Python et bien d’autres choses. Dans notre cas, nous allons nous intéresser à PHP.
Choisissez la configuration de votre Web App :
Une fois que la création de cet objet est terminée. Entrez dedans.
Dans la section principale Overview, vous retrouverez dans la partie supérieure votre URL par défaut (que vous pourrez changer) – n’hésitez pas à cliquer pour voir la page par défaut générée par Azure – ainsi que toutes les informations nécessaires pour vous connecter en FTP ou FTPS à votre espace web : le serveur concerné ainsi que le login/identifiant.
Pour configurer le mot de passe qui va avec, rendez-vous dans Deployment Credentials.
Notez bien que votre identifiant FTP est effectivement composé du nom de votre Web App + slash + le login choisi dans la fenêtre ci-dessus.
Il ne vous reste alors plus qu’à utiliser votre logiciel FTP favoris pour y déposer tous les fichiers contenus dans l’archive décompressée de WordPress, Drupal ou n’importe quel autre CMS.
Votre site web a pour racine le dossier wwwroot donc veillez à bien déposer les fichiers de votre CMS dans ce dossier. Et pensez également à supprimer ou déplacer le fichier par défaut généré par Azure et qui porte le nom suivant : hostingstart.html.
Connectez-vous maintenant sur l’URL de votre espace web et vous devriez voir la première page par défaut de WordPress.
Evidemment pour aller plus loin et démarrer l’installation vous devez maintenant créer une base de données MySQL.
Et c’est là que ça devient cool ! 🙂
Jusqu’à il y a encore quelques mois, Azure n’offrait que des bases de données MySQL externalisées gérées par ClearDB. Et honnêtement je ne peux pas dire que je suis fan de ce service, ne pas pouvoir tout gérer directement depuis Azure c’était déjà nul mais en plus les interfaces proposées par ClearDB sont vraiment pas géniales du tout ! 🙁
Mais depuis quelques mois, Microsoft propose (en Preview à l’heure ou j’écris cet article), de véritables bases de données MySQL gérées par Microsoft dans Azure !
Donc comme précédemment, nous allons créer un nouvel objet Azure qui porte le nom de Azure Database for MySQL.
Lors que vous allez choisir vos réglages, vous devez garder en tête que vous déployez non pas une base de données MySQL unique mais bien un serveur MySQL sur lequel vous pourrez créer plusieurs bases de données.
Je vous laisse choisir le nom, le Resource Group associé, etc. N’oubliez pas non plus un identifiant, un mot de passe, la version de MySQL ainsi que le niveau de service que vous souhaitez pour votre serveur MySQL.
Pour l’instant 3 niveaux sont visibles mais seuls 2 sont disponibles : Basic et Standard. Le Premium est encore en cours d’élaboration par les équipes Microsoft. Partons sur du Basic.
Une fois votre objet MySQL créé. Vous verrez là encore vos identifiants ainsi que le rappel de la configuration qui a été choisie (nom du serveur, login).
Nous devons maintenant configurer les flux pour accéder à votre serveur MySQL.
Pour configurer tout ça, vous devez aller dans Connection security. Dans un premier temps, cliquez sur Add My IP. Cela va automatiquement ajouter votre adresse IP personnelle dans les IP autorisées pour accéder au serveur MySQL (on va en avoir besoin).
Et pendant que vous y êtes, vous devez également autoriser votre espace web (Azure Web App) à accéder à votre serveur MySQL. Vu que c’est pour tester, me concernant, j’ai tout ouvert de 0.0.0.0 à 255.255.255.255 mais pour de la production renseignez l’IP de votre Azure Web App. 😉
Il nous reste maintenant à utiliser MySQL Workbench pour créer notre base de données. A télécharger en suivant ce lien (c’est gratuit).
Connectez-vous à votre serveur en utilisant les références récupérées précédemment et utilisez le bouton dédié pour créer une nouvelle base de données (ils appellent ça schema dans MySQL Workbench).
Où en sommes-nous ? 🙂
Nous avons créé notre espace web et envoyé notre nouvelle installation WordPress. Notre serveur MySQL est créé et nous avons autorisé les connections à ce dernier. Une nouvelle base de données appelée « wordpress » a été créée.
Il ne nous reste donc plus qu’à nous reconnecter sur notre espace web et reprendre la configuration de notre CMS.
Et après quelques instants, vous disposez d’une nouvelle installation WordPress (j’ai rempli un peu de contenu car j’ai prévu de tester d’autre choses).
Vous disposez à présent de votre CMS installé en mode SaaS avec tous les avantages : vous pouvez modifier tous les éléments de configuration de votre WordPress. Vous pouvez modifier les fichiers en vous connectant directement sur votre serveur FTP. Ajouter de nouveaux plugins ou thèmes. Vu que vous avez également accès à votre espace FTP, les mises à jour des thèmes ou des plugins grâce à la fonctionnalité automatique de WordPress sera également possible. 🙂
Bref, vous avez tous les avantages sans les inconvénients de devoir gérer vos serveurs, les mises à jour, l’installation des patchs, etc. Et la garantie qu’en cas de charge supplémentaire les ressources attribuées à votre site seront automatiquement ajustées afin de pouvoir supporter la charge. 🙂
En revanche, tout ceci a bien sûr un coût et en mode « as a service » je ne pense pas qu’Azure ou AWS soient de bons choix car assez chers pour ce type d’hébergements. Dans l’exemple ci-dessous, nous en aurons au minimum par mois : 38 € pour notre App Service Plan + 15 € pour notre serveur MySQL soit 53 € / mois (au mieux – dépendant de la charge ou du trafic que votre site va générer ou si vous utilisez d’autres services Azure). D’autres prestataires sont à mon sens de meilleurs choix pour ce type de besoins : OVH, 1&1 et autres alternatives qui proposent des offres d’hébergement à des tarifs plus intéressants (mais toujours mutualisés).
Si on installe une extension du type WP Server Stats, il nous est également possible d’obtenir quelques infos supplémentaires sur la configuration associée à notre WordPress (certains paramètres peuvent être modifiés dans Azure).
D’après mes tests, le seul point un peu gênant pour un WordPress c’est que typiquement votre installation ne peut pas envoyer d’emails. Dans un contexte cloud cela devrait être associé à un autre service par exemple tel que SendGrid. Donc typiquement, un plugin tels que WP-Contact ne fonctionnera pas sur votre CMS (à voir si je découvre d’autres limitations dans mes prochains tests).
Dans les prochains articles, nous allons voir comment nous connecter en SSH à notre Web App, affecter une URL personnalisée, sécuriser notre site en https ou encore utiliser le backup intégré à Azure ! 🙂
Le Brésil vient de franchir un nouveau pas vers la censure en bannissant le réseau…
La nouvelle fonctionnalité Recall de Windows devient désormais optionnelle La controverse Recall prend fin Annoncée…
Fin de Notion en Russie Notion, l'outil de productivité populaire, a annoncé son retrait du…
Apple serait prêt à investir dans OpenAI Une alliance qui pourrait redéfinir le paysage technologique…
Une limitation historique enfin dépassée Le format FAT32, un vieux routier des systèmes d'exploitation, a…
Microsoft va supprimer le Panneau de Configuration de Windows La semaine dernière, Microsoft a fait…