Nous allons commencer par créer le conteneur Apache de base. Il s’agit en réalité du même guide que le dernier guide. Vous n’avez donc pas à le refaire si cette image est déjà disponible dans votre compte Docker Hub. Nous allons baser ce conteneur sur l'image de conteneur Ubuntu 14.04.

Nous pouvons extraire l'image de base et démarrer une instance de conteneur en tapant:

Vous serez placé dans une sessionbash une fois le conteneur démarré. À partir de là, nous mettrons à jour l'index du package localapt et installeronsapache2:

Nous allons également définir la page par défaut:

Nous pouvons quitter le conteneur maintenant puisqu'il se trouve dans l'état dont nous avons besoin:

Connectez-vous ou créez votre compte sur Docker Hub en tapant:

Vous devrez fournir votre nom d'utilisateur, votre mot de passe et votre adresse électronique pour votre compte Docker Hub.

Ensuite, obtenez l'ID de conteneur de l'instance que vous venez de quitter:

Le champ en surbrillance ci-dessus est l'ID du conteneur. Copiez la sortie que vous voyez sur votre propre ordinateur.

Maintenant, validez en utilisant cet ID de conteneur, votre nom d'utilisateur Docker Hub et un nom pour l'image. Nous utiliserons “apache” ici:

Poussez votre nouvelle image sur Docker Hub:

Vous pouvez maintenant utiliser cette image dans vos fichiers de service.

Maintenant que vous disposez d'un conteneur, vous pouvez créer un fichier d'unité modèle afin quefleet etsystemd puissent gérer correctement le service.

Avant de commencer, mettons en place une structure de répertoires afin que nous puissions rester organisés:

Maintenant, nous pouvons créer notre fichier modèle dans le répertoiretemplates:

Collez les informations suivantes dans le fichier. Vous pouvez obtenir des détails sur chacune des options que nous utilisons en suivant le guide précédent surcreating flexible fleet unit files:

Une modification que nous avons apportée ici consiste à utiliser l'interface privée à la place de l'interface publique. Étant donné que toutes nos instances Apache recevront le traficthrough du proxy inverse Nginx au lieu de gérer les connexions à partir du Web ouvert, c'est une bonne idée. N'oubliez pas que si vous utilisez l'interface privée sur DigitalOcean, l'indicateur de «réseau privé» doit avoir été sélectionné sur le serveur que vous avez démarré.

N'oubliez pas non plus de modifier lesuser_name pour référencer votre nom d'utilisateur Docker Hub afin de récupérer correctement le fichier Docker.

Maintenant, nous allons faire la même chose pour le service sidekick. Celui-ci nous modifierons légèrement en prévision des informations dont nous aurons besoin ultérieurement.

Ouvrez le fichier modèle dans votre éditeur:

Nous utiliserons les informations suivantes dans ce fichier:

La configuration ci-dessus diffère à certains égards de celle du guide précédent. Nous avons ajusté la valeur définie par la commandeetcdctl set. Au lieu de transmettre un objet JSON, nous définissons une simple combinaison adresse IP / port. De cette façon, nous pouvons lire cette valeur directement pour trouver les informations de connexion nécessaires pour accéder à ce service.

Nous avons également ajusté les informations pour spécifier l'interface privée, comme nous l'avons fait dans notre autre fichier. Laissez ceci public si vous ne disposez pas de cette option.

Créons maintenant deux instances de ces services.

Commençons par créer les liens symboliques. Accédez au répertoire~/instances que vous avez créé et créez un lien pour définir les ports sur lesquels ils seront exécutés. Nous voulons exécuter un service sur le port 7777 et un autre sur le port 8888:

Maintenant, nous pouvons démarrer ces services en passant le répertoire~/instances àfleet:

Après le démarrage de vos instances (cela peut prendre quelques minutes), vous devriez pouvoir voir les entréesetcd que vos acolytes ont créées:

Si vous demandez la valeur d'une de ces entrées, vous pouvez voir que vous obtenez une adresse IP et un numéro de port:

Vous pouvez utilisercurl pour récupérer la page et vous assurer qu’elle fonctionne correctement. Cela ne fonctionnera à partir de votre ordinateur que si vous avez configuré le service pour utiliser un réseau privé:

Nous avons maintenant mis en place notre infrastructure d’arrière-plan. Notre prochaine étape est de se familiariser avecconfd afin que nous puissions surveiller l'emplacement de/services/apache dansetcd pour les changements et reconfigurer Nginx à chaque fois.

Démarrez un nouveau conteneur en tapant:

Mettez à jour votre cache de paquetage localapt et installez Nginx. Nous devons également installercurl car l'image de base ne l'inclut pas et nous en avons besoin pour obtenir momentanément le package stableconfd de GitHub:

Maintenant, nous pouvons accéder auxreleases page pourconfd sur GitHub dans nos navigateurs. Nous devons trouver le lien vers la dernière version stable. Au moment de la rédaction de cet article, c'estv0.5.0, mais cela peut avoir changé. Cliquez avec le bouton droit de la souris sur le lien de la version Linux de l'outil et sélectionnez «Copier l'adresse du lien» ou toute autre option similaire disponible.

