Steps that run on the server (e.g. deploy Web-App) always run

Legacy Uncategorised
1

Hi,

I am currently using the Octopus Web Role Deploy package in conjunction with Polling tentacles to enable an Azure cloud service to bootstrap itself with an Octopus Tentacle.

The Octopus deployment project makes use of steps that run on the Octopus Server (not a tentacle on the server) such as “Deploy an Azure Web App”. What I’ve noticed is that these steps run every time my cloud service role (in my case the role is called ‘worker’) triggers a deployment just to itself.

My questions are:

  • is it correct that a step that executes on the Octopus server runs even though it’s not tagged against the role which triggered the deployment?
  • is there a way to stop this from happening which keeps using the out-of-the-box steps?
  • will I have to change to use custom Powershell steps that run on a tentacle on the Octopus server, which will be identified as a different role, and therefore not executed in this scenario.

Thanks for any advice,

Graeme

2

Hi Graeme,

Thanks for getting in touch.

It is correct that steps which execute on the Octopus Server are not scoped to a role so they will run every time a deployment is triggered. Scoping to a role basically means “run this step on targets that have this role” and steps that run on the server will never run on targets with a role so scoping them to a role does not make much sense.

I think in this scenario you could use channels and scope a sub-set of your steps to do a partial deployment when you don’t want the server-side tasks to run. When your worker triggers a deployment to itself it could do so in the “partial deployment” channel.

Does that help at all?

Cheers,
Shane

3

Hi Shane,

Thanks for the response - this doesn’t really help me though.

I’m not sure if you’re familiar with the way the Octopus WebRole WebDeploy works, but in a nutshell the Azure roles always ask to re-deploy the last deployment that came to them, for their specific machine. So a channel isn’t much use as there would be no-way to be certain that the Channel represented the original deployment.

I think scoping the server targets makes a lot of sense as-much as

    1. Always run this step
    1. Only run this step when not deploying to a specific target / role.

I would guess that its the same way that people use a seconday tentacle on the Octopus Server with a role such as ‘Octopus Server’.

Looks like for now we’ll have to switch over to custom steps running on a tentacle on the server rather than running these ‘server steps’.

Thanks,

Graeme

4

Hi Graeme,

Thanks for describing Octopus WebRole WebDeploy, I understand now why using a channel would not work.

In version 3.3 you can indirectly define roles for server script steps by creating them as a child step. In that case the server step will run for each target in the role and with all of the variables available to that target. So I think the same behaviour would be expected when the server step is defined as a top-level step and assigned roles: rather than “run only when this role is present in targets” it would “run for every target in this role”.

I can see your point though: it would be handy to exclude server steps when deploying to certain targets.

I think your best bet at the moment is to go with a Tentacle running on the server.

Cheers,
Shane

5

Hi Shane,

Thanks for the response. I’ll open a user-voice to try and get this voted into the product.

In the meantime with respect to your comment of, “I think your best bet at the moment is to go with a Tentacle running on the server.”, can you offer me some steps as to how to make this work. I can’t see an obvious way to access the management certificates from any other step other than the inbuilt Azure ones.

So - how does a step running on a tentacle which resides on the Octopus server access an Azure management certificate that has been uploaded to Octopus?

Thanks,

Graeme

6

Hi Graeme,

Having a ponder about this one I wonder if it would model better using Azure deployment targets instead of steps? I forgot about deployment targets as we tend to encourage steps but they may work in this case.

Could you create Azure Web App deployment targets with a different role to your cloud service role. Use a normal package deploy step to deploy to that role instead of the “Deploy an Azure Web App” step. Then you could exclude steps by role while using all the Octopus built-in functionality. More on Azure Web App targets here: http://docs.octopusdeploy.com/display/OD/Azure+Web+Apps

Would that make sense for what you are trying to achieve?

Cheers,
Shane

7

Hi Shane,

Just before I try this the first line on the documentation states:
“As of version 3.1, Azure Web App deployment targets have been deprecated. Instead, please use an Azure Web App Step. See our blog post for more details.”

Is this a sensible idea?

Cheers,
Graeme

8

Hi Graeme,

We have them slated to disappear in 3.4 but at the moment I am struggling to think of another way to model what you want in Octopus.

If you want to go down the Tentacle-on-server path then you would need to script against our API to retrieve certificates. The accounts endpoint is /api/accounts and you could make use of Octopus.Client to make life easier.

Cheers,
Shane

9

Ah OK - I see.

With the API - does a tentacle have an API Key by default that it uses, or
would it need to be a variable?

Cheers,
Graeme

10

Hi Graeme,

You would need to create an API key and use that on your Tentacle: http://docs.octopusdeploy.com/display/OD/How+to+create+an+API+key

More information about the API is available here: http://docs.octopusdeploy.com/display/OD/Octopus+REST+API

And some samples on GitHub: https://github.com/OctopusDeploy/OctopusDeploy-Api

Cheers,
Shane

11

Makes sense - thanks for the pointers and thanks for your input Shane.

Cheers,

Graeme