• Home
• Miscellaneous

Miscellaneous

Configuring Cross-Tenant Azure DevOps Access from ArgoCD on ARO

In some large enterprises, it might be a requirement to have your Azure DevOps (ADO) tools in a centralized Azure Tenant different from the tenant where your cluster resides. It then becomes imperative to configure secure cross-tenant access between your Azure Red Hat OpenShift (ARO) cluster and your ADO.

Setting up Cross-Cluster PostgreSQL Replication with Skupper on ROSA and ARO

This guide demonstrates how to set up a highly available PostgreSQL database with cross-cluster replication between Red Hat OpenShift Service on AWS (ROSA) and Azure Red Hat OpenShift (ARO) using Skupper. This architecture enables disaster recovery capabilities and geographical distribution of your database workloads.

Note: You can create a ROSA cluster using the ROSA with STS deployment guide or an ARO cluster with the ARO quickstart guide . While this tutorial focuses on ROSA and ARO, the same principles can be applied to any two OpenShift clusters, regardless of their hosting environment.

Running and Deploying LLMs using Red Hat OpenShift AI on ROSA cluster and Storing the Model in Amazon S3 Bucket

1. Introduction

Large Language Models (LLMs) are a specific type of generative AI focused on processing and generating human language. They can understand, generate, and manipulate human language in response to various tasks and prompts.

This guide is a simple example on how to run and deploy LLMs on a Red Hat OpenShift Services on AWS (ROSA) cluster, which is our managed service OpenShift platform on AWS, using Red Hat OpenShift AI (RHOAI) , which is formerly called Red Hat OpenShift Data Science (RHODS) and is our OpenShift platform for managing the entire lifecycle of AI/ML projects. And we will utilize Amazon S3 bucket to store the model output. In essence, here we will first install RHOAI operator and Jupyter notebook, create the S3 bucket, and then run the model.

Setting custom domains for apps created via OpenShift Dev Spaces

Red Hat OpenShift Dev Spaces (formally CodeReady Workspaces) is an Operator available for OpenShift that allows users to create dynamic IDEs for developing and publishing code. When using OpenShift Dev Spaces, users can test their code and have the service automatically create a route for users to see their code in real time. By default, this route will use the default Ingress Controller, but it is possible to configure Dev Spaces to use a custom domain instead.

Patch token-refresher to use a cluster proxy

Currently, if you deploy a ROSA or OSD cluster with a proxy, the token-refresher pod in the openshift-monitoring namespace will be in crashloopbackoff. There is an RFE open to resolve this, but until then this can affect the ability of the cluster to report telemetry and potentially update. This article provides a workaround on how to patch the token-refresher deployment until that RFE has been fixed using the patch-operator.

Prerequisites

