I have CI deployment with dotnet core. Simply I need restore database, before publish to server. But azure firewall is blocking bitbucket engine dynamic IP address.
In yml config I have this:
image: microsoft/dotnet:sdk
pipelines:
default:
- step:
caches:
- dotnetcore
script: # Modify the comma`nds below to build your repository.
- export ASPNETCORE_ENVIRONMENT=Production
- export PROJECT_NAME=XXX
- export TEST_NAME=XXXTests
- dotnet restore $PROJECT_NAME
- dotnet build
- dotnet ef database update -p $XXX --configuration Release
- dotnet test $XXXTests
#...
#...
After this pipeline is finished with error:
Client with IP address 'DYNAMIC_GENERATED_IP_ADDRESS' is not allowed to access the
server. To enable access, use the Windows Azure Management Portal or
run sp_set_firewall_rule on the master database to create a firewall
rule for this IP address or address range. It may take up to five
minutes for this change to take effect.
Is there way, how to solve it?
AFAIK, although the Client IPs are dynamically generated, it should belong to one of the ranges mentioned here (See the section Valid IP addresses for Bitbucket Pipelines build environments). Do note that these are prone to change as mentioned within, and that in addition to IP whitelisting, you should use a secure means of authentication for any services exposed to Bitbucket Pipelines.
And then you can whitelist them as mentioned here, or here.
Hope this helps!
I am building a Release Pipeline on Azure DevOps. Part of my release is to copy a bunch of files to the Azure VM. As far as I understand, the target machine needs to have PowerShell 5986 port open.
I have a VM with port 5986 open (I verified that by invoking remotely some commands on this VM with "PowerShell on Target Machines" task).
I added "Windows Machine File Copy" task and filled fields:
- Source
- Machines
- Admin Login
- Password
- Destination Folder
In "Machines" field, I put IP of the target machine.
As a result of running the release, I'm getting an error:
Failed to Create PSDrive with Destination:
'\\11.11.11.11\C$\TargetDirectory',
ErrorMessage: 'The network path was not found' The network path was
not found
I also tried to put IP address with a port, in this form: 11.11.11.11:5986
Then, I got this error:
Cannot convert value "\23.97.151.221:5986" to type "System.Uri".
Error: "Invalid URI: The hostname could not be parsed."
Documentation (https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/deploy/windows-machine-file-copy?view=azure-devops) says that IP address with a port is allowed.
What's the issue here?
I was getting the exact same error while doing these:
Initially in my release pipeline, I had an agent job and I created a Windows machine file copy task under the job and filled in all details correctly. I set the Machines field with the public IP address of my target server (a Windows azure VM) and I always got this error you reported.
I tried to use the Azure file copy task instead but I was faced with another problem (error message: Unable to get FQDN for all resources in ResourceGroup: {resourceGroupName}) which I couldn't get to fix after a lot of efforts.
This is the solution that worked for me:
Instead of running an agent job, I ran a Deployment Group Job. With deployment groups, I didn't need an IP address to connect to my VM. Setting up a deployment group for your Azure VM is very simple and well explained here
I created a Windows Machine File Copy task under the Deployment Group job I added. I filled same details for the task except that instead of the IP address of the Windows VM, I entered the computer name in the Machines field and the file copy task ran successfully!
I hope this helps
The problem is because you can't use that task to copy files across Windows Domain boundary! That is to say, if you build on host A and want to copy files to host B, then A and B must be in the same Windows Domain, otherwise you'll get the error like
##[error]Failed to Create PSDrive with Destination: '\\your-server-name-or-ip\some\path', ErrorMessage: 'The network path was not found'
That is to say, if you're using a hosted agent, then you're not able to copy files with that task to any host you have, no matter it has a public IP or not, or a FQDN, because they are not in the same Windows Domain!
You have two options to work around it:
Use Azure File Copy task if your target is an Azure VM or Azure Storage
Use private hosted agent and make sure your target host and your private agent are in the same Windows Domain
Last but not least, the document should really make it clear! It wasted me a lot of time on solving the problem!
go to the destination folder, right-click the folder select properties,share option is there, click that one and share everyone option is there
The solution is to go to the target server and SHARE the directory where the files would be copied. In Windows, just go to Properties of the directory, Sharing tab, and Share it to the user which is used in the VSTS task.
The answer is pretty simple, the DevOps Tasks are actually running PowerShell on you VM and trying to create a PSDrive.
Try using the task mentioned in the screenshot below:
I'm just getting started with Ansible. I've created simple vms with azure module on Ansible.
Now, I'm trying to take a snapshot on azure disk with ansible.
Is that possible?
There is no such a module according to the module list. You can use azure_rm_resource module to perform a custom post request to Azure with Ansible. Here's an API call you should mimic with Ansible
hosts: localhost
connection: local
tasks:
name: Create a snapshot by copying an existing managed disk.
azure_rm_snapshot:
resource_group: ****
name: mySnapshot
location: centralindia
creation_data:
create_option: Copy
source_id: '******'
I have tried three installs through the portal and finally one completely through Azure CLI (with Ubuntu on Windows). Each time the deployment completes but remotely run commands because they fail with "resource temporarily unavailable". I can SSH into the master server. When I do I find the kubectl commands all come up empty (nodes, pods, namespace, version). Service --status-all does not list a single Kubernete service (I would expect to see the API service at least).
When creating through the portal I manually created the SPN and verified I could login to Azure with it. During the CLI setup I let the install create the SPN.
I have tried restarting the master but nothing changes.
What am I missing? It is probably something easy but I am spinning my tires.
I'm trying to use the azure command line to start a vm:
azure vm start myvmnamehere
But it's telling me:
No deployments were found
I'm guessing that I need to specify the location "West US"?
azure vm start is going to start a virtual machine that you've already created, within a specific region. To do that, you'd first need to call azure vm create. You would first create your vm from an image in the gallery (and within a dns name, xxxxx.cloudapp.net). To see the images available to you, try running azure vm image list.
Also: don't forget to add --ssh or --rdp so you can have remote access, when calling azure vm create.
Jeff Wilcox blogged about this in more detail, here.