I have a static web app to which I have mapped the domains [domain].se and www.[domain].se. The domain is managed in Azure.
The problem I'm facing is redirecting all calls to [domain].se to www.[domain].se
Since I couldn't come up with any solution to redirecting http traffic from [domain].se to www.[domain].se using a static web app (other than setting up an additional standard web app on [domain].se that manages redirects), I enabled the "Enterprise-grade edge" feature (which by the way is a very silly name) to be able to use FrontDoor.
When attempting to add the domain to the frontdoor resource, there is an error message telling me that it's already mapped to something (which is correct - the site that I want frontdoor to manage).
When trying to remap [domain].se (and www.[domain].se) to the front door endpoint (select Azure resource in the DNS zone manager), the frontdoor resource is not available.
The issue could probably be resolved by simply removing the current records from the name server and then add a cname record to point it to the frontdoor endpoint.
Two reasons not to do that:
1: It would cause downtime.
2: It feels like a hack. Stuff genereally work better when they are used the way they were expected to when developed. I want the platform to recognize what things are connected in order to avoid future issues.
Related
I have a domain name at web.com, hosting with another site, and want to setup emails through Google Suite. My memory from previous experience tells me that I should be able to set mxrecords directly inside the domain, but web.com is telling me:
Your domain name is not pointing towards Web.com's name servers, this
means if you want to make any changes, you will need to access the
zonefile at the place where you are pointing them, as control is
there.
The hosting is taking place on another site. So I read the above and think this means I need to contact the guy who handles my hosting to add the records. So I do, and I get this response:
You have to do it through web.com to change dns and add new records.
It is done through domain not hosting
Is someone wrong? Or am I misunderstanding how this process works?
The server holds logic, iOS/Android App holds UI. Common case.
How do I suppose to deploy new features in this case with continuous deployment methodology?
I assume that server-side deploy looks like that:
I'm triggering new feature deployment, load balancer starts redirecting 1% of all users to the server instance with the new feature. If everything goes smoothly, then load balancer starts redirecting 10%, 30%, etc up to 100%.
The same can be done for client apps, using, say, Codepush.
So, if I'll deploy server without an app, then there will be no new features usage and therefore no problems with new deployment for sure.
So, probably I have to deploy app first and put some kind of server version checker, so if the server has api for this new feature, the UI for this feature is being shown, and if the app is connected to the wrong server, the new UI is hidden.
That's seems primitive. I need to persist socket connection to the same server to avoid hitting the wrong server, right? And what if instance/zone/region will go down and the user will be suddenly redirected to another sone/region and new server will not have the new feature api? Probably, my assumption is wrong.
So, how do I suppose to deploy new features in this case with continuous deployment methodology?
I would say that your question is more of version compatibility nature of server/client API than CD. We have a similar requirement where a server and the clients communicate and both are constantly enhanced with features. I don't know your production software architecture which might change the needs accordingly but I'll try to come up with some ideas.
I'm going to describe two cases which might apply for you.
First case:
The thing is easier when you do not face the situation that new client versions need to communicate with old server versions. The new server version is deployed first and old clients simply do not use the new feature, as you've already pointed out. In this situation my recommendation is to deploy the server app first and then start to roll out the new client apps. If that's possible I would do that. It applies only when the new feature doesn't force you to break the API.
Second case:
In the case that new client app versions need to talk to an old server app, which I would try to avoid at all costs, the new client needs some switch inside to deactivate feature e.g. B when it's talking to an old server that doesn't support this feature. An API version counter could be the solution. But it requires the client to be able to distinct between server versions. In REST you often see the .../v1/.. inside the URL but could be solved differently as well. Hopefully the API provides some mechanism to get the version the server speaks.
We faced both cases at the same time, the protocol changed over the time including breaking changes, so we needed to implement an API version negotiation mechanism.
I am hosting a service on Windows Azure and using an external DNS (Gandi) to manage zone files. What I would like is to redirect all the incoming Azure traffic to another web page, while I am updating the service (like we'll be back soon).
I know that I can do this by updating the zone file, but it takes time to propagate, then time to put back into normal. So 1 hour update finally takes 6-8 hours.
This is not good. Is there any other way to redirect traffic with IMMEDIATE effect and not wait DNS to propagate? Adding redirection inside the code is not really an option, because Azure service packages take an eternity to upload.
Thanks
Not sure what your full requirement here is, but could VIP swap do the trick for you?
You would deploy the alternate 'well be back' site to the staging slot and when you wish to update the service you'll use VIP swap to make that production whilst you update your service, which is now on staging with the latest build.
When that's ready you can VIP swap back and the new site is now in production?
Edited to add:
I take your point regarding wanting to leave the staging slot for rollbacks, makes perfect sense.
Another option could be to use the Traffic Manager -
Have your main application in one cloud service and your temporary landing page in another.
Configure a traffic manager failover policy with both services (main one first, alternative second).
when you want to go to 'maintenance mode' disable traffic to the main service and all traffic will get routed to the 'maintenance mode' one although there is some lag in propagating it measured in minutes rather than hours when I played with it a little bit just now - there's a DNS time-to-live setting available to you which defaults to 5 minutes.
When you're ready to come-back online re-enable the main site (and you can chose to remove the 'maintenance mode' deployment when all is working
There's a feature in ASP.NET to quickly stop serving content. If you put a file called app_offline.htm in the root of the site, it will serve that instead of regular content. There are details in this blog post.
Using it in Azure may be difficult. I would suggest using VIP Swap, but I see you don't want to do that. You could remote into each VM and manually add the file, though that could be painful. It may be possible to script it, but I don't know an easy way to do so.
I'm creating a iOS app that requires the user to log in at startup, and then uses those credentials to query 4-5 different services on a server over the course of the session.
The server (xyz) it self doesn't accept the credentials, but if the services that it provides are queried then they get accepted. For example https://xyz/service1 works, https://xyz doesn't.
Now what I'm wondering about is if there is anything that stands in the way of creating 4-5 NSURLProtectionSpace's at log in, one for each service on the server, and then use the corresponding protection space when use each service?
Or is there a better way of implementing something that could work in this situation?
All help would be appreciated.
Turns out that there is nothing that stands in the way of creating multiple NSURLProtectionSpace's since each is created for a separate url.
We have an internal web system that handles the majority of our companies business. Hundreds of users use it throughout the day, it's very high priority and must always be running. We're looking at moving to ASP.NET MVC 2; at the moment we use web forms. The beauty of using web forms is we can instantaneously release a single web page as opposed to deploying the entire application.
I'm interested to know how others are deploying their applications whilst still making them accessible to the user. Using the deployment tool in Visual Studio would supposedly cause a halt. I'm looking for a method that's super quick.
If you had high priority bug fixes for example, would it be wise to perhaps mix web forms with MVC and instead replace the view with a code-behind web form until you make the next proper release which isn't a web form?
I've also seen other solutions on the same server of having the same web application run side-by-side and either change the root directory in IIS or change the web.config to point to a different folder, but the problem with this is that you have to do an entire build and deploy even if it were for a simple bug fix.
EDIT: To elaborate, how do you deploy the application without causing any disruption to users.
How is everyone else doing it?
I guess you can run the MVC application uncompiled also? and just replace .cs/views and such on the run.
A websetup uninstall/install is very quick, but it kills the application pool.. which might cause problem. Depending on how your site is built.
The smoothest way is to run it on two servers and store the sessions in sql server or shared state. Then you can just bring S1 down and patch it => bring s1 back up again and bring S2 down => patch S2 and then bring it up again. Al thought this might not work if you make any major changes to the session parts of the code.
Have multiple instances of your website running on multiple servers. The best way to do it is to have a production environment, a test environment, and a developement environment. You can create test cases and run the load every time you have a new build, if can get through all the tests, move the version into production ;).
You could have two physical servers each running IIS and hosting a copy of the site. OR you could run two copies of the site under different IIS endpoints on the SAME server.
Either way you cut it you are going to need at least two copies of the site in production.
I call this an A<->B switch method.
Firstly, have each production site on a different IP address. In your company's DNS, add an entry set to one of the IPs and give it a really short TTL. Then you can update site B and also pre-test/warm-up the site by hitting the IP address. When it's ready to go, get your DNS switched to the new site B. Once your TTL has expired you can take down site A and update it.
Using a shared session state will help to minimise the transition of users between sites.