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”
Since Red Hat OpenShift Container Platform was first released, Red Hat Middleware products were provided to deploy on it and help developers to build more complex solutions. Messaging Brokers are a very important piece in most new application architectures, such as microservices, event sourcing, and CQRS. Red Hat JBoss AMQ was provided from the beginning to deploy Messaging Brokers on Red Hat OpenShift easily.
Continue reading Automated migration from JBoss AMQ 6 to Red Hat AMQ 7 on Red Hat OpenShift
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”
As part of the Red Hat UKI Professional Services team, I have worked with several customers who are implementing AMQ Broker on Red Hat OpenShift Container Platform (OCP). One question customers typically ask is, “How do we validate that the AMQ configuration is correct for our scenario?” Previously, I would have suggested one of the following:
These tools can give you indicators around:
- Is the broker up and running? That is, can it receive/publish messages for this configuration?
- Can the broker handle a certain performance characteristic? That is, what is my minimum publish rate per second for this configuration?
- And much more.
The problem with these tools is that you cannot choose the client technology. This could lead to real-world differences and limited technology choices, which in turn might lead you down the wrong technology path. In other words:
- Do you get the same performance from JMeter versus the AMQ clients you would use in production? Are you comparing like for like? Apples with apples?
So, what do I think is the answer? Quiver . In this article, I’ll provide an overview and demo of using Quiver with Red Hat AMQ on Red Hat OpenShift. If you’re looking for more information on Red Hat AMQ and how it can help, check out this webinar.
Continue reading “Using Quiver with AMQ on Red Hat OpenShift Container Platform”
Red Hat OpenShift Container Platform is a platform-as-a-service (PaaS). It orchestrates and manages containerized applications through Kubernetes. Although OpenShift Container Platform supports cloud-native applications, it also supports custom-built applications. OpenShift Container Platform can run on a hybrid cloud configuration providing the flexibility to expand and grow.
Red Hat OpenStack Platform is an infrastructure-as-a-service (IaaS). This means it is a cloud-based platform that provides virtual servers and other resources. Users either manage it through a web-based dashboard, through command-line tools, or through RESTful web services.
If you are considering Red Hat OpenShift Container Platform on OpenStack Platform, there are several advantages, including easily increasing the number of compute nodes and using dynamic storage.
In this article, I will outline the main points required to successfully install Red Hat OpenShift Container Platform on OpenStack Platform. Because my OpenStack knowledge is limited, I reached out to my colleagues for help and will not address too many OpenStack technical details here.
Continue reading “How to install Red Hat OpenShift 3.11 on OpenStack 13”
In a previous article, we talked about using containers to build .NET Core application images to make our builds portable and reproducible. Because each build starts from scratch, some time is spent downloading and extracting NuGet packages.
One way to reduce build times is to add a local NuGet server; this brings packages closer to the build machines, which reduces the time to download the packages. In this article, we’ll look at how the new incremental build feature of the .NET Core S2I builder can further reduce build times.
Continue reading “Reduce application image build times with .NET Core incremental builds”
In this article, I will discuss the prerequisites and requirements for the successful implementation of Red Hat OpenShift 3.11 disconnected installation using Red Hat Satellite as the local Docker registry, which I have been able to do with the support of my colleagues. I also discuss adjustments that may be required post install.
This work is based on the following references:
Continue reading “Red Hat OpenShift 3.11 disconnected installation using Satellite Docker registry”
What Red Hat is providing
Red Hat OpenShift Application Runtimes (RHOAR) is a recommended set of products, tools, and components for developing and maintaining cloud-native applications on the Red Hat OpenShift platform. As part of this offering, Red Hat is extending its support to Spring Boot 2 and related frameworks for building modern, production-grade, Java-based cloud-native applications.
Spring Boot lets you create opinionated Spring-based standalone applications. The Spring Boot runtime also integrates with the OpenShift platform, allowing your services to externalize their configuration, implement health checks, provide resiliency and failover, and much more. To learn more about how Spring Boot applications integrate with the wider Red Hat portfolio, check out the following OpenShift Commons Briefing by Thomas Qvarnstrom:
Continue reading “Extending support to Spring Boot 2.x for Red Hat OpenShift Application Runtimes”
APIs are the cornerstone of so many recent breakthroughs: from mobile applications, to the Internet of Things, to cloud computing. All those technologies expose, consume, and are built on APIs. And those APIs are a key driver for generating new revenue. Salesforce generates 50% of its revenue through APIs, Expedia generates 90% of its, and eBay generates 60% of its. With APIs becoming so central, it becomes essential to deal with full API lifecycle management. The success of your digital transformation project depends on it!
This article describes a set of full API lifecycle management activities that can guide you from an idea to the realization, from the inception of an API program up to management at scale throughout your whole company.
Continue reading “Full API lifecycle management: A primer”
Red Hat CodeReady Workspaces provide developers with containerized development environments hosted on OpenShift/Kubernetes. DevOps teams can now use a hosted development environment that’s pre-built for their chosen stack and customized for their project.
CodeReady Workspaces can help you rapidly onboard developers for your project as everything they need to develop is running in a containerized workspace. In this post, we’re going to use CodeReady Workspaces to get up and running quickly with an existing open source project, Peak. Peak is a multi-container Kubernetes application for performance testing web services, and it allows you to create distributed performance tests using the Kubernetes Batch API for test orchestration. We’ll make some modifications to Peak’s Flask front end, a stateless web interface that interacts with a Falcon RESTful API to return data about performance tests. You won’t need the complete Peak application deployed, though if you like, you can find steps to deploy it to OpenShift here.
To follow along you’ll need a Red Hat OpenShift Container Platform 3.11 environment. You can use the Red Hat Container Development Kit on your Windows, macOS, or Linux laptop or a hosted Red Hat OpenShift instance to do it on online.
Continue reading “Creating a containerized Python/Flask development environment with Red Hat CodeReady Workspaces”