Red Hat® 3scale is an application programming interface (API) management platform that simplifies the development, deployment, and monitoring of APIs. It offers a range of tools and features such as access control, rate limiting, analytics, a developer portal, and various integration capabilities.
In this blog, we explore the seamless integration of Red Hat 3scale API Management with Red Hat OpenShift® GitOps on IBM® Power® architecture. This integration leverages the strengths of both platforms, enabling easier configuration and management of 3scale objects within an OpenShift cluster on IBM Power. By combining the capabilities of Red Hat 3scale with GitOps practices, you can enhance continuous deployment and streamline the operational processes of your API management resources.
3scale API Management organizes APIs into two main categories:
- Backends: These are internal APIs grouped within a product. They enable API providers to map their internal API architecture to Red Hat 3scale, ensuring efficient management and control.
- Products: These encompass customer-facing APIs, making it easier for providers to create clear and simplified offerings for API consumers. This distinction between internal and external APIs helps streamline the management process.
Once a product is set up in 3scale, you can access comprehensive details about its deployment, authentication settings, and gateway responses through the integration interface, facilitating effective API management.
The following figure depicts an overview of 3scale API Management.
Key Components of 3scale API Management
- Staging and production URLs: In 3scale, the staging and production URLs are the service route names associated with your API. These URLs enable you to separate and manage your API services across different environments.
- API authentication: You can configure various authentication mechanisms such as API keys, OAuth, and OpenID Connect (OIDC) to authenticate and authorize client requests to your API services.
- Hits metric and usage Limits: 3scale includes a built-in metric called Hits, which tracks the number of times your API is invoked. You can define usage limits and pricing rules for specific methods within each application plan, allowing you to control usage and billing for different API methods.
- Mapping rules and metrics: Mapping rules in 3scale help associate operations with predefined methods and metrics, enabling you to track and analyse API usage efficiently.
By leveraging these concepts in 3scale, you can effectively manage your backend, onboard API services as products, configure authentication, set usage limits, and track API usage through metrics and mapping rules.
Now, let's delve into Red Hat OpenShift GitOps.
Red Hat OpenShift GitOps
Red Hat OpenShift GitOps, also known simply as GitOps, is an operational framework that uses version control systems, particularly Git, to manage infrastructure and application deployments. This approach integrates the power of Kubernetes with GitOps principles to facilitate efficient and reliable continuous delivery. GitOps automates the configuration and deployment of applications and infrastructure on Red Hat OpenShift using a Git repository as the source of truth for desired state configurations.
How GitOps works
- Git repository: All configuration files and manifests for your applications and OpenShift resources are stored in a Git repository.
- Desired state definition: In the Git repository, you define the desired state for your applications, services, routes, deployments, and other resources using declarative YAML manifests.
- Continuous monitoring with Argo CD: Argo CD is responsible for continuously monitoring the Git repository for any changes made to the configuration files.
- Automatic change detection: When you update and commit changes to the Git repository, the GitOps tool such as Argo CD automatically detects those changes and can apply them to the OpenShift cluster, ensuring that the cluster state matches the desired state specified in the repository.
The following figure depicts the GitOps workflow.
Configure 3scale API Management platform using OpenShift GitOps
You can configure the Red Hat 3scale API Management platform using OpenShift GitOps for efficient management and deployment of your APIs. The following figure depicts how these two components work together.
Perform the following steps to configure 3scale API Management platform using OpenShift GitOps.
- Set up a Git repository: Start by setting up a Git repository to store all your 3scale configuration files.
- Design your 3scale setup: Define the structure of your 3scale setup, including aspects such as products and backends. Create separate YAML files for these configurations. These files are known as 3scale Custom Resources (CRs), which extend the Kubernetes API to manage custom objects.
- Edit and commit your YAML files: Adjust your YAML files as needed, and then commit them to your Git repository.
- Monitor Git repository with Argo CD: Argo CD continuously monitors your Git repository, watching for any changes you make to the 3scale configuration files.
- Apply changes automatically: When you update your 3scale configuration files and push them to Git, the GitOps tool automatically detects and applies these changes to your 3scale environment.
- Roll back to previous configurations: If you encounter issues, GitOps allows you to revert to a previous configuration by simply reverting to an earlier commit in your Git repository.
With these steps, you can seamlessly integrate Red Hat 3scale using GitOps for a streamlined and efficient API management experience!
By combining Red Hat 3scale with GitOps, you can effectively manage the configuration and deployment of 3scale API management resources in a controlled and auditable manner. GitOps provides version control and automation for the deployment of 3scale configurations, making it easier to manage and track changes to your API management setup over time.
The following figure depicts the 3scale configuration using Argo CD.
Configuring 3scale Custom Resources (CRs)
Perform the following steps to configure Red Hat 3scale CRs.
- Organize your CRs and directory structure:
Create a directory structure that suits your deployment needs. The structure typically includes:
- Base: Contains common 3scale manifest attributes shared across all environments, such as definitions for `products` and `backends`.
- Overlays/dev: Tailored to the development environment, allowing for overrides or extensions of base configurations.
- Define your CRs:
- In the `base` directory, include YAML files that define common attributes for 3scale objects. For example, in the `products` subdirectory, you can specify various product configurations.
- In `overlays/dev`, include YAML files to customize attributes for the development environment, such as environment-specific settings.
- Configure `kustomization.yaml` files in each directory:
- Customize `kustomization.yaml` files in each directory to include the necessary resources and patches. This enables you to manage the environment-specific configurations efficiently.
- In the `base` directory, define the common resources across subdirectories.
- In `overlays/dev`, configure the necessary resources and patches for the development environment.
Once these steps are completed, you can leverage OpenShift GitOps to configure 3scale API management using 3scale CRs effectively.
The following figure depicts the 3scale configuration using Argo CD and 3scale CRs.
Utilize GitOps practices with Red Hat 3scale to ensure your API management resources are configured consistently and in line with your desired state. This setup provides enhanced control over your configurations, allowing you to deploy, monitor, and adjust your 3scale resources seamlessly.
3scale integration with GitOps - Example
Let's explore an example of integrating Red Hat 3scale with GitOps. This example demonstrates how to configure 3scale for a customer product and a customer-order backend using OpenShift GitOps on an OpenShift cluster running on IBM Power (ppc64le). This example illustrates how you can define 3scale objects and deploy them automatically through GitOps using simple YAML files.
Prerequisites
- A fully functioning Red Hat OpenShift cluster (OCP version 4.10 or later).
- OpenShift command-line interface (oc) installed and ready to use.
Steps
Create a new project for 3scale
- Log in to the OpenShift console with administrator privileges.
- Click Create Project and create a project with name 3scale-gitops-example and enter display name and description (optional).
Install the 3scale operator
- Navigate to OperatorHub under Operators and use the search bar to locate the 3scale operator.
- Choose the latest version of 3scale operator (version 2.11 or later). Retain all default values.
Note: Decide whether to install the operator cluster-wide or for a specific namespace. If you choose a namespace-specific installation, ensure the namespace matches where you plan to apply 3scale Custom Resources (CRs) using GitOps (e.g., 3scale-gitops-example namespace).
- Select Automatic for Update Approval option and then click Install.
- Use an APIManager CR to install the 3scale APIManager. When deploying the APIManager, make sure to set the cluster wildcard domain.
- Use the following command to deploy APIManager.
oc apply -f - <<EOF
apiVersion: apps.3scale.net/v1alpha1
kind: APIManager
metadata:
name: example-apimanager
namespace: 3scale-gitops-example
spec:
wildcardDomain: $THREESCALE_WILDCARD (Wildcard specific to cluster)
EOF
This will create the necessary pods for 3scale in the specified namespace (3scale-gitops-example). Make sure all pods are running before proceeding to the next steps.
Next, you need to install the APIcast operator. For more information on APIcast, refer Installing APIcast.
Install OpenShift GitOPs
- Navigate to OperatorHub under Operators and use the search bar to locate the Red Hat OpenShift GitOps operator (version 1.8.x or later) and then click Install. This automatically creates openshift-gitops namespace.
- Use the option to ‘log in via OpenShift’ or use credentials with the help of secrets to log in to Argo CD.
Configure the YAML files
- Access the 3scale GitOps Git repository.
- Modify the repository according to your cluster details.
- Refer the directory structure as shown in the following figure.
In the ‘base’ directory, you can edit the backend and product configuration YAML files:
- Backend configuration YAML file.
apiVersion: capabilities.3scale.net/v1beta1
kind: Backend
metadata:
name: customer-order
spec:
name: "customer-order"
systemName: "customer-order"
- Product configuration YAML file.
apiVersion: capabilities.3scale.net/v1beta1
kind: Product
metadata:
name: customer
spec:
name: "customer"
deployment:
apicastSelfManaged:
stagingPublicBaseURL: "https://api-3scale-apicast-staging.3scale.apps.ppc64le-<ClusterName>:443"
productionPublicBaseURL: "https://api-3scale-apicast-production.3scale.apps.ppc64le-<ClusterName>:443"
authentication:
oidc:
issuerType: "keycloak"
applicationPlans:
portal:
name: "customer"
published: true
appsRequireApproval: true
mappingRules:
- httpMethod: POST
pattern: "/customer/order"
increment: 1
metricMethodRef: hits
- httpMethod: GET
pattern: "/customer/order"
increment: 1
metricMethodRef: hits
policies:
- name: apicast
version: builtin
enabled: true
configuration: {}
For more information on configuration files, refer to Chapter 8. Using the 3scale API Management operator to configure and provision 3scale from Operating Red Hat 3scale API Management documentation.
Configure 3scale API Management
- Enable RBAC to create a cluster role to create, update, or delete 3scale CRs. You must have OpenShift admin privileges to perform these actions.
Use the following command to create a cluster role.
$ oc apply -f rbac/ClusterRole_gitops-threescale-access.yaml
Here’s the content of the file.
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: gitops-threescale-access
labels:
app.kubernetes.io/part-of: openshift-gitops
rules:
- apiGroups: [""]
resources: ["pods", "pods/log"]
verbs: ["get","list", "watch"]
- apiGroups: ["capabilities.3scale.net"]
resources: ["activedocs", "backends", "custompolicydefinitions","developeraccounts", "developerusers", "openapis", "products"]
verbs: ["get", "list", "create", "update", "delete", "patch", "watch"]
- Assign the cluster role to the service account ‘openshift-gitops-argocd-application-controller’.
$ oc adm policy add-role-to-user gitops-threescale-access
system:serviceaccount:openshift-gitops:openshift-gitops-argocd-
application-controller -n 3scale-gitops-example
Configure Git repositories with Argo CD
- In the ArgoCD console, click Manage your repositories à Projects à Settings.
- Select Repositories and either Connect repo using SSH or Connect repo using HTTPS. Enter the necessary details and click Connect.
- Ensure that the connection is successful.
Create Argo CD application
- Create the ArgoCD application in the namespace where 3scale CRs are to be created (for this example, use 3scale-gitops-example namespace).
$ oc apply -f gitops/Application_threescale-dev.yaml -n openshift-gitops
Here is an example of application YAML file.
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: threescale-gitops-app
spec:
destination:
namespace: 3scale-gitops-example
server: https://kubernetes.default.svc
project: default
source:
path: 3scale/overlays/dev
repoURL: https://gitlab.consulting.redhat.com/siprabhu/3scale-gitops-integration.git
targetRevision: HEAD
syncPolicy:
automated:
prune: true
syncOptions:
- ApplyOutOfSyncOnly=true
An ArgoCD application ‘threescale-dev’ will be created.
- Click the Application icon on the left panel of the ArgoCD console, then click Sync. You should see the threescale-dev application; click Sync to synchronize the 3scale CRs.
Synchronize GitOps with Git repository
The GitOps application threescale-dev is configured for manual synchronization. You can change this setting to automatically apply changes committed to the Git repository to 3scale.
After syncing, verify that the application matches the example shown in the following screen capture.
Observe the 3scale Admin console to verify that the product customer and backend customer-order have been configured as expected.
Verify API manager via Git
- Switch to Products view in 3scale and go to Integration.
- Verify the Mapping rules tab to see POST and GET rules are configured in the configuration YAML files.
- Go to Backends to verify that the Private base URL is as expected.
- In the API Gateway Settings, observe the Staging Public Base URL and Production Public Base URL is as expected.
- Go to Applications à Listings and then click New application. Enter the details for Account, Application plan, Name and Description and click Create application.
- Switch to Configuration. In APIcast Configuration, click Promote to Staging and notice the staging URL.
https://api-3scale-apicast-staging.3scale.apps.ppc64le-<ClusterName>:443
- Use an API viewer tool to open the URL and verify the API response.
Conclusion
By adopting GitOps and using 3scale CRs, you can maintain a version-controlled history of your 3scale configuration. This allows you to easily manage environment-specific overrides while achieving consistency and reproducibility in your deployments. GitOps offers an auditable and automated approach to managing changes to your 3scale configuration and supports best practices for configuration management and deployment.
In this blog, we delved into the integration of Red Hat 3scale API Management with OpenShift GitOps, including the configuration of Red Hat 3scale objects using 3scale CRs and the use of OpenShift GitOps for continuous deployment. Also demonstrated a practical example of configuring a Red Hat 3scale API using OpenShift GitOps on an OpenShift cluster based on the IBM Power (ppc64le) architecture. Leave us a comment to share your experience of integrating 3scale with GitOps.
#Featured-area-1#Featured-area-1-home