I'm about to use Azure Service Bus and I'm going to have at least 4 environments that will be used for different parts of the development process, i.e. Build, Test, more Testing, and finally Production.
I would like to export my set of Queues and Topics from my namespace(s) and deploy them to other environments.
Does Azure offer a way of doing this, or do I need to create something myself?
You can use Azure Resource Manager to create a template to deploy your namespace with a set of queues and topics (with topic subscriptions).
To configure your template for Azure Resource Manager, see https://azure.microsoft.com/en-us/documentation/articles/vs-azure-tools-resource-group-adding-resources/
You cannot add the configuration for a service bus with the GUI of Visual Studio but you can do it manually by following this template : https://github.com/sjkp/Azure.ARM.ServiceBus/blob/master/Azure.ARM.ServiceBus/Templates/DeploymentTemplate.json
Currently, the configuration for service bus is not well documented...
Related
At the company that i work, they deploy applications to azure using Azure App Services.
This involves creating the App service manually, and setting up the pipelines manually.
My question is if there is another way to host and run applications in Azure without using App Services?
The reason for this is that i don't like the manually work when setting up a app service and all it's configuration.
Any suggestions?
What you actually need is setting up CI/CD pipelines for your application to create resource(AppService in this case) and deploy on them.
If you are new to Azure Devops, i would highly recommend to explore Devops starter service to deploy your application with few clicks and see how it creates resources and pipelines automatically
On the 2nd question, there are many compute options available on Azure such as Virtual Machines , AKS (Containers Orchestration) , Container instances etc.
You can explore those compute options using the decision tree here
I have an app service running on Azure with an associated SQL server DB.
I would like to create a test environment for the project.
I looked at a few Azure Dev/Test tutorials but they are for setting up VMs and I couldn't see anything indicating it can be used for a app service.
Is my only option to duplicate the appservice, db, ssl certs, custom domains and effectively double my azure bill?
Bruno gave good advice, but here's a few more things to consider.
If you use deployment slots, you are sharing your Web App CPU and memory between all slots. If something goes horribly wrong with a test build that's deployed to a slot on your production machine, your production environment can end up resource starved. I personally don't recommend using slots for testing for this reason. Slots are more for smoke testing/warming up a build that you're about to swap into your production slot.
If you want to save money yet still have the benefit of separate environments, consider looking into ARM templates. ARM templates let you script the provisioning of Azure resources. You can create ARM templates based on your production environment, including scripting the App Settings section of your Web App to hold test configuration settings. You can then deploy your ARM template that spins up a test environment right from a Visual Studio project. If you put all of your test resources into the same resource group, tearing down your test environment is a few mouse clicks to delete the test resource group.
For the App Service, you have something called Slots. This allows you to have multiple environments on the same App Service. You can also have multiple Web Apps under the same App Service Plan as well instead of using Slots, so in this case, you only pay for 1 backend. App Service has a Free Tier, but with limitations such as not supporting custom domains.
Set up staging environments in Azure App Service
For SQL Databases you have to pay for each DB or use Elastic Pools (1 backend for multiple DBs) but that's only worth when you're using at least 100DTUs DBs. The minimum database you can have is the Basic one, but that's $6/month.
I have a Worker Role that need complex environment settings (install a couple of softwares, setup some directories and etc) so I want to deploy it to VM ( instead of Cloud Service that specialize in more simple environment without pre configure settings).
The problem that I can only publish to Cloud Service (from VS 2013), am I missing something ?
I tried to find some article and relevant materiel about deploy a Worker Role to a VM and the only things I found is related to the Cloud Service.
How can I do it ?
(or provide me a general guidelines)
Simply put, you can't deploy a Worker Role as is into an Azure Virtual Machine (IaaS) without doing code changes.
Things you could do:
Isolate your business logic into a separate DLL and then create a separate Windows Service project which consumes this DLL. Then you could deploy that Windows Service into a VM. Do note that your business logic DLL should not have references to any libraries which will only run in Cloud Services kind of environment (e.g. Diagnostics, ServiceRuntime etc.)
Do take a look at Startup Tasks for Cloud Services. They do provide a mechanism to perform additional tasks like installing software when your Cloud Service is deployed.
I got a cloud service (worker role) which I want to deploy to a beta and a production environment.
It seems a waste to have to create three projects (one with the actual implementation and two for deployment).
Is it possible to create two deployment profiles which links to different Azure destinations but uses the same worker role project?
This is very simple to do. Just build your Azure package without deploying, and keep your dev/beta/prod settings in the Service Configuration, not embedded anywhere like web.config/app.config. Then store both the deployment package and configuration in blob storage (speeding up deployment). You'll want multiple configuration files: one for each environment, each stored separately in blob storage.
Once this is done, you can just deploy the package to multiple cloud services, each with a different configuration file. This can be done either through the portal or through PowerShell / CLI.
If you've been deploying directly from Visual Studio, it might not seem quite as obvious. But from VS, you can build a package without actually deploying.
I'd like to know what is the best practice for doing incremental production deployment in azure with servicebus,
How to ensure that the messages don't get deleted when deploying a new version
Is there a backup mechanism to save the messages and load it back after the deployment is complete?
The Windows Azure Service Bus is a service which runs outside of your deployment, similar to Windows Azure SQL Database or Windows Azure Storage. This means that it does not depend on your deployment: you can deploy, remove, re-deploy your application without impacting the messages present in the Service Bus.
The only thing you'll need to take care of when you deploy a new version of your application is that the messages available in Service Bus Queues / Subscriptions might have been sent by the old version of the application. So take into account that the new version of your application will need to be compatible with these "old" message formats.