Hello team, sorry for a basic question.
We acquired AAP for a limited number of licences and we plan to use with Satellite it to provision and manage our infrastructure (based on RHEL, VMware vSphere, Satellite/Foreman, ServiceNow Ticket+CMDB).
We already use Satellite as an Inventory source for AAP for provisionning and for setting up the basic configuration (via rhel-system-roles).
Could you guide me to where is the better place to put/assign our managed server/roles to be used by AAP ?
Instinctively I would say in our Satellite or directly on the Hypervisor (via tags)… but is there a recommended place ?
Satellite’s ability to “assign” roles to hosts in its inventory is a relatively old feature, but works well for its intended purpose. Satellite has a custom playbook (and callback plugin) that loops over dynamically assigned roles, and I think it’s great for one-size-fits-all roles to use on all hosts. (redhat.insights.insights_client and redhat.insights.compliance for e.g.)
That said, that isn’t exactly the “normal” way to run roles against hosts. Normally, you have a playbook that explicitly defines what roles are to be run. As an example, you might have a webserver.yml playbook that includes an apache/nginx role to configure a front-end/reverse-proxy. You would run this playbook specifically against your intended webserver hosts, but technically could work on any host.
Your playbooks/roles/collections should go into a source control (github/gitlab, etc), and you would sync those as Projects in AAP. Your playbooks define what roles are run, and your Job Templates would define what inventory to run those playbooks against. Since you’re already using Satellite as an inventory source, you can still use it as a source of truth for defining variables needed to customize your roles. This keeps AAP consistent with Satellite, but you can also leverage Ruby magic in Satellite to set dynamic values that only Satellite would know.
That being said, you could make a custom playbook that works exactly the same way as Satellite and run roles dynamically “assigned” based off whatever source of truth that you want, but I consider this to be rather complicated to pull off and could be difficult to maintain or train future employees on.
2 Likes
I sense a disconnect, or perhaps an overload is a better way to say it, around the word “role”. There may not be a 1:1 – or even a clear – relation between the roles your individual hosts play in your infrastructure and the Ansible roles you need or want to run against those hosts. This is a very hand-wavy answer, but a lot depends on what you actually have in your Satellite/Foreman and CMDB that you could draw on to inform other processes. Plus, you mentioned you’re migrating from Saltstack; I imagine that your Saltstack way of organizing things is going to influence the approach you take in Ansible. And that’s okay!
Trust your instincts. You have a better feel for your environment than we do, and there are lots of legitimate ways to do things. Build it in a way you’re comfortable maintaining it. And if you have second thoughts later on, embrace change and refactor early and often.
3 Likes
Thank for the advices and suggestions
I just had someone from RH recommend me to use satellite’s hostgroups (via hostvars and groupvars).
I guess there is no absolute answer.
We lean toward using a mixed approach: satellite. Dynamic inventory as source of truth supplemented via Saltstack, vmware and our current cmdb.