Contexte
Les développeurs Java et les professionnels Devops ont longtemps lutté pour automatiser le déploiement des applications Java d'entreprise. La nature complexe de ces applications en général signifie que les dépendances des applications et intégrations externes devaient être reconfiguré à chaque fois qu'une application a été déployée dans les environnements de test / DEV.
De nombreuses solutions annoncées le message "modèle une fois, déployer partout" pour les déploiements d'applications. En réalité, cependant, il y avait toujours les subtilités qui ont rendu très difficile de réutiliser un modèle d'application à travers à la fois un environnement virtuel sur site vSphere et un environnement AWS, par exemple.
Plus récemment, toutefois, les conteneurs Docker popularisé l'idée de composants d'application d'emballage dans des conteneurs Linux qui peut être déployée exactement les mêmes sur tous les hôtes Linux tant que Docker Engine est installé.
conteneurisation Malheureusement applications Java d'entreprise est toujours 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 effectuer des-2 jour des opérations telles sauvegardes planifiées, mises à jour conteneur à l'aide de plug-ins de script BASH, et échelle In / Out. 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 ce blog, nous allons passer en revue l'automatisation d'une application Java appelé Pizza Shop qui est déployé sur deux piles d'applications conteneurisé différentes de bout en bout:
- Nginx (pour l' équilibrage de charge), cluster Tomcat et MariaDB (comme la base de données)
- Nginx (pour l' équilibrage de charge), cluster Jetty et MariaDB (comme la base de données)
Le même fichier WAR Java sera déployé sur deux serveurs d'applications différentes. DCHQ non seulement automatise les déploiements d'applications - mais il intègre également avec 12 nuages différents pour automatiser le provisionnement et l'auto-mise à l'échelle des clusters avec la mise en réseau définie par logiciel. Nous allons couvrir:
- Construire les modèles d'application 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 des applications multi-niveaux Pizza Shop basés sur 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 pour les tests d'évolutivité
Construire Les modèles d'application pour la pizza Application Shop Java Basé sur Tomcat Et Jetty
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éé quatre modèles d'applications utilisant les images officielles de Docker Hub pour la même application Pizza Shop - mais pour quatre serveurs d'applications différentes.
- 3-Tier PizzaShop (Nginx - Tomcat - MariaDB)
- 3-Tier PizzaShop (Nginx - Ponton - MariaDB)
À travers les deux modèles, vous remarquerez que Nginx invoque un plug-in de script BASH pour ajouter le conteneur IP des serveurs d'applications dans le fichier default.conf dynamiquement (ou à la demande du temps).
Les serveurs d'applications (Tomcat et Jetty) sont également invoquaient un plug-in de script BASH pour déployer les fichiers Pizza Shop Java WAR à partir d'une URL externe Tomcat, JBoss et Jetty sont invoquant exactement la même plug-in - sauf le fichier WAR est de se déployer sur différents répertoires:- Tomcat - dir = / usr / local / tomcat / webapps / ROOT.war
- Jetty - dir = / var / lib / Jetée / webapps / ROOT.war
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. 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 Adresse 2, etc.> - permet à un utilisateur de spécifier les adresses IP de la réelle à 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
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 fixations - y compris database.url = jdbc: mysql: // {{MariaDB | container_ip}}: 3306 / {{MariaDB | MYSQL_DATABASE}} - dans lequel le conteneur de base de données IP est résolu dynamiquement à la demande et le temps est utilisé pour s'assurer que les serveurs d'application peuvent établir une connexion avec la base de données.
Voici une liste de valeurs de variables d'environnement pris en charge:
- {{alphanumeric | 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 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.
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 OpenStack, CloudStack, Amazon Web Services, Rackspace, Microsoft Azure, Digital Ocean, HP Cloud Public, 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 Auto-Scale dans cet exemple définit 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éé en accédant à des machines , 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 peuvent être ouverts sur les nouveaux serveurs Cloud (par exemple de 32.000 à 59000 pour Docker, 6783 pour Weave, et 5672 pour RabbitMQ). Un centre de données (ou cluster) est alors sélectionné et le nombre de serveurs de Cloud peut être spécifié.
Déploiement La Pizza Application Shop Multi-Tier Java Basé 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 Run
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 de serveurs d'applications Tomcat
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 2-4, 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 .
Nous avons ensuite utilisé le plug-in de BASH mettre à jour le fichier default.conf de Nginx afin qu'il soit au courant du nouveau serveur ajouté de l'application. Les plug-ins de script BASH peuvent également être prévues pour accueillir les cas d'utilisation comme le nettoyage des journaux ou la mise à jour des configurations à des fréquences définies. Une demande de temps en ligne est disponible pour suivre toutes les modifications apportées à la demande d'audit et de diagnostic.
Pour exécuter un plug-in sur un conteneur en cours d' exécution, un utilisateur peut cliquer sur le Actions menu de l'application en cours d' exécution, puis sélectionnez Plug-ins . Un utilisateur peut alors sélectionner le conteneur d' équilibrage de charge (Nginx), rechercher le plug-in qui doit être exécuté, activez conteneur redémarrage à l' aide du bouton à bascule. L'argument par défaut de ce plug-in sera dynamiquement résoudre tous les conteneurs IP des serveurs Tomcat en cours d' exécution et les ajouter dans le cadre du fichier default.conf.
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.
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