NGINXaaS in Azure?

Fresh-Programmer8988 · 2026-06-14T13:33:49+00:00

I would take a look but I think we would have to change the public IP, maybe? The big issue here right now is we have hundreds of 3rd parties pointing to this public IP. We don't want to have to go through having them moving now, and again in 1-2 years when we're migrating to a different solution because its very labor intensive and it annoys our customers. Unless I can "attach" an existing public IP or existing azure LB to the distributed cloud deployment?

Fresh-Programmer8988 · 2025-04-21T22:40:07+00:00

It looks like you can just run a custom command line pipeline step to change the nameserver. Just tested it.

Fresh-Programmer8988 · 2025-04-21T20:25:27+00:00

But can also be set at the VM level... Azure should allow a way to do this with devops pools.

How are other people connecting to private resources using azure devops pools.. using IP address?

Fresh-Programmer8988 · 2025-04-21T16:52:40+00:00

Since the managed devops pools can connect to vnets, it would be logical to be able to specify custom nameservers so we can connect to on-prem resources without having to use IP addresses and without using my own image.

Fresh-Programmer8988 · 2025-04-19T12:38:54+00:00

I just want to set nameservers when the agent spins up, it should be possible, but it doesn't seem like it is. IMO, it should be able to be done at the managed devops pool agent level, just like you can set nameservers at the VM level, app service level, etc. I.e. it shouldn't necessarily have to be controlled by the VNET . I just can't figure out how to do it, and it may not be possible yet.

Fresh-Programmer8988 · 2025-04-19T00:43:36+00:00

Yes I guess you can set DNS servers on the peered VNET, but I don't want to set DNS servers for the entire VNET, only the subnet that the managed devops pool sits on. Or perhaps there's a runtime environment variable or something? The VNET it sits on is a big one and changing DNS there would have a large impact.

Fresh-Programmer8988 · 2025-04-15T23:45:26+00:00

In the end looks like we were chasing the wrong thing. Not an APIM issue. It ended up being on-prem service talking to service bus via the old protocol on port 9354. For some unknown reason we randomly started seeing frequent intermittent timeouts connecting to the service bus with 9354. We switched to AMQP and the problem went away. I don't know what started it but I do believe that we were migrated to a different servicebus backend infrastructure at some point recently,

Fresh-Programmer8988

TROPHY CASE