This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(9.6, 75%, 10%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ES%3C/text%3E%3C/svg%3E)
Dear Community,
I would like to set up gitlab and other cicd tooling in one spoke-subscription and make the URLs accessible across all spoke-subscriptions via private IP address or FQDN. I do not wish to setup CICD tools (opensource) in the Hub but in the Spoke however, wish to make it accessible via private network and should be reachable from on-prem as well.
Please let me know the best possible solution to overcome this challenge.
EDIT: The hub subscription is used as expressroute endpoint and for management (bastion hosts), and other network-related setup by grouping them as "resource groups"
Thanks
SB.
An Azure networking service that is used to provision private networks and optionally to connect to on-premises datacenters.
Answer accepted by question author
@Sabs ,
I would suggest to go with Hub and spoke architecture. Place your Gitlab in HUB VNET and peer HUB with all spoke VNET and connect HUB to On-Premises. By doing this the Gitlab can be accessed by On-Prem as well as spoke VNETs.
Thanks for your reply @msrini-MSFT .
I am sorry, this is not a feasible option for us. :)
Like I said, we have to host it as spoke and make it available across all subscriptions e.g. think of exposing the URL as an API.
In Azure, when you do VNET peering transit doesn't work. Which means, when you connect A -> B then B -> C, A to C will not be connected directly. If you want to host it in a spoke VNET, then you need to create mesh kind of topology to establish connectivity between VNETs
Hi,
I do get your point and I am also aware of the limitation hence the question was very specific to use spoke to spoke.
What is your view about using API management and exposing the cicd tooling URL as Api's. to all spoke?
Even if you have APIM, and expose them over private IPs, you will still need IP connectivity to the APIM endpoint which you need to provide. Spoke to spoke peering needs to be there so that IP connectivity is provided.
Alright, makes sense.
So, are we saying if I put up an application gateway in conjunction with API management on a spoke, then the same URL still couldn't be accessible to other spokes?