we have a TFS 2018 running inside our Intranet and want to deploy to a remote machine outside of our intranet. The TFS is not visible from the outside (behind Firewall and does not have its own IP)
So we came up with this solution, that might work:
Set up a VPN connection between the target machine and our intranet
Create an Azure Pipeline Agent on the target machine that uses a private access token to communicate to the TFS
Is there an easier solution to this, which doesn't require a VPN connection?
We thought we could deploy to a web share from TFS and then trigger the Azure Pipeline Agent on the target machine, to start the deployment. But from the documentation of Microsoft it seems as if the Agent has to have direct access to the TFS trough HTTPS and only "listens" to jobs in the TFS queue.
That means that the only other solution to a VPN connection from the target machine would be, to make our TFS accessible from the internet trough HTTPS, right?
Unfortunately, until now we haven't found a lot of documentation on "best practices" for this use case. That's why I decided to share it here. Thanks!
Related
We are getting below error on Azure devops pipeline via Self hosted agent release when Azure web app is on Private network. No Error seen when the web app on azure is on Public.
Error: Error: Failed to deploy web package to App Service. Error: tunneling socket could not be established, statusCode=503
Made Azure web app to private and error comes. Moved to public no error seen.
Seems that the self-hosted agent cannot connect to the Azure app service. It seems to be a network issue.
The agent needs a way to connect to the App service directly. To ensure the connectivity is ok, we need to make sure the self-hosted agent is not blocked by NSG rules or App Service networking Access Restrictions. Just whitelist the agent machine in your rules.
The task using Kudu REST API to deploy the application. We need to check the following App Service networking Access Restrictions to allow deployment from a specific agent:
Make sure the REST site “xxx.scm.azurewebsites.net” have Allow All, i.e. no restriction.
Also, the option “Same restrictions as ***.azurewebsites.net” should be unchecked.
If you are using Private Endpoints for Azure Web App, you must create two records in your Azure DNS private zone or your custom DNS server. Kindly check DNS for more details.
Besides, when the proxy is set up, Web API calls and SCM hosts are bypassed by the user. The same has to be configured in the Azure pipelines agent explicitly. To bypass specific hosts, follow the steps here and restart the agent.
1.Allow access to Public removed.
2.Created Pvt endpoints within same Vnet and Subnet of Target VM
3.Created new file .proxybypass in self hosted agent folder C:\Username\Agent
4.Added below entries in .proxybypass to allow and communicate bypassing corporate proxy
https://MyWebappname.azurewebsites.net
http://MyWebappname.azurewebsites.net
enter code here
Can an Azure DevOps proxy server be used to facilitate artifact and pipeline releases for a DMZ environment (e.g containers).
For example,
LAN Azure DevOps > Azure DevOps Proxy > Containers in DMZ
When I've looked at the proxy documentation it seems to just relate to artifact caching.
Any help would be appreciated.
Thanks
You can use proxy server for that and connect it to particular port using firewall rules and telnet to see if connection is working fine.
We used to do same using the proxy server between artifact server and Azure DevOps server by opening some firewalls rules for particular port.
I am thinking of moving from TFS in our local Data Center to Azure DevOps but one of our pipelines deploys to a server that is going to stay in our Data Center, and that's not exposed to the internet. Can I establish a VPN with Azure DevOps such that in this multi-tenant environment the pipeline can deploy to our internal server? Or am I stuck with TFS installed here?
It is possible by using Deployment groups. The connection will be initiated by your servers.
For seeing how it work watch the following video:
https://www.youtube.com/watch?v=58UfRxxAWhE
i'm trying to trigger builds on jenkins when ever a pull request is merged, and trying to add the webhook, which is throwing me the below error.
payload url: http://localhost:8080/job/hook-test/
error: "We couldn’t deliver this payload: Couldn't connect to server "
The URL for the webhook is localhost. GitHub is trying call the webhook on itself.
You need to deploy Jenkins in a publicly accesible URL. It won't work with a local Jenkins install in your PC.
localhost refers to the address of the current machine. When you type localhost in the browser and you access Jenkins, that works because you have Jenkins installed and running in your PC. Access localhost from a different machine and you won't be able to access Jenkins. When you tell github to send the webhook to localhost it will not try to send it to your machine, instead, it will send the webhook to the same machine in which github server is running, and that machine doesn't have Jenkins installed.
The problem here is localhost means something different for you and for github.
To solve this problem, you'll either need to install Jenkins in a public server accesible from internet (so that github can send the webhooks) or use some online service which provides hosted Jenkins servers.
You could also just get a domain and configure it to point to your PC. You would probably need to do some networking configuration but once it's done you (and github) will be able to access your jenkins via some-domain.example.io instead of localhost. Be careful, you would be making your (I asume personal) PC accesible from the internet, and that has security risks.
If you can afford it I recommend using a server in the cloud to run this.
Many cloud platforms even provide a quite long free trial period (I know Amazon and Google Cloud do).
I wanted to create a Test rig on cloud. I have created a windows azure hosted service that installs Test Controller and configures it with on premise DB. I have created another hosted service that installs Test Agent. I have enabled Virtual network in the Azure service by providing Activation token taken from azure portal. I also created a Azure Connect Group in which I added my local endpoint(On Premise DB) and windows azure roles( Test Controller rand Test Agent). When I deploy this on azure I am facing problem of Test Agent connectivity with Test Controller.
Test Controller can ping to my on premise DB machine and vice versa. But my test controller machine cannot ping test agent machine or vice versa on cloud.
I have ensured following things on test Controller
User testagent is part of group TeamTestAgentService
User testagent is also administrator on TestController hosted service.
Firewall exceptions have been added
If I try to ping two azure machines I cannot do that. By default azure has ping disabled so I added following firewall rule
netsh advfirewall firewall add rule name="ICMPv6" dir=in action=allow enable=yes protocol=icmpv6
but it still does not work. I think if these two machines will be able to ping each other the problem of test agent connectivity to test controller on cloud will be solved.
Reply from http://social.msdn.microsoft.com/profile/rlfh/
It won’t work as you have it now. The controller and agents have to be in different roles, but also the controller you need to install Azure Connect as an endpoint– not enabled as a role. So, you want to configure the Controller manually, then it should show up so you can add it to the Connect From list. Leave the agents as they are(azure connect as a role) and then it should work. The Roles in the Connect TO: part won’t be allowed to intercommunicate, though an endpoint can – since they have the option you selected to allow this.
My problem was solved when I manually installed Azure Connect endpoint from azure portal on the controller machine instead of enabling it as a Role in Virtual network.