-
Notifications
You must be signed in to change notification settings - Fork 57
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Added overview of validated patterns and removed the old content
- Loading branch information
1 parent
8137184
commit 4be6516
Showing
2 changed files
with
101 additions
and
61 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,101 @@ | ||
--- | ||
menu: learn | ||
title: About Validated Patterns | ||
weight: 10 | ||
aliases: /learn/about-validated-patterns/ | ||
--- | ||
:toc: | ||
|
||
:_content-type: ASSEMBLY | ||
include::modules/comm-attributes.adoc[] | ||
|
||
[id="about-validated-patterns"] | ||
= Overview of Validated Patterns | ||
|
||
Validated Patterns are an advanced form of reference architectures that provide a streamlined approach to deploying complex business solutions. Unlike traditional architectures, which provide only guidance, Validated Patterns are deployable, testable software artifacts with automated deployment, enhancing speed, reliability, and consistency across environments. These patterns are rigorously tested blueprints designed to meet specific business needs, reducing deployment risks. | ||
|
||
Building on traditional architectures, Validated Patterns focus on customer solutions involving multiple Red Hat products. They are based on successful deployments and include example applications and the necessary open-source projects. Users can easily modify these patterns to fit their specific needs. | ||
|
||
The creation process involves selecting customer use cases, validating the patterns with engineering teams, and developing GitOps-based automation. This automation supports Continuous Integration (CI) pipelines, allowing for proactive updates and maintenance as new product versions are released. | ||
|
||
|
||
|
||
[id="relationship-to-reference-architectures"] | ||
== Relationship to reference architectures | ||
|
||
Validated Patterns enhance reference architectures with automation and rigorous validation. While reference architectures provide a conceptual framework for building solutions, Validated Patterns go further by providing a deployable software artifact that automates and optimizes the reference architecture framework, ensuring consistent and efficient deployments. This approach allows businesses to implement complex solutions rapidly and with confidence, knowing that the patterns have been thoroughly tested and optimized for their use case. | ||
|
||
[id="problem-validated-pattern-solve"] | ||
== The problem Validated Patterns solve | ||
Deploying complex business solutions involves multiple steps, each of which, if done haphazardly, can introduce potential errors or inefficiencies. Validated Patterns address this by offering a pre-validated, automated deployment process. This reduces guesswork, minimizes manual intervention, and ensures faster, more reliable deployments. Organizations can then focus on strategic business objectives rather than deployment complexities. | ||
|
||
[id="goals"] | ||
== Validated Patterns goals | ||
The main goals of the Validated Patterns project include: | ||
|
||
* *Consistency*: Ensure that deployments are uniform across different environments, reducing variability and potential issues. | ||
* *Reliability*: Ensure that solutions are thoroughly tested and validated, minimizing the risk of errors during deployment. | ||
* *Efficiency*: Reduce the time and resources required for deployment by providing pre-configured, automated solutions. | ||
* *Scalability*: Enable businesses to deploy solutions that can scale to meet growing demands. | ||
* *Automation*: Streamline the deployment of complex business solutions by automating key processes. While automation is a key aspect of the framework, its primary role is to support and enhance the core goals of consistency, reliability, efficiency, and scalability. | ||
|
||
|
||
[id="who-should-use-validated-patterns"] | ||
== Who should use Validated Patterns? | ||
Validated Patterns are particularly suited for IT architects, advanced developers, and system administrators with a familiarity with Kubernetes and the Red Hat OpenShift Container Platform. These patterns are ideal for those who need to deploy complex business solutions quickly and reliably across various environments. The framework incorporates advanced https://www.cncf.io/projects/[Cloud Native] concepts and projects, such as OpenShift GitOps (https://argoproj.github.io/argo-cd/[ArgoCD]), Advanced Cluster Management (https://open-cluster-management.io/[Open Cluster Management]), and OpenShift Pipelines (https://tekton.dev/[Tekton]), making them especially beneficial for users familiar with these tools. | ||
|
||
*Examples of Use Cases*: | ||
|
||
* *Enterprise-Level Deployments*: Organizations implementing large-scale, multi-tier applications can use Validated Patterns to ensure reliable and consistent deployments across all environments. | ||
* *Cloud Migration*: Companies transitioning their infrastructure to the cloud can leverage Validated Patterns to automate and streamline the migration process. | ||
* *DevOps Pipelines*: Teams relying on continuous integration and continuous deployment (CI/CD) pipelines can use Validated Patterns to automate the deployment of new features and updates, ensuring consistent and repeatable outcomes. | ||
|
||
|
||
[id="validated-patterns-community-and-ecosystem"] | ||
== The Validated Patterns community and ecosystem | ||
Validated Patterns are supported by a vibrant community and ecosystem that contribute to their ongoing development and refinement. This community-driven approach ensures that Validated Patterns stay current with the latest technological advancements and industry best practices. The ecosystem includes contributions from various industries and technology partners, ensuring that the patterns are applicable to a wide range of use cases and environments. This collaborative effort keeps the patterns relevant and fosters a culture of continuous improvement within the Red Hat ecosystem. | ||
|
||
|
||
|
||
[id="involvement-in-validated-patterns"] | ||
== Red Hat's involvement in Validated Patterns | ||
|
||
Red Hat plays a pivotal role in the development, validation, and promotion of Validated Patterns. As a leader in open-source solutions, Red Hat leverages its extensive expertise to create and maintain these patterns, ensuring they meet the highest standards of quality and reliability. Red Hat’s involvement extends beyond tool provision; it includes continuous updates to align these patterns with the latest technological advancements and industry needs. This ensures that organizations using Validated Patterns are always equipped with the most effective and up-to-date solutions available. Additionally, Red Hat collaborates closely with the community to expand the catalog of Validated Patterns, making these valuable resources accessible to organizations worldwide. | ||
|
||
[id="deployment-workflows"] | ||
== Application deployment workflows | ||
Effective deployment workflows are crucial for ensuring that applications are deployed consistently and efficiently across various environments. By leveraging OpenShift clusters and automation tools, these workflows can streamline the process, reduce errors, and ensure scalability. Below, we outline the general structure for deploying applications, including edge patterns and GitOps integration. | ||
|
||
[id="general-structure"] | ||
=== General structure | ||
|
||
All patterns assume an available OpenShift cluster for deploying applications. If no OpenShift cluster is available, you can use https://console.redhat.com/openshift[cloud.redhat.com]. The documentation uses the `oc` command syntax, but `kubectl` can be used interchangeably. For each deployment, it is assumed that the user is logged into a cluster using the `oc login` command or by exporting the `KUBECONFIG` path. | ||
|
||
|
||
The diagram below outlines the general deployment flow for a data center application. Before proceeding, users must create a fork of the pattern repository to allow for changes to operational elements (such as configurations) and application code. These changes can then be successfully pushed to the forked repository as part of DevOps continuous integration (CI). Clone the repository to your local machine, and push future changes to your fork. | ||
|
||
|
||
image::/images/gitops-datacenter.png[GitOps for Datacenter] | ||
|
||
. Make a copy of the values file, for example, `values-global.yaml` or `values-hub.yaml`. These values files specify subscriptions, operators, applications, and other details. Additionally, each Validated Pattern contains a `values-secret` template file, which provides secret values required to successfully install the pattern. Patterns do not require committing secret material to git repositories. It is important to *avoid pushing sensitive information to a public repository accessible to others*. The Validated Patterns framework includes components to facilitate the safe use of secrets. | ||
|
||
|
||
. Deploy the application as specified by the pattern, usually by using a `make` command (`make install`). When the workload is deployed, the pattern first deploys the Validated Patterns operator, which in turn installs OpenShift GitOps. OpenShift GitOps then ensures that all components of the pattern, including required operators and application code, are deployed. | ||
|
||
Most patterns also include the deployment of an Advanced Cluster Management (ACM) operator to manage multi-cluster deployments. | ||
|
||
|
||
[id="edge-patterns"] | ||
=== Edge Patterns | ||
|
||
Many patterns include both a data center and one or more edge clusters. The diagram below outlines the general deployment flow for applications on an edge cluster. Edge OpenShift clusters are typically smaller than data center clusters and might be deployed on a three-node cluster that allows workloads on master nodes, or even on a single-node cluster (SNO). These edge clusters can be deployed on bare metal, local virtual machines, or in a public or private cloud. | ||
|
||
image::/images/gitops-edge.png[GitOps for Edge] | ||
|
||
[id="gitops-edge"] | ||
=== GitOps for edge) | ||
|
||
After provisioning the edge cluster, import or join it with the hub or data center cluster. For more details on Instructions for importing the cluster see, link:https://validatedpatterns.io/learn/importing-a-cluster/[Importing a cluster]. | ||
|
||
After importing the cluster, ACM (Advanced Cluster Management) on the data center deploys an ACM agent and agent-addon pod into the edge cluster. ACM then installs OpenShift GitOps, which deploys the required applications based on the specified criteria. | ||
|
This file was deleted.
Oops, something went wrong.