My target is to create Azure Resources from Azure DevOps release pipeline. Resources that are created are virtual machines and application gateway (+ all the necessary vnet's etc.). Resources are created successfully, but the pipeline wont work through application gateway. Currently the pipeline has "Azure File Copy" -task to copy some scripts to the virtual machines. This setup works without application gateway but I cannot get it to work with application gateway.
Error message I get from Azure DevOps is: "Unable to get FQDN for all resources in ResourceGroup"
I have created a ticket to MS but they were not able to resolve this issue ("Works as expected") yet and now waiting for Azure DevOps support to participate, but since it is a bit slow I decided to post a question about this here since I think that someone might have bumped into this before as well.
Does anyone have idea if this setup is supported or have any workarounds? Main need would be to copy and execute scripts in virtual machines.
Talked with Azure Networking team and Azure DevOps team and there is no way around this at the moment. Virtual machine must have public IP address to use "Azure File Copy" -task.
So I ended up adding additional NIC with public IP address to the VM and use NSG to only allow traffic from Azure DevOps pipeline.
EDIT: Created a feedback item, please vote if you need this functionality as well: https://feedback.azure.com/forums/217313-networking/suggestions/36482038-add-application-gateway-support-for-azure-devops-t
Related
I am using an Azure DevOps pipeline that is basically a series of steps that call PowerShell scripts that take in parameter values and within the PS script the "Az module commands" are called - these commands create the infrastructure on Azure.
For example...
Create a public static IP address - this I can do.
Create a NIC and link static IP address - this I can do.
Create a Synapse Workspace and 'Self Integration Runtime' - this I can do accept link Synapse SHIRT to the self-hosted integrated runtime on the Azure VM.
Create a Windows VM (datacenter 2019) - this I can do.
Create a Azure Windows VM self-hosted integration runtime via devOps pipeline???
I now want to create a step in the devOPs pipeline (maybe an ARM template or PS script that calls an Az module) that automatically installs the 'self hosted integration runtime' on the Azure Windows VM - the VM is attached to an Vnet/subnet. The runtime on the Azure VM will be linked to the Synapse runtime. (note I am not using Data Factory)
I have read the following. But can't workout if setting up a runtime on the Azure VM and Synapse and linking them is possible and if it can be automated in a devOPs pipeline?
https://learn.microsoft.com/en-us/azure/data-factory/create-self-hosted-integration-runtime?tabs=data-factory#considerations-for-using-a-self-hosted-ir
The below link is very near to what I want to achieve....
https://github.com/Azure/azure-quickstart-templates/tree/master/quickstarts/microsoft.compute/vms-with-selfhost-integration-runtime
Have added one manually step once the devOps pipeline finishes.
Open RDP port on Azure VM. I know the admin. username and password. Log on to the Azure VM.
Turn off advanced security features on the VM temporally.
Download and install the SHIRT from the Microsoft web-site.
Config. SHIRT with the "Key1" value from the SHIRT in Synapse.
Turn on advanced security features on the VM temporally.
I mark this site down -2 for poor editing buttons, worst I seen in 25 years in IT.
As a beginner of DevOps, I would like to know how to use one VM for azure pipeline runs. When starting the run of the azure pipeline task it always gives a fresh VM from azure.
For caching and file saving purposes, I want to use a reserved VM for pipeline run.
Appreciate your suggestions and support.
Check the pic, In the Azure DevOps, we could run the pipeline via Hosted agent and Self-Host agent.
Azure Pipelines provides a pre-defined agent pool named Azure Pipelines, this is hosted agent and each time you run a pipeline, you get a fresh virtual machine. The virtual machine is discarded after one use.
For caching and file saving purposes, I want to use a reserved VM for pipeline run.
We could refer to this doc to install the self-hosted agent, it will save the cache.
You can setup a 'self hosted agent'. That would be your own VM, which you have total control over. I'm not sure whether this will be any cheaper than hosted agents.
I've used a self-hosted agent a while ago, and saved some money booting the VM only when needed. After a while it would shutdown again.
Source: Self-hosted agents
I have an appservice called compspiadev, and I am using Azure's Pipelines to set-up CI/CD. Created the build pipeline and build the project into an artifact to use it in the build pipeline. When I try to deploy I get the following error:
Now my appService doesn't have the ".scm." part in it, and in my configuration I don't set the name to have the KUDU endpoint it adds it automatically:
How can I fix this issue for it to deploy correctly?
Your guess is correct. That is an network error which is because our Azure devops Hosted agent could not connect to the internal deployment endpoint of ILB ASE. (As I mentioned in this ticket, I checked your app from our backend and found it is connecting to ILB ASE.)
You can check this source code (actual working code snippet, I can not help you locate the exact code line since I don't know witch deploy method you used), and you will found that the process of Azure app deployment via Azure app service deploy task is actually the process of communicate with app files to Kudu service (xxx.scm.azurewebsite.net).
For example, if you are using Run from package type to deploy your web app, you can refer to this code snippet.
After you configured ILB ASE, per this doc, the scm site is only available at <appname>.scm.<asename>.appserviceenvironment.net. But you should have known that Hosted agent is a dynamic-distribution Azure VM that is neither in nor connected to the virtual network.
That is why you encountered the error like could not connect to the remote computer <appname>.scm.<asename>.appserviceenvironment.net.
To resolve this issue, you need use private agent to execute your deployment pipeline. For how to configure a valid self agent so that it can communicate with your private DNS, you can follow this reply or this blog.
As is visible in (the URL part of) the error message in your first image, you're deploying to an App Service Environment (which is something of a special cookie).
The Azure App Service Environment is an Azure App Service feature that provides a fully isolated and dedicated environment for securely running App Service apps at high scale.
As we can see in the second image, you don't have the checkbox "Deploy to Slot or App Service Environment" checked.
Check that checkbox, specify the Resource Group name, leave slot name set to production and you should be good to go.
If the deployment target is an Azure App Service environment, leave the slot name as production and specify just the Resource Group name.
Source: Azure App Service Deploy task - Prerequisites for the task
I have “.Net Core Web Api” and “Angular 8” projects. I am manually deploying these two application on Azure Virtual Machine.
Now I want to use Azure CI/CD pipeline process and deployed above application on IIS present on above Azure Virtual Machine.
Can I achieve above tasks by using Azure Deployment Groups? I am not able to find proper solutions on internet.
Any help will be really appreciated.
I have this link: https://learn.microsoft.com/en-us/azure/devops/pipelines/apps/cd/deploy-webdeploy-iis-deploygroups?view=azure-devops but no use.
Can I achieve above tasks by using Azure Deployment Groups?
Of course sure. Azure virtual machine just the VM which hosted by Azure, there's no more difference with the normal VM.
To deploy application to Azure VMs through IIS tasks and azure devops deployment group, you must pay attention to below 2 prerequisites:
1) As normal, VM is a separated machine. In order to combine them into Azure Devops and use them with CI/CD, to be precise, let the Deployment group manage to these virtual machine, you need to run script to register these VMs to VSTS deployment group.
2) Also, to deploy application to VMs via IIS, you need also ensure that these VMs web servers configured with IIS.
Above 2 is what mentioned in the doc you shared.
Our lab published a blog which describe the very detailed steps on how to Deploying to Azure VM using Deployment Groups. You can follow it to continue your configuration in VSTS pipeline.
Since it is very detailed, I would only point some key to you:
1 To configure Deployment Group agent on each of the virtual machines, firstly, please use Azure Resource Group Deployment task with Configure virtual machine deployment options action and enable prerequisites as Configure with Deployment Group agent:
2 For the configuration of IIS manage and deploy task, including physical path and etc, you can follow this(just ignore its task of start) to finish your configuration.
Note:
Here you must add 2 phases since Azure Resource Group Deployment task need run with agent job, and IIS web app manage/deploy task run with deployment group job
These are the basic steps which could help you achieve what you want.
When I create a VM in Azure, it is creating an accompanying Cloud Service and Network Resource. I found that the Cloud Service is there as a deployment layer. I have not found why the Network Interface is there.
Since this particular circumstance is not going to have a deployment associated with it as it is used as an Elasticsearch server, I technically will not be needing the Cloud Service. However, when I delete the service, it takes the VM with it even though I do not expressly select it for delete.
My two specific questions:
1st - Why is there a Cloud Service created and not able to be deleted without repercussions when there is not deployment necessary?
2nd - Why is the Network Interface created and not able to be deleted without repercussions?
Both questions are with the understanding that this is an Elasticsearch VM.
A cloud service is a required artefact of an ASM/classic deployment if a VM. It is not needed in an Azure Resource Manager deployment, which is what you should use for new deployments. However, the two types of deployment are orthogonal, so you may need to keep using ASM if you already have VMs deployed that way. If so, you should consider migrating them to ARM.