DevOps

How DevOps is like auto racing

How DevOps is like auto racing

When I talk about desired outcomes or answer a question about where to get started with any part of a DevOps initiative, I like to mention NASCAR or Formula 1 racing. Crew chiefs for these race teams have a goal: finish in the best place possible with the resources available while overcoming the adversity thrown at you. If the team feels capable, the goal gets moved up a series of levels to holding a trophy at the end of the race.

To achieve their goals, race teams don’t think from start to finish; they flip the table to look at the race from the end goal to the beginning. They set a goal, a stretch goal, and then work backward from that goal to determine how to get there. Work is delegated to team members to push toward the objectives that will get the team to the desired outcome.

Continue reading “How DevOps is like auto racing”

Share
How to configure LDAP user authentication and RBAC in Red Hat OpenShift 3.11

How to configure LDAP user authentication and RBAC in Red Hat OpenShift 3.11

In this article, I demonstrate a systematic method to configure LDAP user and group synchronization in Red Hat OpenShift, as well as OpenShift role-based access control (RBAC) for these LDAP users and groups. Following these steps makes the management of your LDAP users and groups within OpenShift much easier. I achieve this goal by demonstrating:

  • How to validate your ldap parameters with ldaptool prior to installing OpenShift.
  • How to enable LDAP authentication in OpenShift for specific LDAP groups and organization units.
  • The scripts and commands that let you synchronize members of your LDAP groups to OpenShift, which in turn lets you apply custom OpenShift RBAC rules on specific users or groups.

Continue reading “How to configure LDAP user authentication and RBAC in Red Hat OpenShift 3.11”

Share
Using the 3scale toolbox Jenkins Shared Library

Using the 3scale toolbox Jenkins Shared Library

In the previous article of this series, Deploy your API from a Jenkins Pipeline, we discovered how the 3scale toolbox can help you deploy your API from a Jenkins Pipeline on Red Hat OpenShift/Kubernetes. In this article, we will improve the pipeline from the previous article to make it more robust, less verbose, and also offer more features by using the 3scale toolbox Jenkins Shared Library.

Continue reading “Using the 3scale toolbox Jenkins Shared Library”

Share
Deploy your API from a Jenkins Pipeline

Deploy your API from a Jenkins Pipeline

In a previous article, 5 principles for deploying your API from a CI/CD pipeline, we discovered the main steps required to deploy your API from a CI/CD pipeline and this can prove to be a tremendous amount of work. Hopefully, the latest release of Red Hat Integration greatly improved this situation by adding new capabilities to the 3scale CLI. In 3scale toolbox: Deploy an API from the CLI, we discovered how the 3scale toolbox strives to automate the delivery of APIs. In this article, we will discuss how the 3scale toolbox can help you deploy your API from a Jenkins pipeline on Red Hat OpenShift/Kubernetes.

Continue reading “Deploy your API from a Jenkins Pipeline”

Share
An introduction to cloud-native CI/CD with Red Hat OpenShift Pipelines

An introduction to cloud-native CI/CD with Red Hat OpenShift Pipelines

Red Hat OpenShift 4.1 offers a developer preview of OpenShift Pipelines, which enable the creation of cloud-native, Kubernetes-style continuous integration and continuous delivery (CI/CD) pipelines based on the Tekton project. In a recent article on the Red Hat OpenShift blog, I provided an introduction to Tekton and pipeline concepts and described the benefits and features of OpenShift Pipelines.

Continue reading “An introduction to cloud-native CI/CD with Red Hat OpenShift Pipelines”

Share
Application lifecycle management for container-native development

Application lifecycle management for container-native development

Container-native development is primarily about consistency, flexibility, and scalability. Legacy Application Lifecycle Management (ALM) tooling often is not, leading to situations where it:

  • Places artificial barriers on development speed, and therefore time to value,
  • Creates single points of failure in the infrastructure, and
  • Stifles innovation through inflexibility.

