Déployer NGINX et NGINX Plus avec Docker

NGINX | 09 novembre 2021


Note de la rédaction – Les Dockerfiles NGINX Plus pour Alpine Linux et Debian ont été mis à jour en novembre 2021 afin de prendre en compte les dernières versions des logiciels. Ils utilisent également, avec les instructions révisées, les secrets Docker pour transmettre les informations de licence lors de la création d’une image NGINX Plus.

Docker est une plateforme ouverte permettant de créer, de distribuer et d’exécuter des applications distribuées sous forme de conteneurs (des progiciels légers, autonomes et exécutables qui comprennent tout le nécessaire pour faire fonctionner une application). Les conteneurs peuvent ensuite être déployés et orchestrés par des plateformes d’orchestration de conteneurs telles que Kubernetes. (Outre la technologie de conteneurs Docker abordée dans cet article de blog, NGINX propose le F5 NGINX Ingress Controller dans des 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 se prêtent parfaitement à une utilisation avec Docker, et nous publions une image NGINX Open Source sur Docker Hub, le référentiel d’images Docker. Cet article explique comment :

Introduction

La plateforme ouverte Docker comprend Docker Engine, le moteur d’exécution open source qui crée, exécute et orchestre les conteneurs, ainsi que Docker Hub, un service hébergé sur lequel les applications conteneurisées avec Docker sont distribuées, partagées et développées de manière collaborative par l’ensemble de la communauté des développeurs ou au sein d’une organisation donnée.

Les conteneurs Docker permettent aux développeurs de concentrer leurs efforts sur le « contenu » des applications en affranchissant celles-ci des contraintes liées à l’infrastructure. Les applications conteneurisées avec Docker sont instantanément portables sur n’importe quelle infrastructure – ordinateur portable, serveur physique, machine virtuelle ou cloud –, ce qui en fait des composants modulaires pouvant être facilement assemblés et réassemblés pour créer des applications distribuées complètes, susceptibles d’évoluer en permanence et en temps réel.

Pour en savoir plus sur Docker, consultez « Pourquoi Docker ? » ou la documentation complète de Docker.

Utilisation de l’image Docker NGINX Open Source

Vous pouvez créer une instance NGINX dans un conteneur Docker à l’aide de l’image NGINX Open Source disponible sur Docker Hub.

Commençons par un exemple très simple. Pour lancer une instance de NGINX dans un conteneur avec la configuration NGINX par défaut, exécutez la commande suivante :

# docker run --name mynginx1 -p 80:80 -d nginxfcd1fb01b14557c7c9d991238f2558ae2704d129cf9fb97bb4fadf673a58580d

Cette commande crée un conteneur nommé « mynginx1 » à partir de l’image NGINX. Elle renvoie la forme longue de l’identifiant du conteneur, qui est utilisée dans le nom des fichiers journaux ; consultez la section « Gestion de la journalisation ».

L’option « -p » indique à Docker d’associer 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 sur l’hôte Docker, tandis que le second correspond au port exposé dans le conteneur.

L’option « -d » indique que le conteneur s’exécute en mode détaché, ce qui signifie qu’il continue de fonctionner jusqu’à ce qu’il soit arrêté, mais ne répond pas aux commandes exécutées depuis la ligne de commande. Dans la section suivante, nous expliquons comment interagir avec le conteneur.

Pour vérifier que le conteneur a bien été créé et qu’il est en cours d’exécution, ainsi que pour afficher les mappages de ports, nous exécutons docker ps. (Nous avons réparti la sortie sur plusieurs lignes afin d’en faciliter la lecture.)

# docker psCONTAINER ID  IMAGE         COMMAND               CREATED         STATUS        ...  
fcd1fb01b145  nginx:latest  "nginx -g 'daemon of  16 seconds ago  Up 15 seconds ... 

    ... PORTS              NAMES
    ... 0.0.0.0:80->80/tcp mynginx1

Le champ « PORTS » dans la sortie indique que le port 80 de l’hôte Docker est associé au port 80 du conteneur. Une autre façon de vérifier que NGINX est en cours d’exécution consiste à envoyer une requête HTTP à ce port. Le code de la page d’accueil par défaut de NGINX s’affiche :

# curl http://localhost<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
 body {
 width: 35em;
 margin: 0 auto;
 font-family: Tahoma, Verdana, Arial, sans-serif;
 }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="https://www.nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

Utiliser le conteneur Docker NGINX

Nous disposons maintenant d’un conteneur Docker NGINX opérationnel, mais comment gérer le contenu et la configuration de NGINX ? Et qu’en est-il de la journalisation ?

Remarque concernant SSH

Il est courant d’activer l’accès SSH aux instances NGINX, mais OpenSSH n’est pas installé dans l’image NGINX, car les conteneurs Docker sont généralement conçus pour remplir une seule fonction (dans ce cas, exécuter NGINX). Nous utiliserons donc d’autres méthodes prises en charge par Docker.

Au lieu d’utiliser les commandes ci-dessous, vous pouvez exécuter la commande suivante pour ouvrir un shell interactif dans un conteneur NGINX en cours d’exécution (plutôt que de démarrer une session SSH). Toutefois, nous recommandons cette méthode uniquement aux utilisateurs expérimentés.

  • Sur les systèmes Alpine Linux :
# docker exec -it NGINX_container_ID sh
  • Sur les systèmes Debian :
# docker exec -it NGINX_container_ID bash

Gestion du contenu et des fichiers de configuration

Il existe plusieurs façons de gérer à la fois le contenu diffusé par NGINX et les fichiers de configuration de NGINX. Nous présentons ici quelques-unes des options disponibles.

Option 1 – Gérer le contenu et la configuration sur l’hôte Docker

Lors de la création du conteneur, nous pouvons demander à Docker de monter un répertoire local de l’hôte Docker dans un répertoire du conteneur. L’image NGINX utilise la configuration NGINX par défaut, qui définit /usr/share/nginx/html comme répertoire racine du conteneur et place les fichiers de configuration dans /etc/nginx. Pour un hôte Docker dont le contenu se trouve dans le répertoire local /var/www et les fichiers de configuration dans /var/nginx/conf, exécutez la commande suivante (présentée ici sur plusieurs lignes uniquement pour en faciliter la lecture) :

# 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 des répertoires locaux /var/www et /var/nginx/conf sur l’hôte Docker est répercutée dans les répertoires /usr/share/nginx/html et /etc/nginx du conteneur. L’option readonly signifie que ces répertoires peuvent uniquement être modifiés sur l’hôte Docker, et non depuis le conteneur.

Option 2 – Copier des fichiers depuis l’hôte Docker

Une autre option consiste à demander à Docker de copier les fichiers de contenu et de configuration depuis un répertoire local de l’hôte Docker lors de la création du conteneur. Une fois le conteneur créé, les fichiers sont tenus à jour en créant un nouveau conteneur lorsqu’ils sont modifiés ou en les modifiant directement dans le conteneur. Un moyen simple de copier les fichiers consiste à créer un fichier Dockerfile contenant des commandes 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 fichiers (COPY) du fichier Dockerfile, le chemin du répertoire local est relatif au contexte de build dans lequel se trouve le fichier Dockerfile.

Dans notre exemple, le contenu se trouve dans le répertoire content et les fichiers de configuration dans le répertoire conf, tous deux étant des sous-répertoires du répertoire où se trouve le fichier Dockerfile. L’image NGINX inclut les fichiers de configuration NGINX par défaut /etc/nginx/nginx.conf et /etc/nginx/conf.d/default.conf. Comme nous souhaitons utiliser à la place les fichiers de configuration de l’hôte, nous incluons une commande RUN qui supprime les fichiers par défaut :

FROM nginx
RUN rm /etc/nginx/nginx.conf /etc/nginx/conf.d/default.conf
COPY content /usr/share/nginx/html
COPY conf /etc/nginx

Nous créons notre propre image NGINX en exécutant la commande suivante depuis le répertoire où se trouve le fichier Dockerfile. Notez le point (« . ») à la fin de la commande. Il définit le répertoire courant comme contexte de build, lequel contient le fichier Dockerfile ainsi que les répertoires à copier.

# docker build -t mynginx_image1 .

Nous exécutons maintenant cette commande pour créer un conteneur nommé « mynginx3 » à partir de l’image « mynginx_image1 » :

# docker run --name mynginx3 -p 80:80 -d mynginx_image1

Si nous souhaitons modifier les fichiers du conteneur, nous utilisons un conteneur auxiliaire comme décrit dans l’option 3.

Option 3 – Gérer les fichiers dans le conteneur

Comme indiqué dans « Remarque concernant SSH », nous ne pouvons pas utiliser SSH pour accéder au conteneur NGINX. Par conséquent, si nous souhaitons modifier directement les fichiers de contenu ou de configuration, nous devons créer un conteneur auxiliaire disposant d’un accès au shell. Pour que ce conteneur puisse accéder aux fichiers, nous devons créer une nouvelle image dans laquelle les volumes de données Docker appropriés sont définis. Si nous souhaitons copier les fichiers comme dans l’option 2 tout en définissant des volumes, nous utilisons le Dockerfile suivant :

FROM nginxRUN rm /etc/nginx/nginx.conf /etc/nginx/conf.d/default.conf
COPY content /usr/share/nginx/html
COPY 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) :

