Une brève analyse des raisons et des précautions pour que Docker Run ne soit pas cartographié

Docker est une plateforme qui permet aux applications de s'exécuter dans des conteneurs isolés et portables. Il utilise certaines fonctionnalités du noyau Linux pour implémenter une virtualisation légère et réaliser une isolation logicielle. Pour cette raison, Docker a été largement utilisé dans le domaine du déploiement de logiciels en raison de son conteneur léger.

Lorsque nous exécutons un conteneur dans Docker, nous n'avons parfois pas besoin de mapper le port du conteneur à l'hôte. Cet article présentera certaines situations et précautions lorsque le port n'est pas mappé lorsque Docker exécute le conteneur.

Le cas de non-mapping du port

Dans certains scénarios, le cas de non-mapping du port peut être très utile. La situation la plus courante consiste à utiliser Docker pour exécuter des services en arrière-plan. Par exemple, nous pouvons utiliser la commande suivante pour démarrer un serveur Nginx :

docker run -d nginx

Cette commande démarrera un conteneur Nginx en arrière-plan et démarrera un processus Nginx dans le conteneur. Cependant, pour le moment, le conteneur Nginx ne mappe pas le port 80 du conteneur à l'hôte. Cela signifie que nous ne pouvons pas accéder à cette instance Nginx en accédant au port 80 de la machine hôte.

Un autre scénario courant consiste à utiliser Docker pour exécuter certains programmes d'outils. Nous pouvons utiliser la commande suivante pour démarrer un conteneur Ubuntu capable d'exécuter des scripts bash :

docker run -it ubuntu bash

Cette commande démarrera un conteneur Ubuntu en mode interactif et entrera le processus bash dans le conteneur. Pour le moment, nous n'avons pas besoin de mapper le port du conteneur sur l'hôte.

Remarques sur la non-cartographie des ports

Bien qu'il soit pratique de ne pas mapper les ports dans certains scénarios, nous devons faire attention aux problèmes suivants :

Le conteneur n'est pas accessible depuis l'hôte et d'autres réseaux

Lorsque le conteneur ne le fait pas Si nous avons un port mappé, nous ne pouvons pas accéder au conteneur via la machine hôte et d'autres machines d'autres réseaux. Cela signifie que si nous devons accéder à l'application à l'intérieur du conteneur depuis l'extérieur de l'hôte, nous devons mapper le port du conteneur sur l'hôte.

L'application dans le conteneur doit toujours écouter sur le port

Bien que le port du conteneur ne soit pas mappé sur l'hôte, l'application exécutée dans le conteneur doit toujours écouter sur le port. En effet, l'application à l'intérieur du conteneur doit gérer les requêtes réseau.

Le conteneur a toujours des capacités d'accès au réseau

Même si nous ne mappons pas le port du conteneur à l'hôte, le conteneur a toujours des capacités d'accès au réseau. Cela signifie que les applications à l'intérieur du conteneur peuvent accéder aux services sur d'autres réseaux, tels que des bases de données ou des services Web.

Conclusion

Lors de l'exécution d'un conteneur dans Docker, nous n'avons pas nécessairement besoin de mapper le port du conteneur à l'hôte. Ne pas mapper les ports peut être très utile pour les services d'arrière-plan ou certains programmes utilitaires. Cependant, il convient de noter que si vous devez accéder à l'application à l'intérieur du conteneur depuis l'extérieur, vous devez mapper le port du conteneur sur l'hôte. Dans le même temps, l'application exécutée dans le conteneur doit toujours écouter le port pour s'assurer qu'elle peut gérer normalement les requêtes réseau.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!