I am trying to understand the difference between Service Hooks and Service Connections in Azure DevOps.
Service Hooks and Service Connections both seem to do the same thing according to these description.
"Service connections enable you to connect to external and remote services to execute tasks in a job."
Service Connections
"Service hooks let you run tasks on other services when events happen in your Azure DevOps projects."
Service Hooks
None of these pages tell the reader the difference between service hooks and service connections. Even though I am sure each is used for a different purpose.
Service connections enable you to connect to external and remote services to execute tasks in a Azure pipeline job. For example, you may need to connect to your Microsoft Azure subscription, to a different build server or file server, to an online continuous integration environment, or to services you install on remote computers.
You could go to Project Settings>>Service connections page to see available service connections. And when you use tasks which required to connect to external and remote services, you will see it requires you to set up corresponding service connection. For example, if you use GitHub repository as the source repository in pipeline, you need to set up GitHub service connection.
In the meanwhile, Service hooks let you run tasks on other services when events happen in your Azure DevOps projects. You could go to Project Settings>>Service hooks page to integrate with your favorite services by notifying them when events happen in your project. For example, create a card in Trello when a work item is created or send a push notification to your team's mobile devices when a build fails.
You can also use service hooks in custom apps and services as a more efficient way to drive activities when events happen in your projects. Also you could create a service hook for Azure DevOps with Microsoft Teams, so members can get notified when builds are completed, work item updated, etc.
Related
we have azure devops pipelines to build and deploy various projects.
Rccently, we wanted to use the "azureblog file copy" pipeline to copy some files to a blob storage.
This needs write access to the storage account over in azure.
Our administrator says that the pipeline runs as whoever manually runs the pipeline. If this is true, we would have to give all devs and users read/write access to the blog storage, which would be crazy.
I assume he is wrong, and that pipelines run as a specific designated user no matter how they were kicked off. The question is, how to find out what this user is for a given pipeine?
The "edit pipeline" has a security tab near the top, adn this lists a but of "Azure Devops groups", which are presumably groups who have the ability to run the pipelines.
But where is the pipeline user defined?
which user do Azure devops pipelines run as?
It depends on the context in which you are discussing the question.
If you mean inside a pure DevOps service, then I can tell you that the user that the pipeline runs on is not the one who triggers the pipeline (which is the case with native DevOps services by default, unless you install some weird extension or have a problem with the pipeline special design), but this identity:
<Project Name> Build Service Account
'run as someone' is just a property of pipeline run. Pipeline run as 'Build Service Account'(On the DevOps side), If you need a pipeline to download or upload an artifact, you can clearly feel this. If the account mentioned above has no permission, you can't do anything.
If you mean the user's operations based on the Azure side, then I can tell you that for native DevOps service, the 'user' that the pipeline performs operations on the Azure side is not the person who triggers the pipeline. The pipeline of DevOps service consists of multiple tasks, and tasks generally interact with other services through service connection (you can find this in Project settings).
There are many types of service connections. When interacting with services in Azure, this type is generally used:
Azure Resource Manager -> Service principal
When you create a service connection of this type on the DevOps side, Azure will also create an AAD app related to this service connection, and this ADD app corresponds to a service principal in Azure. In Azure, permissions are assigned based on service principals or users, and your DevOps pipeline's operations to Azure are based on this service principal and have nothing to do with anything else in DevOps. On the Azure side, this service principal can be considered as an Azure-side 'avatar' of the tasks of the DevOps pipeline.
If you are interacting with Azure through pure code/pure script, then please follow the logic of the script/code.
Our administrator says that the pipeline runs as whoever manually runs
the pipeline. If this is true, we would have to give all devs and
users read/write access to the blog storage, which would be crazy.
For native DevOps service, of course not. Unless this pipeline has a special design.
I believe the pipeline runs as the "agent". Who the "agent user" is will depend on, first, whether you've chosen a "Microsoft-hosted" or "self-hosted" agent to run your pipeline.
When running pipelines in Azure DevOps that are directly working with Azure Resources you need an Azure Resource Manager service connection. The credentials used to make the service connection are the credentials the pipeline will use when it runs.
You can have your administrator provide you with an Azure AD account that has the permissions you need and then use that Azure AD account to create the service connection for the pipeline. Once you have created the service connection you can use the ResourceID of that connection in place of you azureSubscription.
Here is the link to the Microsoft documentation on creating a service connection.
Here is the link to the Microsoft documentation on the Azure file copy task. To verify you can use the service connection in place of the azureSubscription.
I have a server in AWS, which is hosting a security tool. Azure DevOps supports this tool and I've installed the add on for it. I've added the step to my Pipeline and configured the service connection.
We are using Hosted Agents in a Cloud AZD instance.
When I run my pipeline, I get the following error:
##[error][TOOL] API GET '/api/server/version' failed, error was: {"errno":"ETIMEDOUT","code":"ETIMEDOUT","syscall":"connect","address":"1.1.1.1","port":443}
In my AWS security group, I have allowed the Inbound IP's for Azure DevOps listed here https://learn.microsoft.com/en-us/azure/devops/organizations/security/allow-list-ip-url?view=azure-devops&tabs=IP-V4#ip-addresses-and-range-restrictions
I have also allowed the Geographical IP's for listed in the json file here https://www.microsoft.com/en-us/download/details.aspx?id=56519
If I allow all traffic for 443 through the security group as a test, this works as expected. This is not a solution however as this is a security tool and should not be public.
In my pipeline, I added a task to run a curl command to inspect the IP's of the pipeline. Neither of these ranges appear in any list I can find published.
51.142.72.0/24
51.142.229.0/24
I was advised to post here by AzureDevOps on Twitter for some help, so hopefully someone can assist me here.
I am planning to migrate my work to Azure Stack Hub. Can someone please let me know whether I can use Azure DevOps Services in Azure Stack Hub. If so please advise me on how to.
Thanks
If your Azure Stack Management URLs are not public, you'll need a Self-hosted Agent on-prem or somewhere that it can see the Azure Stack Management URLs.
The Self-Host agent will need the Azure Stack Environments created for your Azure Stack Hub e.g. AzureStackUser and/or AzureStackAdmin using the appropriate Management URL.
In Azure DevOps, create a New Service Connection for Azure Resource Manager, but make sure the Environment is set to Azure Stack.
The Server Url must be to one of the Management URLs of your Azure Stack that match the Environment you configure. This depends on what you're doing.
For Admin related configuration:
Use the Admin Management URL e.g. https:///adminmanagement.local.azurestack.external
Set the Subscription ID and Subscription Name to the Default Subscription on the Azure Stack Hub
Enter the Service Principal and Connection Details
For User related configuration:
Use the Management URL e.g. https:///management.local.azurestack.external
Set the Subscription ID and Subscription Name to the User Subscription defined on the Azure Stack Hub
Enter the Service Principal and Connection Details
NOTE: The Service Principal must have the appropriate Role on either the Default Subscription or the User Subscriptions.
Don't verify the Connection, unless the Management URLs are accessible publically
Hope this helps.
We are trying to start using the Azure Pipelines agents instead of Self hosted ones. While trying to convert over or Acceptance tests I am running into an issue with the agent not allowing our test to connect to an api we spin up with in the Agent that is running on port 44392. Noticed this post. How to open TCP port on localhost on VSTS build agent?, from a couple years ago and is pretty similar to how our test is working. Just wondering if the answer is still accurate or not.
Since your are using the Hosted Agents, which means that the machine is a shared resource between many Azure DevOps Organizations (tenants) and managed (and locked) down by Microsoft.
In other words, we do not provide end user to open port with these agents. The answer in your link is still valid.
You may have to install an agent on your own virtual machine and run the build there. The VM can be in the cloud or on premise. You trade simplicity and cheapness for full control.
I have two web servers and one service server and a database server and all these servers are domain joined. And I have set my private build agent from VSTS from where I can build my artifacts and based on build configuration. And all my DEV,QA and STAGING environments are setup on those servers.
My problem is i am looking for a way using PowerShell Desired state configuration such a way that based on the environment artifacts (DEV,QA and STAGING) the scripts has to copy the artifacts to specific location on those "TWO web-servers" and ensure the website is configured correctly with all the required permissions where these artifacts are used to host IIS website and perform the delete and creation action of particular windows service on "SERVICE service" and should also perform the migration activities on "DATABASE server" for particular database. since I have separated database for each individual environment.
Any kind of help or suggestion would be appreciated. thank you.
My suggestions are:
Don't use DSC for deployment (i.e. deploy applications or databases)
Use DSC for configuration (e.g. install IIS)
Install the VSTS Agent on each server in Deployment Groups mode, running as a service with local administrator privileges
Use the IIS Deploy Tasks designed for Deployment Groups
Use the Powershell Task to manage the Windows Services (tip. help *-Service)