Kategorie: technology

CloudForms 4.1 is here!

Today we are proud to announce that the latest version of CloudForms is available. This release takes several steps further down the road towards managing hybrid IT. We’ve added new cloud platform providers, software defined networking (SDN) management and made it all easier to automate IT processes by integrating Ansible Tower playbook execution. In short, you will find this release greatly expands the breadth of CloudForms while making it easier than ever to set up and automate your IT operations.
Google Cloud Platform
With each release, CloudForms continues to expand its platform providers, and this release is no different. Google has been working with the ManageIQ community to create a provider for the Google Cloud Platform (GCP). This release makes that provider officially available in CloudForms. With the GCP provider enabled, you can view the complete inventory of virtual machines across regions and availability zones. You can provision new virtual instances from a private GCP image and manage them via CloudForms. While the instances are running, CloudForms will receive events like start, stop or delete and you can operate power operations on the instance. Best of all, you can do all of this from a CloudForms appliance running in GCP, allowing you to your entire cloud infrastructure on Google’s massively scalable, global cloud infrastructure.

Improved Azure Support
With the launch of CloudForms 4.0 in December 2015, we added support for Microsoft Azure. Over the intervening months, we’ve continued our collaboration with Microsoft to further enhance and extend CloudForms’ management capabilities for Azure. The result is that now you can provision Azure instance from private images, we’ve added full lifecycle management for those images, and you can receive and respond to events from compute, storage or networking. Most important, you can now perform Smart State Analysis on Azure instances, bringing the deep inspection capability in CloudForms to the cloud and allowing the same policy compliance and enforcement for cloud images as for on-premise images.

Ansible Tower Integration
Anyone who has used CloudForms knows that much of its power comes from its ability to automate complex IT processes, making them faster and more repeatable. Until now, automation meant learning and then developing the automation steps in Ruby. While Ruby is a relatively accessible language, it still poses a hurdle, especially if you are not a developer. In CloudForms 4.1, we’ve taken a major step towards lowering that hurdle by allowing you to use Ansible playbooks as an alternative to Ruby to drive CloudForms automation. Ansible playbooks are written in an easily accessible language that most IT professionals can adopt. What is more, the Ansible Galaxy contains hundreds of playbooks that are ready to run or can provide a starting point for further customization.
Beyond using Ansible in automation routines, it can also be used to enhance service provisioning. Ansible playbooks can be called as a part of the provisioning process, allowing customization of general virtual instances. This allows organizations to start with a few general images and allow Ansible playbooks create the variety of services required. It also makes it easier to move applications from development into production. Developers can provide an Ansible playbook along with their application, ensuring that when that application is deployed, that the image that it is running on is provisioned appropriately.

Software Defined Networking
As more of the datacenter functionality is absorbed into software, CloudForms is looking beyond virtual compute management to other datacenter resources. One of the most dynamic area today is Software Defined Networking (SDN). SDN promises to bring to networking the same dynamic and reconfigurability that virtualization brought to compute systems. With SDN, you can setup, teardown, configure and reconfigure virtual networks that allow applications and systems to operate in the same manner as if they were connected to a physical network. Given CloudForms’s role in the provisioning, configuration and management of virtual instances, it is natural for CloudForms to take on a similar role for the virtual networks that connect those virtual instances.
CloudForms 4.1 introduces management for SDN, including support for OpenStack Neutron and native networking built into Amazon Web Services, Microsoft Azure and Google Cloud Platform. Developed in the ManageIQ community in conjunction with Nuage Networks, CloudForms provides the ability to maintain an inventory of virtual network routers, switches and ports, and view how each items relates to others and to the virtual compute instances to which they are attached. Using CloudForms you can visualize the entire network and navigate across objects, from a router to the network, to the subnet, to the network port, up to the virtual instance that it is connected to. Along that path, you can see summary information for the object, utilization statistics and its relationships to other objects.

Cloud Friendly Subscriptions
For customers who have a hybrid environment of virtual instances both on-premise and in the public cloud, CloudForms 4.1 now offers them the ability to simplify their subscriptions. Available immediately, CloudForms subscriptions may be applied to either two-sockets on premise or 16 virtual instances in the public cloud. Customers may transfer subscriptions from either format as often as is needed without requiring notice to Red Hat. Moreover, public cloud instances may determined by the average cloud instances under management over the prior 12 months. Now customers considering hybrid environments can more easily use CloudForms to help their transition into the public cloud and be confident that they have the subscriptions required, without having to buy for peak demand.
Other Improvements
In addition to the big changes described above, CloudForms 4.1 also contains a number of smaller, but important changes:

