goharbor / harbor

An open source trusted cloud native registry project that stores, signs, and scans content.
https://goharbor.io
Apache License 2.0
24.12k stars 4.76k forks source link

Configure the harbor network at install time #20866

Open yilas opened 2 months ago

yilas commented 2 months ago

Hello 👋🏻

I have a VM located in a DMZ with an address in the 172.20.0.0/24 subnet. I need to access a Harbor instance hosted on a different VM with a completely different address. The issue I'm facing is that the network created by Docker Compose uses a range within 172.20.0.0/16, which is causing conflicts.

Is there a way to designate a specific network for the Harbor deployment, rather than having to adjust the Docker daemon settings initially ?

We could imagine a specific configuration in the harbor.yml for the network. For instance :

networks:
  harbor:
    subnet: 172.22.0.0/16
    gateway: 172.22.0.1

which might render the following docker-compose file :

networks:
  harbor:
    external: false
    driver: bridge
    ipam:
      config:
        - subnet: 172.22.0.0/16
          gateway: 172.22.0.1

Thank you for your help !

MinerYang commented 2 months ago

Hi @yilas,

I don't quite understand your questions. The networks setting you listed above I believe is a internal network that used to route within Harbor containers. All out-coming traffic would proxy to Nginx server. Maybe you could do some invest there to see any configs would meet your requirements.

yilas commented 2 months ago

Hello @MinerYang,

Thank you for your reply. You're right, the networks network is the internal network used by the Harbor containers. Unfortunately, it happens that the range of this network (or subnet) can be used by other networks, which can cause problems if a connection comes from this particular network. This is why I was wondering if it was possible to change/add a setting in the harbor.yml file in order to force the addressing plan used by the Harbor containers.

github-actions[bot] commented 1 week ago

This issue is being marked stale due to a period of inactivity. If this issue is still relevant, please comment or remove the stale label. Otherwise, this issue will close in 30 days.