# docker build -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 auxiliaire « mynginx4_files » doté d’un shell, ce qui nous permet 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/bashroot@b1cbbad63dd1:/#

Le nouveau conteneur auxiliaire mynginx4_files s’exécute au premier plan avec une entrée standard persistante (option -i) et un terminal tty (option -t). Tous les volumes définis dans mynginx4 sont montés en tant que répertoires locaux dans le conteneur auxiliaire.

L’argument « debian » signifie que le conteneur auxiliaire utilise l’image Debian de Docker Hub. Comme l’image NGINX utilise également Debian (et que tous nos exemples jusqu’à présent utilisent l’image NGINX), il est plus efficace d’utiliser Debian pour le conteneur auxiliaire plutôt que de demander à Docker de charger un autre système d’exploitation. L’argument « /bin/bash » signifie que le shell bash s’exécute dans le conteneur auxiliaire et affiche une invite de commande 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 start mynginx4_files# docker stop mynginx4_files

Pour quitter le shell tout en laissant le conteneur s’exécuter, appuyez sur Ctrl+p puis sur Ctrl+q. Pour accéder de nouveau au shell d’un conteneur en cours d’exécution, exécutez cette commande :

# docker attach mynginx4_files

Pour quitter le shell et arrêter le conteneur, exécutez la commande « exit ».

