Ceci est le deuxième blog d'une série 2-blog sur l'évolutivité de la plate - forme en utilisant DCHQ Weave comme couche de réseau sous - jacent. Le premier blog couvrait le déploiement de 10.000 conteneurs sur 10 Weave Clusters, ayant chacun 3 serveurs Cloud sur Rackspace avec 4 Go de mémoire et 2 processeurs.
Dans ce blog, nous couvrons le déploiement de 2.000 conteneurs - mais au lieu d'utiliser 10 clusters avec 3 serveurs cloud chacun, nous allons utiliser un cluster Weave unique avec 30 serveurs cloud . DCHQ non seulement automatise le déploiement et la gestion des applications, mais il automatise également la fourniture d'infrastructures et d' auto-mise à l' échelle sur 13 différents nuages et plates - formes de virtualisation. En savoir plus sur ce test d'évolutivité dans ce blog.
Contexte
Alors que la portabilité des applications ( par exemple être en mesure d'exécuter la même application sur un hôte Linux) est toujours le pilote de premier plan pour l'adoption des conteneurs Linux, un autre avantage clé est en mesure d' optimiser l' utilisation du serveur de sorte que vous pouvez utiliser tous les bits de calcul. Bien sûr, pour les environnements en amont, comme PROD, vous pouvez toujours vouloir consacrer plus qu'assez CPU et mémoire pour votre charge de travail - mais dans DEV environnements de test /, qui représentent généralement la majorité de la consommation des ressources de calcul dans une organisation, l' optimisation de l' utilisation du serveur peut conduire à des économies de coûts significatives.
Tout cela sonne bien sur le papier - mais Devops ingénieurs et les exploitants d'infrastructures luttent encore avec les questions suivantes:
- Comment puis-je les serveurs de groupe dans différents nuages en grappes qui correspondent aux groupes d'entreprises, les équipes de développement, ou des projets d'application?
- Comment puis-je surveiller ces groupes et d'obtenir un aperçu de la consommation de ressources par les différents groupes ou les utilisateurs?
- Comment puis-je configurer la mise en réseau entre les serveurs dans un cluster, de sorte que les conteneurs à travers plusieurs hôtes peuvent communiquer entre eux?
- Comment puis-je définir ma propre politique de placement fondée sur la capacité afin que je puisse utiliser tous les bits de calcul dans un cluster?
- Comment puis-je étendre automatiquement le cluster pour répondre aux demandes des développeurs pour les nouveaux déploiements d'applications à base de conteneurs?
DCHQ, disponible dans hébergé sur site et versions, aborde tous ces défis et fournit des politiques de provisionnement de l'infrastructure, l'auto-mise à l'échelle, de clustering et de placement les plus avancées pour les opérateurs d'infrastructure ou des ingénieurs de Devops.
- Un utilisateur peut enregistrer un hôte Linux en cours d' exécution partout en exécutant un script généré automatiquement pour installer l'agent DCHQ, avec Docker et la couche réseau définie par logiciel ( en option). Cette tâche peut être automatisée programme à l' aide de nos REST API pour créer des "serveurs" Docker ( https://dchq.readme.io/docs/dockerservers )
- Alternativement, DCHQ intègre avec 13 fournisseurs de cloud, permettant aux utilisateurs de tourner automatiquement l'infrastructure virtuelle sur vSphere, OpenStack, CloudStack, Amazon Elastic Cloud Computing, Google Compute Engine, Rackspace, Digital Ocean, SoftLayer, Microsoft Azure, et bien d'autres.
Construire le modèle d'application pour le cluster Nginx
Une fois connecté à DCHQ (soit le DCHQ.io hébergé ou la version sur site), un utilisateur peut accéder à App & Machines et puis cliquez sur le + bouton pour créer une nouvelle Docker Compose modèle.
We have created a simple Nginx Cluster for the sake of this scalability test. You will notice that the cluster_size parameter allows you to specify the number of containers to launch (with the same application dependencies).
Le mem_min paramètre permet de specifcy la quantité minimale de mémoire que vous souhaitez allouer au conteneur.
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
Provisioning 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.
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. Dans ce cas, nous avons défini également une politique d' auto-échelle qui va automatiquement faire tourner des serveurs cloud dans cette grappe jusqu'à la limite maximale définie (dans ce cas , 30 serveurs cloud). Droits granulaires sont disponibles pour vous assurer que ce groupe ne peut être utilisé par les 10 utilisateurs que nous utilisons dans ce test (user1@dchq.io, user2@dchq.io, ..., user10@dchq.io). Enfin, les droits peuvent être définis au niveau schéma (ou modèle d'application) - pour garantir que seules les applications intitulée peuvent être déployés à ce cluster partagé. Dans ce cas, le groupe était ouvert à "Tous les Blueprints".
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 , puis en sélectionnant la machine Compose .
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 Cluster Nginx Utilisation Programmatically de DCHQ REST API
Une fois les serveurs de Cloud sont provisionnés, un utilisateur peut déployer le cluster Nginx en utilisant REST API DCHQ de programmation. Pour simplifier l'utilisation des API, un utilisateur devra sélectionner le cluster créé plus tôt que le cluster par défaut. Cela peut être fait en accédant à Mon profil , puis en sélectionnant le cluster par défaut nécessaire.
Une fois que le cluster par défaut est sélectionnée, un utilisateur peut simplement exécuter le script boucle suivante qui appelle l'API "déployer" ( https://dchq.readme.io/docs/deployid ).
Dans ce script de boucle simple, nous avons ce qui suit:
- Une boucle for, entre 1 et 20
- Avec chaque itération nous déployer l'application Nginx en cluster utilisant le cluster par défaut attribué à user1@dchq.io~~V
- user1% 40dchq.io est utilisé pour user1@dchq.io où le symbole @ est remplacé par hex% 40
- @ Entre le mot de passe et l' hôte n'est remplacé par hex
- <id> fait référence à l'application de cluster ID Nginx. Cela peut être récupéré en accédant à la Bibliothèque > Personnaliser pour le cluster Nginx. L'ID doit être dans l'URL
- 22 sommeil est utilisé entre chaque itération
- Après l'exécution de ce script, 200 conteneurs Nginx auraient été déployés par user1@dchq.io - 20 itérations déployer un cluster Nginx de 10 conteneurs chacun.
Nous avons ensuite répété le même processus pour les autres utilisateurs (user2@dchq.io, user3@dchq.io, ..., user10@dchq.io~~number=plural) - tous les déployant à la même cluster partagé.
Vous pouvez essayer ce script boucle vous - même. Vous pouvez soit installer DCHQ On-Premise ( http://dchq.co/dchq-on-premise.html ) ou inscrivez - vous sur DCHQ.io Hébergé PaaS ( http://dchq.io ).
Surveillance Le CPU, mémoire et E / S Utilisation de la grappe, Serveurs et conteneurs en cours
DCHQ permet aux utilisateurs de surveiller la CPU, mémoire, disque et I / O des clusters, des hôtes et des conteneurs.
- Pour surveiller les clusters, vous pouvez simplement naviguer vers Clusters
- Pour surveiller les hôtes, il vous suffit de naviguer vers Machines
- Pour surveiller les conteneurs, il vous suffit de naviguer vers Vivre Apps
Nous avons suivi les performances des hôtes et cluster avant et après nous avons lancé les 2000 conteneurs.
Après la filature jusqu'à 2.000 conteneurs, nous avons capturé des captures d' écran des tableaux de performances pour le cluster. Vous pouvez voir que l' utilisation de la mémoire agrégées sur les serveurs 30 de nuages dans le cluster était à 81% .
Vous pouvez voir que l' utilisation le plus élevé de la mémoire sur les serveurs 30 de nuages dans le cluster était à 84% .
Lorsque nous avons foré vers le bas dans l' une des 30 hôtes du cluster et avons vu plus de détails comme le nombre de conteneurs en cours d' exécution sur cet hôte particulier, le nombre d'images tiré et bien sûr, la CPU / Utilisation de la mémoire / disque. Dans ce cas, l' utilisation de la mémoire de cet hôte particulier était de 83% .
Voici une vue de tous les cours d'exécution 200 grappes Nginx (où chaque groupe avait 10 conteneurs).
Conclusion
Orchestrer les déploiements d'applications à base de Docker est encore un défi pour de nombreux Devops ingénieurs et les exploitants d'infrastructures comme ils peinent souvent à gérer des pools de serveurs à travers les équipes de développement multiples où les contrôles d'accès, la surveillance, la mise en réseau, le placement basé sur la capacité, à l'échelle automatique des politiques et des quotas sont des aspects clés qui doivent être configurés.
DCHQ, disponible dans hébergé sur site et versions, aborde tous ces défis et fournit des politiques de provisionnement de l'infrastructure, l'auto-mise à l'échelle, de clustering et de placement les plus avancées pour les opérateurs d'infrastructure ou des ingénieurs de Devops.
En plus de la fourniture de l'infrastructure et regroupement des fonctionnalités avancées, DCHQ simplifie la conteneurisation des applications d'entreprise à travers un cadre de composition d'application avance qui étend Docker Compose avec la croix d'image variable d'environnement reliures, les plug-ins de script BASH extensibles qui peuvent être invoquées au moment de la demande ou 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.
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