I have a web app that has been developed using Glassfish server, and am looking to change hosts to Microsoft Azure.
The trouble is, Azure appears to not support Glassfish as a web container, and instead only currently offers Jetty or Tomcat.
Unless I'm missing something, I believe I will need to convert my server to run with one of the two above options, although obviously if there is a method to run GF on Azure that's the ideal option.
Looks like there is a concept named 'worker roles' which can be used to do this.
Have a look at this article: https://blogs.msdn.microsoft.com/dachou/2011/01/17/run-java-with-glassfish-in-windows-azure/
More information:
Microsoft Azure and Glassfish
GlassFish and Java EE 6 everywhere, even in the Azure cloud!
I think you're looking at Web Apps, which doesn't include Glassfish. But that doesn't stop you from simply spinning it up in your own VMs (or web/worker role instances, assuming you can install it in an automated way, in Windows).
Note: to deploy Cloud Services (web/worker roles) you're limited to Visual Studio and Eclipse (on Windows) for creating the deployment package.
Related
Having being unsuccessful to find a decent resource I am finally asking it over here. I have a legacy .Net Frmework Windows Service (which is now migrated to .Net Framework 4.7.2) which I want to eventually migrate to Azure PaaS. After looking around I found 3 ways I could do that and not counting the options like hiding it behind a web app hosted in IIS because I do not think that is the correct solution. I think the correct ways are:
1) Use Worker Role: This is provided by the legacy Cloud Services platform and due to its slow deployments and staging costs is out of question.
2) Use Web Jobs: It may need code changes but I am unable to find a decent article or tutorial in the context of windows services.
3) Use Containers: This seems to be the solution most suitable but I want some expert to guide me through it as I am completely new to docker and azure. Since the service is in .Net Framework, the target OS could only be Windows Server Core(https://learn.microsoft.com/en-us/dotnet/standard/modernize-with-azure-and-containers/modernize-existing-apps-to-cloud-optimized/deploy-existing-net-apps-as-windows-containers) but when I pull the image I get the message that it "cannot be used on this platform". I am using Windows 10. Does this mean that I need to be working on Windows server family OS to be able to pull image which effectively means that to be able to deploy .Net Framework application in an Azure container, I need to be working on Windows Server OS.
Links to a few good reads or videos are welcome as I am unable to find may be because I am not searching it correctly. I would imagine that windows service migration to Azure is a common scenario but I may be wrong.
Do follow the steps mentioned here
,
https://github.com/dotnet-architecture/eShopModernizing/wiki/02.-How-to-containerize-the-.NET-Framework-web-apps-with-Windows-Containers-and-Docker
Also for your windows service, you do have a couple of other options as well
1) Convert your app into an Azure Function and run it on timer trigger. But your app must complete execution within 5 minutes.
2) Deploy your app as a timer triggered web job.
We have a web application that we have hosted as an app service in Azure.In this we are using excel.interop services. Would like to know whether we will we able to retain the same code in the application after hosting it on azure.
As far as I know, if we want to use Microsoft.Office.Interop.Excel, we should install MS office. But it seems that Azure App Service does not support it.
I recommend two workarounds:
Use Azure VM to host the application and install MS office on the Azure VM, you refer to this article.
Instead of excel.interop, use OpenXML to do it, you could refer to this article.
Hope it helpful.
You can "containerize" your application as a container and run it in App Service as a Windows Container App (this feature is still in preview).
https://azure.microsoft.com/en-us/blog/announcing-the-public-preview-of-windows-container-support-in-azure-app-service/
https://azure.microsoft.com/en-us/updates/windows-server-2019-support-added-to-public-preview-of-windows-container-support/
https://learn.microsoft.com/en-us/azure/app-service/app-service-web-get-started-windows-container
https://learn.microsoft.com/en-us/azure/app-service/app-service-web-tutorial-windows-containers-custom-fonts
i have a web application which is created using .net framework 2.0 which is running on windows server 2003.is it possible to migrate that to Microsoft azure.if so does it require an entire rebuild on azure?
A really useful utility for this case is Azure Migration Assistant.
https://azure.microsoft.com/en-us/downloads/migration-assistant/
It will check all your IIS sites and show you if it can be moved up to an App Service, checking target framework, port bindings, etc.
If everything is ok, it can do the migration for you.
Worst case scenario, you can move your application to Azure inside a VM.
It depends on what you mean by "migrate".
If you think about moving as is, you have an option to choose IaaS, where you'll just get a VM and do what you want on it. That'll give you both full control as well as full responsibility over your app.
Otherwise, if you want to avail of the PaaS offering, you'll have to make minor tweaks to your application (assuming the framework version is supported).
I am trying to use ABCpdf .NET with Azure App Service and getting the following error when generating a PDF.
Unable to render HTML. Failed to configure IE 9 or above for the MSHtml engine:
Access denied while writing to the registry.
For IIS applications, please enable "Load User Profile" or
consult MSHtmlBootstrap in the documentation.
Usually in a VM I would set Load User Profile to True and it works but in Azure App Service, I do not have access to IIS Application Pool configuration.
According to the developer of ABCpdf, it should work with Azure websites.
http://www.websupergoo.com/support-azure-abcpdf.htm
Windows Azure Web Sites
WAWS sites operate as 32-bit processes in a multi-tenanted environment. In order to isolate one site from another WAWS is locked down to prevent inter-process communication. While you may find ABCpdf (32-bit) will install to WAWS, we expect the functionality will be diminished.
You cannot modify the registry with Azure Web Apps (formerly Web Sites). So, you're getting an error because the app cannot register itself. Being a multi-tenant service, you are not allowed to make registry modifications.
You need to go back and look at that page again, where they suggest using a VM or a web/worker role (both of which do allow for registry modification).
Even though this is a few years old it's the top StackOverflow question for "ABCpdf App Service" so it seems pertinent add an updated answer.
As of version 12.1 ABCpdf.NET includes the ABCWebKit HTML rendering engine based on WkHTMLToPdf 0.12.6 (Qt patched version).
Although limited compared to the default ABCChrome engine, it will enable rendering in a 64-bit Azure App Service on Windows using Basic App Service plans B1 and above.
NB: it will not work on any of the free App Service plans, or on 32-bit instances.
More information:
Updated ABCpdf .NET Azure Deployment Guide for App Services
Example project on GitHub
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.