When you want to do automated tasks for builds and deployments with Red Hat OpenShift, you might want to take advantage of the OpenShift REST API. In scripts you can use
oc CLI command which talks to the REST APIs. However there are times when it is more convenient to do this directly from your C# code without having to invoke an external program. This is the value of having an infrastructure platform that is exposed as services with an open API.
If you want to call the API from your C# code, you have to create a request object, call the API, and parse the response object. The upstream project, OpenShift Origin, provides a Swagger 2.0 specification and you can generate a client library for each programming language. Of course, C# is supported. This isn’t a new approach, Kubernetes has a repository that is generated by Swagger Codegen.
For C#, we can use Microsoft Visual Studio to generate a C# client library for a REST API. In this article, I’ll walk you through the process of generating the library from the definition.
Continue reading “How to call the OpenShift REST API from C#”
If you are developing with C/C++, Clang tools and newer versions of GCC can be quite helpful for checking your code and giving you better warnings and error messages to help avoid bugs. The newer compilers have better optimizations and code generation.
You can easily install the latest-supported Clang and GCC compilers for C, C++, Objective-C, and FORTRAN using
yum on Red Hat Enterprise Linux. These compilers are available as software collections that are typically updated twice a year. The May 2018 update included Clang/LLVM 5 and GCC 7.3, as well as Go and Rust.
If you want your default
gcc to always be GCC 7, or you want
clang to always be in your path, this article shows how to permanently enable a software collection by adding it to the profile (dot files) for your user account. A number of common questions about software collections are also answered.
Continue reading “How to install Clang/LLVM 5 and GCC 7 on RHEL”
Containers are the new way of deploying applications. They provide an efficient mechanism to deploy self-contained applications in a portable way across clouds and OS distributions. In this blog post we’ll look at what OpenShift brings for .NET Core specifically.
Kubernetes and OpenShift
Kubernetes is the de facto orchestrator for managing containerized applications. Google open-sourced Kubernetes in 2014 and Red Hat was one of the first companies to work with Google on Kubernetes. Red Hat is the 2nd leading contributor to the Kubernetes upstream project.
OpenShift is an open-source DevOps platform that is built on top of Kubernetes. It integrates directly with your application’s source code. This enables continuous integration/continuous deployment (CI/CD) workflows. Tools are available to scale and monitor your applications. The OpenShift Catalog makes it easy to setup middleware and databases. OpenShift comes with comprehensive documentation to install and manage your installation. It can run on-prem and on public clouds such as AWS, GCP and Azure.
Continue reading “Using OpenShift to deploy .NET Core applications”
The Summer 2018 ISO C++ standards committee meeting this year was back in Rapperswil, Switzerland. The new features for C++2a are coming fast now; the Core language working group had very little time for issue processing because of all the proposal papers coming to us from the Evolution working group.
Red Hat sent three of us to the meeting, to cover different tracks: myself (Core), Jonathan Wakely (Library), and Torvald Riegel (Parallelism/Concurrency). Overall, I thought the meeting was very successful; we made significant progress in a lot of areas.
New C++ language features that were accepted at this meeting:
Continue reading “June 2018 ISO C++ Meeting Trip Report (Core Language)”
We are very pleased to announce the general availability of .NET Core 2.1 for Red Hat Enterprise Linux and OpenShift platforms!
.NET Core is the open-source, cross-platform .NET platform for building microservices. .NET Core is designed to provide the best performance at scale for applications that use microservices and containers. Libraries can be shared with other .NET platforms, such as .NET Framework (Windows) and Xamarin (mobile applications). With .NET Core you have the flexibility of building and deploying applications on Red Hat Enterprise Linux or in containers. Your container-based applications and microservices can easily be deployed to your choice of public or private clouds using Red Hat OpenShift. All of the features of OpenShift and Kubernetes for cloud deployments are available to you.
.NET Core 2.1 continues to broaden its support and tools for microservice development in an open source environment. The latest version of .NET Core includes the following improvements:
Continue reading “Announcing .NET Core 2.1 for Red Hat Platforms”
In this article, we will use a Python-based messaging client to connect and subscribe to a topic with a durable subscription in the Apache ActiveMQ Artemis broker. We will use the text-based STOMP protocol to connect and subscribe to the broker. STOMP clients can communicate with any STOMP message broker to provide messaging interoperability among many languages, platforms, and brokers.
If you need to brush up on the difference between persistence and durability in messaging, check Mary Cochran’s article on developers.redhat.com/blog.
A similar process can be used with Red Hat AMQ 7. The broker in Red Hat AMQ 7 is based on the Apache ActiveMQ Artemis project. See the overview on developers.redhat.com for more information.
Continue reading “Using the STOMP Protocol with Apache ActiveMQ Artemis Broker”
Last year, I wrote a blog post how to remotely debug your ASP.NET Core container on OpenShift with Visual Studio Code. Today I introduce how to remotely debug a pod using Visual Studio from your Windows computer. Sometimes you encounter an issue that happens only in the production environment. Remotely debugging a pod enables you to investigate such an issue.
Visual Studio and Visual Studio Code now support SSH as a transport protocol for remote debugging. If a remote host accepts an SSH connection, Visual Studio can do remote debugging using Visual Studio’s default feature. However, you need to use the
oc command instead of an SSH client such as putty since Red Hat OpenShift pods don’t allow direct connections via SSH. The MIEngine debugger enables you to use any command for SSH connection.
All the steps below have been confirmed using a combination of Visual Studio 2017 (versions 15.7.2 and 15.8 preview2) on Windows 10 and OpenShift 3.9.
Continue reading “Remotely Debug an ASP.NET Core Container Pod on OpenShift with Visual Studio”
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”
I recently got my zero-dollar developer copy of Red Hat Enterprise Linux (RHEL, version 7.5) and built a virtual machine (VM) to run it. There it was, on my PC, running in VirtualBox…a gleaming, shiny, brand-spanking-new VM running RHEL. Whatever shall I do with it?
Then I got the idea: I’ll install the Red Hat Container Development Kit (CDK) and build some Python-based containers. I’ll use Flask, a terrific microframework that makes building RESTful services easy.
Continue reading “How to install Python Flask on Red Hat Enterprise Linux 7”
Security is a very important consideration when running your custom middleware applications. The internet can be an unfriendly place.
Sometimes middleware users have a requirement for their software to run in a “‘disconnected” environment, which is one where the network is not routed to addresses outside the one the local node is on—in other words, no internet.
Continue reading “Using .NET Core in a “Disconnected” Environment”