I'm using site manager to get the iis log's file path in each instance, and upload them to the blob storage.
Here problem comes, in my project, there are two version of the services, the debug one and the online one, and I can only upload the iis log from service instance. To manage the project, I need to check the domain name to judgment the instance is in the online service, so that I can update in both debug and online services using the same code.
By now, here is my code:
SiteManager sm = new SiteManager();
foreach (var site in sm.Sites)
{
string[] logDir = GetIISLogDir(site);
foreach (string filePath in logDir)
{
UploadLogToStorage(filePath);
}
}
I think I need to obtain the domain name from variable site, and decide whether to upload the log.
You need to use the Get Deployment operation for this (REST API).
From within your instance you have access to the current deployment ID (RoleEnvironment.DeploymentId). You can use this id when calling Get Deployment to get information about your current deployment like the deployment slot (prod/staging), the url...
Windows Azure diagnostics support uploading the IIS logs for you automatically. Have you considered using this instead? You can configure that remotely if you are running the diagnostics plugin. If you just configure the DM to use different storage accounts for production vs dev (best practice), you will have no problem figuring out which is which (deployment IDs would be different anyway). There is really no need to write code to upload logs yourself unless you are not using the PaaS model (e.g. IaaS or WAWS).
Related
Per article below web app has an option to either auto or manual scale:
https://azure.microsoft.com/en-us/documentation/articles/insights-how-to-scale/
Would appreciate if I can get clarification on below:
Scenario:
I've ASP.NET Sitecore CMS which uses Lucene behind the scene for search. Lucene index gets rebuilt upon publish of new pages.
Lets say I manually or auto scale to 2 instances:
What exactly happens behind the scene i.e. copies all the website folder to new VM and sets up IIS etc?
Web App has functionality to FTP and view website folders. Is it possible to FTP to both of these instances? From what I know I can only FTP to one of them.
Update:
Problem we are facing:
We use lucene index for our web applications. Looks like the index is built on one web app and not other (website works for some user and not for others). We would like to FTP or RDP and see to make sure this is the case.
Thanks.
The FTP or the GIT provided by the Azure is not on the same instance when you use WebApps, So if you do FTP its not to one of the instances - its somewhere else, but when you change files in the FTP or push to GIT, the triggers kick in and a continuous deployment to the Webapp instance/s is done. You can be very well assured that when you upload new files to your FTP that comes with WebApp the build will be updated on both instances. In fact that's one of the driving forces behind webapps that you don't need to think about a VM.
We used once Lucene on Web Apps with multiple instances. What we did back then was use Azure Blob Storage to keep the index files, no matter the number of instances, all had the same index information.
The only problem was that when new instances would come up (autoscale), they had to load the index on memory and that lead to some cold-starts.
We moved to Azure Search afterwards and never looked back :)
Is there a way to execute some script on Azure Web Role Instances ? I am kind off new to Azure and Azure Management APIs.
Basically what i want to achieve is, depending on the environment type, i would like to switch ON/OFF couple of services in all Azure Web Role Instances. So for e.g. if i have a single web role with 5 instances, then the script should execute in all the 5 instances.
Determine the staging/production environment
Get all the web roles for staging and production environment
For each role get all the instances
Run script in all instances (remotely)
Any help here would be much appreciated.
EDIT: I am able to fetch the staging/production environment details and the web role details for each environment as well. I am using the Service Management Rest APIs and the Get Cloud Service Properties method:
https://management.core.windows.net//services/hostedservices/?embed-detail=true
The above URL returns a list of role instance with their IP address.
But when i am trying to hit the Cloud Service (Web API) it is giving 404 error. Not sure if we can use the IP to hit a web api project hosted on IIS.
Thanks in advance,
Jash
Not exactly sure what you are trying to achieve. But if you have a Cloud Service with Web/Worker roles you cannot directly access each individual instance from the Internet. There is an Azure load balancer that sits in front of your deployment and routes Internet requests to instances. This would be useful for you to read.
What you can do, however, is to implement RoleEntryPoint class exactly like you would do for a Worker Role. Then you could check at regular intervals for a trigger - say a Blob in a container, a record in Table Storage, etc. When this happens - decide what to do: fetch special URL from Localhost, directly execute script with Process.Start(). Your choice, you have full control. All you have to do is to add a new class in your Web project that inherits from RoleEntryPoint.
You can refer to this resources for a bit more information on the use of RoleEntryPoint in WebRole projects:
https://code.msdn.microsoft.com/windowsazure/Combine-WorkerRole-and-f97d0487
http://blog.syntaxc4.net/post/2011/04/13/windows-azure-role-startup-life-cycle.aspx
Posts seem to conflict in their description of how best to get web.config settings into an Azure worker role. Some posts say you need to create WaIISHost.exe.config, set output to always then copy relevant web.config info to that file. Other posts describe creation of app.config instead of WaIISHost.exe. Which is correct?
The answer to this depends a bit on the version of the SDK you are using. First and foremost, the WaIISHost.exe.config is only applicable to Web Roles (not worker roles). Worker Roles use and continue to use app.config for their configuration settings. I am going to assume here that you are trying to configure a Web Role's RoleEntryPoint in config settings.
Now, for Web Roles: If you are using the latest SDK (1.8 at time of writing), you will find that creating a WaIISHost.exe.config file (and copy local, etc.) no longer works. Something has changed in the latest SDK and it will no longer pull those values. For earlier versions of the SDK, this is still how you do it. For the latest version (and likely next versions) 1.8, you can create an app.config. When you do that, it will actually create a file in your bin directory like "WebRoleProjectName.dll.config". You DO NOT have to create this file manually yourself and "Copy Local". Simply create the app.config like you normally would and you will find that your RoleEntryPoint in the Web Role can be configured just fine like that.
In your previous SO post, I suggested that you would need to spend some time to understand both Windows Azure websites and Windows Azure Cloud services as you are mixing together.
Like above you are mixing web and worker role together. WaIISHost.exe is the Windows Azure Web Role Host process which is responsible for loading and running your Web Role DLL. This process has nothing to do with Worker role because it is not even existing in a Windows Azure Worker Role. This process will be only available to Web Roles. And because of that your question above "WaIISHost.exe.config vs. app.config for worker role config" is irrelevant.
App.config configuration is used with both Web Role and Worker Role, however web.config is only used with your web application. So if you want to configure Roles only you can use app.config (both with web and worker role) however for web site configuration you can use web.config.
IF you just write what your final objective is in simple word, you sure will get exact assistance and suggestion on how to do it.
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.
I'm looking into moving an existing app to Azure. It will have an MVC app in one web role and some WCF services in another web role. When live, the site will live at http://www.myapp.com and the services will be at http://api.myapp.com with the MVC app configured to point to the services at http://api.myapp.com.
The problem is when pushing the app to the "stage" configuration on Azure. My understanding is that each push to stage will cause the services to live at a new url (something random like http://4aa5ae2071324585ba5a902f4242a98c.cloudapp.net/). In this case, what is the best way for my MVC app to discover the url of the services?
One option would be to setup a dns entry like http://stage.api.myapp.com and update my DNS CNAME record to point to the new Azure staging url every time I push to stage, but... yuck.
Another option would be to push to stage, get the new urls for the services, RDC to each instance of the MVC role and manually update the configurations. Also yuck.
Is there a simple way to do this? I know I could automate some of the steps above with something like PowerShell, but I'm really hoping there's something baked into the Azure framework that makes this easy. It seems like it would be such a standard scenario.
The only way to dynamically discover what the staging URL will be is to have the instance check its own deploymentID. I am assuming here that the MVC website and the WCF service are in the same deployment. If you check the RoleEnvironment.DeploymentID, you will find that this corresponds exactly to the 'random' URL used in staging (i.e. http://[deploymentID].cloudapp.net).
As long as you are dynamically creating the ChannelFactory on the clientside, it should be able to take its own DeploymentID and find the staging URL.
Of course, this is only useful when deployed in staging. Why don't you simply use the Production slot? That name is stable and you can rely on it or the CNAME (more likely) that you set for it. You can always have multiple hosted services (dev, QA, prod, etc.) and just use the production slot on them.
Don't do what #dunnry is suggesting! Azure has a really good concept of endpoints that solve your problem. And you have access to this info from your RoleEnvironment class.
You can take a look at my blog post on how to get the endpoint from the client. The key part is to create an internal endpoint at which your WCF service is listening. Keep in mind though, you don't necessarily need a new role for this, and personally, I would rather host it in IIS alongide the original Web role & have two of these roles for improved reliability.
This way, it doesn't matter what the deployment is, because the service communication will take place inside that deployment, be it staging or production.