In this chapter, we have seen how Puppet can scale while our infrastructure grows. We have to consider all the components involved.
For test or small environments, we may have an all-in-one server, but it makes sense to separate these components from the beginning on dedicated nodes:
A Puppet Master under Passenger
PuppetDB and its backend database (we might decide to move the PostgreSQL service to a dedicated server too)
Eventually an ENC such as Foreman and its backend database (which might be moved to a dedicated node too)
When we need to scale further, or want high availability on these components, we can start to scale out horizontally and load balance the Puppet Master, Foreman, and PuppetDB systems (they all provide stateless HTTP(s) services) and cluster our database services (following the available solutions for PostgreSQL and MySQL).
When the bottleneck of a centralized Puppet Master service becomes an issue or simply not a preferred solution, we might decide to go Masterless...