Hi all. I''m a puppet noob and I''ve been tinkering with it for the past couple of weeks. What I would like to do now is duplicate a web server. So I have a web server running. I would like to make puppet to duplicate this web server on another machine. This includes installing the same packages, have the same directory structure, have the same repository, etc., on the new server. I''m really not sure how to proceed with this. Any starting tips would be greatly appreciated! -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On 10/01/2010 03:07 PM, Kikanny wrote:> Hi all. I''m a puppet noob and I''ve been tinkering with it for the past > couple of weeks. What I would like to do now is duplicate a web > server. So I have a web server running. I would like to make puppet to > duplicate this web server on another machine. This includes installing > the same packages, have the same directory structure, have the same > repository, etc., on the new server. I''m really not sure how to > proceed with this. Any starting tips would be greatly appreciated! >Hi, step one is to build a puppet manifest that "mirrors" you existing server in that puppet will, when run on your server, do nothing. The tricky part is to include everything you really need. There is no automatism that will tell if you have. Once the manifest is complete, run puppet on a fresh machine so that puppet will take care to set everything up. This fresh server is your "duplicate" then. Typically, you will not puppet to manage the web contents of your application. There are solutions that are fitted better for such things (source control systems, network file systems etc.) HTH, Felix -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Kikanny <kikanny@gmail.com> writes:> I''m a puppet noob and I''ve been tinkering with it for the past couple of > weeks. What I would like to do now is duplicate a web server. So I have a > web server running....and not built with puppet, right?> I would like to make puppet to duplicate this web server on another > machine. This includes installing the same packages, have the same directory > structure, have the same repository, etc., on the new server. I''m really not > sure how to proceed with this. Any starting tips would be greatly > appreciated!Well, the sad thing is that puppet is going to make this specific job harder than just sitting down and doing it all by hand. Which, I imagine, is not the news you wanted to hear. :) On the plus side: it will make the *next* web server, after this one, really easy. Like, five minutes of work easy. Basically, what you need to do is go through your existing web server and for every single thing that is custom — every package, every path, every repo — and tell puppet how to put it in place. Which means that you get to do all the work you would have to do for creating a new one by hand, only now you also get to tell puppet how to do it and build a bit of stuff around that. There isn''t any much shortcut to getting through this[1], and it usually takes about ten or twenty percent more time than just doing it would once you know puppet. Budget a little more on top of that for learning puppet. What you really get benefits from is that a whole bunch of that work will be the same stuff you want on a file server, or a database server, or whatever. So, building one of those, or reusing it to build another web server after this one, is super-easy and much faster. Daniel Plus, now you can make *both* web servers run the same puppet stuff, so when you fix a problem or make a new website on one you can have the other pick it up exactly the same (or as different) as you want. Footnotes: [1] ...though you might want to investigate the ralsh tool, shipped with puppet, which might make some of the manual work easier. -- ✣ Daniel Pittman ✉ daniel@rimspace.net ☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
the ralsh command may be of use in this situation. ralsh will produce
minimalist puppet code based on the existing configuration. something like this
may at least give you a good starting point, though i wouldn''t
recommend blindly running this code on another system. you will want to verify
and most likely edit the code first.
`ralsh -t` will list all available types
`ralsh $type` will spit out puppet code based on what it sees on the current
system.
so on your existing webserver you could run something like this to see what
puppet can model from the current systems config:
for x in `ralsh -t `; do echo "${x}"; code=$(ralsh "${x}");
if [ $? -eq 0 ]; then echo "${code}"
>/root/"${x}".puppet; fi; echo; done
this isn''t the ideal solution, but within the puppet paradigm it will
work.
HTH and good luck
byron
-----Original Message-----
From: puppet-users@googlegroups.com [mailto:puppet-users@googlegroups.com] On
Behalf Of Kikanny
Sent: Friday, October 01, 2010 9:07 AM
To: Puppet Users
Subject: [Puppet Users] Duplicating web servers
Hi all. I''m a puppet noob and I''ve been tinkering with it for
the past
couple of weeks. What I would like to do now is duplicate a web
server. So I have a web server running. I would like to make puppet to
duplicate this web server on another machine. This includes installing
the same packages, have the same directory structure, have the same
repository, etc., on the new server. I''m really not sure how to
proceed with this. Any starting tips would be greatly appreciated!
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
On Friday 01 Oct 2010 14:27:38 Daniel Pittman wrote:> On the plus side: it will make the *next* web server, after this one, > really easy. Like, five minutes of work easy.I have to agree with this. It''s taken me the better part of two months (on and off) to get a mailserver manifest to mirror the manual (source based!) build process that we used to use working correctly. Building from source used to take up to 6 hours. Puppet and Cobbler take 11 minutes from bare metal to working server.> Basically, what you need to do is go through your existing web server and > for every single thing that is custom — every package, every path, every > repo — and tell puppet how to put it in place. > > Which means that you get to do all the work you would have to do for > creating a new one by hand, only now you also get to tell puppet how to do > it and build a bit of stuff around that.Checkout "ralsh" as suggested and try to "normalise" your manifests in the same way you would a database - if it looks like it''s duplicated across various systems, move it into a separate module. Cheers, M. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Thank you all for taking your time to explain it to me. I guess I''ll give it a whirl and see how it goes. Another question I have is what if the person managing a web server does not have full knowledge of whatever is installed in a server or there was some other configuration management in place. How would I bring that under puppet''s control? I''m asking this because we do have servers like that. Thanks! -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Kikanny wrote:> Thank you all for taking your time to explain it to me. I guess I''ll > give it a whirl and see how it goes. Another question I have is what > if the person managing a web server does not have full knowledge of > whatever is installed in a server or there was some other > configuration management in place. How would I bring that under > puppet''s control? I''m asking this because we do have servers like > that. Thanks! >In the lack of full knowledge instance, "ralsh" is definitely your friend. It''s a good tool to get the basics about a host. In the latter instance, I don''t see that it matters if another configuration management system was in place - just remember to turn it off so you don''t get conflicting management of resources! Regards James Turnbull -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Friday 01 Oct 2010 15:01:25 Kikanny wrote:> Thank you all for taking your time to explain it to me. I guess I''ll > give it a whirl and see how it goes. Another question I have is what > if the person managing a web server does not have full knowledge of > whatever is installed in a server or there was some other > configuration management in place. How would I bring that under > puppet''s control? I''m asking this because we do have servers like > that. Thanks!1) Get a list of running services/open ports 2) Get all the relevant configuration files for those services/ports 3) Get a list of all the cronjobs on that system and the commands that are run 4) Get a copy of all the scripts that are run by Cron 5) Create your puppet manifests using the crontab entries, scripts and config files as a reference 6) Put all your puppet manifests into git/svn/mercurial/etc. 7) Create a staging platform to test your manifests (just because puppet parses them correctly doesn''t mean that they work!) 8) Test your manifests 9) Test your manifests 10) Test your manifests ..... 102) Test Your manifests 103) Checkout your manifests to your puppet master (provided they have passed the tests!) 104) run puppet on a single server and check that your manifests give the required results 105) Compare the server with one that is already working (but was not built by puppet) and try to discover why your puppet manifests aren''t working in production when they worked in staging 106) Fix the issues 107) Run puppet again and check that everything now works 108) Lock down access to all your servers so the only way a change can be made is via GIT/SVN/Mercurial etc 109) Force commit messages for any changes to the config files 110) Use a web interface to git to track any changes 111) Go down the pub and by your entire team a beer for helping you achieve the impossible. If it''s of any help, after approx nine months, I''m at various stages of this process between 1 and 110 for the different services that we have here... we''ve still not made it down the pub yet... :( Cheers, M. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Also of note, if you''re using Puppet 2.6.x then the command `ralsh` from 0.25.x has been superseded by the `puppet resource` command. -Hunter On Fri, Oct 1, 2010 at 08:34, Matt Wallace <lists@truthisfreedom.org.uk> wrote:> On Friday 01 Oct 2010 15:01:25 Kikanny wrote: >> Thank you all for taking your time to explain it to me. I guess I''ll >> give it a whirl and see how it goes. Another question I have is what >> if the person managing a web server does not have full knowledge of >> whatever is installed in a server or there was some other >> configuration management in place. How would I bring that under >> puppet''s control? I''m asking this because we do have servers like >> that. Thanks! > > 1) Get a list of running services/open ports > 2) Get all the relevant configuration files for those services/ports > 3) Get a list of all the cronjobs on that system and the commands that are run > 4) Get a copy of all the scripts that are run by Cron > 5) Create your puppet manifests using the crontab entries, scripts and config > files as a reference > 6) Put all your puppet manifests into git/svn/mercurial/etc. > 7) Create a staging platform to test your manifests (just because puppet > parses them correctly doesn''t mean that they work!) > 8) Test your manifests > 9) Test your manifests > 10) Test your manifests > ..... > 102) Test Your manifests > 103) Checkout your manifests to your puppet master (provided they have passed > the tests!) > 104) run puppet on a single server and check that your manifests give the > required results > 105) Compare the server with one that is already working (but was not built by > puppet) and try to discover why your puppet manifests aren''t working in > production when they worked in staging > 106) Fix the issues > 107) Run puppet again and check that everything now works > 108) Lock down access to all your servers so the only way a change can be made > is via GIT/SVN/Mercurial etc > 109) Force commit messages for any changes to the config files > 110) Use a web interface to git to track any changes > 111) Go down the pub and by your entire team a beer for helping you achieve > the impossible. > > If it''s of any help, after approx nine months, I''m at various stages of this > process between 1 and 110 for the different services that we have here... we''ve > still not made it down the pub yet... :( > > Cheers, > > M. > > -- > You received this message because you are subscribed to the Google Groups "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
I really appreciate your response Matt. It gave me a good insight on the different steps I would have to do to get this working! Hopefully I''ll be able to go to the pub one day !! On Oct 1, 11:34 am, Matt Wallace <li...@truthisfreedom.org.uk> wrote:> On Friday 01 Oct 2010 15:01:25 Kikanny wrote: > > > Thank you all for taking your time to explain it to me. I guess I''ll > > give it a whirl and see how it goes. Another question I have is what > > if the person managing a web server does not have full knowledge of > > whatever is installed in a server or there was some other > > configuration management in place. How would I bring that under > > puppet''s control? I''m asking this because we do have servers like > > that. Thanks! > > 1) Get a list of running services/open ports > 2) Get all the relevant configuration files for those services/ports > 3) Get a list of all the cronjobs on that system and the commands that are run > 4) Get a copy of all the scripts that are run by Cron > 5) Create your puppet manifests using the crontab entries, scripts and config > files as a reference > 6) Put all your puppet manifests into git/svn/mercurial/etc. > 7) Create a staging platform to test your manifests (just because puppet > parses them correctly doesn''t mean that they work!) > 8) Test your manifests > 9) Test your manifests > 10) Test your manifests > ..... > 102) Test Your manifests > 103) Checkout your manifests to your puppet master (provided they have passed > the tests!) > 104) run puppet on a single server and check that your manifests give the > required results > 105) Compare the server with one that is already working (but was not built by > puppet) and try to discover why your puppet manifests aren''t working in > production when they worked in staging > 106) Fix the issues > 107) Run puppet again and check that everything now works > 108) Lock down access to all your servers so the only way a change can be made > is via GIT/SVN/Mercurial etc > 109) Force commit messages for any changes to the config files > 110) Use a web interface to git to track any changes > 111) Go down the pub and by your entire team a beer for helping you achieve > the impossible. > > If it''s of any help, after approx nine months, I''m at various stages of this > process between 1 and 110 for the different services that we have here... we''ve > still not made it down the pub yet... :( > > Cheers, > > M.-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
James Turnbull <james@puppetlabs.com> writes:> Kikanny wrote: > >> Thank you all for taking your time to explain it to me. I guess I''ll give >> it a whirl and see how it goes. Another question I have is what if the >> person managing a web server does not have full knowledge of whatever is >> installed in a server or there was some other configuration management in >> place. How would I bring that under puppet''s control? I''m asking this >> because we do have servers like that. Thanks!Write down what you need the new server to do. Then build something to do that, using puppet, on a new system. When that doesn''t work (which, inevitably, it won''t the first time) work out what went wrong — was it your "what it does" notes, or the puppet side? Fix that, and go back to the first step until it works. :)> In the lack of full knowledge instance, "ralsh" is definitely your friend. > It''s a good tool to get the basics about a host. > > In the latter instance, I don''t see that it matters if another configuration > management system was in place - just remember to turn it off so you don''t > get conflicting management of resources!*nod* You might be able to read the "instructions" in the other configuration management tool, though, to head-start building the puppet side of things. Daniel -- ✣ Daniel Pittman ✉ daniel@rimspace.net ☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.