Paolo, thank you so much for the info. It is a bit confusing, so I've got a bit of a ways to go, but it is helpful in designing a comprehensive puppet infrastructure.
Can you provide any more details on your "puppet proxy" server configuration? I do not have much experience dealing with Apache proxies and any config details would be helpful. That is the item I'm stuck on right now. Best regards, Karl On Tuesday, November 19, 2013 5:18:31 AM UTC-5, pdpinfo wrote: > > Hi Karl, > > this topic has been discussed many times, particularly in respect of > "large scale" and "distributed". > There are many possible setups/solutions. > I try to add my 2cents, firstly pointing out main issues. > Cannot say if this setup can be recommended, but it works well for us. > > 1) how large is the base ? You may need a central balanced "puppet farm" > to manage the load > --> manage balancing and CA certificates > --> manage high performance setup: involves PASSENGER/Apache > --> manage reports > --> manage node classification > --> manage versioning and deploy > > 2) do you need direct and proxy access at the same time ? > --> you need an apache configuration supporting both > > At the moment the setup I use is: > > - A "repository server" with git+gitolite + scripts/hooks for deploying on > puppet servers > - Many puppet environments and branches for each one > - A "clustered" active/standby Puppet Server (Puppet 2.7, Passenger, > Foreman, Mysql, DRBD+Heartbeat). Supports direct and proxied access. > - Two other "single" puppet servers (contents are deployed by the same > gitrepo) > - Three "puppet proxy" servers (Apache + mod_proxy) pointing to the > respective puppet server > > At the moment this infrastructure (servers are VMs) is supporting almost > 500 clients, while a lot are still linked on a legacy puppet. > > The whole setup involves many steps, starting points are: > > a) manage certificates for many puppet server (here we're using Puppet CA): > --> basically generate one time a certificate including as DNS > alternate names all the DNS names used by puppet servers, including virtual > IP/alias > --> share the server SSLDIR (could be clustered, or networked). Ensure > only one CA is used (or 2 servers, acting as the same CA). Provided the CA > remains the same, the servers certificate can be freely updated in the > future. > > b) generate with Puppet CA an SSL server for SSL termination points > (proxies): should contain all DNS names used to reach the server (including > DNS aliases). Proxy trust Puppet CA. > > c) generate certificate for Foreman-proxy, if used > > d) setup virtual host for proxy (must extract SSL information for request) > and pass them to Puppet Server > > e) setup multiple virtual host on Apache on Puppet servers: > --> VH for proxies: communication with proxies must be secured, > because SSL client authentication happens on Proxies > --> VH for puppet client direct access: "standard" SSL puppet client > authentication > > f) setup puppet.conf of servers, to manage headers passed by apache, i.e > ssl_client_header, ssl_client_verify_header > > So, what is less confusing :-) ? > > Regard > > Paolo > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/d3beb651-8baf-4445-b1e9-95f35689d2e2%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
