Files
landing-web/content/docs/orchestration/mapping-de-ports.mdx
T
leonm 1542a991b9
CI / 🔍 Lint & Type Check (push) Successful in 2m11s
CI / 🐳 Build & Push Image (push) Successful in 1m16s
feat: docs
2026-07-17 16:15:54 +02:00

72 lines
1.8 KiB
Plaintext

---
title: Mapping de ports
description: Publier un port du conteneur vers l'hôte sans exposer toute la stack.
---
## Réseau interne et monde extérieur
Le réseau bridge est privé. Les services communiquent entre eux, mais le navigateur ou le terminal de l'hôte ne peut pas les joindre tant qu'aucun port n'est publié.
```yaml
services:
nginx:
ports:
- "8080:80"
- "8443:443"
```
La syntaxe est :
```text
PORT_HÔTE:PORT_CONTENEUR
```
`8443:443` redirige le port 8443 de la machine vers le port 443 écouté par Nginx dans le conteneur.
## Exposer uniquement le point d'entrée
Dans une stack classique, PostgreSQL, le backend et le frontend n'ont pas forcément de section `ports:`. Ils restent accessibles depuis le réseau Docker, mais pas depuis l'extérieur.
Seul Nginx publie un port. Il devient le point d'entrée et route ensuite les requêtes vers les services internes.
```text
navigateur
port publié de Nginx
├──► frontend
└──► backend ──► postgres
```
## Éviter les collisions
Le port interne d'un service reste le même, tandis que le port hôte peut changer :
```yaml
# Stack A
ports:
- "8443:443"
# Stack B
ports:
- "8444:443"
```
Ce principe permet à plusieurs workers de test de lancer la même stack sur des plages de ports différentes.
## Restreindre une publication à la machine
```yaml
services:
postgres:
ports:
- "127.0.0.1:15432:5432"
```
Le préfixe `127.0.0.1` rend le port accessible depuis le serveur pour la maintenance, sans l'ouvrir sur l'adresse publique.
<Callout title="Principe de sécurité" type="warning">
Ne publie pas une base de données sur toutes les interfaces sans nécessité. Sans le préfixe 127.0.0.1, un mapping comme 5432:5432 peut exposer PostgreSQL sur Internet si le pare-feu le permet.
</Callout>