De retour dans votre conteneur Docker, utilisez l’URL copiée pour télécharger l’application. Nous mettrons ceci dans le répertoire/usr/local/bin. Nous devons choisirconfd comme fichier de sortie:

Maintenant, rendez le fichier exécutable afin que nous puissions l’utiliser dans notre conteneur:

Nous devrions également profiter de cette opportunité pour créer la structure de configuration attendue parconfd. Ce sera dans le répertoire/etc:

Maintenant que nos applications sont installées, nous devrions commencer à configurerconfd. Nous allons commencer par créer un fichier de configuration ou un fichier de ressources de modèle.

Les fichiers de configuration dansconfd sont utilisés pour configurer le service pour vérifier certaines valeurs deetcd et lancer des actions lorsque des changements sont détectés. Ceux-ci utilisent le format de fichierTOML, qui est facile à utiliser et assez intuitif.

Commencez par créer un fichier dans notre répertoire de configuration appelénginx.toml:

Nous allons construire notre fichier de configuration ici. Ajoutez les informations suivantes:

Le fichier ci-dessus contient des commentaires expliquant certaines des idées de base, mais nous pouvons passer en revue les options ci-dessous:

Le fichier que nous avons créé nous dit quelques choses importantes sur le fonctionnement de notre instanceconfd. Notre conteneur Nginx utilisera un modèle stocké à/etc/confd/templates/nginx.conf.tmpl pour rendre un fichier de configuration qui sera placé à/etc/nginx/sites-enabled/app.conf. Le fichier recevra un ensemble d'autorisations de0644 et la propriété sera donnée à l'utilisateur root.

L'applicationconfd recherchera les modifications au nœud/services/apache. Lorsqu'un changement est observé,confd interrogera les nouvelles informations sous ce nœud. Il rendra ensuite une nouvelle configuration pour Nginx. Il vérifiera les erreurs de syntaxe dans le fichier de configuration et rechargera le service Nginx une fois le fichier en place.

Nous avons maintenant créé notre fichier de ressources de modèle. Nous devrions travailler sur le fichier de modèle qui sera utilisé pour rendre notre fichier de configuration Nginx.

Pour notre fichier modèle, nous utiliserons un exemple du projetconfdGitHub documentation pour nous aider à démarrer.

Créez le fichier que nous avons référencé dans notre fichier de configuration ci-dessus. Mettez ce fichier dans notre répertoiretemplates:

Dans ce fichier, nous créons simplement un fichier de configuration de proxy inverse Nginx standard. Cependant, nous utiliserons une syntaxe de modèle Go pour remplacer certaines des informations queconfd extrait deetcd.

Tout d'abord, nous configurons le bloc avec les serveurs «amont». Cette section permet de définir le pool de serveurs auquel Nginx peut envoyer des requêtes. Le format est généralement comme ceci:

Cela nous permet de transmettre des requêtes auxpool_name et Nginx sélectionnera l'un des serveurs définis à qui transmettre la requête.

L'idée derrière notre fichier de modèle est d'analyseretcd pour les adresses IP et les numéros de port de nos serveurs Web Apache. Ainsi, au lieu de définir statiquement nos serveurs en amont, nous devrions renseigner dynamiquement ces informations lors du rendu du fichier. Nous pouvons le faire en utilisantGo templates pour le contenu dynamique.

Pour ce faire, nous utiliserons plutôt ceci comme notre bloc:

Expliquons un instant ce qui se passe. Nous avons ouvert un bloc pour définir un pool de serveurs en amont appeléapache_pool. A l'intérieur, nous spécifions que nous commençons un code de langue Go en utilisant les doubles crochets.

Entre ces crochets, nous spécifions le point de terminaisonetcd où se trouvent les valeurs qui nous intéressent. Nous utilisons unrange pour rendre la liste itérable.

Nous l'utilisons pour transmettre toutes les entrées récupérées sous l'emplacement/services/apache dansetcd dans le blocrange. Nous pouvons alors obtenir la valeur de la clé dans l'itération actuelle en utilisant un seul point dans les "\ {\ {" et "}}" qui indiquent une valeur insérée. Nous l'utilisons dans la boucle de plage pour remplir le pool de serveurs. Enfin, nous terminons la boucle avec la directive{{ end }}.

Note: n'oubliez pas d'ajouter le point-virgule après la directiveserver dans la boucle. Si vous oubliez cela, la configuration ne fonctionnera pas.

Après avoir configuré le pool de serveurs, nous pouvons simplement utiliser une passe proxy pour diriger toutes les connexions dans ce pool. Ce sera simplement un bloc de serveur standard en tant que proxy inverse. La seule chose à noter est leaccess_log, qui utilise un format personnalisé que nous allons créer momentanément:

Cela répondra à toutes les connexions sur le port 80 et les passera au pool de serveurs àapache_pool qui est généré en regardant les entréesetcd.

Pendant que nous traitons de cet aspect du service, nous devrions supprimer le fichier de configuration par défaut de Nginx afin d'éviter tout conflit ultérieur. Nous allons simplement supprimer le lien symbolique permettant la configuration par défaut:

