Thanks for the compliment! The deployment manager is going in that exact direction.
The first use case if for a rather simple use case: copy new files somewhere, which is good for a first deployment, and simple websites. As we continue to develop it, we'll add more robust deployment options that use best practices. For example those that play with the load balancer upstreams list. Lets use this thread to collect real world deployment patterns and see which ones are common enough to be included in Scalr-tools. Does that sounds good? On Thu, Jul 7, 2011 at 6:46 AM, Tommi Jensen <[email protected]> wrote: > Hi guys. > > First off, thanks for providing these tools, it shows definite > promise. > > The deployment tools in the api in particular might be an excellent > fit for cloud management, but a few questions of architecture comes to > mind: > > Have you any thoughts/plans for scenarios similar to the below stated? > > > "transactional" deployments. > > The ability to deploy as-if a transactional/atomic action on all > application servers (or atleast to some extent) > looking at e.g. rsync as an example, pushing the deployment to a > seperate directory, and then once all is in place, either moving or > symlinking the new repository into place might work. > > This might also work with a relatively simple script, assuming the > deployment tool only exits after each instance has successfully > returned, by piggybacking e.g execute-script after dm-deploy- > application. > > Do you have any other approaches in mind? > > "gentle" deployment. > > Assuming each node doesn't necesarrily have to be updated at the same > time (no apparant race conditions/conflicts between new/old apps) > > Being able to do an "atomic" deployment with delays between each node > deployment, as an example: > > 10 application nodes. n1 through 10 > > Given a ngnix lb environment, > gracefully take out "n1" of the lb pool, > set maintenance mode, > run some predefined pre-deployment scripts (db backup comes to mind) > deploy > run some predefined post-deployment scripts(flush opcode cache, run db > updates and/or similar) > unset maintenance mode > populate cache(could be warranted in order to avoid cold cache hits if > the environment is assumed to be high profile) > re-insert into lb pool > (yes, I realise that some of the above listed might easily conflict > with the other nodes given db updates etc, but pretend those are non- > issues attb please ;)) > > Wait predefined amount of time. repeat above on n2. > > possibly some sort of schedule-deployment ruleset coupled with pre/ > post hooks might allow for all of the above given some creative > scripting? > dm-deploy --dschedule-type=chain_200sdelay > dm-deploy --dschedule-type=transaction_all > > or similar.. > > I'm sorry if this seems garbled, if so let me know and I'll try to > rectify it. > > Best regards, and thanks in advance > /Tommi > > -- > You received this message because you are subscribed to the Google Groups > "scalr-discuss" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/scalr-discuss?hl=en. > > -- You received this message because you are subscribed to the Google Groups "scalr-discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/scalr-discuss?hl=en.
