So, you are automating with Ansible?

Well, many of you have started automating with Ansible! And, even if management is not aware if it, with Ansible upstream, namely Ansible ad hoc (command line tool). And it works!

Cool, that strategy is supported by Gardner in a thorough analyses of todays automation platforms. Spoiler: Ansible wins! Ansible is a head of the pack on functionality, partner ecosystem and supported products and services. So, if that matters to you, Ansible might be worth looking into to extend the use. Ansible get more and more integrated in a seamless way into all Red Hat products, like the RHEL system roles. But let's not forget that the real impact on an organisational level automation strategy, includes a lot more than Red Hat products. And, that's where Ansible Automation Platform surpass the competitors! Ansible can be THE common automation language to automate and integrate, across all vendors, clouds and platforms. Why? Because it is easy to get started with for anyone, and have an exponentially growing community! If you can read english and tie your own shoelaces, your are already qualified to work with Ansible! You do not need coding skills to understand what the following playbook actually do:

But, automation introduces security concerns. Where do we get our automation processes from? Who writes them? What is the source? Well, many supported and security analysed collections are provided via our Red Hat Certified Content hub. This hub provides modules/roles that are fully supported by Red Hat and/or a third party vendor like Microsoft, Amazon, VMware, F5, Cisco and many more. That provides predictability. We like that!

But, everything you need is not in the certified content hub? (of course not). Because of the huge Ansible community, you most probably will rarely have to write your own modules or roles from scratch. It's already out there, and the main source for community content is galaxy.ansible.com. This Red Hat supported community have thousands of contributions, both from vendors like IBM and VMware, in addition to collections provided by individual contributors. So, you do not have to reinvent the wheel. But, on some occasions, you do have to modify the stuff you find for free, or even write your own from scratch.

And that leads back to the question about security and compliance. If everyone in an infra team, can download and use collections from the open community Galaxy freely, and even modify them, to suit the needs of the organisation. How do we manage that? How can we secure that, without limiting our options? How can we define the standard tested and approved routines for automating deploy on VMware?

Well, Red Hat did release a solution for this some moons ago, by providing an Automation Hub in our cloud service on cloud.redhat.com. In this cloud service, you can add your preferred and needed fully supported collections from the partner eco system to the Automation Hub, as well as self provisioned and vetted collections into defined namespaces. If you look up at the screenshot of Partner solutions, notice that the menu also shows "My namespace". Which means, that you in our cloud service, could define preferred collections, and enforce that in you local and Tower projects.

But, but, we always have a but! When it comes to storing stuff in the cloud. If you due to security concerns and compliance requirements, have to create an Ansible project on a local git repository (VERY common), you do not want to expose that repo to the internet, but it should be managed by something like Automation Hub locally. We totally agree!

And that's why we with Ansible Automation Platform 1.2 released November 19. 2020, are happy to offer the Private Automation Hub. A local hub running in pair with your Tower infrastructure, to provide both vendor supported collections, community collections and custom collections, in a group managed way, with approval processes, to make sure that the Ansible modules and roles you use to automate/integrate are secure, tested and vetted by the automation and security team in the organisation. And, with simplicity! It's easy to configure internal (or external) git repos, to be allowed, denied, version locked or more, with RBAC access as you are used to in Tower. Quick snapshot here from my homelab, where I have access to ALL certified and supported collections, and this single custom but vetted and published one, in my on premise running Automation Hub.

Adding my organisation's approved and vetted Ansible collections to the production environment in Tower, is easy peasy, as this screenshot shows for the supported repos. Sample is RH-certified collections:

There are a few more details to actually securing what collections/modules/roles are actually allowed/denied to use in an organisation, but I will not dwell into that in this article. (Read docs or contact us) I just have to say, like most other things with Ansible, that aspect is also easy to grasp and handle. And, the Ansible documentation at docs.ansible.com is brilliant!

So, if you are an organisation in the Nordics curious to what Ansible can do to optimise your value chain, enable you for digital transformation, please feel free to contact me for an informal tech/use case talk anytime (demo guaranteed). I can deliver the talk in norsk! If you prefer Finnish, Swedish or Danish, I have brilliant SA colleagues in the Nordics, that would be more than happy to have the same talk with You.

In Norwegian: Dere IT-folk som leser dette, er hjertelig velkommen til ? koble her p? LinkedIn. Jeg sammen med bla. kollega @Vikram jobber ogs? med den norske Red Hat MeetUp-gruppen, s? har du ?nsker der, s? kan de ogs? slenges denne veien via en PM. Selv om gruppenavnet indikerer Oslo, s? er gruppen naturligvis ikke begrenset geografisk i disse tider.

Best regards

?ivind Ekeberg

Senior Solution Architect

Red Hat Nordics - Norway