Red Hat OpenShift

Modern Web Applications on OpenShift: Part 1 – Web apps in two commands

lholmqui
By Lucas Holmquist

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.

This first post will cover how to deploy modern web apps using the fewest steps.

The next post will show how to combine this new S2I image with a current HTTP server image, like NGINX, using an OpenShift chained build for a more production-ready deployment.

The last post will show how to run your app’s development server on OpenShift while syncing with your local file system.

Continue reading “Modern Web Applications on OpenShift: Part 1 – Web apps in two commands”

Share

Customizing an OpenShift Ansible Playbook Bundle

aarrichi
By Alessandro Arrichiello

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

ssadeghi
By Siamak Sadeghianfar

[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
Signage for the Red Hat Summit at Moscone West in San Francisco

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

dtidwell
By Doug Tidwell

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
Moscone West graced with the Shadowman logo

Red Hat Summit: Containers, Microservices, and Serverless Computing

dtidwell
By Doug Tidwell

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

Eclipse Che’s Plans for 2018

slemeur
By Stevan LeMeur

 

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”

Share

Announcing Developer Studio 11.3.0.GA, JBoss Tools 4.5.3 for Eclipse Oxygen.3a

jmauryredhat-com
By Jeff Maury

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!

Installation

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.

http://download.jboss.org/jbosstools/oxygen/stable/updates/

What is new?

Continue reading “Announcing Developer Studio 11.3.0.GA, JBoss Tools 4.5.3 for Eclipse Oxygen.3a”

Share

State of Functions-as-a-Service on Kubernetes (OpenShift Commons Briefing)

rctkv
By Rob Terzi

If you are interested in serverless computing / Functions-as-a-Service (FaaS), and are not following the OpenShift blog, you should checkout The State of Functions-as-a-Service on Kubernetes.  This video is part of the OpenShift Commons Briefing series, which has a lot of great content for developers who interested in cloud-native applications and microservices running on OpenShift and Kubernetes.

FaaS, or serverless as some call it, is a promising compute paradigm suitable for event-driven scenarios. In this briefing, Red Hat’s Michael Hausenblas and Brian Gracely reviewed the current open source offerings for FaaS on Kubernetes (Apache Open Whisk, kubeless, OpenFaaS, etc.) and discussed the pros and cons, on an architectural level and a user experience (UX) point of view. They also covered the topic FaaS vs. containers from a developers as well as an operators perspective.

This talk builds on material gathered by the Serverless Working Group , which is part of the Cloud Native Computing Foundation (CNCF). CNCF serves as the vendor-neutral home for many of the fastest-growing projects on GitHub, including Kubernetes, Prometheus, and Envoy.

Video, slides, and other resources:

Continue reading “State of Functions-as-a-Service on Kubernetes (OpenShift Commons Briefing)”

Share

Bringing Coolstore Microservices to the Service Mesh: Part 2–Manual Injection

jamesfalkner0
By James Falkner

Coolstore+Istio Logo

In the first part of this series we explored the Istio project and how Red Hat is committed to and actively involved in the project and working to integrate it into Kubernetes and OpenShift to bring the benefits of a service mesh to our customers and the wider communities involved. If you want to play with Istio, check out the service mesh tutorials on learn.openshift.com. If you want to install it, follow the Istio Kubernetes quickstart instructions and install it on OpenShift 3.7 or later. Also don’t miss Don Schenck’s series of blogs on Istio technology in general to learn more about it and what Red Hat is doing in this space.

In this post, we will deploy the existing Coolstore microservices demo as a service mesh and start to demonstrate the tangible value you can get out of the system without any major rewrite or rearchitecture of the existing app. We’ll also improve our project along the way to adhere to Istio (and general microservice) best practices. In the real world, your applications and developers often make bad assumptions or fail to implement best practices, so with this information you can learn something about your own projects. For Coolstore, many of these workarounds will eventually find their way into the source code of the demo.

Continue reading “Bringing Coolstore Microservices to the Service Mesh: Part 2–Manual Injection”

Share