Éditeur – Les Dockerfiles NGINX Plus pour Debian et Alpine Linux ont été mis à jour en décembre 2022 pour correspondre à la dernière version de NGINX Plus et aux versions de ces distributions de systèmes d’exploitation. Les Dockerfiles et les instructions utilisent les secrets Docker pour transmettre les informations de licence lors de la création d'une image NGINX Plus.
Docker est une plate-forme ouverte permettant de créer, d'expédier et d'exécuter des applications distribuées sous forme de conteneurs (packages logiciels légers, autonomes et exécutables qui incluent tout ce qui est nécessaire pour exécuter une application). Les conteneurs peuvent à leur tour être déployés et orchestrés par des plateformes d’orchestration de conteneurs telles que Kubernetes . (En plus de la technologie de conteneur Docker décrite dans ce blog, NGINX fournit F5 NGINX Ingress Controller dans les versions basées sur NGINX Open Source et NGINX Plus ; pour les abonnés NGINX Plus, le support est inclus sans frais supplémentaires.)
En tant qu'applications logicielles, NGINX Open Source et F5 NGINX Plus sont d'excellents cas d'utilisation pour Docker, et nous publions une image NGINX Open Source sur Docker Hub , le référentiel des images Docker. Cet article explique comment :
La plateforme ouverte Docker comprend Docker Engine – l'environnement d'exécution open source qui crée, exécute et orchestre les conteneurs – et Docker Hub, un service hébergé où les applications dockerisées sont distribuées, partagées et utilisées en collaboration par l'ensemble de la communauté de développement ou dans les limites d'une organisation spécifique.
Les conteneurs Docker permettent aux développeurs de concentrer leurs efforts sur le « contenu » de l’application en séparant les applications des contraintes de l’infrastructure. Les applications dockerisées sont instantanément portables sur n'importe quelle infrastructure (ordinateur portable, serveur bare-metal, machine virtuelle ou cloud), ce qui en fait des composants modulaires qui peuvent être facilement assemblés et réassemblés dans des applications distribuées complètes et continuellement innovées en temps réel.
Pour plus d'informations sur Docker, consultez Pourquoi Docker ? ou la documentation complète de Docker .
Vous pouvez créer une instance NGINX dans un conteneur Docker à l'aide de l' image Open Source NGINX de Docker Hub.
Commençons par un exemple très simple. Pour lancer une instance de NGINX exécutée dans un conteneur et utilisant la configuration NGINX par défaut, exécutez cette commande :
# docker run --name mynginx1 -p 80:80 -d nginx fcd1fb01b14557c7c9d991238f2558ae2704d129cf9fb97bb4fadf673a58580d
Cette commande crée un conteneur nommé mynginx1 basé sur l'image NGINX. La commande renvoie la forme longue de l'ID du conteneur, qui est utilisé dans le nom des fichiers journaux ; voir Gestion de la journalisation .
L' option -p
indique à Docker de mapper le port exposé dans le conteneur par l'image NGINX – le port 80 – au port spécifié sur l'hôte Docker. Le premier paramètre spécifie le port dans l’hôte Docker, tandis que le deuxième paramètre est mappé au port exposé dans le conteneur.
L' option -d
spécifie que le conteneur s'exécute en mode détaché, ce qui signifie qu'il continue de s'exécuter jusqu'à son arrêt mais ne répond pas aux commandes exécutées sur la ligne de commande. Dans la section suivante, nous expliquons comment interagir avec le conteneur.
Pour vérifier que le conteneur a été créé et qu'il est en cours d'exécution, et pour voir les mappages de ports, nous exécutons docker
ps
. (Nous avons divisé la sortie sur plusieurs lignes ici pour la rendre plus facile à lire.)
# docker ps ID CONTAINER IMAGE COMMANDE CRÉÉE ... fcd1fb01b145 nginx:latest "nginx -g 'daemon d'il y a 16 secondes ... ... NOMS DES PORTS D'ÉTAT ... En hausse de 15 secondes 0.0.0.0:80->80/tcp mynginx1
Le champ PORTS
dans la sortie indique que le port 80 sur l'hôte Docker est mappé au port 80 dans le conteneur. Une autre façon de vérifier que NGINX est en cours d’exécution est de faire une requête HTTP sur ce port. Le code de la page d'accueil par défaut de NGINX apparaît :
# boucle http://localhost<!DOCTYPE html>
<html>
<head>
<title>Bienvenue dans nginx !</title>
<style>
body {
width: 35em; marge: 0 auto; famille de polices : Tahoma, Verdana, Arial, sans-serif; } Une configuration supplémentaire est requise.
Nous avons donc maintenant un conteneur Docker NGINX fonctionnel, mais comment gérons-nous le contenu et la configuration NGINX ? Et qu'en est-il de l'exploitation forestière ?
Il est courant d'activer l'accès SSH aux instances NGINX, mais l'image NGINX n'a pas OpenSSH installé, car les conteneurs Docker sont généralement destinés à un seul usage (dans ce cas, l'exécution de NGINX). Au lieu de cela, nous utiliserons d’autres méthodes prises en charge par Docker.
En alternative aux commandes de la section Gestion du contenu et des fichiers de configuration ci-dessous, vous pouvez exécuter la commande suivante pour ouvrir un shell interactif sur un conteneur NGINX en cours d'exécution (au lieu de démarrer une session SSH). Nous le recommandons toutefois uniquement aux utilisateurs avancés.
Sur les systèmes Alpine Linux :
# docker exec -it <ID_conteneur_NGINX> ch.
Sur les systèmes Debian :
# docker exec -it <ID_conteneur_NGINX> frapper
Il existe plusieurs façons de gérer à la fois le contenu diffusé par NGINX et les fichiers de configuration NGINX. Nous couvrons ici quelques-unes des options.
Une fois le conteneur créé, nous pouvons demander à Docker de monter un répertoire local sur l’hôte Docker vers un répertoire du conteneur. L'image NGINX utilise la configuration NGINX par défaut, qui utilise /usr/share/nginx/html comme répertoire racine du conteneur et place les fichiers de configuration dans /etc/nginx . Pour un hôte Docker avec du contenu dans le répertoire local /var/www et des fichiers de configuration dans /var/nginx/conf , exécutez cette commande (qui apparaît sur plusieurs lignes ici uniquement pour des raisons de lisibilité) :
# docker run --name mynginx2 --mount type=bind source=/var/www,target=/usr/share/nginx/html,readonly --mount type=bind,source=/var/nginx/conf,target=/etc/nginx/conf,readonly -p 80:80 -d nginx
Désormais, toute modification apportée aux fichiers dans les répertoires locaux /var/www et /var/nginx/conf sur l'hôte Docker est reflétée dans les répertoires /usr/share/nginx/html et /etc/nginx du conteneur. L'option lecture seule
signifie que ces répertoires ne peuvent être modifiés que sur l'hôte Docker, et non à partir du conteneur.
Une autre option consiste à demander à Docker de copier le contenu et les fichiers de configuration à partir d’un répertoire local sur l’hôte Docker lors de la création du conteneur. Une fois qu'un conteneur est créé, les fichiers sont maintenus en créant un nouveau conteneur lorsque les fichiers changent ou en modifiant les fichiers dans le conteneur. Un moyen simple de copier les fichiers consiste à créer un Dockerfile avec des commandes qui sont exécutées lors de la génération d'une nouvelle image Docker basée sur l'image NGINX de Docker Hub. Pour les commandes de copie de fichier ( COPY
) dans le Dockerfile , le chemin du répertoire local est relatif au contexte de build dans lequel se trouve le Dockerfile .
Dans notre exemple, le contenu se trouve dans le répertoire content et les fichiers de configuration se trouvent dans le répertoire conf , tous deux des sous-répertoires du répertoire où se trouve le Dockerfile . L'image NGINX inclut les fichiers de configuration NGINX par défaut nommés /etc/nginx/nginx.conf et /etc/nginx/conf.d/default.conf . Comme nous souhaitons plutôt utiliser les fichiers de configuration de l'hôte, nous incluons une commande RUN
qui supprime les fichiers par défaut :
À PARTIR DE nginx
EXÉCUTER rm /etc/nginx/nginx.conf /etc/nginx/conf.d/default.conf
COPIER le contenu /usr/share/nginx/html
COPIER conf /etc/nginx
Nous créons notre propre image NGINX en exécutant la commande suivante à partir du répertoire où se trouve le Dockerfile . Notez le point (« . ») à la fin de la commande. Il définit le répertoire actuel comme contexte de construction, qui contient le Dockerfile et les répertoires à copier.
# docker build -t mynginx_image1 .
Nous exécutons maintenant cette commande pour créer un conteneur appelé mynginx3 basé sur l'image mynginx_image1 :
# docker run --name mynginx3 -p 80:80 -d mynginx_image1
Si nous souhaitons apporter des modifications aux fichiers du conteneur, nous utilisons un conteneur d’aide comme décrit dans l’option 3.
Comme mentionné dans Une note sur SSH , nous ne pouvons pas utiliser SSH pour accéder au conteneur NGINX, donc si nous voulons modifier directement le contenu ou les fichiers de configuration, nous devons créer un conteneur d'aide doté d'un accès shell. Pour que le conteneur d’aide ait accès aux fichiers, nous devons créer une nouvelle image contenant les volumes de données Docker appropriés définis pour l’image. En supposant que nous souhaitons copier des fichiers comme dans l'option 2 tout en définissant également des volumes, nous utilisons le Dockerfile suivant :
DEPUIS nginxEXÉCUTER rm /etc/nginx/nginx.conf /etc/nginx/conf.d/default.conf
COPIER le contenu /usr/share/nginx/html
COPIER la conf /etc/nginx
VOLUME /usr/share/nginx/html
VOLUME /etc/nginx
Nous créons ensuite la nouvelle image NGINX en exécutant la commande suivante (notez à nouveau le point final) :
# construction du docker -t mynginx_image2 .
Nous exécutons maintenant cette commande pour créer un conteneur NGINX ( mynginx4 ) basé sur l’image mynginx_image2 :
# docker run --name mynginx4 -p 80:80 -d mynginx_image2
Nous exécutons ensuite la commande suivante pour démarrer un conteneur d'aide mynginx4_files qui possède un shell, nous permettant d'accéder aux répertoires de contenu et de configuration du conteneur mynginx4 que nous venons de créer :
# docker run -i -t --volumes-from mynginx4 --name mynginx4_files debian /bin/bash root@b1cbbad63dd1:/#
Le nouveau conteneur d'aide mynginx4_files s'exécute au premier plan avec une entrée standard persistante (l' option -i
) et un tty (l' option -t
). Tous les volumes définis dans mynginx4 sont montés en tant que répertoires locaux dans le conteneur d'aide.
L'argument Debian
signifie que le conteneur d'aide utilise l'image Debian de Docker Hub. Étant donné que l’image NGINX utilise également Debian (et tous nos exemples jusqu’à présent utilisent l’image NGINX), il est plus efficace d’utiliser Debian pour le conteneur d’aide, plutôt que de laisser Docker charger un autre système d’exploitation.
L'argument /bin/bash
signifie que le shell bash
s'exécute dans le conteneur d'aide, présentant une invite de shell que vous pouvez utiliser pour modifier les fichiers selon vos besoins.
Pour démarrer et arrêter le conteneur, exécutez les commandes suivantes :
# docker démarre mynginx4_files # docker arrête mynginx4_files
Pour quitter le shell mais laisser le conteneur en cours d'exécution, appuyez sur Ctrl+p
suivi de Ctrl+q
. Pour récupérer l’accès shell à un conteneur en cours d’exécution, exécutez cette commande :
# docker attache mynginx4_files
Pour quitter le shell et terminer le conteneur, exécutez la commande exit
.
Vous pouvez configurer la journalisation par défaut ou personnalisée .
L'image NGINX est configurée pour envoyer par défaut les principaux journaux d'accès et d'erreurs NGINX au collecteur de journaux Docker. Cela se fait en les reliant à sortie standard
et erreur d'erreur
respectivement ; tous les messages des deux journaux sont ensuite écrits dans le fichier /var/lib/docker/conteneurs/<container_ID>/<container_ID>-json.log sur l'hôte Docker, où <container_ID> est l’ID long renvoyé lorsque vous créez un conteneur. Pour le conteneur initial que nous avons créé dans Utilisation de l'image Docker open source NGINX , par exemple, il s'agit de fcd1fb01b14557c7c9d991238f2558ae2704d129cf9fb97bb4fadf673a58580d .
Pour récupérer l'ID de conteneur d'un conteneur existant, exécutez cette commande, où <nom_conteneur>
est la valeur définie par le --nom
paramètre lorsque le conteneur est créé (pour l'ID de conteneur ci-dessus, par exemple, il est monginx1):
# docker inspect --format '{{ .Id }}' <nom_conteneur>
Bien que vous puissiez consulter les journaux en ouvrant le <container_ID>-json.log fichier directement, il est généralement plus simple d'exécuter cette commande :
# journaux de docker <nom_conteneur>
Vous pouvez également utiliser l' API Docker Engine pour extraire les messages du journal, en émettant une requête GET
sur le socket Docker Unix. Cette commande renvoie à la fois le journal d'accès (représenté par stdout=1
) et le journal des erreurs ( stderr=1
), mais vous pouvez également les demander individuellement :
# curl --unix-socket /var/run/docker-sock http://localhost/containers/<nom_conteneur>/logs?stdout=1&stderr=1
Pour en savoir plus sur les autres paramètres de requête, consultez la documentation de l’API Docker Engine (recherchez « Obtenir les journaux des conteneurs » sur cette page).
Si vous souhaitez implémenter une autre méthode de collecte de journaux, ou si vous souhaitez configurer la journalisation différemment dans certains blocs de configuration (tels que server{}
et location{}
), définissez un volume Docker pour le ou les répertoires dans lesquels stocker les fichiers journaux du conteneur, créez un conteneur d'aide pour accéder aux fichiers journaux et utilisez les outils de journalisation de votre choix. Pour implémenter cela, créez une nouvelle image contenant le ou les volumes pour les fichiers de journalisation.
Par exemple, pour configurer NGINX pour stocker les fichiers journaux dans /var/log/nginx/log , nous pouvons commencer avec le Dockerfile de l'option 3 et simplement ajouter une définition de VOLUME
pour ce répertoire :
DEPUIS nginxRUN rm /etc/nginx/nginx.conf /etc/nginx/conf.d/default.conf
COPIER le contenu /usr/share/nginx/html
COPIER la conf /etc/nginx
VOLUME /var/log/nginx/log
Nous pouvons ensuite créer une image comme décrit ci-dessus et l’utiliser pour créer un conteneur NGINX et un conteneur d’assistance qui ont accès au répertoire de journalisation. Le conteneur d'aide peut avoir tous les outils de journalisation souhaités installés.
Comme nous n'avons pas d'accès direct à la ligne de commande du conteneur NGINX, nous ne pouvons pas utiliser la commande nginx
pour contrôler NGINX. Heureusement, nous pouvons utiliser des signaux pour contrôler NGINX, et Docker fournit la commande kill
pour envoyer des signaux à un conteneur.
Pour recharger la configuration NGINX, exécutez cette commande :
# docker kill -s HUP <nom_conteneur>
Pour redémarrer NGINX, exécutez cette commande pour redémarrer le conteneur :
# redémarrage du docker <nom_conteneur>
Jusqu'à présent, nous avons discuté de Docker pour NGINX Open Source, mais vous pouvez également l'utiliser avec le produit commercial, NGINX Plus. La différence est que vous devez d’abord créer une image NGINX Plus, car en tant qu’offre commerciale, NGINX Plus n’est pas disponible sur Docker Hub. Heureusement, c’est assez facile à faire.
Pour générer une image NGINX Plus, créez d’abord un Dockerfile . Les exemples que nous fournissons ici utilisent Debian 11 (Bullseye) et Alpine Linux 3.17 comme images Docker de base. Avant de pouvoir créer l'image Docker NGINX Plus, vous devez télécharger votre version des fichiers nginx-repo.crt et nginx-repo.key . Les clients NGINX Plus peuvent les trouver sur le portail client ; si vous effectuez un essai gratuit de NGINX Plus, ils ont été fournis avec votre package d'essai. Copiez les fichiers dans le répertoire où se trouve le Dockerfile (le contexte de construction Docker).
Comme avec NGINX Open Source, par défaut, les journaux d'accès et d'erreurs NGINX Plus sont liés au collecteur de journaux Docker. Aucun volume n'est spécifié, mais vous pouvez en ajouter si vous le souhaitez, ou chaque Dockerfile peut être utilisé pour créer des images de base à partir desquelles vous pouvez créer de nouvelles images avec des volumes spécifiés, comme décrit précédemment.
Nous ne spécifions volontairement pas de version NGINX Plus dans les exemples de Dockerfiles , afin que vous n'ayez pas à modifier le fichier lorsque vous effectuez une mise à jour vers une nouvelle version de NGINX Plus. Nous avons cependant inclus des versions commentées des instructions pertinentes afin que vous puissiez supprimer les commentaires si vous souhaitez rendre le fichier spécifique à la version.
De même, nous avons inclus des instructions (commentées) qui installent les modules dynamiques officiels pour NGINX Plus .
Par défaut, aucun fichier n'est copié depuis l'hôte Docker lorsqu'un conteneur est créé. Vous pouvez ajouter des définitions COPY
à chaque Dockerfile , ou l'image que vous créez peut être utilisée comme base pour une autre image comme décrit ci-dessus.
Avec les fichiers Dockerfile , nginx-repo.crt et nginx-repo.key dans le même répertoire, exécutez la commande suivante pour créer une image Docker appelée nginxplus (comme précédemment, notez le point final) :
# DOCKER_BUILDKIT=1 docker build --no-cache -t nginxplus --secret id=nginx-crt,src=< /chemin/vers/votre/repo-nginx.crt > --secret id=nginx-key,src=< /chemin/vers/votre/repo-nginx.key > .
L'indicateur DOCKER_BUILDKIT=1
indique que nous utilisons Docker BuildKit pour créer l'image, comme requis lors de l'inclusion de l'option --secret
qui est décrite ci-dessous.
L' option --no-cache
indique à Docker de créer l'image à partir de zéro et garantit l'installation de la dernière version de NGINX Plus. Si le Dockerfile a été précédemment utilisé pour créer une image et que vous omettez l' option --no-cache
, la nouvelle image utilise la version de NGINX Plus du cache Docker. (Comme indiqué, nous ne spécifions volontairement pas de version NGINX Plus dans le Dockerfile afin que le fichier n'ait pas besoin de changer à chaque nouvelle version de NGINX Plus.) Omettez l’ option --no-cache
s’il est acceptable d’utiliser la version NGINX Plus de l’image précédemment créée.
L'option --secret
transmet le certificat et la clé de votre licence NGINX Plus au contexte de build Docker sans risquer d'exposer les données ou de les faire persister entre les couches de build Docker. Les valeurs des arguments id
ne peuvent pas être modifiées sans modifier le Dockerfile de base, mais vous devez définir les arguments src
sur le chemin d'accès à votre certificat NGINX Plus et aux fichiers de clé (le même répertoire dans lequel vous créez l'image Docker si vous avez suivi les instructions précédentes).
Une sortie semblable à celle-ci provenant de la commande nginxplus
des images
docker
indique que l'image a été créée avec succès :
# docker images nginxplus RÉFÉRENTIEL BALISE ID IMAGE CRÉÉ TAILLE VIRTUELLE nginxplus dernier ef2bf65931cf il y a 6 secondes 91,2 Mo
Pour créer un conteneur nommé mynginxplus basé sur cette image, exécutez cette commande :
# docker run --name mynginxplus -p 80:80 -d nginxplus
Vous pouvez contrôler et gérer les conteneurs NGINX Plus de la même manière que les conteneurs NGINX Open Source .
NGINX, NGINX Plus et Docker fonctionnent extrêmement bien ensemble. Que vous utilisiez l'image NGINX Open Source de Docker Hub ou que vous créiez votre propre image NGINX Plus, vous pouvez facilement créer de nouvelles instances de NGINX et NGINX Plus dans des conteneurs Docker et les déployer dans votre environnement Kubernetes. Vous pouvez également créer facilement de nouvelles images Docker à partir des images de base, ce qui rend vos conteneurs encore plus faciles à contrôler et à gérer. Assurez-vous que toutes les instances NGINX Plus exécutées dans vos conteneurs Docker sont couvertes par votre abonnement. Pour plus de détails, veuillez contacter l'équipe commerciale NGINX .
Docker est bien plus que ce que nous avons pu aborder dans cet article. Pour plus d'informations, téléchargez notre eBook gratuit O'Reilly – Container Networking : De Docker à Kubernetes – ou consultez www.docker.com .
« Cet article de blog peut faire référence à des produits qui ne sont plus disponibles et/ou qui ne sont plus pris en charge. Pour obtenir les informations les plus récentes sur les produits et solutions F5 NGINX disponibles, explorez notre famille de produits NGINX . NGINX fait désormais partie de F5. Tous les liens NGINX.com précédents redirigeront vers un contenu NGINX similaire sur F5.com."