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”
The release of Red Hat CodeReady Workspaces 2.0 (CRW) brings changes. Based on Eclipse Che 7 and the Theia online editor, CRW 2.0 frees the developer from the confines of a specially configured PC in favor of multiple specially configured workspaces. Imagine having a separate work environment for each language, version, tools and more, all available from a browser. This article discusses some of the features of CRW.
Continue reading “Managing development environments with Red Hat CodeReady Workspaces 2”
With the exciting advent of CodeReady Workspaces (CRW) 2.0 comes some important changes. Based on the upstream project Eclipse Che 7, CRW brings even more of the “Infrastructure as Code” idea to fruition. Workspaces mimic the environment of a PC, an operating system, programming language support, the tools needed, and an editor. The real power comes by defining a workspace using a YAML file—a text file that can be stored and versioned in a source control system such as Git. This file, called
devfile.yaml, is powerful and complex. This article will attempt to demystify the devfile.
Continue reading “CodeReady Workspaces devfile, demystified”
We are extremely pleased to present the new version of the Red Hat OpenShift deployment extension (OpenShift VSTS) 1.4.0 for Microsoft Azure DevOps. This extension enables users to deploy their applications to any OpenShift cluster directly from their Microsoft Azure DevOps account. In this article, we will look at how to install and use this extension as part of a YAML-defined pipeline with both Microsoft-hosted and self-hosted agents.
Note: The OpenShift VSTS extension can be downloaded directly from the marketplace at this link.
This article offers a demonstration where we explain how easy it is to set up everything and start working with the extension. Look at the README file for further installation and usage information.
Continue reading “Introduction to the Red Hat OpenShift deployment extension for Microsoft Azure DevOps”
We are pleased to announce the release of Red Hat CodeReady Workspaces 2.0. Based on Eclipse Che, its upstream project CodeReady Workspaces is a Red Hat OpenShift-native developer environment enabling cloud-native development for developer teams.
CodeReady Workspaces 2.0 is available now on OpenShift 3.11 and OpenShift 4.x.
This new version introduces:
- Kubernetes-native developer sandboxes on OpenShift: Bring your Kubernetes application into your development environment, allowing you to code, build, test, and run as in production.
- Integrated OpenShift experience: OpenShift plugin and integration into the OpenShift 4 Developer Console.
- New editor and Visual Studio (VS) Code extensions compatibility: New browser-based editor, providing a fast desktop-like experience and compatibility with Visual Studio Code extensions.
- Devfile, developer environment as code: Developer environments are codified with a devfile making them consistent, repeatable, and reproducible.
- Centrally hosted on OpenShift with AirGap: Deploy on your OpenShift cluster, behind your firewall. AirGap capabilities. Easier to monitor and administer.
Continue reading “Red Hat CodeReady Workspaces 2: New tools to speed Kubernetes development”
The latest versions of Red Hat Software Collections and Red Hat Developer Toolset are available now in beta. Red Hat Software Collections 3.4 delivers the latest stable versions of many popular open source runtime languages and databases natively to the world’s leading enterprise Linux platform. These components are supported for up to five years, helping to enable a more consistent, efficient, and reliable developer experience.
Continue reading “Red Hat Software Collections 3.4 and Red Hat Developer Toolset 9 Beta now available”
JBoss Tools 4.13.0 and Red Hat CodeReady Studio 12.13 for Eclipse 2019-09 are here and waiting for you. In this article, I’ll cover the highlights of the new releases and show how to get started.
Continue reading “New features in Red Hat CodeReady Studio 12.13.0.GA and JBoss Tools 4.13.0.Final for Eclipse 2019-09”
Quarkus is, in its own words, “Supersonic subatomic Java” and a “Kubernetes native Java stack tailored for GraalVM & OpenJDK HotSpot, crafted from the best of breed Java libraries and standards.” For the purpose of illustrating how to modernize an existing Java application to Quarkus, I will use the Red Hat JBoss Enterprise Application Platform (JBoss EAP) quickstarts
helloworld quickstart as sample of a Java application builds using technologies (CDI and Servlet 3) supported in Quarkus.
It’s important to note that both Quarkus and JBoss EAP rely on providing developers with tools based—as much as possible—on standards. If your application is not already running on JBoss EAP, there’s no problem. You can migrate it from your current application server to JBoss EAP using the Red Hat Application Migration Toolkit. After that, the final and working modernized version of the code is available in the https://github.com/mrizzi/jboss-eap-quickstarts/tree/quarkus repository inside the
This article is based on the guides Quarkus provides, mainly Creating Your First Application and Building a Native Executable.
Continue reading “Quarkus: Modernize “helloworld” JBoss EAP quickstart, Part 1″
The new release of Red Hat OpenShift 4.2 has many developer-focused improvements. In that context, we have released a new version of OpenShift Connector 0.1.1, a Visual Studio (VS) Code extension with more improved features for a seamless developer experience. Developers can now focus on higher-level abstractions like their application and components and can drill down deeper to get to the OpenShift and Kubernetes resources that make up their application directly from VS Code.
Let’s take a deep tour of the new features with respect to OpenShift Connector.
Continue reading “OpenShift Connector: Visual Studio Code extension for Red Hat OpenShift”
In this article, we’ll cover microservice security concepts by using protocols such as OpenID Connect with the support of Red Hat Single Sign-On and 3scale. Working with a microservice-based architecture, user identity, and access control in a distributed, in-depth form must be carefully designed. Here, the integration of these tools will be detailed, step-by-step, in a realistic view.
This article exemplifies the use of tools that can securely run your businesses, avoiding using homemade solutions, and protecting your services by using an API gateway, preventing your applications from being exposed to the public network. The use of an API gateway also provides additional access control, monetization, and analytics.
Continue reading “How to secure microservices with Red Hat Single Sign-On, Fuse, and 3scale”