The Red Hat Integration Q4 release adds many new features and capabilities with an increasing focus around cloud-native data integration. The features I’m most excited about are the introduction of the schema registry, the advancement of change data capture capabilities based on Debezium to technical preview, and data virtualization (technical preview) capabilities.
Data integration is a topic that has not received much attention from the cloud-native community so far, and we will cover it in more detail in future posts. Here, we jump straight into demonstrating the latest release of data virtualization (DV) capabilities on Red Hat OpenShift 4. This is a step-by-step visual tutorial describing how to create a simple virtual database using Red Hat Integration’s data virtualization Operator. By the end of the tutorial, you will learn:
- How to deploy the DV Operator.
- How to create a virtual database.
- How to access the virtual database.
The steps throughout this article work on any Openshift 4.x environment with operator support, even on time- and resource-constrained environments such as the Red Hat OpenShift Interactive Learning Portal.
Continue reading “First steps with the data virtualization Operator for Red Hat OpenShift”
The developer experience is significantly improved in the Red Hat OpenShift 4.3 web console. If you have used the Developer perspective, which was introduced in OpenShift 4.2 Console, you are probably familiar with our streamlined user flows for deploying applications, the new Topology view, and the enhanced experience around OpenShift Pipelines powered by Tekton and OpenShift Serverless powered by Knative. This release continues to improve upon the features that were introduced in 4.2 and introduces new flows and features for the developer.
Continue reading What’s new in the OpenShift 4.3 console developer experience
A previous article, Debugging applications within Red Hat OpenShift containers, gives an overview of tools for debugging applications within Red Hat OpenShift containers, and existing restrictions on their use. One of the restrictions discussed in that article was an inability to install debugging tool packages into an ordinary, unprivileged container once it was already instantiated. In such a container, debugging tool packages have to be included when the container image is built, because once the container is instantiated, using package installation commands requires elevated privileges that are not available to the ordinary container user.
However, there are important situations where it is desirable to install a debugging tool into an already-instantiated container. In particular, if the resolution of a problem requires access to the temporary state of a long-running containerized application, the usual method of adding debugging tools to the container by rebuilding the container image and restarting the application will destroy that temporary state.
To provide a way to add debugging tools to unprivileged containers, I developed a utility, called
oc-inject, that can temporarily copy a debugging tool into a container. Instead of relying on package management or other privileged operations,
oc-inject’s implementation is based on the existing and well-supported OpenShift operations
oc rsync and
oc exec, which do not require any elevated privileges.
This article describes the current capabilities of the
oc-inject utility, which is available on GitHub or via a Fedora COPR repository. The
oc-inject utility works on any Linux system that includes Python 3, the
ldd utility, and the Red Hat OpenShift command-line tool
Continue reading “Installing debugging tools into a Red Hat OpenShift container with oc-inject”
When debugging an application within a Red Hat OpenShift container, it is important to keep in mind that the Linux environment within the container is subject to various constraints. Because of these constraints, the full functionality of debugging tools might not be available:
- An unprivileged OpenShift container is restricted from accessing kernel interfaces that are required by some low-level debugging tools.
Note: Almost all applications on OpenShift run in unprivileged containers. Unprivileged containers allow the use of standard debugging tools such as
strace. Examples of debugging tools that cannot be used in unprivileged containers include
perf, which requires access to the kernel’s
perf_events interface, and SystemTap, which depends on the kernel’s module-loading functionality.
- Debug information for system packages within OpenShift containers is not accessible. There is ongoing work (as part of the elfutils project) to develop a file server for debug information (
debuginfod), which would make such access possible.
- The set of packages in an OpenShift container is fixed ahead of time, when the corresponding container image is built. Once a container is running, no additional packages can be installed. A few debugging tools are preinstalled in commonly used container base images, but any other tools must be added when the container image build process is configured.
To successfully debug a containerized application, it is necessary to understand these constraints and how they determine which debugging tools can be used.
Continue reading “Debugging applications within Red Hat OpenShift containers”
DevNation tech talks are hosted by the Red Hat technologists who create our products. These sessions include real solutions and code and sample projects to help you get started. In this talk, you’ll learn about testing in production from Alex Soto, Red Hat Software Engineer.
DevOps has grown in popularity in recent years, particularly in software companies that want to reduce lead time to be measured in days/weeks instead of months/years. To make sure your software does the right things and does those things right, you need to test it implacably. Many companies, however, see the testing phase as a bottleneck that slows product release. To change that, we need a new approach — making the release process of an application a testing process and involving QA from the beginning.
In this presentation, we will actively demonstrate several techniques that you can use immediately to start testing in production and speeding up your release cycle.
Continue reading “Testing in production: From DevTestOops to DevTestOps”
The most effective strategies for scaling DevOps and fostering productivity include easy-to-use tools and solutions that create community, according to the 2019 Accelerate State of DevOps Report.
Continue reading Easy-to-use tools are key to CI/CD success says 2019 State of DevOps Report
A couple weeks ago I was faced with the challenge of installing Red Hat 3scale and configuring its tenants using solely the command line — no GUI allowed. This is a rather interesting use case, so I decided to write this article and show how to do it with just seven commands!
(By the way, I also decided to include Red Hat Single Sign-On (SSO) in the mix because I want my APIs to use OpenID Connect (OIDC) for authentication. But I’ll leave those commands to a future article.)
Continue reading “Install Red Hat 3scale and configure tenants with 7 simple commands”
When I talk about desired outcomes or answer a question about where to get started with any part of a DevOps initiative, I like to mention NASCAR or Formula 1 racing. Crew chiefs for these race teams have a goal: finish in the best place possible with the resources available while overcoming the adversity thrown at you. If the team feels capable, the goal gets moved up a series of levels to holding a trophy at the end of the race.
To achieve their goals, race teams don’t think from start to finish; they flip the table to look at the race from the end goal to the beginning. They set a goal, a stretch goal, and then work backward from that goal to determine how to get there. Work is delegated to team members to push toward the objectives that will get the team to the desired outcome.
Continue reading “How DevOps is like auto racing”
In this article, I demonstrate a systematic method to configure LDAP user and group synchronization in Red Hat OpenShift, as well as OpenShift role-based access control (RBAC) for these LDAP users and groups. Following these steps makes the management of your LDAP users and groups within OpenShift much easier. I achieve this goal by demonstrating:
- How to validate your
ldap parameters with
ldaptool prior to installing OpenShift.
- How to enable LDAP authentication in OpenShift for specific LDAP groups and organization units.
- The scripts and commands that let you synchronize members of your LDAP groups to OpenShift, which in turn lets you apply custom OpenShift RBAC rules on specific users or groups.
Continue reading “How to configure LDAP user authentication and RBAC in Red Hat OpenShift 3.11”
In the previous article of this series, Deploy your API from a Jenkins Pipeline, we discovered how the 3scale toolbox can help you deploy your API from a Jenkins Pipeline on Red Hat OpenShift/Kubernetes. In this article, we will improve the pipeline from the previous article to make it more robust, less verbose, and also offer more features by using the 3scale toolbox Jenkins Shared Library.
Continue reading “Using the 3scale toolbox Jenkins Shared Library”