An improved charge-back model with multiple rate-tiers and support for multiple currencies
Instance live-migration, re-configuration, capacity planning, and CPU and memory right-sizing on Red Hat OpenStack Platform
REST API enhancements that allow stop, start, pause, suspend, shelve, reset, and reboot actions on instances as well as the ability to approve or deny provisioning requests
Tenant developments that allow reporting on tenant consumption and tenant quotas as well as storage of rate tables on a per tenant basis
A fully internationalized self-service UI with shopping cart ability, allowing ordering of multiple items in one transaction
Usability and responsiveness improvements for extremely large environments that allow targeted refreshes of inventory instead of full refreshes

For a complete list of new features, you can review the Beta 2 blog post.
Conclusion
CloudForms 4.1 represents a major milestone in the development of Red Hat’s cloud management platform. It broadens its provider support with the addition of Google Cloud Platform, enabling greater choice for customers who are looking to move to the public cloud. Via new SDN management and the additional capabilities related to storage, it expands its scope in the datacenter, enabling customers greater agility and speed. It enhances the security and automated policy enforcement required to keep organizations safe and secure, allowing them greater freedom in IT organization. Though with all of these additions, CloudForms 4.1 manages to make it even simpler for organizations to automate their processes via its integration to Ansible Tower. We are extremely proud of the progress we have made over the last six months. Please celebrate the CloudForms 4.1 release with us at Red Hat Summit and join us as we start the journey on to the next release of CloudForms.
Quelle: CloudForms

Creating “Mastering CloudForms Automation”

