I have been using Octopus for a long time, but right now I’m at a loss on how to proceed. (The background of all this is the lack of support for deploying ASP NET Core applications, so I need to create this flow myself.) These are the simple steps I want to carry out:
- Unzip a package from the internal feed
- Run custom config transformations/replacements (as an Octopus step template)
- Upload the resulting files to an Azure App Service (using
Run an Azure PowerShell Script)
I have tried running this on the server, but then there is no good way to extract my package. Well, it can be done, but the files are not persisted to the next step.
I have tried running this on a tentacle, but then my
Azure Subscription (account in Octopus) is not available.
- Why am I not able to choose where to run my Azure Powershell Script? For non-Azure scripts, I can choose between server and tentacle.
- How to get access to my configured Azure Subscription when running a normal powershell script or tentacle?
- Forcing the package contents to be unzipped on the server (using
Script file inside a package) does unzip the package, but they’re all removed when my next step starts executing.
- Are features like
JSON configuration variables not at all accessible from custom scripts/steps?
I’m really at a loss here, having spent way to much time for these three simple tasks. Could you please give my some idea how to proceed?
It’s great to hear that you are working with ASP .NET Core apps deploying through Octopus. Before I proceed to give my thoughts on the correct approach could you please clarify what your deployment process itself looks like?
If you are deploying to an Azure VM then you should just be able to install a Tentacle on the remote machine and run a normal deployment step. The config transformations and replacements should then work as per usual.
If however you are trying to deploy to an Azure Cloud Service or Web App then this can be done using first class step types. We have various documents on how to perform these steps. These step types will push the contents of your package up to the appropriate locations along with performing the standard config transforms and replacements. You can also then run Azure Script steps that will allow you to run PowerShell Scripts within the context of your azure account.
These azure features are available in the latest versions of Octopus Deploy. What version are you running with?
Am I misunderstanding what you are trying to achieve? If so could you clarify what your architecture looks like (what is being deployed to where) along with what you are expecting the deployment to do? If its just a standard asp .net core project that needs to be deployed, then it should already be supported out of the box without any need for extra scripting.
Thanks for the extra information,
Thanks for your reply.
I am deploying my ASP.NET Core app to an Azure App Service (ex-Azure Web Site). This is currently not supported by Octopus, since everything gets deployed to
wwwroot, when some things need to go into
approot. See this thread for a further explanation by your staff
This is the reason I feel I need to do this myself. Given this background, do my questions seem somewhat clearer?
Thanks for extra clarification about what you are deploying.
I have had chat with the developer who previously worked on deploying these ASP.NET Core apps and he has pointed out a GitHub Gist that he put together which may server as a temporary work around until the GH Ticket to update to WebDeploy 3.6 is resolved.
So long as you have your project all packaged up it just invokes Web Deploy 3.6 in a script step.
As the .Net Core project still still hasn’t reached the RTM stage, it still appears to be a bit of a moving target that has only recently started stabalizing. This is why we havent yet invested all of our resources into dealing with it as a first class citizen, however it is a key goal that we intend to keep an eye on.
I hope this information helps you on your way to performing these deployments,