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 <[email protected]> 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}/ >> #...@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 [email protected] For more options, visit this group at http://groups.google.com/group/capistrano -~----------~----~----~----~------~----~------~--~---
