DCHQ simplifie la conteneurisation des applications d'entreprise et permet de reproduire des environnements très complexes d'application sur plusieurs hôtes à travers un seul clic bouton déployer. DCHQ ne se contente pas d'automatiser les déploiements d'applications, mais il intègre également avec 12 fournisseurs de cloud différents pour automatiser le provisionnement et l'auto-mise à l'échelle des amas de Weave activé comprenant des machines virtuelles distribuées.
Dans ce blog, nous allons passer en revue l'automatisation de déploiement et de gestion du cycle de vie d'une application Java à 3 niveaux à base de Docker déployé sur des serveurs Tomcat avec Nginx pour l'équilibrage de charge et de MySQL pour la base de données.
Cela peut être fait en accédant à la bibliothèque libre-service, puis en cliquant sur Personnaliser pour demander une application à plusieurs niveaux. Dans cet exemple, nous avons une application multi-niveaux comprenant Nginx (pour l' équilibrage de charge), Tomcat (serveur d'applications en cluster) et MySQL (comme la base de données). Vous remarquerez 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). Tomcat est également invoque un plug-in de script BASH pour déployer un fichier Java WAR à partir d' une URL spécifiée. 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. 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. Voici une liste de variables d'environnement supportées:
- {{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 modèle 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 (ou IP interne) d'un modèle 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 modèle comme une 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.
Un utilisateur peut sélectionner une étiquette pour l'environnement (comme DEV ou QE) et un centre de données Weave activé avant de cliquer sur Exécuter.
Une fois que l'application est en cours d'exécution, un utilisateur peut surveiller le CPU, la mémoire, & I O Utilisation / des conteneurs de fonctionnement et effectuer-2 jour des opérations telles que la sauvegarde, les mises à jour conteneur à l'aide de plug-ins BASH, Echelle In / Out et livraison continue .
Dans la démo enregistrée, nous avons réduit le cluster de serveurs d'application de 2 à 3. Un utilisateur peut programmer l'échelle pendant les heures d'ouverture et la balance dans le week-end. 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.
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.
Inscrivez - vous gratuitement sur DCHQ.io Hébergé PaaS ( http://dchq.io ) pour obtenir ce modèle avec Ruby, Python, PHP, MEAN.JS, cluster MongoDB, et beaucoup d' autres modèles.
No comments:
Post a Comment