Somebody suggested SmallCap and that sounds great. This is by no stretch
of the imagination Capistrano, so it might better be named MicroCap but
it may be useful to some who have (as I do) modest needs in this regard,
especially for on-server versioning.
Here''s a preview of the usage:
Usage: ruby smallcap.rb [options]
-s, --server=SERVER Copies app to specified server.
Default: yourserver.com
-u, --user=USER User id for server.
Default: youruserid
-d, --deploy-path=FULLPATHNAME Specifies the full path on server
for deployment.
Default:
/full/path/to/deployment/directory
-e, --edge_rails If present, copies edge or gem
rails to server.
-p, --plugins If present, copies plugins
directory to server.
-c, --components If present, copies components
directory to server.
-i, --script If present, copies script directory
to server. USE WITH CAUTION
-g, --config If present, copies config directory
to server. USE WITH CAUTION
-t, --temp-dir=TMP_DIR If present, sets the temp directory
for caching the files prior to
prop. Note that the root
directories must exist.
Default: System temp directory
-f=CONFIG_FILE Specifies the optional
configuration file for deployment.
--configuration-file Default: deploy.yml
-h, --help Show this help message.
SmallCap defaults to loading a deploy.yml file that specifies your
server config, so you don''t have to type all this junk each time.
Additionally, you can have deploy_dev.yml and deploy_test.yml and select
using -f. Finally, SmallCap loads recipe files in the ./recipes
directory. I''m still working on the semantics of this, but
it''s where
you will do the pre-deployment stuff.
I''m not ready to put this out ITW yet because it''s not ready
for prime
time, but...comments on what you see? Useful? Not?
--
Posted via http://www.ruby-forum.com/.
I like the idea of a simpler deployment solution. Currently we only have one box per application, so I never use the multiple server support offered by Capistrano. However, Capistrano is certainly better than the wsadmin script used to deploy WebSphere apps at my day job :) I see no mention of migrations and server/FCGI process restarts. If you have a plan for those, I''d be happy to give it a whirl. On Tuesday, March 07, 2006, at 11:22 PM, Steve Ross wrote:>Somebody suggested SmallCap and that sounds great. This is by no stretch >of the imagination Capistrano, so it might better be named MicroCap but >it may be useful to some who have (as I do) modest needs in this regard, >especially for on-server versioning. > >Here''s a preview of the usage: > >Usage: ruby smallcap.rb [options] > > -s, --server=SERVER Copies app to specified server. > Default: yourserver.com > -u, --user=USER User id for server. > Default: youruserid > -d, --deploy-path=FULLPATHNAME Specifies the full path on server >for deployment. > Default: >/full/path/to/deployment/directory > -e, --edge_rails If present, copies edge or gem >rails to server. > -p, --plugins If present, copies plugins >directory to server. > -c, --components If present, copies components >directory to server. > -i, --script If present, copies script directory >to server. USE WITH CAUTION > -g, --config If present, copies config directory >to server. USE WITH CAUTION > -t, --temp-dir=TMP_DIR If present, sets the temp directory >for caching the files prior to > prop. Note that the root >directories must exist. > Default: System temp directory > -f=CONFIG_FILE Specifies the optional >configuration file for deployment. > --configuration-file Default: deploy.yml > > -h, --help Show this help message. > >SmallCap defaults to loading a deploy.yml file that specifies your >server config, so you don''t have to type all this junk each time. >Additionally, you can have deploy_dev.yml and deploy_test.yml and select >using -f. Finally, SmallCap loads recipe files in the ./recipes >directory. I''m still working on the semantics of this, but it''s where >you will do the pre-deployment stuff. > >I''m not ready to put this out ITW yet because it''s not ready for prime >time, but...comments on what you see? Useful? Not? > >-- >Posted via http://www.ruby-forum.com/. >_______________________________________________ >Rails mailing list >Rails@lists.rubyonrails.org >http://lists.rubyonrails.org/mailman/listinfo/railsCheers! --Dave Teare http://devlists.com - Email list management http://palmsphere.com - Apps for your hand-held -- Posted with http://DevLists.com. Sign up and save your time!
You''ve pretty much hit the next work item square on. Here''s my problem. I''m not running spinner, so I have no real idea which lighttpd process is mine unless I ssh onto the server, do a ps aux|grep lighttpd|grep mysitename. If you are using Apache, at least you have apachectl or graceful. Any help in this area would totally rock. One of my biggest frustrations now is that deployment is not one-touch and I have to do the file copying, then kill the server, then restart the server. Doing this all in one slug would be great! I''ll be posting some code RSN :) Further disclaimer in case anyone missed this: I am NOTNOTNOT trying to duplicate Jamis'' great work on Capistrano. I just need less and figured it was straightforward to write. Dave Teare wrote:> I like the idea of a simpler deployment solution. Currently we only > have one box per application, so I never use the multiple server support > offered by Capistrano. However, Capistrano is certainly better than the > wsadmin script used to deploy WebSphere apps at my day job :) > > I see no mention of migrations and server/FCGI process restarts. If you > have a plan for those, I''d be happy to give it a whirl. > > On Tuesday, March 07, 2006, at 11:22 PM, Steve Ross wrote: >> Default: yourserver.com >> -c, --components If present, copies components >> -f=CONFIG_FILE Specifies the optional >>you will do the pre-deployment stuff. >> >>I''m not ready to put this out ITW yet because it''s not ready for prime >>time, but...comments on what you see? Useful? Not? >> >>-- >>Posted via http://www.ruby-forum.com/. >>_______________________________________________ >>Rails mailing list >>Rails@lists.rubyonrails.org >>http://lists.rubyonrails.org/mailman/listinfo/rails > > > Cheers! > --Dave Teare > http://devlists.com - Email list management > http://palmsphere.com - Apps for your hand-held-- Posted via http://www.ruby-forum.com/.
Skipped content of type multipart/alternative-------------- next part
--------------
#!/bin/sh
# Author: Nathaniel Brown
# Date: December 16, 2005
# URL: http://nshb.net/lighttpd-restart-script.html
# Version: 1.1
# License: GNU GPL 2.0
#
# chkconfig: - 85 12
# description: Infocenter2 Clinical Interface
# Modified by Adrian Madrid for HXM
# Binary Paths
CAT="/bin/cat"
PS="/bin/ps"
SLEEP="/bin/sleep"
BASENAME="/bin/basename"
HTTPD="/usr/local/sbin/lighttpd"
# Modifiy this line for each install
DOMAIN="abc.xyz.com"
PATH="/home/xyz/domains/"$DOMAIN"/"
LIGHTTPD_CONF=$PATH"conf/lighttpd.conf"
PIDFILE=$PATH"run/lighttpd.pid"
PID=0
if [ -e $PIDFILE ]; then
PID=`$CAT $PIDFILE`
if [ "x" == "x$PID" ]; then
PID=0
fi
fi
case "$1" in
start)
if [ 0 -ne $PID ]; then
running=`$PS --pid $PID | grep $PID`
if [ $running ]; then
echo "lighttpd for "$DOMAIN" is already running"
exit 1
fi
rm $PIDFILE
PID=0
fi
$HTTPD -f $LIGHTTPD_CONF
;;
stop)
if [ 0 -eq $PID ]; then
echo "lighttpd for "$DOMAIN" was not running"
exit 1
fi
kill $PID
tries=""
while [ -e $PIDFILE ]; do
if [ "x$tries" == "x.........." ]; then
break
fi
$SLEEP 2
tries=".$tries"
done
if [ -e $PIDFILE ]; then
echo "lighttpd for "$DOMAIN" did not stop gently, killing
the process"
kill -9 $PID
rm $PIDFILE
fi
;;
restart)
$0 stop
$0 start
;;
reload)
if [ 0 -eq $PID ]; then
echo "lighttpd for "$DOMAIN" was not running"
fi
kill -HUP $PID
;;
status)
if [ 0 -eq $PID ]; then
echo "lighttpd for "$DOMAIN" is not running"
fi
if [ 0 -ne $PID ]; then
echo "lighttpd for "$DOMAIN" (pid $PID) is running..."
fi
;;
*)
echo "Usage: "`$BASENAME $0`"
(start|stop|restart|reload|status)"
exit 1
;;
esac
I''m not going to do an announcement just yet but you can have a look at the current state of the code by doing an svn co from http://opensvn.csie.org/calico_rails/smallcap. No guarantees about this, but I''ve kicked about five revisions out to a server to figure out whether it is doing what I want, and it seems ok. Dave Teare wrote:> I like the idea of a simpler deployment solution. Currently we only > have one box per application, so I never use the multiple server support > offered by Capistrano. However, Capistrano is certainly better than the > wsadmin script used to deploy WebSphere apps at my day job :) > > I see no mention of migrations and server/FCGI process restarts. If you > have a plan for those, I''d be happy to give it a whirl. > > On Tuesday, March 07, 2006, at 11:22 PM, Steve Ross wrote: >> Default: yourserver.com >> -c, --components If present, copies components >> -f=CONFIG_FILE Specifies the optional >>you will do the pre-deployment stuff. >> >>I''m not ready to put this out ITW yet because it''s not ready for prime >>time, but...comments on what you see? Useful? Not? >> >>-- >>Posted via http://www.ruby-forum.com/. >>_______________________________________________ >>Rails mailing list >>Rails@lists.rubyonrails.org >>http://lists.rubyonrails.org/mailman/listinfo/rails > > > Cheers! > --Dave Teare > http://devlists.com - Email list management > http://palmsphere.com - Apps for your hand-held-- Posted via http://www.ruby-forum.com/.
Dave Teare <devlists-rubyonrails@...> writes:> > I like the idea of a simpler deployment solution. Currently we only > have one box per application, so I never use the multiple server support > offered by Capistrano. However, Capistrano is certainly better than the > wsadmin script used to deploy WebSphere apps at my day job :) > > I see no mention of migrations and server/FCGI process restarts. If you > have a plan for those, I''d be happy to give it a whirl.Could it be possible that we, the Windows addictive/slaves/fans, will finally be able to use (a small part of) Capistrano this way? I don''t know if it is possible and in your sight. Anyway, kudos for the idea. Marius Popescu http://mapopescu.blogsome.com
Interesting you should mention this. I was thinking about it. I''m developing on a Mac which has all kinds of nifty little (and not so little) utilities that aren''t available on Windows. However, the primary deal killers for Windows are: - rsync - ssh - cp I do a number of shell commands because OS-native commands like copying a tree are far more efficient than a pure Ruby solution. It''s easy to replace that though. rsync is more difficult to replace, but you could eliminate it if you were willing to copy the entire tree each time. ssh is essential if you want to talk directly to your server This is still a baby, but with input from various platforms, I don''t see any reason the x-plat stuff couldn''t be worked out. Have a look at the current code: svn co http://opensvn.csie.org/calico_rails/smallcap Marius Popescu wrote:> Dave Teare <devlists-rubyonrails@...> writes: > >> >> I like the idea of a simpler deployment solution. Currently we only >> have one box per application, so I never use the multiple server support >> offered by Capistrano. However, Capistrano is certainly better than the >> wsadmin script used to deploy WebSphere apps at my day job :) >> >> I see no mention of migrations and server/FCGI process restarts. If you >> have a plan for those, I''d be happy to give it a whirl. > > Could it be possible that we, the Windows addictive/slaves/fans, will > finally be > able to use (a small part of) Capistrano this way? I don''t know if it is > possible and in your sight. > > Anyway, kudos for the idea. > > Marius Popescu > http://mapopescu.blogsome.com-- Posted via http://www.ruby-forum.com/.
> utilities that aren''t available on Windows. However, the primary > deal killers for Windows are: > > - rsync > - ssh > - cpif you install MinGW and its associated utilities packages like the MSYS and the DTK, you will get all these GNUtils, and they will run native on windows. but it is a few steps and definitely not installed by default certainly sounds like a good argument for writing your deployment utility in, i dunno..ruby? how does Capistrano sound for a name? :) -- Posted via http://www.ruby-forum.com/.
While it''s nice to see so much support for easier deployment, I fail to see the need for it. Just like setting up a development environment, setting up your deployment tools is a thing you only need to do only once. While Capistrano might be overkill, once configured to your needs there''s no need to look back. And as your projects grow, an utility that once was overkill might now turn out to meet your needs perfectly. -- Posted via http://www.ruby-forum.com/.
It''s probably too late for a name change, but you might want to bear in mind that ''SmallCap'' is a fairly common term featured in investment spam. - james On 3/7/06, Steve Ross <cwdinfo@gmail.com> wrote:> Somebody suggested SmallCap and that sounds great. This is by no stretch > of the imagination Capistrano, so it might better be named MicroCap but > it may be useful to some who have (as I do) modest needs in this regard, > especially for on-server versioning. > > Here''s a preview of the usage: > > Usage: ruby smallcap.rb [options] > > -s, --server=SERVER Copies app to specified server. > Default: yourserver.com > -u, --user=USER User id for server. > Default: youruserid > -d, --deploy-path=FULLPATHNAME Specifies the full path on server > for deployment. > Default: > /full/path/to/deployment/directory > -e, --edge_rails If present, copies edge or gem > rails to server. > -p, --plugins If present, copies plugins > directory to server. > -c, --components If present, copies components > directory to server. > -i, --script If present, copies script directory > to server. USE WITH CAUTION > -g, --config If present, copies config directory > to server. USE WITH CAUTION > -t, --temp-dir=TMP_DIR If present, sets the temp directory > for caching the files prior to > prop. Note that the root > directories must exist. > Default: System temp directory > -f=CONFIG_FILE Specifies the optional > configuration file for deployment. > --configuration-file Default: deploy.yml > > -h, --help Show this help message. > > SmallCap defaults to loading a deploy.yml file that specifies your > server config, so you don''t have to type all this junk each time. > Additionally, you can have deploy_dev.yml and deploy_test.yml and select > using -f. Finally, SmallCap loads recipe files in the ./recipes > directory. I''m still working on the semantics of this, but it''s where > you will do the pre-deployment stuff. > > I''m not ready to put this out ITW yet because it''s not ready for prime > time, but...comments on what you see? Useful? Not? > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- * J * ~
I was ok with "deploy" because it''s easy to type... As you can see from this thread, interest has been low to negative, so I''ve put this on a very low simmer because there doesn''t seem to be a crying need. Steve James Adam wrote:> It''s probably too late for a name change, but you might want to bear > in mind that ''SmallCap'' is a fairly common term featured in investment > spam. > > - james > > On 3/7/06, Steve Ross <cwdinfo@gmail.com> wrote: >> Default: yourserver.com >> -c, --components If present, copies components >> -f=CONFIG_FILE Specifies the optional >> you will do the pre-deployment stuff. >> > -- > * J * > ~-- Posted via http://www.ruby-forum.com/.
Seemingly Similar Threads
- Stockmarket Smallcap Profile
- [UNDER CONSTRUCTION] YAC? (Yet Another Capistrano)
- [Bug 774] banner is displaying twice (/etc/issue)
- AW: AW: final question: how many mountpoints can icecast handle ?
- [Bug 990] OpenSSH cannot connect to an IBM RSA (Remote Supervisor Adaptor) II