So if I understand your scenario correctly, you would like to avoid sharing your host's network to your gitlab container to make sure gitlab cannot connect to the internet. At the same time you wish to share the host's network to bind a container port to your host system. It doesn't work that way, but the following might be an acceptable workaround for you: docker containers sharing the same internal network can connect to exposed/published ports of other containers on the same network.
You could follow this approach:
- Run a reverse proxy in front of your gitlab container
- The reverse proxy is member of your internal network and the default bridge network (which includes the host's net)
- This enables the reverse proxy to bind to a host port and forward requests to your gitlab container while gitlab still can't access the internet
I quickly put this example together, hope that gets you started:
docker network create --internal --subnet 10.1.1.0/24 no-internet
docker network create internet
docker-compose.yml:
version: '2' services: whoami: image: jwilder/whoami container_name: whoami networks: - no-internet proxy: image: nginx:1.13-alpine container_name: proxy networks: - internet - no-internet volumes: - ./vhost.conf:/etc/nginx/conf.d/default.conf ports: - "80:80" networks: internet: external: name: internet no-internet: external: name: no-internet
vhost.conf:
upstream whoami { server whoami:8000; } server { server_name localhost; listen 80; location / { proxy_pass http://whoami; } }
Please note the above mentioned internet network is actually not needed, as a docker container shares the host network by default anyway. It's just there to make things clearer.
In the example depicted above, open http://localhost/ and you will see the response of the whoami container, the whoami container itself however can't connect to the internet.
--network no-interneton thedocker runcommand? And in that case I think you could drop the last two commands.--internaland a published port working together.no-internet.