We have deployed our Sitecore CMS on to Azure Web Apps and having some indexing issues or similar. i.e. the updated changes is reflected for some users and not for all.
We have a scale turned on to 2.
I would like to troubleshoot by accessing the instance 1 and 2 directly via URL to make sure both instances have index built 100%.
How do I access each Azure Web Role instances directly via URL?
Thanks.
The first step is to get the list of instance names. There is an Azure API for it, which you can easily invoke using Resource Explorer (https://resources.azure.com/). Use these steps:
In Resource Explorer, find your Web App (in the tree or using search box)
Under the app, click on Instances, which gives you an array of instances. Each instance has a long name like 622e6b27f9077701f23789e5e512844d22a7dfdd29261bc226f65cd000e2d94a
Once you have the instance names, you can add a cookie in your requests to aim at a specific instance by setting the ARRAffinity cookie to that value. e.g.
ARRAffinity=622e6b27f9077701f23789e5e512844d22a7dfdd29261bc226f65cd000e2d94a
You can do it using a tool like curl. Or I like to use the EditThisCookie Chrome extension (link), which lets you set it from the browser.
In fact, you'll find that after hitting the page normally from the browser, you'll already get an ARRAffinity, as it's used for session stickiness. But the Chrome extension lets you change it and aim at other instances.
See also related blog post: http://blog.amitapple.com/post/2014/03/access-specific-instance/
Related
I'm looking to set up a CI/CD flow for the content in the developer portal, so we can make changes in our dev environment and promote them to higher environments. From what I found, this appears to have information on the suggested way to perform this:
https://learn.microsoft.com/en-us/azure/api-management/automate-portal-deployments
which links to this repo:
https://github.com/Azure/api-management-developer-portal
As far as I can tell, the majority of the code in that repository. is for the developer portal itself in case you wanted to self host. I'm not interested in self hosting, I'm only interested in the scripts contained there, as they will allow me to extract and publish the content between environments. Is there a repository with ONLY the code required for the scripts to run (specifically v3)? I'd prefer to avoid manually going through and deleting files that are non-script related if possible, as I don't really know/understand what they all are.
If such a repository existed, it would enable my ideal scenario which would be to fork that repository, run the "capture" script, then check the extracted developer portal content in to the new repository.
Well, so why don't you just copy the scripts.v3 folder and use it? As you noticed you don't need rest files if you are not running self hosted version. So you can just simply copy paste them. Those scripts are nothing more than a client for Azure REST API endpoints written in node.js. And they can run completely independently from the rest of the repository.
If you don't like node.js you can even write your own scripts to deploy developer portal - with languange of your choice.
Developer portal contains Content Types which contain Content Items. One extra thing is media (fonts, images etc.) that are stored in the APIM blob storage. Those two things determinate how Developer Portal looks like.
So all you need to do is:
Grab all content items (using Azure REST API) from one instance and put them to another APIM
Connect to APIM blob storage and grab all media blobs and put them to another APIM blob storage. You can get SAS url to the blob storage using Azure REST API as well.
And if you examine carefully, those scripts are doing exactly the same thing:
capture.js - will take all files from given APIM instance and put it in to your local folder
generate.js - will take files from your local folder and put it to APIM instance of your choice
migrate.js - is just a combination of previous two scripts. It will take files from one instance and put it to another.
cleanup.js - it is the same thing like reset button in developer portal. It brings back the default state.
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 :)
We are experimenting with deploying an MVC app as an Azure web role. Currently the app is being hosted locally on our server. It has a few appSettings in Web.Config that can be changed by the users as part of the "Administration" module of the application.
I know this isn't a good practice for Azure because there will potentially be multiple instances of the application running with multiple Web.Configs, which makes updating them all a nightmare (if not impossible). My understanding is that the ConfigurationSettings specified in the service definition should be used instead of Web.Config so that settings are defined globally in one place that all the instances of the application can access.
My question is is it possible to programmatically update ConfigurationSettings similar to the way we update Web.Config settings, or would it be better for us to move those settings into a database or something else?
Yes, but unfortunately it is definitely not simple to do.
Follow this URL: http://msdn.microsoft.com/en-us/library/windowsazure/ee460809.aspx
It talks about a Svc Management API call that you can make to read/write the Service Configuration. It is a 64-base string which you'll need to decode, find XML flags in it that you want to change and re-encode it back and send it back to the API.
Not pleasant, but doable.
I have a single page html application, that uses a lot of jQuery. The app content (data as xml and media audio/video/image) is (and has to be) provided by blobs on azure account. I don't need any application server.
What is the recommended way to host such single page html application on Windows Azure Environment (Azure is a requirement).
As I do not need any application server, all application files are currently uploaded into single container as Blobs with appropriate content types. It all works very good.
Still, I've seen that Azure has some website hosting capabilities I've been wondering if what I did is appropriate?
Thanks
Windows Azure Web Sites would work well and could be free for the duration. If the constraints of the free offering don't work for you, you can scale out easily.
You could also store your home page in Azure blob storage, but that means users would have to have the full path to it as there's no server configuration to specify a default page. Publicizing your site endpoint via a vanity URL from bit.ly or the like could make that a non-issue though.
Do note though, that by having everything in blob storage, you're incurring a transaction cost for every image, every page, every script access (that's not cached on the browser that is). Depending on the nature of your site and traffic, it could be more cost-effective to leverage something like Windows Azure Web Site for some of this.
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