|
@ Florian Hehlen, I want to define run-level by clients attribute. For example, run-level 0 means just run the system base, run-level 1 means just install application and 2 means
both. It can meet the requirement, but I need to change every cookbook to judge the run-level. @Ranjib. My concerns on “why you don’t want to run the complete run list”.
1.
The cookbook for application deployment is not well written, it bring downtime even deploy the package already deployed. So I don’t want to rerun
it when I just add a system account which is in cookbooks belong to base.
2.
More fast just run what you want. From: Florian Hehlen [mailto:
@Mingfei: I have problems similar to yours. There seems to be a gap when it comes to fine-grained application life-cycle management. I am not sure if it
is a feature/weakness in the Chariot design, or something that just has not yet been explored in depth by the community. @Ranjib: You ask ‘why you don’t want to run the complete run list’. I can think of various reasons: -
Running sub-sets of recipes when managing a test or user-acceptance environment. -
Doing emergency or unplanned maintenance/upgrades in a urgent but controlled way where the goal is to do the least amount of change. -
Off-cycle procedures which one might only want to run as planned event. For example: cleaning temp data or caches, or inflight upgrade of part of a system. In the past I have read people saying that the above procedures are not what Chef is for and that I should introduce a further layer of technology
such as Fabric, Rundeck, Opscode’s Push Jobs. I have issues with this idea. First of all it adds one more level of indirection, configuration, technology, language/DSL, which I can’t justify. Secondly, Chef provides a very solid/safe change/configuration management
architecture, which I feel should be leveraged as much as possible. An alternative might be to make a recipe smart enough to do certain things only when certain settings/attributes/flags are set. I think this is
possible in some cases but not others. I think it’s rather inefficient/risky to have to re-release a cookbook (plus dependencies) just to handle a one-off case for example. I tend to build some cookbooks to have recipes that represent basic execution blocks which I then can assemble into different sequences. One of
these sequences will be the default one. The others will correspond to occasional use-cases. And finally the individual blocks can be used in an ad-hoc way if absolutely necessary. I would love to hear about some experiences people have made with managing non-trivial medium sized applications with Chef.
Florian Hi Danjib, If I use “-o” in chef-client, Not only the run list, but also the attribute “roles” in chef server be overwritten.
The integration which depend on attribute “roles” may broken. Regards, Mingfei From: Ranjib Dey [
">mailto:
]
if you invoke chef-client with -o , the override option, it should not save the node data back (iirc). you have to check no recipes or other code does not use node.save explicitly , im curious why you dont want to run the complete run list (all the roles+ extra recipes), is performance (time) a concern ? regards ranjib
On Sat, Jun 28, 2014 at 11:20 PM, Mingfei Hua <
" target="_blank">
> wrote: Hello, we have several roles defined for different type of servers, like DB, web, rabbitmq, redis. and the integration is depend on roles, such as how the WEB server find the DB servers. in each role,
there are cookbooks or sub roles in 3 layers, there are cookbooks for system, cookbooks for install tomcat/database, cookbooks to install war packages. But in some case, I just need to run the cookbooks for system or just need to deploy the war package, the
easiest way is to change the run-list, but it changes the roles attribute in chef server which integration depend on. Any tips on my issue. A typical role definition: { "name": "hmweb", "chef_type": "role", "json_class": "Chef::Role", "description": "for web application deployment, include hm-webapp", "override_attributes": { "aerohive_webapp": { "wars_array": { "hm-webapp.war": { "name": "hm-webapp", }, "sysmgr-regional-webapp.war": { "name": "sysmgr-regional-webapp", } }, "service_log_enabled": "true" } }, "run_list": [ "role[_base]", "role[_webappbase]", "recipe[aerohive-webapp::deploy]" ] } Sincerely, Mingfei Hua LEGAL DISCLAIMER |
Archive powered by MHonArc 2.6.16.