We run separate nodes for Puppet and Foreman and I would recommend simply because it's simpler, they scale at different rates. We are currently running 6 or so Puppet masters and 6 or so Foreman nodes. Both are accessed behind two load balanced Apache mod_balance nodes. We can hopefully add new nodes to the backend and frontend as required. Having said that we did run originally all on one node. It works, we just wanted greater resilience. I think we got to about 1000 hosts running puppet once per hour before we started to hit problems. The node was 4 core 2 year old batch server. Memory is not a huge problem, you run out CPU before anything else. We have always run the foreman mysql on separate hardware since CERN offers a service for this. We also run 3 types of foreman nodes where we split traffic based on the URL. In particular we had a problem where puppet reports being uploaded to foreman killed the foreman service so the web interface became unresponsive to users. Splitting up foremans by functions has resolved this. Clearly what we have above is pretty complicated and comes after nearly 2 years and probably 4 evolutions of the service. I would start with two boxes, one for foreman and one for puppet and then as quickly as possible plan to get a Apache mod_balance (or HA Proxy) in front or even start with this. All are puppet and foreman backends run passenger to make them multi threaded. In addition we have two very high quality brand new hardware boxes for puppetdb and postgres. .. PuppetDB is where we are currently struggling with scaling for sure. We are actively working with puppetlabs here to reduce the load that PuppetDB generates... This is making progress but still getting this to more than one node currently has no obvious solution.
Our config is : - One node, SL6.2, serving as o Puppetmaster running under passenger (with a recompiled ruby version, see another mail of mine in this thread about that) o Foreman server o Git (gitolite) server o CA server (the puppet CA) o Puppet fileserver o HTTP/Yum mirror for our OSes, epel and any other repositories we might use (and one apt mirror, for our single debian managed host) o Disk is only relevant for mirrors in our case : the mysql DB is 500MB big after a few weeks, because of reports but these can/are cleaned up - The nodes specs (now): o Xeon E5-2640 0 @ 2.50GHZ (12 phycical cores) o 32GB mem. 27GB free… o 2TB (raid6) data filesystem, 185G used. Foreman acts as a web frontend, and connects to “foreman proxy” daemons to run his actions, so in case of overload, you can probably split the puppetmaster/tftp/dhcp/foreman server (the proxy must run on the puppetmaster), but these things are a bit sensitive to set up... But for a beginning, I would advise to run both/all on same host, as this surely will rule out “same host assumptions” in the code/config.
At DESY we have 2 dedicated puppet masters and 2 infrastructure servers which we share between PuppetDB, Foreman and GitLab. As a database backend we use a 2 node postgreSQL cluster. You can find more infos on my talk (link above) at the last hepix With our current setup we are managing ~ 500 clients and the load on the puppet master servers is still very low (load average of ~ 3). We are also using passenger which seems to be the highly recommended way of using puppet in production environments.
nslookup cld-foreman.cloud.pd.infn.it Server: 127.0.0.1 Address: 127.0.0.1#53 Name: cld-foreman.cloud.pd.infn.it Address: 192.168.60.31
https://cld-foreman.cloud.pd.infn.it Unable to connect Firefox can't establish a connection to the server at cld-foreman.cloud.pd.infn.it.
- on cld-foreman: # ssh -R 6333:localhost:80 user@<inside_desktop>.pd.infn.it - on <inside_desktop> atart firefox with "localhost:6333"
- on cld-foreman: # ssh -R 6333:localhost:80 <user>@gate.pd.infn.it - on external computer: # ssh -L 5900:localhost:6333 <user>@gate.pd.infn.it - on external computer start firefox with "localhost:5900"