Hi Peter, On Mar 3, 5:39 pm, Peter Booth <[email protected]> wrote: > 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.
... what I meant was that I see capistrano as a program. I was taught rightly or wrongly to have as little as possible "constants" in my code/program and keep things were possible elegant but not at the sake of elegance. The config files for me is dynamic even if it never changes and I would like to keep config files and capistrano seperate. In the example you gave you build a config file in your capistrano code. In hindsight that probably does not matter that much really and when I looked at it again I aggreed with how you had done it. > 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. Thanks for that, a friend was asking why not use ANT, which I don't know, and thus provides a good answer. > > 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. > A question... Why do you keep generated config files in svn too? I was thinking of only keeping the stubs in svn and use capistrano to directly deploy generated files(generated by cap using the stubs). I can think of reason to store generated configs in svn but would be interested to hear your opinion on this. > > > 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? Nothing really, except time. I like the idea though and keep it in mind for version 2 of my deployment script. > > > 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. Probably a bit of all of the above :-) I am still very much learning capistrano and adapting to the methodology it uses and am bound to make a few(hopefully only a few) stupid mistakes. I have also never worked in a place that have done versioning of configs and am learning as I go along. Hopefully my documentation (internal docs) will be read and people will actually use it. I have already realized that some things that I have written in capistrano can be done differently and potentially better but at the moment it just needs to work. > > 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. I am not sure I understand the question completely. The company for which I am contracting have many different application environments with a diverse set of components and configurations making up the various environments/platforms. (oracle, mysql, tomcat, jboss, websphere) There is not yet a centralized "what runs where" place with regards to applications yet. There is some migrations/consolidation/ simplification underway and I have tried to drive towards going a more centralised config method and putting all configs in svn. capistrano is a good first step in the right direction. Many thanks for taking the time to reply. I welcome a good argument as it lets the creative juices flow and challenges me to think more critically about what I am trying to achieve and thus doing it better as a result. Best Regards --~--~---------~--~----~------------~-------~--~----~ To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/capistrano -~----------~----~----~----~------~----~------~--~---
