Ansible

Write your own Red Hat Ansible Tower inventory plugin

Write your own Red Hat Ansible Tower inventory plugin

Ansible is an engine and language for automating many different IT tasks, such as provisioning a physical device, creating a virtual machine, or configuring an application and its dependencies. Ansible organizes these tasks in playbook files, which run on one or more remote target hosts. Inventory files maintain lists of these hosts and are formatted as YAML or INI documents. For example, a simple inventory file in INI format follows:

Continue reading Write your own Red Hat Ansible Tower inventory plugin

Share
Deliver your applications to edge and IoT devices in rootless containers

Deliver your applications to edge and IoT devices in rootless containers

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.
Image: Systemd + Podman + Ansible.

Continue reading Deliver your applications to edge and IoT devices in rootless containers

Share
WildFly server configuration with Ansible collection for JCliff, Part 2

WildFly server configuration with Ansible collection for JCliff, Part 2

Welcome to the second part of this series introducing Ansible collection for JCliff. This new extension is designed for fine-tuning WildFly or Red Hat JBoss Enterprise Application Platform (JBoss EAP) configurations using Ansible. In Part 1, we installed JCliff and its Ansible collection and prepared our environment. We set up a minimal, working playbook for installing JCliff on the target system. In this article, we will focus on configuring a few of our WildFly server’s subsystems.

Continue reading WildFly server configuration with Ansible collection for JCliff, Part 2

Share
WildFly server configuration with Ansible collection for JCliff, Part 1

WildFly server configuration with Ansible collection for JCliff, Part 1

This three-part series guides you through using Ansible to fine-tune a WildFly or Red Hat JBoss Enterprise Application Platform (JBoss EAP) server configuration. We will use the most recently released version of the Ansible collection for JCliff to extend Ansible’s capabilities. The JCliff collection supports configuring several of the application server subsystems directly from Ansible.

In Part 1, we will mostly focus on the groundwork and discuss all the steps required to be able to use JCliff within Ansible. Once properly installed, we’ll use JCliff to configure WildFly’s system_props subsystem, which lets us declare system variables in WildFly’s server configuration. Once we have that foundation in place, we’ll begin exploring more interesting configurations in Part 2 and Part 3.

Note: See the Ansible documentation for more about Ansible collections.

Continue reading “WildFly server configuration with Ansible collection for JCliff, Part 1”

Share
5 tips for developing Kubernetes Operators with the new Operator SDK

5 tips for developing Kubernetes Operators with the new Operator SDK

Kubernetes Operators are all the rage this season, and the fame is well deserved. Operators are evolving from being used primarily by technical-infrastructure gurus to becoming more mainstream, Kubernetes-native tools for managing complex applications. Kubernetes Operators today are important for cluster administrators and ISV providers, and also for custom applications developed in house. They provide the base for a standardized operational model that is similar to what cloud providers offer. Operators also open the door to fully portable workloads and services on Kubernetes.

The new Kubernetes Operator Framework is an open source toolkit that lets you manage Kubernetes Operators in an effective, automated, and scalable way. The Operator Framework consists of three components: the Operator SDK, the Operator Lifecycle Manager, and OperatorHub. In this article, I introduce tips and tricks for working with the Operator SDK. The Operator SDK 1.0.0 release shipped in mid-August, so it’s a great time to have a look at it.

Continue reading “5 tips for developing Kubernetes Operators with the new Operator SDK”

Share
Automate workshop setup with Ansible playbooks and CodeReady Workspaces

Automate workshop setup with Ansible playbooks and CodeReady Workspaces

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

Share
Using Ansible to automate Google Cloud Platform

Using Ansible to automate Google Cloud Platform

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”

Share
Vault IDs in Red Hat Ansible and Red Hat Ansible Tower

Vault IDs in Red Hat Ansible and Red Hat Ansible Tower

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 DEFAULT_VAULT_IDENTITY_LIST:

Continue reading “Vault IDs in Red Hat Ansible and Red Hat Ansible Tower”

Share