I am looking at migrating a dotnetnuke website to Azure. I need both staging and production versions of the site to be running.
I have looked at using Azure Websites, but at the moment there is no support for SSL on custom domains so this can't be used for the production website. I have migrated the staging site to an Azure Website and now have numerous options for publishing updates (ftp, git, using web matrix).
Due to the constraints of Azure Websites, I used the DNN Accelerator to create a cloud service for the production environment. This set up will allow me to have control over IIS and therefore manage SSL certificates (I think).
The problem I have with this is there does not seem to be any publishing options. The only way I can publish is by connecting to the Azure instance via RDP and then copying the website files onto the files system.
Are there any other ways of publishing? I have looked at converting the website to a WAP, but I believe this has implications when it comes to updating to new DNN versions.
You should never publish your application through RDP since these changes are non-persistent (meaning what you published might disappear after a hardware failure / ...). Adding new instances would also mean that these instances don't have the files you published before.
I suggest you start by looking at the DotNetNuke Azure Accelerator first. If this doesn't fit your needs you might always try to build something yourself, but if you want to say with a regular website and not a web application I wouldn't count on Visual Studio support. In that case you might want to look at creating a package from the command line and using startup scripts to add your website in IIS.
Sounds like you need to use a Start-up task to install the files in the correct place for a Web Role (Cloud Service) Smarx has a nice overview here, MSDN has a wealth of info too http://blog.smarx.com/posts/introduction-to-windows-azure-startup-tasks
Another option is IAAS for Azure with a persisted VM, more work mind you, Cloud Service would be the most efficient and correct solution...
Related
I want to deploy Kentico 9 site on Azure and want to use shared file system for my media content, can you please suggest which Azure configuration (Azure Cloud Services or Azure Web Apps) I should referred?
I'd highly recommend going with Web App over Cloud Services. Mainly because Web App is almost like running on a regular server where Cloud Services is quite a bit different and harder to work with in my opinion.
Check this article out regarding some issues with Kentico and Azure Blog storage as well as how to setup your storage provider to only store media files.
http://www.kehrendev.com/blog/brenden-kehren/may-2016/problems-with-azure-and-kentico
Could you describe what do you mean by shared file system for my media content?
From my experience - it`s (a little bit) easier to deploy (and maintain) Kentico to Azure Web Apps but they do not provide so many customizations - in my humble opinion - the biggest one is you are not able to connect via remote desktop (but this is supported by Azure Cloud Services).
Please note - if you are using Cloud Services you must use Azure Blob Storage - source - which could be in conflict with your requirements.
You can find more information about Web Apps vs Cloud Services vs Virtual Machines on the mentioned page.
TL;DR; - if you do not need customizations, remote desktop and startup tasks - go for WebApps. If not, try to specify more requirements.
You can also check comparinson of the technologies from the Microsoft`s point of view here.
It's not clear who you want to share the media with...
If you want to share the assets amongst more Kentico instances or with a 3rd party system, I'd probably use the Azure Blob Storage. Kentico comes with a dedicated file provider for this exact use out of the box. It's called CMS.AzureStorage.
Using the blob storage is not a limiting factor in terms of hosting your app. You can still use all available options: Web Apps, VM or Cloud Service. There are some technical implications, of course. But they're all described in the documentation.
I recommend checking the comparison matrix to find a hosting option that suits your need best. Kentico recommends using App Service (Web Apps) for most projects as it's easiest to maintain. However, you can't use certain features like Kentico Windows services, for instance. Question is, do you really need them?
I am currently doing some research for the development of a mobile application for our company that should support offline data sync (on an iPad). We have explored many possibilities including PhoneGap/Cordova, Xamarin and simply native iOS development. Xamarin, for many different reasons, seems to be our best choice, so my question will assume we will develop in Xamarin.
I was looking into a library for managing offline data synchronization and the most obvious solution is Microsoft Azure MobileServices. However, my company is Canadian, and apparently it's hard to trust (legally) our data to clouds based in the US. Since we already deployed internally our WebApi on our intranet, I figured there was probably a way to point the MobileServices library to our own WebApi. I have read about the Azure Hybrid Connection possibility, but our data still conveying through Microsoft servers might not be a possibility. So, my question is this:
Is there a way to configure the Microsoft.WindowsAzure.MobileServices Client library to point directly to our intranet, RESTful WebApi backend, without going through any Microsoft Azure servers ?
I understand that, in order to be able to use the Client librairies seamlessly, we probably would have to adapt our WebApi to implement the necessary .net Backend interfaces. I'm mostly wondering if it's even possible as the MSDN documentation on the libraries all seem to point to direct connections to their servers (no possibilities to configure your own connection strings) and all instructions redirect you to their Azure Mobile Services website.
Thank you.
If you look at the API for your mobile client, you'll notice that the Azure Mobile Services Client SDK only cares about two things:
new AzureMobileClient( url, appkey)
...where it's hosted shouldn't be a concern. Everything else is just configuration.
If you want to host the Azure Mobile Services Backend on your own servers, technically you could do this, but there are likely a few caveats. Microsoft has announced that they will be launching a Canadian Azure data center, but we won't see it until 2016.
In the meantime, here's how you can host the services locally. Note that I have not tried to emulate all of the features of Azure Mobile Services (aka Zumo) so your mileage (or kilometerage) will vary.
Hosting Locally:
From a technical feasibility, you absolutely can run the services locally. I know this because you can create the Azure Mobile Services Backend project from within Visual Studio and run it locally for development purposes. This is what our development team does for testing their mobile applications.
Note that you can create the Azure Mobile Service backend directly from within Visual Studio: New Project -> Cloud -> Azure Mobile Service. You can also download the exact same template (pre-configured with your URL and ApplicationKey) directly from the Azure dashboard: Create -> Mobile Service.
Obviously, if you're hosting it on your server it will be up to you to configure and use a proper SSL certificate for your site.
ZUMO Permissions:
By default, the security roles on the server are turned off. So if you're locking down any of your methods using the [AuthorizeLevel] attribute these settings will be ignored at runtime. If you need to enable this feature you can do so by modifying the WebApiConfig.Register() method and marking the site as self-hosted: config.SetSelfHosted(true).
Configuration:
From a configuration perspective, the Azure Mobile Service dashboard provides several tabs for configuring Identity, Push Notifications, Connection Strings and App Settings. Sadly, you won't have a dashboard, but all of these settings have a corresponding value in the local web.config. Any value you provide here is automatically overwritten in Azure, but they're used when running locally.
The minimum settings you'll need to configure are listed here. The ApplicationKey you can distribute with your ZuMo client, but the MasterKey is for the Admin authorization level so you'll want to keep that secret. The MobileServiceName is used by the EntityFramework for your database schema and what appears in the URL of your site.
<add key="MS_MobileServiceName" value="myzumosite" />
<add key="MS_MasterKey" value="masterkey" />
<add key="MS_ApplicationKey" value="appkey" />
Values that start with a MS_ prefix map to corresponding values in the Azure Portal. MS_GoogleClientID and MS_GoogleClientSecret map to the Google Identity values in the dashboard, for example.
Any other value in the AppSettings node is immediately accessible via the ApiServices.Settings property and corresponds to the Settings node in the Azure dashboard.
Database connection strings continue to exist in the connectionStrings node. The same is true for azure notification hub.
Database:
Obviously, the database you configure will be up to you as well. Permissions and User accounts are also obvious. There may be some minor differences between the SQL Azure syntax for Entity Framework database migration scripts that you'll need to worry about. (I've discovered the database migration scripts don't work from the Package Manager, but they do work when the database scripts are run when your website starts)
Caveats:
You will not have a nice dashboard for monitoring performance of your site, reviewing logs or changing runtime settings
You will not be able to scale out your site immediately; Scaling and deployment will be your problem
Deployment configuration is your responsibility (Project -> Publish won't be available unless you configure it)
Not sure if you'll be able to use Azure Active Directory as an authentication scheme, though from the sounds of it that won't be a concern. You can write your own authentication providers: Microsoft's Zumo library only supports a handful, but the underlying Owin.Security package that Microsoft uses supports several dozen systems!
Your site will need to be publically visible to your mobile clients
Push Notifications should work, but you will be using Azure's notification hub for this.
I have no idea where ApiServices.Log will go
The easiest path to take would be to:
Create the Mobile Service in Azure to get the notification hub and settings preconfigured
Download the starter site from the dashboard
Configure the web.config as mentioned here.
It's not possible to simply configure WAMS Client library to work with your own WebApi Backend.
But WAMS library is available at github, so I'm sure you can reuse a lot of code from the WAMS project, especially if you want to use a PCL project.
To route your data securly through Azure, you could think about setting up express route. Additionally, for last weeks update, it's possible to apply a custom domain to the WAMS Backend, including your own certificate to secure your connection.
I'm currently investigating the possibility of my company using Azure.
Our current hosting situation that we run ourselves involves a separate site in IIS for each of our clients, each one having a virtual directory to the CMS we've built with ASP.Net web forms. We can update the contents of that virtual directory, which then provides the latest version of our CMS to all our clients at once.
I'm not looking to recreate that exact situation in Azure, but I am instead interested in figuring out how to create a single Web application in Visual Studio, publish that application to Azure in such a way that multiple sites (that I've specified) are created on Azure. Then I would like to be able to make changes to that application, and publish it again in a such a way that all the sites for it get updated all together, without requiring something be done manually per site/client.
The closest explanation I've found is this one:
http://www.wadewegner.com/2011/02/running-multiple-websites-in-a-windows-azure-web-role/
That gets me close, but what I don't understand is that when I publish this application to Azure, I still only see one application / URL available in the Azure management console. Shouldn't the extra "Site" node result in a different site being available when I publish it? Why doesn't it? Is there a completely separate way to accomplish this that I'm not using?
When you look at the management console you're seeing the web roles that you have deployed, not the sites that are part of that web role which is why you're only seeing one. As long as you've followed the instructions correctly, then yes, you do have two sites running. The catch is that you can only access the main site through that default URL. Presuming you have urls that look like customer1.mysite.com and customer2.mysite.com, you need to make sure you've set these as the host headers in the sub sites and then change your DNS so both of these domains point to URL you can see in the portal (e.g. mysite.cloudapp.net).
When considering a multi-tenant solution, ideally you should design your web-application as a single website that is capable of responding to multiple tenants (each of your customers), as opposed to creating a website/web-application for each one of them. This makes updates across the system manageable.
Your web-application can partition and identity different tenants based on several options such as part of the url (e.g myapp/tenant1 vs myapp/tenant2) or via a host header (e.g. tenant1.myapp.cloudapp.net vs tenant2.myapp.cloudapp.net)
HTH
I'm curious to know if this is possible, and if so, is it a good or bad idea?
We are developing an Azure application that is largely centered around worker roles that receive their work on a CloudQueue, and put the results in a CloudBlob, that the client then downloads. The web interface itself is a dead-simple ASP.NET MVC site that throws jobs in the CloudQueue, and builds URLs to download CloudBlobs.
Currently we accomplish this by having a Azure Cloud Project in our solution, which has a Web Role with the UI, and Worker Roles with the actual work.
Could we use Azure Websites to publish and host the UI, which calls back to our Worker Roles? The Azure DLLs are just regular old .NET libraries, I'm assuming Azure Websites won't have a problem with them. So, when we want to update the UI, we just publish with Visual Studio. And when we want to update the Worker Role - which is 300MB+ and has a bunch of nasty dependencies like Crystal Reports - we can build the cloud bundle and update the Cloud Service through the Azure management portal.
This seems to me like doing this would make it easier to update the UI. I think it would also be cheaper to host it, as we won't have to buy a bunch of instances for the Web Role.
If your question is "Could we use Windows Azure Websites*", based on your application architecture, you sure can use Azure Website to deploy your front end and configure all the networking connection properly so you can continue access other Azure Storage services. As you are using mostly Blob and Queue, you can continue use HTTP/HTTPS settings in the Azure websites. You can keep worker role by as it is however if it is very complex to deploy, using Windows Azure VM may be another direction to go.
I could say website deployment could be easier if your web app does not have something complex to configure in web server as websites may not be able to match web server level configuration compare to webrole and Azure VM. Answering "Easier and cheap" could be very subjective as this is all depend on load and distribution so you would have to try and evaluate it.
What type of projects/software applications are suitable for Azure and why?
Thanks
Rather than thinking of what can be supported in Azure, it might be more helpful to think about its challenges as you decide to port your app over:
Web applications. Since a Web Role hosts IIS, you'll generally have little issue porting a general-purpose asp.net or asp.net mvc website to Azure. There are some glitches you'll run into - see my related answer for more details.
UI. If your app has specific output similar to a WinForms app, you won't be able to run it since you have no video output.
GPU dependencies. If you're doing some background processing dependenton a specific GPU, you won't be able to run in an Azure VM.
Registry and other system-level access. If your app needs to update the registry or run an MSI, you won't be able to install your app.
Instance affinity. If your app requires session stickiness (e.g. a logged-in user MUST visit the same server instance with each access), you won't be able to accomplish this.
COM interop. COM interop is very limited, since you can't install anything via the registry. If you rely on Excel Services, you won't have that capability.
SQL limitations. SQL Azure is limited to 50GB today, and offers no ability to custom-tune the server instance. Also, while it does support a big subset of SQL Server, it doesn't support 100% of SQL Server, so it's possible some of your sprocs may no longer work. There's no SQL Agent today, so you'd need to recreate that functionality in a worker process.
That's just a quick braindump of some challenges you might run into - I'm sure there are others.
Just keep in mind that Azure is providing Windows 2008 Server images for your app to run on, so if your app can run in that environment today, and doesn't require things I listed, you should be in pretty good shape.
You can make most of the .NET projects working in Azure. Azure has support of following project types: web site (both ASP.NET and ASP.NET MVC), worker (background application) and wcf service.
Don't forget security too - there's various ways of authenticating onto Azure but none are as simple as just setting IIS/ASP to windows auth.