SSH offers a very convenient way to execute shell scripts remotely. Code like
ssh myserver.acme.com
<< EOC
cd $APP_HOME
./start_my_stuff.sh
EOC
are fairly easy to write and read.
But while remote execution itself is easy, writing actual distributed code is total mess.
I’m a Java
guy. I wish, I could run Java code remotely as easy as I can do it with shell.
And now, finally, I can.
And that snippet will work for you too, only two requirements are:
That is it, there is no need to install anything special to target servers.
You can find more details in tutorial at GridKit site.
How it work?
A lot of black magic is happening behind the scene. In particular:
By despite
all that internal complexity, it just works. I’m using it to run agents on
Linux and Solaris. I was using that stuff on Amazon EC2 and I cloud have master
process running on my Windows desktop while slave scattered across Unixes.
It was long road. A lot of issues such as firewalls, bugs in JSch (java SSH client),
subtle SSH limitation, etc has been solved along that path.
But now, I believe, it will “just work” for you too.
Java vs shell
But what is the need for such library in a first place? Below are just few of my reasons:
Remotting is just a remotting
Ability to effortlessly run remote java code is not much by itself. But it enables you to reach new levels of day-to-day automation (which was prohibitively expensive before).
But that would be topic for another post.
Very cool and necessary indeed! Prompted network classloading by GridGain that allowed to run any java code on any node with no preliminary deploy. There are also lots of other tools in the project, will add to bookmarks, thanks Alexey :)
ReplyDeleteUseful when working in "manager and remote agents" paradigm.
ReplyDelete