• A logged in user with cluster-admin rights to a ROSA or OSD Cluster deployed using a cluster wide proxy

  Red Hat Cost Management for Cloud Services

  Adopted from Official Documentation for Cost Management Service

  Red Hat Cost Management is a software as a service (SaaS) offering available free of charge as part of your Red Hat subscriptions. Cost management helps you monitor and analyze your OpenShift Container Platform and Public cloud costs in order to improve the management of your business.

  Some capabilities of cost management are :

  • Visualize costs across hybrid cloud infrastructure
  • Track cost trends
  • Map charges to projects and organizations
  • Normalize data and add markups with cost models
  • Generate showback and chargeback information

  In this document, I will show you how to connect your OpenShift and Cloud provider sources to Cost Management in order to collect cost and usage.

  Azure DevOps with Managed OpenShift

  Author: Kevin Collins

  Last edited: 03/14/2023

  Adopted from Hosting an Azure Pipelines Build Agent in OpenShift and Kevin Chung Azure Pipelines OpenShift example

  Azure DevOps is a very popular DevOps tool that has a host of features including the ability for developers to create CI/CD pipelines.

  In this document, I will show you how to connect your Managed OpenShift Cluster to Azure DevOps end-to-end including running the pipeline build process in the cluster, setting up the OpenShift internal image registry to store the images, and then finally deploy a sample application. To demonstrate the flexibility of Azure DevOps, I will be deploying to a ROSA cluster, however the same procudures will apply to if you choose to deploy to any other OCP Cluster.

  MOBB Docs and Guides - oadp

  MOBB Docs and Guides for OADP

  • Deploying OADP on ROSA
  • Deploying OADP on ARO

  Stop default router from serving custom domain routes

  Note: This page is only valid for clusters using the Custom Domain Operator (CDO), which are ROSA clusters prior to version 4.14

  OSD and ROSA supports custom domain operator to serve application custom domain, which provisions openshift ingress controller and cloud load balancers. However, when a route with custom domain is created, both default router and custom domain router serve routes. This article describes how to use route labels to stop default router from serving custom domain routes.

  Installing the Kubernetes Secret Store CSI on OpenShift

  The Kubernetes Secret Store CSI is a storage driver that allows you to mount secrets from external secret management systems like HashiCorp Vault and AWS Secrets.

  It comes in two parts, the Secret Store CSI, and a Secret provider driver. This document covers just the CSI itself.

  Prerequisites

  1. An OpenShift Cluster (ROSA, ARO, OSD, and OCP 4.x all work)
  2. kubectl
  3. helm v3

  Installing the Kubernetes Secret Store CSI

  1. Create an OpenShift Project to deploy the CSI into

     OpenShift - Sharing Common images

     In OpenShift images (stored in the in-cluster registry) are protected by Kubernetes RBAC and by default only the namespace in which the image was built can access it.

     For example if you build an image in project-a only project-a can use that image, or build from it. If you wanted the default service account in project-b to have access to the images in project-a you would run the following.

     However if you had to do this for every namespace it could become quite combersome. Instead if you choose to have a set of common images in a common-images namespace you could make them available to all authenticated users like so.

     Common Managed OpenShift References / Tasks

     Common Managed OpenShift References / Tasks

     Managed OpenShift Overviews

     • Red Hat OpenShift Managed services
     • Microsoft Azure Red Hat OpenShift - ARO
     • Red Hat OpenShift on AWS - ROSA
     • Red Hat OpenShift on IBM Cloud
     • Red Hat OpenShift Dedicated - OSD

     Managed OpenShift Documentation

     • OpenShift Container Platform v4.7
     • Azure Red Hat OpenShift v4.x - ARO
     • Red Hat OpenShift on AWS v4.x - ROSA
     • Red Hat OpenShift on IBM Cloud v4.x
     • OpenShift Dedicated v4.x - OSD

     Common Customer Topics

     Red Hat OpenShift on AWS - ROSA

     • Creating a ROSA cluster with PrivateLink enabled
     • ROSA Installation Prerequisites
     • ROSA STS Workflow
     • Shared Responsiblity Matrix (who does what)
     • Red Hat Process and Security for ROSA
     • ROSA Support

     Azure on Red Hat OpenShift ARO

     • ARO Installation Process
     • ARO Support
     • Azure Compliance
     • Monitoring
     • Authentication

     Education

     • ARO Getting Started
     • ROSA Getting Started

     UPDATED DOCUMENT: This article is out of date and should not be used. Please refer to the official documentation for ROSA and OSD .

     ---

     build: list: never publishResources: false render: never date: ‘2022-08-24’ title: Configure ROSA/OSD to use custom TLS ciphers on the ingress controllers aliases: [’/experts/ingress/tls-cipher-customization’] tags: [“ROSA”, “OSD”] authors:

     • Michael McNeill
     • Connor Wooley

     ---

     This guide demonstrates how to properly patch the cluster ingress controllers, as well as ingress controllers created by the Custom Domain Operator. This functionality allows customers to modify the tlsSecurityProfile value on cluster ingress controllers. This guide will demonstrate how to apply a custom tlsSecurityProfile, a scoped service account (with the associated role and role binding), and a CronJob that the cipher changes are reapplied with 60 minutes (in the event that an ingress controller is recreated or modified).