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!”
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 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”
.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”
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.
Continue reading “Modern web applications on OpenShift: Part 1 — Web apps in two commands”
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”
[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”
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:
- It responds to events by invoking functions
- Functions are loaded and executed on demand
- 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”
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”
2018 has been a busy year already, and we’re not even halfway through. Eclipse Che 6 brought team and enterprise features including multi-user and multi-tenancy as well as a large number of other great capabilities (you can read all about it in our Che 6 release post).
We followed Che 6 GA with already 4 minor releases and the community worked hard in order to add even more capabilities:
- Helm chart for Kubernetes deployment
- C/C++ intellisense with integration of ClangD
- Recover capabilities for OpenShift/Kubernetes
- And almost 150 bug fixes
Continue reading “Eclipse Che’s Plans for 2018”
The community editions of JBoss Tools 4.5.3 and JBoss Developer Studio 11.3 for Eclipse Oxygen.3a are here waiting for you. Check it out!
JBoss Developer Studio comes with everything pre-bundled in its installer. Simply download it from our JBoss Products page and run it like this:
java -jar jboss-devstudio-<installername>.jar
JBoss Tools or Bring-Your-Own-Eclipse (BYOE) JBoss Developer Studio require a bit more:
This release requires at least Eclipse 4.7 (Oxygen) but we recommend using the latest Eclipse 4.7.3a Oxygen JEE Bundle since then you get most of the dependencies preinstalled.
Once you have installed Eclipse, you can either find us on the Eclipse Marketplace under “JBoss Tools” or “Red Hat JBoss Developer Studio”.
For JBoss Tools, you can also use our update site directly.
What is new?
Continue reading “Announcing Developer Studio 11.3.0.GA, JBoss Tools 4.5.3 for Eclipse Oxygen.3a”