Hi Everyone,
I want to have my nodes find a virtual ip by searching for a role. In the first instance, it is for application servers looking for the correct database server to use, and which rabbitmq server to use, but I’m sure I’ll have some other usages soon.
Any advice, or should I look at this from another angle?
Thanks,
Alan
On Jan 24, 2012, at 2:43 PM, Alan Harper wrote:
Hi Everyone,
I want to have my nodes find a virtual ip by searching for a role. In the first instance, it is for application servers looking for the correct database server to use, and which rabbitmq server to use, but I'm sure I'll have some other usages soon.
Any advice, or should I look at this from another angle?
Funny, we were just talking about this the other day for Opscode's own network. We currently store this kind of stuff in a per-env data bag item, but somehow using nodes/roles/search is something we would like to be able to do. You can definitely create a "fake" node with a run-list and IP/FQDN filled in manually, but then you have to worry about it showing up in other searches (think knife ssh '*:*' sudo apt-get update or similar) so this isn't without downsides. There is some work being done to formalize the idea of "managed nodes" (nodes that don't correspond to something running chef-client itself, also referred to "external entities" some places), which would lead to more global best-practicies for this kind of thing. For now, though, you can certainly one-off it as long as you make sure all your other searches are carefully written (possibly add a "NOT managed:true" filter in some places). Hope this helps!
--Noah
On 25/01/2012, at 9:53 AM, Noah Kantrowitz wrote:
On Jan 24, 2012, at 2:43 PM, Alan Harper wrote:
Hi Everyone,
I want to have my nodes find a virtual ip by searching for a role. In the first instance, it is for application servers looking for the correct database server to use, and which rabbitmq server to use, but I'm sure I'll have some other usages soon.
Any advice, or should I look at this from another angle?
Funny, we were just talking about this the other day for Opscode's own network. We currently store this kind of stuff in a per-env data bag item, but somehow using nodes/roles/search is something we would like to be able to do. You can definitely create a "fake" node with a run-list and IP/FQDN filled in manually, but then you have to worry about it showing up in other searches (think
knife ssh '*:*' sudo apt-get updateor similar) so this isn't without downsides. There is some work being done to formalize the idea of "managed nodes" (nodes that don't correspond to something running chef-client itself, also referred to "external entities" some places), which would lead to more global best-practicies for this kind of thing. For now, though, you can certainly one-off it as long as you make sure all your other searches are carefully written (possibly add a "NOT managed:true" filter in some places). Hope this helps!--Noah
Didn't realise fake nodes were possible. Given its a complete new environment getting rolled out, I'll certainly give this approach a try. Thanks!
On Jan 24, 2012, at 3:00 PM, Alan Harper wrote:
On 25/01/2012, at 9:53 AM, Noah Kantrowitz wrote:
On Jan 24, 2012, at 2:43 PM, Alan Harper wrote:
Hi Everyone,
I want to have my nodes find a virtual ip by searching for a role. In the first instance, it is for application servers looking for the correct database server to use, and which rabbitmq server to use, but I'm sure I'll have some other usages soon.
Any advice, or should I look at this from another angle?
Funny, we were just talking about this the other day for Opscode's own network. We currently store this kind of stuff in a per-env data bag item, but somehow using nodes/roles/search is something we would like to be able to do. You can definitely create a "fake" node with a run-list and IP/FQDN filled in manually, but then you have to worry about it showing up in other searches (think
knife ssh '*:*' sudo apt-get updateor similar) so this isn't without downsides. There is some work being done to formalize the idea of "managed nodes" (nodes that don't correspond to something running chef-client itself, also referred to "external entities" some places), which would lead to more global best-practicies for this kind of thing. For now, though, you can certainly one-off it as long as you make sure all your other searches are carefully written (possibly add a "NOT managed:true" filter in some places). Hope this helps!--Noah
Didn't realise fake nodes were possible. Given its a complete new environment getting rolled out, I'll certainly give this approach a try. Thanks!
You could either make them by hand in the web interface, use something like Spice or PyChef from a standalone script, or go full awesome and work out some way for the virtual pair to register itself. That last one might not actually be possible without some external tools right now, and the ACL system would get in the way so maybe not worth going quite that far until there is support in Chef itself for this kind of node. Making a little web service with sinatra+spice or flask+pychef to update the fake nodes seems like the best option, and then have your cookbooks call that API via the HTTP request resource.
--Noah