Déployer Apache Tomcat connecté au service MySQL Database
MySQL Database Service est un service natif Oracle Cloud Infrastructure entièrement géré. Il est développé, géré et pris en charge par l'équipe MySQL d'Oracle. Les tâches telles que la sauvegarde et la récupération, l'application de patches à la base de données et au système d'exploitation, etc. , sont automatisées. Vous êtes seul responsable de la gestion de vos données, de vos conceptions de schéma et de vos stratégies d'accès.
Architecture
L'architecture de référence contient un équilibreur de charge, un niveau d'application avec Apache Tomcat et un niveau de base de données avec un service MySQL Database compatible HA.
Les composants sont situés dans différents sous-réseaux. L'équilibreur de charge se trouve dans un sous-réseau public. Les serveurs Tomcat partagent un sous-réseau privé et la base de données se trouve dans son propre sous-réseau privé. Tout accès externe passe par l'équilibreur de charge via une passerelle Internet.
Le service MySQL Database compatible HA est une abstraction d'un cluster. Il comporte trois instances MySQL mais avec une seule adresse. Une instance est le Primaire et les deux autres instances sont les Secondaires. L'adresse principale est unique, permettant des lectures et des écritures dans la base de données. Les Secondaires reçoivent des données répliquées du Primaire. Aucun accès direct n'est autorisé aux secondaire.
En cas de panne ou de basculement manuel, l'un des Secondaires devient le nouveau Primaire et l'adresse lui est redirigée. Cela signifie que l'adresse IP endpoint ne change jamais et qu'il n'est pas nécessaire de mettre à jour l'application.
Un exemple d'application qui affiche la gestion des sessions d'application à l'aide de la base de données est inclus.
Le diagramme suivant illustre cette architecture de référence.
Description de l'illustration architecture-deploy-tomcat-mds-ha.png
architecture-deploy-tomcat-mds-oracle.zip
Si le sous-réseau est régional, les trois instances MySQL sont placées dans différents domaines de disponibilité et domaines de pannes. Dans les régions dotées d'un seul domaine de disponibilité, les instances MySQL sont placées dans différents domaines de pannes dans le même domaine de disponibilité.
L'architecture comporte les composants suivants :
- Région
Une région Oracle Cloud Infrastructure est une zone géographique localisée qui contient un ou plusieurs centres de données, appelés domaines de disponibilité. Les régions sont indépendantes des autres régions et de vastes distances peuvent les séparer (d'un pays à l'autre ou même d'un continent à l'autre).
- Domaines de disponibilité
Les domaines de disponibilité sont des centres de données autonomes et indépendants au sein d'une région. Les ressources physiques de chaque domaine de disponibilité sont isolées des ressources des autres domaines de disponibilité, ce qui permet de tolérer les pannes. Les domaines de disponibilité ne partagent pas d'infrastructure comme l'alimentation ou le refroidissement, ou le réseau de domaine de disponibilité interne. Il est donc peu probable qu'un échec dans un domaine de disponibilité affecte les autres domaines de disponibilité de la région.
- Domaines d'erreur
Un domaine de panne est un regroupement de matériel et d'infrastructure au sein d'un domaine de disponibilité. Chaque domaine de disponibilité dispose de trois domaines de pannes dotés d'une alimentation et d'un matériel indépendants. Lorsque vous distribuez des ressources dans plusieurs domaines de pannes, vos applications peuvent tolérer la panne du serveur physique, la maintenance du système et les pannes d'alimentation dans un domaine de panne.
- Réseau cloud virtuel (VCN) et sous-réseaux
Un VCN est un réseau personnalisable défini par logiciel que vous configurez dans une région Oracle Cloud Infrastructure. Comme les réseaux de centre de données traditionnels, les réseaux cloud virtuels vous donnent un contrôle total sur votre environnement réseau. Un VCN peut contenir plusieurs blocs CIDR qui ne se chevauchent pas et que vous pouvez modifier après avoir créé le VCN. Vous pouvez segmenter un VCN en sous-réseaux, qui peuvent être ciblés sur une région ou sur un domaine de disponibilité. Chaque sous-réseau se compose d'une plage d'adresses contiguës qui ne chevauchent pas les autres sous-réseaux du VCN. Vous pouvez modifier la taille d'un sous-réseau après sa création. Un sous-réseau peut être public ou privé.
- Balanceur de charge
Le service Oracle Cloud Infrastructure Load Balancing fournit une distribution automatisée du trafic à partir d'un point d'entrée unique vers plusieurs serveurs dans le back-end.
- Liste de sécurité
Pour chaque sous-réseau, vous pouvez créer des règles de sécurité qui spécifient la source, la destination et le type de trafic qui doivent être autorisés dans et hors du sous-réseau.
- Table de routage
Les tables de routage virtuelles contiennent des règles pour acheminer le trafic de sous-réseaux vers des destinations en dehors d'un VCN, généralement via des passerelles.
- Passerelle Internet
La passerelle Internet permet le trafic entre les sous-réseaux publics dans un VCN et Internet public.
- Serveurs Tomcat
Les serveurs Tomcat hébergent Java Servlet, JavaServer Pages, Java Expression Language et Java WebSockets. Vos applications existent dans cette couche.
- Serveurs de base de données
Tomcat peut se connecter à toute base de données offrant une connectivité de base de données Java (JDBC). Cette architecture utilise MySQL Database Service.
- Bastion host
L'hôte bastion est une instance de calcul qui sert de point d'entrée sécurisé et contrôlé vers la topologie depuis l'extérieur du nuage. L'hôte du bastion est généralement provisionné dans une zone démilitarisée (DMZ). Il vous permet de protéger les ressources sensibles en les plaçant dans des réseaux privés auxquels vous ne pouvez pas accéder directement depuis l'extérieur du cloud. La topologie dispose d'un seul point d'entrée connu que vous pouvez surveiller et auditer régulièrement. Ainsi, vous pouvez éviter d'exposer les composants les plus sensibles de la topologie sans compromettre leur accès.
Recommandations
Vos exigences peuvent différer de l'architecture décrite ici. Utilisez les recommandations suivantes comme point de départ.
- VCN
Lorsque vous créez un VCN, déterminez le nombre de blocs CIDR requis et la taille de chaque bloc en fonction du nombre de ressources que vous prévoyez d'attacher aux sous-réseaux du VCN. Utilisez des blocs CIDR se trouvant dans l'espace d'adresses IP privées standard.
Sélectionnez les blocs CIDR qui ne chevauchent aucun autre réseau (dans Oracle Cloud Infrastructure, votre centre de données sur site ou un autre fournisseur cloud) sur lequel vous comptez configurer des connexions privées.
Après avoir créé un VCN, vous pouvez modifier, ajouter et enlever ses blocs CIDR.
Lorsque vous concevez les sous-réseaux, tenez compte de vos besoins en matière de flux de trafic et de sécurité. Attachez toutes les ressources d'un niveau ou d'un rôle spécifique au même sous-réseau, qui peut servir de limite de sécurité.
- Balanceur de charge
Cette architecture utilise un équilibreur de charge de 10 Mbps inclus dans le niveau Toujours libre. En fonction du nombre de connexions simultanées nécessaires et du débit total, vous pouvez utiliser des formes plus grandes. Le débit peut être modifié à tout moment.
Nous vous recommandons d'utiliser des noms DNS car l'adresse IP de l'équilibreur de charge ne peut pas être réservée.
- Instances
Toutes les locations obtiennent deux instances de machine virtuelle toujours libre (VM), que cette architecture utilise pour les serveurs Tomcat.
Si plus de puissance de traitement est nécessaire, vous pouvez sélectionner différentes formes.
- Systèmes de base de données
Connexion à MySQL : installez le dernier client MySQL et installez également MySQL Shell à partir du référentiel Yum MySQL. Reportez-vous à la section Plus d'informations pour obtenir un lien vers l'utilisation du référentiel Yum MySQL.
- Stockage
Les instances de cette architecture utilisent un stockage de blocs standard ; aucune performance supplémentaire n'est requise.
- Connectivité réseau
Vous pouvez gérer l'environnement en vous connectant à votre infrastructure sur site existante à l'aide d'un VPN site à site ou d'une connexion dédiée à FastConnect.
Si l'environnement doit être séparé de l'infrastructure existante ou accessible à l'extérieur, un hôte bastion peut sécuriser les connexions de gestion. L'hôte du bastion est généralement provisionné dans une zone démilitarisée (DMZ). Il protège les ressources sensibles en les plaçant dans des réseaux privés qui ne peuvent pas être accessibles directement depuis l'extérieur du cloud. Vous pouvez éviter d'exposer les composants les plus sensibles de l'architecture sans compromettre leur accès.
Remarques
Prenez en compte les points suivants lors du déploiement de cette architecture de référence.
- Performances
Vous pouvez ajuster les performances en fonction des besoins propres à l'application en modifiant les formes d'instance (si vous utilisez la série Intel), ou OCPU et mémoire séparément (si vous utilisez la série AMD).
L'instance de base de données ne peut pas être modifiée pour le moment. Choisissez la taille appropriée lorsque vous la créez.
- Sécurité
À l'exception de l'hôte du bastion (le cas échéant) et des équilibreurs de charge, tous les composants doivent être placés dans des sous-réseaux privés.
Si une sécurité rigoureuse est requise, envisagez de profiter des zones de sécurité Oracle. Il est inclus sans frais supplémentaires.
- Disponibilité
L'équilibreur de charge est livré avec une instance de secours et ne nécessite aucune intervention en cas de basculement.
Les serveurs Tomcat sont déployés en couple et sont équilibrés par l'équilibreur de charge. Chaque instance Tomcat est située dans un domaine d'erreur différent.
Sauvegardez votre base de données aussi souvent que nécessaire pour correspondre à votre objectif de point de récupération (RPO) prévu.
Bien que peu fréquent, ajustez la fenêtre de maintenance de MySQL Database Service pour qu'elle corresponde aux besoins de votre organisation.
- Coût
Le coût de cette architecture change en fonction de la taille et des formes des instances, de la base de données et des équilibreurs de charge. Il n'y a pas de composants avec des coûts variables.
Déployer
Le code requis pour déployer cette architecture de référence est disponible dans GitHub. Vous pouvez extraire le code dans Oracle Cloud Infrastructure Resource Manager en un seul clic, créer la pile et le déployer. Vous pouvez également télécharger le code à partir de GitHub vers votre ordinateur, personnaliser le code et déployer l'architecture à l'aide de la CLI Terraform.
- Déployer à l'aide d'Oracle Cloud Infrastructure Resource Manager :
- Cliquezsur
Si vous n'êtes pas déjà connecté, entrez les informations d'identification de location et d'utilisateur.
- Examinez et acceptez les conditions générales.
- Sélectionnez la région dans laquelle vous souhaitez déployer la pile.
- Suivez les invites à l'écran et les instructions pour créer la pile.
- Après avoir créé la pile, cliquez sur Actions Terraform et sélectionnez Plan.
- Attendez que le travail soit terminé et examinez le plan.
Pour apporter des modifications, revenez à la page Détails de la pile, cliquez sur Modifier la pile et apportez les modifications requises. Ensuite, relancez l'action Plan.
- Si aucune autre modification n'est nécessaire, revenez à la page Détails de la pile, cliquez sur Actions Terraform et sélectionnez Appliquer.
- Cliquezsur
- Déployer à l'aide du code Terraform dans GitHub :
- Accédez à GitHub.
- Cloner ou télécharger le référentiel sur votre ordinateur local.
- Suivez les instructions du document
README.
Plus d'informations
- Créer un cluster Tomcat avec persistance de session MySQL
- Utilisation de JDBCStore pour la persistance de session
- Démarrage du service MySQL Database
- Guide rapide sur l'utilisation du référentiel MySQL Yum (pour mettre à jour le client MySQL et installer MySQL Shell)
Journal des modifications
Ce journal répertorie uniquement les modifications importantes :
| 24 février 2022 |
|
| 7 janvier 2021 | Instructions supplémentaires pour le déploiement de l'architecture à l'aide d'Oracle Cloud Infrastructure Resource Manager. |