During a recent webinar titled, “Modern continuous integration/continuous delivery (CI/CD) pipeline for traditional provisioning,” we received a lot of interest and many questions regarding the topic. Some of the questions were coming in at a very rapid rate and we were not able to address them all. As a followup to our webinar, we have decided to put the answers to those questions into this blog post. The questions are listed below. This is part two in a series, check out our first blog post here.
The demo in the webinar showed a combination of CloudForms/Ansible Tower to accomplish lifecycle provisioning. Is CloudForms an alternative or must it be used together with Ansible? Can you elaborate on the integration?
CloudForms and Ansible Tower can operate independently of one another for provisioning purposes. CloudForms could theoretically handle end-to-end provisioning through the use of Ruby methods to accomplish external integrations. Likewise, Ansible Tower can do this solely via the use of playbooks implemented via Job Templates.
The demo showed how the two products can very easily integrate with one another to produce a robust provisioning process. Adding the two products together gives you a few advantages over simply using them independently:
Self-service provisioning with CloudForms – this allows us to hand out a nice, neat portal and consolidate our standard services into a catalog-like functionality (e.g. standard RHEL7, RHEL8, and Apache Web Servers) to allow users to order services on-demand and reduce processes for requesting new systems.
Environment visibility with CloudForms – this allows us to do things like intelligent hostname conventions, intelligent placement via capacity/tags, and tracking of resources through their entire lifecycle.
Leverage Ansible for Post-Provisioning Actions – Ansible code is written in modules that are heavily used in the community. The modules allow a much easier way for us to integrate with other devices to accomplish end-to-end provisioning rather than having to write custom, one-off Ruby code, as needed by CloudForms as a standalone entity.
In relation to the demo in the webinar, can we use shell scripts in place of Ruby to test our provisioning and retirement? What other alternatives are available?
Yes, a shell script is a perfectly acceptable means to initiate your provision process via Jenkins. In our case, we chose Ruby as the language of choice due to familiarity, however you could use whatever language that you prefer in order to test your provisioning. We could even use Ansible or Python if that was the preferred language. In fact, there are some examples of using Ansible playbooks to initiate testing in our work in progress Github project located at https://github.com/lynndixon/redhat-cicd-tools.
If there are other tools being used in the existing environment, how will the provisioning tools (e.g. CloudForms/Ansible Tower) get integrated for CI/CD?
For testing automated provisioning, CI/CD is nothing more than a wrapper around the provisioning process. When code changes are detected, via a commit or merge request in a git-based product, the provisioning process is initiated, including anything that the provisioning process will integrate with, e.g. adding a DNS entry or registration with Red Hat Satellite. In many cases, the in-line provisioning process will validate that the integration was successful and fail if it was unsuccessful, in which case the validation happens within the process itself. This is one, very simple approach to take.
In more complex examples, you could potentially unit test the individual integrations independent of the provisioning code to validate those changes individually.
Likewise, it is important to remember that we additionally want to test the retirement process as well as provisioning. This ensures proper cleanup of our environment and validates our end-to-end automated lifecycle process.
Can I apply this process to provisioning virtual networks?
Yes. CI/CD, in its generic form, is simply a process for testing your software, represented in the form of code, prior to the final release to an operational state. It is most commonly used for the release of software development. As it pertains to this topic, “software” is the infrastructure-as-code provisioning process which could also include virtual network provisioning. Due to the high number of infrastructure-as-code environments that we see, we also recommend the use of CI/CD processes to ensure and validate that code prior to delivery into production.
Could we trigger an Ansible workflow from GitLab after commiting a change to a playbook in GitLab?
Yes, this is possible. Realistically, there are many ways to implement a CI/CD pipeline, and the proper way depends upon the needs of your business. Our demo is just one example of the tools that could be used and how they could be used in conjunction with one another. For more information, you can look at https://about.gitlab.com/2019/07/01/using-ansible-and-gitlab-as-infrastructure-for-code/.
What do you do when a build fails? Do you rollback the code? Do you delete the VM?
If the build fails, there is a possibility that a VM will be left behind since the retirement process might not complete due to the failure. In this case, you can write a CloudForms method to cleanup the VM on failure. It would also be a good idea to roll back the code, since the code caused an issue in the environment.
Can we use Chef for our post provisioning configuration?
Yes. We have integrated both CloudForms directly (using Ruby) with Chef for post-provisioning configuration, and more recently Ansible Tower (using playbooks) to call Chef for post-provisioning configuration. The key here would be to separate duties between Ansible Tower and Chef, as there are now multiple configuration management tools in play here. In reference to the question as it pertains to our demo, it would likely be Ansible Tower handling any external integrations (e.g. Infoblox, Active Directory/LDAP, DNS, etc) including Chef, while Chef handles the post-provisioning system configuration.
What are the differences in using Jenkins vs. Ansible for Windows Provisioning use cases?
Although Jenkins does have plugins which allow simple integrations with Windows, Ansible is much more mature in this regard and offers many more modules in which you may use to integrate with Windows environments. Additionally, we are not advocating for Jenkins as an integral part to the actual provisioning process, rather we are using Jenkins to initiate the provisioning process to validate it’s stability and reliability when it detects a code change to that process.
Is Red Hat Satellite required?
Red Hat Satellite is not required. However, a CDN which hosts RPM repositories would be required in instances in which your Ansible Tower automation will need to install packages on your provisioned system. In our case, we typically use Red Hat Satellite as our RPM repository, we register systems with Satellite, and finally install and/or update the appropriate packages as needed to satisfy the needs of our automation. Nearly all instances of automation will require this in some shape or form.
The post Modern continuous integration/continuous delivery (CI/CD) pipeline for traditional provisioning: Your questions answered (Part 2) appeared first on Red Hat OpenShift Blog.
Quelle: OpenShift
Published by