The issue is I cant find any documentation on changing a managed(Autoscaling) group into an un-managed instance group with 0 servers group. I've looked at pythons google.cloud and googleapiclient without any luck. They both show ways of managing each individually but not changing it. service.instanceGroupManagers().resize also no go.
Also https://cloud.google.com/sdk/gcloud/reference/compute/instance-groups/
also treats them individually.
I know they support this but I can't figure out how to do this without the gui.
Maybe someone has a better way of doing this. The idea is having a load balancer with a maintenance splash page in it with a RPS of 0 so it get no traffic. When we want the sites to go down for an update we drain all the active connection with the built drain feature when a server is being deleted. We do this by setting the instance group to autoscale no (Unmanaged) and 0 servers.
If you’re using a managed instance group, & all of the images are the same, the below options are available & much simpler.
It does not seem possible to change from a managed instance group to unmanaged in any way, so, I cannot provide steps to doing this through automation.
Best to use a rolling update or canary deployments. You can also use opportunistic or proactive update. These methods & how to use them (gcloud commands & API examples included) are documented here.
Rolling Update: Replace x instances at a time, i.e. imagine 3 instances, the first instance will go down & be updated, once it is finished the second will go down to be update, once finished lastly, the third will be updated. If there are 50 instances you can specify 10 at a time be updated, etc.
Canary Update: Imagine you want to test your new application. Only x/y (i.e. 1 of 3) instances will be updated. So some users will use the new application while some use the old. This allows you to test the new application in production without affecting all instances. If the new version is running smoothly you can roll forward the update (rolling update) or you can roll back the update by removing the few instance(s) running the new version.
Proactive update: Instances are simply recreated with the new version.
Opportunistic: If proactive updates are too disruptive, opportunistic updates will wait for the autoscaler or some other event that would restart or recreate the instance anyway to then also create the instance with the new template.
Hope this helps.
Related
I am wondering what would be the best practice for deploying updates to a (MVC) Go web application. Imagine the following scenario :
1) Code and test some changes for my Go Web Application
2) Deploy update without anyone currently using the previous version getting interrupted.
I don't know how to make sure point 2) can be covered - when somebody is sending a request to the server and I rebuild/restart it just in this moment, he gets an error - even if the request just uses a part of the code I did not touch or that is backwards-compatible, or if I just added a new Request-handler.
Maybe I'm missing something trivial or a well-known pattern as I am just in the process of learning go and my previous web applications were ASP.NET- or php-applications where this was no issue as I did not need to restart the webserver on code changes.
It's not just an issue with Go, but in general we can divide the problem into two separate ones:
Making sure current requests do not get terminated and affect user experience.
Making sure there is no down-time in which new requests cannot be handled.
The first one is easier to tackle: You just don't violently kill your server, but tell it to exit, causing a "Drain phase", in which it does not accept new requests and only finishes the currently running requests, and exits. This can be done by listening on signals for example, and entering the app into a special state.
It's not trivial with Go as the default http server doesn't support shutting it down, but you can start a server with a net.Listener, and then keep a reference to it an close it when the time is due.
Now, doing only approach one and then starting the service again will cause new requests not to be accepted while this is going on, and we all know this can take a number of seconds in extreme cases.
So what we need is another instance of the server already running with the new code, the instant the old one is not responding to new requests, right? That can be done in several ways:
Having more than one server, and a load-balancer on top of them, allowing one (or more) server to take the load while we restart another. That's the simplest way, and the way most people do it. If you need N servers to take the load of your users, just keep N+1 and restart one at a time.
Using socket sharing tricks. In Newer Linux kernels, Many processes can listen and accept on the same port. What you do is simply start the new instance and then tell the old one to finish and exit. This way there is no pause. This is done by setting SO_REUSEPORT on the listening socket.
The above can be automated with ready to ship solutions, like Einhorn, that deals with all the details for you, see https://github.com/stripe/einhorn
Another approach is documented in this blog post: http://blog.nella.org/?p=879
Our requirement from our next web app is that we will be able to deploy a new version of the web app without a downtime.
how is it possible to achieve such task?
does it mean we need to run 2 different servers (tomcats) ? and redirect users to each one when needed?
are there tools that are doing this specific task? in what category these tools in?
Thanks
Just use Tomcat's parallel deployment feature. It is available from Tomcat 7 onwards.
Don't forget, 100% availability is impossible - it may happen for a certain period, but no one can guarantee it, no matter what setup you have.
But since you're looking for a smooth change from one version to another, then the best you can do is update one node and switch nodes then. Of course, since you likely have sessions which shouldn't disconnected, you'll need to make sure that an instance (e.g. load balancer) directs all new requests to the new node, whereas old session requests stay on the old node until no one uses it anymore, after which you can upgrade the second node and finally, balance load again to both nodes.
I have run into a situation where I need to open a newly created quote at the end of a workflow. I have a feeling this is going to require me to create a a very simple custom workflow that uses "window.open", but I would like to avoid this if anyone has a better idea.
So I need to open a newly created quote as soon as it is created in a workflow. Anyone have any good ideas on how to do this?
Workflows are asynchronous; they run on the server (as opposed to the client) and do not run in realtime. eg a workflow that is triggered by creation of a record will run on the server sometime after the record is created (depending on system load etc - it could be a second or two, or could be half an hour later. If you have stopped the CRM Async service on the server, they might well never run.)
Because they run on the server the user has no interaction with them. As a result you can't open a window, as there's no user involved to open a window for...
What you probably want to do is make use of Dialogs (introduced in CRM 2011). You won't be able to use window.open() but as long as you've got a recent update rollup installed on the server you can present the user with a hyperlink to most CRM records.
Setup of Dialogs is much the same as Workflows, and they use the same mechanics under the hood. The difference is that they're syncronous (i.e. run in real-time) and they are client-side. There's some detail on Technet: http://technet.microsoft.com/en-us/library/gg334463.aspx
I observe the following weird behavior. I have an Azure web role which is deployed on love Azure cloud. Now I click "Configure" in the Azure Management Portal and change the number of instances - the portal shows some "activity". Now I open the browser and navigate to the URL assigned to my deployment and start refreshing the page something like once per two seconds. The page reloads fine many times and then fro some time it will stop reloading - the request will be rejected, then after something like half a minute the requests are handled normally.
What is happening? Is the web server temporarily stopped? How do I change number of instances so that HTTP requests to the role are handled at all times?
When you change the configuration file, your current instance might be restarted. This might be the reason you met with, which your website didn't response in about 30 seconds.
Please have a look http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.roleenvironment.changing.aspx and check if it 's because of the role restarting.
What you are doing is manual. Have you looked at the SDK for autoscaling Azure?
http://channel9.msdn.com/posts/Autoscaling-Windows-Azure-applications
Check out the demo at the 18 minute mark. It doesn't answer your question directly, but its a much more configurable/dynamic way of scaling Azure.
Azure updates your roles one update domain at a time, so in theory you should see no downtime when updating the config (provided you have at least two instances). However, if you refresh the browser every couple of seconds, it's possible that your requests go always to the same instance due to keep-alive.
It would be interesting to know what the behavior is if you disable keep-alives for your webrole. Note that this will have a performance impact, so you'll probably want to re-enable keep-alives after the exercise.
I'm using System.Runtime.Caching.MemoryCache to simulate a repeated task on a running .NET MVC application deployed on AppHarbor.
Entries in the cache are added using a CacheItemPolicy which contains an AbsoluteExpiration offset and a RemovedCallback that calls a method and retriggers the adding of the item in the cache (as described here)
MemoryCache is populated first time in Application_Start. It works fine locally, but doesn't seem to work once deployed on AppHarbor (tried also with HttpRuntime.Cache, same result).
My application is running under a CANOE (free) account on AppHarbor that only has one worker. Does this mean that I won't be able to simulate the background task until I upgrade to some paid plan?
Thanks!
Your application has to have visitors every once in a while for this to work. Other than StillAlive, Pingdom is also a good bet for generating requests to your app. You should also take a look at MomentApp. We expect to have background tasks ready shortly.
I don't think upgrading will help, they are working on adding background jobs to AppHarbor but to my knowledge they available yet.
What about using a service like https://stillalive.com/ to periodically hit a page on your site that then spins up a new thread and starts running your background task? Its available as a free add-on.
I was thinking of doing something like this while waiting for the background task functionality to be available.