Ultimately, developers are expensive, but they are the domain experts in what they build. With development teams often being treated as product teams (who own the entire lifecycle and support of their applications), it becomes imperative that they control the end-to-end process on which they rely to deliver their applications into production. This means decentralizing both the ALM process and the tooling that supports that process. In this article, we’ll explore this approach and look at a couple of implementation scenarios.

Continue reading “Application lifecycle management for container-native development”

Share
Announcing Kubernetes-native self-service messaging with Red Hat AMQ Online

Announcing Kubernetes-native self-service messaging with Red Hat AMQ Online

Microservices architecture is taking over software development discussions everywhere. More and more companies are adapting to develop microservices as the core of their new systems. However, when going beyond the “microservices 101” googled tutorial, required services communications become more and more complex. Scalable, distributed systems, container-native microservices, and serverless functions benefit from decoupled communications to access other dependent services. Asynchronous (non-blocking) direct or brokered interaction is usually referred to as messaging.

Continue reading “Announcing Kubernetes-native self-service messaging with Red Hat AMQ Online”

Share
Building Java 11 and Gradle containers for OpenShift

Building Java 11 and Gradle containers for OpenShift

How do YOU get your Java apps running in a cloud?

First you grab a cloud from the sky by, for example,  (1) Getting started with a free account on Red Hat OpenShift Online, or (2) locally on your laptop using Red Hat Container Development Kit (CDK) or upstream Minishift on Windows, macOS, and Linux, or (3) using oc cluster up (only on Linux), or (4) by obtaining a login from someone running Red Hat OpenShift on a public or on-premises cloud. Then, you download the oc CLI client tool probably for Windows (and put it on your PATH). Then you select the Copy Login Command from the menu in the upper right corner under your name in the OpenShift Console’s UI, and you use, for example, the oc status command.

Great—now you just need to containerize your Java app. You could, of course, start to write your own Dockerfile, pick an appropriate container base image (and discuss Red Hat Enterprise Linux versus CentOS versus Fedora versus Ubuntu versus Debian versus Alpine with your co-workers; and, especially if you’re in an enterprise environment, figure out how to have that supported in production), figure out appropriate JVM startup parameters for a container, add monitoring, and so.

But perhaps what you really wanted to do today is…well, just get your Java app running in a cloud!

Read on to find an easier way.

Continue reading “Building Java 11 and Gradle containers for OpenShift”

Share
Common architectural elements for modern integration architectures (Part 2)

Common architectural elements for modern integration architectures (Part 2)

In Part 1 of this series, we explored a use case around integration being the key to transforming your customer experience.

I laid out how I’ve approached the use case and how I’ve used successful customer portfolio solutions as the basis for researching a generic architectural blueprint. The only thing left to cover was the order in which you’ll be led through the blueprint details.

This article, which is Part 2 of the series, starts the real journey at the very top, with a generic architecture from which we’ll discuss the common architectural elements one by one.

Continue reading “Common architectural elements for modern integration architectures (Part 2)”

Share
How integration is key to customer experience (Part 1)

How integration is key to customer experience (Part 1)

For the past few months, I’ve been digging into my new role with a group of Portfolio Architects, looking specifically at integration as the key to omnichannel customer experience.

It’s an interesting challenge in that we’ve been given the mission of creating architectural content based on common customer adoption patterns. That’s very different from most of the traditional marketing activities usually associated with generating content for the sole purpose of positioning products for solutions. When you’re basing the content on actual execution in solution delivery, you’re cutting out the chuff. 

What’s that mean?

It means that it’s going to provide you with a way to implement a solution using open source technologies by focusing on the integrations, structures, and interactions that actually have been proven to work.

What’s not included is any vendor promises that you’ll find in normal marketing content: those promises that, when it gets down to implementation crunch time, might not fully deliver.

Enter the term architectural blueprint. 

In this series of articles, let’s look at these blueprints, how they are created, and what value they provide for your solution designs.

Continue reading “How integration is key to customer experience (Part 1)”

Share