Applications are often developed, tested, and delivered in containers, and Red Hat OpenShift is a great platform for that purpose. Sometimes, however, the target machine is much smaller than a Kubernetes cluster. It might be an embedded server, industry PC hardware, or a single server.
Continue reading Deliver your applications to edge and IoT devices in rootless containers
Welcome to the final installment in this three-part series about using Ansible Collection for JCliff to manage WildFly or Red Hat JBoss Enterprise Application Platform (JBoss EAP) instances. Previously, we’ve discussed installing and configuring the JCliff Ansible collection and using its basic features. In this article, we discuss advanced options available with the project’s latest release. Without further ado, let’s dive in!
Continue reading WildFly server configuration with Ansible collection for JCliff, Part 3
Red Hat Process Automation Manager 7.9 brings bug fixes, performance improvements, and new features for process and case management, business and decision automation, and business optimization. This article introduces you to Process Automation Manager’s out-of-the-box integration with Apache Kafka, revamped business automation management capabilities, and support for multiple decision requirements diagrams (DRDs). I will also guide you through setting up and using the new
drools-metric module for analyzing business rules performance, and I’ll briefly touch on Spring Boot integration in Process Automation Manager 7.9.
Continue reading Red Hat Process Automation Manager 7.9 brings Apache Kafka integration and more
At Red Hat, we do many in-person and virtual workshops for customers, partners, and other open source developers. In most cases, the workshops are of the “bring your own device” variety, so we face a range of hardware and software setups and corporate endpoint-protection schemes, as well as different levels of system knowledge.
Continue reading Automate workshop setup with Ansible playbooks and CodeReady Workspaces
In this article, you will learn how to seamlessly automate the provisioning of Google Cloud Platform (GCP) resources using the new Red Hat Ansible modules and your Red Hat Ansible Tower credentials.
About the new GCP modules
Starting with Ansible 2.6, Red Hat has partnered with Google to ship a new set of modules for automating Google Cloud Platform resource management. The partnership has resulted in more than 100 GCP modules and a consistent naming scheme of
gcp_*. While we still have access to the original modules, developers are recommended to use the newer modules whenever possible.
Continue reading “Using Ansible to automate Google Cloud Platform”
This article demonstrates the use of multiple vault passwords through vault IDs. You will learn how to use vault IDs to encrypt a file and a string. Once they’re encrypted, the vault ID can be referenced inside a playbook and used within Red Hat Ansible and Red Hat Ansible Tower.
Starting with Ansible 2.4 and above, vault IDs are supported
Vault IDs help you encrypt different files with different passwords to be referenced inside a playbook. Before Ansible 2.4, only one vault password could be used in each Ansible playbook. In effect, every file needed to be encrypted using the same vault password.
To begin with, vault IDs need to be pre-created and referenced inside your
ansible.cfg file. The following excerpt is from
ansible-config list for the configuration
Continue reading “Vault IDs in Red Hat Ansible and Red Hat Ansible Tower”
In this article, I will show how to install and manage Red Hat Ansible Tower on Red Hat OpenShift Container Platform. Ansible Tower helps you scale IT automation, manage complex deployments, and improve productivity. You can centralize and control your IT infrastructure with a visual dashboard, and it provides role-based access control, job scheduling, integrated notifications, graphical inventory management, and more.
As you may know, Ansible Tower 3.3, the latest release of this automation platform, was released a few weeks ago and added new features. From the release notes you’ll see that Ansible Tower 3.3 added support for a container-based installation on top of OpenShift
In this blog, we’ll see how easy it is to set up Ansible Tower 3.3 on OpenShift and have it running as a container in just a few minutes.
Continue reading “How to install Ansible Tower on Red Hat OpenShift”
Today I want to talk about Ansible Service Broker and Ansible Playbook Bundle. These components are relatively new in the Red Hat OpenShift ecosystem, but they are now fully supported features available in the Service Catalog component of OpenShift 3.9.
Before getting deep into the technology, I want to give you some basic information (quoted below from the product documentation) about all the components and their features:
- Ansible Service Broker is an implementation of the Open Service Broker API that manages applications defined in Ansible Playbook Bundles.
- Ansible Playbook Bundles (APB) are a method of defining applications via a collection of Ansible Playbooks built into a container with an Ansible runtime with the playbooks corresponding to a type of request specified in the Open Service Broker API specification.
- Playbooks are Ansible’s configuration, deployment, and orchestration language. They can describe a policy you want your remote systems to enforce, or a set of steps in a general IT process.
Continue reading “Customizing an OpenShift Ansible Playbook Bundle”
[In case you aren’t following the OpenShift blog, I’m cross posting my article here because I think it will be of interest to the Red Hat Developer commnity.]
The Open Service Broker API standard aims to standardize how services (cloud, third-party, on-premise, legacy, etc) are delivered to applications running on cloud platforms like OpenShift. This allows applications to consume services the exact same way no matter on which cloud platform they are deployed. The service broker pluggable architecture enables admins to add third-party brokers to the platform in order to make third-party and cloud services available to the application developers directly from the OpenShift service catalog. As an example AWS Service Broker created jointly by Amazon and Red Hat, Azure Service Broker created by Microsoft and Helm Service Broker created by Google to allow consumption of AWS services, Azure services and Helm charts on Kubernetes and OpenShift. Furthermore, admins can create their own brokers in order to make custom services like provisioning an Oracle database on their internal Oracle RAC available to the developers through the service catalog.
Continue reading “Using Ansible Galaxy Roles in Ansible Playbook Bundles”