I'm getting started using docker-machine on my Windows 2016 box. I'm trying to create some VMs in Azure but I have a particular network security group that I want for it to use and which already exists in Azure. I ran docker-machine create --driver azure and looked over the small help text which tells me how to set the resource group, subnet, etc but I don't see an option for network security group. Is there a way to specify an existing network security group for docker-machine to use when creating VMs in Azure?
Ok, so according to the documentation, you should use Subnet\VNet or Availability Set. The reason you are asking this is because you don't understand how NSG's work in Azure. NSG's are attached to a VNet or Subnet, so deploying a VM\Container into that Subnet\VNet will effectively attach that NSG to the entity you are deploying. But as the documentation states - "Once the machine is created, you can modify Network Security Group rules and open ports of the machine from the Azure Portal.".
So I suppose it creates a new NSG each time you deploy something, so there's no way to achieve that what you are trying (at least for now).
What you could try is deploy to an existing VNet and check if no new NSG are being created specifically for that container host which you are deploying. If that holds and you have an NSG in place, you've achieved what you want exactly.
Related
I know NSG can easily do that, but for some reason I can not use NSG, is there any other alternative can do the same? Firewall within VM might also work, but it's better to control that in Azure level, so I don't have to login to the VM so config that.
You can use Application Security Group (ASG). ASGs are used within a NSG to apply a network security rule to a specific VM or a group of VMs.
You can start here https://learn.microsoft.com/en-us/azure/virtual-network/application-security-groups
I already have a resource group in azure that has a virtual machine and it is associated with a network interface to connect to a vnet in that group.
resource-group-1
-> virtual machine
-> network interface
-> vnet
-> other things ...
But now i created a second resource group which will have some resources and a vnet. I want to use for now, the same virtual machine that exists on resource-group-1, so i created a network interface there:
resource-group-2
-> network interface 2
-> vnet 2
Now i want to connect the network interface 2 of resource-group-1 to the virtual machine in resource-group-2.
I already tried, like the documentation says to stop the VM and going to Settings, Networking and Attach network interface, but i don't seem to be able to select anything useful there.
It seems that some time ago, this changes could only be done through powershell.
Another thing i saw is that we cannot change the vnet when adding a new nic to a VM. This might not be possible at all?
Currently, i guess the following options might make this possible
Find a way to change the VNET of the VM, which will make it stop working with the old VNET.
Create an equal VM with a snapshot for the new VNET.
Connect the two VNETs and probably it will magically work?
It's impossible to add a new network interface that exists in the different VNet from the network interface currently attached to the VM to an existing VM. You can not add two NICs in different VNets to the same Azure VM. Refer to this.
If you want to move your azure VM and its NIC to another resource group, a simple way is to move a VM to another resource group. Read supported moving resources.
In addition, there is a Step-by-Step PowerShell Guide: How to Move Azure VM to a different Resource Group?
I'd like to automate the deployment of a virtual network (that is peered with another network) and container instance connected to that network.
I'd just want to confirm that I'd do the correct steps. I'll be using Azure REST API.
Deploy a Virtual Network with a subnet
Create a Peering to the other virtual network
Create a Network Profile
Deploy the Container with the created network profile.
Step 3 is a bit weird for me because it's different than what I do in the Azure Portal. In the Portal, I just select the virtual network that I want my container to be connected to. Looking at MSDN Docs it seems to me that REST API requires me to create that Network Profile first. Am I right?
When you deploy an container using az container create the az cli will create the network profile for you in the background.
This might be why you might not have seen explicit creation of the network profile before.
A network profile is a network configuration template for Azure resources. It specifies certain network properties for the resource, for example, the subnet into which it should be deployed. When you first use the az container create command to deploy a container group to a subnet (and thus a virtual network), Azure creates a network profile for you. You can then use that network profile for future deployments to the subnet.
https://learn.microsoft.com/en-us/azure/container-instances/container-instances-vnet#network-profile
You steps are looking good.
I created a VM without assigning a Network Security Group. Now, I am trying to assign the one group thats already created to the VM but the group is not listed for assignment.
You only need click Network security group, then you could see your Network Security Group.
Note: Your VM is a classic VM, you only could see classic network security group.
Current guidelines to add an Endpoint mapping are way too complicated compared to the classic VMs model.
Is this the only way now to simply map a public port to an internal port?
https://azure.microsoft.com/pt-pt/documentation/articles/load-balancer-arm-powershell/
It's not the ultimate way to configure endpoints on IaaS VMs that use the ARM model. Actually - please note that it may change at the discretion of MS - each VM you create using the new portal will come by default with a network security group (NSG) with the same name as the VM, that you'll be able to search for later in the portal.
Then, you'll be able to edit those NSG to make them compliant with your requirements.