Octopus Azure deployment - ServiceAccounts vs Application targets

usability
(vikram chirumamilla) #1

Hi

I am currently using Service Accounts in Octopus to deploy to azure.

I do my app registrations in Azure and use a resource group and in Octopus when i use the service account i get the list of apps under the resource group.

But i have noticed this message in octopus under Account and Web App in azure web deploy process

This step is referencing an Azure Account directly, instead of referencing an Azure Web Application Target through Roles. Please read our documentation to learn how to get started with Azure Targets.

When i follow the link i also see this message

Regarding Azure Cloud Services, Azure has announced that from June 30th 2018 they are retiring support for Service Management API (which indicates Cloud Services). Azure has stated that “Cloud Services is similar to Service Fabric in degree of control versus ease of use, but it’s now a legacy service and Service Fabric is recommended for new development”

I am a little lost here. I updated my deployments from using management certificates to Service Principal Accounts earlier this year.

Do I have to upgrade from using service accounts to application targets. I have a bunch of deployments lined up in the coming weeks.

Could you help me understand this.

#3

Hi Vikram,

Thanks for getting in touch!

Service Accounts and Application Targets are two totally separate things here, Service Accounts is how we authenticate against Azure and Application Targets is obviously what we deploy to. That message is there because you’re using the old version of our Azure steps (where you specified the account and target on the step itself). The new way is to register your Azure Web App as a target (and you then configure the Service Account to use on the target itself).

So, for now you don’t have to do anything. I would recommend starting to migrate to the newer steps when you can as we might remove support for the old steps at any point and then your deployments would break until you reconfigure to use targets instead.

Any questions please let me know,

Regards
Alex

(vikram chirumamilla) #4

Thanks Alex for your response.

I am working on setting up the application targets.

We have set up 3 environments in azure, uat stg and prd and we do not use deployment slots.
With the older version of azure steps we were able to use binding variable to dynamically bind the webapp name by setting up environment variables for each environment.

Ex:

Under variables

deploy_env -> uat for uat
stg for stg
prd for prod

My webapps in azure are Webapp-uat, myWebap-stg, myWebapp-prd

And in the azure step i would bind the web app name as

      myWebApp-#{deploy_env}              

How do i do that with deployment targets.
Essentially i have to create 3 deployment targets for each environment per webapp.
Then how do i dynamically bind deployment target to a deployment step have octopus pick an appropriate webapp for each environment.

#5

Hi Vikram,

As you’ve worked out you will need 3 targets, one per environment named for that environment with an appropriate role name (e.g myWebApp). These three targets should then be in the matching Environment in Octopus (UAT, STG, or PRD) with a lifecycle that is configured for those environments.

Once that is setup when you deploy to any given environment it will automatically select the correct deployment target, which in this case would be your Azure Web App.

Any further questions please let me know!

Regards,
Alex