Good Afternoon,
Apologies for starting a whole bunch of threads in one afternoon, but
I''m desperately after a bit of information from the community ;(
I wondered if anyone has written some deployment examples for various
sizes of infrastructure, or if this is something Puppet Labs plans to
address as part of documentation? There are a number of ways of
slicing the apple, including WEBrick for "smaller scale" deployments
through to mod_proxy or mod_passenger for "larger scale" deployments
and some seemingly dated notes in the Wiki about potentially splitting
serving of manifests and files?
I appreciate everyone has a home-cooked and favourite way to make
things work, but think we''d all benefit if initial deployment was a
bit easier, better documented, and standardized?
I''ve got in mind about three different topologies:
1) Fifty nodes, managing 400 resources
2) Two hundred nodes, managing 1000 resources
3) One thousand nodes, managing 2000 resources
4) Other suggestions from anyone here?
Optionally you might mix in the steps necessary to get Dashboard
working as an external node classifier with the setup instructions?
If the hardware and complexity involved in coping with #3 isn''t vastly
greater than solving #1 then perhaps that should become the new
''Recommended'' architecture for deploying any non-trivial
install?
If we''re just talking about installing Apache, dropping in Puppet via
Rack and mod_passenger, it should be fairly easy to write this from
the context of being distribution neutral?
Please feel free to point me at documentation or blogs if there is
anything particularly suitable out there!
Many Thanks,
- Alex
--
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 Jun 29, 2010, at 6:02 AM, Alex Howells wrote:> Good Afternoon, > > Apologies for starting a whole bunch of threads in one afternoon, but > I''m desperately after a bit of information from the community ;( > > I wondered if anyone has written some deployment examples for various > sizes of infrastructure, or if this is something Puppet Labs plans to > address as part of documentation? There are a number of ways of > slicing the apple, including WEBrick for "smaller scale" deployments > through to mod_proxy or mod_passenger for "larger scale" deployments > and some seemingly dated notes in the Wiki about potentially splitting > serving of manifests and files?Sorry if I''m beating a dead horse, but I want to be clear, "Don''t use WEBrick if more than 2 or three clients are connecting at the same time."> I appreciate everyone has a home-cooked and favourite way to make > things work, but think we''d all benefit if initial deployment was a > bit easier, better documented, and standardized? > > I''ve got in mind about three different topologies: > > 1) Fifty nodes, managing 400 resourcesI''ve got a setup like this running on apache+passenger on a Celeron D with 512 MB of RAM. Clients check-in every 30 min. The server isn''t having any trouble with the load.> 2) Two hundred nodes, managing 1000 resources > 3) One thousand nodes, managing 2000 resources > 4) Other suggestions from anyone here? > > Optionally you might mix in the steps necessary to get Dashboard > working as an external node classifier with the setup instructions? > If the hardware and complexity involved in coping with #3 isn''t vastly > greater than solving #1 then perhaps that should become the new > ''Recommended'' architecture for deploying any non-trivial install? > > If we''re just talking about installing Apache, dropping in Puppet via > Rack and mod_passenger, it should be fairly easy to write this from > the context of being distribution neutral?This is true if you want vague steps like "Install Passenger and rack" instead of "Run ''apt-get install librack-ruby libapache2-mod-passenger apache2-mpm-worker apache2-threaded-dev''" In general, it''s usually easier to install stuff that''s packaged in gems (like passenger) using your distro''s package manager if: 1) Your distro''s package manager has those packages 2) The packages are up to date.> Please feel free to point me at documentation or blogs if there is > anything particularly suitable out there!Installing Passenger using gems. Make sure to read the README all the way through. http://github.com/reductivelabs/puppet/tree/0.25.x/ext/rack/ -- 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 tend to avoid gems at all in production because it''s a turd of a package manager. You are asking for pain if you try to deploy production apps with gems IMO, when it''s likely your package manager has versions from the vendor that are acceptable. If they don''t I recommend building the packages and putting them in your in-house custom repo, which you should probably have for cases like this. My deployment is a puppet master per site, not for resource reasons, but for network reasons really. I use mod proxy balancer with mongrels and it serves out fifty nodes with stored configs etc just fine, on a 32 bit VM with probably only one core. And yes, the docs that seem dated for splitting file serving, certificate auth, and manifests are probably still close to valid. -- -- Joe McDonagh Operations Engineer AIM: YoosingYoonickz IRC: joe-mac on freenode "When the going gets weird, the weird turn pro." -- 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.