Ansible Integration with Red Hat
Apparently RedHat has acquired ansible. Any documentation planned for how this will be implemented within the RHEL "ecosystem"? Will the ansible packages move to the RHEL package repos from epel?
Responses
Guru
6577 points
Excellent question. I am also interested to know where Ansible fits into the master plan... and whether it will be integrated into Satellite alongside Puppet.
Is someone from Red Hat willing to comment?
Guru
6577 points
I have heard a rumour that Ansible may be integrated to (or integrated with) Satellite 6.2, can anyone from Red Hat confirm if Ansible is on the Satellite 6 roadmap?
Do Red Hat have any comments around the future support/integration of Ansible Tower into the Red Hat product suite?
Guru
6577 points
For those following at home, this slide deck gives some insight: https://access.redhat.com/articles/2155391
I am a little surprised by the integration suggestions in this deck (slide 18), Ansible, Ansible Tower, Puppet and Satellite 6.x in the stack?
Are any community members currently running Tower in their Red Hat environment? keen to hear feedback.
Guru
6827 points
Pixel, that bit you found in slide 18 is surprising. We have some teams within our project that swear by Ansible (and even prefer it over puppet). We are interested in this topic (in this thread) as well.
Guru
6577 points
Yeah, I am using both Ansible and Puppet.. but for different tasks. Ansible for automation and CI/CD tasks, Puppet for maintaining configuration management of the OS. That being said, I can see Ansible doing both.
I have found Ansible to be an easier sell to the dev side of 'devops' too.
Pro
647 points
Yeah, I am using both Ansible and Puppet.. but for different tasks. Ansible for automation and CI/CD tasks, Puppet for maintaining configuration management of the OS. That being said, I can see Ansible doing both.
I have found Ansible to be an easier sell to the dev side of 'devops' too.
Worth repeating, IMHO; as I've come across MANY teams/team-members with same/similar use case scenario.
Meanwhile in the RHEL-Docs... )
Community Member
30 points
Look for updates in 6.3. This will be an 'and' option, not one or the other.
Guru
2210 points
Based on the comments I saw on the Foreman mailing lists when the Ansible purchase was announced, there's a fair amount of support out there for Ansible replacing Puppet. But Red Hat could never openly admit or support that as there are many customers who have bought heavily into the Puppet ecosystem. Shame it couldn't be an OR option though. That would be ideal.
Red Hat
Guru
2845 points
Ansible Support in Satellite (when released) will be in addition to Puppet support. As a Satellite customer, you have the choice of using either, neither or both. More succinctly, both Ansible and Puppet will be first class citizens in Satellite 6. ( We'll also be continuing to invest in the Puppet ecosystems, delivering Puppet 4 support in the near future).
Guru
9255 points
Hi Rich,
How about a standalone Ansible Tower on top of RHEL 7? In my company we supply Satellite as a Service, but customers setup there own management, monitoring, and automation stack. Currently they use the epel released Ansible and would like a supported version.
Kind regards,
Jan Gerrit Kootstra
Red Hat
Guru
2845 points
You can do most of that today with Tower + Satellite. Tower 3.0 supports Satellite (6) (and Red Hat CloudForms) as inventory sources. Your customers can use that and have supported automation + all the upsides that Satellite offers.
Guru
9255 points
Hi Rich,
I am talking about a Hosting Provider, where customers are running applications on our hardware or hypervisors. We provided them only access to our Satellite server, but do not provide an Ansible Tower service. We only intent to provide the rpm's to install Ansible. As the Satellite contains information for multiple customers we do not wish Ansible to scan the inventory. Allowing the inventory to be scanned would mean that we would have to split the Satellite into multiple organizations, even though there is only one System Management team.
Kind regards,
Jan Gerrit Kootstra