Gestion de la journalisation

Vous pouvez configurer la journalisation par défaut ou la personnaliser.

Utilisation de la journalisation par défaut

L’image NGINX est configurée par défaut pour envoyer les principaux journaux d’accès et d’erreurs de NGINX au collecteur de journaux Docker. Pour ce faire, ils sont liés respectivement à stdout et stderr ; tous les messages des deux journaux sont ensuite écrits dans le fichier /var/lib/docker/containers/container-ID/container-ID-json.log sur l’hôte Docker, où container‑ID est l’identifiant au format long renvoyé lors de la création d’un conteneur. Par exemple, pour le premier conteneur créé dans Utilisation de l’image Docker NGINX Open Source, il s’agit de fcd1fb01b14557c7c9d991238f2558ae2704d129cf9fb97bb4fadf673a58580d.

Pour récupérer l’ID d’un conteneur existant, exécutez cette commande, où container‑name correspond à la valeur définie par le paramètre --name lors de la création du conteneur (pour l’ID de conteneur ci-dessus, par exemple, il s’agit de mynginx1 ):

# docker inspect --format '{{ .Id }}' container-name

Bien que vous puissiez consulter les journaux en ouvrant directement le fichier container-ID-json.log, il est généralement plus simple d’exécuter cette commande :

# docker logs container-name

Vous pouvez également utiliser l’API Docker Engine pour extraire les messages des journaux en envoyant une requête GET au socket Unix de Docker. Cette commande renvoie à la fois le journal d’accès (représenté par stdout=1) et le journal d’erreurs (stderr=1), mais vous pouvez aussi les demander séparément :

curl --unix-socket /var/run/docker-sock http://localhost/containers/container-name/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 « Get container logs » sur cette page).

Utilisation de la journalisation personnalisée

Si vous souhaitez mettre en œuvre une autre méthode de collecte des journaux, ou 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 auxiliaire pour accéder à ces fichiers et utilisez les outils de journalisation de votre choix. Pour ce faire, créez une nouvelle image contenant le ou les volumes destinés aux fichiers journaux.