C'est également le bon moment pour configurer le format de journal que nous avons référencé dans notre fichier de modèle. Cela doit aller dans le blochttp de la configuration, qui est disponible dans le fichier de configuration principal. Ouvrez ça maintenant:

Nous ajouterons une directivelog_format pour définir les informations que nous voulons enregistrer. Il enregistrera le client qui visite, ainsi que le serveur principal auquel la demande est transmise. Nous allons enregistrer quelques données sur la durée de ces procédures:

Enregistrez et fermez le fichier lorsque vous avez terminé.

Nous devons créer un fichier script qui appelleraconfd avec notre fichier de ressources modèle et notre fichier modèle aux moments appropriés.

Le script doit faire deux choses pour que notre service fonctionne correctement:

Nous obtiendrons notre script deMarcel de Graaf’s GitHub page. C'est un script simple et agréable qui faitexactly ce dont nous avons besoin. Nous ne ferons que quelques modifications mineures pour notre scénario.

Plaçons ce script à côté de notre exécutableconfd. Nous appellerons celaconfd-watch:

Nous commencerons par l'en-tête classiquebash pour identifier l'interpréteur dont nous avons besoin. Nous allons ensuite définir certaines options debash afin que le script échoue immédiatement en cas de problème. Il renverra la valeur de la dernière commande à échouer ou à exécuter.

Ensuite, nous voulons configurer certaines variables. En utilisant la substitution de paramètre debash, nous définirons les valeurs par défaut, mais intégrons une certaine flexibilité pour nous permettre de remplacer les valeurs codées en dur lors de l'appel du script. En gros, il suffit de configurer chaque composant de l’adresse de connexion indépendamment, puis de les regrouper pour obtenir l’adresse complète requise.

La substitution de paramètre est créée avec cette syntaxe:${var_name:-default_value}. Cela a la propriété d'utiliser la valeur devar_name si elle est donnée et non nulle, sinon par défaut surdefault_value.

Nous utilisons par défaut les valeurs queetcd attend par défaut. Cela permettra à notre script de bien fonctionner sans informations supplémentaires, mais nous pouvons le personnaliser si nécessaire lorsque vous appelez le script:

Nous allons maintenant utiliserconfd pour rendre une version initiale du fichier de configuration Nginx en lisant les valeurs deetcd disponibles lorsque ce script est appelé. Nous utiliserons une boucleuntil pour essayer en permanence de construire la configuration initiale.

La construction en boucle peut être nécessaire dans le cas oùetcd n'est pas disponible tout de suite ou dans le cas où le conteneur Nginx est mis en ligne avant les serveurs principaux. Cela lui permet d'interrogeretcd à plusieurs reprises jusqu'à ce qu'il puisse enfin produire une configuration initiale valide.

La commande réelleconfd que nous appelons s'exécute une fois, puis se termine. Cela nous permet d'attendre 5 secondes jusqu'à la prochaine exécution pour donner à nos serveurs principaux une chance de s'inscrire. Nous nous connectons à la variableETCD complète que nous avons construite en utilisant les paramètres par défaut ou passés en paramètres, et nous utilisons le fichier de ressources modèle pour définir le comportement de ce que nous voulons faire:

Une fois la configuration initiale définie, la tâche suivante de notre script doit être de mettre en place un mécanisme d’interrogation continue. Nous voulons nous assurer que les modifications futures sont détectées afin que Nginx soit mis à jour.

Pour ce faire, nous pouvons appeler à nouveauconfd. Cette fois, nous voulons définir un intervalle d'interrogation continu et placer le processus en arrière-plan afin qu'il s'exécute indéfiniment. Nous transmettrons les mêmes informations de connexionetcdet le même fichier de ressources de modèle puisque notre objectif est toujours le même.

Après avoir mis le processusconfd en arrière-plan, nous pouvons démarrer Nginx en toute sécurité en utilisant le fichier de configuration créé. Ce script étant appelé notre commande "exécuter" de Docker, nous devons le laisser fonctionner au premier plan afin que le conteneur ne se ferme pas à ce stade. Pour ce faire, il suffit de suivre les journaux, ce qui nous donne accès à toutes les informations que nous enregistrons:

Lorsque vous avez terminé, enregistrez et fermez le fichier.

La dernière chose à faire est de rendre le script exécutable:

Quittez le conteneur maintenant pour revenir au système hôte:

Maintenant, nous pouvons valider le conteneur et le placer sur Docker Hub afin qu'il soit disponible pour nos machines.

Découvrez l'ID du conteneur:

La chaîne en surbrillance est l'ID de conteneur dont nous avons besoin. Commettez le conteneur à l'aide de cet ID avec votre nom d'utilisateur Docker Hub et le nom que vous souhaitez utiliser pour cette image. Nous allons utiliser le nom «nginx_lb» dans ce guide:

Connectez-vous à votre compte Docker Hub si nécessaire:

Maintenant, vous devriez augmenter votre image engagée afin que vos autres hôtes puissent la réduire si nécessaire: