In our previous article from this series we shared a look at the logical common architectural elements found in a cloud factory solution.
The process was laid out how we approached the use case and how portfolio solutions are the base for researching a generic architecture.
It continued by sketching the process of how we approached the use case by researching successful customer portfolio solutions as the basis for a generic architectural design.
Having completed our discussions on the logical view of the architecture, it’s now time to look at a specific example.
This article walks you through an example cloud deployment scenario showing how expanding the previously discussed elements provides a basis for your own cloud factory scenarios.
Architecture review
As mentioned before, the architectural details covered here are based on real solutions using open source technologies. The example scenario presented here is a generic common architecture that was uncovered while researching those solutions. It’s our intent to provide guidance and not deep technical details.
This section covers the visual representations as presented, but it’s expected that they’ll be evolving based on future research. There are many ways to represent each element in this architecture, but we’ve chosen a format that we hope makes it easy to absorb. Feel free to post comments at the bottom of this post, or contact us directly with your feedback.
Now let’s take a look at the details in this architecture and outline the solution for an example factory deployment architecture.
Factory deployment
The key to this cloud factory cloud deployment architecture is that we’re detailing the actual deployment architecture and leaving out the jump boot host and elements covered in the previous article that are used to kick-start the initial deployment head.
Referring to the architecture diagram above, we’ll examine the two cloud deployments. The first is the
detached deployment head and the second is an example cloud environment. Both deployments are fully automated and generated using the cloud factory concept.
The detached head deployment consists of two elements, first the compute deployment which is in this case our OpenStack Directory and will be used to enable further compute nodes in whichever cloud environments are deployed. The second is a software proxy which is used to enable the further rollout of eventual storage elements in
cloud environments.
It should be noted that the software proxy is pulling all the images from the deployment head (left out of this diagram for simplicity) and ensures that only trusted images are being rolled out in the various cloud environments of choice.
The next phase is rolling out one of potentially many cloud environments. In this architecture the focus is on the main elements found in our deployments, such as the OpenStack compute controllers managing the compute nodes. A tenant of these nodes is shown as the OpenShift Container Platform providing an agnostic container-based Platform-as-a-Service (PaaS).
Due to security concerns in the cloud environment, you’ll note that the Ceph storage is isolated from any external access. The storage controllers, storage controller (RHEL-based), storage nodes, and eventual object storage elements provide scalable data coverage for our example cloud deployment.
Finally, for clarity of the cloud deployment networking architecture, elements related to monitoring, logging, communication, networking services, virutalisation, and automation were removed from the schematic diagram shown above, but remain part of the deployment as we’ll see in the data overview.
Factory deployment data
This look at an example factory deployment data view is not meant to be an all-encompassing view of the exact flow. The idea is to give an example that you use to understand how elements and their data works through the entire cloud factory deployment architecture.
With that in mind, the data flow shown is from the deployment head on the left and works its way through to the
detached deployment head, and finally is pushed to as many cloud environments as desired. The base is defined with elements ensuring all the infrastructure, monitoring, logging, and automation tools are leveraged to provide for consistent, factory-like rollouts of your cloud infrastructure.
In the deployment head, trusted images are loaded into the definitive software library element as the image source for all cloud deployments shared with the software proxy elements. Tooling is in place for social coding such as source code management, build pipelines, and communication tools. Monitoring and logging elements are used to collect data from all the local monitoring in detached deployment heads. Underlying virtualisation is managed with imaging VMs. This base deployment head supports the further deployments of detached deployment head and cloud environments.
This concludes the look at the cloud factory architecture.
What’s next
This was just a short overview of the common generic elements that make up our architecture for the cloud factory use case.
An overview of this series on cloud factory portfolio architecture:
Catch up on any past articles you missed by following any published links above.
This completes the series and we hope you enjoyed this cloud factory architectural tour.
(Article co-authored by Eric Lavarde, Consulting Principal Architect, Red Hat)
Published on Java Code Geeks with permission by Eric Schabell, partner at our JCG program. See the original article here: Cloud factory – Example factory deployment Opinions expressed by Java Code Geeks contributors are their own. |
