From: ziuziu <al...@ho...> - 2007-03-06 15:20:09
|
Hi all, I am new on Smartfrog and i would like some advice if possible. I am about to use it as an automated deploy tool for a production enviroment that contains around 8 servers at the moment. Do you think smartfrog easy to use..... reagarding your experience. Does anything to do with opsware. If anyone could give me a point of view it would really help. -- View this message in context: http://www.nabble.com/Smartfrog-habilities-tf3356191.html#a9334125 Sent from the smartfrog-developer mailing list archive at Nabble.com. |
From: Steve L. <ste...@hp...> - 2007-03-07 14:16:31
|
ziuziu wrote: > Hi all, > I am new on Smartfrog and i would like some advice if possible. I am about > to use it as an automated deploy tool for a production enviroment that > contains around 8 servers at the moment. > Do you think smartfrog easy to use..... reagarding your experience. Does > anything to do with opsware. > If anyone could give me a point of view it would really help. > Hello ziuziu I think you need to open the question up the smartfrog-support mailing list; to get the opinions of people other than the developers -we are clearly biased :) Here are some of my opinions on the topic -If you've ever used Ant, using SmartFrog for your deployment isnt that hard a conceptual leap. Just as you configure and run tasks for building things, now you configure and deploy components. Some big differences are (1) the components stay deployed until terminated, when they are meant to clean up, and (2) you can spread components across multiple machines. -setting up an 8 server cluster can be easy or hard, depending on whether the machines are identical, or whether you have a more complex setup of, say, two DB, four app servers, two load balanced front ends and some router in front of it all: the more complex your system, the harder it is to describe the configuration. Eight identical machines? Get the deployment descriptor right for one, then deploy it on eight boxes. -It has built in components to run native and java programs, and manipulate the file system, which, together, can be used for a lot of deployments. There is extra support for application servers (especially jetty, tomcat and JBoss), and in the next release, databases. -If you can use the built in components, then building up a deployment by gluing them together, possibly in complex workflows, means you can deploy without writing any Java code. If you have to resort to java coding, you have more work, but you may have a reusable deployment component, which is yours to keep, or to share if that is your wish (i.e. its your code; SmartFrog being LGPL doesnt mean your components need to be open) -It's not XML. This is good and bad. Good, because the docs are more readable, there's no need to understand XML namespaces, full XPath syntax or, worst of all, XSD and WSDL. Bad, because you have a new syntax to learn. I'm always forgetting semicolons at the end of lines -but then I do the same in Java. -It doesn't have a workflow GUI, one of those drag-and-drop tools that look nice but dont scale. We have a standalone GUI tool, and an eclipse plugin, and hopefully, soon, one for NetBeans. all of these are text based, but make editing the text easier. I havent used opsware; I have no opinions on it. There are a couple of things in Ruby that are possibly similar; Capistrano and Puppet. Puppet is good for configuring a system; I don't know if it can applications in the detail SmartFrog can with Java code Capistrano can deploy Ruby applications, though its workflow is somewhat hard coded to deploying Rails applications and it uses Linux everywhere. Its very much like a make-for-deployment, with some notion of transactions, but is still very procedural. You run a sequence of operations to cold deploy an application, or migrate a database, instead of deploying a set of components whose goal is to keep the system in the declared state. I would certainly encourage you to start using SmartFrog, starting off with the problem of configuring one of the machines, a test machine, or a single part of the system (the database, the application server), and as you get one host working, ask for advice on the mailing list on how to do fault-tolerant multi-machine deployments. We have components to do Service Location Protocol and Anubis (a distributed 'management' tuple-space system) that can be used to let nodes discover each other and interact without the need to hard code machine names across the different descriptors. -Steve |