In this article, I will demonstrate how to speed up your compilation times by distributing compilation load using a distcc server container. Specifically, I’ll show how to set up and use containers running a distcc server to distribute the compilation load over a heterogeneous cluster of nodes (development laptop, old desktop PC, and a Mac). To improve the speed of recompilation, I will use ccache.
Continue reading “2 tips to make your C++ projects compile 3 times faster”
Red Hat OpenShift is part of the Cloud Native Computing Foundation (CNCF) Certified Program, ensuring portability and interoperability for your container workloads. This also allows you to use Kubernetes tools to interact with an OpenShift cluster, like
kubectl, and you can rest assured that all the APIs you know and love are right there at your fingertips.
The Kubernetes Python client is another great tool for interacting with an OpenShift cluster, allowing you to perform actions on Kubernetes resources with Python code. It also has applications within a cluster. We can configure a Python application running on OpenShift to consume the OpenShift API, and list and create resources. We could then create containerized batch jobs from the running application, or a custom service monitor, for example. It sounds a bit like “OpenShift inception,” using the OpenShift API from services created using the OpenShift API.
In this article, we’ll create a Flask application running on OpenShift. This application will use the Kubernetes Python client to interact with the OpenShift API, list other pods in the project, and display them back to the user.
Continue reading “Use the Kubernetes Python client from your running Red Hat OpenShift pods”
Automation is what we (developers) do. We automate ticket sales and automobiles and streaming music services and everything you can possibly tie into an analog-to-digital converter. But, have we taken the time to automate our processes?
In this article, I’ll show how to build an automated integration and continuous delivery pipeline using Jenkins CI/CD and Red Hat OpenShift 4. I will not dive into a lot of details—and there are a lot of details—but we’ll get a good overview. The details will be explained later in this series of blog posts.
Continue reading “Get started with Jenkins CI/CD in Red Hat OpenShift 4”
On April 23, Node.js released its latest major version with Node.js 12. Because this is an even-numbered release, it will become a Long Term Support (LTS) release in October, code-named Erbium.
This release brings a host of improvements and features, which this blog post isn’t going to cover. Instead, I will focus on how to start using this new release today on Red Hat OpenShift. If you’re interested in more about the various improvements and new features, check out the articles listed at the end of this post.
Continue reading “Use Node.js 12 on Red Hat OpenShift today”
Millions of developers worldwide want to learn more about serverless computing. If you’re one of the lucky thousands attending Red Hat Summit in Boston May 7-9, you can gain hands-on experience with the help of Burr Sutter and the Red Hat Developer team.
Guru Night is a BYOL (bring your own laptop) event taking place Wednesday, May 8 from 5:00 p.m. to 8:00 p.m. at the Boston Convention and Event Center in ML2 East-258AB. (Doubtless there will be a map to show you where or what ML2 East etc. is; we have no idea.) Head to the signup page and fill out your details now.
TL;DR: Beer and pizza will be served.
We felt compelled to point that out. But read on.
Continue reading “Guru Night at Red Hat Summit: Hands-on experience with serverless computing”
Working with Red Hat Fuse 7 on Spring Boot is straightforward. In my field experience, I have seen many development (a.k.a. integrator) teams moving to Fuse 7 on Spring Boot for their new integration platforms on Red Hat OpenShift Container Platform (well aligned with agile integration).
Lately, however, I have also seen some teams worried about the size of the final images and the deployment pipeline. In most cases, they had developed a set of common libraries or frameworks to extend or to homogenize the final integration projects. All the cases have the same result:
- Several dependencies copied in each integration project
- Always replacing the container images with the latest fat JAR (including the same dependencies) in each build pipeline
Spring Boot is usually packaged as “fat JARS” that contain all runtime dependencies. Although this is quite convenient, because you only need a JRE and a single JAR to run the application, in a container environment such as Red Hat OpenShift, you have to build a full container image to deploy your application.
Continue reading “Optimizing Red Hat Fuse 7 Spring Boot container images”
Here and elsewhere, we get a lot of questions about post-Docker container tools in Red Hat Enterprise Linux 7.6 and Red Hat Enterprise Linux 8 beta. Tools like podman, buildah, and skopeo enable you to create and manage rootless containers, which are containers that don’t require root access to be built and deployed. To help you master the basics, we’re happy to offer a new podman basics cheat sheet.
Continue reading “Podman basics cheat sheet”
We are pleased to introduce Red Hat CodeReady Workspaces version 1.1, which provides a cloud developer workspace server and browser-based IDE built for teams and organizations. Red Hat CodeReady Workspaces 1.1 includes ready-to-use developer stacks for most of the popular programming languages, frameworks, and Red Hat technologies.
This version of Red Hat CodeReady Workspaces introduces:
- Compatibility with Red Hat OpenShift 4.0
- Installation in disconnected environments
- Simplified configuration of OpenShift OAuth and cluster certificates
Red Hat CodeReady Workspaces 1.1 is available now in the Red Hat Container Catalog. You can install it on OpenShift Container Platform or OpenShift Dedicated, starting at version 3.11, by following the instructions in the Administration Guide.
Continue reading “Red Hat CodeReady Workspaces 1.1: Release notes”
With the growing number of APIs and microservices, the time given to creating and integrating them has become shorter and shorter. That’s why we need an integration framework with tooling to quickly build an API and include capabilities for a full API life cycle. Camel K lets you build and deploy your API on Kubernetes or Red Hat OpenShift in less than a second. Unbelievable, isn’t it?
For those who are not familiar with it, Camel K is a subproject of Apache Camel with the target of building a lightweight runtime for running integration code directly on cloud platforms like Kubernetes and Red Hat OpenShift. It was inspired by serverless principles, and it will also target Knative shortly. The article by Nicola Ferraro will give you a good introduction.
In this article, I’ll show how to build an API with Camel K. For that, we will start first by designing our API using Apicurio Studio, which is based on the OpenAPI standard, and then we will provide the OpenAPI standard document to Camel K in order to implement the API and deploy it to Red Hat OpenShift.
Continue reading “Build and deploy an API with Camel K on Red Hat OpenShift”
I have been talking about systemd in a container for a long time. Way back in 2014, I wrote “Running systemd within a Docker Container.” And, a couple of years later, I wrote another article, “Running systemd in a non-privileged container,” explaining how things hadn’t gotten much better. In that article, I stated, “Sadly, two years later if you google Docker systemd, this is still the article people see—it’s time for an update.” I also linked to a talk about how upstream Docker and upstream systemd would not compromise. In this article, I’ll look at the progress that’s been made and how Podman can help.
Continue reading “How to run systemd in a container”