You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
_Some details will differ based on the requirements of a specific implementation but all validated patterns, based on a portfolio architecture, generalize one or more successful deployments of a use case._
26
26
27
-
Organizations are aiming to develop and deploy applications on an open hybrid cloud in a stable, simple, and secure way. This hybrid strategy includes multicloud deployments where workloads might be running on different clusters and on different clouds - private or public. This strategy also requires an infrastructure-as-code approach that manages versions and deployments based on specific configurations.
27
+
**Use case:**
28
28
29
-
<!--to-doNeeds a better transition
30
-
Do we need to call out this team? if not, remove it-->
29
+
- Use a GitOps approach to manage hybrid and multi-cloud deployments across both public and private clouds.
30
+
- Enable cross-cluster governance and application lifecycle management.
31
+
- Securely manage secrets across the deployment.
31
32
32
-
The Multicloud GitOps pattern addresses these requirements. With the Multicloud GitOps pattern, you can determine:
33
+
**Background:**
34
+
Organizations are aiming to develop, deploy, and operate applications on an open hybrid cloud in a stable, simple, and secure way. This hybrid strategy includes multi-cloud deployments where workloads might be running on multiple clusters and on multiple clouds—private or public.
35
+
This strategy requires an infrastructure-as-code approach: GitOps. GitOps uses Git repositories as a single source of truth to deliver infrastructure-as-code. Submitted code checks the continuous integration (CI) process, while the continuous delivery (CD) process checks and applies requirements for things like security, infrastructure-as-code, or any other boundaries set for the application framework. All changes to code are tracked, making updates easy while also providing version control should a rollback be needed.
33
36
34
-
The pattern is derived from work done by the [Red Hat Portfolio Architecture team](https://gitlab.com/redhatdemocentral/portfolio-architecture-examples/-/blob/main/spi-multi-cloud-gitops.adoc)
37
+
## Solution overview
38
+
This architecture covers hybrid and multi-cloud management with GitOps as shown in Figure 1. At a high level this requires a management hub, for DevOps and GitOps, and infrastructure that extends to one or more managed clusters running on private or public clouds. The automated infrastructure-as-code approach can manage the versioning of components and deploy according to the infrastructure-as-code configuration.
35
39
36
-
- How to use a GitOps approach to manage multiple cloud deployments in both public and private clouds.
37
-
- How to centrally manage multiple clusters, including workloads.
38
-
- How to securely manage secrets across multicloud deployments.
40
+
**Why Hybrid Multicloud management with GitOps ?**
39
41
40
-
### Red Hat Technologies
42
+
- Unify management across cloud environments.
43
+
- Dynamic infrastructure security.
44
+
- Infrastructural continuous delivery best practices.
41
45
42
-
- Red Hat OpenShift Container Platform (Kubernetes)
43
-
- Red Hat Advanced Cluster Management (Open Cluster Management)
44
-
- Red Hat OpenShift GitOps (ArgoCD)
45
-
- Hashicorp Vault
46
-
47
-
## Architecture
48
-
49
-
At a high level this requires a management hub, for DevOps and GitOps, and infrastructure that extends to more than one managed clusters running on private or public clouds.
_Figure 2. Logical diagram of hybrid multi-cloud management with GitOps._
57
+
58
+
As you can see in Figure 2, logically this solution can be viewed as being composed of an automation component, unified management (including secrets management), and the cluster(s) under management—all running on top of a user-chosen mixture of on-prem data center(s) and public cloud(s).
59
+
60
+
61
+
## The technology
62
+
63
+
The following technology was chosen for this solution.
64
+
65
+
[*Red Hat OpenShift Platform*](https://www.redhat.com/en/technologies/cloud-computing/openshift/try-it) is an enterprise-ready Kubernetes container platform built for an open hybrid cloud strategy. It provides a consistent application platform to manage hybrid cloud, public cloud, and edge deployments. It delivers a complete application platform for both traditional and cloud-native applications, allowing them to run anywhere. OpenShift has a pre-configured, pre-installed, and self-updating monitoring stack that provides monitoring for core platform components. It also enables the use of external secret management systems (like HashiCorp Vault in this case) to securely add secrets into the OpenShift platform.
66
+
67
+
[*Red Hat OpenShift GitOps*](https://www.redhat.com/en/technologies/cloud-computing/openshift/try-it) is a declarative application continuous delivery tool for Kubernetes based on the ArgoCD project. Application definitions, configurations, and environments are declarative and version controlled in Git. It can automatically push the desired application state into a cluster, quickly find out if the application state is in sync with the desired state, and manage applications in multi-cluster environments.
68
+
69
+
70
+
[*Red Hat Advanced Cluster Management for Kubernetes*](https://www.redhat.com/en/technologies/management/advanced-cluster-management) controls clusters and applications from a single console, with built-in security policies. Extends the value of Red Hat OpenShift by deploying apps, managing multiple clusters, and enforcing policies across multiple clusters at scale.
71
+
72
+
[*Red Hat Ansible Automation Platform*](https://www.redhat.com/en/technologies/management/ansible) provides an enterprise framework for building and operating IT automation at scale across hybrid clouds including edge deployments. It enables users across an organization to create, share, and manage automation—from development and operations to security and network teams.
73
+
74
+
**Hashicorp Vault** provides a secure centralized store for dynamic infrastructure and applications across clusters, including over low-trust networks between clouds and data centers.
75
+
76
+
This solution also uses a variety of *observability tools* including the Prometheus monitoring and Grafana dashboard that are integrated with OpenShift as well as components of the Observatorium meta-project which includes Thanos and the Loki API.
77
+
78
+
## Architectures
79
+
80
+
Figure 3 provides a schematic diagram overview of the complete solution including both components and data flows.
81
+
82
+
Subsequent schematic diagrams go into more detail on:
83
+
84
+
- Bootstrapping the management hub (Figure 4)
85
+
- Hybrid multi-cloud GitOps (Figure 5)
86
+
- Dynamic security management (Figure 6)
87
+
- Observability in hybrid multi-cloud environments (Figure 7)
For additional logical, physical and dataflow diagrams, please see the work done by the [Red Hat Portfolio Architecture team](https://gitlab.com/redhatdemocentral/portfolio-architecture-examples/-/blob/main/spi-multi-cloud-gitops.adoc)
92
+
_Figure 3. Overview schematic diagram of the complete solution._
93
+
94
+
95
+
### Bootstrapping the management hub
96
+
97
+
[](/images/multicloud-gitops/spi-multi-cloud-gitops-sd-install.png)
98
+
99
+
_Figure 4. Schematic diagram of bootstrapping the management hub._
100
+
101
+
As detailed below, Figure 4 provides a schematic diagram showing the setup of the management hub using Ansible playbooks.
102
+
103
+
- Set up the Red Hat OpenShift Platform that hosts the Management Hub. The OpenShift installation program provides flexible ways to install OpenShift. An Ansible playbook kicks off the installation with necessary configurations.
104
+
- Ansible playbooks are again used to deploy and configure Red Hat Advanced Cluster Management for Kubernetes and, later, other supporting components (such as external secrets management) on top of the provisioned OpenShift cluster.
105
+
- Another Ansible playbook installs HashiCorp Vault, a Red Hat partner product chosen for this solution that can be used to manage secrets for OpenShift clusters.
106
+
- An Ansible playbook is used again to configure and trigger the Openshift GitOps operator on the hub cluster. This deploys the Openshift GitOps instance to enable continuous delivery.
107
+
108
+
### Hybrid multicloud GitOps
109
+
110
+
[](/images/multicloud-gitops/spi-multi-cloud-gitops-sd-security.png)
111
+
112
+
_Figure 5. Schematic diagram of hybrid multi-cloud management with GitOps._
113
+
114
+
115
+
As detailed below, Figure 5 provides a schematic diagram showing remaining activities associated with setting up the management hub and clusters using Red Hat Advanced Cluster Management.
116
+
117
+
- Manifest and configuration are set as code template in the form of “Kustomization” yaml. It describes the end desire state of how the managed cluster is going to be like. When done, it is pushed into the source control management repository with a version assigned to each update.
118
+
- OpenShift GitOps watches the repository and detects changes in the repository.
119
+
- OpenShift GitOps creates/updates the manifest by creating Kuberenet objects on top of Red Hat Advanced Cluster Management.
120
+
- Red Hat Advanced Cluster Management provision/update/delete managed clusters and configuration according to the manifest. In the manifest, you can configure what cloud provider the cluster will be on, the name of the cluster, infra node details and worker node. Governance policy can also be applied as well as provision an agent in the cluster as the bridge between the control center and the managed cluster.
121
+
- OpenShift GitOps will continuously watch between the code repository and status of the clusters reported back to Red Hat Advanced Cluster Management. Any configuration drift or in case of any failure, it will automatically try to remediate by applying the manifest (Or showing alerts for manual intervention).
122
+
123
+
### Dynamic security management
124
+
125
+
[](/images/multicloud-gitops/spi-multi-cloud-gitops-sd-security.png)
126
+
127
+
_Figure 6. Schematic showing the setup and use of external secrets management._
128
+
129
+
As detailed below, Figure 6 provides a schematic diagram showing how secrets are handled in this solution.
130
+
131
+
During setup, the token to securely access HashiCorp Vault is stored in Ansible Vault. It is encrypted to protect sensitive content.
132
+
133
+
Red Hat Advanced Cluster Management for Kubernetes allows us to have centralized control over the managed clusters. It acquires the token from Ansible Vault during install and distributes it among the clusters.
134
+
135
+
To allow the cluster access to the external vault, we need to set up the external secret management (with Helm in this study). OpenShift Gitops is used to deploy the external secret object to a managed cluster.
136
+
137
+
External secret management fetches secrets from HashiCorp Vault using the token we created in step 2 and constantly watches for updates.
138
+
Secrets are created in each namespace, where applications can use them.
139
+
140
+
Secrets are created in each namespace, where applications can use them.
141
+
142
+
### Observability in hybrid multicloud environment
143
+
144
+
145
+
[](/images/multicloud-gitops/spi-multi-cloud-gitops-sd-monitoring.png.png)
146
+
147
+
_Figure 7. Schematic showing the use of Observatorium and other tools to add observability to the solution._
148
+
149
+
As detailed below, Figure 7 provides a schematic diagram of integrating a variety of open source tools to implement observability.
150
+
151
+
- The Grafana dashboard in Hub cluster makes queries. The central Querier component in Observatorium processes the Prom. QL queries and aggregates the results.
152
+
- Prometheus scrapes metrics in the local cluster; a Thanos sidecar pushes metrics to Observatorium to persist in storage.
153
+
- A Thanos sidecar acts as a proxy that serves Prometheus’s local data over Thanos’s gRPC API from the Querier.
154
+
- Promtail is used to collect logs and push to Observatorium’s Loki API.
155
+
- In Observatorium, the Loki distributor sends logs in batches to ingester, where they will be persisted. A couple of things to beware of: both ingester and querier require large memory consumption, will need more replicas.
156
+
- The Grafana dashboard in Hub cluster display logs via requesting: real-time display (tail) with WebSocket or a time-series-based query with HTTP.
157
+
158
+
For logical, physical and dataflow diagrams, please see excellent work done by the [Red Hat Portfolio Architecture team](https://www.redhat.com/architect/portfolio/detail/8)
159
+
160
+
## Demo Scenario
161
+
162
+
## Download diagrams
163
+
View and download all of the diagrams above in our open source tooling site.
0 commit comments