In part 1 we discussed the prerequisites required to get Redhat Satellite 6.2 ready as a provisioning platform. Although there were quite a few tasks, as previously mentioned, in the main these are a one off activity and once set up, make provisioning hosts a quick and easy operation.
I had some great feedback from part 1 which was much appreciated. In particular Rich Jerrido from Redhat, ohples and bippity12 via Reddit all of whom pointed out that it’s not necessary to set up Satellite as a DHCP server if you’re relying on external DHCP servers. I tried out their suggestions and they are indeed correct.
So, bearing this in mind, I updated my configuration from part 1 as follows. First I disabled DHCP on the Satellite server:
This week I’m looking at provisioning with Redhat Satellite 6.2. Redhat Satellite 6 has become a bit of a lumbering beast. It does a lot of stuff but it’s not as straight forward as the old versions. Whilst patching remains probably the key function, the provisioning tools are quite powerful. I’ve been investigating this over the past few weeks. Here’s what I found out.
One of the first thing I discovered was that although RedHat have produced quite a bit of documentation for Satellite 6.2, because it’s become quite complex, there’s still bits missing. Hopefully this article will help you with the missing bits. So, on the provisioning side, Satellite can build VMs, including the VM definition itself, act as a DNS source or update DNS, act as a DHCP server, act a tftp server and a puppet server. These parts I have tested. It can also provision to AWS and Docker containers. These remain to be tested (but will be once I have a suitable test environment). The aim of Satellite provisioning is to supply more or less push button building of servers, VMs and presumably AWS EC2 instances and Docker containers. To achieve this, quite a lot of upfront configuration of Satellite is required, so let’s take a look at the prerequisites.
The following Satellite components need to be set up for efficient Satellite provisioning. Although they do not all need to be in advance and it may seem like a lot of work to set up everything, setting up these prerequisites is pretty much a one off activity. As also mentioned it also greatly speeds up and simplifies the actual deployment process.
- Lifecycle environment: A logical way of dividing up hosts depending on the type of environment they serve, e.g. development, user testing and production
- Content View: a subset of the Satellite content, e.g. packages and puppet modules . This will built from specified yum repositories, which may be the RedHat repositories provided by Satellite or custom (see Creating a repository and adding it to a content view). You can also add puppet modules to the content view to make those available.
- Puppet Environment: Satellite can act as a puppet master and creates its own Puppet environments when you import Puppet modules into Satellite (see Setting up Puppet for Satellite)
- Content Source: these are created when Satellite is installed and will either be the Satellite server itself (via an internal capsule) or other capsules.
- Subnets: These define subnets, VLAN IDs and boot modes for Satellite
- Compute Resource & Compute Profile: For VMs, these define the vCenters and the parameters supplied to VMWare to create the VM, e.g. number of CPUs, memory, etc.
- Host Group: All of the above can be added to a Host Group so that when the Host Group is selected, the new host form is auto populated with the correct details.