Docker Java Application Avec Solr, Mongo, & Cassandra: Conception, déploiement, service de découverte, et de gestion de production
Vous pouvez cloner cet exemple d'application Java "Répertoire des noms" de GitHub.
Un guide étape par étape pour Dockerizing et gérer une application Java comprenant:
- Apache HTTP Server (httpd) et Nginx ( pour l' équilibrage de charge )
- JBoss , Tomcat et Jetty ( comme le serveur d'application )
- Solr ( pour la recherche de texte intégral )
- Mongo , Cassandra , MySQL et Oracle ( pour la base de données )
Ceci est une extension de ce projet ( https://github.com/dchqinc/dchq-docker-java-example ). L'application supporte maintenant Solr pour la recherche en texte intégral et à la fois Mongo & Cassandra comme les bases de données prises en charge.
Pour exécuter et gérer les 24 Java modèles d'application dans ce projet sur les plates - formes de virtualisation (y compris vSphere, OpenStack, AWS, Rackspace, Microsoft Azure, Google Compute Engine, Digital Ocean , IBM SoftLayer, etc.) 13 différents nuages et, assurez - vous que vous soit :
Contexte
Conteneurisation applications Java d'entreprise est encore un défi surtout parce que les cadres de composition d'applications existantes ne traitent pas des dépendances complexes, intégrations externes ou auto-mise à l'échelle des flux de production post-prestation. En outre, la conception éphémère des conteneurs signifie que les développeurs ont dû faire tourner de nouveaux conteneurs et recréer les dépendances complexes et intégrations externes avec chaque mise à jour de version.
DCHQ, disponible en versions hébergées et sur site, répond à tous ces défis et simplifie la conteneurisation des applications Java d'entreprise grâce à un cadre de composition d'application avance qui étend Docker Compose avec l'environnement inter-images variables reliures, les plug-ins de script BASH extensible qui peut être invoqué au moment de la demande ou de post-disposition, et le regroupement de l'application pour la haute disponibilité sur plusieurs hôtes ou régions avec le soutien de mise à l'échelle automatique.
Une fois qu'une demande est provisionnée, un utilisateur peut surveiller le CPU, la mémoire, et I / O des conteneurs de fonctionnement, recevoir des notifications et alertes, et avoir accès à des sauvegardes d'application, à l'échelle automatique dans / sur les flux de travail, et plug-in workflows d'exécution à mettre à jour en cours d'exécution des conteneurs. De plus, les flux de travail hors-of-box qui facilitent la livraison continue avec Jenkins permettent aux développeurs d'actualiser le fichier WAR Java d'une application en cours d'exécution sans perturber les dépendances et les intégrations existantes.
Dans les blogs précédents, nous avons démontré l'automatisation des différentes applications Java (comme Pizza Shop et Movie Store applications) sur des piles d'applications à base de Docker multi-niveaux de 13 à travers différents nuages et plates - formes de virtualisation de bout en bout le déploiement. Pour la liste complète de ces blogs, vous pouvez visiter cette page: http://dchq.co/docker-java-applications.html
Cependant, de nombreux utilisateurs ont été encore confus sur certains des aspects fondamentaux de la modélisation de l'application. Ces questions comprennent:
- D' où viennent ces variables d'environnement proviennent dans votre modèle d'application YAML-?
- Comment est la base de données initialisée avec les schémas appropriés nécessaires à partir de mon application Java?
- Je possède déjà un plan de déploiement pour mon serveur d' applications WebLogic. Puis - je utiliser mon propre script pour déployer une application Java?
Pour répondre à ces questions, nous avons créé un exemple d'application Java "Répertoire des noms" dans ce projet GitHub qui peut être déployée sur ces piles d'applications:
- Apache HTTP Server (httpd) et Nginx (pour l'équilibrage de charge)
- JBoss, Tomcat et Jetty (comme le serveur d'application)
- Solr (pour la recherche de texte intégral)
- Mongo, Cassandra, MySQL et Oracle (pour la base de données)
Dans ce projet, nous fournirons un guide étape par étape pour la configuration, le déploiement et la gestion de cette application Java en utilisant différentes piles d'applications et sur différents cloud / infrastructure virtuelle.
Nous allons couvrir:
- Configuration des fichiers Java pour les variables d'environnement de connexion base de données et Solr
- Utilisation de la fève liquibase pour initialiser la base de données connectée
- Construire les modèles d'application à base de YAML qui peuvent ré-utilisés sur un hôte Linux en cours d'exécution partout
- Provisioning et auto-mise à l'échelle de l'infrastructure sous-jacente sur un nuage (avec Rackspace étant l'exemple dans ce blog)
- Déploiement du multi-tier application Java sur le cluster Rackspace
- Suivi de la CPU, la mémoire et d'E / S des conteneurs en cours
- Activation du flux de travail de livraison continue avec Jenkins pour mettre à jour le fichier WAR des applications en cours d'exécution lorsqu'une construction est déclenchée
- Mise à l'échelle sur le cluster de serveurs d'application lorsque l'application est ressources limitées en utilisant le cadre Discovery Service pour mettre à jour le service d'équilibrage de charge
Configuration des fichiers Java Pour Base de données et Solr Variables Connection Environnement
Vous pouvez cloner cet exemple d'application Java "Répertoire des noms" de GitHub.
Ceci est l'étape la plus importante dans votre application Java "Dockerizing". Afin de tirer parti des variables d'environnement, vous pouvez passer lors de l'exécution des conteneurs, vous devez vous assurer que votre application est configurée d'une manière qui vous permettra de modifier certaines propriétés à la demande du temps - comme:
- Le port Solr URL et que vous souhaitez utiliser
- Le pilote de base de données que vous souhaitez utiliser
- L'URL de base de données
- Les informations d'identification de base de données
- Tous les autres paramètres que vous souhaitez modifier à la demande du temps (par exemple, le min / max taille du pool de connexion, le délai d'inactivité, etc.)
Pour ce faire, nous avons créé plusieurs fichiers Java pour déclarer les variables d'environnement, nous devons utiliser pour se connecter à la base de données et Solr. Les fichiers Java peuvent être trouvés dans le répertoire config:
Laissez ce premier examine SolrConfig.java : https://github.com/dchqinc/dchq-docker-java-solr-mongo-cassandra-example/blob/master/src/main/java/dchq/dbconnect/config/SolrConfig.java
Vous remarquerez que solr_host et solr_port sont déclarés comme des variables d'environnement que vous pouvez passer lors de l' exécution du conteneur du serveur d'applications.
Maintenant , nous allons examine DatabaseConfig.java : https://github.com/dchqinc/dchq-docker-java-solr-mongo-cassandra-example/blob/master/src/main/java/dchq/dbconnect/config/DatabaseConfig.java
Vous remarquerez que database_driverClassName , database_url , nom_utilisateur_bdd et database_password sont déclarés comme des variables d'environnement que vous pouvez passer lors de l' exécution du conteneur du serveur d'applications. Ceux - ci seront utilisés pour connecter les bases de données MySQL, PostgreSQL et Oracle.
Ensuite, nous allons examine MongoConfig.java : https://github.com/dchqinc/dchq-docker-java-solr-mongo-cassandra-example/blob/master/src/main/java/dchq/dbconnect/config/MongoConfig.java
Vous remarquerez que mongo_url est déclarée comme variables d'environnement que vous pouvez passer lors de l' exécution du conteneur du serveur d'applications.
Cependant, le MongoConfig.java est également utilisé pour remplir la base de données avec le droit schema & table au démarrage - si cette table est pas déjà trouvé.
Enfin, nous allons examine CassandraConfig.java : https://github.com/dchqinc/dchq-docker-java-solr-mongo-cassandra-example/blob/master/src/main/java/dchq/dbconnect/config/CassandraConfig.java
Vous remarquerez que cassandra_url est déclarée comme variables d'environnement que vous pouvez passer lors de l' exécution du conteneur du serveur d'applications.
Utilisation du Liquibase Bean pour initialiser le MySQL, PostgreSQL et Oracle bases de données connectées
Nous recommandons généralement d'initialiser le schéma de base de données dans le cadre du déploiement des applications Java lui-même. De cette façon, vous n'avez pas à vous soucier de la tenue des dossiers SQL distinctes qui doivent être exécutées sur la base de données séparément.
Toutefois , si vous avez déjà ces fichiers SQL et vous préférez toujours les exécuter sur la base de données séparément - puis DCHQ peut vous aider à automatiser ce processus grâce à son cadre de plug-in. Vous pouvez consulter cette section pour plus d' informations.
Initialisation des bases de données mongo et Cassandra est couvert dans les fichiers MongoConfig.java et CassandraConfig.java.
Pour MySQL, PostgreSQL et Oracle, la liquibase bean est utilisé dans le fichier DatabaseConfig.java pour vérifier l'dataSource et exécuter des instructions SQL de Upgrade.sql. Pistes Liquibase dont les états de changelog ont dirigées contre chaque base de données.
Voici le fichier Upgrade.sql réelle avec les instructions SQL pour initialiser le schéma sur la base de données MySQL, PostgreSQL ou Oracle connecté.
Construire Les modèles d'application YAML-Based qui peut re-utilisé sur tout hôte Linux Exécution Partout
Une fois connecté à DCHQ (soit le DCHQ.io hébergé ou la version sur site), un utilisateur peut accéder à App & Machine , puis cliquez sur le + bouton pour créer une nouvelle Docker Compose modèle.
Nous avons créé 24 modèles d'application en utilisant les images officielles de Docker Hub pour la même application Java "Répertoire des noms" - mais pour les serveurs et les bases de données d'applications différentes.
Les modèles comprennent des exemples de piles d'applications suivantes (pour la même application Java):
- Apache HTTP Server (httpd) & Nginx - pour l' équilibrage de charge
- Solr - pour la recherche de texte intégral
- Tomcat, Jetty, et JBoss - pour les serveurs d'applications
- Mongo, Cassandra, MySQL et Oracle XE - pour les bases de données
Plug-Ins Pour configurer les serveurs Web et les serveurs d'applications à la demande Time & Post-Provision
Dans tous ces modèles d'application, vous remarquerez que certains des conteneurs invoquez plug-ins de script BASH à la demande de temps pour configurer le conteneur. Ces plug-ins peuvent être exécutées après disposition ainsi.
Ces plug-ins peuvent être créés en naviguant dans Plug-ins . Une fois le script BASH est fourni, l'agent DCHQ exécutera ce script à l' intérieur du conteneur . Un utilisateur peut spécifier des arguments qui peuvent être redéfinies au moment de la demande et post-disposition. Tout précédé par le $ signe est considéré comme un argument - par exemple, $ FILE_URL peut être un argument qui permet aux développeurs de spécifier l'URL de téléchargement d' un fichier WAR. Cela peut être remplacé au moment de la demande et post-disposition lorsqu'un utilisateur veut actualiser le fichier Java WAR sur un conteneur en cours d' exécution.
Le plug-in ID doit être fourni lors de la définition du modèle d'application basée sur YAML. Par exemple, pour invoquer un plug-in de script bash pour Nginx, nous référencer le plug-in ID comme suit:
Dans les exemples de modèles, nous invoquons 4 BASH plug-ins de script.
Nginx invoque un plug-in de script BASH qui injecte conteneur IP des serveurs d'applications dans le fichier default.conf dynamiquement (ou à la demande du temps). Le plug-in ID est 0H1Nk .
Apache HTTP Server (httpd) invoque un script BASH plug-in qui injecte conteneur IP des serveurs d'applications dans le fichier httpd.conf dynamiquement (ou à la demande du temps). Le plug-in ID est uazUi .
La beauté du serveur Nginx et Apache HTTP (httpd) plug-ins est qu'ils peuvent être exécutés après disposition dans le cadre de l'échelle de la grappe de serveurs d'applications ou échelle sur. Cela permet de définir des politiques auto-échelle qui mettent à jour automatiquement le serveur Web (ou équilibreur de charge). Cela fait partie de DCHQ de service de découverte du cadre.
Découverte de service avec des étapes du cycle de vie Plug-In
Le cycle de vie paramètre dans les plug-ins vous permet de spécifier le stade exact ou un événement pour exécuter le plug-in. Sinon cycle de vie est spécifié, par défaut, le plug-in sera exécuter on_create . Voici les étapes du cycle de vie pris en charge:
- on_create - exécute le plug-in lors de la création du conteneur
- on_start - exécute le plug-in après un conteneur commence
- on_stop - exécute le plug-in avant un conteneur arrêts
- on_destroy - exécute le plug-in avant de détruire un récipient
- post_create - exécute le plug-in après que le conteneur est créé et en cours d' exécution
- post_start [Node] - exécute le plug-in après un autre récipient commence
- post_stop [Node] - exécute le plug-in après un autre récipient arrêts
- post_destroy [Node] - exécute le plug-in après un autre conteneur est détruit
- post_scale_out [Node] - exécute le plug-in après un autre groupe de conteneurs est mise à l' échelle des
- post_scale_in [Node] - exécute le plug-in après un autre groupe de conteneurs est gradué en
Pour obtenir un accès au serveur Nginx et Apache HTTP (httpd) plug-ins sous la licence EULA, assurez-vous soit:
Les serveurs d'applications (Tomcat, Jetty, et JBoss) sont également invoquaient un plug-in de script BASH pour déployer le fichier Java WAR de l'accès GitHub URL.
Tomcat, JBoss et Jetty invoquent le plug-in exact script BASH même (plug-in ID: oncXN ) - à l' exception du fichier WAR est de se déployer sur des répertoires différents:
- Tomcat - dir = / usr / local / tomcat / webapps / ROOT.war
- Jetty - dir = / var / lib / Jetée / webapps / ROOT.war
- JBoss - dir = / opt / jboss / JBoss / standalone / déploiements / ROOT.war
Solr invoque un plug-in de script BASH différent (plug-in ID: doX8s ) qui va obtenir le fichier names.zip et décompressez - le dans / opt / Solr / server / Solr /
CLUSTER_SIZE Et hôte Paramètres Pour HA déploiement sur plusieurs hôtes
Vous remarquerez que le CLUSTER_SIZE paramètre vous permet de spécifier le nombre de conteneurs à lancer (avec les mêmes dépendances d'application).
L' hôte paramètre vous permet de spécifier l'hôte que vous souhaitez utiliser pour les déploiements de conteneurs. Cela est possible si vous avez sélectionné Weave comme couche de réseau lors de la création de vos clusters. De cette façon , vous pouvez vous assurer de haute disponibilité pour vos applications les clusters de serveurs à travers différents hôtes (ou régions) et vous pouvez respecter les règles d'affinité pour garantir que la base de données fonctionne sur un hôte séparé par exemple. Voici les valeurs prises en charge pour le paramètre hôte:
- host1, host2, host3 , etc. - sélectionne un hôte au hasard dans un centre de données (ou cluster) pour les déploiements de conteneurs
- Adresse IP 1, IP Address 2, etc. - permet à un utilisateur de spécifier les adresses IP réelles à utiliser pour les déploiements de conteneurs
- Hostname 1, Hostname 2, etc. - permet à un utilisateur de spécifier les hostnames réelles à utiliser pour les déploiements de conteneurs
- Wildcards (par exemple "db- ", ou "app-SRV ") - pour spécifier les caractères génériques pour utiliser dans un nom d' hôte
Environnement Bindings variable à travers les images
En outre, un utilisateur peut créer cross-images reliures de variables d'environnement en faisant une référence à la variable d'environnement d'une autre image. Dans ce cas, nous avons fait plusieurs - Dans laquelle le nom du conteneur de base de données est réglée de façon dynamique à la demande du temps et est utilisé pour faire en sorte que les serveurs d'application peut établir une connexion avec la base de données.
Voici une liste de valeurs de variables d'environnement pris en charge:
- {{alphanumérique | 8}} - crée un 8 caractères chaîne alphanumérique aléatoire. Ceci est très utile pour créer des mots de passe aléatoires.
- {{Image Name | ip}} - vous permet d'entrer l'adresse IP de l' hôte d'un conteneur en tant que valeur pour une variable d'environnement. Ceci est très utile pour permettre à la couche de middleware pour établir une connexion avec la base de données.
- {{Image Name | container_ip}} - vous permet d'entrer le nom d'un conteneur en tant que valeur pour une variable d'environnement. Ceci est très utile pour permettre à la couche de middleware pour établir une connexion sécurisée avec la base de données (sans exposer le port de base de données).
- {{Image Name | container_private_ip}} - vous permet d'entrer l'adresse IP interne d'un conteneur en tant que valeur pour une variable d'environnement. Ceci est très utile pour permettre à la couche de middleware pour établir une connexion sécurisée avec la base de données (sans exposer le port de base de données).
- {{Image Name | port_Port Number}} - vous permet d'entrer le numéro de port d'un conteneur en tant que valeur pour une variable d'environnement. Ceci est très utile pour permettre à la couche de middleware pour établir une connexion avec la base de données. Dans ce cas, le numéro de port spécifié doit être le numéro de port interne - à savoir ne pas le port externe qui est alloué au conteneur. Par exemple, {{PostgreSQL | port_5432}} sera traduit au port externe réelle qui permettra au niveau de middleware pour établir une connexion avec la base de données.
- {{Image Name | Environment Variable Name}} - vous permet d'entrer la valeur de la variable d'environnement d'une image dans la variable d'environnement d' une autre image. Les cas d'utilisation sont infinies - comme la plupart des applications multi-niveaux auront des dépendances inter-image.
Voici quatre exemples. Vous pouvez trouver personnaliser et exécuter tous les 24 modèles vous.
Multi-Tier Java (Nginx-Tomcat-Solr-Mongo)
Multi-Tier Java (Nginx-JBoss-Solr-Oracle-XE)
Multi-Tier Java (ApacheLB-Tomcat-Solr-Cassandra)
Multi-Tier Java (ApacheLB-Jetty-Solr-Mongo)
Provisioning & Auto-échelle L'infrastructure sous-jacent un Nuage
Une fois qu'une demande est enregistrée, un utilisateur peut enregistrer un fournisseur de Cloud pour automatiser le provisionnement et l'auto-mise à l'échelle des grappes sur 12 nuage points terminaux différents, y compris VMware vSphere, OpenStack, CloudStack, Amazon Web Services, Rackspace, Microsoft Azure, Digital Ocean, IBM SoftLayer, Google Compute Engine, et bien d'autres.
Tout d' abord, un utilisateur peut enregistrer un fournisseur de Cloud pour Rackspace (par exemple) en naviguant sur les fournisseurs de Cloud , puis en cliquant sur le + bouton pour sélectionner Rackspace . L'API Key Rackspace doit être fournie - qui peut être récupéré à partir de la section Paramètres du compte du panneau de configuration Rackspace Cloud.
Un utilisateur peut alors créer un cluster avec une politique d' auto-échelle pour faire tourner automatiquement les nouveaux serveurs de Cloud. Cela peut être fait en accédant à Clusters page, puis en cliquant sur le + bouton. Vous pouvez sélectionner une stratégie de placement fondée sur la capacité et ensuite Weave que la couche réseau afin de faciliter, la communication inter-conteneur protégé par mot de passe sécurisé sur plusieurs hôtes dans un cluster. La politique d' auto-échelle , par exemple, peut fixer le nombre maximum de VM (ou les serveurs de Cloud) à 10.
Un utilisateur peut maintenant fournir un certain nombre de serveurs de Cloud sur le cluster nouvellement créé soit par le biais du flux de travail basée sur interface utilisateur ou en définissant un modèle de machine de composition à base de YAML-simple qui peut être demandé à la Bibliothèque Self-Service.
Flux de travail basé sur l' interface utilisateur - Un utilisateur peut demander des serveurs Rackspace Cloud en naviguant vers Machines et puis en cliquant sur le + bouton pour sélectionner Rackspace . Une fois que le fournisseur de Cloud est sélectionné, l'utilisateur peut sélectionner la région, la taille et l' image nécessaire. Les ports sont ouverts par défaut sur les serveurs Rackspace Cloud pour accueillir certaines des exigences de ports (par exemple 32000-59000 pour Docker, 6783 pour Weave, et 5672 pour RabbitMQ). Un cluster est alors sélectionné et le nombre de serveurs de Cloud peut être spécifié.
Machine Compose modèle basé sur YAML - Un utilisateur peut d' abord créer un modèle de machine Compose pour Rackspace en naviguant vers Machines et cliquez sur + bouton, puis sélectionnez la machine Compose .
Voici le modèle pour demander un serveur 4GB Cloud.
Les paramètres pris en charge pour le modèle machine Compose sont résumées ci-dessous:
- Description : Description du modèle / template
- instanceType : Cloud fournisseur valeur spécifique (par exemple general1-4)
- région : fournisseur de Cloud valeur spécifique (par exemple IAD)
- Image : Obligatoire - image ID / nom complet (par exemple IAD / 5ed162cc-b4eb-4371-b24a-a0ae73376c73 ou vSphere VM Template nom)
- nom d' utilisateur : en option - uniquement pour vSphere VM Template nom d' utilisateur
- Mot de passe : En option - uniquement pour vSphere VM Template mot de passe crypté. Vous pouvez crypter le mot de passe en utilisant le critère https://www.dchq.io/#/encrypt
- réseau : en option - Cloud fournisseur valeur spécifique (par exemple , par défaut)
- SecurityGroup : fournisseur de Cloud valeur spécifique (par exemple DCHQ-security-groupe)
- CLES : fournisseur de Cloud valeur spécifique (par exemple clé privée)
- OpenPorts : Facultatif - virgules des valeurs de port séparés
- count : nombre de VM, par défaut 1.
Une fois le modèle machine Compose est enregistré, un utilisateur peut demander cette machine du Self-Service Library . Un utilisateur peut cliquer sur Personnaliser , puis sélectionnez le fournisseur de Cloud et Cluster à utiliser pour le provisionnement de ces serveurs Rackspace Cloud.
Déploiement Le Multi-Tier Java Application sur le cluster Rackspace
Une fois les serveurs de Cloud sont provisionnés, un utilisateur peut déployer un multi-niveaux, les applications Java basées sur Docker sur les nouveaux serveurs de Cloud. Cela peut être fait en accédant à la bibliothèque libre-service, puis en cliquant sur Personnaliser pour demander une application à plusieurs niveaux.
Un utilisateur peut sélectionner une étiquette de l' environnement (comme DEV ou QE) et le Cluster Rackspace créé avant de cliquer sur Création de machines .
Accès à The In-Browser Terminal pour les conteneurs de course
Une invite icône de commande devrait être disponible à côté des noms des conteneurs sur la page Live Apps. Cela permet aux utilisateurs d'entrer dans le conteneur en utilisant un protocole de communication sécurisé grâce à la file d'attente de messages d'agent. Une liste blanche des commandes peut être défini par le locataire Admin pour veiller à ce que les utilisateurs ne font pas de changements nuisibles sur les contenants de fonctionnement.
Pour le déploiement Tomcat par exemple, nous avons utilisé l'invite de commande pour vous assurer que le fichier WAR Java a été déployée dans le cadre du / tomcat / webapps / local / usr /.
Surveillance Le CPU, mémoire et E / S Utilisation des conteneurs en cours
Une fois que l'application est en cours d'exécution, nos développeurs surveillent la CPU, la mémoire, et I / O des conteneurs en cours d'exécution pour obtenir des alertes lorsque ces mesures dépassent un seuil prédéfini. Ceci est particulièrement utile lorsque les développeurs effectuent des tests fonctionnels et de charge.
Un utilisateur peut effectuer une analyse historique de suivi et d' établir une corrélation entre les questions mises à jour de conteneurs ou de construire des déploiements. Cela peut être fait en cliquant sur le Actions menu de l'application en cours d'exécution, puis sur la surveillance . Une plage de dates personnalisée peut être sélectionnée pour afficher CPU, mémoire et E / S historiquement.
Activation du flux de travail de livraison continue Avec Jenkins mettre à jour le fichier WAR de l'application en cours Lorsque A Build est Déclenché
Pour les développeurs qui souhaitent suivre le modèle des conteneurs «immuables» par la reconstruction des images Docker contenant le code d'application et le filage de nouveaux conteneurs avec chaque mise à jour de l'application, DCHQ fournit une fonctionnalité de génération automatique qui permet aux développeurs de créer automatiquement des images Docker de Dockerfiles ou des projets privés GitHub contenant Dockerfiles.
Cependant, de nombreux développeurs peuvent souhaiter mettre à jour les conteneurs de serveur d'applications en cours d'exécution avec le fichier le dernier Java WAR place. Pour cela, DCHQ permet aux développeurs pour permettre un flux de travail de livraison continue avec Jenkins. Cela peut être fait en cliquant sur le Actions menu de l'application en cours d'exécution, puis en sélectionnant Livraison en continu . Un utilisateur peut sélectionner une instance Jenkins qui a déjà été enregistrée par DCHQ, l'emploi réel sur Jenkins qui produira fichier WAR la dernière, puis un plug-in de script BASH pour saisir cette construction et le déployer sur un serveur d'applications en cours d' exécution. Une fois que cette politique est enregistrée, DCHQ va récupérer le dernier fichier WAR de Jenkins tout moment une construction est déclenchée et le déployer sur le serveur d'applications en cours d' exécution.
Les développeurs, à la suite auront toujours le dernier fichier WAR Java déployé sur leurs conteneurs de fonctionnement dans des environnements de test / DEV.
Mise à l'échelle Out Le cluster Tomcat Application Server et de levier Le Cadre Service Discovery mettre à jour le Load Balancer
Si l'application en cours d'exécution devient ressource limitée, un utilisateur peut mettre à l'échelle sur l'application pour répondre à la charge croissante. En outre, un utilisateur peut programmer l'échelle pendant les heures d'ouverture et la balance dans le week-end par exemple.
Pour redimensionner le cluster de serveurs Tomcat 1-2, un utilisateur peut cliquer sur le Actions menu de l'application en cours d'exécution, puis sélectionnez Echelle Out . Un utilisateur peut ensuite spécifier la nouvelle taille pour le cluster, puis cliquez sur Exécuter maintenant .
Comme à l'échelle est exécutée, le cadre Discovery Service sera utilisé pour mettre à jour l'équilibreur de charge. Un plug-in sera automatiquement exécuté sur Apache HTTP Server pour mettre à jour le fichier httpd.conf d'Apache HTTP Server de sorte qu'il est au courant du nouveau serveur ajouté de l' application. Ceci est parce que nous avons spécifié post_scale_out: AppServer comme l'événement du cycle de vie pour ce plugin.
Une demande de temps en ligne est disponible pour suivre toutes les modifications apportées à la demande d'audit et de diagnostic. On peut y accéder à partir du menu extensible au bas de la page d'une application en cours d' exécution. Dans ce cas, le cadre Discovery Service exécuté le plugin Apache HTTP Server automatiquement juste après le cluster du serveur d'applications a été réduite à.
Alertes et notifications sont disponibles lorsque les conteneurs ou les hôtes sont en panne ou lorsque la CPU et utilisation de la mémoire soit des hôtes ou des conteneurs dépasse un seuil défini.
Conclusion
Conteneurisation applications Java d'entreprise est encore un défi surtout parce que les cadres de composition d'applications existantes ne traitent pas des dépendances complexes, intégrations externes ou auto-mise à l'échelle des flux de production post-prestation. En outre, la conception éphémère des conteneurs signifie que les développeurs ont dû faire tourner de nouveaux conteneurs et recréer les dépendances complexes et intégrations externes avec chaque mise à jour de version.
DCHQ, disponible en versions hébergées et sur site, répond à tous ces défis et simplifie la conteneurisation des applications Java d'entreprise grâce à un cadre de composition d'application avance qui facilite l'environnement inter-image de liaisons de variables, les plug-ins de script BASH extensibles qui peuvent être invoquées à demander le temps ou après disposition, et le regroupement de l'application pour la haute disponibilité sur plusieurs hôtes ou régions avec le soutien de mise à l'échelle automatique.
d'avoir accès à des modèles à plusieurs niveaux d'application Java out-of-box avec l'application des fonctionnalités de gestion du cycle de vie comme la surveillance, les mises à jour de conteneurs, l'échelle in / out et continue livraison.
No comments:
Post a Comment