In this post, we speak with Peter McGowan, author of Mastering CloudForms Automation, to find out about his interest in CloudForms automation and the process behind bringing his book to reality. You can download an electronic copy of the book from the Red Hat Customer Portal.
How did you get started working on CloudForms?
I started working with CloudForms shortly after Red Hat acquired ManageIQ, and we re-branded the EVM product as CloudForms 2.0. I was one of the consulting architects who went through the initial internal training to learn about it.
What sparked your interest in CloudForms automation?
I think my real interest in the automation side of CloudForms was sparked from an internal course that I attended, taught by two automate gurus: John Hardy and Brad Ascar from Red Hat. It was an introduction that planted the seeds in my mind of what could be done. I could really see the power of the tool.
That gave me enough knowledge to go and work with the product with some customers, but I soon realised what a huge topic CloudForms automation was, and that the course only really scratched the surface. Getting comfortable with the inner workings of the automate model took months. I’m the sort of person that learns by doing and seeing, so I studied a lot of Ruby code and wrote object_walker to help me understand how it all works behind the scenes. I also received a lot of help from the CloudForms community and from within Red Hat.
Why did you undertake the effort of writing a book?
At the time I was incredibly frustrated by the lack of tutorial style documentation out there. The official docs are written in a reference style, but I often wished there was a book that would guide me through the steps of doing something in automate, with a lot of code samples.
One of Red Hat’s EMEA consultants, Adrian Bradshaw, wrote a how-to guide for Red Hat Satellite 6 and published it as an open source GitBook. Inspired by his example, I started writing the CloudForms & ManageIQ Automation How-To Guide on GitBook to pass on the knowledge that I was learning in the format that I thought was missing. It took around 9 months to complete, and ended up covering about 60 topics. A lot of people contributed code and ideas and I kept learning more and discovering additional topics to investigate and write about, so it just grew organically.
What was the hardest part of the effort?
Definitely the time that it consumed. I wrote the GitBook while I was working in the EMEA Architects team, snatching time in hotels in the evenings, occasional weekends, and on days when I wasn’t working with a customer.
Umbrian courtyard where several chapters of the book were written.
My wife and I went on holiday to a beautiful boutique hotel in Italy last year. I’m much less of a heat-lover than she is, so after having seen the weather forecast and that we were in for a heatwave, I took my laptop. I think I got about 5 chapters written in the beautiful shady Umbrian courtyard that week while my wife was by the pool.
Once we started working on transforming the GitBook into the O’Reilly book, the time pressure shifted into another gear. There were a lot of 12 hour days and long weekends, reformatting and getting things ready for the various publishing deadlines. A big “thank you” goes to my manager for letting me focus on the book exclusively, otherwise it wouldn’t have been possible.
Why did you focus on Automate? What attracted you to that part of CloudForms?
My background has been enterprise systems management for many years, and I’ve always loved scripting, first Perl, and then Python. Learning Ruby was fun, and automate seemed to be one of the most powerful aspects of CloudForms. You can literally automate anything with it.
What role does Automate play in the overall CloudForms architecture?
CloudForms is a web-based application, and there is a huge amount of functionality that is available out-of-the-box via the WebUI. Automate is one of the features that isn’t necessarily front-and-centre in the WebUI, but behind the scenes it does a lot of the work; things like sequencing the steps involved in provisioning a virtual machine for example. It’s also incredibly customisable.
Who is this book geared toward and how can they best use it?
The book is geared towards anyone who wants to understand more about CloudForms automate. This could be just to get an awareness of how the built-in provisioning state machines work, or to learn how to create their own custom automation workflows.
The book is in six parts, with the first part introducing the components, concepts and Ruby objects that we use when creating automation scripts. We literally start by writing “Hello, World!” to the automation log file.
The remaining five parts cover the provisioning of virtual machines and cloud instances; creating service catalogs; the retirement process for VMs and services; the capability of CloudForms automate to integrate with the wider enterprise, and some miscellaneous topics.
I’ve written it as the book that I’d always wished for; there are a lot of code samples, and step-by-step tutorials and screenshots showing how to get things done. Several of the chapters cover some in-depth background information, but I found that this helped in my understanding of how things worked when I was learning, which is why I’ve included them.
Were there any surprises or interesting things you learned along the way?
I’m always pleasantly surprised at how many people now make reference to the original GitBook and say that they find it useful, it makes it all worthwhile. I once saw it mentioned in a job description: “Required skill: an ability to understand Peter McGowan’s Automation Book”. That made me smile.
When I started on the O’Reilly version it was interesting to learn the little details that make the difference between 60-odd vaguely connected brain-dumps on a web site (the original GitBook), and a proper book. Things like introducing concepts, leading the reader on a journey, starting a chapter with a reason for covering this topic, that kind of thing. Brian Anderson from O’Reilly helped me enormously in this regard, and Shiny Kalapurakkel and the production editing team were fantastic in getting the layout right. I also learned that my English needs improving somewhat.
From a technical point of view, the more I’ve discovered about Ruby and Rails, the more I’ve been impressed with it.
Was there a particular highlight that you’d like to share?
I think there are probably three that really spring to mind. I’ve read O’Reilly books for many years, and I have a nice little collection on the bookshelf in my study at home. I hadn’t realised quite what a “look and feel” they have from a layout and font point of view until I compiled my first build in O’Reilly’s Atlas build system. Seeing my words in an instantly recognisable O’Reilly format gave me a big grin from ear to ear that lasted the rest of the day. Then, I think finding out what my animal was going to be was exciting. O’Reilly allocated an animal  for the CloudForms book, it’s a Red Breasted Goose. And finally seeing the book in print for the first time at the Red Hat Summit was amazing. It was a very proud moment!
How do you feel now that it&8217;s done and published?
Exhausted, elated, proud, and hugely thankful to everyone that has helped (a lot of people!)
What is next for you and for the book?
I’ve been working on getting a ManageIQ version of the book ready. Unfortunately, due to the lead-time involved in getting the O’Reilly book written, copyedited, checked and printed, there wasn’t time to include any of the new features that CloudForms 4.1 brings, especially the Ansible Tower integration. I’ve almost finished adapting the book for ManageIQ Capablanca, and once that’s done I’ll work on updating it for CloudForms 4.1 and ManageIQ Darga.
I’d also like to start working on some cookbook-style books, possibly containing automation recipes or CloudForms configuration and deployment guidelines for various scenarios.
Is there anything else you’d like to add?
Writing the book has been a real collaborative effort. It might be my name on the cover, but it was only possible because of the people and fantastic knowledge-sharing culture that we have at Red Hat and the amazing team at O’Reilly. I think of any technical publisher, O’Reilly is the dream aspiration for any budding author. There are too many people to name individually, but to each of you, next time you see me, tap me on the shoulder because I owe you a beer!
 
Quelle: CloudForms

Configuration of an Ansible Tower provider in CloudForms

This is part 2 of our series on Ansible Tower Integration in Red Hat CloudForms.
As mentioned in our previous post, CloudForms 4.1 brings native integration capabilities with Ansible Tower. This post explores the Ansible Tower requirements as well as the configuration of the provider in CloudForms.
Like all providers within CloudForms, the Ansible Tower provider is agent-less and only requires connectivity and credentials to the Ansible Tower API.
The initial configuration of the provider is performed by selecting ‘Add a new Provider’ under ‘Configuration > Configuration Management > Configuration’.
 

 
Once the credential details are filled-in and validated, add the provider and trigger a provider update by selecting ‘Refresh Relationship and Power States’ under the new provider&8217;s &8216;Configuration&8217; button. CloudForms queries the Ansible Tower API and obtains an inventory of all hosts and Job Templates available.
All discovered hosts are accessible by expanding the inventory groups under the newly created Ansible Tower provider.

 
Similarly, all discovered Job Templates are accessed under the provider by expanding the &8216;Ansible Tower Job Templates&8217; accordion menu.

 
Job Template details are visible from within CloudForms. This includes any extra variables or surveys set on the Job Template.
 

