Disclaimer: This is not a roadmap for Red Hat, just a concept based on upstream projects and research.
First, a bit of back story just so you know how I’ve arrived about what this post talks about.
I’ve been researching how organizations design reusable services and suggesting how it might be possible to improve the lives of service designers (what some call a DevOps Engineers) by:
- Allowing orchestration of a greater amount of deployment types (containers, VMs, public cloud services, etc).
- Accommodating greater reuse as build automation is adopted (don’t throw away all your hard work, but build upon it).
Originally, several Red Hatters and I took a look at how the ManageIQ community (the upstream for Red Hat CloudForms) could orchestrate a repeatable deployment of an application that included resources from OpenShift and OpenStack using Ansible playbooks via Ansible Tower. Here is a video of that and a post explaining why we did this. We identified some of the gaps we would like to see fixed and were excited to see ManageIQ’s RC1 including integration with Ansible Tower to fill many of those gaps.
We also conducted research and built empathy with users within some of our larger customers and discovered several personas and patterns that were attempting to design reusable services that would help deliver applications to product faster with higher quality. We created a concept with the information we had and floated it by the users and had positive feedback.
When we presented this research, analysis, and concept around a service designer user experience to both the ManageIQ and OpenShift teams we had a mixed response. The ManageIQ team reacted positively while the OpenShift team felt it conflicted with plans they had to integrate concepts from the fabric8 community into OpenShift. This was a fair point of view, so we decided to do more digging.
This is when I began looking at the fabric8 community – an opinionated open source microservices platform that several Red Hatters are working on. I encourage you to go have a watch of some of their demonstrations so you can see how they are attempting to make application delivery easier.
I submit that by extending the reach of fabric8 beyond the applications developed on the container application platform (openshift) and deploying operations tooling it will be possible to:
- Access more automation through the use of Ansible’s content (ansible-galaxy has over 6000 roles and 1500 authors).
- Assist developers to understand what impact on the infrastructure there application is having.
What if we were to start including both operations tools and the ability to automate beyond the container application platform in the Continuous Delivery pipeline by deploying the needed tools to do this during the creation of our cd-pipeline?
Now, why would we want to actually provision our automation (in this case Ansible) and our management platform (in this case ManageIQ) as part of a developers request to create a new application?
Well, it may have several benefits over long lived automation and management platforms.
- Management on demand – no more long lived management infrastructure for applications that don’t exist!
- Tenancy per application – all your management cleanly divided by tenant.
- Good behavior to have “Ops” included in “Dev” – by having operations tools included in the pipeline it may be easier to invite operations into the development process and reduce friction when moving towards production.
How might this work? Here is a simple walk through with some visuals to give you an idea.
First, it would be nice to have both Ansible and manageIQ as applications available within fabric8. The image below shows what this might look like in when a user selects “Create New App”.
Once the user deploys the cd-pipeline application (that already includes gogs, jenkins, jboss forge, docker-registry, and Nexus) they would also have fully functional ManageIQ and Ansible pods running and integrated into their environments pipeline.
Now that we have Ansible running as a pod and Jenkins is aware of it, the Jenkinsfile (what defines your pipeline in Jenkins) could be annotated to allow for the use of Ansible Playbooks within the pipeline itself. This would allow for the pipeline to automate things outside of OpenShift, such as Amazon Route 53 DNS or maybe even make some changes to a hadoop cluster, extending the automation beyond the container application platform (OpenShift).
Here is what it might look like to review your build log in Fabric8 if a developer wanted their deployment to also provision a new database (outside of OpenShift) and update it’s schema.
And finally, since when the cd-pipeline app was deployed it automatically wired the ManageIQ pod to your openshift environment it would be possible to have an operational view of containers and even see what playbooks and/or jenkins pipelines they were derived from. This would be handy for troubleshooting any issues of a running application or even starting to tie the worlds of application lifecycle management together with operations management. “How much more real memory is this consuming on the physical hosts when I make this code change?”
I hope you find this blog post useful. I’d love to hear your feedback and thoughts or continue this discussion. Send me a tweet @jameslabocki
all things open 