Intro : Entre autres choses, Parallax est un partenaire AWS. Ce didacticiel vous permettra d’être opérationnel, mais si vous avez besoin de quelque chose d’autre en termes de support, d’aide, de sécurité ou de conseil, venez nous dire bonjour – nous sommes des gens sympas.
Alors… la boîte d’hébergement partagée que vous utilisiez pour faire fonctionner votre site WordPress ne convient plus ? Ne craignez rien, c’est ce qui se passe lorsque des personnes veulent réellement visiter votre site. La séquence habituelle des événements est que votre site commence à ralentir, vous rencontrez des erreurs de connexion en provenance de votre base de données et que tout le monde commence à regarder votre site web avec tristesse et déception, alors que le reste de l’entreprise se délecte de cette nouvelle renommée Internet mais s’efforce de comprendre pourquoi quelque chose d’aussi simple que de garder un site en ligne ne se produit pas.
Dans ce didacticiel, nous expliquerons comment installer et exécuter WordPress sur Amazon Web Services de manière à ce que vos données soient en sécurité, votre site rapide et votre hébergement croît et se réduit en fonction de l’affluence sur votre site web, en utilisant Elastic Beanstalk pour les DevOps, Aurora pour la base de données et Elastic Filesystem pour le stockage de téléchargement.
Si vous venez d’un contexte VPS / hébergement partagé traditionnel, AWS peut être un peu effrayant. Ce n’est pas le cas, c’est juste un peu différent et vous devez faire un peu plus de démarches vous-même pour que tout se passe comme vous le souhaitez.
Chaque fois que nous utiliserons un terminal dans ce didacticiel, le texte sera stylisé comme suit . N’oubliez pas que vous devrez appuyer sur entrée / retour après chaque bit d’entrée du terminal.
Étape 1: obtenir un compte AWS
Vous devez avoir un compte avec Amazon Web Services pour commencer. C’est assez facile à faire, ils vous adressent généralement un appel de vérification lors de votre inscription, ce qui peut prendre un peu de temps.
Si vous avez déjà un compte AWS, prenez un moment pour vous donner un « High-Five ». Vous gagnez ! Sinon, créez-vous un compte.
Étape 2: Le code source / Installer Git
Vous voudrez avoir votre code source dans un dossier de votre ordinateur, géré avec Git. Si vous utilisez déjà Git, c’est également génial. Sinon, vous voudrez l’installer, que ce soit pour Windows ou Mac.
Git est comme un système de gestion de version pour les fichiers. Si vous pensez à un formulaire papier, comme ceux (interminables) que la banque vous oblige à remplir lorsque vous demandez un prêt hypothécaire, Git serait un peu comme un système que vous utilisez pour stocker un formulaire à chaque étape de son remplissage (si vous êtes comme moi, probablement au bout de quelques jours, la procrastination et la paperasserie vont de pair).
L’avantage de Git est que, lorsque vous commettez inévitablement une erreur en remplissant ledit formulaire, vous pouvez revenir très facilement à une version précédente. C’est également ce que nous allons utiliser pour stocker notre code afin que les autres éléments d’Amazon Web Services auxquels nous l’enverrons puissent comprendre les modifications qui y seront apportées.
Installer Git sur Mac :
1. Téléchargez le dernier Git pour Mac
2. Exécutez l’installateur comme vous le feriez avec n’importe quoi d’autre
3. Ouvrez un terminal (Applications / Utilitaires / Terminal)
Installer Git sous Windows :
1. Téléchargez la dernière version de Git pour Windows
2. Exécutez l’installateur comme vous le feriez avec n’importe quoi d’autre
3. Ouvrez une invite de commande (tapez «CMD» dans la barre de recherche du menu Démarrer).
Toutes les plateformes – Configurez votre identité Git :
4. Tapez (ou copiez-collez):
git --version
Si vous voyez quelque chose comme « git version xxx », c’est bon, Git est en fait installé. Si vous voyez « command not found », il ya un problème : essayez de réexécuter le programme d’installation.
5. Dites à Git qui vous êtes – c’est pour qu’il puisse enregistrer vos données en fonction des modifications apportées à votre code. Exécutez ce qui suit en remplaçant mes coordonnées par les vôtres (sinon, vous utiliserez Git en étant moi et ça ferait désordre) :
git config --global user.name "Lawrence Dudley"
git config --global user.email "[email protected]"
6. Célébrez – Git est maintenant installé sur votre ordinateur.
Obtenez votre code source dans Git :
Nous allons utiliser notre nouveau Git pour gérer notre code. C’est assez simple, mais nous devons exécuter quelques commandes pour nous assurer que Git sait où se trouve notre code et comment il doit le gérer.
Je le fais sur un Mac – les commandes Windows devraient être identiques, à part des choses comme changer de répertoire qui est « cd » sur Mac et « dir » sur un PC.
Je vais utiliser une nouvelle copie de WordPress que j’ai téléchargée, décompressée et placée sur mon bureau.
1. Nous allons d’abord changer de répertoire dans notre dossier décompressé :
cd ~/Desktop/wordpress
2. Ensuite, nous allons initialiser un référentiel Git dans ce dossier :
git init
Vous devriez voir quelque chose comme: « Initialized empty Git repository in /Users/lawrencedudley/Desktop/wordpress/.git/ »
3. Ensuite, nous allons ajouter tous les fichiers ici à Git :
git add -A
4. Et ensuite, nous allons les « committer ». Committer dans Git, c’est un peu comme planter un bâton dans le sable et dire «à ce moment-ci, voici à quoi tout ressemble et nous nous référerons à cela». Dans ce cas, nous parlerons de «initial commit»:
git commit -m "initial commit"
Vous pouvez changer ce qui se trouve entre les deux guillemets pour dire quelque chose d’autre – ce n’est rien de fonctionnel, simplement comment vous souhaitez l’appeler.
5. Vérifiez que votre code est bien committé :
git status
Si vous ne voyez « nothing to commit, working tree clean », vous voilà prêt !
Étape 3 : Configurer un environnement Elastic Beanstalk
Il existe différentes manières (nombreuses en fait) d’utiliser Amazon Web Services pour contrôler certains serveurs. Vous pouvez passer directement par la route EC2, ce qui serait comparable à l’exécution de votre propre VPS, moins les panneaux de contrôle fournis avec le vôtre, ou vous pouvez utiliser l’une des autres options de gestion pour configurer les instances et les faire exécuter ce que vous voulez (en particulier votre site WordPress).
Nous allons utiliser Elastic Beanstalk dans cet exemple car il est assez simple et extensible pour faire ce que nous voulons réaliser et prend en charge la plupart des tâches compliquées, en coulisse, pour nous.
Installer l’interface de ligne de commande Elastic Beanstalk
L’interface de ligne de commande « eb » vous permet d’insérer du code dans Elastic Beanstalk.
Amazon dispose d’un bon guide pour l’installer.
Si vous êtes sur un Mac, ceci devrait être suffisant pour exécuter :
pip install --upgrade --user awsebcli
Choisissez une région AWS
Vous devrez choisir une région AWS dans laquelle déployer. Il y en a plusieurs:
us-east-1: Est des États-Unis (Virginie du Nord)
us-west-1: Ouest des États-Unis (N. Californie)
us-west-2: Ouest des États-Unis (Oregon)
eu-west-1: UE (Irlande)
eu-central-1: EU (Francfort)
ap-south-1: Asie Pacifique (Mumbai)
ap-south-1: Asie Pacifique (Singapour)
ap-south-2: Asie Pacifique (Sydney)
ap-nord-est-1: Asie Pacifique (Tokyo)
ap-nord-est-2: Asie Pacifique (Séoul)
sa-east-1: Amérique du Sud (Sao Paulo)
cn-north-1: Chine (Beijing)
us-east-2: Est des États-Unis (Ohio)
ca-central-1: Canada (Central)
eu-west-2: EU (Londres)
En règle générale, vous souhaiterez choisir une région proche des visiteurs de votre site Web. Cependant, il y a une petite mise en garde : tous les services AWS ne sont pas encore disponibles dans toutes les régions.
Comme la dernière partie de ce didacticiel repose sur l’utilisation d’Elastic File System, un composant relativement nouveau d’AWS, seules les régions suivantes prennent en charge tous les services utilisés :
us-east-1: Est des États-Unis (Virginie du Nord)
us-east-2: Est des États-Unis (Ohio)
us-west-2: Ouest des États-Unis (Oregon)
eu-west-1: UE (Irlande)
Dans cet exemple, nous avons beaucoup utilisé Londres, mais veuillez noter qu’à l’heure actuelle, EFS n’est pas pris en charge. Par conséquent, si vous êtes en Europe comme nous le sommes, l’Irlande est probablement la voie à suivre.
Vous pouvez sélectionner une région dans le menu déroulant situé en haut à droite de la plupart des écrans de la console AWS.
Configurer une application vierge Elastic Beanstalk
Vous serez dans la console principale lorsque vous vous connecterez à Amazon Web Services. Cela ressemblera un peu à ça :
Le service que vous recherchez est Elastic Beanstalk. C’est sous « Computer » (suivez la flèche sur la capture d’écran ci-dessus) ou vous pouvez le rechercher.
Remarque: j’utilise la nouvelle interface utilisateur publiée par AWS pour EB dans ces exemples. Vous devriez recevoir une invitation à utiliser la nouvelle interface utilisateur. Si vous ne le faites pas, ne paniquez pas – bien que tout puisse sembler légèrement différent, il n’est pas très loin de ce qu’il était et il se trouve principalement au même endroit, appelé pareillement.
Une fois que vous l’ouvrez, vous devriez voir ceci :
Essayez de contenir votre enthousiasme quelque peu et ne pas aller directement et cliquez sur le bouton « launch now ». Nous souhaitons passer en revue l’assistant qui est un peu moins excitant apparaissant lorsque vous cliquez sur « Create New Application » en haut à droite. Encore une fois, suivez les flèches.
J’ai appelé notre application « wordpress » de manière descriptive. Vous pouvez mettre ce que vous voulez ici.
Si vous pensez que vous allez exécuter plus d’une installation WordPress, utilisez peut-être nomsite-wordpress ou quelque chose du genre.
Nous avons une application pour le moment, mais aucun environnement n’est propice à son exécution. C’est BIEN, nous pouvons trier cela maintenant.
Une application ressemble plus ou moins à ce que cela laisse entendre : c’est un ensemble de code qui sera déployé. Un environnement est un emplacement (ou un serveur / un ensemble de serveurs) sur lequel ce code sera utilisé.
La plupart des utilisateurs avancés auront un environnement de production et un environnement de qualité. Certaines personnes auront même un environnement pour chaque version différente de leur application. Nous allons ignorer certains éléments avancés et nous concentrer uniquement sur la mise en route.
Sous « Actions », vous trouverez « Create environment ». Cliquez dessus.
Nous allons ignorer les environnements de travail pour le moment – vous voulez un environnement de serveur Web :
La logique voudrait que vous sélectionniez PHP dans le menu déroulant de cet écran et que vous cliquiez ensuite sur « Create environment ». La logique est fausse. Sélectionnez PHP dans le menu déroulant, mais ne cliquez pas sur ce bouton.
Pourquoi ? WordPress est toujours une bête PHP5.6 pour le moment (même si cela devrait changer en 2017 de temps en temps) et utiliser la version par défaut de PHP risque de faire mal à beaucoup de choses.
Nous allons cliquer sur « Configure more options » à la place :
Il est probablement utile de noter à ce stade qu’avoir le code de l’application comme « Sample application » convient également. Nous nous soucierons du déploiement de notre code dans cet environnement une fois que nous aurons fini de tout configurer.
Notez que nous avons sélectionné « High availability » au lieu de « Low cost ». Cela signifie que notre installation WordPress sera sur plusieurs serveurs, pas qu’un seul et nous permettra de le scaler automatiquement.
Après avoir sélectionné Haute disponibilité, cliquez sur « Change platform configuration » :
Vous voulez choisir PHP 5.6 dans cette liste déroulante. 7.0 ne fonctionnera pas actuellement, mais pourrait fonctionner dans le futur. En prime, vous pouvez réellement changer cela plus tard sans subir de temps d’arrêt. C’est génial.
Vous voudrez ouvrir le réseau, comme indiqué ci-dessous, en cliquant sur « Modify » en dessous :
Sous VPC, choisissez votre VPC par défaut (il ne devrait en exister qu’un dans la liste déroulante s’il s’agit d’un nouveau compte).
La visibilité devrait être « Public ».
Cochez tous les sous-réseaux d’équilibrage de charge.
Cochez « Public IP Address ».
Cochez tous les sous-réseaux d’instance.
Cochez l’option par défaut pour le groupe de sécurité.
Si vous êtes un peu clique-heureux comme moi, vous aurez remarqué qu’il existe une option de base de données dans les écrans de configuration.
Ne touchez pas à cela – aussi tentant soit-il, il ne prend actuellement pas en charge un système appelé AWS Aurora. En termes simples, Aurora est fondamentalement MySQL, mais en plus génial et nettement plus rapide.
Parce que nous aimons les choses impressionnantes et rapides, nous allons configurer nous-mêmes certains de ces éléments ultérieurement.
Une dernière étape facultative consiste à attribuer un nom à votre environnement. C’est une bonne chose à faire, car si vous ne le faites pas, il sera appellé «Custom-env», ce qui n’est pas particulièrement accrocheur. Nous allons appeler le notre : « Production ».
Vous trouverez ce paramètre dans la première zone de configuration, intitulée « Environment settings » :
Une fois que cela est sauvegardé, vous pouvez laisser le reste tel quel et continuer en cliquant sur le bouton « Create environment » en bas à droite.
AWS partira et fera votre demande pour vous maintenant. Cela prend un peu de temps (peut-être 5 minutes) à se régler, alors soyez patient. Cela n’a peut-être pas l’air de faire des choses, mais c’est le cas.
Que venons nous de faire ?!
Nous avons donc cliqué sur des boutons, AWS a fait certaines choses. Mais quelles choses ?
Ce que nous venons de demander à Elastic Beanstalk de faire pour nous est de créer l’environnement suivant :
Une image vaut mille… euh… noeuds?!
Nous avons mis en place un niveau de serveur web évolutif et équilibré en charge. Qu’est-ce que cela veut dire ?
Il y a un équilibreur de charge au « front ». C’est ce à quoi les navigateurs de l’utilisateur parlent quand ils veulent une page web. L’équilibreur de charge choisit ensuite l’un des serveurs web PHP5.6 placé derrière et demande à l’un d’eux la page web demandée par l’utilisateur. Une fois qu’il l’a reçu, il le renvoie au navigateur de l’utilisateur.
Pourquoi est-ce bon ?
1. L’équilibreur de charge est redondant, c’est-à-dire qu’il risque d’avoir des morceaux qui cassent et que les utilisateurs pourront toujours l’utiliser.
2. Les serveurs web situés derrière sont également redondants. Si l’un d’eux tombe en panne, l’équilibreur de charge cesse de lui envoyer du trafic.
3. Les serveurs web peuvent être mis à l’échelle de manière transparente, c’est-à-dire que vous pouvez avoir deux serveurs web comme dans le diagramme ci-dessus, ou vous pouvez en avoir 50. Qui sait, peut-être que Justin Bieber a écrit un blog pour vous et qu’il est devenu viral.
Moins de temps d’arrêt, plus de vitesse.
Accéder à l’environnement
Si vous revenez à votre application (cliquez sur « wordpress »), puis dans votre environnement (une fois qu’elle devient verte, cela signifie que tout est prêt pour vous), vous remarquerez qu’il existe une URL dans Elastic Beanstalk :
En cliquant sur ce lien, vous pourrez voir l’exemple d’application que nous avons installé précédemment dans cet environnement (rappelez-vous : notre code n’est pas encore entré !) :
La page vous indiquera quelle version de PHP est exécutée par votre environnement. S’il indique 7.0, fermez l’environnement, créez-en un et assurez-vous de choisir 5.6. Vous pouvez avoir autant d’environnements par application que vous le souhaitez, ce qui est utile pour tester des éléments avant de les utiliser.
Étape 4 : faire fonctionner notre code
Nous avons donc un environnement. Mais nous ne voulons pas vraiment d’une page avec «Félicitations» collée dessus. Nous voulons WordPress !
Pour que WordPress s’exécute ici, nous allons faire exécuter notre code dans cet environnement.
Revenez sur votre terminal et accédez au dossier de votre projet qui, si vous vous en souvenez bien, était pour moi le dossier wordpress situé sur mon bureau :
cd ~/Desktop/wordpress
Vous devrez exécuter:
eb init
Ceci vous demandera ensuite dans quelle région vous exécutez votre application. Ce sera la même que la région en haut à droite de tous les écrans de votre console AWS. Pour nous, c’est Londres, nous allons donc aller avec la région 15.
Touches d’accès
Si vous n’avez jamais utilisé EB auparavant, vous verrez ce qui suit :
You have not yet set up your credentials or your credentials are incorrect
You must provide your credentials. (Vous n’avez pas encore configuré vos identifiants ou vos identifiants sont incorrects. Vous devez fournir vos informations d’identification.)
En effet, l’outil EB doit savoir sur quel compte Amazon vous souhaitez déployer.
Dans la console Amazon, ouvrez un outil appelé IAM :
Une fois que vous avez ouvert, sélectionnez Users -> Add New User.
Vous voudrez peut-être attribuer un nom à cet utilisateur – nous avons opté pour « eb-desktop-deploy » et coché « programmatic access ».
Cliquez sur « Next : Permissions »
IAM est très puissant… et très complexe. Par souci de brièveté, nous avons choisi d’associer la stratégie PowerUserAccess à cette situation. Ce n’est pas une bonne pratique (vous devez limiter les autorisations au maximum, mais au minimum), mais il est hors de la portée de ce didacticiel d’aborder trop profondément le fonctionnement d’IAM :
Cliquez sur « Next: Review », puis sur « Create user ».
Cela vous donnera un écran avec votre clé d’accès ID et votre clé d’accès secrète. Vous voudrez peut-être les copier dans l’outil de ligne de commande EB que nous avions précédemment ouvert.
Une fois l’opération terminée et entrée dans l’interface de ligne de commande EB, il vous sera demandé quelle application utiliser. Si vous n’en avez qu’une, votre option 1 devrait être « wordpress » ou ce que vous avez appelé votre application lors de sa configuration dans la console.
La nôtre s’appelle « wordpress » et correspond à l’option 1; nous allons donc avec 1 :
Sélectionnez une application à utiliser
1) wordpress
2) [Create New Application]
Une fois que vous avez entré ceci, vous devriez être de retour à l’invite de commande. L’interface de ligne de commande Elastic Beanstalk est maintenant configurée de sorte qu’elle sache de quelle application est ce dossier, prête à télécharger votre code.
Lançons notre code….
Prêt ? eb deploy
Vous devrez attendre un peu pendant qu’il fait ses affaires, mais il devrait vous faire un retour pour vous dire ce qu’il fait. Il prend votre code, le conditionne sous forme de fichier zip, l’envoie aux serveurs de votre environnement EB et le place là où il doit être.
Si vous visitez maintenant l’URL de votre environnement dans Elastic Beanstalk, vous devriez voir le premier écran de configuration de WordPress :
Parce que nous n’épelons pas tout avec un « Z » ici, nous allons en anglais (UK).
Bon. Le temps du problème.
Rappelez-vous comment nous avons dit de ne pas créer de base de données ? Eh bien… nous ne l’avions pas fait. Nous ne connaissons donc pas le nom de la base de données, le nom d’utilisateur, le mot de passe, enfin, vraiment rien, car il n’existe pas encore.
De retour à la console AWS, nous allons créer la base de données. Le service que nous voulons ici s’appelle «RDS», en abrégé « Relational Database Service » :
Cette fois, le gros bouton bleu est en fait celui que vous voulez. Cliquez sur « Get Started Now ».
Sélectionnez Aurora, puis renseignez les informations nécessaires à la base de données. Nous avons opté pour une taille d’instance t2.medium avec un déploiement multi-z activé.
Cela signifie qu’il existe un nœud de base de données maître et un nœud de base de données esclave et qu’ils se basculent entre eux si nécessaire.
Sachez que la taille par défaut du nœud de la base de données, r3.large, est assez coûteuse à exécuter. Par conséquent, si vous optez pour cette option, assurez-vous que c’est vraiment ce que vous voulez faire ou vous pourriez vous retrouver avec une facture assez lourde.
Assurez-vous de noter à la fois le nom d’utilisateur principal et le mot de passe, car vous en aurez bientôt besoin.
Choisissez le groupe de sécurité VPC par défaut (là encore, le best practice suggérerait le contraire, mais cela dépasse le cadre de ce didacticiel), le reste peut rester tel quel par défaut.
Cliquez sur « Launch DB Instance ».
Si vous cliquez maintenant sur « Finish », puis sur « Instances », vous verrez que vos instances sont en cours de création (il s’agit de la mémorisation Multi-AZ, donc il y en a deux, bien qu’il n’y ait qu’une seule base de données).
Attendez que les instances soient créées. Cela prend un certain temps alors vous voudriez peut-être prendre un café.
Nous avons dit que cela prend un certain temps… Voilà à quoi ça ressemble quand vous y arrivez enfin.
Cliquez sur la petite flèche de divulgation en haut, celle intitulée «wordpress» et non «wordpress-eu-west-2a» :
Copiez-collez-le et placez-le au même endroit que le nom d’utilisateur et le mot de passe de la base de données. Vous avez maintenant assez d’informations pour terminer la configuration de WordPress.
Avant d’y arriver, nous devons nous assurer que nos serveurs Web dans notre configuration Elastic Beanstalk peuvent parler à notre serveur de base de données.
Pour ce faire, ouvrez le service « VPC » dans la console AWS, sélectionnez « Security Groups » à gauche et sélectionnez celui dont le nom de groupe est « default » :
Ouvrez les règles entrantes, ajoutez une règle de type « MYSQL / Aurora » et sélectionnez la source avec le même identifiant de groupe que votre règle par défaut.
Cliquez sur Enregistrer, puis retournez à la page de votre installateur WordPress, saisissez les informations d’identification de la base de données et cliquez sur « Submit ».
Notez que vous n’avez pas besoin de : 3306 à la fin du noeud final du cluster que vous avez copié-collé à partir de RDS. Simplement le nom d’hôte et c’est bien.
Si tout va bien avec vos paramètres de base de données, vous devriez voir ce qui suit :
Hmmm… « Sparky ». C’est ce que nous appelons des électriciens dans le nord de l’Angleterre. Cliquez sur « Run install ».
Vous devriez vous retrouver avec le dernier écran de configuration WordPress :
Suivi par (roulement de tambour s’il vous plaît) le tableau de bord d’administration WordPress :
Voici à quoi ressemble notre diagramme d’architecture. Nous avons séparé l’équilibreur de charge, les serveurs web et maintenant les serveurs de base de données maîtres et esclaves et l’ensemble du système intègre une redondance :
Étape 5 : Persistance du stockage
Si vous attendez un peu, tout va se casser
Vous allez maintenant vous sentir bien dans votre peau, tout le monde vous regarde comme si vous étiez une sorte de super-héros. Au moins jusqu’à ce que vous essayiez de redimensionner votre nouvelle installation WordPress ou de reconfigurer quoi que ce soit et que tout tombe en panne.
Pourquoi ferait-il cela ?
Lorsque nous avons installé WordPress, le programme d’installation a écrit un fichier sur le disque appelé «wp-config.php». Il l’a écrit sur le disque du serveur sur lequel le site est en cours d’exécution. Actuellement comme en ce moment.
Si ce serveur devait être remplacé, ce fichier n’existerait plus car il n’installe que les fichiers que nous avons transmis à Elastic Beanstalk à l’aide de eb deploy. Et ce serait dommage.
La solution consiste donc à valider notre fichier wp-config.php dans Elastic Beanstalk afin que ce fichier soit toujours présent lorsque nous en avons besoin.
La validation des mots de passe dans les fichiers de configuration de votre code source est presque universellement considérée comme une mauvaise pratique. Nous allons donc utiliser un élément appelé « Environment Variables ». Ce sont essentiellement des espaces réservés pour quelque chose qui est stocké ailleurs.
Jetons un coup d’œil aux éléments de notre fichier wp-config.php relatifs à la base de données créés par le programme d’installation :
/ ** MySQL settings – You can get this info from your web host ** //
/** The name of the database for WordPress */
define(‘DB_NAME’, ‘wordpress’);
/** MySQL database username */
define(‘DB_USER’, ‘wordpress’);
/** MySQL database password */
define(‘DB_PASSWORD’, ‘awesome_db_password’);
/** MySQL hostname */
define(‘DB_HOST’, ‘wordpress.cluster-cltekbrfbilr.eu-west-2.rds.amazonaws.com’);
Nous allons définir des variables d’environnement dans Elastic Beanstalk afin que le code n’ait pas à contenir directement les détails (et pourrait en fait être réutilisable sur plusieurs installations WordPress).
Tout d’abord, ouvrez la console Elastic Beanstalk :
Ouvrez ensuite votre environnement et cliquez sur « Configuration » à gauche :
Ouvrez « Software Configuration » et faites défiler vers le bas :
Ces variables / propriétés d’environnement existent toujours dans cet environnement. Nous allons en ajouter quelques-unes pour que WordPress sache toujours où trouver la base de données :
Une fois que vous avez cliqué sur Enregistrer et appliquer, vous pouvez maintenant utiliser ces variables d’environnement en toute sécurité dans votre fichier wp-config.php.
Qui était :
/** The name of the database for WordPress */
define(‘DB_NAME’, ‘wordpress’);
Peut maintenant être appelé comme :
/** The name of the database for WordPress */
define(‘DB_NAME’, getenv(‘DB_NAME’));
PHP lit la valeur de la propriété à partir de la variable d’environnement / propriété définie dans Elastic Beanstalk.
Pour vous aider (et comme vous n’avez pas encore le fichier wp-config.php généré à ce stade), nous avons inclus un fichier de référence qui a été modifié pour vous.
Vous pouvez le télécharger ici, mais n’oubliez pas de modifier vos clés secrètes à partir de la ligne 49 en suivant les instructions du fichier. Dans le cas contraire, votre site risque d’être assez facile à pirater.
Une fois que vous avez modifié les clés secrètes, déposez ce fichier dans votre dossier WordPress localement et validez-le. Après l’avoir déposé dans le dossier, exécutez :
git add -A
git commit -m "added wp-config file"
eb deploy
Elastic Beanstalk mettra un certain temps à déployer vos modifications et une fois cela fait, vous aurez un fichier wp-config.php fonctionnel qui survivra au redémarrage, à la suppression des instances, à la mise à l’échelle de votre configuration, etc.
Qu’en est-il des téléchargements ?
Vous avez peut-être mis un et un ensemble ici. Quoi d’autre dans WordPress écrit des fichiers sur le disque ? Oh oui, c’est vrai : les mises en ligne.
Actuellement, vous avez un site WordPress qui survivra aux redémarrages. Jusqu’ici tout va bien. Et si vous écrivez un article ou une page, elle sera toujours là aussi, car elle est enregistrée dans la base de données. Mais les téléchargements ne le sont pas – ils sont simplement enregistrés localement sur le disque. Nous avons besoin de changer cela.
Heureusement, il existe un service AWS qui convient parfaitement à ce travail. Il s’appelle Elastic Filesystem. Il s’agit d’un gros disque partagé. Nous allons l’attacher à nos serveurs web afin que, lorsqu’un fichier Web sera chargé, il restera là et sera également accessible par d’autres serveurs web.
Nous devons ajouter la dernière pièce (pour le moment) à notre architecture pour qu’elle ressemble à ceci :
Elastic File System (EFS) est un produit intéressant : il vous permet de monter un lecteur partagé. Jusqu’ici tout va bien. Ce qui est intéressant à ce sujet, c’est la façon dont vous l’approvisionnez et le configurez.
Avec EFS, vous ne payez que pour votre utilisation, vous n’avez pas besoin de pré-provisionner une quantité d’espace de stockage et vous pouvez y télécharger jusqu’à 8 exaoctets par volume. C’est beaucoup de photos de chats.
En fait, vous pouvez stocker plusieurs photos de chaque chat ayant jamais vécu, sur un seul lecteur EFS. Vous n’avez probablement pas besoin de 8 exaoctets, mais vous avez besoin de quelque part pour que vos envois WordPress puissent fonctionner, nous allons donc configurer un volume. Ouvrez la console AWS et recherchez EFS :
Choisissez le VPC par défaut comme avant et assurez-vous que toutes les zones de disponibilité sont cochées, puis passez à l’étape suivante.
Les valeurs par défaut sur les deux écrans suivants sont correctes, cliquez simplement sur suivant :
Attendez que l’état du cycle de vie soit prêt. Il dira créer pendant un moment avant de finalement décider que c’est fini. Vous voulez envisager de vous adonner à un passe-temps comme le tricot – tout ce qui nous attend implique une certaine attente.
Ensuite, nous allons monter les volumes au bon endroit, ce qui signifie un peu de configuration pour Elastic Beanstalk car ce n’est pas un service pris en charge par EB depuis la console (pour le moment).
Amazon possède une documentation sur la fonctionnalité, appelée .ebextensions, que nous allons utiliser. J’ai fourni un fichier à copier et déposer dans votre projet ci-dessous si cela semble effrayant. Sinon, poursuivez votre lecture pour une brève explication:
Les extensions .eb sont plus ou moins comparables aux scripts Chef (ou Ansible, Puppet, l’autre, etc.) et sont essentiellement des scripts exécutés à certains moments du cycle de vie d’une instance.
Dans ce cas, nous sommes intéressés par l’installation du client NFS pour monter le volume EFS puis pour monter le volume.
Une fois que le cycle de vie du volume est dans un état « Available », notez le nom DNS qui vous a été fourni :
Nous allons déposer cela dans une autre variable d’environnement Elastic Beanstalk, appelée « EFS_NAME » :
Ensuite, nous allons créer un dossier appelé .ebextensions à la racine du projet et y placer le fichier suivant, appelé «efs.config» :
packages:
yum:
nfs-utils: []
jq: []
files:
« /tmp/mount-efs.sh » :
mode: « 000755 »
content: |
#!/usr/bin/env bash
mkdir -p /mnt/efs
EFS_NAME=$(/opt/elasticbeanstalk/bin/get-config environment | jq -r ‘.EFS_NAME’)
mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2 $EFS_NAME:/ /mnt/efs || true
mkdir -p /mnt/efs/uploads
chown webapp:webapp /mnt/efs/uploads
commands:
01_mount:
command: « /tmp/mount-efs.sh »
container_commands:
01-rm-wp-content-uploads:
command: rm -rf /var/app/ondeck/wp-content/uploads
02-symlink-uploads:
command: ln -snf /mnt/efs/uploads /var/app/ondeck/wp-content/uploads
Ce fichier force Elastic Beanstalk à monter le volume EFS sur / mnt / efs, à supprimer le dossier wp-content / uploads (s’il existe) et à lui faire un lien symbolique vers / mnt / efs / uploads afin qu’il soit conservé et partagé entre les instances.
Exécutez une dernière fois eb deploy et vous êtes prêt.
En conclusion
Vous avez maintenant une installation WordPress fonctionnelle, scalable et tolérante aux pannes, s’exécutant dans Amazon Web Services.
Vous pouvez ajouter et supprimer des serveurs, gérer la capacité de votre base de données séparément de celle de votre serveur web et disposer d’un magasin persistant pour votre dossier de téléchargements WordPress.
Il existe quelques autres sujets connexes que nous pouvons examiner dans un suivi, y compris Route 53, de sorte que le site puisse s’exécuter sur votre propre domaine et sur CDN CloudFront (alias comment rendre votre site WordPress incroyablement rapide) et comment faire pour que le site scale automatiquement ?
article traduit de parall.ax : How to Run Scalable WordPress on AWS (Amazon Web Services) Tutorial – 16/Jan/17 (auteur Lawrence Dudley).
