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”
For developers working on a Kubernetes-based application environment such as Red Hat OpenShift, there are a number things that need to be considered to fully take advantage of the significant benefits provided by these technologies, including:
- How do I communicate with the orchestration layer to indicate the application is operating correctly and is available to receive traffic?
- What happens if the application detects a system fault, and how does the application relay this to the orchestration layer?
- How can I accurately trace traffic flow between my applications in order to identify potential bottlenecks?
- What tools can I use to easily deploy my updated application as part of my standard toolchain?
- What happens if I introduce a network fault between my services, and how do I test this scenario?
These questions are central to building container-native solutions. At Red Hat, we define container-native as applications that conform to the following key tenets:
- DevOps automation
- Single concern principle
- Service discovery
- High observability
- Lifecycle conformance
- Runtime confinement
- Process disposability
- Image immutability
This may seem like a lot of overhead on top of the core application logic. Red Hat OpenShift Application Runtimes (RHOAR) and Istio provide developers with tools to adhere to these principles with minimal overhead in terms of coding and implementation.
In this blog post, we’re specifically focusing on how RHOAR and Istio combine to provide tools for DevOps automation, lifecycle conformance, high observability, and runtime confinement.
Continue reading “Building Container-Native Node.js Applications with Red Hat OpenShift Application Runtimes and Istio”
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”
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 Service Mesh 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”
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 Service Mesh series. My previous article was Part 7: Istio Dark Launch: Secret Services.]
Continue reading “Istio Smart Canary Launch: Easing Into Production”
“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 Service Mesh series 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”
If you break things before they break, it’ll give you a break and they won’t break.
(Clearly, this is management-level material.)
[This is part six of my ten-week Introduction to Istio Service Mesh series. My previous article was Part 5: Istio Tracing & Monitoring: Where Are You and How Fast Are You Going?]
Continue reading “Istio Chaos Engineering: I Meant to Do That”
The Heisenberg Uncertainty Principle states that you cannot measure an object’s position and velocity at the same time. If it’s moving, it’s not in a location. If it’s in a location, then it has no velocity.
Thanks to some awesome open-source software, our microservices running in Red Hat OpenShift (using Kubernetes) can report both their performance and their health. Granted, they can’t violate the Uncertainty Principle, but they can help bring certainty to your cloud-native applications. Istio brings tracing and monitoring to your system with very little effort, helping you keep things humming.
[This is part five of my ten-week Introduction to Istio Service Mesh series. My previous article was Part 4: Istio Circuit Breaker: When Failure Is an Option.]
Continue reading “Istio Tracing & Monitoring: Where Are You and How Fast Are You Going?”
The phrase “Failure is not an option” is tossed about with much bravado, as though one could make something work by just their strength of will. But the fact remains, things eventually fail. Everything. How then, do you handle the inevitable failure of your microservices? Well, by combining containers, Kubernetes, Red Hat OpenShift, and Istio, we can skip over-the-top displays of swagger, let the system handle things, and get some sleep at night.
[This is part four of my ten-week Introduction to Istio Service Mesh series. My previous article was Part 3: Istio Circuit Breaker: How to Handle (Pool) Ejection.]
Continue reading “Istio Circuit Breaker: When Failure Is an Option”