Using a custom builder image on Red Hat OpenShift with OpenShift Do

Using a custom builder image on Red Hat OpenShift with OpenShift Do

dhelfand
By Daniel Helfand

One of the things I enjoy most about using Red Hat OpenShift is the Developer Catalog. The Developer Catalog is a central location where a team working with Red Hat OpenShift can encapsulate and share how application components and services are deployed.

The Developer Catalog is often used to define an infrastructure pattern referred to as a builder image. A builder image is a container image that supports a particular language or framework, following best practices and Source-to-Image (s2i) specifications.

The OpenShift Developer Catalog provides several standard builder images supporting applications written in Node.js, Ruby, Python, and more. And while the Developer Catalog has many easy ways to get started deploying several supported languages, the catalog is also flexible in allowing you to add your own builder images to support an infrastructure pattern that is not preloaded in the catalog.

Continue reading “Using a custom builder image on Red Hat OpenShift with OpenShift Do”

Share
Deploying an internal container registry with Minikube add-ons

Deploying an internal container registry with Minikube add-ons

kameshsampath
By Kamesh Sampath

Minikube has a feature called add-ons, which help in adding extra components and features to Minikube’s Kubernetes cluster.

The registry add-on will deploy an internal registry, which can then be used to push and pull Linux container images. But at times, we might wish to mimic push and pull to different registries (i.e., using aliases for container registry). In this article, I will walk you through the steps required to achieve the same.

Continue reading “Deploying an internal container registry with Minikube add-ons”

Share
Developer preview of Debezium Apache Kafka connectors for Change Data Capture (CDC)

Developer preview of Debezium Apache Kafka connectors for Change Data Capture (CDC)

hguerrero
By Hugo Guerrero

With the release of Red Hat AMQ Streams 1.2, Red Hat Integration now includes a developer preview of Change Data Capture (CDC) capabilities to enable data integration for modern cloud-native microservices-based applications. CDC features are based on the upstream project Debezium and are natively integrated with Apache Kafka and Strimzi to run on top of Red Hat OpenShift Container Platform, the enterprise Kubernetes, as part of the AMQ Streams release.

Continue reading “Developer preview of Debezium Apache Kafka connectors for Change Data Capture (CDC)”

Share
API-first design with OpenAPI and Red Hat Fuse

API-first design with OpenAPI and Red Hat Fuse

jborella
By Jacob Borella

API-first design is a commonly used approach where you define the interfaces for your application before providing an actual implementation. This approach gives you a lot of benefits. For example, you can test whether your API has the right structure before investing a lot of time implementing it, and you can share your ideas with other teams early to get valuable feedback. Later in the process, delays in the back-end development will not affect front-end developers dependent on your service so much, because it’s easy to create mock implementations of a service from the API definition.

Much has been written about the benefits of API-first design, so this article will instead focus on how to efficiently take an OpenAPI definition and bring it into code with Red Hat Fuse.

Continue reading “API-first design with OpenAPI and Red Hat Fuse”

Share
10 tips for reviewing code you don�t like

10 tips for reviewing code you don’t like

dlloyd
By David Lloyd

As a frequent contributor to open source projects (both within and beyond Red Hat), I find one of the most common time-wasters is dealing with code reviews of my submitted code that are negative or obstructive and yet essentially subjective or argumentative in nature. I see this most often when submitting to projects where the maintainer doesn’t like the change, for whatever reason. In the best case, this kind of code review strategy can lead to time wasted in pointless debates; at worst, it actively discourages contribution and diversity in a project and creates an environment that is hostile and elitist.

A code review should be objective and concise and should deal in certainties whenever possible. It’s not a political or emotional argument; it’s a technical one, and the goal should always be to move forward and elevate the project and its participants.  A change submission should always be evaluated on the merits of the submission, not on one’s opinion of the submitter.

Continue reading “10 tips for reviewing code you don’t like”

Share
Announcing Red Hat AMQ streams 1.2 with Apache Kafka 2.2 support

Announcing Red Hat AMQ streams 1.2 with Apache Kafka 2.2 support

hguerrero
By Hugo Guerrero

We are thrilled to announce an updated release of the data streaming component of our messaging suite, Red Hat AMQ streams 1.2, which is part of Red Hat integration.

Red Hat AMQ streams, based on the Apache Kafka project, offers a distributed backbone that allows microservices and other applications to share data with extremely high throughput and extremely low latency. AMQ streams makes running and managing Apache Kafka a Kubernetes-native experience, by additionally delivering Red Hat OpenShift Operators, a simplified and automated way to deploy, manage, upgrade and configure a Kafka ecosystem installation on Kubernetes.

Continue reading “Announcing Red Hat AMQ streams 1.2 with Apache Kafka 2.2 support”

Share