Bâtir pour la production: Applications Web - Aperçu

Ce tutoriel en 6 parties vous montrera comment construire à partir de zéro une application de production multi-serveur. La configuration finale sera prise en charge par des systèmes de sauvegarde, de surveillance et de journalisation centralisée, ce qui vous aidera à vous assurer que vous serez en mesure de détecter les problèmes et de les récupérer. L’objectif ultime de cette série est de développer des concepts d’administration système autonomes et de vous présenter certaines des considérations pratiques liées à la création d’une configuration de serveur de production.

Si vous souhaitez revoir certains des concepts qui seront abordés dans cette série, lisez ces tutoriels:

Bien que les articles liés fournissent des instructions générales sur la configuration d’une application de production, cette série montrera comment planifier et configurer un exemple d’application du début à la fin. J’espère que cela vous aidera à planifier et à mettre en œuvre votre propre environnement de serveur de production, même si vous exécutez une application différente sur une pile technologique complètement différente. Étant donné que ce didacticiel couvre de nombreux sujets relatifs à l’administration système, il explique souvent que l’explication détaillée est renvoyée aux articles de support externes fournissant des informations supplémentaires.

À la fin de cet ensemble de didacticiels, nous aurons une configuration de serveur de production pour une application PHP, WordPress à des fins de démonstration, accessible via https://www.example.com/. Nous allons également inclure les serveurs qui prendront en charge les serveurs d’applications de production. La configuration finale ressemblera à quelque chose comme ça (DNS privé et sauvegardes à distance non illustrées):

image: https: //assets.digitalocean.com/articles/architecture/production/lamp/final.png [Configuration de la production]

Dans cette configuration, les serveurs de la zone * Application * sont considérés comme essentiels au bon fonctionnement de l’application. Outre le plan de récupération et le serveur de sauvegarde distant, les composants restants (sauvegardes, surveillance et journalisation) seront ajoutés pour prendre en charge la configuration de l’application de production. Chaque composant sera installé sur un serveur Ubuntu 14.04 distinct dans la même région DigitalOcean, NYC3 dans notre exemple, avec la mise en réseau privée activée.

L’ensemble des serveurs qui composent l’application sera appelé les noms d’hôte suivants:

Il est important de noter que ce type d’installation a été choisi pour montrer comment les composants d’une application peuvent être générés sur plusieurs serveurs. votre propre configuration doit être personnalisée en fonction de vos propres besoins. Cette configuration de serveur particulière a des points d’échec uniques qui pourraient être éliminés en ajoutant un autre équilibreur de charge (et https://www.digitalocean.com/community/tutorials/how-to-configure-dns-round-robin-load-balancing- pour-haute-disponibilité [DNS round-robin]) et déservation serveur de base de données ou en ajoutant un IP statique qui pointe vers un équilibreur de charge actif ou passif qui est couvert ci-dessous et que nous couvrirons brièvement.

Les composants qui prendront en charge les serveurs d’applications seront appelés noms d’hôtes suivants:

De plus, les trois composants de support suivants ne sont pas illustrés dans le diagramme:

Nous allons également développer des plans de reprise pour les pannes dans les différentes composantes de l’application.

Lorsque nous aurons atteint notre objectif, nous aurons un total de 10 serveurs. Nous les créerons tous en même temps (cela simplifiera des choses telles que la configuration de DNS), mais n’hésitez pas à les créer au besoin. Si vous envisagez d’utiliser des sauvegardes DigitalOcean comme solution de sauvegarde, en plus ou au lieu de Bacula, veillez à sélectionner cette option lors de la création de vos gouttelettes.

Chaque serveur Ubuntu 14.04 devrait avoir un superutilisateur non root, qui peut être configuré en suivant ce tutoriel: https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-14-04 [ Configuration initiale du serveur avec Ubuntu 14.04]. Toutes les commandes seront exécutées sous cet utilisateur, sur chaque serveur.

Nous supposerons que vous avez une certaine connaissance des concepts de base de la sécurité Linux, que nous ne traiterons pas en détail. Si vous avez besoin d’une introduction rapide à la sécurité Linux, lisez cet article: 7 Mesures de sécurité pour protéger vos serveurs.

Maintenant que nous avons un aperçu de la configuration de nos applications de production, créons un plan général pour atteindre notre objectif.

Les composants qui composent l’application sont les plus importants. Nous voulons donc que ceux-ci soient opérationnels tôt. Cependant, comme nous prévoyons d’utiliser la résolution d’adresse basée sur le nom de nos connexions de réseau privé, * nous devrions configurer notre DNS en premier *.

Une fois que notre DNS est prêt, afin de rendre les choses opérationnelles, nous allons configurer les serveurs qui composent l’application. Comme la base de données est requise par l’application et que l’application est requise par l’équilibreur de charge, nous allons configurer les composants dans cet ordre:

Une fois les étapes de configuration de notre application terminées, nous pourrons élaborer un * plan de récupération * pour différents scénarios. Ce plan sera utile pour déterminer notre stratégie de sauvegarde.

Une fois que nous aurons nos différents plans de récupération, nous voudrons le supporter en mettant en place des * sauvegardes *. Suite à cela, nous pouvons configurer * monitoring * pour nous assurer que nos serveurs et services sont dans un état OK. Enfin, nous allons configurer la * journalisation centralisée * afin de pouvoir nous aider à afficher nos journaux, à résoudre les problèmes et à identifier les tendances.

Notre plan général étant prêt, nous sommes prêts à implémenter la configuration de notre application de production. N’oubliez pas que cette configuration, bien que totalement fonctionnelle, est un exemple à partir duquel vous devriez pouvoir obtenir des informations utiles et utiliser ce que vous avez appris pour améliorer la configuration de votre propre application.

Passez au prochain didacticiel pour commencer à configurer l’application: Construction pour la production: applications Web - Déploiement.