In this article we configured a new Ansible Tower provider in CloudForms. This provides CloudForms with visibility into the Ansible Tower inventory, including hosts and job templates. In following posts, we will explore how to launch a Job Template from within CloudForms as a button on a VM, as a Service Item in the Service Catalog, or as part of CloudForms Automation.
Quelle: CloudForms

Introducing Ansible Tower Integration in CloudForms 4.1

Ansible Tower is a management tool designed to help automate infrastructure operations. Ansible Tower features management of host inventory, Ansible playbooks, access keys and passwords, as well as detailed reporting and audit of infrastructure deployments. Ansible Tower is designed for team-based infrastructure management, and as such, facilitates user’s involvement at different levels of the infrastructure operations. It enhances basic Ansible CLI operations with a visual overview of the infrastructure states and provides management workflows across the enterprise. Using Ansible Tower, users can schedule Ansible playbook runs and monitor current and historical results, allowing for troubleshooting or identification of issues before they occur.
 

 
The latest 4.1 release of Red Hat CloudForms provides an out-of-the-box integration to Ansible Tower. Ansible Tower is configured and presented as a Configuration Management provider in the same form and location as Red Hat Satellite 6. Once configured, the integration provides visibility in CloudForms of the Ansible Tower inventory, including hosts and job templates.
 