Par exemple, pour configurer NGINX afin qu’il stocke les fichiers journaux dans /var/log/nginx/log, nous pouvons partir du Dockerfile de l’option 3 et simplement ajouter une directive VOLUME pour ce répertoire :

FROM nginxRUN rm /etc/nginx/nginx.conf /etc/nginx/conf.d/default.conf
COPY content /usr/share/nginx/html
COPY 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 auxiliaire ayant accès au répertoire des journaux. Tous les outils de journalisation souhaités peuvent être installés dans le conteneur auxiliaire.

Contrôle de NGINX

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 de NGINX, exécutez la commande suivante :

# docker kill -s HUP container-name

Pour redémarrer NGINX, exécutez cette commande afin de redémarrer le conteneur :

# docker restart container-name

Déploiement de NGINX Plus avec Docker

Jusqu’à présent, nous avons abordé l’utilisation de Docker avec 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, cette opération est assez simple.

Remarque : Ne téléversez jamais vos images NGINX Plus vers un dépôt public tel que Docker Hub. Cela constituerait une violation de votre contrat de licence.

Création d’une image Docker de NGINX Plus

Pour générer une image NGINX Plus, commencez par créer un fichier Dockerfile. Les exemples fournis ici utilisent Alpine Linux 3.14 et Debian 11 (Bullseye) 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 bénéficiez d’un essai gratuit de NGINX Plus, ils sont inclus dans votre package d’essai. Copiez les fichiers dans le répertoire où se trouve le fichier Dockerfile (le contexte de build Docker).

Comme avec NGINX Open Source, les journaux d’accès et d’erreurs de NGINX Plus sont liés par défaut au collecteur de journaux Docker. Aucun volume n’est spécifié, mais vous pouvez en ajouter si vous le souhaitez. Vous pouvez également utiliser chaque fichier Dockerfile pour créer des images de base à partir desquelles vous pourrez créer de nouvelles images avec des volumes spécifiés, comme décrit précédemment.

Nous avons délibérément choisi de ne pas spécifier de version de NGINX Plus dans les exemples de fichiers Dockerfile afin que vous n’ayez pas à modifier le fichier lors de la mise à jour vers une nouvelle version de NGINX Plus. Nous avons toutefois inclus des versions commentées des instructions concernées, que vous pouvez décommenter si vous souhaitez que le fichier soit propre à une version donnée.

De même, nous avons inclus des instructions (mises en commentaire) permettant d’installer les modules dynamiques officiels pour NGINX Plus.

Par défaut, aucun fichier n’est copié depuis l’hôte Docker lors de la création d’un conteneur. Vous pouvez ajouter des instructions « COPY » à chaque fichier « Dockerfile », ou utiliser l’image que vous créez comme base pour une autre image, comme décrit ci-dessus.

Dockerfile NGINX Plus (Debian 11)

Chargement de l’exemple de code…

Dockerfile NGINX Plus (Alpine Linux 3.14)

Chargement de l’exemple de code…

Création de l’image NGINX Plus

Avec le fichier Dockerfile, ainsi que les fichiers nginx-repo.crt et nginx-repo.key dans le même répertoire, exécutez-y la commande suivante pour créer une image Docker nommée nginxplus (comme précédemment, notez le point final) :

# DOCKER_BUILDKIT=1 docker build --no-cache -t nginxplus --secret id=nginx-crt,src=your_cert_file --secret id=nginx-key,src=your_key_file .

L’indicateur « DOCKER_BUILDKIT=1 » indique que nous utilisons Docker BuildKit pour créer l’image, comme requis lors de l’utilisation de l’option --secret, 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 déjà été utilisé pour créer une image et que vous n’incluez pas l’option --no-cache, la nouvelle image utilise la version de NGINX Plus provenant du cache Docker. (Comme indiqué, nous ne spécifions volontairement aucune version de NGINX Plus dans le Dockerfile afin de ne pas avoir à modifier le fichier à chaque nouvelle version de NGINX Plus.) Omettez l’option --no-cache s’il est acceptable d’utiliser la version de NGINX Plus provenant de l’image créée précédemment.

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 ni de les conserver 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 aux fichiers de certificat et de clé NGINX Plus (le même répertoire que celui dans lequel vous créez l’image Docker si vous avez suivi les instructions précédentes).

