VSTS hosted build and Azure hosted Octopus server

Tomas Polak's Avatar

Tomas Polak

05 Jan, 2018 02:21 PM

Hello,
I've seen few similar questions posted but none seems matching our case.
We're using VSTS for source control and also for Hosted builds. So both source control and the build agents are hosted by Microsoft and outside our direct control. Our Octopus server is running in Azure on one of our VMs and is under our full control.
I wonder what is the intended and secure way to allow usage of VSTS Octopus extension (and tasks like Create Octopus Release or Push Packages to Octopus) in this scenario?
The documentation suggests to create VSTS Project Service Endpoint, which of course requires connection to said Octopus server and the only way I can think of doing that is to expose Octopus server to the internet, which is not desirable.

As for the Push Packages task, we've overcome partially the disconnection by pushing to VSTS NuGet feed and then by adding this feed into Octopus as external Nuget feed. Downside is that this is passive, Octopus is pulling the packages during the deployment and we've not found a way yet to trigger the deployment this way as one could when using the Octopus build-in NuGet feed. One idea could be to enable Octopus to poll the external feed every now and then and trigger actions when new packages are detected... It still won't cover all use cases however, especially it will break the build/release cycle, which is not desirable.

On a side note, Microsoft has concept of Service Endpoints in Azure, at Subnet level, which enables secure traffic between say Microsoft.Sql or Microsoft.Storage services and said VLAN subnet and that traffic is then never routed over the internet. I'd wonder if - and I understand this is more for Microsoft to answer - if similar Endpoint could not be created somehow for the VSTS at Subnet level?

Or I could be missing here something obvious. Nevertheless, I am keen to discuss the topic.
Thank you.

  1. Support Staff 1 Posted by Shaun Marx on 10 Jan, 2018 03:18 AM

    Shaun Marx's Avatar

    Hi Tomas, thanks for reaching out. Sorry for taking so long to get back to you on this.

    This is definitely an interesting problem. The easiest way I can think of to address this is by creating a virtual machine to host a new build agent for VSTS which can then communicate with Octopus. This should have the benefit of being able to provide you more control such as network access.

    I believe the Azure Data Center IP addresses are published online, so should be able to whitelist the IP address ranges for your region as the hosted agent should be in the same region as your VSTS account. I believe these may change quite regularly so may be a bit tedious to keep updated. It may be worthwhile to confirm with Microsoft however. You can get more information regarding the IP addresses here

    Ultimately the only requirement would be that the build agent performing the work should be able to reach the Octopus Server.

    Please let me know if I misunderstood anything!

    Regards,
    Shaun Marx

  2. 2 Posted by Tomas Polak on 10 Jan, 2018 12:41 PM

    Tomas Polak's Avatar

    Hi Shaun,
    thanks for getting back to me. What you're suggesting with running our own build agent would of course work once we would place it in Azure and let it have connection to our Octopus server there, there's however the downside where we would then have to install and keep updating all the bits and pieces of software required for the build to run - while now the Microsoft team running VSTS Hosted or VSTS VS2017 build agents does it for us. And that is not a small undertaking which would yet again take our attention from producing value to creating and maintaining platform. I only wish there would be a hassle-free way you can easily clone what VSTS has running on build agents and run it on your own.

    The white listing, I think that's out of question, you'd be effectively exposing Octopus server to everyone from your region using Azure. Here's correct link btw.

    Thanks,
    //Tomas

  3. Support Staff 3 Posted by Shaun Marx on 11 Jan, 2018 03:41 AM

    Shaun Marx's Avatar

    Hi Tomas, no problem at all.

    You are correct in that it would have this drawback, however, I don't see an alternative to getting this to work. Perhaps it would be worthwhile to approach Microsoft regarding this as they may be able to provide additional help and or insights.

    I am sorry that I can't provide any more insights but very keen to hear the outcome if you manage to solve this.

    Regards,
    Shaun Marx

  4. 4 Posted by Tomas Polak on 13 Jan, 2018 07:57 PM

    Tomas Polak's Avatar

    Hi Shaun,
    I've concluded my research on the topic. I've spoken with Microsoft, but that didn't brought anything new to the table yet. I have however resolved the matter to our satisfaction.

    • we are using VSTS for source control
    • we have moved from VSTS hosted build agents to private agents
      • I have found hassle-free way of maintaining and deploying private agents
      • build time for one of my referential builds changed from 2.6min to 15s, that is no surprise because now the agents are available immediately for the build, git repo is cached, nuget packages are cached, but it is very nice side effect
    • we have Octopus server running on VM in Azure
    • we are using Octopus extension for VSTS to create releases
      • when we release to staging our integration tests run as part of that proces
    • with all that we have fully integrated Production line from source code all the way down to deployment. Unbroken, consistent and driven from a single VSTS defined build. If anything fails (including the release to staging), the build fails, which is great since our strategy is to promote build through environments, not to build for an environment.

    The missing/changed piece in our setup is the move from VSTS hosted build agents to private. This Microsoft GitHub project allows us to create VM image with all the software needed for building privately. It is maintained by Microsoft, so effort wise this means almost no effort for us to get everything installed and then simply create as many VMs to serve as build agents as we need.
    Also the private build agent requires no whitelisting of Azure regional IPs, simply because the connection to VSTS originates from the build agent (polling).
    Last, we have create VSTS Service Endpoint for Octopus, poiting to our local server in Azure and since the Octopus extension uses this only during the build, it all works as it should.

    I am happy we have it all working now. I'd however be a bit happier if both VSTS hosted agents and Octopus running in Azure would work together out of the box. So I am having pending question with Microsoft about their plans to add VSTS as Azure VLAN Service Endpoint, same way they support their Microsoft.Sql or Microsoft.Storage services. If I get update from Microsoft on that I'll share it here as well.

  5. Support Staff 5 Posted by Shaun Marx on 15 Jan, 2018 02:58 AM

    Shaun Marx's Avatar

    Hi Tomas, I am glad you managed to arrive at a solution.

    The Github repository you linked is a very good find and should prove to be quite useful.

    I agree that it would still be preferable if Microsoft could add VSTS as a VLAN Service endpoint as that would remove the overhead in managing the VM completely. Would be very happy to see Microsoft add the ability. Please let us know if you hear back from them regarding this!

    If you can think of any way for us to improve this story, please don't hesitate to let us know :)

    Regards,
    Shaun Marx

Reply to this discussion

Internal reply

Formatting help / Preview (switch to plain text) No formatting (switch to Markdown)

Attaching KB article:

»

Attached Files

You can attach files up to 10MB

If you don't have an account yet, we need to confirm you're human and not a machine trying to post spam.

Keyboard shortcuts

Generic

? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac