I’m looking to use Foreman+Katello to manage a relatively small estate (~100) of Linux (new boxes will be Alma, older ones are Ubuntu) servers. From an infrastructure POV we have Pre-prod and Prod environments, and Dev look after the application releases separately. High priority security updates aside, my plan is essentially to take a Product Sync once a month, roll out to Pre-prod then promote to Prod a week later after testing.
These servers will all use the standard Alma repos for most packages, but certain types of server will use extra repos (for example nginx, mysql), so I’m trying to figure out the best way to divide and manage updates for the different server roles.
Products/Repos need to be subscribed to at both a Host level and a Content View level, so I’m uncertain whether to use different Products for the additional repos, or just use one Product containing all required Repos and assign a different Content View for every different server type. The latter currently seems to me like the most straightforward solution.
Can I ask for a little advice on how people manage this in their respective environments please? I’ve not been able to source much information in this area so far.
from a Katello point of view, products are basically a group of repos that all require one specific subscription (Katello is very RedHat opinionated here), so whether you want to put everything in one product or split your repos up into several ones is somewhat a matter of taste. You can use products to set some defaults for the repos like sync plan etc, but you can set everything on the repo level too, afaik. I personally like to group repositories that belong to a certain software stack in one product (like all our mirrored Foreman/Katello repos is one product, another one are Puppet repos, etc).
Concerning the content views, there are several valid solution, and figuring out witch is the best is very use-case dependent.
One big content view for everything: This is generally the low-effort way. The pro is obviously that you have close to no overhead when it comes to managing your content views, but it is also very unflexible (e.g. you can only update all the repos in the CV at once) and every host can access every repo that you have.
One CV per product/repo with one CCV combining them: This approach has the upside that you can update specific repos/components on their own without needing to push new versions of all repositories, but comes at the cost of needing to do a lot more CV publishes per update, since for a full update you need to publish a new version of each CV and then another publish + promote for the composite content view. All your systems can still access all the repos.
One big CV per server-role: This is basically option 1 scaled up. It increases maintenance since you need to manage several CVs but ensures hosts in one CV cannot access the repos that they should not.
One CV per product/repo, one CCV per server-role: Basically option 2 scaled up. You keep the flexibility, but add yet more maintenance on top of if. On the pro side, servers can once again not access any repos they should not.
In any case, I would recommend taking a look at activation keys, since they can help you a lot setting up your systems with the right repositories.
If you do not have paid per-system repositories, I would generally recommend option 2 from the above list and letting activation keys handle what repositories are enabled on the systems by default.
For paid per-system content I would the suggest scaling out to option 4 (which is relatively easy if you started out from option 2).
For example: We have a “general purpose” CCV for our systems where all the default OS repos and our default third-party tools like Puppet are included. But we have additional CCVs (using the same base CVs + an additional CV for the “special” content). This way, maintenance is still on a reasonable level with, but we keep the flexibility this setup offers and can ensure that the paid-per-system content is only accessible to hosts that should have it.
Yes, sorry, I should have also specified that I planned to use different Content Views for different repos, and create Composites to combine them for various server roles as needed. I’m also only using Foreman/Katello for managing updates, not provisioning of the servers themselves - that might also be relevant to only using a single “Product” which contains all my repos.
Activation Keys I have experimented with a little, as I’m just experimenting with a small, 3 server proof of concept lab at the moment I’d mostly been applying different configs manually. I think I didn’t find it immediately apparent that you also have to add Subscriptions to Activation Keys once you’re created them, so I had a bit of trouble with getting my client boxes to work in conjunction with those, but I believe I should be okay with that now when I go back to it.
Thanks, that’s really helpful, and I think seems to broadly be in line with my thinking so far.
