Programming Languages

How to Debug Your Node.js Application on OpenShift with Chrome DevTools

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”

Share

Making the Operation of Code More Transparent and Obvious

You can study source code and manually instrument functions as described in the “Use the dynamic tracing tools, Luke” blog article, but why not make it easier to find key points in the software by adding user-space markers to the application code? User-space markers have been available in Linux for quite some time (since 2009). The inactive user-space markers do not significantly slow down the code. Having them available allows you to get a more accurate picture of what the software is doing internally when unexpected issues occur. The diagnostic instrumentation can be more portable with the user-space markers, because the instrumentation does not need to rely on instrumenting particular function names or lines numbers in source code. The naming of the instrumentation points can also make clearer what event is associated with a particular instrumentation point.

For example, Ruby MRI on Red Hat Enterprise Linux 7 has a number of different instrumentation points made available as a SystemTap tapset. If SystemTap is installed on the system, as described by What is SystemTap and how to use it?, the installed Ruby MRI instrumentation points can be listed with the stap -L” command shown below. These events show the start and end of various operations in the Ruby runtime, such as the start and end of garbage collection (GC) marking and sweeping.

Continue reading “Making the Operation of Code More Transparent and Obvious”

Share

“Use the dynamic tracing tools, Luke”

A common refrain for tracking down issues on computer systems running open source software is “Use the source, Luke.” Reviewing the source code can be helpful in understanding how the code works, but the static view may not give you a complete picture of how things work (or are broken) in the code. The paths taken through code are heavily data dependent. Without knowledge about specific values at key locations in code, you can easily miss what is happening. Dynamic instrumentation tools, such as SystemTap, that trace and instrument the software can help provide a more complete understanding of what the code is actually doing

I have wanted to better understand how the Ruby interpreter works. This is an opportunity to use SystemTap to investigate Ruby MRI internals on Red Hat Enterprise Linux 7. The article What is SystemTap and how to use it? has more information about installing SystemTap. The x86_64 RHEL 7 machine has ruby-2.0.0648-33.el7_4.x86_64.rpm installed, so the matching debuginfo RPM is installed to provide SystemTap with information about function parameters and to provide me with human-readable source code. The debuginfo RPM is installed by running the following command as root:

Continue reading ““Use the dynamic tracing tools, Luke””

Share

Red Hat Summit: Developing .NET Core Apps on Red Hat OpenShift

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”

Share

Istio Service Mesh Blog Series Recap

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”

Share

March 2018 ISO C++ Meeting Trip Report (SG1: Concurrency and Parallelism)

This year’s Winter ISO C++ Standard Committee meeting was held in March in Jacksonville, Florida. A number of larger features, for which there is substantial interest but which are also difficult to get right, were discussed:

  • Concepts, along with Concept types from the Ranges TS; see P0898 and n4685
  • Modules; see n4689
  • Coroutines; see n4723
  • Networking; see n4711
  • Executors; see p0443

Jason Merrill’s recently published trip report covers the core language topics. This report focuses on the topics of interest to the Concurrency and Parallelism Study Group (SG1).  The “big ticket” items discussed in SG1 during the week were:

Continue reading “March 2018 ISO C++ Meeting Trip Report (SG1: Concurrency and Parallelism)”

Share

Inside a Red Hat Open Innovation Labs Residency (Part 3)

This article is the final in a series taking readers on a journey to peek inside life in a Red Hat Open Innovation Labs residency.

This is the top-tier experience for any customer*, exposing them to open collaboration, open technologies, and fast agile application delivery methods.

This experience often escapes organizations attempting digital transformation, so through submersion in an Open Innovation Labs residency, Red Hat shares its experience in managing, developing, and delivering solutions with communities, open technologies, and open collaboration.

Join me as I share experiences from inside a real-life residency, watching Red Hat work intimately with a customer, exposing new ways of working, leveraging open technologies using fast, agile application delivery methods and open collaboration.

In the first part, I shared what’s in a Red Hat Open Innovation Labs residency. Then in part two, I looked at what I encountered as the residency progressed towards delivery. All that’s left now is to share the delivery week, known as Demo Day.

Continue reading “Inside a Red Hat Open Innovation Labs Residency (Part 3)”

Share

Istio Smart Canary Launch: Easing Into Production

First to fall over when the atmosphere is less than perfect

Your sensibilities are shaken by the slightest defect

You live your life like a canary in a coalmine…

When Sting and The Police sang those lyrics, I doubt they had microservices, Istio, Kubernetes, and OpenShift in mind. Yet here we are, years later, using the Canary Deployment pattern to ease code into production.

[This is part eight of my ten-week Introduction to Istio series.  My previous article was Part 7: Istio Dark Launch: Secret Services.]

Continue reading “Istio Smart Canary Launch: Easing Into Production”

Share

Istio Dark Launch: Secret Services

“Danger is my middle name” is great for spies and people of mystery, but when it comes to deploying software, boring is better. By using Istio with OpenShift and Kubernetes to ease your microservices into production, you can make deployment really, really boring. That’s good.

[This is part seven of my ten-week Introduction to Istio series about Istio, Service Mesh, Red hat OpenShift, and Kubernetes. My previous article was Part 6: Istio Chaos Engineering: I Meant to Do That.]

Boring Is Good

Not to worry, dear DevOps person; there are some exciting things in store for you. It’s just that the end result, thankfully, is boring. You want the fun of setting things in motion and then the routine of watching it just work.

Continue reading “Istio Dark Launch: Secret Services”

Share