We have a requirement to trigger(using a JCL command) a Dotnet Core Console application (hosted on a PCF container) from outside the container. What would be a good solution approach in this context.
One option we have is to convert the console app into a web api and host an API endpoint which can be called from external sources. Web api can then trigger a long running task (may be use something like Hangfire to handle the execution). Would like to hear if there are better approaches that can be used here. Thanks in advance.
Cloud Foundry includes support for running tasks which might be all you need. Additionally, Steeltoe includes some functionality for building tasks into your application. There is a Steeltoe Sample that can run EntityFramework migrations via cf runtask
Related
I have an ASP.NET MVC solution with the following structure:
Solution.sln
--- Solution/Main.csproj
--- Solution.Services.UnitTest/Solution.Services.UnitTest.csproj
For simplicity in this question, lets say my Main solution is both my website and services. So we have one solution with is the "application".
The UnitTest solution is a simple solution that refers the Main project, but with a lot of unit tests (using NUnit).
I have setup automatic deployment in Azure. Every time I make a commit on develop it updates one web-app, and when I update master, it updates another web-app. I've done this by setting up the integration to my Github repo here inside the Azure portal:
Webapp --> Deployment --> Deployment Options
My question is: how do I run my unit test first?
I don't see any options to add this. I don't see any option if I use the newer Continious Delivery (Preview) either.
I can see there is an option to add performance tests, but thatis not what I need.
So my question is two-fold: How do I add these unit tests inside the Azure web portal / updating my build file? And if this is not possible inside Azure, what is the "norm" on how to solve this (very common, I assume) problem?
You can add a custom KUDU script to the root directory of your solution. At that point you have "complete" control over the build and deploy pipeline in Azure. Every web app has a default script in Azure. If you pull your current KUDU script (assuming your are using dotnet core), you should just need to add a dotnet test command before the dotnet publish command and fail accordingly.
https://github.com/projectkudu/kudu/wiki/Custom-Deployment-Script
If you have looking for a friendlier alternative, then you can use any number of CI/CD tools outside of Azure. VSTS offers several free build minutes every month.
I got confused on the correct design decision to execute background & long running tasks inside asp.net mvc web applications. now on these two links :-
http://www.hanselman.com/blog/HowToRunBackgroundTasksInASPNET.aspx
&
http://haacked.com/archive/2011/10/16/the-dangers-of-implementing-recurring-background-tasks-in-asp-net.aspx/
they mentioned that it is risky to run background tasks and long running tasks inside asp.net web applications for the reasons they listed (mainly because IIS is not designed to run these types of tasks). but at the same time they listed some tools that can be installed inside the asp.net project to run background jobs such as quartz.net, WebBackgrounder , etc.
so i am not sure how these tool works ? for example if i install the WebBackgrounder inside my asp.net mvc web application (using nuget), and i deploy my asp.net mvc web application inside IIS ,, so will the jobs defined inside these tools run under IIS also ? or they will run independently of the IIs which is hosting the web application ?
They will run on IIS, but in a different thread. What you need to achieve? Maybe you're trying to solve a problem in the wrong place. Consider decouple this task from your web app using message queue. Then, construct a service to consume messages from queue and compute what you need.
Here's a sample using azure service bus and worker roles, but you can use the same idea on premises:
http://www.asp.net/aspnet/overview/developing-apps-with-windows-azure/building-real-world-cloud-apps-with-windows-azure/queue-centric-work-pattern
If you run Quartz.Net inside IIS then you're going to run into the same issues of IIS terminating the application periodically. When they mention using Quartz.Net what they are saying is that you install Quartz.Net as a windows service. Then your application talks to the Quartz.Net server that is running inside the service and schedules the jobs to run on it. The server/service then runs the jobs for you and you don't have the issues of running inside IIS, because your jobs are running inside the service.
There isn't a Quartz.Net nuget server package that can be installed as a windows service. For that you'll have to download the source and build it yourself or download the binaries from SourceForge. The Quartz.Net nuget package is what you will use to schedule the jobs from your web application to the Quartz.Net server.
Is there a way I can deploy my entire website/webapp to an Azure WebRole without the need of Visual Studio?
Context: We have a test environment where there's an IIS hosted web app where our testers test (of course). The thing is, we want to grab that exact tested web app folder and deploy it "as is" to a WebRole.
Please avoid commenting on our procedure, we have been looking at it and we will eventually change it if we have to, I just need a 'simple' yes(how)/no answer.
IIS Web Deploy can be used to package/migrate/restore IIS applications. It can be enabled while deploying a web role as described in this article and allows to update the web role with the application as deployed in your test environment.
Be aware that only single instance cloud services are supported and that in case of a maintenance operation by the fabric controller, your service will be rolled back to the state created by the initial azure package deployment. (There once was a tool for syncing between multi-instance web deployments but sadly that did not work out too well and is no longer supported. Do not attempt to use or rebuild it.)
Installing and Configuring Web Deploy shows the steps to get web deploy for your local testing IIS while articles on using web deploy like this one show examples for calling the tool.
Another option to evaluate are azure websites and git deployment. This could provide you with a documented and reproducible form of deployment that is not prone to unwanted rollbacks while allowing the service to scale to multiple instances. This option might not work out if the application it too tied to the web roles infrastructure or contains code not suitable for the more restricted web sites environment.
A third option to look at is using CSPack as presented in this article. You basically create a service definition and package up the webapp manually without building it in Visual Studio or TFS.
Yes - make sure you have enabled Remote Access on your webrole. Then copy your web app from your local IIS folder to F:\sitesroot\0 (NOTE - may be E:\sitesroot\0 on same web roles).
Yes, you can write a programmatic interface against Web Deploy from your C# code. If you're deploying to Azure Web Sites, you could also use the Windows Azure Management Libraries to spin up new web sites or clouand deploy them.
I currently work with a legacy asp.net web application and one of the requirements going forward is that it be deployable to windows azure.
I would like to know how difficult it will be to manage deployment to both Azure and a traditional IIS web server.
Azure seems to require a specific customized version of a web applicaiton project is it possible to deploy the customized web application to a standard IIS instance once it has been converted.
EDIT:
It is a ASP.NET Web Application rather than a Web Site (compiles everything into one dll)
UPDATE:
In the end due to the amount of work involved in converting the application to work in Azure and the cost of Azure compared with other cloud solutions it was decided to go with a traditional Cloud hosted virtual server.
And thank you for the really good answers.
Whether or not you can deploy your application to Azure almost as is depends a lot on how your application works. Azure pretty much requires your application be stateless. If it's a plain vanilla web application that stores data in the session or application cache only and saves data to a database only, then you can deploy it to Azure.
If you have stateful services running like background threads (which is bad anyways), or if you save data to the file system (besides temporary caching), then you may have issues. Really, the issues moving to Azure are really the same as moving to any multi-server load balanced solution. One caveat is permanent storage.
If you need to store data in a place other than the database, then you're best off working with Azure's storage solution which has an API and client library for storing binary data, key/value data (they call it tables, but really, it's not tables), and queues. They also do have a transparent blob-as-file-system option for compatibility. If you want to use these in your app that also is used outside of Azure then you need to write an extra layer between your code and the Azure client library that supports both Azure services and standard local service. Azure SDK does include emulators for Azure services, but they're definitely not meant for production use.
As far as the mechanics of Azure-specific projects, that is actually not that difficult. Yes, you need to create an Azure-specific project in your solution that defines the Web Role and what gets deployed, but it will reference your existing Web Application, not the other way around. You can deploy the Azure Web Role to Azure or you can continue to deploy the existing application to IIS normally and concurrently.
Web Site, Web Application, MVC, really doesn't make much of a difference. Actually doesn't have to be .NET either. Can be PHP or Java or whatever you want to put on your VM. It'll all work the same as far as Azure is concerned.
MS likes to push Azure as a Platform-as-a-Service (Paas) solution where they have a ton of services they offer and you run apps on their standard platform, and contrasts that with Amazon AWS which they call Infrastructure-as-a-Service (Iaas) which is "just" a Virtual Machine. However, MS is really just as much a IaaS solution as AWS, perhaps even more so. The only difference between AWS and Azure is AWS allows you to choose what to install on your VM and with Azure you have to use Windows Server 2008 R2 as the basis for your VM (but you can customize the VM image to install custom software on top of windows). With both Azure and AWS, the hosts offer additional PaaS services you can take advantage of for data storage and message routing. AWS also offers tons of extra services like video streaming.
Also note that with Azure (and AWS I think) you can use the services they offer even in a non-hosted application. If you want to use Azure's data storage from a non-Azure application, you can do that, it's just HTTP REST calls to get/put data. The only differences you pay for data in/out between datacenter and your non-datacenter-hosted application which would be free if the app was also inside the datacenter (just the data in/out is free in-datacenter, you still have storage and transaction fees).
A few things:
Samuel Neff's answer mentioned mounting a file system in a blob (a Cloud Drive). Only one instance may lock this cloud drive for writing, so it does not behave like a network file share. You'll need to plan for this.
You'll need to integrate with the Windows Azure diagnostics subsystem, to gain visibility into your app's run state (e.g. performance counters, trace logs, etc.).
If there are 3rd-party apps that your web app depends on, you'll need to install these. These actually get installed as part of the role instance's boot process, either via your OnStart() event handler or as a startup task. The latter allows for admin-level installs (including registry changes, COM component installations, etc.). You'll need to carefully manage these installations, as they impact the boot time of the instance.
For an asp.net app, you'll need to think about session state. In-proc session state won't work, because each instance will have its own state store in memory. The SQL Azure session state provider doesn't have background cleanup agents, so you'll need to build this into your web or worker role instance (see this blog post by the SQL Azure team for the implementation). The best option is to use the AppFabric Cache, a new service that just went into production. This cache-as-a-service provides an custom session state provider for asp.net as well. Note: As of today, the AppFabric Cache service is only accessible via a .NET interface; there's no REST interface for it (all other storage services - tables, blobs, queues - have a REST interface). .NET, Java, and PHP all have storage client libraries. Ruby has one from the open source community.
You'll have to manage scaling out to more than one instance, when the need arises. This is not a built-in service today, but there are 3rd-party services such as ParaLeap's AzureWatch. There's also Microsoft's System Center Operations Manager, which now has Windows Azure monitoring support. You'll also need to handle scale-back situations, where you reduce the number of server instances.
I have some additional details in an answer for a similar StackOverflow question, here.
I have not tried Windows Azure Migration Scanner personally, but if it works as advertised, this would really come in handy.
Im looking at writing a application for a web 2.0 start up site which will essential monitor specific RSS feeds.
Due to the expected up take of such a service I am expecting that taking advantage of cloud computing would be the way to do it, however with my lack of experience I do not know if it is possible to run a Windows service in the cloud.
There will be a web front end to this but it isn't imagined that that will have a heavy load as it will be just for sign up, then users will recevie notifications by SMS/Email
You can run a "service" in the cloud, when using Azure. It's called a "Worker Role" see the Architecture here.
If you're looking at running Windows Azure (which splits into a web role and worker role).
You'll have to sign up for an Azure key (The Bizspark pack includes one I believe) to get started, download the SDK and Azure tools.
It looks like you would only really need the web role for this, in which case it's just a normal ASP.NET / MVC site that you'd write as normal.
Essentially the benefit you'd get here would be being able to ramp up the number of server instances running your application by tweaking the config file.
The other option is the Amazon EC2 Cloud which allows you to instantiate as many instances of Windows2k3 Data Centre edition as you need. I run Windows Services, IIS, Postgresql etc. on such an instance with no issues.
Managed to find this link to publishing WCF services in the cloud. Im new to WCF so not sure if it will offer the solution I require, it probably will but I need to do some more research
Link