Quarkus, a next-generation Kubernetes native Java framework, was announced in early March, and now Quarkus 0.12.0 has been released and is available from the Maven repository. The quickstarts, guides, and website also have been updated, and 213 issues and PRs are included in this release. That’s quite a few updates, but in particular check out the new metrics, health check, and Kafka guides. Also, this release requires GraalVM 1.0.0-RC13 for Building a Native Executable.
Continue reading “Quarkus 0.12.0 released”
A Java runtime environment should be able to run compiled source code, whereas a development kit, for example, OpenJDK, would include all the libraries/binaries to compile and run the source code. Essentially the latter is a superset of the runtime environment. More details on OpenJDK support and lifecycle can be found here.
Red Hat ships and supports container images with OpenJDK for both Java 8 and 11. More details are here. If you are using Red Hat Middleware, the s2i images shipped are also useful to deploy, for example, on Red Hat Openshift Container Platform.
Note that Red Hat only provides OpenJDK-based Java 8 and 11 images. With that said, there will certainly be situations where developers would like to create their own Java runtime images. For example, there could be reasons such as minimizing storage to run a runtime image. On the other hand, a lot of manual work around libraries such as Jolokio or Hawkular and even security parameters would need to be set up as well. If you’d prefer not to get into those details, I would recommend using the container images for OpenJDK shipped by Red Hat.
In this article we will:
- Build an image with Docker as well as Buildah.
- We will run that image with Docker as well as Podman on localhost.
- We will push our image to Quay.
- Finally, we will run our app by importing a stream into OpenShift.
This article was written for both OpenShift 3.11 and 4.0 beta. Let’s jump right into it.
Continue reading “Creating and deploying a Java 8 runtime container image”
In this article, I discuss containers, but look at them from another angle. We usually refer to containers as the best technology for developing new cloud-native applications and orchestrating them with something like Kubernetes. Looking back at the origins of containers, we’ve mostly forgotten that containers were born for simplifying application distribution on standalone systems.
In this article, we’ll talk about the use of containers as the perfect medium for installing applications and services on a Red Hat Enterprise Linux (RHEL) system. Using containers doesn’t have to be complicated, I’ll show how to run MariaDB, Apache HTTPD, and WordPress in containers, while managing those containers like any other service, through systemd and
Additionally, we’ll explore Podman, which Red Hat has developed jointly with the Fedora community. If you don’t know what Podman is yet, see my previous article, Intro to Podman (Red Hat Enterprise Linux 7.6) and Tom Sweeney’s Containers without daemons: Podman and Buildah available in RHEL 7.6 and RHEL 8 Beta.
Continue reading “Managing containerized system services with Podman”
Red Hat Enterprise Linux (RHEL) 7.6 Beta was released a few days ago and one of the first new features I noticed is Podman. Podman complements Buildah and Skopeo by offering an experience similar to the Docker command line: allowing users to run standalone (non-orchestrated) containers. And Podman doesn’t require a daemon to run containers and pods, so we can easily say goodbye to big fat daemons.
Podman implements almost all the Docker CLI commands (apart from the ones related to Docker Swarm, of course). For container orchestration, I suggest you take a look at Kubernetes and Red Hat OpenShift.
Podman consists of just a single command to run on the command line. There are no daemons in the background doing stuff, and this means that Podman can be integrated into system services through
We’ll cover some real examples that show how easy it can be to transition from the Docker CLI to Podman.
Continue reading “Intro to Podman (Red Hat Enterprise Linux 7.6 Beta)”
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”
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”
The community editions of JBoss Tools 4.5.2 and JBoss Developer Studio 11.2 for Eclipse Oxygen.2 are here waiting for you. Check it out!
Continue reading “Announcing Developer Studio 11.2.0.GA and JBoss Tools 4.5.2.Final for Eclipse Oxygen.2”
In this blog entry, I want to introduce a “different” way to work with OpenShift. In the typical way to deploy a Pod to OpenShift, we have available a set of very useful objects we have build/image configurations. This takes the pain from us by hiding the details about image construction but, sometimes we just want to see some code running in the cloud. Or we want to see if our service/application is able to interact with nearby services or we have some code but we don’t want to use a git repo just yet. To solve that problem, I will show the concept of InitContainers, and how by being a little bit creative we achieve some cool stuff like deploying our code inside a running container.
Continue reading “Accelerating the development of Node.js using OpenShift”
JBoss Tools 4.5.1 and Red Hat JBoss Developer Studio 11.1 for Eclipse Oxygen.1A are here waiting for you. Check it out!
Continue reading “Announcing Red Hat Developer Studio 11.1.0.GA and JBoss Tools 4.5.1.Final for Eclipse Oxygen.1A”
This is a transcript of a session I gave at EMEA Red Hat Tech Exchange 2017, a gathering of all Red Hat solution architects and consultants across EMEA. It is about considerations and good practices when creating images that will run on OpenShift. This fourth and last part focuses on the specific aspects of cloud-ready applications and the consequences concerning the design of the container images.
Continue reading “Container Images for OpenShift – Part 4: Cloud readiness”