I have an application that consists of an Angular 2+ frontend deployed on a separate App Service to my .NET Core backend (per environment).
I'm investigating zero-downtime deployments with Azure App Service staging slots, however I don't understand how I'd have this setup in my case, because:
My FE and BE are deployed via DevOps CI/CD automation, and are built + deployed in an Azure Pipeline - meaning my Angular app has its API URL set in whichever environment.ts file is chosen (depending on which environment is being deployed to).
What is the correct way to achieve having a zero-downtime deployment setup in Azure in this case?
You are correct in that you won't be able to use deployment slots with your Angular app, since the configuration is bundled with the code. You can use Azure Static Web App with CDN to achieve this.
For your backend, deployment slots with auto swap enabled should get you what you're looking for.
https://learn.microsoft.com/en-us/azure/storage/blobs/static-website-content-delivery-network
https://learn.microsoft.com/en-us/azure/app-service/deploy-staging-slots
Related
We are currently using Static Web Apps for our front end web client with an independent Azure Function App supporting the API requests.
The production Azure Function App URL does not change and as a result we are able to deploy consistently to the production Static Web App and independent Azure Function app using Github Actions.
We would like to mirror the dynamic Static Web App deployments with Azure Function App deployment slots for our non-production environments. We would like to dynamically create a staging environment for each PR created in Github.
Is it possible to deploy to a unique dynamic Azure Function App deployment slot and return the Function App hosted URL via Github Actions back to Static Web Apps configuration?
Is it possible to deploy to a unique dynamic Azure Function App deployment slot and return the Function App hosted URL via Github Actions back to Static Web Apps configuration?
In my view, it is possible to create the Slot in Azure Function App as a Staging Environment and you can push every (Code Release) to the Staging Slot Environment.
There is a feature called "Swapping" and 2 kinds of swapping i.e., swap and auto-swap.
If you want to create many slots (staging environments), which is called Scaling the Slots. This Slot Scales when the Function app scale in Consumption Plan and in app service plans, Slots runs on fixed number of workers running in that plan.
You have to deploy the Azure Function App either in App Service Plans or Premium Hosting Plan for scaling the slots because only one deployment slot allowed in Consumption Plan and can enable the auto-swap for pushing code to production from staging environments for every code release.
Refer to the MS Doc for more information on Scaling the slots in Azure Function Apps.
I have created one web application in angular and backend api is build in asp.net core.
Now my clients wants to manage two deployment slots :
1.Staging
2.Production
My Requirement is when client perform swap operation from staging->production , at that I need to change one variable which is placed in /assets/config.json(in angular application).
Basically I am placing my base-url in /assets/config.json file and when angular app is loading ,in app_initializer, i am using this base url from config.json and i am performing web api call to fetch appliation specific configuration for azure active directory.
Now base-url is different for both environments.
I have placed other app configuration variables in "configuration" section in azure app service.
But now when client swap from staging to production at that time I need to change "baseurl" but i am not able to get any provision in azure configuration section for this.
If anyone knows than please help me
If an App Service Plan containing an App Service is horizontally scaled in Azure (using Monitor - Auto scale functionality) how does that affect future deployments via Octopus if the "Deploy to Azure" step is used. Would any deployments automatically get deployed to all scaled instances in Azure without us having to do any more configuration in Octopus?
Octopus will not automatically deploy to scaled instances without configuration. You will need to configure Octopus to automatically deploy to targets using project triggers. You can find documentation on using project triggers here: https://octopus.com/docs/deployment-process/project-triggers/automatic-deployment-triggers and documentation specifically concerning auto-scaling infrastructure here: https://octopus.com/docs/deployment-patterns/elastic-and-transient-environments/keeping-deployment-targets-up-to-date
I'm using the ASP.NET Core & Angular startup template from ASP.NET Boilerplate with Multi-Tenancy disabled: 1 database with a single tenant(Default).
I'm also using TeamCity to build/test/publish the projects available in the startup template so I end up with 3 NuGet packages that are getting pushed to Octopus Deploy:
API (Host project, ASP.NET Core Web Application)
Migrator (Console application, capable of migrating the database(s))
UI (Angular App)
I want to deploy this setup to Azure with Octopus Deploy(self hosted, v2018.9.0) in the following way using 2 App Services(Host & UI) and 1 Azure SQL database(Host):
Take the UI and API applications offline, displaying a friendly maintenance message while updating the projects.
Migrate the database using the Migrator package
Deploy the API application package
Deploy the UI application package
Put the API application online, maybe some more tests to check that it's working correctly
Put the UI application online.
If all this was on-prem, I would have no questions. It's the Azure part that I can't figure out because I don't know how to do these things on Azure via Octopus Deploy:
Put an Azure App Service offline/online (using an app_offline.htm file)
Deploy the Migrator package to the API Azure App Service in a special folder(so that I don't overwrite the API deployment) and run the migrator: dotnet [migrator.dll] -q
I tried using the Octopus Deploy "Deploy an Azure Web App" but this step won't let me also deploy the migrator package and run it before the API package is deployed. Or does it? I don't know how.
I tried using the "Run an Azure PowerShell script" but this executes on the Octopus Deploy server and not on the Azure App Service environment right?
Maybe there are other, even better, approaches deploying this setup to Azure?
You can use App service slots to swap in/out version of your logical applications. When you swap there's a warming up that occurs and no loss of traffic.
So basically deploy to backup slot, then swap production with backup slot.
For the db I don't think your strategy is valid. There are some assumptions you are making that will not make your life easy. I would look at handling the db deployment separately with no breaking changes but that's my opinion.
I'm not familiar with Octopus or TeamCity so I won't go into details about those.
I have setup continuous deployment of a standard web api project to an API App on Azure. The new version is deployed to the staging slot and then swapped with production at the end of the release task. I can see that (by going to App Service Editor in azure portal) the dll file versions reflect the latest changes. But when I access the APIs (from a webapp or postman) on this Azure app the result does not reflect the published changes. The only way I can force the new changes is either restarting the API app or stopping and starting the app service.
Am I missing anything in using continuous integration with API app on Azure?
I have solved this by adding a new task available in VSO release which restarts the staging slot before swapping with production. This makes sure that the new changes are part of the IIS process.