Deployment Automation Of Docker WebLogic Cluster On Any Cloud

Automatisation du déploiement de Docker WebLogic Cluster Sur aucun nuage

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'un cluster WebLogic basé à Docker de bout en bout le déploiement. Nous allons couvrir:

• Construire le modèle d'application pour le cluster WebLogic qui peut ré-utilisé 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 cluster WebLogic sur les serveurs Rackspace Cloud
• Déploiement du Panier fichier Java WAR sur le serveur d'administration
• Accès à l'In-Browser Terminal pour l'exécution de conteneurs
• 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
• Suivi de la CPU, la mémoire et d'E / S des conteneurs en cours

Construire le modèle d'application pour le cluster Oracle WebLogic 12c

O nce connecté à DCHQ (soit le DCHQ.io hébergé ou sur site la version), un utilisateur peut accéder à App & Machine , puis cliquez sur le + bouton pour créer une nouvelle Docker Compose modèle.

Nous avons créé un modèle d'application de cluster WebLogic à l'aide d'une image personnalisée que nous avons construit misant sur l'image de Radu Dobrinescu (radudobrinescu / wls12c: 2.0).

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). Nous l' utilisons pour définir la taille de cluster de serveur géré.

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 un contraignant dans ce Caes: ADMIN_HOSTNAME = {{AdminServer | ip}} - dans laquelle l'administrateur IP de l'hôte du serveur est résolu dynamiquement à la demande du temps et est utilisé pour veiller à ce que les serveurs gérés peuvent établir une connexion avec le serveur d'administration.

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 le nom du conteneur 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.

Le bâtiment actuel de l'image Docker WebLogic peut être automatisé grâce à DCHQ ainsi. Un utilisateur peut cliquer sur l' image Construire puis cliquez sur le bouton +. Un utilisateur peut créer une image en utilisant soit un Dockerfile ou d' un projet privé / public GitHub qui a un Dockerfile.

L'image que nous créons pour WebLogic a été construit en utilisant l'image de Radu Dobrinescu (radudobrinescu / wls12c: 2.0) ( https://hub.docker.com/r/radudobrinescu/wls12c/ ). Nous avons fait quelques modifications à l'image dans notre propre Dockerfile et poussé la nouvelle image à notre propre référentiel puis (DCHQ / weblogic: dernière). La construction d'images peut être programmé en utilisant une expression cron. En outre, un utilisateur peut utiliser {{timestamp}} dans le nom de tag afin de créer des noms de tags uniques à chaque nouvelle génération. De cette façon , un utilisateur peut revenir à des images plus anciennes pour la sauvegarde.

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 13 nuage points terminaux différents, y compris vSphere, OpenStack, CloudStack, Amazon Web Services, Rackspace, Microsoft Azure, Digital Ocean, HP Public cloud, 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.

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. Un cluster est alors sélectionné et le nombre de serveurs de Cloud peut être spécifié.

Déploiement Le cluster WebLogic vers les serveurs Rackspace Cloud

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 pour l'environnement (comme DEV ou QE) et le Cluster Rackspace créé avant de cliquer sur Exécuter.

Une fois que le cluster WebLogic est provisionné, un utilisateur peut accéder à la console d' administration du serveur pour vous assurer que les serveurs gérés sont découverts et en cours d' exécution. L'URL serait http: // <admin_server_host_ip>: 7001 / console . Les informations d' identification par défaut seraient weblogic / welcome1.

Déploiement du fichier Java WAR Shopping Cart en utilisant le cadre Plug-In

Une fois que le cluster WebLogic est en cours d' exécution, un utilisateur peut exécuter un plug-in de script BASH pour déployer un WAR Java fichier sur l' un des serveurs. Dans ce cas, nous avons simplement invoqué un plug-in pour déployer le Panier application sur le serveur d' administration. De l' Actions menu, l'utilisateur peut sélectionner Plug-ins , puis sélectionnez le conteneur (s) sur lequel le plug-in sera exécutée. Un utilisateur peut alors rechercher le plug-in et remplacer les arguments exposés.

Dans ce simple plug-in, nous attrapant trois fichiers depuis un serveur accessible à distance afin de déployer l'application.

• deploy.py
• deploy_app.sh
• shoppingcart.war

Voici les fichiers réellement utilisés:

deploy.py

---------------------

deploy_app.sh

---------------------

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.

Dans ce cas, nous avons utilisé l'invite de commande pour vous assurer que le fichier deploy.py a en effet été téléchargé sur le serveur d'administration. En faisant une /oracle/fmwhome/wlst_custom/deploy.py de chat simple - nous avons pu vérifier que le fichier existe bien sur ce conteneur.

Nous avons ensuite accédé à la console d'administration du serveur et navigué à Déploiements pour vous assurer que le Panier demande a en effet été déployée.

Enfin, nous avons accédé à l'application réelle sur http: // <admin_server_host_ip>: 7001 / shoppingcart

Surveillance Le CPU, mémoire et E / S Utilisation de la course

Containers

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.

Notez que le plug-in de script BASH peut être personnalisé pour faire en sorte que la bonne séquence des étapes est prise pour le WebLogic Server. Par exemple, un utilisateur peut souhaiter utiliser un plan de déploiement spécifique ou exécuter des scripts avant un-déploiement puis déployer le nouveau fichier WAR.

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.

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.

Inscrivez - vous gratuitement sur ​​http://DCHQ.io ou télécharger DCHQ On-Pemise

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.