Une sortie semblable à la suivante de la commande « docker images nginxplus » indique que l’image a été créée avec succès :

# docker images nginxplus
REPOSITORY  TAG     IMAGE ID      CREATED        VIRTUAL SIZE
nginxplus   latest  ef2bf65931cf  6 seconds ago  91.2 MB

Pour créer un conteneur nommé « mynginxplus » à partir de cette image, exécutez la commande suivante :

# 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.

Résumé

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 lancer 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 simplifie encore davantage le contrôle et la gestion de vos conteneurs. Assurez-vous que toutes les instances NGINX Plus exécutées dans vos conteneurs Docker sont couvertes par votre abonnement. Pour plus d’informations, veuillez contacter l’équipe commerciale de NGINX.

Docker offre bien plus de possibilités que celles que nous avons pu aborder dans cet article. Pour en savoir plus, téléchargez gratuitement notre livre numérique O’Reilly – « Réseaux de conteneurs : de Docker à Kubernetes » – ou consultez www.docker.com.

Documentation connexe

Déploiement de NGINX et de NGINX Plus sur Docker


Partager
Mots-clés : F5 NGINX, 2021, Tech

À propos de l’auteur

Rick Nelson
Rick NelsonVice-président régional, ingénierie des solutions

Autres articles de Rick Nelson

Articles de blog associés

Tendances actuelles des technologies cloud natives, de l’ingénierie de plateforme et de l’IA
NGINX | 13/10/2025

Tendances actuelles des technologies cloud natives, de l’ingénierie de plateforme et de l’IA

Découvrez les principaux enseignements tirés des réponses à l’enquête annuelle F5 NGINX sur les dernières tendances en matière de technologies cloud natives, de sécurité, d’ingénierie de plateforme et d’IA.

Quels contrôleurs Ingress NGINX sont affectés par les vulnérabilités CVE-2022-4886, CVE-2023-5043 et CVE-2023-5044 ?
NGINX | 03/11/2023

Quels contrôleurs Ingress NGINX sont affectés par les vulnérabilités CVE-2022-4886, CVE-2023-5043 et CVE-2023-5044 ?

Lorsque de nouvelles CVE sont signalées, il est facile de ne plus savoir si elles concernent un outil de contrôleur Ingress NGINX particulier, car il existe plusieurs projets. Cet article présente les CVE et explique comment distinguer les différents projets de contrôleurs Ingress afin de dissiper toute confusion.

Votre API est-elle en temps réel ? Testez sa latence avec l’outil rtapi de NGINX
NGINX | 11/03/2020

Votre API est-elle en temps réel ? Testez sa latence avec l’outil rtapi de NGINX

Votre API répond-elle aux requêtes en moins de 30 ms ? Si ce n’est pas le cas, il ne s’agit pas d’une API en temps réel offrant la faible latence exigée par la grande majorité des organisations. Mesurez la latence de votre API avec l’outil rtapi de NGINX et découvrez comment NGINX peut l’aider à offrir une réactivité en temps réel.

Un testeur d’expressions régulières pour NGINX et NGINX Plus
NGINX | 11/06/2019

Un testeur d’expressions régulières pour NGINX et NGINX Plus

Le testeur d’expressions régulières (regex) pour NGINX et NGINX Plus vous évite de tâtonner en vous indiquant si une expression régulière utilisée dans un bloc location ou map correspond aux valeurs comme prévu. Il génère la configuration appropriée et affiche les valeurs des groupes de capture.

Caches partagés avec les clusters de cache NGINX Plus, partie 1
NGINX | 24/01/2017

Caches partagés avec les clusters de cache NGINX Plus, partie 1

Optimisez la capacité de votre cache web en le répartissant entre plusieurs serveurs de cache web NGINX ou NGINX Plus. Découvrez comment procéder dans cet article.

Introduction aux microservices
NGINX | 19/05/2015

Introduction aux microservices

Les microservices suscitent actuellement beaucoup d’intérêt. Cet article de blog est le premier d’une série de sept consacrée à la conception, au développement et au déploiement de microservices.