OpenShift Enterprise by Red Hat

Announcing odo: Developer-focused CLI for Red Hat OpenShift

Announcing odo: Developer-focused CLI for Red Hat OpenShift

Following the first announcement of odo earlier in the year, we are pleased to announce the beta release of odo, an official project hosted on the OpenShift GitHub repository. After months of hard work, the beta release indicates that the API is stable and that functionality going forward will not change.

OpenShift Do (odo, for short) is a fast and straightforward CLI for developers who write, build, and iterate constantly on their source code. Instead of using more-refined tools such as oc, odo focuses on the iterative inner-loop cycle of coding (iterating on code changes prior to committing to Git) rather than the management of each application deployed to OpenShift. This article provides an overview of odo’s functionality.

Continue reading “Announcing odo: Developer-focused CLI for Red Hat OpenShift”

Share
From zero to Quarkus and Knative: The easy way

From zero to Quarkus and Knative: The easy way

You’ve probably already read about Quarkus, but you may not know that the superfast startup speed of Quarkus makes it the best candidate for working with Knative and serverless for your Function-as-a-Service (FaaS) projects.

Quarkus, also known as Supersonic, Subatomic Java, is a Kubernetes native Java stack tailored for GraalVM and OpenJDK HotSpot, crafted from the best-of-breed Java libraries and standards. Knative is a Kubernetes-based platform to build, deploy, and manage modern serverless workloads. You can learn more in this article series.

This article does not provide a full deep dive on Knative or Quarkus. Instead, I aim to give you a quick and easy way to start playing with both technologies so you can further explore on your own.

Continue reading “From zero to Quarkus and Knative: The easy way”

Share
Red Hat Single Sign-On: Give it a try for no cost!

Red Hat Single Sign-On: Give it a try for no cost!

In a software world where each day is more hostile than the previous one, security matters and developers are coping with more and more non-functional requirements about security. The most common ones are the “OWASP Top 10”: the ten security risks that every developer should know. There are many more security risks you should care about, but those ten risks are the ones having the most impact on the security of your software. Among them are authentication and access control.

The good news is that authentication and access control are now commodities in the open source world, thanks to Red Hat Single Sign-On Red Hat Single Sign-On is an access management tool that takes care of the details of most authentication protocols such as SAML, OAuth, and OpenID Connect; user consent with UMA; and even access control. It is easy to use, is very well-documented, and has a very active community: Keycloak.

This article describes how to download and install Red Hat Single Sign-On for no cost.

Continue reading “Red Hat Single Sign-On: Give it a try for no cost!”

Share
Monitoring Node.js Applications on OpenShift with Prometheus

Monitoring Node.js Applications on OpenShift with Prometheus

Observability is Key

One of the great things about Node.js is how well it performs in a container. Its fast start up time, and relatively small size make it a favorite for microservice applications on OpenShift. But with this shift to containerized deployments comes some complexity. As a result, monitoring Node.js applications can be difficult. At times it seems as though the performance and behavior of our applications become opaque to us. So what can we do to find and address issues in our services before they become a problem? We need to enhance observability by monitoring the state of our services.

Instrumentation

Instrumentation of our applications is one way to increase observability. Therefore, in this article, I will demonstrate the instrumentation of a Node.js application using Prometheus.

Continue reading “Monitoring Node.js Applications on OpenShift with Prometheus”

Share
Using Kubernetes readiness and liveness probes for health checks with ASP.NET Core 2.2 on OpenShift

Using Kubernetes readiness and liveness probes for health checks with ASP.NET Core 2.2 on OpenShift

.NET Core 2.2 has been released. You can try it on Red Hat Enterprise Linux (RHEL) and OpenShift. One of the new features of ASP.NET Core is the Health Checks API.

In this article, which was written for C# Advent Calendar 2018, I show an example of how the API works with OpenShift by implementing two health checks for the Kubernetes liveness and readiness probes. Since OpenShift includes Kubernetes, this example also works well with Kubernetes.

Continue reading “Using Kubernetes readiness and liveness probes for health checks with ASP.NET Core 2.2 on OpenShift”

Share
Modern web applications on OpenShift: Part 1 — Web apps in two commands

Modern web applications on OpenShift: Part 1 — Web apps in two commands

