ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <ste...@apache.org>
Subject Re: Check process on remote host - Can Ant do that ?
Date Thu, 14 Feb 2008 10:33:20 GMT
Z W wrote:
> Steve L
> Thanks for your response.
> Sounds like another huge learning curve for me.
> Is there any other way in Ant besides having to learn sf ?
> I'm unsure if I have the time bandwidth to experiment with.


1. If you can use conditions to check for the remote state, then you can 
do stuff too. Here's some of my ant-based deployment tests that probe a 
URL using <waitfor> and then run some <get> operations until my test 
pages are happy



   <target name="wait" depends="deploy-properties">
     <fail unless="application.url" >No application.url defined</fail>
     <property name="deploy.sleep" value="5"/>
     <property name="deploy.waittime" value="20" />
     <sleep seconds="5"/>
     <waitfor maxwait="${deploy.waittime}"
         maxwaitunit="second">
       <http url="${application.url}" />
     </waitfor>
   </target>

   <target name="wait-undeploy" depends="undeploy">
     <property name="undeploy.waittime" value="10"/>
     <waitfor maxwait="${undeploy.waittime}"
         maxwaitunit="second">
       <not>
         <http url="${application.url}"/>
       </not>
     </waitfor>
   </target>

   <target name="get" depends="deploy,wait">
     <get src="${application.url}happy.jsp"
         dest="${build.dir}/happy.html"/>
     <get src="${application.url}feed/"
         dest="${build.dir}/feed.xml"/>
   </target>

   <!--this is our state-->
   <target name="deployed" depends="get"
       description="the application is in a deployed state"/>


   <target name="undeployed" depends="undeploy"/>


As well as <http>, there's a <socket> condition that looks for a port 
being open on a local/remote machine

2. Puppet, by Luke Kanias, is another (ruby-based) configuration 
management tool. Unix only; good a low level system config management, 
but not so good at Java application configuration.

3.  Build and publish your own RPM/deb files.

On linux, you can use the <rpmbuild> task to create new RPM files; you 
can then <scp> up these RPMs, and install them -or push them out to a 
server farm using yum or similar. This lets you manage hundreds of 
machines, machines that must be set up to pull down files from your 
central repository

RPMs can run code at install/uninstall time, so can start and stop 
services. They are very, very hard to get right though, especially 
robust uninstall scripts. I've found it easier to not put any scripts 
there and require the users to shut things down cleanly.


4. Write complex scripts and run them on the remote boxes

for this to work best, I'd encourage you to move away from bash or 
similar, and push out Ant, Perl or Ruby files to the remote boxes, and 
run them there. If you use Ant, there are some Remote Ant tools that you 
can search for; I think ant.apache.org covers them. Its much easier for 
a build file on the remote system to test stuff and act on it, than it 
is for a local build file to try and manage it. If you are deploying to 
app servers, you already have enough of  a JVM installed to host ant...


I'm slowly building up a set of articles on deployment/configuration on 
a wiki:
   http://wiki.smartfrog.org/wiki/display/sf/Patterns+of+Deployment
Have a look if you have some time.

-steve



-- 
Steve Loughran                  http://www.1060.org/blogxter/publish/5
Author: Ant in Action           http://antbook.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org


Mime
View raw message