Before we delve into the practical aspects of installing Pulp, let's take a more in-depth look at why you would use it. Throughout this book, we have advocated building a Linux environment that is standardized and features high degrees of repeatability, audibility, and predictability. These are important not just as a foundation for automation, but also serves as good practice in the enterprise. 

Let's assume that you build a server and deploy a new service to it with Ansible, as we have set out earlier in this book. So far, so good—the Ansible playbooks provide documentation on the build standard and ensure the build can be accurately repeated at a later date. There is a catch, however. Let's say that, a few months later, you return to create another server—perhaps to scale an application or for a Disaster Recovery (DR) scenario. Depending on the source for your packages, one of two things will happen:

• If you install from the public internet-facing repositories, both builds will have the latest versions of all the packages that were installed on the date they were built. This difference may be significant, and if time has been put into testing and qualifying software on a given build of Linux, you may not be able to guarantee this with different package versions. Sure, everything is up to date, and you will have all of the latest security patches and bug fixes, but every time you perform this build on a different day, you are prone to getting different package versions. This causes problems with repeatability, especially when ensuring that code that has been tested in one environment works in another.
• At the other end of the scale is the ISO build repositories that we used in Chapter 6, Custom Builds with PXE Booting. These never change (unless someone downloads a newer ISO and extracts it over the old one), and so while it produces builds that are of a completely known quantity (and hence support our repeatability goal), they never receive any security updates. This in itself may be a problem.

The compromise is, of course, to find a middle ground between these two extremes. What if it were possible to create our own repositories of packages that were a snapshot of a given point in time of a public repository? Hence, they remain static when we need them to (thus ensuring consistent builds), and yet can be updated on demand if an important security fix comes out. The Pulp project comes to our rescue here and is capable of doing exactly these things. It is also a component in some of the more complex infrastructure management solutions such as Katello, as we shall see in the next chapter. 

However, for installations where a Graphical User Interface (GUI) is not a requirement, Pulp meets our needs perfectly. Let's take a look at how we might install it.