Frédéric Giloux

I am a computer engineer, working as a senior middleware consultant at Red Hat, enthusiastic about technologies and free software. You can see my profile on linkedin: https://de.linkedin.com/in/fredericgiloux

Recent Posts

Container Images for OpenShift – Part 4: Cloud readiness

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”

Share

Container Images for OpenShift – Part 3: Making your images consumable

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 third part focuses on how you can make your images easier to consume by application developers or release managers.

Continue reading “Container Images for OpenShift – Part 3: Making your images consumable”

Share

Container Images for OpenShift – Part 2: Structuring your images

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 second part focuses on how you should structure images and group of images to achieve the objectives stated in part one.

Continue reading “Container Images for OpenShift – Part 2: Structuring your images”

Share

Container Images for OpenShift – Part 1: Objectives

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. The content is structured in a series of four posts:

  • Objectives
  • Structuring your images
  • Making your images consumable
  • Cloud readiness

Continue reading “Container Images for OpenShift – Part 1: Objectives”

Share

Troubleshooting Java applications on OpenShift

What is it about?

OpenShift has seen a lot of traction with the release of its third version based on Kubernetes a couple of years ago. More and more companies after a thorough evaluation of OpenShift Container Platform (OCP) have built an on-premise or in the cloud PaaS. With the next step, they have started to run their applications on OCP. One of the important aspects of running applications in production is the capacity of quickly restoring services to the normal service level after an incident followed by the identification and the resolution of the underlying problem. In this respect, I want to present in this blog a few approaches for troubleshooting Java applications running on OpenShift. Similar approaches can be taken with other languages.

Debugging applications during development phase can be done thanks to features like:

  • Debug mode for resolving issues during startup.
  • Port forwarding for connecting an IDE like JBDS to an application running in a remote container and debugging it with breakpoints and object inspection.

This has been presented in blogs like here and here.

In this blog, on the contrary, I want to focus on troubleshooting applications in production and to cover things like capturing heap and thread dumps, resource consumption per thread. These are techniques that have more than once been helpful in the past for resolving deadlocks, memory leaks or performance degradation due to excessive garbage collection for instance.

Let’s get into the heart of the matter!

Continue reading “Troubleshooting Java applications on OpenShift”

Share

Development workflows with Fuse Integration Services (FIS)

Fuse Integration Services (FIS) is a great product bringing routing (Apache Camel), SOAP and Rest services (CXF) and messaging (JMS) to the modern age of containers and PaaS and all its goodies: encapsulation, immutability, scalability and self healing. OpenShift provides the PaaS infrastructure to FIS.

A developer may implement a module in isolation on his own machine, but it often makes sense, especially when we talk about integration services, to have the code being validated in a complex integrated environment — something that OpenShift is great at providing.

It is so easy to spawn an environment including frontend, backend and peer services that you may not want to wait for the integration test phase to see how your code performs and to identify where issues may happen. You want to see it right away, during your dev! This blog entry details a couple of workflows with their pros and cons for just doing that.

Continue reading “Development workflows with Fuse Integration Services (FIS)”

Share

Controlling resources with cgroups for performance testing

Introduction

Today I want to write about the options available to limit resources in use for running performance tests in a shared environment. A very powerful tool for this is cgroups [1] – a Linux kernel feature that allows limiting the resource usage (CPU, memory, disk I/O, etc..) of a collection of processes.
Nowadays it is easy with virtual machines or container technologies, like Docker, which is using cgroups by the way, to compartmentilize applications and make sure that they are not eating resources that have not been allocated to them. But you may face, as I did, situations where these technologies are not available and if your application happens to run on a Linux distribution like RHEL 6 and later you can directly rely on cgroups for this purpose. 

Continue reading “Controlling resources with cgroups for performance testing”

Share