Il s'agit là d'une pratique peu courante dans le domaine des conteneurs. Au lieu d'accéder directement au conteneur, une solution courante consiste à mettre en place un équilibreur de charge pour chaque IP à exposer, et cet équilibreur de charge fait correspondre un port bien connu au port unique. Dans l'espace cloud, cette solution est souvent moins coûteuse que l'allocation de plusieurs machines virtuelles avec des IP différentes.

Vous pouvez publier directement vers une adresse IP unique avec Docker, par exemple :

docker run -p 192.168.0.3:22:22 sshd

Pour cela, il faut que l'hôte ait configuré chacune des adresses IP décrites dans la section Autres questions et réponses sur les SE .

Si vous avez toujours besoin de la requête originale, exposant directement le conteneur, vous pouvez utiliser les pilotes réseau macvlan ou ipvlan pour donner au conteneur une IP accessible de l'extérieur. J'ai tendance à éviter cela car c'est souvent le symptôme d'une tentative de gérer un conteneur comme s'il s'agissait d'une VM. La documentation sur macvlan se trouve à l'adresse suivante https://docs.docker.com/network/macvlan/

Dans le cas où vous avez besoin d'IP sur les conteneurs, la solution la plus proche est réseau de passerelles Il existe plusieurs sous-types de ponts. IBM propose un exemple de l'un d'entre eux aquí . C'est mieux que ce que je pourrais expliquer. Maintenant, ce qu'ils font, c'est.. :

1. Créer un pont Linux sur l'hôte.

   brctl addbr br0 brctl addif br0 enp0s1 brctl setfd br0 0 ifconfig br0 192.168.0.0/24 netmask 255.255.255.0

*Omettre le pas pour le persister.

2. Vérifier ensuite que le pont est UP

   root@docker:~# brctl show br0 bridge name bridge id STP enabled interfaces br0 8000.42570a00bd6d no enp0s1 root@docker:~#

3. Créez le réseau ponté :

   docker network create --driver=bridge --ip-range=192.168.0.0/24 --subnet=192.168.0.0/24 -o "com.docker.network.bridge.name=br0" br0

** Ici, vous pouvez utiliser --aux-address pour exclure les ips de la plage. Vous devez également limiter le nombre de --subnet à un sous-ensemble plus restreint, mais tout dépend de vos besoins.

*** Il peut être utile de définir cette valeur par défaut. Cela est également expliqué dans le lien.

4. Démarrez votre (vos) conteneur(s) :

   docker run -it my/contianer

   • Des options telles que --ip et d'autres peuvent être utilisés ici. Aide Docker docker run --help |grep IP pourrait être utile à cet égard.
5. Une fois que le conteneur est en cours d'exécution, vous pouvez utiliser docker inspect <container_name> pour savoir si vous disposez d'une IP, puis pour tester la connectivité à ce conteneur, etc.

J'espère que cela vous aidera, n'hésitez pas à poser d'autres questions si vous en avez, ou si cela ne correspond pas à ce que vous voulez/à ce dont vous avez besoin, donnez un peu de contexte.

Tous mes conteneurs de production utilisent une telle configuration.

J'ai configuré un pont avec mon nic physique à l'intérieur (étapes 1 et 2 dans la réponse de @wti)

J'installe l'agent opensvc ( https://repo.opensvc.com ), créer un service ( svcmgr -s mygitlab create )

Je remplis la configuration du service ( svcmgr -s mygitlab edit config ) avec un extrait de configuration comme ci-dessous

[DEFAULT]
id = 0ce6aa9c-715f-113f-9c32-0fb32df00d49
orchestrate = start

[ip#0]
container_rid = container#0
gateway = 192.168.1.1
ipdev = br0
ipname = 192.168.1.3
netmask = 255.255.255.0
type = netns

[container#0]
type = docker
run_image = gitlab:latest
run_args = -i -t --net=none
        --hostname=gitlab.acme.com
    -v /etc/localtime:/etc/localtime:ro

Une fois cela fait, il suffit de démarrer le service ( svcmgr -s mygitlab start ) et vérifier l'état ( svcmgr -s mygitlab print status )

Lorsque c'est nécessaire, je déploie également une configuration de haute disponibilité, qui fait basculer le service docker sur un autre nœud en cas d'indisponibilité du premier nœud.