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”
Without proper testing, we should not ship any container. We should guarantee that a given service in a container works properly. Meta Test Family (MTF) was designed for this very purpose.
Containers can be tested as “standalone” containers and as “orchestrated” containers. Let’s look at how to test containers with the Red Hat OpenShift environment. This article describes how to do that and what actions are needed.
MTF is a minimalistic library built on the existing Avocado and behave testing frameworks, assisting developers in quickly enabling test automation and requirements. MTF adds basic support and abstraction for testing various module artifact types: RPM-based, Docker images, and more. For detailed information about the framework and how to use it check out the MTF documentation.
Continue reading “Container Testing in OpenShift with Meta Test Family”
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”
Recently, I wrote a post called Zero to Express on OpenShift in Three Commands, which shows how to get started using Node.js, Express, and OpenShift together as fast as possible using the Node.js s2i (source-to-image) images that were recently released as part of Red Hat OpenShift Application Runtimes (RHOAR).
This post will add to the last one and show how we can start to debug and inspect our running code using the Chrome Developer Tools (DevTools) inspector.
Continue reading “How to Debug Your Node.js Application on OpenShift with Chrome DevTools”
At Red Hat Summit 2018, Red Hat’s John Osborne and Microsoft’s Harold Wong gave a talk: Developing .NET Core Applications on Red Hat OpenShift.
.NET Core 1.0 availability for Linux was announced two years ago, but many developers still have a number of questions about the differences between .NET Framework and .NET Core. The session started with an overview of the differences. In a nutshell, .NET Framework is the set of APIs and libraries that Windows developers have used to years, which is pretty heavily tied to Microsoft Windows and Windows GUI APIs. On the other hand, .NET Core is the cross-platform set of APIs that are available for building applications that can run on Linux, macOS, or mobile devices via Xamarin. .Net Core 2.0 was released last August; see Don Schenck’s article.
One of the key questions is when to use one versus the other. Here’s the summary Harold Wong presented:
Continue reading “Red Hat Summit: Developing .NET Core Apps on Red Hat OpenShift”
[Cross posted from the OpenShift blog]
About a year ago Red Hat announced its participation as a launch partner of the Istio project, a service mesh technology that creates an application focused network that transparently protects the applications from abnormalities in environments. The main goals of Istio are enhancing overall application security and availability through many different capabilities such as intelligent routing, circuit breaking, mutual TLS, rating, and limiting among others. Ultimately Istio is about helping organizations develop and deploy resilient, secure applications and services using advanced design and deployment patterns that are baked into the platform.
As part of our investments in making the technology easily consumable to Kubernetes and OpenShift users, Red Hat has created a ton of content:
- learn.openshift.com: A web-based OpenShift and Kubernetes learning environment where users get to interact through the web browser with a real running instance of OpenShift and Istio service mesh with zero install time and no sign-up required.
- Istio tutorial: Want to try the web-based scenario yourself from scratch? This Git repo contains instructions on how to set up an environment for yourself.
- Introducing Istio Service Mesh for Microservices book by Christian Posta and Burr Sutter
- Blog posts on the OpenShift and Red Hat Developer blogs
Continue reading “Getting Started with Istio and Jaeger on Your Laptop”
We are excited to announce a Developer Preview of Red Hat AMQ Streams, a new addition to Red Hat AMQ, focused on running Apache Kafka on OpenShift.
Apache Kafka is a leading real-time, distributed messaging platform for building data pipelines and streaming applications.
Using Kafka, applications can:
- Publish and subscribe to streams of records.
- Store streams of records.
- Process records as they occur.
Continue reading “Announcing AMQ Streams: Apache Kafka on OpenShift”
The past nine weeks of blog posts have introduced, explained, and demonstrated some of the many features of the Istio service mesh when combined it is with Red Hat OpenShift and Kubernetes. This, the final post in this series, is a recap.
[This is part ten of my ten-part Introduction to Istio series. My previous article was Part 9: Istio Egress: Exit Through the Gift Shop.]
Week one was an introduction to the concept of a service mesh. The concept of a Kubernetes sidecar container was explained and diagrammed, and it was the beginning of a constant theme throughout the blog posts: You don’t have to change your source code.
Continue reading “Istio Service Mesh Blog Series Recap”
In this article, I will show how you can implement a common use case that often happens when you migrate a classic Java EE application into a Red Hat OpenShift environment.
Usually a classic Java EE application stores a user’s information, such the profile’s configuration, in the HTTP session. In a typical production scenario, there are several application server instances that build a cluster and are used to implement high availability, failover, and load balancing. To make sure that stateful information is preserved across the application server instances, you must distribute your session as described in the Java EE 7 specification section EE.6.4, “Servlet 3.1 Requirements.”
Continue reading “Externalized HTTP Session in an OpenShift 3.9 Environment”