I’ve recently started provisioning a new worker pool with a new worker in it running as an Azure VM with an Octopus Tentacle configured to be a worker (using “tentacle.exe register-worker”) to improve the deployment performance of some Azure-based steps. The idea is that running the scripts in an Azure VM-based worker means things will run at local Azure network speed rather than over our (slow / unreliable) ExpressRoute connection.
I think I’ve got everything more or less working and it seems to deploy ok, but I’m having some problems reading the UI for my process where it has child deployment steps - I can’t see where the worker config is defined in either the parent or child steps.
Neither the parent nor child steps mention the “SI Worker Pool” once they’re nested, which makes it really hard to see what the deployment process will actually do.
Am I not looking in the right place, or is this information just not shown in nested steps? We’re on Octopus Deploy version “v2018.1.0.0 LTS” so I guess it’s possibly already been changed in a later version.
By the way, when I query the API for this project I see “WorkerPoolId”: “WorkerPools-21” in both child steps, so the information is there - it’s just not shown in the UI. Also, the deployment does actually do the right thing as well, so I think this primarily is a UI issue.
It looks like this is at least partially fixed in the latest version of Octopus (v2019.6.3 at the moment). The UI now shows the Worker Pool name in child steps, but I’m still not sure the “Run once” option is fully represented:
There’s no “Run once” radio button, and the text at the bottom of the image leaves a dangling “each deployment target in the following roles:” message with no following roles (because I’ve not assigned any).
I can see why this seems strange, and we can quite possibly do better here.
The reason you aren’t seeing the “Run once” option is that it is not presented for child steps. Child steps are designed for modeling rolling deployments. Though in your case you’ve selected Deploy to all deployment targets in parallel which is essentially a rolling deployment with a window size equal to the number of targets.
In these scenarios, run once isn’t a valid option, as the child step will run once for each target matching the role of the parent.
Does that make sense? What are you hoping to achieve with child steps in your scenario? Is it just for grouping, or did you have a specific deployment plan in mind?
So I’ve actually got a pattern of sets of 4 steps in my deployment - something like below. The child steps are more for logical grouping than for rolling deployments:
1 Deploy Azure WebApp A
1.1 Create “staging” deployment slot
1.2 Deploy Azure Web App to “staging” slot
1.3 Swap “staging” deployment slot
1.4 Remove “staging” deployment slot
2 Deploy Azure WebApp B
2.1 Create “staging” deployment slot
2.2 Deploy Azure Web App to "staging slot
2.3 Swap “staging” deployment slot
2.4 Remove “staging” deployment slot
I’m using the “Legacy” mode for the WebApp deployment so we’re licensed by Worker rather than per App Service, and the other 3 steps are custom Azure PowerShell step templates I’ve written myself.
(There’s a couple of dozen projects like this - I’m eagerly waiting for Composite Step Templates so I can refactor them all )
At present we’re deploying using “Run once on octopus server” to Azure over our ExpressRoute connection which is a somewhat glitchy and fails often enough to be a bit of a pain - probably more due to our internal network configuration than anything else.
What I’m trying to do is provision an Azure VM with the tentacle service installed and configured as a Worker in a new Worker Pool so that the more reliable Octopus “package acquisition” is performed over the flakey connection to Azure, and then the Worker can do a high-speed Azure-to-Azure deployment of the App Service - from a technical perspective, I’ve got this all working, it’s just that the UI doesn’t make it clear what it’s configured to be doing, and I’m worried I’d be handing over a plate of cryptic spaghetti to our devs if I leave it like is currently is.
I found it’s been improved in the latest version (v2019.6.3) so it now shows the Worker Pool in the child step page, but the whole run once thing isn’t very clear - I originally configured the separate steps as “Run once on a worker” and then when I moved them into a parent step it automatically turned into a “Deploy to all targets in parallel”. If I separate the steps again they go back to “Run once” so it looks like the internal data is how I want it to be - it’s just not surfaced up to the UI.
Could you suggest how to configure the Workers, Roles, Steps, etc, to achieve what I want - i.e. "run once on an Azure-based Worker in my “SI Worker Pool”?
I just noticed something in the last image I posted - the graphic on the right of the page in the “Execution Location” section shows the “Execute once on a worker” image, so it’s almost like the problem is that the “Run once on a worker” radio button is incorrectly hidden / omitted in the dialog in child steps, but it’s still the “active” option.
Ahh, thank you for the additional information. I better understand your scenario now.
The truth is, you’ve slipped through the cracks in the logic somewhat.
As I mentioned, child steps are designed for modeling rolling deployments. Octopus doesn’t allow child steps to be added to parent steps which “run once”. But by using the ‘Legacy’ mode for the Azure Web App step, the UI has allowed you to configure child steps for a “run once” parent.
That’s why the UI behavior is odd; it’s a scenario it isn’t expecting.
I’m going to chat with our team about your scenario, and I’ll get back to you with a decision of either:
this is a valid scenario (and we’ll fix the glitch)
this isn’t a recommended use of child steps, and we’ll suggest for you to flatten them
Using an Azure VM in a worker pool sounds like a nice approach.
Something to consider as an alternative way to model the deployment process:
You could possibly collapse the four steps into a single Deploy an Azure Web App step and configure the Custom Deployment Scripts feature. Creating the slot could then be done in the pre-deployment script, while swapping and removing could be done in the post-deployment script. This would also possibly allow you to model the whole process as a single step template.
Thanks for the update. I drifted toward the child steps approach for a couple of reasons:
Sometimes we don’t want to swap the slots - maybe we’re just doing a deployment into the “staging” slot to compare configs or smoke-testing in the LIVE web app before we launch the new version to customers a few days later, so having separate steps means we can just execute the “Reset staging slot” and “Deploy to staging slot” steps and disable the “Swap staging slot” and “Remove staging slot” steps in any given deployment
The logical grouping means it’s easier to set up and maintain (although it sounds like that’s not what parent / child steps were originally meant for, so maybe I’m trying to crowbar behaviour where it’s not supposed to be!). One of our projects, for example, is made up of 5 web apps, and having a flat list of 20 steps would make it hard to “see” the 5 separate web apps in the process.
I’ll wait to hear back from your team, but for what it’s worth I think it’s important to have some way to logically group related steps in long processes for maintainability and usability, but like you say, the parent / child layout at the moment is coupled with managing rolling deployments so it has some additional behaviour than just partitioning steps…
@Michael_Richardson - have you heard anything back from your team re the approach I’ve taken for my WebApp deployments in terms of whether it’s “supported” or not?
Unfortunately for your current scenario, the outcome was that we felt that child steps are currently designed around creating rolling deployments. We felt that allowing them to be added to “run once” steps would result in potential confusion and some weird scenarios for us to support.
But… we absolutely sympathise with the desire to group related steps visually.
We’re going to do three things:
Close the loophole that allows child steps to be configured for Azure Web App steps in legacy mode (sorry!).
Make it clearer in the UI that “Add child step” is really “Configure rolling deployment”
Investigate how we can support grouping steps.
Of course #3 is not going to help you right this moment. For that we apologize.
So in summary, we would recommend against using child steps for your current scenario.
I realize it comes with license implications (I promise I don’t get paid on commission), but I would recommend considering using Azure Web App deployment targets. It would simplify your deployment process, and child steps would be natural fit.
Please feel welcome to share any further thoughts or feedback!
No worries - I had a feeling that news was coming :-).
In terms of using the “non-legacy” mode for App Services, it’s not really a viable option for my client - they’ve got around 50 distinct pay-walled products, each with a customer-facing website app service and a separate content management app service, all running their own DEV, UAT and LIVE instances - it’s just under 300 app services in total.
If we used, say 10 workers to deploy in Legacy Mode that would be plenty to avoid queues based on our current deployment frequency, and your pricing page tells me that would be $840 per year for rolling renewals, but if I look at the pricing for 300 app service deployment targets it’s over $20,000, which I’m sure you can imagine would raise an eyebrow or two if I suggested it. (Btw, I’d happily have you correct me if I’m wrong - I don’t actually get involved in the procurement side of things so I might have misunderstood the license requirements for the different scenarios).
We’ll obviously need to flatten our parent-child structure until any new grouping feature is built, but I can’t really see us switching off of Legacy Mode, and tbh, I think my client would probably at least look at other platforms if the Legacy Mode were ever removed just because of the licensing implications. (Either that, or they’d look at writing their own custom step template to deploy app services, which probably wouldn’t be as feature-rich as the built in one!)
Thanks for the response - I hope the additional info above helps explain the decisions behind why we’ve done things the way we have right now.
In terms of step grouping features, I don’t know how this would work with backward compatibility, but having new built-in step templates called “Rolling Deployment” and “Step Group” might help.
The idea would be that instead of adding one deployment step (e.g. “Run a Script”) into another deployment step (e.g. another “Run a Script” step), which currently creates a parent “pseudo step”, you’d have to explicitly create a “Rolling Deployment” (where you’d configure the rolling options) or “Step Group” step in your process, and you could only add steps into these types.
That’s a bit of blue-sky thinking though - the practical realities of adding functionality to the current product might mean it’s not realistic (or would need a very complicated database migration script to convert existing processes during the Octopus upgrade process).
)