I think we scared him off.
2009/3/3 Peter Booth <pbo...@nocoincidences.com>
> Gerhardus,
>
> On Mar 2, 2009, at 11:46 AM, Gerhardus Geldenhuis wrote:
>
>
> Hi Peter,
> I already use the multistage gem which works very well for us.
>
>
> multistage is excellent at providing a structure for stage-specific
> configuration.
>
>
> I am reluctant to add any bits of config file in my capistrano tasks.
> I prefer to keep "implementation" and "content" seperate (read: The
>
> art of unix programming). That allows me to version my config files
> using an external versioning tool and keep all configs together.
>
>
> I'm not clear how separating or lumping "implementation" and "content"
> influence whether or not you can use an external versioning tool and keep
> all configs together.
>
> In the past I have used ERB to generate Apache and Tomcat config files. In
> that case the template began as a vanilla nginx config, was modified
> iteratively as I tuned the config, and the plugged in values only represent
> "what runs where." If I understand you correctly, this would meet your
> criteria about separating "implementation" and "content."
>
> There are some situations when configuration generation requires logic that
> doesn't neatly fit the template approach (e.g. "Use SSL for application X,
> unless we're sharing a host, and ensure that the environments that use a
> hardware load-balancer use the website name and not the hostname for the
> name based virtual server ...")
>
> The strength of Capistrano over Ant is that it's an internal DSL
> implemented in a scripting language. By using XML, Ant is much less powerful
> and much more painful to use. In this case, thinking of configuration as
> live logic rather than simply data simplifies things.
>
> The monit example is not one of these situations. Rather there is no
> intellectual capital in the static content. The method you saw was part of a
> module that creates simple config files. Now in that example all the
> generated config files were stored in subversion, in a tree that is rooted
> by host.
>
>
> If I could download a file to the deploy platform, build the config
> file and then send this out to nodes that would be preferable to doing
>
>
> that's what I do - what's stopping you from doing this?
>
> a local svn checkout on each node and building the config file
> seperately on each server. I prefer build once deploy many to deploy
> many, build many.
>
>
> Agreed.
>
> The fact that we're disagreeing here suggests that either I dont understand
> your question, that its more complex than I imagine, or that there is some
> existing Capistrano functionality that you're not aware of.
>
> Stepping back, one open question is, do you centralize the "*What runs
> where?"* knowledge in a single place? One could use a YAML file, and
> generate the stage specific files needed for multi-stage, at the same time
> as generating web server configs and the like. I think its inelegant and a
> pain in the ass to have to open multiple files to configure this stuff.
>
> Peter
>
>
>
>
> Regards
>
> On Mar 2, 4:06 pm, Peter Booth <pbo...@nocoincidences.com> wrote:
>
> What you describe sounds kind of painful. I'm assuming that you are
>
> already using Capistrano for something.
>
>
> I had to solve a similar problem so as to allow multiple
>
> "stages" (dev, qa, uat, prod, ...) to run
>
> on a single host without port or directory clashes. It was amazingly
>
> easy with capistrano and
>
> the capistrano-ext gem, which allows you to create stage-specific
>
> config files.
>
>
> I would create the file dynamically as part of the deploy with code
>
> that looks like that below.
>
>
> Peter
>
>
> def build_monit_config( application, application_id, stage, stage_id,
>
> instance)
>
>
> monit_config = "########## Monit Configuration File\n\n"
>
> monit_config << "\n# stage: #{stage}\n# stage ID: #{stage_id}
>
> \n# instance: #{instance}\n\n# Produced automatically at:
>
> #{Time.now}\n"
>
> first_port = fetch(:start_port)
>
> top_port = first_port + fetch(:num_proc) - 1
>
> first_port.upto(top_port) { |i|
>
> @path =
> "/var/www/domains/signalpatterns.com/#{application}/<http://signalpatterns.com/#%7Bapplication%7D/>
>
> #...@stage}/#...@instance}"
>
> @log_dir = "#...@path}/htdocs/current/log"
>
> @config_dir = "#...@path}/htdocs/shared/config"
>
> @pid_dir = "#...@path}/htdocs/shared/pids"
>
> cfg = <<-CMD
>
> check process #{application}-#{i} with pidfile #...@pid_dir}/
>
> #{application}-mongrel.#{i}.pid
>
> start program = "/usr/bin/mongrel_rails cluster::start -C
>
> #...@config_dir}/mongrel_cluster.yml -v --clean --only #{i}"
>
> stop program = "/usr/bin/mongrel_rails cluster::stop -C
>
> #...@config_dir}/mongrel_cluster.yml -v --force --only #{i}"
>
> if failed urlhttp://localhost:#{i}/monit
>
> with timeout 10 seconds
>
> then restart
>
> if failed urlhttp://localhost:#{i}/monit
>
> with timeout 10 seconds for 2 cycles
>
> then
>
> exec "/bin/bash -c 'kill -9 `cat #...@pid_dir}/
>
> #{application}-mongrel.#{i}.pid`'"
>
> group #...@id}
>
> ##########
>
> CMD
>
> monit_config << cfg
>
> }
>
> monit_config
>
> end
>
>
> On Mar 2, 2009, at 9:50 AM, Gerhardus Geldenhuis wrote:
>
>
>
>
> Hi
>
> I want to create custom config files and would appreciate any tips if
>
> anyone has attempted the same thing.
>
>
> I am planning to do it in the following way:
>
> Download the config files using run command with svn
>
> insert and append the config files using the run command with sed and
>
> awk based on the servers in my roles.
>
>
> Typically what I am going to do is setup our modjk loadbalancer
>
> according the the list of tomcat application servers.
>
>
> We also loadbalance accross our apaches that run modjk and I intend
>
> using capistrano to build/customize there config files too.
>
>
> What I am trying to achieve is that after having build the servers the
>
> only other step I need to do is write a capistrano config and then run
>
> 1 or 2 cap commands to deploy new configs and applications to my
>
> environment.
>
>
> Eventually I can reverse the steps; write the config file first which
>
> then takes care of building the virtual servers and configuring them.
>
>
> Regards
>
>
>
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
To unsubscribe from this group, send email to
capistrano-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/capistrano
-~----------~----~----~----~------~----~------~--~---