In this multi-part series, we will take a look at how to deploy modern web applications, like React and Angular apps, to Red Hat OpenShift using a new source-to-image (S2I) builder image.

Series overview:

Continue reading “Modern web applications on OpenShift: Part 1 — Web apps in two commands”

Share
Customizing an OpenShift Ansible Playbook Bundle

Customizing an OpenShift Ansible Playbook Bundle

Today I want to talk about Ansible Service Broker and Ansible Playbook Bundle. These components are relatively new in the Red Hat OpenShift ecosystem, but they are now fully supported features available in the Service Catalog component of OpenShift 3.9.

Before getting deep into the technology, I want to give you some basic information (quoted below from the product documentation) about all the components and their features:

  • Ansible Service Broker is an implementation of the Open Service Broker API that manages applications defined in Ansible Playbook Bundles.
  • Ansible Playbook Bundles (APB) are a method of defining applications via a collection of Ansible Playbooks built into a container with an Ansible runtime with the playbooks corresponding to a type of request specified in the Open Service Broker API specification.
  • Playbooks are Ansible’s configuration, deployment, and orchestration language. They can describe a policy you want your remote systems to enforce, or a set of steps in a general IT process.

Continue reading “Customizing an OpenShift Ansible Playbook Bundle”

Share
Using Ansible Galaxy Roles in Ansible Playbook Bundles

Using Ansible Galaxy Roles in Ansible Playbook Bundles

[In case you aren’t following the OpenShift blog, I’m cross posting my article here because I think it will be of interest to the Red Hat Developer commnity.]

The Open Service Broker API standard aims to standardize how services (cloud, third-party, on-premise, legacy, etc) are delivered to applications running on cloud platforms like OpenShift. This allows applications to consume services the exact same way no matter on which cloud platform they are deployed. The service broker pluggable architecture enables admins to add third-party brokers to the platform in order to make third-party and cloud services available to the application developers directly from the OpenShift service catalog. As an example AWS Service Broker created jointly by Amazon and Red Hat, Azure Service Broker created by Microsoft and Helm Service Broker created by Google to allow consumption of AWS services, Azure services and Helm charts on Kubernetes and OpenShift. Furthermore, admins can create their own brokers in order to make custom services like provisioning an Oracle database on their internal Oracle RAC available to the developers through the service catalog.

Continue reading “Using Ansible Galaxy Roles in Ansible Playbook Bundles”

Share
Red Hat Summit: Functions as a Service with OpenWhisk and OpenShift

Red Hat Summit: Functions as a Service with OpenWhisk and OpenShift

Serverless computing (often called Functions-as-a-Service, or FaaS) is one of the hottest emerging technologies today. The OpenWhisk project, currently in incubation at Apache, is an open-source implementation of FaaS that lets you create functions that are invoked in response to events. Our own Brendan McAdams gave a presentation and demo that explained the basics of serverless, how the OpenWhisk project works, and how to run OpenWhisk in OpenShift.

Brendan outlined the three properties of a serverless / FaaS platform:

  1. It responds to events by invoking functions
  2. Functions are loaded and executed on demand
  3. Functions can be chained together with triggered events from outside the FaaS platform itself.

Continue reading “Red Hat Summit: Functions as a Service with OpenWhisk and OpenShift”

Share
Red Hat Summit: Containers, Microservices, and Serverless Computing

Red Hat Summit: Containers, Microservices, and Serverless Computing

You’re in an IT department. How does the rest of the organization see you? As a valuable asset whose code and APIs make a difference in the marketplace, or as a necessary evil that should be trimmed as much as possible? Containers, microservices, and serverless computing can make you more responsive, flexible, and competitive, which in turn makes your organization more effective. And that puts you solidly in the asset column.

After sprinting through the streets of San Francisco from the stage of the opening keynote at Red Hat Summit 2018 (replay available here), Burr Sutter hosted a packed house in Moscone South to talk about these technologies. Containers are widely accepted (see the announcement from Red Hat and Microsoft for an example), microservices are increasingly popular as an approach to modernizing monolithic applications, and serverless computing is emerging as an important new programming model.

Continue reading “Red Hat Summit: Containers, Microservices, and Serverless Computing”

Share