Red Hat OpenShift

OpenShift 4.0 Developer Preview on AWS is up and running

OpenShift 4.0 Developer Preview on AWS is up and running

The OpenShift 4.0 Developer Preview is available for Amazon Web Services (AWS), and if you’re anything like me, you want to be among the first to get your hands on it.

The starting point is try.openshift.com, where you’ll find overview information and that important “Get Started” button. Click it and you’re off to the big show.

Continue reading “OpenShift 4.0 Developer Preview on AWS is up and running”

Share
Node.js for Red Hat OpenShift Application Runtimes wins a Devie award

Node.js for Red Hat OpenShift Application Runtimes wins a Devie award

For the past year and a half or so, Red Hat Middleware has provided a supported Node.js runtime on OpenShift as part of Red Hat OpenShift Application Runtimes (RHOAR). Our goal has been to provide rapid releases within a week or two of the upstream Node.js core project, booster applications to get developers up and running quickly, and, of course, provide world-class service and support for customers.

This past week at the DeveloperWeek 2019 conference in San Francisco, that focus and dedication paid off as Red Hat was awarded a “Devie” award in the category of “Code Frameworks and Libraries.” I couldn’t have been more thrilled to accept the award on behalf of our team.

Continue reading “Node.js for Red Hat OpenShift Application Runtimes wins a Devie award”

Share
Extending support to Spring Boot 2.x for Red Hat OpenShift Application Runtimes

Extending support to Spring Boot 2.x for Red Hat OpenShift Application Runtimes

What Red Hat is providing

Red Hat OpenShift Application Runtimes (RHOAR) is a recommended set of products, tools, and components for developing and maintaining cloud-native applications on the Red Hat OpenShift platform. As part of this offering, Red Hat is extending its support to Spring Boot 2 and related frameworks for building modern, production-grade, Java-based cloud-native applications.

Spring Boot lets you create opinionated Spring-based standalone applications. The Spring Boot runtime also integrates with the OpenShift platform, allowing your services to externalize their configuration, implement health checks, provide resiliency and failover, and much more. To learn more about how Spring Boot applications integrate with the wider Red Hat portfolio, check out the following OpenShift Commons Briefing by Thomas Qvarnstrom:

Continue reading “Extending support to Spring Boot 2.x for Red Hat OpenShift Application Runtimes”

Share
Using sidecars to analyze and debug network traffic in OpenShift and Kubernetes pods

Using sidecars to analyze and debug network traffic in OpenShift and Kubernetes pods

In the world of distributed computing, containers, and microservices, a lot of the interactions and communication between services is done via RESTful APIs. While developing these APIs and interactions between services, I often have the need to debug the communication between services, especially when things don’t seem to work as expected.

Before the world of containers, I would simply deploy my services on my local machine, start up Wireshark, execute my tests, and analyze the HTTP communication between my services. This for me has always been an easy and effective way to quickly analyze communication problems in my software. However, this method of debugging does not work well in a containerized world.

First of all, the containers most likely run on an internal container platform network that is not directly accessible by your machine. A second problem is that, in compliance with container design best practices, containers contain only the minimal set of applications and libraries needed to execute their task. This means that a tool like tcpdump is usually not available in a container. This makes debugging and analyzing network traffic between containers and, thus, debugging of inter-microservice communication a bit harder than in the non-containerized world. This article shows one solution.

Continue reading “Using sidecars to analyze and debug network traffic in OpenShift and Kubernetes pods”

Share
Creating and deploying a Java 8 runtime container image

Creating and deploying a Java 8 runtime container image

A Java runtime environment should be able to run compiled source code, whereas a development kit, for example, OpenJDK, would include all the libraries/binaries to compile and run the source code. Essentially the latter is a superset of the runtime environment. More details on OpenJDK support and lifecycle can be found here.

Red Hat ships and supports container images with OpenJDK for both Java 8 and 11. More details are here. If you are using Red Hat Middleware, the s2i images shipped are also useful to deploy, for example, on Red Hat Openshift Container Platform.

Note that Red Hat only provides OpenJDK-based Java 8 and 11 images. With that said, there will certainly be situations where developers would like to create their own Java runtime images. For example, there could be reasons such as minimizing storage to run a runtime image. On the other hand, a lot of manual work around libraries such as Jolokio or Hawkular and even security parameters would need to be set up as well. If you’d prefer not to get into those details, I would recommend using the container images for OpenJDK shipped by Red Hat.

In this article we will:

  • Build an image with Docker as well as Buildah.
  • We will run that image with Docker as well as Podman on localhost.
  • We will push our image to Quay.
  • Finally, we will run our app by importing a stream into OpenShift.

This article was written for both OpenShift 3.11 and 4.0 beta. Let’s jump right into it.

Continue reading “Creating and deploying a Java 8 runtime container image”

Share
Announcing Kubernetes-native self-service messaging with Red Hat AMQ Online

Announcing Kubernetes-native self-service messaging with Red Hat AMQ Online

Microservices architecture is taking over software development discussions everywhere. More and more companies are adapting to develop microservices as the core of their new systems. However, when going beyond the “microservices 101” googled tutorial, required services communications become more and more complex. Scalable, distributed systems, container-native microservices, and serverless functions benefit from decoupled communications to access other dependent services. Asynchronous (non-blocking) direct or brokered interaction is usually referred to as messaging.

Continue reading “Announcing Kubernetes-native self-service messaging with Red Hat AMQ Online”

Share
Effortless API creation with full API lifecycle using Red Hat Integration (Part 1)

Effortless API creation with full API lifecycle using Red Hat Integration (Part 1)

Nowadays, API development with proper lifecycle management often takes days if not weeks to get a simple API service up and running. One of the main reasons behind this is there are always way too many parties involved in the process. Plus there are hours of development and configuration.

First, the system analysts negotiate the API interface with the API consumer; then the developer writes the actual API to implement the interface. They then pass the API on to the DevOps team that is in charge of deploying the API. And it is not done yet; then the deployment info needs to be passed to the operations team that is in charge of setting up the API endpoints in the management system and also applying the access policies.

The speed of providing managed API services can be one of the major factors in the success of a company’s business.

This article, which is the first in a series of three articles, describes how the new Red Hat Integration bundle allows citizen integrators to quickly provide an API through tools that make creating an API in five simple steps effortless.

Continue reading “Effortless API creation with full API lifecycle using Red Hat Integration (Part 1)”

Share
Using a public certificate with Red Hat Single Sign-On/Keycloak

Using a public certificate with Red Hat Single Sign-On/Keycloak

When deploying Red Hat Single Sign-On/Keycloak for a test or a proof of concept, most users will choose to use a self-signed certificate as explained in the official documentation.

The setup instructions are straightforward, but this self-signed certificate will trigger certificate error messages in your web browser and can also prevent some clients such as Postman from working properly.

This article explains how to use a public certificate from Let’s Encrypt with Red Hat Single Sign-On.

Continue reading “Using a public certificate with Red Hat Single Sign-On/Keycloak”

Share
Curse you choices! Kubernetes or Application Servers? (Part 3)

Curse you choices! Kubernetes or Application Servers? (Part 3)

This is the finale of a series on whether Kubernetes is the new Application Server. In this part I discuss the choice between Kubernetes, a traditional application server, and alternatives.  Such alternatives can be referred to as “Just enough Application Server”, like Thorntail. There are several articles on Thorntail (previously known as Wildfly Swarm) on the Red Hat Developer blog. A good introduction to Thorntail is in the 2.2 product announcement.

Continue reading Curse you choices! Kubernetes or Application Servers? (Part 3)

Share