Re: [Fab-user] Moving to Fab ?

[Jeff Forcier]

Hi Nicolas,

Your closing statement does sound relatively accurate -- your tool's
focus seems to be on setting up a "staging area" locally, getting
things ready there, copying the files in one go, and then executing
scripts on the remote end. Fabric, on the other hand, has been more
aimed at writing a Python script "locally" which uses the SSH tunnel
to actually execute the shell level commands on the remote server.
File copying is obviously much the same anywhere.

There's really nothing preventing you from executing your current
workflow using Fabric, however, since it's capable of working locally
as well as remotely.

The main thing Fabric is missing that you seem to rely on is your
"environments" and "tags", which sound similar to an item on our todo
list, namely implementing a way to group servers together (something
Capistrano refers to as 'roles'). We also do not have a baked-in
concept of environments, but it's easy enough right now to implement
them (I believe the current docs explore this somewhat, IIRC).

Regards,
Jeff

On Wed, Nov 5, 2008 at 12:33 PM, Nicolas Steinmetz <address@hidden> wrote:
> Hello,
>
> I'm currently testing Fab in order to evaluate it to see if it can replace a
> home made perl script that my firm use for deployment but that I cannot
> maintain or improve due to my lack of perl skills.
>
> It has following features
> - Handle environnement server (one file per environnement)
> - For a given environnement, I can set "tags", like "front" for front server
> and "db" for db servers. For each tag, I can set one or more servers.
>
> Example for my ezpupdate/etc/prod file :
> tags: front db
> front: www1 www2 www3
> db: sql1
>
> In a given archive for a deployment, I have the following structure :
>
> files/
> files/front
> files/db
> changes/
> changes/front
> changes/db
> commands.upd
>
> -> files is used for files to be sent. Then "front" and "db" are the tags
> that match the tags defined above.
>
> For ex, if I want to update a new httpd.conf, my.cnf, and index.php files, I
> will have :
> files/front/etc/httpd/httpd.conf
> files/front/var/www/project/index.php
> files/db/etc/my.cnf
>
> -> changes are to be considered as a kind of patch. Accoding to some
> pattern, I'm able to add/change/modifiy/withdraw a line in a given file.
> Just think it as sed . Same principe for front/tag tags.
>
> -> commands.upd is a file which gather some commandes to run, once files and
> changes have been applied. It can run local and remote commands and it can
> even run a commande once for a given tag.
>
> For ex, if I want to update the crontab of the first server in the list and
> not all of them :
> remote front once cd /var/www/projet && update_crontab.sh
>
> Process of deployment is the following one :
> I run : myscript -target=<envt> -source=<archive>
>
> then it does the following :
> - create a log file
> - unpack archive in /tmp on my local computer (from which I deploy the
> package on my remote servers)
> - send files on relevant servers according to tag
> - apply changes with some ssh $srv "sed like command"
> - execute remote / local commandes in commands.upd
> - end log file
>
> In parallel, I started trying to implement fab on my own but I'd like to
> have your feedback on my current tool vs fab (0.0.9). My first thought is
> that Fab is based on the opposite principe (or maybe I'm wrong due the
> examples I saw), that is to say  to send archives on the remote server and
> then to execute remote scripts. Whereas in my case, I'm more on the
> principle : I handle locally files, send them to remote computers and
> execute script from deployment server (not sure I'm clear).
>
> Thanks for reading me, I hope I'm clear enough and looking forward reading
> your feedback on this.
>
> Nicolas
>
> _______________________________________________
> Fab-user mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/fab-user
>
>