( function() {
var func = function() {
var iframe_form = document.getElementById(‘wpcom-iframe-form-672c677f374bdb7c2c7fd975c07eb5f7-57a481bcc88ef’);
var iframe = document.getElementById(‘wpcom-iframe-672c677f374bdb7c2c7fd975c07eb5f7-57a481bcc88ef’);
if ( iframe_form && iframe ) {
iframe_form.submit();
iframe.onload = function() {
iframe.contentWindow.postMessage( {
‘msg_type': ‘poll_size’,
‘frame_id': ‘wpcom-iframe-672c677f374bdb7c2c7fd975c07eb5f7-57a481bcc88ef’
}, window.location.protocol + ‘//wpcomwidgets.com’ );
}
}

// Autosize iframe
var funcSizeResponse = function( e ) {
var origin = document.createElement( ‘a’ );
origin.href = e.origin;

// Verify message origin
if ( ‘wpcomwidgets.com’ !== origin.host )
return;

// Verify message is in a format we expect
if ( ‘object’ !== typeof e.data || undefined === e.data.msg_type )
return;

switch ( e.data.msg_type ) {
case ‘poll_size:response':
var iframe = document.getElementById( e.data._request.frame_id );

if ( iframe && ” === iframe.width )
iframe.width = ‘100%';
if ( iframe && ” === iframe.height )
iframe.height = parseInt( e.data.height );

return;
default:
return;
}
}

if ( ‘function’ === typeof window.addEventListener ) {
window.addEventListener( ‘message’, funcSizeResponse, false );
} else if ( ‘function’ === typeof window.attachEvent ) {
window.attachEvent( ‘onmessage’, funcSizeResponse );
}
}
if (document.readyState === ‘complete’) { func.apply(); /* compat for infinite scroll */ }
else if ( document.addEventListener ) { document.addEventListener( ‘DOMContentLoaded’, func, false ); }
else if ( document.attachEvent ) { document.attachEvent( ‘onreadystatechange’, func ); }
} )();

 
With this integration, Red Hat CloudForms leverages the automation capabilities of Ansible and extends its reach to third party applications, by re-using the large library of existing Ansible playbooks (see Ansible Galaxy).
Practically, the integration brings to CloudForms the following capabilities:

launch Ansible Job Templates from CloudForms Automate, such as Provisioning or Retirement State Machines, on a click of a button on a Host/VM, or as an action on a control policy
launch Ansible Job Templates from CloudForms Service Catalog as a Service Item or as part of a Service Bundle

We will explore each of these capabilities over the next blog posts. Stay tuned!
This is the first article of our series on Ansible Tower Integration in Red Hat CloudForms:

Part 1: Introducing Ansible Tower Integration in CloudForms 4.1
Part 2: Configuration of an Ansible Tower provider in CloudForms
Part 3: Launching our First Ansible Job Template on a VM in CloudForms
Part 4: Publishing an Ansible Job Template as a Service Catalog Item in CloudForms
Part 5: Using an Ansible Job Template Service Item in a CloudForms Service Bundle

Quelle: CloudForms

Launching our First Ansible Job Template on a VM in CloudForms

This is part 3 of our series on Ansible Tower Integration in Red Hat CloudForms.
In this article, we will explore how to use the Ansible Tower integration in CloudForms by configuring the launch of an Ansible Template Job on a click of a button from a VM.
In this example, we use an Ansible Job Template created based on a role found on the Ansible Galaxy role library. In particular, we installed on our Ansible Tower the sfromm.postgresql role dedicated to managing PostgreSQL. Our associated Ansible Playbook is available on GitHub.
As seen in our previous article, an inventory of all Job Templates is available in CloudForms under ‘Configuration > Configuration Management > Ansible Tower Job Templates’. For each of them, CloudForms provides the ability to auto-generate a Service Dialog which can be used to prompt users to validate or provide Job Template inputs. The dialog  generation can be triggered by invoking ‘Configuration > Create Service Dialog from this Job Template’ on a Job Template and filling the service dialog name field.
 

 
Once saved, the generated service dialog can be found under ‘Automate > Customization > Service Dialogs > All Dialogs > PostgreSQL Deployment Dialog’.
 

This dialog contains all of the fields required to launch the Job Template. The first element on the dialog is a ‘Limit’ field. This is used in Ansible Tower to filter the hosts and specify on which particular host the job must run. CloudForms populates this field automatically with the VM name when used on a VM button. The other elements correspond to the extra variables required by our Job Template, as previously seen from the Ansible Tower Job Templates inventory.
At this point, we can edit the dialog and modify the elements. One of the common task is to uncheck the ‘read only’ option on the elements and/or add additional logic behind others (e.g. Dynamic Dropdown Lists, etc). For example, we rename the labels to make them more user friendly, and we remove the ‘Limit’ element which will be populated behind the scene by CloudForms.
On the Ansible Tower side, all you need is to configure an inventory corresponding to your CloudForms infrastructure or cloud providers.
If used following a CloudForms VM provisioning, you must trigger an update of the Ansible Tower inventory prior to launching a Job Template. In order to perform this update, simply enable the option ‘Update on Launch’ on the required inventory group source in Ansible Tower.
 

This is required to ensure the new host is present in the Ansible Tower inventory before trying to launch a Job Template on it.
CloudForms populates the limit parameter on the Job Template in order to target on which host the template should be executed. Additional extra parameters can also be set in CloudForms using a Service Dialog or programmatically (an example is provided under
Datastore / ManageIQ / ConfigurationManagement / AnsibleTower / Operations / StateMachines / Job / launch_ansible_job).
Service Dialogs are automatically generated from CloudForms by clicking on the ‘Create Service Dialog from this Job Template’ button presented for each Job Template.
 

The resulting Service Dialog contains all elements required as input in the Ansible Job Template. This includes the limit as well as all extra parameters in separate elements. It is of course possible to edit the generated Service Dialog to amend or modify any of the fields.
In our case, we simply want to deploy PostgreSQL and a database keeping the default values entered within the Job Templates parameters. We will keep the dialog as generated.
The next step is to create a new button on VMs for our Job Template. Navigate to ‘Automate > Buttons’ and expand the ‘VM and Instance’ object type. Add a new Button Group if required and create a new button by selecting ‘Configuration > Add a new Button’.
Under dialog, make sure you select the previously generated dialog (‘PostgreSQL Deployment Dialog’ in our case). System/Progress is set to ‘Request’, Message to ‘create’ and Request to ‘Ansible_Tower_Job’. The Job Template name is specified as an attribute/value pair under ‘job_template_name’ (in this case, set to the corresponding Ansible Job Template name ‘PostgreSQL Deployment’). Additional values such as dialog_param_postgresql_databases or dialog_param_postgresql_users can be specified to override our default values on the Job Template if required.
 

Save the Button and voila. We have a new Button for our VM allowing us to run our Ansible Job Template to deploy PostgreSQL on the VM using Ansible Tower.
 

These steps can be followed to add additional buttons on the VMs with associated Job Templates.
In this article, we looked at how to configure the launch of an Ansible Template Job on a click of a button from a VM. In the next article, we will explore how to use Ansible Job Templates as Service Items and publish them in the Service Catalog.
Quelle: CloudForms