Deploy Forms application to Azure Files

Hi, we need to deploy a couple of WinForms apps to shared folders in Azure (Azure Files). We had a deployment that used to work on-prem, but now fails as there is no processor in Azure Files to run the powershell script
I think we need to deploy locally (to server or other tentacle), perform all the config file substitution, run any scripts, then copy the final folder structure to the shared folders (in Azure Files).
Is this just a simple case of changing the target from the old on-prem share to be local (Octo server or tentacle), then having a copy step afterwards (to put the deployed files to Azure Files)?

Thanks
Richard

Hi Richard,
Thanks for reaching out! Depending on what your process is to configure the application, you might be able to use the Run an Azure Script step on a worker. A worker is basically just a tentacle that performs these kinds of actions for targets where tentacles can’t be deployed. You can find more documentation here.

This video might be helpful: Ask Octopus - How do I upload files to Azure Blob Storage? - YouTube. You might be able to do a similar process, but instead of blob storage you would obviously call the files storage CLI commands. At the 3:03 mark where Ryan gets done referencing a package, you can perform config file transforms by clicking the Configure Features button.

So the overall process would be to configure the Azure account. Then set up the process using Run an Azure script step which would reference your application package and perform the necessary configuration transforms using the Configure Features functionality. Then the script you would run in that step could use the Azure CLI commands to copy the resulting files to Azure Files storage.

If your process is a little more involved and you find this won’t work for you, let me know a little more about your process and we can go from there.

I hope this helps!

Thanks,
Mark

Thanks Mark, I think that’s more complex than we need. At the moment, we have a ‘deploy a package’ step which runs on a tentacle which unpacks it, performs config file replacements, then copies files to a server (old way, working) or Azure Files (new way, not working).
From the logs, it copies to the files to the target location, then runs:
Executing ‘\azfs01a.file.core.windows.net\backoffice\IT\Eureka<projectName>\Dev\System\Octopus.Action.CustomScripts.Deploy.ps1’
10:41:01 Verbose | Setting Proxy Environment Variables
10:41:01 Verbose | Writing script module ‘Delete and Copy Config’ as PowerShell module Library_DeleteandCopyConfig_637737792596564141.psm1. This module will be automatically imported - functions will automatically be in scope.
10:41:01 Error | . : AuthorizationManager check failed.

I think all we need to do is a deployment to the server with the tentacle, perform the variable substitution, then do a manual copy of the files to the shared AZ folder. Is there a package which will do that, without trying to do the copy?

We have a deployment script (run after config changes, before core deployment steps) which do some further config-file copying. I think this could be the cause of the problem

Thanks
Richard

Hi Richard,
Yeah, it looks like the Library_DeleteandCopyConfig PowerShell module is trying to be run from your shared Azure Files directory (\azfs01a…). That’s my assumption from those log statements anyway. Running scripts from an external share may cause some issues with the security policy Windows uses. This article may be related: How to Run PowerShell Scripts from a Shared Directory - Scripting Blog (microsoft.com).

Nevertheless, if you just want to deploy your package to the server you have the tentacle on and perform transforms, you can do that with a Deploy a Package step. It will still have all of the .NET config transform features in there as well.

You can follow this step up with whatever process you want to do to then copy those files over to your Azure Files directory, whether that is manually or using Azure CLI commands.

I hope this helps!

Thanks,
Mark

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.