I am running a SHIR that is attached to Azure Synapse on a VM host that uses outbound port 443. I want to create a scheduled custom AzCopy service that also uses outbound port 443 on that same VM. Is this possible if the schedules of the AzCopy service and Synapse jobs don't overlap or does the SHIR occupies port 443 uninterrupted?
Since this is an outbound connection, the port is not "held" by self hosted integration runtime, and you can use it with other applications.
Related
I am running Azure DevOps Ubuntu self-hosted agent as container in the Container Instances. What are the minimum inbound and outbound network traffic rules so the agent can operate? I tried ports 80 and 443 TCP for both in and outbound but the container is still not able to find the DevOps Agent pool (it says [1;36m1. Determining matching Azure Pipelines agent...[0m).
As depicted here, only outbound HTTP(S) on port 443 is required.
I have an Azure VM, and a web application listening internally on port 32001. The VM is publicly accessible on a static IP address. I'm trying to route all traffic the VM receives on port 443 to its localhost port 32001. I am try to set it up in this screen, and my first idea was to edit the HTTPS rule. But no matter what I try, I can't seem to get a connection to my webapp. What am I supposed to do?
You can't do this using just VM. What you actually need is a Load Balancer in front of your Azure VM which takes care on port forwarding. An example you can find here and here. But in short, what you need to do is:
expose 32001 on your VM
create Load Balancer
add VM to backend pool in Load Balancer
configure port forwarding on this balancer
In inbound and outband rules you can configure what traffic is allowed, but you can't configure there port forwarding.
You can also check this topic
I have a http service listening in port 52205 in a azure ubuntu VM. The VM is assigned with a Network Security Group with the inbound and outbound values set as in the snapshot. Even then I couldn't telnet or access the http endpoints from my local machine.
According to your description, you should open port in Endpoints:
I have an Azure Container Service (Swarm). I am running a docker-compose with multiple http aspi and websites in it's definition. How can I configure the the swarm agent to allow inbound traffic to those apis? (they are running on different ports). By default I can access an api or a website under the 80 port only.
By default the Load Balancer has ports 80, 8080 and 443 open.If you
want to connect on another port you will need to open that port on the
Azure Load Balancer for the Agent Pool.
There is a document shows you how to open more ports for your applications in Azure Container Service.
I am new to Azure and trying to setup our companies testing environment in Azure.
As I understand it for two machines to talk to each other in Azure they need to be in the same cloud service, i.e. our web server and DB server.
So I have created a service, then created each of the VM's in that service. They are both running. In the endpoints I can see:
web server:
NAME PROTOCOL PUBLIC PORT PRIVATE PORT LOAD-BALANCED SET NAME
HTTP TCP 80 80 -
HTTPS TCP 443 443 -
PowerShell TCP 5986 5986 -
Remote Desktop TCP 50232 3389 -
db server:
NAME PROTOCOL PUBLIC PORT PRIVATE PORT LOAD-BALANCED SET NAME
MSSQL TCP 1433 1433 -
PowerShell TCP 54327 5986 -
Remote Desktop TCP 52459 3389 -
in the cloud service the input areas
INPUT ENDPOINTS
protoApp : 123.456.789.227:80
protoApp : 123.456.789.227:443
protoApp : 123.456.789.227:5986
protoApp : 123.456.789.227:50232
protodb : 123.456.789.227:1433
protodb : 123.456.789.227:54327
protodb : 123.456.789.227:52459
I can connect to the protodb server but not the protoapp server (on the given ports).
There are two / three questions really.
Should they both be in the same cloud service?
Should the live DB and web server be in a seperate cloud server (not created them yet)
Can anyone think of a reason why I can no longer MSTSC / rdp to one of the machines, even though the endpoints say its all fine, the machine is running and the cloud service says it has it as an endpoint.
No reason why not, though you should look at creating a Virtual Network to connect them
You should consider this if
Performance dictates it
You want extra security - consider somebody hacks the web server, they then immediately have access to the same server that hosts the data. Really you should restrict the incoming IPs for MSSQL to something trusted anyway, or the same subnet if you use a Virtual Network
Cost is not an issue
I've sometimes had trouble using mstsc to directly connect via RDP to Azure VMs. If you go to http://manage.windowsazure.com and navigate to your VM, there will be a "Connect" option at the bottom. This will download a .rdp file which might help.
Something else worth noting, If you're using Azure VMs, you won't qualify for Microsoft's uptime SLA unless you have two or more VMs per cloud service configured as part of an Availability Set. So straight away you should consider that the number of VMs you're planning will double if you want to have a production/highly available environment, and you should consider the impact this will have on your application architecture too.